深入理解 AI Agent · AGENT #02：Agent 的四大核心机制，拆开来看每个都在干什么

前篇回顾Agent 基础篇 #01 从LLM到Agent →Agent 基础篇 #02 四大核心机制上一篇建立了 Agent 的整体框架Agent LLM Planning Tool Use MemoryLilian Weng 的经典分解加上 Reflection 作为第四大机制。这个公式看起来很简洁但每个模块展开之后都是一个独立的工程领域。这篇把四个机制拆开逐个看它们在工程中到底在做什么、解决什么问题、有哪些经典方案。不追求穷尽每个细节——后续 RAG、MCP、Memory 系列会各自深入——而是要建立一张全景图知道每个模块的边界在哪以及它们怎么协作。1. PlanningAgent 怎么拆解任务LLM 的一次推理只能生成一段文本。当任务需要 10 步才能完成时Agent 不能一次性把 10 步全想出来然后一口气执行——它需要在执行过程中不断调整计划。这就是 Planning 模块要解决的问题。1.1 三种规划策略的演进Planning 的发展经历了三个阶段每个阶段都在解决前一个阶段的短板策略核心思路优势局限代表作Chain-of-ThoughtCoT单路径逐步推理一步一步想简单有效零额外开销不能与外部工具交互走错了无法回头Wei et al., 2022Tree of ThoughtsToT多路径搜索每一步探索多个分支并择优推理能力更强适合高价值决策计算成本高每步多次 LLM 调用Yao et al., 2023Plan-and-Execute先生成完整计划再逐步执行执行中可以修正计划全局视角支持步骤间依赖和并行规划阶段开销大计划可能因环境变化而失效LangGraph / HuggingGPT这三者的关系是递进的CoT 解决能推理的问题ToT 解决推理质量的问题Plan-and-Execute 解决推理与执行结合的问题。工程选择原则多数生产场景用 ReAct单步推理行动循环就够了。ToT 适合错误代价极高的场景如金融决策Plan-and-Execute 适合步骤多且有依赖关系的任务如查数据库 → 分析 → 写报告 → 发邮件。不要在简单任务上用重型规划——规划本身也有延迟和出错的风险。1.2 ReAct最广泛使用的规划模式上一篇已经介绍过 ReAct 的 Thought → Action → Observation 循环。这里补充一个工程细节ReAct 的本质是规划与执行交替进行——每一步 Thought 就是一次微型规划决定下一步做什么Observation 则是从环境中获取反馈用来修正后续计划。这种模式的好处是灵活——不需要提前制定完整计划可以边走边看。坏处是缺乏全局视角如果任务有 20 步Agent 可能走到第 10 步才发现一开始的方向就是错的。1.3 Dream-SaaS 中的规划Dream-SaaS 的 Supervisor 采用的是 Plan-and-Execute 的变体。Supervisor 在收到用户请求后先做一次意图分析和任务拆解决定需要调用哪些子 Agent、以什么顺序执行。执行过程中如果某个子 Agent 返回的结果不符合预期比如代码审查 Agent 发现了严重问题Supervisor 可以修改后续计划——比如增加一轮修复验证步骤。这比纯 ReAct 更高效因为避免了每做一步都重新规划全局的开销也比静态 DAG 更灵活因为可以在运行时调整执行路径。2. Tool UseAgent 怎么扩展能力LLM 本身只能处理文本。要让 Agent 查数据库、调 API、操作浏览器就需要 Tool Use 机制——让模型能够输出结构化的工具调用请求由外部系统执行后把结果返回。2.1 从 Function Calling 到 MCP 的演进Tool Use 的发展可以分三个阶段第一阶段Function Calling2023OpenAI 在 GPT-3.5/4 中引入 Function Calling定义了工具调用的基本范式开发者用 JSON Schema 描述工具的输入输出格式模型在推理时输出结构化的调用请求应用层执行后把结果喂回模型。这个阶段的问题每个平台定义自己的工具格式——OpenAI 一套、Anthropic 一套、Google 一套。工具开发者需要为每个平台写不同的适配代码N 个工具 × M 个平台 N×M 个集成。第二阶段Computer Use2024-2025Anthropic 的 Computer Use 让 Agent 直接看屏幕截图、计算鼠标坐标、点击按钮。范式转变是不再需要为每个软件写专门 APIAgent 可以操作任何有图形界面的软件。但代价是速度慢、精度有限、风险高——能点击任何按钮的 Agent也可能点错按钮。第三阶段MCP 统一协议2024 至今Anthropic 在 2024 年 11 月发布 MCPModel Context Protocol定义了工具发布和发现的标准协议。工具开发者只需实现一次 MCP Server任何支持 MCP 的 ClientClaude、GPT、开源框架都能直接调用。N×M 的集成问题变成了 NM。阶段时间范式核心问题Function Calling2023每个平台自定义工具格式N×M 集成成本工具不可复用Computer Use2024-2025Agent 直接操作 GUI速度慢、精度低、安全风险MCP2024 至今统一协议标准化NM 集成工具可复用可发现2.2 Tool Use 的工程挑战即使有了 MCP 这样的标准协议Tool Use 在工程中仍有几个硬问题工具选择准确率当可用工具超过 10 个时模型选错工具的概率显著上升。Anthropic 的解决方案是 Tool Search Tool——先让模型搜索相关工具再调用而不是一次性把所有工具描述塞进 prompt。上下文污染工具返回的大量数据如一个 10MB 的日志文件会挤占上下文窗口把重要信息挤出去。Anthropic 在 2025 年底推出的 Programmatic Tool Calling 让模型写代码来处理工具返回的数据只把摘要放回上下文。错误处理工具调用可能超时、返回错误、返回格式异常。Agent 需要有能力判断工具调用失败了并决定下一步——重试、换工具、还是放弃。Tool Use 的核心矛盾工具越多Agent 能力越强但工具选择越容易出错。这就是为什么给 Agent 加 50 个工具并不比加 5 个精准的工具更好——工程上的关键是工具描述的质量和选择策略而不是数量。2.3 Spring AI 中的 Tool 定义示例Tool(description 搜索知识库中的相关文档) public ListDocument searchKnowledgeBase( Param(query) String query, Param(topK) int topK ) { return knowledgeBaseService.search(query, topK); }Spring AI 的Tool注解让工具定义变得声明式——只需描述工具做什么、接受什么参数框架负责生成 JSON Schema 并注册到 Agent。MCP 协议则进一步把这个注册过程标准化让工具可以跨框架复用。3. MemoryAgent 怎么记住经验LLM 本身没有记忆——每次 API 调用都是独立的模型不记得上一轮对话。但一个有用的 Agent 需要记住用户偏好、历史操作、过去的错误。这就是 Memory 模块的职责。3.1 三层记忆架构参照认知科学的记忆分层Agent 的记忆系统通常分为三层层级对应认知科学存储位置内容生命周期工作记忆工作记忆Working Memory上下文窗口当前对话历史 当前任务状态 检索到的相关记忆单次会话短期记忆短期记忆Short-term Memory外部存储Redis / DB最近几轮对话的摘要、用户最近的操作跨会话定期清理长期记忆长期记忆Long-term Memory向量数据库 结构化存储用户偏好、历史经验、学到的知识永久工作记忆就是上下文窗口本身容量有限4K-200K tokens会话结束就消失。短期记忆是对近期信息的压缩和摘要存储在外部系统中。长期记忆是持久化的经验和知识需要通过检索才能加载到工作记忆中。3.2 记忆的工程实现三层记忆听起来简单工程实现中有几个关键决策什么该记、什么不该记如果什么都记存储会迅速膨胀检索也会变慢。Agent 需要判断哪些信息值得长期保存。通常的做法是让 LLM 在每轮对话结束后做一次记忆提取——从对话中抽取关键事实、用户偏好、重要决策存入长期记忆。怎么检索长期记忆存储在向量数据库中通过语义相似度检索。但纯语义检索不够——用户问上次那个项目怎么样了需要的是时间最近的相关记忆而不是语义最相似的记忆。生产级系统通常采用混合检索语义相似度 时间衰减 重要性权重的加权组合。怎么遗忘记忆不是越多越好。过时的信息会干扰检索质量。成熟的记忆系统需要定期清理、合并和压缩——把多条相关记忆合并为一条摘要淘汰长期未访问的记忆。Dream-SaaS 的记忆分层工作记忆 当前对话上下文 从向量库检索的相关记忆片段短期记忆 近 7 天的对话摘要Redis 存储自动过期长期记忆 用户偏好 ProfilePostgreSQL 知识向量库Qdrant。记忆提取通过专门的 Memory Agent 执行在每轮对话结束后异步运行。具体实现在本系列的 Memory 篇中详细展开。3.3 记忆的 Java 工程实现思路// 短期记忆Redis 存储自动过期 Component public class ShortTermMemory { private final RedisTemplateString, String redis; public void saveSummary(String sessionId, String summary) { redis.opsForList().rightPush(session: sessionId, summary); redis.expire(session: sessionId, 7, TimeUnit.DAYS); } public ListString getRecentContext(String sessionId, int limit) { return redis.opsForList().range(session: sessionId, -limit, -1); } } // 长期记忆向量数据库 结构化存储 Component public class LongTermMemory { private final QdrantClient qdrant; // 语义检索 private final UserProfileRepository repo; // 结构化查询 public void storeMemory(MemoryEntry entry) { // 向量化存储语义检索用 qdrant.upsert( entry.getId(), embeddingService.embed(entry.getContent()), entry.getMetadata() ); // 结构化存储精确查询用 repo.save(entry); } public ListMemoryEntry retrieve(String query, int topK) { float[] queryVec embeddingService.embed(query); return qdrant.search(queryVec, topK); } }4. ReflectionAgent 怎么从错误中学习前三个机制解决的是怎么做的问题Reflection 解决的是怎么做得更好。一个没有反思能力的 Agent每次犯同样的错误有反思能力的 Agent能从失败中提取经验避免重蹈覆辙。4.1 Reflexion把失败变成语言化的经验Reflection 的经典实现是 Shinn et al.NeurIPS 2023提出的Reflexion框架。它的核心思路很直白Agent 执行任务失败后不是简单地重试而是先让 LLM 分析失败原因生成一段自然语言的自我反思如上次失败是因为没有检查变量是否在使用前初始化然后把这段反思存入记忆在下次尝试时注入到 prompt 中。执行任务 → 评估结果 → 失败 ├─ 是 → 生成反思文本 → 存入记忆 → 带着反思重试 └─ 否 → 返回结果Reflexion 的实验数据很说明问题在 HumanEval 编程基准上Reflexion 的 pass1 达到 91%而 GPT-4 直接生成只有 80%。在 HotPotQA 多跳问答上准确率提升了约 20 个百分点。4.2 反思的工程挑战Reflexion 的思路清晰但工程实现中有几个陷阱反思幻觉2025 年的研究发现LLM 的自我反思有时会生成看起来合理但实际错误的分析——模型编造了一个失败原因然后基于这个错误原因去调整行为结果越改越差。这就是反思幻觉Reflection Hallucination。解决方案基于事实的反思。不能只让模型凭空反思必须提供客观的反馈信号——代码的执行错误日志、工具调用的返回值、环境的实际状态。反思必须锚定在这些事实之上而不是模型的想象。反思的代价每次反思都需要额外的 LLM 调用。在延迟敏感的场景中如实时对话反思的开销可能不可接受。实际工程中通常只在关键节点做反思如任务失败、结果异常而不是每步都反思。常见误区不是所有场景都需要 Reflection 模块。如果任务的成功率已经很高如 95%反思带来的收益微乎其微反而增加了延迟和成本。Reflection 最有价值的场景是任务复杂、错误率高、且错误模式可归纳如代码生成、多步推理、工具调用链。4.3 Dream-SaaS 中的反思Dream-SaaS 的代码审查 Agent 实现了轻量级反思当审查结果被用户标记为误报时系统会将这次误报的上下文代码片段 审查意见 用户反馈存入记忆。下次审查类似代码时检索这段记忆提醒 Agent 上次类似的代码被判定为误报注意避免。这不是完整的 Reflexion 框架但核心思路一致把失败经验转化为可检索的记忆指导后续行为。// 轻量级反思误报记忆存储 public void onUserFeedback(ReviewResult result, String feedback) { if (false_positive.equals(feedback)) { // 存入误报记忆下次遇到类似代码时检索 reflectionMemory.store( new ReflectionEntry( result.getCodeSnippet(), // 触发误报的代码 result.getComment(), // Agent 给出的审查意见 此模式曾被误判为问题代码, // 反思结论 LocalDateTime.now() ) ); } }5. 四个机制怎么协作一张全景图四个机制不是独立运行的它们在一个完整的 Agent 执行流程中紧密配合。用 Dream-SaaS 的 Supervisor 来举例用户请求 │ ▼ ┌─────────────────────────────────────────────┐ │ PlanningSupervisor 分析意图拆解任务 │ │ → 需要查知识库 审查代码 生成报告 │ └─────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ Memory检索用户偏好 历史上下文 │ │ → 该用户偏好简洁风格上次类似的报告... │ └─────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ Tool Use并行调用子 Agent 和工具 │ │ → KnowledgeBaseAgent CodeReviewAgent │ │ → 各 Agent 通过 MCP 调用底层工具 │ └─────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────┐ │ Reflection汇总结果检查质量 │ │ → 审查结果是否完整是否需要补充 │ │ → 如有问题回到 Planning 修正计划 │ └─────────────────────────────────────────────┘ │ ▼ 返回最终结果机制角色对应本系列Planning决定做什么、怎么做、什么顺序编排篇本文 下篇Tool Use执行具体操作与外部世界交互MCP 系列已发布Memory提供上下文和经验指导决策Memory 系列已发布Reflection检查结果质量从错误中学习后续专题6. 总结四个核心机制——Planning、Tool Use、Memory、Reflection——构成了 Agent 的完整能力栈。Planning 决定做什么Tool Use 提供执行能力Memory 提供经验和上下文Reflection 确保质量并持续改进。机制核心问题经典方案工程要点Planning怎么拆解复杂任务CoT → ToT → Plan-and-Execute简单任务用 ReAct复杂任务用 Plan-and-ExecuteTool Use怎么扩展 Agent 能力Function Calling → MCP工具质量 数量注意上下文污染Memory怎么跨会话记住经验工作/短期/长期三层记忆混合检索 定期遗忘Reflection怎么从错误中学习Reflexion 框架必须锚定事实避免反思幻觉理解这四个机制的关键不在于记住每个算法的细节而在于理解它们各自解决什么问题、边界在哪里、怎么协作。有了这张全景图再去看后续每个系列的深入展开就知道它在整个架构中扮演什么角色。下篇预告《深入理解 AI Agent七从单 Agent 到多 Agent——为什么一个不够》深入理解 AI Agent · AGENT 基础篇 #02作者宋哥 | Java 后端 → AI Agent 工程师项目Dream-SaaS · 多 Agent 协作平台有问题评论区见欢迎交流~参考资料[1] Lilian Weng, LLM Powered Autonomous Agents https://lilianweng.github.io/posts/2023-06-23-agent[2] Wei et al., Chain-of-Thought Prompting Elicits Reasoning in Large Language Models, NeurIPS 2022 [2201.11903] Chain-of-Thought Prompting Elicits Reasoning in Large Language Models[3] Yao et al., Tree of Thoughts: Deliberate Problem Solving with Large Language Models, NeurIPS 2023 https://arxiv.org/abs/2305.10601[4] Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, ICLR 2023 [2210.03629] ReAct: Synergizing Reasoning and Acting in Language Models[5] Shinn et al., Reflexion: Language Agents with Verbal Reinforcement Learning, NeurIPS 2023 https://arxiv.org/abs/2303.11366[6] Anthropic, The Model Context Protocol Introducing the Model Context Protocol \ Anthropic[7] Anthropic, Introducing advanced tool use on the Claude Developer Platform Introducing advanced tool use on the Claude Developer Platform \ Anthropic[8] Lei Wang et al., A survey on large language model based autonomous agents, Frontiers of Computer Science 2024[9] Zylos AI, Agent Self-Correction: From Reflexion to Process Reward Models Agent Self-Correction: From Reflexion to Process Reward Models | Zylos Research[10] Taskade, How LLMs Got Hands: The History of Tool Use and Function Calling How LLMs Got Hands: A History of Tool Use (2026)