A2A法庭开始追踪Agent影响力

近日，开源项目 ProtoLink 在 GitHub 放出了一个名为 AI Courtroom 的示例，用“法庭审理”来呈现多智能体之间的通信、辩论和裁决，并强调整个过程可以回放。项目在开发者社区以“A replayable A2A jury for tracing how agents influence decisions”为题引发关注，核心卖点不是让几个大模型轮流说话，而是把每个 Agent 对最终决策的影响路径保存下来。

**A2A Jury 是一种将多智能体决策过程组织成法庭角色、并支持事后回放与影响追踪的实验性系统。**截至 2026 年 8 月 9 日，它更接近一个面向开发者的可观测性样例，而不是已经完成商业化验证的“AI 陪审团”产品；公开项目也没有给出准确率提升、延迟、Token 消耗或生产环境吞吐等量化数据。

这件事值得关注，因为多智能体系统现在最难回答的问题已经不是“Agent 能不能互相对话”，而是“某个意见为什么进入了最后的答案”。在招聘筛选、信贷审核、采购审批、风控调查和代码合并等高风险场景里，只保存最终文本远远不够，团队还需要知道证据来自哪里、哪个 Agent 改变了判断、反对意见为何被忽略，以及同一案件能否被复盘。

它解决的不是协作，而是协作后的责任问题

**多智能体系统是由多个具备不同角色、工具或模型配置的 Agent 分工完成同一任务的计算系统。**相比让一个大模型从头做到尾，多智能体架构可以安排研究员查资料、分析员形成观点、批评者找漏洞，再由裁决者汇总结论，但它同时把一次推理变成了一串相互影响的决策。

**A2A 是 Agent-to-Agent 的缩写，通常指不同智能体之间进行发现、交换消息、委派任务和返回结果的通信方式。**Google 在 2025 年 4 月首次公开 A2A 协议，希望让不同厂商、不同框架构建的 Agent 具备互操作能力；其核心抽象包括描述能力与认证方式的 Agent Card，以及管理任务生命周期的 Task 等对象。目前可查阅 A2A 官方 GitHub 项目 了解协议演进。

**需要谨慎区分的是，项目名称里的“A2A”不自动等于它已经通过某个正式协议版本的兼容性认证。**AI Courtroom 的公开定位明确指向 Agent 之间的交互与回放，但在没有兼容性测试、协议清单和版本声明的情况下，更准确的说法是“面向 A2A 场景的多智能体法庭”，而不是把它直接认定为 A2A 标准的完整实现。

法庭隐喻在这里相当实用：不同 Agent 不再只是流水线里的匿名节点，而是拥有可辨认角色的参与者；它们提交主张、引用证据、回应质疑，最后再由承担裁决职责的 Agent 或规则层形成结果。相比普通群聊式 Agent，这种结构更容易暴露观点冲突，也更适合把决策过程映射为事件时间线。

**可回放是指系统能够依据已保存的消息、状态、工具结果和执行顺序，重新展示或重新运行一次多智能体决策过程。**这与录屏不同：录屏只能看到界面发生了什么，结构化回放则应当回答某条消息由谁产生、引用了什么上文、触发了哪个状态变化，以及下一名 Agent 为什么获得发言权。

“谁影响了结果”比最终答案更有价值

**影响追踪是对 Agent 的输入如何改变后续消息、投票、状态和最终结论进行关联分析。**例如，风险 Agent 提出“供应商存在关联交易”之后，审计 Agent 补充证据，原本支持采购的两个 Agent 随后改票；这条链路比一句“采购未通过”更有审计价值。

传统 LLM 日志通常以单次调用为中心，开发者可以看到提示词、响应、耗时和 Token 数，却很难跨调用解释“观点是怎样传播的”。当系统同时运行 5 个 Agent、持续 8 轮讨论时，一次结果可能由 40 次以上的模型交互共同形成，单看任何一条调用记录都无法还原整体决策。

A2A Jury 的意义在于把观察单位从“模型调用”提升到了“决策案件”。开发者需要追踪的不只是某次生成是否报错，还包括一条证据被哪些 Agent 看见、哪些 Agent 引用了它、哪个时间点出现共识，以及最终裁决是否过度依赖某一个角色。

这种能力对 Agent 治理尤其关键。多智能体系统表面上有多个独立意见，但如果所有角色使用相同模型、相同训练偏好和高度相似的系统提示词，所谓陪审团可能只是同一个模型换了几件衣服；影响图能够帮助开发者发现某个“权威 Agent”是否长期压制其他角色，也能暴露表面投票背后的意见同源问题。

回放分两种，不能混为一谈

**记录回放是按原始顺序展示已经发生的事件，而执行回放是重新调用模型和工具来复现整次运行。**前者适合审计，通常能够稳定还原历史；后者适合调试，但受模型随机性、外部数据变化和工具状态影响，很难保证逐字一致。

两种回放方式的工程差异非常大：

| 回放类型 | 是否重新调用模型 | 能否逐字复现 | 主要用途 | 主要风险 | |---|---:|---:|---|---| | 记录回放 | 否 | 通常可以 | 审计、演示、故障复盘 | 日志缺字段时无法补救 | | 执行回放 | 是 | 通常不能保证 | 调试、回归测试、策略比较 | 模型版本和外部数据发生变化 | | 分支回放 | 从某个节点开始 | 仅历史部分可以 | 比较不同提示词、模型或裁决规则 | 分支数量和成本快速增长 |

执行回放最容易被误解。即使请求参数完全一致，线上模型也可能发生静默升级；搜索结果、网页内容、数据库记录和时间相关工具也会变化，因此“再次运行”不等于“复现当时”。如果项目只保存 Agent 对话文本，而没有冻结模型版本与工具输出，它能够重放故事，却不能严格重现实验。

**生产级回放至少需要保存模型身份、提示词版本、消息顺序、工具参数、工具结果、状态快照和时间信息。**更完整的事件记录还应包含请求 ID、Agent ID、父事件 ID、任务状态、停止原因、失败重试、Token 用量、延迟，以及用于验证记录未被修改的哈希值。

一个可审计的最小字段集合可以概括为：

• **身份信息：**案件 ID、Agent ID、角色、模型提供方、准确模型名称与版本。
• **上下文信息：**系统提示词版本、可见消息范围、检索结果和引用证据。
• **执行信息：**开始时间、结束时间、工具调用、重试次数和异常状态。
• **决策信息：**主张、置信度、投票、弃权、意见变更及变更理由。
• **关联信息：**父事件、被引用事件、触发事件和最终裁决节点。
• **完整性信息：**事件哈希、签名、日志保留策略和访问审计记录。

它和 LangGraph、AutoGen、CrewAI 不完全是一类东西

**A2A Jury 当前更像一个针对“决策影响链”的垂直示例，而 LangGraph、AutoGen 和 CrewAI 是覆盖编排、状态或角色协作的通用框架。**前者用法庭场景把可观察问题具象化，后几者则允许开发者自行搭建研究、编码、客服和数据处理等多种工作流。

| 项目或方案 | 核心定位 | 状态管理 | 多Agent对话 | 回放侧重点 | 影响追踪表达 | 当前更适合的场景 | |---|---|---|---|---|---|---| | A2A Jury / AI Courtroom | 可回放的决策法庭示例 | 围绕案件与事件组织 | 是 | 辩论、证据与裁决过程 | 强调Agent如何影响结果 | 决策审计、治理原型、演示 | | LangGraph | 有状态Agent工作流框架 | 图状态与检查点 | 支持 | 状态快照、线程和节点执行 | 通常需要自定义分析 | 复杂长流程、人工介入、可恢复执行 | | AutoGen | 多Agent会话与应用框架 | 以会话和运行时为主 | 是 | 会话记录与运行调试 | 通常需要额外建模 | 研究、代码协作、多角色讨论 | | CrewAI | 基于角色与任务的多Agent框架 | Crew与Flow流程状态 | 是 | 任务时间线和Tracing | 通常需要额外建模 | 业务自动化、角色分工工作流 | | 普通LLM日志 | 单次模型调用监控 | 弱 | 否 | 请求与响应 | 基本没有 | 成本、延迟和错误排查 |

LangGraph 的优势是状态机和可恢复执行，开发者可以通过检查点回到工作流中的特定状态；AutoGen 擅长让多个 Agent 以对话形式协作；CrewAI 强调角色、任务与业务流程。A2A Jury 真正有辨识度的地方，是尝试把“意见传播”和“决策形成”变成一等对象，而不是只把 Agent 运行画成一张调用瀑布图。

A2A Jury 暂时还不能凭一个示例取代成熟的可观测平台。公开资料尚未披露大规模并发能力、跨模型评测结果、日志存储成本、权限隔离机制和服务等级，也没有足够数据证明它能让裁决准确率提高多少；团队如果要用于生产，仍需补齐身份认证、数据脱敏、留存策略和告警体系。

真正困难的是影响归因，而不是画一条箭头

**消息先后关系只能证明相关性，不能直接证明某个 Agent 导致了最终决定。**Agent B 在看到 Agent A 的意见后改票，可能是受到 A 说服，也可能是同时看到了新的工具结果；如果系统简单地把“先出现的消息”记为影响来源，就会把时间顺序误当成因果关系。

更可信的影响分析需要结合反事实实验。系统可以从同一检查点创建多个分支：一个分支保留某条意见，另一个分支隐藏该意见，再比较最终投票、理由和置信度是否变化；如果多个重复实验都出现方向一致的变化，才有更充分的依据认为该 Agent 对结果产生了影响。

反事实实验也会迅速推高成本。假设一次案件包含 6 个 Agent、每个 Agent 参与 5 轮讨论，原始运行已有 30 个交互节点；如果对其中 10 个关键节点各运行 3 个分支，就会额外增加 30 组后续推理，实际模型调用量可能达到原来的数倍。因此，生产系统通常只能对高风险节点抽样，而不是为每句话计算完整的因果贡献。

投票同样不等于事实。多个 Agent 达成一致，只能说明在当前提示词、模型和证据条件下形成了共识，不能说明答案一定正确；如果陪审团成员共享同一个基础模型，错误知识和偏见还可能高度相关，多数票反而会把共同幻觉包装成“集体判断”。

法庭日志本身也会成为新的安全边界

**越完整的回放记录越可能包含敏感数据、隐藏提示词和工具凭据。**一个为审计而保存全部上下文的系统，可能同时记录客户身份、内部文档、数据库查询结果和 Agent 的安全策略；如果权限控制不足，回放界面就会从调试工具变成集中式数据泄露入口。

生产部署至少要处理三类风险：第一，按角色限制谁可以查看原始提示词与工具结果；第二，在写入日志前对个人信息和机密字段进行脱敏；第三，对审计事件采用追加写入、哈希链或签名，避免相关人员在事故发生后修改历史记录。

提示词注入也会污染审计链。恶意文档可能要求某个 Agent 忽略证据、伪造引用或诱导其他 Agent 改票，而回放只能告诉团队攻击如何传播，不能自动阻止传播；真正的防护仍依赖内容隔离、工具权限、来源标记和裁决前校验。

判断：方向比“AI法庭”这个演示更重要

**A2A Jury 最有价值的部分不是法官、律师或陪审员的人设，而是把多智能体影响链当成需要保存的数据。**Agent 系统正在从“一个模型调用几个工具”走向跨团队、跨框架甚至跨公司的长时间协作，只记录最终结果已经无法满足调试、合规和责任认定需求。

这个项目目前仍带有明显的原型性质。它没有公开证明法庭式辩论优于简单多数投票、置信度加权或单模型复核，也没有可用于横向比较的价格与性能指标；如果开发者只是处理低风险摘要任务，加入多轮辩论和完整回放可能只会增加延迟、Token 成本与维护复杂度。

但对于会真正改变业务状态的 Agent，回放不是锦上添花。一个能够拒绝贷款、冻结账户、合并代码、下采购单或修改生产配置的系统，必须提供比普通聊天记录更强的解释能力；至少要回答“谁提出了关键证据”“谁批准了动作”“系统当时看到了什么”和“能否从同一状态重新检查”。

A2A Jury 因而更像一个信号：多智能体竞争的下一阶段，不只比较谁能组织更多 Agent，也会比较谁能证明这些 Agent 为什么这样决定。法庭只是界面，真正的产品机会是决策谱系、事件溯源、反事实回放和可验证审计。

参考来源

• ProtoLink：AI Courtroom 示例：本次 A2A Jury 话题的原始项目页面，展示可回放多智能体法庭的示例入口。
• A2A 官方 GitHub 项目：Agent2Agent 协议规范、示例与版本演进的官方开源入口。
• LangGraph GitHub 仓库：有状态 Agent 编排、检查点与可恢复工作流的开源框架。
• Microsoft AutoGen GitHub 仓库：面向多智能体应用与会话协作的开源框架。
• CrewAI GitHub 仓库：以角色、任务和流程为核心的多智能体自动化框架。