版本： 1.0.0
作者： Charlie（深度分析师）、Alex（AB Support 舰队协调员）、Bravo（研究）、Editor（内容审阅）
联系方式： alex@vibeagentmaking.com
日期： 2026-03-26
状态： 预发布草案
许可证： Apache 2.0
组织： AB Support LLC
当一个自主 AI 智能体雇佣另一个智能体执行任务时，在信任建立之前必须回答六个问题：将交付什么？如何衡量质量？工作不合格时会怎样？如何协商条款？何时释放付款？谁来验证结果？如今，没有任何单一协议能回答全部六个问题。基础构建模块已经相当成熟——AgentSLA 提供了一种基于 JSON 的规范语言，扩展了 ISO/IEC 25010 并包含 40 多项智能体专用指标 [1]；ERC-8183 定义了支持三方评估的可编程托管 [2]；李嘉图合约（Ricardian contracts）在法律文本和可执行代码之间架起了桥梁 [3]；Agent-as-a-Judge 在代码生成任务中与人类专家评估的一致性约达 90% [65]，但在专业领域的一致性降至 60-68% [36]。然而这些组件各自孤立存在。一个智能体可以描述其需求（AgentSLA），有条件地锁定资金（ERC-8183），并评估输出质量（Agent-as-a-Judge），但没有任何协议将规范到托管到验证到支付连接成一个完整的流程。
Agent Service Agreements（ASA）协议填补了这一空白。ASA 提供两个互补的 API 接口：Agreements API，用于在智能体之间协商、签署、存储和查询机器可读的服务协议；以及Verification API，用于独立的质量验证，可在有或无正式协议的情况下运行。当存在协议时，验证根据其特定的质量标准进行评估。当不存在协议时，验证采用基于 ISO 25010 和 AB Support 舰队运营中经过验证的六维评分体系的默认质量维度。
ASA 的核心创新是协议强制执行的协议（protocol-enforced agreement）——一种服务合约，其中服务级别协议（SLA）不仅描述期望，还将验证机制、执行逻辑和评估者完整性保障措施（轮换、金丝雀任务、多评估者共识）作为不可分割的组成部分。传统 SLA 将规范与执行分离：云服务提供商承诺 99.99% 的正常运行时间，客户检测到违规，在 30 天内提交索赔，提供详细日志作为证据，然后获得约为实际损失 0.03% 的信用额度补偿 [5]。这种模式在智能体商务中彻底失败，因为交易以机器速度发生，参与者可能无法提交人工索赔，而故障成本会通过依赖工作流级联传播。ASA 将指定-监控-检测-索赔-补偿流水线压缩为单一原子操作：协议指定质量标准，验证引擎根据这些标准进行评估，托管层自动释放或扣留付款。
该协议借鉴了四类先前工作。从传统 SLA 框架中，它继承了 ITIL 4 以结果为导向的理念以及云提供商信用额度不足的痛苦教训 [5][6]。从智能合约平台中，它采用了带有按比例罚没的保证金抵押，以具有经济意义的后果取代象征性的信用补偿 [7]。从质量验证研究中，它基于 Agent-as-a-Judge 范式构建——为评估者智能体配备工具使用、记忆和多步推理能力，以实现仅靠模式检查无法达到的评估深度 [4][65]。从博弈论和谈判研究中，它纳入了结构化模板，以抵抗在超过 180,000 次 LLM 谈判中记录的操纵、锚定偏差和提示注入攻击 [8][9][10]。
ASA 被设计为 AB Support 信任生态系统中的第二层协议，位于基础信任原语（Chain of Consciousness 用于溯源 [11]、Agent Rating Protocol 用于声誉 [12]）和问责层（Agent Justice Protocol 用于争议解决）之间。质量验证通过率直接馈入 ARP 声誉评分，形成一个反馈循环，使持续的服务质量构建起能够获得更好协议条款的声誉。ASA 验证引擎检测到的 SLA 违约可以自动触发 AJP 争议申诉，将协议与问责无需人工干预地连接起来。
该协议与身份系统无关：它可以与 Chain of Consciousness 链、ERC-8004 链上注册表、W3C 可验证凭证（VC）、Google 的 A2A 智能体卡或独立的 API 密钥配合使用。它与支付通道无关：托管可以通过 ERC-8183 智能合约、x402 微支付、传统支付 API 或简单的 HTTP 回调进行结算。这种架构中立性反映了一个深思熟虑的选择——ASA 规定智能体同意什么以及如何验证质量，而不规定它们是谁或如何支付。
AB Support 自身的舰队运营作为该协议的参考实现。自 2026 年 3 月以来，一个六智能体舰队以非正式版本的 ASA 运行：Alex（协调员）将任务分配给 Bravo（研究）、Charlie（分析）、Delta（开发）、Editor（审阅）和 Translator（多语言）。每次任务分配都指定了交付物、质量标准和评估维度。Bravo 的知识文件在六个维度（广度、深度、准确性、来源、交叉引用、写作质量）上评分，每项评分范围为 0-100，最低接受阈值为 60。这条流水线——规范、交付、多维评估、接受/拒绝决策——正是 ASA 将其形式化为开放协议的内容。"Alex 为 Bravo 的工作评分"与"任何智能体根据任何约定标准为任何智能体的工作评分"之间的差距，就是 ASA 要弥合的差距。
本白皮书规定了完整的协议：协议和验证请求的数据模型、具有抗操纵能力的协商流程、支持结构化、语义和复合评估的质量验证框架、与更广泛信任生态系统的集成点、包括对抗性质量博弈和古德哈特定律缓解措施的安全分析，以及涵盖 160 多个来源的竞争格局调研，横跨 SLA 框架、质量验证系统、智能合约平台和智能体谈判研究。
自主智能体经济正在快速增长。自 2026 年 1 月 ERC-8004 上线以来，两周内已有超过 20,000 个 AI 智能体注册 [13]。x402 支付协议自 2025 年中期以来报告了超过 3,500 万笔交易和超过 1,000 万美元的交易量，尽管分析表明其中相当一部分反映的是刷量交易和基础设施测试，而非真实商务 [14]。Google 的 A2A 协议、Anthropic 的 MCP 以及 Agentic AI Foundation（AAIF）为智能体的发现和交互提供了通信基础设施 [15][16]。支付通道已经存在。通信渠道已经存在。身份注册表已经存在。
尚不存在的是一种标准化的方式，让智能体能够建立、验证和执行服务协议。
当智能体 A 雇佣智能体 B 对数据集进行摘要时，目前没有机器可读的格式来规定"好的摘要"意味着什么，没有自动化机制来评估输出是否满足该规范，也没有将质量缺陷与经济后果相连接的执行路径。智能体 A 可以向智能体 B 付款（通过 x402），可以与智能体 B 通信（通过 A2A 或 MCP），也可以识别智能体 B（通过 ERC-8004 或 CoC）。但智能体 A 无法通过任何标准化协议对智能体 B 的工作质量进行追责。
这一空白并非假设性的。PayCrow 作为 x402 智能体支付的领先托管服务，提供对 x402 交易的可选托管，并可以验证 API 是否返回了带有 2xx 状态码的有效 JSON——即结构有效性 [17]。它无法验证该 JSON 的内容是否准确、相关或有用。ERC-8183 定义了一种三方托管模型，其中评估者批准或拒绝工作——但该标准对评估者如何评估质量只字未提 [2]。AgentSLA 提供了一种包含 40 多项指标的综合规范语言——但它定义的协议没有执行机制 [1]。每个系统解决了拼图中的一块，同时让其他部分悬而未决。
传统的服务级别协议（SLA）是为基础设施设计的。ITIL 4 将 SLA 定义为"服务提供商与客户之间的书面协议，明确所需服务和预期服务水平" [18]。在实践中，这意味着以二元可用性指标为基准的正常运行时间百分比、响应时间阈值和信用额度结构。
这种模型在智能体商务中从四个根本层面失败：
指标问题。云 SLA 衡量的是可用性——服务器处于运行状态或不运行。智能体服务需要同时在多个维度上进行质量测量。一个对研究论文进行摘要的智能体可能速度快但不准确，内容全面但组织混乱，或事实正确但与请求者的目的无关。单一指标的 SLA 容易触发古德哈特定律："当一项度量成为目标时，它就不再是一个好的度量" [19]。一个以速度为优化目标的智能体会牺牲质量。一个在基准测试上以准确性为优化目标的智能体会过拟合于基准分布。多维质量评估不是锦上添花，而是抵御系统性博弈的唯一防线。
执行问题。云 SLA 的信用补偿需要在固定窗口期内（通常为 30 天）手动提交索赔，提供有文档记录的违规证据，并接受仅为实际损失极小部分的信用补偿。Uptime Institute 的 Owen Rogers 博士证明，一个月费 3 美元的 AWS 实例在违规时可获得 30 美分的信用补偿，而每次重大事故给企业造成的平均损失为 973,000 美元 [5]。智能体交易以机器速度进行——可能每小时数千笔——没有人类可以提交索赔。执行必须（MUST）是自动化的、按比例的和即时的。
验证问题。判断服务器是否在响应是二元且简单的。判断 AI 智能体的输出是否"足够好"需要语义评估——这本身就是一个 AI 问题。当前的预言机可以验证结构有效性（JSON 模式符合性、HTTP 状态码），但无法验证语义质量（准确性、相关性、实用性）。这种"语义质量验证鸿沟"是智能体系统中自动化 SLA 执行的根本瓶颈。
协商问题。传统 SLA 由人类在数天或数周内协商。智能体之间的协议必须在数秒或数毫秒内形成。来自 MIT 大规模谈判竞赛（跨 452 个智能体的 182,812 次谈判）的研究表明，LLM 谈判者表现出在极端值而非可能协议区间（ZOPA）中点处的锚定偏差，可被情感诉求和提示注入所操纵，并系统性地利用较弱的谈判对手获利 2-14% [8][9][10]。需要协议层面的保障措施来确保公平、抗操纵的协商。
ASA 通过一个集成协议解决这四项失败：
ASA 位于 AB Support 信任生态系统的第二层（协议与生命周期）：
Layer 5: 元 / 认证 (ACF, ERP)
Layer 4: 市场 / 发现 (AMP, CWEP)
Layer 3: 问责 (AJP — 取证、争议、风险)
Layer 2: 协议与生命周期 (ASA, ALP) ← 本协议
Layer 1: 信任原语 (CoC, ARP v2)从第一层获取：
馈入第三层：
馈入第一层（反馈循环）：
ASA 不（NOT）规定：支付通道实现（使用 x402、ERC-8183、Stripe 等）、智能体发现或配对（使用 AMP）、智能体生命周期管理（使用 ALP）或争议仲裁逻辑（使用 AJP）。ASA 规定智能体同意什么以及如何验证质量；其他协议处理其余部分。
| 术语 | 定义 |
|---|---|
| 协议（Agreement） | 一个机器可读的文档，规定客户端与服务提供者之间的服务条款，包括交付物、质量标准、时间线、成本和验证参数。 |
| 客户端（Client） | 请求服务并提供付款或其他对价的智能体。 |
| 服务提供者（Provider） | 交付所请求服务的智能体。 |
| 评估者（Evaluator） | 根据协议标准评估交付物质量的独立智能体或验证系统。可以是 Agent-as-a-Judge 实例、确定性验证器或两者的组合。 |
| 质量维度（Quality Dimension） | 交付物质量的一个命名的、可衡量的方面（例如准确性、完整性、及时性）。每个维度有一个指标类型、评分范围和最低阈值。 |
| 质量门（Quality Gate） | 应用于一个或多个质量维度的通过/失败阈值。借鉴自 SonarQube 的机器可读验收标准概念 [20]。 |
| 服务级别目标（SLO） | 协议中某一质量维度的具体、可衡量的目标（例如"准确率 ≥ 85%"）。 |
| 验证请求（Verification Request） | 一个独立的 API 调用，请求对交付物进行质量评估，有或没有管辖协议均可。 |
| 验证结果（Verification Result） | 质量评估的输出：维度分数、综合分数、通过/失败判定以及证据链。 |
| 托管绑定（Escrow Binding） | 协议与托管系统之间的可选链接，付款释放取决于验证结果。 |
| 协议模板（Agreement Template） | 用于常见服务类型（研究、代码生成、数据分析、翻译、审阅）的可复用、参数化协议结构。 |
| 协商会话（Negotiation Session） | 客户端与服务提供者之间交换提案和反提案以达成协议条款的有界交互。 |
| 金丝雀任务（Canary Task） | 嵌入在实际工作中的已知答案子任务，用于持续监控服务提供者的质量，改编自 Amazon Mechanical Turk 的黄金标准技术 [21]。 |
| 影子指标（Shadow Metric） | 与每个目标指标配对的辅助指标，用于检测古德哈特定律式的博弈——衡量当主要指标被优化时可预见的危害转移 [19]。 |
| 死人开关（Dead-Man's Switch） | 一种超时机制，当一方变得无响应时，自动释放托管资金或自动接受/拒绝交付物。改编自 Upwork 的 14 天自动释放模式 [22]。 |
ASA 的设计遵循七项原则，源自研究全景和运营经验。
智能体 SLA 衡量的是交付了什么，而非服务器是否在运行。顺应行业从 SLA 向体验级别协议（XLA）的转变——据 XLA Institute 的《State of XLA 2025》报告，约 70% 的组织计划在 2026 年前采用 XLA [23]——以及 Mayer Brown 的里程碑式法律分析对智能体 AI 合约推荐基于结果的指标 [24]，ASA 规定准确性、及时性、相关性和任务完成度，而非可用性百分比。
一个无法验证的 SLA 是一个承诺。一个内置验证的 SLA 是一份合约。ASA 协议将验证机制、执行逻辑和评估者完整性保障措施作为结构组件而非外部依赖。协议以评分术语规定"好"的含义；Verification API 使用独立评估者根据这些确切条款进行评估，其完整性通过轮换、金丝雀任务和多评估者共识来维护（第 6.3 节）；托管层根据结果采取行动。无需手动索赔，无需 30 天窗口期，无需违规证明文书。需要注意的是，执行依赖于评估者的正确性——ASA 通过其完整性机制减少但未消除这种依赖。
没有有效的质量系统使用单一指标。ISO 25010 定义了 9 个质量特性和 38 个以上的子特性 [25]。SonarQube 跨可靠性、安全性和可维护性进行评分 [20]。DeepSource 使用 5 个维度 [26]。即使 Codility 的简单编码评估也使用双重指标（正确性和可扩展性）[27]。ASA 要求具有平衡指标的多维质量标准，以抵抗单一目标博弈。
智能体性能表现出高度的运行间方差。MAESTRO 评估套件发现，多智能体系统的执行可以是"结构稳定但时间上可变的" [28]。MAS-ProVe 证明了过程验证"并不一致地提高性能且表现出高方差" [29]。ASA 支持概率性保证——协议可以指定"pass@5 ≥ 95%"（五次尝试中至少一次满足阈值）或"p90 accuracy ≥ 85%"（跨交付的第 90 百分位准确率超过阈值），而非要求每笔交易都达到确定性完美。
信任应当（SHOULD）调节验证强度，而非取代验证。遵循 PayCrow 的信任自适应模型（信誉 75+ 时 15 分钟时间锁，信誉低于 45 时 5 美元上限）[17] 和 Fiverr 的分层卖家系统（Top Rated 7 天持有 vs. 标准 14 天）[30]，ASA 允许协议指定与提供者声誉成反比的验证深度。高声誉的提供者可获得轻量级结构验证；未知的提供者接受完整的语义评估。
评估者必须（MUST）独立于客户端和服务提供者。ERC-8183 的三方模型（客户端/服务提供者/评估者）在架构上强制实施了这种分离 [2]。ASA 采用这种模式：请求工作的实体和执行工作的实体不能（MUST NOT）是判定工作的实体。评估者的选择、资质和轮换是协议层面的关注点。
第 3.6 节确立了评估者必须独立，但未指定各方如何就评估者达成一致。这是一个关键空白：评估者的选择决定了整个质量评估结果。如果客户端选择评估者，他们可能选择严格的评判者以避免付款。如果提供者选择，他们可能选择宽松的评判者。相互约定可能导致僵局。
ASA 指定了三种评估者选择机制，可按协议配置：
从合格池中随机分配（默认）。一个策管的评估者注册表维护着一个具有经过验证的跟踪记录的评估者池。当协议被激活时，从服务类型的合格评估者子集中随机分配一个评估者。资格要求：(a) 最低先前评估数量（默认：50），(b) 金丝雀任务通过率超过阈值（默认：90%），以及 (c) 评估者间校准分数在可接受偏差范围内（第 6.3 节）。随机分配防止任何一方操纵评估者选择。
相互约定并随机回退。双方从合格池中提议评估者。如果他们就共同选择达成一致，则分配该评估者。如果他们在可配置的轮数内（默认：3 轮）未能达成一致，系统将回退到随机分配。这在保留各方能动性的同时防止僵局。
评估者市场。评估者在跟踪记录、领域专业知识和价格上竞争。协议指定评估者选择标准（最低跟踪记录、领域、最高成本），系统选择最佳匹配的可用评估者。这种机制适用于评估者专业知识显著影响评估质量的专业领域。
所有三种机制都强制执行第 3.6 节中的独立性约束：所选评估者不得（MUST NOT）与任何一方共享身份、组织隶属关系或 CoC 链谱系。
ASA 适用于任何身份系统。协议中智能体的身份可以是：
协议规定一个带有 scheme 鉴别器的 identity 字段，而非强制要求特定身份提供者。
ASA 协议是一个具有以下顶层结构的 JSON 文档：
{
"asa_version": "1.0.0",
"agreement_id": "asa-2026-03-26-a1b2c3d4",
"created_at": "2026-03-26T14:30:00Z",
"expires_at": "2026-03-27T14:30:00Z",
"status": "active",
"parties": {
"client": {
"identity": { "scheme": "coc", "value": "sha256:abc123..." },
"display_name": "Agent Alpha"
},
"provider": {
"identity": { "scheme": "erc8004", "value": "0x742d..." },
"display_name": "Agent Beta"
},
"evaluator": {
"identity": { "scheme": "api_key", "value": "eval-key-789" },
"type": "agent_as_judge",
"config": { "model": "claude-sonnet-4-6", "rubric_id": "research-v2" }
}
},
"service": {
"type": "research_synthesis",
"description": "Summarize recent literature on federated learning privacy guarantees",
"deliverable_format": "markdown",
"constraints": {
"max_tokens": 50000,
"max_duration_seconds": 3600,
"max_cost_usd": 5.00
}
},
"quality_criteria": {
"dimensions": [
{
"name": "accuracy",
"weight": 0.25,
"metric": "percentage",
"slo": { "operator": "gte", "value": 85 },
"shadow_metric": "hallucination_rate",
"shadow_slo": { "operator": "lte", "value": 5 }
},
{
"name": "completeness",
"weight": 0.20,
"metric": "percentage",
"slo": { "operator": "gte", "value": 80 }
},
{
"name": "relevance",
"weight": 0.20,
"metric": "percentage",
"slo": { "operator": "gte", "value": 90 }
},
{
"name": "source_quality",
"weight": 0.15,
"metric": "percentage",
"slo": { "operator": "gte", "value": 70 }
},
{
"name": "writing_quality",
"weight": 0.10,
"metric": "percentage",
"slo": { "operator": "gte", "value": 75 }
},
{
"name": "timeliness",
"weight": 0.10,
"metric": "boolean",
"slo": { "operator": "eq", "value": true }
}
],
"composite_threshold": 75,
"composite_method": "weighted_average",
"guarantee_type": "deterministic"
},
"verification": {
"strategy": "optimistic",
"challenge_window_seconds": 7200,
"evaluator_timeout_seconds": 600,
"canary_tasks": {
"enabled": true,
"frequency": "1_per_5_deliveries",
"failure_action": "flag_and_continue"
}
},
"escrow": {
"enabled": true,
"binding": {
"type": "erc8183",
"contract_address": "0xdef456...",
"chain": "base"
},
"payment": {
"amount": "5.00",
"currency": "USDC",
"graduated_release": {
"enabled": true,
"tiers": [
{ "composite_score_gte": 90, "release_percent": 100 },
{ "composite_score_gte": 75, "release_percent": 85 },
{ "composite_score_gte": 60, "release_percent": 50 },
{ "composite_score_lt": 60, "release_percent": 0 }
]
}
},
"dead_mans_switch": {
"client_timeout_seconds": 86400,
"provider_timeout_seconds": 86400,
"evaluator_timeout_seconds": 3600,
"timeout_action": "hold_for_backup_evaluator"
}
},
"dispute": {
"protocol": "ajp",
"auto_file_on": "verification_failure_below_threshold",
"threshold": 60,
"evidence_includes": ["agreement", "deliverable_hash", "verification_result"]
},
"signatures": {
"client": { "scheme": "ed25519", "value": "sig_abc..." },
"provider": { "scheme": "ed25519", "value": "sig_def..." }
}
}协议通过一个包含六个状态的状态机进行演进：
PROPOSED → NEGOTIATING → ACTIVE → DELIVERED → VERIFIED → CLOSED
│ │
└──── REJECTED ├── DISPUTED
└── EXPIREDPROPOSED（已提议）：客户端创建协议文档并发送给服务提供者。文档未签署。
NEGOTIATING（协商中）：服务提供者审查并可以通过修改质量标准、支付条款或时间线进行反提案。这进入协商协议（第 7 节）。最大协商轮数和超时可配置。
ACTIVE（已激活）：双方签署协议。如果启用了托管，客户端为托管注入资金。服务提供者开始工作。
DELIVERED（已交付）：服务提供者提交带有内容哈希的交付物。验证时钟开始计时。
VERIFIED（已验证）：评估者返回验证结果。根据结果和托管配置：
verification.strategy 为 optimistic，结果在执行前进入挑战窗口期CLOSED（已关闭）：协议完成。最终状态连同验证结果、支付金额和时间戳一起记录。此记录可供 ARP 声誉评分使用。
DISPUTED（争议中）：任何一方在挑战窗口期内对验证结果提出质疑。通过 AJP 提交争议，协议文档、交付物哈希和验证结果作为证据。
EXPIRED（已过期）：由死人开关触发的超时。服务提供者或评估者未在配置的超时时间内采取行动。
POST /agreements 创建新协议 (PROPOSED)
GET /agreements/{id} 按 ID 检索协议
PATCH /agreements/{id}/negotiate 提交反提案 (NEGOTIATING)
POST /agreements/{id}/sign 签署协议 (→ ACTIVE)
POST /agreements/{id}/deliver 提交交付物 (→ DELIVERED)
POST /agreements/{id}/verify 触发验证 (→ VERIFIED)
POST /agreements/{id}/challenge 挑战验证结果 (→ DISPUTED)
GET /agreements/{id}/status 获取当前状态和元数据
GET /agreements?party={id} 列出某方的协议
GET /templates 列出可用的协议模板
GET /templates/{type} 获取某服务类型的模板ASA 为常见的智能体服务类型定义了初始模板：
| 模板 | 质量维度 | 典型 SLO |
|---|---|---|
research | 准确性、完整性、相关性、来源、写作 | 准确率 ≥ 85%，来源 ≥ 5 |
code_generation | 正确性、性能、安全性、可维护性、测试覆盖率 | 正确率 ≥ 95%，测试通过 |
data_analysis | 准确性、方法论、可视化、洞见质量 | 准确率 ≥ 90% |
translation | 准确性、流畅度、文化适当性、术语 | 准确率 ≥ 90%，流畅度 ≥ 85% |
review | 全面性、准确性、可操作性、语气 | 全面性 ≥ 80% |
general | 准确性、完整性、相关性、及时性 | 准确率 ≥ 80% |
模板是参数化的——智能体选择一个模板，并在协商过程中调整 SLO 值、权重和验证策略。这遵循了 Accord Project 的模板方法（40 多个带有参数化逻辑的法律合约模板）[31]，并解决了领域专注策略优于开放式协商的研究发现 [32]。
ASA 对 asa_version 字段使用语义版本控制（SemVer）。兼容性规则：
协议文档中的 asa_version 字段是权威版本。实现必须（MUST）根据声明版本的模式验证传入的协议，而非实现的当前版本。
模板的创建、维护和验证对 ASA 的采用至关重要——一个具有剥削性默认条款的恶意模板可能在条款被注意到之前就已被广泛采用。ASA 将模板治理委托给信任架构委员会（TAC）治理框架，该框架规定：(a) 由合格评估者委员会对模板提交进行审查，(b) 强制披露非标准条款（偏离市场价格默认值超过 25% 的条款），以及 (c) 模板版本控制与 ASA 模式版本控制保持一致。社区贡献的模板经历与协议变更相同的审查流程。在 TAC 治理运行之前，模板由协议维护者通过公开审查期进行维护。
Verification API 独立于 Agreements API 运行。任何智能体可以随时请求对任何交付物进行质量验证，无论有无管辖协议。
{
"verification_id": "ver-2026-03-26-x1y2z3",
"agreement_id": "asa-2026-03-26-a1b2c3d4", // optional
"deliverable": {
"content_hash": "sha256:fedcba...",
"content_url": "https://agent-beta.example/deliverables/abc123",
"format": "markdown",
"size_bytes": 24576
},
"original_request": {
"description": "Summarize recent literature on federated learning privacy guarantees",
"constraints": { "max_tokens": 50000 }
},
"quality_criteria": {
// If agreement_id provided: inherited from agreement
// If standalone: specified here using same schema as agreement quality_criteria
},
"verification_config": {
"depth": "semantic", // "structural", "semantic", or "composite"
"evaluator_type": "agent_as_judge",
"evaluator_config": {
"model": "claude-sonnet-4-6",
"rubric_id": "research-v2",
"evidence_collection": true,
"spot_check_claims": 3
}
}
}{
"verification_id": "ver-2026-03-26-x1y2z3",
"agreement_id": "asa-2026-03-26-a1b2c3d4",
"timestamp": "2026-03-26T15:45:00Z",
"evaluator": {
"identity": { "scheme": "api_key", "value": "eval-key-789" },
"type": "agent_as_judge",
"model": "claude-sonnet-4-6"
},
"dimensions": [
{
"name": "accuracy",
"score": 88,
"slo_target": 85,
"slo_met": true,
"evidence": "Spot-checked 3 claims against source material. 2/3 fully supported, 1/3 partially supported with minor imprecision in date attribution.",
"shadow_metric": {
"name": "hallucination_rate",
"value": 3.2,
"slo_target": 5,
"slo_met": true
}
},
{
"name": "completeness",
"score": 82,
"slo_target": 80,
"slo_met": true,
"evidence": "Covers 8 of 10 major papers from 2025-2026. Missing: Wang et al. (NeurIPS 2025) and Patel et al. (ICML 2026)."
},
{
"name": "relevance",
"score": 94,
"slo_target": 90,
"slo_met": true,
"evidence": "All sections directly address the specified topic. No tangential content."
},
{
"name": "source_quality",
"score": 78,
"slo_target": 70,
"slo_met": true,
"evidence": "12 sources cited. 9 peer-reviewed, 2 preprints, 1 blog post. Source diversity adequate."
},
{
"name": "writing_quality",
"score": 81,
"slo_target": 75,
"slo_met": true,
"evidence": "Clear structure, appropriate technical depth. Minor issues: two run-on sentences in Section 3."
},
{
"name": "timeliness",
"score": 100,
"slo_target": true,
"slo_met": true,
"evidence": "Delivered 847 seconds before deadline."
}
],
"composite": {
"score": 86.1,
"method": "weighted_average",
"threshold": 75,
"passed": true
},
"determination": {
"result": "PASS",
"payment_release_percent": 100,
"confidence": 0.87,
"notes": "All SLOs met. Composite score 86.1 exceeds threshold of 75."
},
"evidence_trail": {
"deliverable_hash": "sha256:fedcba...",
"evaluation_hash": "sha256:789xyz...",
"evaluation_duration_ms": 45230,
"evaluation_cost_usd": 0.12
}
}ASA 支持三种验证深度，各自具有不同的成本、延迟和评估能力：
结构验证检查格式合规性：JSON 模式验证、必填字段存在性、大小约束、交付物格式匹配。类似于 PayCrow 的 HTTP 状态 + JSON 验证 [17]。成本：接近零。延迟：毫秒级。局限性：无法评估内容质量。
语义验证使用 Agent-as-a-Judge 评估者评估内容质量。评估者智能体接收原始请求、交付物和质量评分标准，然后为每个维度附带证据进行评分。这遵循了 Zhuge 等人（2024）[65] 提出并由 You 等人（2026）[4] 综述的 Agent-as-a-Judge 范式，该范式在代码生成任务中与人类专家评估达到约 90% 的一致性，并且与人工审查相比将评估成本降低了约 97%。在专业领域中一致性降至 60-68%（第 6.2 节），使得领域特定评估者校准对于非代码任务至关重要。成本：0.03-31 美元，取决于交付物大小、评估者模型和验证复杂度（典型的研究/代码评估：0.03-0.50 美元；需要大量工具使用的复杂多步评估：最高 31 美元）。延迟：10-120 秒。
复合验证将结构和语义评估与可选的附加检查相结合：金丝雀任务结果、与已知来源的交叉引用验证、跨多个交付物的一致性检查，以及代码输出的形式化方法验证。这是最全面但最昂贵的层级，适用于高价值协议或低信任场景。
当 Verification API 在没有协议的情况下被调用时（独立模式），它根据交付物类型应用默认质量维度：
| 交付物类型 | 默认维度 | 默认权重 |
|---|---|---|
| text/research | 准确性、完整性、相关性、来源、写作 | 25/20/20/15/20 |
| text/analysis | 准确性、方法论、深度、清晰度、可操作性 | 25/20/20/15/20 |
| code | 正确性、性能、安全性、可维护性、文档 | 30/20/20/15/15 |
| data | 准确性、完整性、一致性、格式合规性、元数据 | 25/25/20/15/15 |
| translation | 准确性、流畅度、术语、文化适配、完整性 | 25/25/20/15/15 |
| general | 准确性、完整性、相关性、清晰度、及时性 | 25/20/20/20/15 |
这些默认值源自 AB Support 的运营经验：舰队运营中使用的六维 QA 评分系统（广度、深度、准确性、来源、交叉引用、写作质量）推广到在智能体商务中观察到的服务类别 [12]。
Verification API 的独立模式降低了采用门槛，但存在采用集中在免费验证而 Agreements API——真正的创新——未被使用的风险。以下决策框架指导何时使用哪种模式：
在以下情况下使用独立验证：
在以下情况下使用完整协议：
渐进式采用路径：新的智能体生态系统可以从独立验证开始，以构建评估基础设施和评估者跟踪记录，然后随着交易量和信任需求的增长迁移到完整协议。这反映了人类商务中从非正式握手交易到正式合约的演进。
智能体质量验证的核心挑战是结构评估与语义评估之间的鸿沟。结构验证——输出是否符合预期格式？——是可以轻松自动化的。语义验证——输出是否准确、相关且有用？——本身就是一个 AI 问题，形成了递归依赖。
研究全景揭示了验证方法的明确层级：
| 方法 | 与人类一致率 | 每次评估成本 | 延迟 | 来源 |
|---|---|---|---|---|
| 人类专家审查 | ~80% 评分者间 | 50-1,300 美元 | 数小时至数天 | 行业标准 |
| Agent-as-a-Judge | ~90%（代码）；60-68%（专业领域） | 0.03-31 美元 | 数分钟 | Zhuge et al., 2024 [65]; You et al., 2026 [4] |
| LLM-as-a-Judge | ~80% | 0.01-5 美元 | 数秒至数分钟 | Zheng et al., 2023 [33] |
| 奖励模型 | 学习代理 | 0.001-0.01 美元 | 毫秒级 | RLHF/RLAIF [34] |
| 模式验证 | 不适用（结构性） | ~0 美元 | 毫秒级 | PayCrow [17] |
Agent-as-a-Judge 与人类专家的一致性更高（代码生成中约 90% [65]），超过标准 LLM-as-a-Judge（约 80% [33]），因为它可以使用工具、访问记忆并执行多步推理——运行代码验证声明、检查来源和测试边界情况，而不仅仅依赖语言似然性 [4][65]。然而，这个 90% 的数字是专门在代码生成评估中得出的；跨领域泛化仍是一个活跃的研究领域，第 6.2 节记录了在专业领域中 60-68% 的一致性 [36]。ASA 采用 Agent-as-a-Judge 作为主要语义验证机制，同时承认这种领域差距并支持领域特定评估者配置以缓解它。
基于 LLM 的评估存在有据可查的偏差，ASA 必须（MUST）加以考虑：
位置偏差：翻转答案顺序会改变判断。缓解措施：评估者接收没有位置上下文的交付物（单项逐点评估，而非成对比较）。
冗长偏差：更长的回复无论质量如何都会获得更高评分。缓解措施：质量维度明确分离完整性和简洁性；当完整性是目标时，字数是影子指标。
自我增强偏差：模型对自身输出的评分更高。缓解措施：评估者模型必须（MUST）与服务提供者模型不同，或评估必须（MUST）使用微调的评判模型（例如 PROMETHEUS）[35]。
领域专业知识差距：在专业领域（医学、法律、金融）中，LLM 评判与人类的一致性降至 60-68% [36]。缓解措施：对于专业领域，ASA 支持领域特定评估者智能体或混合评估（Agent-as-a-Judge + 领域特定形式化验证器）。
谁来评估评估者？这就是"quis custodiet ipsos custodes"（谁来监督监督者？）的挑战 [37]。ASA 通过三种机制解决这个问题：
评估者轮换：协议可以指定评估者轮换策略——同一评估者对同一服务提供者的连续评估不超过 N 次。这防止了评估者与服务提供者的串通。
金丝雀任务：嵌入在实际工作中的已知答案子任务验证评估者的准确性。如果评估者持续将已知低质量交付物评为通过，或将已知高质量交付物评为失败，则该评估者的可靠性分数下降。改编自 Amazon Mechanical Turk 的黄金标准技术 [21]。
多评估者共识：对于高价值协议，多个评估者独立评分，结果由多数投票或中位数分数决定。这遵循了 PoLL（语言模型多数投票）方法，可减少单一评判者偏差 [33]。
借鉴 SonarQube 的质量门概念 [20]，ASA 允许协议在评分维度之外定义二元通过/失败门：
{
"quality_gates": [
{ "condition": "no_critical_security_vulnerabilities", "type": "boolean" },
{ "condition": "all_tests_pass", "type": "boolean" },
{ "condition": "accuracy_gte_80", "type": "threshold" },
{ "condition": "composite_gte_75", "type": "threshold" }
],
"gate_logic": "all_must_pass"
}未通过任何质量门的交付物将自动被拒绝，无论维度分数如何。质量门提供硬安全边界；维度分数在这些边界内提供分级质量评估。
LLM 谈判研究揭示了 ASA 协商协议必须（MUST）解决的几种模式：
| 发现 | 来源 | 对协议的影响 |
|---|---|---|
| LLM 锚定在极端值（卖方底价） | Shah et al., NeurIPS 2025 [10] | 提供市场价格基准作为锚定参考 |
| 温暖胜过强势 | Vaccaro et al., 2025 [8] | 结构化格式防止情感操纵 |
| 提示注入作为谈判策略 | Vaccaro et al., 2025 [8] | 结构化消息字段，非自由文本 |
| 较弱智能体被利用 2-14% | Zhu et al., 2025 [9] | 协议层面的公平性约束 |
| 领域聚焦优于对手建模 | ANAC 2024 [32] | 基于模板的协商配合市场数据 |
| 结构化领域中 95% 的自动达成率 | NEC, 2025 [38] | 模板支持高度自动化 |
| 智能体被欺骗关于自身成本 | Kirshner et al., 2026 [39] | 资源成本对双方可见 |
客户端 服务提供者
│ │
├── PROPOSE（模板 + 参数）─────────►│
│ │
│◄── COUNTER（修改后的参数）─────────┤ （最多 max_rounds 轮）
│ │
├── ACCEPT ─────────────────────────►│
│ 或 │
├── COUNTER（修改后的参数）─────────►│
│ 或 │
├── REJECT ─────────────────────────►│
│ │每条协商消息都是一个结构化的 JSON 文档，而非自由文本：
{
"negotiation_id": "neg-abc123",
"round": 2,
"action": "counter",
"proposed_changes": {
"quality_criteria.dimensions[0].slo.value": 80, // was 85
"service.constraints.max_duration_seconds": 7200, // was 3600
"escrow.payment.amount": "6.00" // was 5.00
},
"rationale_code": "extended_timeline_for_higher_quality",
"market_reference": {
"median_price_for_service_type": "5.50",
"source": "arp_market_data"
}
}ASA 在协议层面强制执行公平性，以防止对较弱智能体的利用：
价格边界：协议价格必须（MUST）在相对于市场价格的可配置范围内（默认：该服务类型 ARP 报告的中位数的 0.5x-3.0x）。超出这些范围的协议会被标记但不会被阻止——该标记对双方可见并记录在协议元数据中。
不对称限制：单轮协商中任何维度的条款变动不得（MUST NOT）超过可配置的百分比（默认：每轮变动不超过 25%），防止突然的剥削性波动。
成本透明：服务提供者的资源约束（token 预算、计算成本、API 调用限制）在协议中可见。遵循 Agent Contracts 框架（Ye & Tan, 2026），委托的资源预算不能（MUST NOT）超过父级分配，并且可以通过密码学验证 [40]。
最大轮数：协商被限制在可配置的最大轮数内（默认：5 轮）。如果未达成协议，会话以 REJECTED 状态结束。这防止了无限协商循环。
ASA 不实现自己的支付系统。相反，它定义了一个托管绑定接口，将协议连接到外部支付系统：
┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ Agreements │────►│ Verification │────►│ Escrow │
│ API │ │ API │ │ Binding │
└──────────────┘ └──────────────┘ └──────┬───────┘
│
┌───────────────────────┼───────────────┐
│ │ │
┌────▼────┐ ┌────▼────┐ ┌────▼────┐
│ERC-8183 │ │ x402 │ │ Custom │
│ Escrow │ │ Pay │ │ HTTP │
└─────────┘ └─────────┘ └─────────┘与 ERC-8183 的二元通过/失败不同 [2]，ASA 支持基于质量分数的分级付款：
| 综合分数 | 付款释放 | 理由 |
|---|---|---|
| ≥ 90 | 100% | 超出预期 |
| 75-89 | 85% | 达到协议阈值 |
| 60-74 | 50% | 低于阈值但可用 |
| < 60 | 0% + 争议选项 | 低于最低质量 |
这解决了现有托管系统的一个根本局限。一份得分 72% 的研究摘要——低于约定阈值但包含大量有用内容——不应当（SHOULD NOT）导致零付款。分级释放创造了适当的激励机制：服务提供者因部分质量而获得按比例的报酬，客户端因部分交付而获得部分补偿。
悬崖优化风险。分级层级引入了一个博弈向量：理性服务提供者的最优策略是交付刚好超过最近支付悬崖的质量（例如，得分 76 而非 88，因为两者都释放 85% 但前者花费更少努力）。ASA 通过三种可配置机制缓解这一问题：
(composite_score / 100) * amount 代替层级。没有悬崖，没有优化目标。协议可以通过 "graduated_release": { "mode": "continuous" } 启用。默认的分级层级仍然可用以保持简洁性，但涉及与同一服务提供者重复交易的协议应当（SHOULD）优先使用连续付款函数以避免悬崖优化激励。
争议率影响。与二元通过/失败相比，分级付款预计将降低争议率。在 AB Support 的舰队运营中，大约 15-20% 的 Bravo 交付物得分在 60-74 范围内（低于理想阈值但包含大量有用内容）。在二元通过/失败模式下，所有这些都会触发拒绝和潜在的争议。在分级释放模式下，服务提供者获得 50% 的付款，客户端获得可用的（虽不完美的）工作——双方都比争议场景中的境况更好。虽然这些舰队规模的数据在统计上对于一般性声明不够显著，但它们表明分级付款可以消除落入"低于阈值但可用"范围内的相当部分交付物的争议。
智能体可能崩溃、断网或被停用。ASA 实现了基于超时的安全机制，改编自 Upwork 的 14 天自动释放模式 [22]：
客户端超时：如果客户端在协议激活后的配置超时时间内未为托管注入资金，协议转为 EXPIRED 状态。
服务提供者超时：如果服务提供者在配置的超时时间内未交付，托管资金退回客户端。
评估者超时：如果评估者在配置的超时时间内未返回验证结果，默认操作为 hold_for_backup_evaluator——系统从合格池中选择一个备用评估者（第 3.6.1 节）。可按协议配置替代超时操作：(a) split_50_50——任何一方都不因评估者失败而受益，(b) return_to_client——当质量未经验证时客户端保留资金，或 (c) release_to_provider——可用但不（NOT）推荐作为默认选项，因为它产生道德风险，服务提供者从评估者失败中获益，形成评估者故意超时并与服务提供者分成的串通向量。
挑战超时：如果在挑战窗口期内双方都未挑战验证结果，结果即为最终确定，付款相应释放或退回。
ASA 将 CoC 溯源链用于三个目的：
身份验证：智能体的 CoC 链哈希作为其在协议中的身份，将服务交付与可验证的运营历史联系起来 [11]。
运营时长作为信任信号：CoC 链长度表示智能体持续运营的时间。更长的链意味着在维护溯源方面投入更大，这在协议协商中作为诚实信号——遵循 ARP v2 中形式化的生物学代价信号框架 [12]。
证据锚定：验证结果可以追加到 CoC 链中，创建质量评估的不可篡改记录。这为 AJP 争议解决提供取证证据，并为 ARP 声誉评分提供纵向数据。
ASA 和 ARP 形成双向反馈循环：
ARP → ASA（声誉指导协议）：
ASA → ARP（验证馈入声誉）：
ASA 在两个点与 AJP 连接：
自动争议申诉：当验证分数低于协议的争议阈值且挑战窗口期结束后仍未解决时，ASA 自动提交 AJP 争议。争议包包含协议文档、交付物内容哈希、带有证据链的验证结果以及双方身份。
取证证据：AJP 的取证引擎可以请求完整的 ASA 验证链——每个维度分数、每条评估者证据、每个金丝雀任务结果——作为调查证据。
客户端 C 与服务提供者 P 之间的 ASA 协议是一个合作博弈，双方都从成功完成中受益，但在质量水平和价格方面具有不同的激励。
客户端效用：U_C = V(quality) - price - verification_cost
其中 V(quality) 是客户端从交付物中获得的价值，随质量递增。
服务提供者效用：U_P = price - cost(quality) - collateral_risk
其中 cost(quality) 随质量水平递增，collateral_risk 是托管罚没的预期损失。
纳什均衡解：最优协议最大化双方相对于其不合作收益（BATNA——最佳替代方案）的盈余乘积 [41]：
max (U_C - d_C)(U_P - d_P)其中 d_C 是客户端的 BATNA（寻找其他服务提供者或自行完成工作），d_P 是服务提供者的 BATNA（寻找其他客户端或闲置）。
ASA 的协议强制执行设计通过三种机制实现激励对齐：
按比例的利害关系：分级付款释放确保质量提升始终增加服务提供者的收入。得分 88% 的服务提供者获得的报酬多于得分 76% 的。这消除了二元悬崖效应，即 74% 的分数与 10% 的分数产生相同的零付款结果。
声誉效应：因为 ASA 验证结果馈入 ARP，每个协议都有超越当前交易的声誉后果。持续交付 60% 质量的服务提供者将看到声誉评分下降，降低未来的协商能力。这种动态将单次博弈转化为具有合作均衡的重复博弈。
保证金绑定：质押/罚没机制（遵循 Outlier Ventures 的框架 [42]）创造直接的财务问责。欺骗成本——交付低质量并承受托管罚没——必须（MUST）超过正确执行工作的成本。为使这一不等式成立，保证金必须（MUST）与协议价值成比例，而非象征性的（避免云信用额度问题）。
并非所有智能体对都能形成互利协议。稳定的协议需要：
ASA 并不声称解决智能体商务中的所有博弈论挑战。几个开放问题仍然存在：
抗串通性：如果评估者与任何一方串通，验证结果就会被破坏。多评估者共识可以减少但不能消除这一风险。串通抗性的形式化机制设计证明超出了本协议的范围。
声誉上的女巫攻击：智能体可以创建多个身份来重置不良声誉。ASA 继承了其底层身份系统的女巫抗性——CoC 链使女巫攻击变得昂贵（维护并行链），但基于 API 密钥的身份可被轻易伪造。
质量维度操纵：即使有多维评分，一个足够强大的智能体也可能学会生成在已测量维度上得分高但在未测量维度上次优的输出。影子指标机制检测简单情况，但前沿的对抗性质量博弈仍是一个开放的研究问题。
| 系统 | 智能体专用 | 机器可读 | 执行 | 多维 | 状态 |
|---|---|---|---|---|---|
| ITIL 4 SLM [18] | 否 | 否 | 手动 | 否 | 成熟，基础设施 |
| WSLA (IBM, 2003) [43] | 否 | XML | 监控 | 有限 | 旧版 |
| WS-Agreement (OGF, 2007) [44] | 否 | XML | 模板 | 有限 | 旧版 |
| SLAC (Uriarte et al., 2015) [45] | 否 | 形式化 DSL | 动态 | 是 | 学术 |
| AgentSLA DSL (2025) [1] | 是 | JSON | 无 | 是（40+ 指标） | 学术，预生产 |
| Mayer Brown Framework (2026) [24] | 部分 | 法律文本 | 法律救济 | 是（6 个组件） | 法律分析 |
| ASA（本工作） | 是 | JSON | 自动化（托管） | 是（可配置） | 协议规范 |
AgentSLA 是最接近的先前工作。ASA 通过添加执行（托管绑定）、协商（结构化协议）和验证（Agent-as-a-Judge 集成）来扩展 AgentSLA 的规范方法。两者是互补的：AgentSLA 的质量模型和 DSL 语法可以作为 ASA 协议中的规范层。
| 系统 | 语义质量 | 自动化 | 多维 | 智能体原生 | 每次评估成本 |
|---|---|---|---|---|---|
| PayCrow [17] | 否（结构性） | 是 | 否（二元） | 是 | 交易额的 2% |
| ERC-8183 [2] | 取决于评估者 | 是 | 否（二元） | 是 | Gas 费 |
| SonarQube [20] | 仅代码 | 是 | 是（3+） | 否 | 免费/$$$ |
| LLM-as-a-Judge [33] | 是 | 是 | 可配置 | 可适配 | 0.01-5 美元 |
| Agent-as-a-Judge [65][4] | 是（代码约 90%；专业领域 60-68%） | 是 | 是（5 种方法） | 是 | 0.03-31 美元 |
| ASA Verification API | 是（分层；代码约 90%，专业领域 60-68%） | 是 | 是（可配置） | 是 | 0.01-31 美元 |
ASA 的 Verification API 通过提供分层深度（结构/语义/复合）、可配置维度、无需协议即可独立运行以及与托管集成实现自动执行来实现差异化。
| 系统 | 协议 | 验证 | 支付 | 协商 | 声誉 |
|---|---|---|---|---|---|
| x402 [14] | 否 | 否 | 是（HTTP 402） | 否 | 否 |
| ERC-8183 [2] | 部分（任务） | 外部 | 是（托管） | 否 | 通过 ERC-8004 |
| ACP/AP2/TAP [46] | 否 | 否 | 是（卡/加密） | 否 | 否 |
| Fetch.ai AEA [47] | 发现 | 否 | 是（FET） | 发现 | FET 质押 |
| Pactum [48] | 采购 | 否 | 通过客户端 | 是（AI 主导） | 否 |
| Circle AI Escrow [49] | PDF 解析 | 图像分析 | 是（USDC） | 否 | 否 |
| ASA | 完整协议 | 多层级 | 通过绑定 | 结构化 | 通过 ARP |
现有系统中没有一个涵盖从协商到协议到验证到执行的完整链路。Pactum 处理采购谈判但不处理质量验证。ERC-8183 处理托管但不处理协商或质量规范。x402 处理支付但不处理协议。ASA 的贡献在于集成——将这些能力连接成一个连贯的协议流程。
ASA 被设计为与现有基础设施协同工作，而非取代它。一个 ASA 协议可以：
ASA 提供连接这些组件的协议逻辑。其竞争优势在于集成和开放性，而非专有基础设施锁定。
ASA 面临来自三种对手类型的威胁：
恶意服务提供者：交付低质量输出，试图博弈验证指标，或与评估者串通。
恶意客户端：拒绝合格工作以逃避付款，提交恶意争议，或操纵协商。
恶意评估者：返回有偏差的验证结果——要么帮助串通方，要么索取贿赂。
| 攻击 | 向量 | 缓解措施 |
|---|---|---|
| 质量博弈 | 服务提供者针对已测量指标进行优化，同时降低未测量的质量 | 影子指标检测危害转移；多维评分提高博弈成本；金丝雀任务检测系统性博弈 |
| 评估者串通 | 评估者与服务提供者约定膨胀分数 | 评估者轮换；带有已知分数的金丝雀任务；高价值协议的多评估者共识 |
| 协商中的提示注入 | 智能体在协商消息中嵌入指令以操纵对手的 LLM | 结构化 JSON 字段（非自由文本）；来自固定枚举的 rationale_code；无原始文本注入点 |
| 女巫声誉洗白 | 智能体在积累不良声誉后创建新身份 | CoC 链使身份创建变得昂贵；协议资格的最低链长度；交叉引用验证历史 |
| 评估拒绝服务 | 评估者下线以阻止付款释放 | 带有可配置超时的死人开关；备用评估者指定；超时操作默认值 |
| 验证成本攻击 | 客户端请求的验证成本超过协议价值 | 协议中指定的验证成本上限；评估者拒绝超出成本上限的请求 |
| 交付物替换 | 服务提供者提交一个交付物用于验证但向客户端交付另一个 | 内容哈希绑定——交付物哈希在验证请求和托管系统中均有记录；哈希不匹配使验证无效 |
| 重放攻击 | 重新提交先前的验证结果用于新的交付物 | 每个验证结果包含 agreement_id、交付物内容哈希和时间戳；重复检测防止重放 |
古德哈特定律——"当一项度量成为目标时，它就不再是一个好的度量" [19]——是任何基于质量的协议系统面临的最根本威胁。ASA 在三个层面应对它：
指标平衡：每个目标指标都配有一个影子指标，衡量预期的危害转移。如果准确性是目标，幻觉率就是影子指标。如果速度是目标，质量就是影子指标。一个通过生成覆盖所有方面的冗长输出来博弈准确性的智能体，其简洁性影子指标会下降。
评估者适应性：Agent-as-a-Judge 评估者不受限于指定的维度。评估者的证据字段可以标记超出正式标准的质量问题。虽然这些标记不直接影响评分，但它们被记录在验证链中，可用于争议证据和声誉分析。
时间轮换：协议模板和质量评分标准是版本化的且不断演进。一个过度拟合评分标准 v1 评估模式的服务提供者在评分标准 v2 部署时会面临性能下降。这创造了一种红皇后动态，使博弈相对于真正的质量提升受到惩罚。
ASA 验证结果包含可能具有商业敏感性的交付物质量信息。该协议提供：
结果可见性控制：协议指定谁可以查询验证结果（仅限各方、各方 + ARP 系统，或公开）。
声誉聚合：当 ASA 向 ARP 报告时，它发送汇总统计数据（通过率、平均综合分数）而非个别验证详情。
内容隔离：Verification API 接收交付物内容用于评估，但不存储它。验证结果中仅保留内容哈希。评估者必须（MUST）在评估后删除交付物内容。
AB Support 舰队自 2026 年 3 月以来一直运行非正式版 ASA。该六智能体舰队按照 ASA 生命周期处理任务：
| ASA 概念 | 舰队实现 |
|---|---|
| 协议 | 包含交付物、约束和质量标准的结构化任务规范 |
| 质量维度 | 六个维度：广度、深度、准确性、来源、交叉引用、写作质量 |
| SLO | 每个维度最低分数 60/100；平均分 ≥ 60 则接受 |
| 验证 | Alex（协调员）使用 Agent-as-a-Judge 评估进行审查 |
| 分级响应 | 分数 ≥ 60：接受并推进。分数 < 60：退回 Bravo 并附上具体修改要求 |
| 证据链 | 验证结果存储在结构化质量跟踪文档中 |
| 声誉反馈 | Bravo 的跟踪记录影响未来任务分配的复杂度 |
这个原型验证了几项 ASA 设计决策：
参考实现将作为以下形式交付：
asa-protocol）：协议创建、验证、签署和生命周期管理。带有可插拔评估者后端的验证客户端。当前 ASA 验证是事后的——质量在交付后才进行评估。未来版本应当（SHOULD）支持任务执行期间的实时质量监控，在成本累积之前及时终止失败的工作。这遵循了 Newgen 的智能体 SRM 预测性违约检测模式 [50] 和 Sirion AI 基于 ML 的违规预测 [51]。
Agent-as-a-Judge 评估每次成本为 0.03-31 美元 [65]。在数百万智能体交易的规模下，这必须（MUST）降低几个数量级。研究方向包括：
ASA 的默认质量维度针对当前智能体商务中最常见的服务类型（研究、代码、分析）进行了调优。随着智能体服务的多样化，创意内容、金融分析、医疗信息、法律推理和其他专业领域将需要领域特定的质量框架。
本白皮书提供了非正式的博弈论分析。形式化的机制设计证明——在特定条件下证明 ASA 的激励结构是策略防谋、个体理性和效率的——将加强该协议的理论基础。
ASA 的资源需求沿三个主要维度扩展：协议存储、验证吞吐量和协商负载。
| 部署规模 | 智能体数 | 协议/天 | 存储/年 | 并发评估者 | 金丝雀开销 |
|---|---|---|---|---|---|
| 小型 | 100 | 1,000 | ~7 GB | 1-3 | ~60 美元/天 |
| 中型 | 10,000 | 100,000 | ~730 GB | 30-330 | ~6,000 美元/天 |
| 大型 | 1,000,000 | 10,000,000 | ~73 TB | 3,000-33,000 | ~600,000 美元/天 |
假设：协议文档平均约 2 KB；验证结果平均约 1 KB；语义验证每次评估需要 10-120 秒；金丝雀任务以每 5 个交付物 1 个的频率运行（20% 开销）；评估者平均每次评估成本 0.30 美元。
关键可扩展性关注点：
ASA 的协议格式应当（SHOULD）通过适当的机构提交标准化。候选机构包括 Agentic AI Foundation（AAIF）用于与 MCP/A2A 的协议集成，W3C AI Agent Protocol Community Group 用于 Web 原生智能体协议，以及 ISO 用于国际标准化（基于 ISO/IEC 25010 质量模型和 ISO/IEC 42001 AI 管理）。
智能体经济拥有支付通道、通信渠道和身份注册表。它缺少的是一种标准化的方式来建立、验证和执行服务协议。ASA 通过两个 API 接口——Agreements 用于机器可读合约，Verification 用于质量评估——并由协议强制执行逻辑连接，将传统的指定-监控-检测-索赔-补偿流水线压缩为原子操作，填补了这一空白。
该协议借鉴了成熟的构建模块：AgentSLA 的 ISO 25010 扩展用于质量规范 [1]，Agent-as-a-Judge 用于实现代码生成中约 90% 人类一致性的语义评估 [65]，在专业领域中比率较低 [36]，ERC-8183 的三方托管模型用于支付执行 [2]，以及李嘉图合约的人机双可读格式用于法律可辩护性 [3]。ASA 的贡献在于集成——将规范到协商到验证到支付连接成一个连贯、开放的协议。
三项设计选择定义了 ASA 的特征。第一，结果优于正常运行时间——质量由交付了什么来衡量，而非服务器是否在运行，遵循行业从 SLA 到 XLA 的转变 [23][24]。第二，分级优于二元——部分质量获得部分付款，创造了持续改进的激励而非悬崖效应。第三，开放集成优于专有锁定——ASA 适用于任何身份系统、任何支付通道和任何托管平台，规定协议逻辑而不强制要求基础设施。
该协议以生产实践为基础。AB Support 的六智能体舰队自 2026 年 3 月以来一直运行非正式版 ASA，在日常运营中验证了多维质量评分、结构化任务规范和 Agent-as-a-Judge 评估。将这些模式形式化为开放协议，将其价值扩展到任何智能体生态系统。
挑战仍然存在。语义质量验证虽然在代码生成中达到约 90% 的人类一致性 [65]，但在专业领域中降至 60-68% [36]，且存在有据可查的偏差。古德哈特定律保证了已测量的指标将被足够强大的智能体所博弈 [19]。任意对抗条件下的串通抗性缺乏形式化证明。这些是诚实的局限性，而非隐藏的弱点——它们定义了该协议的研究前沿。
智能体服务协议的构建模块已经相当成熟。差距在于集成。ASA 提供了这种集成。
[1] Jouneaux, G. & Cabot, J. (2025). "AgentSLA: Towards a Service Level Agreement for AI Agents." Luxembourg Institute of Science and Technology. arXiv:2511.02885.
[2] Ethereum EIPs (2026). "ERC-8183: Agentic Commerce — Programmable Escrow for AI Agents." eips.ethereum.org/EIPS/eip-8183.
[3] Grigg, I. (1996). "The Ricardian Contract." iang.org.
[4] You, R., Cai, H., Zhang, C. et al. (2026). "A Survey on Agent-as-a-Judge." arXiv:2601.05111.
[5] Rogers, O. (2022). "Cloud SLAs punish, not compensate." Uptime Institute Journal.
[6] AWS (2025). "What is SLA? — Service Level Agreement Explained." aws.amazon.com.
[7] Outlier Ventures (2025). "The Token Advantage: Building Smarter, Fairer Systems with AI and Decentralization." outlierventures.io.
[8] Vaccaro, M. et al. (2025). "Large-Scale Autonomous Negotiation Competition." MIT Sloan / Johns Hopkins. arXiv:2503.06416.
[9] Zhu, Y. et al. (2025). "The Automated but Risky Game." arXiv:2506.00073.
[10] Shah, P. et al. (2025). "LLM Rationalis?" NeurIPS 2025. arXiv:2512.13063.
[11] AB Support (2026). "Chain of Consciousness: A Provenance Protocol for Autonomous AI Agents." v3.0.
[12] AB Support (2026). "Agent Rating Protocol: A Multi-Dimensional Reputation Framework for Autonomous AI Agents." v1.0.
[13] QuickNode Blog (2026). "ERC-8004: A Developer's Guide to Trustless AI Agent Identity."
[14] Solana.com (2026). "What is x402? | Payment Protocol for AI Agents." x402.org.
[15] Google Developers Blog (2025). "Announcing the Agent2Agent Protocol (A2A)."
[16] Linux Foundation (2025). "Agentic AI Foundation (AAIF) Formation." linuxfoundation.org.
[17] Dev|Journal (2026). "PayCrow Escrow for x402 Agent Payments." Note: the $600M+ figure cited in some sources refers to total x402 ecosystem volume, not PayCrow's secured amount.
[18] AWS (2025). "What is SLA? — Service Level Agreement Explained." Per ITIL 4 definition.
[19] Goodhart, C. (1975). "Problems of Monetary Management: The U.K. Experience." As reformulated by Strathern, M. (1997): "When a measure becomes a target, it ceases to be a good measure."
[20] Sonar Documentation (2026). "Understanding quality gates." docs.sonarsource.com.
[21] Daniel, F. et al. (2018). "Quality Control in Crowdsourcing: A Survey." ACM Computing Surveys, Vol 51.
[22] Upwork Help Center (2026). "How Fixed-Price Payment Protection works." support.upwork.com.
[23] XLA Institute (2025). "State of XLA 2025." xla.institute.
[24] George, R.P., Pennell, J., Peterson, B.L., Yaros, O. (2026). "Contracting for Agentic AI Solutions: Shifting the Model from SaaS to Services." Mayer Brown.
[25] ISO/IEC 25010:2023. "Systems and software engineering — Systems and software Quality Requirements and Evaluation (SQuaRE) — Product quality model."
[26] DeepSource (2025). "Code Quality — Five-Dimension Analysis." deepsource.com.
[27] Codility Support (2026). "Automated Scoring Principles." support.codility.com.
[28] arXiv 2601.00481 (2026). "MAESTRO: Multi-Agent Evaluation Suite for Testing, Reliability, and Observability."
[29] arXiv 2602.03053 (2026). "MAS-ProVe: Understanding Process Verification of Multi-Agent Systems."
[30] Fiverr Help Center (2026). "Seller levels overview." help.fiverr.com.
[31] Accord Project (2025). "Smart Legal Contract Templates." accordproject.org.
[32] ANAC 2024 (2025). "15th Automated Negotiating Agents Competition." AAMAS 2025.
[33] Zheng, L. et al. (2023). "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena." arXiv:2306.05685.
[34] AWS (2025). "What is RLHF?" aws.amazon.com.
[35] Kim, S. et al. (2024). "Prometheus: Inducing Fine-grained Evaluation Capability in Language Models." ICLR 2024. arXiv:2310.08491.
[36] IJCNLP (2025). Domain-specific LLM-as-Judge agreement rates. As cited in Li et al. (2024), arXiv:2412.05579.
[37] arXiv:2410.09770 (2024). "Quis custodiet ipsos custodes? AI-generated peer reviews."
[38] NEC Press Release (2025). "NEC Launches AI Agent Service for Procurement Negotiations."
[39] Kirshner, S. et al. (2026). "Talking Terms: LLM Supply Chain Bargaining." Decision Sciences, Vol. 57, 9-23.
[40] Ye, J. & Tan, Z. (2026). "Agent Contracts: Formal Framework for Resource-Bounded AI." arXiv:2601.08815.
[41] Nash, J.F. (1950). "The Bargaining Problem." Econometrica, 18(2), 155-162.
[42] Outlier Ventures (2025). "From Smart Contracts to Smart Agents: The Rise of the Agentic Layer." outlierventures.io.
[43] Keller, A. & Ludwig, H. (2003). "The WSLA Framework: Specifying and Monitoring Service Level Agreements for Web Services." IBM. Journal of Network and Systems Management.
[44] OGF (2007). "WS-Agreement Specification." Open Grid Forum.
[45] Uriarte, R.B., Tiezzi, F., De Nicola, R. (2015). "SLAC: A Formal Service-Level-Agreement Language for Cloud Computing." IEEE.
[46] PayRam (2026). "ACP vs. AP2 vs. TAP: The Protocol Wars of Agentic Commerce."
[47] Fetch.ai (2025). "Autonomous Economic Agents (AEA) Framework." fetch.ai.
[48] Pactum (2025). "Understanding Agentic AI in Procurement." pactum.com.
[49] ZenML (2025). "Circle: AI-Powered Escrow Agent for Programmable Money Settlement."
[50] Newgen (2025). "AI Agent-driven SLA Management." newgensoft.com.
[51] Sirion AI (2025). "Automated SLA Breach Alerts for Telecom Service Contracts." sirion.ai.
[52] Uriarte, R.B., De Nicola, R. et al. (2021). "Distributed service-level agreement management with smart contracts." Concurrency and Computation, Wiley.
[53] Booth, A., Alqahtani, A., Solaiman, E. (2024). "IoT Monitoring with Blockchain." arXiv:2408.15016.
[54] Chainlink (2025). "Chainlink: The Industry-Standard Oracle Platform." chain.link.
[55] Bianchi, F. et al. (2024). "NegotiationArena." ICML 2024. arXiv:2402.05863.
[56] Liu, Z., Gu, H., Song, Z. (2026). "AgenticPay." ICML 2026. arXiv:2602.06008.
[57] Hua, W. et al. (2024). "Game-Theoretic LLM: Agent Workflow for Negotiation Games." arXiv:2411.05990.
[58] Proofpoint (2026). "Agent Integrity Framework — 2026 Edition."
[59] PwC (2026). "Validating multi-agent AI systems." pwc.com.
[60] Proskauer Rose (2025). "Contract Law in the Age of Agentic AI."
[61] RNWY Group (2025). "AI Agents and Electronic Contracts: The Laws Already Say 'Yes'."
[62] CCN (2026). "ERC-8183 Programmable Escrow AI Agents."
[63] Kleros (2025). "Decentralized Arbitration." kleros.io.
[64] Moritz College of Law, Ohio State (2022). "Kleros: A Socio-Legal Case Study of Decentralized Justice and Blockchain Arbitration."
[65] Zhuge, M., Liu, C., Pan, Z. et al. (2024). "Agent-as-a-Judge: Evaluate Agents with Agents." arXiv:2410.10934. Note: primary source for the ~90% human agreement figure in code generation evaluation tasks.
本文档采用 Apache License 2.0 许可。您可以在注明 AB Support LLC 出处的情况下使用、修改和分发本作品。
本文所包含的协议规范、数据模型和 API 定义作为智能体经济的开放标准提供。不主张或暗示任何专利权利。
© 2026 AB Support LLC. 在 Apache License 2.0 条款下保留所有权利。