13 · Multi-Agent协作：两个人都完成了，结论却打架

Multi-Agent（多Agent协作）把能独立推进的工作交给多个Agent，再由调度器约束依赖和资源，由合并者判断结果能否组成同一份交付物。

本课的位置：Multi-Agent位于左侧编排控制层，拆分、隔离、等待和合并多个执行者的工作，仍使用同一套执行边界。

设想一个开发文档研究任务：“确认撤销API key后，旧下载链接还能用多久，并核对兼容性要求要不要调整。”材料包括当前第3版认证文档和一份旧版兼容性记录。交付物是一段带来源的说明；是否修改系统，是后续另一个动作。

主Agent把问题分给两个执行者：A读当前文档，B整理兼容性记录。设例中，A交回60秒，B交回3600秒。两份结果都完整，两个子任务也都正常结束；直接拼接，就会把矛盾完整交给用户。

这里没有真实产品或模型效果承诺。我们用这项虚构研究任务讨论协作层的位置：它位于单Agent运行时之上，主Agent可以提出分工，每个子Agent有自己的上下文与执行过程；依赖、预算、归属和交付资格由程序负责兑现。

拆分之前，先明确各自要回答的问题

A要确定当前规则，所需材料是现行认证文档、适用版本和用户问题；B要找出旧兼容性要求，所需材料是历史记录、目标版本和来源说明。B交回的不是另一份当前规则，而是“现有要求基于什么假设”，这样才可能发现迁移遗漏。

每个任务都写清目标、允许输入、工具范围、输出内容和完成条件。A交付规则与出处，B交付原有期望与出处，合并者对照同一个事实。若任务只写“帮忙查一下”，很容易得到两份主题相似却无法比较的摘要。

DAG是有向无环图，用箭头表达前置依赖。A、B没有前置，可同时开始；C合并依赖两者，D交付依赖C。关系中不能出现“A等B、B又等A”，重复任务与缺失前置也要在开始前发现。

多个角色名称并排出现，并不自动形成多个Agent。如果一份短文和一个明确问题由单Agent就能完成，继续顺序处理往往更省事。独立任务足够清楚、输入可分开、结果能核对，才有拆分价值；需要不断共享细节、共同改同一结果时，协调成本可能超过收益。

上下文独立，材料和写入归属也要独立

A不需要看到B的完整过程，B也不应把A未经核对的结论直接当成自己的证据。各自接收明确的任务说明、授权范围、资料版本和输出约定；不能只写“按上文继续”，假定另一个执行者知道所有背景。

共同材料可以使用同一批输入快照，并保持只读。各子任务写入自己的工作区，合并者才有资格提交最终产物。独立上下文减少无关信息干扰，独立Workspace解决文件归属；前者不会自动阻止写冲突，后者也不会补齐遗漏的任务要求。

如果A、B都覆盖同一份报告，最后保存的人可能抹掉另一方的内容。更稳妥的做法是让它们提交独立结果，再比较目标路径、输入版本与修改内容。不同内容指向同一目标时先报冲突；同一内容重复提交可以去重，但仍保留来源。

共享输入还有权限约束。父任务有能力读取某份资料，不代表每个子任务都需要获得它；委托时缩小到当前职责所需的范围。资料在执行过程中更新，就要明确新旧任务使用哪一版，不能把不同时间的结果悄悄合成一份当前结论。

谁能开始，谁必须继续等？

调度器先看前置状态。前置还在运行，后续任务继续等待；必需前置已经失败或被拒绝，依赖它的任务被阻断。只有前置成功，才申请并发名额和预算，开始实际工作。

本例允许A、B同时研究，但C必须等它们都交付可读结果。并发名额限制同一时刻活动的数量，预算限制整项任务总共能消耗多少，截止时间限制最晚何时收束。这些限制不能互相替代，多开Agent也不能绕过同一个工具服务的串行配额。

主Agent可以根据新发现增加任务，但新增任务也要检查依赖、权限和额度。子Agent提出“再派十个人查一遍”只是建议，不自动获得扩张资格。任务开始后保存父Run、子任务和尝试号的归属，重试沿用这份关系，避免出现无人管理的派生工作。

传统后端工作流也会处理这些依赖；Agent增加的是子任务内部可以由模型选择检索和分析步骤。程序仍然要决定哪些状态允许继续推进，而不是接受一句“我完成了”就进入交付。

两份结论为什么都完整，却不能合并？

回到研究任务，合并者收到以下内容：

同一批资料只说明它们来自相同的输入集合，并不保证每条材料都描述同一时期的事实。结构完整也不等于含义一致；两份结果必须放到“哪一版规则、适用于什么对象”上重新比较。

合并者先核对必需结果是否齐全、产物属于哪个任务、来源能否定位；再核对结论是否指向同一事实。这里一个说60秒，一个说3600秒，当前报告不能同时把两者当成现行要求，所以暂停交付，保留冲突的来源和版本。

随后安排定点重查：B核对旧要求是否已经迁移到第3版。若历史记录确实未更新，就形成一份新的说明——当前有效期按60秒理解，兼容性要求仍有旧假设需要调整。旧记录保留，不能静默覆盖，让后来的人误以为过去从未要求过一小时。

A的正确产物不必跟着重做。只要输入版本、来源和校验仍成立，继续复用它；如果资料版本改变，或发现A也误读了规则，就重新判断复用资格。这样把返工范围控制在冲突所在，而不是每遇到一个问题便从头启动整组Agent。

修复后的两条说明同指当前规则，不构成两份独立证据，更不能用多数投票决定事实。对于单位、日期、枚举等明确字段，可以按约束自动比较；“是否适用于这个用户”之类复杂条件，还需要语义审核或人工核对。多个Agent复述同一句错误，不会让它变得更可信。

并行究竟能省哪一段时间？

给这项任务的第一轮做一个教学计划：A预计200毫秒，B预计300毫秒，合并50毫秒，交付30毫秒。全部顺序相加为580毫秒；若A、B确实可以重叠，又暂时不计启动和排队，最长的依赖链是“B→合并→交付”，合计380毫秒。这条链就是关键路径。

计算时，一个任务最早能结束的时间，等于前置中最晚结束的时间，加上自身耗时。没有前置就从起点计算；保存每次让它等待最久的前置关系，便能找回最长链。

这些数值是规划假设，不是模型速度实测，更不是交付时间保证。真实耗时还包括任务启动、重复输入、模型排队、工具限流、合并以及这次冲突带来的重查。两项研究若都需要同一个串行接口，能重叠的部分也会缩小。

因此，本例适合尝试并行，是因为两份材料可以独立阅读，最后又能围绕同一个事实核对。若任务很短、交接很多或高度依赖同一份上下文，单Agent顺序推进可能更合适。多Agent研究实践也讨论了分工与协调之间的成本，不能把一个系统的效果直接搬到另一种任务上。

给探索留额度，也给收敛留额度

预算不能只写一句“注意节省”。设例把总额度定为12个教学单位，至少2个留给合并和交付。A、B启动前各预留上限，结束后按已确认消耗结算，释放未用部分；首次合并虽然发现冲突，也已经消耗资源，不能因为没有正式结果就记为零。

启动前比较总额、已消耗和在途预留，避免多个子任务同时把同一笔余额当作可用额度。研究任务不得吃掉全部收敛额度；需要追加时，由父任务重新判断缩小范围、续额还是停止。跨服务共同申请时，判断与预留要在存储层原子完成。

取消尤其不能直接清账。远端调用是否停止、产生多少费用还没确认时，保留未决预留并继续对账。并发限制解决现在跑几个，费用限制解决总共花多少，时间限制解决何时结束，三者都要传到每个子任务。

必需任务失败就阻断依赖它的交付；可选背景研究失败，则可以交付明确缺少背景的部分结果。哪些结果可以缺，来自任务契约，不能由合并Agent临时把失败项解释成不重要。

父任务停止时，关闭新增调度，向活动子任务及其工具传播取消，等待它们退出。迟到产物可以补记事实，不能绕过父Run状态再次触发交付。下一课进入Observability，把父子任务、工具、来源、预算和产物连接起来，才能解释这次矛盾究竟在哪里产生，又怎样被收束。