# 做 AI Agent 一年,90% 的时间都在做表面功夫
**作者**: Ando
**日期**: 2026-07-08T11:44:24.000Z
**来源**: [https://x.com/ando_w/status/2074821901940056524](https://x.com/ando_w/status/2074821901940056524)
---

有天我顺手统计了一下自己做 AI Agent 开发的时间,结果挺刺眼的。
真正花在写代码、做设计上的时间,只有 10%。
剩下 90%,全耗在同一件事上——手动测试。
点开网页,输入要测的数据,盯着 Agent 一步一步跑,然后用人脑判断:这次到底是变好了,还是变坏了。
这还不是最烦的。最烦的是 Agent 这系统本身就不确定。我有时候只想改一个很小的行为,结果改了一句 prompt,它就崩了。更没底的是,很多时候我连它到底有没有真的坏都看不出来,只能再跑一遍,再跑一遍,再跑一遍。
到这一步,我的工作已经不是在写代码了,是在反复手动验证一个连我自己都快看不懂的系统。
这正常吗?
# 90% 的根,叫"验证不对称"
在想办法改进之前,我先确认了一件事:这到底是不是我一个人的痛点。
不是。
2025 年,OpenAI 和 Meta 的研究员 Jason Wei 提出一个概念,叫"验证的不对称性"(asymmetry of verification)。意思是:有很多任务,做出来很难,但验证它做得对不对,却很容易。
顺着这个,他给出一条定律——verifier's rule:任何可解且易于验证的任务,终将被 AI 解决。
这跟我的 90% 有什么关系?
我之所以 90% 的时间在验证,恰恰是因为对我们构建的 AI Agent 来说,生成变得很便宜了,但验证还很贵。这就是那个不对称。
换句话说:如果我能把"判断 Agent 做得对不对"这件事,从一个靠肉眼、靠感觉的难题,变成一道自动的、可重复的验证体系——那我就是在亲手把一个难验证的问题,改造成一个容易验证的问题。
一旦它变得容易验证,按这条定律,剩下的就该交给 AI 了。我的角色,从"守在屏幕前点按钮的人",变成了"制造可验证架构的人"。
# 芯片行业 30 年前就被逼着干过这事
这话听起来抽象,但有个行业 30 年前就做过同样的事。
而且巧了,就是我入行前干的——芯片的设计与验证。
说个冷知识:写芯片代码的人,往往比验证芯片代码的人少。在芯片真正流片之前,花在验证上的人力,经常是设计的两倍、三倍甚至更多。
为什么?因为芯片一旦流片,出错了就是几百万美金直接打水漂,没有"改个 bug 重新部署一下"这种好事。整个行业被现实倒逼着,把大部分精力压在同一件事上:想尽一切办法,把所有可能的 bug 全部找出来。
干这件事的核心,光会写芯片代码不够,你得会设计验证体系——怎么设计回归测试主动把 bug 暴露出来,在哪些地方埋检查点,又怎么衡量自己到底测得够不够全。
讲到这儿你大概发现了,这跟我们今天做 AI Agent 开发,几乎是同一个形状。
当 AI 把写代码变得越来越便宜(就像当年 EDA 工具让写 Verilog 变容易一样),你的价值就不在设计上了。它出现了一个新的价值点:你能不能设计出一套体系,让 AI 的每一次改动都可以被验证。
# 第一步不是写测试,是把系统改造成对 AI 友好的
具体怎么做?
第一步可能跟你想的不太一样——我要做的第一件事不是写测试,而是把 AI Agent 改造成一个"对别的 AI Agent 友好"的系统。
我手上有两套东西:一套是我们自己写的 AI Agent,另一套是我用来写代码的 Coding 工具,比如 Codex。
之前测试为什么痛苦?因为我那套系统的入口是一个网页、一个 UI,是给人用的。要测它,就得有个人在那儿点一下、输一下。从第一天起,它就是为人的眼睛和手设计的。
现在大家都在讲"面向 AI Agent 的开发",真正的核心是三个问题:
1. 你的系统脱离了人的眼睛和 UI 之后,还能跑得起来吗?
2. 它运行的过程中,那些中间状态有没有留下足够的信息,让另一个 AI 能看懂?
3. 你有没有专门设计接口,让 AI 能自主拿到这些信息?
举个例子:我运行一个 Agent 的时候,需要让 Codex 能看到整条 workflow 长什么样、中间调了哪些工具、每一步拿回了什么数据。如果这些信息一离开 UI 就消失,或者整个 workflow 离开 UI 后端就瘫了——那只能说明,这套接口到现在还是为人设计的,不是为 AI 设计的。
怎么改?两条现成的路:
一条是用 MCP 模拟网页操作,让 AI Agent 直接读你的网页,靠多模态观察。
另一条是前后端彻底拆开,后端变成一个能独立运行的 Agent,所有调用做成命令行可控的形式,前端退到一边,只负责把后端信息监控出来给人看。
我选了第二条,前后端分离。原因是 MCP 虽然能看到网页上的操作,但在 authorization、corner case 和效率上,没有前后端分离来得直接、来得快。
说实话,做前后端分离这一步我们也花了不少力气。之前重度用了 Vercel 的 AI SDK,一开始确实好用,但在前后端分离这件事上,得花点工夫才能做到一个比较好的程度。我们最终把它变成了一个能脱离前端、在后台长时间稳定跑下去的系统。
做完回头一看,有没有人踩过同样的坑?有。普林斯顿 SWE Agent 那篇论文里提过一个概念,叫 ACI(Agent Computer Interface)。他们的观点是:AI Agent 是一类全新的用户,和人不一样,你得专门给它设计接口。而且实验发现,接口设计得好不好,对 Agent 表现的影响,甚至大过你换一个更强的模型。
所以每天听到的"面向 AI Agent 的编程""面向 AI Agent 的服务",核心从来不在某个具体技术上,而在:你做的东西,能不能被另一个 AI(简单点说,能不能被 Codex)快速、主动地拿到它需要的信息。
# 回归测试,但得给不确定系统专门设计
做完前面那步,接下来就很直接了——构建测试。
说穿了就是回归测试(regression test)。概念不复杂,复杂的是怎么给一个不确定的系统去构建它。
拿给 Agent 加功能举例。我想新加一个工具的时候,心里其实有个明确的预期:在什么条件下这个工具会被触发,触发之后整个 workflow 应该怎么走。这条我期待它走的路径,叫 happy path(快乐路径),它就是一个新功能的验收标准。
从架构上,先解决一个棘手的问题:谁来当裁判?
Agent 的输出是一大段自然语言、一条运行路径,不是一个能直接相减的数字。所以传统那种"过或者不过"的分类系统不够用。
我的办法是把裁判拆成两层:能确定的交给确定性裁判,模糊的交给 AI 裁判。
## 第一层:确定性断言
就是一组硬性检查:跑这个测试的时候工具是否触发了、跑到某一步中间状态有多少条记录、覆盖到哪些情况了。这层的特点是绝对可靠、确定性、零成本。
## 第二层:LLM 裁判(Supervisor)
专门处理第一层卡不住的模糊部分。这里有几个关键细节:
第一,这个大语言模型的上下文必须是干净的。它不参与任何开发,不知道你代码的来龙去脉,它眼里只有"对正确的预期"。
第二,面对没有标准答案的输出,不让它判对错,而是让它做量化打分,通过分数判断最终结果好了多少、差了多少。
如果你做过芯片验证,这套系统挺眼熟的——assertion、coverage、scoreboard,概念都借了。只不过相比硬件,AI Agent 本身就存在一定的不确定性,所以对不确定性的容忍程度要更高一点。
# 攒案例 + 功能开关
解决了裁判问题,第二步就是不停地攒案例。
上面基于 happy path 做的开发,功能越多,happy path 就一条条固化下来。除此之外,还可以从真实用户、从测试里捞那些我们自己根本没设计过的、五花八门的输入,放进测试集里。
这两类回归测试,能保证系统在不停更改的状态下依旧没退步,同时尽量没有盲区。
还有一个我自己觉得特别关键的实践:每加一个新功能,我都会给它配一个开关(flag)。
有了开关,我就有开和关两个版本。当它们跑同一套回归测试的时候,我能清楚地看到新功能到底带来了什么——哪些变好了,哪些被悄悄弄坏了。
# 闭环:人不参与的收敛
有了上面这套架构,最妙的一步来了:怎么把这一切形成一个闭环?
在 Codex 里,当它需要开发新功能的时候,它不只考虑代码怎么写,它需要:
1. 先设计回归测试。
2. 再设计开关。
3. 然后写代码。
4. 写完之后,开关开、开关关,各跑一遍回归测试。
5. 通过回归测试的结果反馈,去修改代码。
6. 直到代码改成能符合回归测试要求的版本。
整个这套体系里,人没有参与。Codex 这种 coding agent,通过我们设计的可验证体系,把这一切连成了一个闭环。
到这一步你会发现:我们已经不再写代码,也不再手动测试了。我们做的,就是把"什么算对"定义清楚,剩下的让这个闭环自己去收敛。
这正好就是开头那篇文章讲的——如果你能验证一个结果,就等价于能给 AI 造一个环境让它去趋近。 90% 的手动验证,到这里就真的变成自动的了。
# 找到你自己的 90%
最后说几句。
今天这套前后端分离、回归测试,都是抛砖引玉。我不是想让大家照着我这样做,我更想让大家看见的是——为什么我们做出这样的技术决定。
说实话,前后端分离、回归测试,在很多技术博文里都有,为什么今天还要反复提?因为如果不是那 90% 的效率浪费把我逼到墙角,我可能不会做这个决定。
这套解法真正想让大家思考的是:在你自己的工程里,有没有类似的瓶颈?有没有正在悄悄吃掉你时间、让你觉得很烦躁、很重复的问题?如果有,用你自己的方式去解就好。
一年前大家还在争"要不要用 AI 写代码",你用了可能比别人效率高。今天没人争这个问题了,因为大家都在用。这时候你要想的是:你怎么用 AI,才能比别人效率更高?
如果你用 AI,原来十分钟做的事用了 AI 干了两个小时,结果还一样——那这不叫效率提升,叫本末倒置。
所以别把我说的这套解法当成"很好的事情",它对你来说可能一文不值。我想给的只是一种启发:看完之后,你回过头看看自己的工程,发现有没有类似的问题,脑子里如果有了新的解法,我就很开心了。
祝大家都能把属于自己的那 90% 的效率,重新拿回到自己手里。
## 相关链接
- [Ando](https://x.com/ando_w)
- [@ando_w](https://x.com/ando_w)
- [1.5K](https://x.com/ando_w/status/2074821901940056524/analytics)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [7:44 PM · Jul 8, 2026](https://x.com/ando_w/status/2074821901940056524)
- [1,552 Views](https://x.com/ando_w/status/2074821901940056524/analytics)
- [View quotes](https://x.com/ando_w/status/2074821901940056524/quotes)
---
*导出时间: 2026/7/8 22:47:56*