从零搭建智能体评测系统：先解决数据可信问题

一、为什么很多智能体评测系统从源头上就是错的

智能体评测和传统模型评测有一个本质区别：传统模型评测大多只关心输入与输出，而智能体评测必须关心“中间发生了什么”。一个任务最终成功，可能是每一步都推理正确，也可能是中间错了三步、最后靠运气纠正回来；一个任务最终失败，也可能只是某个外部工具调用超时，而不是决策能力不足。

要把这些中间过程讲清楚，评测系统依赖的不是一两个结果字段，而是完整的执行轨迹数据。这些数据要经过采集、上报、落盘、聚合几个环节，才能变成评测能用的东西。很多团队直接跳过这一步去设计评分标准，结果评出来的分数看着挺好看，回头一查，发现有一部分执行数据根本没采全，或者同一条数据被重复计算了好几遍，评出来的分是不准的，只是没人发现。

这类问题最大的隐蔽性在于：它不会报错、不会崩溃。系统照常运行，报表照常生成，趋势图甚至看起来很平滑。只有当你因为某个异常结论往回追查时，才会发现数据底层已经悄悄失真。如果评测体系直接建立在这样的数据上，后续所有关于通过率、失败原因分布、能力短板分析的结论，都会从源头上产生偏移。

二、一个真实的教训：数据膨胀八倍，统计全部失真

在笔者参与的一个智能体执行数据管道中，曾遇到过这样一个具体案例：服务端一天生成的执行轨迹文件约90MB，但按会话和步骤去重后，真正有效的唯一数据只有约11MB，膨胀了八倍以上。

排查后定位到两个原因叠加：

第一，每次上报都把完整的对话历史存了两份到不同字段里。不同消费环节各自需要不同视角的数据，上报端为了省事，直接冗余存储。

第二，上报端每完成一步，就把当前会话中所有已完成的步骤重新打包上报一次。服务端收到后只是把数据追加写入文件，没有按会话标识和步骤序号做幂等去重。这意味着一个会话执行了20步，第1步的数据会被写入20遍，第2步被写入19遍，以此类推。

这种写入模式在数据量小的时候完全无感，一旦并发会话数上升，存储先扛不住；更严重的是，后续做统计时，如果不做去重，失败步骤的计数会被严重稀释——同一个错误步骤被重复计了几十次，而成功步骤只计了几遍，失败率看起来远高于真实值。反之，如果某些重复数据集中在成功路径上，也可能掩盖真实问题。

这个案例说明了一个核心原则：评测系统的第一优先级不是评分模型有多精细，而是底层数据是否值得信任。 数据不可信，评分再科学也是在空中楼阁上做文章。

三、从0到1，按这个顺序搭建，别反过来

第一步：保证执行数据能可靠落地，哪怕方案粗糙

搭建智能体评测系统时，很多人上来就讨论该用哪些指标、权重怎么设、阈值怎么定。这些当然重要，但不应该是第一步。

第一步应该是一个朴素的落盘队列：智能体每产生一个执行事件，就把它放进一个持久化队列，再由消费者批量写入可靠存储。

粗糙没关系，关键是要解决三类问题。一是进程崩溃时，内存里还没落盘的事件不能丢；二是网络抖动导致上报失败时，要有重试机制，并且重试不能产生重复记录；三是写入端要能承受突发流量，不能因为上报量大就阻塞智能体主流程。

落盘的数据结构可以很简单，但必须有三个基础字段：会话唯一标识、步骤序号、事件时间戳。这三个字段是后续所有去重和排序的基础。没有它们，后面的数据质量无从谈起。

第二步：在落盘时就把采集维度定清楚

数据落地时顺手把采集维度定清楚，能省后面很多返工。一个比较务实的分层思路是把执行日志拆成三个面：

• 操作面：谁调用了谁、调用耗时多少、返回状态是什么。这一层回答“系统在什么时候做了什么”。
• 推理面：当时的推理链是什么、置信度多少、中间选择了哪条路径。这一层回答“为什么这么做”。
• 上下文面：对外的HTTP调用、SQL查询、向量库检索等外部交互的输入输出摘要。这一层回答“外部环境给了什么信息”。

推理事件应该嵌套在操作事件内部，形成父子Span结构。好处很直接：凌晨报警说智能体做了一次不该做的写入操作，点开操作Span一路展开到推理层，就能看到当时的推理依据是什么。不用对着一堆分散的输出日志靠猜测还原现场。

第三步：在设计评分标准之前，先建立数据质量校验

数据管道建成之后，不应该立刻进入评分环节，而应该先建立几个基础校验：

一是去重校验。以会话标识加步骤序号为唯一键，检查是否存在重复记录。如果同一会话同一步骤出现多条，要么在上报端做幂等控制，要么在消费端做合并去重，而且两种策略必须明确选一种，不能混着来。

二是完整性校验。检查已结束会话的步骤序号是否连续，是否存在中间步骤缺失。缺失可能来自采集端的遗漏，也可能来自写入端的丢失。

三是时钟一致性校验。同一会话内的事件时间戳应该是单调递增的，如果出现乱序，说明采集端或传输端存在异步缓冲问题。

这些校验看起来简单，但能在评分上线前拦住大部分脏数据问题。

第四步：才开始构建评分层

当底层数据被确认可靠后，评分层的设计才有讨论的价值。此时可以围绕几个维度展开：任务完成度、路径效率、工具调用合理性、推理质量、失败恢复能力等。

评分层的输入必须是经过质量和去重处理的数据集，而不是直接从原始文件里统计。评分过程中，如果发现某个指标异常，也应该有回溯到原始执行轨迹的能力——这是分层数据结构带来的直接好处。

四、几个工程上的防坑建议

第一，不要让上报端承担去重逻辑。上报端只负责采集和发送，去重放在消费端或写入端统一处理。上报端一旦承担去重，就需要维护状态，而智能体执行进程的状态维护本身就是个不稳定因素。

第二，大数据量情况下不要用单文件追加。可以采用按时间分片或按会话分桶的写入方式，配合异步合并策略。这样即使某段时间数据异常，也只需要重放局部文件，不会影响全局。

第三，给每条执行记录预留扩展字段。智能体的能力边界在不断变化，今天不采集的维度，半年后可能就是评分的关键输入。预留扩展字段的成本远低于重建整条数据管道。

第四，评测数据的管理要有生命周期。不能无限期保留所有原始轨迹，需要根据会话价值和存储成本设置分层存储策略，避免历史数据成为持续负担。

五、总结

智能体评测系统搭建的真正难点不在于评分算法，而在于如何获得可信的执行数据。把数据管道的可靠性放在第一位，把去重与校验变成强制环节，再在上层构建评分体系，这个顺序看似“慢”，实际上是少走弯路的最快路径。

先让数据可信，再谈评分好坏。这是搭建智能体评测系统时需要反复提醒自己的一句话。