从单兵作战到团队协作：Octo让多个 AI 智能体真正配合工作

去年开始越来越多开发者在工作里同时用几个 AI：写代码用 Claude，润色文档用 GPT，数据分析跑一个专门的 Agent。几个 AI 各干各的，看起来效率很高，但这种并行充其量是人多力量大，离协作差得很远。一旦让多个 AI 智能体配合完成一个有前后依赖关系的任务，复杂度会跳到完全不同的量级。

多个智能体同时工作时最直接的困惑是谁能看到谁的信息。两个智能体分别写方案的前半部分和后半部分，它们需要看到对方的进展吗，还是互相看不到最后由人来合并。互相看不到怎么保证风格一致、不重复；互相看到了信息干扰怎么处理，A 看到 B 的输出后被带偏方向怎么办。

这个问题完全取决于任务性质，头脑风暴类任务需要智能体看到彼此观点来激发新思路，流水线类任务每个环节只需上游输出，多余信息反而是噪音。工程上需要可配置的可见性控制，不同任务模式用不同的信息流拓扑。大部分现有框架没有把这层抽象做出来，开发者只能自己在 prompt 里打补丁。

任务涉及多个环节时，谁把结果交给谁就变得不简单了。A 智能体生成的代码需要 B 审查，B 发现问题打回给 A 修改，A 改完再交给 B，B 通过后交给 C 写文档。这个流程需要清晰的状态机来追踪任务在哪个环节、谁持有当前版本、谁在等待输入。

传统工作流引擎处理的是人的任务，状态变化节奏慢，一个环节可能花几小时甚至几天。智能体执行速度快得多，几分钟就能跑完十几个步骤，状态变化频率远高于人工流程。多个智能体并行工作时还会出现竞态问题：两个智能体同时修改同一份文档，或基于同一份过时信息各自做出判断，结果互相矛盾。另外，传统工作流里每个节点有人确认，智能体之间如果只传递结果不做验收，低质量输出会直接流到下游，错误在链条里被放大。

大部分多 Agent 框架解决了启动多个 Agent 的问题，但没有解决怎么让它们配合，几个 Agent 同时在跑，互相之间靠什么协调？共享文件夹、消息队列、还是直接互相对话。实践中开发者手写大量胶水代码来管理 Agent 之间的交互，这些代码没有标准化，换一套任务场景就得重写。调试更是难题：多个 Agent 的输出不符合预期时，定位问题出在哪个环节非常困难，每个 Agent 的内部推理过程对外部不可见，交互日志分散在各处。

编排层需要定义不同的协作模式，几个智能体围绕一个议题各抒己见最后由人收束，这是圆桌模式；一个做完交给下一个审查，审查不过打回返工，这是审校模式；大任务拆成若干子任务分头执行最后合并结果，这是分治模式。每种模式的信息流、权限边界、验收机制都不同，不能用同一套默认行为来覆盖。

Octo 在编排层提供了六种协作模式：Solo（独立执行）、Roundtable（圆桌讨论）、Critic（审校流程）、Pipeline（流水线传递）、Split（任务分治）、Swarm（群体智能）。每种模式对应不同的信息可见性规则和状态流转机制，开发者根据任务性质选择合适的模式，不需要在所有场景下都硬编码一套协作逻辑。这个设计把编排从胶水代码变成了可配置的基础设施。

每个智能体也应该有明确的身份标识和能力边界，一个被配置为代码审查角色的智能体不应该去修改产品需求文档，一个负责数据分析的不应该有权限直接操作生产数据库。多智能体环境里权限管理比传统 IAM 复杂得多：传统系统里用户身份相对静态，角色和权限映射明确；智能体的身份可能随任务上下文变化，同一个智能体在 A 项目里是执行者，在 B 项目里是审查者，权限需要跟着场景走。

智能体代表某个团队成员执行任务时，它应该继承那个人的授权范围还是拥有独立的权限体系，这个问题现在没有行业共识，而Octo 的设计思路是让智能体作为创建者的数字劳动力分身，继承授权、带着品味替人完成工作，身份和能力边界通过 AgentCard 明确标识。

搭起几个智能体容易，让它们可靠地配合产出可追溯的结果，中间需要大量基建。信息流、权限、状态、验收、追溯，每个维度都需要仔细设计。Octo 目前已在 GitHub 全面开源（https://github.com/Mininglamp-OSS），包含服务端、Web/桌面客户端、iOS、Android、CLI 五端代码，Apache 2.0 协议。如果你在探索多智能体协作的工程化路径，可以直接拉代码跑一跑。部署文档在 octo-deployment 仓库，K8s 部署清单已经准备好。社区刚起步，觉得这个方向有价值的话给个 Star 支持一下，早期参与者的声音会直接影响产品方向。