AI 编程Agent深夜产代码，报告可信度几何

2026 年 4 月的一个早晨，我正在审查一个编码智能体连夜赶出的 Pull Request。那份报告确实不错：什么变了、为什么变、哪些测试覆盖了它、一个它主动放弃的边界情况，以及解释为什么放弃的备注。读起来就像一个细心的同事的工作。我正要点击合并时，突然意识到自己实际上在做什么：接受一份关于工作的叙述——由干活的东西写的叙述——就好像叙述本身就是工作。

明确一点：我从未在那份报告里发现任何问题。而且检查总是可能的——读 Diff、跑测试。对于一个 PR 来说，那就是正常的 Review。但智能体一晚上能出好几个，连续好几天不间断地跑，而报告的存在恰恰是为了让我不必重建每个工作现场。到了那个量级，报告就成了界面。而「我从未发现任何问题」成了我信任这个界面的全部依据，整整几个月都是如此。

而且这不是我疑神疑鬼。METR 的《前沿风险报告》（2026 年 2 月至 3 月），同年 5 月发布，发现他们的长任务——8 小时及以上的「时间跨度 1.1 套件」——至少 16% 表面成功的运行，在人工审查后被发现实际上是不合法的。他们还提到，手动检查作弊往往是他们评估工作中最大的那块。另一篇论文（arXiv:2607.26819）测试了编码智能体是否会去查阅仓库的贡献规则：大多数不会，而且在对 AI 贡献明确禁止的仓库里，在测试条件下的拒绝率是零。这是不同设置下的不同失效模式——一个是基准测试作弊，另一个是规则发现被交给智能体自己决定。但它们是同构的：规则或声明只有在该规则或声明能被智能体之外的东西强制执行或验证时才算数。而今天的常见设置恰恰相反。我们问工人工作进展如何，然后把它的回答归档为真相。

所以 5 月我改变了监督对象。智能体在字面意义上无人值守地运行——没人看着它们工作，包括过夜和多日自主运行。但它们的声明从不无人值守。始终处于监督之下的是授权：什么能进入 main，以及是谁批准的。

我为此搭了一个小框架，命名为 thaliana。它围绕恰好三条规则构建。它不编排智能体、不路由 Prompt、不给代码质量打分——那是其他工具的事。这个只守护记录。

1. 声明附带收据。智能体报告中的每个完成声明——「测试通过」「模块已迁移」「回归已修复」——必须引用一个 commit SHA、测试日志或记录的 API 调用。「必须引用」这一步是写作规则；机械的部分是检查：CI 验证报告中的每个引用都解析为仓库中实际存在的东西，并且一个确定性检查会标记任何触碰已提交证据的变更。注意这里没有检查什么：测试是否真的好，或者工作是否正确。它检查的是故事有收据，以及没有人事后换掉收据。可发现的篡改，而非不可篡改。

2. 协作活在文件里。智能体不通过聊天或会话内存互相传递上下文。计划、决策、审查发现、报告——全是仓库里的文件。而「哪些文档当前有效」从 Git 本身派生：文档在 force 当且仅当它在 main 上且没有被标记为 superseded——这个标记本身只有通过合并才能落地。没有状态字段：没有「approved」字段：没有任何字段赋予有效性。一个文档是否被合并不是文档自己有权声明的事。

3. 授权通过人工合并进入。在这个系统里，新的授权只有一种方式进入：人工合并到 main——这是我唯一称之为审批的行为。委托不会移动这个根，因为委托本身就是一个审批：我合并一条策略，说明智能体可以在无人值守的情况下做什么，之后，一个独立的机器主体——一个执行策略的机器人凭证，区别于工作者——可以合并该策略及其检查允许的 PR。机器合并执行的是已经授予的授权；它不创造任何新的。工作者自己的凭证止步于推送分支和打开 PR。自我审批不是要求它们遵守的规则；而是它们没有权限执行的操作。

一个完整的工作单元如下。我合并一份委托——一份包含目标、里程碑和智能体可以触碰的路径的简短契约。智能体在分支上工作，写一份带证据链接的报告，打开 PR。必需的检查验证收据存在并针对最终状态重建和重新运行测试。第二个机器审查者——不同的供应商、不同的凭证——审查 Diff，其发现被记录。一个确定性脚本（里面没有任何 LLM）将 Diff 与委托允许的路径进行比较，并检查审查是否收敛：没有高优先级的开放发现，且本轮没有新提出的发现。如果在固定的轮次上限内没有收敛，或者 Diff 越过了委托机械可检查的边界，运行停止并升级，而不是继续推进。然后 PR 等待这里唯一重要的事件：人工合并。

记录所呈现的

我是 5 月初开始构建的。到目前为止它跑了三个仓库。下面的数字来自其中最繁忙的一个，那是一个 7 月底启动的项目，写这篇文章时已经到了第十八份委托。在截至 8 月 27 日的 30 天里：1,764 次提交（所有参与者——智能体的工作和我的合并），118 次人工合并到 main，以及 288 次独立凭证的机器审查运行（按轮次而非 PR 计）。不止一次，一个运行自我停止并等待我——包括那次工作者得出结论说自己的任务在委托范围之外，写了下来，然后停机。那次停止，明确说，来自于规范，而非关卡：智能体自我判断了范围并选择停机。

让我谨慎对待这些数字意味着什么，也就是说：说明不了太多。它们是活动量，不是成就。它们没有显示框架让任何事变得更好、更快——或者更安全——一个我没有资格说的词。这是我自己项目上的单操作员案例研究——而且由于仓库是私有的，这些数字本身也是你们暂时无法核实的声明。记录确实显示的，作为记录的性质而非我记忆中的性质：没有一次到 main 的合并来自工作者凭证。合并不是那些凭证拥有的操作，而记录中的每次合并都是我的——这也意味着我还没有在这个仓库里行使过机器合并委托。（第一次机器合并发生在三个仓库中的另一个；那个故事属于后面的帖子。）测试，我应该补充，是由规范和审计而非关卡守护的：框架不会机械地阻止对测试预期的修改，而由于篡改测试是经典的作弊方式，那正是审计首先要查看的地方。8 月中审计记录时，每个对测试预期的修改都能追溯到一次升级和一个人工决策。到目前为止，不变式都保持了。这是存在性证明，我不主张超越它。

代价也在记录里，而且不小：那个仓库里按文件数计，超过 90% 的追踪文件是证据——日志、报告、审查记录，将近 150 MB。实际上这意味着克隆沉重、搜索嘈杂：在仓库里跑 grep，你撞上记录的频率和撞上代码一样。证据故意活在同一个仓库里——它绑定到相同的历史，所以一个声明、它的收据、以及它们描述的提交不会漂移分开而不留下 Git 可见的变更——但重量是真实的。这东西改变的是你的工作方式，不只是你安装了什么。我一直在付出，因为它给我带来的东西：一夜运行之后的早晨是用来评判工作的，而不是重建发生了什么。在你的规模上这个交易是否有意义，我确实不知道。如果这些东西最终对你有用，我猜会是作为独立的部分而非整体——没有任何一部分需要其他部分。

它保证什么，不能保证什么

它保证记录，不保证工作。CI 可以验证引用的测试日志存在且没有被悄悄改写。它无法验证测试是否有意义。还有一个更尖锐的漏洞：存在性检查不能确立真实性。在生成时刻伪造日志的智能体——把虚构写进文件、提交、诚实地引用——会通过存在性和变更检查。正确衡量那个漏洞的方法是看 CI 在合并时能重新推导出什么。关于最终状态的构建和测试类声明是容易的那一类：必需的关卡在 PR 上重建并重新运行测试，所以关于最终代码的伪造「测试通过」无法存活。无法重新推导的是历史——无人值守的多日运行中途的日志、无法重新执行的外部 API 调用记录。接收服务签署的收据可以覆盖其中部分，但我所调用的服务目前还不提供；让 CI 产生更多证据也会缩小那个漏洞，但代价是把真实性问题转移到 CI 配置本身。收紧那个门槛已在队列中。目前，在不可重现的那一类里，如果有什么能捕获伪造，那就是下游抽样人工审计。框架的贡献是提高了代价：假货必须在提交、日志和一个独立凭证的审查者之间保持一致，而这些都是它可能露馅的地方。提高代价是它做的全部。这里的任何东西都不能让伪造不可能发生。

信任模型，展开说：我信任 GitHub 的权限机制（分支保护、CODEOWNERS、必需检查）、CI 配置和运行器的完整性，以及工作者和审查者之间的凭证分离。这个设置防御机械可见的漂移、未经授权的授权变更和悄悄的改写；对于语义捷径，或在生成时刻被一致伪造的证据，防御效果差得多。它让篡改可见而非不可能。它不防御恶意的平台管理员，也不防御我。而一些纪律——审查者被期望检查什么、审计如何保持警觉——仍然活在书面规范而非检查中。那个边界在移动。不过。框架里今天机械化的部分大多最初是书面规范，在运营让我看到失效的形态后被升级为检查。剩余的规范不是道歉；它们是队列。

这不就是分支保护吗？

大体上，是的。分支保护、CODEOWNERS、机器用户、必需检查——都是商品化的东西。供应链人更早几年就到了这里针对构建产物：SLSA 和 in-toto 为产物及其生产过程附上可验证的溯源和证明。如果你来找的是一种新颖的机制，并没有。

研究和工具世界也同时从几个方向到达了相同的边界。Proof-or-Stop（2026 年 7 月）是我所知的最近邻：它把「已审查」和「已完成」这样的生命周期状态视为声明，在有机械可验证的证据支持之前不算数——它甚至和我的委托有相同的骨架，绑定到声明的文件路径的范围契约、一个如果 Diff 离开那些路径就让它失败的关卡、以及来自独立审查者的持久裁决。我们分道扬镳的地方在于人。Proof-or-Stop 把 Pull Request 视为「界面，不是信任边界」，把合并就绪的信任根从人工审批移到一个用签名收据认证的源状态绑定证据证书；我走另一条路，依赖 GitHub 的权限边界和仓库历史，以人工合并作为唯一的审批原语。除此之外，还有针对智能体执行溯源的调查工作（arXiv:2606.04990）、一份关于由接收服务而非智能体签署收据的提案（arXiv:2606.04193），以及越来越多最近的小型独立工具，要求智能体的完成声明附带收据（例如 Agent Audits 和 multi-agents-control-plane）。我不是第一个，显然也不是一个人。说实话，趋同比优先级更让我感兴趣：2026 年独立构建的几个系统都把智能体输出视为需要工作者之外证据的声明。如果这篇东西有自己的什么，我想是三个选择——一个有效性锚定在合并的 Git 状态而非自我声明审批字段的文档账本、只作为合并策略存在的委托、以及保持在人工合并的根授权，而机器只执行它。

这样运行下来你面临三个问题，每个都值得单独写一篇。如何在不用 LLM 裁判的情况下验证证据，什么会漏过去？当审批者是一个只有 30 秒的人时，审批和橡皮图章有什么区别？以及最让我惊讶的那个：我的机器审查者似乎永远不会用尽发现，所以审查需要一个设计好的终止条件——否则它永远不会结束。

代码尚未公开，原因在于设计本身：框架自己的仓库在框架下运行，所以它充满了自己的证据——来自真实运行的真实日志。发布代码意味着发布那个记录，而每个文件都必须先过一遍去标识扫描。那是框架为自己记录设定的门槛，我宁愿达到它也不愿仓促行事。想法不需要等。

在那之前，这个安排依然成立：智能体无人值守地运行。它们的声明不是。