Agent之间，有互联网了！

这一次，联网的不再是电脑，而是一群会干活的Agent。

它们为什么需要联网？

因为以前我们用AI，更像是在各自开单机，Claude Code写代码，Codex跑任务，另一个Agent做调研，再来一个Agent改文档。每个都挺能干，但大多数时候，它们各干各的。

那么问题来了：

当一个人只有一个Agent，这叫效率工具；当一个公司里开始出现十个、一百个、甚至更多 Agent，事情就没那么简单了。

这时候它们就需要一张网，能分工，能沟通，能交接，能验收，还能把每一次协作里的经验沉淀下来。

而这也正是明略科技这次开源发布Octo的切入点。

像下面的例子中，你只需要给一个Agent下达任务，它就会自动带着其它Agent一起协作干活：

简单来说，Octo想做的是一个开源可信的Agent协作网络，也就是让人、Agent和外部工具一起进入同一套协作系统：

• Open，是开放和可自部署；
• Context，是让工作上下文在协作中流动；
• Taste，是把人的判断、偏好和品味留下来；
• Orchestration，是把人、Agent 和工具编排到同一层协作里。

一言蔽之，就是Agents do. Humans decide.

这句话背后，其实藏着AI应用下一阶段的一个关键变化。AI不再只是在聊天框里回答问题，它开始进入组织流程，成为可以被分工、被管理、被验收的数字劳动力。

三个核心概念：Agent需要一个真正的工位

Octo要做的第一件事，就是给Agent一个可以进入组织协作的工位。

这里面有三个核心概念，Bot、Channel/Thread、Matter。

先看Bot。

在Octo里，Agent不是一个临时调用的功能按钮，它会以Bot身份进入团队，有身份、有名片、有能力说明，也有工作记录。

一个写代码强的Bot，可能文档能力一般；另一个做调研扎实的Bot，可能更适合写行业报告。如果所有Agent都只是聊天框里的一个入口，组织就很难知道谁擅长什么、谁做过什么、谁的产出更可靠。

Bot解决的就是这个问题。

它让Agent从工具入口变成了数字同事。每个Bot有自己的AgentCard，有归属、有能力边界，也有工作履历。你可以把OpenClaw、Hermes、Codex、Claude Code、WorkBuddy等主流Agent工具接进来，让它们以Bot身份在同一个系统里被统一管理。

接下来是Channel和Thread。

Channel可以理解成项目群或工作频道。人和Bot在同一个频道里对齐意图、讨论方案、派发任务、看进展。

但它和普通群聊的差别在于，Agent并不只是被@出来回一句话。

它可以接收上下文，参与讨论，继续推进任务。Channel解决的是“在哪里协作”的问题。

Thread则是一件具体的事。

比如一个产品发布项目里，可能同时有传播方案、技术稿、官网文案、客户案例、FAQ等多个讨论。如果所有消息都堆在一个群里，很快就会被冲散。Thread的价值，就是把一件事的来龙去脉、讨论过程和最终结论留在同一个地方。

最后是Matter。

它要解决的是“怎么把聊天变成行动，怎么把行动变成交付”。

很多人用AI工具时都有过类似体验。聊的时候很顺，感觉AI已经理解了；但聊完之后，东西仍然散在对话框里。你还要自己复制、整理、建任务、催进度、看产出。

Matter的思路是，当讨论中出现需要跟进的工作，Agent可以自动总结要点，由人确认后创建成事项。

这个事项里有负责人，有交付物，有验收标准，也有从Brief、过程讨论、产出、反馈到验收结论的完整记录。

换句话说，AI干的活终于有了交付现场。

它不再只给你一段回答，还会把工作推进到可追踪、可复盘、可验收的状态。

六种协作模式：多Agent协作，不只是拉个群

现在一说多Agent，很多人脑子里会浮现一个画面。

拉个群，把几个Agent丢进去，然后让它们互相讨论。虽然这确实也是协作的一种，但远远不够。

真实工作里的协作很复杂，有些任务需要大家公开讨论，有些任务需要独立完成，避免互相影响；有些任务要先做再审，有些任务要按流水线交接；还有些任务，干脆让多个方案一起跑，最后挑一个最好用的。

而Octo这次直接给出了六种协作模式。

第一种，Solo，单人完成。

一个Bot自己完成任务，适合边界清楚、目标明确的小任务。比如改一段文案、整理一份纪要、补一段代码注释。

第二种，Roundtable，圆桌讨论。

多个Bot围绕同一个问题公开讨论，互相看得到观点。它适合头脑风暴、多角度分析、选题讨论、策略判断。比如做一个产品发布选题，可以让技术向Bot、用户向Bot、商业向Bot分别给判断，再由Leader收束。

第三种，Critic，独立审核。

一个Bot做，另一个Bot审。审核方可以打回重做。它适合那些对质量敏感的工作，比如代码审查、事实核查、方案挑错、合同风险提示。

这个模式的关键在于“做”和“审”分开。毕竟现实公司里，我们也不会让同一个人既写稿又终审。AI协作进入真实工作后，也要有类似的制衡机制。

第四种，Pipeline，流水线。

A做完交给B，B做完交给C。每一步的产出都是下一步的输入。它适合有明确先后顺序的多步任务，比如先调研，再分析，再写报告，再润色成对外稿件。

第五种，Split，分头干。

把大任务拆成几块，不同Bot并行处理，最后由Leader合并。它适合资料量大、模块相对独立的任务。

比如做一个行业研究，可以让一个Bot负责国外公司，一个Bot负责国内公司，一个Bot负责技术路线，最后统一汇总。

第六种，Swarm，竞选择优。

同一个题目发给多个Bot，各自独立完成，再选出表现更好的方案。它适合创意型任务，比如标题、视觉概念、活动策划、产品命名。

我们可以从下面这个四个Agent在一个群聊里，从找bug到上线产品的例子中，感受一下全程无人干预的情况下，Agent们的协作方式：

这六种模式合在一起，说明Octo想解决的不是让Agent聊天这么简单。

它真正处理的是组织协作里的结构问题。谁能看到什么信息，谁负责哪一步，谁来审核，谁来合并，什么情况下需要人拍板。

在以前，这些规则主要靠人来维持。到了Agent越来越多的时代，协作系统本身就要把规则写进去。

这也是Octo和传统IM工具的差异。

飞书、Slack、钉钉这样的工具，主要为人和人设计。它们擅长消息沟通、会议协同、文档流转。但当Agent也变成工作主体，系统就需要额外处理AI身份管理、AI任务追踪、AI协作模式这些新问题。

旧工具当然可以加AI能力，但如果Agent数量持续增加，只在聊天框旁边挂一个AI入口，迟早会不够用。

四个端：让OCTO出现在工作发生的地方

一个协作平台想真正被用起来，光有理念不行。它得进入人的日常工作场景。

Octo在产品形态上覆盖Web App、移动端（iOS/Android）、浏览器插件与CLI几个入口。人在哪里工作，Agent就应该在哪里出现。

Web App更像完整的协作工作台。

Channel、Matter、Bot工作记录、项目进展，都可以在这里集中管理。适合推进复杂项目，也适合管理多个Bot组成的数字团队。

移动端解决的是反馈和验收。

很多AI任务不一定需要你全程盯着，但关键节点需要你拍板。比如Bot交回一个阶段成果，你在手机上看一眼，觉得可以就通过，不行就打回补充。这类轻量判断，很适合在移动端完成。

而浏览器插件的价值不是让你把飞书文档、GitHub Issue、网页报告都搬进Octo。它要做的是在你已经工作的页面旁边，直接呼出Agent，并把当前页面上下文带进去。

比如你正在看一篇行业报告，选中一段内容，让Bot帮你总结、翻译、改写；你正在看GitHub Issue，让Bot基于当前问题拆解修复思路；你在文档里卡住了，可以直接呼出Bot帮你续写一版。

这件事的好处就是工作流不被打断。

AI工具过去常常要求用户切换窗口、复制上下文、重新描述任务。浏览器插件把这一步缩短了。你在哪儿工作，Agent就在哪儿待命。

CLI则主要面向开发者和Agent原生操作。

对开发者来说，很多任务本来就发生在终端里。通过CLI，Agent任务可以和命令行工作流接起来，尤其适合代码、自动化、运行环境相关的场景。

所以Octo的产品思路，不是让组织把现有系统全部推倒重来。它更像在文档、代码平台、项目管理工具、浏览器页面和终端之间，加了一层人和Agent共同协作的连接层。

这也解释了为什么它要强调开源和私有化部署。

对于企业来说，真正有价值的AI资产，往往不是某一次回答本身，而是回答背后的业务上下文、协作记录、偏好判断和工作方法。

这些东西如果沉淀在第三方平台里，企业很难真正掌握；如果能沉淀在自己的环境里，就可能变成长期资产。

协作方式，在Agent时代被重构

Octo背后还有一个更大的判断。

AI时代被重构的，不只是单个工具，还有协作方式。过去的组织协作，主要发生在人与人之间。未来很可能同时发生在人与人、人与Agent、Agent与Agent之间。

这会带来一个很现实的问题，也就是人到底该站在哪里？

如果把AI当成一个更聪明的搜索框，人依然要自己拆任务、组织过程、检查结果。AI只是更快给答案。

但如果把Agent当成数字劳动力，人的角色就会发生变化。

人不一定要亲自做每一步执行，却必须在关键节点给方向、定标准、做判断、看结果。

这就是“Agents do. Humans decide.”这句话的意思。

Agent负责思考、分析、生成、执行、调度；人负责判断什么是对的，什么是好的，什么是符合业务取舍的。

你发起任务，Bot推进执行；Bot交回阶段成果，你验收；不满意，打回；满意，通过；你的每一次批注、打回、偏好选择，都会继续影响Bot下一次干活。

这就形成了一个飞轮：派发任务，验收反馈，沉淀偏好与技能，下次更高效。在Octo里，每次协作会沉淀三类资产。

• Context，上下文。包括项目背景、历史决策、讨论记录。新成员或新Bot加入时，不用从零对齐。
• Taste，偏好。每次验收、打回、批注、风格选择，都在记录你和团队到底喜欢什么、认可什么、排斥什么。
• Skill，技能。比如写代码用什么规范，做报告按什么结构，复盘用什么模板。这些做事方法可以在组织内部复用。

这也是我们刚才提到的O.C.T.O.四个字母的含义，即Open、Context、Taste和Orchestration。

这四个维度串起来，Octo想做的就不只是一个AI办公工具。它更像PrivateAI时代的一层组织基础设施。

因为当AI开始真正参与工作，企业关心的也不只是“这个模型聪不聪明”。更关键的是，我的数据在哪里？我的协作经验能不能沉淀？我的组织风格会不会随着模型更换而丢失？我的Agent能不能越用越懂业务？

从这个角度看，Octo开源的意义，也不只在于让开发者多了一个项目可以试。

它代表了一个趋势，AI应用正在从“个人效率工具”往“组织协作网络”迁移。

一个强Agent，可以帮一个人提高效率。一群Agent能在同一套规则下协作，才可能改变一个组织的工作方式。

互联网让计算机彼此连接，才真正释放出网络效应。

到了Agent时代，类似的问题又出现了。当每个人、每个团队、每个业务流程里都有Agent，谁来把它们连接起来？

Octo给出的答案，是先把Agent放进组织协作里。

让它们有身份，有工位，有任务，有验收，有记录，也有逐步积累下来的偏好和技能。

说到底，Agent真正进入公司，不是因为它能在聊天框里多说几句漂亮话。

而是因为它可以把活接下来，把事往前推，把结果交回来，并且在一次次反馈里越来越懂这个组织。

当Agent不再单打独斗，AI才真的有机会从助手变成同事。

文章来自于"量子位"，作者 "金磊"。