Nick Nisi 与 Zack Proser：让编码智能体用证据证明工作完成

Nick Nisi 和 Zack Proser 介绍 Beyond Done 工作坊，讨论如何验证智能体完成的工作。他们认为信任需要通过可观察的检查逐步建立，而不是依靠一句任务完成。

Nisi 是 WorkOS 的工程经理，Proser 是 Applied AI 团队工程师。工作坊仓库包含幻灯片和小型示例应用的练习。

人们首先可能想到逐行检查生成的代码，但智能体产生修改的速度可能超过人工审查速度。讲者探讨了如何补充实际行为的证据。

浏览器测试可以提交表单并检查成功消息。这很有用，但模型声称测试通过，本身不能证明完整的用户目标已经实现。

演示使用一个浏览器本地候补名单应用。输入邮箱后，页面显示该地址和成功状态，看起来似乎操作成功。

刷新后，记录消失了。界面虽然发生变化，数据却没有持久保存；只检查即时显示的测试会漏掉需求的另一半。

Proser 说，开发者同时监督多个智能体时尤其容易漏掉这类问题。构建成功、测试通过，仍可能意味着用户得到错误结果。

团队强调，验证、可靠性和评估是扩展智能体工作的基础。智能体需要反馈，让失败可见，并说明什么才是正确行为。

Nisi 说，“不要出错”这样的模糊指令不够。应定义预期成果，让智能体能够观察、尝试修复并再次检查。

讲者倾向于拆分大任务，并为每项任务定义明确的完成条件。他们的生产力说法属于团队经验，不是保证收益的对照实验结果。

Nisi 要求保留证据，例如测试输出、截图、录像或冒烟检查，展示实际发生了什么。证据必须对应需求，而不只是附在自信的状态报告旁边。

Proser 介绍实验性服务 CTX，用于共享上下文和验证。智能体通过 MCP 连接报告工作，验证器检查外部产物后才把工作流节点标为完成。

例如，验证器可以查询 GitHub 上的 pull request 及其检查，再把失败信息返回给智能体。这个可复用检查比智能体单独的断言提供更具体的证据。

Nisi 的实验工具 Riker 在工作委派后继续跟进：它可以处理审查、运行检查、保存证据，并在需要时请求人关注。这是他们自己的方法示例，并非普遍适用的保证。

听众列举了常见验证步骤：刷新页面、检查 API 和网络响应、查看存储及控制台日志，并操作界面。这些观察能力也可以提供给智能体。

笼统地要求在浏览器中验证，仍有很大解释空间。可重复脚本可以执行一致的步骤，并报告具体哪个检查失败。

讲者把非确定性的模型回答与执行明确检查的命令作比较。脚本可以让检查更一致，但其覆盖范围和正确性仍然重要。

他们制作 Snack 作为工作坊模板，并非适用于所有应用的通用验证器。它的命令可以启动和停止应用、检查环境、操作候补名单并查看结果。

Snack 可以检查存储、获取页面快照和截图并运行检查。示例还包含模型评判器，处理不适合精确比较的问题。

Proser 认为共享验证工具可以使整个团队受益。Nisi 补充说，即使实现被重写，有意义的测试集也能保留对行为的预期。

讲者演示了 JSON 页面快照和截图作为证据。浏览器调试工具也能揭示性能瓶颈，而不必让智能体猜测页面为何变慢。

候补名单示例检查存储并重新加载页面。由于存储为空，验证器可以暴露持久化问题，并向智能体提供具体失败信息。

他们指出，验证可以覆盖后端和数据库操作，也可以覆盖界面。每个团队都需要针对自己的应用及成功标准设计检查。

Nisi 举例说明如何让原本难以观察的动画变得可见：记录球的坐标可以发现意外跳跃。有用的反馈循环需要暴露诊断问题所需的状态。

对于候补名单，类似 Playwright 的检查从空状态开始，填写地址、点击按钮并检查结果。后续修改后可以再次运行，作为回归测试。

一张截图本身不是证明。画面可能通过错误路径达到看似合理的状态，也可能掩盖副作用；还要验证真实操作过程和底层状态。

可重复循环为智能体提供可操作的反馈：复现失败、修改实现、重新检查并保存结果。这可以减少人对每一步的提示。

详细错误信息很重要，因为它说明哪里失败以及系统如何进入该状态。智能体可以据此调查，而不是只看到笼统的失败。

讲者不主张规定每一个实现步骤。他们希望明确结果检查，同时在约束内给智能体选择解决方案的空间。

他们把这个过程与熟悉的红灯、绿灯、重构循环联系起来：复现失败、实施修复、展示结果。证明是工作的一部分，不是事后补充。

现场运行的 doctor 命令检查本地环境、浏览器会话和构建。之后的存储检查显示示例地址没有保存。

讲者讨论保留运行证据。这些记录可以帮助调查当前失败、构建未来评估案例，前提是记录与任务相关并得到妥善处理。

后续演示引入了误导性的确认文案：页面可能说席位已确认，但底层状态只是进入候补名单。精确检查和语义判断可能各自漏掉不同问题。

团队讨论把快速决策模型作为一种可能的评判器。这种模型本身也会出错，因此其分类结果同样需要评估，不能自动视为正确。

在 Saboteur 与 Detective 练习中，演示程序被加入一个隐藏错误，参与者必须用证据指出问题。评分看的是结论是否有依据，而不是表达得有多自信。

现场运行时，doctor 显示了一份针对旧代码的失败记录。这说明证据需要关联其实际检查的版本和条件。

演示遇到输出问题，讲者明确承认了这一点。他们借此区分正确发现错误、错误宣称成功、编造不存在的错误和没有证据的回答。

每次漏掉的失败都可以变成新的评估案例。讲者建议建立基线并持续运行，随着新失败模式出现，由团队共同完善。

代码或环境变化后，旧证据可能过时。昨天通过的结果不能证明今天的版本也通过相同检查。

对于 Web 应用，讲者建议从定制验证器和基线评估开始。在与应用相关的地方，让智能体看到渲染、网络流量、存储和性能。

具体观察内容取决于产品。例如登录功能可能需要检查 cookie 及其过期时间是否正确设置。

保存用户操作过程的证据，包括失败和耗时，使人能够检查实际情况，团队也能据反复出现的失败改进检查。录像可以补充适当的审查，但不能替代它。

讲者把这个过程称为积累证据：应用变化时不断增加单元测试、评估和冒烟测试。运行既有检查有助于发现回归，但任何测试集都不能证明完全没有缺陷。

被问及如何确保检查运行时，Proser 倾向于通过 CI 强制执行，而不是只依赖模型选择遵循某个技能。Nisi 也提到本地 hook 和仓库指令可用于提示运行检查。

他们介绍快速本地反馈与 CI 配合的价值。智能体可以在把工作交还给人之前发现并修复问题，而共享 CI 仍是团队层面的独立检查。

有人问这与现有端到端测试相比有什么好处。Nisi 说，好处是反馈循环更短：智能体可以自己运行工具并返回证据，而不必等人发现明显失败。

Nisi 说他依赖 CI 和自动代码审查，但也指出检查通过仍可能伴随没有实际用途的代码。验证既要防止回归，也要测试预期成果。

对于生产环境，Proser 建议在有条件时先验证预览环境，并监控发布过程，包括指标和功能开关。适当防护取决于系统，也无法消除全部风险。