ownership-provenance-protocol

所有权与证明协议（OAP）

一个精简的 MCP 协议，用于强制执行两项目前主流 Agent 框架都无法原生实现的规则：

1. 任务只有在被明确接受后才归某人所有。 仅靠分配、推断或上下文信息并不足够——执行者（人类或 AI Agent）必须明确接受任务，任务才算归其所有。
2. 报告任务完成时，必须说明报告者如何确认其属实。 每条“已完成”声明都必须附带一个来源标签：Observed（我亲自完成）、Reviewed（我检查过相关证据）或 Reported（我在转述他人告知的内容）。没有第四种选项，也不能不选择其中一项就报告完成。

协议的全部内容就是这些。此仓库中的其他所有内容，都是为了支持这两项规则。

为什么要做这个项目

所有权交接失败是生产环境中多 Agent 系统常被提及的一种故障模式——一个 Agent 把工作交给另一个 Agent，上下文随之丢失，最终无人对结果负责。此外，一篇发表于 2026 年 3 月、关于 Agent 身份协议的论文（Prakash，AIP: Agent Identity Protocol for Verifiable Delegation Across MCP and A2A，arXiv:2603.24775）指出，在作者的调查中，他们未发现此前有已实现的协议能同时结合可验证委派、权限衰减式授权和面向来源记录的完成记录。

本项目旨在针对这两个问题，测试一种范围狭窄且具体的解决方案——它不是完整的治理平台，也不是评估框架，只专注于所有权、任务接受和证明机制。

现实世界中的动因

两个有文档记录的公开事件直接影响了这项设计：

• Replit AI 编码 Agent 在代码冻结期间删除了生产数据库，随后谎称无法回滚——这项声明信心十足，却从未经过实际验证。后来有人真正尝试回滚，一切顺利。(AI Incident Database, Incident #1152)
• 加拿大航空的聊天机器人向一位客户提供了其丧亲票价政策的错误资格信息，告知他可以事后申请折扣，而实际政策要求必须在出行前获批。审裁庭裁定航空公司承担责任——这表明，无论是否有人工事先审核过 AI 的说法，公司都要为其负责。(Moffatt v. Air Canada, 2024 BCCRT 149，不列颠哥伦比亚省民事纠纷解决审裁庭)

这两起事件的模式相同：声明表现出的信心超过了实际验证所得出的程度。本协议专门用于捕捉这类问题——不是让 Agent 变得更聪明，而是从结构上杜绝在未说明实际验证方式的情况下报告声明。

六个 MCP 工具

工具	功能
create_task	创建处于 pending_acceptance 状态的任务。此时尚无任何人拥有该任务。
accept_task	明确接受任务。如果任务已有不同的当前所有者，则操作失败——通过原子方式强制执行，在真实并发场景下也安全，而不只是适用于顺序调用。
report_completion	必须提供有效的来源值（observed | reviewed | reported）。如果缺少该值或其无效，则直接拒绝调用——这是整个系统中唯一不可妥协的规则。
handoff_task	转移所有权，并在转移的准确时刻捕获任务状态的冻结快照。接收者不会自动成为所有者——必须先自行调用 accept_task，才能采取行动。
get_task_status	返回单个任务的完整历史记录：注入任务、所有接受记录、所有带有来源信息的完成声明，以及所有交接记录。
list_unaccepted_tasks	显示当前没有所有者的任务——这是一个可直接查询的信号，用于识别本协议旨在防止的“静默继承”风险。

协议不变量

以下六项陈述在任何符合规范的实现中始终成立：

1. 每项任务当前的负责人为零个或一个。
2. 所有权只能通过明确的接受来变更。
3. 每项完成声明都恰好有一个溯源值。
4. 没有新证据时，溯源值绝不会变得「更确定」——如果没有经过验证的中间步骤，参与者不能将「已报告」的声明升级为「已观察」。此实现通过拒绝同一任务上取代「已报告」声明的 observed 声明来强制执行这一点，除非调用提供了指明已验证内容的 sourceReference。降级、反向更正和首次声明不受影响。
5. 每次交接都会捕获状态快照。
6. 每项任务的历史记录都能完整重建。

如果某个实现要求明确接受、拒绝没有溯源信息的声明、支持全部三种溯源类别、保留可重建的历史记录，并支持通过交接转移所有权，则该实现符合 OAP 规范。部分实现应称为「受 OAP 启发」，而非符合规范。

为什么不直接使用日志 / Git / OpenTelemetry / Temporal？

这个问题问得很好，简而言之，OAP 的定位是与它们协同工作，而非取而代之：

• 日志被动记录事后发生的事情。OAP 则要求在接受完成声明之前，主动做出承诺。
• Git对内容进行版本控制，并记录谁提交了什么，但没有「已接受、正在履行的义务」这一概念，也不会将其与产出物本身区分开来。
• OpenTelemetry能出色地在分布式追踪中传播上下文，但没有与正确性声明中的溯源标签相当的模式概念。
• Temporal / 持久化执行引擎非常擅长解决状态持久化和可靠恢复问题——此参考实现旨在构建在这类工具之上，而非重新发明它们。但持久化执行回答的是「此步骤是否运行过」，而不是「参与者是否通过明确接受拥有此任务，以及我们如何知道其完成声明属实」。

在本地运行

要求：Node.js 24、PostgreSQL、pnpm。

pnpm install

设置必需的环境变量：

DATABASE_URL=<your Postgres connection string>
MCP_ACCESS_TOKEN=<a long random string — generate one with `openssl rand -hex 32`>

推送模式并启动 API 服务：

pnpm --filter @workspace/db run push
pnpm --filter @workspace/api-server run dev

调用任何工具之前，至少创建一个参与者。 每个工具都需要一个参与者 ID，并且要求该参与者已存在——参与者列是 NOT NULL 外键。协议有意不提供 create_actor 工具或路由：参与者身份是 OAP 的输入，而非 OAP 签发的内容，因此在实际部署中，参与者由现有的身份管理系统提供。这意味着刚推送的数据库中没有任何参与者，首次调用 create_task 会因 404 错误而失败，直到你添加一个参与者。本地开发可使用种子脚本：

pnpm --filter @workspace/scripts run seed-actor alice human "Alice"

这只是一个普通脚本，不属于协议接口——服务器不会导入它，也无法通过 HTTP 访问它。

MCP 服务挂载在 /mcp，每个请求都必须在 Authorization 标头中携带作为 bearer token 的 MCP_ACCESS_TOKEN，但 /api/healthz 除外；该路径不需要身份验证，可用于健康检查。

连接一个真实的 MCP 客户端（例如 Claude Code）：

claude mcp add --transport http opp http://localhost:5000/mcp --header "Authorization: Bearer <your-token>"

运行测试

测试套件覆盖协议的并发保障，因此需要一个真实的 PostgreSQL 实例——它会执行真正同时发生的事务，不能使用进程内或单连接替代方案运行。

pnpm --filter @workspace/api-server run test

测试默认连接到 postgresql://opp:[email protected]:55432/opp_test。如需连接其他数据库，请设置 OPP_TEST_DATABASE_URL，并先将模式推送到该数据库。运行器会完全忽略 DATABASE_URL，并拒绝连接任何非环回主机：测试套件会在每项测试之间清空所有表，而继承真实的连接字符串会恰好摧毁此协议旨在保护的溯源记录。

状态

这是一个早期项目，仅经过个人测试，尚未打磨成成熟产品。它由作者手动构建并进行了对抗性测试，涵盖并发竞争、格式错误的输入和绕过所有权检查的尝试；此外，还通过真实的外部 MCP 客户端，在实际部署环境中完成完整的协议握手，进行了端到端验证。手动测试所覆盖的所有权和证明保证现已由自动化测试套件锁定，该套件会针对真实数据库并发运行这些竞争测试。除作者外，尚无人使用过此项目；对于其是否适合生产环境，除上述说明外，我们不作任何保证。如果你使用此项目时发现问题，或发现某种情况不受这些不变量约束，请提交 issue。

许可证

MIT