快消息！5000个Agent如何协同工作？拆解明略科技(2718.HK)Octo的企业级布局

一、Agent越来越多，为什么企业反而更忙了？

(资料图片仅供参考)

过去一年，企业接入AI的方式发生了明显变化。除了通用大模型，越来越多团队开始使用编程Agent、办公Agent、数据分析工具，以及围绕具体业务开发的专用智能体。

这些工具各有优势，却很容易形成新的信息孤岛。

例如，市场团队用一个Agent完成行业研究，销售团队通过CRM管理客户，数据团队在BI系统里分析经营表现。当企业需要根据市场变化制定销售策略时，相关信息可能分散在不同系统里。一个Agent完成的分析结果，也未必能被另一个Agent直接调用，更难自动进入后续业务流程。

员工只好充当中间的协调者：复制报告、转发消息、补充背景、核对结果，再把任务交给下一个工具。

这类问题与Agent本身的聪明程度关系不大。即使每个Agent都能完成自己的工作，企业依然需要解决任务组织、上下文传递、权限管理和结果验收等问题。Agent的规模越大，这些问题越难依靠人工维持。

在这种情况下，企业需要一套能够连接现有Agent和业务系统的协作机制。它既要让Agent找到合适的协作者，也要知道任务进行到了哪一步、已经产生了哪些结果，以及接下来应该由谁继续处理。

明略科技开源的Octo，正是围绕这类需求展开探索。它希望提供一个面向企业任务的协作层，将分散的Agent、工具与业务系统组织起来，让不同能力能够围绕同一目标协同工作。

二、Octo如何组织一群Agent一起工作？

理解Octo，可以从它的几个基本概念入手：Bot、Channel、Thread和Loop。

Bot可以理解为协作体系中的参与者，既可以承担具体职责，也可以连接不同的Agent和工具。Channel提供相对稳定的协作空间，Thread用于围绕具体事项组织讨论与信息。Loop则进一步聚焦任务执行，让参与者围绕一个目标持续协作。

这套结构将参与者、沟通上下文和任务执行联系起来。

假设一家企业需要完成一份市场进入方案。任务可能涉及行业研究、竞品分析、用户调研、财务测算和方案撰写。系统可以根据任务特点组织不同角色参与：有的负责收集信息，有的分析数据，有的审查结论，还有的整合最终方案。

各个Agent不必在同一个环节做重复劳动，也不需要把所有信息无差别地发送给所有参与者。协作围绕具体任务展开，每个角色根据职责获取所需信息，并将阶段性成果交给后续环节。

Octo支持多种协作模式，以适应不同任务的组织方式。

Solo适合单个Agent独立完成任务；Roundtable让多个参与者围绕同一问题展开讨论；Critic引入审查和批评角色，帮助发现方案中的问题；Pipeline将任务拆成前后衔接的步骤；Split支持把任务拆分后分别处理；Swarm则面向多个参与者协同推进的场景。

这些模式对应着不同的工作组织方式。简单任务可以直接交给单个Agent，涉及多专业判断的任务可以组织讨论与审查，需要大量并行处理的任务则可以进行拆分。

因此，多个Agent一起工作，重点在于让不同角色形成明确的分工关系，并且能够沿着任务链条继续推进。

三、企业接入Agent，为什么还要考虑跨平台协作？

企业已有的AI工具往往来自不同供应商，也可能运行在不同的技术框架和环境中。

如果为了使用一套新的协作平台，就要求企业把原有Agent全部迁移过去，改造成本很容易成为落地障碍。更现实的做法，是让新系统能够连接已有工具，逐步建立协作关系。

Octo采用开放的接入思路，支持对接飞书、钉钉、企业微信等协作渠道，也可以连接自建系统、工作流和不同类型的Agent工具，包括Dify Workflow、Codex、OpenClaw，以及CLI、MCP和Skill等能力。

这意味着企业可以根据自身情况分阶段接入。

对于已有的业务系统，可以先通过链接或引用关联信息；需要进一步处理时，再按权限读取相关内容；如果任务要求更深的自动化，也可以逐步开放事件订阅和工具执行能力。对于经过确认、具有复用价值的经验，则可以进一步整理和沉淀。

这种渐进式接入方式，有助于企业控制改造范围。原有系统仍然可以承担自己的职责，Octo负责将分散的能力组织起来，围绕跨系统任务形成协作链路。

例如，一项客户服务任务可能需要读取CRM中的客户记录、查询订单系统、调用知识库，再把处理结果写回工单系统。整个过程涉及多个系统，单个Agent很难独立掌握所有业务上下文和执行权限。通过协作层组织任务，企业可以逐步把这些环节连接起来。

对已经投入资源建设Agent的企业而言，这也提供了另一种扩展路径：保留已有能力，在需要协作的地方建立连接。

四、上下文如何流动，数据又该放在哪里？

多Agent协作的难点之一，是上下文管理。

一个Agent完成任务后，后续参与者需要知道此前发生了什么、哪些结论已经得到验证、还有哪些问题尚未解决。如果每次任务切换都要重新描述背景，协作效率就会受到影响；如果把所有企业数据集中复制到一个平台，又会带来额外的数据治理和安全问题。

Octo在设计上强调原始数据与任务上下文的区分。

企业原有的数据可以继续留在CRM、文档系统、数据库等源系统中。协作过程中，系统根据任务需要，通过授权方式引用或读取相关信息。任务空间负责组织与当前工作有关的上下文、过程和结果，减少参与者反复寻找信息、重复交代背景的成本。

这种方式也意味着，上下文管理需要兼顾两个方面：一方面，参与任务的Agent必须获得足够的信息，才能理解目标并继续执行；另一方面，信息访问必须受到权限约束，不能因为加入协作网络，就默认获得企业所有数据。

随着接入方式从信息引用逐步深入到数据读取、事件订阅和工具执行，企业可以根据业务风险配置相应的权限与控制措施。

对于长链条任务而言，过程信息同样重要。任务目标、阶段性结果、执行状态和后续动作需要保持衔接，才能支持持续推进与问题排查。对于经过验证的工作经验，企业还可以将其整理为可复用的知识或流程。

这让一次任务有机会为下一次工作留下有用的信息，逐步减少重复沟通和重复配置。

五、从一次协作，到企业自己的Agent体系

如果协作层只能把Agent连接起来，价值仍然有限。企业真正关心的，是这些能力能否在长期使用中不断积累。

Octo的整体设计可以从四个方面理解：Open、Context、Taste和Orchestration。

Open强调开放接入，让不同平台、运行环境和Agent能够参与协作；Context负责组织任务所需的上下文；Taste指向经过筛选和验证、能够体现组织经验的知识与偏好；Orchestration则负责将参与者、工具和任务流程组织起来。

四者共同指向一个长期目标：让企业逐渐形成自己的Agent协作体系。

举例来说，一家企业第一次使用Agent完成市场研究时，需要人工明确研究范围、指定数据来源、检查分析结果。随着类似任务反复发生，团队可以逐步沉淀研究模板、数据调用方式、审查标准和常见问题处理经验。下一次遇到相近任务时，系统就有机会复用已有的流程与知识，减少从头配置的工作。

当然，经验沉淀不意味着所有历史输出都可以直接复用。企业仍然需要判断信息是否准确、知识是否过时、流程是否适用于新的业务场景。只有经过筛选和验证的内容，才适合进入长期复用体系。

随着这些能力不断积累，Agent的价值也会从单次执行延伸到组织层面。企业可以逐步建立一套能够被调用、组合、维护和持续改进的数字化工作能力。

六、企业级Agent还需要开放性与数据主权

当Agent开始参与真实业务，开放接入之外，数据安全和部署方式同样重要。

企业的客户信息、业务流程和内部知识往往具有明确的权限边界。协作系统需要支持对数据访问和工具调用进行管理，并让企业能够根据自身要求控制部署与运行环境。

Octo采用Apache 2.0开源协议，并支持私有化部署，为企业根据自身基础设施和安全要求进行部署、集成与扩展提供了选择。

开源能够降低企业理解和评估技术方案的成本，也为开发者参与项目、围绕实际需求进行改造提供空间。但开源本身并不自动解决企业级安全问题，实际落地仍需要结合部署环境、访问控制、审计机制和业务流程进行设计。

对于需要长期运行的Agent体系来说，这些能力与任务编排同样重要。企业既希望Agent能够自主处理更多工作，也需要明确它可以访问哪些信息、执行哪些操作，以及出现异常时如何介入。

结语

当企业使用的Agent从几个增加到几十个、几百个，乃至尝试组织更大规模的协作时，管理重点会逐渐转向任务、上下文、权限与执行过程。

Octo探索的方向，是为这些分散的Agent建立一套协作机制，让它们能够跨越平台和系统，围绕共同目标完成分工，并将有价值的经验沉淀下来。

这条路径最终能走多远，还取决于模型能力、系统集成、业务流程和治理机制的共同进步。但有一点已经值得关注：企业AI的下一阶段，除了持续提升单个Agent的能力，还需要认真解决多个Agent如何在真实组织中配合工作的问题。

当越来越多的工作可以交给Agent执行，企业真正需要建设的，也将是一套能够持续组织、管理和改进这些数字化工作者的基础设施。