智能体之间实现互联网连接

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

那它们具体为什么需要联网？

原因很简单。在过去，我们使用AI更像是在各自开“单机”。Claude Code写代码，Codex跑任务，另一个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给出判断，最后由人来收束。

第三种：Critic，独立审核。一个Bot负责做，另一个Bot负责审。审核方可以打回要求重做。这个模式适合那些对质量高度敏感的工作，比如代码审查、事实核查、方案挑错、合同风险提示。关键在于“做”和“审”必须分开。毕竟在现实公司里，我们也不会让同一个人既写稿又终审。AI协作进入真实工作后，也需要类似的制衡机制。

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

第五种：Split，分头干。把一个大任务拆成几块，让不同的Bot并行处理，最后再由Leader汇总。它适合资料量大、模块相对独立的任务。比如做一个行业研究，可以让一个Bot负责国外公司，一个Bot负责国内公司，一个Bot负责技术路线，最后统一汇总。

第六种：Swarm，竞选择优。同一个题目发给多个Bot，让它们各自独立完成，然后选出表现更好的方案。它比较适合创意型任务，比如想标题、设计视觉概念、策划活动、为产品命名。

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

这六种模式合在一起，说明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才真的有机会从助手变成同事。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：智能体之间实现互联网连接要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题