我做 AI Agent 一年,90% 在做表面功夫——直到我换了思路

Hello，大家好啊！

我统计了一下， 我最近做AIAgent开发的 时间， 结果发现了 一件不太对劲的事情。

我真正花在写代码、 做设计上的 时间只有百分之十， 剩下的百分之九十全都耗在了 同样一件事情上， 手动测试。

我得点开网页， 输入想要测的数据集， 盯着Agent， 一步一步地跑， 然后用人脑去判断这次它到底是变好了 还是变坏了， 而且这还不是最麻烦的呢。

最麻烦的是， AIAgent这个系统本身就不确定， 是吧？

我有的时候只想改一个很小的 行为， 结果改了一句prompt， 它就崩掉了。

更让人没底的是， 很多时候我连它到底有没有真的 坏都没有办法一眼看出来， 那我只能再跑一遍， 再跑一遍， 再跑一遍。

然后感觉它到底是不是对的。

到这一步， 我得工作其实已经不是在写代码， 而是反复地手动地 去验证一个连我自己都有点快看不懂的 系统， 这正常吗？

啊， 有没有一种办法能够把这百分之九十的 时间变成一套可重复， 不需要我守在屏幕前一遍一遍点的 自动化体系？

来， 今天我们就来聊一聊， 到底是如何让AIAgent的 开发省去这百分之九十的 时间的。

欢迎大家收看我们今天新一期的视频。

那在聊我们怎么改进它之前， 其实我首先确认了 一件事情，啊， 这到底是不是我一个人的痛点， 是不是我一个人碰到的问题？

啊，其实不是啊。

在二零二五年， OpenAIMeta的 研究员JasonWei就提出了 一个概念啊， 他观察到一件事情， 叫做验证的不对称性， 意思是有很多任务做出来很难， 但是验证它做得 对不对却很容易。

那顺着这个他给出了 一条定律， 叫做verifier's'rule， 啊， 就是任何可解且易于验证的 任务终将被AI解决。

那这件事情跟我的 那个百分之九十到底有什么关系啊？

我之所以百分之九十的 时间在验证， 恰恰就是因为对于我们所构建的 这个AIAgent来说， 生成变得很便宜， 但是验证还很贵， 这就是那个不对称。

也就是说， 如果我能把判断这个Agent做得 对不对这件事情， 从一个靠肉眼靠感觉的难题， 变成一道自动的 可重复的验证体系， 那我其实就是把一个难验证的 问题亲手改造成一个容易验证的 问题。

一旦它变得容易验证， 按照这条定律， 剩下的就应该交给AI了， 那我的角色就变成了 如何去制造这个可验证的架构。

这个话听起来其实很抽象啊， 但其实在另外一个行业， 三十年前就做过 同样的事情了。

而这个行业就是我现在正在从事的 行业， 芯片的设计与验证。

我先讲一个你可能没有想到过的冷知识啊。

写芯片代码的 人往往比验证芯片代码的 人要少。

在芯片真正流片之前， 花在验证上的人力， 啊， 经常是设计的两倍、 三倍或者更多。

为什么会这样？

因为芯片一旦流片， 啊，如果出错， 那就是几百万美金直接打水漂， 啊， 没有改一个Bug， 重新部署一下这种好事儿， 呃， 所以整个行业被现实倒逼着， 把大部分的精力压在了 同样一件事情上， 就是想尽一切办法把所有可能的 Bug全部都找出来。

而干这件事情的核心， 其实不是说你会写芯片代码就行了， 啊， 你是要去会设计、 验证的体系， 你怎么样去设计一套回归测试， 主动把Bug暴露出来， 在哪些地方埋下检查点， 又怎么样去衡量自己到底测得 够不够全。

讲到这儿， 你大概已经发现， 这跟我们今天做AIAgent的 开发几乎是同样一个形状。

当AI把写代码变得越来越便宜， 就像当年的EDA工具， 让写Verilog这件事情变容易了 一样， 你的价值就不仅仅在设计上面了， 它出现了一套新的价值点， 你能不能设计出来一套体系， 让AI的 每一次改动都可以被验证？

那么我具体是怎么给予我们自己的 AIAgent， 把这件事情做出来的呢？

第一步可能跟你想的 有点不太一样啊， 我要做的第一件事儿， 不是写测试， 而是把我们的 AIAgent改造成一个对别的 AIAgent友好的系统。

我解释一下啊， 我手上其实有两套里统， 一个是我们自己写的 那个AIAgent， 另一套呢， 是我用来写代码的 Coding工具， 比如说Codex啊。

那我之前测试为什么那么痛苦？

因为我那套系统的 入口是一个网页， 是一个UI， 是给人用的， 要测它， 就得有个人在那儿点一下， 输一下，是吧？

那从第一天起， 它就是为人的 眼睛和手去设计的。

现在大家都在讲面向AIAgent的 开发， 这件事情的 真正核心在于三个问题啊。

第一， 你的系统在脱离了人的 眼睛和UI之后， 它还能跑得起来吗？

第二， 它运行的过程中， 那些中间状态有没有留下足够的 信息， 让另外一个AIAgent能看懂？

第三， 你有没有专门设计接口， 让AI能够自主地 去拿到这些信息？

举一个具体的例子啊， 我们在运行一个AIAgent的 时候啊， 我需要让Codex能够看到整条 workflow长什么样， 中间调用了哪些工具， 每一步拿回了什么数据。

如果这些信息一旦离开UI就消失， 或者说整个workflow离开UI， 它就停止， 后端就瘫了。

那只能说明我们这方设计的 接口到现在为止还是为人去设计的， 不是为了AI去设计的。

啊，那么怎么改啊？

其实有两条比较现成的路， 一条呢就是说， 啊， 那我们调用MCP是吧， 模拟网页的操作， 模拟人的操作， 让AIAgent直接去读你的 网页啊， 靠多模态去进行一个观察。

那另一条呢， 就是把前后端彻底拆开啊， 后端变成一个能独立运行的 AIAgent。

所有的调用都能做成命令行的控制形式。

前端的退到一边， 只负责把后端的信息这个监控 出来给人们去看啊， 让人进行操作。

我选的其实就是第二条路啊。

前后端分离。

啊，原因是在于， 我用MCP， 我的确能够看到网页上面的 一些操作， 但是呢， 在这个authorization呢， 或者在一些具体的 cornercase， 包括效率上面， 啊， 没有前后端分离来得这么直接， 来得这么快。

而且说实话啊， 就是做前后端这一步啊， 我们也花了不少力气。

呃， 原因在于我们之前其实是重度使用了 这个Vercel的 AISDK， 它在最开始用的 时候的确很好用， 但是在前后端分离这件事情上， 你的确是需要花一些工夫才能 把它做到一个比较好的程度。

啊， 我们把它变成了 一个能脱离前端， 然后自己在后台长时间稳定跑下去的 这样的一个系统， 是吧？

而做完这一步， 我们再回过头去看是吧， 有没有人跟我们踩了 一样的坑呢？

普林斯顿的 这个SWEAgent， 那篇论文里面提到过 一个概念叫做Agent ComputerInterface， ACI啊， 他们的观点就是说， AIagent是一类全新的 用户， 他和人不一样， 所以你得专门给它设计接口， 而且呃， 这个实验的结果发现， 接口设计得好不好， 对于agent的 表现影响甚至大过 你换一个更强的模型。

所以我们每天听到面向AIagent的 编程， 面向AIagent的服务， 它的核心从来不是某一个具体的 技术啊， 其实是在于你所做的 这样的一个东西， 能不能被另外一个AI， 或者说是简单一点， 能不能够被Codex快速地 主动地拿到它需要的信息。

做完了前面那步， 接下来就很直接了， 我们要开始构建测试。

说穿了， 它就是一个回归测试啊， regressiontest。

概念不复杂， 复杂的是怎么样为一个不确定的 系统去构建它。

啊，在这里方， 我就拿我们给AIagent加功能来举例。

当我想要给AIagent新加一个工具的 时候， 我心里其实是有一个明确的 预期的， 比如在什么条件下， 啊， 这个工具会被触发。

触发之后，啊， 整个AI的 工作流又应该怎么走。

啊， 那这个我期待它怎么走的路径， 我们把它叫做快乐路径啊， Happypath， 它就是一个新功能的 验收标准。

从架构上来说， 我们要先解决一个棘手的问题， 谁来当裁判？

agent的 输出是一大段自然语言， 啊， 是一条运行的路径， 它不是一个直接相减的数字， 所以传统那种过 或者不过啊， 这种分类的 系统其实是不够用的。

我的办法是把这个裁判呐， 拆成两层， 能确定地交给确定性的 裁判啊， 那些模糊的交给AI裁判。

那这个第一层呢， 就是确定性的 断言assertion。

这一层其实就是一组硬性的检查， 比如说跑这个测试的时候， 工具是否触发呀， 跑到某一步的时候， 这个中间状态啊， 有多少条记录呀， 覆盖到那些情况呀。

这层的特点就是它绝对可靠啊， 然后确定性并且零成本。

第二层呢， 就是一个LLM的裁判啊， 我把它叫做Supervisor， 它是专门处理第一层那些卡不住模糊的 部分。

那这方有几个关键细节啊， 这个大语言模型的 上下文必须是干净的啊， 它不参与任何的开发， 它不知道你代码的 来龙去脉， 它的这个眼睛里面只有对正确的 预期啊。

而第二点呢， 然后面对那些没有标准答案的 输出， 我们不让它去判断对和错， 而是让它去做一个量化的打分， 通过分数去判断最终的 结果是好了多少， 差了多少。

那如果你做过芯片的验证， 其实你觉得整套系统还是比较眼熟的， 比如说，呃， 我们借用了 这个assertion的概念， 借用了coverage的 概念啊，借用了 Scoreboard的概念， 只不过相比于硬件来说， 这个AIagent它本身就存在一定的 模糊替代， 存在一定的不确定性， 所以它对于这种不确定性的 容忍程度要更高一点。

那解决了谁来当裁判的 问题之后呢， 第二步啊， 就是不停地攒案例。

上面我们做的 事情是基于这个Happypath， 快乐路径进行的开发。

那我开发的功能越多， 是吧， 我就慢慢慢慢把这些Happy path能够一条一条地 固化除此之外呢， 我们可以从真实的用户， 从测试里面去捞那些我们自己 根本就没有设计过的， 五花八门的输入， 啊， 把它们放到我们的这样的 一个测试机里面。

那么， 这两类回归测试啊， 能够保证我们的 系统在不停更改的状态下， 依旧没有退步， 啊， 同时保证尽量地没有盲区。

还有一个我自己觉得特别关键的 实践就是， 每加一个新功能， 我都会给它配一个开关， 一个flag， 有了开关我就有这个开和关的 两个版本， 当它们去跑同样一套回归测试的 时候， 我就能够清楚地 看到新功能到底带来了 什么东西， 哪些变好了， 哪些被悄悄地弄坏了。

那有了上面这一套架构之后， 最妙的一步来了， 我们如何把这一切形成一个闭环？

我们可以在Codex 里面去做这样一件事情， 就是当它需要开发新的 功能的时候， 它不仅仅考虑这个代码怎么写， 它需要首先先去设计回归测试， 其次去设计这样的 一个开关， 然后呢， 去进行代码的编写， 编写完之后， 再开关开开关关闭的时候，同样地 去跑一遍这样的

一个回归测试，通过回归测试的 结果进行一个反馈， 再去修改代码，直到最终的 代码改成能够符合回归测试要求的 这样的一个版本。

那在整个这样的 一套体系里面， 人是没有参与的 ，而Codex这种coding agent通过我们设计的 这种可验证体系， 把这一切都连成了 一个闭环，那到这一步你会 发现我们已经不再写代码， 我们也不再手动测试， 我们做的 就是把什么算对定义清楚，剩下的 就是这个闭环自己在收敛。

而这正好就是我们开头那篇文章所讲到的 ，如果你能验证一个结， 就等价于能给AI造就一个环境， 让它去趋近。

百分之九十的手动验证， 到这里就真的变成自动的了。

那最后聊一下， 就是今天我们做的 这套前后端分离回归测试， 其实都是抛砖引玉啊。

我并不是想让大家说， 你照着我这个东西这样做，我更多的 是想让大家看见，为什么我们做出这样的 技术决定。

说实话， 像前后端分离回归测试，在很多的 技术博文里面都有，为什么 我们今天还是要反复去提？

我们想让大家看见的， 是为什么我们做出这样的 技术决定啊？

如果不是那个百分之九十的 效率的浪费， 把我逼到了墙角， 是吧， 我觉得我可能不会做这样的 技术决定。

所以，这套解法真正想让大家思考的 是，在你自己的 工程里面，有没有类似的瓶颈？

有没有正在悄悄吃掉你的时间， 或者说让你觉得很烦躁很重复的 问题？

如果有，你用你自己的方式去解就好啊。

一年前， 大家都在争， 是吧， 我要不要用AI写代码？

你如果用了AI写代码， 你可能比别人的效率高。

在今天，没有人争这个问题了， 因为大家都在用。

那这个时候你需要思考的 是，你怎么样使用AI才能比别人的 效率更高啊？

如果说你用这个AI， 原来十分钟做的 事情，你用了AI干了 两个小时，结果是一样的， 那这个地方没有效率的提升， 是吧？

你用了AI效率反而下降了， 这就是本末倒置啊。

所以，不要把我说的 这样一个解法就当做是， 哦，是很好的一件事情， 它可能对于你来说一文不值。

哦，我想给的只是一种启发。

你看完我们的视频之后， 哎， 你能够回过头去看看你自己的 工程，啊， 去发现有没有类似的问题， 然后你脑子里如果有了 一些新的解法，哦， 我就非常的开心， 好吧。

所以祝大家都能把属于你的 那百分之九十的 效率重新拿回到自己的手里。

那以上就是我们这期视频的 全部内容， 如果你觉得我们的 视频做得还不错的话， 那欢迎点赞收藏转发订阅评论我们的 频道， 这对我们来说非常的重要。

感谢你的收看，祝你学习顺利！