Agent 开发困境：构建已经免费，但验证还是地狱

1. Agent 开发的真实困境

我在做 Agent 项目时，有一个越来越真实的痛点：

一个挺大的功能，Coding Agent 几个小时就写完了。有 spec、有代码、有单测，有效果截图。代码跑起来，看着像模像样——结构清晰、命名规范，CI/CD 都能通过，核心流程也都没问题。

然后，噩梦开始了。

我得去验收它：把它能走的路一条条走完，把它该守的边界一个个试过，把它可能崩的角落一处处抠出来。最要命的是，哪怕我吭哧吭哧验上一两天，心里依然没底——那些我根本没想到的情况，它真的扛得住吗？而恰恰是这些没被想到的角落，才是日后线上事故的源头。

最后的账单，往往是这样的：

AI 写它，只要几个小时；我验它，要花上一两天。而一两天之后，我依然不敢拍胸脯说它是对的。

写得飞快，验得要死。作为一个自认为比较 AI Native 的团队，我认为这不是我们独有的问题，而可能是行业的普遍困境。

2. 大家都在想"怎么做"，却没人管"怎么验"

你有没有发现，这几年我们折腾的所有"工程"，其实是一条不断往上爬的阶梯——

• 先是Prompt Engineering：研究怎么把话跟模型说对；

• 然后是Context Engineering：琢磨每一步应该把哪些正确的信息喂给模型；

• 再然后是Harness Engineering：想着怎么给它装个合适的环境，配上趁手的工具；

• 最近最火的是Loop Engineering：干脆别一句句喂了，写个循环，让 Agent 自己跑、自己推进、遇到问题自己想办法解决，最后交付个结果。

这四个阶段，是一个持续利用模型智能的提升、并把人类价值不断上移的过程，但是它们本质上全是在解决同一件事——怎么让它跑得更好、更自动。

却没有任何一级，认真回答过那个最朴素、也最要命的问题：

它跑完了，跑的挺快，看着还行，但是我怎么知道它到底做的对不对、好不好？

这个一直被我们用"人肉盯着看"糊弄过去的窟窿，今天基本变成了 Agent 开发的主要矛盾，请允许我效仿硅谷的风格也造个词 ———

Verification Engineering 验证工程

（叫啥名不重要，意思大家懂的都懂~）。

接下来的内容，就是我想好好聊一聊，为什么我觉得 Verification 这个重要，以及我认为的 Verification Engineering 应该长什么样。

3. 这不就是 Evaluation 吗？

我猜你大概率会立刻皱眉："你说的 verification，不就是现在满大街的 eval / evaluation / observability / tracing 那一套吗？LangSmith、Langfuse 们早做了。"

这个问题我自己也纠结过很久。最后我的判断是：

verification 包含 evaluation，但它是一个更高维的视角。

evaluation 关心的，是"术"层面的事：怎么评估模型和 Agent 的性能、怎么追踪每一步发生了什么、怎么把整个过程的可观测性做扎实。这些都极其重要，是地基，缺了它寸步难行。

但 verification 关心的，是一个更要命的问题："对"到底是什么？

• evaluation 告诉你：它做了什么、性能如何——成功率 87%、P95 延迟 2.1 秒、这一步调了哪个工具，从哪里取了 Memory。

• verification 要尝试回答：它做出来的这个东西，是不是我想要的那个"好东西"。

区别在哪？前者可以外包给一套工具和指标；后者外包不掉。因为"什么算好"这个标准的源头，是一个 builder 对产品的审美。

所以我更愿意这么说：

evaluation 是测量，verification 是判断。测量可以被标准化，判断是一种品味的表达。

一个再牛的 eval 平台，能精确告诉你"成功率多少、延迟多少、哪一步用了什么工具"，但它永远替你回答不了那句真正要命的话——"这东西做出来，到底 UI 好不好看，功能好不好用，是不是我心里真正想要的那个版本？"

这就是为什么我说 Verification Engineering 站得更高：它把 evaluation、tracing、observability 这些"看得清"的能力当底座，然后在上面架起那层真正稀缺的东西——

把一个 builder 的产品审美，工程化、规模化地表达出来，让机器替你反复执行这种判断。

记住这一层。后面所有的话，都会绕回到它。

4. Verifier is the bottleneck

我们都幻想过那个画面：一个 Agent，不用你守着，自己就把活儿干了。

但你冷静想一句话——

一个 loop 真正有价值，当且仅当它能脱离你自主运行；而它能脱离你，又当且仅当它自己能判断：什么时候算做完、什么时候算通过、什么时候算失败、以及失败了该怎么修。

这个做判断的角色，就是verifier（验证者）。

道理其实挺糙：一个 loop 跑得再花哨，只要背后没有一个你信得过的 verifier，你就还得乖乖坐回屏幕前盯着——那它压根没把你解放出来。所以我现在越来越确信：

Loop 真正的瓶颈，从来不是"怎么跑起来"，而是"怎么判断对不对"。Verifier is the bottleneck。

而这里头，藏着一个特别残酷的不对称：

• 对少数任务，验证比生成便宜——测试通过、CI 变绿、编译器接受，干脆利落的 0 和 1。这种叫"可验证目标"，loop 在这儿如鱼得水。

• 对大多数真正有价值的工作，验证和生成一样难，甚至更难：这个产品策略好不好？这次重构真的更干净吗？这个页面，用户点进来会不会觉得别扭？

这些问题，你没法塞进一个单元测试里。

所以 Loop 工程真正难啃的骨头，根本不是把循环搭起来，而是怎么"造"出可验证性——怎么把一个模糊的目标，翻译成机器能自己检查的标准。一句话：

Loop 真正的约束从来不是模型能力，而是人类在输出边界上的"验证带宽"。

Claude Code 一晚上能给你提 20 个 PR，发 3 个产品版本，但你 review 不完。瓶颈不在它那头，在你这头。说白了——你，不 scale !!!

5. 残酷的"可验证定律"：为什么 Coding 已经大结局

顺着这个逻辑往下推，我想起了业界比较共识的可验证定律：

一项能力会不会先被 AI 攻克，取决于它的"验证成本"有多低。

为什么 Coding 是第一个走到大结局的赛道？因为它把"可验证"的三大要素全占齐了：

• 海量训练数据

  ——全世界的开源代码摆在那儿，且非常结构化，好采集好清洗；

• 完美的运行环境

  ——编译器、测试、CI，一个能一键判对错的真实世界；

• 完善的评估指标

  ——测试通过率、各种 benchmark。

于是，一旦像 Anthropic 这样的玩家把飞轮转起来——生成 → 用真实环境验证 → 拿验证结果再训练 → 模型更强 → 用的人更多 → 数据更多——这轮子越转越快，后来者几乎找不到弯道超车的机会。

所以 Coding 赛道已经大结局了，接下来我们应该 bet on what?

6. 把验证成本打下来

如果可验证定律成立，下一波机会就是名牌了：

哪里的验证还很贵，哪里就是下一个战场。而最后赢的人，不是把模型做得更聪明的人，是把"验证成本"打下来的人。

可前面说过，那些最值钱的东西——产品好不好、UI 对不对、体验顺不顺——根本塞不进一个单元测试。这种"品味级"的判断，传统手段够都够不着。

那怎么办？我的设想是：让 verifier 成为你产品的原生用户，直接住到产品里去玩它。

所以也许我们需要考虑重新捡起这些技术：

• Browser-Use（for Web）

• Mobile-Use（for App）

• Computer-Use（for PC/Client）

有了它们，verifier 就不再是隔着代码"指指点点"，而是能像一个真实用户那样，亲手打开你的产品，一步步点下去，亲眼看到结果长什么样。

我心里那个产品的样子，是这样的：

让一个 verifier 住进你的 Agent 里，成为一个常驻的"资深 Pro 用户"。

它不知疲倦，天天用你的产品，像最挑剔的老用户那样验收每一个新功能，持续告诉你：这儿的流程断了、点完这个 button 页面崩了、新版 UI 不如以前的风格好、甚至——你这回的改动，其实让产品变差了。

它干的事，本质上就是把第三节那个"外包不掉"的难题，第一次撬开了一道缝：把"对产品品味的验收"——这件最贵、最依赖人、最不可能标准化的事——变得可以规模化。

7. 别追求 day 1 就完美，能让验收"没那么痛"就值钱

我猜你又要反驳了："品味、体验这种东西，怎么可能完全自动验证？"

对，完全做不到。但这恰恰是我最想强调的一点：

你根本不需要 day 1 就实现端到端的完美验证。

验证从来不是一个"全有或全无"的开关，它是一条成本曲线。

如果你今天能把验收一个功能的时间，从两天压到半天；能把"我盯着屏幕一个个点 case"的 80% 交给那个住在 Agent 里的 Pro 用户，只留最后 20% 给我拍板——这就已经是天大的价值了。

在这条曲线上每往下挪一格，都是真金白银的杠杆。别被"做不到完美"吓退，先去做"让它没那么痛"。

8. 尾声：一场把人逼向纯粹品味的撤退

回头看这条阶梯：Prompt 工程化了"怎么说"，Loop 工程化了"怎么跑"，而 Verification 要工程化的，是"什么算对"。

当 AI 把"做出来"这件事变得几乎免费，人类手里其实只剩下最后一件外包不掉的事：判断什么是好的，什么是值得的。也就是—— Taste。

所以 Verification Engineering 最终极的样子，绝不是用更多测试去把 AI 框死，而是想办法把"人的品味"也变得可以规模化地施加给机器。而 Browser / Mobile / Computer-Use 这些"手和眼"，就是让品味能下沉、能落地、能被一个 verifier 反复执行的那条通道。

这是一场漫长的撤退，也是一次彻底的解放：我们终将从"逐行验收"里抽身，最终人的最大价值就是——决定什么值得做；而把"它到底做对了没有"这件苦差事，交给一个住在 Agent 里、比你还挑剔的资深用户。

构建，已经免费了。

下一阶段，看谁能把验证变得越来越容易吧~