AI 写得快,验证要跟上:Agent 时代真正稀缺的是可靠反馈回路

QUOTE

生成只是把工作往后推，验证才决定它能不能进入现实。

—— kinpoe

Lauren（poteto）在一次公开分享里说，她上个月向生产环境交付了 2500 个 PR——也就是代码变更请求。

这个数字很容易让人只盯着模型：它到底写得有多快？

Matt Pocock 看完这场分享，记下的却是另一组细节。按他的观后笔记，Agent 被放进受限的抽象、可部署的测试环境和一套会随代码同步的 Feature Map 里。它可以快速试错，但不能随意破坏系统；每次改动都要留下可比较的结果。

这给 Agent 时代的生产力提出了一个不太好听的判断：写代码正在变便宜，证明代码可以交付正在变贵。速度如果没有验证跟上，只会把返工、回滚和排查更快地推到团队面前。

本文看点

《AI Native 研发范式实践手册》给了一组很有冲击力的拆解：编码在完整研发链路中的占比不到 1%，写 1 小时代码，上线可能要 3 周。剩下的时间花在跨团队分析、联调环境、多平台联调、发布审批、灰度和封网。

手册据此预测，2027 年以后“环境与验证”可能占研发投入的 40%–50%，编码降到 5%–10%。这个预测未必适合所有组织，但它把注意力从“模型每分钟写多少行”移到了交付链路真正卡住的地方。

手册还提供了一个更实用的度量框架：

只看 L1，团队很容易自嗨；只看 L3，又会失去定位问题的过程抓手。Agent 的产出必须同时穿过这三层，才算交付。

手册中的案例——交付周期缩短一半、千行代码缺陷率下降 70%、变更失败率下降 90% 以上——都是前后对比，缺少公开基线和对照组，也带有明显的阿里内部工具语境。它们更适合当作方向性证据：当编码成本下降，验证、环境和权限会成为新的投入中心。

Matt Pocock 对这场分享的观后笔记，提炼出三件事。

第一，把 Agent 锁在受控抽象里。人喜欢功能强、边界宽的“锋利工具”，但 Agent 在这类工具里很容易把错误扩散出去。Lauren 的团队用内部框架和 lint 规则，把常见的坏动作变得困难，让 Agent 在有限的动作空间里把事情做深。

第二，从一开始就建设验证基础设施。自定义 CLI 要能让 Agent 驱动应用、采集结果和测量性能；应用本身要能部署到一个可反复试验的环境里。只让 Agent 读代码、改代码，不给它一个能运行和比较的世界，所谓自主只是一串没有证据的文本。

第三，维护 Feature Map。它记录功能边界、预期行为和代码入口，跟着代码库一起更新。普通文档确实很容易过时，但当它能改变 Agent 的探索路径、减少定位和修复的盲区时，它就成了导航基础设施。

这套方法里最容易被忽略的部分，是“证据”。2500 个 PR 不是可靠性的证明；能不能在相同任务上重复跑、比较改动前后的行为、定位失败原因，才是外循环的价值。这个数字来自个人公开分享，不能直接当作所有团队的吞吐基准。

《Building a Custom Harness with Pi and Jev》把 Agent 还原成一个循环：模型提出工具调用，Harness 执行调用，同时决定这个调用是否被允许。模型“想做什么”和系统“允许做什么”，必须是两层。

这套教程把 Jev 这样的轻量决策模型放在三个位置：

故障策略也应该分开设计。安全门询问失败时要 fail closed，宁可阻断也不放行；路由服务不可用时可以 fail open，退回强模型让任务继续。把所有故障都设成同一种“全开”或“全关”，只会把不同风险混在一起。

下面按实际执行顺序，把这三道检查放回同一个流程：

— 根据 Pi / Jev 教程整理。路由服务故障可回退强模型；工具安全检查故障则停止调用。

更重要的是，确定性问题不要交给模型猜。路径是否越出项目目录、凭据是否命中黑名单、资源是否超过上限，都应该由代码直接判断。轻量模型只处理代码难以穷举的语义边界，并且记录输入摘要、概率、阈值和最终动作。没有这些日志，下一次失败只能靠记忆复盘。

两种评测方式的差别，可以先看 LangChain 原文这张图：左侧生成一段解释，右侧直接返回候选结果及其分值。

— 左：生成解释性文本；右：返回候选类别及分值。来源：LangChain，Jev-as-a-Judge for Agent Evals。

图中的发票判断只是输出形式示例，不是下文天气请求实验的测试样本。

LangChain 对 Jev 的早期实验，比较了代码评测、LLM-as-a-judge 和类型化决策模型。实验中，Jev 在 500 次二元判断里与人工标注全部一致；质量分数的均值方差为 0.0000149，单次调用成本约 0.00035 美元，平均耗时 0.44 秒。

数字很诱人，边界也很清楚：测试集只有五个天气请求，服务版本没有完整记录，任务类型和规模都有限。低方差只说明结果稳定，不说明判断一定正确；稳定地判错，仍然会把错误放大。

这项实验提供了一个可借鉴的做法：把评测拆成可重复的具体问题，逐项检查工具是否越权、输出是否覆盖要求、失败是否能恢复。每次改 Harness、权限或提示词，都重放同一批轨迹，比较准确率、重复性、成本和延迟。

当评测便宜到每次运行都能做，覆盖率才有机会从“上线前抽样验收”变成“每次生产轨迹都留下证据”。这会改变团队节奏：事故不再是唯一的反馈来源，日常运行本身就在积累可查询的样本。

几条关于 Bend 的讨论，把问题推到了更远处。支持者的想象是：让语言或运行时在生成后拒绝错误实现，Agent 可以不断收到“这不对，再来一次”的反馈，代码复杂度的上限就不必由人工逐行检查来决定。

这个方向有吸引力，因为它正面回应了技术债的累积：模型可以写出越来越多代码，但错误如果没有被及时拒绝，最终会把进度卡死。Bend 相关讨论把形式验证描述成“软件工厂语言”，甚至提出不必再看最终实现。

它不能自动证明需求写对了、权限边界合理、外部依赖稳定，也不能替你确认产品对真实用户有价值。更稳妥的做法，是把可靠性拆成三层：

这三层逐层缩小不确定性。越靠近业务，越需要检查代码以外的问题。

— 这张图概括的是本文的验收框架；形式验证不能替代后两层。

如果你现在只有一个 Agent 和一个小项目，可以先做六件事：

这套清单看起来不如换一个更大的模型刺激，却更接近真实的生产力。有效权限可以粗略理解为：

任何一项收紧，系统的可行动空间都会变小；但正是这些边界，让 Agent 的速度能够被信任。

最后回到开头的问题：Agent 写得快，为什么人反而更忙？因为生成只是把工作往后推，验证才决定它能不能进入现实。

下一次调整 Agent，先留住一次失败：它收到什么任务、调用了什么工具、哪一步偏离了目标。把这次失败做成可重复运行的检查，再让修改后的 Agent 过一遍。

当同一种错误不必由你提醒第二次，速度才开始变成真正节省下来的时间。