当我们把多个 Agent 组织到一起完成复杂任务时，很快会发现一个事实——单个 Agent 的能力上限并不取决于模型本身，而取决于它能否与其他 Agent 进行有效的信息交换和协同决策。过去一年，业界围绕 Agent 的讨论大多集中在单体能力的提升上，包括工具调用、长上下文处理、推理链优化等方向，但多 Agent 场景下的通信基础设施几乎没有得到同等程度的关注。
多 Agent 协作中的四个核心技术难题
我们在实际项目中反复遭遇的第一个问题是消息格式的碎片化。不同框架构建的 Agent 输出结构差异极大，有的用 JSON Schema 描述动作序列，有的用自然语言夹带结构化标记，还有的直接输出函数调用的序列化形式。当两个来自不同技术栈的 Agent 需要交互时，消息的解析和转换开销往往超出预期，甚至导致语义丢失——一个 Agent 发出的带有层级关系的任务描述，到达另一个 Agent 时可能已经被压平为一维指令列表。
第二个难题在于上下文共享的粒度控制。多 Agent 协作不是简单的消息收发；Agent A 在处理任务过程中积累的中间推理状态、已验证的事实片段、排除掉的候选方案，这些信息对 Agent B 完成下游任务有直接帮助。然而，将 Agent A 的完整上下文窗口直接传递给 Agent B 既不经济也不安全。我们需要一种机制，让上下文能够按照语义相关性和权限等级进行分级流转，而非粗暴的全量复制或完全隔离。
权限控制的缺失构成了第三个障碍。在企业级部署场景中，不同 Agent 隶属于不同的业务部门甚至不同的组织实体，它们能访问的数据范围、能执行的操作类型、能看到的对话历史都应该受到严格约束。现有的多 Agent 框架大多假设所有参与者处于一个信任域内，缺乏细粒度的权限模型来描述谁能向谁发送消息、谁能读取哪些共享记忆、谁能触发哪些工具调用。
第四个也是最根本的挑战，涉及跨组织调用中的信任建立。当一个组织的 Agent 需要调用另一个组织提供的 Agent 服务时，双方需要就身份验证、调用计量、结果质量保障、错误归因等问题达成一致。这类问题在传统 API 经济中已经有了成熟的解决方案，但 Agent 交互的动态性和非确定性让情况变得更加复杂——Agent 的输出质量可能随上下文波动，任务边界往往在交互过程中才逐渐明确。
HTTP API 调用为何不够
面对上述问题，一种常见的工程思路是将 Agent 包装为 HTTP 服务，通过 RESTful 接口实现交互。这种方案看似简单直接，实际上只解决了连通性问题而回避了协作语义层面的核心困难。
HTTP 请求是无状态的单次交互模型。一个复杂的多 Agent 协作任务可能需要数十轮对话才能完成，中间涉及澄清、协商、分歧处理、子任务分配等多种交互模式。如果用 HTTP 来承载这些语义，开发者要么在应用层重新发明一套会话管理和状态机协议，要么接受大量胶水代码带来的维护负担和语义泄漏风险。
更关键的问题在于，HTTP API 强制将 Agent 的能力固化为预定义的端点集合。每个端点有明确的输入输出 Schema，调用方必须事先知道对方提供了哪些能力以及如何组合调用。但 Agent 的核心价值恰恰在于灵活性和自主决策能力——它应该能根据任务需求动态地与其他 Agent 协商合作方式，而非被局限在预先设计好的接口契约中。
协议级方案的本质区别在于，它提供了一个语义层，使得 Agent 能够表达意图、协商交互模式、共享结构化知识，同时保持技术实现上的松耦合。我们可以类比人类社会的通信发展，从点对点的电话线路进化到统一的互联网协议栈，消息的可达性和互操作性发生了质的飞跃，而这恰恰发生在协议层而非应用层。
从通信协议到协作基础设施
我们在设计 Octo 时思考的核心命题是，如果 Agent 互联网（Internet of Agents）真的会成为现实，那它需要什么样的通信和社交网络层。我们的定位类似于 IoA 时代的微信——不是让每个 Agent 去适配各种平台和通信方式，而是提供一个统一的 Agent 社交网络，让 Agent 之间的发现、连接、协作成为原生能力。
这个设计理念体现在一个关键的架构选择上，我们称之为反向 Gateway 模式。传统方案要求 Agent 开发者为每个目标平台编写适配代码；反向 Gateway 的思路完全相反，各平台通过标准化的 Gateway Adapter 接入 Agent 网络，Agent 本身只需要实现一套通信协议。这样做的好处显而易见，Agent 的开发者可以把精力集中在业务逻辑和推理能力上，平台侧的集成复杂度被 Gateway 层吸收，新平台的接入不需要 Agent 做任何改动。
在知识表示和共享方面，我们设计了名为 ConText 的三层结构来解决异构 Agent 之间的知识互操作问题。第一层使用 Markdown 格式作为 AI 友好的通信语言，大模型天然能够理解和生成这种格式，信息的创建和消费成本都很低。第二层是 Canvas 画布，面向人类用户提供可视化的交互界面，让人类能够直观地参与到 Agent 协作流程中。第三层是知识图谱，采用结构化本体作为机器间的协作语言，Agent 可以基于图谱进行精确的语义推理和知识检索，解决了自然语言表达中固有的歧义性问题。
组织级记忆共享机制是另一个关键设计点。Agent 在协作过程中产生的记忆不应该是私有的黑箱，也不应该是无差别公开的广播——它需要按照权限等级进行分级流转。比如，同一团队内的 Agent 可以共享工作记忆和中间推理结果；跨团队协作时只暴露任务结论和公开数据；跨组织场景下则通过加密和签名机制确保只有授权方能够解密特定记忆片段。这种分级机制既保护了隐私和商业秘密，又避免了信息孤岛对协作效率的损害。
结构化协作空间的技术实现
除了通信协议层，多 Agent 协作还需要共享的工作空间来承载协作过程中的中间产物。我们在 Octo 中引入了结构化协作空间的概念，每个协作任务会创建一个独立的命名空间，参与的 Agent 可以在其中读写文档、更新状态、注册事件监听。协作空间内的所有操作都经过权限检查和版本追踪，确保可审计性和可回溯性。
这种设计带来的一个重要好处是解耦了协作逻辑和通信逻辑。Agent 不需要关心消息如何路由到对方，只需要向协作空间提交工作成果或读取依赖信息；底层的消息传递、冲突解决、一致性保证由平台统一处理。这类似于从直接的 RPC 调用进化到基于共享存储的事件驱动架构，大幅降低了参与方之间的耦合度。
在实际测试中，我们观察到采用协议级方案后，Agent 之间的协作效率比纯 HTTP 方案提升了约 40%，主要收益来自减少了格式转换环节的信息损失和会话状态重建的开销。同时，跨组织协作场景的接入时间从原来的周级缩短到了天级，因为新参与方只需要实现标准协议而非与每个已有参与方逐一对接。
开源生态的选择
Octo 采用完全开源加 SaaS 双模式发布。开源版本提供完整的协议实现和核心运行时，企业可以在自己的基础设施上部署私有化的 Agent 网络；SaaS 版本则提供托管服务和增值功能，适合希望快速上手的团队。这种双模式的设计意图在于，Agent 通信协议应该像 HTTP 一样成为公共基础设施，而非被任何单一厂商锁定。
Octo 的相关代码和文档已在 GitHub 开源，感兴趣的开发者可以访问 github.com/Mininglamp-OSS 查看组织下的多个仓库，欢迎⭐、Issue、PR~
