这篇回答一个判断题而非操作题，给不上评测就盲改的团队一个明确的理由。
最值得拿走的是 Agent 失败的三形态：单步错误静默累积、非确定性让复现困难、多步链路级联放大——三者叠加使得「改了一版感觉变好了」成为工程上不可接受的说法。评测集的价值是让迭代从辩论变成测量。最容易省掉评测的时机恰是项目早期，省下的几天会在后面每次改 prompt 时加倍还回去。
相比站内的评测方法长文，这篇聚焦「为什么」，并连接到 Agent 上线前的整体检查。补充一个团队文化层面的判断：评测的意义不在工具而在纪律，它要求团队接受「没有测量就没有发言权」；这个共识立起来之后，评测才会从成本项变成复利资产。再补一个对客户的沟通建议：把评测集的建设写进项目计划的第一周交付物，让它成为合同层面的约定，而不是团队的自我要求，执行阻力会小很多。
读完建议做一件事：为当前 Agent 项目先建三十条评测用例，覆盖三类失败形态各十条。
—— FDEChina编辑部 · 实战派
Agent 项目为什么必须做评测？
直接回答：因为 Agent 的失败方式与普通软件根本不同——它是静默的、非确定的、会级联的。普通应用出了 bug 会报错、会崩溃，你能看见；Agent 出了问题往往不报错，它只是安静地给出一个看起来合理但错误的结果，或者多绕了五步把任务做偏。没有评测集，你既发现不了这些问题，也无法在迭代时知道自己是变好了还是变坏了。
展开看三类失败形态。第一，静默累积：一个 Agent 任务由十几步组成，检索错一点、参数填偏一点、工具选错一次，单看每步都不算大错，串起来结果就不可用，而中间没有任何报错。第二，非确定性：同一个输入跑两次，路径可能不同，你修好的问题下次可能以另一个面目复发，没有固定评测集就无法判断修复是否真的生效。第三，级联放大：多 Agent 或长链路系统里，上游一步的偏差会被下游放大，最终输出的质量崩塌点离根因很远，靠人工盯是盯不住的。这三条决定了 Agent 交付的迭代方式只能是对着评测集测量，而不能是「改了一版感觉更好」。
评测集在实践中的价值远不止「测准不准」。它是团队沟通的锚：客户说效果不行，你们先对评测集用例逐条看，分歧立刻具体化。它是回归的保护网：每次改 prompt、换模型、调工具，都重跑一遍评测，防止按下葫芦浮起瓢。它还是商誉的证明：交付验收时，拿得出评测报告的一方在谈判桌上完全不同。完整的方法论见 Agent 评测方法与 能落地的 LLM 评测，回归机制的具体设计见 评测回归模式。
从零开始的最小路径也并不重：先从真实业务里挑三十到五十条有代表性的输入，人工写下期望行为，形成第一版评测集；每次迭代前后重跑，记录通过率变化；随着项目推进逐步扩充边界用例。这件事在项目第一周就该做，而不是上线前补——最常被省掉评测的时机恰恰是早期，省下的几天会在后面每一次改动时加倍还回去。上线前的整体检查见 Agent 上线清单，更大局的分析见 你的 AI 产品需要评测。