一个退款功能可能影响全局？开发者：Agent评测已成开发基石

Agent 评测已经成为当前 Agent 应用的基石。如果说年初大家都在关注 Harness，那目前的热点和深水区，一定是 Agent 评测和 Agent Infra。

据我了解，基本每个做 Agent 产品的团队都很看重评测的方法论以及效果。

因此我专门开了一个系列，给大家详细介绍一下什么是评测、怎么做，以及其中的一些方法论和细节。这是这个系列的第一篇文章，结合业界的共识以及我自己的最佳实践，给大家总结了我们为什么需要 Agent 评测。

一、从一次问题修复说起

比如现在有一个后端业务，需要增量开发一个 Agent 工具来服务于该业务，例如淘宝的千问购物、京东的智能客服等。

在开发这个 Agent 的过程中，我们会收到来自线上的反馈。当用户或 PM 反馈问题时，我们通常会去查这次问题对应的执行记录（即 trace），具体排查是在哪一步出了错。常见的问题包括：

- 工具没有正常返回；
- 我们的 skill 没有被 Agent 很好地理解；
- Agent runtime 出了问题，Agent Loop 对于当前任务存在不合理的地方，让 Agent 的理解出现偏差，导致这次任务失败。

找到问题之后，我们会修改对应的 tool，或者调整 prompt、skill，甚至是 Agent runtime，再检查原来的问题有没有被解决。之后，如果按照往常开发后端业务的方式，我们还会做一些回归测试，移交给 QA 测试。QA 可能也是测对应的功能、造一些 Case，就认为可以上线了。

但是，处理到这一步，我们只能确认这次反馈的问题得到了解决。至于整个 Agent 的其他任务有没有受到影响，我们比较难判断。为了处理一种特殊情况而补上的这些“打补丁式”的规则，可能会改变 Agent 在其他场景下的行为，但如果仅仅看刚才修好的那个案例，我们是看不出这些变化的。

类似的担忧其实也会发生在新功能上线的时候。现在有了 Agent 的参与，整个开发周期会缩短。我们需要在有限的时间内判断：目前的新功能是否可用，原来的核心功能有没有受到影响。

这些判断主要还是来自目前收到的反馈，以及测试环境里的测试。但上线之后，或者数据量多起来之后，等我们发现问题时，用户就已经受到了影响。

现在，一些做得比较好的 Agent 公司会关注 Agent 评测。比如，字节目前的招聘就很看重 Agent 评测这个岗位。

这些团队或公司希望在上线之前，就有一套可以反复使用的检查方法，来帮助他们：判断这次修改具体解决了什么，有没有影响原本正常的功能；随着 tool、prompt 和 workflow 的变化，保留一些依据，判断当前的 Agent 产品究竟有没有变得更好用。

二、什么是 Agent 评测

前面提到了，我们在遇到问题或开发新功能的过程中，会修改 tool、prompt、skill 或者是 Agent runtime。虽然整个改动发生在某个具体地方，但我们最终需要去检查的是，这些部分组合起来之后，Agent 还能不能完成用户的目标，或者是给它设定的目标。

Agent 的执行过程有一部分是由模型决定的。模型会根据用户的要求、当前上下文和工具返回的结果，决定调用哪个工具、传什么参数，以及我们下一步需要做什么。这让它的完整执行路径不完全由代码预先确定。

模型的输出往往伴随着波动，同一个任务会出现不同的执行结果和过程。这也是大家经常聊到的：Agent 与传统软件不同，它是一个带有概率性的工具。它本身能够正常运行，并不意味着 Agent 每次都会选对合适的工具、传正确的参数，并按照我们编写的工作流和业务要求去完成整件事情。

所以，要判断这样的系统做得怎么样，我们需要先确定具体的任务跟完成标准，再根据执行的记录和实际的结果去检查它的表现。

这里的标准往往来自于业务的要求。哪些业务操作可以执行，哪些条件必须满足，最终应该得到什么样的结果，都是我们在开发的过程中需要确定清楚的。

这就是我们所说的 Agent 评测：围绕具体任务，按照明确的标准检查 Agent 执行过程和结果的一套方法。通过这些检查，了解 Agent 完成任务的质量，以及在所测环境和条件下的稳定性。

用客服场景举例，假设用户需要取消一个订单，我们可以给 Agent 准备相应的订单信息和业务条件，让它处理这个请求。

然后去检查：

- 操作的是不是用户指定的订单？
- 这个订单是否满足取消条件？Agent 有没有按照要求处理？
- 如果应该取消这个订单，那订单的状态是不是真的发生了改变？

比如 Agent 调用了取消订单的工具，最后也回复用户“订单已经取消了”，我们仍然需要去检查对应的后端业务系统里的订单状态。工具调用的记录和回复内容，都不能单独证明我们的任务已经完成了。

如果订单不满足取消条件，我们就需要去检查 Agent 是否正确说明了原因，并且没有执行取消操作。我们看到的这些执行过程的记录，其实就是所谓的 trace。我们可以用 Langfuse 或者 Phoenix 之类的工具去观测或收集它。

我们可以通过 trace 查看 Agent 选了哪些工具、传了什么参数、收到了什么样的结果，然后再根据我们业务系统的状态，去判断这次的任务有没有按照要求完成。要了解稳定性，还需要换一些订单条件、用户表达，并在相同条件下重复执行，观察成功和失败的情况。

Agent 评测可以和现有的测试工作结合。QA 如果已经按照明确的任务和标准，检查 Agent 在不同场景下的表现，这些工作就可以成为评测的一部分。原来的工具测试也可以继续使用，例如检查参数是否合法、接口是否正常返回。

至于具体怎样判断，可以根据任务选择方法。订单状态、操作对象这类明确的结果，可以通过代码检查；用户问题是否得到回应、解释是否清楚，可以结合人工判断，或使用经过人工校准的模型评分。

三、为什么我们需要 Agent 评测

1. 防止越修越坏

在修复问题时，我们大多数人其实会把注意力放在这次失败的任务之中。在进行 bug fix 之后，我们会把原有的请求再复跑一遍，来确认它是否正常完成，最后会让 QA 去测试一下。

但这样其实有个问题：Agent 会处理很多不同的任务，这次修改也可能会影响到其他任务的执行。比如，我们给一个客服 Agent 增加了一份处理退款的 skill，退款功能已经能用了，但原来的订单查询、取消等流程也需要再检查一次。因为模型现在多了一组可以参考的 skill，它对工具的选择、对用户意图的判断都可能受到影响。

因此，评测时可以把这些原本能够完成的任务保留下来，在版本更新的时候重新检查，这是比较重要的。因为我们必须确保在更新或者上线之前，Agent 的核心功能不受影响。我们不能只看整体分数有没有提高，或者新功能带来了哪些新特性，还要看具体有哪些任务可能出现退化。这就是 Agent 评测的重要性，因为新改动可能会掩盖某些已有功能的下降。

基于此，团队在上线之前就可以多一份判断的依据，能够提前处理一部分本来需要等到用户反馈才能发现的问题。

2. 判断是否真的变好

我们修改 prompt、补充 skill，往往是因为觉得这样做可以让 Agent 更好地完成任务，比如去增加一些业务规则，补上一些常见问题的处理方式，增加一些边界条件，或者把我们工具的使用说明写得更加详细。

这些改动从局部看是很有道理的，但实际有没有效果呢？我们需要从执行结果来判断，从全局入手。

假如我们给一个电商的退款 skill 补充了一段异常处理的说明，之前失败的那个案例通过了，这个结果让我们看到了改进的可能。但如果只看这次执行，还是不能确定是修改起了作用，还是这一次执行只是模型的一次偶然成功。其他类似的异常情况是否也能处理，同样需要继续检查。

有了评测之后，我们就可以让旧版本和新版本在尽量一致的条件下，多次处理同一批任务，再对照具体的表现。除了看有没有完成，也可以看同样的任务花了多少时间、调用了多少次工具，来评估性能跟成本上的改变。

某个版本虽然处理得更加完整，但也让用户等待的时间更久了。这样的变化是否值得，需要我们结合业务要求去判断。

3. 确认能否稳定完成任务

很多时候，我们在测试环境中成功处理一个请求，会让我们觉得这个功能已经可用了。但在实际场景里，用户的表达肯定不止我们设计的那样，他可能会先聊其他问题，再提出真正的要求。能不能在这种情况下完成同样的目标，需要我们去进一步确定。

举个例子，用户直接说“取消这个订单”时，Agent 是可以正常处理的。但如果用户先问了取消规则，又改了想取消的订单，模型在那个时候是否还保留着正确的上下文，就需要重新判断了。

除了变化场景之外，同样的任务我们也需要去重复执行。对于“取消订单”这样的操作，我们需要让每次检查都从相同的初始订单状态开始，观察 Agent 的表现是否稳定。一次成功能够证明我们这次任务完成了，但多次的检查才能帮助我们了解它在这些条件下有多大把握反复做好。

我目前实践下来的一个观点是：我没办法完全要求 Agent 在特定任务下做到 100% 正确，但我们能够通过评测等相关手段，让任务的稳定性达到 90% 以上。这也是目前很多大厂正在追求的目标。

4. 说清楚什么算做好

我们在讨论需求时，经常会说“让 Agent 理解用户意图”“把这个业务流程处理好”。这些表述可以说明方向，但落实到具体情况，不同人的理解可能并不一样。

比如，用户有多个订单，只说了一句“把订单取消”。开发者可能认为 Agent 可以根据最近的对话判断目标订单，PM 可能希望再向用户确认一次，QA 在测试时又可能采用另一种判断。这里需要先明确产品允许 Agent 在什么条件下直接操作，什么情况下必须追问。

把这些情况写成评测案例，就需要同时写清楚可以接受什么行为、不能接受什么行为。讨论具体案例时，原来没有说清楚的要求会逐渐暴露出来。即使功能还没做完，这些讨论也能帮助开发、产品和测试人员形成一致的判断标准。看过实际输出后，团队也可能发现标准需要补充，评测会随着这种理解继续调整。

这个过程其实是我们迭代产品的一个过程。目前，很多大厂的 PM 也会参与到我们 Agent 的评测中，这已成为 Agent 评测一个比较关键的环节。因为参与评测的人员需要有很强的业务知识，对整个业务系统有较深的了解，才能完成我们整个 Agent 产品的迭代。

所以，如果评测能够帮助我们明确什么算作“做好”、什么样的任务完成情况是我们想要的，那就能够帮助我们在这个过程中完成一次产品的迭代。

5. 知道下一步该改什么

当问题不断从线上反馈过来时，我们很容易先处理最近收到的那一条。但只看单次反馈，很难知道整个 Agent 最常在哪些地方失败，也很难判断开发时间应该优先花在哪里。

把一批任务的评测结果和 trace 放在一起，就可以进一步归类：有些任务选错了工具，有些丢失了前面已经确认的信息，还有些调用过程正常，但最终没有完成业务操作。这样，我们能看到某类问题是否反复出现，并找到需要继续排查的环节。

不过，评测集可能专门收集了困难案例，所以其中失败最多的问题，不一定就是线上影响最多用户的问题。安排优先级时，还需要结合这些任务在线上的使用频率，以及失败会带来什么后果。一个不常发生、却可能操作错订单的问题，也可能比经常出现的措辞问题更值得优先处理。

这些信息放在一起，团队才能更具体地决定，接下来应该修工具、调整 skill，还是改进 Agent 对上下文的处理。修改完成之后，再用对应的任务检查，确认这次投入有没有解决原来的问题。

四、Agent 评测如何用到我们实际的 Agent 开发环节

回到开头提到的问题修复。我们查完 trace、找到原因之后，还需要把这次问题放到后续的开发和测试中。结合前面的内容，可以把这个过程整理成五步：整理任务、明确标准、准备环境、运行对比、持续更新。

1. 整理需要评测的任务

先明确这次改动需要检查哪些任务。这些任务可以来自已经发生的线上问题，也可以来自产品的核心功能，以及本次新增功能的验收要求。

比如，这次修改的是退款 skill，就需要检查之前失败的退款案例、其他常见的退款场景，以及可能受到影响的订单查询、取消订单等核心流程。把这些任务整理在一起，才知道本次评测覆盖了什么。

2. 补齐案例条件，写清完成标准

选好任务之后，再把它整理成可以执行和判断的 case。这里需要保留必要的上下文和业务状态，并写清楚预期结果。

比如，用户先提出取消订单 A，在 Agent 执行操作之前，又把目标改成订单 B，但 Agent 最后仍然操作了 A。这个 case 就需要保留用户改变意图的对话、两个订单的初始状态，以及用户最终确定的目标。如果两个订单都满足取消条件，预期结果就是：订单 B 被取消，订单 A 保持原样。

接着确定怎么检查这个结果。能直接验证的内容可以用代码检查，需要理解语义的部分再结合人工或模型判断。在这个例子里，可以直接检查两个订单的最终状态。这样就有了一个完整的案例：给 Agent 什么任务、在什么条件下执行，以及怎样判断它有没有完成。

3. 准备一致的运行环境

比较不同版本时，除了本次准备比较的改动，其他条件需要尽量保持一致。比如只修改 skill 时，任务、模型、工具实现和评分规则就不应该同时发生变化，否则很难判断结果差异来自哪里。

业务状态也需要在每次运行前恢复。如果旧版本已经取消了订单，新版本接着使用这个状态，就无法直接比较。评测可以在独立的测试环境里进行，同时让模型配置、工具行为和业务规则尽量接近实际使用条件。对应的代码、prompt、skill 和任务版本，也需要记录下来。

4. 运行评测，对照新旧版本

让旧版本和修改后的版本处理同一批任务，按照相同的标准检查结果。对于需要判断稳定性的任务，还要在相同初始条件下重复执行，观察成功和失败的情况。

比较时，除了看整体表现，还需要看具体哪些任务由失败变成了成功，哪些原本正常的任务出现了退化。同时保留 trace、评分依据，以及耗时、token 用量、工具调用次数等记录。这样，发现差异后才能继续分析原因，也能判断改进是否带来了额外的时间和成本。

5. 处理评测结果，持续补充案例

根据结果判断是否采用这次改动。核心任务出现新的失败时，需要先结合执行记录排查，再判断是否具备上线条件。修复之后重新检查，并保留已经解决的问题，供后续版本继续使用。

这组任务可以放进每次发版前的检查中。上线之后，再从真实用户反馈中补充新的案例和业务条件。这样，线上遇到的问题就能逐渐积累成后续开发的检查依据，评测也会跟着产品一起更新。

五、总结

评测能给我们提供判断的依据，但这个依据是否可靠，还需要看我们选了哪些案例、标准是怎么写的，以及是在什么条件下运行的。这里有几个问题需要注意。

1. 原来的案例通过了，不代表类似的问题都解决了

比如，我们一直根据同一批失败案例修改 prompt 和 skill，最后这些案例都通过了。但换成新的同类任务，是否还可以正常完成，就需要继续检查。所以，除了保留这些案例做回归，也需要准备一些没有用于调优的案例，看看之前的修改能不能处理其他类似的问题。这个过程有点类似机器学习训练过程中训练集和评测集的划分。

2. 评测标准本身也可能有问题

比如，业务并没有要求固定的操作顺序，我们却要求 Agent 按某个顺序调用工具，就可能把本来已经完成的任务判成失败。因此，看到异常的评测结果时，我们也需要结合 trace 和实际结果检查，究竟是 Agent 做错了，还是评测没有正确判断。评测的标准本身就是一个深水区的问题。目前最好的实践，就是让业务专家去制定我们当前业务系统里面的整个标准。

3. 任务失败了，也需要看具体原因

假如测试环境里的订单服务不可用，导致一批任务失败，我们不能直接认为是模型或者 skill 出了问题。但如果是 Agent 传错了参数，或者没有按照要求处理服务异常，这些行为仍然需要检查。把失败的原因保留下来，后面才知道应该去改哪里。

4. 上线之后，还是需要继续观察

我们准备的案例很难覆盖用户所有的表达和业务情况。即使评测通过了，上线之后也可能遇到之前没有考虑到的问题。这些新的反馈还需要继续整理到评测里，作为后续修改和发版时检查的依据。

我目前的一个判断是：Agent 评测已经成为 Agent 开发的基石。我们在不断修改 tool、prompt、skill 和 Agent runtime 的过程中，需要有一套可以反复使用的方法，去判断这次修改有没有解决问题，原来能完成的任务有没有受到影响。这样才能在快速迭代的时候，对当前版本的表现有更多把握。

同时，在做评测的过程中，我们也需要不断讨论：用户到底希望完成什么任务，什么样的结果才算做好，哪些操作是不能接受的。这些讨论本身就会帮助我们进一步明确产品的需求。所以，Agent 评测不仅能够提高产品的整体迭代效率，也能帮助我们更好地认识到产品需要什么，以及如何更好地服务用户。

这是我关于 Agent 评测系列的第一篇文章，主要给大家介绍了什么是 Agent 评测，让大家能够理解当前大厂是怎么看待 Agent 评测的。后续我会完整地更新关于评测我所学到和思考的一切，比如：

- 评测的具体做法：LLM as a Judge……
- 常用的工具与实践

欢迎 follow，也欢迎提出你的问题～