PatchBoard：基于模式的状态变更机制，用于可靠且可审计的LLM多智能体协作

# PatchBoard：基于模式的状态变异，实现可靠且可审计的LLM多智能体协作
来源：https://arxiv.org/html/2605.29313
Shuyu Zhang Yaqi Shi Lu Wang 计算机科学与技术学院 西安电子科技大学 西安，中国 wanglu@xidian\.edu\.cn

###### 摘要

大语言模型多智能体系统通常通过自然语言对话或松散结构的共享内存进行协调，这使得中间状态难以验证、归因和审计。我们引入了PatchBoard，一种基于模式的协作架构，它用经过验证的JSON补丁变异替换了智能体间的对话，这些变异作用于共享的结构化状态。一个架构智能体构建特定于任务的模式和工作流规则，而一个确定性内核在事务性地提交每个提议的状态变异之前，根据模式约束、角色特定的写入合约和运行时不变性对其进行验证。在630个匹配的ALFWorld情节中，PatchBoard实现了84.6%的成功率，而LangGraph为30.8%，Flock为61.6%，同时将每个成功任务的令牌消耗降低至45.5k，相比之下，LangGraph和Flock分别为368.3k和64.2k。

PatchBoard：基于模式的状态变异，实现可靠且可审计的LLM多智能体协作

Shuyu Zhang Yaqi Shi Lu Wang††thanks：通讯作者。计算机科学与技术学院 西安电子科技大学 西安，中国 wanglu@xidian\.edu\.cn

## 1 引言

大语言模型正越来越多地被用作自主智能体，这些智能体能够规划、推理、调用工具、与环境交互，并通过反馈修正其行为（Yao et al., 2023b (https://arxiv.org/html/2605.29313#bib.bib34)；Schick et al., 2023 (https://arxiv.org/html/2605.29313#bib.bib22)；Shinn et al., 2023 (https://arxiv.org/html/2605.29313#bib.bib23)；Yao et al., 2023a (https://arxiv.org/html/2605.29313#bib.bib35)；Wang et al., 2024a (https://arxiv.org/html/2605.29313#bib.bib27)）。随着任务变得更长、更复杂，一个自然的扩展是将多个智能体组织成角色专精的团队。在这样的系统中，不同的智能体通过多轮交互进行协调。具有代表性的系统，如AutoGen、CAMEL、ChatDev、MetaGPT和AgentVerse，表明多智能体协作可以改进任务分解，并支持跨推理、软件工程、模拟和工具使用场景的复杂工作流（Wu et al., 2024a (https://arxiv.org/html/2605.29313#bib.bib1)；Li et al., 2023 (https://arxiv.org/html/2605.29313#bib.bib16)；Qian et al., 2024 (https://arxiv.org/html/2605.29313#bib.bib19)；Hong et al., 2024 (https://arxiv.org/html/2605.29313#bib.bib11)；Chen et al., 2024 (https://arxiv.org/html/2605.29313#bib.bib6)；Wang et al., 2024b (https://arxiv.org/html/2605.29313#bib.bib28)）。这些系统中的主要协调接口是自然语言，它很有吸引力，因为它匹配LLM的原生输入-输出格式，并使智能体通信灵活且富有表现力。

然而，自然语言通信在长期和有状态的协作中成为了一个脆弱的基石。对话历史随着轮次增加而增长，混合了任务事实与元讨论和修复尝试，并且通常不清楚哪些中间输出应该被视为已提交的状态。下游智能体可能会将一个未经验证的观察结果、过时的计划、格式错误的中间声明或失败的修复尝试，当作可靠的任务状态来读取。一旦这些信息进入共享上下文，后续的智能体可能会通过额外的推理、工具调用或环境操作来放大该错误。这个问题在协作环境中尤其有害，因为失败并非局限于单个模型调用。一个被污染了的中间状态可能会悄无声息地影响所有后续智能体。

现有工作试图通过使智能体协调更加明确来解决这些问题。一些系统使用工作流图、规划器或验证函数来约束执行（LangChain，2024 (https://arxiv.org/html/2605.29313#bib.bib15)；Zhang et al., 2025 (https://arxiv.org/html/2605.29313#bib.bib36)）。其他系统则要求智能体生成或重用可执行程序和技能，从而实现紧凑且可组合的控制策略（Wang et al., 2024a (https://arxiv.org/html/2605.29313#bib.bib27)；Yang et al., 2025b (https://arxiv.org/html/2605.29313#bib.bib33)）。另一些基于黑板架构的系统则通过共享内存来协调智能体，允许独立的工作者读取和更新一个公共状态（Hayes-Roth, 1985 (https://arxiv.org/html/2605.29313#bib.bib10)；Salemi et al., 2025 (https://arxiv.org/html/2605.29313#bib.bib21)）。诸如LMQL和Outlines之类的结构化生成方法进一步帮助模型产生遵循指定格式的输出（Beurer-Kellner et al., 2023 (https://arxiv.org/html/2605.29313#bib.bib3)；Willard 和 Louf, 2023 (https://arxiv.org/html/2605.29313#bib.bib29)）。这些方法相比无约束的对话有所改进，但它们留下了一个重要的空白。基于工作流和代码的方法仍然要求运行时信任生成的程序或控制逻辑，而黑板内存本身并不能判断一个更新是否类型正确、是否经授权、是否非过时、或者是否安全可提交。结构化输出有助于格式化，但仅靠格式化并不定义模型建议与已提交的共享状态之间的系统级边界。

本文提出了PatchBoard，一种基于模式的通信基础，用于实现可靠且可审计的LLM多智能体协作。PatchBoard用经过验证的JSON补丁变异替换了无限制的智能体间对话，这些变异作用于一个共享的JSON状态（Bryan 和 Nottingham, 2013 (https://arxiv.org/html/2605.29313#bib.bib20)）。一个架构智能体定义任务模式、工作者合约、上下文预算和工作流规则（Bourhis et al., 2017 (https://arxiv.org/html/2605.29313#bib.bib12)），而一个确定性内核则验证并事务性地提交仅经授权的状态更新。这使得协作变得明确、可归因和可重放，防止格式错误或未经授权的输出悄然进入共享内存。在ALFWorld（Shridhar et al., 2021 (https://arxiv.org/html/2605.29313#bib.bib24)）上，PatchBoard在630个匹配的情节中实现了84.6%的成功率，而LangGraph为30.8%，Flock为61.6%。它还实现了最低的标准化成本，每个成功任务需要45.5k个令牌，相比之下LangGraph为368.3k，Flock为64.2k。

我们做出以下贡献：

- • 我们将LLM多智能体协作形式化为对共享结构化状态的经过验证的变异，使用受限的JSON补丁接口使智能体间通信变得明确、类型化且可审计。
- • 我们设计了一个确定性内核，用于验证提议的更新，强制执行模式和角色特定的写入约束，构建有预算的上下文视图，事务性地提交已接受的补丁，并记录可重放的事务日志。
- • 我们构建了一个完整的PatchBoard原型，并在长时域交互任务上对其进行了评估，包括黑板控制、消融实验、敏感性分析、故障注入以及一项诊断性问答研究，该研究阐明了结构验证与语义支持之间的界限。

## 2 相关工作

#### LLM多智能体协调。

近期的LLM多智能体系统将复杂任务分解为角色专精的智能体，这些智能体通过明确的交互协议进行通信、批评和协调。AutoGen和AgentScope为组合基于对话或消息传递的智能体提供了通用基础设施（Wu et al., 2024a (https://arxiv.org/html/2605.29313#bib.bib1)；Gao et al., 2024 (https://arxiv.org/html/2605.29313#bib.bib2)），而ChatDev和MetaGPT则通过聊天链或SOP式工作流实例化了基于角色的软件开发协作（Qian et al., 2024 (https://arxiv.org/html/2605.29313#bib.bib19)；Hong et al., 2024 (https://arxiv.org/html/2605.29313#bib.bib11)）。最近的分析进一步表明，协调失败、模糊的交接和冗余通信仍然是基于LLM的多智能体系统中的核心挑战（Cemri et al., 2025 (https://arxiv.org/html/2605.29313#bib.bib4)）。这一系列工作激发了将通信基础本身视为多智能体设计中的一等对象的动机。

#### 结构化工作流与感知验证的编排。

越来越多的工作通过图、状态机、语言模型程序或自动优化的工作流使智能体执行更加明确。LangGraph将智能体应用表示为有状态图（LangChain, 2024 (https://arxiv.org/html/2605.29313#bib.bib15)）；StateFlow将LLM任务求解公式化为状态驱动的工作流（Wu et al., 2024b (https://arxiv.org/html/2605.29313#bib.bib30)）；DSPy将LM流水线抽象为可优化的声明性程序（Khattab et al., 2024 (https://arxiv.org/html/2605.29313#bib.bib14)）；SGLang则针对结构化语言模型程序的高效执行（Zheng et al., 2024 (https://arxiv.org/html/2605.29313#bib.bib37)）。最近诸如AFlow和VeriMAP等系统进一步探索了自动化工作流生成和感知验证的多智能体规划（Zhang et al., 2025 (https://arxiv.org/html/2605.29313#bib.bib36)；Xu et al., 2026 (https://arxiv.org/html/2605.29313#bib.bib38)）。这些工作展示了将智能体协调从自由格式的对话转向明确控制结构的价值。

#### 共享内存、黑板与智能体记忆。

黑板架构提供了一种经典机制，通过共享状态协调独立的知识源（Hayes-Roth, 1985 (https://arxiv.org/html/2605.29313#bib.bib10)；Penny, 1986 (https://arxiv.org/html/2605.29313#bib.bib17)）。这个想法最近在LLM多智能体系统中重新出现，其中黑板风格的内存支持动态智能体选择、共享信息发现和事件驱动协作（Han 和 Zhang, 2025 (https://arxiv.org/html/2605.29313#bib.bib9)；Salemi et al., 2025 (https://arxiv.org/html/2605.29313#bib.bib21)）。与此同时，智能体记忆系统研究了如何存储、链接和检索长期观察结果，以支持跨交互的持久行为（Packer et al., 2023 (https://arxiv.org/html/2605.29313#bib.bib18)；Xu et al., 2025 (https://arxiv.org/html/2605.29313#bib.bib31)）。这些工作强调了持久共享状态的重要性，同时未明确说明在长时域协作中应如何更新、授权和审计这种状态。

#### 结构化输出、事务与语义验证。

结构化生成技术使用语法、模式或编程接口约束LLM输出，减少了机器消费输出中的格式错误（Beurer-Kellner et al., 2023 (https://arxiv.org/html/2605.29313#bib.bib3)；Willard 和 Louf, 2023 (https://arxiv.org/html/2605.29313#bib.bib29)；Zheng et al., 2024 (https://arxiv.org/html/2605.29313#bib.bib37)；Geng et al., 2025 (https://arxiv.org/html/2605.29313#bib.bib7)）。相关系统工作为LLM智能体带来了更强的运行时保证：SagaLLM研究多智能体规划的上下文管理、验证和事务保证（Chang 和 Geng, 2025 (https://arxiv.org/html/2605.29313#bib.bib5)），而最近的运行时治理工作强调了自主智能体基于路径的策略执行（Kaptein et al., 2026 (https://arxiv.org/html/2605.29313#bib.bib13)）。最后，基于证据的问答和事实验证基准，如HotpotQA、FEVER和MuSiQue，评估了生成的声明是否有证据支持（Yang et al., 2018 (https://arxiv.org/html/2605.29313#bib.bib32)；Thorne et al., 2018 (https://arxiv.org/html/2605.29313#bib.bib25)；Trivedi et al., 2022 (https://arxiv.org/html/2605.29313#bib.bib26)）。这些线索共同将结构化输出控制、事务执行和语义验证联系起来。

总体而言，PatchBoard通过将协作变为一系列基于模式、经角色授权、可重放的状态变异，推动了这一方向的发展，为多智能体系统提供了更严格的运行时边界，以实现可靠且可审计的协调。

## 3 方法

参考图注图1：PatchBoard架构。架构智能体将用户请求编译成一个任务蓝图，其中包含全局状态模式、工作者合约、工作流规则和上下文预算。确定性内核维护全局状态树，构建有界状态视图，验证工作者提议的JSON补丁，事务性地提交已接受的更新，并安排后续工作者的调用。工作者通过经过模式验证的变异与共享状态交互。### 3.1 方法概述

PatchBoard将多智能体协作形式化为一个在共享结构化状态上的闭环状态转换循环。如图1 (https://arxiv.org/html/2605.29313#S3.F1)所示，一个架构智能体首先将用户请求转换为一个任务蓝图，该蓝图指定了全局状态模式、工作者合约、上下文预算和工作流规则。在蓝图经过验证后，运行时协调由一个确定性内核处理，该内核初始化全局状态，构建有界的工作者视图，验证JSON补丁提案，提交已接受的补丁，记录事务日志，并根据已提交的状态事件调度未来的工作者。

令 St\mathcal{S}_{t} 表示步骤 tt 的全局状态树。一个手工制作的蓝图元模式 Σmeta\Sigma_{\mathrm{meta}} 定义了架构智能体生成的蓝图的合法结构。一个被接受的蓝图 B\mathcal{B} 实例化了一个任务特定的模式 Σ\Sigma、一组工作者 A\mathcal{A} 和工作流规则 R\mathcal{R}。模式 Σ\Sigma 定义了 St\mathcal{S}_{t} 的有效结构和不变量，而 R\mathcal{R} 将已提交的状态事件映射到未来的工作者调用。对于一个工作者 a∈Aa\in \mathcal{A}，内核具体化一个有界视图 Vta\mathcal{V}_{t}^{a} 并接收一个候选补丁 Δta\Delta_{t}^{a}。

内核是唯一能够修改已提交状态的组件。令 WaW_{a} 表示工作者 aa 的写入合约，令 ⊥\bot 表示补丁应用失败。内核首先将候选补丁应用于当前状态的临时副本，

S^t+1\displaystyle\hat{\mathcal{S}}_{t+1}=Apply(St,Δta),\displaystyle=\mathsf{Apply}(\mathcal{S}_{t},\Delta_{t}^{a}),\(1\)Acceptta\displaystyle\mathsf{Accept}_{t}^{a}=Syntax(Δta)∧Auth(Δta,Wa)\displaystyle=\mathsf{Syntax}(\Delta_{t}^{a})\land\mathsf{Auth}(\Delta_{t}^{a},W_{a})∧(S^t+1≠⊥)∧ValidΣ(S^t+1)\displaystyle\quad\land\;(\hat{\mathcal{S}}_{t+1}\neq\bot)\land\mathsf{Valid}_{\Sigma}(\hat{\mathcal{S}}_{t+1})∧InvB(St,Δta,S^t+1).\displaystyle\quad\land\;\mathsf{Inv}_{\mathcal{B}}(\mathcal{S}_{t},\Delta_{t}^{a},\hat{\mathcal{S}}_{t+1}).这里 Acceptta\mathsf{Accept}_{t}^{a} 表示工作者 aa 的补丁在步骤 tt 是否被接受，而 InvB\mathsf{Inv}_{\mathcal{B}} 表示由蓝图 B\mathcal{B} 注册的运行时不变量。被接受的补丁作为事务提交；被拒绝的补丁会被记录，但不改变已提交的状态。这分离了模型生成的提议与接受的系统状态。完整的内核伪代码在附录A (https://arxiv.org/html/2605.29313#A1)中提供。

### 3.2 架构智能体与任务蓝图

架构智能体在任务初始化时被调用一次。给定一个用户请求，它生成一个蓝图 B\mathcal{B}，该蓝图在任何工作者被调用之前定义了协作结构。蓝图包含任务模式 Σ\Sigma、工作者规格、上下文预算和工作流规则 R\mathcal{R}。这些字段决定了共享状态的布局、可能参与该任务的角色、每个工作者可以修改的状态区域，