dengyier/OpenWorkProof

解决的问题

当 AI 代理声称完成任务时，通常无法独立证明谁授权了这项工作、代理具体做了什么、是否在约定范围内，以及谁最终接受或拒绝了结果。日志只显示系统输出，而不显示授权、执行和验收的链条。OpenWorkProof 通过将每个代理任务转化为可移植、签名的证据包来解决这个问题，任何第三方都可以在无需访问原始系统的情况下离线验证。

工作原理

OpenWorkProof 是一个开放协议层，可以嵌入到现有的代理、CI 流水线、MCP 服务器和多代理编排器中。它链式连接六种事实：工作订单（要求做什么）、签名授权（谁允许）、操作前策略决策（允许或拒绝）、操作收据（代理实际做了什么）、独立验证（证据是否支持结论）以及人工验收（谁最终接受或拒绝）。

核心对象是 WorkOrder、CapabilityGrant、PolicyDecision、ActionReceipt、VerificationDecision 和 AcceptanceDecision。每一步都使用 Ed25519 进行加密签名，账本采用追加写入并包含内容摘要。对订单、授权、收据、证据或公钥的任何修改都会导致离线重放失败并关闭工作流。

一个关键设计点是验证和验收严格分离。验证者签署验证决策，但只有指定的验收者才能签署单独的 AcceptanceDecisionBinding 来接受或拒绝交付。这防止系统声称通过的验证等同于客户同意。协议还强制执行人类保持控制的原则：Human Agency Profile 定义人类实际允许代理自主使用哪些已授予的能力。保留操作在执行前返回错误，请求人类决策。

适用对象

OpenWorkProof 适用于构建或部署 AI 代理并需要可信记录其行为和原因的团队。它也适用于希望将代理工作移交给外部客户或监管机构，并让他们独立验证授权、执行、验证和验收整个链条而不依赖平台自身数据库的组织。它适合任何使用 MCP、GitHub Actions、CLI 工具或 Python API 并希望为代理工作流添加可验证问责制的人。

亮点

• 为每个代理操作提供从授权到验收的完整签名证据链。
• 使用 Ed25519 签名和追加写入账本，任何更改都会破坏离线重放并关闭工作流。
• 通过双重签名机制将验证与验收分离，防止虚假的最终验收声明。
• 包含 Human Agency Profile，允许人类预先定义代理可以自主执行的操作，保留操作在执行前被阻止。
• 提供多种集成路径：GitHub Action、CLI、MCP 服务器、AgentTeams 编排、DeepSeek Harness 插件（本地候选）和 Python API。
• 支持 Surface 和 Acceptance 包的离线验证，允许第三方仅凭证据包和公钥进行审计。