{
  "title": "Agent 快被自己「话太多」拖死了——多智能体通信效率的深层危机",
  "url": "https://miaok.ong/posts/agent-multi-agent-communication-crisis/",
  "date": "2026-06-07T09:00:00+08:00",
  "lastmod": "2026-06-07T09:00:00+08:00",
  "type": "posts",
  "kind": "page",
  "language": "zh",
  "description": "现在是 2026 年 6 月。距离 AutoGPT 和 BabyAGI 引爆多智能体热潮已经过去了三年。",
  "keywords": null,
  "tags": ["AI","Agent","多智能体","通信效率","arXiv"],
  "categories": [],
  "author": "孔淼",
  "image": "https://miaok.ong/images/avatar.jpg",
  "content": "\u003ch1 id=\"agent-快被自己话太多拖死了多智能体通信效率的深层危机\"\u003e\n  Agent 快被自己「话太多」拖死了——多智能体通信效率的深层危机\n  \u003ca class=\"heading-link\" href=\"#agent-%e5%bf%ab%e8%a2%ab%e8%87%aa%e5%b7%b1%e8%af%9d%e5%a4%aa%e5%a4%9a%e6%8b%96%e6%ad%bb%e4%ba%86%e5%a4%9a%e6%99%ba%e8%83%bd%e4%bd%93%e9%80%9a%e4%bf%a1%e6%95%88%e7%8e%87%e7%9a%84%e6%b7%b1%e5%b1%82%e5%8d%b1%e6%9c%ba\"\u003e\n    \u003ci class=\"fa-solid fa-link\" aria-hidden=\"true\" title=\"链接到标题\"\u003e\u003c/i\u003e\n    \u003cspan class=\"sr-only\"\u003e链接到标题\u003c/span\u003e\n  \u003c/a\u003e\n\u003c/h1\u003e\n\u003cblockquote\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e2026-06-07 | 深度长文 | 基于 arXiv 2606.05304 + ICLR 2026 SupervisorAgent + 行业框架对照\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003e现在是 2026 年 6 月。距离 AutoGPT 和 BabyAGI 引爆多智能体热潮已经过去了三年。\u003c/p\u003e\n\u003cp\u003e三年间，多 Agent 协作从一个「用 LangChain 串两个 LLM 调用」的实验品，变成了 Claude Code 里 1000 个 Agent 并发执行的工业级范式。 Anthropic 刚发布的 Dynamic Workflows 让用户在一个任务里调度上千个智能体； OpenAI Codex 把软件开发流程拆成了子代理链条； CrewAI 、 AutoGen 、 LangGraph 各有数万 GitHub Star——我们似乎已经默认了「一个 Agent 解决不了的，就放十个 Agent 一起去解决」。\u003c/p\u003e\n\u003cp\u003e但 2026 年 6 月 6 日，一篇来自新加坡科技设计大学（ SUTD ）的 arXiv 论文提出了一个让整个方向需要重新审视的问题：\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e「 What Should Agents Say?」——Agent 之间到底该说什么\u003c/strong\u003e？\u003c/p\u003e\n\u003cp\u003e这个看似简单的问题，戳穿了多智能体系统（ MAS ）当前最深的隐形成本。而结合 ICLR 2026 上的另一篇相关工作、主流框架的通信模式分析、以及推理模型时代的新变量，我们会发现：\u003cstrong\u003eAgent 之间的「话费」正在从优化项变成生存项\u003c/strong\u003e。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"一问题的物理本质-on-的通信灾难\"\u003e\n  一、问题的物理本质： O(n²) 的通信灾难\n  \u003ca class=\"heading-link\" href=\"#%e4%b8%80%e9%97%ae%e9%a2%98%e7%9a%84%e7%89%a9%e7%90%86%e6%9c%ac%e8%b4%a8-on-%e7%9a%84%e9%80%9a%e4%bf%a1%e7%81%be%e9%9a%be\"\u003e\n    \u003ci class=\"fa-solid fa-link\" aria-hidden=\"true\" title=\"链接到标题\"\u003e\u003c/i\u003e\n    \u003cspan class=\"sr-only\"\u003e链接到标题\u003c/span\u003e\n  \u003c/a\u003e\n\u003c/h2\u003e\n\u003cp\u003e假设你有一个由 5 个 Agent 组成的顺序流水线（ Sequential Pipeline ），就像 2026 年最典型的 Agent 编排方式那样：\u003c/p\u003e\n\u003cp\u003e`用户提需求 → Agent A 分析 → Agent B 编码 → Agent C 测试 → Agent D 部署 → Agent E 报告\u003c/p\u003e\n\u003cpre tabindex=\"0\"\u003e\u003ccode\u003e\n在「无约束自然语言通信」模式下，每次交互的具体情况是这样的：\n\n1. Agent A 接收用户需求，调用 LLM 。输出包含：需求理解、分析过程、初始方案建议。共约 2000 Token 。2.Agent B 收到的输入是：用户需求 + Agent A 的全部 2000 Token 输出。它再产生约 3000 Token （代码 + 解释）。3.Agent C 收到的输入是：用户需求 + A 的 2000 Token + B 的 3000 Token 。它再产生约 2500 Token （测试报告）。4.Agent D 的输入是：用户需求 + A(2000) + B(3000) + C(2500)。加上自己的 1500 Token 。5.Agent E 的输入是：用户需求 + A(2000) + B(3000) + C(2500) + D(1500)。加上自己的 1000 Token 。\n\n累计 Token 消耗：每个下游 Agent 处理的上下文呈**线性增长**，但每次调用的 API 成本 = 输入 Token 价格 × 累积上下文大小。当一个任务需要 20 轮交互时，第 20 轮的输入可能已经达到数万 Token——而这些 Token 里起码有 70% 是冗余的。\n\n这还没算推理模型。如果把 Agent C 换成 Gemini 3.1 Pro Thinking ，它单次内部思维链可能就有 8000 Token 的思考过程——而这些全会被塞进 Agent D 和 E 的共享历史里。\n\n**这不是线性增长的问题，是复利**。\n\n---\n\n## 二、 PACT 论文的发现： Agent 不需要写小作文\n\nSUTD 的 *What Should Agents Say?* 是第一个系统性地把「 Agent 间通信内容」作为独立变量来研究的论文。\n\n### 2.1 五种通信策略，没一个能通吃\n\n研究团队在两套 MAS 拓扑（分离证据交互 Split-evidence 和顺序流水线 Sequential Pipeline ）上测试了业界最常见的五种 Agent 间通信模式：\n\n| 策略\n| 做法\n| 优点\n| 致命缺陷\n |\n\n| **全量透传（ Full Pass-through ）**\n| 上游 Agent 的完整输出原样传给下游\n| 不丢信息\n| Token 消耗累积爆炸\n |\n\n| **LLM 摘要透传（ Summary ）**\n| 由另一个 LLM 先做摘要再传递\n| 减少 Token\n| 关键是「谁来做摘要」——又是成本；且摘要质量不稳定\n |\n\n| **关键信息提取（ Structured Extraction ）**\n| 只提取结构化字段传递\n| 紧凑\n| 容易遗漏语境化细节\n |\n\n| **辩论式（ Debate ）**\n| Agent 相互反驳，多轮后收敛\n| 提升答案质量\n| Token 消耗最大——每一轮反驳都在积累历史\n |\n\n| **投票式（ Voting ）**\n| 多个 Agent 独立输出，按多数票决定\n| 简单鲁棒\n| 并行调用成本高，且不解决「为什么要并行」的根本问题\n |\n\n**核心发现：没有一种固定策略在所有场景下最优。但有一个共同规律——在所有有效的案例中，传递的都是「动作-状态」信息（ action-state ），而非「完整自然语言叙事」**。\n\n换句话说： Agent 之间需要的是填表，不是写作文。\n\n### 2.2 PACT ：把 Agent 通信变成状态更新\n\n基于这个发现，研究团队提出了 **PACT （ Protocolized Action-state Communication and Transmission ）**。\n\nPACT 的核心思想非常朴素：**把 Agent 间通信视为「公开状态更新」问题**。 每个非终端 Agent 在完成任务后，其输出不是直接推入共享历史，而是先经过一个「投影层」——被压缩成一个紧凑的 action-state 记录。这条记录只包含三件事：\n\n- **做了什么**（ action ）\n- **产生了什么状态变更**（ state delta ）\n- **下游需要知道什么**（ dependency/flag ）\n\n然后才将这条压缩后的记录写入共享历史，供后续 Agent 消费。\n\n这个思路听起来像什么？**像 Git 的 commit message **。\n\nGit 社区经过几十年演化形成的共识是： commit message 应该是一行 subject + 一段 body ，描述「做了什么」和「为什么做」，而不是把整个 diff 和开发者的思考过程塞进去。没人愿意读一个 3000 行的 commit message 。但多智能体系统目前的做法，就相当于把每个 Agent 的内部 diff 、思考笔记、甚至失败重试记录全部塞给下游。\n\n### 2.3 量化效果：不是锦上添花，是质变\n\n论文在生产级代码 Agent 框架上的实测数据非常有力：\n\n- **OpenHands （生产级开发框架）**：使用 PACT 后，在 token-per-resolved 指标**降低 10%** 的同时，任务的 **resolve rate 提升了**。即：不仅省钱，还更准。\n- **SWE-agent**：在维持同等 resolve rate 的前提下，**输入 Token 消耗减半**。\n\n「 token 减半、成功率不降」——这在任何工程指标上都是第一优先级的事情。\n\n---\n\n## 三、 SupervisorAgent ：另一条路线，同样的目标\n\nICLR 2026 上另一篇入选论文 *Stop Wasting Your Tokens: Towards Efficient Runtime Multi-Agent Systems*，从不同角度攻击了同一个问题。\n\nSupervisorAgent 的方案是：**在关键交互节点插入一个轻量级「监督 Agent 」**，它的工作不是参与业务逻辑，而是纯粹做三件事：\n\n1. **过滤噪声**：把上游 Agent 输出中的废话、重复内容、失败重试记录剥离2.**纠正错误**：在错误信息污染下游上下文之前拦截3.**净化观察结果**：把传递的内容压缩为最小有效信息\n\n关键是，这个监督 Agent 的触发是靠一个**免 LLM 的上下文过滤器（ LLM-free context filter ）**——也就是说，它本身几乎不消耗 Token 。\n\n在 GAIA benchmark （多智能体系统最具挑战性的评测之一）上， SupervisorAgent 让 **Smolagent 框架的平均 Token 消耗降低了 29.68%，成功率零损失**。在数学推理、代码生成、问答等五个额外 benchmark 和多种 SoTA 基础模型上，效果一致。\n\n如果把 PACT 和 SupervisorAgent 放在一起看，它们在说同一件事：**Agent 通信的默认模式（自由自然语言 + 全量透传）是错的**。 区别在于 PACT 从「协议层」解决问题（定义 Agent 应该传什么）， SupervisorAgent 从「运行时层」解决问题（在传递时过滤什么）。两者本质互补。\n\n---\n\n## 四、当前主流框架的通信模式：一个对照检查\n\n这让我们有必要审视一下，当前最流行的几个 Agent 框架在通信这件事上到底是怎么做的。\n\n### CrewAI\n\n强制 Agent 顺序执行（ Sequential ）。什么意思？上一个 Agent 的全部输出，一字不改地作为下一个 Agent 的输入上下文。**这是 O(n²) 的 Token 指数陷阱**。 5 个 Agent 的流水线，第 5 个 Agent 的输入上下文可能已经是第 1 个的 5 倍大。\n\n### AutoGen （微软）\n\n基于群聊（ Group Chat ）模式，默认依赖完整对话历史。随着对话轮次增加，每次 API 调用的上下文呈**二次方爆炸**（所有 Agent 的所有历史发言互相可见）。官方已经意识到了这个问题，引入了 `max_turns` 限制和对话总结机制来截断长尾——但这本质上是「用摘要代替原始输出」，类似论文里测试过的那种方案，效果取决于摘要质量。\n\n### LangGraph\n\n基于图（ Graph ）和状态机。所有 Agent 围绕一个集中的 **`State` 字典**读写，只传递结构化状态而非自由文本。这是目前主流框架中在通信效率上最先进的——它天然实现了 PACT 想要做的事：**用结构化状态替代自然语言聊天**。 但 LangGraph 的局限在于，它要求开发者显式定义 state schema ，这增加了设计成本，也让它在处理高度非结构化的协作场景时不够灵活。\n\n### Claude Code / Codex （ OpenAI ）\n\n这两个 Agentic Coding 工具的 Agent 通信模式比较特殊。它们主要通过 MCP （ Model Context Protocol ）等协议直接与工具交互，内部 Agent 间的通信相对较少。更多时候采用的是「单体超大上下文」策略——把大量信息一次性喂给一个长上下文模型，让模型自己去理解和调度。这在当前阶段有效（因为 Gemini 3.1 Pro 有 200 万 Token 上下文窗口），但同样不可持续——上下文窗口虽然变大了，但注意力密度（ attention density ）会随窗口增大而稀释。\n\n---\n\n## 五、推理模型时代： Thinking Trace 的灾难性放大\n\n如果前面讨论的问题还只是「优化项」，那推理模型的出现把这件事变成了「必选项」。\n\n2026 年， OpenAI GPT-5.5 、 DeepSeek-V4 、 Gemini 3.1 Pro Thinking 、 Claude Opus 4.8 等推理模型都默认或可选地在内部执行长链思维（ Chain-of-Thought ）。单次推理可能产生几千到几万 Token 的隐式思维链：\n\n`\u0026#34;嗯，让我重新考虑一下这个问题。从第一性原理出发...\u0026#34;\n\u0026#34;等一下，我之前的推理有一个漏洞...\u0026#34;\n\u0026#34;实际上，有另一种可能性...\u0026#34;\n\u0026#34;综合考虑以上所有因素，我的结论是...\u0026#34;\n\u003c/code\u003e\u003c/pre\u003e\u003cp\u003e这些 Thinking Trace 本身有价值——它让模型推理更深更准。但问题在于：\u003cstrong\u003e如果 MAS 框架不隔离这些 Trace ，它们会被全量塞进共享历史\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003e后果是灾难性的：\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eToken 账单失控\u003c/strong\u003e：一个 2000 Token 的最终输出背后可能有 8000 Token 的思维链。下游 3 个 Agent 各自还要复制这 8000 Token 的上下文开销。2.\u003cstrong\u003e跨 Agent 污染\u003c/strong\u003e： Agent B 读到 Agent A 的内部纠结过程（「嗯，等一下\u0026hellip;」「其实有一个问题\u0026hellip;」），可能被 A 的犹豫误导，做出不必要的纠偏动作。3.\u003cstrong\u003e注意力稀释\u003c/strong\u003e：研究表明 LLM 对上下文中部的信息处理能力本就不足（ Lost in the Middle ）。当上下文中塞满了别人的思考过程，关键信息被淹没的概率急剧上升。\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003e**PACT 和 SupervisorAgent 方案在推理模型时代的最大价值恰恰在这里：它们强制隔离内部思维链，只在 Agent 间传递最终结论或结构化的 action-state **。 这不是锦上添花——是推理模型参与多 Agent 协作的前提条件。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"六行业正在重新发明-tcp--agent-通信协议简史\"\u003e\n  六、行业正在「重新发明 TCP 」： Agent 通信协议简史\n  \u003ca class=\"heading-link\" href=\"#%e5%85%ad%e8%a1%8c%e4%b8%9a%e6%ad%a3%e5%9c%a8%e9%87%8d%e6%96%b0%e5%8f%91%e6%98%8e-tcp--agent-%e9%80%9a%e4%bf%a1%e5%8d%8f%e8%ae%ae%e7%ae%80%e5%8f%b2\"\u003e\n    \u003ci class=\"fa-solid fa-link\" aria-hidden=\"true\" title=\"链接到标题\"\u003e\u003c/i\u003e\n    \u003cspan class=\"sr-only\"\u003e链接到标题\u003c/span\u003e\n  \u003c/a\u003e\n\u003c/h2\u003e\n\u003cp\u003e2025-2026 年，业界已经意识到 Agent 间通信需要标准化，而不是每个框架自己搞一套。几大协议正在收敛：\u003c/p\u003e\n\u003cp\u003e| 协议\n| 主导方\n| 用途\n| 与通信效率的关系\n|\u003c/p\u003e\n\u003cp\u003e| \u003cstrong\u003eMCP (Model Context Protocol)\u003c/strong\u003e\n| Anthropic\n| Agent ↔ 工具连接\n| 通过 JSON-RPC 标准化工具调用，大幅减少「解释工具怎么用」的 Prompt Token\n|\u003c/p\u003e\n\u003cp\u003e| \u003cstrong\u003eA2A (Agent-to-Agent)\u003c/strong\u003e\n| Google ，已捐 Linux 基金会\n| Agent ↔ Agent 点对点编排\n| 通过 Agent Cards 实现能力交换，定义了「 Agent 发现其它 Agent 」的标准\n|\u003c/p\u003e\n\u003cp\u003e| \u003cstrong\u003eACP (Agent Communication Protocol)\u003c/strong\u003e\n| IBM\n| 基于 Broker 的消息代理\n| 中间人模式，减少点对点复杂度\n|\u003c/p\u003e\n\u003cp\u003e| \u003cstrong\u003eANP (Agent Network Protocol)\u003c/strong\u003e\n| 社区\n| 去中心化 Agent 市场\n| 可信 Agent 发现与能力协商\n|\u003c/p\u003e\n\u003cp\u003e但这些协议目前解决的都是「怎么找 Agent 」「怎么连 Agent 」的问题——\u003cstrong\u003e还没有一个协议在解决「 Agent 连上之后该说什么、该说多少」的问题\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003ePACT 论文的意义正在于此：它试图定义的是通信的\u003cstrong\u003e内容层\u003c/strong\u003e，而不是传输层或发现层。这和 TCP/IP 的四层模型类比很恰当：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eA2A/ACP/MCP 解决的是「传输层」和「应用层」——数据怎么传、 Agent 怎么发现\u003c/li\u003e\n\u003cli\u003ePACT 试图解决的是「表示层」——\u003cstrong\u003e数据该长什么样\u003c/strong\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e就像 HTTP/2 引入头部压缩不是锦上添花而是让 Web 可以规模化的基础技术一样， Agent 通信内容压缩也不会是可有可无的优化——它是 Agent 数量从 5 个增长到 500 个的前提。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"七三点行动建议\"\u003e\n  七、三点行动建议\n  \u003ca class=\"heading-link\" href=\"#%e4%b8%83%e4%b8%89%e7%82%b9%e8%a1%8c%e5%8a%a8%e5%bb%ba%e8%ae%ae\"\u003e\n    \u003ci class=\"fa-solid fa-link\" aria-hidden=\"true\" title=\"链接到标题\"\u003e\u003c/i\u003e\n    \u003cspan class=\"sr-only\"\u003e链接到标题\u003c/span\u003e\n  \u003c/a\u003e\n\u003c/h2\u003e\n\u003cp\u003e如果你正在搭建或运营多 Agent 系统，以下三项检查是立即可执行的：\u003c/p\u003e\n\u003ch3 id=\"1-审计你的-agent-通信日志\"\u003e\n  1. 审计你的 Agent 通信日志\n  \u003ca class=\"heading-link\" href=\"#1-%e5%ae%a1%e8%ae%a1%e4%bd%a0%e7%9a%84-agent-%e9%80%9a%e4%bf%a1%e6%97%a5%e5%bf%97\"\u003e\n    \u003ci class=\"fa-solid fa-link\" aria-hidden=\"true\" title=\"链接到标题\"\u003e\u003c/i\u003e\n    \u003cspan class=\"sr-only\"\u003e链接到标题\u003c/span\u003e\n  \u003c/a\u003e\n\u003c/h3\u003e\n\u003cp\u003e随便抓一个多 Agent 任务的完整对话历史，数一数：有多少内容是冗余的？有多少 Token 是下游 Agent 根本用不上的？有多少「谢谢你的分析」「好的，让我来处理」这种社交礼仪在浪费 Token ？\u003c/p\u003e\n\u003ch3 id=\"2-隔离-thinking-trace\"\u003e\n  2. 隔离 Thinking Trace\n  \u003ca class=\"heading-link\" href=\"#2-%e9%9a%94%e7%a6%bb-thinking-trace\"\u003e\n    \u003ci class=\"fa-solid fa-link\" aria-hidden=\"true\" title=\"链接到标题\"\u003e\u003c/i\u003e\n    \u003cspan class=\"sr-only\"\u003e链接到标题\u003c/span\u003e\n  \u003c/a\u003e\n\u003c/h3\u003e\n\u003cp\u003e如果 Agent 使用了推理模型，确保思维链在传给下游之前被剥离。不要把「嗯，让我想想\u0026hellip;」塞给下一个 Agent——它不需要知道你是如何纠结的。\u003c/p\u003e\n\u003ch3 id=\"3-用结构化状态替代自然语言聊天\"\u003e\n  3. 用结构化状态替代自然语言聊天\n  \u003ca class=\"heading-link\" href=\"#3-%e7%94%a8%e7%bb%93%e6%9e%84%e5%8c%96%e7%8a%b6%e6%80%81%e6%9b%bf%e4%bb%a3%e8%87%aa%e7%84%b6%e8%af%ad%e8%a8%80%e8%81%8a%e5%a4%a9\"\u003e\n    \u003ci class=\"fa-solid fa-link\" aria-hidden=\"true\" title=\"链接到标题\"\u003e\u003c/i\u003e\n    \u003cspan class=\"sr-only\"\u003e链接到标题\u003c/span\u003e\n  \u003c/a\u003e\n\u003c/h3\u003e\n\u003cp\u003e如果你在用 LangGraph ，你已经在做这件事了——但要确保 state schema 的设计是收敛的（只包含下游需要的信息），而不是扩张的（什么信息都往里扔）。如果你在用 CrewAI 或 AutoGen ，考虑在 Agent 之间插入一个类似 SupervisorAgent 的过滤层。\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"结语\"\u003e\n  结语\n  \u003ca class=\"heading-link\" href=\"#%e7%bb%93%e8%af%ad\"\u003e\n    \u003ci class=\"fa-solid fa-link\" aria-hidden=\"true\" title=\"链接到标题\"\u003e\u003c/i\u003e\n    \u003cspan class=\"sr-only\"\u003e链接到标题\u003c/span\u003e\n  \u003c/a\u003e\n\u003c/h2\u003e\n\u003cp\u003e2023 年的问题是「怎么让多个 Agent 一起工作」。\u003c/p\u003e\n\u003cp\u003e2024 年的问题是「怎么让多个 Agent 高效地一起工作」。\u003c/p\u003e\n\u003cp\u003e2025 年的问题是「怎么让 1000 个 Agent 高效地一起工作」。\u003c/p\u003e\n\u003cp\u003e2026 年， PACT 和 SupervisorAgent 这两篇论文告诉我们：\u003cstrong\u003e答案不在于更好的编排——在于更少的废话\u003c/strong\u003e。\u003c/p\u003e\n\u003cp\u003eAgent 通信协议可能是下一个基础设施级的机会。就像 TCP/IP 定义了互联网节点如何握手，\u003cstrong\u003eAgent Communication Protocol 的「表示层」将定义 AI 代理如何在群体中高效协作\u003c/strong\u003e。 而 PACT 这篇论文，可能是这个方向上最早的一块里程碑。\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003e\u003cstrong\u003e参考来源\u003c/strong\u003e：\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003eChen Huang et al., \u003cem\u003eWhat Should Agents Say? Action-state Communication for Efficient Multi-Agent Systems\u003c/em\u003e, arXiv: 2606.05304, 2026-06-06. SUTD.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cem\u003eStop Wasting Your Tokens: Towards Efficient Runtime Multi-Agent Systems\u003c/em\u003e, ICLR 2026. SupervisorAgent.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003e\u003cem\u003eA Survey of Agent Interoperability Protocols: MCP, ACP, A2A, and ANP\u003c/em\u003e, arXiv: 2505.02279, 2025.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eAnthropic, Claude Code Dynamic Workflows, 2026.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eOpenAI, Codex Agent Architecture, 2026.\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003ePACT 开源实现： \u003ca href=\"https://github.com/iNLP-Lab/PACT\"  class=\"external-link\" target=\"_blank\" rel=\"noopener\"\u003ehttps://github.com/iNLP-Lab/PACT\u003c/a\u003e\u003c/p\u003e\n\u003c/li\u003e\n\u003c/ul\u003e\n",
  "wordCount": 934,
  "readingTime": 5,
  "tableOfContents": "\u003cnav id=\"TableOfContents\"\u003e\n  \u003cul\u003e\n    \u003cli\u003e\u003ca href=\"#一问题的物理本质-on-的通信灾难\"\u003e一、问题的物理本质： O(n²) 的通信灾难\u003c/a\u003e\u003c/li\u003e\n    \u003cli\u003e\u003ca href=\"#六行业正在重新发明-tcp--agent-通信协议简史\"\u003e六、行业正在「重新发明 TCP 」： Agent 通信协议简史\u003c/a\u003e\u003c/li\u003e\n    \u003cli\u003e\u003ca href=\"#七三点行动建议\"\u003e七、三点行动建议\u003c/a\u003e\n      \u003cul\u003e\n        \u003cli\u003e\u003ca href=\"#1-审计你的-agent-通信日志\"\u003e1. 审计你的 Agent 通信日志\u003c/a\u003e\u003c/li\u003e\n        \u003cli\u003e\u003ca href=\"#2-隔离-thinking-trace\"\u003e2. 隔离 Thinking Trace\u003c/a\u003e\u003c/li\u003e\n        \u003cli\u003e\u003ca href=\"#3-用结构化状态替代自然语言聊天\"\u003e3. 用结构化状态替代自然语言聊天\u003c/a\u003e\u003c/li\u003e\n      \u003c/ul\u003e\n    \u003c/li\u003e\n    \u003cli\u003e\u003ca href=\"#结语\"\u003e结语\u003c/a\u003e\u003c/li\u003e\n  \u003c/ul\u003e\n\u003c/nav\u003e",
  "isDraft": false
}