Agent核心原理与运行机制-学习笔记

目录

1. 一张图理解 Agent
2. Agent 与 Chatbot 的本质区别
3. Agent 的四大核心组件
4. Agent 为什么在近年爆发
5. Function Calling：模型如何“使用工具”
6. 三种主流 Agent Loop
7. Agent 落地的三个硬问题
8. 上下文工程：决定 Agent 表现上限
9. Plan、Default、Auto 三种运行模式
10. 工程实践框架
11. 全文速记与自测

---

1. 一张图理解 Agent

核心概念： AI Agent 是能自主感知环境、制定计划、调用工具并执行任务的智能系统。

它的基本工作方式不是“一问一答”，而是持续循环：

用户目标
   ↓
感知环境 → 制定计划 → 调用工具 → 执行动作
   ↑                              ↓
   └──────── 观察结果与反馈 ────────┘
                    ↓
          达成目标 / 调整计划 / 请求人工介入

这个闭环称为 Agent Loop：

感知（Perception）→ 规划（Planning）→ 行动（Action）→ 观察（Observation）→ 再规划

Agent 的关键不在于一次生成出“标准答案”，而在于它能否根据行动结果不断修正下一步。

---

2. Agent 与 Chatbot 的本质区别

文章使用了一个很形象的比喻：

• LLM 像一个超级大脑：懂得多、会推理、能表达，但本身没有手脚。
• AI Agent 像一个完整的人：既有大脑，也有眼睛、手脚和记忆。

对比维度	Chatbot	AI Agent
核心能力	生成内容	完成任务
交互方式	用户提问，模型回答	围绕目标进行多轮自主行动
外部世界	通常只“说怎么做”	可通过工具“真的去做”
过程结构	单次或多轮对话	感知—规划—行动—观察循环
状态能力	依赖当前对话	需要工作记忆、长期记忆与环境状态
风险水平	主要是内容错误	还可能产生真实世界的错误操作

一句话区分：Chatbot 追求“回答得好”，Agent 追求“把事情做完”。

---

3. Agent 的四大核心组件

3.1 大脑：LLM 与推理模块

负责理解目标、拆解任务、选择下一步动作和判断结果。模型越强，复杂任务中的规划与纠错能力通常越好。

3.2 眼睛：感知模块

负责读取环境信息，例如网页内容、文件、数据库记录、终端输出或工具返回值。没有可靠感知，Agent 就只能在不完整信息上猜测。

3.3 手脚：工具系统

工具把“语言意图”转换为真实操作，例如：

• 搜索资料、读取网页或查询数据库；
• 运行代码、处理文件；
• 调用业务 API；
• 操作浏览器或其他软件。

3.4 记忆：上下文与状态

记录目标、已完成步骤、工具结果、失败原因和重要约束，使 Agent 知道“我正在做什么、已经做了什么、接下来该做什么”。

---

4. Agent 为什么在近年爆发

Agent 的兴起不是单一技术突破，而是两组条件同时成熟：

1. 强推理模型出现：GPT-4 级别的模型让任务拆解、工具选择和错误修正达到可用水平。
2. 交互协议标准化：MCP、A2A 等协议逐步统一工具接入与 Agent 协作方式，降低了系统集成成本。

条件	解决的问题	带来的变化
强推理 LLM	Agent “会不会想”	能处理更长、更复杂的任务链
Function Calling	Agent “怎么可靠地下指令”	从自然语言猜测转向结构化调用
MCP 等工具协议	工具“怎么统一接入”	减少重复适配，扩大可用工具范围
A2A 等协作协议	多 Agent “怎么沟通”	支持角色分工、任务转交与协同

---

5. Function Calling：模型如何“使用工具”

Function Calling 的本质：模型不直接执行函数，而是输出符合约定格式的结构化调用意图，真正的执行由外部代码完成。

典型流程：

1. 开发者向模型声明可用工具及参数结构（JSON Schema）。
2. 模型根据用户目标选择工具，并生成结构化参数。
3. 程序校验权限与参数后执行工具。
4. 工具结果返回给模型。
5. 模型根据结果继续行动或生成最终答复。

{
  "tool": "search_flight",
  "arguments": {
    "from": "上海",
    "to": "北京",
    "date": "2026-10-01"
  }
}

模型只是生成上面的“调用请求”；查询航班的是程序，而不是模型本身。

与早期 Prompt Hack 的区别

维度	Prompt Hack	Function Calling
输出形式	依赖提示词约束自然语言格式	由 Schema 约束结构
解析稳定性	容易缺字段、格式漂移	更稳定、可校验
早期失败率	文章给出的范围为 15%–25%	主流模型的格式错误率已接近 0
工程可维护性	低	高

---

6. 三种主流 Agent Loop

6.1 ReAct：边思考，边行动

ReAct（Reason + Act）让模型在每一步根据当前观察决定下一步动作。

思考 → 行动 → 观察 → 思考 → 行动 → ……

• 优点：灵活，适合信息不足、路径未知的探索型任务。
• 缺点：工具调用次数多，token 与时间成本较高，也容易在局部问题中绕圈。

6.2 Plan-and-Execute：先规划，再执行

模型先生成较完整的计划，再按计划执行；必要时才重新规划。

• 优点：步骤稳定、成本较低、容易追踪进度。
• 缺点：初始计划若基于错误假设，后续步骤可能一起偏离。
• 适用：流程清楚、依赖明确、重复性较高的任务。

6.3 Reflexion：从失败中反思

Agent 不只重试，还会分析失败原因，形成可用于下一轮的经验。

• 优点：能针对失败调整策略，复杂任务中纠错能力强。
• 缺点：需要额外的评估、反思和重试，token 消耗最高。

三种模式对比

模式	核心机制	优势	代价	更适合
ReAct	每步思考并行动	灵活探索	调用多、成本高	路径未知的任务
Plan-and-Execute	先整体规划再执行	结构清晰、成本较低	依赖计划质量	步骤明确的任务
Reflexion	失败后总结再尝试	擅长纠错	token 消耗最高	高难度、允许迭代的任务

实际工程中通常不会三选一，而是混合使用：先 Plan-and-Execute 建立骨架，在不确定步骤使用 ReAct，失败后再触发 Reflexion。

---

7. Agent 落地的三个硬问题

7.1 可靠性会随步骤数迅速下降

如果每一步成功率为 (p)，连续执行 (n) 步且每一步都必须成功，则端到端成功率约为：

$$ P_{total}=p^n $$

文章给出的例子：单步失败率为 5%，即单步成功率为 95%。执行 20 步后：

$$ 0.95^{20}\approx 35.8%\approx 36% $$

这说明即使每一步“看起来已经很准”，长链任务仍可能非常不可靠。

工程启示：

• 减少不必要的步骤和工具调用；
• 对关键步骤做参数校验和结果验证；
• 使用幂等操作，允许安全重试；
• 设置检查点，使失败后能从中间恢复；
• 在高风险节点要求人工确认。

7.2 成本与延迟放大

Agent 需要多轮思考、调用工具、读取结果和修正计划。文章指出，其 token 消耗可能是普通对话的 4–15 倍。

因此，系统优化不能只追求“模型更强”，还要关注：

• 是否每一步都需要大模型；
• 是否能缓存重复结果；
• 是否能把大文件或历史信息移出上下文；
• 是否能用规则或小模型完成简单判断；
• 是否设置了步数、时间和预算上限。

7.3 安全与幻觉

Chatbot 的错误通常停留在文本层；Agent 的错误可能变成真实操作。主要风险包括：

• 调错工具或传错参数；
• 越权访问、修改或删除数据；
• 把不可信网页内容当作指令；
• 在事实不足时“补全”信息；
• 失败后反复重试，放大影响。

---

8. 上下文工程：决定 Agent 表现上限

上下文工程（Context Engineering）是为模型选择、组织和维护当前任务所需信息的系统方法。

文章的关键判断是：Agent 的表现上限往往由上下文质量决定，而不只是由模型能力决定。

为什么上下文不是越多越好

当上下文变成“历史垃圾场”时，会出现：

• 重要约束被大量无关信息淹没；
• 过期结果与最新状态冲突；
• token 成本与响应延迟增加；
• 模型更难判断哪些信息可信、哪些需要忽略。

四种核心优化策略

策略	含义	典型做法
卸载 Offload	不把所有信息都塞进提示词	将日志、文件、长历史存到外部存储，只保留引用
检索 Retrieve	在需要时取回相关信息	RAG、关键词搜索、向量检索、结构化查询
隔离 Isolate	防止不同任务或角色互相污染	子 Agent 独立上下文、工具结果分区、权限隔离
压缩 Compress	保留结论，减少冗余	摘要、状态表、阶段性检查点、去重

---

9. Plan、Default、Auto 三种运行模式

这三种模式解决的是同一个矛盾：自主性越高，执行效率通常越高，但失控风险也会增加。

模式	Agent 行为	人的角色	适用场景
Plan	先分析并给出计划，不直接执行	先审批方案	目标不清、影响范围大、高风险任务
Default	边执行边在关键节点确认	阶段性监督	日常开发、内容处理、可控业务流程
Auto	在授权范围内自主完成	设置边界与验收	低风险、可回滚、规则清晰的任务

推荐把它们设计成一条流水线：

Plan：先把事情想清楚
  ↓
Default：边做边审，验证关键假设
  ↓
Auto：路径成熟后，在清晰边界内放手执行

---

10. 工程实践框架

设计或评估一个 Agent 时，可以依次回答以下问题：

10.1 目标层

• 最终交付物是什么？
• 成功标准是否可验证？
• 哪些约束不能违反？

10.2 规划层

• 任务能否拆成更短的步骤？
• 应采用 ReAct、Plan-and-Execute，还是混合模式？
• 什么情况需要重新规划或停止？

10.3 工具层

• 每个工具的输入、输出和副作用是否清晰？
• 参数是否使用 Schema 校验？
• 工具权限是否遵循最小授权原则？

10.4 上下文层

• 当前步骤真正需要哪些信息？
• 哪些信息应该卸载、检索、隔离或压缩？
• 如何区分可信指令、环境数据与不可信内容？

10.5 可靠性与安全层

• 关键结果如何验证？
• 操作能否安全重试、撤销或回滚？
• 哪些动作必须由人确认？
• 是否有步数、时间、token 和费用上限？

10.6 观测层

• 是否记录每次计划、调用、返回值与错误？
• 能否定位失败发生在哪一步？
• 能否用数据持续优化成功率与成本？

---

11. 全文速记与自测

11.1 七句话速记

1. Agent 的本质不是“更会聊天”，而是“能围绕目标持续行动”。
2. Agent Loop 是感知、规划、行动、观察组成的反馈闭环。
3. Function Calling 让模型输出结构化调用意图，代码负责真正执行。
4. ReAct 重灵活，Plan-and-Execute 重结构，Reflexion 重纠错。
5. 长任务会放大微小的单步错误，(0.95^{20}) 只剩约 36%。
6. 上下文质量决定 Agent 能否在正确的信息上做正确的判断。
7. 真正可用的 Agent 必须同时管理能力、成本、权限、验证与回滚。

11.2 自测题

1. 为什么说 Agent 与 Chatbot 的核心区别是“完成任务”而不是“回答问题”？
2. Function Calling 为什么能减少格式错误，却不能消除业务错误？
3. ReAct、Plan-and-Execute、Reflexion 分别适合什么任务？
4. 单步成功率达到 95%，为什么 20 步任务仍可能失败？
5. 上下文工程中的“卸、检、隔、压”分别解决什么问题？
6. 为什么 Auto 模式仍然需要边界与人工介入机制？

参考答案

1. 因为 Agent 能感知环境、使用工具并根据结果继续行动，目标是产生外部结果，而不只是生成文本。
2. Schema 可以约束调用格式，但模型仍可能选错工具、误解参数，程序也可能遇到权限、数据和环境错误。
3. ReAct 适合路径未知的探索任务；Plan-and-Execute 适合步骤清晰的任务；Reflexion 适合高难度且允许迭代纠错的任务。
4. 多步任务要求每一步连续成功，端到端成功率会按 (p^n) 复合下降。
5. 卸载减少上下文负担；检索按需补充信息；隔离防止任务互相污染；压缩保留结论并去除冗余。
6. 因为自动化会把模型错误转化为真实操作，必须用权限、预算、停止条件、验证与审计限制影响范围。