title: 智能体的设计模式
web_id: 82
智能体的设计模式
LLM Agent 并非凭空产生，它是对传统程序架构的一次重新洗牌。这篇文章梳理四种核心设计模式，作为 Agent 系统设计的工具箱。
过去两年，以 LLM 为核心的智能体（Agent）从学术实验走向了生产环境。但 Agent 不是一个 monolithic 的概念——"让模型自己决定"等于什么都没说。实际上，Agent 系统有清晰的设计模式，每种模式解决一类特定的问题。
本文梳理四种最核心的模式：反思（Reflection）、工具使用（Tool Use）、规划（Planning）和多智能体协作（Multi-Agent）。它们不是互斥的——生产级的 Agent 通常会组合 2-3 种模式。
一、反思（Reflection）
反思模式的核心思想很简单：Agent 在执行完动作后，以自己的输出为对象进行自我批评或接受外部反馈，并将改进经验存入记忆，用于下一轮迭代。
为什么需要反思？
LLM 的单次推理是"一锤子买卖"——它没有机会审视自己的输出是否有遗漏或错误。反思相当于给 Agent 加了一个内循环：输出 → 评价 → 修正，让单次生成变成多轮精炼。
三种常见的反思方式：
- 自反思（Self-Reflection）：Agent 自己评价自己的输出，生成改进建议。实现简单，但容易陷入"我没错"的偏误。
- 外部批评（External Critique）：用另一个 LLM 或人类来评价。更客观，但增加了调用成本和延迟。
- 工具反馈（Tool Feedback）：利用代码执行结果、编译错误、API 返回值等事实信号作为批评依据。比纯文本反思更可靠——反馈是执行环境给的，不是模型猜的。
实现模式
实践中通常通过两种方式：
- LLM-as-Judge：用一个 LLM（或同一个但角色不同的 prompt）评价输出。给出评分规则或 checklist，生成改进建议。
- 结构化记忆：反思结果存入向量数据库或经验缓冲区，按"经验 → 教训 → 下次改进"的格式结构化存储，在下一轮推理时作为上下文注入。
优缺点
✅ 无需额外训练，prompt engineering 即可实现；适用于有明确评价标准的任务（代码、数学、事实性问答）。
❌ 自反思容易陷入"我没错"的偏误；引入二次调用增加延迟和成本；对开放性任务（如创意写作）可能越改越差。
二、工具使用（Tool Use）
工具使用模式让 LLM 突破自身知识边界和计算能力，通过调用外部 API、数据库、计算引擎等资源完成自身无法直接完成的任务。
从 Function Calling 到 MCP
工具使用经历了三代演进：
- 第一代：Prompt Injection——在 prompt 中描述工具的名称和用途，期望模型以自然语言输出调用意图。优点是灵活，缺点是解析困难，不结构化。
- 第二代：Function Calling（结构化输出）——模型输出预定义的 JSON schema（tool_calls），系统端负责执行。这一代解决了解析问题，使工具调用可靠到可以上生产。目前 OpenAI、Anthropic、Google 等主流模型都已原生支持。
- 第三代：MCP（Model Context Protocol）——Anthropic 提出的标准化协议。工具定义、调用、响应格式统一为 JSON-RPC 2.0。服务器通过
list_tools 和 call_tool 两个端点和客户端通信，工具可以热插拔，无需修改 Agent 代码。
实现考虑
- 错误处理：工具调用可能失败、超时或返回意外格式，需要设计重试和降级逻辑
- 权限控制：Agent 的工具权限应与人类用户的权限一致，避免通过工具调用越权操作
- 工具选择：当工具数量很大（数百甚至数千）时，不可能把所有 tool spec 塞进上下文。双编码器方案成为标准——将工具描述编码为向量，查询时计算语义相似度选择 top-k 工具
- 动态工具创建：高级模式——Agent 可以在运行时生成新工具（如写一段 Python 代码并立即在沙箱中执行）。这极大扩展了适应性，但也引入了安全风险
优缺点
✅ 极大扩展模型能力（实时信息、精确计算、第三方 API 调用）；MCP 标准化后集成成本大幅降低。
❌ 工具选择错误或幻觉可能造成灾难性后果；每个工具调用增加延迟；需要可靠的错误处理机制。
三、规划（Planning）
规划模式的核心是让 Agent 在执行动作前进行推理和子目标分解。与简单的"输入 → 输出"不同，规划给了 Agent 一张地图。
三种规划范式
ReAct：推理与行动交织
ReAct 将推理轨迹（Thought）和动作（Action）交替输出。Agent 每走一步先思考再行动，观察结果后继续思考。这是目前最广泛采用的 Agent 范式——LangChain、AutoGPT 等都以此为基础。
核心流程：Thought → Action → Observation → Thought → ...
优点：灵活、即时的反馈闭环。缺点：可能陷入局部最优，对长程任务缺乏全局视野。
Plan-and-Solve：先计划后执行
Plan-and-Solve 先让 LLM 生成完整计划，然后逐步执行。与 ReAct 不同，计划阶段不执行动作，避免了"边做边改"可能导致的短视行为。适合需要整体统筹的长程任务。
Tree of Thoughts：多点探索
ToT 在每一步展开多个候选思路，用广度优先搜索（BFS）或深度优先搜索（DFS）配合评价函数选择最优路径。对比 ReAct 的贪心路径，ToT 能探索更广的搜索空间。
- 需要实现三样东西：状态生成器（在当前节点产生多个后继）、评价器（评估每个候选的价值）、搜索算法（BFS/DFS）
- 适合场景：数学证明、创意写作、策略游戏这类需要多路径探索的任务
任务分解
另一条路线是将复杂任务分解为多个子任务，每个子任务独立解决。LLM 作为控制器，将任务按类型分解后交给专门的模型或工具执行——这类似于操作系统的调度器，而不是把一切都让大模型自己扛。
优缺点
✅ 显著提升复杂任务的完成率；ToT 能跳出局部最优；Plan-and-Solve 提供全局视角。
❌ 规划消耗大量 Token；计划可能与实际执行环境不符（需要动态修正）；分解粒度难以自动确定。
四、多智能体协作（Multi-Agent）
多智能体模式不再让一个 Agent 包揽所有，而是将系统拆分为多个专门化的 Agent，通过通信协议协作完成复杂任务。
架构分类
- 顺序型（Sequential）：Agent 链式传递输出，前一个的输出作为后一个的输入。简单但缺乏双向反馈。
- 分层型（Hierarchical）：一个管理者 Agent 拆解任务，分发给多个工作者 Agent。管理者负责协调和结果汇整。是实践中效果最稳定的架构。
- 去中心化（Decentralized）：多个平级 Agent 通过协商、投票、辩论达成一致。鲁棒性高但通信开销大。
代表性框架
- AutoGen（微软）——多 Agent 对话框架。核心是两个角色：AssistantAgent（LLM 驱动的助手）负责推理和生成，UserProxyAgent（代表人类的代理）负责执行工具和提供反馈。支持人类介入、灵活的对话模式。
- MetaGPT——为软件公司角色建模：产品经理写 PRD、架构师出设计文档、工程师写代码。每个 Agent 输出结构化产物，通过消息队列共享中间结果。特别适合软件工程场景。
- CrewAI——轻量级框架。定义 Agent（角色、目标、工具）、Task（描述、预期输出）、Crew（Agent 和 Task 的组合），调用一句
crew.kickoff() 执行。易于上手。
- 辩论模式（Debate）——多个 Agent 就相同问题各自推理，然后交换结论并互评。通过多轮辩论收敛到更准确的答案。Agent 数量在 3-4 个时效果最佳。
共享记忆
多 Agent 场景需要共享上下文。常用方案包括：
- 向量数据库（Chroma、FAISS）——Agent 将关键信息写入共享向量库，其他 Agent 检索读取
- 消息队列（Redis Pub/Sub、RabbitMQ）——Agent 之间通过 topic 发布和订阅消息
- 共享数据库——结构化数据存入 PostgreSQL / SQLite，所有 Agent 通过查询写入
优缺点
✅ 专业化分工让每个 Agent 更专注；辩论提高事实性；协作能解决单 Agent 无法处理的超大规模任务。
❌ 协调复杂度指数增长；通信开销大；成本线性增加（N 个 Agent 约 N 倍 Token 消耗）；Agent 间可能产生矛盾指令。
模式组合
实际生产系统中，这些模式很少单独使用。常见组合：
- ReAct + Tool Use——Agent 在推理循环中调用工具，观察结果后继续推理。这是目前最主流的 Agent 范型，几乎所有生产级 Agent 框架都默认采用。
- Planning + Reflection——Agent 制定计划，每完成一个子步骤后反思输出质量，必要时修正计划。适合复杂多步骤场景。
- Multi-Agent + 共享记忆——多个专业 Agent 通过共享记忆协作，管理者 Agent 使用 ReAct 循环协调全局。
选择哪种模式取决于任务性质：需要事实准确性时优先 Tool Use 和 Reflection；需要长程策略时优先 Planning；任务横跨多个领域时优先 Multi-Agent。好的 Agent 架构设计不在于堆砌模式，而在于理解每种模式的适用边界。