Skip to content

Latest commit

 

History

History
63 lines (32 loc) · 5.79 KB

File metadata and controls

63 lines (32 loc) · 5.79 KB

把不确定补丁放进确定性边界 / Putting Uncertain Patches Inside Deterministic Boundaries

摘要 / Abstract

Coding Agent 最危险的误解之一,是把“模型给出了合理解释”当成“修改已经被证明正确”。PatchProof 的设计过程说明,真正可复用的能力不是更长的 Prompt,而是一组将提案、权限、执行和证据分离的工程协议。

One dangerous misconception around coding agents is treating a plausible model explanation as proof that a change is correct. PatchProof shows that the reusable capability is not a longer prompt, but an engineering protocol that separates proposal, authority, execution, and evidence.

一、补丁不是权限 / 1. A Patch Is Not Authority

Unified Diff 只是数据。系统首先规范化 Diff、验证路径和大小,再把它与当前仓库快照组合成 Proposal Hash。审批人批准的是这个完整哈希,而不是“看过大概内容”或某个可变文件名。

A unified diff is data. The system first normalizes it, validates paths and bounds, and combines it with the current repository snapshot into a Proposal Hash. The reviewer approves that complete hash—not a vague intent or mutable filename.

这解决了两个常见问题:审批后仓库已经变化,以及审批对象与实际执行对象不一致。任何快照漂移都会让旧审批失效。

This closes two common gaps: the repository changing after review and the executed object differing from the approved object. Any snapshot drift invalidates the approval.

二、通过测试还不够 / 2. Passing Tests Is Not Enough

如果补丁前测试本来就通过,补丁后通过不能证明它修复了问题。如果没有真实测试运行,退出码零也不能证明正确。如果候选补丁可以修改评分器,它甚至可以“修复测试”而不是修复产品。

If a test already passed before the patch, passing after the patch proves no repair. Exit code zero proves nothing when no test ran. If the candidate can modify its grader, it may “fix the test” instead of the product.

因此 PatchProof 把判定拆成四段:补丁前必须复现失败,补丁后复现通过,完整回归通过,外置隐藏测试通过。每段都必须真实执行测试;ImportError、零测试和基础设施错误不能伪装成目标失败。

PatchProof therefore uses four phases: fail-before reproduction, pass-after reproduction, full regression, and external hidden tests. Every phase must execute actual tests; ImportError, zero tests, and infrastructure failures cannot impersonate the target failure.

三、隔离是可验证配置 / 3. Isolation Is a Verifiable Configuration

“用了 Docker”不是充分的安全结论。需要检查准确镜像、是否允许拉取、网络、用户、挂载、根文件系统、Capabilities、进程数、内存、CPU、临时目录和超时清理。

“Uses Docker” is not a sufficient security conclusion. The exact image, pull policy, network, user, mounts, root filesystem, capabilities, process count, memory, CPU, temporary storage, and timeout cleanup all matter.

Runner Fingerprint 将镜像和资源配置绑定进回执。本地 Runner 也可以复用同一判定逻辑,但必须明确标记为不隔离,不能借用 Docker 路径的安全声明。

The Runner Fingerprint binds the image and resource configuration into the receipt. A local runner may reuse the verdict logic, but it remains explicitly non-isolated and cannot borrow the Docker path's security claim.

四、回执提供完整性,不提供神奇真实性 / 4. Receipts Provide Integrity, Not Magical Authenticity

内容寻址回执能发现内容变化、避免静默覆盖,并把运行参数和阶段证据固定下来。但公开哈希算法不能认证是谁执行了验证,也不能替代数字签名、可信时间戳和身份提供方。

A content-addressed receipt detects content changes, prevents silent overwrite, and binds configuration to phase evidence. A public hash algorithm cannot authenticate who ran the validation or replace digital signatures, trusted timestamps, and identity providers.

因此文档必须区分完整性、真实性和不可抵赖性。v0.1 只实现第一项。

Documentation must therefore separate integrity, authenticity, and non-repudiation. v0.1 implements only the first.

五、Skill 把方法复用到其他 Agent / 5. Skills Transfer the Method

独立库复用运行时代码,Skill 则复用设计和审计方法。verifiable-agent-audit 将权限、信任边界、审批、恢复、预算和副作用变成控制目录;agent-eval-builder 将固定数据、独立评分、正确拒答、分母和失败分类变成可重复工作流。

The standalone library reuses runtime code; Skills reuse design and audit methods. verifiable-agent-audit turns authority, trust boundaries, approvals, recovery, budgets, and side effects into a control catalog. agent-eval-builder turns pinned data, independent grading, correct abstention, denominators, and failure taxonomy into a repeatable workflow.

这两种复用互补:库约束机器执行,Skill 约束工程过程和表述边界。

The two forms are complementary: the library constrains machine execution, while Skills constrain engineering process and claims.

结论 / Conclusion

值得展示的 Agent 工程能力,不是“让模型做更多”,而是知道哪些动作必须分权、哪些结果必须独立验证、哪些失败必须关闭,以及哪些数字不能夸大。PatchProof 的核心产出正是这组边界。

The meaningful Agent-engineering capability is not making the model do more. It is knowing which actions require separate authority, which outcomes need independent validation, which failures must fail closed, and which metrics must not be overstated. Those boundaries are PatchProof's core result.