做 AI Agent 这一年，我越来越不相信“单次演示成功”。

因为演示的时候，大家看到的通常都是最顺的那一次：

• 提问足够清楚；
• 上下文正好干净；
• 工具刚好选对；
• 参数刚好填准；
• 执行路径没有歪。

可一旦进入真实使用，问题就会完全不一样。

用户会连续追问、改条件、换资料、重试、撤销、重做，还会在一句话里夹带多个意图。这个时候，决定 Agent 好不好用的，就不再是“它有一次回答得多漂亮”，而是：

它能不能在一整套真实任务里持续做对，而且别乱来。

最近我把两组模型塞进同一套 Agent 里，按同样的任务、同样的约束、同样的工具、同样的回归方式反复跑，结果比我想象中更有意思。

• DeepSeek：120/120 strict 通过；
• Qwen：114/120 strict 通过。

如果只看这个数字，最容易得出的结论是“DeepSeek 更稳”。

但我真正想写的，其实不是一篇模型“输赢榜”，而是：

一个 AI Agent 到底该怎么测，才不会被漂亮 Demo 骗过去。

一、为什么单次成功几乎没有参考价值

如果一个 Agent 只跑一次，很容易出现一种错觉：它好像已经能用了。

比如：

• “帮我把这段内容整理成笔记”——成功；
• “帮我创建一个待办”——成功；
• “帮我根据资料回答问题”——成功。

看起来都能跑。

但真正麻烦的地方，是这些动作一旦进入连续使用后，错误不会以“彻底坏掉”的方式出现，而会以一种非常像“偶发 bug”的方式慢慢暴露出来：

• 明明该读 A，它却顺手把 B 也带进来了；
• 明明只该提草稿，它却直接想写正式内容；
• 明明工具选对了，参数却差一点；
• 明明回答看起来还行，但执行路径其实越过了安全边界。

这类问题最烦人的地方就在于：

它们并不一定让页面报错，也不一定让结果完全失败。

有些甚至在第一次看时“像是成功了”，但从系统层面看，它已经是不该接受的结果。

所以我越来越觉得，Agent 测试最重要的一件事，就是把“看起来差不多对”这件事彻底剔掉。

二、我后来更重视的，不是模型会不会答，而是它会不会守约

很多人测试模型时，习惯先看它会不会说、会不会总结、会不会推理。

这些当然重要。

但放到 Agent 场景里，我后来更在意的是另一组问题：

1. 它有没有选对动作

该回答时回答，该查资料时查资料，该生成草稿时生成草稿。

2. 它有没有保持边界

只让它看这轮允许看的资料，它就不该顺手把别的资料也一起算进来。

3. 它有没有“多做一步”

这是很多 Agent 最危险的地方。

用户也许只想让它整理一下，它却直接试图执行写入操作；
用户只是想要一个建议，它却往前多走了一步。

4. 它在重复运行时会不会漂

一轮跑对不难，连续跑很多轮还都稳定，才是真正有意义的结果。

也就是说，Agent 最需要测的，不是“智力有多高”，而是“遵守契约的稳定性有多高”。

三、为什么我更愿意看“重复 20 次”的结果

单次成功永远是最会骗人的。

很多概率性问题，在第一次第二次都不一定出现，
但当你把同一个任务反复跑很多次时，差异就会开始显现。

这也是为什么我越来越认同一种更接近工程现实的做法：

• 不是“跑过一次就算通过”；
• 而是同一类任务要重复跑；
• 不只看均值，还要看最坏情况；
• 不只看成功率，还要看失败类型。

因为真正决定线上体验的，常常不是平均分，而是那些低概率但高伤害的问题。

比如：

• 多调了一次工具；
• 多走了一次写入链路；
• 带入了不该带入的资料；
• 在某一轮里突然出现范围外执行。

这些都不是“有一点小误差”这么简单。

它们更像是：

只要发生一次，就足以让用户不敢继续信任这个 Agent。

四、从这次结果里，我真正学到的不是“谁赢了”，而是该怎么选模型

如果只从最终结果看，DeepSeek 120/120，Qwen 114/120，差距并不夸张。

但如果站在产品交付角度，这 6 个点其实很关键。

因为很多时候我们上线模型，不是在选“哪个更会聊”，而是在选：

• 哪个更值得放进真实工作流；
• 哪个更适合接你的工具链；
• 哪个更不容易在边界问题上出事；
• 哪个更适合承担连续交互压力。

所以我现在会把模型选型优先级改成这样：

第一优先级：有没有灾难性失败

只要一个模型更容易出现“本不该发生的执行”，那它就算便宜、快、会说，也很难成为放心的选择。

第二优先级：是否稳定复现正确路径

能不能 20 次、30 次、更多次都维持正确，不要漂。

第三优先级：再去比较延迟和成本

在安全和稳定没过线之前，谈延迟和成本其实意义不大。

这也是我现在看模型的一种变化：

以前我先问“它聪不聪明”；
现在我先问“它靠不靠谱”。

五、为什么很多 Agent 项目会卡在“演示很好，落地很难”

我现在越来越觉得，很多 Agent 项目的瓶颈，并不是模型本身，而是团队还在用“聊天产品”的方式看待它。

聊天产品里，一次回答不完美，用户还可以继续问。

但 Agent 不一样。

Agent 一旦开始接工具、接资料、接执行链路，它就进入了一个更严肃的环境：

• 会不会读错；
• 会不会选错；
• 会不会多做；
• 会不会连续漂移。

这时候，光靠 Prompt 微调是远远不够的。

你必须把它拉进一套真实的评测框架里，像测一个正式系统一样去看它。

我觉得这也是 Agent 从“看起来有趣”走向“真正能用”的分水岭。

六、如果你也在做 Agent，我会建议你至少先做三件事

1. 不要只留 happy path

最该测的不是最顺的那条路，而是那些最容易出边界问题的场景。

2. 不要只跑一次

重复性测试越早做，后面越少踩坑。

3. 把失败分级

不是所有失败都一样。

有的是表达不佳，有的是参数错误，有的是严重越界。

如果不分级，很多真正危险的问题会被平均分掩盖掉。

结语

这次把两个模型放进同一套 Agent 跑完之后，我最大的感受其实很简单：

一个 Agent 最值钱的，不是它最好的那一次，而是它能不能把正确的事稳定地做很多次。

所以我现在看任何 Agent 演示，第一反应都不再是“它这次做得挺好”，而是：

• 同样的任务再跑 20 次会怎样？
• 它有没有低概率高风险的问题？
• 它的边界到底是模型懂的，还是系统守住的？

真正让 Agent 走向可用的，不是更花哨的演示，而是更诚实的测试。

参考开源仓库：https://github.com/VeteranBoLuo/light-note