{
  "markdown": "# OpenWorkProof\n\n<!-- mcp-name: io.github.dengyier/OpenWorkProof -->\n\n<div align=\"center\">\n  <strong>中文</strong> | <a href=\"README_en.md\">English</a>\n</div>\n\n> 让智能依人的目的而行动，让每一次行动经得起人的判断。\n\nOpenWorkProof 是 AI Agent 工作契约与可验证执行协议。\n\n它记录谁授权了任务、Agent 实际执行了什么、是否超出约定范围、验证者得出了什么结论，\n以及验收者最终接受还是拒绝。每次工作都可以导出为一套签名证据包。第三方不需要接入\n原系统，只凭证据包和公钥，就能独立验证整条工作链。\n\nOpenWorkProof 不保证 Agent 的结果一定正确，也不替客户作出验收决定。它确保授权有来源、\n执行有证据、验证与验收不会被混为一谈，并把接受、拒绝、撤销和申诉的权利留给人。\n\n[安装](#五分钟开始) · [工作原理](#工作原理) ·\n[Human Agency](#human-agency能力越强人的决定权越不能消失) ·\n[DeepSeek Harness](docs/integrations/deepseek-harness.md) ·\n[协议文档](docs/protocol/human-agency-profile-v0.1.md) ·\n[English](README_en.md)\n\n```text\nCore 公开版本: 1.4.0\nDeepSeek Harness 插件候选: 0.1.0, 尚未发布 npm\ncore focused: 97 passed / 0 failed / 0 skipped\nplugin: 80 passed / 0 failed / 0 skipped\ncandidate: 186 passed / 0 failed / 0 skipped\nrequired-live: 4373 passed / 0 failed / 0 skipped\n许可证: Apache-2.0\n```\n\n公开发布状态请直接回读 [PyPI](https://pypi.org/project/openworkproof/)、\n[GitHub Release](https://github.com/dengyier/OpenWorkProof/releases/tag/v1.4.0) 与\n[MCP Registry](https://registry.modelcontextprotocol.io/v0.1/servers/io.github.dengyier%2FOpenWorkProof/versions/1.4.0)。\nCore `1.4.0` 已发布到 PyPI、GitHub Release 与 MCP Registry；DeepSeek Harness 插件\n`0.1.0` 仍是本地候选，尚未发布 npm 或插件市场。两者是独立的发布事实。\n\n## Agent 说 `完成了`，还缺什么\n\nMCP 连接 Agent 与工具，A2A 连接 Agent 与 Agent。它们解决如何连接和通信，不能单独\n证明一次工作是否获得授权、是否按约执行，以及最终由谁验收。\n\n设想一家 AI 服务商让 Agent 修改客户的代码仓库。Agent 提交了补丁，也说测试已经通过。\n客户仍然需要回答：\n\n1. 谁授权 Agent 修改这个仓库？\n2. 它是否只使用了允许的工具、路径、配额和期限？\n3. 补丁、测试和报告是否来自同一次执行？\n4. 验证通过是否被错误地写成客户已经接受？\n5. 发生争议时，第三方能否在不接入双方系统的情况下复核事实？\n\n日志能告诉人系统输出了什么，却很难独立证明授权、因果关系和最终验收。平台也不能只用\n自己的数据库证明自己可信。\n\nOpenWorkProof 把一次 Agent 工作变成一条可以带走、保存和复核的证据链：\n\n```text\n客户冻结任务与验收条件\n        ↓\n有权主体签署授权\n        ↓\nAgent 执行，每个重要动作留下签名凭证\n        ↓\nVerifier 独立验证证据与因果链\n        ↓\nAcceptor 独立接受或拒绝\n        ↓\n第三方离线复核完整结果\n```\n\nOpenWorkProof 不让 Agent 变得更聪明。它让 Agent 的工作更值得委托。\n\n## OpenWorkProof 是什么\n\nOpenWorkProof 是可以嵌入现有 Agent、CI、MCP 和多 Agent 编排器的开放协议层。\n它把六类事实连接起来：\n\n| 事实 | 回答的问题 |\n|---|---|\n| 工作目的与范围 | Agent 被要求完成什么 |\n| 签名授权 | 谁允许它做这件事 |\n| 事前决策 | 这个动作现在是否可以执行 |\n| 行动凭证 | Agent 实际做了什么 |\n| 独立验证 | 证据是否完整，结论是否成立 |\n| 人工验收 | 谁最终接受或拒绝 |\n\n最终交付的不是一份只能在原平台查看的日志，而是一套可离线验证的签名证据包。持有证据包\n和公钥的第三方，可以独立复核授权来源、执行范围、证据摘要、验证结论和验收结果。\n\n### 它不是什么\n\nOpenWorkProof 不是 Agent OS，也不是新的模型或编排框架。它不负责替 Agent 规划任务，\n也不声称能够判断所有业务结果是否正确。\n\nHuman Agency Profile 是授权边界，不是员工评分、绩效监控、法律责任转移、自动担责、资金托管或合规认证。\n\nOpenWorkProof 也不托管资金，不执行付款，不代替法律仲裁。协议状态可以证明证据达到某个\n阶段，但不能制造外部商业事实。\n\n## 工作原理\n\n一条完整工作链由以下对象组成：\n\n```text\nWorkOrder -> CapabilityGrant -> PolicyDecision -> ActionReceipt\n          -> VerificationDecision -> AcceptanceDecision\n```\n\n| 对象 | 作用 |\n|---|---|\n| `WorkOrder` | 冻结目标、源版本、路径、工具、期限和验收条件 |\n| `CapabilityGrant` | 由有权主体签署，只能缩小或消费，不能扩权 |\n| `PolicyDecision` | 在工具执行前作出允许或拒绝决定 |\n| `ActionReceipt` | 绑定请求、授权决定、执行结果和证据摘要 |\n| `VerificationDecision` | 由独立 Verifier 对冻结范围和证据作出判断 |\n| `AcceptanceDecision` | 由 WorkOrder 绑定的 Acceptor 接受或拒绝交付 |\n\n协议使用 Ed25519 签名、规范化 JSON、追加式账本和内容摘要。修改 WorkOrder、授权、\nreceipt、证据、公钥或因果父集，离线回放都会失败并关闭流程。\n\n详细 Schema 位于 [specs](specs/)，当前实现与历史快照位于\n[docs/status.md](docs/status.md)。\n\n## 六个角色，各自保留边界\n\n| 角色 | 职责 |\n|---|---|\n| Maintainer | 初始化 WorkOrder，签发根授权 |\n| Manager | 委派受限权限，发起工作与证明组合 |\n| Developer | 在授权范围内读取、修改和运行测试 |\n| Verifier | 使用独立密钥验证结果和证据 |\n| Sidecar | 提供受信任的执行事实与 checkpoint |\n| Acceptor | 独立签署接受、拒绝或权限 profile 变更 |\n\n角色分离的目的不是增加组织层级，而是防止同一个 Agent 同时充当执行者、验证者和最终\n验收者。系统可以自动化流程，但不能让权力边界在自动化中消失。\n\n## Human Agency：能力越强，人的决定权越不能消失\n\n`CapabilityGrant` 表示系统允许 Agent 使用哪些能力。`Human Agency Profile` 表示人愿意\n让 Agent 自主使用这些能力中的哪一部分。真正有效的权限取以下三者的交集：\n\n```text\nWorkOrder 允许的范围\n∩ CapabilityGrant 授予的能力\n∩ active HumanAgencyProfile 中人的选择\n```\n\nHuman Agency Profile 具有三个工程特征：\n\n- **WorkOrder 绑定**：profile 不能被挪到另一项任务使用；\n- **Acceptor 签名**：只有被指定的人类权威可以改变 active profile；\n- **机器可验证**：执行前可以确定某个动作是 allowed、reserved 还是 denied。\n\n`reserved` 动作不会先执行再提醒，而是在执行前返回\n`AGENCY_HUMAN_DECISION_REQUIRED`。appeal 是签名复核请求，只记录异议，\n不恢复或扩大权限。只有 Acceptor 签名的 transition 才能撤销当前 profile 或将其替换为另一个 Acceptor 签名的 profile。\n\n完整定义见 [Human Agency Profile v0.1](docs/protocol/human-agency-profile-v0.1.md)，\n可运行示例见 [examples/human_agency_profile_v01.py](examples/human_agency_profile_v01.py)。\n\n## 验证与验收必须分开\n\n`VERIFIED` 只说明 Verifier 按冻结范围和证据得出了验证结论。客户是否接受交付，必须由\nWorkOrder 绑定的 Acceptor 独立决定。\n\nOpenWorkProof 使用双签：Verifier 签署验证结果，Acceptor 再签署\n`AcceptanceDecisionBindingV01`。该 binding 把 WorkOrder、Decision、\nCompositionReport、验收请求和最终 receipt 精确连接起来。缺失 binding 时，系统拒绝\n把两份彼此无关的有效签名拼成一次交付。\n\nAcceptor 私钥不进入 AgentTeams 或 exporter。外部人工验收使用\n`prepare → sign → commit`：\n\n1. 系统生成不包含私钥的草稿；\n2. 外部 Acceptor 独立签名；\n3. 追加式事务提交签名对象；\n4. 导出 Acceptance Bundle；\n5. 第三方离线验证。\n\n```bash\nowp acceptance-bundle-build LEDGER SURFACE \\\n  --evidence-root PATH --output DIRECTORY\n\nowp acceptance-bundle-verify DIRECTORY\n```\n\n退出码是闭合的：`ACCEPTED=0`、`REJECTED=2`、`operational=4`。\nAgentTeams 的外部人工验收入口使用 `--acceptance-bundle DIRECTORY`，只读取外部目录并\n调用同一个 verifier，不生成密钥、receipt 或 binding。\n\n```text\nVERIFIED != ACCEPTED != PAID/SETTLED/LEGAL AUDIT/ADOPTION\n```\n\n`REJECTED` 是可验证终态，不是系统错误，也不能写成交付成功。\n\n## 验证完整性：验证结果本身也要经得起检查\n\n“测试通过”不等于“该验证可信”。如果测试选择器漏掉了本应检查的对象，或者负向控制虽然\n失败、却不是按预期原因失败，结论仍然不应进入 `VERIFIED`。\n\nVerification Integrity v0.5 会冻结合格对象集合和负向控制的预期失败特征：\n\n- `POPULATION_CAPTURE_FAILED`：实际选择没有覆盖约定的合格对象，结论关闭为 `UNKNOWN`；\n- `CONTROL_FAILURE_SIGNATURE_MISMATCH`：负向控制的失败原因与登记特征不符，不能把这次失败当作有效证明；\n- 只有人口覆盖和控制证据都成立时，系统才会根据证据给出 `VERIFIED`、`REFUTED` 或 `UNKNOWN`。\n\n这套机制证明“结论由约定范围内的证据支持”，不证明业务结果永远正确。客户采用、付款、\n法律效力和上游采纳仍是独立外部事实；没有相应证据时，状态就是 `not evidenced`。\n\n## 五分钟开始\n\n### 1. 从公开包安装\n\n公开 PyPI 页面当前状态应以页面回读为准：\n\n```bash\npython -m pip install openworkproof\nowp --help\n```\n\n### 2. 从源码开发\n\n需要修改协议或接入适配器时，可以从源码安装当前 `main`：\n\n```bash\ngit clone https://github.com/dengyier/OpenWorkProof.git\ncd OpenWorkProof\npython -m venv .venv\nsource .venv/bin/activate\npython -m pip install -e .\nowp --help\n```\n\n### 3. 运行 Human Agency 最小示例\n\n```bash\npython examples/human_agency_profile_v01.py\n```\n\n预期输出包含：\n\n```text\nprofile verified  : True\nresolved status   : active\nowp.repo_read     : delegated -> allowed\nowp.apply_patch   : reserved -> AGENCY_HUMAN_DECISION_REQUIRED\n```\n\n该示例不写应用层文件或账本，也不输出私钥。\n\n### 4. 验证离线包\n\n已有 Surface Bundle 时：\n\n```bash\nowp surface-verify PATH\n```\n\n已有 Acceptance Bundle 时：\n\n```bash\nowp acceptance-bundle-verify DIRECTORY\n```\n\n完整离线验证说明见 [docs/offline-verification.md](docs/offline-verification.md)。\n\n## 接入方式\n\n| 入口 | 适合谁 | 从哪里开始 |\n|---|---|---|\n| GitHub Action | 已有 PR 交付流程的团队 | [integrations/github/action.yml](integrations/github/action.yml) |\n| CLI | 本地验证、CI 和自动化脚本 | `owp --help` |\n| MCP | 需要把 OWP 暴露为 Agent 工具的团队 | [MCP_SERVER.md](MCP_SERVER.md) |\n| AgentTeams | Manager、Developer、Verifier 多角色协作 | [agentteams/README.md](agentteams/README.md) |\n| DeepSeek Harness | 需要事前授权、独立复核与外部验收的代码变更 | [集成说明](docs/integrations/deepseek-harness.md) |\n| Python API | 需要嵌入已有平台或服务 | [src/openworkproof](src/openworkproof/) |\n\nGitHub Action 的 four-question 对应中文四问报告：\n\n1. 验证了什么主张；\n2. 看到了什么证据；\n3. 执行受到什么约束；\n4. 现在可以得出什么结论。\n\n报告结论是 `VERIFIED`、`REFUTED` 或 `UNKNOWN`，并说明是否只达到\n`READY_FOR_ACCEPTANCE`。它不会把协议结论写成客户已经接受或已经付款。\n\nDeepSeek Harness 适配器当前是外部发布 READY 的本地候选，锁定\n`DeepSeek Harness 0.1.1-rc.2`。Audit 只记录观察事实；Enforce 在工具执行前授权，并阻断\n原生 `write`、`edit`、`bash`、`pwsh`、`str_replace_editor`、`cordis_define` 与\n`cordis_run`、`cordis_stop`、`cordis_undefine` 修改面。安装后的 bundle 默认关闭并视为\n`NOT_CONFIGURED`；只有显式启用并提供私有 case 后才会记录 Audit 证据。`/owp-verify` 只消费因果关联后的精确补丁\n回执；真实 CLI 进程已完成账本回读、独立验证、无私钥验收草稿与离线导出，并在进程重启\n后恢复同一已提交 receipt。上述本地预检不等于 npm 发布、外部复现、客户采用或\nDeepSeek 官方背书。\n\n宿主版本从实际执行文件解析，包含全局安装常见的符号链接路径；`read`、`glob`、`grep`、\n`web_search` 四类只读工具也进入闭合 observation 协议并由真实宿主预检覆盖，不会因正常\n只读调用使证据 bridge 退出。\n\n## 当前可以复核的证据\n\n以下是本地候选的工程证据，不是客户采用证明：\n\n| 验证门 | 当前结果 |\n|---|---|\n| core focused | `97 passed / 0 failed / 0 skipped` |\n| plugin | `80 passed / 0 failed / 0 skipped` |\n| candidate | `186 passed / 0 failed / 0 skipped` |\n| required-live | `4373 passed / 0 failed / 0 skipped` |\n| AgentTeams | Manager、Developer、Verifier 三角色 live preflight 已通过（`http://127.0.0.1:18080`） |\n| 离线验证 | Surface、Acceptance 与 Human Agency bundle 可独立回放 |\n| 供应链 | candidate inventory、OCI/Docker 工件和哈希绑定已过门 |\n\nrequired-live 全量门在 `OPENWORKPROOF_AGENTTEAMS_REQUIRED=1` 与\n`AGENTTEAMS_HOMESERVER=http://127.0.0.1:18080` 下以 `0 failed / 0 skipped` 通过；\n`AGENTTEAMS_MATRIX_TOKEN` 仅从本机 `agentteams-manager` 容器只读取得，不打印、不落盘。\n\nRich #4196、Dify #33013 和 AgentScope #2239 是自有演示与复现实验，用于验证不同项目\n类型下的协议路径。它们不是客户案例，也不代表上游项目已经采用 OpenWorkProof。\n\n```text\nagentteams_live_environment: evidenced\nagentteams_three_role_preflight: evidenced\nagentteams_end_to_end_business_execution: not_evidenced\nhuman_acceptance: not_evidenced\ncustomer_adoption: not_evidenced\npaid_sow: not_evidenced\ndeposit: not_evidenced\nupstream_adoption: not_evidenced\n```\n\n## Verified Agent Delivery\n\n`OpenWorkProof Verified Agent Delivery` 是协议之上的首个应用切片。它把一次 Agent 工作\n组织成可独立验证、可由客户验收的交付事实。\n\n```bash\nowp delivery-case init CASE_DIR\nowp delivery-case inspect CASE_DIR\nowp delivery-case verify CASE_DIR\nowp delivery-case export CASE_DIR --output-directory OUTPUT_DIR\n```\n\n`inspect` 从真实 Surface、Acceptance 和 Settlement 证据重新派生状态，不信任磁盘中\n预写的结论。`export` 生成带确定性摘要和完整性 manifest 的第三方复核包。\n\n`READY_FOR_SETTLEMENT_REVIEW` 只表示证据已经可以交给外部付款方复核，不表示付款或\n结算已经发生。`BOUND` 表示协议对象已经形成确定绑定，也不表示付款、客户采用或法律\n认可。\n\n商业材料与准入边界见\n[docs/commercial/verified-agent-delivery](docs/commercial/verified-agent-delivery/)。\n\n## 开放协议与长期方向\n\nOpenWorkProof 当前先解决一件小而具体的事：让一次 Agent 工作可以被独立验证和验收。\n当不同组织之间积累了足够多可携带的履约事实，才可能进一步支持 Agent 服务的比较、\n交易、争议处理和结算。\n\n```text\n单次工作可验证\n        ↓\n跨组织交付可验收\n        ↓\n履约事实可携带\n        ↓\nAgent 服务可以被比较、交易和结算\n```\n\n最后一步是长期方向，不是当前能力。OpenWorkProof 当前不建设商城、钱包、支付通道、\n资金托管、保险、公证或法定仲裁。\n\n下一阶段重点：\n\n- 让更多 Agent 框架和编排器复现协议；\n- 完善 Human Agency 的权限 profile、transition 与 appeal 生态；\n- 增加跨组织真实执行和外部 Acceptor 复现；\n- 用公开、可复核的事实推进协议互操作，而不是用平台锁定换取采用。\n\n## 参与项目\n\n你可以从以下任何一步开始：\n\n- 运行最小示例并报告无法复现的地方；\n- 把协议接入一个现有 Agent、CI 或 MCP 工具；\n- 审阅 Schema、威胁模型和真值边界；\n- 提交适配器、测试或文档；\n- 带着一个真实但可脱敏的 Agent 交付问题参与讨论。\n\n贡献说明见 [CONTRIBUTING.md](CONTRIBUTING.md)。安全问题请使用\n[GitHub Security Advisories](https://github.com/dengyier/OpenWorkProof/security/advisories/new)\n私下报告。项目使用 [Apache-2.0](LICENSE) 许可证。\n\n## 为什么继续做这件事\n\n能力回答 Agent 能做什么，工作契约回答它为什么被允许这样做，证据让行动接受复核。\n机器可以执行验证规则，但最终接受、拒绝和承担后果的判断仍然属于人。\n\n我们希望未来的 Agent 可以承担越来越多的工作。能力越强，越应该忠于人明确表达的目的；\n系统越自动，授权、证据和申诉越不能消失。\n\nOpenWorkProof 想做的事情很朴素：当人把工作交给 AI，仍然知道自己交出了什么、发生了\n什么，以及何时可以说不。\n\n**让智能依人的目的而行动，让每一次行动经得起人的最终判断。**\n",
  "bytes": 10264,
  "sha": "b4c6838200832e679dcccdc608b8b89f768a186e523202d16d04ada040e6127b",
  "repo_slug": "dengyier/openworkproof",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/mcp_io_github_dengyier_openworkproof_e5d767ad/readme"
}