一个开源平台，编织起了Agent「互联网」

在历史长河中，技术的发展很少是一路线性往前走的，很多关键变化发生在「连接」被打通的那一刻。 拿计算机来说，到了 20 世纪 60 年代，它们已经具备强大的计算能力，但大多还是各自封闭运行的系统。架构不同、接口不通，彼此之间很难真正连在一起。 直到 ARPANET（阿帕网）的出现，这种孤岛的状态才被打破。计算机第一次在真正意义上连在一起，开始共享信息、建立联系。 如今，以龙虾为代表的 Agent，正面临半个多世纪前 IBM System/360 等大型机所遭遇的困境：单体能力已经足够强，但系统仍是分散的。 从「单一 Agent」到「一张组织网络」 过去很长时间，AI 行业把大部分精力都放在了相同的事上：把单个模型做得更强，把单个 Agent 打磨得更能干。这条路走到今天，其实已经接近一个阶段性的拐点：在大多数实际工作场景里，Bot 助手的能力不再是主要问题。 作为单体 AI，它们足够强大：IM（即时通信）交互、写代码、做调研、推进任务，都不在话下。真正卡住效率的，是彼此之间「接不上」。 Agent 被困在了各自的工作流中，由于运行在不同工具、上下文和权限体系里，各干各的，彼此看不见、调不动，也无法形成连续任务链条。它们可以各自完成一段工作，却很难共同完成一件事情。 一个人 + 一个 AI 助手本质上仍然只是效率工具；只有当一群人和一群 AI 助手能够在同一个体系中协同工作，才开始接近一种新的组织形态。 对于 Agent 来说，下一步除了变得更加聪明，还要找到属于自己的「互联网」，就像当年的计算机一样。 在这样的背景下，一个以人与 AI Agent 协作为基础、面向企业组织场景的开源平台 Octo 应运而生。该平台由全球 Agentic AI 第一股明略科技打造，核心做一件事：将分散在各个工作流里的 Bot 聚合到同一协作空间。更重要的是，这种连接不只是个人维度的。 在 Octo 中，Bot 既是个人助手，在经过授权之后也能在组织成员之间共享和调用。Bot 大军的自由流动，让 Agent 的身份开始发生转变：从个人工具蜕变为企业级资产和数字员工。 随着 Bot 以组织形式部署、使用并沉淀，它们不再各自为战，通过分工协作在任务之间流转，在过程中收到持续的反馈与评价，并进行修正。 项目地址：https://github.com/Mininglamp-OSS 更进一步，在 Agent 等数字劳动力爆发的当下，明略科技想要将 Octo 平台打造成为 Private AI 时代的组织基础设施，构建人和 AI 协作的新范式。当企业开始拥有成百上千 Agent 时，Octo 可以像管理互联网节点一样实现它们之间、它们与创建者之间以及创建者与创建者之间的高效连接、通信与协作。每个 Agent 既各司其职，又相互协作，这种工作模式在大多数场景中优于单一巨型模型。 并且对普通用户尤其友好的一点是，在 Octo 中，常见的工作场景被打包成现成的 Bot 模板，不用自己从头配，「领养」就能直接拉进群里干活。在这里不用考虑繁琐的装虾流程，易用性拉满。 Agent，不应只「活」在对话框里 现在，大多数 Bot 助手都是挂在 Discord、Telegram、飞书、钉钉这些 IM 里，通过消息接收指令、执行任务。Octo 同样是从 IM 形态切入，但它并不只是做一个更聪明的聊天工具，更在于重写协作本身。在这里，IM 更像是入口，而不是核心。 Octo 的 IM 界面 人和 Agent 虽然在同一个 IM 界面沟通、下任务、接收结果。但真正发生变化的，是背后的连接结构。 在传统工具里，人和 AI 往往是一对一的关系：你下指令，它完成任务，整个过程封闭在各自的工作流里。现在，Octo 把这层关系打破了，它想连接的是人、Bot、Runtime Agent 和工具这些原本分散的节点。 这也让它看起来不只是多了一个聊天窗口。更关键的是，它在搭一套新的协作方式：任务由人发起，由 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 更深入地嵌入分工体系，真正决定效率的是那些无法被标准化、也不应该被外流的东西 —— 组织自己的上下文和人自己的判断。 本文来自微信公众号“机器之心”（ID：almosthuman2014），作者：杜伟，36氪经授权发布。