从「单一 Agent」到「一张组织网络」在历史长河中技术发展鲜少呈线性推进诸多关键变化往往发生于「连接」被打通的瞬间。以计算机为例20 世纪 60 年代它们虽已具备强大计算能力却大多为各自封闭运行的系统因架构不同、接口不通彼此难以真正相连。直至 ARPANET阿帕网出现这种孤岛状态才得以打破计算机首次在真正意义上实现连接开始共享信息、建立联系。如今以龙虾为代表的 Agent正面临半个多世纪前 IBM System/360 等大型机所遭遇的困境单体能力足够强大但系统仍处于分散状态。长期以来AI 行业将大量精力投入到相同事务中强化单个模型、打磨单个 Agent。然而如今这条路已接近阶段性拐点在多数实际工作场景中Bot 助手的能力已非主要问题。作为单体 AI它们足够强大能够轻松应对 IM即时通信交互、写代码、做调研、推进任务等工作。真正制约效率的是它们彼此之间「接不上」。Agent 被困于各自的工作流中由于运行在不同工具、上下文和权限体系里各干各的彼此看不见、调不动无法形成连续任务链条。它们虽能各自完成一段工作却难以共同完成一件事情。一个人 一个 AI 助手本质上只是效率工具只有当一群人和一群 AI 助手能够在同一体系中协同工作才开始趋近一种新的组织形态。对于 Agent 而言除了变得更加聪明还需找到属于自己的「互联网」就像当年的计算机一样。在此背景下一个以人与 AI Agent 协作为基础、面向企业组织场景的开源平台 Octo 应运而生。该平台由全球 Agentic AI 第一股明略科技打造其核心任务是将分散在各个工作流里的 Bot 聚合到同一协作空间。更为重要的是这种连接并非仅局限于个人维度。在 Octo 中Bot 既是个人助手经授权后也能在组织成员之间共享和调用。Bot 大军的自由流动使 Agent 的身份发生转变从个人工具蜕变为企业级资产和数字员工。随着 Bot 以组织形式部署、使用并沉淀它们不再各自为战而是通过分工协作在任务之间流转在过程中接收持续的反馈与评价并进行修正。更进一步在 Agent 等数字劳动力爆发的当下明略科技欲将 Octo 平台打造成为 Private AI 时代的组织基础设施构建人和 AI 协作的新范式。当企业拥有成百上千的 Agent 时Octo 能够像管理互联网节点一样实现它们之间、它们与创建者之间以及创建者与创建者之间的高效连接、通信与协作。每个 Agent 既各司其职又相互协作这种工作模式在大多数场景中优于单一巨型模型。对普通用户而言Octo 的一大优势在于常见的工作场景被打包成现成的 Bot 模板用户无需从头配置「领养」后即可直接拉进群里开展工作。在这里用户无需考虑繁琐的装虾流程易用性极高。Agent不应只「活」在对话框里目前大多数 Bot 助手依托 Discord、Telegram、飞书、钉钉等 IM 平台通过消息接收指令、执行任务。Octo 同样从 IM 形态切入但它并非仅仅是一个更聪明的聊天工具更重要的是对协作本身进行重写。在这里IM 更像是入口而非核心。在 Octo 的 IM 界面人和 Agent 虽在同一界面沟通、下达任务、接收结果但真正发生变化的是背后的连接结构。在传统工具中人和 AI 往往是一对一的关系用户下达指令AI 完成任务整个过程封闭在各自的工作流里。如今Octo 打破了这层关系试图连接人、Bot、Runtime Agent 和工具这些原本分散的节点。这使得 Octo 不仅仅是多了一个聊天窗口更关键的是它搭建了一套新的协作方式任务由人发起由 Bot 调用 Runtime Agent 完成执行。执行过程不断被反馈其他 Bot 接力人在关键节点进行判断和取舍。更有意思的是在 Octo 的底层通信协议里人和 Agent 从一开始就被设计为同等身份的消息主体。Bot 之间可以直接对话互相补充一只负责搜集信息一只负责分析一只负责纠错最后交给人来品鉴。这便是 A2A 协作真正发生的地方并非人指挥 AI、AI 反馈人的单向循环而是多个 Agent 之间形成了真实的任务接力。在这个过程中人的角色也发生了转变。复杂任务可以整包交出去Bot 负责拆解、调度、推进并实时反馈进度判断是否需要人类或其他 Bot 介入、从哪里接手。人退到关键节点进行判断和取舍而非紧盯每一步。当 Agent 从各自孤立的工作流中走出来效率提升只是表层变化。更深层次的影响是组织处理复杂任务的方式本身开始被重新组织。然而连接只是第一步。将 Agent 拉到同一空间仅解决了「能不能看见彼此」的问题。真正进入企业场景后更具挑战性的是另一件事复杂任务往往不会在一次对话中结束而是会经历需求澄清、资料补充、方案生成、多人反馈、反复修改和最终验收等过程在此过程中信息和判断都在不断变化。因此在 IM 之外Octo 需要进一步下沉为每一件复杂任务建立稳定的承载单元即接下来要介绍的 Matter事项。从「连接」到「干活」将复杂任务拉进事项里复杂、长程任务需要解决以下问题事情如何干成、如何干对、如何留存这正是 Matter 要解决的问题。在普通 IM 中信息易被滚动消息淹没。今日讨论的方案明日可能就被新消息刷屏。一周后若想追溯当时选择 A、放弃 B 的原因只能在聊天记录里大海捞针。对于复杂任务而言这种信息形态远远不够。针对这一局限Matter 把每个任务沉淀成一张可追溯的「决策卡」不仅记录最终结果还包括任务缘起Brief、过程时间线Timeline、关键产出、人的反馈和验收结论。一个事项从 Brief 开始沿着 Timeline 展开中间有产出、有打回、有补充、有确认最后形成可以回看的组织记忆。这对企业至关重要。在实际工作中很多价值并非仅存在于最终文档里。选择一个方案的原因哪些判断来自业务负责人哪些修改来自法务、销售或技术同学这些信息共同构成了组织的决策资产。以保存消息为主要目标的普通 IM 工具难以承载这些资产而 Matter 要保存的是一件事如何被推进、修正和完成。除了保存过程Matter 更重要的价值在于复杂任务里的每一次修改、打回和验收都蕴含着人的判断。一旦这类反馈进入 Matter它们便从一次性的沟通记录转变成了 Agent 学习组织偏好的原材料。Octo 所追求的 Taste也正是在这个位置生长出来。越用越懂你在实战中沉淀 TasteMatter 解决了「事情如何留存」的问题而 Taste 则让「Agent 越用越懂你」。如今许多 Agent 都有自己的配置文件、工具说明和角色设定但它们的自我成长仍然有限。一个团队喜欢的风格、什么样的结论才算有洞察这些偏好很难通过一次系统提示清晰表达。很多时候人类的判断是隐性的。例如负责人说「这个感觉不对」客户说「这个角度不准」这些反馈背后的经验、品味和行业语境不一定能立即转化为一套规则。因此「偏好对齐必须在实战中完成」成为 Octo 塑造 Taste 所采取的思路。人的每一次打回、圈一笔、修改、确认都可成为 Bot 学习组织品味的素材。一次方案退回可能是逻辑不够收束一次报告重写可能是结论缺少业务视角。这些信号沉淀到 Matter 之后就有机会被提炼成下一次可复用的偏好。这个过程可以理解为人把说不清的「我就要这个」逐渐沉淀为 Agent 可以理解、调用与继承的偏好。下次遇到类似任务相关偏好会自动进入上下文。这样一来Bot 会在一次次实战中更接近团队的做事方式并理解公司的决策、交付模式。当 Bot 拥有了差异化的偏好多 Agent 协作的关键就变成了「如何让它们在同一任务中合理分工」避免简单地将它们拉进同一个群聊里一起发言。Octo 的六种协作模式正是为解决这一问题而设计。六种协作模式本质是六种信息拓扑多个 Agent 一起协作并非简单地「多叫几个 Bot 进群」。更细化的问题决定了执行效果例如信息如何传递谁负责生成谁负责验证哪些任务需要独立视角哪些任务需要公开讨论哪些步骤必须按顺序进行哪些任务可以分头推进面对不同层次的需求Octo 将复杂协作拆分为六种模式Solo 是单干模式适合简单明确的任务由领队独自完成。Roundtable 是圆桌讨论在领队主持下多个 Agent 围绕同一议题展开公开讨论参与者互相可见适合需要形成共识、碰撞观点、收束结论的任务。Critic 是生成 — 验证模式其中一个 Agent 负责生成另一个 Agent 负责审核生成方和验证方必须不同。验证方有否决权发现问题可以打回重做。该模式适合需要独立审查的场景如代码检查、事实核查、方案质检。Pipeline 是流水线模式从 A 到 B 到 C 严格串行每一步的产出作为下一步的输入。它适合存在明确顺序依赖的任务如先调研再分析再写作再校对。Split 是分头干模式领队把任务拆成互不可见的子块由多个 Agent 各自处理最后再由领队合并。它适合大任务分治如将一个行业报告拆成政策、市场、技术、案例几个部分。Swarm 是撒网竞选模式同一个任务交给多个 Agent 独立完成参与者彼此互盲最后由领队择优。它适合需要多解并行、避免从众的场景如标题、方案创意、产品命名、不同分析路径。整体来看Octo 多协作模型不仅将 Bot 聚集到同一地方还规定了信息流转的方式不同任务匹配不同拓扑系统保证信息沿正确路径流动。相比之下飞书或 Slack 群聊里的 AI 虽能让所有人看到所有消息但复杂任务往往需要更精细的隔离。群聊擅长「都看见」却难以做到「该互见时互见该互盲时互盲」。换句话说Octo 对协作的理解已超越「多人聊天」这一层面。在真实组织中协作包括空间划分、权限边界、上下文继承、过程追踪、任务拆解、反馈沉淀和最终验收。人类过去依赖项目管理系统、知识库、IM、文档和会议来完成这些工作Agent 加入后这套协作骨架也随之改变。拆开来看Octo 在做四件事从产品形态看Octo 正让 Agent 像组织成员一样融入工作流用 IM 承载交互用空间、分组、频道、子区搭建协作结构用语音提升输入效率用浏览器插件接入外部工具再用 group.md 约束协作方式。结构层空间Space、分类Category、频道Channel和话题Thread将协作关系组织得清晰明了。在 Octo 里一项任务通常在某个空间里被提出可能是一个简单的问题也可能是一段更完整的描述。无论形式如何这条信息一出现就带有明确的上下文属于哪个空间面向目标的工作区在哪个频道可理解为群聊话题是什么可理解为群聊子区。与普通聊天不同新消息不会很快被冲掉自然地落在某个频道或话题里成为一件可以一直跟进、随时回溯的事情。入口层在 IM 界面私聊和语音让我们进入这套系统的方式变得更简单。通过人与人、人与分身的一对一对话通道私聊可让人与 Agent 在同一上下文中沟通、分工、反馈无需额外学习新的交互方式就能将任务放入、结果取出。然而当协作变复杂时问题可能出现在输入环节。很多时候并非 Agent 做不出而是人来不及把需求讲清楚。输入慢导致整个流程变慢。引入语音后信息能更快进入系统任务描述、上下文补充和决策反馈都更便捷。Octo 内置的语音输入不仅将声音转成文字还是一个持续进化和学习的系统。它会结合当前对话的上下文对转写的内容进行修正和梳理提高准确率使表达更清晰、更有逻辑。同时对于团队中的人名、公司名或者行业专有名词出现频率越高它认得越准。此外用户还可以语音 他人、修改已有内容甚至删掉前面的输入。在这里语音接近一种可参与操作的交互方式。从能力上看这套机制与市面上一些语音驱动操作的产品相似但它直接嵌在整个协作流程里随任务一起推进。环境接入层更像是一个「上下文桥接器」。这一层并非取代工具而是将已有工具接入。通过内置的浏览器插件用户可以通过「Cmd K」将外部工具无缝接入。无论是在网页、文档还是代码平台上只要选中一段内容当前页面的链接、标题和选中文本就会自动带入上下文。将这些信息一键发送给 Bot 或者在当前对话引用后它们立即接手并知晓用户在处理什么问题、处于什么环境。它无需将用户从现有工具流中「拉走」在旁参与协作即可。真正的分水岭在大多数团队里难的不仅是把事情做完让 AI「行为可控」同样重要。GROUP.md 的作用正体现在此。它相当于一份专门为 Bot 设定的「行为准则」明确了一个群聊的定位、协作模式和行为边界。每一次对话、每一条任务指令所有参与的 Bot 都会在遵守 GROUP.md 规则的前提下执行确保讨论高效且有序。并且当切换到另一套 GROUP.md 时同一只 Bot 会马上调整工作模式「进什么庙念什么经」绝不逾矩。此外Octo 还强调多端补全Web、移动端、浏览器插件、CLI 共同构成入口。尤其是 CLI它连接端侧环境和私有化部署叙事让本地模型、本地文件、本地运行环境进入协作体系。O.C.T.O.四个维度缺一不可至此Octo 的产品能力较为清晰它们分别对应名字背后的四个维度Open、Context、Taste 与 Orchestration。O 是「Open」代表开放生态。不同 Runtime 的 Agent包括 OpenClaw、Codex、Claude Code、Cursor 等都能够以 Bot 身份接入获得统一身份。C 是「Context」代表共享上下文。IM 中的讨论收敛为结构化知识项目上下文在不同 Agent 之间共享任务过程也可被持续追溯。T 是「Taste」代表偏好进化。实战反馈沉淀为偏好每个 Agent 背后主人的品味和判断方式被结构化留存与调用。O 是「Orchestration」代表多 Agent 编排。六种协作模式对应六种信息拓扑不同 Bot 带着不同偏好参与同一任务合力完成复杂工作。这四个维度相互关联构成了 Octo 所提供的完整能力。承载起 Context、Taste、Orchestration 的共同基座正是 Matter它成为复杂任务得以被理解、反馈、校准和编排的核心容器。没有 MatterContext 会散落在聊天记录里Taste 会缺少来自真实任务的反馈来源多 Agent 编排也难以留下可追溯的过程和结果。Octo 想要把一次次协作转化为组织资产就必须先让每一件事有稳定的结构、完整的过程以及可以沉淀的判断。从这个视角来看Octo 想争夺的是企业在 Agent 时代最关键的一类资产自己的上下文、判断标准以及做事方法。写在最后像 Octo 这样的尝试不仅弥补了将 Agent 连接在一起的能力也在悄然改变组织内部知识流动和协作的方式。但这并未走向另一个极端。人不可替代的部分包括 Taste、暗默知识、判断力依然保留在个体身上只是通过协作过程得到进一步彰显和传递即「能力可以共享但判断不会被抹平」。这也引出了一个更根本的问题在 AI 时代企业真正的长期竞争力究竟来自哪里当模型能力快速趋同长期竞争力更多来自企业自己的 Context、Taste 和 Skill。这些东西无法被复制也不应流失它们才是组织在 AI 协作中真正的「护城河」。正因如此当 Agent 真正融入组织运转数据主权问题变得无法回避这些上下文、判断信号与执行记录究竟归谁所有、留在哪里、由谁控制Octo 给出的答案很明确走私有化路径通过开源开放支持本地部署。在实现上Octo 以 CLI 接入的方式将端侧模型与本地环境接入工作流中产生的上下文、决策过程与执行结果同样留在端侧沉淀为组织可以掌控的资产。这意味着包括聊天数据、协作产出、Bot 记忆在内每条对话、每行代码都保留在用户的环境中完全运行在自己的服务器上。所有这些都将成为企业独享的 AI 资产。在 Octo 的产品哲学中「Context」与「Taste」是两大核心前者是 AI 理解任务的土壤后者是持续校准方向的罗盘。Octo 并非将人的隐性能力蒸馏为平台资产而是在尊重数据边界的前提下让这些能力得到放大、记录与传承。这与明略科技长期坚持的可信 AI 方向高度一致。明略科技持续构建面向端侧智能、私有化部署与人机协作的新一代 AI 基础设施能力可以流动但数据不外流协作可以展开但控制权留在组织内部。对企业而言Private AI 不只是本地化部署更是数据主权、知识主权与协作主权的真正回归。对个人而言真正被放大的价值是 Taste—— 我品故我在当 AI 逐步接管思考人的判断力、鉴赏力与创造力不会被取代反而成为存在的意义本身。支撑这一切的底座是 Trustworthy AI开源、白盒、可审计。只有当 AI 的能力来源、运行过程和协作边界足够透明人才放心将「思」交给它们把「品」留在自己手里。Octo 的探索尚处于早期但轮廓已清晰当 Agent 更深入地嵌入分工体系真正决定效率的是那些无法被标准化、也不应被外流的东西 —— 组织自己的上下文和人自己的判断。
明略科技 Octo 平台：打破 Agent 协作困境，构建人和 AI 协作新范式
从「单一 Agent」到「一张组织网络」在历史长河中技术发展鲜少呈线性推进诸多关键变化往往发生于「连接」被打通的瞬间。以计算机为例20 世纪 60 年代它们虽已具备强大计算能力却大多为各自封闭运行的系统因架构不同、接口不通彼此难以真正相连。直至 ARPANET阿帕网出现这种孤岛状态才得以打破计算机首次在真正意义上实现连接开始共享信息、建立联系。如今以龙虾为代表的 Agent正面临半个多世纪前 IBM System/360 等大型机所遭遇的困境单体能力足够强大但系统仍处于分散状态。长期以来AI 行业将大量精力投入到相同事务中强化单个模型、打磨单个 Agent。然而如今这条路已接近阶段性拐点在多数实际工作场景中Bot 助手的能力已非主要问题。作为单体 AI它们足够强大能够轻松应对 IM即时通信交互、写代码、做调研、推进任务等工作。真正制约效率的是它们彼此之间「接不上」。Agent 被困于各自的工作流中由于运行在不同工具、上下文和权限体系里各干各的彼此看不见、调不动无法形成连续任务链条。它们虽能各自完成一段工作却难以共同完成一件事情。一个人 一个 AI 助手本质上只是效率工具只有当一群人和一群 AI 助手能够在同一体系中协同工作才开始趋近一种新的组织形态。对于 Agent 而言除了变得更加聪明还需找到属于自己的「互联网」就像当年的计算机一样。在此背景下一个以人与 AI Agent 协作为基础、面向企业组织场景的开源平台 Octo 应运而生。该平台由全球 Agentic AI 第一股明略科技打造其核心任务是将分散在各个工作流里的 Bot 聚合到同一协作空间。更为重要的是这种连接并非仅局限于个人维度。在 Octo 中Bot 既是个人助手经授权后也能在组织成员之间共享和调用。Bot 大军的自由流动使 Agent 的身份发生转变从个人工具蜕变为企业级资产和数字员工。随着 Bot 以组织形式部署、使用并沉淀它们不再各自为战而是通过分工协作在任务之间流转在过程中接收持续的反馈与评价并进行修正。更进一步在 Agent 等数字劳动力爆发的当下明略科技欲将 Octo 平台打造成为 Private AI 时代的组织基础设施构建人和 AI 协作的新范式。当企业拥有成百上千的 Agent 时Octo 能够像管理互联网节点一样实现它们之间、它们与创建者之间以及创建者与创建者之间的高效连接、通信与协作。每个 Agent 既各司其职又相互协作这种工作模式在大多数场景中优于单一巨型模型。对普通用户而言Octo 的一大优势在于常见的工作场景被打包成现成的 Bot 模板用户无需从头配置「领养」后即可直接拉进群里开展工作。在这里用户无需考虑繁琐的装虾流程易用性极高。Agent不应只「活」在对话框里目前大多数 Bot 助手依托 Discord、Telegram、飞书、钉钉等 IM 平台通过消息接收指令、执行任务。Octo 同样从 IM 形态切入但它并非仅仅是一个更聪明的聊天工具更重要的是对协作本身进行重写。在这里IM 更像是入口而非核心。在 Octo 的 IM 界面人和 Agent 虽在同一界面沟通、下达任务、接收结果但真正发生变化的是背后的连接结构。在传统工具中人和 AI 往往是一对一的关系用户下达指令AI 完成任务整个过程封闭在各自的工作流里。如今Octo 打破了这层关系试图连接人、Bot、Runtime Agent 和工具这些原本分散的节点。这使得 Octo 不仅仅是多了一个聊天窗口更关键的是它搭建了一套新的协作方式任务由人发起由 Bot 调用 Runtime Agent 完成执行。执行过程不断被反馈其他 Bot 接力人在关键节点进行判断和取舍。更有意思的是在 Octo 的底层通信协议里人和 Agent 从一开始就被设计为同等身份的消息主体。Bot 之间可以直接对话互相补充一只负责搜集信息一只负责分析一只负责纠错最后交给人来品鉴。这便是 A2A 协作真正发生的地方并非人指挥 AI、AI 反馈人的单向循环而是多个 Agent 之间形成了真实的任务接力。在这个过程中人的角色也发生了转变。复杂任务可以整包交出去Bot 负责拆解、调度、推进并实时反馈进度判断是否需要人类或其他 Bot 介入、从哪里接手。人退到关键节点进行判断和取舍而非紧盯每一步。当 Agent 从各自孤立的工作流中走出来效率提升只是表层变化。更深层次的影响是组织处理复杂任务的方式本身开始被重新组织。然而连接只是第一步。将 Agent 拉到同一空间仅解决了「能不能看见彼此」的问题。真正进入企业场景后更具挑战性的是另一件事复杂任务往往不会在一次对话中结束而是会经历需求澄清、资料补充、方案生成、多人反馈、反复修改和最终验收等过程在此过程中信息和判断都在不断变化。因此在 IM 之外Octo 需要进一步下沉为每一件复杂任务建立稳定的承载单元即接下来要介绍的 Matter事项。从「连接」到「干活」将复杂任务拉进事项里复杂、长程任务需要解决以下问题事情如何干成、如何干对、如何留存这正是 Matter 要解决的问题。在普通 IM 中信息易被滚动消息淹没。今日讨论的方案明日可能就被新消息刷屏。一周后若想追溯当时选择 A、放弃 B 的原因只能在聊天记录里大海捞针。对于复杂任务而言这种信息形态远远不够。针对这一局限Matter 把每个任务沉淀成一张可追溯的「决策卡」不仅记录最终结果还包括任务缘起Brief、过程时间线Timeline、关键产出、人的反馈和验收结论。一个事项从 Brief 开始沿着 Timeline 展开中间有产出、有打回、有补充、有确认最后形成可以回看的组织记忆。这对企业至关重要。在实际工作中很多价值并非仅存在于最终文档里。选择一个方案的原因哪些判断来自业务负责人哪些修改来自法务、销售或技术同学这些信息共同构成了组织的决策资产。以保存消息为主要目标的普通 IM 工具难以承载这些资产而 Matter 要保存的是一件事如何被推进、修正和完成。除了保存过程Matter 更重要的价值在于复杂任务里的每一次修改、打回和验收都蕴含着人的判断。一旦这类反馈进入 Matter它们便从一次性的沟通记录转变成了 Agent 学习组织偏好的原材料。Octo 所追求的 Taste也正是在这个位置生长出来。越用越懂你在实战中沉淀 TasteMatter 解决了「事情如何留存」的问题而 Taste 则让「Agent 越用越懂你」。如今许多 Agent 都有自己的配置文件、工具说明和角色设定但它们的自我成长仍然有限。一个团队喜欢的风格、什么样的结论才算有洞察这些偏好很难通过一次系统提示清晰表达。很多时候人类的判断是隐性的。例如负责人说「这个感觉不对」客户说「这个角度不准」这些反馈背后的经验、品味和行业语境不一定能立即转化为一套规则。因此「偏好对齐必须在实战中完成」成为 Octo 塑造 Taste 所采取的思路。人的每一次打回、圈一笔、修改、确认都可成为 Bot 学习组织品味的素材。一次方案退回可能是逻辑不够收束一次报告重写可能是结论缺少业务视角。这些信号沉淀到 Matter 之后就有机会被提炼成下一次可复用的偏好。这个过程可以理解为人把说不清的「我就要这个」逐渐沉淀为 Agent 可以理解、调用与继承的偏好。下次遇到类似任务相关偏好会自动进入上下文。这样一来Bot 会在一次次实战中更接近团队的做事方式并理解公司的决策、交付模式。当 Bot 拥有了差异化的偏好多 Agent 协作的关键就变成了「如何让它们在同一任务中合理分工」避免简单地将它们拉进同一个群聊里一起发言。Octo 的六种协作模式正是为解决这一问题而设计。六种协作模式本质是六种信息拓扑多个 Agent 一起协作并非简单地「多叫几个 Bot 进群」。更细化的问题决定了执行效果例如信息如何传递谁负责生成谁负责验证哪些任务需要独立视角哪些任务需要公开讨论哪些步骤必须按顺序进行哪些任务可以分头推进面对不同层次的需求Octo 将复杂协作拆分为六种模式Solo 是单干模式适合简单明确的任务由领队独自完成。Roundtable 是圆桌讨论在领队主持下多个 Agent 围绕同一议题展开公开讨论参与者互相可见适合需要形成共识、碰撞观点、收束结论的任务。Critic 是生成 — 验证模式其中一个 Agent 负责生成另一个 Agent 负责审核生成方和验证方必须不同。验证方有否决权发现问题可以打回重做。该模式适合需要独立审查的场景如代码检查、事实核查、方案质检。Pipeline 是流水线模式从 A 到 B 到 C 严格串行每一步的产出作为下一步的输入。它适合存在明确顺序依赖的任务如先调研再分析再写作再校对。Split 是分头干模式领队把任务拆成互不可见的子块由多个 Agent 各自处理最后再由领队合并。它适合大任务分治如将一个行业报告拆成政策、市场、技术、案例几个部分。Swarm 是撒网竞选模式同一个任务交给多个 Agent 独立完成参与者彼此互盲最后由领队择优。它适合需要多解并行、避免从众的场景如标题、方案创意、产品命名、不同分析路径。整体来看Octo 多协作模型不仅将 Bot 聚集到同一地方还规定了信息流转的方式不同任务匹配不同拓扑系统保证信息沿正确路径流动。相比之下飞书或 Slack 群聊里的 AI 虽能让所有人看到所有消息但复杂任务往往需要更精细的隔离。群聊擅长「都看见」却难以做到「该互见时互见该互盲时互盲」。换句话说Octo 对协作的理解已超越「多人聊天」这一层面。在真实组织中协作包括空间划分、权限边界、上下文继承、过程追踪、任务拆解、反馈沉淀和最终验收。人类过去依赖项目管理系统、知识库、IM、文档和会议来完成这些工作Agent 加入后这套协作骨架也随之改变。拆开来看Octo 在做四件事从产品形态看Octo 正让 Agent 像组织成员一样融入工作流用 IM 承载交互用空间、分组、频道、子区搭建协作结构用语音提升输入效率用浏览器插件接入外部工具再用 group.md 约束协作方式。结构层空间Space、分类Category、频道Channel和话题Thread将协作关系组织得清晰明了。在 Octo 里一项任务通常在某个空间里被提出可能是一个简单的问题也可能是一段更完整的描述。无论形式如何这条信息一出现就带有明确的上下文属于哪个空间面向目标的工作区在哪个频道可理解为群聊话题是什么可理解为群聊子区。与普通聊天不同新消息不会很快被冲掉自然地落在某个频道或话题里成为一件可以一直跟进、随时回溯的事情。入口层在 IM 界面私聊和语音让我们进入这套系统的方式变得更简单。通过人与人、人与分身的一对一对话通道私聊可让人与 Agent 在同一上下文中沟通、分工、反馈无需额外学习新的交互方式就能将任务放入、结果取出。然而当协作变复杂时问题可能出现在输入环节。很多时候并非 Agent 做不出而是人来不及把需求讲清楚。输入慢导致整个流程变慢。引入语音后信息能更快进入系统任务描述、上下文补充和决策反馈都更便捷。Octo 内置的语音输入不仅将声音转成文字还是一个持续进化和学习的系统。它会结合当前对话的上下文对转写的内容进行修正和梳理提高准确率使表达更清晰、更有逻辑。同时对于团队中的人名、公司名或者行业专有名词出现频率越高它认得越准。此外用户还可以语音 他人、修改已有内容甚至删掉前面的输入。在这里语音接近一种可参与操作的交互方式。从能力上看这套机制与市面上一些语音驱动操作的产品相似但它直接嵌在整个协作流程里随任务一起推进。环境接入层更像是一个「上下文桥接器」。这一层并非取代工具而是将已有工具接入。通过内置的浏览器插件用户可以通过「Cmd K」将外部工具无缝接入。无论是在网页、文档还是代码平台上只要选中一段内容当前页面的链接、标题和选中文本就会自动带入上下文。将这些信息一键发送给 Bot 或者在当前对话引用后它们立即接手并知晓用户在处理什么问题、处于什么环境。它无需将用户从现有工具流中「拉走」在旁参与协作即可。真正的分水岭在大多数团队里难的不仅是把事情做完让 AI「行为可控」同样重要。GROUP.md 的作用正体现在此。它相当于一份专门为 Bot 设定的「行为准则」明确了一个群聊的定位、协作模式和行为边界。每一次对话、每一条任务指令所有参与的 Bot 都会在遵守 GROUP.md 规则的前提下执行确保讨论高效且有序。并且当切换到另一套 GROUP.md 时同一只 Bot 会马上调整工作模式「进什么庙念什么经」绝不逾矩。此外Octo 还强调多端补全Web、移动端、浏览器插件、CLI 共同构成入口。尤其是 CLI它连接端侧环境和私有化部署叙事让本地模型、本地文件、本地运行环境进入协作体系。O.C.T.O.四个维度缺一不可至此Octo 的产品能力较为清晰它们分别对应名字背后的四个维度Open、Context、Taste 与 Orchestration。O 是「Open」代表开放生态。不同 Runtime 的 Agent包括 OpenClaw、Codex、Claude Code、Cursor 等都能够以 Bot 身份接入获得统一身份。C 是「Context」代表共享上下文。IM 中的讨论收敛为结构化知识项目上下文在不同 Agent 之间共享任务过程也可被持续追溯。T 是「Taste」代表偏好进化。实战反馈沉淀为偏好每个 Agent 背后主人的品味和判断方式被结构化留存与调用。O 是「Orchestration」代表多 Agent 编排。六种协作模式对应六种信息拓扑不同 Bot 带着不同偏好参与同一任务合力完成复杂工作。这四个维度相互关联构成了 Octo 所提供的完整能力。承载起 Context、Taste、Orchestration 的共同基座正是 Matter它成为复杂任务得以被理解、反馈、校准和编排的核心容器。没有 MatterContext 会散落在聊天记录里Taste 会缺少来自真实任务的反馈来源多 Agent 编排也难以留下可追溯的过程和结果。Octo 想要把一次次协作转化为组织资产就必须先让每一件事有稳定的结构、完整的过程以及可以沉淀的判断。从这个视角来看Octo 想争夺的是企业在 Agent 时代最关键的一类资产自己的上下文、判断标准以及做事方法。写在最后像 Octo 这样的尝试不仅弥补了将 Agent 连接在一起的能力也在悄然改变组织内部知识流动和协作的方式。但这并未走向另一个极端。人不可替代的部分包括 Taste、暗默知识、判断力依然保留在个体身上只是通过协作过程得到进一步彰显和传递即「能力可以共享但判断不会被抹平」。这也引出了一个更根本的问题在 AI 时代企业真正的长期竞争力究竟来自哪里当模型能力快速趋同长期竞争力更多来自企业自己的 Context、Taste 和 Skill。这些东西无法被复制也不应流失它们才是组织在 AI 协作中真正的「护城河」。正因如此当 Agent 真正融入组织运转数据主权问题变得无法回避这些上下文、判断信号与执行记录究竟归谁所有、留在哪里、由谁控制Octo 给出的答案很明确走私有化路径通过开源开放支持本地部署。在实现上Octo 以 CLI 接入的方式将端侧模型与本地环境接入工作流中产生的上下文、决策过程与执行结果同样留在端侧沉淀为组织可以掌控的资产。这意味着包括聊天数据、协作产出、Bot 记忆在内每条对话、每行代码都保留在用户的环境中完全运行在自己的服务器上。所有这些都将成为企业独享的 AI 资产。在 Octo 的产品哲学中「Context」与「Taste」是两大核心前者是 AI 理解任务的土壤后者是持续校准方向的罗盘。Octo 并非将人的隐性能力蒸馏为平台资产而是在尊重数据边界的前提下让这些能力得到放大、记录与传承。这与明略科技长期坚持的可信 AI 方向高度一致。明略科技持续构建面向端侧智能、私有化部署与人机协作的新一代 AI 基础设施能力可以流动但数据不外流协作可以展开但控制权留在组织内部。对企业而言Private AI 不只是本地化部署更是数据主权、知识主权与协作主权的真正回归。对个人而言真正被放大的价值是 Taste—— 我品故我在当 AI 逐步接管思考人的判断力、鉴赏力与创造力不会被取代反而成为存在的意义本身。支撑这一切的底座是 Trustworthy AI开源、白盒、可审计。只有当 AI 的能力来源、运行过程和协作边界足够透明人才放心将「思」交给它们把「品」留在自己手里。Octo 的探索尚处于早期但轮廓已清晰当 Agent 更深入地嵌入分工体系真正决定效率的是那些无法被标准化、也不应被外流的东西 —— 组织自己的上下文和人自己的判断。
