没有评估等于盲人摸象——不知道哪里好哪里差。评估的核心目的不是打分而是发现问题并定向优化。很多团队开发 Agent 时犯的第一个错误就是凭感觉判断好像效果还行。这是在赌运气。系统化的评估能告诉你三件关键的事哪里好、哪里不好、哪里需要改。一、评估的两大类端对端评估End-to-End Evaluation输入 → 输出的整体质量评估。给 Agent 一个问题看最终回答是否正确。优点简单直接能快速发现有没有用缺点只知道好不好不知道哪里不好——出了错你不知道是意图识别错了、工具选错了、还是生成阶段出了幻觉适用上线前的全面质检、持续集成中的回归测试步骤级评估Step-level Evaluation逐环节分析定位具体问题出在哪一步。Agent 搜索了错误的文档推理逻辑有误工具调用失败工具返回结果处理不当步骤级评估需要 Agent 具备可观测性——每一步的推理、工具调用、中间结果都要被记录。通过分析日志可以精确定位问题环节。优点精确定位问题便于定向优化缺点实现较为复杂需要 Agent 框架提供完善的日志和追踪能力二、评估指标指标说明测量方式准确性最终回答是否正确人工标注 / LLM-as-Judge完整性是否涵盖了所有必要信息检查清单比对效率消耗了多少 token 和时间Token 计数 时间追踪安全性是否执行了危险操作Hook 日志 安全审计鲁棒性面对异常输入是否稳定对抗性测试集LLM-as-Judge用 LLM 来评估另一个 LLM 的输出是目前最实用的自动化评估方式。关键设计原则给 LLM Judge 明确的评分标准——不要让它自由发挥使用对比评估而非绝对评分——让 LLM 比较两个输出哪个更好比让它打分更可靠多次采样取平均——单次评估有随机性多次取平均更稳定三、SWE-bench 评估基准SWE-bench 是专门评估代码修复能力的基准。给定 GitHub Issue让 Agent 修复 bug评估修复是否正确。Claude Code、Cursor 等产品都在用这套基准。SWE-bench 的工作方式从真实 GitHub 仓库选取 Issue给 Agent 完整的仓库代码 Issue 描述Agent 需要定位 bug、生成修复代码通过测试套件验证修复是否正确此外还有更多评估基准GAIA评估通用 AI 助手的多步推理能力ToolBench评估 Agent 的工具使用能力AgentBench跨 8 个场景的 Agent 综合评估四、工程实践建议先定指标再开发上线前就明确什么算好什么算不好。没有标准优化无从谈起。端对端做覆盖确保核心场景不出大错。准备 50-100 个覆盖主要场景的测试案例。步骤级做诊断出问题时定位到具体环节。建立完善的 Agent 运行日志系统。持续评估每次修改后重新跑一遍评估集防止回归。将评估集成到 CI/CD 管道中。人工抽检不可省自动化评估有盲区定期人工抽检能发现自动化评估发现不了的问题。