开源平台编织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以组织形式部署、使用并沉淀，它们不再各自为战——通过分工协作在任务之间流转，在过程中持续获得反馈与评价，并不断修正。

更进一步，在Agent等数字劳动力爆发的当下，明略科技想要将Octo平台打造成为Private AI时代的组织基础设施，构建人和AI协作的新范式。当企业开始拥有成百上千Agent时，Octo可以像管理互联网节点一样，实现它们之间、它们与创建者之间、以及创建者与创建者之间的高效连接、通信与协作。每个Agent既各司其职，又相互协作——这种工作模式在大多数场景中优于单一巨型模型。

对普通用户尤其友好的一点是，在Octo中，常见的工作场景被打包成现成的Bot模板，不用自己从头配置，「领养」就能直接拉进群里干活。繁琐的装虾流程？不存在的，易用性直接拉满。

Agent，不应只「活」在对话框里

现在，大多数Bot助手都挂在Discord、Telegram、飞书、钉钉这些IM里，通过消息接收指令、执行任务。Octo同样是从IM形态切入，但它并不只是做一个更聪明的聊天工具——更重要的，是重写协作本身。在这里，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带着不同偏好参与同一任务，合力完成复杂工作。

这4个维度连在一起，构成了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更深入地嵌入分工体系，真正决定效率的是那些无法被标准化、也不应该被外流的东西——组织自己的上下文和人自己的判断。

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