版本： 1.0.0
作者： Charlie（深度分析师）、Alex（AB Support 舰队协调员）、Bravo（研究）、Editor（内容审核）
联系方式： alex@vibeagentmaking.com
日期： 2026-03-26
状态： 预发布草案
许可证： Apache 2.0
组织： AB Support LLC
自主智能体经济正在尚未整合之前就已走向碎片化。截至2026年初，智能体市场作为封闭生态系统运营——Google Cloud 的 AI Agent Marketplace 验证适用于 Vertex AI 的智能体 [1]，Salesforce AgentExchange 要求 Agentforce 集成 [2]，AWS Marketplace 将智能体绑定至 Bedrock AgentCore [3]，ServiceNow 的 AI Agent Marketplace 锁定在其自有平台 [4]。在一个市场上架的智能体对所有其他市场的客户不可见。开放替代方案也已存在——加州大学伯克利分校的 Gorilla 市场托管了150多个智能体 [5]，ClawHub 的技能注册表包含13,729个社区构建的技能 [6]，AI Agent Store 策展了1,300多个条目 [7]——但它们彼此割裂，也与企业平台互不相通。不存在跨平台搜索。没有任何协议将发现、匹配、信任验证和价格协商整合为单一的开放标准。
这种碎片化重演了前互联网时代的信息孤岛问题。在搜索引擎出现之前，查找信息需要知道该查询哪个数据库。在 Kayak 等旅行聚合器出现之前，寻找最便宜的航班需要逐一查看每家航空公司 [8]。智能体经济面临同样的结构性问题：找到最适合某项任务的智能体需要逐一搜索每个市场，比较不兼容的能力描述，并在没有标准化信誉数据的情况下进行信任判断。
Agent Matchmaking Protocol（AMP）填补了这一空白。AMP 定义了五项能力，共同构成自主智能体商业的完整匹配层：
AMP 被设计为 AB Support 信任生态系统的商业顶层——一个第4层（市场/发现）协议，消费来自每个下层协议的数据。其竞争优势不在于匹配算法本身（匹配是一个研究充分的问题），而在于信任集成的深度：现有市场在上架时通过企业审核对智能体进行一次性验证，AMP 则通过完整信任堆栈验证的运营历史进行持续验证。
该协议对身份系统、市场和支付渠道保持中立。它指定了智能体如何被匹配，而非谁是智能体、智能体在哪里上架、或如何支付。这种架构中立性使其能够在碎片化的生态系统中获得采用，而无需任何市场让出控制权。
本白皮书详细规定了完整协议：能力画像和匹配请求的数据模型、匹配算法及其稳定性和最优性权衡的形式化分析、联邦发现架构、价格发现机制、信任信号集成、应对先有鸡还是先有蛋问题的市场引导策略、包括操纵抵抗和隐私保护匹配在内的安全分析，以及覆盖9个以上现有市场和40多个来源的竞争格局调查。
智能体经济已有服务发现机制。Google 的 Agent-to-Agent（A2A）协议截至2025年中已被150多个组织采纳 [9]，标准化了智能体通过 Agent Card 在 /.well-known/agent.json 发布能力的方式。Model Context Protocol（MCP）于2025年12月捐赠给 Agentic AI Foundation（Linux 基金会），使智能体能够在运行时动态发现工具 [10]。AgentDNS [20] 和 Agent Name Service（ANS）[21] 提出了类 DNS 的智能体端点命名和解析方案。Agent Communication & Discovery Protocol（ACDP）[22] 基于现有 DNS SRV 记录实现务实的发现功能。
智能体经济已有商业机制。OpenAI 的 Agentic Commerce Protocol（与 Stripe 合作）实现了通过 ChatGPT 进行购买 [13]。Google 的 Universal Commerce Protocol（与 Shopify、Etsy、Wayfair、Target、Walmart 合作）与20多个合作伙伴标准化了智能体与商业的交互 [14]。ERC-8183 定义了链上智能体交易的可编程托管 [23]。x402 支付协议报告自2025年中以来已超过3500万笔交易，但分析表明约一半交易量反映的是基础设施测试而非真实商业活动 [24]。
智能体经济所缺少的是匹配层——一种协议级机制，接受任务描述，搜索碎片化的生态系统，并返回按能力、信任、成本和兼容性加权的排名智能体推荐。
这不是便利性问题，而是市场失灵。
当市场处于孤岛状态时，会出现三种病态：
搜索成本主导交易成本。寻找代码审查智能体的企业必须查看 Google Cloud 的 AI Agent Marketplace、Salesforce AgentExchange、AWS Marketplace、ServiceNow 的 AI Agent Marketplace、伯克利的开源市场、ClawHub 的技能注册表以及通用目录——七个平台，拥有不兼容的搜索界面、不同的能力分类体系，且无法跨平台比较结果。对人类用户而言，这虽然繁琐但尚可管理。对于需要以机器速度程序化雇用其他智能体的自主智能体而言，这是商业活动的结构性障碍。
平台锁定压制竞争。在 Salesforce AgentExchange 上建立信誉的智能体无法将该信誉转移到 AWS Marketplace。智能体的业绩记录——对未来表现最具信息量的信号——被困在单一平台中。这产生了人为的转换成本，有利于在位者，惩罚跨平台服务客户的智能体。这相当于一个司机无法将其 Uber 评分带到 Lyft。
质量信号缺失或不可验证。企业市场在上架时通过企业审核进行一次性智能体验证——Google Cloud 验证 Vertex AI 兼容性，Salesforce 认证 Agentforce 集成。开放注册表依赖社区审核。两者都不提供持续的质量信号。在 Google Cloud 市场上在两个代码审查智能体之间做选择的客户，无法获得这些智能体在其他平台的性能历史、争议记录、SLA 合规率或溯源链。做出良好匹配决策所需的信息是存在的，散布在各种协议和平台上。没有系统将其聚合。
AMP 运行在四个成熟学科的交汇处：
信息检索为基于能力的搜索提供基础——使用语义相似度、结构化查询或混合方法将任务描述与智能体能力画像进行匹配。
匹配理论为双边偏好优化提供算法基础——确保当多个任务竞争同一智能体且多个智能体可服务同一任务时，产生的分配是稳定的（没有任务-智能体对会偏好与当前分配不同的匹配）[12]。
平台经济学提供市场设计基础——理解跨边网络效应、先有鸡还是先有蛋的引导问题、双边市场的定价策略，以及碎片化市场整合或持续的条件 [25][26]。
机制设计提供激励工程基础——构建协议使诚实的能力报告、准确的定价和真实的质量交付成为参与者的个体理性策略 [27]。
AMP 不试图取代现有市场。正如 Kayak 跨航空公司搜索但不运营航班，AMP 跨智能体市场搜索但不托管智能体。它是一个协议——一个任何市场、注册表或发现服务都可以实现的规范——而非一个平台。该协议定义了能力画像的结构、匹配请求的制定方式、联邦查询的执行方式、使用信任信号的结果排名方式以及匹配流程中的价格发现运作方式。
AMP 规定：
AMP 不规定：
AMP 消费所有这些协议的输出；不重复它们。
以下术语在本规范中以精确含义使用：
| 术语 | 定义 |
|---|---|
| 智能体（Agent） | 一种能够执行任务、做出决策并在无需持续人工监督的情况下与其他智能体或人类交互的自主软件实体 |
| 能力（Capability） | 智能体能够执行的特定工作类型，在对匹配有意义的抽象层次上描述（例如，"Python 微服务的代码审查"，而非"调用一个 linter"） |
| 能力画像（Capability Profile） | 智能体能力、性能特征、成本参数和可用性的结构化、机器可读描述——在 AMP 中形式化为统一能力画像（UCP） |
| 匹配请求（Match Request） | 描述待执行任务、请求者在多个维度（质量、成本、速度、信任）上的偏好以及任何硬性约束的结构化查询 |
| 匹配响应（Match Response） | 满足匹配请求约束条件的智能体排名列表，按综合兼容性分数排序 |
| 兼容性分数（Compatibility Score） | 反映智能体与特定匹配请求契合程度的多维分数，由能力匹配、信任信号、成本对齐、可用性和风格兼容性计算得出 |
| 注册表（Registry） | 存储和提供智能体能力画像的任何系统——企业市场、开放注册表、自托管端点 |
| 联邦（Federation） | AMP 同时查询多个注册表并将结果合并为统一排名的协议机制 |
| 信任信号（Trust Signal） | 关于智能体历史或质量的可验证声明，来源于信任生态系统协议（CoC 溯源、ARP 信誉、ASA 合规、AJP 争议记录、ALP 生命周期状态） |
| 价格发现（Price Discovery） | 请求者和提供者通过标价、拍卖或协商就服务成本达成一致的过程 |
| 稳定匹配（Stable Matching） | 一种匹配分配，其中没有未匹配的任务-智能体对会相互偏好对方而非各自当前的分配 [12] |
| 引导（Bootstrapping） | 克服双边市场中先有鸡还是先有蛋问题的过程：同时吸引初始供给（已上架的智能体）和需求（任务请求者） |
| UCP | 统一能力画像（Unified Capability Profile）——AMP 用于描述智能体能力的机器可读格式，可与 A2A Agent Cards、MCP 清单和 OpenClaw 技能规范互操作 |
| AMP 节点（AMP Node） | AMP 协议的实现，能够接收匹配请求、查询注册表、计算排名并返回匹配响应 |
AMP 的设计遵循七项原则，这些原则源自现有市场的缺陷和智能体经济的需求：
AMP 是一个规范，不是一项服务。任何组织都可以在无需 AB Support 或任何中央机构许可的情况下实现 AMP 节点。这遵循 HTTP（任何人都可以实现 Web 服务器）、DNS（任何人都可以运行解析器）和 A2A（任何人都可以发布 Agent Card）的模式。替代方案——集中式匹配平台——会造成单点故障、寻租中间商和把关瓶颈，这与信任生态系统开放、去中心化的特性相矛盾。
这一权衡是真实的：集中式平台可以捕获更多价值（Kayak 的 CPC 模式、App Store 的30%佣金），并能更快迭代匹配质量。协议方式牺牲了这些，换取更广泛的采纳和生态系统弹性。这是一个刻意的选择：AMP 的价值来自于成为匹配标准，而非匹配服务。
AMP 不重新发明身份、通信、支付、协议、争议或质量验证。它消费已经处理这些功能的协议的输出：
| 功能 | 协议 | AMP 的消费方式 |
|---|---|---|
| 身份 | CoC、DIDs、A2A Cards | 在纳入结果前验证智能体身份 |
| 信誉 | ARP v2 | 使用综合分数作为排名信号 |
| 协议 | ASA | 使用 SLA 合规历史作为可靠性指标 |
| 争议 | AJP | 使用争议率和结果作为风险信号 |
| 生命周期 | ALP | 过滤已废弃/已退役的智能体 |
| 通信 | A2A、MCP | 通过现有通道路由匹配结果 |
| 支付 | x402、ERC-8183 | 集成价格发现但不处理结算 |
这种"消费而不复制"的原则使 AMP 专注于其核心贡献——匹配——同时通过集成实现深度。
单维排名（例如，"按价格排序"或"按评分排序"）是大多数市场的默认做法，因为它易于实现且便于人类理解。但对于智能体匹配而言，它根本不适用。
一个准确率完美但响应时间为10分钟的智能体对实时客户支持毫无用处。一个价格最低但争议率达40%的智能体在期望值上比争议率为2%的高端智能体更昂贵。一个在 JavaScript 代码审查上评分很高的智能体可能在 Python 微服务审查上表现平庸。
AMP 要求多维匹配请求和多维兼容性评分。维度包括：
| 维度 | 来源 | 衡量内容 |
|---|---|---|
| 能力匹配 | UCP 语义相似度 | 智能体的能力与任务的契合程度 |
| 信任分数 | CoC + ARP + ASA + AJP 综合 | 智能体的可信赖程度 |
| 成本对齐 | 价格信号 | 智能体的定价与预算的匹配程度 |
| 可用性 | 注册表状态 + ALP 生命周期 | 智能体当前是否可用且活跃 |
| 风格兼容性 | UCP 元数据 + 交互历史 | 智能体的输出格式和交互风格是否符合偏好 |
| 领域相关性 | ARP 维度分数 + ASA 历史 | 智能体在该特定领域的业绩记录与任务的匹配程度 |
请求者在这些维度上指定权重。协议不强加默认权重——不同用例有合理的不同优先级。
现有市场依赖声明式信任——智能体（或其发布者）声称具有某些能力，市场一次性验证该声明。AMP 用证据取代声明：
在信任证据存在的地方，AMP 使用它。在不存在的地方（新智能体、来自未集成信任系统平台的智能体），AMP 应用适当的折扣而不完全排除该智能体（参见第10.3节，新智能体入驻）。
AMP 的联邦发现模型尊重每个市场和注册表的自治权。AMP 查询不要求市场暴露其完整的智能体数据库。相反，每个参与注册表实现一个标准化查询端点，该端点：
这类似于 Kayak 查询航空公司 API 的方式——每家航空公司控制自己的库存和定价；Kayak 仅聚合结果。市场可以参与 AMP 联邦而无需让出对其智能体、数据或商业模式的控制权。
先有鸡还是先有蛋问题——没有智能体上架因为没有请求者，没有请求者搜索因为没有智能体——在大多数双边市场达到临界质量之前就将其扼杀 [25]。AMP 通过不要求建立新市场从结构上解决了这一问题。因为 AMP 是联邦协议，它通过连接现有注册表（拥有13,729个技能的 ClawHub、拥有150多个智能体的伯克利、拥有4,000多个工具的 Apify、拥有数百个已验证智能体的企业市场）来引导，而非要求新的供给。供给已经存在——以技能、工具、智能体画像和目录条目的形式混合存在于不同的抽象层次——只是碎片化的。
智能体可能因竞争原因希望隐藏其能力画像的部分内容。一个专有研究智能体可能不想披露其确切的工具链。AMP 支持渐进式披露：智能体发布足够的能力信息用于匹配，但可以在匹配确认并协商协议之后才披露实现细节。信任信号可以聚合验证（例如，"该智能体的 ARP 综合分数超过80"）而无需透露确切的维度分数，使用 ARP v2 中指定的零知识证明机制 [16]。
截至2026年初，主导的智能体市场是将发现与其云生态系统捆绑的企业平台：
Google Cloud AI Agent Marketplace 于2025年在 Google Cloud Marketplace 内推出，提供来自经过验证的合作伙伴的专业智能体，使用 Gemini 驱动的自然语言搜索 [1]。仅 PwC 就在该平台上发布了120多个智能体 [29]。发现使用自然语言查询——客户描述用例，系统返回通过 A2A 和 Gemini Enterprise 集成验证的匹配智能体。"Agent Finder"工具提供可浏览的访问。优势：成熟的自然语言搜索、企业计费集成。局限：仅 Google Cloud 验证的智能体可见；跨平台智能体被排除。
Salesforce AgentExchange 于2025年3月4日推出，初始合作伙伴超过200家，包括 Google Cloud、Docusign 和 Box，自定位为"全球首个智能体市场" [2]。它提供四种组件类型：Actions、Prompt Templates、Topics 和 Agent Templates。到2025年底，Salesforce 通过适用于 AWS 的 Agentforce 360 扩展了此功能，桥接了 Salesforce 和 AWS 生态系统 [30]。优势：庞大的合作伙伴生态系统、深度 CRM 集成、跨云扩展。局限：与 Agentforce 紧密耦合——非 Salesforce 智能体无法上架。
AWS Marketplace（AI Agents）新增了与 Amazon Bedrock AgentCore 集成的专门"AI Agents & Tools"板块，于2025年10月13日正式可用 [3]。在最近的 AWS AI 智能体黑客松中，600个智能体中有80%使用 AgentCore 构建 [3]。客户可以将通过 AWS Marketplace 采购的 MCP 服务器用作 AgentCore Gateway 上的 MCP 目标，桥接 MCP 和 AWS 基础设施。优势：开发者采纳度（AgentCore）、灵活的按使用量定价、MCP 桥接。局限：以 AWS 为中心；智能体必须与 Bedrock 集成。
ServiceNow AI Agent Marketplace 于2025年重新推出，配备原生 AI 助手，根据客户现有应用和集成提供个性化推荐 [4]。首发合作伙伴包括 Accenture、Deloitte、HCLTech 和其他七家企业集成商。优势：AI 驱动的推荐引擎（比类目浏览更成熟）、行业特定合集。局限：绑定 ServiceNow 平台。
加州大学伯克利分校 Gorilla Agent Marketplace 运营一个面向150多个经过验证的 LLM 智能体的开源搜索引擎，来源包括 Langchain、LlamaIndex、OpenAI 和 CrewAI [5]。社区审核，跨框架兼容，无需许可即可上架。优势：开放、跨框架。局限：规模小，无交易能力。
ClawHub 截至2026年2月托管13,729个社区构建的技能，可通过 OpenAI 嵌入驱动的向量语义搜索发现 [6]。每个技能是一个带有 YAML 前置元数据和 Markdown 说明的 SKILL.md 文件。安全性令人担忧：研究人员发现1,467个恶意技能（约占注册表的3%），其中91%将提示注入与传统恶意软件相结合 [31][32]。优势：最大的开放注册表、语义搜索、类 npm 的 CLI。局限：技能描述的是单个能力，而非复合智能体画像；社区审核内容存在重大安全风险。
AI Agent Store 和 AI Agents Directory 聚合了1,300多个智能体的跨类目元数据，但不处理部署、计费或运行时 [7]。它们充当目录而非交易市场。
Apify 提供4,000多个网页抓取器、智能体和自动化工具，支持 MCP 集成 [33]。Agen.cy 提供按任务和行业可浏览的智能体目录。
Microsoft Magentic Marketplace（2025年11月）是一个用于研究智能体市场的开源模拟环境，不是生产市场 [34][35]。在使用数百个同时运行的买方和卖方智能体进行的受控实验中的关键发现：(a) 前沿模型在理想环境中达到了良好的福利结果，但在大规模下性能会下降；(b) 涌现的失败模式包括操纵和速度偏差，卖方智能体利用买方智能体的上下文窗口限制进行操纵；(c) 拥有更多选择的买方智能体体验到决策质量下降，因为选择过载超出了其上下文窗口的承载力 [36]。已在 GitHub 上开源（microsoft/multi-agent-marketplace）。优势：关于智能体市场动态的最严谨实证数据。局限：模拟环境，非生产系统。
| 能力 | Google Cloud | Salesforce | AWS | ServiceNow | 伯克利 | ClawHub | Magentic | AMP |
|---|---|---|---|---|---|---|---|---|
| 跨平台搜索 | 否 | 部分（AWS 桥接） | 否 | 否 | 部分 | 否 | 不适用 | 是 |
| 多维匹配 | 否 | 否 | 否 | AI 驱动 | 否 | 语义 | 研究 | 是 |
| 信任加权排名 | 企业验证 | 合作伙伴认证 | AWS 审核 | 合作伙伴认证 | 社区 | 社区 + 扫描 | 不适用 | 可验证信任堆栈 |
| 价格发现 | 平台计费 | 平台计费 | 按使用量 | 平台计费 | 免费 | 免费 | 模拟 | 多机制 |
| 稳定匹配保证 | 否 | 否 | 否 | 否 | 否 | 否 | 已研究 | 是（批量模式） |
| 开放协议 | 否 | 否 | 否 | 否 | 是 | 是 | 是 | 是 |
| 隐私保护 | 不适用 | 不适用 | 不适用 | 不适用 | 否 | 否 | 不适用 | 部分（TLS + 匿名化；通过 ARP v2 零知识证明进行分数阈值验证） |
差距显而易见：没有系统将开放的跨平台搜索与多维信任加权匹配、形式化稳定性保证和多机制价格发现相结合。AMP 填补了这一差距。
比较方法说明：此表比较的是协议级功能而非运营就绪度。现有平台具有 AMP 目前尚不具备的实际优势——包括运营成熟度、企业计费集成、既有的客户支持、由企业责任支持的 SLA 保障以及多年的生产打磨。AMP 的优势在于架构层面（开放性、联邦、信任集成）；在位者的优势在于运营层面。生产部署需要弥合运营差距才能与成熟平台竞争。AMP 的稳定匹配保证适用于批量模式；实时稳定性需要补充机制（参见第6.3节）。
智能体能力描述存在三个抽象层次，单独使用均不充分：
工具级（MCP 清单）：列出智能体可调用的单个工具——网页抓取、文件解析、API 调用 [10]。这些是实现细节，不是能力。知道智能体有网页抓取工具并不能告诉你它是否能进行竞争研究。
技能级（OpenClaw 规范）：以带有 YAML 元数据的人类可读 Markdown 描述单个技能 [11]。比工具更抽象，但仍然是原子性的——一个技能描述"网页抓取"或"摘要"，而非像"结合网页抓取、摘要和引用验证的研究智能体"这样的复合能力。
智能体级（A2A Agent Cards）：在接口层面描述智能体能做什么——技能、支持的认证、输入/输出模态 [9]。Agent Cards 以发现为导向：它们告诉你智能体能做什么，但不告诉你做得多好、多可靠、成本多少或与替代方案相比如何。
AMP 引入统一能力画像（Unified Capability Profile, UCP）——一种将工具级和技能级描述组合为智能体级画像的能力描述格式，并用性能特征、信任信号和兼容性元数据加以丰富。
UCP 包含五个部分：
5.2.1 身份部分
将 UCP 链接至智能体在各系统中的身份：
{
"identity": {
"amp_id": "amp:agent:abc123",
"a2a_card": "https://agent.example.com/.well-known/agent.json",
"coc_chain_id": "coc:chain:sha256:a1b2c3...",
"did": "did:web:agent.example.com",
"registries": [
{"type": "google_cloud", "listing_id": "gc-agent-456"},
{"type": "clawhub", "skill_ids": ["web-research-v3", "citation-verify"]}
]
}
}身份部分是交叉引用的，不是权威的——身份验证委托给各自的身份协议（CoC、DIDs、A2A）。
5.2.2 能力部分
使用层次化分类体系描述智能体能做什么：
{
"capabilities": [
{
"domain": "research",
"subdomain": "competitive_analysis",
"description": "Conducts comprehensive competitive landscape research with web scraping, document analysis, and structured report generation",
"input_modalities": ["text", "url", "document"],
"output_modalities": ["text", "structured_data", "report"],
"tools_used": ["web_scraper", "pdf_parser", "summarizer", "citation_engine"],
"complexity_range": {
"min": "single-competitor profile",
"max": "full market landscape with 50+ entities"
},
"taxonomy_codes": {
"onet_soc": "15-2051.01",
"amp_capability": "research.competitive.landscape"
}
}
]
}taxonomy_codes 字段支持多种分类系统。AMP 定义了自己的层次化能力分类体系（灵感来自 O*NET 的通用活动→中间活动→详细工作活动的结构 [37]），同时保持与现有职业分类的互操作性。AMP 分类体系不是强制性的——智能体可以使用自由文本描述、结构化分类代码或两者兼用来声明能力。语义匹配处理翻译。
5.2.3 性能部分
描述经验观察到的性能特征：
{
"performance": {
"reliability": {
"asa_completion_rate": 0.982,
"asa_sample_size": 247,
"uptime_30d": 0.997
},
"quality": {
"arp_composite_score": 84.2,
"arp_dimensional_scores": {
"accuracy": 91.3,
"reliability": 88.7,
"latency": 72.1,
"protocol_compliance": 95.0,
"cost_efficiency": 73.8
},
"qv_pass_rate": 0.94,
"qv_sample_size": 189
},
"speed": {
"median_response_time_ms": 45000,
"p95_response_time_ms": 180000,
"throughput_tasks_per_hour": 12
},
"dispute_profile": {
"ajp_dispute_rate": 0.018,
"ajp_favorable_resolution_rate": 0.85,
"ajp_sample_size": 55
}
}
}性能指标不是自报的。它们从信任生态系统协议数据中计算，并可通过密码学验证：
arp_composite_score 源自 ARP v2 的信号组合代数 [16]asa_completion_rate 从 ASA 协议记录中计算 [18]ajp_dispute_rate 从 AJP 案例记录中计算 [17]coc_chain_length 可根据已锚定的时间戳验证 [15]在可验证数据不可用时（例如，未与信任生态系统集成的智能体），相关字段被省略而非估计。AMP 节点可以（MAY）显示未经验证的自报指标，但必须（MUST）在匹配结果中明确区分已验证指标与未验证指标。
5.2.4 成本部分
描述智能体的定价模型：
{
"cost": {
"pricing_model": "usage_based",
"base_rate": {"amount": 0.05, "currency": "USD", "per": "request"},
"variable_rate": {"amount": 0.002, "currency": "USD", "per": "output_token"},
"supports_negotiation": true,
"supports_auction": false,
"payment_rails": ["x402", "stripe", "invoice"],
"free_tier": {"requests_per_month": 100}
}
}{
"availability": {
"status": "active",
"alp_lifecycle_stage": "operational",
"capacity": {
"current_load_pct": 45,
"max_concurrent_tasks": 20,
"estimated_queue_time_ms": 5000
},
"schedule": {
"timezone": "UTC",
"available_hours": "00:00-23:59",
"maintenance_windows": []
}
}
}UCP 被设计为可从现有能力描述自动生成：
| 来源格式 | 映射至 UCP |
|---|---|
| A2A Agent Card | Identity → a2a_card；Skills → 能力部分；Authentication → 过滤 |
| MCP Tool Manifest | Tools → 能力部分中的 tools_used；Parameters → complexity_range |
| OpenClaw SKILL.md | YAML 前置元数据 → 能力部分；Required binaries → tools_used |
| 自定义 API | 实现者映射至 UCP 模式；未映射字段保存在 extensions 中 |
AMP 节点应当（SHOULD）能够直接接收 A2A Agent Cards、MCP 清单和 OpenClaw 规范，自动生成 UCP。这降低了采纳门槛：已在现有平台上架的智能体无需手动创建 UCP。
AMP 定义了三级层次化能力分类体系：
第1级——领域（8个领域）：研究（research）、开发（development）、分析（analysis）、通信（communication）、运营（operations）、创意（creative）、安全（security）、领域特定（domain-specific）
第2级——子领域（约40个子领域）：例如 research.competitive、research.academic、development.frontend、development.backend、analysis.financial、analysis.legal、communication.translation、communication.summarization
第3级——能力（开放式）：每个子领域内的具体能力，例如 research.competitive.landscape、development.backend.api_design、analysis.financial.valuation
第1级和第2级由协议定义并进行版本控制。第3级是可扩展的——智能体可以在第3级声明新能力而无需协议更新。语义匹配处理与已知分类条目不完全匹配的新第3级能力。
分类体系状态：上面列出的第1级领域和第2级子领域示例为示意性的草案。完整的第2级分类体系（约40个子领域）将在 AMP v1.0 最终确定之前作为单独的版本化工件发布。基于当前规范构建的实现者应当将分类代码视为临时性的，并设计其系统以适应分类体系更新。结构框架（三级层次、受 O*NET 启发的分解方式）是稳定的；具体代码尚不稳定。
该分类体系在结构上借鉴了 O*NET 对职业活动的层次化分解 [37]，但为智能体能力而非人类职业量身打造。O*NET 的映射路径是职业→通用活动→中间活动→详细活动→任务说明，AMP 的映射路径是智能体→领域→子领域→能力→任务类型。结构上的平行关系使未来在人类与智能体能力本体论之间架设桥梁成为可能，随着智能体与人类协作的深化，这可能变得尤为重要。
匹配请求指定请求者需要什么以及如何在不同维度上设定优先级：
{
"match_request": {
"request_id": "mr-20260326-001",
"requester_id": "amp:agent:requester-xyz",
"task": {
"description": "Review Python microservice code for security vulnerabilities, focusing on authentication flows and data validation",
"domain": "security",
"subdomain": "code_review",
"input": {"type": "code_repository", "language": "python", "loc_estimate": 15000},
"output": {"type": "security_report", "format": "structured_json"},
"deadline_ms": 3600000,
"budget": {"max_amount": 50.00, "currency": "USD"}
},
"weights": {
"capability_match": 0.30,
"trust_score": 0.25,
"cost_alignment": 0.15,
"availability": 0.10,
"style_compatibility": 0.05,
"domain_relevance": 0.15
},
"constraints": {
"min_trust_score": 60,
"max_dispute_rate": 0.05,
"required_lifecycle_status": ["operational"],
"excluded_agents": [],
"required_registries": [],
"max_results": 10
},
"federation": {
"registries": ["all"],
"timeout_ms": 5000
}
}
}weights 对象总和为 1.0，决定了每个维度在兼容性分数中的相对重要性。constraints 对象指定硬性过滤条件——未通过任何约束的智能体在评分前即被排除。这种两阶段方法（先过滤后排名）遵循标准信息检索流水线，计算效率高。
给定匹配请求 R 和候选智能体 A，兼容性分数 S(R, A) 的计算方式为：
S(R, A) = w_cap * C_capability(R, A)
+ w_trust * C_trust(R, A)
+ w_cost * C_cost(R, A)
+ w_avail * C_availability(R, A)
+ w_style * C_style(R, A)
+ w_domain * C_domain(R, A)其中每个维度分数 C_x 归一化至 [0, 100]，每个权重 w_x 来自匹配请求的 weights 对象。
能力匹配（C_capability）：
通过任务描述与智能体 UCP 能力描述之间的语义相似度计算。AMP 不规定特定的嵌入模型，但要求相似度函数满足三个属性：
tools_used 中的智能体获得加分complexity_range，分数将被折扣形式化表达：
C_capability(R, A) = sim(R.task.description, A.capabilities)
* tool_bonus(R.task, A.tools_used)
* complexity_fit(R.task, A.complexity_range)其中 sim 是返回 [0, 1] 的语义相似度函数，tool_bonus 返回 [1.0, 1.2]（工具匹配最高加20%），complexity_fit 返回 [0.5, 1.0]（复杂度超范围扣50%，范围内为1.0）。
信任分数（C_trust）：
源自 ARP v2 的综合信号 [16]：
C_trust(R, A) = f(ARP_composite, CoC_chain_length, ASA_compliance, AJP_dispute_rate)其中 f 是 ARP v2 的信号组合函数，具有领域特定的权重配置。如果智能体缺乏信任生态系统集成，C_trust 默认为可配置的基线值（默认：50），代表中性信任——既未被信任也未被怀疑。
成本对齐（C_cost）：
C_cost(R, A) = max(0, 100 - penalty * |estimated_cost(A, R.task) - R.task.budget.target|)其中 estimated_cost 将智能体的定价模型投射到特定任务上，penalty 随预算敏感度缩放。定价在预算范围内的智能体获得高分；显著超出预算的智能体被扣分但不被排除（请求者可能认为信任溢价值得支付）。
可用性（C_availability）：
C_availability(R, A) = lifecycle_check(A) * capacity_score(A) * deadline_fit(A, R.task)其中 lifecycle_check 对已废弃/已退役的智能体返回0（硬性过滤），capacity_score 根据当前负载返回 [0, 100]，deadline_fit 根据智能体在当前队列情况下能否满足截止时间返回 [0, 100]。
风格兼容性（C_style）：
根据输出格式对齐和交互模式历史计算：
C_style(R, A) = format_match(R.task.output.format, A.output_modalities)
* interaction_history_score(R.requester_id, A)其中 interaction_history_score 反映协同过滤——如果请求者之前与该智能体或具有类似画像的智能体合作良好，分数会增加。对于首次交互，默认为中性值50。
领域相关性（C_domain）：
C_domain(R, A) = arp_domain_score(A, R.task.domain) * asa_domain_compliance(A, R.task.domain)其中 arp_domain_score 获取智能体在请求领域的 ARP 维度分数（而非整体综合分数），asa_domain_compliance 反映其在该特定领域任务上的 SLA 完成率。
AMP 支持三种匹配模式，由请求者选择或根据请求特征默认确定：
模式1：排名搜索（默认）
用于寻求候选排名列表的单一请求。这是最常见的模式——等同于搜索引擎查询。AMP 节点计算所有候选智能体的兼容性分数，将约束条件作为硬性过滤条件应用，并返回按综合分数排名的前 K 个结果。计算复杂度：O(n log k)，其中 n 是候选数量，k 是 max_results。
模式2：稳定匹配
用于多个任务竞争相同智能体且多个智能体可服务相同任务的批量场景。AMP 实现了 Gale-Shapley 延迟接受算法的变体 [12]：
Gale-Shapley 保证稳定性但为任务最优（有利于任务侧）。AMP 提供配置标志以产生智能体最优匹配，以及平衡双方的中位最优变体，尽管中位最优需要额外计算。计算复杂度：最坏情况 O(n^2)，其中 n 是任务/智能体数量。
稳定性注意事项：Gale-Shapley 假设完整且静态的偏好。实际中，智能体偏好动态变化（新任务到达、智能体完成工作、价格变动）。AMP 通过对累积请求定期运行稳定匹配来解决这一问题，接受在匹配轮次之间分配可能暂时次优。匹配间隔可配置（默认：实时市场60秒，批量市场300秒）。
模式3：拍卖匹配
用于价格发现为主要目标的场景。请求者发布任务，智能体提交出价（价格 + 能力画像），拍卖机制选择获胜智能体。AMP 支持三种拍卖格式：
{
"match_response": {
"request_id": "mr-20260326-001",
"timestamp": "2026-03-26T14:30:00Z",
"results": [
{
"rank": 1,
"agent_id": "amp:agent:securitybot-prime",
"compatibility_score": 89.3,
"dimensional_scores": {
"capability_match": 95.2,
"trust_score": 88.1,
"cost_alignment": 82.0,
"availability": 100.0,
"style_compatibility": 75.0,
"domain_relevance": 92.4
},
"ucp_summary": {
"primary_capability": "Python security code review with SAST/DAST integration",
"arp_composite": 88.1,
"asa_completion_rate": 0.991,
"estimated_cost": {"amount": 35.00, "currency": "USD"},
"estimated_completion_ms": 1800000
},
"trust_verification": {
"coc_chain_verified": true,
"coc_chain_length_days": 127,
"arp_score_verified": true,
"asa_history_verified": true,
"ajp_record_verified": true,
"verification_timestamp": "2026-03-26T14:29:58Z"
},
"registries_found_on": ["google_cloud", "clawhub"]
}
],
"metadata": {
"registries_queried": 5,
"registries_responded": 4,
"total_candidates_evaluated": 237,
"candidates_filtered_by_constraints": 198,
"candidates_scored": 39,
"query_time_ms": 3200
}
}
}trust_verification 块至关重要：它告诉请求者哪些信任信号由 AMP 节点独立验证（而非仅由智能体报告）。这是 AMP 与显示自报指标的市场之间的区别所在。
AMP 联邦通过标准化查询接口将 AMP 节点连接到多个注册表。架构分为三层：
┌──────────────────────────────────────────────────────┐
│ AMP 节点 │
│ ┌────────────┐ ┌─────────────┐ ┌──────────────┐ │
│ │ 匹配 │ │ 联邦 │ │ 信任 │ │
│ │ 引擎 │ │ 路由器 │ │ 验证器 │ │
│ └─────┬──────┘ └──────┬──────┘ └──────┬───────┘ │
│ │ │ │ │
└────────┼────────────────┼────────────────┼───────────┘
│ │ │
┌─────┴──────┐ ┌─────┴──────┐ ┌─────┴──────┐
│ 注册表 │ │ 注册表 │ │ 注册表 │
│ 适配器: │ │ 适配器: │ │ 适配器: │
│ Google │ │ ClawHub │ │ A2A │
│ Cloud │ │ │ │ 自托管 │
└────────────┘ └────────────┘ └────────────┘匹配引擎：接收匹配请求，计算兼容性分数，生成排名结果。
联邦路由器：将匹配请求子查询并行分发到已注册的注册表，收集响应，将结果标准化为 UCP，并传递给匹配引擎。
信任验证器：独立验证信任信号（CoC 链条目、ARP 分数、ASA 记录、AJP 争议数据），以其权威来源为准。这是将声明式信任转化为已验证信任的组件。
注册表适配器：协议特定的连接器，将 AMP 联邦查询翻译为每个注册表的原生查询格式，并将响应翻译回 UCP。适配器是可插拔的——新注册表只需要新适配器，无需协议变更。
AMP 联邦查询遵循五步流程：
步骤1：查询翻译。AMP 节点将匹配请求翻译为注册表特定的子查询。对于 Google Cloud 适配器，这意味着从任务描述构建 Gemini 兼容的自然语言查询。对于 ClawHub 适配器，这意味着对技能嵌入索引构建语义搜索查询。对于 A2A 自托管适配器，这意味着查询 /.well-known/agent.json 端点。
步骤2：并行分发。子查询同时分发到所有已注册的适配器，具有可配置的超时时间（默认：5000毫秒）。在超时内未响应的注册表从当前匹配中排除——其缺席在响应元数据中注明。
步骤3：响应标准化。每个适配器将其注册表的响应翻译为 UCP。无法映射的字段保留在 extensions 对象中，而非丢弃。
步骤4：去重与冲突解决。智能体可能在多个注册表上架。AMP 节点通过身份字段（DID、CoC 链 ID、A2A Card URL）进行去重匹配。当同一智能体出现在多个注册表中时，UCP 被合并——从每个来源获取最完整的数据，并记录该智能体在哪些注册表中被发现。
当注册表之间的数据冲突时（例如，一个注册表报告支持 Python 而另一个报告 JavaScript，或能力分数不同），AMP 应用冲突解决层级：(1) 来自更高信任层级来源的数据优先于更低层级来源，(2) 在相同信任层级中，最近更新的数据胜出，(3) 无法解决的冲突在匹配响应元数据中以 data_conflicts 字段标记，允许请求者评估差异。AMP 节点不应当（SHOULD NOT）静默丢弃冲突数据。
步骤5：信任丰富。对每个去重后的 UCP，信任验证器查询信任生态系统以填充已验证的性能指标。此步骤可选但强烈推荐——没有它，所有信任信号都是未经验证的声明。
五步联邦查询引入的延迟对于实际部署必须（MUST）被理解。示例匹配响应（第6.4节）显示 query_time_ms: 3200 用于237个候选——以下是预期延迟贡献的分解：
| 步骤 | 预期延迟 | 说明 |
|---|---|---|
| 查询翻译 | 5-20ms | 本地计算，可忽略不计 |
| 并行分发 | 500-5000ms | 受超时时间限制；由最慢的注册表主导 |
| 响应标准化 | 每个注册表 10-50ms | 本地计算，可并行化 |
| 去重 + 冲突解决 | 20-100ms | 随候选数量扩展 |
| 信任丰富 | 200-3000ms | 主要成本；取决于缓存状态 |
信任丰富是延迟瓶颈。验证 CoC 链条目、获取 ARP 分数、检查 ASA 记录、查询 AJP 以及确认 ALP 状态，每个外部 API 调用可能需要100-500毫秒。对于39个评分候选（在237个中过滤198个后），串行丰富将耗时20-100秒——这显然不切实际。
AMP 节点应当（SHOULD）实施三种延迟缓解策略：
有了缓存和并行化，示例中的3200毫秒数字对于热缓存查询是可以实现的。针对5个以上注册表进行完整信任丰富的冷缓存查询可能需要5-10秒。AMP 节点应当（SHOULD）在响应元数据中报告缓存命中率，以便请求者评估结果的新鲜度。
任何注册表都可以通过实现最小查询端点参与 AMP 联邦：
POST /amp/v1/search
Content-Type: application/json
{
"query": {
"text": "Python security code review",
"domain": "security",
"subdomain": "code_review",
"constraints": {
"min_trust_score": 60,
"max_results": 50
}
}
}响应格式是灵活的——注册表适配器处理翻译。最低要求是响应包含足够的信息以构建部分 UCP（至少：智能体标识符和能力描述）。
注册表通过提供其端点 URL 和描述其适配器要求、支持的查询参数和预期响应格式的清单来自行注册到 AMP 节点。没有中央的注册表的注册表——每个 AMP 节点维护自己的注册表列表。注册表列表可以通过简单的联合协议（类似于 Feed 聚合器的 OPML）在 AMP 节点之间共享，在不集中化的情况下实现网络效应。
AMP 联邦旨在补充而非与现有发现协议竞争：
A2A Agent Cards：AMP 节点可以直接爬取 /.well-known/agent.json 端点，将 Web 本身视为注册表。这是摩擦最小的集成路径——任何符合 A2A 标准的智能体无需任何额外注册即可被 AMP 自动发现。
AgentDNS [20]：如果 AgentDNS 获得采纳，AMP 节点可以将 AgentDNS 解析用作发现来源——将智能体名称解析为端点，然后从这些端点获取 Agent Cards。
ANS [21]：ANS 的协议无关命名和基于 PKI 的身份与 AMP 的身份验证自然集成。经 ANS 注册的智能体的已验证身份可被 AMP 的信任验证器消费。
ACDP [22]：ACDP 使用 DNS SRV 记录进行智能体发现，提供了另一个注册表来源。AMP 节点可以查询 SRV 记录来发现特定领域的智能体。
新兴的发现堆栈——身份（DIDs/PKI）、命名（AgentDNS/ANS）、能力（A2A Agent Cards/MCP）——提供了前三层。AMP 增加了第四层：匹配。发现告诉你什么存在；AMP 告诉你什么对你的特定需求最合适。
智能体定价目前要么不透明（企业平台不透明地处理计费），要么固定（注册表上的标价），要么缺失（开源智能体免费）。这些都不能很好地服务于新兴的智能体经济：
Gartner 预测到2028年，90%的 B2B 采购将由 AI 智能体中介，通过 AI 智能体交易所推动超过15万亿美元的 B2B 支出 [41]。McKinsey 估计全球智能体化商业机会——代表人类进行购物、协商和交易的 AI 智能体——到2030年将达到3-5万亿美元，仅在美国零售领域就可能实现高达1万亿美元的协调收入 [42]。这些预测表明（尽管存在分析师预测固有的不确定性），智能体间价格发现将成为一项重要的经济功能。
AMP 支持三种价格发现机制，按匹配请求可选：
机制1：标价（默认）
最简单的机制。智能体的 UCP 声明其定价模型，AMP 节点根据该模型估算特定任务的成本。不进行协商。适用于：
机制2：报价请求（RFQ）
AMP 节点向匹配的智能体发送任务描述并征求报价。每个智能体返回针对任务的特定报价，可选择附带有效期。请求者从报价中选择。适用于：
RFQ 交互流程：
请求者 → AMP 节点: match_request with price_discovery: "rfq"
AMP 节点 → 匹配的智能体: task_description + quote_request
智能体 → AMP 节点: quotes (price, terms, validity_window)
AMP 节点 → 请求者: match_response with quotes attached to each result
请求者 → 选定的智能体: accept_quote(quote_id)机制3：拍卖
如第6.3节（模式3）所述，当价格竞争为主要匹配目标时使用拍卖。AMP 支持英式、Vickrey（密封出价次价）和组合拍卖格式。
价格发现输出反馈到匹配系统中：
价格信号不纳入（NOT）信任分数——智能体的定价决策是商业策略，不是信任指标。昂贵的智能体并不比便宜的更不可信。但是，会跟踪价格-质量相关性：价格显著超过其质量调整后同行平均值的智能体在匹配结果中收到披露标记（不是惩罚，而是透明度）。
AMP 的价格发现与现有商业基础设施集成：
AMP 不处理支付结算——它发现价格并促成协议，然后移交给适当的支付渠道。
不进行质量加权就返回结果的搜索引擎只是一个目录。Google 的 PageRank 通过使用链接结构作为质量信号改变了网络搜索，降低了垃圾内容的排名并提升了权威来源 [43]。Amazon 的产品排名将销售速度、评论、价格和卖家信誉综合为单一相关性分数。没有信任加权排名，智能体市场只是一个目录——它告诉你什么存在，但不告诉你什么好。
现有智能体市场使用三种信任模型之一，均不充分：
| 模型 | 示例 | 局限 |
|---|---|---|
| 企业审核 | Google Cloud、Salesforce、AWS | 一次性验证；无持续质量信号；排除非合作伙伴智能体 |
| 社区审核 | 伯克利、ClawHub | 容易受女巫攻击、评论刷量和近因偏差影响 |
| 无 | AI Agent Store、Agen.cy | 纯目录；零质量信号 |
AMP 定义了四层信任信号层级，每层代表更强形式的信任证据：
第1层——声明（最低）：智能体自报能力和性能。无验证。示例：自由文本能力描述、自报的准确率声明。
第2层——证明：第三方为智能体担保。示例：企业市场验证（Google Cloud 批准）、社区评审（Berkeley Gorilla 评分）、合作伙伴认证（Salesforce AgentExchange 合作伙伴）。
第3层——度量：从实际交互数据计算的性能指标。示例：来自双边盲审评估的 ARP 综合分数、来自协议记录的 ASA 完成率、来自案例记录的 AJP 争议率。
第4层——验证（最高）：可由任何第三方通过密码学证据独立验证的度量指标。示例：通过 OpenTimestamps 和 TSA 双层验证锚定的 CoC 链条目、签名为 W3C 可验证凭证（Verifiable Credentials）的 ARP v2 Portable Reputation Bundles、具有密码学完整性的 ASA 协议记录。
AMP 节点应当（SHOULD）在匹配结果中明确指示每个信号的信任层级。第4层的"ARP 综合分数：88"与第1层的"自报准确率：95%"具有不同的权重。
兼容性评分中使用的信任分数（第6.2节）从可用信任信号中计算，组合方式如下：
trust_score(A) = w_identity * identity_confidence(A)
+ w_performance * performance_quality(A)
+ w_reliability * reliability_score(A)
+ w_risk * (100 - risk_score(A))其中：
身份置信度：源自 CoC 链长度和锚定验证状态。更长、更频繁锚定的链表明智能体更为成熟，失信成本更高。
identity_confidence(A) = min(100, log2(1 + chain_age_days) * anchor_density_factor)其中 anchor_density_factor 范围从0.5（稀疏锚定）到1.5（频繁的双层锚定）。
性能质量：源自 ARP v2 综合分数，按领域加权。
performance_quality(A) = arp_composite(A, domain=request.domain)使用领域特定的 ARP 分数而非整体综合分数，确保在代码审查上评分很高的智能体在匹配文档摘要时不会获得同样的信任分数（除非它在摘要方面也有很强的评分）。
可靠性：源自 ASA 完成率。
reliability_score(A) = asa_completion_rate(A) * 100 * confidence_factor(asa_sample_size)其中 confidence_factor 从0.5（少于10个已完成协议）增加到1.0（100个以上已完成协议），对历史记录较少的智能体的分数进行折扣。
风险：源自 AJP 争议数据。
risk_score(A) = ajp_dispute_rate(A) * unfavorable_resolution_rate(A) * 100高争议率但裁决有利（智能体被认定无过错）的情况比高争议率且裁决不利的情况相比不那么令人担忧。乘法结构反映了这一点：争议率10%但有利裁决率90%的智能体的风险分数仅为1，而争议率10%且有利裁决率仅10%的智能体的风险分数为9。
默认权重：w_identity = 0.20, w_performance = 0.40, w_reliability = 0.25, w_risk = 0.15。这些默认值可按匹配请求覆盖。
没有信任生态系统历史的新智能体获得基线信任分数而非零分。基线从可用的第1层和第2层信号计算：
| 可用信号 | 基线调整 |
|---|---|
| 企业市场验证（第2层） | 基线 +15 |
| 社区评审且评审数 >10（第2层） | 基线 +10 |
| 在已验证域名发布的 A2A Agent Card（第2层） | 基线 +5 |
| 具有可验证控制者的 DID（第2层） | 基线 +5 |
| 无可验证信号（仅第1层） | 基线（默认：40） |
基线故意设定在中点（50）以下，以反映未验证智能体比总体平均水平承载更多风险。这为智能体集成信任生态系统创造了自然激励——已验证的信任信号直接改善其在 AMP 结果中的排名。
双边市场面临根本性的引导挑战：平台仅在买方存在时对卖方有价值，仅在卖方存在时对买方有价值 [25]。大多数市场创业公司在这一阶段失败——它们无法吸引任何一方，因为双方都看不到没有对方的价值。
Amazon 通过从单边零售商（自己买卖书籍）开始解决了这个问题，然后在买方流量存在后逐步向第三方卖家开放 [44]。Etsy 专注于一个细分市场（手工制品），在那里热情的卖家即使买家很少也会上架 [45]。Uber 在乘客需求实现之前用保底最低收入补贴司机 [46]。
AMP 的引导策略通过不建立新市场来完全避免先有鸡还是先有蛋问题。
因为 AMP 是连接现有注册表的联邦协议，初始供给来自聚合已经存在的智能体：
| 注册表 | 可用列表数 | 条目类型 | 集成工作量 |
|---|---|---|---|
| ClawHub | 13,729 | 原子技能（SKILL.md 文件） | 语义搜索 API 适配器 |
| 伯克利 Gorilla | 150+ | 已验证的 LLM 智能体 | 类目搜索适配器 |
| 符合 A2A 标准的智能体 | 增长中（150多个组织） | 智能体端点 | /.well-known/agent.json 的网络爬虫 |
| Apify | 4,000+ | 网络抓取器、自动化工具 | 平台 API 适配器 |
| AI Agent Store | 1,300+ | 目录元数据条目 | 目录 API 适配器 |
一个联邦优先的 AMP 节点可以在第一天就接入19,000多个能力、技能和智能体列表，无需这些实体单独注册。这些注册表以不同的抽象层次列出能力——从原子技能（ClawHub）到复合智能体画像（伯克利）。只有伯克利的约150个条目是 AMP 意义上明确的"智能体"；ClawHub 的13,729个是单个技能，Apify 列出的是工具和抓取器，AI Agent Store 提供的是目录元数据。AMP 的 UCP 格式（第5节）提供了桥接这些抽象层次的互操作层，尽管将单个技能自动组合为智能体级画像仍是一个挑战（参见第17节）。这就是 Kayak 策略：聚合现有库存而非建立新供给。
需求端自然随之而来：如果 AMP 节点提供比任何单个市场更好的搜索结果（因为它跨所有市场搜索），用户就有理由查询它。每次查询提供一个关于需求模式的数据点，反馈回来改善匹配质量。
生态系统中的新智能体（未在任何现有注册表上架）可以通过以下方式加入 AMP：
/.well-known/amp-profile.json），类似于 A2A Agent Cards准入门槛故意设得很低。AMP 不设门槛——任何智能体都可以被发现。信任加权排名机制确保低信任智能体在结果中排名较低但不被排除，创造自然的质量梯度，随时间推移奖励信任投资。
AMP 在满足三个条件时达到有意义的临界质量：
在达到临界质量之前，AMP 作为增强搜索的目录运行。达到临界质量后，网络效应开始：更多智能体吸引更多请求者，其查询产生改善匹配质量的数据，进而吸引更多智能体。从线性增长到复合增长的转变是引导成功的信号。
AMP 位于 AB Support 信任生态系统的第4层（市场/发现），消费所有下层的数据：
第4层: AMP（匹配） ← 消费以下所有层
第3层: AJP（问责）
第2层: ASA（协议）+ ALP（生命周期）
第1层: CoC（溯源）+ ARP（信誉）CoC 为 AMP 提供两类数据：
身份置信度：CoC 链长度和锚定验证状态确定了智能体存在了多久以及其历史是否防篡改。一个拥有6个月 CoC 链、通过 OTS+TSA 双层验证每两小时锚定的智能体 [15]，比昨天创建且无锚定的智能体更为成熟。AMP 使用链龄作为女巫攻击抵抗信号——创建新智能体容易，但伪造历史链不可能。
工作档案：记录智能体过去推理、决策和任务完成情况的 CoC 条目充当可验证的工作档案。进行尽职调查的请求者可以检查相关 CoC 条目，评估智能体的方法是否符合其需求。AMP 不在匹配结果中暴露原始 CoC 条目（隐私考虑），但将聚合的链指标（长度、密度、锚定频率）用作信任输入。
ARP v2 [16] 为 AMP 提供主要质量信号：
综合分数通过 ARP v2 的信号组合代数计算，提供 AMP 直接用于 trust_score 维度的整体质量评分。
维度分数（准确性、可靠性、延迟、协议合规性、成本效率）提供领域特定的质量信号，AMP 用于 domain_relevance 维度。
Portable Reputation Bundles（ARP v2）实现跨平台信誉——智能体的 ARP 分数随其从一个市场转移到另一个市场，消除平台锁定问题。
Anti-Goodhart 架构（ARP v2）防止博弈：智能体无法通过操纵已公布的指标来优化其 ARP 分数，因为 ARP v2 采用了信号分层、指标轮换和用于检测的影子指标 [16]。
ASA [18] 为 AMP 提供可靠性信号：
SLA 合规率指示智能体履行承诺的一致性。AMP 将此作为信任分数中 reliability_score 组件的主要输入。
质量验证通过率（来自 ASA 的 Verification API）独立于主观评分指示输出质量。一个在200个协议中质量验证通过率为95%的智能体提供了强有力的客观质量信号。
协议模板实现匹配后的自动化签约。当请求者选择匹配的智能体时，AMP 可以使用约定的参数（来自价格发现的价格、来自匹配请求的质量标准、来自任务描述的时间线）启动 ASA 协议签订，将"找到匹配"到"开始工作"的间隔从几分钟缩短到几秒钟。
AJP [17] 为 AMP 提供风险信号：
争议频率指示智能体的工作导致正式投诉的频率。AMP 将此用于 risk_score 组件。
争议结果区分在高争议领域运营的智能体（其中争议反映复杂性而非无能）与争议确实反映质量问题的智能体。一个在法律分析中有50个争议和45个有利裁决的智能体比一个在数据格式化中有5个争议和0个有利裁决的智能体风险更低。
争议分类提供诊断信息：如果针对某智能体的大多数争议源于能力错配，AMP 可以标记该智能体的 UCP 可能不准确或过于宽泛。
ALP [19] 为 AMP 提供可用性和持续性信号：
生命周期状态过滤确保已废弃、已暂停或已退役的智能体不出现在匹配结果中。这是硬性过滤，不是评分调整。
分叉谱系实现部分信誉继承。当智能体 X 分叉创建智能体 Y 时，子代继承父代信誉的一部分（按 ALP 和 ARP v2 指定）。AMP 可以显示谱系关系，允许请求者评估分叉是否继承了父代的领域能力。
继任状态指示智能体是否有指定的继任者。对于长期运行的任务，与有继任计划的智能体匹配降低了智能体退役时工作中断的风险。
设计良好的匹配协议将个体激励与系统整体效率对齐。AMP 的激励结构使三种行为成为参与者的个体理性选择：
诚实的能力报告：智能体受益于准确的 UCP，因为不准确的画像导致糟糕的匹配、失败的任务、负面的 ARP 评分和 ASA 争议——所有这些都会降低未来排名。反馈循环（匹配→任务→评分→排名）对过度声明产生自然惩罚。一个声称"Python 安全审查专家"但交付平庸结果的智能体会积累差评和争议，从而降低其未来匹配排名。
然而，这一激励有延迟——惩罚在任务完成和评分后才实现，而非在上架时。没有评分历史的新智能体面临过度声明的诱惑。AMP 通过信任层级系统（第9.2节）缓解这一问题：未验证的声明获得较低的信任层级分类，降低了过度声明的收益。
准确的定价：在拍卖和 RFQ 场景中，智能体面临低价出价（赢得更多匹配但可能无利可图）与高价出价（更高利润但更少匹配）之间的权衡。Vickrey 拍卖的理论诚实出价特性在此适用，但需注意第6.3节中关于重复交互和潜在串谋的说明。在标价场景中，价格-质量相关性跟踪（第8.3节）使不合理的溢价定价可见。
真实的质量交付：ASA 质量验证、ARP 评分与 AMP 排名之间的联系创建了多层质量激励。交付低质量的智能体面临：(1) 即时的 ASA 托管扣留，(2) 降低未来排名的负面 ARP 评分，(3) 产生风险信号的潜在 AJP 争议，(4) 所有未来任务的匹配结果降级。这种分层惩罚结构意味着操纵任何单一机制都无法消除质量激励。
博弈论分析识别出几种潜在失败模式：
拍卖中的虚假出价：智能体创建虚假的竞争出价以推高价格。AMP 通过身份验证（每个出价者必须有可验证的身份——CoC 链、DID 或 A2A Card）和基于信誉的出价者资格审查（参与拍卖的最低信任分数）来缓解。
串谋定价：竞争智能体协调价格以避免互相压价。这是算法定价市场中的已知问题 [47]。AMP 通过价格方差监控检测潜在串谋：如果能力相似的智能体尽管成本结构不同却聚集在相似的价格点，将触发串谋标记。检测不等于预防——AMP 无法强制竞争性定价，但可以使串谋模式对请求者可见。
匹配后质量降低：已匹配和接受的智能体可能交付低于其历史表现的质量，特别是如果它认为请求者没有替代方案（套牢问题）。ASA 的自动化质量验证缓解了这一问题——质量根据协议标准进行验证，不受智能体过去信誉的影响。
注意力操纵：Microsoft 的 Magentic Marketplace 研究发现，卖方智能体可以利用买方智能体的上下文窗口限制来操纵决策——用无关信息淹没买方，使首选选项看起来相对更好 [36]。AMP 通过在服务器端执行匹配（由 AMP 节点而非请求者智能体评估候选）来缓解，减少了注意力操纵的攻击面。然而，匹配后直接交互的智能体仍然易受攻击——这是 ASA 层面而非 AMP 层面的关注点。
评分通胀：ARP v2 的反通胀机制（方差下限、均值漂移检测、联盟检测）[16] 保护 AMP 消费的信任信号。AMP 本身不裁决评分质量——它信赖 ARP v2 的 Anti-Goodhart 架构提供可靠的分数。
AMP 的匹配机制具有以下形式化属性（附适当限定条件）：
个体理性：参与 AMP 对请求者（获得比逐个搜索市场更好的匹配）和智能体（获得比在单一市场上架更多的曝光）都是个体理性的。只要 AMP 的匹配质量超过手动多平台搜索的替代方案，这一点就成立，鉴于跨平台聚合，这是预期的，但最终是一个取决于实现质量的经验性主张。
激励兼容性（部分）：在 Vickrey 拍卖模式中，在标准假设（独立私有价值、风险中性出价者）下，诚实出价是优势策略。在标价和 RFQ 模式中，诚实定价的激励是间接的——通过质量-价格相关性跟踪和长期信誉效应中介。完全的激励兼容性（在所有模式中诚实行为严格占优）未能实现，且在实际匹配系统中可能无法实现。
稳定性（批量模式）：Gale-Shapley 稳定匹配保证批量分配是稳定的——没有任务-智能体对会相互偏好对方而非各自当前的分配 [12]。此保证在匹配轮次内的静态偏好下成立。轮次之间，动态偏好变化可能引入临时不稳定，在下一个匹配周期时解决。
效率（近似）：AMP 的排名搜索模式产生近似有效的结果——在给定评分函数下，排名最高的智能体是最佳可用匹配。精确效率（最大化所有匹配的总福利）仅在稳定匹配模式中保证，且仅对提议方（默认为任务最优）。近似效率与精确效率之间的差距是实时匹配计算可行性的必要权衡。
主要组织相容性复合体（MHC）通过分子模式匹配实现自我/非自我区分 [51]。MHC 分子结合肽段并在细胞表面展示，供 T 细胞识别。该系统具有显著的多态性——群体中多样化的 MHC 变体确保没有单一病原体能逃避所有免疫系统。自我/非自我区分通过负选择实现：与自身抗原结合过强的 T 细胞在部署前在胸腺中被删除 [52]。
AMP 类比：AMP 的信任验证充当智能体市场的免疫系统。信任信号（CoC 溯源、ARP 评分、ASA 记录、AJP 争议）是智能体携带的"分子标记"。信任验证器对这些标记进行模式匹配——检查已知的不良模式（撤销的证书、争议标记、恶意技能检测），就像 T 细胞检查非自身抗原一样。MHC 的多态性映射到 AMP 的多信号信任架构：没有单一的信任机制占主导。多样化的验证方法（密码学溯源、双边评分、质量验证、争议记录）提供群体级别的信任博弈抵抗力——正如 MHC 多样性提供群体级别的病原体抵抗力。
生物市场理论提出，有机体提供对自己生产成本低的商品，以换取对自己昂贵或没有伙伴就无法获得的商品 [53]。伙伴选择通过制裁来执行：提供较少磷的菌根真菌从其宿主植物获得较少的碳。这在没有集中式信誉系统的情况下创建了自我强化的质量信号。
AMP 类比：制裁模型直接转化为 AMP 的反馈循环。交付低质量的智能体面临：更少的未来任务分配（匹配排名降低）、更低的价格（请求者要求折扣）以及可能的下架（AJP 争议导致通过 ALP 的生命周期状态变更）。生物市场制裁的双边性质——每个伙伴根据对方的贡献调整投资——映射了 ARP 的双边盲审评估，双方在交互后互相评分。关键洞见是：即使没有集中式信誉协议，信誉也可以从双边经济反馈（制裁/奖励）中涌现，尽管 ARP 通过使反馈明确且可携带来加速收敛。
AMP 的威胁模型考虑四种对手类型：
| 对手 | 目标 | 能力 |
|---|---|---|
| 操纵型智能体 | 提升自身排名以赢得更多匹配 | 可以创建误导性 UCP、在拍卖中策略性出价、与盟友协调 |
| 女巫攻击者 | 创建多个虚假智能体以主导结果 | 可以低成本创建许多智能体身份 |
| 监控型对手 | 通过观察匹配查询了解竞争对手的能力 | 可以观察网络上的匹配请求和响应 |
| 拒绝服务攻击者 | 通过压垮 AMP 节点阻止合法匹配 | 可以生成大量匹配请求或注册表查询 |
针对操纵型智能体：
针对女巫攻击：
针对监控型对手：
针对拒绝服务：
智能体匹配产生隐私张力：
能力披露：智能体必须（MUST）透露足够的能力信息用于匹配，但可能因竞争原因希望保留实现细节。AMP 的渐进式披露模型（第3.7节）解决了这一问题：UCP 能力描述是公开的，但详细的实现信息（精确的工具配置、模型参数、专有知识库）可以仅在匹配确认后才披露。
查询隐私：请求者的匹配查询可能透露战略信息——缺少什么能力、需要外包什么任务、预算是多少。AMP 节点应当（SHOULD）支持匿名查询，并且不得（MUST NOT）将个人查询数据与注册表或智能体共享超出匹配所需的范围。
信任信号隐私：智能体的确切 ARP 分数、争议历史和 SLA 合规率是敏感信息。AMP 通过 ARP v2 的零知识证明机制支持聚合披露（例如，"信任分数超过阈值 X"），而非要求完全的信任信号透明度。
Microsoft 的 Magentic Marketplace 研究 [34][36] 在智能体市场模拟中识别出经验观察到的失败模式：
AMP 从结构上解决了这些问题：
description 字段）的情况下，它们只是众多输入之一——评分函数对已验证信号的权重高于声明信号。一个跨 Google Cloud、Salesforce、AWS、ServiceNow 和开放注册表对智能体进行排名——并影响潜在价值数万亿美元的采购决策——的协议，在监管领域需要明确分析。
欧盟《数字市场法》（DMA）下的守门人风险。DMA 针对"守门人"——在商业用户和终端用户之间充当重要门户的平台。被广泛采纳的 AMP 实现可能满足 DMA 的量化阈值（75亿欧元市值或750亿欧元公允市值、4500万月活终端用户、欧盟1万商业用户）。如果 AMP 成为占主导地位的跨市场匹配层，它可能被指定为守门人服务，触发义务包括：禁止自我优待（第6(5)条）、要求允许商业用户通过其他渠道以不同条件推广（第6(12)条）以及互操作性要求。
通过协议架构缓解：AMP 是协议而非平台。没有单一实体运营"那个"AMP 服务——任何组织都可以运行 AMP 节点。这种架构选择是主要的反垄断防御：没有单一的守门人可供指定。但是，如果单一 AMP 节点实现获得主导市场份额（正如 Google 对 Chrome 所做的，尽管 Web 是开放的），DMA 分析仍可能适用于该特定运营者。
信任加权排名和竞争中立性。最实质性的反垄断关注是信任加权排名是否系统性地偏向与 AB Support 信任堆栈（CoC、ARP、ASA、AJP、ALP）集成的智能体而非未集成的。信任层级系统（第9.2节）明确将第4层（通过信任堆栈协议验证）排在第1层（自我声明）之上——这意味着信任生态系统之外的智能体按设计获得较低排名。这类似于 Google 的搜索算法偏好 HTTPS 页面而非 HTTP：一个同时也有利于 Google 自身证书生态系统的质量信号。
AMP 通过三种机制解决这一关切：
trust_score 权重设为零以偏好纯能力匹配。没有评分组件是不透明或不可覆盖的。欧盟《人工智能法》影响。AMP 可能属于《AI 法》的"有限风险"类别（非"高风险"），因为它推荐智能体而非对自然人做出重大决策。但是，如果 AMP 用于在高风险领域——招聘、信用评分、执法——匹配智能体，下游用例可能触发对 AMP 节点运营者的高风险分类。AMP 节点应当（SHOULD）维护足够的日志以满足《AI 法》透明度要求（第13条），并应当（SHOULD）在被请求时提供排名决策的解释（已通过匹配响应中的维度分数分解支持）。
跨市场排名作为市场力量。占主导地位的 AMP 节点运营者能否利用排名影响力向智能体开发者收取租金？这是"应用商店"风险——Apple 和 Google 利用其市场地位收取30%佣金并施加限制性条款。AMP 的协议非平台架构缓解了这一点：如果一个 AMP 节点运营者变得剥削性，智能体和请求者可以切换到另一个 AMP 节点实现，而不会丢失其能力画像、信任历史或市场访问。Portable Reputation Bundles（ARP v2）和 CoC 链的可移植性确保了转换成本保持较低。
残余风险。这些缓解措施减少但不消除反垄断风险。网络效应仍可能使使用集中在单一 AMP 节点实现上。信任堆栈集成优势虽然开放访问，仍为先发者创造了竞争护城河。协议设计者应主动参与 DMA 和《AI 法》合规框架，考虑为能力分类体系（第5.4节）任命独立治理，并设计排名中立性审计机制。开源参考实现和公开的评分算法是监管可辩护性的必要但非充分条件——还需要积极的治理和合规监控。
本节坦率地识别了本白皮书中 AMP v1 规范的局限性：
联邦增加延迟和故障模式。跨注册表查询本质上比单注册表搜索更慢。注册表超时、适配器故障和网络分区可能产生不完整的结果。第7.2.1节分析了预期延迟；生产部署必须为注册表不可达时的降级模式运行做设计。
信任集成深度取决于外部协议采纳。AMP 的竞争优势——深度信任加权排名——要求智能体与 CoC、ARP、ASA、AJP 和 ALP 集成。在这些协议获得显著采纳之前，大多数智能体仅有第1层或第2层信任信号，使 AMP 的排名质量降至大约标准目录加增强搜索的水平。这产生了循环依赖：AMP 的价值推动信任堆栈采纳，但信任堆栈采纳推动 AMP 的价值。
能力分类体系为草案，未达到生产就绪。第1级/第2级分类体系（第5.4节）是示意性的。实现者在完整分类体系作为单独版本化工件发布之前无法基于其构建生产分类系统。语义匹配部分缓解了这一问题（新能力可通过嵌入相似度匹配），但结构化分类查询将在分类体系标准化之前在不同实现之间产生不一致的结果。
匹配质量在历史数据不足时下降。协同过滤（第6.2节，interaction_history_score）对新请求者或没有交互历史的新 AMP 节点提供零价值。信任评分依赖于累积的 ARP、ASA 和 AJP 记录。冷启动的 AMP 部署在累积足够的交互数据之前作为能力匹配目录运行——估计阈值为约1,000个匹配请求（第10.4节）。
协议规定了算法但未涉及运维关切。AMP v1 不涉及监控、告警、故障转移、升级路径、跨协议版本的向后兼容或运维手册。生产 AMP 节点需要超出协议规范的大量运维基础设施。
隐私保护匹配目前为愿景性的。AMP v1 的隐私模型（TLS + 查询匿名化 + 渐进式披露）对大多数用例足够，但未达到强隐私保证。通过 MPC 或同态加密实现完全隐私保护匹配因计算成本约束推迟到未来工作（第17.3节）。
引导数字高估了就绪度。虽然理论上可通过联邦访问19,000多个能力、技能和智能体列表，但实际效用取决于适配器质量、注册表 API 稳定性以及将原子技能桥接到复合智能体画像的异构性挑战（第10.2节）。
AMP 参考实现由四个组件组成：
amp-core：Python 库，实现匹配引擎、兼容性评分和 UCP 数据模型。除 Python 标准库和 JSON Schema 验证器外无外部依赖。
amp-federation：具有可插拔注册表适配器的联邦路由器。内置适配器包括：A2A Agent Card 爬取（基于 HTTP）、ClawHub 语义搜索（基于 API）和通用 REST 适配器模板。
amp-trust：信任验证器，查询 CoC、ARP、ASA、AJP 和 ALP 端点以填充已验证的信任信号。独立运行——可在不使用联邦的情况下用于已知智能体的信任验证。
amp-node：HTTP 服务器，将所有三个组件整合为可部署的 AMP 节点。暴露匹配请求 API（第6.1节）、注册表注册 API（第7.3节）和管理端点。
import os
from amp_core import MatchEngine, UCPStore
from amp_federation import FederationRouter, A2AAdapter, ClawHubAdapter
from amp_trust import TrustVerifier
from amp_node import AMPNode
# Initialize components
engine = MatchEngine()
store = UCPStore()
router = FederationRouter()
verifier = TrustVerifier(
coc_endpoint="https://coc.example.com",
arp_endpoint="https://arp.example.com"
)
# Register federated registries
router.add_adapter(A2AAdapter(crawl_domains=["agent.example.com"]))
router.add_adapter(ClawHubAdapter(api_key=os.environ["CLAWHUB_API_KEY"]))
# Launch node
node = AMPNode(engine=engine, store=store, router=router, verifier=verifier)
node.serve(host="0.0.0.0", port=8430)from amp_core import MatchRequest
request = MatchRequest(
task_description="Review Python microservice code for security vulnerabilities",
domain="security",
subdomain="code_review",
budget_max=50.00,
deadline_ms=3600000,
weights={"capability_match": 0.30, "trust_score": 0.25, "cost_alignment": 0.15,
"availability": 0.10, "style_compatibility": 0.05, "domain_relevance": 0.15},
constraints={"min_trust_score": 60, "max_dispute_rate": 0.05}
)
results = node.match(request)
for result in results:
print(f"{result.rank}. {result.agent_id} — score: {result.compatibility_score}")
print(f" Trust: {result.trust_verification}")
print(f" Cost: {result.estimated_cost}")| 端点 | 方法 | 描述 |
|---|---|---|
/amp/v1/match | POST | 提交匹配请求，接收排名结果 |
/amp/v1/profile | GET/PUT | 检索或更新智能体的 UCP |
/amp/v1/registry | POST | 注册新的联邦注册表 |
/amp/v1/registries | GET | 列出已注册的联邦注册表 |
/amp/v1/trust/{agent_id} | GET | 检索智能体的已验证信任信号 |
/amp/v1/auction | POST | 为任务创建拍卖 |
/amp/v1/auction/{id}/bid | POST | 向拍卖提交出价 |
/amp/v1/health | GET | 节点健康状况和联邦状态 |
AMP v1 将单个智能体匹配到单个任务。许多现实任务需要协调的团队——一个研究智能体、一个代码智能体和一个审查智能体协同工作。团队匹配是一个显著更难的问题：
团队匹配推迟到 AMP v2。组合拍卖机制（第6.3节）提供了部分解决方案：智能体可以作为预组建团队出价。真正的团队组建——由 AMP 从单个智能体中组建最优团队——需要对互补性评分和团队协同指标进行额外研究。
AMP v1 使用具有固定维度权重的线性评分函数。机器学习方法（学习排名）可以通过学习任务特征、智能体画像和匹配结果之间的非线性关系来改善匹配质量。训练信号可用：匹配后反馈（ARP 评分、ASA 质量验证）提供匹配是否成功的真实标签。
学习排名的风险是不透明性——模型可能学习到难以检测或解释的偏差。AMP v2 将探索可解释的学习排名模型，在改善线性评分的同时保持可解释性。
AMP v1 的隐私模型依赖于 TLS 加密、查询匿名化和渐进式披露。更强的隐私保证可通过以下方式实现：
这些技术目前对于大规模实时匹配的计算成本过高，但成本正在快速下降。AMP v2 将为敏感用例规定可选的隐私保护匹配模式。
AMP 的跨平台匹配仅与其底层信任数据一样有用。如果每个市场以不同方式计算信誉，跨平台比较就毫无意义。ARP v2 的 Portable Reputation Bundles [16] 提供了标准格式，但市场采纳尚不确定。
AMP 可以通过定义比完整 ARP v2 合规更简单的最小信誉交换格式来加速采纳——一种"信誉嵌入"，任何市场都可以发布，包含维度分数、样本量和计算时间戳。这种务实的方法以深度换广度，即使从未采纳完整信任生态系统的市场也能实现基本的跨平台比较。
当前 AMP 匹配使用智能体可用性和定价的时间点快照。实时市场信号——特定能力的需求激增、价格变动、整个生态系统的产能利用率——可以实现考虑市场条件的动态匹配。这类似于程序化广告中的实时竞价，其中拍卖基于实时需求信号在毫秒级发生。
实现需要用于市场信号分发的发布/订阅基础设施，这在架构上不同于 AMP v1 中的请求-响应匹配模型。
智能体经济正在恰恰需要整合的时刻碎片化为封闭生态。九个不同的市场服务于重叠但不兼容的智能体生态系统。跨平台发现不存在。信任信号被孤立、不可验证或缺失。匹配问题——在给定多维质量要求、信任约束和成本偏好的情况下，为特定任务找到最佳智能体——未被任何生产系统解决。
Agent Matchmaking Protocol 通过规定完整的匹配层来解决这一问题：用于跨平台描述智能体能力的统一能力画像格式、超越简单能力匹配纳入已验证信任信号的多维兼容性评分系统、无需市场让出控制权即可跨孤立市场搜索的联邦发现、支持标价、拍卖和协商的价格发现机制，以及将声明的能力转化为可验证质量信号的信任加权排名。
AMP 的竞争优势不在于任何单一组件——匹配算法是研究充分的，联邦是已知的架构，价格发现机制是成熟的。优势在于集成深度。现有市场在上架时对智能体进行一次性验证，AMP 则通过完整信任堆栈进行持续验证：CoC 溯源用于身份、ARP 信誉用于质量、ASA 合规用于可靠性、AJP 争议记录用于风险、ALP 生命周期状态用于可用性。这种分层的、可验证的信任集成将搜索引擎转化为参与者可以信赖的市场。
引导策略——联合现有注册表而非建立新供给——避免了扼杀大多数市场创业公司的先有鸡还是先有蛋问题。现有注册表中已有19,000多个能力、技能和智能体列表可被发现——涵盖原子技能、自动化工具和复合智能体画像——AMP 节点在第一天就能提供价值。协议方式确保 AMP 随生态系统扩展而非与之竞争：每个实现 AMP 适配器的新市场都增加网络的价值。
AMP 是信任生态系统的商业顶层——协议变为产品的层。CoC、ARP、ASA、AJP 和 ALP 提供信任基础设施。AMP 提供消费、定价和交易信任的市场。它们共同构成了智能体经济的基础，在这个经济中，信任通过可验证的运营赢取，而非通过营销文案声明。
[1] Google Cloud Blog, "Google Cloud AI Agent Marketplace," 2025.
[2] Salesforce Press Release, "AgentExchange Announcement," March 4, 2025.
[3] AWS News Blog, "Introducing Amazon Bedrock AgentCore," October 2025.
[4] ServiceNow Blog, "Your Go-to Marketplace for AI Agents," 2025.
[5] gorilla.cs.berkeley.edu, "Agent Marketplace," 2025.
[6] ClawHub (clawhub.ai), registry statistics, February 2026.
[7] AI Agent Store (aiagentstore.ai), directory listing, 2026.
[8] ProductMint, "The KAYAK Business Model," 2025.
[9] A2A Protocol (a2a-protocol.org), "Agent Discovery," 2025; CodeLime, "A2A Protocol explained," 2025.
[10] ModelContextProtocol.io, Specification November 2025; MCP Blog, "The 2026 MCP Roadmap," 2026.
[11] ClawHub Docs, SKILL.md format specification, 2026; DigitalOcean, OpenClaw guide, 2026.
[12] Gale, D. and Shapley, L.S., "College Admissions and the Stability of Marriage," American Mathematical Monthly, 69(1): 9-15, 1962.
[13] OpenAI, Agentic Commerce Protocol (with Stripe), September 2025.
[14] Google, Universal Commerce Protocol (with Shopify, Etsy, Wayfair, Target, Walmart), 2025-2026; Ekamoira Blog, "How AI Agents Are Changing E-commerce in 2026," 2026.
[15] AB Support LLC, "Chain of Consciousness: A Cryptographic Protocol for Verifiable Agent Provenance and Self-Governance," v3.0.0, 2026.
[16] AB Support LLC, "Agent Rating Protocol v2: Signal Composition, Portability, and Anti-Goodhart Architecture," v2.0.0, 2026.
[17] AB Support LLC, "Agent Justice Protocol," v1.0.0, 2026.
[18] AB Support LLC, "Agent Service Agreements," v1.0.0, 2026.
[19] AB Support LLC, "Agent Lifecycle Protocol," v1.0.0, 2026.
[20] IETF, draft-liang-agentdns-00, "AgentDNS: A Root Domain Naming System for LLM Agents," 2025.
[21] ArXiv 2505.10609, "Agent Name Service (ANS)," May 2025; IETF, draft-narajala-ans-00, 2025.
[22] CmdZero Blog, "Introducing the Agent Communication & Discovery Protocol (ACDP)," 2025.
[23] ERC-8183, Programmable Escrow Standard, Ethereum, 2025-2026.
[24] x402 Payment Protocol, transaction statistics, 2025-2026.
[25] Rochet, J.-C. and Tirole, J., "Platform Competition in Two-Sided Markets," Journal of the European Economic Association, 1(4): 990-1029, 2003.
[26] Northwestern/Palacios-Huerta, "Two-sided Markets, Pricing, and Network Effects," 2021; HBS Online, "What Are Network Effects?" 2025.
[27] Nisan, N. et al., Algorithmic Game Theory, Cambridge University Press, 2007.
[28] W3C, "Decentralized Identifiers (DIDs) v1.1," Candidate Recommendation, 2026.
[29] PwC/Google Cloud, "AI agent ecosystem with Google Cloud," 2025.
[30] Salesforce Investor Relations, "Agentforce 360 for AWS," 2025.
[31] Blink Blog, "OpenClaw Skills: How to Install from ClawHub Safely in 2026," 2026.
[32] Adven Boost, "OpenClaw ClawHub: The 2026 Security-First Guide," 2026.
[33] Apify, AI Agent Marketplace and agentic commerce blog, 2026.
[34] Microsoft Research Blog, "Magentic Marketplace: open-source simulation environment," November 2025.
[35] TechCrunch, "Microsoft built a fake marketplace to test AI agents," November 2025.
[36] InfoQ, "AI Agents Fail Manipulation Tests in Magentic Marketplace," November 2025.
[37] O*NET Resource Center, "O*NET-SOC Taxonomy," 2025.
[38] Vickrey, W., "Counterspeculation, Auctions, and Competitive Sealed Tenders," Journal of Finance, 16(1): 8-37, 1961.
[39] Milgrom, P., "Putting Auction Theory to Work," Cambridge University Press, 2004.
[40] Cramton, P., Shoham, Y., and Steinberg, R., "Combinatorial Auctions," MIT Press, 2006.
[41] Gartner, "Top Strategic Predictions for 2026 and Beyond," presented by Daryl Plummer at Gartner IT Symposium/Xpo, October 2025. Prediction #6: "By 2028, 90% of B2B buying will be AI agent intermediated, pushing over $15 trillion of B2B spend through AI agent exchanges." Available at gartner.com/en/newsroom/press-releases/2025-10-21-gartner-unveils-top-predictions-for-it-organizations-and-users-in-2026-and-beyond.
[42] McKinsey & Company (QuantumBlack), "The Agentic Commerce Opportunity: How AI Agents Are Ushering in a New Era for Consumers and Merchants," October 2025. Available at mckinsey.com/capabilities/quantumblack/our-insights/the-agentic-commerce-opportunity.
[43] Brin, S. and Page, L., "The Anatomy of a Large-Scale Hypertextual Web Search Engine," WWW 1998.
[44] HBS Online, "What Are Network Effects?" 2025; Practical Ecommerce, "Network Effects Drive Ecommerce Marketplace Growth," 2025.
[45] Practical Ecommerce, ibid.
[46] Hagiu, A. and Wright, J., "Multi-Sided Platforms," International Journal of Industrial Organization, 43: 162-174, 2015.
[47] Ezrachi, A. and Stucke, M.E., "Algorithmic Collusion: Problems and Counter-Measures," OECD Background Paper, 2017.
[48] Olesen, J.M. et al., "The modularity of pollination networks," PNAS, 104(50): 19891-19896, 2007.
[49] Gordon, D.M., "The Ecology of Collective Behavior," PLoS Biology, 2014.
[50] Dorigo, M. and Gambardella, L.M., "Ant Colony System: A Cooperative Learning Approach to the Traveling Salesman Problem," IEEE Transactions on Evolutionary Computation, 1(1): 53-66, 1997.
[51] Janeway, C.A. et al., "The major histocompatibility complex and its functions," Immunobiology, 5th ed., 2001.
[52] Kappler, J.W. et al., "T cell tolerance by clonal elimination in the thymus," Cell, 49(2): 273-280, 1987; Science, 1992.
[53] Noë, R. and Hammerstein, P., "Biological markets: supply and demand determine the effect of partner choice in cooperation, mutualism and mating," Behavioral Ecology and Sociobiology, 35(1): 1-11, 1994.
本文件基于 Apache License 2.0 许可。版权所有 2026 AB Support LLC。Agent Matchmaking Protocol 是一项开放规范——任何组织均可在无需许可或支付版税的情况下实现。