第一部分 理论篇：大模型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 Layer）：LLM作为推理引擎
规划层是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 Layer）：Agent的知识基础
记忆层相当于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 是在 ReAct（Thought‑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 幻觉传播发生流程
- 步骤1：LLM产生幻觉输出（错误事实 / 虚假数据）
- 步骤2：错误 Observation 被写入上下文
- 步骤3：后续所有 Thought 基于错误上下文推理
- 步骤N：最终答案建立在完全错误的基础上
风险说明：幻觉比单次调用更危险，幻觉在循环中被不断「确认」和放大。
1.6.1.2 缓解幻觉的三层策略
| 层级 | 措施 |
|---|---|
| 工具层 | 1. 工具返回值做格式验证，拦截异常输出 2. 高风险工具结果做二次 API 查证 3. 工具调用失败时返回明确错误而非空值 |
| 循环层 | 1. OTAC 的 Check 步骤提前发现矛盾 2. 设置关键事实的「校验点」Prompt 3. 跨轮次检测信息前后一致性 |
| 系统层 | 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如何调用Tool（ReAct教学项目）
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_steps
2.2 方式二：原生Function‑Calling实现工具调用
把"工具说明书"用 JSON Schema 传给 API 的 tools 参数，让模型原生返回结构化的 tool_calls，程序只需消费这些结构，不再自己解析文本。
| 名称 | 作用 |
|---|---|
| tools=TOOLS_SCHEMA | 传入工具列表的 JSON Schema（工具名、描述、参数类型、必填项） |
| tool_choice="auto" | 让模型自己决定：调用哪个工具，或直接回答 |
| finish_reason | 判断模型为什么停：tool_calls = 要调工具，stop = 给答案了 |
① 调 LLM（带 tools=TOOLS_SCHEMA, tool_choice="auto"）
↓
② 看 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