IoA 论文解读：多智能体真正缺的，不是更多 Agent，而是协作层

如果只看标题，Internet of Agents 很容易被理解成又一个“让很多 Agent 一起聊天”的框架。论文真正想做的事其实更底层：它不是单纯讨论“几个 Agent 一起工作会不会更强”，而是在问，未来如果真的会出现大量独立开发、运行环境不同、能力边界不同的 Agent，它们要靠什么机制互相发现、临时组队、分配任务、等待结果，再在必要时继续拆出子团队。

从这个角度看，IoA 想解决的不是一个提示词技巧，而是一个多智能体协作系统的基础设施问题。

---

这篇论文为什么值得看

作者认为，现有多智能体框架主要有三类结构性问题：

• 只在自己的生态内协作，第三方 Agent 很难接入

第一个问题点出了今天不少 agent framework 的现实局限：大家都在造自己的 agent，但很少认真处理“别人的 agent 怎么接进来”。

• 大多是在单机上“模拟多智能体”，和真实分布式场景差距很大
• 通信流程和状态切换往往是写死的，缺少任务驱动的动态协作能力

第三个问题抓住了多智能体系统最容易失控的地方：系统里 agent 变多，并不自动等于协作能力变强。

所以 IoA 的目标并不是继续做一个“更多角色、更长对话”的框架，而是想回答一个更像系统架构的问题：

Agent 之间能不能像互联网中的服务一样被注册、检索、路由、编排与复用？

---

IoA 的核心思想是什么

先把多智能体协作抽象成“即时通讯系统”

IoA 的第一步很朴素：把多智能体系统拆成服务器和客户端。

• 服务器负责注册、发现、组队和消息转发
• 客户端负责把一个具体 Agent 封装成可通信的参与者

这个抽象看上去不惊艳，但很关键。它把“多智能体协作”从一段提示词流程，压成了一个更清晰的系统模型。

图里的分层也比较工整：

• 交互层处理组队和通信
• 数据层管理联系人、群聊、任务与注册信息
• 基础层负责网络、存储和 Agent 集成

这套分层不新，但适合 IoA 这种问题。因为它真正关心的不是单个 agent 的内部推理，而是协作关系如何被组织起来。

用注册与发现机制解决异构 Agent 接入

每个 Agent 注册时提交自己的描述、能力和类型；有任务时，其他 Agent 可以按能力检索候选协作者。

这一步本质上是在做面向 Agent 的 service discovery。

这也是 IoA 和很多“封闭生态”框架的分水岭。它不要求所有 agent 出自同一套框架，只要求它们能在一层统一协议上被描述、被找到、被拉进协作网络。

用嵌套组队处理复杂任务

IoA 不假设初始团队一次就能把所有事情做完。

如果讨论中出现更专业的子任务，某个成员可以继续发起二级组队，拉出子群聊。这样整个协作结构就从“单一群聊”变成一棵任务树。

这个设计有两个直接好处：

• 复杂任务可以被自然拆成层级化子问题
• 不是所有 agent 都必须长期留在同一个大群里消耗通信预算

论文还专门提到，这种嵌套组队有机会降低大团队的通信复杂度。这个判断是合理的，因为它把“全员全程互相可见”的高成本协作，改成了按子任务局部展开的协作。

用有限状态机管理对话流

IoA 没有把对话流程写死成一条线，而是抽象出五种群聊状态：

• discussion
• sync task assignment
• async task assignment
• pause & trigger
• conclusion

这里真正有价值的地方，不是“用了状态机”这件事本身，而是作者把 LLM 的决策限制在一个比较清楚的状态空间里。模型需要判断：

• 现在要不要继续讨论
• 该进入同步还是异步任务分配
• 是否应该暂停等待某些异步任务
• 谁最适合成为下一位发言者

这比“固定流程跑到底”的多智能体系统要灵活得多，也更接近真实协作。

---

论文给了一张很直观的总流程图，用写论文这个任务串起了注册发现、动态组队、状态切换和子团队展开。

这张图有一个好处：它把 IoA 的卖点集中到了一起。不是“多人讨论”四个字，而是“多人讨论 + 动态分工 + 子团队递归展开 + 协议化消息流转”。

---

从代码看，IoA 到底是怎么落地的

如果只看论文，你会觉得 IoA 是一个“互联网式 Agent 网络”。但看完开源实现后，更准确的描述是：

IoA 当前代码实现的是一个中心化的、多 Agent 即时通讯与任务编排系统。

服务端确实承担了注册中心、路由器和会话管理器的角色

在 im_server/app.py 中，服务端提供了几类核心能力：

• /register：注册 Agent
• /retrieve_assistant：按能力检索 Agent
• /teamup：创建群聊
• /ws/{agent_name}：通过 WebSocket 收发与广播消息

代码上也能直接看到两层关键存储：

• ConfigMilvusWrapper("configs/agent_registry.yaml") 用于 Agent Registry
• AutoStoredDict("database/server/sessions.db") 用于会话管理

这正对应论文里的“注册发现”和“消息路由”设计。

但也要看到，当前实现依然是明显的中心化 Hub-and-Spoke 结构，而不是去中心化网络。

---

论文里的消息协议，在代码里被 concretize 成 AgentMessage

common/types/communication.py 里定义了 AgentMessage，其中包含：

• sender
• comm_id
• next_speaker
• state
• type
• task_id
• task_desc
• task_conclusion
• triggers
• team_up_depth
• max_turns

这和论文附录里的消息协议基本一致，只是代码里把论文中的 group_id 具体实现成了 comm_id，同时又补充了 updated_plan、is_collaborative_planning_enabled 之类字段，说明仓库代码已经开始往“协作规划”方向延伸。

---

组队不是硬编码的，而是通过两个工具让 LLM 决定

im_client/communication/communication_layer.py 里定义了两个组队工具：

• agent_discovery
• team_up

关键逻辑在 _discover_and_teamup()。它不是直接写死“先检索再组队”，而是把这两个工具交给模型，让模型根据目标和已有联系人决定何时继续检索、何时正式建群。

---

“暂停与触发”不是装饰概念，代码里真的有状态维护

IoA 没有停留在“讨论 -> 分任务 -> 结束”的表层流程。

在 TaskManager 中，仓库专门维护了：

• 任务状态
• 待响应成员
• 异步任务 trigger
• trigger 的更新与清理

set_triggers()、update_triggers()、is_triggered() 这几段代码，正是论文里 pause & trigger 状态的工程落地。

这里处理的是一个很现实的问题：异步任务发出去以后，群聊不能一直空转，总得知道该等什么、等到什么时候、等完之后由谁继续往下说。

嵌套组队也不是停留在图示层面

在 _call_tool_agent_and_inform() 里，客户端会先判断一个子任务是否值得继续团队协作：

• 如果当前 agent 支持 nested team
• 且 team_up_depth 没超限
• 就会继续 launch_goal()，把子任务作为一个新的目标发起协作

这意味着论文图里的“子群组递归展开”在代码里不是口头承诺，而是真有运行路径。

IoA 论文里讲“异构 Agent 集成”，听起来很宏大；但看仓库后会发现，它的工程做法相当务实：

• 用 Docker 包装第三方 Agent
• 给它提供统一的 Adapter
• 对外暴露一个足够简单的 run(task_desc) 接口

在 im_client/agents/base.py 和 docs/source/customize/integrate_thirdparty_agent.rst 里，这个思路写得很清楚。

IoA 的“异构集成”并不是要统一所有 Agent 的内部结构，而是统一接入边界。对系统工程来说，这是一种很合理的取舍。

---

论文实验说明了什么

IoA 的实验覆盖面比很多多智能体论文更广。它不是只挑一个 benchmark 证明“我能跑”，而是从四个维度做验证：

• 工具异构：GAIA
• 架构异构：开放式指令 benchmark
• 观测与动作空间异构：RoCoBench
• 知识异构：RAG

4.1 GAIA：工具互补确实能带来收益

在 GAIA 验证集上，IoA 总体分数达到 40.00，略高于 AutoGen 的 39.39，而且在更难的 Level 2 和 Level 3 上更有优势。

这里值得注意的不是“只赢了一点”，而是作者用的并不是特别重型的专用 Agent，而是几个配有不同工具的基础 ReAct Agent。换句话说，IoA 想证明的是：协作层如果设计得当，普通 Agent 的组合也能做出很强的结果。

4.2 对 AutoGPT 和 Open Interpreter 的实验：它真的能接第三方 Agent

开放式指令 benchmark 上，IoA 相比：

• AutoGPT 的总体胜率是 76.5%
• Open Interpreter 的总体胜率是 63.4%

这是整篇论文里最看重的一组结果，因为它最贴近 IoA 的核心主张：把不同生态、不同内部架构的 Agent 拉到同一个协作层里。

4.3 RoCoBench：这套协作机制不只适合“调工具”

在具身协作任务上，IoA 并不是专门为 embodied setting 设计的，但它在五个任务里有四个成功率优于 Roco Dialog。

这组结果的价值在于，它说明 IoA 的长处不只是“会调工具”，还包括任务分配和对话流控制本身具备一定通用性。

4.4 RAG：异构知识源之间的协作是有收益的

在 RAG 任务里，一个亮眼结果是：

• GPT-4 总体 0.611
• IoA + 2 heterogeneous agents 总体 0.610
• IoA + 3 homogeneous agents 总体 0.671

也就是说，基于 GPT-3.5 的 IoA 配置，已经能接近甚至超过 GPT-4 的单模型表现。

这不意味着“多 Agent 一定比更强模型更好”，但至少说明：当知识分布在不同来源时，协作层确实可能弥补单个模型的知识盲区。

4.5 论文还单独测了组队精度

论文不只展示最终任务结果，还额外评估了组队机制本身。

从结果看，嵌套组队场景的 Top@1、Top@10、MR、MRR 都优于常规组队。这个结果和论文方法本身是对得上的：一旦允许在任务推进中继续补充专家，匹配到合适 agent 的概率本来就更高。

4.6 论文也坦率承认了通信成本问题

论文没有把结果写得过于完美，而是直接给出成本分析。

作者发现一个很实际的问题：异步任务增多以后，客户端里的 LLM 容易重复前文、改写前文，导致对话越聊越长，信息增量却不高。

这不是小瑕疵，而是多智能体系统的典型难点。论文给出的数字也很说明问题：

• IoA 总成本约 0.99 美元/任务
• 通信成本约 0.53
• 手工去掉重复后，通信成本可降到 0.28

这个结论非常有价值，因为它把多智能体研究里经常被淡化的一件事摆上了桌面：系统上限不只受推理能力限制，也受通信效率限制。

---

论文真正有价值的地方

我对 IoA 的总体评价是：这篇论文最值得看的，不是它又做了一个多智能体 workflow，而是它开始用更像网络系统和分布式系统的视角看待 Agent 协作。

它真正贡献了三层东西。

它把 Agent 协作问题下沉到了系统层

很多论文研究的是“怎样让 agent 回答更好”，IoA 研究的是“怎样让 agent 互相找到、互相协作、互相等待、互相恢复上下文”。这是更底层的问题。

它把“异构性”当成前提，而不是例外

今天的大模型生态本来就是碎片化的。不同 Agent 用不同工具、不同运行环境、不同接口风格，本来就是常态。IoA 的价值，在于它不是试图消灭这种异构性，而是想在异构性之上建立一层最小协作协议。

它意识到了“协作控制”本身就是性能来源

不是所有提升都来自更强模型。多智能体系统里，相当一部分收益来自更合理的通信协议、更清晰的任务分配和更少的协作摩擦。IoA 至少把这个问题正面提出来了。

---

存在的问题

“Internet-like” 不等于真正的去中心化网络

当前实现里，服务器是注册中心、路由器和会话存储中心。这更像一个中心化 IM 协作平台，而不是分布式自治网络。

所以它更准确的定位应该是：面向分布式 Agent 的中心化协作框架。

安全层更多停留在架构图里

论文在架构图中给了 Security Block，但当前服务端实现基本还没有完整的认证、授权和隔离机制；代码里甚至直接设置了开放的 CORS。所以如果把它当成生产级 Agent 基础设施，显然还差很远。

---

LLM 决策越灵活，系统波动也越大

组队、下一发言者、状态切换都交给 LLM 决策，带来的好处是灵活；代价就是：

• 容易重复沟通
• 容易拖长对话
• 容易在异步阶段做出不理想的继续讨论决策

它更像 research prototype，而不是 production platform

仓库已经很完整，但你依然能明显看出研究代码的特征：

• 许多能力依赖 prompt orchestration
• 安全和治理能力不足
• 扩展方向明确，但工程收敛度有限

把它当研究框架看，会觉得很有启发；把它当企业级系统直接落地，会高估它的成熟度。

---

总结

如果你关心的是下面这些问题，这篇论文很值得读：

• 异构 Agent 如何互联
• 多智能体系统如何支持分布式部署
• 群体协作如何从硬编码流程走向动态调度
• 消息协议、任务状态和协作控制如何形成一个统一系统

我的结论很简单：

IoA 不一定是当前多智能体最强的任务解法，但它是少数真正把“Agent 协作基础设施”当作一等问题来认真设计的工作。

它最重要的意义，不是又证明了“多智能体有用”，而是把讨论往前推了一步：

未来如果 Agent 真会像服务一样大规模存在，我们需要的可能不只是更强的单体模型，而是一层像互联网协议那样的协作中间层。

这正是 IoA 最值得被讨论的地方。

---

参考材料

• 论文：INTERNET OF AGENTS: WEAVING A WEB OF HETEROGENEOUS AGENTS FOR COLLABORATIVE INTELLIGENCE
• 开源仓库：https://github.com/OpenBMB/IoA