评估优先：Agent 工程的压舱石

做 Agent 项目做久了，你会发现一个事实：评估才是真正的瓶颈。

不是模型不够强，不是框架不够好，不是 Prompt 不够精——这些东西都能迭代。但如果你没办法回答”这次改动到底变好了还是变差了”，所有迭代都是盲人摸象。

我见过太多团队踩这个坑：Agent demo 跑得很炫，上线后体验一路下滑，团队反复改 Prompt、换模型、调参数，折腾几个月说不清楚到底有没有改善。问题的根源不是技术能力不够，是从第一天起就没把评估当回事。

为什么评估是压舱石

压舱石的作用是让船稳。Agent 系统的不确定性太强——同一个输入跑两遍可能出不同结果，换一个模型版本行为全变，改一句 Prompt 触发连锁反应。没有评估体系兜底，系统就是在飘。

评估解决三个核心问题：

1. 你知道现在是什么水平吗？

没评估，你不知道。团队讨论”Agent 效果怎么样”，全凭感觉。产品说”好像还行”，开发说”我觉得没问题”，用户说”不太好用”。三个人三个判断，没共识。有了评估基线，至少大家在同一个事实层面说话。

2. 你知道改动有没有用吗？

Agent 开发是高度实验性的。今天改了检索策略，明天调了工具调用逻辑，后天换了个模型。每次改动都可能同时改善某些场景、恶化另一些场景。没有评估，改了等于白改——你既无法证明改对了，也无法发现改坏了。

3. 你知道问题出在哪吗？

Agent 出问题的地方很隐蔽。不是报错，而是”看起来对了但其实错了”——检索到了无关文档但模型硬编了个看似合理的回答，工具调用参数差了一个字段但恰好没触发异常。好的评估能拆到具体环节，告诉你到底是检索的问题、理解的问题、还是生成的问题。

评估方法设计：不是找个指标那么简单

很多人理解的评估就是”找个分数算一下”。任务完成率、准确率、BLEU、ROUGE——挑几个算一算，出个报告，完事。

这种做法对传统软件够用，对 Agent 远远不够。Agent 的评估方法设计，本质上是在回答”什么算好”，而这个答案因项目而异。

从终态倒推

评估方法不是从指标出发，是从业务终态出发的。

客服 Agent 的终态是用户问题被解决。那就定义清楚什么叫”解决”：用户没再来投诉？用户在对话结束后点了满意？人工质检员判定对话有效？这三件事不完全等价，你得选一个（或组合）作为 ground truth，然后围绕它设计评估。

代码 Agent 的终态是代码能跑且功能正确。评估就不是看生成代码的文本质量，而是实际运行——编译通过率、测试通过率、功能验证通过率。文本再漂亮的代码跑不起来就是零分。

从终态倒推，才能避免评估和实际目标脱节。

多层评估，各管一段

Agent 系统是分层的，评估也得分层。一个完整的 Agent pipeline 通常包含：

• 输入理解层：意图识别、实体抽取、槽位填充
• 检索/工具选择层：找到相关信息、选对工具
• 推理规划层：分解任务、规划步骤
• 输出生成层：组织语言、格式化结果

每层的评估方法和指标不同。输入理解看准确率和召回率，检索看 Precision@K 和 MRR，工具选择看匹配率，输出生成看事实一致性和用户满意度。

另外有一个专项维度容易被忽略：安全性评估。Agent 有工具调用能力，越狱抵抗、Prompt 注入防护、有害输出拦截这些都需要专门的测试 case。安全评估的优先级在某些场景下（面向 C 端、金融、医疗）甚至高于功能评估。

分层评估的好处是能定位问题。如果整体指标下降了，你能快速知道是哪个环节出的纰漏，而不是对着一个笼统的”效果变差了”无从下手。

LLM-as-Judge 的位置

LLM-as-Judge 这两年很火，也确实有用——很多评估维度（事实一致性、语气得体性、逻辑连贯性）很难用规则或传统 NLP 指标衡量，用大模型当裁判是个务实的选择。

但 LLM-as-Judge 不是万能的，它有自己的毛病：

• 位置偏见：倾向于偏好第一个出现的选项
• 冗长偏见：倾向于给更长的回答打高分
• 自我偏好：某些模型倾向于偏好自己生成风格的文本
• 一致性不稳定：同一个 judge 模型，换一下 Prompt 格式，打分就可能变化

务实的做法是把 LLM-as-Judge 当作评估工具箱里的一种工具，而不是唯一工具。关键维度上配人工标注做校准，定期检查 judge 模型和你真实业务标准之间的偏差。

人机协同评估

完全自动化评估是理想，但 Agent 项目早期不现实。更实际的做法是人机协同：

• 自动评估覆盖高频场景，跑量大、速度快，做日常回归
• 人工评估覆盖边缘场景和高质量要求场景，做深度判断
• 人工标注作为自动评估的校准基准，定期抽样对比

比例看项目阶段。早期人工比例高（可能 50% 以上），随着自动评估体系成熟，逐步降低人工占比。但不建议完全去掉——Agent 行为会随模型更新漂移，纯自动评估可能跟不上。

评估数据构建：最被低估的工程

如果说评估方法设计是”怎么评”，那评估数据构建就是”拿什么评”。后者往往更难，也更被低估。

Golden Set 不是随便选的

Golden Set（黄金数据集）是评估的基石。选错了，整个评估体系就建在沙子上。

几个原则：

覆盖性比数量重要。 100 条精心挑选覆盖各种场景的数据，比 1000 条随机抽取的同质化数据有用得多。覆盖性要考虑：用户意图类型、对话轮数、输入长度、语言风格、边缘情况。

要有时间维度。 Agent 的用户行为会变化，评估数据不能一劳永逸。定期补充新数据，淘汰过时数据。一个半年前的 Golden Set 可能已经不反映当前用户的真实行为模式。

要区分难度。 全是简单 case 的 Golden Set 会给你虚假的信心。要有意识地把难题——多轮对话、歧义输入、工具调用失败后的恢复——纳入评估范围。

从哪搞数据

评估数据的来源其实不少，关键是愿不愿意花精力收集和整理：

线上日志是最好的数据源。 真实用户行为比任何人工编造的测试 case 都有价值。从线上日志里筛选有代表性的对话，人工标注正确答案，就是高质量评估数据。成本主要是标注人力，但回报远高于自己编 case。

用户反馈是信号源。 用户点了”不满意”、转人工、重复提问——这些都是评估的金矿。把这些信号和对应对话关联起来，你就有了带标签的评估数据。

对抗生成补盲区。 找几个人专门”刁难” Agent，把 Agent 搞崩的场景记录下来。这种数据量不大但价值极高——它暴露的是你评估体系的盲区。

合成数据做补充。 用 LLM 生成评估数据可以快速扩量，但有两个风险：一是分布偏差（生成的数据和真实用户行为不一致），二是难度偏低（LLM 倾向于生成”标准”case）。合成数据可以做补充，不能做主力。

数据质量怎么保证

评估数据本身也需要质量控制。听起来套娃，但确实如此。

标注一致性检查。 多人标注同一批数据，算 Cohen’s Kappa 或类似的标注一致性指标。整体 Kappa 低于 0.7 时需要重新讨论标注标准，对分歧较大的标注项逐条复核。低一致性的数据放进 Golden Set，评估结果就不可靠。

定期审计。 Golden Set 里的数据会”腐坏”——业务逻辑变了、用户行为变了、甚至 Agent 的正确行为标准也变了。每季度做一次审计，清理过时数据。

对抗测试。 故意往 Golden Set 里放一些”陷阱”case——答案有争议的、边界条件的、甚至标注错误的。如果自动评估在这些 case 上的表现突然变化，说明评估体系本身可能出了问题。

评估体系的工程化

评估不是一次性的工作，是持续运行的工程系统。

评估流水线

一条完整的评估流水线大概长这样：

代码变更 / 模型更新 / Prompt 修改
        ↓
   自动触发评估
        ↓
  跑 Golden Set → 分层指标计算
        ↓
  LLM-as-Judge 补充评估
        ↓
  人工抽检（校准）
        ↓
  生成评估报告（对比基线）
        ↓
  指标劣化 → 告警 / 阻断发布
  指标改善 → 审查原因 → 更新基线

关键设计点：

自动化触发。 评估不应该靠人记得去跑。代码合并、模型版本更新、配置变更——这些事件自动触发评估。CI/CD pipeline 里加一个评估 stage，不通过就不让上线。

基线对比。 孤立的分数没有意义，有意义的是和基线的对比。每次评估都对比上一个版本的指标，标注变化幅度。指标劣化超阈值则告警并阻断发布；指标显著改善也需审查原因，确认不是评估数据出了问题。

分层报告。 给不同角色看不同层级的报告。开发看组件级指标（检索准确率、工具选择匹配率），产品看端到端指标（任务完成率、用户满意度），管理层看趋势（周环比、月环比）。

评估的成本控制

评估是花钱的——LLM 推理、人工标注、计算资源，都要成本。

控制成本的核心是分级评估：

• L1 冒烟测试：20-50 条核心 case，每次变更都跑。快、便宜，只抓严重退化。
• L2 回归测试：200-500 条覆盖主要场景的 case，版本发布前跑。中等成本，覆盖面广。
• L3 全面评估：1000+ 条全量 Golden Set + 人工评估，季度或重大版本跑。成本高，但全面准确。

日常开发用 L1 卡住底线，版本发布用 L2 保证质量，定期用 L3 校准整体方向。这样既不会因为评估太重而拖慢迭代，也不会因为评估太轻而漏掉问题。

在线评估：离线之外的事

离线评估再完善，也和真实线上环境有差距。用户的行为分布、输入风格、边缘场景，很难被 Golden Set 完全覆盖。所以上线后还需要在线评估手段：

• A/B 测试：新旧版本同时跑，对比核心业务指标。最直接的方式，但需要足够流量才能统计显著。
• 影子部署：新版本跑在真实流量上但不返回结果给用户，只收集输出做离线对比。适合风险较高的变更。
• 金丝雀发布：新版本先放给小比例用户，监控指标，逐步扩大流量。

离线评估管的是”能不能上”，在线评估管的是”上了之后怎么样”。两者互补，缺一不可。

常见的坑

做 Agent 评估这几年，有些坑反复看到：

坑一：评估指标和业务目标脱节。 追求 BLEU 分数提升，但用户满意度没变。因为 BLEU 衡量的是文本相似度，不是用户问题是否被解决。评估指标一定要能追溯到业务终态。

坑二：Golden Set 过小或过偏。 20 条数据的 Golden Set 基本等于没有。或者 200 条数据但全是简单 case，评估永远”通过”，上线后被真实用户教做人。

坑三：只看平均分。 平均准确率 85% 看着不错，但可能是简单 case 95%、困难 case 40%。永远要看分层数据和分布，不看单一汇总数字。

坑四：评估一次就不管了。 评估体系建好了，跑了一次，出了个报告，然后就没有然后了。评估是持续工程，不是一次性交付物。没有持续运行的评估，等于没有评估。

坑五：过度依赖 LLM-as-Judge。 Judge 模型本身也有偏见和不稳定。把它当唯一裁判，可能引入新的系统性偏差。定期用人工标注校准 judge 模型的打分。

一个实操框架

最后给一个可以直接用的框架，适合 Agent 项目从零开始搭建评估体系：

第一步（第1-2周）：定义评估目标

• 明确业务终态指标（用户满意度、任务完成率等）
• 梳理 Agent pipeline 的关键环节
• 确定每层的评估维度

第二步（第2-4周）：构建初始 Golden Set

• 从线上日志筛选 100-200 条对话
• 人工标注正确答案和关键质量维度
• 标注一致性校准（目标 Kappa > 0.7）
• 覆盖主要场景类型和难度分布

第三步（第4-6周）：搭建评估流水线

• 自动化评估脚本（规则 + LLM-as-Judge）
• 基线指标建立
• CI/CD 集成
• 评估报告模板

第四步（第6-8周）：运行和调优

• 跑 2-3 轮完整评估
• 校准 LLM-as-Judge 与人工标注的偏差
• 补充 Golden Set 盲区
• 建立分级评估机制（L1/L2/L3）

第五步（持续）：运营和维护

• 定期更新 Golden Set
• 季度全面审计
• 评估指标趋势监控
• 新场景的评估覆盖

时间线是理想情况。实际操作中，第一步和第二步经常需要反复迭代——你定义评估目标的过程中会发现自己对业务终态的理解不够清楚，这本身就是有价值的产出。

结语

Agent 工程里，模型是引擎，框架是底盘，Prompt 是方向盘，评估是仪表盘。没有仪表盘你也能开，但你不知道开向哪、开得多快、还能开多久。

把评估放在优先位置，不是因为评估本身有多精妙，是因为没有评估的 Agent 开发就是在赌博。而工程的意义，就是把赌博变成可管理的过程。

参考资料

• Agent 系统交付的可量化指标研究
• Agent Memory 评估的工程化解决方案综述
• 从盲目调优到数据驱动：大规模 Agent 评估工程实践指南
• Metrics Internalization: Loop Engineering
• Zheng et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. arXiv:2306.05685
• Es et al. (2023). RAGAS: Automated Evaluation of Retrieval Augmented Generation. arXiv:2309.15217
• Liang et al. (2022). Holistic Evaluation of Language Models (HELM). arXiv:2211.09110
• LangSmith Documentation - Evaluation & Testing
• TruLens - LLM Evaluation and Tracking