这一次，**联网**的不再是电脑，而是一群会干活的**Agent**。 它们为什么突然需要联网？因为以前我们用一个AI，更像是在各自开“单机”。Claude Code写代码，Codex跑任务，另一个Agent做调研，再来一个改文档。每个单拎出来都挺能干，但大多数时候，它们各干各的。 问题来了：一个人有一个Agent，这叫效率工具；但当一家公司里开始出现十个、一百个、甚至更多Agent时，事情就没那么简单了。它们需要一张网——能分工、能沟通、能交接、能验收，还能把每一次协作的经验沉淀下来。 这正是**明略科技**这次开源发布**Octo**的切入点。简单来说，你只需要给一个Agent下达任务，它就会自动带着其它Agent一起协作干活。Octo想做的是一个开源可信的Agent协作网络，核心就是**让人、Agent和外部工具一起进入同一套协作系统**。 这里要拆解一下Octo这个名字背后的含义：Open，开放可自部署；Context，让工作上下文在协作中流动；Taste，是把人的判断、偏好和品味留下来；Orchestration，是把人、Agent和工具编排到同一层协作里。一句话概括就是：**Agents do. Humans decide.** 这句话背后，藏着AI应用下一阶段的一个关键变化。AI不再只是在聊天框里回答问题，它开始进入组织流程，成为可以被分工、被管理、被验收的数字劳动力。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丢进去，然后让它们互相讨论。虽然这确实也是协作的一种，但远远不够。真实工作里的协作很复杂——有些任务需要大家公开讨论，有些任务需要独立完成以免互相影响；有些任务要先做再审，有些任务要按流水线交接；还有些任务，干脆让多个方案一起跑，最后挑一个最好用的。而Octo这次直接给出了**六种协作模式**。 **第一种，Solo，单人完成。** 适合边界清楚、目标明确的小任务，比如改一段文案、整理一份纪要、补一段代码注释。 **第二种，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在产品形态上覆盖了**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资产，往往不是某一次回答本身，而是回答背后的业务上下文、协作记录、偏好判断和工作方法。这些东西如果沉淀在第三方平台里，企业很难真正掌握；如果能沉淀在自己的环境里，就可能变成长期资产。 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才真的有机会从助手变成同事。