自主度的上限等于验证能力
能给 Agent 多少自主度，等于你能多便宜、多可靠地验证它。无法验证的任务，先建立验收能力再谈自主。
能给 Agent 多少自主度，等于你能多便宜、多可靠地验证它。无法验证的任务，先建立验收能力，再谈自主——顺序反了，你拿到的只是更快的错误。
闭环能不能跑完，比单步准不准更重要
评估一个 Agent 时，直觉上会盯着「每一步做得准不准」。但真正决定它在生产里有没有用的，是另一件事：它能不能把任务从头到尾自动跑完。
差别在返工成本。一个多阶段流程（识别请求、分析依赖、处理参数、生成断言、产出代码）里每一步都可能出错。如果某个环节失败需要人介入排查，Agent 省下的时间会被迅速吃掉——「效率提升」经常就是这样被抵消掉的。所以设计的重点不该是让每一步都生成最优答案，而是让整条链路具备足够强的容错：模型输出的不确定或不合法结果，通过结构校验、异常内容丢弃等方式处理掉，保证后续阶段能继续走。哪怕初版结果不够完美，也要先产出一个能跑通的结果。bytedance-nl2test
这条判断有个重要的推论：「偶尔给出惊艳结果」和「稳定给出可用结果」是两种能力，前者在评估里看起来更亮眼，后者才是能被依赖的。自建评测时如果只测单步准确率，会系统性地高估那些「聪明但不稳定」的实现。
先算验证，再算自主度
两条硬规则。第一，完成状态必须由环境判定，不能只因为模型说「已完成」就标记完成。这是「回答 ≠ 负责」的分界线：agent 说它发起了请求，和请求真的产生了一次且仅一次副作用，是两件事。副作用型动作要有幂等键和收据；进程在结果确认前崩溃时，对结果不确定的动作执行 reconcile 对账，禁止盲目重放——重放可能造成重复扣款、重复发信。
第二，不要把团队自己无法评估的判断外包给 Agent。人识别不出正确答案，agent 同样识别不出。无法验证的任务必须先建立验收能力：golden set、领域专家抽检、可机械判定的判据，然后再交出去。
判据必须机械可判定
成功判据要写死且可机械判定：测试变绿、产物存在、Diff 为空、命令 exit 0。写不出这种判据的，视为未定义，而不是「先跑起来看看」。
判定还要与执行分开：agent 改完代码，由独立的验证步骤跑测试、做类型检查、检查 Diff、验证输出文件，全部满足才算完成。高价值结果建议用独立验证器或不同的评测路径，避免让生成者用自己的视角验证自己 anthropic-evals。
「机械可判定」内部还有一条成本阶梯，别跳级用。确定性检查（Schema、类型、断言、业务规则）排在最前；分类模型处理结构化风险（有害内容、隐私、注入）；LLM 判官留在最后，只有当验证本身需要语义理解、写不成确定性规则时才动用 agents-in-action。跳级的代价有两笔：高并发部署里 Guardrail 的开销可能与 Agent 本身相当甚至更高；而用模型验证模型，两边同偏误——判官会被它所评估的那段表达带着走。
生成速度超过验证速度会发生什么
生产代码的成本结构已经反转：生成不再是最慢的一环，验证才是。代价是可量化的——AI 生成的代码约 45% 引入了已知安全缺陷 bytebytego-verification。
更隐蔽的代价是认知债：生成速度持续超过验证速度，会累积「代码看似通过、但没人能说清它为什么这样工作」的状态。它不是 bug，是一种没人认领的负债——平时不付息，出事时一次性结清。
验证容量不够时只有三个选项
验证一旦成为瓶颈，只有三个显式选项：扩验证容量、降产出速率、降质量标准。没有第四个，也不能让它默认发生。质量下滑如果是没人做过的取舍，就是事故；写下来、有人签字，才叫决策。
怎么把验证吞吐做成可运营的容量，让验证速度追上生成速度 会展开。这里只留一句判据：自主度能不能放大，取决于这三个选项里你选了哪一个，以及这个选择是不是你主动做的。
反过来看，判定机制本身是否可得，决定了一次改造能不能交给 Agent。 CodeScene 2026 年 9 月的案例给了正面样本：三周重构 30 万行 C 代码，726 个文件、2903 次提交、改动 25.2 万行，成本约 4000 美元。支撑它的两个机制正好对应本文的两条线——一是 CodeHealth MCP 给出确定性评分，让 Agent 知道该改哪里、以及一次转换是否真的产生了正面效果；二是回放轨迹框架逐帧比较状态哈希，每次更改后验证行为是否仍然一致。因为反编译的游戏能提供确定性逐帧回放，这个判定机制才成立 codescene-refactor。
反过来的推论更值得记住：大多数遗留系统不存在与之相当的判定机制，这正是重构它们存在风险的原因。 回放框架之所以有效，是因为反编译的游戏天然提供确定性逐帧回放；换成一个没有等价性检查的业务系统，同一套自主度就不成立。作者自己的结论也落在这里——自动化测试与等价性检查是绝对必要的保障措施，而这份负担恰好落在不健康代码库往往最缺少的东西上。
把任务推进「可自动验证」那一格
任务按两个维度落进四格：目标是否清晰、结果能否自动验证。Harness 的靶心不是让模型更聪明，而是把任务往「目标清晰 + 可自动验证」那一格推 ai-agent-book。
另外两格各有各的难法。目标清晰但只能人工验收，瓶颈在验收成本，只能靠 golden set、专家抽检、可机械判定的代理断言一点点往下压。目标模糊却偏偏有自动验证，是最危险的一格：只要手上有个跑得动的指标，所有优化就会自然流向它。拿 linter 告警数当「代码质量」来优化，几个晚上就能刷出一个全绿但没人敢改的项目——这不是失败，是高效地跑偏，比失败更难发现，因为仪表盘一直在变好。
把路径交给模型
只固定三件事：目标结果、成功判据、约束。达成目标的路径交给模型选。反过来做——把每一步都指挥清楚——是双重浪费：你付了推理成本，却没用上模型的判断。
模型升级后还要重新校准这条边界。用上一代模型时不合理的请求——大项目整仓移植、自主长任务——现在可能可行，委派方式也该从指挥步骤转向描述最终状态，让系统自己规划路径并回报取舍。
扩展能力边界还有一条常被漏掉的路：改环境，而不是写更强的提示词。淘天团队的实践是让验证在真实环境里闭环——反馈越公开、越可规模化的问题，越先被解决 taotian-env-verification；环境侧的做法在环境反馈决定能力边界 里展开。
三个问题自检：这个任务的成功能不能写成一句机器可判定的话？验证成本占生成成本多少？如果明天产出翻倍，验证跟得上吗？