Agent 评测：知道哪里做对，也知道哪里做错

评测是给程序一组输入，按照事先写好的标准检查结果。客户要求查询退款到账时间，程序应该查询退款状态并解释时间；客户只问物流，就应该查物流。把这两类输入保留下来，每次改动后再运行一遍，就能看到改动帮助了谁、影响了谁。

Trace，执行轨迹记录一次任务经过哪些操作：收到问题、选择工具、查询资料、生成答复。轨迹让你从一个错误答案继续追问：选错工具了，传错参数了，还是拿到正确资料后解释错了？

可以把评测看成作业批改，Trace看成解题过程。看总分知道哪些题没做对，翻步骤才能找到应该改的地方。总分涨了两分就宣布“重大突破”，有时只是题恰好对胃口；逐条对照会更有说服力。

先把“做对了”写具体

下面是一条可直接判定的退款查询：

这样一条记录叫样本。预期工具、参数和答复要求叫判定标准。程序答复后，逐项核对这些标准，得到这一条的评测结果。

字段和金额可以交给代码核对；表达是否清楚、资料是否充分，可以依据评分规则请人或模型评审。先定义要检查的内容，再选检查办法。

把协作任务接到评测

沿用退款协作的思路：给定一笔100元、尚未发货的订单，以及“未发货可申请退款”的政策，期待程序答复“可申请退款100元”。查询订单、查询政策、生成答复，都留下各自的输入与结果。

如果答复写成1000元，先检查订单查询是否交回100元。上游金额正确，就继续查汇总步骤；上游已经错误，则先修查询或参数。修好以后，再用相同订单与政策重跑，同时对照结果、费用和等待时间。前面学习的协作步骤，就成了这里可以逐项检查的对象。

十四篇分三段学习

第一段准备题目和判定规则。

Golden Set指经过核对、适合反复使用的基准样本集；Rubric指写清各项判定条件的评分规则。它们把“我感觉答得不错”变成大家能一起核对的条件。

第二段让评测结果对应执行过程。

Span表示轨迹中的一个操作，例如一次订单查询。多个Span共享同一个任务关联编号，并记录各自的时间和结果。先学会读这些记录，排查问题时就能沿任务往下找。

第三段比较变化，判断为什么变化。

先完成第一段，再用相同判定条件看第二段记录；最后做版本对照。例子都准备了固定数据，保存程序即可运行，再用文章给出的改动观察变化。

从失败记录回到原因

程序对“退款多久到账”回答了“包裹正在派送”。评测把工具选择记为错误；查看轨迹发现它调用了物流工具；查看版本记录，发现新提示把“状态查询”都分到了物流类别。

接下来改进分类条件，重新运行退款和物流两组样本。这样能同时检查退款是否修好了、物流是否受到影响。最后才汇总比例、用量和等待时间。

继续阅读

OpenTelemetry的Trace概念解释Span、父子关系和跨服务关联，可对照轨迹篇的本地记录阅读。完成这层后，把质量判定、执行证据和访问控制接到生产操作流程中。