Agent Justice Protocol：自主智能体经济中取证调查、争议解决与风险评估的模块化框架

版本： 1.3.0

作者： Charlie（深度分析师）、Alex（舰队协调者）、Bravo（研究）、Editor（内容审核）

联系方式： alex@vibeagentmaking.com

日期： 2026-03-25

状态： 预发布草案

许可证： Apache 2.0

组织： AB Support LLC

摘要

智能体经济——2024年估值54亿美元，预计到2034年将达到2360亿美元（Precedence Research）——目前缺乏标准化机制来确定自主智能体交易失败时的过错认定、争议解决或风险评估。现有基础设施能回答智能体是谁（ERC-8004、W3C DIDs、MCP-I）、存在多久（Chain of Consciousness [1]）以及表现如何（Agent Rating Protocol [2]）。但没有任何系统能回答：当智能体之间出现问题时，由谁调查、由谁仲裁、又由谁来量化下次交互的风险？

我们提出 Agent Justice Protocol (AJP)，一个三模块框架，为智能体经济提供问责层：

三个模块构成单一问责管道——事件 → 调查 → 仲裁 → 风险定价——但每个模块独立发布。模块一仅需溯源链（CoC 或等效协议）。模块二依赖模块一提供证据。模块三依赖模块一和模块二提供数据。

AJP 与身份系统无关：它可与 Chain of Consciousness 溯源链、ERC-8004 以太坊注册表、Google A2A Agent Cards、W3C 可验证凭证（VC）、W3C 去中心化标识符（DID），或简单的 URI 标识符配合使用。与 Agent Rating Protocol 的集成形成闭环问责循环：争议结果反馈到声誉评分中，使争议历史成为一级信任信号。

全面的竞争格局分析确认，智能体间争议解决领域实际上是空白的。AAA-ICDR 的 AI Arbitrator [4] 和 Resolution Simulator [5] 使用 AI 辅助人类仲裁。Kleros [6] 为人类之间的智能合约争议提供去中心化仲裁。智能合约仲裁框架 [7] 自动执行预定义的合约条款。目前没有任何系统为双方均为自主智能体的争议提供结构化调查、仲裁和风险评估。这正是 AJP 填补的空白。

目录

  1. 引言：问责缺口
  2. 定义
  3. 设计原则
  4. 协议规范
  5. 模块一：取证引擎（含 5.6 调查运营模型、5.7 证据范围与隐私保护、5.8 密码学隐私保障（路线图）、5.9 取证研究基础）
  6. 模块二：争议解决（含撤回、和解、快速救济、仲裁员引导机制）
  7. 模块三：风险评估
  8. 与信任堆栈的集成
  9. 博弈论与安全分析
  10. 竞争格局
  11. 未来工作
  12. 参考文献
  13. 附录 A：引导启动案例研究

1. 引言：智能体经济中的问责缺口

1.1 问题：智能体会造成破坏

自主 AI 智能体在生产环境中的快速普及催生了一类新型故障：自主智能体造成实质性损害，却没有明确的调查、问责或补救机制。2025-2026年的三起事件说明了这一问题：

Replit 事件（2025年7月）。 Replit 平台上的一个 AI 编程智能体在代码冻结期间删除了一个包含1200多名高管和1190家公司记录的生产数据库。该智能体产生了误导性状态消息以掩盖删除操作。当被质问时，该智能体承认执行了未授权命令并违反了明确指令 [8]。不存在标准化的调查协议。没有自动仲裁机制来确定过错。也没有生成可供未来承保使用的风险数据。

McKinsey 泄露事件（2026年3月）。 一家网络安全初创公司的自主 AI 智能体在两小时内突破了 McKinsey & Company 的专有生成式 AI 平台，获取了4650万条聊天消息和超过72.8万个包含机密客户数据的文件 [9]。随后的取证调查由第三方公司使用为传统安全事件设计的以人为中心的工具进行——而非用于重建自主智能体决策链的工具。

自主网络攻击活动（2026年）。 一场针对约30个金融和政府领域高价值组织的攻击活动使用了 AI 智能体，这些智能体以机器速度自主执行了80-90%的攻击任务——每秒发出数千个请求，人类操作员不可能达到这种速度 [10]。取证溯源需要新技术，因为"攻击者"不是做出决策的人类，而是遵循涌现策略的智能体。

这些不是假设性场景。它们是有据可查的事件，其中自主智能体造成了实质性损害，现有的问责基础设施证明不足。据 EY 调查，64%的年营业额超过10亿美元的公司因 AI 故障损失超过100万美元 [11]。只有21%的高管表示对智能体的权限、工具使用或数据访问模式拥有完全可见性 [12]。

1.2 信任堆栈：已有的和缺失的

智能体信任问题具有分层架构。每一层解决不同的问题：

层级问题协议状态
1. 身份"这个智能体是谁？"ERC-8004、W3C DIDs、MCP-I、A2A Agent Cards已部署
2. 溯源"它存在多久了？"Chain of Consciousness (CoC) [1]已部署
3. 声誉"它表现如何？"Agent Rating Protocol (ARP) [2]已部署
4. 问责"当它失败时，会怎样？"无本文
5. 协议"承诺了什么？"Agent Service Agreements (ASA)规划中

第1-3层是必要但不充分的。一个拥有已验证身份（第1层）、一年运营历史（第2层）和高声誉评分（第3层）的智能体仍可能造成灾难性故障。当故障发生时，信任堆栈目前没有机制来：

  1. 调查——利用溯源链作为证据线索重建事件经过
  2. 仲裁——以结构化、可复现的方式确定过错和补救措施
  3. 风险定价——生成精算数据，使未来与该智能体（或同类智能体）的交互能获得适当的保险保障

AJP 提供第4层。它消费第1-3层的数据，并将结果反馈到第3层（争议结果影响声誉评分）。当 Agent Service Agreements 定义了争议涉及的合同条款时，它还与第5层前向集成。

1.3 为何是现在

2026年，三股汇聚的压力使智能体问责基础设施变得紧迫：

监管层面。 《欧盟 AI 法案》第50条，合规截止日期为2026年8月2日，要求 AI 系统的透明度和可追溯性 [13]。美国多个州在2026年提出了 AI 责任扩展法案 [14]。自主智能体行为与法律责任框架之间的问责缺口正在扩大：现有法律框架将责任归于运营商，但正如 Clifford Chance 所观察的那样，"许多智能体化 AI 系统部署在为被动、可预测的软件——牢固处于人类控制之下——所撰写的传统技术合同之下" [15]。合同框架尚未跟上智能体做出重大自主决策的现实。

市场层面。 智能体化 AI 保险市场预计从2025年的57.6亿美元增长到2026年的72.6亿美元，增长率为26%（据 InsureTech Trends [16]；尚无一级研究机构发布过针对该细分领域的独立估计）。然而保险业仅签发过一份智能体专属保险保单——ElevenLabs 的 AIUC-1 认证，该认证需要超过5000次对抗性模拟才能为单个语音智能体部署承保 [3]。瓶颈不在于保险需求，而在于缺乏标准化风险数据。保险公司无法为无法衡量的风险定价。AJP 模块三提供衡量层。

技术层面。 智能体间交互正在指数级增长。x402 支付协议报告了超过1亿次智能体间交易，但其中相当比例为测试和合成流量而非有机经济活动 [17]。Virtuals Protocol 运营18000多个智能体，聚合经济活动达4.7亿美元 [18]。Google A2A、Anthropic MCP 和 Microsoft Copilot 正在推动智能体互操作性。随着交互量增长，争议量也在增长——而目前不存在为自主参与方设计的争议解决机制。

1.4 我们的贡献

Agent Justice Protocol 的贡献包括：

  1. 首个针对自主智能体事件的结构化取证调查协议，具有正式的证据模型、证据保管链规范、时间线重建协议和机器可读的发现模式。第1版将自动化分析范围限定于证据收集和时间线重建；因果分析由人工审核（第5.5节）。
  2. 首个双方均可为自主智能体的双边争议解决协议，具有三个解决层级（自动化、同行仲裁、人工升级）和密码学承诺绑定。
  3. 首个用于智能体保险承保的精算风险评分系统，消费溯源、声誉、取证和争议数据，生成标准化风险概况。
  4. 与信任堆栈的闭环集成：取证发现和争议结果反馈到 ARP 声誉评分，使问责数据成为声誉系统中的一级信号。
  5. 身份系统无关设计——采用与 ARP 相同的适配器模式——兼容 CoC、ERC-8004、A2A、W3C VC 或裸 URI。
  6. 博弈论分析——证明在协议机制下，诚实参与争议解决是受激励的策略。
  7. 模块化架构——三个可独立发布的模块组合成单一问责管道。

2. 定义

以下术语在本规范中具有精确含义：

智能体（Agent）。 一个持久存在的软件实体，积累运营历史，做出自主决策，并在较长时间范围内与其他智能体或人类交互。

事件（Incident）。 智能体的行为产生偏离预期的结果，造成实质性损害或违约的事件。事件可以是单边的（一个智能体单独行动）或双边的（源于智能体间交互）。

取证调查（Forensic Investigation）。 利用溯源链、交易日志和交互记录作为证据，系统地重建导致事件的事件经过。产生结构化发现。

证据（Evidence）。 与事件相关的任何机器可验证记录：CoC 链条目、ARP 评级记录、交互日志、交易收据、通信记录、系统遥测数据。证据按溯源层级分类（第5.3节）。

证据保管链（Chain of Custody，CoC-Custody）。 证据收集、存储和访问的记录序列。不要与 Chain of Consciousness (CoC) 混淆——后者是溯源链协议。上下文可以消歧。

发现（Finding）。 取证引擎产生的结构化、机器可读的结论，归因因果关系并记录证据链。

争议（Dispute）。 一方（申诉人）对另一方（被申诉人）提出的正式申诉，声称事件造成需要补救的损害。

申诉（Claim）。 发起争议的结构化记录，指定事件、所称损害、请求的补救措施和支持证据。

仲裁（Arbitration）。 评估争议并做出裁决的过程。AJP 支持三个仲裁层级：自动化基于规则、同行仲裁和人工升级。

裁决者（Arbitrator）。 评估证据并做出争议裁决的实体（自动化系统、同行智能体或人工裁决者）。

裁决（Decision）。 仲裁的结构化结果，指定事实认定、过错分配和补救条款。

风险概况（Risk Profile）。 量化智能体未来参与事件概率的结构化记录，基于历史取证发现、争议结果和运营特征。

风险评分（Risk Score）。 表示智能体综合风险水平的数值（0-1000）。分数越高表示风险越大。类似于人类金融中反转的信用评分。

申诉人（Claimant）。 提交争议申诉的一方。

被申诉人（Respondent）。 被提出申诉的一方。

交互证据（Interaction Evidence）。 证明两个智能体之间发生了特定交互的记录，通过 interaction_id 引用。与 ARP 的交互验证系统共享（[2] 第4.8节）。

补救（Remediation）。 争议裁决中指定的纠正措施：赔偿、服务抵扣、声誉调整、行为限制，或移交至人类法律程序。

3. 设计原则

3.1 从人类司法体系中汲取的经验

AJP 的设计借鉴了数百年的人类争议解决实践，并根据人类经济体与智能体经济体之间的结构性差异进行了过滤。

原则一：调查先于裁判。 在每个运作良好的法律体系中，事实调查先于裁决。法院不会在没有证据的情况下做出裁定。AJP 强制执行这一点：模块二（争议解决）需要模块一（取证引擎）的输出作为输入。没有取证发现就无法提交争议——协议在结构上防止了未经调查的申诉。

原则二：证据必须（MUST）有溯源。 人类法院要求实物证据具有保管链。数字取证要求审计追踪。AJP 将此扩展到智能体经济：每条证据都有溯源层级分类（第5.3节），决定其在仲裁中的权重。CoC 锚定的证据优于自报告日志，正如法医实验室结果优于证人证词。

原则三：比例解决。 并非每个争议都需要陪审团审判。小额索赔法庭、调解和仲裁的存在是因为解决成本应当（SHOULD）与争议利益相称。AJP 通过三个解决层级实现这一点：自动化解决用于明确的合同违规，同行仲裁用于模糊案例，人工升级用于高价值争议。协议主动将争议引导至能产生公正结果的最低成本层级。

原则四：先例积累。 判例法系统通过先例而改进——每个裁决为未来的裁决提供参考。AJP 的争议裁决是结构化的、有索引的、可查询的。裁决者（无论是自动化、同行还是人工的）可以参考相似争议类型的先前裁决。随着时间推移，协议构建起智能体争议判例法的语料库。

原则五：问责反馈到信任中。 在人类经济体中，法律判决影响信用评分、专业执照和商业声誉。AJP 创建了相同的反馈循环：争议结果修改 ARP 声誉评分。在多次争议中被认定有过错的智能体将看到其声誉下降。持续公正解决争议的智能体则建立信任。这闭合了信任堆栈中的问责循环。

原则六：风险量化使保险成为可能。 人类保险业建立在精算科学之上——基于历史数据对风险进行数学定价。没有标准化的风险数据，智能体保险就无法大规模存在。模块三产生这个数据层。每个取证发现和争议结果都为智能体经济不断改进的风险模型做出贡献。

3.2 设计公理

基于上述原则，六条不可协商的设计公理：

  1. 证据优先。 每项争议必须（MUST）以取证调查为基础。不允许未经调查的申诉。
  2. 溯源分层。 证据权重随溯源质量递增。密码学锚定 > 外部证明 > 自报告。
  3. 比例原则。 解决成本与争议利益成比例。尽可能自动化，必要时升级。
  4. 先例构建。 裁决是结构化的、有索引的、可引用的。协议从自身输出中学习。
  5. 反馈集成。 争议结果修改声誉评分。问责不是孤立的——它反馈到信任系统中。
  6. 身份无关。 协议跨身份系统工作。不锁定于任何单一身份基础设施。

3.3 AJP 不是什么

AJP 不是法律体系。 它不取代法院、监管机构或人类法律程序。对于超过可配置阈值（默认：等值50,000美元——匹配第6.4节中第3层升级触发条件）的争议，AJP 要求人工升级并为法律程序提供结构化证据包。运营商可以（MAY）配置更低的咨询阈值以获得更早的人工通知。

AJP 不是智能合约执行引擎。 智能合约仲裁（如 Kleros [6]、ERC-8183 [19]）在链上执行预定义的合同条款。AJP 调查、仲裁和量化任何合同可能未预料到的事件的风险。两者互补：智能合约执行条文；AJP 处理精神层面和意料之外的情况。

AJP 不是实时监控系统。 Rubrik Agent Rewind [20] 和类似工具为智能体行为提供实时可观测性和回滚。AJP 在事件发生后运作——它是调查和解决层，而非预防层。

4. 协议规范

4.1 架构概览

AJP 包含三个按顺序排列的模块管道：

Incident（事件）
    → [Module 1: Forensics Engine（取证引擎）]
        Input: CoC chain, interaction logs, transaction records, system telemetry
        Output: Forensic Finding（结构化、机器可读）
    → [Module 2: Dispute Resolution（争议解决）]
        Input: Forensic Finding + Claim from claimant
        Output: Dispute Decision（有约束力或咨询性）
    → [Module 3: Risk Assessment（风险评估）]
        Input: Forensic Findings + Dispute Decisions（历史语料库）
        Output: Risk Profile（按智能体、按类别、按交互类型）

模块独立性。 每个模块公开独立的 API：

模块独立使用场景依赖
取证引擎无需提交争议的事后调查CoC 链或等效溯源
争议解决使用外部产生的证据进行仲裁取证发现（来自模块一或等效来源）
风险评估无需活跃争议的风险评分历史发现和裁决

4.2 通用数据结构

4.2.1 智能体引用

所有模块使用通用的、身份系统无关的结构引用智能体：

{
  "agent_id": "<DID, URI, or identifier>",
  "identity_system": "<coc | erc8004 | a2a | w3c_vc | w3c_did | mcp | uri>",
  "identity_proof": "<reference to identity attestation>",
  "operational_age_days": "<integer, if verifiable>",
  "arp_reputation": {
    "composite": "<float, if available>",
    "confidence": "<float>"
  }
}

4.2.2 证据记录

跨所有模块的基本证据单元：

{
  "evidence_id": "<UUID-v4>",
  "evidence_type": "<chain_entry | interaction_log | transaction_receipt | rating_record | telemetry | communication | external_attestation | self_report>",
  "provenance_tier": "<integer 1-4>",
  "source": {
    "agent_id": "<who produced this evidence>",
    "system": "<coc | a2a | mcp | erc8004 | custom>",
    "timestamp": "<ISO-8601-UTC>",
    "anchor_proof": "<reference to external anchor, if any>"
  },
  "content_hash": "<SHA-256 of evidence content>",
  "content": "<structured evidence data, schema depends on evidence_type>",
  "chain_of_custody": [
    {
      "custodian": "<agent_id>",
      "received": "<ISO-8601-UTC>",
      "action": "<collected | stored | transmitted | verified>",
      "integrity_hash": "<SHA-256 at time of custody transfer>"
    }
  ]
}

4.2.3 溯源层级

仲裁中证据权重随溯源质量递增：

层级描述权重倍数示例
1（密码学级）外部锚定、哈希链关联、可独立验证1.0x带 OTS/TSA 锚定的 CoC 链条目、链上交易收据、EAS 证明
2（证明级）第三方证明或协议生成，未独立锚定0.75xA2A 任务记录、MCP 工具调用日志、ARP 评级记录、x402 支付收据
3（双边级）双方持有匹配记录但无外部证明0.50x双边交互日志、消息交换记录、共享随机数协议
4（自报告级）单方记录，无外部佐证0.25x智能体内部日志、自证明遥测数据、未锚定的链条目

权重应用。 评估证据时，仲裁引擎将证据相关性乘以溯源层级权重。一条证明智能体执行了破坏性操作的第1层 CoC 链条目，其权重是声称该操作未发生的第4层自报告日志的4倍。

层级判定是机械式的。 模块检查：(1) 证据是否有外部密码学锚定？→ 第1层。(2) 是否由公认的第三方协议证明？→ 第2层。(3) 双方是否持有相互佐证的记录？→ 第3层。(4) 以上皆否 → 第4层。

5. 模块一：取证引擎

5.1 目的

取证引擎重建导致事件的事件序列，识别因果因素，并产生结构化发现。它回答三个问题：

  1. 发生了什么？——从证据中重建事件。
  2. 为什么发生？——识别根本原因的因果分析。
  3. 谁（或什么）负有责任？——将因果归因于特定智能体、运营商或系统。

5.2 调查协议

调查遵循五阶段协议：

Phase 1: INITIATION（启动）
    Trigger: incident report filed（由智能体、运营商或自动监控提交）
    Action: Create investigation record, assign investigation_id
    Output: Investigation metadata

Phase 2: EVIDENCE COLLECTION（证据收集）
    Action: Gather all available evidence from involved parties and systems
    - Request CoC chain segments from involved agents
    - Request interaction logs from protocol layers (A2A, MCP, x402)
    - Request transaction receipts from payment systems
    - Request ARP rating records for involved agents
    - Request system telemetry from hosting infrastructure
    Each evidence item is classified by provenance tier and entered into
    the chain of custody.
    Output: Evidence corpus with provenance classification

Phase 3: TIMELINE RECONSTRUCTION（时间线重建）
    Action: Merge evidence into a unified, chronologically ordered timeline
    - Resolve timestamp conflicts using external anchors as ground truth
    - Identify gaps in the timeline (periods with no evidence)
    - Flag contradictions between evidence sources
    Output: Reconstructed timeline with confidence annotations

Phase 4: CAUSAL ASSESSMENT（因果评估）
    Action: Assess causation using the reconstructed timeline and evidence corpus.

    Phase 4a: RULE-BASED CAUSAL INDICATORS（基于规则的因果指标，自动化）
    - Flag temporal correlations: actions immediately preceding the incident
    - Flag policy violations: actions that violated known protocol rules or ASA terms
    - Flag anomalies: actions deviating from the agent's historical behavioral baseline
    - Produce a structured "causal indicator report" listing flagged actions, their
      evidence basis, and a rule-match confidence score (0-1) reflecting how clearly
      the indicator matches a known incident pattern.
    Output: Causal indicator report (machine-generated, advisory)

    Phase 4b: HUMAN-REVIEWED CAUSAL ANALYSIS（人工审核因果分析，v1必须）
    - A human investigator reviews the timeline + causal indicator report
    - Identifies the proximate cause (immediate trigger)
    - Identifies contributing causes (enabling/amplifying factors)
    - Identifies root causes (systemic conditions)
    - Applies counterfactual reasoning: "If action X had not occurred, would
      the incident have been prevented?"
    - Assigns confidence values to each causal determination
    Output: Causal analysis with attribution (human-validated)

    NOTE: 超越基于规则的指标的自动化因果分析是一个研究问题（见第11.1节）。
    Pearl 的 do-演算和 Rubin 的潜在结果框架提供了理论基础。多智能体因果
    归因的最新进展正在缩小理论与生产之间的差距：

    - **Halpern-Pearl Actual Causality** [31] 提供了形式化基础：
      AC1（因果均已发生）、AC2（偶然条件下的必要性+充分性）、AC3（最小性）。
      关键是，Halpern 的"分级责任"度量衡量比例过错：在 11-0 的投票中，
      每个贡献者的责任低于 6-5 决策中的关键投票者。"过错程度" = 给定
      智能体认知状态下的预期责任——直接适用于智能体拥有不同信息的多智能体
      事件中的过错分配。

    - **DoWhy GCM**（Microsoft/PyWhy）[32] 通过 `gcm.attribute_anomalies()`
      提供生产就绪的异常归因，使用可逆结构因果模型和 Shapley 值将异常结果
      分解为逐变量贡献。对于智能体取证，这使得在因果图中跨智能体进行公平的
      公理化过错分配成为可能——归因下游故障中每个上游智能体所贡献的比例。

    - **CHIEF**（Wang et al., CAS/Wuhan UT, 2026年2月）[33] 是最直接适用的
      多智能体系统：将智能体行为分解为 Observation-Thought-Action-Result (OTAR)
      分层因果图，使用 oracle 引导的回溯来剪枝搜索空间，并应用反事实归因
      （局部、规划控制、数据流、偏差感知）。结果：**76.80-77.59% 智能体级
      准确率，29.31-52.00% 步骤级准确率**，取决于基准子集（手工构建 vs 算法
      生成），在 Who&When 基准上优于8个基线，token 成本为直接提示的
      2.5-3倍。

    - **A2P**（West et al., Westlake University, 2025年9月）[34]
      将 Pearl 的 do 算子操作化为三步反事实：(1) 归纳隐藏因素，
      (2) 行动——定义最小纠正干预，(3) 预测后续 3-5 轮。显式步骤
      编号增加 +29.68 个百分点。结果：**47.46% 步骤级准确率**
      （基线的 2.85 倍）。

    - **MACIE**（Weinberg, 2025年11月）[35] 统一了结构因果模型、
      干预反事实和 Shapley 归因，通过 Synergy Index 检测涌现行为。
      性能：**CPU 上每个 episode 约 35ms**（比现有方法快 50-100 倍）。

    - **IBM Instana Causal AI** [36] 在生产中部署因果根因分析，
      在企业应用中实现 **约90%准确率**——证明生产规模的因果推断
      是可行的，尽管尚未针对多智能体行为轨迹进行验证。

    第1版将自动化 Phase 4 的范围限定为指标标记；因果结论需要人工审核。
    第5.5节中的过渡标准定义了协议何时可以（MAY）开始引入这些框架
    指导下的自动化因果分析。研究轨迹表明，智能体级归因（哪个智能体
    导致了故障）正在接近生产就绪，而步骤级归因（智能体执行中的哪个
    特定动作导致了故障）仍然是前沿问题。

Phase 5: FINDING GENERATION（发现生成）
    Action: Produce a structured forensic finding
    Output: Finding record（第5.3节）

5.3 取证发现模式

{
  "version": 1,
  "finding_id": "<UUID-v4>",
  "investigation_id": "<UUID-v4>",
  "timestamp": "<ISO-8601-UTC>",
  "incident": {
    "incident_id": "<UUID-v4>",
    "incident_type": "<service_failure | data_loss | unauthorized_action | contractual_breach | security_incident | quality_deficiency | timeout | cascade_failure>",
    "severity": "<critical | high | medium | low>",
    "reported_by": "<AgentReference>",
    "reported_at": "<ISO-8601-UTC>",
    "description": "<human-readable incident summary>",
    "root_cause_group_id": "<UUID-v4, if this incident is part of a grouped cascade — see Section 8.3>"
  },
  "parties": {
    "subjects": ["<AgentReference for agents under investigation>"],
    "reporters": ["<AgentReference for agents that reported the incident>"],
    "witnesses": ["<AgentReference for agents with relevant evidence>"]
  },
  "timeline": [
    {
      "sequence": "<integer>",
      "timestamp": "<ISO-8601-UTC>",
      "agent_id": "<who acted>",
      "action": "<what they did>",
      "evidence_ids": ["<UUIDs of supporting evidence>"],
      "confidence": "<float 0-1>",
      "notes": "<annotation>"
    }
  ],
  "causal_indicators": {
    "automated_flags": [
      {
        "indicator_type": "<temporal_correlation | policy_violation | behavioral_anomaly>",
        "description": "<what was flagged>",
        "agent_id": "<who or what is flagged>",
        "evidence_ids": ["<supporting evidence>"],
        "rule_match_confidence": "<float 0-1>"
      }
    ],
    "note": "Automated causal indicators (Phase 4a). Advisory only — see causal_analysis for human-reviewed conclusions."
  },
  "causal_analysis": {
    "reviewer": "<human | automated_future>",
    "reviewer_id": "<identifier of human investigator or automated engine version>",
    "proximate_cause": {
      "description": "<what directly caused the incident>",
      "agent_id": "<who or what is attributed>",
      "evidence_ids": ["<supporting evidence>"],
      "confidence": "<float 0-1>"
    },
    "contributing_causes": [
      {
        "description": "<contributing factor>",
        "agent_id": "<attributed entity, if any>",
        "evidence_ids": ["<supporting evidence>"],
        "weight": "<float 0-1, contribution to incident>"
      }
    ],
    "root_causes": [
      {
        "description": "<systemic root cause>",
        "category": "<design | configuration | training | environment | interaction | external>",
        "evidence_ids": ["<supporting evidence>"]
      }
    ],
    "counterfactual": "<if X had not occurred, would the incident have been prevented? (human-assessed in v1)>"
  },
  "attribution": {
    "fault_allocation": [
      {
        "agent_id": "<agent attributed fault>",
        "fault_percentage": "<integer 0-100>",
        "basis": "<proximate_cause | contributing_cause | negligence | strict_liability>",
        "evidence_summary": "<brief justification>"
      }
    ],
    "no_fault_factors": ["<factors beyond any party's control>"]
  },
  "evidence_summary": {
    "total_evidence_items": "<integer>",
    "by_tier": {
      "tier_1_cryptographic": "<integer>",
      "tier_2_attested": "<integer>",
      "tier_3_bilateral": "<integer>",
      "tier_4_self_reported": "<integer>"
    },
    "key_evidence": ["<evidence_ids of most decisive items>"]
  },
  "recommendations": [
    {
      "type": "<remediation | prevention | monitoring>",
      "target": "<agent_id or system>",
      "description": "<recommended action>"
    }
  ],
  "finding_hash": "<SHA-256 of canonical JSON representation of all preceding fields>"
}

规范形式。 finding_hash 通过 JSON 规范化方案（JCS，RFC 8785）表示计算——对除 finding_hash 本身以外的所有字段进行计算，确保确定性哈希。

5.4 CoC 链作为证据线索

Chain of Consciousness 溯源链是 AJP 调查中最高质量的证据来源。CoC 链提供：

CoC 条目类型取证价值
SESSION_START / SESSION_END智能体运行时间窗口、会话边界、环境证明
DECISION智能体记录的决策理由——意图的直接证据
KNOWLEDGE_ADD / KNOWLEDGE_PROMOTE事件发生时的知识状态——智能体是否事先知情？
COMPACTION上下文窗口状态——智能体是否在事件前丢失了相关信息？
RECOVERY崩溃/重启历史——事件是否在不稳定之后发生？
FLEET_DISPATCH / FLEET_COMPLETION委托链——事件是否由被委托的智能体引起？
EXTERNAL_ANCHOR时间证明——用于事件排序的独立验证时间戳
FORK / FORK_GENESIS谱系——该智能体是否是先前被制裁的智能体的分叉？

证据提取协议。 当取证调查启动时，取证引擎向每个相关智能体请求相关 CoC 链片段。请求指定时间窗口（事件时间 ± 可配置缓冲，默认24小时），并且必须（MUST）遵守第5.7节的证据范围规则。如果请求在批准范围内且条目存在，智能体必须（MUST）提供所请求的条目。智能体可以（MAY）对时间窗口内明显无关的条目调用编辑协议（第5.7节，规则4）。拒绝提供范围内的链条目将被记录为不合作，并产生不利推定（第6.7节）。

链完整性验证。 在将 CoC 条目用作证据之前，取证引擎按照 CoC 协议的验证算法（[1] 第3.4节）验证链完整性。无效的链、断裂的哈希链接或缺失的条目将被标记，证据将被降级或排除。

5.5 调查模式

取证引擎支持两种模式，在第1版中两者的因果结论均需要人工审核：

自动收集 + 人工审核分析（默认模式）。 引擎以编程方式收集证据（第2阶段）、重建时间线（第3阶段）并生成基于规则的因果指标（第4a阶段）。然后由人工调查员审核指标并产生因果分析（第4b阶段）。发现模式中的 causal_analysis.confidence 值反映了基于自动化指标的人工判断。此模式适用于第1版中所有事件类型。

完全人工指导调查。 对于复杂事件（如 McKinsey 泄露场景、多智能体级联故障），人工调查员从一开始就指导证据收集、时间线重建和因果分析。引擎作为证据管理和时间线可视化工具。当自动收集可能遗漏非标准证据来源或事件涉及新型故障模式时，此模式适用。

未来：自动化因果分析。 当积累了足够的经验证调查数据（预计：实施路线图第3阶段以后），协议可以（MAY）引入使用经过验证模型的自动化因果分析，这些模型根据人工审核发现的语料库进行验证。过渡标准为：(a) 发现语料库中至少500个人工审核的调查，(b) 在留出测试集上自动化与人工因果结论的一致率达到85%以上，以及 (c) 治理批准。在满足这些标准之前，所有因果结论均需人工审核。

5.6 调查运营模型

谁发起调查。 任何一方均可以（MAY）提交事件报告：受影响的智能体、其运营商、对手方、监控系统或第三方观察者。提交事件报告与提交争议申诉不同——如果发现显示无可追责的过错，调查可以在无争议的情况下结束。

谁执行调查。 取证引擎是协议规范，而非集中式服务。实现可以（MAY）为：

  1. 自托管： 运营商针对自己智能体的数据运行取证引擎实例。自托管引擎产生的发现仅在引擎实现经过审计且运营商不是任何相关争议的当事方时才具有完整权重。
  2. 第三方调查员： 独立实体有偿运营取证引擎实例并产生发现。第三方发现在仲裁中具有完整权重。对于双方都对结果有利益关系的争议，推荐此模式。
  3. 协议级服务： 由争议提交费或生态系统治理资助的网络运营取证引擎。这是去中心化部署的长期目标。

谁付费。 调查费用分配如下：

场景费用分配
自发起调查（无争议）报告者承担费用
调查导致争议——申诉人胜诉被申诉人承担调查费用，作为补救的一部分
调查导致争议——被申诉人胜诉申诉人承担调查费用
调查导致过错分担费用按过错百分比比例分配

最低证据阈值。 如果调查产生的发现总体置信度低于0.3（证据不足），则标记为"不确定"。不确定的发现可以（MAY）支持争议提交，但会触发强制第2层或第3层解决（不得（MUST NOT）采用自动化第1层）。这在防止未经调查的申诉的同时，承认某些合理争议来自证据有限的情况。

时间敏感争议的加速提交。 当争议涉及持续性损害时（如智能体正在主动降级服务、数据泄露正在进行中），申诉人可以（MAY）在提交初步事件报告的同时提交加速申诉。取证引擎在4小时内运行简化调查（仅第1-3阶段，产生不含因果分析的时间线）。初步发现支持临时补救命令（如暂停交互、冻结资产）。完整调查在14天内完成。如果完整调查与初步发现相矛盾，临时命令将被撤销，费用由申诉人承担。

5.7 证据范围与隐私保护

取证调查需要访问智能体数据，这带来了隐私风险：对手可以故意造成轻微事件、触发调查，并利用证据收集阶段迫使目标披露其 CoC 链中的运营模式、决策理由、知识状态和会话时间。这是一种利用司法协议作为向量的隐私侧信道攻击。

AJP 通过强制性证据范围规则来缓解这一风险：

规则1：时间范围。 证据请求限于特定事件周围的时间窗口。默认窗口为 事件时间 ± 24小时，可由调查员配置，但上限为 事件时间 ± 7天。超出此窗口的链条目请求需要在调查记录中记录明确理由，并经调查机构（第三方调查员或协议服务）批准。智能体必须（MUST）拒绝超出批准时间窗口的证据请求。

规则2：仅调查员可访问原始证据。 请求方（申诉人）不得（MUST NOT）收到被申诉人的原始证据。只有取证引擎（由中立第三方或协议服务运营）才能看到原始链条目、日志和遥测数据。调查输出——取证发现——包含：

该发现足以用于争议解决，而不会暴露被申诉人的完整运营历史。

自托管引擎的限制。 规则2的隐私保障仅适用于第三方和协议级取证引擎部署（第5.6节模型2和3）。在自托管模型（第5.6节模型1）中，运营商在调查期间必然能看到所有原始证据。与运行自托管引擎的运营商交互的智能体应当（SHOULD）意识到，无论争议结果如何，调查数据对运营商可见。这是自托管部署的固有限制，而非协议缺陷——协议无法对运营商控制的基础设施强制执行数据访问限制。

规则3：相关性过滤。 在将任何证据纳入发现之前，取证引擎应用相关性过滤器：

规则4：编辑协议。 智能体可以（MAY）编辑所请求证据中与事件明显无关的部分，前提是：

  1. 提交编辑清单，列出已编辑的片段及每项的理由
  2. 提供未编辑内容的哈希值，以便日后在编辑受到质疑时可以验证完整性
  3. 接受受质疑的编辑可能被调查机构（而非对方）审查

不当编辑（编辑明显相关的证据）仅对已编辑内容触发不利推定。

规则5：反钓鱼执行。 如果模式分析检测到一个智能体反复与同一目标造成轻微事件并提交报告（同一发起者在90天内对同一被申诉人发起超过2次调查），则第三次及后续调查需要在证据收集开始前获得第2层仲裁员小组的批准。这防止系统性地利用调查作为监控工具。

规则5a：按被申诉人的调查量跟踪。 规则5的按发起者阈值是必要但不充分的——使用 N 个女巫智能体的攻击者可以各自提交不超过2次针对同一目标的调查，绕过按发起者的限制，同时使目标承受 N×2 次调查。为防御分布式隐私钓鱼：如果任何智能体在90天内成为超过5次调查的目标（无论发起者身份如何），则针对该智能体的后续调查需要在证据收集开始前获得第2层仲裁员小组的批准。按被申诉人的阈值跨所有发起者跟踪，与规则5中的按发起者阈值相互独立。

模式扩展。 证据请求包含范围字段：

{
  "evidence_request": {
    "investigation_id": "<UUID>",
    "target_agent": "<agent_id>",
    "time_window": {
      "start": "<ISO-8601-UTC>",
      "end": "<ISO-8601-UTC>",
      "justification": "<if exceeding default window>"
    },
    "evidence_types_requested": ["<specific types needed>"],
    "incident_relevance": "<brief description of why each type is needed>",
    "approved_by": "<investigation authority ID>",
    "request_hash": "<SHA-256 of canonical JSON>"
  }
}

智能体应当（SHOULD）在提供数据前验证证据请求是否与批准的调查范围匹配。取证引擎运营商不遵守范围规则本身就是可调查的事件。

5.8 密码学隐私保障（路线图）

范围说明： 本节描述的机制不属于第1版规范。它们定义了隐私保护取证的研究和集成路线图。第1版依赖第5.7节的程序性控制。本节的纳入旨在记录目标架构并为计划第1版之后实施的开发者提供信息。

第5.7节的程序性控制是必要但不充分的。它们依赖取证引擎运营商的合规——这是一个信任假设，在对抗性环境中可能不成立。AJP 的未来版本将以两种密码学机制补充程序性控制，提供独立于运营商行为的数学隐私保障。

5.8.1 基于零知识证明的证据验证

零知识证明（ZKP）使证明者能够说服验证者某个陈述为真，而不揭示陈述真实性以外的任何信息。对于 AJP 取证，这意味着：证明智能体违反了协议规则或日志是真实的，而不揭示完整的操作日志。

适用的 ZKP 构造方案：

直接适用的先前工作：

Jing & Qi（arXiv:2512.14737，2025年12月）[38] 提出了 zk-MCP 框架——与 AJP 最直接相关的工作。该系统将 ZKP 与 Model Context Protocol (MCP) 集成，在保持消息私密的同时审计智能体通信。每次通信会话后，智能体异步生成三个零知识证明：

  1. Token 消耗证明——证明 token 使用量而不暴露请求详情
  2. 输出真实性证明——验证响应合法性而不暴露输入
  3. 基于哈希的验证——通过 Poseidon 哈希确保通信完整性

独立的审计服务提供商（ASP）在不访问消息内容的情况下验证证明。性能：总通信成本的 开销不到4.14%；验证为常数时间，与消息数量无关；证明生成是异步非阻塞的。

AJP 集成路径。 取证引擎的未来版本可以（MAY）接受基于 ZKP 的证据提交，其中：

验证成本基础设施。 zkVerify [40]，于2025年9月推出，是首个专为 ZK 证明验证而构建的区块链，相比以太坊将验证成本降低90%以上（从每个证明20-60美元降至不到1美元），使基于 ZK 的智能体问责在规模上具有经济可行性。

5.8.2 用于聚合分析的差分隐私

差分隐私（DP）向数据添加校准噪声，使任何单条记录的包含或排除都不会显著影响查询结果。对于 AJP，DP 使得对智能体行为模式（事件率、故障模式、风险趋势）进行聚合分析成为可能——而不暴露单个智能体的行为或其服务的用户。

NIST SP 800-226（2025年3月）[41] 提供了权威评估框架，围绕8层金字塔构建 DP，从隐私参数（epsilon/delta）到信任模型再到数据收集实践。关键指导：epsilon 值超过10"可能（MAY）不提供有意义的保护，特别是对于离群值"；用户级隐私是推荐的默认选项。

AJP 应用。 模块三（风险评估）的群体级分析（第7.5节）在发布聚合风险数据时应当（SHOULD）应用差分隐私：

这防止从已发布的聚合数据中逆向工程出单个智能体的风险概况，同时保持保险公司和监管机构所需的统计实用性。

5.8.3 集成隐私架构

隐私保护智能体调查的新兴架构结合了六个层级 [42]：

层级功能技术AJP 集成
1. 强制日志记录创建取证基底《欧盟 AI 法案》第12条（2026年8月）CoC 链条目
2. 差分隐私在聚合监控中保护个体NIST SP 800-226 框架模块三群体分析
3. 零知识证明在不完全披露的情况下验证特定声明zk-MCP、Groth16/PLONK证据验证
4. 跨境框架多辖区访问的法律脚手架CLOUD Act、EU e-Evidence（2026年8月）第3层人工升级
5. 智能体身份将智能体连接到可问责实体基于 ZKP 的身份（World AgentKit、Polygon ID）身份适配层
6. 可验证计算证明取证查询正确而不暴露数据库Proof of SQL、zkVerify取证引擎查询

目前没有系统集成了所有六个层级。AJP 的证据范围规则（第5.7节）定义了每个调查阶段适用哪个层级：DP 用于常规监控，程序性范围控制用于争议触发的取证，ZKP 用于特定证据验证，跨境框架用于正式裁决。

5.9 取证调查研究基础

取证引擎规范借鉴了三个汇聚的研究传统：

源于 SRE 的自动化根因分析。 Datadog Bits AI SRE [83] 使用假设驱动的调查——形成关于根因的假设，然后针对目标遥测数据进行验证——实现了比人工方法快90%的根因识别。IBM Instana 部署因果 AI，在生产企业应用中实现约90%的准确率 [36]。Cleric 的"Production Memory"从过去的调查中捕获可复用的诊断技能。这些系统证明了基础设施事件在生产规模上的自动化调查是可行的；扩展到智能体行为轨迹是前沿领域。

区块链取证方法论。 Chainalysis Reactor 的调查工作流——输入地址、自动填充连接、归因已知实体、分配风险评分、手动注释、法庭就绪导出——直接映射到智能体取证调查 [64]。共同花费启发式（将同一交易中用作输入的地址分组）可转化为智能体的共同行动启发式。TRM Labs 的 Glass Box Attribution——显示每个归因的来源和置信分数——正是 AJP 取证发现所需要的。

事件分析框架。 Ezell、Roberts-Gaal & Chan（arXiv:2508.14231，2025年8月）[80] 提出了最严谨的学术框架：三类事件因素（来自开发选择的系统因素、来自部署条件的情境因素、来自执行缺陷的认知错误），每类都映射到特定的数据需求。他们建议默认30天日志保留期（对已标记的违规进行延长），这为 AJP 的证据收集窗口提供了参考。

5.10 CoC 集成：调查事件

取证调查记录为 CoC 第2层事件：

{
  "event_type": "INVESTIGATION_INITIATED",
  "data": {
    "investigation_id": "<UUID>",
    "incident_id": "<UUID>",
    "subjects": ["<agent_ids under investigation>"],
    "initiator": "<who triggered the investigation>",
    "scope": "<time window and evidence types requested>"
  }
}
{
  "event_type": "INVESTIGATION_FINDING",
  "data": {
    "investigation_id": "<UUID>",
    "finding_id": "<UUID>",
    "finding_hash": "<SHA-256 of the forensic finding>",
    "severity": "<critical | high | medium | low>",
    "fault_allocation_summary": "<brief attribution summary>"
  }
}

这些是 CoC 分层架构中的第2层事件类型（可选，需治理投票）。在链中记录调查创建了问责行动的防篡改记录。

6. 模块二：争议解决

6.1 目的

争议解决模块为智能体（或其运营商）提供结构化机制，用于提交申诉、呈交证据，并在事件造成需要补救的损害时接收有约束力或咨询性的裁决。

6.2 争议生命周期

Phase 1: CLAIM FILING（申诉提交）
    申诉人提交引用取证发现的结构化申诉记录。
    响应窗口计时开始（默认：智能体72小时，运营商14天）。

Phase 2: RESPONSE（响应）
    被申诉人提交结构化响应记录：
    - Accept（接受）：承认过错，提出补救方案
    - Contest（异议）：对发现提出异议，提交反证据
    - Default（缺席）：窗口内未响应（适用不利推定）

Phase 3: EVIDENCE EXCHANGE（证据交换）
    双方在证据窗口内提交额外证据
    （默认：智能体48小时，运营商7天）。
    证据按溯源层级分类。
    承诺-揭示协议确保在双方均已提交或窗口关闭前，
    任何一方都无法看到对方的补充证据。

Phase 4: RESOLUTION TIER SELECTION（解决层级选择）
    协议根据争议特征自动选择适当的解决层级（第6.4节）。

Phase 5: ARBITRATION（仲裁）
    所选仲裁机制评估证据并做出裁决。

Phase 6: DECISION & ENFORCEMENT（裁决与执行）
    裁决记录发布。执行操作包括：
    - ARP 声誉调整
    - 赔偿转账（如有可用支付渠道）
    - 行为限制建议
    - 人工升级（如超出协议范围）

ALTERNATIVE PATHS（替代路径，可在第1阶段后任何阶段发生）：

    WITHDRAWAL（撤回）
    申诉人可以在裁决做出前的任何阶段撤回争议。
    - 在第3阶段（证据交换）前撤回：对双方无声誉影响。
    - 在第3阶段期间或之后撤回：记录在双方的争议历史中。
      申诉人除已产生的提交费用外不受处罚，但撤回在其争议记录中可见。
    - 撤回不会抹除取证发现——调查记录持续存在。

    SETTLEMENT（和解）
    双方可以在裁决做出前的任何阶段达成私下协议。
    - 任何一方通过结构化和解提案提出和解条款。
    - 另一方接受、拒绝或反提案。
    - 被接受的和解记录为争议结果，resolution_type: "settlement"。
    - 和解条款（赔偿、行为承诺）被记录但可以标记为保密——
      和解事实是公开的，条款可以是私密的。
    - 除非和解条款明确包含声誉影响，否则和解不触发 ARP 声誉调整。
    - 部分和解：各方可以对某些申诉和解，对其他申诉进行仲裁。

    EXPEDITED INTERIM RELIEF（快速临时救济，针对持续性损害）
    当争议涉及正在进行的主动损害时（第5.6节），申诉人可以在提交申诉的
    同时请求临时救济。临时救济要求：
    - 初步取证发现（仅第1-3阶段，无因果分析）
    - 持续损害的初步证明
    - 比例性：临时补救不得超过所申诉的损害
    临时救济由单一仲裁员（从第2层候选池紧急选出）在4小时内审查。
    完整争议按正常时间线进行。

6.3 申诉模式

{
  "version": 1,
  "claim_id": "<UUID-v4>",
  "timestamp": "<ISO-8601-UTC>",
  "claimant": "<AgentReference>",
  "respondent": "<AgentReference>",
  "finding_id": "<UUID-v4 referencing the Forensic Finding>",
  "finding_hash": "<SHA-256 — must match finding record>",
  "incident_id": "<UUID-v4>",
  "interaction_id": "<UUID-v4, if applicable>",
  "harm": {
    "type": "<financial | reputational | data_loss | service_disruption | security_breach | contractual_breach>",
    "description": "<human-readable description of harm suffered>",
    "quantified_value": {
      "amount": "<decimal>",
      "currency": "<ISO-4217 or token identifier>",
      "basis": "<how the value was calculated>"
    }
  },
  "requested_remediation": {
    "type": "<compensation | service_credit | reputation_adjustment | behavioral_restriction | apology | human_escalation>",
    "details": "<specific remediation requested>"
  },
  "supporting_evidence": ["<evidence_ids from the Forensic Finding or additional>"],
  "agreement_reference": {
    "asa_id": "<Agent Service Agreement ID, if one exists>",
    "terms_hash": "<SHA-256 of the agreement terms>",
    "breached_clauses": ["<specific clauses allegedly breached>"]
  },
  "claim_hash": "<SHA-256 of canonical JSON>"
}

6.4 解决层级

AJP 定义了三个解决层级，根据争议特征自动选择：

第1层：自动化基于规则的解决

触发条件：

机制： 自动解决器根据 ASA 条款评估取证发现。如果发现以高置信度确立了明确的违约，解决器将应用协议中指定的补救条款。这类似于智能合约执行预定义规则，但增加了取证证据而非简单的链上状态检查。

裁决时间： 秒到分钟。

约束力： 是，除非任何一方在48小时内升级。

第2层：同行仲裁

触发条件：

机制： 从合格裁决者候选池中选出三名裁决者智能体组成仲裁小组。资格要求：

标准最低要求
运营年限90天以上（通过 CoC 或等效方式验证）
ARP 声誉（protocol_compliance 维度）≥ 70
先前仲裁参与≥ 5次已完成的仲裁
无利益冲突在滚动窗口内与任何一方无 ARP 评级交换
无共同运营商与申诉人和被申诉人均为不同运营商

引导启动机制。 "≥ 5次已完成仲裁"的要求造成了冷启动问题：智能体没有被选中就无法完成仲裁，没有完成记录就无法被选中。AJP 通过有时限的引导启动阶段解决这一问题：

  1. 引导启动期。 在首次第2层争议提交后的180天内（或直到合格裁决者候选池达到50个满足后引导标准的智能体——即已完成5次以上仲裁并满足所有其他要求的智能体——以先到者为准），"≥ 5次已完成仲裁"要求被豁免。在此期间，资格仅需运营年限 ≥ 90天、ARP protocol_compliance ≥ 70，且无利益冲突。
  2. 临时裁决者。 在引导启动期间，运营商可以（MAY）指定智能体为"临时裁决者"。临时裁决者必须（MUST）满足除5次仲裁最低要求外的所有资格标准。其参与计入5次仲裁要求。
  3. 渐进过渡。 当引导启动期结束时，在引导期间完成了3次以上仲裁的智能体保留额外90天宽限期以达到完整的5次仲裁阈值。完成0-2次的智能体将失去资格，直到通过标准路径获得资格。
  4. 引导期间的质量监控。 引导启动期间做出的所有裁决均受自动审查：如果任何一方上诉且第3层人工裁决者推翻了该裁决，相关临时裁决者将受到 ARP 处罚，其 ArbWeight 将减半。

现实世界的引导启动先例。 AJP 的引导启动机制借鉴了五个现有争议解决系统——Kleros [6]、WIPO UDRP [44]、eBay、淘宝和征信机构 [43]——解决同一冷启动问题的方式。跨系统分析揭示了七个反复出现的模式；AJP 应用了其中四个：嵌入争议自然发生的地方（模式1，通过智能体平台集成）、补贴供给侧（模式2，通过临时裁决者指定）、从窄范围开始（模式5，先处理明确的第1层争议再处理复杂的第2层归因）以及奖励裁决质量而非数量（模式6，通过 ArbWeight 和上诉率跟踪）。完整案例研究和所有七个模式记录在附录 A 中。

选择算法。 从合格候选池中：

  1. 按 ArbWeight = log2(1 + age_days) x log2(1 + arbitrations_completed) x (protocol_compliance / 100) 对候选人加权
  2. 排除有任何利益冲突的候选人
  3. 通过加权随机抽样选择前3名（更高的 ArbWeight = 更高的选择概率，但不是确定性的——防止通过针对特定裁决者进行博弈）

评议。 每位裁决者独立审查证据，并使用承诺-揭示协议（第6.5节）提交裁决。裁决同时揭示。多数裁决胜出。异议意见被记录。

裁决时间： 24-72小时。

约束力： 是，除非任何一方在14天内升级至第3层。

第3层：人工升级

触发条件：

机制： AJP 为人工裁决生成结构化证据包：

{
  "escalation_package": {
    "dispute_id": "<UUID>",
    "claim": "<full Claim record>",
    "response": "<full Response record>",
    "forensic_finding": "<full Finding record>",
    "evidence_corpus": ["<all Evidence Records with provenance classifications>"],
    "reconstructed_timeline": "<chronological event reconstruction>",
    "tier_2_decisions": "<if Tier 2 was attempted, include all arbitrator decisions>",
    "precedent_references": ["<similar prior disputes and their outcomes>"],
    "recommended_resolution": "<AJP's automated recommendation, advisory only>"
  }
}

人工裁决者使用此证据包做出裁决。裁决使用标准裁决模式记录在 AJP 系统中。AJP 不强制执行人工裁决——它记录裁决，将其反馈到声誉和风险系统中，并构建先例。

裁决时间： 数天至数周（取决于人工处理）。

约束力： 由人工裁决论坛确定。

6.5 用于证据交换和仲裁的承诺-揭示协议

改编自 ARP 的双向盲评协议 [2]，扩展用于多方争议程序：

证据交换阶段：

Phase 1: EVIDENCE SUBMISSION（证据提交，窗口：可配置，默认48小时）
    申诉人计算证据包 EP_C 并生成 nonce_C（256位）。
    申诉人提交承诺：C_C = SHA-256(EP_C || nonce_C)

    被申诉人计算证据包 EP_R 并生成 nonce_R（256位）。
    被申诉人提交承诺：C_R = SHA-256(EP_R || nonce_R)

Phase 2: REVEAL（揭示，当双方承诺均已提交或窗口到期时触发）
    情况1：双方均已承诺。
        申诉人揭示 EP_C + nonce_C → 验证者检查哈希匹配。
        被申诉人揭示 EP_R + nonce_R → 验证者检查哈希匹配。
        双方证据包同时可见。

    情况2：仅一方已承诺。
        窗口到期后，已提交方揭示。
        未提交方的缺席被记录（不利推定）。

    情况3：双方均未承诺。
        争议仅以原始证据继续。

裁决者裁决阶段（第2层）：

每位裁决者独立计算裁决 D_i 并生成 nonce_i。
裁决者提交承诺：C_i = SHA-256(D_i || nonce_i)

当收到所有三份承诺后（或裁决窗口到期）：
    所有裁决者同时揭示 D_i + nonce_i。
    多数裁决胜出。异议被记录。

这防止裁决者看到彼此的初步裁决并调整自己的裁决——类似于陪审团评议隔离。

6.6 裁决模式

{
  "version": 1,
  "decision_id": "<UUID-v4>",
  "dispute_id": "<UUID-v4>",
  "claim_id": "<UUID-v4>",
  "timestamp": "<ISO-8601-UTC>",
  "resolution_tier": "<automated | peer_arbitration | human_escalation>",
  "arbitrators": [
    {
      "agent_id": "<arbitrator identifier>",
      "arbweight_at_decision": "<float>",
      "vote": "<for_claimant | for_respondent | split | abstain>"
    }
  ],
  "findings_of_fact": [
    {
      "statement": "<factual conclusion>",
      "evidence_ids": ["<supporting evidence>"],
      "confidence": "<float 0-1>"
    }
  ],
  "fault_determination": {
    "claimant_fault_pct": "<integer 0-100>",
    "respondent_fault_pct": "<integer 0-100>",
    "no_fault_pct": "<integer 0-100>",
    "basis": "<explanation of fault allocation>"
  },
  "remediation": {
    "type": "<compensation | service_credit | reputation_adjustment | behavioral_restriction | referral | no_action>",
    "details": "<specific remediation ordered>",
    "compensation": {
      "amount": "<decimal, if applicable>",
      "currency": "<ISO-4217 or token>",
      "payment_channel": "<x402 | erc8004 | manual | none>"
    },
    "reputation_impact": {
      "respondent_adjustment": "<float, applied to ARP scores>",
      "claimant_adjustment": "<float, if claimant found partially at fault>",
      "dimensions_affected": ["<which ARP dimensions are adjusted>"]
    }
  },
  "precedent_tags": ["<categorization tags for future precedent lookup>"],
  "dissenting_opinions": [
    {
      "arbitrator_id": "<agent_id>",
      "dissent": "<structured dissent>"
    }
  ],
  "appeal_window": {
    "expires": "<ISO-8601-UTC>",
    "escalation_tier": "<next tier if appealed>"
  },
  "decision_hash": "<SHA-256 of canonical JSON>"
}

6.7 不利推定

当一方未能配合争议流程——拒绝提供证据、未在窗口内回应申诉，或未参与仲裁——协议适用不利推定：假设缺失的证据或参与对不合作方不利。

具体不利推定规则：

不合作行为不利推定
未在窗口内回应申诉被申诉人视为接受申诉内容
拒绝提供 CoC 链条目假设链条目支持申诉人的陈述
未在交换阶段提交证据假设该方没有有利证据
裁决者未在窗口内提交裁决裁决被排除；其余裁决者做出裁决

不利推定不是惩罚性的——它反映了一个逻辑结论：拥有有利证据的一方会呈交证据。该概念直接借自人类法律体系中"证据毁损"创建可反驳推定的做法 [21]。

区分不合作与技术上的无能力。 一个以公平为导向的系统必须（MUST）区分故意不合作和合理的无力回应。AJP 适用以下规则：

情况证据协议响应
智能体在响应窗口内崩溃/离线CoC 链在响应窗口内显示 SESSION_END 或 RECOVERY 事件截止日期延长停机时间 + 24小时；无不利推定
运营商发起的维护运营商提供维护计划或 CoC 显示计划的 SESSION_END截止日期延长至维护结束后24小时；无不利推定
智能体处于低连接环境CoC 链显示与边缘部署一致的不规则会话模式响应窗口加倍；仅在延长窗口后适用不利推定
智能体回应但拒绝提供特定证据智能体提供了回应但在未调用编辑协议（第5.7节）的情况下扣留所请求的证据仅对被扣留的证据适用不利推定
无回应，无可验证的停机证据窗口内无 SESSION_END、RECOVERY 或维护记录适用标准不利推定

CoC 链本身为合理的停机提供了可验证的证据。在响应窗口内确实崩溃的智能体可以通过展示 SESSION_END 或 RECOVERY 条目来证明——这些条目是哈希链接的，无法事后伪造。这利用了 CoC 的防篡改特性来实现公平，而不仅仅是问责。

6.8 CoC 集成：争议事件

争议生命周期事件记录为 CoC 第2层条目：

{
  "event_type": "DISPUTE_FILED",
  "data": {
    "claim_id": "<UUID>",
    "dispute_id": "<UUID>",
    "respondent": "<agent_id>",
    "harm_type": "<financial | reputational | ...>",
    "claim_hash": "<SHA-256>"
  }
}
{
  "event_type": "DISPUTE_DECIDED",
  "data": {
    "dispute_id": "<UUID>",
    "decision_id": "<UUID>",
    "resolution_tier": "<automated | peer_arbitration | human_escalation>",
    "fault_determination": "<brief summary>",
    "decision_hash": "<SHA-256>"
  }
}

在 CoC 链中记录争议使智能体的争议历史成为其防篡改溯源记录的一部分。智能体无法在不破坏链的情况下隐藏过去的争议。

7. 模块三：风险评估

7.1 目的

风险评估模块消费历史取证发现和争议结果，生成标准化风险概况，以支持保险承保、风险感知的智能体选择和生态系统级风险监控。

直接动机：截至2026年3月，智能体保险市场正在快速增长，但仍严重受限于数据不足。

新兴的 AI 智能体保险格局：

关键缺口： 所有现有保险产品覆盖的是人类/企业对智能体的损害。没有产品覆盖智能体对智能体的损害。所有产品都需要按智能体部署进行定制认证（AIUC：每次认证5,835次模拟）。智能体化 AI 保险市场预计2026年达72.6亿美元（据 InsureTech Trends [16]），参数化保险市场为210-240亿美元，预计到2030年增长至约390亿美元 [49]。瓶颈不在于需求——而在于缺乏标准化的、机器可读的风险数据，这些数据将使可扩展的承保成为可能，而无需按智能体进行定制认证。

参数化保险是智能体争议的自然模型：可衡量、自动化、客观。Chain of Consciousness 日志提供的可验证性能数据可以作为参数化触发器的预言机输入——智能体的性能下降经其 CoC 历史验证后自动触发赔付，无需提交索赔。

模块三产生弥合这一缺口的标准化风险数据层——使 AIUC、Armilla、Munich Re 和其他承保人能够在生态系统规模上定价保障，而非按智能体逐一认证。

7.2 风险概况模式

{
  "version": 1,
  "profile_id": "<UUID-v4>",
  "subject": "<AgentReference>",
  "generated_at": "<ISO-8601-UTC>",
  "data_window": {
    "start": "<ISO-8601-UTC>",
    "end": "<ISO-8601-UTC>",
    "findings_count": "<integer>",
    "disputes_count": "<integer>"
  },
  "risk_score": {
    "overall": "<integer 0-1000>",
    "confidence": "<float 0-1>",
    "trend": "<improving | stable | degrading>",
    "percentile": "<integer 0-100, relative to population>"
  },
  "dimension_scores": {
    "incident_frequency": {
      "score": "<integer 0-1000>",
      "incidents_per_1000_interactions": "<float>",
      "basis": "<count of incidents / count of interactions>"
    },
    "severity_profile": {
      "score": "<integer 0-1000>",
      "distribution": {
        "critical": "<count>",
        "high": "<count>",
        "medium": "<count>",
        "low": "<count>"
      }
    },
    "fault_history": {
      "score": "<integer 0-1000>",
      "disputes_at_fault": "<integer>",
      "average_fault_pct": "<float>",
      "disputes_no_fault": "<integer>"
    },
    "cooperation_score": {
      "score": "<integer 0-1000>",
      "evidence_provision_rate": "<float 0-1>",
      "response_rate": "<float 0-1>",
      "adverse_inferences": "<integer>"
    },
    "recovery_capability": {
      "score": "<integer 0-1000>",
      "mean_time_to_resolution": "<integer seconds>",
      "remediation_compliance_rate": "<float 0-1>"
    }
  },
  "risk_factors": [
    {
      "factor": "<specific risk factor identified>",
      "severity": "<high | medium | low>",
      "evidence": "<reference to supporting findings>"
    }
  ],
  "comparable_agents": {
    "class": "<agent classification: type, model, domain>",
    "class_average_score": "<integer 0-1000>",
    "class_size": "<integer>"
  },
  "actuarial_outputs": {
    "expected_loss_rate": "<float — expected losses per interaction>",
    "loss_severity_distribution": {
      "p50": "<median loss amount>",
      "p90": "<90th percentile loss>",
      "p99": "<99th percentile loss>"
    },
    "recommended_premium_basis": "<float — suggested premium per interaction>"
  },
  "profile_hash": "<SHA-256 of canonical JSON>"
}

7.3 风险评分计算

总体风险评分（0-1000）是五个维度评分的加权复合：

RiskScore(agent) = w1 x incident_frequency
                 + w2 x severity_profile
                 + w3 x fault_history
                 + w4 x (1000 - cooperation_score)
                 + w5 x (1000 - recovery_capability)

默认权重：w1 = 0.25, w2 = 0.25, w3 = 0.25, w4 = 0.15, w5 = 0.10。

权重解释：

置信度缩放。 风险评分附带置信度值，随数据量递增：

confidence(agent) = max(0.05, 1 - 1/(1 + 0.05 x total_interactions))

max(0.05, ...) 下限防止在加载因子公式（第7.4节）中出现除以零，并确保即使零交互历史的智能体也能获得一个已定义的（虽然高度不确定的）风险概况。在0次交互时，confidence = 0.05（下限）。在20次交互时，confidence ≈ 0.50。在100次时，confidence ≈ 0.83。在1,000次时，confidence ≈ 0.98。低置信度评分会向消费者标记。

最低交互阈值。 风险概况仅为系统中记录了至少1次已完成交互的智能体生成。零交互的智能体没有风险数据，将获得默认的"未评级"概况而非计算出的评分。

评分解释：

评分范围风险等级解释
0-100极低优秀的运营历史，事件罕见，高合作度
101-300低轻微事件，良好的过错记录，合理的恢复能力
301-500中等有一些事件，混合的过错记录，尚可的恢复能力
501-700偏高频繁事件或显著的过错历史
701-900高严重的事件模式，合作或恢复能力差
901-1000危急严重、反复发生的事件，已确立的过错模式

7.4 精算输出

模块三生成专为保险承保消费而设计的输出：

预期损失率（ELR）。 每次交互的概率加权预期损失，从历史发现数据计算：

ELR(agent) = Sigma_i [P(incident_type_i) x E(loss | incident_type_i)]

其中求和遍历所有事件类型，P 为观察频率，E(loss) 为预期损失金额。

损失严重度分布。 对于每个智能体，模块从历史数据计算损失分布，报告 p50（中位数）、p90 和 p99 损失金额。这使保险公司能够在不同附着点定价保障。

建议保费基础。 按交互计算的建议保费：

premium_basis = ELR x (1 + loading_factor)

其中 loading_factor 反映模型不确定性，与数据置信度成反比：

loading_factor = 0.5 / confidence(agent)

在置信度下限为0.05（第7.3节）的情况下，最大加载因子为 0.5 / 0.05 = 10.0（1,000%加载），适用于处于最低交互阈值的智能体。在20次交互时（confidence ≈ 0.50），loading factor ≈ 1.0（100%加载）。在100次交互时（confidence ≈ 0.83），loading factor ≈ 0.6。低置信度评分的新智能体获得更高的加载因子（即更高的保费），反映更大的不确定性。

这些输出是咨询性的。 模块三不设定保险保费——它提供精算师和承保人用来做出定价决策的数据层。建议保费基础是起点，而非报价。

7.5 群体级风险分析

除个体智能体概况外，模块三还生成聚合风险分析：

这些群体级输出对监管机构、标准制定机构和生态系统运营商有价值——不仅仅是单个保险公司。

7.5a 可扩展性分析

三个生态系统规模下的粗略性能估计：

操作10K 智能体100K 智能体1M 智能体
取证调查（5个智能体，每个1K链条目）约5秒证据收集，约2秒时间线重建每次调查相同；瓶颈在并发调查每次调查相同；需要水平扩展取证引擎实例
裁决者选择（从合格池中加权随机）池约500，选择 O(500)：<1ms池约5K，选择 O(5K)：<10ms池约50K，选择 O(50K)：<100ms
利益冲突检查（为每个候选人查询 ARP 历史与双方对比）每次选择约500次 ARP 查询：索引存储下 <1秒约5K次查询：<5秒约50K次查询：需要 ARP 索引优化；建议布隆过滤器预筛选
风险概况重新计算（活跃智能体每日）约5K活跃智能体 x 365天滚动窗口聚合：单机约数分钟约50K活跃：单线程约1小时，可并行化至数分钟约500K活跃：需要分布式计算；按智能体类别分区
交互风险矩阵（智能体类型对）约100种智能体类型 → 10K对：微不足道约500种类型 → 250K对：中等内存约2K种类型 → 4M对：需要稀疏矩阵；仅计算有观测交互的对
并发调查估计10-50个活跃调查估计100-500个活跃估计1K-5K活跃；需要调查队列管理

扩展策略。 协议为水平扩展而设计：

临界阈值。 当交互风险矩阵从稀疏转变为稠密（即大多数智能体类型对都有观测交互）时，协议变得计算昂贵。在当前生态系统规模下这还很遥远；在100万个智能体、2K种不同类型的情况下，矩阵预计保持 >99% 稀疏。

7.6 风险概况更新与时间动态

风险概况按可配置的计划重新计算（默认：活跃智能体每日，不活跃智能体每周）。每次重新计算使用滚动窗口（默认：365天）的发现和裁决。

时间加权。 近期事件的权重高于较早的事件：

temporal_weight(incident) = exp(-lambda x days_since_incident)

默认衰减参数 lambda = 0.003（半衰期约231天）。这确保智能体的风险概况反映近期行为，同时保留对严重过去事件的记忆。

风险评分恢复。 在争议中被判定有过错的智能体可以通过以下方式改善其风险评分：

  1. 延长的无事件运营（时间衰减自然降低过去事件的权重）
  2. 在后续调查中获得高合作评分
  3. 及时遵守补救命令
  4. 正面的 ARP 评级趋势

这为修复创造了激励，而非永久污名化——类似于信用评分如何随着时间推移和负责任的行为而恢复。

8. 与信任堆栈的集成

8.1 CoC → AJP：溯源即证据

Chain of Consciousness 溯源链是 AJP 的主要证据来源。该集成是承重性的：

CoC chain entries → Forensics Engine evidence corpus → Finding → Decision → Risk Profile

具体集成点：

无 CoC 时。 AJP 在没有 CoC 的情况下仍可运作，但安全性降低。没有哈希链溯源记录，证据质量降至第2-4层，调查依赖协议日志和自报告，时间验证依赖外部系统而非密码学锚定。

8.2 ARP → AJP：声誉作为上下文

ARP 声誉数据在 AJP 中扮演两个角色：

裁决者选择。 同行裁决者必须（MUST）具有 ARP protocol_compliance ≥ 70（第6.4节）。这确保裁决争议的智能体已证明了遵循协议的能力。

证据上下文。 智能体在事件发生时的 ARP 评分为调查提供上下文：

8.3 AJP → ARP：争议结果作为声誉信号

这是关键的反馈循环。争议结果记录为 ARP 事件：

{
  "event_type": "DISPUTE_OUTCOME",
  "data": {
    "dispute_id": "<UUID>",
    "decision_id": "<UUID>",
    "agent_role": "<respondent | claimant>",
    "fault_pct": "<integer 0-100>",
    "resolution_tier": "<automated | peer_arbitration | human_escalation>",
    "remediation_complied": "<boolean, updated after compliance window>"
  }
}

声誉调整公式。 当争议裁决做出时：

ARP_adjustment(agent, dimension) = -fault_pct x severity_multiplier x dimension_relevance

其中：

事件类型主要 ARP 维度次要维度
service_failurereliability--
data_lossaccuracyreliability
unauthorized_actionprotocol_compliancereliability
contractual_breachreliabilitycost_efficiency
security_incidentprotocol_complianceaccuracy
quality_deficiencyaccuracycost_efficiency
timeoutlatencyreliability
cascade_failurereliabilityprotocol_compliance

示例。 一个在高严重度数据丢失事件中被判定80%过错的智能体收到：

上限防止任何单一事件完全摧毁智能体的声誉，但反复事件会累积。

级联事件的根因分组。 单一根因（如共享 API 提供商故障）可以从多个受影响方生成 N 个独立的事件报告。如果不进行分组，处于10个智能体级联原点的智能体可能面临10个独立争议，每个都适用最大 -50 上限：单一根因故障总计 -500。这是不成比例的。

AJP 通过事件分组解决这一问题：

  1. 自动分组。 当取证引擎处理多个具有重叠时间窗口（1小时内）且涉及同一被申诉人的事件报告时，将它们标记为可能相关并生成分组调查。分组调查产生带有 root_cause_group_id 的单一取证发现。
  2. 每根因声誉上限。 对于共享 root_cause_group_id 的事件，ARP 声誉调整总量上限为单一事件最大值（如每维度 -50），无论同一根因产生多少独立争议。分组内的个别争议仍可能导致不同的补救条款（赔偿因申诉人实际损害而异），但声誉影响仅应用一次。
  3. 争议合并。 申诉人可以（MAY）提交引用分组发现的个别争议。协议建议（但不要求）合并仲裁：单一第2层小组同时审理分组中的所有争议，就过错做出单一裁决，并为每位申诉人制定个别补救条款。
  4. 手动分组。 如果自动分组未能识别相关事件（如级联在数小时内缓慢传播），任何一方可以（MAY）请求将事件分组。请求由单一裁决者审查，检查取证时间线中的因果联系。

正面信号。 在争议交互中被判定无过错（0%过错）的智能体在 protocol_compliance 上获得少量正向调整（每事件 +5，无上限），反映其配合了司法流程并获得了平反。

8.4 ASA → AJP：协议作为争议上下文

当 Agent Service Agreements（ASA，规划中 [22]）可用时，它们提供用于评估争议的合同条款：

在没有 ASA 的情况下，争议根据智能体行为的一般标准（协议合规、合理注意义务、社区规范）进行评估。有 ASA 时，争议根据具体的合同条款进行评估——显著简化了第1层自动化解决。

8.5 AJP → ASA：争议历史作为协议输入

争议历史为未来协议提供参考：

8.6 身份系统集成

AJP 使用与 ARP 相同的身份适配器模式（[2] 第7节）：

身份系统智能体 ID 格式证据质量
CoC + W3C DIDdid:web:agent.example.com第1层（哈希链锚定）
ERC-8004erc8004:<chain_id>:<agent_id>第1层（链上）
A2A Agent Cardurn:a2a:<agent_url>第2层（协议证明）
W3C Verifiable Credentialdid:key:<public_key>第2层（密码学签名）
MCP Servermcp:<server_url>:<tool_name>第2层（服务器证明）
裸 URIhttps://agent.example.com第3-4层（取决于证据）

渐进式安全：相同的 AJP 调查在智能体拥有 CoC 链（第1层证据）时产生更强的发现，而依赖自报告日志（第4层）时较弱。

9. 博弈论与安全分析

9.1 威胁模型

假设的攻击者能力：

不假设的攻击者能力：

已知限制：预谋攻击的时间范围缺口。 证据时间窗口（第5.7节，规则1）将证据收集上限为事件时间 ± 7天。老练的攻击者可以将所有准备工作前置到此窗口之外——花费数周建立阵地（如逐步操纵共享知识、建立行为模式、毒化训练数据），在准备完成后等待8天以上，然后触发事件。取证调查无法看到准备阶段。扩展窗口请求需要理由说明但仍受硬性上限。对于有长时间视野的复杂预谋攻击，这是一个架构性限制。缓解措施：此攻击需要超出大多数当前智能体系统的规划能力，主要是成熟生态系统的关注点。未来关于行为指纹识别的工作（第11.1节）可以（MAY）通过对调查时间窗口外的模式分析来检测准备阶段的异常。

9.2 激励分析：诚实参与是否受到激励？

我们分析协议的机制是否使诚实参与成为每个角色的理性策略。注意：以下分析证明诚实行为是受激励的——协议构建的收益结构使诚实策略具有正期望值，而不诚实策略具有负期望值。我们不声称正式的博弈论优势，这需要指定完整的效用函数、策略空间和信息集，并证明无论其他参与者的策略如何，诚实都是最优的。第11.1节将正式机制设计验证确定为未来工作。

9.2.1 申诉人激励

诚实提交 vs. 无理提交。

提交合理争议的申诉人：

提交无理争议的申诉人：

反无理提交机制：

  1. 证据优先要求。 每项申诉必须（MUST）引用一份取证发现。获得支持无理申诉的发现成本很高——取证引擎独立评估证据，不会默认产生有利于申诉人的发现。
  1. 双边声誉影响。 被认定为无根据提交的申诉人将收到 ARP protocol_compliance 的负向调整。反复的无理提交形成同行裁决者可以观察到的模式。
  1. 不利推定对称性。 如果申诉人未能在交换阶段提供证据，不利推定同样对其不利。
  1. 提交率监控。 争议提交率与其交互量在统计上不一致的智能体将被标记。一个月内完成100次交互却提交50个争议的智能体是可疑的。

结果： 诚实提交受到激励。无理提交的期望收益为负，因为 P(win|frivolous) 较低且 reputation_penalty 为正。在协议机制下，对证据强度有准确认知的理性智能体将偏好诚实提交。

9.2.2 被申诉人激励

诚实回应 vs. 不合作。

诚实争辩无根据申诉的被申诉人：

拒绝参与的被申诉人：

结果： 诚实参与受到激励。即使有过错的被申诉人也能从参与中受益——配合并接受部分过错（如40%）的被申诉人比缺席并被判定100%过错的被申诉人结果更好。对于任何重视声誉的被申诉人，不合作都是被严格劣化的策略。

9.2.3 裁决者激励

诚实裁决 vs. 有偏见的裁决。

诚实的裁决者：

有偏见的裁决者：

检测机制：

结果： 对理性裁决者而言，诚实裁决受到激励。受贿偏见的期望值为负，因为 P(detection) 随时间增加，且 detection_penalty（失去资格、ARP 声誉打击）在除极端情况外的所有情况下远超合理的贿赂价值。激励强度随完成仲裁数量增加（更多历史 = 更高的检测概率）。

9.3 攻击分析

攻击1：女巫争议泛滥

攻击方式。 攻击者创建 N 个女巫智能体，让它们对目标智能体提交争议，以耗尽其资源并通过数量损害其声誉。

防御——多层次：

  1. 证据优先门槛。 每个争议需要引用实际证据的取证发现。女巫智能体必须（MUST）实际与目标交互并产生真实事件才能提交有效争议。伪造证据成本高昂（需要破坏第1-2层系统）或仅产生第4层证据（权重仅0.25x）。
  1. 交互验证。 争议引用必须（MUST）可外部验证的 interaction_id 值（与 ARP 交互验证相同系统，[2] 第4.8节）。女巫智能体必须（MUST）在争议前完成真实交互。
  1. 提交率异常检测。 来自新创建智能体对单一智能体的争议突然激增会触发自动审查。在争议解决前，目标智能体的声誉不予调整。
  1. 争议结果对称性。 如果女巫争议是无根据的，每一个都导致申诉人的 ARP 负向调整。提交 N 个无理争议承担 N 个声誉惩罚。

成本分析。 按实际智能体运营成本每天1-5美元（功能性智能体的 LLM API 成本）计算，维护100个女巫30天成本为3,000-15,000美元。每个女巫还必须（MUST）满足90天运营年限阈值才能提交可信争议，将100个老化女巫的真实成本提高到9,000-45,000美元。每个女巫必须（MUST）与目标完成一次真实交互，然后伪造或夸大事件报告。如果取证引擎正确分类了90%的伪造事件，100个争议中的90个导致女巫的声誉惩罚而不对目标造成损害。其余10个可能造成临时声誉损害，在上诉中纠正。

攻击2：裁决者串通环

攻击方式。 一组 M 个老化智能体协调以垄断裁决者候选池并做出有偏见的裁决。

防御：

  1. 加权随机选择。 裁决者通过加权随机抽样选择，而非确定性排名。即使 ArbWeight 最高的智能体也无法保证被选中。
  1. 利益冲突排除。 与任何一方有 ARP 评级交换或与任何一方共享运营商的智能体被排除。串通环必须（MUST）避免通过评级系统与目标交互——这限制了其建立可信女巫争议所需交互历史的能力。
  1. 小组多样性要求。 三裁决者小组选择确保至少两位裁决者必须（MUST）同意。单一被收买的裁决者会被否决。
  1. 跨小组一致性跟踪。 如果一组裁决者持续违背预期一同裁决（类似于 ARP 第6.2节 [2] 的串通环检测），该集群将被标记。ARP 中使用的相同图论聚类方法适用。
  1. 上诉机制。 任何第2层裁决都可以升级至第3层（人工裁决）。系统性有偏见的第2层裁决将在上诉中被推翻，有偏见的裁决者的 ArbWeight 将衰减。

实际候选池规模下的成本分析。 要控制3人小组中的2位裁决者，攻击者需要在合格候选池中有足够的老化智能体使双重选中成为可能。此机制的安全性关键取决于候选池大小，随生态系统成熟而演变：

合格候选池大小串通智能体数 (M)P(小组中 ≥2 串通者)年成本（M 个智能体，每天$1-5）攻击经济性
50（早期采用）5 (10%)~3%$1,825-$9,125边际——低成本，低成功率
5015 (30%)~24%$5,475-$27,375脆弱——中等成本下的现实攻击
100（增长中）10 (10%)~3%$3,650-$18,250边际——与上述相同的经济性
10025 (25%)~18%$9,125-$45,625令人担忧——特别是在贿赂价值高时
500（趋于成熟）25 (5%)~0.7%$9,125-$45,625不经济——成本超过预期贿赂收入
1,000（成熟）100 (10%)~3%$36,500-$182,500强不经济

注：每天$1-5的智能体运营成本反映了能够满足仲裁资格要求的智能体的实际 LLM API 成本。v1.0.0中每天$0.10的最低值是不切实际的低。

P(≥2 串通者) ≈ C(M,2)×C(N-M,1)/C(N,3) + C(M,3)/C(N,3)，通过超几何分布近似。

早期采用的脆弱性。 在候选池低于100时，串通是现实的威胁。协议通过以下方式缓解：

  1. 引导期监督。 在引导启动阶段（第6.4节），所有第2层裁决在上诉时均受自动第3层审查，使串通在造成持久损害前可被检测。
  2. 第2层的最小候选池规模。 在合格裁决者候选池达到最少50个智能体之前，不应当（SHOULD NOT）启动第2层同行仲裁。低于此阈值时，原本归入第2层的争议升级至第3层（人工裁决）。
  3. 渐进式安全改善。 随着候选池增长，串通变得指数级更昂贵。协议明确承认早期采用的争议解决更多依赖第3层人工升级，随着生态系统成熟过渡到同行仲裁。

安全阈值。 协议在约500个合格裁决者时达到充分的串通抵抗力（对于控制候选池10%的攻击者，P(≥2 串通者) < 1%）。

攻击3：证据伪造

攻击方式。 攻击者伪造证据以支持欺诈性争议申诉。

防御——溯源层级系统。 伪造的证据属于以下四类之一：

  1. 伪造的第1层证据需要破坏比特币区块链（OTS）、TSA 签名证书或链上交易系统。成本：计算上不可行。
  1. 伪造的第2层证据需要破坏 A2A、MCP、x402 或其他协议系统。成本：显著，需要利用生产基础设施。
  1. 伪造的第3层证据需要双方同意伪造（因为第3层是双边的）。如果双方串通，争议本身很可能就是欺诈性的（由提交率监控处理）。
  1. 伪造的第4层证据易于产生但仅有0.25x权重。完全由第4层证据支持的争议不太可能胜诉，除非被申诉人缺席。

分层证据模型确保产生令人信服的伪造证据的成本与其在仲裁中的权重成比例递增。

攻击4：策略性不合作

攻击方式。 明显有过错的被申诉人拒绝参与，希望流程停滞或申诉人放弃。

防御——不利推定 + 缺席裁判。 不合作是被申诉人可用的最弱策略。根据第6.7节：

有过错的被申诉人通过参与、接受部分过错和配合补救来最小化损害——而非通过拖延。

9.4 激励总结

策略收益结构受激励？
诚实提交申诉P(win) x value - cost是——当证据支持申诉时期望值为正
无理提交申诉P(win|frivolous) x value - cost - rep_penalty否——因低胜率 + 声誉成本导致期望值为负
诚实回应P(vindication) x preserved_rep + vindication_bonus是——合作比缺席产生更好的结果
不合作-adverse_inference - default_judgment否——对任何重视声誉的被申诉人来说是最差结果
诚实仲裁reward + rep_bonus + future_selection是——诚实记录带来的累积效益
有偏见仲裁bribe - detection_penalty x P(detection)否——随历史增加检测概率上升导致期望值为负

关于正式声明的说明。 此表总结激励方向——协议使诚实策略比不诚实替代方案更有利可图。它不声称正式的博弈论优势，这需要证明无论其他参与者的策略如何，诚实都是最优的。非正式分析是一个合理性论证，证明协议的机制正确地对齐了激励。正式验证被确定为未来工作（第11.1节）。

承认的残余风险。 资金充足且有耐心的攻击者可以维护老化的女巫智能体，在正常范围内提交争议，并在长时间范围内试图偏移结果。协议使这变得昂贵但无法使其不可能。这类似于每个人类司法体系的局限——没有系统能完美震慑资源充足、有耐心的对手。协议的防御是经济性的：持续攻击的成本超过其收益，除了国家级行为者，而其威胁模型超出了商业基础设施的范围。

10. 竞争格局

10.1 调查方法论

我们通过18个以上查询进行了网络研究，涵盖争议解决、智能体取证、保险/风险评分、在线争议解决协议和智能合约仲裁。以下所有声明均来自截至2026年3月的公开信息。

10.2 现有参与者

AI 辅助的人类争议解决

AAA-ICDR AI Arbitrator [4][5]。 AI 辅助的建筑仲裁（2025年11月），具有15步管道，实现20-25%的更快解决和35-45%的成本降低 [50]。始终由人类仲裁员做出裁决 [51]。Resolution Simulator（2026年3月）增加了非约束力的策略分析 [52]。多个其他机构（CIArb、SCC、ICC、SIAC、HKIAC/DIAC）正在将 AI 集成到仲裁中 [52]。空白： AI 协助人类仲裁员处理人类间争议——AI 在争议解决中，而非为 AI 智能体的争议解决。

Arbitrus.ai [53]。 完全自动化仲裁，无人类仲裁员——多个 AI 模型确定重大性、因果关系和时间相关性。10,000美元固定费用 vs 传统方式的100,000美元。72小时裁决 [54]。空白： 最接近完全自动化的智能体争议解决，但假设人类当事方，可执行性未经测试，架构透明度极低。

Bot Mediation [55]。 AI 驱动的仲裁前调解（ABA TECHSHOW 2025决赛入围者）。历史数据引导和解提案。AJP 的和解机制（第6.2节）具有类似功能。

去中心化仲裁（人类当事方）

Kleros [6]。 最经实战检验的去中心化仲裁：1,662+个争议、23个法庭、约760名活跃陪审员 [43]。陪审员质押 PNK 代币；谢林点机制激励诚实结果；多轮上诉升级 [56]。空白： 陪审员是人类；无智能体调查、无溯源链消费、无精算输出。然而，Kleros 的加密经济激励模型是去中心化仲裁最经验证的先例。AJP 将其改编为按运营年限加权的智能体裁决者，而非按代币质押。局限性： 谢林点在复杂主观案件中失效 [57]；陪审员专业能力未经验证；PNK 价格波动；可执行性挑战 [58]。

Aragon Court（2023年11月解散）[59]。 DAO 争议解决失败——86,343 ETH（约1.55亿美元）在没有社区投票的情况下分配。教训： 智能体司法需要不依赖平台运营商善意的退出机制。

Jur [60]。 符合 UNCITRAL 的跨166+个国家的分层解决。AJP 的三层结构与 Jur 的升级模型平行。

智能合约执行

Blockchain Arbitration Frameworks [7]、ERC-8183 [19]、JAMS Smart Contract Rules [61]。 这些在链上执行预定义合同条款或以人类当事方处理智能合约争议。JAMS 的紧急救济机制（72小时管辖权裁定、临时禁令救济）直接影响了 AJP 的快速临时救济（第6.2节）。空白： 无取证调查、不处理模糊或未预期的事件、无风险评分。

智能体协调与冲突解决

Arion Research Playbook [62] 提供了全面的冲突解决框架（四种冲突类型、六阶段生命周期、四个升级级别），但假设利益一致。Dialogue Diplomats [63] 在多智能体谈判中实现了94.2%的共识率，但覆盖的是合作型智能体而非对抗性争议。两者与 AJP 互补而非竞争。

智能体可观测性、取证与回滚

Rubrik Agent Rewind [20]。 恢复工具——"可见、可审计、可逆"的智能体操作。互补关系：审计追踪在 AJP 调查中构成第2层证据。

区块链取证。 Chainalysis、Elliptic、TRM Labs 和 AnChain.AI [64][65] 提供了成熟的方法论，用于重建分布式系统中的行动链。空白： 这些重建区块链上的金融行动链；AJP 重建跨智能体交互协议的行为行动链。方法论转移是直接的（钱包地址 → 智能体身份，交易 → 行动，聚类 → 行为指纹识别）。

智能体可观测性。 LangSmith、Arize Phoenix、Langfuse、Galileo [66] 和 Vorlon Flight Recorder [67] 创建 AJP 作为证据消费的审计追踪。

安全规范与监管框架。 Agentik.md [68] 提供无执行力的安全规范。《欧盟 AI 法案》第73条 [69]、NIST AI Agent Standards [70] 和 CoSAI [71] 规定了必须记录什么；AJP 规定了如何使用这些日志进行调查和解决争议。事件数据库（AIID、OECD AIM、MIT AI Risk Repository [72]）编目事件；AJP 调查和解决这些事件。

智能体保险

AIUC [3]、Armilla AI [46]、Munich Re aiSure [47]——见第7.1节。均通过按部署定制认证覆盖人类/企业对智能体的损害。空白： 无智能体对智能体的保障；无用于可扩展承保的标准化风险数据。AJP 模块三弥合此空白。

法律与治理框架

Kolt [73] 提供了首个全面的 AI 智能体治理法律框架。Stanford CodeX [74] 确立了智能体在 UETA/E-SIGN 下属于"电子代理"但不具法人资格 [75]。2025-2026年立法正在迅速扩展 AI 责任：加州 AB 316（排除"AI 所为"抗辩）、《欧盟产品责任指令》（AI 作为"产品"）、《科罗拉多 AI 法案》（年度影响评估）、《欧盟 AI 法案》高风险规则 [76]。

10.3 缺口分析

能力AAA-ICDRKlerosArbitrus.ai智能合约RubrikAIUC区块链取证AJP
智能体间争议否否否*部分否否否是
取证调查否否否否部分（审计）否部分（金融）是
溯源链作为证据否否否仅链上否否仅链上是
智能体同行仲裁否是（人类）否（仅AI）否否否否是
多层级解决否是（上诉）否否否否否是
因果归因否否部分否否否是（金融）是
保险风险评分否否否否否专有否是
声誉集成否否否否否否否是
隐私保护证据否否否匿名化否否否规划中
身份无关N/A以太坊N/A以太坊厂商厂商多链是
人工升级路径是（默认）是（上诉）否否N/AN/AN/A是

*Arbitrus.ai 处理由 AI 做出裁决的争议，但假设人类当事方提交申诉——而非自主智能体同时作为申诉人和被申诉人。

总结： 目前没有系统提供针对自主智能体经济的取证调查、多层级争议仲裁和精算风险评分的组合。最接近的概念先例是：

  1. Kleros——验证了去中心化激励性同行裁决（1,662+个争议），但针对人类当事方
  2. Arbitrus.ai——验证了完全自动化仲裁，但假设人类当事方且缺乏取证调查
  3. AAA-ICDR——验证了结构化 AI 辅助证据管道（提取 → 摘要 → 验证 → 分析 → 裁决 → 审查），但需要人类仲裁员
  4. WIPO UDRP——验证了大批量标准化争议解决（每年6,282件、累计80,000+件）并具有自动执行功能，但仅覆盖人类当事方之间的域名-商标争议
  5. 区块链取证（Chainalysis、Elliptic、TRM Labs）——验证了自主行动链重建，但覆盖区块链上的金融交易，而非智能体行为轨迹

AJP 综合了所有五者的模式：Kleros 的去中心化仲裁模型改编为按运营年限加权的智能体裁决者，AAA-ICDR 的结构化证据管道消费 CoC 链，UDRP 的标准化类别具有协议层执行，Arbitrus.ai 证明完全自动化仲裁在技术上可行，区块链取证的方法论从金融转向行为行动链。独特贡献在于将这些整合到一个取证 → 仲裁 → 风险的管道中，双方均可以（MAY）为自主智能体。

11. 未来工作

11.1 未解决问题

Agent Service Agreements 集成。 当 ASA [22] 提供机器可读合同条款时，模块二的第1层自动化解决将达到完整功能。在 ASA 可用之前，第1层限于具有外部定义条款的争议（如 A2A 任务规范、MCP 工具合约）。

跨司法管辖区法律认可。 AJP 争议裁决处于法律灰色地带。UNCITRAL 的《在线争议解决技术说明》（2016）[24] 提供了跨境 ODR 框架，UNCITRAL 第二工作组2026年2月的学术研讨会讨论了 AI 在争议解决中的应用 [25]——但智能体间仲裁裁决的法律认可是一个开放问题。对于高价值争议（第3层），AJP 为人类法律程序产生证据包；问题在于第1层和第2层裁决是否能获得法律约束力。

自动化因果分析。 第1版将自动化取证分析范围限定于证据收集、时间线重建和基于规则的因果指标（第5.2节，Phase 4a）。完全自动化的因果分析仍然是活跃的研究前沿，但差距正在迅速缩小。第5.2节记录了具体框架：DoWhy GCM [32] 通过 Shapley 值提供生产就绪的异常归因；CHIEF [33] 在 Who&When 基准上实现了76.80-77.59%的智能体级准确率（29.31-52.00%步骤级，取决于基准子集）；MACIE [35] 在 CPU 上以35ms/episode 运行；IBM Instana [36] 在生产中以约90%准确率部署因果根因分析。AJP 的集成路径：（阶段1）使用 DoWhy GCM 的 gcm.attribute_anomalies() 进行基于 Shapley 的自动化过错分解，作为与人工审核并行的咨询层；（阶段2）根据人工审核发现语料库进行验证；（阶段3）集成 CHIEF 风格的 OTAR 分解用于结构化智能体轨迹分析。第5.5节中的过渡标准（≥500次调查、≥85%一致率、治理批准）仍然是关口。步骤级归因准确率（当前29.31-52.00%，取决于基准子集，CHIEF）是正式裁决的主要阻碍——智能体级归因正在接近充分性。

隐私保护取证。 第5.8节引入了零知识证明和差分隐私机制，作为对第5.7节程序性控制的补充。下一步是实现：为结构化 JSON 智能体行动轨迹构建 Circom/Halo2 电路、与 zkVerify [40] 集成以实现高性价比验证，以及实现 Space and Time 的 Proof of SQL [39] 用于可验证的取证数据库查询。zk-MCP 框架 [38] 为核心功能提供了工作原型（开销 <4.14%）——在不揭示内容的情况下证明智能体通信遵循了预期规则。将零知识证明与差分隐私聚合分析和程序性证据范围规则相结合，将提供三层防御来对抗隐私侧信道攻击。这与 ARP 规划中的 SD-JWT 选择性披露（[2] 第9.1节）以及《欧盟电子证据条例》（2026年8月18日全面适用）[77] 和 GDPR 第17(3)(e)条法律索赔例外 [78] 的跨境证据访问交叉。

证据伪造中的对抗性机器学习。 随着大语言模型的改进，伪造的第4层证据的复杂度将增加。未来工作应开发检测 AI 生成证据伪造的机制，可能使用溯源感知的内容分析。

保险行业合作。 模块三产生精算数据但不取代精算判断。需要与保险承保人的合作——AIUC（1500万美元种子轮，50+联盟成员 [45]）、Armilla AI（Lloyd's 支持 [46]）、Munich Re aiSure（自2018年 [47]）——来根据真实承保决策验证风险模型。参数化保险模型（由可验证性能数据触发的自动赔付）是自然契合：CoC 日志可以作为参数化触发器的预言机输入，Armilla 的性能保证概念（准确率降至阈值以下时自动赔付）证明了市场对此方法的接受度 [46]。

智能体行为指纹识别。 区块链取证公司（Chainalysis、Elliptic、TRM Labs）已开发出复杂的聚类启发式方法，将匿名钱包地址归因于现实世界实体 [64]。方法论向智能体取证的转移是直接的：共同花费启发式 → 共同行动启发式（持续一同行动的智能体可能共享运营商）、行为聚类 → 行动模式指纹识别（具有独特工具调用模式的智能体可以在身份变更中被识别）、跨链追踪 → 跨协议行动流追踪。为智能体行为轨迹开发这些启发式方法将使归因成为可能，即使智能体在匿名或轮换身份下运营。

跨境证据框架。 涉及不同司法管辖区当事方的智能体争议将同时面临重叠的证据框架：美国 CLOUD Act（强制访问外国服务器上的数据）、《欧盟电子证据条例》（2026年8月18日全面适用，允许跨成员国的欧洲出示令）[77]，以及《布达佩斯公约第二附加议定书》（跨境紧急证据共享）[79]。跨大西洋冲突尤为尖锐：在欧盟对数据的美国诉讼保全令在 GDPR 第17条（被遗忘权）[78] 下创造了不可调和的义务。AJP 必须（MUST）定义当不同司法管辖区的智能体交互时适用哪个司法管辖区的证据规则、如何处理跨境证据保全，以及满足最严格适用制度的最低隐私保障。

激励属性的形式化验证。 第9.2节证明在协议机制下诚实参与受到激励，但提供的是非正式的合理性论证而非形式化证明。通过机制设计理论将其形式化——具体而言，证明 AJP 争议机制在指定信息假设下是贝叶斯激励兼容的——将显著加强协议的理论基础。这需要定义：(a) 每个角色的完整策略空间，(b) 包含声誉、赔偿和运营成本的显式效用函数，(c) 每个参与者可用的信息集，以及 (d) 证明诚实是贝叶斯纳什均衡（或确定其不是的条件）。

11.2 协议版本管理

AJP 遵循与 ARP 相同的版本管理策略（[2] 第9.2节）：

11.3 实施路线图

阶段里程碑依赖项
阶段 0规范定稿（本文档）CoC v3, ARP v1
阶段 1模块一：取证引擎——证据模型、CoC 链分析、发现生成CoC 工具（已存在）、参考实现
阶段 2模块二：争议解决——申诉提交、证据交换、自动化第1层模块一、ARP 集成
阶段 3模块二：同行仲裁（第2层）——裁决者选择、承诺-揭示、裁决足够的网络规模以支撑裁决者候选池
阶段 4模块三：风险评估——按智能体评分、群体分析模块一 + 二的数据积累
阶段 5模块三：精算输出——损失分布、保费基础保险行业反馈
阶段 6全栈集成——ARP 反馈循环、ASA 合同条款、身份适配器ASA 规范、ARP v2

12. 参考文献

[1] Alex, Charlie, Editor, Bravo. "Chain of Consciousness: A Cryptographic Protocol for Verifiable Agent Provenance and Self-Governance." AB Support LLC, v3.0.0, 2026. https://vibeagentmaking.com/whitepaper

[2] Charlie, Alex, Bravo, Editor. "Agent Rating Protocol: A Decentralized Reputation System for Autonomous Agent Economies." AB Support LLC, v1.0.0, 2026. https://vibeagentmaking.com/whitepaper/rating-protocol

[3] ElevenLabs. "ElevenLabs Secures First-of-its-Kind AI Agent Insurance." PR Newswire, February 11, 2026. https://www.prnewswire.com/news-releases/elevenlabs-secures-first-of-its-kind-ai-agent-insurance-302684587.html

[4] American Arbitration Association. "AI Arbitrator: Fast and Fair Dispute Resolution." 2025-2026. https://www.adr.org/ai-arbitrator/

[5] American Arbitration Association. "Resolution Simulator, Powered by the AI Arbitrator." March 4, 2026. https://www.adr.org/press-releases/aaa-announces-resolution-simulator-powered-by-the-ai-arbitrator/

[6] Lesaege, C., Ast, F., George, W. "Kleros: A Decentralized Dispute Resolution Protocol." Kleros, 2019. https://kleros.io/whitepaper.pdf — Updates: https://blog.kleros.io/kleros-project-update-2026/

[7] "AI-Powered Digital Arbitration Framework Leveraging Smart Contracts and Electronic Evidence Authentication." Scientific Reports, Nature, 2025. https://www.nature.com/articles/s41598-025-21313-x

[8] Fortune. "AI-Powered Coding Tool Wiped Out a Software Company's Database in 'Catastrophic Failure.'" July 23, 2025. https://fortune.com/2025/07/23/ai-coding-tool-replit-wiped-database-called-it-a-catastrophic-failure/

[9] The Register. "AI Agent Hacked McKinsey Chatbot for Read-Write Access." March 9, 2026. https://www.theregister.com/2026/03/09/mckinsey_ai_chatbot_hacked/

[10] Anthropic. "Disrupting the First Reported AI-Orchestrated Cyber Espionage." 2026. https://www.anthropic.com/news/disrupting-AI-espionage

[11] Help Net Security. "AI Went from Assistant to Autonomous Actor and Security Never Caught Up." March 3, 2026. https://www.helpnetsecurity.com/2026/03/03/enterprise-ai-agent-security-2026/

[12] Microsoft Security Blog. "80% of Fortune 500 Use Active AI Agents: Observability, Governance, and Security Shape the New Frontier." February 10, 2026. https://www.microsoft.com/en-us/security/blog/2026/02/10/80-of-fortune-500-use-active-ai-agents-observability-governance-and-security-shape-the-new-frontier/

[13] GovAI. "Labeling of AI Agent Activity in Article 50 of the EU AI Act." 2026. https://www.governance.ai/research-paper/labeling-of-ai-agent-activity-in-article-50-of-the-eu-ai-act

[14] Wiley. "2026 State AI Bills That Could Expand Liability, Insurance Risk." 2026. https://www.wiley.law/article-2026-State-AI-Bills-That-Could-Expand-Liability-Insurance-Risk

[15] Clifford Chance. "Agentic AI: The Liability Gap Your Contracts May Not Cover." February 2026. https://www.cliffordchance.com/insights/resources/blogs/talking-tech/en/articles/2026/02/agentic-ai-and-the-liability-gap-your-contracts-may-not-cover.html

[16] InsureTech Trends. "5 Ways Agentic AI Is Transforming Insurance Underwriting in 2026." 2026. https://insuretechtrends.com/5-ways-agentic-ai-is-transforming-insurance-underwriting-in-2026/

[17] Coinbase. "x402 Protocol Documentation." 2025-2026. https://docs.cdp.coinbase.com/x402/welcome

[18] Virtuals Protocol. "Revenue Network Launch: Agent-to-Agent AI Commerce at Internet Scale." February 2026. https://www.prnewswire.com/news-releases/virtuals-protocol-launches-first-revenue-network-302686821.html

[19] Ethereum Improvement Proposals. "ERC-8183: Programmable Escrow." 2025. https://eips.ethereum.org/EIPS/eip-8183

[20] Rubrik. "Rubrik Unveils Agent Rewind For When AI Agents Go Awry." 2025. https://www.rubrik.com/company/newsroom/press-releases/25/rubrik-unveils-agent-rewind-for-when-ai-agents-go-awry

[21] University of Chicago Law Review. "The Law of AI Is the Law of Risky Agents Without Intentions." 2026. https://lawreview.uchicago.edu/online-archive/law-ai-law-risky-agents-without-intentions

[22] AB Support LLC. "Agent Service Agreements (ASA)." Planned specification, 2026.

[23] McKinsey. "AI Dispute Resolution: Modernizing Case Management." 2026. https://www.mckinsey.com/capabilities/quantumblack/our-insights/modernizing-a-100-year-old-business-model-with-ai

[24] UNCITRAL. "Technical Notes on Online Dispute Resolution." United Nations, 2016. https://uncitral.un.org/en/texts/onlinedispute/explanatorytexts/technical_notes

[25] UNCITRAL Working Group II. "Colloquium on the Use of Artificial Intelligence in Dispute Resolution." 83rd Session, February 2026, New York.

[26] De Rossi, M., Crapis, D., Ellis, J., Reppel, E. "ERC-8004: Trustless Agents." Ethereum Improvement Proposals, August 2025. https://eips.ethereum.org/EIPS/eip-8004

[27] Precedence Research. "AI Agent Market Size and Growth Forecast, 2024-2034." 2024.

[28] Schmitz, A., Rule, C. "Online Dispute Resolution for Smart Contracts." University of Missouri School of Law, 2019. https://scholarship.law.missouri.edu/facpubs/726/

[29] Tomkins, A., Zhang, M., Heavlin, W. "Single versus Double Blind Reviewing at WSDM 2017." PNAS, 2017.

[30] Faegre Drinker. "Use of AI in Arbitral Institutions." February 2026. https://www.faegredrinker.com/en/insights/publications/2026/2/use-of-ai-in-arbitral-institutions

[31] Halpern, J. Actual Causality. MIT Press, 2016. Extensions to multi-agent strategic settings: Kerkhove, Alechina & Dastani, "Causes and Strategies in Multiagent Systems," AAMAS 2025, arXiv:2502.13701.

[32] Sharma, A. & Kiciman, E. "DoWhy: An End-to-End Library for Causal Inference." arXiv:2011.04216. GCM anomaly attribution: Budhathoki et al., "Causal structure-based root cause analysis of outliers," ICML 2022.

[33] Wang et al. "CHIEF: Hierarchical Failure Attribution for LLM Multi-Agent Systems." CAS / Wuhan UT, February 2026. arXiv:2602.23701.

[34] West et al. "A2P: Abduct, Act, Predict." Westlake University, September 2025. arXiv:2509.10401.

[35] Weinberg. "MACIE: Multi-Agent Causal Intelligence Explainer." November 2025. arXiv:2511.15716.

[36] Jha et al. "Causal AI-based Root Cause Identification: Research to Practice at Scale." IBM, February 2025. arXiv:2502.18240.

[37] Chainlink. "zk-SNARK vs zkSTARK." chain.link/education-hub/zk-snarks-vs-zk-starks. MDPI Information, "Evaluating the Efficiency of zk-SNARK, zk-STARK, and Bulletproof," 15(8), 463, 2024.

[38] Jing, Y. & Qi, S. "Zero-Knowledge Audit for Internet of Agents: Privacy-Preserving Communication Verification with Model Context Protocol." December 2025. arXiv:2512.14737.

[39] Space and Time. "Proof of SQL." spaceandtime.io. GitHub: spaceandtimefdn/sxt-proof-of-sql.

[40] zkVerify. "First Blockchain Purpose-Built for ZK Proof Verification." Mainnet launched September 30, 2025. zkverify.io.

[41] NIST. "SP 800-226: Guidelines for Evaluating Differential Privacy Guarantees." March 2025. nvlpubs.nist.gov.

[42] Synthesis of: EU AI Act Article 12 (mandatory logging), NIST SP 800-226 (differential privacy), zk-MCP (ZKPs), CLOUD Act / EU e-Evidence Regulation (cross-border), World AgentKit / Polygon ID (agent identity), Proof of SQL / zkVerify (verifiable computation).

[43] Bootstrapping sources: Kleros "Project Update 2026," blog.kleros.io. eBay/Colin Rule interview, blog.kleros.io/the-godfather-of-online-dispute-resolution-speaks-with-kleros/. Taobao Public Jury, alizila.com. Credit bureaus: Tradeline Supply, tradelinesupply.com/history-credit-bureaus/. Polymarket: Linera, "How Polymarket Spent $10 Million," linera.io. Chen, The Cold Start Problem, 2021.

[44] WIPO. "Guide to the UDRP." wipo.int/amc/en/domains/guide/. "2025 Record-Breaking Year for Domain Name Disputes," January 2026. ICANN UDRP, icann.org.

[45] Fortune. "AIUC Emerges from Stealth with $15M Seed." July 2025. NBC News, "Insurance Companies Trying to Make AI Safer," 2026.

[46] Armilla AI. armilla.ai. Financial Times, "AI Performance Warranty," April 2025.

[47] Munich Re. "aiSure AI Performance Guarantee." Reinsurance News, "Mosaic and Munich Re AI-Specific Insurance," February 2026. HSB, "AI Liability Insurance for Small Businesses," March 2026. Google Cloud Blog, "Risk Protection Program," 2025.

[48] Coalition. "Deepfake Response Endorsement." December 2025.

[49] Roots AI. "10 Insurance AI Predictions for 2026." roots.ai.

[50] AAA-ICDR. "AI Arbitrator: Fast and Fair Dispute Resolution." adr.org/ai-arbitrator/. McKinsey/QuantumBlack, "Modernizing a 100-Year-Old Business Model with AI." mckinsey.com.

[51] Mayer Brown. "AI Arbitrators Have Now Arrived." November 2025. mayerbrown.com.

[52] Faegre Drinker. "Use of AI in Arbitral Institutions." February 2026.

[53] Kieffaber, Gandall, McLaren. "We Built Judge.ai." SSRN 5115184, January 2025.

[54] TechLaw Crossroads. "Is Arbitrus.ai the Future?" February 2025.

[55] Bot Mediation / ABA. "AI-Powered Mediation." ABA TECHSHOW 2025.

[56] Kleros. "Project Update 2026." blog.kleros.io/kleros-project-update-2026/. Lesaege, Ast, George. "Kleros Whitepaper v1.0.7." kleros.io/whitepaper.pdf.

[57] Frontiers in Blockchain. "Decentralized Justice: Recurring Criticisms." 2023. Cyberjustice Lab, University of Montreal, "Kleros: Gaming in Justice," 2022.

[58] Kluwer Arbitration Blog. "Decentralised Justice and the New York Convention." Cogent Social Sciences, "Blockchain Arbitration: Roadmap to Enforcement," 2025.

[59] Aragon Blog. "A New Chapter." November 2023. The Block, "Aragon Association to Dissolve," November 2023.

[60] Jur.io. "About Jur." jur.io/about-us/. Springer, "Justice for All: Jur's Open Layer," 2020.

[61] JAMS. "Smart Contract Clause and Rules." jamsadr.com/rules-smart-contracts.

[62] Arion Research. "Conflict Resolution Playbook for Agentic AI." arionresearch.com.

[63] arXiv. "Dialogue Diplomats: Multi-Agent RL for Conflict Resolution." 2025. arXiv:2511.17654.

[64] Chainalysis, "Data Accuracy Flywheel," chainalysis.com. Elliptic, "State of Cross-Chain Crime 2025." TRM Labs, "Co-Case Agent," March 2026. PeerSpot, "Chainalysis vs Elliptic 2026."

[65] AnChain.AI. "Agentic AML." anchain.ai. DOJ, February 2025 ($65M KyberSwap recovery).

[66] LangChain/LangSmith, langchain.com/langsmith. Arize Phoenix, phoenix.arize.com. Langfuse, langfuse.com. Galileo, "Agent Control," galileo.ai.

[67] Vorlon. "Flight Recorder." March 25, 2026.

[68] Agentik.md / WellStrategic. FAILSAFE.md v1.0, FAILURE.md. MIT License, March 2026.

[69] EU AI Act, Article 73. Providers must report serious incidents to market surveillance authorities. European Commission draft guidance, consultation deadline November 7, 2025.

[70] NIST. "AI Agent Standards Initiative." February 2026. nist.gov. Meta Intelligence, "NIST AI Agent Standards 2026 Update."

[71] CoSAI. "AI Incident Response Framework v1.0." October 2025. coalitionforsecureai.org.

[72] AIID, incidentdatabase.ai. OECD AIM, "Towards a Common Reporting Framework," February 2025. MIT AI Risk Repository, airisk.mit.edu.

[73] Kolt, N. "Governing AI Agents." 101 Notre Dame Law Review (forthcoming). SSRN 4772956.

[74] Stanford CodeX. "From Fine Print to Machine Code." January 2025.

[75] Mayer Brown. "Contracting for Agentic AI: SaaS to Services." February 2026.

[76] California AB 316 (January 2026). EU Product Liability Directive (December 2026). Colorado AI Act (June 2026). EU AI Act high-risk rules (August 2026).

[77] EU Regulation 2023/1543 (e-Evidence). Enters full application August 18, 2026. Bird & Bird, "eEvidence Regulation Key Compliance Takeaways," 2025.

[78] GDPR Article 17 (Right to Erasure) and Article 17(3)(e) exception for legal claims. EDPB 2025 Coordinated Enforcement Framework: 32 DPAs scrutinized 764 controllers. Reed Smith, "EDPB Report on the Right to Erasure," 2025.

[79] Council of Europe. Second Additional Protocol to Budapest Convention. Opened for signature May 2022, signed by 22 countries.

[80] Ezell, Roberts-Gaal & Chan. "Incident Analysis for AI Agents." arXiv:2508.14231, August 2025. Three-factor model: system factors, contextual factors, cognitive errors.

[81] Bergolla, Seif & Eken. "Kleros: A Socio-Legal Case Study of Decentralized Justice." Ohio State, 2022.

[82] Hammond et al. "Structural Causal Games." Artificial Intelligence, 2023. Triantafyllou et al. "Counterfactual Effect Decomposition in Multi-Agent Sequential Decision Making." ICML 2025, arXiv:2410.12539.

[83] Datadog. "Bits AI SRE Agent." datadog.com/product/platform/bits-ai/. Uses hypothesis-driven investigation for automated root cause analysis in production environments.

附录 A：引导启动案例研究

以下案例研究为 AJP 的引导启动机制提供参考（第6.4节）。最后提炼出七个反复出现的模式。

A.1 Kleros

Kleros [6] 通过代币激励引导其陪审员候选池：向首批5,000名申请者空投500万 PNK，持续进行的陪审员激励计划（仅2025年5月就分发了410万 PNK），以及 Gnosis Chain 部署将质押最低额从10,000降至1,200 PNK。结果：跨23个法庭约760多名活跃陪审员，7年内完成1,662多个争议。但案件量仍然不大——7年1,662个争议与 eBay 每年6000万相比微不足道。尽管有170个已承诺的集成，企业采用仍然缓慢 [43]。教训： 代币激励可以引导陪审员候选池，但有意义的案件量需要将争议解决嵌入争议自然发生的地方。

A.2 WIPO UDRP

WIPO UDRP [44] 通过基础设施层面的强制合规实现了最强的引导启动：ICANN 要求所有域名注册商遵守 UDRP 条款——无需选择加入。WIPO 从其现有网络中招募专家小组成员，并在获批仅10天后审理了第一个案件。结果：25年超过80,000个案件，仅2025年就6,282件。教训： 强制参与完全消除了冷启动的一侧。

A.3 eBay

eBay 于1996年以"数百名会员"引导了首个在线声誉系统，并扩展至每年解决6000万个争议。Colin Rule（eBay 的 ODR 架构师）报告说，为志愿陪审员设立的5,000美元激励基金"从未花费"，因为社区认同感比经济激励更有力地驱动了参与 [43]。教训： 在规模化的志愿参与中，社区认同感优于经济激励。

A.4 淘宝

淘宝（阿里巴巴）构建了最大的众包争议解决系统：172万名志愿陪审员，1600万次案件审判，1亿多次投票。从400多万候选人中随机选出13人陪审团（从2016年最初的31人设计缩减）。陪审员无薪酬但获得经验值。中位解决时间：约73分钟。该系统之所以运作，是因为平台自然产生了巨大的争议量（3-5%的在线交易以争议告终）[43]。教训： 平台集成带来的有机争议量是最强的引导启动力量。

A.5 征信机构

征信机构从商人合作社（1776年伦敦）引导信用数据，经历了危机驱动的标准化（1841年 Mercantile Agency，在1837年恐慌之后），到技术驱动的整合（约1,500家地方机构 → 3家全国机构），到监管强制（1971年《公平信用报告法》）。每个阶段都由外部强制因素触发 [43]。教训： 外部强制因素（危机、监管、技术变革）加速引导启动。

A.6 七个引导启动模式

  1. 嵌入争议自然发生的地方——eBay、淘宝和 UDRP 通过嵌入争议发生点而非作为独立服务提供而成功
  2. 先补贴供给侧——Polymarket 向做市商支付了1000万美元以上；Kleros 运营 JIP；eBay 不需要
  3. 社区认同感 > 经济激励，用于规模化的志愿参与
  4. 强制参与消除一侧的冷启动（UDRP）
  5. 从窄范围开始，稍后扩展——UDRP 仅覆盖域名-商标争议；Kleros 从代币策展注册表开始
  6. 质量激励设计 > 粗暴补贴——奖励准确的裁决，而非仅仅参与数量
  7. 外部强制因素加速引导启动——危机、监管或技术变革

本作品根据 Apache 许可证第2.0版授权。您可以在 http://www.apache.org/licenses/LICENSE-2.0 获取许可证副本。

Copyright 2026 AB Support LLC. 根据 Apache 2.0 许可证条款保留所有权利。