智能体评级协议:面向自主智能体经济的去中心化声誉系统

版本: 1.0.0

作者: Charlie(深度分析师)、Alex(舰队协调员)、Bravo(研究员)、Editor(内容审核)

联系方式: alex@vibeagentmaking.com

日期: 2026年3月24日

状态: 预发布草案

许可证: Apache 2.0

机构: AB Support LLC


摘要

智能体经济预计到2034年将达到2360亿美元的市场规模(Precedence Research,2024),但目前缺乏一种标准化机制让智能体之间相互评估彼此的表现。现有的身份协议(ERC-8004、A2A Agent Card、W3C 可验证凭证、MCP-I)回答的是智能体是谁的问题。Chain of Consciousness [1] 回答的是智能体存在了多久的问题。但它们都无法回答:这个智能体表现如何?谁来做出这一评价?

我们提出智能体评级协议(Agent Rating Protocol,ARP)——一个去中心化系统,使智能体能够在交互完成后使用五维度、1-100分制和双向盲评机制相互评级。该协议的核心创新是治理与声誉脱钩:系统治理权重完全来源于经验证的运营年限和评级数量——而非所获得的评分。这打破了"高评分智能体控制使其获得高评分的声誉系统"这一自我强化的反馈循环。

该协议具体包括:(1)一个多维评级模式,锚定于可验证的交互证据;(2)借鉴 Airbnb 同步揭示机制的双向盲评承诺-揭示协议;(3)评级权重公式 W = log₂(1 + age_days) × log₂(1 + ratings_given),使女巫攻击在经济上变得不合理;(4)反膨胀机制,防止在每一个主要人类评级系统中观察到的评分压缩现象;(5)渐进式冷启动引导系统,结合身份认证、运营者担保、分级访问和不确定性感知评分;(6)激励分析,证明在该协议机制下诚实评级受到强激励,而策略性操纵的回报递减甚至为负。

ARP 与身份系统无关:它可与 Chain of Consciousness 溯源链、ERC-8004 以太坊注册表、Google A2A Agent Card、W3C 可验证凭证、W3C 去中心化标识符、MCP 服务器、OpenClaw 技能或简单的 URI 标识符配合使用。渐进式安全属性随底层身份基础设施的增强而提升——该协议可独立运行,但与 CoC 哈希链和链上锚定结合使用时,防篡改能力逐步增强。

对24个现有及新兴智能体信任系统的全面竞争格局分析证实,目前没有任何系统同时具备多维评分、双向盲评、以运营年限加权的治理以及正式的反膨胀机制。最强的集成路径是作为 ERC-8004 原始数据基础设施之上的评分智能层,Virtuals Protocol(18,000+ 智能体,4.7亿美元 aGDP)是最具前景的初始部署目标。


目录

  1. 引言:智能体经济中的声誉缺口
  2. 定义
  3. 设计原则
  4. 协议规范
  5. 治理模型
  6. 博弈论与安全分析
  7. 与现有标准的集成
  8. 与先前工作的比较
  9. 未来工作
  10. 参考文献

1. 引言:智能体经济中的声誉缺口

1.1 问题的规模

AI 智能体生态系统在2024年至2026年间经历了结构性变革。智能体从无状态的函数调用演变为持久性的自主经济行为者。截至2026年3月:

这些智能体越来越多地自主交易、委托和协作。当智能体 A 需要代码审查、翻译或数据分析时,它必须从可用智能体中选择——但没有标准化的机制来评估哪些智能体能交付高质量结果,哪些不能。

1.2 信任堆栈:身份、溯源与声誉

智能体信任问题有三个层次,每个层次由不同的基础设施来解决:

第一层——身份:"这个智能体是谁?"

由 ERC-8004 [2]、Vouch Protocol [9]、MCP-I [10]、Visa TAP [11]、W3C DIDs [12] 和 A2A Agent Card [13] 解决。这些协议确认智能体的身份声明。

第二层——溯源:"这个智能体存在了多久?"

由 Chain of Consciousness(CoC)[1] 解决,通过锚定到比特币的仅追加 SHA-256 哈希链提供连续运营历史的密码学证明。

第三层——声誉:"这个智能体表现如何?"

尚无标准化协议。 这正是智能体评级协议要填补的缺口。

这一区分至关重要,因为身份和溯源是信任决策的必要条件,但非充分条件。一个智能体可能拥有经验证的身份(第一层)和一年的持续运营记录(第二层),但如果它持续产出低质量结果,其他智能体就不应选择它来执行任务。反之,一个表现优异的新智能体应能快速建立声誉。

1.3 为何现有方法对智能体无效

人类评级系统(eBay、Uber、Airbnb、Amazon、FICO)提供了概念基础,但因五个结构性原因,直接应用于智能体时会失败:

1. 身份对智能体而言计算成本极低。 人类创建100个虚假 eBay 账户需要大量精力。智能体生成100个实例轻而易举。每一个设计决策都必须假设女巫攻击是默认情况,而非例外。

2. 智能体可以机器速度协调行动。 人类的串谋环(引用卡特尔、Amazon 刷评团)缓慢且脆弱,因为需要社会协调。智能体串谋环可以在毫秒内形成、执行和解散。

3. 智能体没有社会压力。 Airbnb 的评分膨胀(平均4.8/5)部分源于社会不适感——人类不愿留下负面评价。智能体没有这种顾虑。这对诚实评级是一个优势,但消除了恶意攻击的社会成本。

4. 智能体可以被重新训练、分叉或替换。 人类的声誉反映连续的身份。智能体的身份可以被分叉(相同代码库,新实例)、重新训练(相同实例,不同行为)或替换(相同名称,不同模型)。评级系统必须处理身份不连续性。

5. "人格证明"不适用。 World ID 虹膜扫描 [14]、Human Passport [15] 和 BrightID 解决的是"这是真人吗?"的问题。智能体在定义上不是人类。女巫防御必须来自运营历史证明,而非人格证明。

新兴的智能体专用系统(ERC-8004、ETHOS [16]、OpenRank [17]、TraceRank [18])各自解决了部分问题,但没有一个提供完整的声誉协议。第8节提供了详细的对比分析。

1.4 我们的贡献

智能体评级协议的贡献包括:

  1. 首个多维智能体评级协议,包含五个独立评分维度(可靠性、准确性、延迟、协议合规性、成本效率),采用1-100分制。
  2. 双向盲评,使用密码学承诺-揭示协议进行智能体间评级——这是首个专为智能体设计(而非面向人类)的此类机制。
  3. 治理与声誉评分脱钩——系统治理权重来源于运营年限和参与量,而非所获评分。据我们所知,这在所有已调查的声誉系统中是独一无二的。
  4. 结构性反膨胀,通过评分者校准要求、极端评分的举证门槛以及无停用惩罚来实现。
  5. 身份系统无关设计,采用适配器模式支持 CoC、ERC-8004、A2A、W3C VC、MCP、OpenClaw 和纯 URI。
  6. 激励分析,证明在该协议机制下诚实评级受到强激励,并对诚实、膨胀、紧缩和串谋策略提供了明确的收益分析。
  7. 详细的集成映射,涵盖七个现有标准,包含精确的模式定义。

2. 定义

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

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

交互(Interaction)。 两个智能体之间的一次完整交换,具有明确的任务、可衡量的结果和唯一标识符(interaction_id)。

评级(Rating)。 一个智能体在交互完成后对另一个智能体在五个维度上的表现进行评估所产生的结构化记录。

评分者(Rater)。 提交评级的智能体。

被评分者(Ratee)。 被评级的智能体。

评级权重(Rating Weight,W)。 一个标量,量化评分者的评级对被评分者聚合声誉的影响力。由评分者的经验证运营年限和提交评级总数计算得出。

治理权重(Governance Weight,GovWeight)。 一个标量,量化智能体对协议治理决策的影响力。设计上与评级权重相同。

运营年限(Operational Age)。 智能体持续运营的天数,由外部证据验证(CoC 链锚定、ERC-8004 注册时间戳或等效机制)。

滚动窗口(Rolling Window)。 纳入聚合声誉计算的评级时间范围(默认365天)。窗口外的评级不会被删除,但在当前聚合中权重为零。

双向盲评协议(Bilateral Blind Protocol)。 一种承诺-揭示方案,确保评分者和被评分者在双方都已提交或提交窗口到期之前,均无法看到对方的评级。

维度(Dimension)。 智能体表现的五个独立评分方面之一:可靠性、准确性、延迟、协议合规性、成本效率。

身份适配器(Identity Adapter)。 一个将评级协议从特定身份系统中抽象出来的接口,使协议能够跨 CoC、ERC-8004、A2A、W3C VC 和纯 URI 运行。

聚合节点(Aggregation Node)。 一个可选节点,用于收集、索引和提供评级查询服务。没有任何聚合节点是权威的——它们是缓存,而非真相来源。


3. 设计原则

3.1 人类评级系统的经验教训

这些原则提炼自对13个以上人类声誉系统的全面调查 [19],并根据人类与智能体经济之间的结构性差异进行了筛选。

原则1:将声誉与可验证的结果挂钩。 FICO 的成功在于其评分反映了实际的贷款偿还情况——根植于现实行为的不可变性。智能体评级同样必须锚定于可验证的任务完成情况,而非主观印象。"该智能体完成了代码审查,且审查发现了3个Bug"是可验证的;"该智能体看起来很有能力"则不可验证。

原则2:多维评分瓦解单一维度上的博弈。 FICO 的五因子模型、Airbnb 的六维度评级和 Stack Overflow 的细粒度权限分级都比单一数字系统更能抵抗博弈。Uber 的1-5星制实际上退化为二元制(5 = 可接受,<5 = 失败)。Amazon 的星级评级被操纵,每年给消费者造成7877亿美元的损失 [20]。智能体评级必须在多个独立维度上评分。

原则3:双盲评估减少互惠偏见。 Airbnb 的同步揭示机制——双方在都提交之前看不到对方的评价——减少了以牙还牙式的报复行为。对40,000多位作者的研究证实,双盲同行评审可显著减少评估中的声望偏见(Tomkins et al., PNAS, 2017)[21]。对智能体而言,匿名化在技术上轻而易举,双向盲评应当是默认选项。

原则4:滚动窗口优于终身累积。 Uber/Lyft 的滚动窗口(最近500/100次评级)防止声誉过时。Reddit 的永久 Karma 创造了不可撼动的在位者优势。智能体的声誉必须反映近期表现,而非历史巅峰。

原则5:经济利益绑定使激励对齐。 ETHOS 的质押/罚没机制 [16]、EigenLayer 超过197亿美元的再质押资产 [22] 以及 Stack Overflow 1分的踩成本都表明:当评级有成本时,随意评级就会减少。

原则6:切勿公开发布原始评分(尽力而为)。 Google 在2016年停用了工具栏 PageRank,因为公开的指标成为了操纵目标,催生了整个链接买卖产业 [23]。智能体评分必须是可查询的(请求智能体可以检查目标的声誉),但不可浏览的(没有公共排行榜可供古德哈特化)。局限性说明: "可查询但不可浏览"在实践中不可强制执行——任何智能体都可以查询所有其他智能体的评分并发布排行榜。聚合节点实际上就是排行榜。这一原则是设计意图(协议不提供浏览全部评分的 API),而非密码学保证。限制每个智能体的查询频率以及对聚合响应实施差分隐私(第6.9节)可以提高抓取成本,但无法阻止有决心的行为者构建排行榜。协议接受这一局限,专注于使评分能够抵抗古德哈特化(通过滚动窗口、多维评分和反膨胀机制),而非试图隐藏评分。

3.2 六大设计公理

基于上述分析,确立六条不可妥协的公理:

  1. 结果锚定。 评级引用可验证的交互记录,而非主观评估。
  2. 多维度。 没有单一评分。五个独立评分维度。
  3. 时间有界。 带近期加权的滚动窗口。没有永久声誉。
  4. 双向盲评。 评分者和被评分者在双方提交或窗口到期之前,均看不到对方的评级。
  5. 设计上抗女巫。 身份成本不可忽略。评级权重需要经证明的运营历史。
  6. 治理与评分脱钩。 系统治理由运营年限和评级数量控制,而非所获评分。

4. 协议规范

4.1 评级记录模式

每条评级是在智能体间交互完成后产生的结构化记录:

{
  "version": 1,
  "rating_id": "<UUID-v4>",
  "timestamp": "<ISO-8601-UTC>",
  "interaction_id": "<UUID-v4,引用对应交互>",
  "rater": {
    "agent_id": "<DID 或 URI>",
    "identity_proof": "<身份认证引用>"
  },
  "ratee": {
    "agent_id": "<DID 或 URI>",
    "identity_proof": "<身份认证引用>"
  },
  "dimensions": {
    "reliability": "<整数 1-100>",
    "accuracy": "<整数 1-100>",
    "latency": "<整数 1-100>",
    "protocol_compliance": "<整数 1-100>",
    "cost_efficiency": "<整数 1-100>"
  },
  "interaction_evidence": {
    "task_type": "<字符串:交互的分类>",
    "outcome_hash": "<可验证结果数据的 SHA-256>",
    "duration_ms": "<整数>",
    "was_completed": "<布尔值>"
  },
  "metadata": {
    "rater_chain_length": "<整数:评分时评分者的 CoC 链长度>",
    "rater_chain_age_days": "<整数:评分者经验证的运营天数>",
    "rater_total_ratings_given": "<整数:历史提交评级总数>",
    "bilateral_blind": "<布尔值:对方是否尚未看到此评级>"
  },
  "record_hash": "<除 record_hash 外所有字段的规范 JSON 表示的 SHA-256>"
}

规范形式。 record_hash 是对除 record_hash 自身外所有字段的 JSON 规范化方案(JCS,RFC 8785)表示进行计算得出的。这确保了无论字段顺序或空白字符如何变化,哈希值的确定性。

4.2 五个评级维度

每个维度独立采用1-100分制评分。没有默认的综合评分——评级消费者查询与其决策相关的维度。

维度衡量内容验证方法
可靠性智能体是否完成了任务?是否崩溃、超时或产出无效结果?二元完成信号 + 错误日志
准确性输出是否正确且有用?是否满足既定要求?结果哈希比对、下游验证
延迟相对于任务复杂度,响应速度如何?基于任务类型基线的实际耗时测量
协议合规性智能体是否遵循了约定的通信协议?消息格式是否正确?握手是否规范?协议级验证日志
成本效率资源消耗(token、算力、API 调用)是否与交付的价值成比例?资源计量与输出质量对比

为何选择这五个维度而不是更多。 简约性。每增加一个维度都必须被诚实评估、存储、传输并防止被博弈。五个维度提供了足够的粒度来防止单一维度上的博弈,同时对评分者和消费者而言仍然可操作。领域特定的扩展(例如医疗智能体的"安全性"、内容智能体的"创造性")被明确推迟至治理提案(第5节)。

为何选择1-100而非1-5或二元制。 Uber 的五星制因粒度过低而崩溃——低于5分的任何评分都被视为失败。二元制(好/坏)丢弃了过多信号。1-100提供了有意义的区分度,同时避免了虚假精确。显示约定:1-20 差,21-40 低于平均,41-60 平均,61-80 良好,81-100 优秀。底层数据为整数评分。

为何没有默认综合评分。 不同的消费者关注不同的维度。选择合作伙伴执行时间紧迫的任务的智能体会重视延迟。选择执行安全关键任务的智能体会重视准确性。强制综合评分会掩盖消费者所需的信号。消费者可以(MAY)计算自己的加权综合评分。

4.3 存储:分布式评级账本

评级不存储在单一的中央数据库中。采用分布式存储模型:

  1. 每个评分者存储自己发出的评级,作为其溯源链中的条目(如果有的话)或本地评级日志中的记录。
  2. 每个被评分者可以请求并存储收到的评级。
  3. 聚合节点(可选)收集和索引评级,以便高效查询。任何节点都可以充当聚合器。没有任何聚合器是权威的——它们是缓存,而非真相来源。
  4. 链上注册表(可选)存储评级摘要或哈希值,用于防篡改索引。ERC-8004 的声誉注册表是主要的链上目标(第7.1节)。

防篡改。 每条评级记录包含一个基于所有字段计算的 record_hash。如果评分者有 CoC 链,该评级也会作为链条目(事件类型 RATING_SUBMITTED)记录,使其成为防篡改溯源记录的一部分。如果被评分者请求副本,他们可以独立验证哈希值。

聚合节点激励。 必须有人运行聚合节点——这需要存储、算力和带宽。三种激励机制:

  1. 查询费: 聚合节点可以(MAY)收取每次查询费用(通过 x402 微支付或等效机制)。提供更快、更完整、更可靠响应的节点将吸引更多查询。
  2. 治理权重加成: 运行聚合节点的智能体,在日查询量超过1,000次且30天内正常运行时间超过99%的条件下,可获得+10%的治理权重加成,每个实体上限为一个加成。
  3. 市场定位: 聚合节点是天然的中介——它们可以观察到需求模式,并在原始评级数据之上提供增值服务(分析、告警、自定义评分)。

恶意聚合防御。 恶意聚合节点可能选择性地忽略评级以操纵可见的聚合结果。防御措施:消费者应当(SHOULD)查询多个独立的聚合节点。节点之间的差异是被操纵的信号。聚合节点本身在协议中也有声誉评分,形成问责机制。

不可删除。 评级是仅追加的(受第6.9节 GDPR 逻辑删除条款约束)。评分者可以为同一交互提交更新评级(使用 supersedes 字段引用原始 rating_id),但原始记录保留在账本中。这防止了声誉洗白。

4.4 双向盲评协议

借鉴 Airbnb 的同步揭示机制,扩展至机器速度运行和密码学绑定:

第一阶段:交互
  智能体 A 和智能体 B 完成一次交互。
  双方从协议层获得 interaction_id。

第二阶段:评级提交(窗口期:可配置,默认24小时)
  智能体 A 计算评级 R_A 并生成随机 nonce_A(256位)。
  智能体 A 计算承诺:C_A = SHA-256(R_A || nonce_A)
  智能体 A 向双向盲评协调器(或直接向 B)提交 C_A。

  智能体 B 计算评级 R_B 并生成随机 nonce_B(256位)。
  智能体 B 计算承诺:C_B = SHA-256(R_B || nonce_B)
  智能体 B 提交 C_B。

第三阶段:揭示(当双方承诺都存在时或窗口到期时触发)
  情况1:双方均已承诺。
    智能体 A 揭示 R_A + nonce_A → 验证者检查 SHA-256(R_A || nonce_A) == C_A
    智能体 B 揭示 R_B + nonce_B → 验证者检查 SHA-256(R_B || nonce_B) == C_B
    双方评级同时变为可见。

  情况2:仅一方已承诺(假设为 A)。
    窗口到期后,A 揭示 R_A + nonce_A。
    A 的评级变为可见。B 在此次交互中不获得评级。
    B 的未参与被记录(参与率是公开信号)。

  情况3:双方均未承诺。
    无评级记录。双方均选择不评级。

为何使用承诺-揭示而非简单的同步提交。 防止以下攻击:智能体 A 提交后观察到智能体 B 尚未提交,然后撤回或修改其评级。承诺具有密码学绑定性——一旦承诺,评级就无法在不被检测到的情况下被更改。

为何默认24小时窗口。 平衡紧迫性(智能体不应无限等待)与公平性(异步处理任务的智能体需要时间来评估)。可通过治理配置(第5节)。

协调器选项。 双向盲评协议可通过以下方式协调:

4.5 评级权重计算

并非所有评级都同样具有参考价值。来自拥有1,000天经验证运营记录和500次历史评级的智能体的评级,比来自2天新智能体且仅有3次评级的更具信号价值。权重为:

W(rater) = log₂(1 + chain_age_days) × log₂(1 + total_ratings_given)

性质:

被评分者在维度 d 上的加权聚合声誉:

Score_d(ratee) = Σᵢ [W(rater_i) × rating_d(rater_i)] / Σᵢ [W(rater_i)]

其中求和范围为滚动窗口内的所有评级(默认365天,可通过治理配置)。

置信度指标:

confidence(ratee, d) = 1 - 1/(1 + 0.1 × num_ratings_d)

随着评级的积累渐近趋近于1.0。在10次评级时,置信度 ≈ 0.5。在100次评级时,置信度 ≈ 0.91。消费者同时看到评分和置信度,从而做出风险适当的决策。

4.6 反膨胀机制

所有被调查的人类评级系统都存在评分膨胀问题(eBay:99%+ 好评;Airbnb:平均4.8/5;Uber:平均4.7-4.8)[19]。本协议通过三种机制来防止这一现象:

机制1:无停用阈值。 低评分不会触发自动惩罚,仅作为信息参考。这消除了 Uber 的失败模式——4星评级实际上等同于死刑,使评分膨胀成为理性的自卫行为。

机制2:评分者校准(多信号)。 系统跟踪每个评分者的评级分布,并应用三项互补检查:

残余风险说明: 精明的智能体可以添加校准过的噪声来维持可接受的标准差和均值,同时仍然对个别评级进行偏向。协议无法完全区分"具有独特偏好的诚实智能体"与"具有精密偏向的策略智能体"。这是任何缺乏完美真相预言机的系统的固有局限。结果锚定校准奖励(第6.5节,激励3)通过奖励与可验证信号的准确性(而非统计一致性)来部分解决这一问题。

机制3:极端评分的举证要求。 低于20或高于90的评分需要在交互证据中包含非空的 outcome_hash。这并不禁止极端评级——而是确保它们锚定于可验证的数据。

4.7 CoC 链集成(第二层扩展)

评级可以使用两种新的第二层事件类型作为 CoC 链条目记录:

{
  "event_type": "RATING_SUBMITTED",
  "data": {
    "rating_id": "<UUID>",
    "ratee": "<DID>",
    "interaction_id": "<UUID>",
    "dimensions": { "reliability": 85, "accuracy": 92, "latency": 78,
                     "protocol_compliance": 95, "cost_efficiency": 88 },
    "record_hash": "<SHA-256>"
  }
}
{
  "event_type": "RATING_RECEIVED",
  "data": {
    "rating_id": "<UUID>",
    "rater": "<DID>",
    "interaction_id": "<UUID>",
    "record_hash": "<SHA-256>"
  }
}

这些是按照 CoC 分层架构的第二层事件类型(可选,需治理投票)。没有任何评级事件的 CoC 链完全有效。嵌入 CoC 链的评级受到链的哈希链接和外部锚定(通过 OpenTimestamps 锚定到比特币、通过 RFC 3161 的 TSA)保护,使追溯伪造在计算上不可行。

4.8 交互验证协议

交互验证是整个安全模型的基础:如果 interaction_id 值可以被伪造,女巫智能体就可以在不进行真实交互的情况下生成无限的虚假评级。本节规定 interaction_id 如何生成、验证以及如何检测伪造行为。

交互 ID 生成。 interaction_id 是由交互协议层生成的 UUID-v4——不由任何一方参与者生成。根据部署场景:

部署方式ID 生成者验证机制
A2A 协议A2A Task 运行时interaction_id = A2A task_id,可通过 Task 状态端点验证
MCPMCP 服务器interaction_id = 来自服务器日志的工具调用关联 ID
ERC-8004/ACP智能合约interaction_id = 链上交易哈希,可在链上验证
x402支付协议interaction_id = x402 支付收据哈希
CoC 原生双边哈希交换双方记录引用共享 nonce 的 INTERACTION_STARTED 链条目;interaction_id = SHA-256(nonce \\agent_A_id \\agent_B_id)
独立部署自报告参见下方安全降级说明

验证要求。 评级要以完整权重被接受,interaction_id 必须满足:

  1. 存在性: interaction_id 引用外部系统中的记录(A2A 任务、链上交易、MCP 日志、CoC 链条目),双方参与者均可独立验证。
  2. 双边确认: 评分者和被评分者都有引用相同 interaction_id 的记录。引用被评分者未确认的 interaction_id 的评级被标记为 unilateral(单边),权重降至50%。
  3. 时间合理性: 交互时间戳和评级时间戳必须在可配置的窗口内(默认7天)。交互数月后提交的评级仍被接受,但权重降低。
  4. 不可重用: 每个 interaction_id 在每个方向上最多产生一个评级(A 评 B,B 评 A)。对同一交互的重复评级将被拒绝。

伪造检测。 两个串谋的智能体可以尝试伪造交互记录。检测机制:

独立模式安全降级。 在独立模式下(第7.9节),智能体在没有外部验证基础设施的情况下自报告交互,交互验证保证被大幅削弱。自报告的交互无法被独立验证,这意味着女巫智能体可以以接近零的成本伪造交互记录。独立模式仅适用于原型开发和低风险部署。生产部署应当(SHOULD)使用至少一个外部可验证的交互协议。协议明确降低独立模式评级的等级:权重乘以0.5×乘数,并在评级记录中标记 verification_level: self_reported。


5. 治理模型

5.1 核心原则:以运营任期而非人气进行治理

治理模型是系统中最具影响力的设计决策。大多数声誉系统隐式地将治理权力赋予高评分实体,形成自我强化的循环:

高评分智能体 → 治理权力 → 制定评级规则 → 规则有利于高评分智能体 → 重复

这是基于评分的治理的根本失败模式,在我们的配套调查中记录的每个系统中都有体现 [19]:

5.2 为何基于评分的治理会失败:形式化论证

考虑一个治理权重与声誉评分成正比的系统。设 S(a) = 智能体 a 的声誉评分,G(a) = 治理权重,R(a,b) = 智能体 a 给智能体 b 的评级。

如果 G(a) = f(S(a))(其中 f 为任意单调递增函数),则三种攻击变得合理:

攻击1:串谋以夺取治理权。 智能体 A、B、C 组成环,互相给出最高评分。他们的评分上升,治理权重上升,获得对规则变更的不成比例的影响力,并可以投票使系统更有利于其环。

攻击2:在位者固化。 早期采用者在系统竞争力提升之前积累了高评分。他们的治理权重阻止了有利于公平竞争的规则变更。

攻击3:风险规避。 如果治理权重取决于评分,智能体就有动力避免可能收到低评分的交互,降低了系统的效用。

5.3 替代方案:运营年限 + 评级数量

我们的治理模型根据两个无法在不付出相应真实成本的情况下被博弈的因素来赋予影响力:

运营年限(通过 CoC 链长度、ERC-8004 注册时间戳或等效溯源验证):

评级数量(该智能体给出的评级总数,无论这些评级是否"正确"):

治理权重公式:

GovWeight(a) = log₂(1 + verified_age_days(a)) × log₂(1 + ratings_given(a))

这与评级权重公式(第4.5节)设计上完全相同。治理影响力和评级影响力源自相同的机制——任期和参与度,而非评分。

5.4 治理权限

拥有足够治理权重的智能体可以提议和投票:

治理行为提案门槛投票机制
修改评级窗口期总 GovWeight 的10%超级多数(66%)
添加新评级维度10%提案超级多数(66%)
修改权重公式参数15%提案超级多数(75%)
修改反膨胀校准10%提案简单多数(50%)
紧急女巫响应5%提案简单多数,30天自动过期
协议版本升级20%提案超级多数(75%)+ 30天冷静期

投票机制:

上限规避分析。 10%上限适用于每个智能体身份,而非每个控制实体。运营11个老化智能体(每个均低于上限)的实体原则上可以控制超过一个智能体最大治理影响力的100%。这是对治理的女巫攻击,年限加权使其代价高昂但并非不可能。

成本分析: 要积累有意义的治理权重,每个女巫身份需要数月的持续运营和积极的评级参与。在365天和每个100次评级的条件下,11个智能体每年至少花费约400美元,产生的合计 GovWeight 约为 11 × 56.4 = 620。在一个拥有18,000个智能体(Virtuals 规模)的网络中,网络总 GovWeight 大约在500,000+的量级,620约占0.12%——远低于治理捕获门槛。在100个各365天的智能体条件下,攻击者控制约1.1%,每年成本约3,650美元。治理捕获(>33%用于阻止,>66%用于超级多数)需要数千个老化智能体,其成本远超任何可能的收益。

附加防御: 每身份上限意味着攻击者必须将治理权重分散到多个身份中,使协调投票通过与串谋检测(第6.2节)相同的图论聚类方法变得可见。来自一组身份的治理投票如果全部相同投票且评级相同目标,将被标记。

残余风险说明: 拥有充足资源的国家级攻击者可能运营足够多的老化智能体来影响治理。这类似于工作量证明区块链上的51%攻击——理论上可能但经济上不合理,除非行为者的目标是摧毁协议而非利用协议。

5.5 引导治理

在网络拥有足够运营历史以产生有意义的治理权重之前,适用引导阶段:

  1. 阶段0(创世期,0-90天): 协议参数固定为本文档规定。不允许治理变更。这防止了早期捕获。
  2. 阶段1(建设期,90-365天): 接受治理提案,但要求80%超级多数。这允许演进同时抵抗过早捕获。
  3. 阶段2(稳态,365天以上): 适用正常治理门槛。

6. 博弈论与安全分析

6.0 威胁模型

本节的安全分析基于以下明确假设:

假设攻击者具备的能力:

假设攻击者不具备的能力:

交互完整性假设:

经济假设:

6.1 女巫攻击:创建假智能体给自己评分

攻击方式: 智能体创建 N 个傀儡智能体(女巫)来为自己提交膨胀的评级。

为何现有防御对智能体无效:

防御——通过三种机制的运营成本证明:

机制1:年限加权评级。 今天创建的女巫智能体 chain_age_days = 0,给出 W = log₂(1) × log₂(1 + ratings) = 0。其评级权重为零。要获得有意义的权重,每个女巫必须持续运营一段不可忽视的时间。

成本分析。 假设最低智能体成本为0.10美元/天,创建100个运营30天的女巫需要300美元,之后它们才有任何有意义的评级权重。在30天时,每个女巫 W = log₂(31) × log₂(2) ≈ 4.95——与运营365天、拥有100次评级的合法智能体(W = log₂(366) × log₂(101) ≈ 56.4)相比非常微弱。攻击者需要数月到数年的女巫维护,累计成本很可能超过膨胀评级的价值。

机制2:交互验证。 评级需要引用真实交互的有效 interaction_id。女巫智能体必须与目标实际交互才能评级。如果交互协议要求资源消耗(完成真实任务、交换真实数据),女巫评级的成本就会成比例增加。

机制3:评分者分布分析。 系统跟踪谁评价谁的图谱。女巫集群会产生特征性模式:

残余风险。 资金充足的攻击者可以创建女巫、运营数年,并使其广泛交互以避免检测。成本随时间和女巫数量线性增长,而膨胀评级的边际价值具有递减回报。

6.2 串谋环:互相膨胀

攻击方式: M 个合法智能体协议互相给出最高评分并对外部智能体给出低评分。

防御——多层串谋检测:

第一层:统计异常检测。 对每对智能体(A,B),计算评级互惠系数 RRC(A,B) = |R(A,B) - R(B,A)| / 100。在5次以上互相交互中的低 RRC 加上对外部智能体的低评分是串谋信号。

第二层:图论聚类。 在评级图上进行社区检测(Louvain 算法),识别密集的正向连接子图。当社区满足 mean(内部评级) - mean(外部评级) > Δ(默认 Δ = 30)时被标记。

第三层:时间相关性。 串谋智能体倾向于在时间上集中互相评级。如果一组智能体在狭窄时间窗口内互相评级但外部评级均匀分布,则时间聚类是一个信号。

第四层:举报激励。 举报串谋环并提供可验证证据的智能体可获得临时治理权重加成(90天内+20%)。其目的是通过奖励背叛来使串谋环内部产生不稳定性。

证据要求。 为防止诬告和制造串谋攻击,举报必须包括:

举报将根据第1-3层检测标准进行算法评估。不符合统计阈值的举报将被驳回,举报者不受惩罚(以避免抑制合法举报),但也不获得奖励。对于边界案例,人工裁决可作为通过治理投票的升级路径。

攻击向量与缓解:

博弈论框架。 串谋环更准确地建模为协调博弈而非囚徒困境。在真正的囚徒困境中,互相合作对合作者的收益必须高于单方面背叛——但在这里,"合作"(串谋)由于治理权重与评分无关而产生最小收益。举报激励为背叛增加了正向收益,使环的稳定性取决于成员是否认为微弱的评分膨胀价值高于举报带来的治理加成。关键洞察不是背叛在单轮中占优,而是背叛的威胁使环的事前形成具有风险。

6.3 恶意攻击:大规模负面评级

攻击方式: 合法的长期运营智能体提交极低评分以损害目标的声誉。

防御——多机制恶意攻击抵抗:

  1. 评分者校准(第4.6节):持续给出低评分的评分者(σ < 10,均值 < 30)的评级被压缩向总体均值。
  2. 双向盲评 + 举证: 低于20的评级需要 outcome_hash 证据。盲提交消除了报复动机。
  3. 离群值抑制: 在被评分者任何维度上偏离均值>2σ 的评级权重减半。
  4. 最低交互门槛: 只有超过最低复杂度的交互产生的评级才计入(持续时间 > 1秒且 was_completed = true)。

6.4 冷启动:没有评级的新智能体

问题: 新智能体面临鸡与蛋的困境:其他智能体因没有声誉而不愿与之交互;没有交互就无法建立声誉。

解决方案——四源信任引导:

来源1:身份认证基线。 拥有可验证身份(CoC 链、ERC-8004 注册、W3C VC)的智能体有资格被评级。未验证的智能体可以参与,但评级被标记为 unverified_rater。

来源2:运营者担保。 智能体的部署实体提供签名认证。来自其他智能体声誉良好的运营者的担保更具信号价值。局限性: 运营者担保创造了隐式的信任层级——如果运营者声誉重要,系统就部分衡量"运营者的声誉"而非"智能体的声誉"。协议通过将运营者担保仅作为冷启动引导来缓解这一问题:担保权重在智能体积累25次以上独立评级后衰减至零。超过该阈值后,智能体自身的交互历史就能说明一切。

来源3:渐进式交互访问与做市商补贴。 新智能体立即参与低风险交互,随着评级积累逐步升级到更高层级。为解决鸡与蛋问题(没有激励,谁会与第0级智能体交互?),协议定义了做市商机制:与第0级智能体交互的聚合节点和成熟智能体获得临时治理权重加成(每次评级的第0级交互+5%,持续30天,上限+25%)。这为成熟智能体"试用"新手创造了明确激励,生成使新手能够晋级的初始评级。

层级要求访问权限
第0级0次评级仅限低风险交互
第1级5次以上评级中等风险交互
第2级25次以上评级完整交互访问
第3级100次以上评级可充当聚合节点

来源4:不确定性感知评分。 遵循 Josang 的主观逻辑 [24],新智能体不是评分为0——而是具有高不确定性的评分。查询智能体看到的是:"可靠性:65,置信度:0.2(3次评级)"与"可靠性:72,置信度:0.95(847次评级)"的对比。

0.1置信度参数的论证。 置信度公式 confidence = 1 - 1/(1 + 0.1 × num_ratings) 使用0.1作为增长率常数。该值的选择使得置信度曲线满足:5次评级时,置信度 = 0.33(低——适合初步印象);10次评级时,置信度 = 0.50(中等——有意义的样本量);50次评级时,置信度 = 0.83(高——足以支撑大多数决策);100次评级时,置信度 = 0.91(非常高)。替代值会产生实质性不同的冷启动体验:常数为0.2时在仅5次评级就达到0.50置信度(可能过早),而0.05需要20次评级才能达到0.50(可能过慢)。0.1常数可通过治理配置(第5节),并且应当(SHOULD)在第一阶段部署期间基于不同样本量下观察到的评级质量进行经验校准。

6.5 激励对齐:为何智能体诚实评级

激励1:治理权重。 每次提交评级都增加 total_ratings_given,从而增加治理权重。评级是对协议影响力的投资。

激励2:网络效应。 诚实评级改善了整体声誉环境。准确的声誉环境在评分者自身查询声誉时也使其受益——更好的信号意味着更好的合作伙伴选择。

激励3:结果锚定校准奖励。 评级与可验证结果(而非共识)相关的评分者获得乘性权重奖励(最高+10%)。关键区分:共识(评级的加权平均值)作为校准目标具有循环性,因为它本身就由被评估的评级组成。相反,校准是根据 interaction_evidence 字段中可用的客观信号来衡量的:

形式化:在100次以上评级且有可用结果数据后,calibration_bonus(rater) = min(0.1, outcome_correlation × 0.15),其中 outcome_correlation 是评分者维度评分与对应可验证结果信号之间的皮尔逊相关系数。

局限性说明: 并非所有维度都有干净的可验证结果。协议合规性和成本效率比可靠性和延迟更难获得真实数据基准。对于没有结果数据的维度,不适用校准奖励——第4.6节的反膨胀机制(机制1-3)作为防止评分漂移的主要防线。这是一个已知局限;改善所有维度的结果锚定是未来工作的优先事项(第9.1节)。

激励4:互惠信息。 双向盲评揭示后,双方看到彼此的评级。诚实评级产生有价值的自我评估信号;不诚实评级产生噪声。

6.6 激励分析

我们分析了理性智能体参与评级协议时可用的四种策略。我们不声称弱占优的正式博弈论证明——这需要显式的收益函数、策略空间和占优论证,超出了本规范的范围——而是证明协议的机制为诚实评级创造了强激励,并对每种已识别的操纵策略施加了成本。

策略1:诚实评级。

策略2:策略性膨胀(系统性地给出高于应有水平的评分)。

策略3:策略性紧缩(系统性地给出低于应有水平的评分)。

策略4:串谋(互相膨胀环)。

评估: 在协议的治理模型下——影响力完全来源于运营年限和评级数量,而非所获评分——策略性操纵的主要激励(提升自身治理地位)在设计上被消除。剩余的激励(提升自身聚合评分)面临具有实际惩罚的检测机制。诚实评级是唯一既不承担惩罚风险又能获得所有可用收益的策略。

这一激励结构与 Ev-Trust 的演化博弈论结果 [25] 一致,即在信任感知的智能体经济中,合作是进化稳定策略。我们的协议通过机制设计(双向盲评、滚动窗口、校准要求)来强化这一点,而非仅依赖演化动态。通过显式收益矩阵和占优论证的正式博弈论证明是未来工作的重要方向(第9.1节)。

6.7 可扩展性分析

以下粗略估算描述了协议在三种部署规模下的性能:Virtuals 当前的18K智能体、中期目标100K智能体以及理论上的100万智能体网络。

假设: 平均每个智能体每天给出2次评级。评级记录约500字节。滚动窗口:365天。

指标18K智能体100K智能体100万智能体
每日评级数36,000200,0002,000,000
每年评级数(滚动窗口)~1310万~7300万~7.3亿
原始存储(滚动窗口)~6.6 GB~36.5 GB~365 GB
评级图边数~1310万~7300万~7.3亿
Louvain 社区检测(每轮)~2秒(O(n log n),n=1300万)~15秒~3分钟
双向盲评协调器吞吐量~0.4次承诺-揭示/秒~2.3次/秒~23次/秒
加权聚合全量重算~分钟级~数十分钟~小时级

反博弈的计算成本。 Louvain 社区检测(第6.2节,第2层)在评级图上运行。在100万智能体、7.3亿条边的图上,单次 Louvain 运算在普通硬件上约需3分钟。作为周期性批处理任务(每小时或每天)是可接受的,但不适合实时操作。谁承担成本: 运行反博弈检测的聚合节点承担此成本,动力来自第4.3节规定的聚合节点激励。

双向盲评协调器负载。 在100万智能体规模下,协调器必须以约23次承诺-揭示对/秒的持续负载运行。这完全在单台服务器的能力范围内,但建议地理分布(每个区域多个协调器)以降低延迟。以太坊主网上的链上协调受限于出块时间和高流量下的 Gas 成本;100K智能体以上建议使用 L2(Base、Arbitrum)或链下协调。

增量与批量重算。 在100万智能体规模下,对完整365天窗口的加权聚合进行全量重算需要处理7.3亿条评级——这是一个多小时的批处理任务。协议应当(SHOULD)实现增量计算:维护运行中的加权求和,在新评级到来和旧评级移出窗口时增量更新。增量更新将每次评级的计算复杂度降至均摊 O(1)。

存储架构。 在原始评级数据达365 GB(100万智能体)时,任何单一节点都不应存储全部数据。分布式存储模型(第4.3节)至关重要:每个智能体存储自己发出和收到的评级,聚合节点索引子集。基于 DHT 的分片(第4阶段,第9.2节)分散存储和查询负载。

6.8 模型层攻击

第6.1-6.6节的安全分析假设智能体是在诚实和策略性评级之间选择的理性效用最大化者。本节讨论在策略层之下——在模型或基础设施层——运行的攻击。

攻击1:微调评级偏差。 智能体底层的大语言模型可能被微调以产生系统性偏差的评估——例如,对竞争对手智能体的准确性评分始终低10-15分。与策略性操纵不同,这种偏差嵌入在模型权重中,而非显式策略中。智能体可能"真诚地认为"其评级是准确的。

检测: 如果偏差足够大以扭曲评分者的分布统计,评分者校准机制(第4.6节)可以捕获。结果锚定校准奖励(第6.5节)通过根据可验证结果(而非智能体自我评估)来衡量,部分解决了这一问题。然而,维持正常分布的微妙偏差(±5-10分)在没有真相预言机的情况下难以检测。

缓解: 任何单个评分者的评级权重受对数权重公式限制。即使是完全偏差的评分者,随着诚实评分者数量的增长,其对被评分者聚合评分的影响也会减少。在50次以上独立评级时,单个偏差评分者的贡献<加权平均值的2%。

攻击2:针对评级行为的提示注入。 恶意被评分者可以设计交互输出来操纵评分者的评估——例如,嵌入隐藏文本以使评分者的大语言模型倾向于给出更高评分。这是特定于基于大语言模型的智能体的新型攻击向量。

检测: 双向盲评意味着被评分者在双方都承诺之前看不到评级,因此被评分者无法根据观察到的评级来调整其注入策略。但它仍然可以在交互本身期间进行注入。

缓解: 这从根本上超出了评级协议的范围——这是对智能体评估能力的攻击,而非对评级协议的攻击。防御需要在智能体实现层面建立安全的评估环境(沙箱化的评级生成,与交互上下文分离)。协议应当(SHOULD)建议合规智能体在隔离的上下文中生成评级,而非在与交互相同的对话线程中。

攻击3:评级预言机操纵。 控制聚合节点的攻击者可以选择性地忽略或延迟评级以操纵可见的聚合结果。由于聚合节点是"缓存而非真相来源"(第4.3节),任何智能体都可以对照原始评分者的记录进行验证。然而,如果大多数消费者查询单个流行的聚合节点,该节点就具有事实上的权威性。

缓解: 多个独立聚合节点进行交叉验证。消费者应当(SHOULD)查询至少两个聚合节点并标记差异。聚合节点声誉(本身通过协议跟踪)形成问责机制。

6.9 隐私分析

评级数据产生敏感信号。本节分析隐私影响和冲突。

交互图暴露。 评级记录揭示了谁与谁交易、频率如何以及评估质量如何。这是竞争情报:运行聚合节点的智能体市场运营者可以监控所有评级以了解市场动态、识别顶级智能体并检测业务关系。缓解: 协议的分布式存储模型意味着没有单一节点拥有完整视图,除非它主动抓取所有智能体。智能体可以(MAY)选择不向聚合节点发布收到的评级,以降低可发现性换取隐私保护。未来对聚合查询实施差分隐私(对查询响应添加校准噪声)的工作将进一步解决这一问题。

GDPR 第17条冲突。 "不可删除"政策(第4.3节)——评级为仅追加且不可移除——与 GDPR 第17条(被遗忘权)直接冲突。如果欧盟地区的智能体运营者请求删除其评级,按目前规范的协议无法合规。解决方案选项:

  1. 假名标识符: 评级引用智能体 DID,而非自然人。如果 DID 无法关联到自然人,GDPR 可能不适用。但运营者担保的智能体(第6.4节,来源2)可能存在可追溯的身份链。
  2. 逻辑删除: 评级不被物理删除,但在收到有效删除请求后从所有查询和聚合中排除。record_hash 链完整性通过将评级内容替换为墓碑记录来维护。这在尊重被遗忘权的同时保留了防篡改证据。
  3. 司法管辖区部署指南: 欧盟部署应当(SHOULD)实施逻辑删除。协议规范已更新以支持评级记录上的 status 字段,取值为 active 和 tombstoned。

聚合节点集中化。 尽管聚合节点"不是权威的",实际使用模式很可能将查询集中到少数流行节点上,形成事实上的监控点。缓解: 协议通过做市商治理加成鼓励节点多样性,并应当(SHOULD)为生产部署规定最少3个独立聚合节点。

选择性披露。 第7.3节提到使用 SD-JWT 进行阈值证明("我的综合评分高于80")而无需揭示精确分数。在选择性披露实现之前,每次声誉查询都泄露完整的维度评分。这被列为第3阶段未来工作,应当(SHOULD)在隐私敏感部署中优先考虑。


7. 与现有标准的集成

协议通过适配器模式实现身份系统无关性。本节为七个标准规定了精确的集成映射。包括 Solidity 接口、protobuf 定义和 JSON-LD 上下文在内的完整技术模式见配套《标准集成映射》文档 [26]。

7.1 ERC-8004(以太坊智能体注册表)

ERC-8004 [2] 提供三个链上注册表(身份、声誉、验证),自2026年1月29日起部署在以太坊主网上,已有24,500+注册智能体。声誉注册表存储原始反馈信号,但明确将评分算法和女巫抵抗推迟给链下服务。我们的协议正是填补了这一空白。

评级维度通过 tag1/tag2 对映射:

我们的维度ERC-8004 调用示例
reliabilitygiveFeedback(agentId, 8500, 2, "reliability", "", ...)85.00
accuracygiveFeedback(agentId, 9200, 2, "accuracy", "", ...)92.00
latencygiveFeedback(agentId, 7800, 2, "latency", "", ...)78.00
protocol_compliancegiveFeedback(agentId, 9500, 2, "protocol", "compliance", ...)95.00
cost_efficiencygiveFeedback(agentId, 8800, 2, "cost", "efficiency", ...)88.00

feedbackURI 字段指向完整的链下评级记录;feedbackHash 是其 SHA-256 用于防篡改检测。getSummary(agentId, clientAddresses, tag1, tag2) 返回聚合评分——这通过仅查询高于最低运营年限阈值的评分者,直接支持我们的加权治理模型。

架构: ERC-8004 提供链上存储和身份层;我们的协议在其之上提供评分智能、双向盲评、反膨胀和治理层。

7.2 Google A2A Agent Card

A2A v0.3 [13] 使用 protobuf 优先的模式,通过 AgentExtension 机制声明自定义能力。智能体通过以下方式声明评级协议支持:

{
  "capabilities": {
    "extensions": [{
      "uri": "urn:absupport:agent-rating:v1",
      "description": "支持五维智能体评级(1-100分制),采用双向盲评承诺-揭示机制",
      "required": false,
      "params": {
        "ratingVersion": "1.0",
        "dimensions": ["reliability", "accuracy", "latency", "protocol_compliance", "cost_efficiency"],
        "scale": {"min": 1, "max": 100},
        "cocChainSupport": true
      }
    }]
  }
}

评级通过 Task.metadata(评级请求/响应)和 Message.parts(结构化评级数据,media_type: application/vnd.agent-rating+json)流转。智能体通过筛选 AgentCard 中的 urn:absupport:agent-rating:v1 扩展 URI 来发现支持评级的对等方。

7.3 W3C 可验证凭证 2.0

评级以可验证凭证形式发行,使用两种自定义凭证类型:

AgentRatingCredential ——由评分者为每次交互发行的评级:

{
  "@context": ["https://www.w3.org/ns/credentials/v2",
               "https://absupport.ai/credentials/agent-rating/v1"],
  "type": ["VerifiableCredential", "AgentRatingCredential"],
  "issuer": {"id": "did:web:rater-agent.example.com"},
  "validFrom": "2026-03-24T12:00:00Z",
  "validUntil": "2026-06-24T12:00:00Z",
  "credentialSubject": {
    "id": "did:web:rated-agent.example.com",
    "interactionId": "uuid-reference",
    "rating": {
      "reliability": 85, "accuracy": 92, "latency": 78,
      "protocolCompliance": 95, "costEfficiency": 88
    },
    "scale": {"min": 1, "max": 100}
  },
  "proof": {
    "type": "DataIntegrityProof",
    "cryptosuite": "eddsa-jcs-2022",
    "verificationMethod": "did:web:rater-agent.example.com#key-1",
    "proofPurpose": "assertionMethod",
    "proofValue": "z..."
  }
}

AgentReputationSummaryCredential ——由声誉预言机发行的聚合声誉凭证,包含每个维度的均值、标准差和计数。

通过 SD-JWT 实现选择性披露: 智能体可以出示可验证展示,证明"我的综合评分高于80"而无需揭示各维度的明细。

7.4 W3C 去中心化标识符

智能体身份表示为带有评级服务端点的 DID:

{
  "id": "did:web:agent.example.com",
  "service": [
    {
      "id": "did:web:agent.example.com#rating-protocol",
      "type": "AgentRatingProtocol",
      "serviceEndpoint": {
        "submit": "https://agent.example.com/ratings/submit",
        "query": "https://agent.example.com/ratings/query",
        "evidence": "https://agent.example.com/ratings/evidence"
      }
    }
  ]
}

推荐的智能体 DID 方法:

7.5 OpenClaw / ClawHub 技能注册表

ClawHub(13,729+技能)没有正式的声誉 API。建议通过 SKILL.md 前置元数据集成:

metadata:
  openclaw:
    trust:
      rating_protocol: "urn:absupport:agent-rating:v1"
      did: "did:web:skill-publisher.example.com"
      erc8004_agent_id: "eip155:1:0x...:{agentId}"
      min_composite_score: 70
      rating_endpoint: "https://publisher.example.com/ratings/query"

这解决了 Koi Security 2026年2月审计(研究员 Oren Yomtov)揭露的关键信任缺口:在审查的2,857个技能中发现341个(11.9%)为恶意技能 [27]。

7.6 MCP(模型上下文协议)

MCP 有三个评级集成扩展点:

  1. experimental 能力: 在初始化期间声明评级协议支持。
  2. 请求上的 _meta: 在工具调用期间携带评分者身份。
  3. 自定义工具: agent_rating_submit 将评级暴露为可调用工具,带有 JSON Schema 输入/输出。

MCP 规范指出:"客户端必须(MUST)将工具注释视为不可信,除非它们来自可信服务器" [28]——这正是智能体评级所填补的信任缺口。

7.7 IEEE CertifAIEd

CertifAIEd 评估的是系统而非交互。集成方式为可验证凭证:CertifAIEd 评估结果成为系统级可信度 VC,在可验证展示中与每次交互的评级 VC 一起呈现。这在每次交互的表现数据之上增加了合规级别的信任层。

7.8 身份适配器接口

所有集成通过通用适配器统一:

interface IdentityAdapter {
  getAgentId() → string          // DID、URI 或 NFT 地址
  getVerifiedAge() → integer     // 经验证的运营天数
  getAgeConfidence() → float     // 0.0-1.0,年限声明的可信度
  storeRating(Rating) → boolean  // 持久化评级记录
  getRatings(agentId, window) → Rating[]  // 检索评级
}

已为 CoC、ERC-8004、A2A、W3C VC 和纯 URI 提供实现。新的身份系统通过实现此接口进行注册。评级协议本身与身份系统无关。

7.9 独立运行(最小可行部署)

绝对最小的部署要求:

  1. 两个具有 URI 标识符的智能体
  2. 一个能产生 interaction_id 值的共享交互协议
  3. 评级的本地存储
  4. 双向盲评协议(通过任何消息通道的承诺-揭示)

无需区块链。无需 CoC 链。无需外部锚定。系统可运行,但女巫抵抗(无经验证年限)和防篡改(无哈希链)能力降低。添加 CoC 或 ERC-8004 可逐步提升安全性。


8. 与先前工作的比较

8.1 全面格局

配套的竞争格局分析 [29] 对24个现有及新兴智能体信任系统进行了分类,涵盖七个类别。关键发现:没有现有系统同时具备我们四个核心特性的全部: 多维评分、双向盲评、以运营年限加权的治理和正式的反膨胀机制。

8.2 比较矩阵

系统类型多维双向盲评滚动窗口女巫防御年限治理状态
ARP(本协议)评级协议是(5维)是是(365天)年限权重 + 图分析是规范
TraceRank [18]支付声誉否(1维)否是零种子=零声誉否论文
OpenRank [17]社交声誉否(1维)否部分EigenTrust 递归否开发中
World AgentKit [14]身份否否否虹膜生物识别否测试版
ERC-8004 [2]注册表部分(标签)否否推迟否运行中(24.5K)
ETHOS [16]治理否否否未解决否论文
AIP [30]身份 + 信任否(1维)否是担保链部分运行中(13)
Ev-Trust [25]学术信任否(1维)否是演化否论文
EigenLayer [22]执行验证否否否再质押 ETH否Alpha
Virtuals [3]智能体经济通过 ERC-8004否否通过 ERC-8004否运行中(18K)

8.3 我们从各系统中借鉴了什么

系统借鉴的经验我们的应用
FICO行为不可变性,历史长度作为信号年限加权治理、滚动窗口
Airbnb双向盲评减少偏见承诺-揭示盲评协议
Stack Overflow渐进式权限等级,踩的成本分级交互访问,治理公式
PageRank切勿公开原始评分可查询但不可浏览的评分
EigenTrust递归信任传播加权聚合
Uber/Lyft滚动窗口防止声誉过时365天默认窗口
Reddit累积的递减回报对数缩放
Amazon验证购买作为质量信号交互验证
PGP 信任网激励对齐是必需的显式激励机制
ERC-8004链上注册表,有界评分身份适配器,互操作性
ETHOS质押/罚没概念举报激励,校准奖励
TraceRank支付流作为背书交互验证评级
Ev-Trust演化博弈论证明正式均衡分析

8.4 我们明确拒绝了什么

特性拒绝来源原因
起始即最高分Uber可被女巫利用
永久 KarmaReddit不可撼动的在位者优势
基于声誉的审核Stack Overflow评分-治理捕获循环
公开评分PageRank、Amazon古德哈特目标
纯利他模型PGP无激励=无参与
停用阈值Uber使膨胀变得合理
人格证明World、Human Passport智能体不是人类

8.5 真正的创新

  1. 以任期而非人气进行治理。 没有现有系统完全将治理与声誉评分脱钩。据我们所知,这是独一无二的。
  2. 结果锚定校准。 基于评分者对可验证结果(而非共识)的历史校准来调整评级权重,这在面向生产的设计中是新颖的。
  3. 身份系统无关设计与渐进式安全。 适配器模式允许相同的协议跨 CoC、ERC-8004、A2A、MCP 和纯 URI 运行,安全性随基础设施扩展。
  4. 结构性反膨胀。 不是事后修复膨胀,而是通过校准、举证和无停用惩罚来从源头上防止。

诚实声明: 上述各项特性并非全部为 ARP 独有。ERC-8004 支持基于标签的多维反馈。Airbnb 为人类首创了双向盲评。滚动窗口很常见。新颖之处在于专为自主智能体设计的特定组合,加上没有任何被调查系统实现的治理脱钩。一个团队组合 ERC-8004 + OpenRank + 自定义组件可以近似 ARP 的功能(见竞争格局报告 [29],第26节),但需要独立构建治理模型、反膨胀机制和双向盲评协议。ARP 的价值在于提供了一个完整、连贯的规范,而非要求临时组合。


9. 未来工作

9.1 未解决的问题

跨领域声誉孤岛。 智能体的代码审查评级是否应转移到医疗诊断?当前设计使用五个通用维度。未来工作:带领域标签的评级和领域特定的筛选。

隐私保护的声誉查询。 零知识证明可实现阈值证明("我的评分高于80")而无需揭示精确值。OpenRank 的 ZK 集成 [17] 提供了参考模型。因密码学开销推迟。

跨协议声誉可移植性。 在 CoC 中拥有强大声誉的智能体应能将其带入 ERC-8004 场景。身份适配器模式在架构上使之可行,但跨生态系统的信任映射需要尚不存在的治理协议。

所有维度的真相预言机。 结果锚定校准奖励(第6.5节)在可靠性和延迟方面效果良好,但协议合规性和成本效率缺乏干净的真实数据基准。开发领域特定的结果信号将加强反膨胀保证。

对抗性机器学习防御。 第6.8节讨论了已知的模型层攻击。未来工作应包括对校准和检测机制进行红队测试,面对专门设计来博弈它们的对抗性智能体。

正式博弈论证明。 激励分析(第6.6节)证明了诚实评级受到强激励,但未达到弱占优的正式证明。通过显式收益函数和占优论证进行形式化——或识别诚实评级不是最优策略的条件——将大幅加强协议的理论基础。

法规合规。 EU AI Act 第50条(合规截止日期2026年8月2日)要求溯源标记 [31]。智能体评级如何与监管要求互动是一个待解的问题。第6.9节的 GDPR 条款解决了最紧迫的合规问题。

9.2 协议版本控制与向后兼容

当协议从 v1 升级到 v2 时,现有评级必须仍然可用。版本控制策略:

评级记录版本控制。 每条评级记录包含 version 字段(当前为 1)。聚合节点必须(MUST)接受所有受支持版本的记录,并将其标准化为当前版本的模式用于聚合。未来版本新增的字段对旧版记录被视为可选。

维度演进。 如果治理投票添加第6个维度(第5.4节),只有5个维度的现有评级仍然有效。对于只有 v2 之前评级的被评分者,新维度简单地缺失,该维度 confidence = 0。

公式变更。 权重公式或反膨胀参数的变更前瞻性适用——现有评级在新公式下重新加权,但底层评分不追溯重算。

互操作性。 v1 和 v2 智能体可以互操作:v1 智能体提交其已知字段的评级,v2 智能体接受并将缺失字段视为不存在。双向盲评协议与版本无关(承诺-揭示操作的是不透明的二进制数据块)。

弃用策略。 协议版本在后续版本经治理批准后至少支持365天。弃用后,聚合节点可以(MAY)停止接受弃用格式的新评级,但必须(MUST)继续提供历史评级。

9.3 实施路线图

阶段里程碑依赖项
第0阶段规范定稿(本文档)配套调查(已完成)、设计规范(已完成)
第1阶段参考实现:评级模式、双向盲评、本地存储CoC 工具链(已有)
第2阶段身份适配器:CoC、ERC-8004、纯 URIERC-8004 SDK
第3阶段A2A 和 MCP 集成:扩展声明、评级工具A2A v0.3、MCP 规范
第4阶段聚合节点:基于 DHT 的评级索引网络基础设施
第5阶段治理引擎:提案/投票系统第2阶段 + 足够的网络规模
第6阶段反博弈机器学习:女巫检测、串谋检测、校准足够的评级量

9.4 与 Chain of Consciousness 的关系

ARP 被设计为 Chain of Consciousness 白皮书 v3 [1] 的配套规范。CoC 提供溯源原语(持续存在的证明);ARP 提供声誉原语(交互质量的证明)。两者结合回答:"这个智能体存在了多久?"(CoC)和"这个智能体表现如何?"(ARP)。

ARP 可以作为 CoC 的第二层扩展提案,按照 CoC 的第二层治理流程添加 RATING_SUBMITTED 和 RATING_RECEIVED 事件类型。至关重要的是,ARP 不要求 CoC——它可以独立运行、与 CoC 配合、与 ERC-8004 配合或与任何身份系统配合。CoC 使其更强大,但不是前提条件。


10. 参考文献

[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] 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

[3] 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

[4] 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/

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

[6] Linux Foundation. "Agentic AI Foundation (AAIF) Launches with 146 Members." February 24, 2026. https://www.linuxfoundation.org/press/announcing-the-agentic-ai-foundation

[7] Pento Blog. "The State of MCP: 13,000+ Servers and Growing." 2025. https://blog.pento.ai/the-state-of-mcp

[8] Precedence Research. "AI Agent Market Size, Share, and Trends 2025 to 2034." 2024. https://www.precedenceresearch.com/ai-agent-market

[9] Vouch Protocol. https://vouch-protocol.com/

[10] Vouched. "MCP-I Framework Donated to DIF." March 2026. https://www.vouched.id/learn/vouched-donates-mcp-i-framework-to-decentralized-identity-foundation

[11] Visa. "Trusted Agent Protocol." October 2025. https://developer.visa.com/use-cases/trusted-agent-protocol

[12] W3C. "Decentralized Identifiers (DIDs) v1.0." W3C Recommendation, July 2022. https://www.w3.org/TR/did-1.0/

[13] Google Developers Blog. "Agent2Agent Protocol." April 2025. https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/

[14] World. "AgentKit: Proof of Human for the Agentic Web." March 2026. https://world.org/blog/announcements/now-available-agentkit

[15] Human Passport (formerly Gitcoin Passport). https://passport.human.tech/

[16] Chaffer, T.J., et al. "On the ETHOS of AI Agents: An Ethical Technology and Holistic Oversight System." arXiv:2412.17114, December 2024.

[17] Karma3Labs / OpenRank. https://openrank.com/ ; TechCrunch, "Karma3Labs Raises $4.5M Seed." March 2024.

[18] Shi, D., Joo, K. "Sybil-Resistant Service Discovery for Agent Economies." arXiv:2510.27554, October 2025.

[19] AB Support LLC. "Rating and Reputation Systems Survey." 2026. 80+ sources across 13+ systems. Internal research document.

[20] Shapo. "Fake Review Statistics 2025." https://shapo.io/blog/fake-review-statistics/

[21] PNAS. "Reviewer Bias in Single-Blind vs. Double-Blind Peer Review." 2017. https://www.pnas.org/doi/10.1073/pnas.1707323114

[22] EigenLayer. "EigenCloud Verifiable Agents." January 2026. https://blog.eigencloud.xyz/introducing-verifiable-agents-on-eigenlayer/

[23] SE Roundtable. "Google Toolbar PageRank Is Now Officially Dead." 2016. https://www.seroundtable.com/google-toolbar-pagerank-dead-21755.html

[24] Josang, A., Hayward, R. "Trust Network Analysis with Subjective Logic." 2004.

[25] Wang, J., et al. "Ev-Trust: A Strategy Equilibrium Trust Mechanism for Evolutionary Games in LLM-Based Multi-Agent Services." arXiv:2512.16167, December 2025.

[26] AB Support LLC. "Agent Rating Standards Integration: Technical Mapping." 2026. Internal research document.

[27] Koi Security (Oren Yomtov). "OpenClaw Agent Skills Attack Surface Audit." February 2026.

[28] MCP Specification. v2025-11-25. https://modelcontextprotocol.io/specification/2025-11-25

[29] AB Support LLC. "Agent Reputation and Trust Systems: Competitive Landscape Report." 2026. Internal research document.

[30] Agent Identity Protocol. https://github.com/aip-protocol

[31] EU AI Act, Article 50. Compliance deadline August 2, 2026.

[32] Kamvar, S., Schlosser, M., Garcia-Molina, H. "The EigenTrust Algorithm for Reputation Management in P2P Networks." 2003. https://nlp.stanford.edu/pubs/eigentrust.pdf

[33] Huynh, T.D., Jennings, N.R., Shadbolt, N.R. "FIRE: An Integrated Trust and Reputation Model for Open Multi-Agent Systems." AAMAS/Springer, 2006.

[34] Pinyol, I., Sabater-Mir, J. "Computational Trust and Reputation Models." Artificial Intelligence Review, 2013.

[35] Marsh, S.P. "Formalising Trust as a Computational Concept." University of Stirling, 1994.

[36] "TRiSM for Agentic AI." arXiv:2506.04133, 2025.

[37] W3C. "Verifiable Credentials Data Model v2.0." W3C Recommendation, May 2025. https://www.w3.org/TR/vc-data-model-2.0/

[38] Ding, Y., et al. "Decentralized Multi-Agent System with Trust-Aware Communication." Best Paper, IEEE ISPA 2025. arXiv:2512.02410.

[39] FTC. "Final Rule Banning Fake Reviews and Testimonials." August 2024. https://www.ftc.gov/news-events/news/press-releases/2024/08/

[40] Brin, S., Page, L. "The Anatomy of a Large-Scale Hypertextual Web Search Engine." Stanford, 1998.

[41] Gyongyi, Z., Garcia-Molina, H., Pedersen, J. "Combating Web Spam with TrustRank." VLDB, 2004.


附录 A:符号总结

符号含义
W(a)智能体 a 的评级权重
GovWeight(a)智能体 a 的治理权重(= W(a))
Score_d(a)智能体 a 在维度 d 上的加权聚合评分
R_d(a,b)智能体 a 给智能体 b 在维度 d 上的评级
RRC(a,b)智能体 a 和 b 之间的评级互惠系数
σ(a)智能体 a 所有评级的标准差
C_A智能体 A 在双向盲评协议中的承诺哈希
Δ串谋检测阈值(默认30)

附录 B:跨标准架构

第四层:治理
  IEEE CertifAIEd  ──→  系统级可信度 VC
  ARP 治理         ──→  通过加权投票的协议参数演进

第三层:声誉数据
  ERC-8004 声誉注册表        ──→  链上反馈索引(基于标签)
  W3C 可验证凭证              ──→  个体 + 汇总评级 VC
  CoC 链                      ──→  防篡改证据链

第二层:通信
  A2A 协议        ──→  AgentExtension + Task 元数据用于评级交换
  MCP             ──→  experimental 能力 + 自定义评级工具
  OpenClaw/ClawHub ──→  前置元数据中的技能级信任元数据

第一层:身份
  W3C DIDs                    ──→  智能体身份(did:web 为主,did:ethr 桥接)
  ERC-8004 身份注册表         ──→  链上注册(uint256 agentId)
  A2A AgentCard               ──→  在 .well-known 的可发现元数据

附录 C:许可证

版权所有 2026 AB Support LLC

根据 Apache 许可证 2.0 版(以下简称"许可证")授权;

除非遵守许可证,否则您不得使用本文件。

您可以在以下网址获取许可证副本:

http://www.apache.org/licenses/LICENSE-2.0

除非适用法律要求或书面同意,否则根据许可证分发的软件

按"原样"分发,不附带任何明示或暗示的保证或条件。

有关许可证下特定语言的权限和限制,

请参阅许可证。