明略科技 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，也正是在这个位置生长出来。

越用越懂你：在实战中沉淀 Taste

Matter 解决了「事情如何留存」的问题，而 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，它成为复杂任务得以被理解、反馈、校准和编排的核心容器。没有 Matter，Context 会散落在聊天记录里，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 更深入地嵌入分工体系，真正决定效率的是那些无法被标准化、也不应被外流的东西 —— 组织自己的上下文和人自己的判断。