多 Agent 协作的技术挑战：为什么需要协议级的消息互通

当我们把多个 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~