现在很多人做AI Agent，聊起来都在说多智能体协作，打开产品一看，基本就是一个聊天框。跟Agent说句话，它回一段，再补一句，它再改改，来回几个回合，事情就算"协作"过了。这认知偏差挺大的。聊天界面本身没有问题，问题出在把聊天界面等同于协作层。人和人之间发消息也能干活，但真到了多步骤、多角色、有验收标准的工作场景，没人会靠群聊把一个项目从头到尾管完，协作工具里得有任务、有文档、有审批流。AI Agent也一样。

把两个大模型丢进同一个对话窗口，让它们自由聊天，期待它们自己把活分好、干好、交付好，这件事的成功率跟在大群里@所有人说"大家看着办吧"差不多。每个Agent都能看到所有消息，谁该干什么没人管，干到哪一步了没人追踪，最后谁来验收也没个说法。信息全部平摊在一个频道里，对人来说叫刷屏，对Agent来说叫上下文污染，token烧得飞快，有用的信号被稀释在几十轮无关对话里。

最早做Octo的时候，我们也试过把协作理解成"让多个Agent在一个房间里聊"。很快就发现根本跑不通实际任务。写一份技术报告，研究员Agent和写作者Agent在同一个对话里同时输出，研究员还在查资料，写作者已经开始编数据了，两边产出互相干扰，最后出来的东西反倒成了四不像。代码review场景更难搞，开发者Agent写完代码直接扔在对话里，reviewer Agent和开发者能互相看到对方的每一步思考，reviewer会被开发者的思路带偏，该挑的毛病挑不出来。这跟人做code review是一个道理，站在写代码的人旁边看着他一行行写，很难保持独立判断。

信息可见性是多Agent协作里一个被严重忽视的设计维度。群聊天然假设所有人看到所有信息，这是为人的社交场景设计的，但协作场景需要的是精确控制谁在什么时候看到什么。

Octo把这个拆成了六种编排模式，每种模式对应不同的信息拓扑。Roundtable是圆桌模式，所有参与者互相可见，适合头脑风暴和多角度讨论，大家各抒己见最后收束。Critic模式下做的人和审的人互相看不到过程，只交付结果，做的人把活交出来，审的人独立给反馈，避免互相影响判断，代码review、设计稿走查这类需要独立视角的场景就该用这个。Pipeline是流水线，每个Agent只看到上一步的产出，做完传给下一个，类似编译链路，适合有明确先后依赖的多步任务。Split模式把大任务拆开分给不同Agent并行去干，彼此看不到，最后合并结果，写一份市场报告可以让几个人各写一个章节再拼起来。Swarm是同题竞作，几个Agent拿到同一个题目各做各的，最后选最好的那个方案，创意类任务特别好用，比如起名字、想slogan、写多个版本的文案。Solo就简单了，一个Agent搞定的事。

这么罗列，听着像把简单的事情搞复杂了，公司里干活，脑暴会、流水线生产、独立审稿、并行分工、竞稿比稿，这些模式本来就存在，只是协作工具从来没有把这些模式显式地建模给AI用。以前没有AI，人自己知道什么场景该怎么协作，工具只要提供一个聊天框加文档就够了。现在Agent要进场干活，不给它明确的协作结构，它就只能在聊天框里瞎聊，聊到哪算哪。

聊天框解决的是沟通问题，沟通之后还需要一整层执行能力把事情落地。任务从哪里创建，创建之后怎么派给合适的Agent，Agent干完了怎么交付，交付物挂在哪里，谁来验收，验收不通过怎么打回，打回之后的反馈怎么让Agent下次记住，这些事情在纯Chat界面里全部是缺失的。或许可以让Agent在聊天里自己管理这些，那相当于让每个程序员自己手写项目管理系统，能跑但绝不优雅，而且每个Agent都要重复造一遍轮子。

回路是从对话里自然长出来的工作单元，在群里说一声要干个什么事，系统就能把它变成一个有负责人、有交付物、有验收标准的回路，而不是让这句话淹没在聊天记录里。负责人可以是人也可以是智能体。交付物不管是代码、文档还是报告，都挂在回路下面，一年后回来看也清楚当时干了什么、为什么这么干。验收环节是特别在意的一件事，AI干的活不能交了就算完，必须有人或者有另一个Agent来验收，满意了就过，不满意就打回，打回的理由不是一句"不好重做"就完事，而是要沉淀成经验，下次这个Agent再接类似的活就能自动参考。

说到经验这件事，现在绝大多数Agent框架都没正经做这个。今天让一个Agent写份报告，告诉它"标题不用感叹号"，明天换个对话窗口它又忘了，下次还得再说一遍。每次都从零开始教，手停口停，跟招了一个没有记忆的实习生一样。Octo里的经验系统就是为了解决这个问题，每次验收打回、每次说"我更喜欢这样"，都被沉淀成经验卡片，Agent下次接活会自动检索相关经验参考。这东西短期看不太出来差异，用三个月之后，Agent会比刚接入时更懂团队的品味和要求，这个差距是用出来的，不是prompt调出来的。

编排模式决定信息怎么流，回路负责把事情干完，经验负责让Agent越用越懂你，这三层叠在一起才勉强算一个能跑实战的多Agent协作系统。光有聊天框，就像给一群人发了通讯工具但不给办公空间、不给项目管理工具、不给文档系统、不给考核机制，大家确实能"沟通"，但干活效率可想而知。

还有一个很少被讨论的问题是Agent的身份和路由。多Agent协作到了一定规模，不可能每次都手动指定"这个任务让写代码的Agent去干，那个任务让写文档的Agent去"。Agent得有自己的名片，标明它擅长什么、跑在什么运行时上、之前干过什么活、表现如何。领队Agent需要能感知到其他Agent的能力，自动把子任务路由给最合适的那个。Octo里的AgentCard和A2A路由就是在做这件事，目前还在早期阶段，但方向很明确，协作规模上去之后没有自动路由根本管不过来。

关于运行时也说几句。现在很多多Agent框架默认所有Agent跑在同一个云端环境里，用同一家的模型。实际用起来完全不够，有的Agent需要跑在本地因为要操作电脑上的文件，有的Agent需要用长文能力强的模型，有的Agent适合用小模型因为任务简单响应要快，还有的团队会自己微调模型。Octo的做法是不管Agent跑在哪里，本地CLI也好云端也好，只要注册上来就能被编排调度，平台只管"它是谁、能干什么、干了什么"，不管它"怎么跑的"。

有人会问，就一个Agent帮着写写邮件回回消息，需要这么复杂吗。确实不需要，Solo模式就是干这个的，简单任务一个Agent搞定就完事了。但如果在认真考虑让AI Agent团队化地干活，比如一个Agent负责调研、一个负责写代码、一个负责测试、一个负责写文档，它们之间有依赖关系、有质量要求、有知识沉淀的需求，那纯Chat的协作方式撑不了几个回合就会乱套。多Agent协作跟分布式系统有很多相似之处，可以从简单开始，但消息路由、状态管理、故障恢复、负载均衡这些基础设施问题迟早要面对，晚面对不如早面对。

开源社区里也能看到很多多Agent框架，大部分停留在"让多个Agent聊起来"这个阶段，做几个demo看着很炫，真拿去跑实际任务就各种问题。Octo目前团队内部已经在日常使用了，回路工作台、项目管理、自动化流水线、搜索这些模块已经上线在跑，智能体管理和运行时注册本月上线，经验系统和A2A路由也在迭代中。项目开源在  GitHub - Mininglamp-OSS/octo-server: 🐙 The Go backend powering OCTO — an open workplace built for humans × AI agents. REST & WebSocket APIs, Lobster (AI agent) orchestration, and WuKongIM real-time messaging control plane. · GitHub，感兴趣可以拉下来试试，也欢迎提issue和PR。

如果正在做多Agent相关的产品或者在评估多Agent框架，建议先想清楚一件事，Agent是在聊天还是在干活。如果只是聊天，一个对话框够了。如果要干活，任务追踪、交付物管理、验收机制、经验沉淀、信息可见性控制、自动路由，这些东西没有一个是聊天框本身能提供的。刚开始搭多Agent系统的时候，可以从最简单的Chat开始跑通demo，但要尽早把执行层和编排层补上，不然demo永远是demo。