用独立信息域和验收条件判断拆分价值，控制协作带来的成本与状态冲突。
本文于 2026-09-12 补充整理，按 2026-08 专题归档。示例为方案设计，参数用于说明方法，不代表已上线项目或实测成果。
拆分应来自独立工作，而不是角色名称
给系统安排“专家”“经理”“审核员”三个角色，不会自动得到更可靠的架构。如果它们读取同一份上下文、调用相同工具，只是在重复生成意见，成本可能增加，错误却高度相关。
适合拆分的例子是：一个子任务查询知识库规范，另一个读取工单历史，两者各自有明确输入、权限和输出。协调者负责对齐证据，不让两个工作者随意修改共同业务状态。
Anthropic 的工作流模式介绍提供了并行与协调者模式的背景。本文的重点是对这个企业助手如何约束协作成本和状态。
为子任务定义交付契约
{
"subtaskId": "history-analysis",
"goal": "查找同项目内的相似故障处理记录",
"allowedTools": ["searchTickets", "getTicket"],
"maxModelCalls": 3,
"resultSchema": "EvidenceSummaryV1",
"deadline": "由协调者设置的绝对截止时间"
}
这是任务信封示意。实际传输中截止时间必须是可解析的时间值。身份上下文由执行系统注入，不能从目标描述里解析。
结果至少包含证据 ID、主要发现、未解决问题和状态。子任务输出“没有发现”，应与超时和权限拒绝区分。
避免共享可变状态
知识检索者和工单历史分析者返回独立结果，由一个汇聚节点更新主任务。若多个 Agent 都能修改同一提案，就必须处理版本冲突和覆盖问题。
写操作可以集中到专门执行器，统一检查审批和幂等。子 Agent 提出修改建议，但不直接执行创建工单。这样协调失败时，不至于出现多个工作者各自创建一张记录。
消息应携带任务 ID、子任务 ID、尝试编号和结果版本。重复结果可以被识别，晚到结果不能覆盖已经结束的主任务。
并行收益要扣除协调成本
两项任务并行后，理想耗时接近较慢的一项加汇聚时间，但总 token 通常是两项相加，再增加协调开销。若任务之间强依赖，并行还可能产生大量无效工作。
同一个模型对同一证据的多次投票不是独立事实来源。多票一致可能来自共同偏差，因此不能把“多数赞成”当作安全授权。
遇到证据冲突时，优先比较来源权威性、版本和适用环境。无法解决时，明确列出冲突并请求补充，而不是让协调者挑一段更流畅的答案。
为局部失败定义汇聚规则
知识查询成功、历史查询超时，主任务能否返回？取决于任务要求。如果用户只问规范，可返回带限制说明的结果；如果要判断是否重复工单，历史查询缺失可能意味着不能继续写入。
必须预先定义哪些子任务是必需项，哪些可以缺失。超时后取消不再需要的子任务，并回收预算；晚到结果作为审计记录保存，不重新打开已经完成的任务。
用单 Agent 作为对照组
相同样本、相同工具集合和相近总预算下，比较单 Agent 与多 Agent。观察任务成功率、证据覆盖、冲突率、总成本和端到端耗时。
如果收益只来自给多 Agent 更多 token，而不是任务划分本身，结论就应如实表达。拆分应该解决可解释的问题，而不是成为架构复杂度的默认方向。
