Multi-Agent Collaboration：多 Agent 的分工、共享上下文与人工验收

快速结论

Multi-agent collaboration 是一种工作设计。团队拆解目标，把各部分分配给两个或更多 AI Agent，并把所需上下文放在共享记录里，团队配置并授权访问的成员与 Agent 都能读到。Agent 之间通过可见的交接传递产出。

一个带人工验收的示例

下面用一个假设场景说明多 Agent 协作的几个部分如何组合。小型产品团队运行每周产品发布简报。团队负责人在 Channel 里发布简报要求，包括发布目标、目标受众、要用的来源、格式和截止时间，并按目标、约束和工作流创建有明确负责人的任务，分配给各角色。

研究 Agent 在团队配置的成员与权限范围内读取共享上下文，认领分给它的工作，把来源整理进共享文档。起草 Agent 把笔记变成结构化简报，复核 Agent 对照要求检查来源、链接和语气，各自更新自己任务的进度。

最终简报成为交付物。评审者打开它，对照验收标准评估，并把反馈写进共享记录。团队据此安排起草 Agent 修订。如果简报涉及团队指定的高风险、不可逆或需对外执行的动作，团队或该工作流受团队授权的 Agent 为平台支持的动作准备 Action Card，有权人以本人身份审阅并提交该指定动作。团队决定哪些指定动作需要审阅，工作空间保留审阅与提交记录。

一周之后，团队能从记录中回答四个问题，即每个部分由谁产出、审阅后改了什么、谁验收了最终版本，以及哪项指定动作由谁审阅并提交。这份记录就是协作的验收结果。

Syfo 与 Multi-Agent Collaboration 的关系

Multi-agent collaboration 是一种工作设计，团队拆解目标并把各部分分配给多个 AI Agent，把所需上下文放在团队配置并授权访问的成员与 Agent 可读的共享记录里。Syfo 是让人和 Agent 共同工作的 workspace，承载这种设计中的协作与验收部分。

团队能在同一处核验真正重要的事实，包括决定了什么、每件任务由谁负责、交付了什么，以及哪项指定动作由谁审阅并提交。

运行时与编排这一侧仍由团队及其选用的工具负责，包括 Agent 间调度、模型通信、部署和与其他系统的集成，角色、目标、权限、风险策略与业务决策同样留在团队一侧。Syfo 与这些系统协同工作。

这一结构背后的组织模式是 Organizational Agent Harness；Syfo 案例页说明团队安排这类工作的示例方式。

Multi-agent collaboration 与编排、单 Agent 工作、Agentic AI 的区别

这个词经常和相近概念混在一起。区别很重要，因为它决定团队要搭建和验证什么。

协作与编排。 编排是运行时问题，控制层决定哪个 Agent 运行、何时运行、能调用什么。协作是工作设计问题，涉及谁拥有任务的哪一部分、共享什么上下文、产出如何复核。有的工作流编排强而协作弱，有的正好相反。团队说他们的 Agent 在「协作」时，通常指角色、上下文和交接的设计。

多 Agent 与单 Agent。 单 Agent 从一个上下文处理一件任务。多 Agent 把任务拆分，让不同 Agent 并行、专精或互相检查。好处是关注点分离，起草和核对事实不必争抢同一份注意力。代价是协调，每一次交接和每一次共享上下文更新，都需要团队设计和验证。

Multi-agent collaboration 与 Agentic AI。 Agentic AI 是一个宽泛类别，指具有目标导向、在有限逐步指令下规划和行动的 Agent。Multi-agent collaboration 是这个类别里的一种组织形式，把多个目标导向的 Agent 用角色、上下文和交接组织起来。单 Agent 系统可能很 agentic，多 Agent 工作流也可能很简单。问一个任务是否「等同」于 agentic AI，会错过实际问题，即任务是否从拆分中受益。

这个区别也影响评估方式。对单 Agent，检验标准是产出是否回答了提示词。对 multi-agent collaboration，检验标准是分工是否带来比单 Agent 更好的产出，且协调成本在团队承受范围内。跳过这个比较的团队，常常最后是两个 Agent 做了以前一个 Agent 做的事，还多了一段需要管理的交接。

协作中的 Agent 需要什么

协作出现问题时，团队先检查四个方面。每个方面都有对应的设计答案。

一个角色、一个负责人。 团队为纳入任务管理的工作指定由人这一侧或 Agent 承担的负责人，并设置可见状态。工作受阻时，团队能定位到具体任务并明确负责人。角色模糊会造成重复或无人认领的工作。

比单步更长久的共享上下文。 团队把目标、约束、决定和来源放在团队配置并授权访问的成员可读的记录里。获准成员看到同一份当前上下文，成员边界与权限由团队设定。只存在于私人提示词或单个 Agent 记忆里的上下文会漂移，每个 Agent 从不同版本的事实出发。

可见的交接。 每次工作转移都被记录，什么移动了、从谁转移到谁、处于什么状态。可见交接是一个小型的复核点，它让团队能回答某件工作来自哪里、过程中改了什么。

对照书面标准的复核。 交付物应对照验收标准评估，而不依赖主观印象。评审者打开实际产出、检查、记录结果。复核把协作和一堆产出区分开。

标准由团队定义，Agent 不自行设定标准。每周简报可能要求已核验的来源、固定结构和字数限制，录入摘要可能要求客户上下文和明确的下一步。标准写下来之后，评审者有具体的依据可查，团队也能从记录看到什么被验收、什么被打回。

常见的协作模式

几种模式反复出现在工具、论文和框架里。按名字认识它们值得，因为它们直接对应设计选择。

主管与专家。 某些运行时框架采用主管 Agent 把工作分配给专家 Agent 并整合产出的模式，把分工决策集中起来。团队仍设定角色、目标、边界与验收标准，运行时分配由团队选用的编排工具承担。风险是主管成为瓶颈，或者团队看不清每个专家做了什么。

同行复核。 两个或更多 Agent 互相产出和检查，起草 Agent 与复核 Agent，或写作者与批评者。这种模式把创造与验证分开。风险是当复核者和起草者盲目共享同一份上下文时，复核者继承了起草者的假设。

基于角色的流水线。 一串 Agent 各做一阶段，研究、起草、编辑、可发布。交接就是设计本身。风险是每一阶段若不做检查就信任前一阶段，错误会累积。

并行专家。 独立 Agent 并行处理同一目标的不同部分，由团队安排合并与最终复核。这种模式适用于各部分相互独立、再由团队安排合并复核的任务。风险是合并后的产出里有没人弥合的空缺或矛盾。

这些模式都不是能直接买到的产品。每一个都是团队对角色、上下文和交接做的设计选择。同一套工具能支持多种模式，一个工作流可能组合其中两三种。

每种模式回答不同的问题。主管与专家回答谁来定分工，同行复核回答工作如何被检查，流水线回答阶段如何衔接，并行专家回答独立部分如何合并。团队很少需要把一种模式当品牌选，而是要为每个问题选正确答案，一个工作流可能组合其中两三种。

流水线适合每周简报或录入摘要这类重复工作，因为它把顺序清楚展示给评审者。代价是延迟，每一阶段都要等前一阶段，工作流的速度取决于最慢的一次交接。对截止时间很紧的任务，团队应该先确认串行流水线够快，再增加阶段。

以 Bot 为中心 vs. 以工作为中心的协作

上面几种模式讲的是工作如何在 Agent 之间流动，与之相关的另一个设计问题是产品把什么放在中心。当 Agent 有了名字、上下文和持续进行的工作，协作工具的差别就在于中心对象是 Agent 本身，还是工作本身。

一种方向以 Bot 为中心。xAI 关于 Grok Bot 的设计说明把 Bot 定为主要对象，对话本身退居其次，每个 Bot 都是持续存在的参与者，群聊则是多个专精 Bot 共享上下文、彼此交接工作的地方，协作围绕群聊里的这组 Bot 展开。

Syfo 采取以工作为中心的方向，主要对象是工作本身。Channel 承载目标和共享记录，Agent 按角色围绕一件可以有负责人和可见状态的任务组织起来，产出成为评审者能打开的交付物，再由评审者复核并决定下一步。Agent 是这份记录里的参与者，工作空间并不围绕 Agent 组织。

在一场群聊里，两者看起来相似，都是几个 Agent 在交换消息，但重心不同。以 Bot 为中心的设计把 Bot 及其上下文放在中心，以工作为中心的设计把任务、负责人、交付物和复核放在中心，让团队更有依据地复核各部分由谁产出、交付物如何被处理。哪一种更合适，取决于团队是围绕持续存在的 Agent 组织，还是围绕可复核的工作组织。

Multi-agent collaboration 在哪些地方失效

常见的设计风险包括以下几类。把这些当作试点中要验证的条件，市场普遍结论不在其列。

沟通开销。 每一条 Agent 间消息、上下文刷新和状态更新都消耗时间和 token。随着 Agent 数量增加，协调消耗可能超过工作本身。

目标冲突。 为不同目标优化的 Agent 会互相拆台，一个在删减内容，另一个需要完整版本。没有共享目标记录、没有解决冲突的人，系统会来回摆动。

上下文漂移。 每个 Agent 维护自己版本的目标与约束。上下文不共享时，小差异累积到产出和简报不一致。

重复工作。 没有清晰归属，两个 Agent 产出重叠内容。团队需要重复处理，并手工弥合差异。

不可复核的产出。 当 Agent 贴出长消息、团队称它为交付物时，没有人能打开稳定的交付物、对照标准评估、记录验收。复核变成了检索会话记录。

没有人工关卡。 对于包含团队指定的高风险、不可逆或需对外执行动作的工作流，团队需要明确的审阅与提交关卡。缺少这一关卡时，该指定动作可能缺少清晰的人工决策记录。关卡针对具体指定动作，不阻塞整个工作流。

每周简报需要评审者对照标准复核交付物；如果简报包含团队指定的动作，再由有权人审阅并提交该动作。事先把关卡写清楚，协作能够继续推进，同时把人的判断留在关键时刻。

每个失效模式都有验证角度，这也是后面清单能当试点测试的原因。试点的目标是识别第一项会挡住生产的失效模式。顺序很重要，因为修法不同，角色不清靠命名和归属修，上下文漂移靠共享记录修，缺失人工关卡靠定义复核步骤修。

试点与评估清单

试点宜从一件重复工作流开始，一次只验证一个要素。

• 每件任务是否只有一位明确负责人（人或 Agent）对结果和验收标准负责？
• 相关团队成员能否读到当前目标与最新决定，还是它们只存在于私人提示词里？
• 每次交接是否记录了来源、目标和状态？
• 评审者能否打开实际交付物，还是只能看到摘要？
• 是否记录谁验收了每件交付物、谁提交了每个指定动作？
• 团队能否在不更换工具的情况下更新角色、权限和风险策略？
• 团队能否从共享记录识别出某个 Agent 产出了无人复核的工作？

任何一题答否，通常应先调整流程，指定负责人、把决定写进共享记录、让交付物经过评审者。选择第一个用例和清单同样重要。适合的试点工作流要足够重复以验证模式、足够窄以便定义、足够可见以便评审者判断产出。候选例子包括每周研究简报、录入摘要、草稿复核和跨团队状态报告。在针对敏感数据、外部系统或不可逆动作的关卡定义并测试完成之前，不宜从这类工作流起步。

团队应先判断任务是否因拆分而获益，技术上的新鲜感本身不构成采用理由。只有一位负责人、一份事实源、产出很短的任务，交给单 Agent 并配上清晰的提示词可能更快。横跨研究、起草、检查和复核的任务，则自然适合拆分，不同步骤需要不同的注意力，团队也希望在下一步开始前看到上一步的产出。拆分一件没有自然接缝的任务，只会增加协调成本，不提升清晰度，因此设计问题要先于工具问题。

FAQ

multi-agent system 有哪些例子？

常见例子包括一个 Agent 收集来源、另一个 Agent 起草的研究工作流；一个 Agent 分类请求、另一个 Agent 组织回复的客户场景；以及 Agent 产出、复核并汇总状态更新的内部报告。只要多个 Agent 从共享上下文出发、角色和交接都有明确定义，即可称为 multi-agent system。

如何让多个 AI Agent 协同工作？

给每个 Agent 一个明确角色和单一任务负责人，把目标和决定放进共享记录，记录每一次交接，并让交付物经过评审者。实际要设计的是角色、上下文和复核，连接模型只是其中一部分。

multi-agent 和 agentic AI 是一回事吗？

不是。Agentic AI 是宽泛类别，指目标导向、在有限逐步指令下规划和行动的 Agent。Multi-agent collaboration 是其中的一种组织形式，用角色、共享上下文和交接组织多个 Agent。单 Agent 系统可能很 agentic，多 Agent 工作流也可能很简单。

multi-agent system 之间如何通信？

通过共享记录。一个 Agent 写下草稿、来源清单或状态更新，下一个 Agent 读取它。通信渠道是团队授予两个 Agent 访问权的上下文，交接在人能看清什么移动了时是可见的。模型层面的消息和协议属于运行时细节，团队可见的契约是共享上下文和已记录的交接。

Bot 队伍和 Agent 工作区是一回事吗？

不完全是，两者围绕不同的对象组织协作。Bot 队伍把持续存在的 Bot 放在中心，团队先集齐这些 Bot 再与它们对话，工作发生在对话里。像 Syfo 这样的 Agent 工作区把工作放在中心，Channel 承载共享记录，每件任务可以有负责人和可见状态，交付物经过复核和验收。两者都能让多个具名 Agent 出现在同一共享协作空间中，区别在于持久的对象是 Bot 还是可复核的工作。