前篇回顾：Agent 基础篇 #01 从LLM到Agent → Agent 基础篇 #02 四大核心机制

上一篇建立了 Agent 的整体框架：Agent = LLM + Planning + Tool Use + Memory（Lilian Weng 的经典分解，加上 Reflection 作为第四大机制）。这个公式看起来很简洁，但每个模块展开之后都是一个独立的工程领域。

这篇把四个机制拆开，逐个看它们在工程中到底在做什么、解决什么问题、有哪些经典方案。不追求穷尽每个细节——后续 RAG、MCP、Memory 系列会各自深入——而是要建立一张全景图：知道每个模块的边界在哪，以及它们怎么协作。

1. Planning：Agent 怎么拆解任务

LLM 的一次推理只能生成一段文本。当任务需要 10 步才能完成时，Agent 不能一次性把 10 步全"想"出来然后一口气执行——它需要在执行过程中不断调整计划。这就是 Planning 模块要解决的问题。

1.1 三种规划策略的演进

Planning 的发展经历了三个阶段，每个阶段都在解决前一个阶段的短板：

策略 核心思路 优势 局限 代表作
Chain-of-Thought（CoT） 单路径逐步推理，"一步一步想" 简单有效，零额外开销 不能与外部工具交互；走错了无法回头 Wei et al., 2022
Tree of Thoughts（ToT） 多路径搜索，每一步探索多个分支并择优 推理能力更强，适合高价值决策 计算成本高（每步多次 LLM 调用） Yao et al., 2023
Plan-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 Use：Agent 怎么扩展能力

LLM 本身只能处理文本。要让 Agent 查数据库、调 API、操作浏览器，就需要 Tool Use 机制——让模型能够输出结构化的工具调用请求，由外部系统执行后把结果返回。

2.1 从 Function Calling 到 MCP 的演进

Tool Use 的发展可以分三个阶段：

第一阶段：Function Calling（2023）

OpenAI 在 GPT-3.5/4 中引入 Function Calling，定义了工具调用的基本范式：开发者用 JSON Schema 描述工具的输入输出格式，模型在推理时输出结构化的调用请求，应用层执行后把结果喂回模型。

这个阶段的问题：每个平台定义自己的工具格式——OpenAI 一套、Anthropic 一套、Google 一套。工具开发者需要为每个平台写不同的适配代码，N 个工具 × M 个平台 = N×M 个集成。

第二阶段：Computer Use（2024-2025）

Anthropic 的 Computer Use 让 Agent 直接看屏幕截图、计算鼠标坐标、点击按钮。范式转变是：不再需要为每个软件写专门 API，Agent 可以操作任何有图形界面的软件。但代价是速度慢、精度有限、风险高——能点击任何按钮的 Agent，也可能点错按钮。

第三阶段：MCP 统一协议（2024 至今）

Anthropic 在 2024 年 11 月发布 MCP（Model Context Protocol），定义了工具发布和发现的标准协议。工具开发者只需实现一次 MCP Server，任何支持 MCP 的 Client（Claude、GPT、开源框架）都能直接调用。N×M 的集成问题变成了 N+M。

阶段 时间 范式 核心问题
Function Calling 2023 每个平台自定义工具格式 N×M 集成成本，工具不可复用
Computer Use 2024-2025 Agent 直接操作 GUI 速度慢、精度低、安全风险
MCP 2024 至今 统一协议标准化 N+M 集成，工具可复用可发现

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 List<Document> searchKnowledgeBase(
    @Param("query") String query,
    @Param("topK") int topK
) {
    return knowledgeBaseService.search(query, topK);
}

Spring AI 的 @Tool 注解让工具定义变得声明式——只需描述工具做什么、接受什么参数，框架负责生成 JSON Schema 并注册到 Agent。MCP 协议则进一步把这个注册过程标准化，让工具可以跨框架复用。

3. Memory：Agent 怎么记住经验

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 存储，自动过期）；长期记忆 = 用户偏好 Profile（PostgreSQL）+ 知识向量库（Qdrant）。记忆提取通过专门的 Memory Agent 执行，在每轮对话结束后异步运行。具体实现在本系列的 Memory 篇中详细展开。

3.3 记忆的 Java 工程实现思路

// 短期记忆：Redis 存储，自动过期
@Component
public class ShortTermMemory {
    private final RedisTemplate<String, String> redis;
    
    public void saveSummary(String sessionId, String summary) {
        redis.opsForList().rightPush("session:" + sessionId, summary);
        redis.expire("session:" + sessionId, 7, TimeUnit.DAYS);
    }
    
    public List<String> 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 List<MemoryEntry> retrieve(String query, int topK) {
        float[] queryVec = embeddingService.embed(query);
        return qdrant.search(queryVec, topK);
    }
}

4. Reflection：Agent 怎么从错误中学习

前三个机制解决的是"怎么做"的问题，Reflection 解决的是"怎么做得更好"。一个没有反思能力的 Agent，每次犯同样的错误；有反思能力的 Agent，能从失败中提取经验，避免重蹈覆辙。

4.1 Reflexion：把失败变成语言化的经验

Reflection 的经典实现是 Shinn et al.（NeurIPS 2023）提出的 Reflexion 框架。它的核心思路很直白：

Agent 执行任务失败后，不是简单地重试，而是先让 LLM 分析失败原因，生成一段自然语言的自我反思（如"上次失败是因为没有检查变量是否在使用前初始化"），然后把这段反思存入记忆，在下次尝试时注入到 prompt 中。

执行任务 → 评估结果 → 失败？
                         ├─ 是 → 生成反思文本 → 存入记忆 → 带着反思重试
                         └─ 否 → 返回结果

Reflexion 的实验数据很说明问题：在 HumanEval 编程基准上，Reflexion 的 pass@1 达到 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 来举例：

用户请求
   │
   ▼
┌─────────────────────────────────────────────┐
│  Planning：Supervisor 分析意图，拆解任务     │
│  → "需要查知识库 + 审查代码 + 生成报告"      │
└─────────────────────────────────────────────┘
   │
   ▼
┌─────────────────────────────────────────────┐
│  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-Execute
Tool Use 怎么扩展 Agent 能力？ Function Calling → MCP 工具质量 > 数量；注意上下文污染
Memory 怎么跨会话记住经验？ 工作/短期/长期三层记忆 混合检索 + 定期遗忘
Reflection 怎么从错误中学习？ Reflexion 框架 必须锚定事实，避免反思幻觉

理解这四个机制的关键不在于记住每个算法的细节，而在于理解它们各自解决什么问题、边界在哪里、怎么协作。有了这张全景图，再去看后续每个系列的深入展开，就知道它在整个架构中扮演什么角色。

下篇预告：《深入理解 AI Agent（七）：从单 Agent 到多 Agent——为什么一个不够？》

📘 深入理解 AI Agent · AGENT 基础篇 #02

作者：宋哥 | Java 后端 → AI Agent 工程师

项目：Dream-SaaS · 多 Agent 协作平台

有问题评论区见，欢迎交流~

参考资料

# 人工智能
Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

MCP协议开发实战：从零搭建AI Agent工具链

本文介绍了MCP协议在AI工具链中的应用与实践。MCP协议旨在解决异构工具集成难题，为AI模型提供标准化、安全的工具调用接口。文章详细解析了MCP的核心架构，包括Server、Client、Transport等组件，以及通信流程与安全模型。通过实战示例，指导读者开发计算器和文件系统工具Server，并集成到Claude等AI客户端中。进阶部分展示了如何构建复杂工具链，包括API集成、数据库查询和多

avatar AI Agent技术社区
cover

AI Tool 设计：粒度、参数与错误恢复怎么做

avatar AI Agent技术社区
cover

AI Agent 的 3D 建模雕刻刀img2threejs： 一张照片生成 3D 模型（以opencode为例）

avatar AI Agent技术社区