一条 Trajectory，如何解释 Agent Benchmark 的成败？

上一篇，我们沿着 RLHF、PPO、GRPO 和 DAPO，看了不同后训练算法“吃”的数据有什么区别。

这一次先不急着进入训练。我们从一次 Benchmark 开始。

假设同一个 Coding Benchmark 上，旧模型通过了 74 个任务，新模型只通过 68 个。最直接的结论似乎是：模型退化了。

但这 6 个失败任务里，可能有的容器没有启动，有的工具权限发生变化，有的上下文被 harness 提前裁掉，还有的只是 verifier 超时。即使确实是模型问题，我们也需要知道它从哪一步开始偏离。

一个最终分数回答不了这些问题。它只告诉我们结果，却没有保存结果形成的过程。

这正是 trajectory 的位置。

Benchmark 产出分数，Trajectory 负责解释分数。

它把模型决策、工具执行、环境变化、评估结果和系统版本组织成一条行为证据链。Benchmark 用它判断结果是否可信、变化来自哪里；后训练再从中挑选可学习的经验，转换成 SFT、偏好学习或强化学习样本。

所以这篇文章真正讨论的不是“如何多记一些日志”，而是：分散在各系统里的观测数据，怎样被组装成一条可复现、可判定、可归因，也能继续进入训练的 trajectory。

1. 对话、Telemetry 和 Trajectory 不是一回事

最容易得到的是对话记录：用户说了什么，模型回复了什么，工具返回了什么。它适合阅读，却不一定适合复现。

更底层的是 telemetry，包括模型网关 trace、工具日志、容器指标、测试报告和截图。它们足够详细，却分散在不同系统中，也不天然表达 Agent 的行为语义。

Trajectory 位于两者之间。它不复制所有原始日志，而是围绕一个 task，把有因果关系的事件按顺序组织起来：

Task Snapshot ↓Observation -> Model Action -> Tool Result -> State Change ↓Verifier Result + Failure Attribution

其中原始 prompt、完整测试日志、Patch 和截图可以继续留在对象存储中，trajectory 只保存必要摘要和引用。网关延迟、GPU 利用率等指标也不需要逐项复制，只保留与本次执行相关的状态和关联标识。

因此更准确的关系是：

Telemetry 是原材料Trajectory 是围绕任务组织的数据产品Training Sample 是面向算法的下游派生物

2. 一次 Benchmark，本质上是七个变量共同作用

模型只是评测系统中的一个变量。要解释一次结果，至少要同时知道：

Task × Model × Harness × Tool × Environment × Budget × Verifier

Task 决定目标和初始状态；Model 产生决策；Harness 组织上下文和循环；Tool 把动作落到外部系统；Environment 保存真实状态；Budget 限制 token、时间和调用次数；Verifier 决定怎样算成功。

只要其中两个变量同时变化，就不能把结果差异简单归因给模型。例如更换模型时也升级了 system prompt，即使成功率提高，也只能说整套方案变好了，不能证明模型单独贡献了多少。

Task 本身也不是一条 prompt。SWE-bench 的任务同时绑定 issue、代码仓库 base commit、测试与执行环境；WebArena 则使用可独立部署的网站环境和程序化 validator。它们都在说明：Benchmark 的输入不是一句问题，而是一组可重置、可执行、可验收的状态。

这七个变量会成为 trajectory 的版本坐标。后面判断 Better、Same、Worse，或者定位 Harness、Environment 问题，都依赖它们。

3. 一次具体 rollout，会在哪些系统留下数据

任务准备好后，当前 policy 才开始 rollout。一次 Coding Agent 执行，表面上是一串“模型回复、工具返回”；在系统内部，它会同时在模型网关、harness、工具网关、执行环境、verifier 和调度系统中留下记录。

下面仍然使用“修复登录接口偶发 500”这个任务。为了看清数据关系，我们构造一条接近生产日志的示例；其中数值只是示意，采集位置和因果关系才是重点。

任务运行在仓库提交4f21c9上，当前策略是policy@13。Agent 搜索代码并修改异常处理后，在第 4 轮决定运行登录模块测试。

模型网关：这次决策是怎样生成的

模型网关记录到：这次请求输入约 8200 个 token，其中 6100 个命中前缀缓存；首 token 等待 430 毫秒，模型继续生成 186 个 token，最后返回一个run_tests工具调用。

这些数据能回答模型调用的版本、成本和延迟，却只能证明Agent 想运行测试。如果请求在网关重试两次，或者实际响应模型与请求模型不同，也应当在这里暴露。

Harness：模型作决定时看见了什么

Harness 知道这是第 4 轮循环，使用system prompt v8和tool schema v5。由于前文过长，上一步刚做过一次上下文压缩，任务还剩 8 分钟执行预算。

这一层解释的是行为条件。即使 policy 完全相同，只要工具描述、上下文裁剪或最大循环次数改变，Agent 就可能不再作出相同决策。

工具网关：动作有没有真正执行

工具网关收到run_tests(test_login.py)，参数校验通过，沙箱权限允许，未触发重试。测试进程运行 6.8 秒后返回exit code = 1。

这说明工具确实执行了，但还不能直接说“修复失败”。退出码只代表整组测试里至少有一个失败项，具体发生了什么还要看环境状态。

执行环境：代码和测试发生了什么变化

环境侧显示，Agent 一共修改了两个文件。原本失败的test_login_500从 fail 变成 pass，但原本正常的test_session_refresh从 pass 变成 fail；测试期间没有产生额外网络请求。

到这里我们才知道，Agent 找到了目标 bug，同时引入了回归。工具返回值是一条 observation，环境前后的差异才更接近事实。

Verifier：为什么最后仍然是 0 分

Verifier 的规则不是“目标测试通过即可”，而是目标测试必须通过，并且已有测试不能回退。因此它给目标修复记+1，给新增回归记-1，最终 reward 为 0，失败类型标记为regression。

这个 0 分比简单的 pass/fail 多了一层信息：模型并非完全没有解决问题，而是解决方式破坏了原有行为。后续无论做过程监督、失败分类还是 hard case 回流，都需要保留这两个 reward 分量。

调度系统：这条数据花了多少资源

调度侧记录到，这条 rollout 排队 420 毫秒，模型推理消耗约 2.1 GPU 秒，测试消耗 6.8 CPU 秒，全程没有抢占和 OOM。

这些数据不决定任务对错，却决定训练数据的成本，也能帮助排除基础设施噪声。例如测试容器因 OOM 被杀死时，不应该把它直接标成模型能力失败。

把六个视角放在一起，才得到一条可以解释的轨迹：

模型网关：想调用 run_testsHarness：第 4 轮，刚完成上下文压缩工具网关：调用成功，测试进程 exit 1执行环境：目标用例修复，但出现一个回归Verifier：reward = 0，failure = regression调度系统：无 OOM，排除基础设施失败

**网关记录调用，工具记录执行，环境记录事实，verifier 负责判定，调度系统解释成本与噪声。**任何一层缺失，都可能把同一个结果归因给错误的对象。

4. 从这条 rollout 抽象出四类数据

上面的数据来自不同系统，也有完全不同的保存方式。把它们全部塞进一条超大的 JSON，查询和权限都会很快失控。

更自然的做法，是先按用途分成四类：

OpenTelemetry 的 GenAI 语义约定已经覆盖模型、token、tool call 和 evaluation 等常见观测对象。不过它仍在持续演进，而且并不负责定义完整的训练数据模型。更合适的用法，是借它统一 trace 和基础字段，再由训练系统补上 task、policy、harness、environment 与 verifier 的版本关系。

落到离线数据层，也不需要一开始就设计一张包罗万象的宽表。可以先围绕一次 rollout 建四张事实表：

task / model / harness / tool / env / verifier | fact_rollout（含 Budget） / | \ fact_model_call fact_tool_execution fact_evaluation | fact_state_transition | patch / log / screenshot

fact_model_call保存模型决策及其成本，fact_tool_execution保存动作是否执行，fact_state_transition保存环境前后差异，fact_evaluation保存判定过程。大体积内容进入对象存储，事实表只保留引用。

四张事实表通过 rollout 标识和步骤顺序重新拼接。组装后的结果不再是一堆日志，而是一条带业务语义的记录：

Trajectory ro_0017├─ Context：login_500@3 / policy@13 / repo 4f21c9 / Budget 10 分钟├─ Step 1..4：观察、模型决策、工具执行、环境变化├─ Outcome：reward 0 / regression└─ Evidence：patch、测试日志、模型与工具 trace 引用

这条记录还必须绑定版本坐标：

(task_version, model_version, harness_version, tool_version, environment_version, verifier_version)

版本不是附属元数据，而是 trajectory 身份的一部分。没有它，就无法判断两次评测是否真的可比，也无法重放当时的行为。

从 telemetry 到 evaluated trajectory，大致经历四步：先按 rollout 关联多源事件，再按 Agent 实际看到的顺序重建 action 和 observation，然后挂接环境状态与原始证据，最后运行 verifier 并补上 reward、有效性和失败分类。

到这一步，trajectory 才同时具备三种用途：回放一次执行、解释一次评测，以及作为训练样本的上游数据。

5. Trajectory 如何判断 Better、Same、Worse

单次 pass/fail 只能判断一个 case 的结果。要比较 baseline 和 candidate，还需要把同一个 task 下的多条 trajectory 放在一起。

比较至少包含四个维度：

• •结果：是否完成任务，reward 各分量如何变化；
• •行为：走了多少步，调用了哪些工具，第一处分歧在哪里；
• •效率：消耗多少 token、时间和计算资源；
• •稳定性：重复运行后，通过率和失败类型是否稳定。

因此结果分类不应该只有 Good 和 Bad，而应至少有五种：

这里有两个很容易被忽略的情况。

第一，结果相同不代表 trajectory 相同。两个模型都通过任务，candidate 却多调用了十次搜索工具、消耗三倍 token，它在 outcome 上是 Same，在效率上却可能是 Worse。

第二，单条随机 rollout 很难证明模型退化。对非确定性 Agent，应该在相同版本坐标和预算下重复采样，比较 pass rate、reward 分布和失败类型，而不是用一次成败下结论。

Verifier 在这里提供结果标签，但它不是唯一真值来源。确定性结果优先使用单元测试、数据库状态或程序化 validator；软性质量可以交给 reward model 或 LLM judge；冲突和低置信样本再进入人工复核。LLM judge 还需要防范位置偏差、冗长偏差和自我偏好。

6. 同样是 0 分，Trajectory 如何定位问题

回到登录接口的例子。最终都是 reward 0，trajectory 却可能讲出完全不同的故事。

情况一：Model 问题

环境正常、工具可用、harness 和 baseline 一致。Candidate 看到了同样的测试失败，却修改了无关文件，或者在错误位置反复尝试。

此时第一处分歧发生在模型 action，后续环境失败是它的结果。经过重复采样仍稳定出现时，才有较强证据把问题归因给模型。

情况二：Harness 问题

模型调用前，关键报错已经被上下文压缩删除；或者工具 schema 改名，但 system prompt 仍使用旧名字。模型后面的动作确实不正确，却是在错误输入条件下产生的。

这种 trajectory 应用于修复 harness 或重跑评测，不应直接作为“模型能力退化”的证据。

情况三：Tool 或 Environment 问题

模型生成了正确的run_tests，但工具被权限策略拒绝；或者容器依赖安装失败，测试根本没有启动。它们都可能表现为任务失败，却属于评测无效。

工具网关回答“动作有没有执行”，环境快照回答“世界有没有按预期变化”。两者必须分开，否则一次 HTTP 200 或exit code = 0很容易被误当成任务成功。

情况四：Verifier 问题

环境状态已经满足目标，verifier 却读取了旧快照；或者 LLM judge 因答案位置、长度发生偏置。同一 trajectory 在 verifier v4 得 1 分，在 v5 得 0 分，首先应该检查判定逻辑，而不是训练模型。

情况五：Infrastructure 问题

Rollout 在生成中被抢占、OOM 或超时截断。只看最终输出，它像是模型半途放弃；连接调度记录后，才知道这是一条不完整数据。

实际归因可以遵循一条简单路径：

先检查任务、工具、环境和 Verifier 是否有效 ↓再检查 Harness、Budget 和版本是否可比 ↓找到 baseline 与 candidate 的第一处行为分歧 ↓最后才判断是否属于 Model 回归

失败归因不是给日志贴标签，而是沿 trajectory 找到第一处改变因果方向的事件。

7. 不是每条失败 Trajectory 都应该进入训练

完成评测和归因后，trajectory 才能进入数据筛选。

最先隔离的是 Invalid：环境启动失败、工具权限错误、verifier 冲突、调度 OOM。这些数据可以用于修复平台，却不应该训练模型，否则模型会被迫学习如何适应一套已经损坏的世界。

真正由模型行为造成的成功与失败，才进入候选池：

假设同一个 task 采样 16 条 rollout，全部成功说明它对当前模型可能过于简单；全部失败则要继续区分“模型尚不会”和“任务已经损坏”。成功与失败混合的区域，往往最容易形成有区分度的训练信号。

在 GRPO 这类组相对训练中，如果同一 prompt 下所有输出奖励相同，组内优势会变成 0。DAPO 的 Dynamic Sampling 因此过滤全对和全错的组，继续采样有效组。但这些轨迹并非永久无用：全对任务可以进入回归集，全错任务可以用于课程学习和失败研究。

Trajectory 还会随模型更新而过期。policy@12的主要错误可能是不调用测试，policy@13已经解决它，却开始过度修改文件。旧数据仍可用于 SFT、经验回放和回归分析，但不能不带版本地冒充当前 policy 的 on-policy 数据。

因此训练价值不能只看 reward，还要同时考虑：

正确性 × 可判定性 × 难度 × 新颖性 × 当前策略相关性

只有完成有效性检查和失败归因，Benchmark trajectory 才能安全地变成训练资产。

8. Telemetry、Evaluated Trajectory 和 Train Sample 必须分层

生产系统最容易踩的坑，是建一张万能大表：工具日志、评分、训练 token、评测结果全部塞进去。开始很省事，后来谁也说不清一列是原始事实、派生标签还是某次算法专用的中间量。

更清晰的做法是拆成三个数据产品。

Raw Telemetry：保存原始证据

保存模型输入输出、网关 trace、工具日志、环境 observation、时间戳、错误码、资源指标和 Artifact。它尽量忠实记录各系统“观察到了什么”，不因为某个训练算法只需要一部分字段就提前丢弃信息。

Evaluated Trajectory：用于筛选和分析

在 raw telemetry 上重建 Agent 的行为顺序，关联 task、model、harness、tool、environment、verifier 版本，再补充 reward 分量、有效性、Better/Same/Worse 和失败归因。它回答“这次执行表现如何，以及我们为什么这么判断”。

Train Sample：用于某种训练目标

它是 evaluated trajectory 的派生物。SFT 可能只保留成功 action；偏好学习需要 chosen/rejected 配对；GRPO 需要同一 prompt 的一组 rollout、旧策略概率和组内 reward；某些步骤还要 mask 掉 observation，避免把环境返回错误地当成模型目标。

三者之间需要稳定的数据血缘：

raw_telemetry_ref -> evaluated_trajectory_id -> dataset_version -> training_run_id -> checkpoint_version

这样模型出现回退时，才能从 checkpoint 反查训练集，从训练样本追到评估标签，再回到原始工具调用和环境状态。

评测数据还要单独隔离。训练集可以不断吸收 hard case，评测集则需要密封、版本冻结和污染检测。否则每次把线上失败回流训练，都可能顺手把评测答案喂给模型，最后得到一条越来越好看的曲线和一个没有泛化能力的系统。

9. 先让每个 Benchmark 分数都可以被解释

实际落地可以从一个小而可验证的领域开始：例如有稳定单测的代码修复、结果可比较的 SQL 生成，或状态可查询的内部工作流。

第一版不必建设庞大的“Agent 数据中台”，只需要确保六件事：

1. 每个 task 有可重置的环境、预算和明确 verifier；
2. 模型网关、harness、工具、环境与 verifier 共享 rollout 标识；
3. 每条 trajectory 绑定 task、model、harness、tool、environment、verifier 版本；
4. 模型 action、工具结果和环境状态变化能够按顺序重建；
5. Better、Same、Worse、Invalid 和失败归因有明确规则；
6. 训练样本能够追溯到 evaluated trajectory 和原始证据。

做到这些，一次 Benchmark 才不再只留下排行榜上的一个数字：

Benchmark Run-> Raw Telemetry-> Evaluated Trajectory-> 结果比较与失败归因-> Training Sample-> New Policy

Trajectory 在这里连接了评测和训练。向上，它让我们知道分数能不能信、变化来自哪里；向下，它决定哪些行为值得学习，哪些故障应该隔离。

所以真正重要的不是“把 Agent 的所有日志都存下来”，而是让每一条 trajectory 都能回答三个问题：

当时发生了什么？为什么得到这个结果？它是否值得进入下一轮训练？

能回答这三个问题，Benchmark 产出的才不只是分数，而是一批可以持续改进模型的数据资产。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】