自主度的上限等于验证能力

能给 Agent 多少自主度，等于你能多便宜、多可靠地验证它。无法验证的任务，先建立验收能力再谈自主。

能给 Agent 多少自主度，等于你能多便宜、多可靠地验证它。无法验证的任务，先建立验收能力，再谈自主——顺序反了，你拿到的只是更快的错误。

先算验证，再算自主度

两条硬规则。第一，完成状态必须由环境判定，不能只因为模型说「已完成」就标记完成。这是「回答 ≠ 负责」的分界线：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，是一种没人认领的负债——平时不付息，出事时一次性结清。

验证容量不够时只有三个选项

验证一旦成为瓶颈，只有三个显式选项：扩验证容量、降产出速率、降质量标准。没有第四个，也不能让它默认发生——没人数过吞吐，也没人在文档里写明放宽了什么，只是 review 从细看变成了扫一眼。质量下滑如果是没人做过的取舍，就是事故；写下来、有人签字，才叫决策。

怎么把验证吞吐做成可运营的容量，让验证速度追上生成速度 会展开。这里只留一句判据：自主度能不能放大，取决于这三个选项里你选了哪一个，以及这个选择是不是你主动做的。

把任务推进「可自动验证」那一格

任务按两个维度落进四格：目标是否清晰、结果能否自动验证。Harness 的靶心不是让模型更聪明，而是把任务往「目标清晰 + 可自动验证」那一格推 ai-agent-book。

另外两格各有各的难法。目标清晰但只能人工验收，瓶颈在验收成本，只能靠 golden set、专家抽检、可机械判定的代理断言一点点往下压。目标模糊却偏偏有自动验证，是最危险的一格：只要手上有个跑得动的指标，所有优化就会自然流向它。拿 linter 告警数当「代码质量」来优化，几个晚上就能刷出一个全绿但没人敢改的项目——这不是失败，是高效地跑偏，比失败更难发现，因为仪表盘一直在变好。

把路径交给模型

只固定三件事：目标结果、成功判据、约束。达成目标的路径交给模型选。反过来做——把每一步都指挥清楚——是双重浪费：你付了推理成本，却没用上模型的判断。

模型升级后还要重新校准这条边界。用上一代模型时不合理的请求——大项目整仓移植、自主长任务——现在可能可行，委派方式也该从指挥步骤转向描述最终状态，让系统自己规划路径并回报取舍。

扩展能力边界最有效的手段，是把内部环境改造成有反馈、可验证的状态，而不是写更强的提示词。淘天团队的实践是让验证在真实环境里闭环：反馈越公开、越可规模化的问题，越先被解决 taotian-env-verification。

三个问题自检：这个任务的成功能不能写成一句机器可判定的话？验证成本占生成成本多少？如果明天产出翻倍，验证跟得上吗？