上个月，一个团队的朋友跟我说，他们在内部做了一次 Agent 能力评估。方式是让 Agent 跑 50 个真实的客服场景，然后让人工逐条打分。

结果出来之后，所有人都在争论一个问题：82% 的通过率，到底算好还是不好？

没人能回答。因为"好"没有标准。

这件事让我意识到一个问题：我们在疯狂地往生产环境里塞 Agent，但我们几乎没有一套可靠的方法来评价它到底干得怎么样。传统软件测试的那套方法论——单元测试、集成测试、端到端测试——在 Agent 面前，几乎全部失效。

传统测试为什么失效了

传统测试建立在一个核心假设之上：确定性。给定输入 A，系统必须输出 B。如果输出了 C，那就是 bug。

Agent 天然不满足这个假设。同一个用户问题，Agent 可能走完全不同的推理路径，给出不同的回答——而且两个回答可能都是"对的"。你怎么写断言？你没法写 assertEqual(agent.answer, expected_answer)，因为 expected_answer 本身就不唯一。

这还只是最表面的问题。更深层的麻烦在于：

Agent 的行为是涌现的。 传统软件的行为是开发者写的，每一行代码都有明确的意图。但 Agent 的很多行为不是被"写"出来的，而是在训练过程中"涌现"出来的。你没法通过审查代码来预测它在某个边界条件下会做什么——因为连模型的设计者也不一定知道。

Agent 的决策链不透明。 一个 Agent 在执行复杂任务时，可能会调用多个工具、进行多步推理。它的决策过程像一个黑箱——你看到输入和输出，但中间的推理路径你看不清。更麻烦的是，同一个 Agent 框架、同一个模型，换个 prompt 可能行为完全不同。你怎么回归测试一个随时在变的东西？

环境是开放的。 传统软件跑在受控环境里，输入空间是有限的。Agent 跑在真实世界，面对的是无限的可能性。用户可能用任何语言、任何格式、任何逻辑来提问。你不可能穷举所有场景。

业界在尝试什么

好消息是，有人开始认真面对这个问题了。

Supabase 最近发布了一套叫 Evals 的基准测试，专门用来评估 AI 编码 Agent 的能力。思路是让 Agent 在标准化的代码场景里完成任务，然后对比预期输出打分。有点像给 Agent 做一场标准化考试——题目固定，答案固定，分数可比较。

这个方向是对的，但 LeCun 最近转发讨论的一个话题点出了核心困难：AI Agent 的研究能力评估面临一个开放性问题。你很难设计一套 benchmark 来真正衡量 Agent 的"能力"——因为 Agent 的价值不只在于能不能完成特定任务，还在于它在多大程度上能处理意料之外的情况。

这就好比用高考分数来衡量一个人的工作能力。高考能测出你解题的能力，但工作里大部分挑战不是解题。

我自己这段时间用各种 Agent 做不同的事情——写代码、做调研、处理数据。有些场景效果惊艳，有些场景让人抓狂。但你要我准确说出它在哪些任务上靠谱程度有多高，我也说不出来。我的判断主要靠"感觉"，靠用了几个月之后形成的模糊直觉。

这不是工程化的做法。

我的实践思路

在没有成熟方法论的情况下，我在实践中摸索出了几个方向。不一定对，但至少比"凭感觉"靠谱一些。

分级评测。 我把 Agent 的任务分成三类：

• 确定性任务——有明确的对错标准。比如代码格式转换、数据提取、API 调用。这类可以用传统的通过/失败来评测。
• 半确定性任务——有合理范围但没有唯一答案。比如代码审查、文档生成、数据分析。这类需要用"质量区间"来评测，不是二元判断，而是打分。
• 开放性任务——答案高度依赖上下文。比如复杂推理、多步决策、创意生成。这类只能靠人工抽样评估，定期做，持续跟踪。

大部分团队把精力花在第一类上，因为最容易量化。但真正决定 Agent 价值的是后两类。你的 Agent 能不能写出一份靠谱的技术方案？能不能在用户描述模糊的情况下给出有价值的建议？这些问题没有 benchmark 能回答。

持续采样。 与其追求一次性评测，不如在生产环境里持续采样。我们现在的做法是每周从 Agent 的真实交互里随机抽取 50 条，让人工标注质量等级，跟踪趋势。不是科学的实验设计，但它能告诉你 Agent 是在变好还是变差。这比任何一次性 benchmark 都有价值。

边界管理。 给 Agent 画红线，比评测它的全能性更实用。明确定义 Agent 可以自主处理什么、什么需要人工确认、什么绝对不能做。然后在运行中持续监控，看 Agent 有没有越界。这其实是一种"运行时评测"——不等结果出来再评价，而是在过程中持续约束。

一个反直觉的结论

聊到这里，你可能期待我给出一个"正确的评测方法论"。但我想说的是一个更底层的判断：

Agent 不需要通过所有测试才能上线。它需要的是在它擅长的领域足够好，在它不擅长的领域被正确拦截。

传统软件追求零缺陷。Agent 追求的是可控的不完美。这两件事需要完全不同的质量观。

我见过一些团队花大量精力试图让 Agent 达到人类专家的水平，然后因为达不到而放弃。这个预期本身就是错的。Agent 的价值不在于替代专家，而在于让 80% 的常规任务被快速处理，让专家把精力集中在真正需要人类判断的 20% 上。

评测体系也应该围绕这个逻辑来设计——不是问"Agent 够不够好"，而是问"Agent 在它被分配的任务上，表现是否在可接受的范围内"。

这听起来像是降低了标准。但实际上，这是一种更诚实的质量观。它承认了 Agent 的局限性，同时最大化了它的价值。

Agent 评测是一门新的工程学科。就像十年前我们不知道怎么测微服务一样，现在我们也不知道怎么测 Agent。但有一点是确定的：如果你现在就开始建立评测习惯，哪怕是最粗糙的，你也比大多数团队领先了。因为据我了解，大部分团队的 Agent 评测方法就是——"出了事再说"。