上一篇我们沿着 RLHF、PPO、GRPO 和 DAPO看了不同后训练算法“吃”的数据有什么区别。这一次先不急着进入训练。我们从一次 Benchmark 开始。假设同一个 Coding Benchmark 上旧模型通过了 74 个任务新模型只通过 68 个。最直接的结论似乎是模型退化了。但这 6 个失败任务里可能有的容器没有启动有的工具权限发生变化有的上下文被 harness 提前裁掉还有的只是 verifier 超时。即使确实是模型问题我们也需要知道它从哪一步开始偏离。一个最终分数回答不了这些问题。它只告诉我们结果却没有保存结果形成的过程。这正是 trajectory 的位置。Benchmark 产出分数Trajectory 负责解释分数。它把模型决策、工具执行、环境变化、评估结果和系统版本组织成一条行为证据链。Benchmark 用它判断结果是否可信、变化来自哪里后训练再从中挑选可学习的经验转换成 SFT、偏好学习或强化学习样本。所以这篇文章真正讨论的不是“如何多记一些日志”而是分散在各系统里的观测数据怎样被组装成一条可复现、可判定、可归因也能继续进入训练的 trajectory。对话、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 是面向算法的下游派生物一次 Benchmark本质上是七个变量共同作用模型只是评测系统中的一个变量。要解释一次结果至少要同时知道Task × Model × Harness × Tool × Environment × Budget × VerifierTask 决定目标和初始状态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 问题都依赖它们。一次具体 rollout会在哪些系统留下数据任务准备好后当前 policy 才开始 rollout。一次 Coding Agent 执行表面上是一串“模型回复、工具返回”在系统内部它会同时在模型网关、harness、工具网关、执行环境、verifier 和调度系统中留下记录。下面仍然使用“修复登录接口偶发 500”这个任务。为了看清数据关系我们构造一条接近生产日志的示例其中数值只是示意采集位置和因果关系才是重点。任务运行在仓库提交4f21c9上当前策略是policy13。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执行环境目标用例修复但出现一个回归Verifierreward 0failure regression调度系统无 OOM排除基础设施失败**网关记录调用工具记录执行环境记录事实verifier 负责判定调度系统解释成本与噪声。**任何一层缺失都可能把同一个结果归因给错误的对象。从这条 rollout 抽象出四类数据上面的数据来自不同系统也有完全不同的保存方式。把它们全部塞进一条超大的 JSON查询和权限都会很快失控。更自然的做法是先按用途分成四类数据形态回答的问题例子Trace / Span一个操作经过哪里、花了多久模型请求、工具执行、verifier 检查Event某个时间点发生了什么选择工具、压缩上下文、修改文件Metric整体是否出现趋势或异常Token、延迟、错误率、GPU 利用率Artifact判断所依赖的原始证据是什么Prompt、Patch、截图、测试日志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 / screenshotfact_model_call保存模型决策及其成本fact_tool_execution保存动作是否执行fact_state_transition保存环境前后差异fact_evaluation保存判定过程。大体积内容进入对象存储事实表只保留引用。四张事实表通过 rollout 标识和步骤顺序重新拼接。组装后的结果不再是一堆日志而是一条带业务语义的记录Trajectory ro_0017├─ Contextlogin_5003 / policy13 / repo 4f21c9 / Budget 10 分钟├─ Step 1..4观察、模型决策、工具执行、环境变化├─ Outcomereward 0 / regression└─ Evidencepatch、测试日志、模型与工具 trace 引用这条记录还必须绑定版本坐标(task_version, model_version, harness_version, tool_version, environment_version, verifier_version)版本不是附属元数据而是 trajectory 身份的一部分。没有它就无法判断两次评测是否真的可比也无法重放当时的行为。从 telemetry 到 evaluated trajectory大致经历四步先按 rollout 关联多源事件再按 Agent 实际看到的顺序重建 action 和 observation然后挂接环境状态与原始证据最后运行 verifier 并补上 reward、有效性和失败分类。到这一步trajectory 才同时具备三种用途回放一次执行、解释一次评测以及作为训练样本的上游数据。Trajectory 如何判断 Better、Same、Worse单次 pass/fail 只能判断一个 case 的结果。要比较 baseline 和 candidate还需要把同一个 task 下的多条 trajectory 放在一起。比较至少包含四个维度•结果是否完成任务reward 各分量如何变化•行为走了多少步调用了哪些工具第一处分歧在哪里•效率消耗多少 token、时间和计算资源•稳定性重复运行后通过率和失败类型是否稳定。因此结果分类不应该只有 Good 和 Bad而应至少有五种分类Trajectory 给出的证据Better成功率或质量提高且不是环境或 verifier 变化造成Same结果差异处于正常波动范围行为和成本没有明显恶化Worse在可比条件下成功率、质量或稳定性明确下降Invalid环境、工具、任务或 verifier 异常本次结果不应计入模型分数Inconclusive样本不足或模型之外的多个变量同时变化无法归因这里有两个很容易被忽略的情况。第一结果相同不代表 trajectory 相同。两个模型都通过任务candidate 却多调用了十次搜索工具、消耗三倍 token它在 outcome 上是 Same在效率上却可能是 Worse。第二单条随机 rollout 很难证明模型退化。对非确定性 Agent应该在相同版本坐标和预算下重复采样比较 pass rate、reward 分布和失败类型而不是用一次成败下结论。Verifier 在这里提供结果标签但它不是唯一真值来源。确定性结果优先使用单元测试、数据库状态或程序化 validator软性质量可以交给 reward model 或 LLM judge冲突和低置信样本再进入人工复核。LLM judge 还需要防范位置偏差、冗长偏差和自我偏好。同样是 0 分Trajectory 如何定位问题回到登录接口的例子。最终都是 reward 0trajectory 却可能讲出完全不同的故事。情况一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 找到第一处改变因果方向的事件。不是每条失败 Trajectory 都应该进入训练完成评测和归因后trajectory 才能进入数据筛选。最先隔离的是 Invalid环境启动失败、工具权限错误、verifier 冲突、调度 OOM。这些数据可以用于修复平台却不应该训练模型否则模型会被迫学习如何适应一套已经损坏的世界。真正由模型行为造成的成功与失败才进入候选池Trajectory 类型更合适的去向稳定成功且路径简洁SFT 或高质量行为样本同任务下成功与失败并存偏好对、GRPO 组或过程分析模型稳定失败但任务有效Curriculum、任务拆解或 hard case成功但代价明显升高效率优化、cost-aware rewardHarness、Tool、Environment 失败隔离并回流对应工程系统假设同一个 task 采样 16 条 rollout全部成功说明它对当前模型可能过于简单全部失败则要继续区分“模型尚不会”和“任务已经损坏”。成功与失败混合的区域往往最容易形成有区分度的训练信号。在 GRPO 这类组相对训练中如果同一 prompt 下所有输出奖励相同组内优势会变成 0。DAPO 的 Dynamic Sampling 因此过滤全对和全错的组继续采样有效组。但这些轨迹并非永久无用全对任务可以进入回归集全错任务可以用于课程学习和失败研究。Trajectory 还会随模型更新而过期。policy12的主要错误可能是不调用测试policy13已经解决它却开始过度修改文件。旧数据仍可用于 SFT、经验回放和回归分析但不能不带版本地冒充当前 policy 的 on-policy 数据。因此训练价值不能只看 reward还要同时考虑正确性 × 可判定性 × 难度 × 新颖性 × 当前策略相关性只有完成有效性检查和失败归因Benchmark trajectory 才能安全地变成训练资产。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评测集则需要密封、版本冻结和污染检测。否则每次把线上失败回流训练都可能顺手把评测答案喂给模型最后得到一条越来越好看的曲线和一个没有泛化能力的系统。先让每个 Benchmark 分数都可以被解释实际落地可以从一个小而可验证的领域开始例如有稳定单测的代码修复、结果可比较的 SQL 生成或状态可查询的内部工作流。第一版不必建设庞大的“Agent 数据中台”只需要确保六件事每个 task 有可重置的环境、预算和明确 verifier模型网关、harness、工具、环境与 verifier 共享 rollout 标识每条 trajectory 绑定 task、model、harness、tool、environment、verifier 版本模型 action、工具结果和环境状态变化能够按顺序重建Better、Same、Worse、Invalid 和失败归因有明确规则训练样本能够追溯到 evaluated trajectory 和原始证据。做到这些一次 Benchmark 才不再只留下排行榜上的一个数字Benchmark Run- Raw Telemetry- Evaluated Trajectory- 结果比较与失败归因- Training Sample- New PolicyTrajectory 在这里连接了评测和训练。向上它让我们知道分数能不能信、变化来自哪里向下它决定哪些行为值得学习哪些故障应该隔离。所以真正重要的不是“把 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%免费】 一条 Trajectory，如何解释 Agent Benchmark 的成败？
上一篇我们沿着 RLHF、PPO、GRPO 和 DAPO看了不同后训练算法“吃”的数据有什么区别。这一次先不急着进入训练。我们从一次 Benchmark 开始。假设同一个 Coding Benchmark 上旧模型通过了 74 个任务新模型只通过 68 个。最直接的结论似乎是模型退化了。但这 6 个失败任务里可能有的容器没有启动有的工具权限发生变化有的上下文被 harness 提前裁掉还有的只是 verifier 超时。即使确实是模型问题我们也需要知道它从哪一步开始偏离。一个最终分数回答不了这些问题。它只告诉我们结果却没有保存结果形成的过程。这正是 trajectory 的位置。Benchmark 产出分数Trajectory 负责解释分数。它把模型决策、工具执行、环境变化、评估结果和系统版本组织成一条行为证据链。Benchmark 用它判断结果是否可信、变化来自哪里后训练再从中挑选可学习的经验转换成 SFT、偏好学习或强化学习样本。所以这篇文章真正讨论的不是“如何多记一些日志”而是分散在各系统里的观测数据怎样被组装成一条可复现、可判定、可归因也能继续进入训练的 trajectory。对话、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 是面向算法的下游派生物一次 Benchmark本质上是七个变量共同作用模型只是评测系统中的一个变量。要解释一次结果至少要同时知道Task × Model × Harness × Tool × Environment × Budget × VerifierTask 决定目标和初始状态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 问题都依赖它们。一次具体 rollout会在哪些系统留下数据任务准备好后当前 policy 才开始 rollout。一次 Coding Agent 执行表面上是一串“模型回复、工具返回”在系统内部它会同时在模型网关、harness、工具网关、执行环境、verifier 和调度系统中留下记录。下面仍然使用“修复登录接口偶发 500”这个任务。为了看清数据关系我们构造一条接近生产日志的示例其中数值只是示意采集位置和因果关系才是重点。任务运行在仓库提交4f21c9上当前策略是policy13。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执行环境目标用例修复但出现一个回归Verifierreward 0failure regression调度系统无 OOM排除基础设施失败**网关记录调用工具记录执行环境记录事实verifier 负责判定调度系统解释成本与噪声。**任何一层缺失都可能把同一个结果归因给错误的对象。从这条 rollout 抽象出四类数据上面的数据来自不同系统也有完全不同的保存方式。把它们全部塞进一条超大的 JSON查询和权限都会很快失控。更自然的做法是先按用途分成四类数据形态回答的问题例子Trace / Span一个操作经过哪里、花了多久模型请求、工具执行、verifier 检查Event某个时间点发生了什么选择工具、压缩上下文、修改文件Metric整体是否出现趋势或异常Token、延迟、错误率、GPU 利用率Artifact判断所依赖的原始证据是什么Prompt、Patch、截图、测试日志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 / screenshotfact_model_call保存模型决策及其成本fact_tool_execution保存动作是否执行fact_state_transition保存环境前后差异fact_evaluation保存判定过程。大体积内容进入对象存储事实表只保留引用。四张事实表通过 rollout 标识和步骤顺序重新拼接。组装后的结果不再是一堆日志而是一条带业务语义的记录Trajectory ro_0017├─ Contextlogin_5003 / policy13 / repo 4f21c9 / Budget 10 分钟├─ Step 1..4观察、模型决策、工具执行、环境变化├─ Outcomereward 0 / regression└─ Evidencepatch、测试日志、模型与工具 trace 引用这条记录还必须绑定版本坐标(task_version, model_version, harness_version, tool_version, environment_version, verifier_version)版本不是附属元数据而是 trajectory 身份的一部分。没有它就无法判断两次评测是否真的可比也无法重放当时的行为。从 telemetry 到 evaluated trajectory大致经历四步先按 rollout 关联多源事件再按 Agent 实际看到的顺序重建 action 和 observation然后挂接环境状态与原始证据最后运行 verifier 并补上 reward、有效性和失败分类。到这一步trajectory 才同时具备三种用途回放一次执行、解释一次评测以及作为训练样本的上游数据。Trajectory 如何判断 Better、Same、Worse单次 pass/fail 只能判断一个 case 的结果。要比较 baseline 和 candidate还需要把同一个 task 下的多条 trajectory 放在一起。比较至少包含四个维度•结果是否完成任务reward 各分量如何变化•行为走了多少步调用了哪些工具第一处分歧在哪里•效率消耗多少 token、时间和计算资源•稳定性重复运行后通过率和失败类型是否稳定。因此结果分类不应该只有 Good 和 Bad而应至少有五种分类Trajectory 给出的证据Better成功率或质量提高且不是环境或 verifier 变化造成Same结果差异处于正常波动范围行为和成本没有明显恶化Worse在可比条件下成功率、质量或稳定性明确下降Invalid环境、工具、任务或 verifier 异常本次结果不应计入模型分数Inconclusive样本不足或模型之外的多个变量同时变化无法归因这里有两个很容易被忽略的情况。第一结果相同不代表 trajectory 相同。两个模型都通过任务candidate 却多调用了十次搜索工具、消耗三倍 token它在 outcome 上是 Same在效率上却可能是 Worse。第二单条随机 rollout 很难证明模型退化。对非确定性 Agent应该在相同版本坐标和预算下重复采样比较 pass rate、reward 分布和失败类型而不是用一次成败下结论。Verifier 在这里提供结果标签但它不是唯一真值来源。确定性结果优先使用单元测试、数据库状态或程序化 validator软性质量可以交给 reward model 或 LLM judge冲突和低置信样本再进入人工复核。LLM judge 还需要防范位置偏差、冗长偏差和自我偏好。同样是 0 分Trajectory 如何定位问题回到登录接口的例子。最终都是 reward 0trajectory 却可能讲出完全不同的故事。情况一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 找到第一处改变因果方向的事件。不是每条失败 Trajectory 都应该进入训练完成评测和归因后trajectory 才能进入数据筛选。最先隔离的是 Invalid环境启动失败、工具权限错误、verifier 冲突、调度 OOM。这些数据可以用于修复平台却不应该训练模型否则模型会被迫学习如何适应一套已经损坏的世界。真正由模型行为造成的成功与失败才进入候选池Trajectory 类型更合适的去向稳定成功且路径简洁SFT 或高质量行为样本同任务下成功与失败并存偏好对、GRPO 组或过程分析模型稳定失败但任务有效Curriculum、任务拆解或 hard case成功但代价明显升高效率优化、cost-aware rewardHarness、Tool、Environment 失败隔离并回流对应工程系统假设同一个 task 采样 16 条 rollout全部成功说明它对当前模型可能过于简单全部失败则要继续区分“模型尚不会”和“任务已经损坏”。成功与失败混合的区域往往最容易形成有区分度的训练信号。在 GRPO 这类组相对训练中如果同一 prompt 下所有输出奖励相同组内优势会变成 0。DAPO 的 Dynamic Sampling 因此过滤全对和全错的组继续采样有效组。但这些轨迹并非永久无用全对任务可以进入回归集全错任务可以用于课程学习和失败研究。Trajectory 还会随模型更新而过期。policy12的主要错误可能是不调用测试policy13已经解决它却开始过度修改文件。旧数据仍可用于 SFT、经验回放和回归分析但不能不带版本地冒充当前 policy 的 on-policy 数据。因此训练价值不能只看 reward还要同时考虑正确性 × 可判定性 × 难度 × 新颖性 × 当前策略相关性只有完成有效性检查和失败归因Benchmark trajectory 才能安全地变成训练资产。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评测集则需要密封、版本冻结和污染检测。否则每次把线上失败回流训练都可能顺手把评测答案喂给模型最后得到一条越来越好看的曲线和一个没有泛化能力的系统。先让每个 Benchmark 分数都可以被解释实际落地可以从一个小而可验证的领域开始例如有稳定单测的代码修复、结果可比较的 SQL 生成或状态可查询的内部工作流。第一版不必建设庞大的“Agent 数据中台”只需要确保六件事每个 task 有可重置的环境、预算和明确 verifier模型网关、harness、工具、环境与 verifier 共享 rollout 标识每条 trajectory 绑定 task、model、harness、tool、environment、verifier 版本模型 action、工具结果和环境状态变化能够按顺序重建Better、Same、Worse、Invalid 和失败归因有明确规则训练样本能够追溯到 evaluated trajectory 和原始证据。做到这些一次 Benchmark 才不再只留下排行榜上的一个数字Benchmark Run- Raw Telemetry- Evaluated Trajectory- 结果比较与失败归因- Training Sample- New PolicyTrajectory 在这里连接了评测和训练。向上它让我们知道分数能不能信、变化来自哪里向下它决定哪些行为值得学习哪些故障应该隔离。所以真正重要的不是“把 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%免费】