White Meta
中文EN
Theme: ...

返回文章列表

智能体的设计模式

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 返回值等事实信号作为批评依据。比纯文本反思更可靠——反馈是执行环境给的，不是模型猜的。

自反思提示词示例：

Improving email

Review the email first draft

Check that the tone is professional and
look for phrases that could be considered
rude or insensitive.

Verify all facts, dates, and promises are
accurate.

Then write next draft of the email.

实现模式

实践中通常通过两种方式：

  • LLM-as-Judge：用一个 LLM（或同一个但角色不同的 prompt）评价输出。给出评分规则或 checklist，生成改进建议。

  • 结构化记忆：反思结果存入向量数据库或经验缓冲区，按"经验 → 教训 → 下次改进"的格式结构化存储，在下一轮推理时作为上下文注入。

优缺点

✅ 无需额外训练，prompt engineering 即可实现；适用于有明确评价标准的任务（代码、数学、事实性问答）。

❌ 自反思容易陷入"我没错"的偏误；引入二次调用增加延迟和成本；对开放性任务（如创意写作）可能越改越差。

二、工具使用（Tool Use）

工具使用模式让 LLM 突破自身知识边界和计算能力，通过调用外部 API、数据库、计算引擎等资源完成自身无法直接完成的任务。

从 Function Calling 到 MCP

工具使用经历了三代演进：

  1. 第一代：Prompt Injection——在 prompt 中描述工具的名称和用途，期望模型以自然语言输出调用意图。优点是灵活，缺点是解析困难，不结构化。

  2. 第二代：Function Calling（结构化输出）——模型输出预定义的 JSON schema（tool_calls），系统端负责执行。这一代解决了解析问题，使工具调用可靠到可以上生产。目前 OpenAI、Anthropic、Google 等主流模型都已原生支持。

  3. 第三代：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 架构设计不在于堆砌模式，而在于理解每种模式的适用边界。