A202

Name: A202
Author: a202-protocol

本地服务

a202.org商业与营销45 周前更新

代码仓库访问官网

关于 A202

A202 是面向软件 Agent 与独立组织间可验证商业交易的开放规范，定义委托权限、交易与会话状态、信息披露规则及一致性检查。

主要功能

01类型化委托权限模型
02交易与会话状态机
03受控披露规则
04可执行的一致性测试套件

适用场景

01界定 Agent 主导交易的权限
02检查交易实现是否符合规范

配置

本地服务的配置在各客户端中通用，复制后粘贴到客户端的 MCP 配置文件即可。

mcp.json · 通用配置

{
  "mcpServers": {
    "a202-protocol-a202": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "ghcr.io/a202-protocol/a202-mcp:0.1.0"
      ]
    }
  }
}

启动命令docker run -i --rm ghcr.io/a202-protocol/a202-mcp:0.1.0

本地服务需要在你的电脑上安装运行环境（如 Node.js 18+）。各客户端的配置文件位置不同，请参考客户端文档。

安装包

ocighcr.io/a202-protocol/a202-mcp:0.1.0stdio

工具

还没有获取到工具列表

本地服务需要在你的电脑上运行后才能读取工具，维护者暂未提供工具列表。

详细介绍

A202：面向 Agent 主导商务活动的可验证协议

状态： 全文为说明性内容。

A202 为 Agent 对 Agent 或由 Agent 主导的交易提供可验证商务能力：这是一套开放规范，用于规定商业授权、协商状态，以及独立组织之间交易的可验证符合性，其中包括由软件 Agent 代表这些组织进行的交易。

它定义了用于委托商业授权的类型化对象、用于交易及其中每个双边会话的状态机、关于可以向谁披露哪些信息的规则，以及一套可执行的符合性测试套件，可将上述各项转化为检查，让实现通过或未通过。

目的、范围和非目标的完整说明见 CHARTER.md。

由 A. A. Musse 创建并开发。请参阅 MAINTAINERS.md。

状态

已发布，1.0 之前版本。

v0.1.0 是该版本系列的首个带标签发布：包含一个标签、每个架构文件的摘要、符合性清单和发行说明，并一并发布。请参阅 RELEASES.md 和 CHANGELOG.md。在 1.0 之前，次版本号递增可能会破坏兼容性；任何不兼容变更都会附带迁移说明。
名称为 A202，读作 “A two-oh-two”，全称为 A202, the Verifiable Agreement Protocol for Agent-Led Commerce。全称是描述性名称，并非缩写：这些字母并不代表该名称。202 指 HTTP 202 Accepted；A202-0017 规定，已接受的提交会返回此状态，因为接受是本规范其余部分所基于的基本操作。A202- 原因代码前缀、A202-NNNN 提案标识符，以及 a202-commercial/0.1 规范版本字符串也都源于此名称。
A202™ 是 Plural Worlds 的商标。名称的许可使用方式见 TRADEMARK.md。
架构 $id 值可通过 https://schemas.a202.org 解析。固定样例使用保留的 .invalid 主机名，因为测试数据绝不能解析。
根据 Apache License 2.0 版授权。 整个仓库均适用同一许可证：规范文本、架构、固定样例、清单、运行器和说明性文档。该许可证明确授予每位贡献者的专利许可。请参阅 LICENSE 和 CONTRIBUTING.md。
接受外部贡献，条件见 CONTRIBUTING.md：提交的贡献采用相同许可证，并须附上开发者来源证明签署。

目录结构

路径	内容
`CHARTER.md`	目的、范围、非目标、设计原则
`GOVERNANCE.md`	项目如何运作，以及赞助方可以和不可以控制什么
`MAINTAINERS.md`	谁维护此仓库
`CONTRIBUTING.md`	贡献状态，以及接受贡献所依据的条款
`SECURITY.md`	私下协调漏洞披露
`THREAT-MODEL.md`	假定的攻击者、所防护的属性，以及明确不防护的内容
`CODE_OF_CONDUCT.md`	行为准则
`TRADEMARK.md`	A202 名称，以及允许和不允许如何使用该名称
`RELEASES.md`	版本管理、发布内容、兼容性政策
`CHANGELOG.md`	变更内容，以及 `RELEASES.md` 要求的发行说明汇总位置
`.github/`	审查分派、拉取请求和议题表单，以及每次变更时运行测试套件的工作流
`proposals/`	`A202` 变更提案流程
`schemas/`	规范性商业模型、交易配置扩展模型和 JSON 架构
`authority/`	商业授权：授权权限、限制、委托、批准、撤销
`discovery/`	交易对手邀请：未注册方如何加入某个指定交易
`negotiation/`	交易与会话状态机，以及拍卖事件语义
`conformance/`	测试样例、清单、规范性运行器和一致性等级定义

每份规范文档都带有状态标头，说明哪些章节是规范性的，哪些是说明性的。

运行一致性测试套件

运行器会根据架构验证清单中列出的每个测试样例，然后应用 JSON Schema 无法表达的不变量。架构有效并不等于符合规范，这正是运行器存在的原因。

它需要 jsonschema>=4.18。如果系统解释器中没有该依赖，创建虚拟环境即可：

python3 -m venv .venv && .venv/bin/pip install "jsonschema>=4.18"

从仓库根目录运行：

python3 conformance/run-conformance.py --verbose

预期结果是所有测试样例均通过、没有失败，并显示清单中的总数：清单是计数的唯一来源，运行器会在每次运行时打印该总数。运行器还会断言，每个负向测试样例都会因清单声明的原因代码而被拒绝；如果规范性层会抛出原因代码，则无论何处抛出都适用。任何架构变更前后都要运行该测试套件。

每个负向测试样例都尽可能精简：移除唯一的违规元素后，文档必须能顺利通过验证。因偶然原因失败的负向测试样例毫无测试价值，因此添加时请务必核实。

该测试套件不依赖任何人记得手动运行。它会与参考实现测试和 MCP 服务测试一起，在每个拉取请求和每次推送到默认分支时运行，由 .github/workflows/checks.yml 负责执行。GOVERNANCE.md 第 3.4 节要求任何对架构、测试样例、清单或运行器的变更都必须通过测试套件；该工作流会将这一要求落实为合并门槛。