代理应该说什么？用于高效多智能体系统的动作-状态通信

TL;DR 多智能体系统中自由文本通信导致token消耗激增，PACT将通信压缩为结构化的行动-状态记录，在维持任务性能的同时显著降低token用量，提升效能成本比。

问题

问题背景

多智能体系统（MAS）正逐步成为编排 LLM 执行复杂任务的主流范式，而智能体间的通信效率——即消息的令牌消耗与信息密度——直接决定系统的推理成本与规模上限。

现有方法的局限

当前 MAS 普遍采用自由形式的自然语言作为智能体间通信载体，但系统设计者通常只关注角色、流程与轮次调度，对消息内容本身的优化很少。本文分析的五种常见策略（传递完整输出、简短摘要、仅结论、仅工件、混合）均暴露出明显短板：

• 完整输出：令牌开销极高，迅速拥塞共享上下文窗口，且下游智能体往往只需要部分关键信息；
• 简短或仅结论：虽节省令牌，但可能丢失下游所需的行动中心信息（action-centered information），且效果高度依赖拓扑结构；
• 仅工件：识别了正确的内容类型，却缺少结构化的交互协议，导致下游解析困难。 综合来看，不存在一种固定策略在所有拓扑中普遍最优，自由形式通信始终在信息完整性与成本之间摇摆。

技术挑战与业界关注度

该问题的核心难点在于：如何在不降低任务完成度的前提下，将智能体的原始输出投影到一个紧凑、结构化且可复用的状态更新消息空间，从而替代冗余的自然语言历史。这要求在通信协议层面对智能体的“行动-状态”进行抽象，而非停留在自然语言提示的浅层压缩。随着 MAS 向生产环境延伸（如自动化编程助手 OpenHands、SWE-agent），令牌成本直接关联商业可行性，业界迫切需要通用、拓扑无关的通信效率优化方案。

行业类比

与微服务架构中通过 gRPC / Protobuf 替换冗长 JSON 文本以提升服务间吞吐的做法相似，这里需要用结构化的行动-状态记录替代自由格式的自然语言，以换取系统级效率。

核心洞察

• **有效通信的核心在于保留以行动为中心的信息 (action-centered information)。** 实验发现，无论传递全文还是仅结论，只要下游代理收到其执行任务所必需的行为状态，系统性能就保持稳定。这一发现将优化目标从“缩短消息”或“全量传递”的简单权衡，转向精确捕获动作必要的上下文状态，为设计通用 MAS 通信协议澄清了方向。
• **PACT 将通信重新定义为公共状态更新问题，用结构化记录取代自由文本。** 不同于事后压缩或固定格式摘要，PACT 在消息进入共享历史前将原始输出投射为紧凑的 action-state 记录，确保下游代理接收规划、动作和结果状态，而无需解析冗余叙述。该方法在不同 MAS 拓扑中均达到更优的性能-成本权衡，优于所有对比的固定通信策略。
• **在生产编码环境中，PACT 大幅节省令牌且不损失解决率。** 在 OpenHands 任务中，PACT 使令牌消耗减少 10% 的同时提升了解决率；在 SWE-agent 上则实现令牌减半且解决率持平。这表明结构化通信不仅能改善基准测试，还能直接降低实际工程系统的推理成本，具备生产部署的实用价值。

方法

输入与问题建模

PACT 的输入是多智能体系统（MAS）中每个智能体在完成当前子任务后输出的原始自然语言响应。这些自由形式的消息直接传递会导致令牌消耗膨胀、上下文窗口耗尽，且不同拓扑（如Split-Evidence 交互和顺序流水线）下最优通信策略各异。

核心机制：将通信重构为公共状态更新

PACT 将 inter-agent communication 视为一个公共状态更新问题（public state-update problem），核心模块是一个协议化投影层，负责将每个智能体的原始输出转化为统一的动作-状态记录（action-state record）。具体流程如下：

1. 信息提取：从原始输出中识别并保留以行动为中心的信息（action-centered information） — 即下游智能体执行后续任务所必需的动作、状态变更、关键中间结果或约束条件。
2. 结构化压缩：依据预定义的 PACT 消息空间（action-state message space），将提取的信息封装为一个紧凑的结构化对象，弃置冗余叙述、对话历史等非必要内容。该消息空间可能包含字段如：
   • 执行的动作类型与参数
   • 环境状态的关键变化
   • 产生的关键成果（artifact）引用
3. 共享历史注入：压缩后的记录替代原始冗长文本进入共享上下文，供后续智能体检索和使用。

输出与效果

PACT 输出的消息体积极小，仅包含协议化的动作-状态记录。实验显示，这使令牌使用量大幅下降，同时在多种 MAS 拓扑上保持或提升任务性能。例如，在 OpenHands 编码平台上，PACT 在 resolve rate 指标持平或提升的前提下，将每解决一个任务的令牌开销降低 10%；在 SWE-agent 上，输入令牌减半仍保持解决率。

与固定通信策略（如传递完整内容、仅传递结论、仅传递工件）相比，PACT 不依赖单一硬编码规则，而是通过公共状态更新的协议抽象，动态适配不同拓扑，同时实现跨越令牌效率与任务性能的最优折衷。

实验

实验设计

本文首先设计两种多智能体系统 (MAS) 拓扑用于诊断分析：

• Setting A — Split-Evidence Interaction：多个来源证据的分离交互任务，智能体需汇总不同来源信息
• Setting B — Sequential Pipeline：顺序流水线对话任务

在这两种设定下，对比五种常用智能体间通信策略：全内容传递、纯结论、纯工件、结构化摘要等，均基于 GPT-4o 和 DeepSeek-V3 实施。随后提出 PACT 并在相同任务及生产级编码工具平台 OpenHands 与 SWE-agent（基于 SWE-bench）上评估，基线为未经压缩的全内容历史通信。

关键发现

• 没有任何固定通信策略在所有拓扑下均最优；有效消息始终保留下游智能体所需的动作中心信息 (action-centered information)。
• PACT 将智能体输出投影为紧凑的动作状态记录后再加入共享历史，在两种 MAS 设定下均实现相近或更强的任务性能 + 大幅 token 节省。
• 在 OpenHands 上，PACT 带来更高解决率，且每个已解决任务的 token 消耗减少约 10%；在 SWE-agent 上，解决率持平，但输入 token 减半。
• 消融实验证明，仅压缩长度不够，必须保留结构化的状态字段才能保持性能。

基线对比解读

全内容通信基线虽信息完整，但冗余严重，浪费上下文并引入无关事实，使后续智能体推理质量下降。PACT 通过将通信视为公共状态更新问题，强制提取动作与状态变化关键信息，丢弃叙述性细节，从而在信息密度上远优于全内容基线。该思路类似状态机共享，与纯压缩或摘要方法形成根本差异——后者常损失关键行动线索。结果表明，多智能体通信的核心不是传递更多文字，而是传递最少但足以更新全局状态的符号化片段。这一原则对大规模 MAS 部署的成本控制与上下文管理具有重要工程意义。

行业影响

落地场景

PACT 可广泛应用于多智能体系统 (MAS) 的通信压缩，尤其适合以下产品与业务：

• 软件工程工具：如自动化代码修复、测试生成、PR 审查的 agent 平台（OpenHands、SWE-agent），PACT 在此类 harness 上已验证可降低 token 消耗且保持或提升解决率。
• 企业工作流自动化：多角色协作的决策流水线（如客户支持系统由意图识别、知识检索、方案生成、人工升级等 agent 组成），PACT 能避免自由文本通信带来的上下文膨胀。
• 复杂规划与推理服务：旅行规划、供应链优化等需要多步骤协商的场景，压缩后的状态记录使系统能处理更长的交互历史。
• 内容生成与审核：多 agent 依次完成撰稿、事实核查、风格润色时，PACT 可大幅削减传递的 token 量。

商业价值

PACT 主要从降本和增效两条线贡献商业价值：

• 推理成本缩减：在多 agent 交互中，PACT 将自由文本压缩为紧凑的 action-state 记录，平均可减少约 10% 的 tokens-per-task，对于基于 API 付费的 LLM 服务，直接转化为推理费用节省。
• 吞吐量与体验提升：节省的上下文窗口可容纳更多历史步骤或并发请求，降低因上下文耗尽导致的截断和重试，提升系统可靠性和用户体验。
• 性能保持或略微增益：PACT 在多数场景下任务性能不降，甚至在个别基准上小幅提高，避免了“降本但降质”的妥协。
• 规模化部署优势：对于 SaaS 或云服务形态的多 agent 平台，token 节省意味着同样集群可服务更多客户，边际收益显著。

与现有产品/工作流的接口

PACT 的集成方式对现有系统侵入性低，适合作为中间件注入：

• Proxy Hook 模式：论文在 OpenHands 和 SWE-agent 上实现了 PACT 作为轻量级 proxy，截获 agent 发出的消息并压缩后再转发给下游 agent，无需改动原有 agent 逻辑。这种设计可适配大多数基于 LangChain、AutoGen 或自定义框架的系统。
• 协议化消息格式：PACT 输出结构化的 action-state 记录，可定义 JSON schema，便于与现有监控、日志、重放工具链集成。
• 拓扑无关性：PACT 对 split-evidence 交互和顺序管道两种拓扑都有效，说明其可泛化到不同的 agent 编排模式。

具体落地 Use Case

1. 电商智能客服：一个客服 MAS 包含 agent A（问题分类）→ agent B（商品推荐）→ agent C（退换货指引）。若无压缩，每次对话可能累积大量冗余描述。注入 PACT 后，agent A 只传递 {action: classify_issue, state: {issue_type: 'return', product_id: 'X'}}，下游根据此精简记录执行，大幅减少每轮对话 token，支持更高并发。

2. 金融合规报告自动生成：流水线式 agent 团队依次完成数据提取、风险分析、报告撰写、合规检查。采用 PACT，每个阶段传递结构化的“分析结果摘要”而非完整草稿，不仅降低推理成本，还能避免原始文本中的敏感信息泄漏风险，因为压缩后的记录仅保留关键事实和行动指令。

局限

• **动作-状态空间定义依赖领域知识**：PACT 要求为每个任务定制协议（protocol），将原始输出映射到紧凑的动作-状态记录。在开放域对话或创造性协作中，清晰界定“动作”与“状态”的边界困难，可能导致信息丢失或协议过度简化，影响下游代理的推理质量。论文仅在两个拓扑结构上验证，未讨论在高度动态、角色切换频繁的 MAS 中的适应性。
• **在部分场景下收益有限**：在 SWE-agent 上，PACT 仅实现了解析中性（resolve-neutral），即任务成功率未提升，仅减少了 token 消耗；而 OpenHands 的提升（resolve rate）也伴随人均 token 降低。这表明 PACT 的效能与底层 agentic harness 的设计耦合，压缩通信未必转化为任务性能的提升，尤其在需要精细上下文的多步推理任务中。此外，论文未分析压缩率与任务难度之间的关系。
• **实验覆盖的模型与基准较为局限**：诊断实验与主实验主要依赖少数几个 LLM（如 GPT-4o、Claude 3.5 Sonnet 等），未涵盖开源小模型、不同架构或强化学习微调后的代理。基准任务集中于分证据问答与软件工程（SWE-bench-Lite），缺乏更广泛的协作推理、规划或科学发现场景的验证。PACT 在不同规模、不同能力模型上的鲁棒性以及跨任务泛化能力尚待系统评估。