蚂蚁开源Avernet协作层

蚂蚁把多智能体的“组织关系”单独拆了出来

蚂蚁集团旗下 inclusionAI 团队近期正式开源多智能体协作基础设施 Avernet V0.1，社区版本已经上线。该项目于 2026 年 7 月发布首个开源版本，截至今天（8 月 7 日）刚满一个月，核心目标不是再造一个智能体开发框架，而是把注册、发现、邀请、组队、共识和执行追踪等通用能力抽成独立基础设施。

Avernet 是一个面向人与智能体、智能体与智能体协作的基础设施层。它不负责让单个 Agent 变得更聪明，而是负责让不同来源、不同模型和不同运行环境中的 Agent，能够找到彼此、建立关系并围绕同一项任务持续协作。

这一区别看似只是产品定位，实际上决定了 Avernet 与大量 Agent 框架不是同一类东西。LangGraph、AutoGen、CrewAI 以及蚂蚁此前开源的 AWorld，主要解决智能体内部如何编排、调用工具、保存状态和执行工作流；Avernet 则更像一套“组织系统”，处理谁能加入、谁负责决策、任务如何分发、分歧如何收敛，以及整个过程如何留下记录。

多智能体真正难的不是多，而是协作

多智能体系统是由多个具备一定自主决策能力的 Agent 共同完成任务的软件系统。它的理论优势很直接：一个 Agent 做规划，一个 Agent 搜集资料，一个 Agent 执行工具，另一个 Agent 复核结果，复杂任务由此从单线程处理变成角色分工。

现实中的多智能体系统却很容易退化成一群模型在聊天。Agent 数量增加后，消息轮次、上下文长度和模型调用成本会同步上升；如果没有明确的退出条件和决策机制，三个 Agent 可能反复讨论同一问题，却得不出比单个强模型更好的答案。

协作层是位于智能体能力与业务应用之间、专门管理通信关系和协作流程的软件层。它类似企业里的通讯录、会议系统、项目管理平台和审计系统的组合：员工能力仍由员工自己提供，但谁参与项目、会议如何组织、结论由谁确认、任务有没有完成，都不应该由员工临时口头约定。

Avernet 的判断正是如此：多智能体应用不应该为每个项目重复开发一套通讯录和会议制度。开发者可以继续保留原有 Agent 的模型、工具、记忆和业务逻辑，只把协作流程接入 Avernet，从而降低异构系统之间的整合成本。

这一思路比“再做一个全家桶 Agent 平台”更克制，也更接近基础设施应有的边界。Agent 行业目前不缺能够创建角色、串联提示词的框架，真正缺少的是可跨项目复用的身份、发现、会话、状态同步和审计能力。

Avernet V0.1 先标准化五件事

Avernet V0.1 的核心价值是把多智能体从临时编排推进到可管理协作。按照目前公开资料，其主要覆盖注册与发现、邀请与组队、共享上下文、协作共识以及可追溯执行五个环节。

1. 注册与发现：先让 Agent 知道谁能做什么

智能体注册是把 Agent 的身份、能力和可用状态登记到统一目录中的过程。没有注册中心时，开发者通常会在工作流中硬编码某个 Agent 的地址和职责，一旦服务迁移、能力变化或实例下线，整个流程都可能需要修改。

服务发现是系统根据能力描述和运行状态找到合适 Agent 的机制。它解决的是“谁会做这件事”和“谁现在可以做这件事”，而不只是“某个固定服务在哪里”。

这套能力对企业场景尤其重要。以报销审核为例，系统可以分别寻找具备票据识别、财务规则检查、反欺诈分析和人工复核权限的参与者，而不是把所有任务交给一个无所不包的超级 Agent。

注册发现的难点并不在于做一张服务列表，而在于能力标签是否可信、状态是否及时，以及权限是否会随着任务变化。Avernet 已经搭起统一入口，但 V0.1 能否应对复杂权限继承、动态能力评估和大规模实例抖动，仍需要真实生产环境验证。

2. 群组与会话：给多个 Agent 一间持续存在的会议室

群组是具有相对稳定成员关系的协作单元，会话则是围绕某个具体任务展开的交互过程。两者分离之后，研发团队可以长期保留一个代码审查群组，同时为每次提交创建独立会话，避免不同任务的上下文相互污染。

共享上下文是让多个参与者读取同一组任务状态和关键资料的机制。它解决了多 Agent 系统中常见的信息割裂问题：规划 Agent 已经修改目标，执行 Agent 却仍然根据旧版本行动；复核 Agent 只看到最终答案，却看不到中间假设和工具结果。

Avernet 通过群组、会话和共享上下文组织协作状态，这比简单地把所有历史消息拼进提示词更合理。聊天记录只是消息流，共享状态还需要版本、权限、有效期和写入冲突管理，这些恰恰是生产级多智能体系统容易踩坑的地方。

3. 两类协作模式：聊天和指挥链不是一回事

自由聊天模式是参与者在没有固定上下级关系时平等交换信息的协作方式。这种模式适合头脑风暴、方案评审和开放式研究，不同 Agent 可以从安全、成本、性能等角度提出独立意见。

领导者—跟随者模式是由一个 Leader 负责拆解、分派和汇总任务，其他 Follower 执行子任务的层级式协作方式。这种模式更适合目标明确、步骤可拆分的任务，例如让一个主管 Agent 组织资料检索、数据核验、写作和事实检查。

两种模式没有绝对优劣，但成本结构截然不同。自由聊天能够保留更多探索空间，却容易增加无效轮次；领导者—跟随者模式效率更高，却可能因为 Leader 的错误规划让整个团队走偏。

Avernet 支持这两种模式，说明它没有把所有协作都简化为工作流节点。真正有价值的下一步，是根据任务不确定性、参与者负载和历史成功率动态切换协作结构，而不是只提供一个静态模式参数。

4. 共识机制：不是让 Agent 投票这么简单

多智能体共识是多个参与者在存在不同意见时形成可执行结论的过程。在内容审核、风险判断和代码合并场景中，系统不能只保存三份互相矛盾的回答，而必须明确最终采用哪一个结论、由谁承担决策责任。

这里的“共识”不应与分布式数据库里的 Raft、Paxos 等一致性算法直接画等号。数据库共识主要确保多个节点对状态顺序达成确定性一致，而大模型 Agent 的输出带有概率性和语义模糊性，真正的问题往往是判断依据是否充分、少数意见是否需要保留，以及何时应该升级给人工处理。

Avernet 对共识流程进行基础设施化是正确方向，但公开信息尚不足以证明它已经解决了复杂语义决策。对于开发者而言，更现实的期待是用它统一组织提案、反馈、修订和确认过程，而不是认为接入之后多个 Agent 就会自动产生更正确的答案。

5. 追踪与反馈：没有记录的协作无法优化

可追溯执行是记录任务从发起、分配、讨论到形成结果全过程的能力。多 Agent 应用出现错误时，开发者需要知道问题来自模型幻觉、工具失败、上下文过期、权限不足，还是任务分配本身不合理。

Avernet 将执行记录纳入协作闭环，这一点比单纯强调“群体智能”更务实。只有保存参与者、消息、状态变化和决策结果，团队才可能评估某个 Agent 是否经常拖慢流程，某种协作模式是否浪费模型调用，以及人工在哪些节点频繁接管。

反馈循环是根据历史协作数据调整参与者选择和流程策略的机制。公开资料提到 Avernet 希望通过观察、评估、复用和优化推动系统持续演进，但这部分能力在 V0.1 阶段更适合看作架构方向，而不是已经得到基准测试验证的自动学习系统。

它和 AWorld、编排框架、Agent 协议有何区别

Avernet 最容易被误解为蚂蚁又开源了一套多智能体框架。实际上，它与 inclusionAI 此前推出的 AWorld 更接近上下层互补关系：AWorld 关注 Agent 如何执行与学习，Avernet 关注多个参与者如何建立组织并协同工作。

MCP、Agent2Agent 等协议与 Avernet 也不是简单替代关系。协议通常定义能力如何描述、消息如何交换或工具如何调用；Avernet 的重点则是把协议之上的群组、邀请、共识和追踪变成可运行服务。

| 项目类型 | 主要解决的问题 | 典型能力 | 更适合的场景 | 与 Avernet 的关系 | |---|---|---|---|---| | Avernet | 多个异构 Agent 如何建立协作关系 | 注册发现、邀请组队、群组会话、共识、执行追踪 | 跨团队、跨引擎的长期协作 | 独立协作层 | | AWorld | Agent 如何执行任务并形成学习闭环 | 事件驱动、工具调用、上下文管理、训练数据闭环 | 复杂任务执行与智能体进化 | 可作为下层 Agent 引擎 | | LangGraph 类编排框架 | 状态化工作流如何运行 | 图结构、节点、条件分支、持久化状态 | 边界明确的业务流程 | 可把工作流节点接入协作层 | | AutoGen/CrewAI 类框架 | 多角色 Agent 如何对话和分工 | 角色定义、轮次管理、任务委派 | 单应用内快速搭建 Agent 团队 | 能力有重叠，但通常更偏应用框架 | | MCP/A2A 类开放协议 | 工具或 Agent 如何互操作 | 能力描述、消息格式、调用规范 | 跨产品连接与生态兼容 | 协议可成为 Avernet 的连接方式 |

Avernet 的竞争力不会取决于它能否再提供一套聊天接口，而取决于能否成为不同框架共同使用的协作层。只有当使用 AWorld、LangGraph、自研 Agent 和传统 Bot 平台的团队都愿意接入同一套身份与会话体系，它才具备基础设施级网络效应。

开源和部署门槛都比较友好

Avernet V0.1 已按 MIT 许可证开放源代码。MIT 许可证允许开发者使用、修改和再分发代码，对希望进行私有化部署或二次开发的企业团队相对友好，但使用者仍需保留原始版权和许可声明。

部署方式覆盖本地运行与 Docker 容器化方案。前者适合个人开发者验证概念，后者更容易接入现有测试和集群环境；不过，“能够容器化启动”与“达到生产级可用”之间仍隔着监控、升级、灾备、权限和容量规划等一整套工程工作。

异构兼容是 Avernet 目前最值得关注的设计选择。公开资料显示，它希望连接自定义 Agent、第三方智能体引擎、现有 Bot 平台及开放协议，而不是要求所有参与者迁移到 inclusionAI 的技术栈中。

这种开放性必须由真实适配器和兼容性测试来证明。V0.1 阶段的开发者更应该关注接入一个现有 Agent 需要改动多少代码、状态模型能否映射、异常能否恢复，而不是只看兼容列表中出现了多少框架名称。

V0.1 的短板也很明确

Avernet 当前仍是一个早期社区版本，而不是已经完成大规模验证的企业协作平台。公开材料没有给出吞吐量、端到端延迟、故障恢复时间、最大稳定并发 Agent 数量或多智能体任务成功率等系统化基准数据，因此暂时无法用数字判断其性能上限。

缺少基准测试是现阶段最明显的信息空白。多 Agent 基础设施的成本不只来自系统本身，还来自协作轮次带来的模型推理费用；如果四个 Agent 为一个结论往返十轮，即使基础设施延迟只有几十毫秒，整体成本仍可能显著高于单 Agent 方案。

大规模共识与跨地域状态同步也是已知挑战。公开路线信息显示，V0.1 对跨地域、多集群协作和大规模群组的支持仍有限，可视化运维能力也处于早期阶段，这意味着它目前更适合原型验证和中小规模内部试验。

安全边界比功能数量更值得企业用户优先审查。Agent 注册后可以看到什么、共享上下文能否按字段隔离、外部参与者是否可以注入恶意指令、执行记录如何脱敏，以及人类能否随时终止错误协作，都会直接决定 Avernet 能否进入金融、医疗和政企业务。

人与 Agent 的混合协作同样不能只停留在“人也可以加入群聊”。生产系统需要明确人类确认点、超时升级策略、责任归属和不可逆操作的审批机制，否则多智能体只是把自动化风险从一个模型扩散到了一个组织。

这次开源的价值，在于把问题定义对了

Avernet 最重要的贡献不是宣布多智能体已经成熟，而是把行业焦点从“创建更多 Agent”转向“如何管理 Agent 之间的关系”。当基础模型能力逐渐接近、工具调用越来越标准化之后，系统差异将更多来自组织方式：任务交给谁、谁有权否决、上下文如何共享，以及失败后如何追责。

这一方向对开发者有实际价值。正在维护多个垂直 Agent、需要跨系统调度能力，或者已经被手写消息队列、角色列表和会话状态拖累的团队，可以把 Avernet 当作协作层候选方案进行验证；只有一两个固定 Agent、流程完全确定的应用，则未必需要额外引入这一层复杂性。

Avernet 也不应该被过早称为“多智能体操作系统”。操作系统意味着稳定的资源抽象、权限隔离、调度、公认接口和广泛生态，而 V0.1 目前更准确的定位，是一套试图统一多智能体协作原语的开源基础设施。

蚂蚁的优势在于拥有真实复杂业务和较完整的 Agent 技术栈。inclusionAI 已经通过 AWorld 探索事件驱动智能体、工具生态和学习闭环，如果 Avernet 能与这些能力形成清晰分层，并在蚂蚁内部高并发、高审计要求的场景中得到验证，它会比纯社区概念项目更有说服力。

最终决定 Avernet 能否站住脚的，将是三个数字：接入现有 Agent 的工程成本、增加协作层后的任务成功率变化，以及每项成功任务的总推理成本。官方尚未公布这些关键基准，因此现阶段最合理的判断是：架构方向值得关注，产品成熟度仍需等待社区案例和后续版本回答。

参考来源

• Avernet 官方开源仓库：项目源代码、许可证、部署说明与后续版本更新的主要来源。
• inclusionAI 官方 GitHub 组织：可查看 inclusionAI 旗下开源项目及团队维护动态。
• AWorld 官方开源仓库：用于了解蚂蚁另一套多智能体框架的事件驱动架构及其与 Avernet 的定位差异。