单 Agent vs 多 Agent：架构、边界与落地取舍

在大型语言模型（LLM）能力飞速发展的今天，构建 Agent 应用已成为主流。然而，在选择单 Agent 还是多 Agent 架构时，许多团队会陷入困境。单 Agent 如同全栈工程师，能力全面但有上限；多 Agent 则像项目团队，分工明确但管理复杂。

本文将从工程落地视角，系统性对比单 Agent 与多 Agent 的技术路线、适用场景、关键设计点与常见陷阱，帮助你判断何时应该坚持“强单体”，何时应该引入“团队协作”，以及如何设计一个高效、可控的多 Agent 系统。

核心概念速览

Agent：一个以 LLM 为核心，具备工具调用（Tools）和记忆（Memory）能力的可执行实体。可以将其视为一个拥有“大脑”的微服务。
工具 (Tool/Function)：Agent 可以调用的确定性能力，通常通过函数调用（Function Calling）实现，具有明确的输入、输出和错误定义。
记忆 (Memory)：为 Agent 提供状态感知能力。包括短期对话上下文、长期知识库（如向量数据库）以及任务执行中的工作记忆（如草稿区）。
编排 (Orchestration)：定义 Agent 之间或 Agent 内部任务的执行流程，包括消息传递、角色切换、任务分解与结果汇聚。编排可以是简单的循环，也可以是复杂的有向无环图（DAG）。

单 Agent vs. 多 Agent：优劣边界

维度	单 Agent	多 Agent
核心优势	架构简单、延迟低、可观测性好、维护成本低。	任务分解、领域专长、并行吞吐、自我审校、容错性强。
延迟/吞吐	通常端到端延迟较低。	可通过并行执行提升吞吐量，但调度本身会引入额外延迟。
成本	Token 开销、模型调用和工具回调次数相对较少。	协作本身（消息、投票、审校）会产生大量额外的 Token 和调用开销。
可靠性	链路短，故障点少，但容易出现“单点幻觉”。	可通过“质检”、“裁判”或“投票”机制降低幻觉风险，但也引入了协作失败的新风险。
可控性	逻辑清晰，易于追踪和调试。	依赖统一的消息协议和 Tracing 工具，否则复杂性难以管理。
维护	升级和迭代相对直接。	任何角色或协议的变更都可能涉及多个 Agent 的契约调整和回归测试。

核心原则：如果一个精心设计的“强单体”Agent 能够稳定满足业务需求，就不要急于引入多 Agent 架构。只有当任务的复杂度、并行需求或审校要求带来的收益，明确高于系统复杂度的增加时，才应考虑多 Agent 方案。

如何构建一个强大的单 Agent

一个高性能的单 Agent 系统远不止“模型 + ReAct 循环”。关键在于以下工程实践：

明确的系统提示 (System Prompt)：
- 定义职责边界：“你能做什么，不能做什么。”
- 工具使用策略：“何时应该使用哪个工具。”
- 失败处理机制：“如果工具调用失败，应该如何重试或上报。”
- 输出格式约束：“必须以 JSON 格式或 Markdown 格式输出。”
- 对于复杂任务，可以在提示词中嵌入一个轻量的“先思考再行动”（Plan-then-Execute）的指令。
健壮的工具设计：
- 结构化接口：工具的参数和返回值应为强类型、结构化的数据，并包含明确的错误码、置信度和可重试标记。
- 幂等性与超时：工具层应处理好幂等性、超时和重试逻辑，避免让 Agent 在对话中处理这些底层问题。
分层记忆管理：
- 短期记忆：采用滑动窗口或摘要策略，防止上下文无限膨胀。
- 长期记忆：通过向量检索或知识图谱提供外部知识，并要求 Agent 在回答中附上引用来源，以减少幻觉。
- 工作记忆：为任务执行提供一个“草稿区”，用于存储中间结果和状态。

代码示例：基于 LlamaIndex 的强单 Agent

以下代码演示了如何使用 LlamaIndex 构建一个包含工具和记忆的 FunctionAgent。

import asyncio
from llama_index.core.agent import FunctionAgent
from llama_index.core.memory import ChatMemoryBuffer
from llama_index.core.tools import FunctionTool
from llama_index.llms.openai import OpenAI

# 1. 定义工具，包含清晰的文档字符串
def search_docs(query: str, top_k: int = 3) -> str:
    """基于企业知识库检索相关文档，并返回引用片段。"""
    # 此处应调用真实的检索系统
    print(f"正在检索: {query} (top_k={top_k})")
    return f"[模拟结果] 已找到关于 '{query}' 的3个相关片段。"

# 2. 将函数包装为 LlamaIndex 工具
doc_search_tool = FunctionTool.from_defaults(search_docs)

# 3. 配置 LLM 和记忆模块
llm = OpenAI(model="gpt-4o-mini")
memory = ChatMemoryBuffer.from_defaults(token_limit=4096)

# 4. 创建 Agent，并注入强大的系统提示
agent = FunctionAgent.from_defaults(
    tools=[doc_search_tool],
    llm=llm,
    system_prompt=(
        "你是一名企业知识助手。\n"
        "1. 优先使用 `search_docs` 工具来回答关于公司政策和产品的问题。\n"
        "2. 你的回答必须基于工具返回的证据，并附上引用。\n"
        "3. 如果无法找到确切信息，请明确告知用户。\n"
        "4. 使用清晰的列表或小标题组织你的回答。"
    ),
)

async def main():
    # 5. 运行 Agent，并传入记忆以维持对话上下文
    response = await agent.achat(
        "请总结一下我们的退货政策，并说明关键点。",
        chat_history=memory.get_all()
    )
    print(str(response))
    memory.put(response)

if __name__ == "__main__":
    asyncio.run(main())

通过精心设计这三个方面，70% 以上的业务场景都可以用单 Agent 架构优雅地解决。

多 Agent 的价值与适用场景

引入多 Agent 并非为了炫技，而是为了解决单 Agent 难以处理的特定问题：

任务分解与编排：对于跨领域、多阶段的复杂任务（如“调研-分析-总结-审校”），需要一个 Planner Agent 来进行拆解和调度。
领域专长隔离：不同领域的任务需要专用的提示词、工具集和知识库。例如，一个“法务 Agent”和一个“代码审查 Agent”的能力边界和行为模式完全不同。
并行处理提速：当任务可以分解为多个独立的子任务时，多 Agent 可以并行执行，显著提升处理吞- 吐量，尤其适用于批处理流水线。
自我审校与质量保证：引入“评审 Agent”或“裁判 Agent”可以对其他 Agent 的输出进行事实核查、合规审查或质量评估，有效降低幻觉和风险。
长流程容错：在长任务流中，将职责分配给不同 Agent 可以使失败定位、重试和回滚更加清晰和可控。

代码示例：基于 AutoGen 的多 Agent 协作

AutoGen 框架擅长通过消息传递机制组织多 Agent 协作。以下代码演示了一个“总控 Agent”根据任务类型调用不同“专家 Agent”的模式。

import asyncio
from autogen import ConversableAgent

# 1. 定义专家 Agent
code_writer_agent = ConversableAgent(
    "code_writer",
    llm_config={"config_list": [{"model": "gpt-4o-mini", "api_key": "..."}]},
    system_message="你是一名资深 Python 程序员，擅长编写高质量、可读性强的代码。",
)

code_reviewer_agent = ConversableAgent(
    "code_reviewer",
    llm_config={"config_list": [{"model": "gpt-4o-mini", "api_key": "..."}]},
    system_message="你是一名代码审查专家，负责检查代码的 bug、性能问题和风格规范。",
)

# 2. 定义用户代理，发起任务
user_proxy = ConversableAgent(
    "user_proxy",
    code_execution_config=False,
    human_input_mode="NEVER",
)

async def main():
    # 3. 使用 group chat 编排协作流程
    chat_result = await user_proxy.a_initiate_chat(
        recipient=code_writer_agent,
        message="写一个 Python 函数，计算斐波那契数列的第 n 项。",
        # 定义多轮对话，让写作者和审查者互动
        max_turns=2,
        summary_method="last_msg",
    )
    
    # 审查环节
    await user_proxy.a_initiate_chat(
        recipient=code_reviewer_agent,
        message=f"请审查以下代码：\n{chat_result.summary}",
        max_turns=1,
    )

if __name__ == "__main__":
    asyncio.run(main())

这种模式将职责清晰地分层隔离，使得系统易于扩展和维护。

多 Agent 系统的关键设计点

角色与边界：为每个 Agent 定义清晰的“职责契约”，明确其能力范围以及何时应将控制权转交给其他 Agent。
工具与消息协议：
- 工具协议：统一工具的输入输出 schema，包含错误码、置信度等元数据，便于 Agent 做出决策。
- 消息协议：定义标准的消息格式（如角色、内容、Trace ID、结构化载荷），确保 Agent 间高效通信。
记忆与共享状态：
- 私有记忆：每个 Agent 维护自己的对话历史和内部状态。
- 共享黑板 (Blackboard)：提供一个中心化的存储区域，供所有 Agent 读写任务的中间产物和全局状态。
调度与路由：
- 静态路由：根据预定义规则将任务分发给特定 Agent。
- 动态路由：由一个专门的 Router Agent 决定任务的下一跳。
- 共识机制：通过投票或辩论等方式，让多个 Agent 对结果达成共识，以提高准确性。
终止与退出条件：
- 明确定义任务完成、失败或需要人工介入的判定标准。
- 设置最大对话轮次、最大工具调用次数等“熔断”机制，防止无限循环或消息风暴。

典型架构模式

模式	描述	适用场景
Router + Workers	一个路由 Agent 根据用户意图，将任务分发给不同的专家 Worker Agent。	业务类型清晰，如客服系统中的“售前咨询” vs “售后支持”。
Planner → Executor → Critic	规划器分解任务，执行器调用工具，评审员检查结果。	需要审校的长流程任务，如生成研究报告、代码重构。
Debate / Self-Correction	多个 Agent 从不同角度生成方案，并通过辩论或投票选出最优解。	需要降低幻觉、提高严谨性的场景，如事实核查、合规审查。
Blackboard	所有 Agent 围绕一个共享的“黑板”协同工作，逐步完善一个复杂的产物。	协同创作场景，如方案设计、软件架构规划。
DAG / Workflow (LangGraph)	将 Agent 和工具定义为图中的节点，通过有向边连接，形成确定性的工作流。	拓扑结构固定、可复用的业务流程，如 ETL、自动化审计。
Human-in-the-Loop	在关键决策点或高风险环节，将控制权交由人类审批。	金融、医疗、法律等高风险领域，确保合规与安全。

主流工具链生态

AutoGen (Microsoft)：专注于多 Agent 的消息传递和对话编排，支持将 Agent 封装为工具，适合进行复杂协作模式的快速实验。
LlamaIndex Agents：以数据为中心，强调 Agent 与检索、记忆、工具的深度整合，提供了 FunctionAgent、AgentWorkflow 等工程化组件。
LangGraph (LangChain)：将 Agent 系统从传统的 ReAct 循环重构为可控的图（Graph）结构，极大地提升了复杂系统的可观测性、可控性和可复现性。

建议：使用 AutoGen 探索多 Agent 的协作范式，使用 LlamaIndex 构建数据驱动的 Agent 应用，使用 LangGraph 将成熟的、高价值的工作流固化为生产级系统。

工程与 SRE 最佳实践

成本控制：通过缓存（工具调用结果、检索片段）、模型降级（简单任务用小模型）和批处理来优化 Token 和计算成本。
并发与幂等：注意外部 API 的速率限制，并确保所有工具调用都是幂等的，以便安全重试。
可观测性：为每条消息和工具调用注入唯一的 Trace ID，使用 LangSmith、AutoGen Studio 或类似工具实现端到端的可视化追踪。
评测与回归：建立包含各类场景的评测数据集，关注任务成功率、工具调用成功率、平均执行步数等关键指标。
安全与合规：在沙箱环境中执行代码，对输入输出进行 PII（个人身份信息）脱敏，对敏感操作强制人工审核。

选型清单：12 个关键问题

在决策前，请回答以下问题：

单 Agent 能否在可接受的性能指标（SLA）内完成任务？
业务是否需要多个不同领域的专家协作？
任务是否包含可以并行处理的子任务以显著缩短时间？
是否需要严格的合规审查、决策留痕和可解释性？
依赖的工具接口是否稳定、幂等且可观测？
是否有能力构建统一的消息、状态和记忆管理层？
团队是否具备运营和维护复杂分布式系统的能力？
是否建立了自动化的评测和回归测试体系？
成本预算是否能支持多 Agent 带来的额外开销？
是否设计了清晰的人工介入（Human-in-the-loop）通道？
架构是否需要考虑跨语言或跨平台的 Agent 协作？
能否通过 LangGraph 这样的图式编排来降低系统的随机性？

总结与建议

选择单 Agent 还是多 Agent 架构，本质上是在“简洁高效”与“分工协作”之间做权衡。我们的建议是遵循“三步走”策略：

始于强单体：首先致力于构建一个工具健壮、记忆分层、提示明确的“强单体”Agent，解决 80% 的核心问题。
增量多 Agent 化：在业务收益最明确的环节（如任务路由、结果审校、并行处理）逐步引入专门的 Agent。
固化为工作流：当一个多 Agent 协作模式被验证为稳定且高价值时，使用 LangGraph 等图编排工具将其固化为可控、可观测的生产级工作流。

最终，架构的选择应服务于业务价值。切勿为了“多”而“多”，一个稳定可靠的单 Agent 远胜于一个混乱失控的 Agent 群体。

👉 如果你需要 ChatGPT 代充 / Claude / Claude Code / 镜像 / 中转 API：

购买 / 了解更多：ai4.plus
备用入口：kk4099.com

核心概念速览#

单 Agent vs. 多 Agent：优劣边界#

如何构建一个强大的单 Agent#

代码示例：基于 LlamaIndex 的强单 Agent#

多 Agent 的价值与适用场景#

代码示例：基于 AutoGen 的多 Agent 协作#

多 Agent 系统的关键设计点#

典型架构模式#

主流工具链生态#

工程与 SRE 最佳实践#

选型清单：12 个关键问题#

总结与建议#