Gartner上周发了个预测：到2029年，70%部署了生产级Agentic AI的组织会遭遇"重大意外事件"。这个数字一出来，我第一反应是——才70%？

不是说Gartner保守。是我见过太多团队上线Agent的方式了：跑个demo，老板拍板，两周接入，宣布成功。至于Agent上线之后到底干得怎么样，大部分团队的评估方式就是——"没出大事就行"。

这其实催生了一个很少被讨论、但越来越值钱的能力：会评判Agent做得好不好。

会用和会评，差了一个层级

今年写了好几篇关于AI工具的文章，从采纳数据到成本建模都聊过。但有一个角度一直没展开：大部分人讨论的是"怎么用Agent"，很少人讨论"怎么判断Agent用得对不对"。

这两个能力看着像一回事，其实差别很大。

"会用"是操作层面的——会写prompt，会接API，会把Agent塞进工作流。这些能力正在快速贬值，因为工具本身在变简单，今天需要调半天的东西，明年可能一键搞定。

"会评"是判断层面的——你得知道Agent的输出在什么场景下可信，什么场景下是"看起来对但实际在瞎编"。你得能设计评估场景，不是跑个benchmark就完事，而是把业务中真实会遇到的边界case拆出来，一个一个验证。

前者正在被工具本身替代。后者目前还没有任何工具能替代。

那个83%的坑，我们踩了三个月才发现

说个具体的事。

之前了解过一个团队的AI客服上线过程。他们花了大概三个月把Agent接进了工单系统，上线后第一周数据很好看：自动解决率83%，用户满意度4.2/5。全组庆祝，觉得这事成了。

第二周开始出问题。有用户反馈说Agent给的操作路径是错的——比如某个功能入口改版了，但Agent还在指旧路径。用户照着走，走不通，再来问人工客服。人工客服一看记录，Agent确实回答了，回答得"很自信"，但内容是过期的。

更要命的是，这种case在数据里看不出来。用户满意度还是高——因为大部分简单问题Agent确实处理得不错。只有那17%的复杂问题，Agent在"很自信地给出错误答案"。而这个17%，恰好是业务影响最大的那批问题。

发现这个问题花了将近两周。不是因为数据有问题，而是因为没有人设计过"Agent回答错误但看起来很对"这种评估场景。大家评估的时候测的都是"Agent会不会说不知道"，没想到还有一种失败模式是"Agent说得像真的一样，但完全是错的"。

后来他们加了一轮"反向验证"——每个Agent回答都让另一个独立的评估流程去核实关键信息的时效性。光是这一件事，就把所谓的"自动解决率"从83%打到了61%。

61%才是真实数字。83%是一个让人安心的幻觉。

评估能力为什么难替代

这个事让我后来一直在想一个问题：评估能力为什么这么难被自动化？

想来想去，我觉得有三个原因。

第一个是业务上下文。同样是"用户问怎么退款"，在金融场景和电商场景的评估标准完全不同。金融场景你宁可让Agent多说一句"请咨询人工"，也不能让它给出一个可能涉及资金操作的错误指引。这种判断需要对业务风险的深度理解，不是跑评测集能替代的。

第二个是场景设计。好的评估不是跑100个case看通过率，而是设计出那10个最容易出问题的case。这跟测试工程师的价值有点像——值钱的不是写测试脚本，是知道哪些边界条件最容易漏。但Agent的评估比传统测试更难，因为LLM的输出不是确定性的，同一个问题问两次答案可能不一样。

第三个是识别"看起来对的错误"。这是最难的。Agent说错了但不明显的那种错误，比直接说"我不知道"危险得多。识别这种错误需要评估者本身对业务有足够的判断力——你得知道正确答案长什么样，才能看出Agent的回答哪里不对。

这三样东西加在一起，构成了一个不太容易被工具化的能力组合。

a16z那个数据，换一种读法

前阵子a16z那份AI消费报告，大部分人关注的是"前1%用户月均花903美元，中位数只有25美元"这个差距。但我后来注意到另一个数据点：在已经上线Agent的企业中，有系统化评估流程的不到15%。

也就是说，85%的团队是"先上线再说"。

这其实是个挺有意思的职业机会窗口。当所有人都在学怎么"用"Agent的时候，会"评"Agent的人极度稀缺。而且这种稀缺不是暂时的——因为评估能力依赖于对业务的深度理解，不像工具操作那样看个教程就能学会。

Gartner那个70%的预测，在我看来，根因不是技术问题，是组织能力问题。大部分组织的"AI团队"里，有工程师、有产品经理、有数据分析师，但没有专门的"评估角色"。Agent上线后的质量评估，通常是工程师顺手做，或者产品经理凭感觉判断。

这跟十年前安全工程师的处境有点像。大家都知道安全很重要，但安全评估这件事一直没人专门做，直到出了足够多的事故，才催生了专门的安全团队。

Agent领域可能也要走同样的路。只不过这次的"事故"不是数据泄露，而是"Agent在核心业务流程中给出了看起来很对的错误输出"——这种事故更隐蔽，发现成本更高。

一些不太成熟的想法

写到这里，我其实也没有一个很确定的结论。评估能力到底应不应该成为一个独立的角色？还是说它应该是每个技术人的基础能力？我自己也还在想。

但有一点我比较确定：当"会用Agent"变成所有人的标配技能时，差异化的竞争力不在于你用得多熟练，而在于你能不能判断Agent的输出是否可信、是否安全、是否真的在解决问题。

这个判断力不是学某个工具能学出来的。它来自于对业务的理解、对失败模式的经验、以及对"看起来很对"保持警觉的习惯。

上周跟一个做测试的朋友聊，她说了一句让我印象很深的话："以前我的工作是找bug，现在我的工作是找那种不是bug的bug——就是系统觉得没问题，但业务上确实错了的那种。"

可能这就是下一个阶段技术人最值钱的地方。不是会做事，是会判断事做得对不对。