agent-0-1-">Agent评测系统从0到1：先把数据管道做对，再谈评分标准

很多团队启动Agent评测系统时，第一反应是设计评分维度：任务完成率、工具调用准确率、推理链质量、成本效率……这套指标体系当然重要，但一个常被忽略的事实是：评分标准的上限，取决于数据管道的下限。如果采集环节就在悄悄丢数据、重复计数，那么后面再精巧的评分模型，也只是在错误的地基上盖楼——分数看起来很漂亮，结论从源头上就是错的。

本文按”从0到1”的落地顺序，拆解搭建Agent评测系统时最容易被跳过、却最不能跳过的那一步：让执行数据可靠地变成”评测可用的东西”。

一、为什么不能跳过数据管道直接设计评分

一条Agent执行数据，要经过采集 → 上报 → 落盘 → 聚合四个环节，才能变成评测系统真正消费的样本。这条链路里任何一环出问题，都不会报错、不会崩溃，只会让数据”悄悄失真”：

• 采集端漏埋点，某些工具调用根本没记录；
• 上报端重复打包，同一份数据被写入多次；
• 落盘端只做追加写入、不做去重，历史步骤被反复堆叠；
• 聚合端不做会话级、步骤级校验，重复数据被当成独立样本参与统计。

这类问题的共同特征是静默性：系统照常运行，监控指标一切正常，只有当你真正去核对”有效数据量”时，才会发现数字对不上。

一个真实的排查案例很能说明问题：某次服务端一天的日志文件约 90MB，去重后实际有效数据只有约 11MB，放大了 8 倍多。拆开看是两个原因叠加：

1. 字段冗余：每次上报都把完整的对话历史分别存入两个不同字段，因为不同下游环节各自需要完整上下文，谁也没觉得这是问题；
2. 重复上报：上报端每完成一步，就把当前会话中”所有已完成的步骤”重新打包上报一次，而服务端只是追加写入文件，没有按”会话 + 步骤”做去重，导致早期步骤被反复写入几十遍。

后果是什么？存储成本被放大数倍只是表层；更深层的是，任何基于这份数据的统计——平均步骤数、工具调用频次、耗时分布——全部失真。如果评测系统直接在这种数据上跑分析，得到的结论在源头上就不可信。

二、第一步：让数据可靠落地，哪怕粗糙

搭建顺序不能反。第一步不是设计评分体系，而是保证执行数据能稳定、不丢、不重复地落盘。落地的标准可以很朴素：

• 进程重启不丢数据；
• 网络抖动不丢数据；
• 同一会话的同一步骤，不重复计数。

实现上，一个简单的落盘队列就够用：采集端把执行事件写入本地队列（内存 + 本地文件双缓冲），由独立的消费者批量上报到服务端；服务端接收后先落原始层，再做去重与归一化。关键设计点有三个：

1. 定义稳定的去重键。 最常用的是”会话ID + 步骤序号 + 事件类型”，必要时再加时间戳或内容哈希作为兜底。去重键必须在采集端生成并随数据一起上报，不能等落盘时再猜。

# 采集端：为每个执行步骤生成幂等的事件ID
event = {
    "session_id": session_id,
    "step_index": step_index,
    "event_type": "tool_call",       # tool_call / llm_response / ...
    "event_id": f"{session_id}:{step_index}:tool_call",
    "payload": {...},
    "ts": time.time(),
}

2. 落盘层做幂等写入。 无论是写文件还是写数据库，都以 event_id 为主键或唯一索引，重复写入直接覆盖或丢弃，而不是追加。追加写入是重复数据最常见的温床。

3. 上报端只报增量。 每一步完成后只上报”这一步”的事件，不要重新打包整个会话的已完成步骤。完整上下文的拼装交给下游聚合层按 session_id 重组——这样既避免了重复上报，也让单条事件更小、更易校验。

# 服务端落盘时的幂等处理伪代码
def persist(event):
    key = event["event_id"]
    if store.exists(key):        # 已存在则跳过，保证幂等
        return
    store.write(key, event)      # 以 key 为主键写入

这三件事做扎实，后面的评分才有意义。反过来，如果这一步是糊的，你甚至无法回答”我们昨天到底跑了多少个有效会话”这种最基础的问题。

三、顺手把采集维度定清楚，省掉大量返工

数据能可靠落地之后，紧接着要做的不是急着打分，而是把该采的维度定清楚。维度设计一旦定型，后期返工成本极高——埋点改一遍、历史数据补不回来，评测口径就得跟着打折。

业界一种被广泛认可的思路是把日志拆成三层，结构上让推理层嵌套在操作层之内：

• 操作面（Operation）：谁调用了谁、调用参数、耗时、成功与否。这一层回答”Agent做了什么”。
• 推理面（Reasoning）：当时的推理链、决策依据、置信度。这一层回答”Agent为什么这么做”。
• 上下文面（Context）：对外部的 HTTP 调用、SQL 查询、向量库检索等。这一层回答”Agent看到了什么”。

三层嵌套的好处非常直接。设想凌晨收到告警：Agent 对主库执行了一次不该有的写入。如果只有一堆 print() 日志，你只能靠猜；而有了结构化 Trace，从操作层点开那次写入，一路展开到嵌套的推理层，你会直接看到当时的推理内容是”用户说’整理一下’，我认为应该归档到主库”——问题定位从”翻日志猜”变成”看链路读”。

{
  "operation": {
    "name": "db_write",
    "target": "primary_db",
    "duration_ms": 42,
    "reasoning": {
      "chain": "用户说'整理一下'，我认为应该归档到主库",
      "confidence": 0.72
    },
    "context": {
      "type": "sql",
      "statement": "UPDATE ..."
    }
  }
}

维度定义阶段还有几个容易漏的点值得提前想清楚：时间戳统一用同一时区与精度；区分”会话级”与”步骤级”字段，避免把会话属性重复写进每条步骤；为失败、重试、超时单独设事件类型，而不是混在成功事件里靠状态字段区分。这些细节在采集阶段多花一天，在评测阶段能省一周。

四、聚合层：把原始数据变成评测样本

落盘的是原始事件，评测消费的是聚合样本，中间这一层同样需要设计：

1. 按会话重组：以 session_id 聚合，按 step_index 排序，还原完整执行轨迹；
2. 有效性过滤：剔除截断会话、采集不全的会话、明显异常的重复事件；
3. 样本化：把一次会话转成一条评测样本，附带任务描述、期望结果、实际轨迹三层信息；
4. 指标预计算：步骤数、工具调用次数、总耗时、失败率等基础指标在聚合层算好，评分层直接取用，避免重复扫描原始数据。

聚合层还要承担一个”守门人”职责：对每个会话做完整性校验（步骤序号是否连续、必采字段是否缺失），校验不通过的样本打标而非静默丢弃——这样你始终知道”有多少数据被排除、为什么被排除”，评测结论的可信度才有据可查。

五、落地顺序总结

按下面的顺序搭，不要反过来：

1. 可靠落地：落盘队列 + 幂等去重键 + 增量上报，先保证不丢不重；
2. 维度定型：操作面 / 推理面 / 上下文面三层嵌套，一次定义到位；
3. 聚合校验：会话重组、有效性过滤、完整性打标；
4. 评分体系：在前三步可信的数据之上，再设计评分维度与权重。

跳过前三步直接做第四步，是很多评测系统”看起来能用、结论不可信”的根本原因。数据管道的价值不在于精巧，而在于可信——它不产生任何评分，却决定了所有评分的意义。把这条链路做扎实，你的Agent评测系统才真正具备从0到1的底座。