1. 第一回合：Agent如何评估？
王工：我看你简历上写了两年Agent应用开发经验。今天我问一些实战经验问题:你们之前做Agent项目，评估这块是怎么搭建的？
小张：刚开始直接套用评估LLM的那套方法，测准确率、测BLEU分，不过发现可能并不适合于Agent的评测，所以我们就换了方式。
王工：具体说说？
小张：其实我们要知道Agent和传统LLM最大的区是啥——比如LLM测的是Output输出的内容，简单来说就是看它输出的合不合理，对不对。但Agent侧重点不太一样，看的是Outcome（结果），就是无论它是怎么工作或者怎么分析的，不重要，只看最终是否把事情真正做了。
王工：还有吗？
小张：哦对，还有个点，除了结果判断，效率也非常重要。Agent是有调用轨迹的，俗称Trace。具体看的点就是效率，比如同样完成了任务，一个Agent调了3次工具，另一个调了30次，效率差距也不能忽视
王工：那你们后来怎么设计评估体系的？
小张：我们评估这块，学的是Anthropic那套思路——简单说就是"别把鸡蛋放一个篮子里"，分成多层进行评估
王工：具体怎么分层？
小张：其实说是5层，看起来很有步骤化，但一般大家做Agent业务上线时都会用到这些办法
比如我们第一步自动化测试，起码保证Agent能力不低于之前。做法也很简单比如用历史工单数据跑回归测试，新模型在已知case上的准确率不能低于之前水平，否则继续调整Agent。
之后会加入人工抽检，例如从业务线随机抽200条POI判重结果，看有没有逻辑冲突或边界case处理不当。
上线就是正常步骤，会先走灰度发布，小范围A/B测试
后面第四、五层都是常规线上业务处理，我们会对其进行上线后监控，有问题立刻告警。比如监控API调用错误率、响应时长、数据输出格式合规性，指标异常自动触发告警到运维群。
最后收集业务方反馈，定期进行Agent迭代
王工：思路没什么问题，属于正常思路，就是不知道你们上线执行的如何？
小张：说实话，挺两极分化的。我们作为团队前沿，是会按照这个标准把Agent用到生产环境的，但不少团队都是急着上线，所以说...基本上就是能上线就行。
王工：那风险不小啊。
小张：对，所以我们才觉得评估这块得提前做，不能等出了问题再补。
2. 第二回合：评测的核心指标怎么设计
王工：你们第一层具体指标你们怎么定的？不会只做正确率统计吧
小张：不是的，我先说说任务成功率吧，有个细节我想展开说说，就是——Pass@k和Pass^k的区别。
王工：说吧
小张：Pass@k是试k次，只要成功1次就算过，适合辅助类工具，给你几个选项挑一个就行。Pass^k则是指的试k次必须全成功，适合自动化Agent作业场景
王工：行，其它指标呢
小张：还有就是效率，效率我们主要分场景，有两种：TTFT（首Token延迟），交互式场景需要重点关注；平均任务完成时间，一般任务处理都用这个就可以
王工：我想听听你们工具调用你们怎么评估的
小张：说到这个，就离不开NDCG，简单来说就是Agent"选对工具"和"调用顺序对不对"的问题。
王工：还有什么指标吗？
小张：还有规划能力和错误恢复，规划能力我们看计划质量和计划遵循度。错误恢复比较复杂——在Agent在推理、工具调用、记忆检索、动作执行四个环节都可能出错，得分别设计恢复策略。
指标对应具体场景，暂时先不展开说明，如有兴趣留言:NDCG、或者你希望了解的指标,我将专门出一期来讲解
3. 第三回合：工具链和实现机制
王工：基准测试有做过吗，基准测试你们选的哪些？
小张：这个得看场景。我们代码Agent用SWE-bench，Web交互用WebArena，通用能力用GAIA，工具调用密集型用ToolBench。
王工：评估框架有用过吗，简单说说吧
小张：我们用DeepEval，它专门为Agent设计的，有TaskCompletion、ToolCorrectness这些现成指标。LangSmith用来做可视化调试。
王工：CI/CD怎么集成的？
小张：CI/CD我们之前为了方便，就采用全量跑的方式，结果流水线一跑就是俩小时，上线进度严重滞后。后来就改成分层验证—-提交、合并、上线时一样跑一些，减少了上线的时延压力。
王工：灰度发布如何做的？
小张：标准流程，部署时先切1%到5%流量，监控错误率和P99延迟，没问题再逐步放量。我们设了硬指标，任务成功率下降超过3个点就自动回滚。
4. 收尾：实战踩坑经验
王工：最后聊聊你们踩过的坑吧。
小张：步步艰难...说个典型的坑环境隔离。我们让Agent操作数据库、调API，如果测试环境没进行隔离，上一轮测试的数据残留就会影响下一轮。解决办法就是全新会话，或者将agent容器化。
王工：还有吗？
小张：还有就是常见但很隐蔽的坑——“时间Mock”。我们有个业务场景让Agent负责查“昨日销售额”。结果测试用例今天跑是绿的，明天跑就变红了，因为现实时间变了，但是系统中测试数据还是昨日的。这修复起来比较简单，在测试环境里把系统时间也给Mock（模拟）掉，强制固定在一个特定的时间点。这个其实看着简单，但也有出路，参考的SWE-bench的做法。
王工：数据泄漏问题遇到过吗？
小张：遇到过，有一次我们使用的测试模型得分特别高，但实际使用又太不理想，后来发现测试数据集可能在预训练时已经训练过，这个原因主要是因为我们当时采用的是大模型来造数据，就用到大量开源数据。
解决办法：现在直接使用业务私有数据做预训练，要么用SWE-Bench Pro那种GPL许可的方式防数据泄漏。
王工：那你们有用到大模型来做裁判（LLM-as-a-Judge）吗，打分准吗？
小张：我们的做法比较简单：要么提示词中加few-shot示例，要么详细评分标准。然后再加上人工定期抽检打分情况。
王工：你们这套体系跑下来效果怎么样？
小张：系统化评估框架上线后，迭代周期加快了40%，生产事故减少60%，减少人工抽查量80%。目前还在持续迭代中
王工：好，今天面试就到这里，聊得挺深入的。
