面向 Agent 的可验证架构：从 UI 驱动到自动回归闭环

摘要

当 Agent 的生成能力越来越便宜，工程瓶颈会转向“怎样证明它做对了”。稳定的 Agent 系统不能只为人的眼睛和 UI 设计；它必须能够脱离界面运行、暴露结构化中间状态，并允许另一个 Agent 调用和验证。在此基础上，将确定性断言、LLM 评判器、回归样本和功能开关组成闭环，才能把人工守着屏幕的试错变成可重复的工程流程。

永久结论

Agent 自动化的上限，不取决于它能生成多少内容，而取决于系统能自动验证多少行为。

可验证架构的完整链条是：

Agent 可访问的接口 → 可观测的执行轨迹 → 分层评判器 → 回归样本 → 新旧版本对照 → 自动修正 → 发布门禁

人的价值也因此从反复操作和肉眼验收，转向三件事：定义什么算对、选择代表性样本、决定哪些风险不能交给自动化。

从 UI-first 转向 Agent-first

UI-first 系统默认使用者是人：人点击、人观察、人判断下一步。Agent-first 系统则要让执行层不依赖界面，UI 只是人类的监控与操作窗口。

问题	UI-first	Agent-first
如何启动任务	点击页面	API、CLI 或结构化工具调用
如何了解进度	观察界面	读取状态、事件和执行轨迹
如何判断成功	人凭感觉验收	机器可执行的断言和评分规则
如何复现故障	手动重走流程	回放同一输入、状态和版本

设计时先回答三个问题：

系统脱离 UI 和人的眼睛后，是否仍能完整运行？
每一步的输入、工具调用、结果和失败原因，是否留下了可读取的状态？
是否有专门的接口，让另一个 Agent 获取这些信息并继续操作？

架构偏好

如果条件允许，优先将前后端解耦，让后端能够独立、长时间运行。视觉操作和模拟点击适合作为兼容手段，不应成为唯一接口。

分层验证：硬断言与 LLM 评判器

Agent 的输出既包含可以精确判断的行为，也包含语义性质量。不要让一种裁判方式包打天下。

第一层：确定性断言

用代码检查硬事实：

是否调用了正确工具；
必要字段、记录数量和状态转移是否符合约束；
是否触发了禁止操作；
超时、重试和预算是否超标。

这一层应尽量可重复、低成本，并作为不可绕过的发布门禁。

第二层：LLM 评判器

只把无法用硬规则表达的部分交给 LLM，例如相关性、完整性、语气和多步决策质量。评判器需要：

只看验收目标、执行轨迹和候选结果，不参与开发过程；
按明确 rubric 分维度评分，不是笼统回答“对/错”；
使用人工标注样本校准，持续检查评分偏差；
为低分结果输出失败类型和理由，给下一轮修正提供信号。

先证明评判器可信，再用它驱动 Agent 优化。

把测试变成可积累的资产

回归集不应是一批临时 prompt，而应是持续增长的产品资产：

理想路径：每个新功能都固化至少一条预期工具调用和状态变化。
历史失败：将真实用户输入、边界情况和线上故障加入回归集。
可控对照：用功能开关让旧版和新版在同一批样本上运行，将“感觉变好”变成可比较的证据。
多次重复：对概率性输出重复运行，比较分布而不是一次结果。

自动回归闭环

先定义验收标准。
保存回归样本。
在功能开关下实现变更。
新旧版本运行同一测试集。
硬断言 + LLM 评分。
是否达到阈值：未达到，根据失败类型修正，回到第 4 步；达到，人工审查证据并发布。

开发 Agent 不只接收“写代码”的任务，而是接收一份可验收的变更契约：

先写回归样本、断言和评分标准；
为新行为设置功能开关；
实现变更，同时保留完整轨迹；
在开关开启和关闭时运行同一测试集；
对比质量、成本、延迟和历史回归；
根据失败证据继续修正，直到达标或触发停止条件。

实施检查清单

核心工作流可以脱离 UI 运行
工具调用、中间状态、错误和成本可观测
外部 Agent 有稳定、结构化的操作接口
硬规则由确定性断言验收
语义质量由经人工样本校准的 LLM 评判器评估
回归集同时包含理想路径、历史失败和真实输入
每个新功能可以与基线版本做受控对照
定义达标阈值、最大轮数、Token 预算和超时上限
高风险改动仍需人工审查后发布

边界与风险

评判器不是真相机：如果没有人工校准，LLM 评分会把偏差自动化。
回归集会过时：只针对旧样本优化，可能导致测试集过拟合。
可验证不等于可上线：安全、隐私、权限和业务后果仍需独立门禁。
自动循环必须有上限：没有轮数、时间和成本边界的闭环，只会更快地浪费资源。

来源说明

本笔记由视频《我做 AI Agent 一年，90% 在做表面功夫——直到我换了思路》的机器转写稿提炼而来。“90%”是作者对自身工作时间的估算，不应当作普遍性统计结论。