多 Agent 编排与结果合并

先用单 Agent 建立可验证基线，再决定是否拆成多个独立推理循环。本文沿任务依赖计算并行上限，明确每个分支的输入、产物与提交权，并处理迟到结果和失败恢复。成功标准是完整任务的质量、时间和成本改善。

从工作流到多 Agent

单 Agent 也能并行调用独立工具；因此“需要同时读多个文件”不一定需要多个推理循环。多 Agent 更适合需要各自较长分析、不同信息范围或独立工作过程的子任务。每个 Worker 形成自己的上下文后，向协调者返回压缩结果与证据定位，可以减少主上下文承载的原始材料。

多次模型调用也不自动等于多 Agent。固定抽取、校验和格式化流水线可以由普通工作流实现；动态分解任务并让各分支根据工具反馈独立推进，才更接近这里讨论的协作 Agent。Building effective agents

多 Agent 对话框架展示了角色、工具和交流模式的组合能力，但框架提供对话机制不等于自动提供任务正确性。AutoGen 论文 决定采用哪种结构时，应先找出单 Agent 当前的具体限制，再验证增加协作是否改善了它。

先画依赖，再计算收益

假设任务由准备 A、实现 B、独立兼容性检查 C 和汇总 D 组成。B、C 都需要 A 的接口约定；D 必须拿到两者结果。若 B 与 C 确实能独立推进，下面的并行成立：

串行时间是 2+4+6+3=15 分钟；理想并行时间是 2+max(4,6)+3=11 分钟，节约 4 分钟。若委派、排队和合并冲突额外耗费 5 分钟，总时间反而是 16 分钟。启动了两个 Worker，并不等于任务快了一倍。

如果 C 检查的是 B 尚未产出的补丁，C 就依赖 B，这个图需要改成串行；也可以先让 C 独立整理检查标准，等补丁完成后再验证。⁠改变任务定义可以创造一部分并行空间，但不能用模型猜测消除真实数据依赖。

duration = {"A": 2, "B": 4, "C": 6, "D": 3}
deps = {"A": [], "B": ["A"], "C": ["A"], "D": ["B", "C"]}
finish = {}
# 本例字典按依赖的拓扑顺序列出，不是通用调度器。
for node, minutes in duration.items():
    finish[node] = max((finish[x] for x in deps[node]), default=0) + minutes
assert finish["D"] == 11
assert sum(duration.values()) == 15
print("理想并行分钟:", finish["D"])
print("另加 5 分钟协调开销:", finish["D"] + 5)

成本也要加总主 Agent、所有 Worker、重复读取、工具调用和失败尝试。便宜模型承担合适子任务可能节省费用，但多个独立窗口也会重复加载约束和材料；前缀缓存能否命中取决于服务、模型和输入。不能保证“另开子 Agent 必然比主循环切模型便宜”。

实际多 Agent 研究系统的工程报告同时讨论了上下文隔离、独立研究与较高 token 消耗，也指出紧密依赖任务的协调限制。该系统的收益应作为具体案例理解，而非所有任务的加速倍数。Anthropic 多 Agent 研究系统

增加并行，为什么没有按人数提速？

先画出依赖，再谈并行收益。图中每条任务条的起点由前置任务决定，合并也占时间。注意默认总工时是 15，最长路径却是 9；这两个量分别回答资源消耗与完成延迟。

$$T_{\mathrm{parallel}}=\underset{p\in \mathrm{paths}}{\max }\sum _{i\in p}{t}_i+T_{\mathrm{coordination}}$$

委派是交付一个任务契约

“你负责检查兼容性”过于模糊：检查哪个版本、哪些接口、是否允许修改、需要什么证据都没有定义。协调者应把 Worker 完成任务所需的信息交付完整，同时避免倾倒全部主会话历史。

工具、历史、文件系统是否共享依运行环境而定。即使共享目录，Worker 也未必已经读过文件；即使不共享历史，也可以通过明确输入恢复必要背景。委派消息应说明实际可访问的资源，而不是假定对方“知道前面聊过什么”。

如果主任务要求“先只改中文”，这个约束必须传给所有可能修改文档的 Worker。主 Agent 的授权也不是任意扩张工具权限的理由：只读检查任务应获得它需要的能力，越出范围的发现交回协调者决定。

产物所有权与结果验收

给写入划定边界

共享工作区中，两个 Agent 同时修改同一文件可能覆盖内容；分配不同文件也不一定独立，因为它们可能共同改变某个接口约定。可选择按目录或产物分工、使用独立分支或工作副本，再由一个明确的集成者合并。

隔离的副本减少直接覆盖，却不能避免语义冲突。例如 B 把字段改名为 item_id，C 的测试仍认为字段叫 sku；即使补丁文本能自动合并，集成后也会失败。契约中固定接口版本，变更时先传播给依赖方，可以减少这种无效工作。

摘要用于定位，证据用于确认

Worker 返回“检查通过”不够。结果应包含针对的输入版本、采用的方法、可查看产物和未覆盖项。协调者先检查目标覆盖，再核验版本与证据，最后决定接受、补充还是重新划分。

独立评审有助于发现遗漏，但另一个同模型 Agent 也可能共享同样偏差。“作者与评审分离”提供角色和上下文差异，不等于统计独立或证明正确。把明确标准、独立测试、实际运行与必要的人类评审结合，才有可解释的验证边界。

worker 成功，为什么仍不能合并？

结果归档可以保存所有尝试，正式产物合并却只能接受满足当前合同的结果。把“worker 已结束”“结果已收到”“结果已验收并合并”拆成不同状态，避免一个 success 字段承担三种含义。

编排也需要恢复语义

协调者应为每个子任务保存任务 ID、尝试编号、输入版本、状态和产物位置。状态至少区分 queued、running、completed、accepted、failed、cancelled：Worker 已完成，只代表结果产生；accepted 才表示协调者已确认可用于整体交付。

假设尝试 1 超时，协调者启动尝试 2；稍后尝试 1 的旧结果到达。若只按子任务名接受，会让旧内容覆盖新内容。需要按尝试编号与输入版本核验迟到结果，必要时把它留作参考而不自动发布。

取消也不保证旧 Worker 立刻停止写入。共享资源场景要控制提交权限，例如由集成者核验当前有效尝试或版本后才写入权威产物；否则界面显示 cancelled 的 Worker 仍可能在后台覆盖文件。跨执行者的状态规则与 记忆与状态 中的条件更新相呼应。

怎样判断多 Agent 确实有收益

用同一任务集比较单 Agent、单 Agent 并行工具和多 Agent，尽量保持工具权限、输入证据与验收标准一致。除了任务成功率和总延迟，还记录主 Agent 协调时间、重复工作比例、冲突数、失败重试与全部成本。

如果 Worker 很快而主 Agent 长时间反复澄清和合并，瓶颈是任务划分或结果契约；如果两个 Worker 总查相同材料，范围可能重叠；如果总是合并后失败，应检查共享接口与集成测试。如果单 Agent 的批量工具已达到相同效果，就没有必要为了角色数量增加维护成本。

更详细的指标和逐任务追踪在 评估与可观测 展开。评估的单位应是用户的完整任务，不能只统计启动了多少 Agent 或产生了多少条消息。

继续阅读：评估、试次与可观测。