【篇首语｜企业 AI，正在从“会用”走向“能交付” 】

“国庆七日谈”不追逐短期工具热度，而是每天回答一个企业 AI 进入生产必须面对的工程问题：从需求契约出发，依次讨论业务上下文、多 Agent 协作、运行底座、质量验证、控制边界与组织规模化。我们会把AiDD2026上海、北京、成都三站的相关实践放在同一条链路上，寻找那些正在从个别案例沉淀为共同方法的答案。

第三日，把视线转向多个 Agent 共同完成任务的现场：多 Agent 不是多开几个对话框，协作为什么比智能更难？

国庆七日谈·第三日｜多Agent协作

▼

让一个 Agent 写代码、查资料或分析日志，已经不再新鲜。于是，一个看起来顺理成章的想法出现了：如果一个 Agent 不够，就多放几个；让产品 Agent 拆需求、开发 Agent 写代码、测试 Agent 找问题、运维 Agent 处理发布，效率自然会继续提高。

但真实任务不会因为参与者变多就自动变简单。

一个 Agent 独立工作时，问题通常集中在它能不能理解目标、调用工具和完成验证。多个 Agent 同时工作后，新的失败点会沿协作链出现：谁来拆任务，谁先开始，哪一份状态是最新的，上一个 Agent 交付了什么证据，下一个 Agent 是否具备接手条件，两个结论冲突时由谁裁决，任务阻塞后谁负责升级。

如果这些问题没有机制，多 Agent 只是在多个窗口里同时产生内容。每个 Agent 都可能局部正确，整个任务却仍然失败。

2026 年 AiDD 上海站、北京站和成都站的三场分享，分别从图驱动推理、Agent 团队治理与 Harness 作业编排切入，共同指向一个判断：多 Agent 的生产力不取决于角色数量，而取决于有没有一套可执行的协作协议。

这套协议至少要回答五件事：任务怎样形成契约，状态如何共享，工作怎样交接，冲突怎样拦截，责任在哪里收口。

多几个 Agent，先增加的往往是协调成本

人类团队不会因为把更多人拉进群聊就自动高效，Agent 团队也是一样。

多个 Agent 可能使用不同模型、不同工具和不同上下文。它们对同一个目标的理解未必一致，完成标准也可能不同。一个 Agent 把“已经生成结果”当成完成，另一个 Agent 却在等待可执行文件；一个 Agent 修改了数据，另一个 Agent 仍依据旧状态继续推理；还有两个 Agent 同时处理同一子任务，最后留下两份互相冲突的答案。

所以，多 Agent 的第一个问题不是“安排多少角色”，而是“建立什么共同事实”。没有共同任务、共同状态和共同证据，角色越多，信息同步和错误传播的路径也越多。

单体 Agent 可以在自己的上下文里保持局部连贯；多个 Agent 则必须把局部判断转成其他执行者能够读取、验证和继续推进的工作对象。协作工程的起点，不是群里多了几个名字，而是团队拥有了同一套任务、状态和交接语言。

第一层：先把规划、执行与治理责任拆开

在 AiDD 北京站《AgentTeams——多Agent治理管控与协作平台》中，阿里云产品解决方案架构师、AgentTeams 开源 Maintainer 王泉力展示了 Team Leader 与 Worker 的分层协作：Team Leader 分析目标、创建任务 DAG、拆分与分配子任务，Worker 专注具体执行，人类则能够查看过程并在需要时介入。

图 1：王泉力《AgentTeams——多Agent治理管控与协作平台》：Team Leader 负责拆解和分配，Worker 专注执行，共享上下文让协作状态可见（PPT 第 13 页）

这不是要求所有企业照搬同一种组织图，而是揭示一条通用原则：规划责任和执行责任需要被区分。负责拆解的单元要看见全局依赖，负责执行的单元要得到明确输入、边界和完成条件。如果每个 Worker 都重新解释总目标，协作很快会退化成多份互不兼容的计划。

人类治理也不能只发生在任务开头。人在 Agent 团队中不只是“发出一句指令”，还需要看见谁在做什么、当前卡在哪里，并在目标偏移或风险扩大前打断错误路径。多 Agent 的自主性越高，人工介入点越应该成为协作协议的一部分。

第二层：把聊天请求变成有状态的任务契约

责任拆开之后，任务还必须从一条聊天消息，变成有负责人、有依赖、有完成条件的工作对象。

王泉力的材料把任务状态分为待办、进行中、阻塞和完成，并为任务保留描述、负责人、时间与活动轨迹。这样，“做完了”不再是一句对话回复，“卡住了”也不会沉没在长长的聊天历史中。

图 2：王泉力《AgentTeams——多Agent治理管控与协作平台》：任务状态机、统一负责人和活动时间线让协作过程可见（PPT 第 21 页）

显式状态的价值，是让协作双方对同一件事形成可检查的理解：这项任务现在处于什么阶段，已经产生什么结果，还缺什么条件，下一步应该由谁行动。只有状态被持久化，任务才能被转交、恢复和复盘。

在 AiDD 成都站《统一的Harness Engineering框架，实现作业、管理和工具的灵活编排》中，兴云数科软件工程总工王秉发进一步把交接落到具体产物上。其需求分析案例为每个技能明确了读取依赖、输出产物和下游接收方，失败则进入检查与迭代。

图 3：王秉发《统一的Harness Engineering框架，实现作业、管理和工具的灵活编排》：读取依赖、输出产物与下游接收共同构成交接契约（演讲 PPT 第 19 页）

这让交接从“我已经处理过”变成“我交付了什么”：上游读取了哪些事实，生成了哪份产物，是否经过检查，下游凭什么判断可以接手。没有这些信息，下一个 Agent 只能重新猜测上一步的意图；有了交接包，协作才可能沿着同一条链继续。

第三层：共享的不是聊天记录，而是可继续推进的状态

多个 Agent 在同一个群里，并不等于共享上下文。聊天记录告诉大家“说过什么”，却未必说明当前任务的有效状态是什么。

在 AiDD 上海站，阿里云云原生可观测技术专家刘贵阳在《突破 LLM 的运维能力边界：图驱动多 Agent 协同与因果推演实战》中，以根因分析展示了一套更结构化的做法：协作上下文包含调查轨迹、图状态、调查范围、证据块、工作记忆和状态快照，不同 Agent 围绕这些对象接力推进。

图 4：刘贵阳《突破 LLM 的运维能力边界：图驱动多 Agent 协同与因果推演实战》：调查轨迹、图状态、证据块与工作记忆共同组成可传递上下文（演讲 PPT 第 26 页）

这里最重要的不是某一种存储形式，而是状态能够被读取、验证和续写。后续 Agent 不只收到一句结论，还能知道前一步观察了什么、调用了什么、哪些证据支持当前判断、调查范围已经推进到哪里。

从这个角度看，多 Agent 协作的最小单位不是角色，而是可被共同读取和更新的任务状态。角色可以更换，模型可以升级，只要任务对象、证据路径和完成条件仍然清楚，协作就能继续。

第四层：按任务边界选择 Team、Worker 与 Subagent

协作系统还要回答一个常被忽视的问题：任务应该在哪一层执行？

王泉力的材料把业务模块映射为 Team，把业务功能映射为 Worker Agent，把功能内部低时延、强内聚的步骤映射为同一进程中的 Subagent。这个划分背后不是术语差异，而是协作成本的差异。

图 5：王泉力《AgentTeams——多Agent治理管控与协作平台》：模块、功能与流程映射到 Team、Worker 和 Subagent 三种协作粒度（PPT 第 32 页）

跨模块任务需要清晰交接、独立责任与完整留痕，适合跨 Team 或 Worker 协作；一个功能内部连续、强依赖共享上下文的步骤，如果每一步都跨进程传递，就会把大量时间耗在上下文重建与状态同步上，更适合在同一 Worker 内编排。

所以，多 Agent 不是分得越细越好。凡是需要独立验收、并行执行或跨专业交接的工作，应该形成清晰任务；凡是高度内聚、必须共享完整上下文的连续步骤，则不必为了“看起来更像多 Agent”而强行拆开。

第五层：冲突要有门禁，走不下去要能够升级

多个 Agent 协作时，结论冲突不是异常，而是常态。真正危险的不是出现不同判断，而是没有机制决定下一步该继续、回退还是交给人。

刘贵阳的材料在根因分析流程中设置了统一 Gate：检查时间顺序是否成立、是否存在替代解释、证据是否足够。不通过时，不让错误假设继续向下传播，而是回退、补证、替换假设或进入人工复核。

图 6：刘贵阳《突破 LLM 的运维能力边界：图驱动多 Agent 协同与因果推演实战》：Gate 通过时间顺序、替代解释与证据充分性拦截错误推进（演讲 PPT 第 27 页）

这类 Gate 不能覆盖所有并发写入、资源争夺和权限冲突，但它给出了一个关键方法：协作不能只定义成功路径，还要定义分歧如何被看见和处理。如果所有 Agent 都可以把自己的结果直接写入最终状态，局部错误会迅速变成团队事实。

人在其中要有明确工位。王秉发的材料把人类确认、检查与询问、手工测试和人工审批嵌入作业节点，同时让自动化继续完成适合机器执行的部分。

图 7：王秉发《统一的Harness Engineering框架，实现作业、管理和工具的灵活编排》：人工确认、测试与审批被嵌入作业节点，和自动化共同推进状态（演讲 PPT 第 12 页）

人工参与的价值，不是替 Agent 收拾所有残局，而是在高风险、信息不足或责任不可转移的节点承担判断。哪些情况必须停，谁有权继续，审批后留下什么记录，都应在任务开始前被定义。

当 Agent 自己走不下去时，还需要明确升级路径。刘贵阳课件中的 Fallback 机制，会在循环、门禁连续失败、证据不足、低置信度或超时等情况下暂停调查，保存状态快照，再选择恢复、切换策略或转交人工。

图 8：刘贵阳《突破 LLM 的运维能力边界：图驱动多 Agent 协同与因果推演实战》：Fallback 保存状态与证据后，分级恢复、转交或人工接管（演讲 PPT 第 37 页）

关键不在某一个阈值，而在升级前先保存进度与证据。否则，人工接手后仍然要从头排查，多 Agent 不但没有节省时间，反而制造了一段无法解释的黑箱过程。

最后一公里：作业完成，管理状态也要同步

多 Agent 还有一种很隐蔽的失败：任务实际上已经完成，管理系统却仍停在旧节点。

王秉发的材料提出让作业活动完成后自动反写工作项、翻转流程状态。执行现场发生的变化能够回到管理视图，避免人再去群里追问“现在做到哪一步了”，也减少手动同步带来的滞后与偏差。

图 9：王秉发《统一的Harness Engineering框架，实现作业、管理和工具的灵活编排》：作业完成后反写工作项和流程状态，让执行现场与管理视图保持一致（演讲 PPT 第 35 页）

状态回写不仅是看板更新。它意味着下一项任务的启动条件、人类审批的依据、异常恢复的位置，都建立在同一份事实之上。协作链路由此闭合：任务被拆解，执行者接手，产物与证据被交付，门禁决定是否放行，最终状态回到管理系统。

多 Agent 至少需要五份共同协议

把三站分享放在一起，可以归纳出多 Agent 协作的五个基本对象。

第一，任务契约。每个子任务要有目标、输入、边界、负责人、依赖和完成条件。

第二，共享状态。所有参与者围绕同一份任务、证据和进度工作，而不是分别在自己的对话历史里维护不同现实。

第三，交接包。上游交付的不只是答案，还要包括产物、证据、状态变化、未决问题和下游启动条件。

第四，冲突门禁。分歧、证据不足和质量不合格要能够阻塞错误推进，并触发补证、重试、换路或人工复核。

第五，责任升级。系统要知道什么时候暂停、谁有权裁决、如何把状态和证据完整交给人，并让最终结果回写管理流程。

企业可以从一条边界清晰的小链路开始验证这五份协议。例如，让两个执行 Agent 和一个质检 Agent 共同完成一类固定工单：先明确任务格式与验收条件，再建设共享状态，让每次交接带上产物与证据，最后设置一个人工放行点。只有这条小链路可以稳定运行，增加更多角色才有意义。

还要记住：不是所有复杂任务都应该使用多 Agent。一个 Agent 可以完成、上下文高度内聚、责任边界清晰的工作，强行拆分只会增加通信和同步成本。多 Agent 真正适合的，是那些天然存在专业分工、能够并行推进、需要独立复核，或者必须跨系统交接的任务。

结语：一群 Agent，不会自然变成一支团队

模型能力可以让每个 Agent 更聪明，却不会自动让多个 Agent 形成组织。

一支真正能够交付的 Agent 团队，需要有人拆解和分配，需要任务成为可持久的工作对象，需要所有成员看见同一份状态，需要交接携带产物与证据，也需要人在冲突、阻塞和高风险节点能够打断、裁决并承担责任。

上海站的图驱动推理说明，协作必须保留状态、证据和失败后的接管路径；北京站的分层团队与任务管理说明，目标要被拆成有负责人、有状态的契约；成都站的 Harness 实践则进一步说明，依赖、产物、人工工位和状态回写要进入同一条作业链。

所以，多 Agent 的门槛不是多创建几个角色，也不是让它们在群聊里彼此提问。真正的门槛，是把协作从自然语言里的临时默契，变成系统可以执行、检查和追踪的协议。

当这套协议存在，多个 Agent 才可能互相补位；没有它，再多的智能也只会变成更多并行的不确定性。

国庆七日谈·第四日，我们继续讨论：云端大模型越来越强，企业为什么还要做本地闭环？

 主要参考演讲

- 刘贵阳：《突破 LLM 的运维能力边界：图驱动多 Agent 协同与因果推演实战》，第9届 AI+研发数字峰会（AiDD 2026 上海站）。

- 王泉力：《AgentTeams——多Agent治理管控与协作平台》，AiDD 2026 北京站。

- 王秉发：《统一的Harness Engineering框架，实现作业、管理和工具的灵活编排》，AiDD 2026 成都站。