Multi-Agent 选型：任务拆分、协作拓扑与部署成本

先证明任务需要独立上下文或并行判断，再选择协作拓扑、框架和部署方式。把委派契约、汇合、共享写入、取消与成本放进同一次 PoC，避免把多个 Agent 当成默认升级。

资料范围为 2026-09-05 核对的官方文档。案例、容量和门槛是设计示例，未经线上性能验证；以下组合是面向资料研究与可追踪交付的工程建议。

先把三个选型层次分开

本文将 Agent 视为一个能够根据反馈选择后续动作的运行单元，它拥有自己的指令、上下文和可用工具。多个角色提示词顺序执行，不一定需要多个独立 Agent；一张包含十个函数节点的图，也不自动成为多 Agent 系统。

选型层次	要回答的问题	典型选择
协作拓扑	谁拆任务、谁接收结果、谁继续和结束？	Supervisor、Handoff、执行图、对等协作
实现框架	用什么抽象表达调用、状态和交接？	普通代码、LangGraph、OpenAI Agents SDK、CrewAI、Microsoft Agent Framework
运行与部署	谁保存任务事实，进程故障后谁继续？	单进程、持久任务队列、工作流引擎、独立 Agent 服务

这三层可以自由组合。Supervisor 可以写在普通 Python 服务里，也可以是图中的节点；同一个图既可以进程内运行，也可以将重型任务交给外部 Worker。选了支持检查点的框架，仍然需要决定检查点存在哪里、谁触发恢复，以及恢复时哪些外部动作可能再次执行。

在比较 SDK 之前，先为任务写出六项约束：交付结果、可独立拆分的部分、需要读取的数据、允许产生的外部动作、时间与成本预算、失败后的处理方式。无法回答这些问题时，框架功能表很难帮助决策。

判断是否需要多个 Agent

沿用开头的场景：核验三份产品公告的生效日期，与内部记录比较，生成带来源的差异报告；只有任务授权允许且证据满足要求时，才创建待核验工单。

如果三份公告格式固定，一次并行 HTTP 请求、字段提取和规则比较就能完成，不需要给每份公告配一位“研究员”。如果每份公告都需要多次检索、追踪修订记录和判断证据，则独立上下文与局部推理循环可能有价值。

观察到的瓶颈	先尝试的改动	何时升级为多 Agent
等待几个独立工具返回	并行工具调用	每个分支都需要独立的多步判断
工具太多，模型经常选错	工具检索、按需加载、明确路由	专业领域之间长期存在明显的上下文干扰
长文塞满上下文	检索、摘要、结构化中间产物	子任务能独立收集证据并交付可验证结果
必须按顺序完成审批与写入	确定性状态机或工作流	部分步骤确实需要自主探索
想提高答案可信度	来源核验与独立验收	第二条检验路径能发现第一条路径的真实错误

LangChain 官方将上下文管理、职责分离和并行作为多 Agent 的常见动因，同时列出 Subagents、Handoffs、Skills 与 Router 等不同模式。这些模式提供的是设计空间，不能替代具体任务上的测量。Multi-agent 文档

Anthropic 的研究系统采用协调者与并行子 Agent，服务于多方向资料探索。其公开经验也指出，这类系统会显著增加 Token 消耗，并不适合所有强依赖、共享上下文的任务。这个案例支持“为可分解的研究增加上下文容量”，不支持“增加 Agent 数量就一定更准确”。官方工程案例

协作拓扑怎样选择

下面的分类用于讨论控制权。同一个系统可以组合多种模式，执行图也能承载 Supervisor 或 Handoff。

结构	控制权与结果去向	适合的任务	主要代价
Supervisor / Manager	协调者委派，子任务返回，协调者汇总	多方向研究、多个专业分析合成一个交付物	协调者成为瓶颈，摘要可能丢证据
Handoff	当前 Agent 将后续对话交给另一 Agent	客服分流、专业咨询接管	上下文与权限交接复杂，容易来回转交
Workflow / Graph	程序维护依赖、路由、汇合和终态	有明确步骤、等待和恢复要求的业务流程	需要显式建模状态和异常分支
Peer-to-peer / 共享黑板	多个参与者交换消息或更新共同任务板	分工动态、需要反复协商的探索任务	消息增多，冲突与结束条件难控制

Supervisor：需要一个人对最终产物负责

三份公告各自核验，最终只交付一份差异报告，很适合 Manager 调用专业子任务。子 Agent 返回证据包，Manager 负责比较、补缺口和组织结果。

关键是让返回值足以检查：资料版本、判断依据、引用、未解决问题和完成状态。只有一段流畅摘要时，Manager 很难区分“没找到”与“已证实不存在”。如果协调者必须重新读完所有原文，拆分可能没有减少认知负担，只增加了一层调用。

OpenAI Agents SDK 区分 agents as tools 与 handoffs：前者由 Manager 保留控制权并调用专业 Agent；后者切换当前活动 Agent，让接手者继续处理对话。对于本例，优先采用前者，因为三份核验都应返回给同一个交付责任人。Agent orchestration

Handoff：需要专业 Agent 接管后续交互

用户先咨询产品，随后进入售后排障，此时接管比每句话都经由总协调者转述更自然。转交必须携带必要事实、当前问题和可用权限，也要说明接手后的退出路径。

Handoff 不意味着可以把整段历史和所有凭据一并复制。权限由服务端身份与策略决定，不能因对话到了“财务 Agent”就自动获得财务写权限。系统还应记录当前负责人和转交次数；反复转交却没有新增信息，应触发明确的兜底流程。

执行图：需要明确什么时候可以进入下一步

资料核验的顺序要求很清楚：固定范围，派发核验，收齐当前版本结果，形成提案，检查执行许可，写入并回读。适合由图或状态机表达外层依赖，节点内部保留有限探索。

LangGraph 的 Graph API 用状态、节点和边描述执行，并通过 reducer 指定状态更新的合并方式。节点可以是普通函数，也可以包含 Agent 循环。因此采用图框架不要求每个节点都调用模型。Graph API

一张图的价值取决于交接契约。汇合节点要知道本轮预期有哪些分支；重复收到 A 的结果不能当成 B 已完成；所有分支结束也不等于所有证据充分。

对等协作：只有协商本身有价值时才采用

多人围绕同一个复杂方案提出修改，可能需要来回协商。但如果目标只是分别核验三份公告，让所有 Agent 互相聊天通常会增加重复理解和冲突处理。

若允许每对 Agent 建立一条双向沟通关系，潜在关系数是 $n(n-1)/2$；这是连接数量的上界示意，不是实际消息量或成本公式。实际开销取决于路由、轮数和每次传递的上下文。

共享黑板应保存带版本的任务与产物引用，并由明确规则裁决竞争写入。广播聊天记录无法替代任务认领、过期租约、冲突检测和验收。开始采用这一模式前，至少要能解释：为什么中心委派不够，以及谁有权宣布整个任务结束。

将拓扑落到框架

下表比较与本场景有关的抽象和需要验证的边界。“适合”是基于这些抽象的工程判断，不是功能排他声明，也不是性能测评结果。

候选	值得优先评估的原因	PoC 必须验证的边界
普通代码 + 模型 SDK	团队已有可靠任务平台，协作路径少且清楚	是否开始重复实现复杂的恢复、交接和状态合并
LangGraph	需要显式状态、分支、汇合和检查点	reducer 的重放行为、恢复入口、存储与版本迁移
OpenAI Agents SDK	希望用较少概念表达工具式子 Agent 与对话转交	子任务边界、长任务托管、取消传播、观测数据归属
CrewAI Flows	团队偏好 Flow 组织步骤，并在步骤内组合 Crew	Flow 状态恢复与业务动作重放是否符合预期
Microsoft Agent Framework	已有 Microsoft 技术栈，或正在评估 AutoGen 的迁移路径	目标语言和模型接入、工作流恢复、现有集成的迁移成本

LangGraph 官方区分保存线程图状态的 checkpointer 与保存跨线程数据的 store。前者可用于对话连续性、中断恢复等场景，后者用于应用定义的长期信息。生产环境应选择满足自身持久性和隔离要求的存储实现。Persistence

CrewAI Flows 提供结构化状态及 @persist 持久化机制，也允许 Flow 编排 Crew。选型时应在目标版本上实际测试恢复入口和重新执行的范围，不能仅凭“存在持久化装饰器”认定外部写入不会重复。Flows 官方文档

Microsoft Agent Framework 官方将 Agent 与 Workflow 作为主要构建方式，提供 Python 与 .NET 支持。需要结合团队的运行环境和既有依赖评估，不能仅凭“企业级”描述直接判定适合自己的业务。Microsoft Agent Framework 概览

AutoGen 的生命周期需要单独考虑。 本次核验时，其官方仓库已声明进入维护模式，不再接收新功能增强，并建议新用户从 Microsoft Agent Framework 开始。新项目应将维护状态与迁移成本纳入筛选；已有 AutoGen 系统则先验证迁移收益与回归风险，不必仅因名称变化立即重写。AutoGen 官方仓库

实际筛选时，先用语言、模型接入、数据存放和许可要求排除不合适的候选，再留下两种方案完成同一个端到端任务。大量框架都能画出“研究员 → 分析师 → 审稿人”，差异更容易在中断、恢复、检查状态和替换模型时暴露。

部署边界跟随故障与权限边界

多个逻辑 Agent 可以处在一个进程中。只有出现独立扩缩容、不同依赖、强隔离、长时间等待或跨团队所有权时，才需要扩大运行边界。

部署方式	适用条件	需要接受的成本
单进程内多会话	短任务、同一信任域、便于整体重启	共享进程故障与资源，需额外持久化才能恢复
编排服务 + Worker 队列	独立任务多、需要削峰与分开扩容	消息重投、租约、去重、取消和容量控制
持久工作流 + Agent 活动	长任务、外部事件、审批等待、跨服务步骤	工作流版本与重放规则，活动副作用的幂等处理
独立 Agent 服务	跨团队或跨信任域，接口需独立演进	网络故障、身份认证、协议兼容和服务运维

把 Agent 放进独立进程不会自动提供权限隔离。如果进程继承同一套高权限凭据，数据访问边界仍然相同。真正的隔离需要落实到身份、凭据、文件系统、网络和工具入口。

MCP 主要标准化 AI 应用与工具、资源及外部数据之间的连接；A2A 面向 Agent 之间的互操作与任务协作。它们解决不同接口问题，可以组合使用。MCP 介绍、A2A 介绍

对本项目的三个内部 Worker，类型化函数或内部任务 API 已经可能足够。跨团队独立服务需要发现能力、交换任务状态与产物时，再评估 A2A。无论使用什么协议，业务授权、预算、取消落地与外部动作对账仍要有实现责任人。

一个可落地的参考架构

对资料核验与工单创建，初始方案采用“外层显式流程 + 并行只读 Worker + 单一写入服务”。拆分范围可由模型提出，最终由程序验证和登记；固定三份公告时，直接使用确定性拆分即可。

研究产物与业务写入分别持久化，补查继续消耗原任务预算，不能通过重建任务绕过上限。每个节点都应定义异常出口。

将事实、产物和对话分开保存

任务状态保存“谁在做什么”：任务版本、预期分支、尝试次数、预算占用、截止时间与终态。证据产物保存“为什么这样判断”：原始来源、引用位置、资料版本、提取结果与冲突。Agent 对话历史服务于局部推理，可以压缩，但不能成为业务事实的唯一副本。

下面是本文应用层的结果契约示意，不是任一框架或协议的原生对象：

{
  "task_id": "verify-20260905-001",
  "task_version": 3,
  "branch_id": "source-a",
  "attempt_id": "attempt-02",
  "status": "needs_evidence",
  "artifact_ref": "artifacts/verify-20260905-001/v3/source-a/attempt-02.json",
  "source_revision": "revision-2",
  "missing": ["尚未取得生效日期的原始条款"],
  "usage": { "input_tokens": 8200, "output_tokens": 900 }
}

汇合器按 (task_id, task_version, branch_id) 判断逻辑分支，按尝试标识追踪重试。同一结果重投应去重；两个尝试返回不同结论，应按受控的尝试状态接收并保留冲突记录，不能盲目采用最后到达者。产物引用也必须经过访问控制，不能让模型提供任意路径就被读取。

为最终写入设置唯一责任入口

Worker 只生成证据与提案，工单创建统一经过写入服务。该服务检查当前可信授权、提案版本和业务前置条件，再使用已持久化的操作键提交。

如果下游支持幂等键，同一次业务意图的重试应复用原键；提案变更则要重新校验其授权和操作关系。如果下游不支持幂等，需要通过业务唯一约束、外部关联号查询或人工对账处理不确定结果，不能声称一个本地检查点就能提供端到端 exactly-once。

“超时”必须进一步区分：尚未发出、已发出但结果未知、已明确失败。第二种情况先对账，避免重复创建。更多恢复语义见副作用恢复与对账。

预算、取消和验收属于运行控制

启动子任务时原子预留预算，完成后结算；还要为汇总与验收保留额度。限制维度至少包括并发、模型与工具调用、时间和费用。框架的轮数上限无法覆盖所有成本来源。

父任务取消后，停止新派发，将取消意图持久化并传递到在途任务。迟到结果不能重新推进已取消的写入流程；已发生的动作仍需记录和对账。即使远端无法立即停止，也要阻止它继续获得新的执行许可。

验收器检查用户要求和真实资源。模型审稿适合发现表达缺口，日期一致性、引用可访问性、资源是否存在等条件，应尽量由独立程序或人工核验，避免 Agent 自己宣布成功。

用成本与关键路径判断并行收益

对彼此独立的核验分支，在资源足够且没有限流的简化情况下，可以用下式估计端到端延迟：

$$T_{parallel} \approx T_{plan} + \max(T_1,\ldots,T_n) + T_{merge} + T_{verify}$$

顺序执行对应的是各分支耗时之和。真实系统还应加入排队、限流和重试；共享工具容量不足时，并行甚至会增加尾部延迟。

例如三个分支分别需要 20、25、30 秒，规划 5 秒、汇总 10 秒、验收 5 秒，则顺序方案约 95 秒，并行方案约 50 秒。这些是手工设定的算例，不是框架跑分。 如果某一分支延长到 90 秒，全部收齐才交付的策略就会受它支配。

费用则应覆盖规划、全部分支、汇总、重试与验收。多 Agent 的额外开销来自重复指令、上下文传递、结果压缩和协调，也可能因专业模型与上下文缩短而部分抵消，必须按实际计费口径统计。

按任务成本口径统计单位验收交付成本，分子包含失败和返工，分母只计通过验收的交付。这里的拓扑比较额外关注协调、重复上下文和尾部等待的增量，避免再次只比单次模型价格。

用同一组任务完成 PoC

先固定任务、数据快照、工具权限、验收规则与版本，再比较三条路线：单 Agent、单 Agent 加并行工具、显式编排加多个 Agent。优先使用同一模型做对照，之后再单独比较混合模型策略，避免把模型差异误算成架构收益。

第一轮可以选择 30 个分层任务，每个方案每题运行 3 次；这是启动实验的示例规模，不足以证明罕见风险已经消失。样本应覆盖简单查询、多来源独立核验、强依赖推理和带外部动作的任务。保留未用于调试的验收集，并报告逐题差异与波动，不能只展示最成功的一次。

验证维度	记录内容	用来决定什么
交付质量	验收通过率、证据覆盖、冲突保留、人工修正量	拆分是否改善真实产物
时间与成本	端到端延迟分布、排队时间、单位验收交付成本	并行是否值得额外消耗
协作开销	重复检索、重复上下文、转交与返工次数	拓扑是否过于复杂
恢复行为	重投、进程退出、迟到结果、审批后改稿	状态边界是否正确
业务正确性	越权写入、重复资源、取消后新动作	是否满足上线硬门槛

故障注入至少包含四个场景：分支结果重复投递；旧任务版本的结果迟到；工单创建成功后响应丢失；父任务取消时仍有 Worker 运行。检查权威资源与可信审计记录，不能仅看模型输出“已处理”。

选型门槛要在实验之前确定。例如业务可以要求“本轮故障用例全部符合契约，验收通过率不低于基线，延迟达到业务期限，成本不超过预算”。哪些指标允许交换、哪些是硬约束，由业务目标决定。有限测试中没有出现事故，只说明本轮未观察到，不是未来永不发生的保证。指标设计可参考Agent 评测指标。

将选择写成一份架构决策记录

对于本文的资料核验场景，可以先形成以下待验证决策：

决策项	初始选择与理由
协作模式	外层执行图，节点内按需调用有界 Worker；交付责任集中
框架候选	LangGraph 与现有任务平台上的普通代码进入 PoC，比较状态治理的实际成本
对话入口	需要专业接管时再加入 Handoff，当前核验分支统一返回汇总器
部署方式	先保持一个服务和持久状态，重型或需要隔离的任务再拆 Worker
数据与写入	证据产物独立保存，业务写入经过统一权限与幂等入口
复审条件	验收收益不明显则减少 Agent；等待、扩容或权限边界变化时调整部署

选择 LangGraph 进入候选，是因为本例需要显式汇合与恢复；如果团队已经有成熟工作流平台，普通代码可能需要维护的新增组件更少。如果产品核心变成多轮客服接管，OpenAI Agents SDK 的 Handoff 模式值得优先评估；团队已有 CrewAI 或 Microsoft 生态资产时，则应将迁移与维护成本放入同一份比较表。

一份有效的选型结论应留下任务范围、比较结果、接受的代价、尚未验证的假设和复审触发条件。等到数据证明某个专业子任务能够独立完成、减少关键路径或提高验收质量，再扩大它的自治范围。架构沿着已经测得的收益增长，团队才能解释每增加一个 Agent，系统究竟获得了什么。

先判断任务能不能独立完成

任务形态	优先考虑	原因
多个互不依赖的资料核验	并行只读子任务	输入与产物可以隔离
后一步依赖前一步结论	顺序流程或局部委派	并行不能消除依赖
多人修改同一制品	分区、版本控制与单点提交	防止相互覆盖
简单查询加固定格式输出	单 Agent 或确定性流程	委派开销可能更大

Anthropic 的研究系统使用协调者与并行子 Agent 探索多个方向，说明多上下文可以服务于广度搜索。这是特定任务中的设计经验，不能直接推导所有业务都应采用相同拓扑。官方工程案例

在资料核验案例中，可让子 Agent 各自核验一个来源并返回证据，把文章更新或工单创建留在统一执行入口。这样先获得并行探索收益，再控制最终写入。

子任务返回可核对证据，不各自创建工单。汇总必须区分缺失、失败和相互冲突的结果。

委派的是一个有边界的任务

“帮我研究一下”会把任务范围、完成标准和退出条件全部留给子 Agent 猜测。更好的委派需要说明以下内容：

委派字段	例子
目标	核验 source-001 的发布日期
输入范围	指定版本资料与允许读取的公开来源
产物	日期、来源引用、版本、冲突与未知项
权限	只读，不更新知识库或创建工单
预算	独立上限与父任务剩余额度
完成条件	至少取得要求的证据，或明确说明无法取得
失败与取消	返回已取得证据和未完成事项

父任务应保留子任务编号、输入快照、委派版本与当前状态。只把子 Agent 的最后一句话拼起来，会丢掉它是否完成、使用哪版资料和哪些内容仍不确定。

汇总器不能把冲突变成多数票

三个 Agent 得到同一个日期，可能只是引用了同一篇转载。增加数量不等于增加独立证据。汇总时需要核对来源重合、发布时间、证据级别和引用链。

如果一个来源写发布日期，另一个写功能开放日期，应先区分概念，而不是投票决定哪一个是真的。子任务结果可以按“已证实、冲突、证据不足”汇总，无法解决的差异进入人工核验或下一次有界探索。

已有记忆治理解释了来源和权限跨团队流动的问题。子 Agent 产物进入共享记忆时也适用：不要因为它来自内部协作，就自动升级为可信事实。

并行写入需要显式合并规则

最容易维护的初始方案，是让子任务产出独立草稿或补丁，由一个提交者检查后写入。需要更复杂协作时，可以按文件、章节或资源分区，并用版本前置条件发现冲突。

即使两个子任务没有修改同一行，也可能产生语义冲突：一篇把项目描述为已发布，另一篇仍按预览版解释。机械合并通过以后，仍需整体验收。

DeepSeek 执行篇提供了委派、团队与执行边界的具体案例。本篇建议从“输入隔离、产物独立、提交集中”开始，再用实际协作需求决定是否扩展共享状态。

预算与取消需要向下传播

父任务有总预算，子任务有局部上限。并行启动前应预留额度，完成后结算实际消耗；不能让每个子任务都读取同一个未预留余额，然后各自花完它。汇总和独立验收也需要资源。

取消则应记录为持续有效的控制意图。父任务取消后停止新委派，向在途子任务传递取消，并跟踪它们是否停止或仍有外部动作待确认。已经发生的副作用不因取消而消失。

A2A 提供跨 Agent 任务协作的协议对象，MCP 主要连接工具与数据。协议可以帮助交换状态，却不能保证对方已经停止所有外部动作。A2A 规范也说明取消请求不保证成功，需处理任务已结束或当前阶段不可取消等情况。A2A 规范

一次并行收益评审

用单 Agent、并行工具调用、多个 Agent 三种方案完成同一组资料核验。分别记录关键路径、总调用成本、重复检索比例、冲突数量和最终验收结果。

并行工具已能解决的问题，不必增加独立 Agent。多 Agent 确有收益时，再为工作簿中的委派卡补上失联、取消、相互矛盾和父任务预算耗尽四个反例。