OpenWorkProof

OpenWorkProof

让智能依人的目的而行动，让每一次行动经得起人的判断。

OpenWorkProof 是 AI Agent 工作契约与可验证执行协议。

它记录谁授权了任务、Agent 实际执行了什么、是否超出约定范围、验证者得出了什么结论， 以及验收者最终接受还是拒绝。每次工作都可以导出为一套签名证据包。第三方不需要接入 原系统，只凭证据包和公钥，就能独立验证整条工作链。

OpenWorkProof 不保证 Agent 的结果一定正确，也不替客户作出验收决定。它确保授权有来源、 执行有证据、验证与验收不会被混为一谈，并把接受、拒绝、撤销和申诉的权利留给人。

安装 · 工作原理 · OWP Guard 实验性保护 · Human Agency · DeepSeek Harness · 协议文档 · 社区记录 · English

MCPRush 动态信息卡片；点击查看评分依据与扫描范围。

Core 包版本: 1.5.0
DeepSeek Harness 插件候选: 0.1.0, 尚未发布 npm
core focused: 97 passed / 0 failed / 0 skipped
plugin: 80 passed / 0 failed / 0 skipped
candidate: 186 passed / 0 failed / 0 skipped
required-live: 4373 passed / 0 failed / 0 skipped
许可证: Apache-2.0

以上测试数字为 1.4.0 协议基线的既有验证记录。1.4.1 修复 MCP 启动入口兼容，1.4.2 补清工具说明；1.5.0 新增独立启用的实验性 Codex Guard。当前发行检查以 GitHub Actions 与发行说明为准。

公开发布状态请直接回读 PyPI、 GitHub Release 与 MCP Registry。 Core 1.5.0 包含 owp-guard 命令，并保留现有 MCP 启动与工具说明；公开发布状态以上述入口回读为准。DeepSeek Harness 插件 0.1.0 仍是本地候选，尚未发布 npm 或插件市场。两者是独立的发布事实。

社区贡献与外部记录

OpenWorkProof 与维护者 dengyier 的相关公开记录如下。 状态核对于 2026-10-26，后续变化以链接中的原始记录为准。

类别	可核查的成果与参与记录
社区目录收录	awesome-mcp-servers PR #11702 于 2026-08-29 由维护者合并；awesome-a2a 和 DeepSeek Harness 社区插件目录 当前也列有 OWP 条目。
外部研究	Judgment Pack 的 Study 014 以固定 OWP 提交 8eeca6f 为对象，公开研究判断与执行的绑定、离线重放及检测边界。研究与适配器由外部作者完成。
跨项目集成实验	AgentGuard 的 OWP 集成实验 PR #4 仍开放；其维护者提交的执行边界修复 PR #5 于 2026-09-11 合并到 integration/openworkproof-v1.4.0 集成分支。尚不表示已合入对方主分支或完成集成发布。
协议社区讨论	维护者参与 AutoGen GuardrailProvider 讨论，并发起 MCP 工作契约层讨论 #3215（已关闭），交流签名授权、执行回执与工具调用边界。
DEV 技术分享	维护者公开发表协议介绍、社区反馈复盘及可验证人类授权等文章，并与外部开发者讨论证据范围、时效和判断绑定。
公开发现与检查入口	Glama、MCPRush 和 VerifyMCP 均提供 OWP 页面；自动检查的评分、扫描版本与范围请查看各平台详情。

目录收录、技术讨论、集成实验与平台评分各有不同含义。Study 014 明确不是 OWP 安全审计或背书， 其研究范围为 39 个既定测试单元与 8 个留出测试单元，不能称为“通过 47 次攻击”。 上述记录不表示相关机构正式采纳、全面安全认证、客户生产部署或付费使用。

维护者的其他开源提案与待审收录申请

记录	当前状态
OpenClaw 通道诊断工具提案：PR #54244、较早的 PR #54231	均已关闭、未合并；记录维护者的社区参与，不列为已被上游采纳的贡献。
awesome-ai-sdks PR #316	已提交、仍开放，尚未合并收录。
awesome-ai-agents PR #5	已提交、仍开放，尚未合并收录。

OWP Guard：既存の Agent でプレビュー用ディレクトリを保護する（実験的）

ユーザーは Codex で引き続きタスクを依頼できます。OWP は、サポート対象のツールを実行する前に自動チェックを行い、指定したプレビュー用ディレクトリ内の通常ファイルの読み取り、追加、変更を許可し、範囲外へのアクセス、削除／移動、任意のコマンド、未サポートのツールを拒否します。 初版では、プロジェクト単位でのインストール、状態確認、明示的なアップグレード、アンインストール時の復元を提供し、POSIX のローカルテキスト編集に対応しています。

1.5.0 以降、パッケージには owp-guard が含まれます。MCP をインストールしても、保護は自動的に有効になりません。ホストが Hook を実際に読み込み、信頼する必要があります。これはコンピューター全体を隔離するものではなく、オンライン検索など、ホストが公開していない経路は保護対象外です。 インストール、検収、完全な境界については、統合ガイドをご覧ください。

初回利用時は、install → enable → doctor → run の順に実行して、プロジェクトへの導入、現在のバージョンの認可、実際のチェック、Codex タスクの実行を行えます。この入口では、純正の単一項目のセッション信頼を使用し、Hook の信頼チェックを回避したり、グローバル設定を変更したりすることはありません。詳しくは、初回の有効化と保護された起動をご覧ください。

Agent が「完了しました」と言っても、何が足りないのでしょうか

MCP は Agent とツールを接続し、A2A は Agent 同士を接続します。これらは接続と通信の方法を解決しますが、作業が認可されていたか、指示どおりに実行されたか、最終的に誰が検収したかを、それだけで証明することはできません。

AI サービスプロバイダーが、Agent に顧客のコードリポジトリを変更させる場面を想像してください。Agent はパッチを提出し、テストも通過したと言います。それでも顧客は、次のことを確認する必要があります。

1. 誰が Agent にこのリポジトリの変更を許可したのでしょうか？
2. 許可されたツール、パス、クォータ、期限だけを使用したのでしょうか？
3. パッチ、テスト、レポートは、同じ実行から得られたものでしょうか？
4. 検証に合格したことが、顧客がすでに受け入れたこととして誤って記録されていないでしょうか？
5. 争議が発生した場合、第三者は双方のシステムに接続せずに事実を再確認できるでしょうか？

ログからシステムが何を出力したかは分かりますが、認可、因果関係、最終検収を独立して証明するのは困難です。また、プラットフォームが自らのデータベースだけを使って、自らの信頼性を証明することもできません。

OpenWorkProof は、Agent の作業を、持ち運び、保存、再確認できる証拠チェーンにします。

客户冻结任务与验收条件
        ↓
有权主体签署授权
        ↓
Agent 执行，每个重要动作留下签名凭证
        ↓
Verifier 独立验证证据与因果链
        ↓
Acceptor 独立接受或拒绝
        ↓
第三方离线复核完整结果

OpenWorkProof は Agent をより賢くするものではありません。Agent の作業を、より安心して委任できるものにします。

OpenWorkProof とは

OpenWorkProof は、既存の Agent、CI、MCP、マルチ Agent オーケストレーターに組み込めるオープンなプロトコル層です。 次の 6 種類の事実をつなぎます。

事実	答える質問
作業の目的と範囲	Agent は何を完了するよう求められたのか
署名付き認可	誰がその作業を許可したのか
事前決定	このアクションを今実行してよいか
アクションレシート	Agent は実際に何をしたのか
独立検証	証拠は完全か、結論は妥当か
人による検収	誰が最終的に受け入れ、または拒否したのか

最終成果物は、元のプラットフォームでしか確認できないログではなく、オフラインで検証できる署名済み証拠パッケージです。証拠パッケージと公開鍵を持つ第三者は、認可の出所、実行範囲、証拠ダイジェスト、検証結果、検収結果を独立して再確認できます。

OpenWorkProof ではないもの

OpenWorkProof は Agent OS でも、新しいモデルやオーケストレーションフレームワークでもありません。Agent に代わってタスクを計画するものではなく、すべての業務上の結果が正しいと判断できると主張するものでもありません。

Human Agency Profile は認可の境界であり、従業員の評価、パフォーマンス監視、法的責任の転嫁、自動的な責任負担、資金の預託、コンプライアンス認証ではありません。

OpenWorkProof は資金を預からず、支払いを実行せず、法的仲裁に代わるものでもありません。プロトコルの状態は、証拠が特定の段階に達したことを証明できますが、外部の商取引上の事実を作り出すことはできません。

仕組み

完全な作業チェーンは、次のオブジェクトで構成されます。

WorkOrder -> CapabilityGrant -> PolicyDecision -> ActionReceipt
          -> VerificationDecision -> AcceptanceDecision

オブジェクト	役割
WorkOrder	目標、ソースバージョン、パス、ツール、期限、検収条件を固定します
CapabilityGrant	権限を持つ主体が署名し、範囲を縮小するか消費することだけができ、権限を拡大することはできません
PolicyDecision	ツールの実行前に、許可または拒否を決定します
ActionReceipt	リクエスト、認可決定、実行結果、証拠ダイジェストを結び付けます
VerificationDecision	独立した Verifier が、固定された範囲と証拠に基づいて判断します
AcceptanceDecision	WorkOrder に紐づく Acceptor が、成果物を受け入れるか拒否します

プロトコルでは、Ed25519 署名、正規化 JSON、追記専用台帳、コンテンツダイジェストを使用します。WorkOrder、認可、receipt、証拠、公開鍵、因果関係の親集合のいずれかを変更すると、オフラインでの再生に失敗し、プロセスが停止します。

詳細な Schema は specs に、現在の実装と過去のスナップショットは docs/status.md にあります。

6 つの役割、それぞれの境界を維持

役割	責務
Maintainer	WorkOrder を初期化し、ルート認可を発行します
Manager	制限付きの権限を委任し、作業と証明の構成を開始します
Developer	認可された範囲内で、読み取り、変更、テストの実行を行います
Verifier	独立した鍵を使用して、結果と証拠を検証します
Sidecar	信頼できる実行事実と checkpoint を提供します
Acceptor	受け入れ、拒否、権限 profile の変更を独立して署名します

役割を分離する目的は、組織階層を増やすことではなく、同じ Agent が実行者、検証者、最終検収者を兼ねるのを防ぐことです。システムはプロセスを自動化できますが、自動化によって権限の境界を消してはなりません。

Human Agency：能力が高まるほど、人の決定権を失わせてはなりません

CapabilityGrant は、システムが Agent にどの能力の使用を許可するかを示します。Human Agency Profile は、人がこれらの能力のうち、どの部分を Agent に自律的に使用させるかを示します。実際に有効な権限は、次の 3 つの共通部分です。

WorkOrder 允许的范围
∩ CapabilityGrant 授予的能力
∩ active HumanAgencyProfile 中人的选择

Human Agency Profile には、次の 3 つのエンジニアリング上の特性があります。

• WorkOrder との紐付け：profile を別のタスクに転用することはできません。
• Acceptor による署名：指定された人間の権限者だけが、active profile を変更できます。
• 機械検証が可能：実行前に、アクションが allowed、reserved、denied のどれに該当するかを判断できます。

reserved アクションは実行後に警告するのではなく、実行前に AGENCY_HUMAN_DECISION_REQUIRED を返します。appeal は署名付きの再審査リクエストであり、異議を記録するだけで、権限を復元したり拡大したりすることはありません。現在の profile を取り消したり、別の Acceptor が署名した profile に置き換えたりできるのは、Acceptor が署名した transition だけです。

完全な定義は 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 がない場合、システムは互いに無関係な 2 つの有効な署名を組み合わせて、1 回の納品として扱うことを拒否します。

Acceptor の秘密鍵は AgentTeams や exporter に渡されません。外部による人手での検収は、 prepare → sign → commit の手順で行います。

1. システムが秘密鍵を含まないドラフトを生成します。
2. 外部の Acceptor が独立して署名します。
3. 追記専用トランザクションで署名オブジェクトをコミットします。
4. Acceptance Bundle をエクスポートします。
5. 第三者がオフラインで検証します。

owp acceptance-bundle-build LEDGER SURFACE \
  --evidence-root PATH --output DIRECTORY

owp acceptance-bundle-verify DIRECTORY

終了コードは明確に定義されています：ACCEPTED=0、REJECTED=2、operational=4。 AgentTeams の外部人手検収の入口では --acceptance-bundle DIRECTORY を使用し、外部ディレクトリだけを読み取り、同じ verifier を呼び出します。鍵、receipt、binding は生成しません。

VERIFIED != ACCEPTED != PAID/SETTLED/LEGAL AUDIT/ADOPTION

REJECTED は検証可能な終端状態であり、システムエラーではありません。また、納品成功として記録することもできません。

验证完整性：验证结果本身也要经得起检查

“测试通过”不等于“该验证可信”。如果测试选择器漏掉了本应检查的对象，或者负向控制虽然 失败、却不是按预期原因失败，结论仍然不应进入 VERIFIED。

Verification Integrity v0.5 会冻结合格对象集合和负向控制的预期失败特征：

• POPULATION_CAPTURE_FAILED：实际选择没有覆盖约定的合格对象，结论关闭为 UNKNOWN；
• CONTROL_FAILURE_SIGNATURE_MISMATCH：负向控制的失败原因与登记特征不符，不能把这次失败当作有效证明；
• 只有人口覆盖和控制证据都成立时，系统才会根据证据给出 VERIFIED、REFUTED 或 UNKNOWN。

这套机制证明“结论由约定范围内的证据支持”，不证明业务结果永远正确。客户采用、付款、 法律效力和上游采纳仍是独立外部事实；没有相应证据时，状态就是 not evidenced。

五分钟开始

1. 从公开包安装

MCP 客户端推荐使用 uvx --from openworkproof owp-mcp。从 1.4.1 起， 目录常用的 uvx openworkproof 也启动同一个 MCP 服务。已有缓存可先运行 uvx --refresh openworkproof。完整配置见 MCP_SERVER.md。

公开 PyPI 页面当前状态应以页面回读为准：

python -m pip install openworkproof
owp --help

2. 从源码开发

需要修改协议或接入适配器时，可以从源码安装当前 main：

git clone https://github.com/dengyier/OpenWorkProof.git
cd OpenWorkProof
python -m venv .venv
source .venv/bin/activate
python -m pip install -e .
owp --help

3. 运行 Human Agency 最小示例

python examples/human_agency_profile_v01.py

预期输出包含：

profile verified  : True
resolved status   : active
owp.repo_read     : delegated -> allowed
owp.apply_patch   : reserved -> AGENCY_HUMAN_DECISION_REQUIRED

该示例不写应用层文件或账本，也不输出私钥。

4. 验证离线包

已有 Surface Bundle 时：

owp surface-verify PATH

已有 Acceptance Bundle 时：

owp acceptance-bundle-verify DIRECTORY

完整离线验证说明见 docs/offline-verification.md。

接入方式

入口	适合谁	从哪里开始
GitHub Action	已有 PR 交付流程的团队	integrations/github/action.yml
CLI	本地验证、CI 和自动化脚本	owp --help
MCP	需要把 OWP 暴露为 Agent 工具的团队	MCP_SERVER.md
AgentTeams	Manager、Developer、Verifier 多角色协作	agentteams/README.md
DeepSeek Harness	需要事前授权、独立复核与外部验收的代码变更	集成说明
Python API	需要嵌入已有平台或服务	src/openworkproof

GitHub Action 的 four-question 对应中文四问报告：

1. 验证了什么主张；
2. 看到了什么证据；
3. 执行受到什么约束；
4. 现在可以得出什么结论。

报告结论是 VERIFIED、REFUTED 或 UNKNOWN，并说明是否只达到 READY_FOR_ACCEPTANCE。它不会把协议结论写成客户已经接受或已经付款。

DeepSeek Harness 适配器当前是外部发布 READY 的本地候选，锁定 DeepSeek Harness 0.1.1-rc.2。Audit 只记录观察事实；Enforce 在工具执行前授权，并阻断 原生 write、edit、bash、pwsh、str_replace_editor、cordis_define 与 cordis_run、cordis_stop、cordis_undefine 修改面。安装后的 bundle 默认关闭并视为 NOT_CONFIGURED；只有显式启用并提供私有 case 后才会记录 Audit 证据。/owp-verify 只消费因果关联后的精确补丁 回执；真实 CLI 进程已完成账本回读、独立验证、无私钥验收草稿与离线导出，并在进程重启 后恢复同一已提交 receipt。上述本地预检不等于 npm 发布、外部复现、客户采用或 DeepSeek 官方背书。

宿主版本从实际执行文件解析，包含全局安装常见的符号链接路径；read、glob、grep、 web_search 四类只读工具也进入闭合 observation 协议并由真实宿主预检覆盖，不会因正常 只读调用使证据 bridge 退出。

当前可以复核的证据

以下是本地候选的工程证据，不是客户采用证明：

验证门	当前结果
core focused	97 passed / 0 failed / 0 skipped
plugin	80 passed / 0 failed / 0 skipped
candidate	186 passed / 0 failed / 0 skipped
required-live	4373 passed / 0 failed / 0 skipped
AgentTeams	Manager、Developer、Verifier 三角色 live preflight 已通过（http://127.0.0.1:18080）
离线验证	Surface、Acceptance 与 Human Agency bundle 可独立回放
供应链	candidate inventory、OCI/Docker 工件和哈希绑定已过门

required-live 全量门在 OPENWORKPROOF_AGENTTEAMS_REQUIRED=1 与 AGENTTEAMS_HOMESERVER=http://127.0.0.1:18080 下以 0 failed / 0 skipped 通过； AGENTTEAMS_MATRIX_TOKEN 仅从本机 agentteams-manager 容器只读取得，不打印、不落盘。

Rich #4196、Dify #33013 和 AgentScope #2239 是自有演示与复现实验，用于验证不同项目 类型下的协议路径。它们不是客户案例，也不代表上游项目已经采用 OpenWorkProof。

agentteams_live_environment: evidenced
agentteams_three_role_preflight: evidenced
agentteams_end_to_end_business_execution: not_evidenced
human_acceptance: not_evidenced
customer_adoption: not_evidenced
paid_sow: not_evidenced
deposit: not_evidenced
upstream_adoption: not_evidenced

Verified Agent Delivery

OpenWorkProof Verified Agent Delivery 是协议之上的首个应用切片。它把一次 Agent 工作 组织成可独立验证、可由客户验收的交付事实。

owp delivery-case init CASE_DIR
owp delivery-case inspect CASE_DIR
owp delivery-case verify CASE_DIR
owp delivery-case export CASE_DIR --output-directory OUTPUT_DIR

inspect 从真实 Surface、Acceptance 和 Settlement 证据重新派生状态，不信任磁盘中 预写的结论。export 生成带确定性摘要和完整性 manifest 的第三方复核包。

READY_FOR_SETTLEMENT_REVIEW 只表示证据已经可以交给外部付款方复核，不表示付款或 结算已经发生。BOUND 表示协议对象已经形成确定绑定，也不表示付款、客户采用或法律 认可。

商业材料与准入边界见 docs/commercial/verified-agent-delivery。

开放协议与长期方向

OpenWorkProof 当前先解决一件小而具体的事：让一次 Agent 工作可以被独立验证和验收。 当不同组织之间积累了足够多可携带的履约事实，才可能进一步支持 Agent 服务的比较、 交易、争议处理和结算。

单次工作可验证
        ↓
跨组织交付可验收
        ↓
履约事实可携带
        ↓
Agent 服务可以被比较、交易和结算

最后一步是长期方向，不是当前能力。OpenWorkProof 当前不建设商城、钱包、支付通道、 资金托管、保险、公证或法定仲裁。

下一阶段重点：

• 让更多 Agent 框架和编排器复现协议；
• 完善 Human Agency 的权限 profile、transition 与 appeal 生态；
• 增加跨组织真实执行和外部 Acceptor 复现；
• 用公开、可复核的事实推进协议互操作，而不是用平台锁定换取采用。

参与项目

你可以从以下任何一步开始：

• 运行最小示例并报告无法复现的地方；
• 把协议接入一个现有 Agent、CI 或 MCP 工具；
• 审阅 Schema、威胁模型和真值边界；
• 提交适配器、测试或文档；
• 带着一个真实但可脱敏的 Agent 交付问题参与讨论。

贡献说明见 CONTRIBUTING.md。安全问题请使用 GitHub Security Advisories 私下报告。项目使用 Apache-2.0 许可证。

为什么继续做这件事

能力回答 Agent 能做什么，工作契约回答它为什么被允许这样做，证据让行动接受复核。 机器可以执行验证规则，但最终接受、拒绝和承担后果的判断仍然属于人。

我们希望未来的 Agent 可以承担越来越多的工作。能力越强，越应该忠于人明确表达的目的； 系统越自动，授权、证据和申诉越不能消失。

OpenWorkProof 想做的事情很朴素：当人把工作交给 AI，仍然知道自己交出了什么、发生了 什么，以及何时可以说不。

让智能依人的目的而行动，让每一次行动经得起人的最终判断。