dengyier/OpenWorkProof

中文 | English
> 让智能依人的目的而行动，让每一次行动经得起人的判断。
OpenWorkProof 是 AI Agent 工作契约与可验证执行协议。
它记录谁授权了任务、Agent 实际执行了什么、是否超出约定范围、验证者得出了什么结论，
以及验收者最终接受还是拒绝。每次工作都可以导出为一套签名证据包。第三方不需要接入
原系统，只凭证据包和公钥，就能独立验证整条工作链。
OpenWorkProof 不保证 Agent 的结果一定正确，也不替客户作出验收决定。它确保授权有来源、
执行有证据、验证与验收不会被混为一谈，并把接受、拒绝、撤销和申诉的权利留给人。
安装 · 工作原理 ·
Human Agency ·
DeepSeek Harness ·
协议文档 ·
English
公开发布状态请直接回读 PyPI、
GitHub Release 与
MCP Registry。
Core 1.4.0 已发布到 PyPI、GitHub Release 与 MCP Registry；DeepSeek Harness 插件
0.1.0 仍是本地候选，尚未发布 npm 或插件市场。两者是独立的发布事实。
Agent 说 完成了，还缺什么
MCP 连接 Agent 与工具，A2A 连接 Agent 与 Agent。它们解决如何连接和通信，不能单独
证明一次工作是否获得授权、是否按约执行，以及最终由谁验收。
设想一家 AI 服务商让 Agent 修改客户的代码仓库。Agent 提交了补丁，也说测试已经通过。
客户仍然需要回答：
1. 谁授权 Agent 修改这个仓库？
2. 它是否只使用了允许的工具、路径、配额和期限？
3. 补丁、测试和报告是否来自同一次执行？
4. 验证通过是否被错误地写成客户已经接受？
5. 发生争议时，第三方能否在不接入双方系统的情况下复核事实？
日志能告诉人系统输出了什么，却很难独立证明授权、因果关系和最终验收。平台也不能只用
自己的数据库证明自己可信。
OpenWorkProof 把一次 Agent 工作变成一条可以带走、保存和复核的证据链：
OpenWorkProof 不让 Agent 变得更聪明。它让 Agent 的工作更值得委托。
OpenWorkProof 是什么
OpenWorkProof 是可以嵌入现有 Agent、CI、MCP 和多 Agent 编排器的开放协议层。
它把六类事实连接起来：
| 事实 | 回答的问题 |
|---|---|
| 工作目的与范围 | Agent 被要求完成什么 |
| 签名授权 | 谁允许它做这件事 |
| 事前决策 | 这个动作现在是否可以执行 |
| 行动凭证 | Agent 实际做了什么 |
| 独立验证 | 证据是否完整，结论是否成立 |
| 人工验收 | 谁最终接受或拒绝 |
最终交付的不是一份只能在原平台查看的日志，而是一套可离线验证的签名证据包。持有证据包
和公钥的第三方，可以独立复核授权来源、执行范围、证据摘要、验证结论和验收结果。
它不是什么
OpenWorkProof 不是 Agent OS，也不是新的模型或编排框架。它不负责替 Agent 规划任务，
也不声称能够判断所有业务结果是否正确。
Human Agency Profile 是授权边界，不是员工评分、绩效监控、法律责任转移、自动担责、资金托管或合规认证。
OpenWorkProof 也不托管资金，不执行付款，不代替法律仲裁。协议状态可以证明证据达到某个
阶段，但不能制造外部商业事实。
工作原理
一条完整工作链由以下对象组成：
| 对象 | 作用 |
|---|---|
| WorkOrder | 冻结目标、源版本、路径、工具、期限和验收条件 |
| CapabilityGrant | 由有权主体签署，只能缩小或消费，不能扩权 |
| PolicyDecision | 在工具执行前作出允许或拒绝决定 |
| ActionReceipt | 绑定请求、授权决定、执行结果和证据摘要 |
| VerificationDecision | 由独立 Verifier 对冻结范围和证据作出判断 |
| AcceptanceDecision | 由 WorkOrder 绑定的 Acceptor 接受或拒绝交付 |
协议使用 Ed25519 签名、规范化 JSON、追加式账本和内容摘要。修改 WorkOrder、授权、
receipt、证据、公钥或因果父集，离线回放都会失败并关闭流程。
详细 Schema 位于 specs，当前实现与历史快照位于
docs/status.md。
六个角色，各自保留边界
| 角色 | 职责 |
|---|---|
| Maintainer | 初始化 WorkOrder，签发根授权 |
| Manager | 委派受限权限，发起工作与证明组合 |
| Developer | 在授权范围内读取、修改和运行测试 |
| Verifier | 使用独立密钥验证结果和证据 |
| Sidecar | 提供受信任的执行事实与 checkpoint |
| Acceptor | 独立签署接受、拒绝或权限 profile 变更 |
角色分离的目的不是增加组织层级，而是防止同一个 Agent 同时充当执行者、验证者和最终
验收者。系统可以自动化流程，但不能让权力边界在自动化中消失。
Human Agency：能力越强，人的决定权越不能消失
CapabilityGrant 表示系统允许 Agent 使用哪些能力。Human Agency Profile 表示人愿意
让 Agent 自主使用这些能力中的哪一部分。真正有效的权限取以下三者的交集：
Human Agency Profile 具有三个工程特征：
- **WorkOrder 绑定**：profile 不能被挪到另一项任务使用；
- **Acceptor 签名**：只有被指定的人类权威可以改变 active profile；
- **机器可验证**：执行前可以确定某个动作是 allowed、reserved 还是 denied。
reserved 动作不会先执行再提醒，而是在执行前返回
AGENCY_HUMAN_DECISION_REQUIRED。appeal 是签名复核请求，只记录异议，
不恢复或扩大权限。只有 Acceptor 签名的 transition 才能撤销当前 profile 或将其替换为另一个 Acceptor 签名的 profile。
完整定义见 Human Agency Profile v0.1，
可运行示例见 examples/human_agency_profile_v01.py。
验证与验收必须分开
VERIFIED 只说明 Verifier 按冻结范围和证据得出了验证结论。客户是否接受交付，必须由
WorkOrder 绑定的 Acceptor 独立决定。
OpenWorkProof 使用双签：Verifier 签署验证结果，Acceptor 再签署
AcceptanceDecisionBindingV01。该 binding 把 WorkOrder、Decision、
CompositionReport、验收请求和最终 receipt 精确连接起来。缺失 binding 时，系统拒绝
把两份彼此无关的有效签名拼成一次交付。
Acceptor 私钥不进入 AgentTeams 或 exporter。外部人工验收使用
prepare → sign → commit：
1. 系统生成不包含私钥的草稿；
2. 外部 Acceptor 独立签名；
3. 追加式事务提交签名对象；
4. 导出 Acceptance Bundle；
5. 第三方离线验证。
退出码是闭合的：ACCEPTED=0、REJECTED=2、operational=4。
AgentTeams 的外部人工验收入口使用 --acceptance-bundle DIRECTORY，只读取外部目录并
调用同一个 verifier，不生成密钥、receipt 或 binding。
REJECTED 是可验证终态，不是系统错误，也不能写成交付成功。