9.0
重磅
AI SCORE
编程提效2026-08-08 20:39
AI Agent提交代码的生产级验证协议设计
dev.to · AI#AI Agent#代码审查#工程实践
Editor brief · 编辑速览
提出三个核心问题：操作授权验证、补丁到测试结果的因果链追溯、谁为最终结果负责；建议每个工具调用携带机器可验证的证明。
上个月我合并了一个 AI agent 写的 bug 修复。看起来没问题。agent 说测试通过了。我部署了它。
两小时后，生产环境炸了。
不是因为 agent 错了——而是我从来没验证过任何东西。我只是信任了它。
问题不在于"agent 能不能做事"，而在于"agent 能否证明它做了什么"。
如今每一个多 agent 框架都在解决同一个问题：让 agent 互相通信。
MCP 把 agent 连接到工具。A2A 把 agent 连接到 agent。LangChain、CrewAI、AutoGen 编排着这场舞蹈。工具链非常强大。
但没人解决的是：当 agent #2 说"我审查了这个补丁"或"测试通过了"时，没有任何协议层面的方式来验证这个声明。
Agent #3 只能选择信任 agent #2。中间件只能选择信任两者。你——这个 human——也只能选择信任这条流水线。
这在演示里行得通。在生产环境里不行。
当我开始深挖这个问题时，我一直在回到三个问题：
一个 agent 不应该能够自行决定执行 rm -rf 或推送到生产环境。每一个工具调用都应该携带机器可验证的证明：证明某个特定角色说了"可以"，在什么范围内，在什么配额内。
如果一个 agent 说"我测试了补丁并且通过了"，你应该能够反向追溯：测试运行 → 它测试的补丁 → 应用该补丁的授权 → 启动这一切的工作单。没有缺口。没有"我发誓，真的过了。"
这是终极测试。如果验证一个 agent 的工作需要登录到 agent 的机器、读取它的日志、并信任它的中间件，那你其实没有真正验证任何东西——你只是把信任搬了个家。
一个真正的验证协议应该允许独立方离线回放整条证据链，只需要证据包和公钥。
OpenWorkProof 是一个协议层（不是框架），位于 agent 和它们的工具之间。它不替代 MCP 或 A2A——它在连接性之上增加了问责机制。
以下是每一次工具调用的处理流程：
在 agent 接触任何工具之前，会签署一个 PolicyDecision：
from openworkproof import policy
auth_ctx = policy.derive_authorization_context(
work_order=work_order,
grants=grants,
receipts=receipts,
request=signed_request,
arguments=args,
execution_facts=facts,
checkpoint=checkpoint,
)
decision = policy.authorize_tool_call(auth_ctx)
# decision.allowed == False → deny receipt, don't execute
每个决策都绑定了：谁授权的（角色 + Ed25519 公钥）、授权了什么工具、在什么范围和配额内、以及授权窗口何时过期。
如果 agent 没有被授权？工具调用永远不会发生。就这么简单。
一旦工具运行，它会产生一个 ActionReceipt，链回到授权：
你不能跳过步骤。你不能捏造历史。因果图强制要求精确的父集——如果步骤 5 声称步骤 3 是它的父节点，但步骤 3 根本没发生，验证会在协议层面失败。
这是我最引以为豪的部分。任何第三方都可以零信任地回放整条链：
from openworkproof.acceptance import verify_acceptance_bundle
result = verify_acceptance_bundle(
work_order=work_order,
report=report,
effective_grants=grants,
receipts=receipts,
committed_evidence=evidence,
acceptance_receipt=signed,
public_keys=keys,
)
# Pure function. Zero I/O. Deterministic.
不需要数据库连接。不需要访问 agent 的机器。不需要信任任何参与者。只需要证据包和公钥。如果链内部一致，就通过。如果不一致，就失败——并准确告诉你哪里出了问题。
我在意识到"agent"这个词对问责来说太模糊之后，最终确定了六个角色：
| 角色 | 说明 |
|---|---|
| Maintainer | 最高权限持有者，签发顶级 Grant |
| Manager | 管理一个工作单元，签发子 Grant |
| Developer | 执行具体开发任务 |
| Reviewer | 审查代码和证据 |
| Tester | 运行测试并生成报告 |
| Sidecar | 提供外部验证和checkpoint |
关键约束：grants 只能衰减。当从 Maintainer → Manager → Developer 委托时，权限只能缩小，不能扩大。子 grant 不能授予比父 grant 更多的访问权。这是不克隆权限原则——它在协议层面防止了权限提升。
状态机流程：running → locally_verified → proof_ready → awaiting_human → accepted
我没有用玩具例子测试这个。我用它测试了两个真实的开源 issue：
Bug 1: Rich #4196 — 终端格式化
Rich 是一个流行的 Python 终端格式化库（50k+ stars）。Bug #4196 是一个渲染边缘 case。我构建了一条完整的 9 步证据链：
WorkOrder → Grant issuance → PolicyDecision → repo_read → apply_patch → run_tests → evidence publication → acceptance bundle → offline verification
每一步都签名。每一步都可追溯。第三方验证器确认了这条链，没有接触任何在线系统。
Bug 2: Dify #33013 — LLM 应用平台
完全不同的项目类型——Dify 的 QuestionClassifierNode 中的一个 TypeError。同样的协议无需修改就能工作。这证明了协议没有耦合到某一种代码库、某一种 bug、或某一种测试套件。
2,283 个测试。0 失败。Apache-2.0。
这是一个协议，不是一个产品。以下是它目前还不做的事：
协议核心是扎实的。实现证明了这一点。表面面积是有限的——在这个阶段是有意为之的。
AI agent 基础设施领域正在发生一个有趣的变化：
验证层是还没有人真正解决的那个。而它即将变得不可或缺——欧盟 AI 法案的高风险条款已经生效，要求 AI 系统具有可证明的授权、约束和问责。
我一直回想到的一个类比：OAuth 定义了人类如何授权应用程序，而这创造了 Okta/Auth0 市场。OpenWorkProof 定义了人类如何授权 AI agent——以及如何验证它们做了什么。同样的模式，不同的领域。
我发这篇文章是因为我想知道我是真的在解决一个问题，还是只是在解决我遇到的这个问题：
我不是来卖东西的。项目是开源的（Apache-2.0），仓库是公开的，我真的有兴趣知道其他团队是否遇到了同样的验证困境。
GitHub: dengyier/OpenWorkProof
交互式演示：Rich #4196 的 9 步证据链
pip install openworkproof