单Agent还是多Agent？企业团队的架构决策框架

采用LLM Agent的团队总会碰到一个反复出现的问题：是用一个配备好工具的Agent，还是让多个Agent协同工作？演示环境里，多Agent方案看起来往往更自然。但进入生产环境后就不那么光鲜了——协调成本、状态bug、评估负担往往同时出现，而且来得很晚。

本文围绕几个决定多Agent设计是否划算的核心维度，构建一套决策框架：任务结构、状态管理、故障处理、人工监督、延迟、成本、可靠性与安全性。文中会对比 LangGraph、CrewAI 与 Microsoft AutoGen，以及微软现在推荐用于新项目的 Microsoft Agent Framework。

版本提示：微软的 AutoGen 仓库已明确标注 AutoGen 进入维护模式——不再新增功能，由社区维护，并推荐新项目使用 Microsoft Agent Framework（1.0 版于 2026 年 4 月正式发布）。本文对 AutoGen 的讨论仅针对现有系统，新项目则覆盖 Agent Framework。相关说法引用自 2026 年 10 月的文档，落地前请再行核实。

从单个Agent开始

先构建单Agent版本。一个带有明确工具集的 LLM 循环，会在早期就逼你回答那些真正困难的问题：任务边界在哪里、真正需要哪些工具、Agent会在哪里卡住。

以下情况应坚持使用单Agent：

• 工作是线性的。 先研究后写作、先获取后转换。这种有序步骤、每一步输出喂给下一步的流程本质上是流水线；一个Agent按顺序调用工具，比编排多个Agent更简单、更易追踪。
• 一个上下文窗口能装下整个问题。 如果文档、工具输出和历史记录都能舒适地放进上下文，拆分Agent只会增加协调开销，而不增加能力。
• 输出有唯一的责任方。 审批、面向客户的消息、财务操作都需要一个明确的最终决策所有者。
• 团队刚接触Agent。 单Agent能在完全可见的情况下教会你各种失败模式——工具错误、提示漂移、失控循环。这些经验可以向上迁移，反过来却很难。

多Agent何时才值得

下面这些信号没有一个是自动成立的，每一个都需要具体、可检验的形式。把它们当作假设，而不是辩护理由。

存在真正独立的子任务。 跨不相关来源的并行研究，或针对不同系统的并发调用。关键词是独立：如果步骤B必须等步骤A完成才能开始，那你面对的是流水线——而流水线本身也未必需要多个Agent。

角色在指令、工具或模型上存在实质差异。 一个配备网络搜索工具的研究员和一个手握合规文档的政策审查员，塞进同一个系统提示里只会互相拖累。CrewAI 直接对此建模：每个Agent带有角色、目标和背景故事；任务绑定到Agent并带有明确的预期输出。

隔离是设计出来的，而非默认存在。 把工作拆给多个Agent，本身并不能遏制故障——一个共享的下游消费者仍会看到上游的每一个错误。故障隔离必须被设计：每个Agent的重试预算、超时、以及交接边界上的校验。

工作流是长期运行且可中断的。 跨越数小时甚至数天、带有人工检查点的流程，需要持久的分步状态。LangGraph 将其拆分为 checkpointer（线程级：连续性、人在回路、时间回溯、容错）与 store（跨线程的事实与偏好）；Microsoft Agent Framework 的工作流引擎同样提供检查点与状态恢复。

各步骤的信任边界不同。 当工作流不同部分在不同凭证或数据访问范围下运行时，分离Agent能给每一步一个干净的身份。但要注意：权限不同并不总是需要多个Agent——单个Agent也可以在每次工具调用时承接受限凭证。只有当这些边界稳定、可审计、且值得从结构上强制执行时，多Agent才真正划算。

多Agent何时不划算

共享状态才是真正的复杂度所在。 一旦多个Agent必须就共享事实达成一致——当前计划、客户意图——你就拥有了一个分布式系统问题。冲突和脏读不会因为这些组件是语言模型而消失；管理它们是实打实的工程工作。

调试面成倍扩大。 一个Agent，一条trace。五个Agent，你就得重建谁在什么顺序、基于哪个版本的共享状态、对谁说了什么。要么为可观测性预留预算，要么就留在单Agent。

延迟在关键路径上层层累加。 顺序交接会在每一步增加模型调用的延迟。在用户看到输出之前，数一数有多少次顺序LLM调用；对交互式场景而言，仅凭这一点就足以否决某个设计。

评估变得更复杂。 测试相互交互的Agent意味着要覆盖交互空间，而不只是单个输出——这很难，但并非不可能。可行的模式是：每个Agent的单元测试 + 对组合工作流的集成测试。如果没人能说清楚这个系统将如何被评估，那它还没准备好被构建。

协调模式：带版本意识的对比

不同框架在协调方式上有本质差异，下面是一份带版本意识的对比：

维度	LangGraph	CrewAI	AutoGen（现有系统）	Microsoft Agent Framework（新项目）
状态	活跃开发	活跃开发	维护模式，无新功能，社区维护	1.0 于 2026 年 4 月 GA，微软推荐的继任者
心智模型	显式图：节点是步骤，边是转移	基于角色的团队：带角色、目标、背景的Agent	AgentChat teams（0.4.x）：预定义协作模式	Agents + 编排 + 基于图的工作流，支持声明式 YAML
协调方式	手动接线：条件边、子图	声明式流程：sequential（默认）或 hierarchical	轮询、选择器、swarm、图流团队	顺序、并发、交接、群聊、Magentic-One
状态管理	类型化状态模式；checkpointer + store	任务输出作为上下文；结构化 TaskOutput；guardrails 校验交接	团队内共享上下文；记忆组件	可插拔记忆：对话历史、持久键值状态、向量检索
人在回路	interrupt()：任意处暂停，经 Command 恢复	每任务的 human_input 标志	团队设计内的审批步骤	HITL 审批、长任务暂停/恢复
故障恢复	从检查点恢复；检视历史状态	guardrail_max_retries；层级模式下 manager 重新规划	终止条件约束执行	检查点；安全/合规中间件钩子
最佳适配	长期运行、有状态、可审计工作流	任务边界清晰的专家团队	维护现有 AutoGen 部署	新企业项目，尤其是微软技术栈

一个要点：不要混用 API 代际。AutoGen 0.2 的 GroupChat/GroupChatManager/max_round/TERMINATE 这套用法已被取代，而即便是 0.4.x 的 AgentChat API 现在也进入维护模式。新项目微软指向 Agent Framework，它将 Semantic Kernel 的企业级基础与 AutoGen 的编排研究统一起来。

Magentic-One 是微软研究院提出的一种通用多Agent系统架构，已被集成进 Microsoft Agent Framework 作为预置协调模式之一。其核心设计是一个「编排者」（Orchestrator）Agent 负责任务规划与进度追踪，配合若干专职 Agent（如网页浏览、代码执行、文件操作等）协同完成开放式任务。与 CrewAI 的静态角色分配不同，Magentic-One 的编排者会在运行时动态决定下一步调用哪个 Agent，并在子任务失败时重新规划——这使它更适合任务结构事先未知的场景，但也意味着更难预测执行路径，可观测性要求更高。在 Agent Framework 中使用 Magentic-One 时，其检查点与状态恢复能力与框架整体机制共享，弥补了原始研究实现中缺乏持久化的短板。

状态：最重要的那个决策

归纳起来有三种模式：

显式状态（LangGraph）。 你声明模式，节点读写命名字段。两套持久化系统各司其职：checkpointer 保存线程级快照（暂停/恢复、时间回溯检视），store 保存跨线程事实。团队最容易搞错的两件事是：MemorySaver/InMemorySaver 把检查点放在内存里，进程重启就全丢——生产环境需要持久化的 checkpointer；以及，从 interrupt() 恢复时会从头重新执行整个节点，之前的代码会被重跑。中断前的副作用必须幂等，或者移到中断之后。

校验式交接（CrewAI）。 任务输出作为上下文流向下游，包裹在结构化的 TaskOutput 里（raw、JSON 或经 Pydantic 校验）。针对「没有可检视状态」这一刻板印象的修正是 guardrails：任务可以携带基于函数或基于 LLM 的 guardrail，在下一个任务运行前校验输出，并支持可配置重试（guardrail_max_retries）——这是在交接边界强制状态不变量的具体机制。

对话即状态（团队群聊架构）。 Agent 通过共享的对话上下文协调——表达力强，但最难推理。状态不变量依然可以强制，只是代价更高：校验步骤、结构化输出、以及在违规时终止团队的终止条件。

无论选哪种模式，先把不变量写下来：哪些事实绝不能过期、谁可以修改它们、在出现分歧时什么会让系统停下来。

检查点与持久化的底层原理值得稍作说明。LangGraph 的 checkpointer 本质上是一个快照机制：每当图执行到节点边界，当前完整的状态字典就被序列化并写入存储后端（内存、SQLite、PostgreSQL 等）。这意味着即使进程崩溃，下次恢复时也能从最后一个成功检查点重放，而不是从头运行整个工作流。「时间回溯」（time-travel）调试正是利用这一机制：开发者可以加载任意历史快照，修改输入，然后从那个节点向前重新执行，用于定位「第三步出了什么问题」这类追溯性问题。这套机制的代价是存储与序列化开销，以及要求节点内副作用必须幂等——向外部 API 写数据、发邮件等不可逆操作如果在中断前发生，恢复时会被重跑一遍，因此应当后置到 interrupt() 调用之后或加入幂等保护。

故障处理是设计出来的，不是继承来的

假设每个组件都会失败；设计问题是爆炸半径有多大：

• 工具故障（API 宕机、输出格式错误）：每个工具的重试与回退——绝不让一个工具的失败模式变成整个系统的失败模式。
• 委托循环（A 问 B，B 又问 A）：用终止条件、轮数限制和看门狗超时来约束。
• 状态损坏：一次坏写入毒化下游工作。用写入边界的校验加上恢复失败运行前的检查点检视来防御。
• 静默的质量衰减：系统在运行，产出却平庸。没有框架能解决这个问题；它需要带真实标注样本的评估套件，在每次变更时运行。

人工监督：人应该坐在哪里

企业场景让这件事成为必选项，而各框架在粒度上有所不同：

• LangGraph：interrupt() 可在任意处暂停——节点内部，甚至工具内部——通过 checkpointer 持久化状态，经 Command 恢复。静态的 interrupt_before/interrupt_after 覆盖已知检查点。记住重执行规则：保持中断前代码无副作用或幂等。
• CrewAI：human_input 标志把人工审查放在任务边界——粒度更粗，但更易推理。
• Microsoft Agent Framework：带暂停/恢复的人在回路审批，外加合规策略的中间件钩子，无需改动提示。

在「出错代价超过等待代价」的地方设门：生产写入、面向客户的发送、财务动作。起草一份内部摘要不配拥有审批门。

延迟、成本、可靠性、安全：算清楚账

延迟：数清关键路径上的顺序 LLM 调用次数，乘以典型的单次调用延迟。如果总和超过 UX 预算，先重新设计再动手。

成本：（每次运行的调用数）×（每次调用的 token 数）×（每天运行次数）×（每 token 价格）。多Agent 设计会放大前三个因子；用真实量级而非演示量级来算这笔账。

可靠性：教科书式的估算——十个顺序步骤各 95% 可靠，端到端约 60%（0.95^10 ≈ 59.9%）——建立在「失败不相关」这一简化的独立性假设之上。相关性会让这个估算朝任一方向偏移：共享的失败原因会让联合失败更可能发生，而共享的缓解措施（统一验证、重试）会让它更不可能。把这个数字当作「增加验证、测量自己步骤可靠性」的出发点，而不是预测结果。

安全：更多Agent意味着更多信任边界。按Agent或按工具调用限定凭证范围；把Agent间消息当作跨信任层级的不可信输入（提示注入会像在微服务间一样在Agent团队间传播）；记录决策以备审计。一个权限过高的Agent是单点风险；五套凭证就是五处可能配置错误的地方。

一次针对单Agent基线、在延迟/成本/可靠性上度量的小规模试点，比任何架构图都更有教益。

提示注入（Prompt Injection）在多Agent环境中的传播机制需要特别关注。单Agent系统中，注入攻击的攻击面主要是用户输入与工具返回值；而在多Agent系统里，Agent A 的输出会成为 Agent B 的输入，攻击者只需污染上游一个节点的输出，恶意指令就能随着消息传递在整个团队中扩散——这与微服务中通过中间数据存储传播的注入攻击在结构上完全一致。防御思路包括：将 Agent 间消息视为不可信输入并做结构化校验（而非直接拼入提示）；对来自外部数据源（网页、文件、数据库）的内容做沙箱化处理；以及在高风险工具调用前设置人工审批门。凭证最小权限原则在此处也有双重作用：即使攻击者成功注入了恶意指令，受限凭证能限制实际可执行的操作范围，降低爆炸半径。

一个示例与上线前清单

设想一个支持工单分流工作流：工单被分类、用客户历史丰富、然后路由，由人工审批会改变 SLA 的路由决策。

• 单Agent版本：一个Agent、三个工具（分类器、CRM 查询、路由器），审批门设在路由器工具之前。每个决策都在一条记录里可见。
• 多Agent版本：分离的分流、丰富、路由Agent——只有在出现具体信号时才值得考虑：缓慢的独立丰富调用（并行性），或快速变化、应有独立所有者与评估套件的路由规则（专业化，并把故障隔离设计进去）。

「感觉更可扩展」不是信号。一个经过度量的基线才是。

上线前，不妨对照这份清单逐项核查：

• 单Agent基线已构建并度量（延迟、成本、可靠性）
• 至少一个多Agent信号被具体验证为真，而非假设
• 状态不变量已写明：什么绝不能过期、谁可修改、什么会让系统停下
• 持久化选择已明确：重启后什么存活、什么不存活
• 框架选择带版本意识：没有迁移计划就不要在维护模式框架上做新企业构建
• 人工审批门设在出错代价超过等待代价之处
• 终止条件、轮数限制、重试预算、幂等规则均已定义
• 带真实标注样本的评估套件在每次变更时运行
• 凭证范围划分与审计日志是设计出来的，而非被推迟
• 团队能从 trace 而非架构图来解释系统行为

披露：本文在 AI 协助下创作，技术性说法已对照 2026 年 10 月的官方框架文档核对，落地前请对照最新文档再行验证。