AgentX 基准测试数据集

AgentX 如何构建一次回放

1. 01

   采集

   参与者主动启用 HTTP 代理后，代理会在会话运行期间记录请求与响应时间、token 数、conversation ID 和 subagent ID。

2. 02

   转换

   原始 prompt、源代码、tool argument 和 tool result 均会移除。Input 按 64-token block 转换为会话内串联 hash，在不暴露内容的前提下保留相同 prefix。

3. 03

   重建

   AIPerf 使用确定性的合成编码与 tool-use token 填充这些 block，再把每个会话重建为有向无环图（DAG），涵盖主 agent 轮次、并行 subagent、辅助请求以及轮次间的 tool 执行时间。

4. 04

   回放与测量

   每种配置先通过固定 seed 的 warmup 建立 cache 状态，随后在不同并发客户端数量下进行一小时 profiling。每次回放使用独立的 cache-bust 标记，防止无关会话意外共享 prefix。

v1.0 数据集包含什么

AgentX v1.0 从内部自愿参与的 trace 语料中筛选出 393 个 Claude Code 会话。入选会话至少包含 20 个请求，Claude Code 版本不低于 2.1.139，并且同时运行的 subagent 不超过 10 个。后处理还会移除重复请求、Claude Code 特有的安全监控与标题生成请求，以及重建后 input 超过 990k token 的请求。

• full: 完整的 AgentX v1.0 回放集，包含最高 1M token 的上下文。
• 256k: 面向最大上下文配置为 256k token 的模型与推理引擎的限制版。

回放控制

从稳态开始

固定 seed 会在每段会话 25%–75% 的位置选择起点。Primer 请求和每条回放 lane 额外 10 个 warmup 请求会在 profiling 前建立 KV cache。

确定性回放

Seed 固定会话采样、起点和合成内容。对外报告的指标只覆盖一小时 profiling 窗口，不包含 warmup。

Speculative decoding

合成 token 可能扭曲 draft token 的接受情况，因此 AgentX 会针对每组 model、speculator、draft length 和 thinking mode，使用 SPEED-Bench 测得并固定 acceptance length。

DRAM offload

没有标准化 DRAM 配置的服务器上限为 3 TB；GB200 NVL72、GB300 NVL72 和 TPUv7 等标准化系统使用装机容量。每种配置只能按其 GPU 占比使用对应的 DRAM。

如何解读 AgentX 结果

这里的 concurrency 表示同时运行的 agent 客户端数量，不是固定 request batch。AgentX 采用 closed-loop 模式，因此更快的配置会完成更多请求，遇到的负载组合也可能略有不同；这种波动在低并发时最明显。报告结果时，应同时给出吞吐量、首 token 延迟（TTFT）和 interactivity，单一 latency 指标不足以描述完整运行。

AgentX 衡量推理系统性能。合成 payload 不适合评估模型回答质量。

客户端无法观测服务端 chat template、专有 tokenizer、服务端 tool、加密的 reasoning 内容，也无法精确得知图片和文档最终展开成多少 token。AgentX 使用确定性 placeholder 和针对不同模型校准的 padding 处理这些输入。重建后的 trace 会复现请求长度、时间关系、对话拓扑和 KV 复用模式，但不包含原始会话。