尧图网站设计 尧图网站设计YAOTU DESIGN
ARTICLE DETAIL

资讯详情

深耕网站设计与一线实操的经验洞察。

深入理解大模型Agent:从理论到年报ReAct Agent实战

深入理解大模型Agent:从理论到年报ReAct Agent实战 第一部分 理论篇大模型Agent核心原理1.1 Agent的定义演化时间轴Agent 模型 记忆 工具 规划 循环1.2 现代Agent四层架构感知、规划、执行、记忆现代工业落地的大模型 Agent一般拆解为感知层、规划层、执行层、记忆层四大核心模块。四层相互循环协作记忆层贯穿整个生命周期共同实现智能体自主思考、工具调用、任务迭代执行的完整能力闭环。1.2.1 感知层Perception Layer多源输入与上下文组装感知层是Agent的“感官入口”负责接收来自外部世界的各类信息将多路输入整合、组装成完整Prompt上下文喂给后续推理模块。1.2.1.1 输入来源类型用户文本指令用户自然语言描述的任务目标和约束条件。工具返回结果函数调用、API执行完成后返回的数据作为本轮任务的反馈信息。历史对话记录从记忆层读取出来的短期、长期上下文信息。外部环境状态网页内容、本地文件、代码仓库等环境读取的数据。多模态输入可选图像、表格、PDF等非文本类信息。1.2.1.2 Prompt上下文组装过程感知层将多路信息拼接成大模型可识别的消息列表依次放入系统提示词、检索得到的长期记忆内容、历史对话上下文、当前用户输入。1.2.1.3 感知层核心设计问题信息筛选什么信息必须传入上下文哪些冗余信息可以过滤上下文窗口控制上下文超长时如何截断、摘要压缩避免超出模型Token上限。多模态统一表征图片、表格等异构信息如何转换成模型可理解的格式。1.2.2 规划层Planning LayerLLM作为推理引擎规划层是Agent的大脑Agent自主决策、任务分解、动态反思的能力全部由该层提供。规划层质量直接决定Agent能力上限大模型本身的推理能力就是Agent的规划智慧。1.2.2.1 四项核心职责目标理解解析用户意图提取任务核心目标与约束条件把自然语言转换成机器可处理的任务表征。路径规划将复杂大目标拆解为多个子任务确定任务执行顺序、挑选合适工具序列生成行动计划。动态调整根据工具返回的执行结果实时更新计划当执行结果不符合预期时重新规划后续执行步骤。自我反思审查中间执行结果和历史操作判断任务是否回退、修正或者直接终止避免错误不断累积放大。1.2.2.2 典型推理模式思维链CoT规划层最常使用Chain‑of‑Thought提示词范式拆分Thought思考、Action行动两个阶段System分步骤思考先列出计划再执行。Thought用户要分析销售数据需要读取 CSV 文件计算各月环比找出峰值月份生成摘要报告Action: 读取销售文件1.2.3 执行层Execution Layer从指令到真实行动执行层是Agent的手脚负责落地规划层输出的行动指令完成和外部世界交互拿到任务执行结果再反馈回去开启新一轮循环。1.2.3.1 三大核心职责工具调用解析规划层输出的行动指令分发到对应的工具、接口同时处理调用超时、异常报错、权限不足等问题。环境交互操控浏览器、读写本地文件与数据库、运行脚本命令完成真实环境操作。结果回收将工具返回的数据格式化为文本注入下一轮Prompt上下文触发规划层开启新一轮推理循环。1.2.3.2 执行层完整工作流规划层输出行动指令 → 工具路由器分发任务 → 工具执行 → 结果格式化与异常处理 → 将结果注入上下文触发下一轮规划。1.2.4 记忆层Memory LayerAgent的知识基础记忆层相当于Agent的“记忆系统”用来存储对话、任务、知识信息让智能体拥有跨轮次长期认知。Agent记忆体系一共分为四类短期记忆当前对话消息历史直接拼入Prompt上下文受模型上下文窗口限制一般保存最近N轮对话。长期记忆将重要信息做Embedding向量化存入向量数据库每次任务开始时通过语义检索取出相关历史信息注入Prompt。情景记忆记录具体时序事件例如“用户上次项目框架是React”偏向保存事件发生过程类似人类经历回忆。语义记忆存储通用规则、抽象知识例如“用户偏好简洁风格报告”偏向概念、事实、用户偏好类知识。1.2.4.1 记忆读写时机读取时机每轮对话启动、感知层组装Prompt、规划层参考历史决策时读取记忆写入时机对话结束提取摘要、检测重要偏好信息、任务完成保存执行过程与结论。1.2.5 四层协作一次完整Agent执行全流程四层模块并不是一次性单向运行而是循环迭代记忆层全程贯穿任务生命周期每一步都可以读写记忆。完整执行链路感知层接收输入 → 规划层推理规划 → 执行层调用工具 → 执行层回收结果 → 规划层再次规划迭代 → 记忆层写入任务成果1.2.5.1 实战案例任务「帮我写一份竞品分析报告」感知层接收用户「竞品分析」指令从记忆层读取用户所在行业背景信息组装完整Prompt规划层任务拆解生成计划搜索竞品A →搜索竞品B →对比分析 →生成报告摘要执行层依次调用搜索工具获取竞品A、竞品B结构化数据规划层汇总搜索结果再次推理分析产出竞品对比文本记忆层将本次竞品分析结论写入长期记忆后续对话可以直接复用本次成果。1.3 ReAct循环Thought‑Action‑Observation推理行动交织ReAct 是目前工业Agent最主流的执行范式核心思想就是推理思考Thought和行动执行Action交替循环。大模型不再一次性给出最终答案而是先思考、再动手调用工具、观察返回结果基于新信息再次思考往复迭代直到任务完成。1.3.1 ReAct完整执行流程用户输入目标任务Thought思考分析当前任务拆解步骤制定下一步行动计划判断是否需要调用外部工具。Action行动执行计划调用对应的工具接口如果信息已经充足也可以直接输出最终答案结束任务。Observation观察接收工具返回的数据、结果反馈把外部信息带回给大模型。Thought再次思考评估刚刚拿到的结果判断任务是否完成、数据是否充足规划后续步骤。重复「Thought‑Action‑Observation」循环直到模型产出Final Answer最终答案任务终止。1.3.2 三个阶段详解1.3.2.1 Thought 思考阶段属于模型内部推理过程不需要接触外部环境。负责解析现状、反思上一轮结果、判断缺口、生成下一步策略。是Agent“动脑”的环节。1.3.2.2 Action 行动阶段Agent对外交互的环节。按照思考得出的方案发起工具调用例如联网搜索、读取文件、查询数据库。1.3.2.3 Observation 观察阶段接收外部世界给到Agent的反馈。将工具返回的原始结果整理成可读文本送入上下文供给下一轮思考使用。1.3.3 ReAct 的优势与局限1.3.3.1 ReAct 的优势可解释性强Thought 步骤暴露推理过程方便调试、审计和用户理解。动态适应每一步 Observation 都能够修正计划不再依赖一次性生成完美规划。支持多步工具链天然支持任务先后依赖关系先查A才能查B相比单次工具调用能力更强。框架简洁仅依靠提示词约束 工具路由即可实现开发门槛低LangChain、AutoGPT 等大量开源Agent框架均基于该范式。1.3.3.2 ReAct 的局限无显式验证步骤行动完成之后缺少专门的校验环节。一旦工具返回结果出错错误会在循环迭代中不断累积放大。单路径推进同一时刻只探索一条执行路线无法并行尝试多种备选方案也不具备任务分支回溯能力。上下文随循环增长每一轮 Thought‑Action‑Observation 的内容都会追加进Prompt上下文长任务很容易逼近模型上下文窗口上限同时带来更高的 Token 消耗成本。依赖 Prompt 格式稳定性强依赖大模型输出严格遵守指定格式。一旦模型发生输出漂移返回格式错乱工具解析失败就会直接造成Agent运行崩溃。1.4 OTAC循环Observe‑Think‑Act‑Check带校验的自主循环OTAC 是在 ReActThought‑Action‑Observation范式之上迭代升级出来的Agent循环框架。最核心的改动就是在行动之后新增了Check自我检查环节解决ReAct缺少结果校验、错误不断累积放大的痛点。1.4.1 ReAct存在的核心缺陷没有验证环节行动完成后直接进入下一轮思考Agent不会主动校验执行结果是否达到预期错误会悄无声息流入后续步骤。错误累积放大在长任务流程里早期步骤产生的错误结果被写入上下文后续全部推理都会建立在错误信息的基础之上。无回退机制一旦执行路径出错ReAct只会一直向前推进缺少“退回上一步、更换备选方案”的纠错能力。1.4.2 OTAC改进思路ReAct循环流程Thought → Action → Observation循环过程中无校验步骤。OTAC循环流程Observe → Think → Act → Check每一次行动结束之后都会执行Check验证校验失败时可触发重试或者任务回退。1.4.2.1 设计哲学遵循「先做再查」的执行理念。每次行动结束后主动校验执行成果把错误消灭在当前步骤而不是等到整个任务失败后再回头排查问题。目前 Claude Code、Manus、Devin、OpenAI Operator 这类工程型Agent工具都内置了该验证思想在执行代码、操控网页之后添加结果校验步骤。1.4.3 Check步骤OTAC的核心创新Check阶段负责检验Act行动产出的结果校验完成后一共有三种决策分支继续Pass条件执行结果符合预期无异常问题处理方式将结果写入记忆进入下一轮Observe步骤继续推进任务。重试Retry条件执行结果没有达到预期但是任务的前进方向正确处理方式调整参数或者更换工具在当前步骤之内重新执行Act一般设置最大重试次数防止无限循环。回退Rollback条件执行出现严重错误、Agent走入错误路径处理方式回退到前一个安全状态重新开启Think环节制定全新的行动方案。1.4.3.1 Check校验时需要思考的核心问题结果是否包含任务预期产出的内容是否出现报错、异常、空返回等负面现象当前距离最终任务目标还缺少哪些信息1.4.3.2 案例对比┌──────────────────────────────────────────┐ ┌──────────────────────────────────────────────────────┐ │ ReAct无校验错误跑偏 │ │ OTAC带Check自检重试成功 │ └──────────────────────────────────────────┘ └──────────────────────────────────────────────────────┘ 开始任务读取网页价格 开始任务读取网页价格 │ │ ▼ ▼ Thought打开网页获取价格 Observe目标读取网页价格暂无结果 │ │ ▼ ▼ Action访问目标网址 Think计划调用浏览器访问网页 │ │ ▼ ▼ Observation页面空白、加载失败 Act第一次执行访问网页 │ │ ▼ ▼ Thought网页无价格改用搜索引擎查询 Check页面空白加载失败 → Status:RETRY刷新重试 │ │ ▼ │ Action搜索商品价格 ┌───────────┘ ▼ ▼ Observation拿到第三方报价 Act第二次重新访问网页 │ │ ▼ ▼ 输出最终答案 Check页面加载成功读到价格¥199 → Status:PASS │ ▼ 任务完成输出价格结果1.4.4 Check 对比 ReAct 里 Thought 的核心区别Thought 的首要目标是「往前规划下一步干什么」Check 的唯一目标是「回头核验上一步有没有干成」。维度ReAct 的 Thought顺带判断结果OTAC 的 Check独立校验步骤核心目标规划后续行动向前推进任务核验上一步行动是否达标审查成果校验属性隐性、可选可跳过校验显性、强制每一步 Act 之后必经关卡失败分支无原生重试 / 回退机制容易跑偏三分支PASS / RETRY / ROLLBACK视线方向看向未来下一步干什么看向过去刚才有没有做成容错方式发现异常就换一条新路往前走发现异常优先在原地修复错误1.5 自主决策与复杂任务分解策略1.5.1 agent 自主策略依靠大模型理解目标实时做出判断摆脱固定路由严格规定的if else代码。Agent 在执行任务的全过程需要自主回答三个核心问题选什么工具当前目标需要调用哪一个工具、参数如何配置。大模型依据工具描述、上下文动态匹配不需要硬编码路由逻辑。继续还是停止判断任务是否完成剩余多少步骤。评估当前进展是否达成目标决定是否终止循环。自己做还是求助遇到高风险操作删除文件、发送邮件或者信息不足时主动暂停任务、向用户确认拒绝盲目执行。Agent 根据自身信心程度输出三种决策结果决策状态触发条件Agent 动作典型场景继续执行信心充足信息完整按计划执行下一步行动无需等待确认搜索公开信息、读取本地文件、生成文稿低风险、可逆操作主动停止不确定性高缺少关键信息向用户提问补齐缺失信息之后继续执行报告受众不明确需要确认是面向内部员工还是外部客户拒绝执行高风险、越权操作告知用户风险等待用户显式授权才可执行删除数据库表、群发邮件、修改生产环境配置不可逆高危操作1.5.2 复杂长任务任务分解为什么需要任务分解LLM 上下文窗口有限单次无法容纳全部中间结果子任务可以并行执行提升执行速度分治策略降低单步出错概率每个子任务结果能够独立校验。1.5.2.1 三种任务分解策略顺序分解Sequential任务拆分成存在先后依赖的子步骤一步一步执行前一步输出作为后一步输入。示例分析论文 →读取 PDF →提取摘要 →查找关键词 →生成报告适用场景子任务之间强前后依赖。并行分解Parallel子任务之间互不依赖可同时分配给多个 Agent 或多线程执行最后汇总全部结果。示例竞品调研同时搜索 A、B、C 三家公司资料之后汇总对比。适用场景多个独立任务没有数据依赖关系。层级分解Hierarchical大任务拆成中型任务中型任务继续拆分更小任务形成多层嵌套Planner → Sub‑Planner → Executor。示例开发功能 →设计模块 →(设计接口 编写单元测试 实现代码) →集成测试适用场景任务复杂度很高需要多层规划。1.5.2.2 企业 Agent 四大共性决策原则最小权限原则只申请完成当前任务最小权限不主动扩大权限范围可撤销优先优先执行可逆操作草稿 发送、移动 删除透明行动重要操作向用户展示过程禁止后台无声执行人在回路高风险节点永远保留人类确认入口Agent 自主决策不等于无监督运行。1.6 Agent面临的边界挑战与Multi‑Agent展望1.6.1 挑战一幻觉传播循环错误放大1.6.1.1 幻觉传播发生流程步骤1LLM产生幻觉输出错误事实 / 虚假数据步骤2错误 Observation 被写入上下文步骤3后续所有 Thought 基于错误上下文推理步骤N最终答案建立在完全错误的基础上风险说明幻觉比单次调用更危险幻觉在循环中被不断「确认」和放大。1.6.1.2 缓解幻觉的三层策略层级措施工具层1. 工具返回值做格式验证拦截异常输出2. 高风险工具结果做二次 API 查证3. 工具调用失败时返回明确错误而非空值循环层1. OTAC 的 Check 步骤提前发现矛盾2. 设置关键事实的「校验点」Prompt3. 跨轮次检测信息前后一致性系统层1. 使用 Retrieval‑Augmented 减少凭空生成2. 关键输出步骤引入人工审核节点3. 日志记录每轮 TAO/OTAC便于事后溯源1.6.2 挑战二工具滥用与安全对齐1.6.2.1 三大安全风险风险类型问题描述对策工具过度调用Agent 为「确保结果」频繁调用工具导致API成本失控千刀慢剐或因重复写操作产生副作用。设置工具调用预算max_tool_calls并在 Check 阶段判断是否「已足够」避免冗余调用。权限蔓延攻击恶意用户通过 Prompt 诱导 Agent 调用超出授权范围的工具Prompt Injection / 越权指令。工具调用白名单 上下文沙箱隔离每次工具调用前验证是否在当前任务的权限范围内。不可逆操作风险Agent 执行了删除数据、发送邮件、转账等不可撤销操作且没有提前向用户确认。操作前分类可逆操作自动执行不可逆操作强制暂停等待显式授权人在回路。1.6.2.2 Agent安全对齐的四个维度维度说明意图对齐Agent 真正执行的是用户的目标而不是字面指令避免目标错位行为约束操作边界由权限系统而非 Prompt 决定不依赖 LLM 的「自觉」透明可审计所有工具调用和决策过程可追溯、可解释可撤销设计优先选择可撤销方案为人类干预保留空间1.6.3 从单Agent到Multi‑Agent协作1.6.3.1 单 Agent 的天花板上下文窗口限制超长任务中间信息丢失单一能力瓶颈一个 LLM 无法精通所有领域串行执行慢复杂任务各步骤无法并行单点故障一个 Agent 出错整个任务失败1.6.3.2 Multi‑Agent角色分工突破限制Agent角色职责类比Orchestrator调度Agent总调度Agent负责任务分解、分配给子Agent、汇总结果项目经理Specialist Agent专家Agent只负责单一领域代码、搜索、写作…模型和工具针对领域优化领域工程师Critic Agent评审Agent专门验证其他Agent的输出类似OTAC的Check但由独立Agent执行质检员/审核员Memory Agent记忆Agent负责信息检索、存储和压缩为其他Agent提供统一的知识服务知识库管理员第二部分 实战篇解析LLM如何调用ToolReAct教学项目2.1 方式一手写Prompt实现工具调用不依赖 API 的 Function Calling 能力而是在 System Prompt 里和模型约定一种固定的输出格式程序再用正则把这个格式翻译回结构化数据从而知道模型想调用哪个工具、传什么参数。字段含义由谁输出Thought推理过程分析当前状态决定下一步做什么模型Action要调用的工具名模型Action Input工具入参JSON 格式模型Final Answer模型认为信息够了输出最终答案循环结束模型Observation工具执行结果程序执行后填回模型不输出流程如下① 调 LLM带 stop[Observation:]让模型停在调用工具前 ↓ ② 正则解析输出 ├─ 有 Final Answer: → 结束返回答案 ├─ 有 Action: → 继续 └─ 都没有 → 格式解析失败unparseable ↓ ③ 程序执行工具 TOOLS_MAP[action](**action_input) ↓ ④ 把 assistant 输出 Observation: 结果 追加回 messages ↓ ⑤ 回到 ①循环直到 Final Answer 或达到 max_steps2.2 方式二原生Function‑Calling实现工具调用把工具说明书用 JSON Schema 传给 API 的 tools 参数让模型原生返回结构化的 tool_calls程序只需消费这些结构不再自己解析文本。名称作用toolsTOOLS_SCHEMA传入工具列表的 JSON Schema工具名、描述、参数类型、必填项tool_choice“auto”让模型自己决定调用哪个工具或直接回答finish_reason判断模型为什么停tool_calls 要调工具stop 给答案了① 调 LLM带 toolsTOOLS_SCHEMA, tool_choiceauto ↓ ② 看 finish_reason ├─ stop → 模型直接给答案循环结束 └─ tool_calls → 继续 ↓ ↓ ③ 遍历 msg.tool_calls逐个执行 - tool_call.function.name → 工具名 - tool_call.function.arguments → 参数json.loads 转 dict - 执行 TOOLS_MAP[name](**args) → 得到结果 ↓ ④ 把结果以 role:tool tool_call_id 回填进 messages ↓ ⑤ 回到 ①循环直到 finish_reason stop 或达到 max_steps
返回列表