先记住这个答案
在开发前定义成功标准，是把模糊的智能助手需求变成可检查的产品行为。可以先从少量真实任务建立样本，写明初始条件、允许范围、预期产物和失败条件，并准备一个能通过检查的参考结果。这样简单实现也能建立基线，后续增加工具、记忆或规划时，可以看到成功率和成本的实际变化。评估集应持续扩充，但不必等到规模很大才开始验证。
- 任务契约包括输入、环境、允许范围和验收证据
- 先证明评分器接受正确结果并拒绝已知错误
- 保留未参与日常调优的样本，检查泛化与回归
把产品承诺写成能分辨对错的条件
例如用户希望 Agent 为项目补测试，完成条件不能只写生成了测试文件。应检查测试能运行、覆盖目标行为，并且面对一个已知缺陷能够失败。否则 Agent 可能创建永远通过的断言，看起来工作完成却没有实际保护。
任务要求与评分条件要一致。如果产品允许合理文件命名，评分器就不该暗中要求某个固定文件名。先用人工构造的正确结果跑通检查，再加入几个明显错误的产物，能及早发现评分器过严或过松。
用少量真实场景建立基线
可以从团队反复手动检查的任务开始，覆盖一个常规场景、一个信息缺失场景和一个不应执行动作的场景。样本数量应随任务差异增长，重点是暴露不同决策边界，而不是把同一句请求换词扩成大量近似题。
用最简单可工作的实现跑基线，记录结果、工具调用、耗时和失败原因。之后新增记忆检索或多阶段规划时，比较是否解决了原先的失败，也检查是否使简单任务变慢。没有基线，就容易把系统更复杂误认为能力更强。
让评估随产品演进但保持可比较
新故障可以转成回归样本，新增能力可以建立更难的任务。应记录样本和评分器版本，口径改变时重新跑基线，而不是直接比较不同集合的总分。还要保留部分未被反复用于提示调整的样本，减少只针对已知题目的优化。
对现实中含糊的请求，可以先明确哪些行为允许自主决定，哪些必须等待信息。评估不是替产品随意发明规则，而是暴露规则缺口并形成一致约定。上线后仍需观察真实用户结果，离线样本不能覆盖所有环境变化。
容易答错的地方
- 等 Agent 完整做完再考虑评估
- 此时往往只能按已有实现反推标准，难以发现架构一开始就没有满足的用户需求。排查“AI Agent 开发前定义成功标准与评估集”时还要核对输入、版本和执行顺序，并用反例确认修复后的边界。
- 只放应该调用工具的例子
- 这样可能把每个请求都调用工具优化成高分，需要加入已有信息足够、对象不明确或条件不满足的反例。
面试官还会怎么问？
一开始没有真实用户记录怎么办？
围绕明确产品场景构造可复现任务，并让了解业务的人验证要求和参考结果；上线后再用真实失败补充。
参考答案必须和 Agent 输出完全相同吗？
不必。参考结果用来证明任务可解，评分应接受满足要求的其他实现，除非格式本身就是契约。针对“AI Agent 开发前定义成功标准与评估集”，还应保留最小复现、预期结果和失败路径，避免只凭一次现象下结论。
小评估集能证明系统可靠吗？
它能发现具体问题和较明显的变化，但不能证明广泛可靠性。随着任务类型和风险增加，需要扩大覆盖并报告样本限制。
参考资料
示例用于理解所注明的运行环境与边界；延伸学习可结合原文中的更多案例。