做 Agent 开发的人最近半年几乎都会被同一个问题卡住线上模型跑出来的执行轨迹那么多到底怎么变成下一版模型的训练数据我花了一段不算短的时间把这条链路完整跑通了一次——从日志埋点、轨迹清洗、样本构建到 SFT 和偏好对齐再到离线回归、线上灰度最后把线上新产生的轨迹回收进下一轮数据池形成一个真正能转起来的“Agent 后训练闭环”。这篇内容就是这次实践的过程拆解。这条链路解决的是一个很实际的问题很多 Agent 项目不缺日志缺的是把日志变成数据、把数据变成模型提升的加工方法。适合的人有两类。一类是正在做 Agent 后训练、但对数据侧无从下手的工程师另一类是已经跑通 Pipeline、想对照检查“我是不是漏了某些关键环节”的团队。接下来我按实际操作的顺序从轨迹数据的价值判断开始说起。1. 执行轨迹到底是种什么数据——先想清楚值不值得拿来训练1.1 一条完整轨迹的解剖在讨论训练之前得先统一对“执行轨迹”的认知。一个典型 Agent 任务的执行轨迹不是一段单调递增的文字而是一组结构化的循环过程。以 ReAct 这类最常见的范式为例一个 Agent 拿到任务后会反复执行“思考 → 调用工具 → 观察返回结果”这样的循环直到它认为自己可以给出最终答案。我通常会把一条轨迹拆成下面的结构任务描述Task用户原话或者经过意图改写后的任务文本。步骤序列Steps每个步骤包含 thought、action、observation 三要素。执行结果Outcome成功、失败、部分成功或者被用户中断。元信息Meta模型版本、Agent 框架版本、运行环境、时间戳、工具调用明细等。这里的 thought 是模型内部推理的显式文本action 是它决定调用的工具名称和参数observation 是工具返回的环境反馈。一条复杂的任务可能有十几步甚至几十步每一步都是这样一个三元组。把轨迹当训练数据本质是把这条“过程链”变成可学习的状态-动作序列。1.2 轨迹数据和静态指令数据有什么本质区别很多人一开始会拿 Agent 执行轨迹和普通的 SFT 指令数据做类比但两者差异很大。静态指令数据是“结果数据”它只告诉模型用户说了什么你应该输出什么。而执行轨迹是“过程数据”它额外包含了多步决策链、环境反馈、中途纠错这三样东西。具体来说轨迹数据里有三类静态指令数据很难提供的信息。第一是行动序列。模型能从成功轨迹里学到“一件事应该按什么顺序做”。比如用户问“帮我查一下某公司最新产品信息并整理成摘要”成功的轨迹可能包含调用搜索、打开链接、提取正文、再次搜索补充、汇总输出这一连串动作。只看结果摘要模型学不到这套动作编排。第二是纠错序列。大量真实轨迹里前几步是失败的比如工具参数给错了、搜索没返回有效结果、页面解析失败。模型随后调整策略换一种工具或者换一个关键词最后成功。这种“从错误中恢复”的路径是纯静态数据很难构造出来的。第三是工具反馈分布。轨迹里的 observation 部分记录了真实环境对工具调用的反馈模型通过这部分数据可以学会“某个工具在什么条件下返回什么格式、什么错误码”这是把模型从“只会生成文本”推向“真的会用工具”的关键一环。1.3 为什么不能直接拿原始日志训练既然轨迹这么有价值那直接把线上日志灌进训练集行不行我试过结论是不行而且代价很高。原始日志存在几个硬伤。首先是格式噪声。线上日志里交错着心跳检测、重试机制、模型流式输出片段、用户中途插话、系统超时提示甚至还有多轮并发请求互相穿插的记录。不把这些噪声剥离掉模型学到的会是“在什么时候说一堆无关内容”。其次是行为噪声。线上轨迹的成败是由很多因素综合决定的包括当前模型的策略、用户的实际投入程度、工具服务的稳定性。同一类任务用户中途放弃和模型完成任务在日志里可能看起来差不多但前者不应该作为正向训练信号。第三是目标不一致。线上 Agent 的设计目标可能是“尽可能完成任务”也可能是“尽可能少调用工具省成本”还可能是“优先保证安全不越权”。如果不理解线上目标的偏置直接训练会把业务规则里的保守倾向错误地学成“能力不足”或者把激进策略学成“无视边界”。所以执行轨迹有价值但原始日志不能直接用。需要一套加工流程把日志里的“数据矿石”提炼成“训练样本”。2. 从原始日志到干净样本轨迹采集与清洗全流程2.1 先设计好埋点字段否则后面全部白费轨迹清洗的第一步其实是日志埋点。这一步如果漏做后面再想补成本是成倍上升的。我建议每一条线上轨迹必须记录这么几个字段字段说明为什么必须记trace_id一次任务的全局唯一 ID用来把分散在不同服务里的日志串成完整轨迹task_id / task_text任务标识和任务原文后续做重复任务聚类、数据去重都能用到stepsthought/action/observation 的数组核心训练内容outcome成功、失败、部分成功、用户取消区分正负样本的基石user_feedback用户点赞、点踩、手动修改线上最真实的奖励信号model_version当前模型的版本标识数据血统追踪复盘时必须知道是谁跑出来的agent_versionAgent 框架与提示词版本同样的模型不同提示词产生的轨迹差异很大tool_call_detail每次调用的工具名、耗时、返回码分析工具失败率、识别投机性调用intervention是否有用户或人工介入纠正被人工纠正过的轨迹不能直接当成功样本这套字段看起来简单但实际踩坑时你会发现少一个字段就断一条线索。我之前就遇到过想分析某类任务的失败轨迹结果日志里没有记录 user_feedback导致完全无法区分“模型答错了”和“用户根本不想继续”两种情况那批数据最后只能作废。2.2 轨迹还原与并发交错处理在分布式环境下轨迹还原是个容易被低估的问题。Agent 执行过程中主控模块、工具网关、模型服务是三个不同的进程日志分散在三处按时间戳粗暴排序的话很容易把并行调用拼成乱序序列。我常用的做法是以 trace_id 为分组键把同一 trace 下所有事件捞出来再按事件时间排序最后过滤掉两类非业务事件——一类是模型侧的流式 token 输出片段另一类是网关层的健康检查和重试记录。做完这步才能得到一张干净的执行事件表。这里有个细节同一 trace 内Agent 可能会因为工具超时而重试。重试事件要保留但要在步骤里打上 retry 标记。训练时这些重试步骤既能作为纠错样本也可能成为噪声源关键看最终是否成功。成功轨迹里的重试是“知错就改”失败轨迹里的重试是“反复横跳”两者在筛选时要区别对待。2.3 清洗规则把轨迹加工成可读文本轨迹还原之后还要过一层清洗规则。我把常用的清洗操作列一下这些阈值是我在多次实验里逐步调出来的可以作为参考起点。观测文本截断。工具返回的 observation 经常特别长尤其抓取网页或读取文档时动不动上万字。我一般截断到 8000 字符以内超出部分强制截断并加截断标记。模型不需要把整篇网页都背下来它只需要学会从长文中抽取关键信息。敏感信息脱敏。轨迹里可能携带用户隐私数据、内部系统地址、密钥信息。这步必须用规则加模型双重过滤。脱敏不是隐去关键词就行要连格式指纹一起处理否则模型很容易从上下文学会“输出这类格式”而不是“安全地处理这类信息”。脱敏做不好后面训练集根本不敢外发质检。工具名归一化。不同版本框架可能对同一工具使用不同别名例如 search 和 web_search要统一映射到同义词表。简单任务过滤。有些轨迹只包含一步动作加一个答案这种样本的学习价值不高而且量大了会稀释复杂任务的占比不利于模型学会长程规划。经验阈值是步骤数少于 3 的轨迹除非是被重点关注的失败类型否则可以直接移除。相似轨迹去重。每天产生的轨迹可能高度相似尤其是搜索类任务反复出现“查天气”这类重复请求。我按任务文本的 embedding 相似度做聚类阈值取到 0.9 以上视为重复。只保留同类中质量最高的一条防止某类任务在训练集里过度泛滥。2.4 筛选规则与分层采样策略清洗完接下来是决定哪些轨迹能进入训练集。先说正样本的标准outcome 为成功且没有用户或人工介入纠正intervention 为空。这条标准比表面看起来严格因为很多线上“成功”实际上是被用户纠正之后才完成的比如用户中途补充说明“不是这个意思我要的是另一个版本”模型随后修正答案。这类轨迹代表模型有纠错能力但也有可能掩盖了“第一轮理解偏题”的问题。我一般会把这类轨迹单独打上修正标签不直接进正向 SFT。失败轨迹也不能全部丢掉。它们是天然的负样本用于偏好对齐阶段做 pair。但失败轨迹也要分类至少分成“模型犯错导致失败”和“环境不可用导致失败”。前者可用于 DPO 的 negative后者只能丢弃或作为环境鲁棒性分析材料。最后是分层采样。我会按任务类型做配额控制比如搜索类、代码生成类、数据分析类、网页操作类各占 20% 到 30%加上工具组合类确保训练数据不会因为业务偏置而变的单一。这一步的真实工作很繁琐但直接影响训练结果。2.5 质检人工抽检不能省自动化流程全部跑完后我建议大家至少抽检 1000 条轨迹做一次人工复核重点看三类问题轨迹是否完整有没有缺 observation、步骤排序是否正确有没有前后颠倒、筛选标签是否合理有没有把失败轨迹标成成功。人工抽检看起来费时但实际上能拦截掉大量规则覆盖不到的异常。这轮质检还有一个作用修正规则阈值。比如某类任务的轨迹普遍很长步骤数超过 25 就可能是触发了死循环但如果某类任务天然复杂那么 25 以上的正常轨迹也不少。质检员反馈这些边界情况后规则可以迭代得更准。3. 轨迹变训练数据的三条管线SFT、偏好对齐与过程监督3.1 SFT动作级监督只教模型“下一步做什么”SFT 是最直接的转换方式核心思路是把一条轨迹拆成若干“状态 → 动作”对让模型学会在给定的历史状态下应该采取哪个下一步动作。我构造 SFT 样本时用的是 chat 格式。一个样本长这样{ messages: [ {role: system, content: 你是一个能调用工具完成任务的助手。工具列表search(query), open_url(url), read_page(), summarize(text), respond(answer)。你必须一步步执行每步先输出 Thought 再输出 Action。}, {role: user, content: 查一下 AlphaTech 公司最近发布的第四代产品参数整理成对比表配一句点评。}, {role: assistant, content: Thought: 用户需要产品参数先搜索产品信息。\nAction: search(\AlphaTech 第四代产品 参数\)}, {role: user, content: Observation: 搜索到 3 条结果第一条是官网介绍页包含参数表。排名官网 新闻稿 第三方评测。}, {role: assistant, content: Thought: 官网信息最准确打开官网页面。\nAction: open_url(\https://...\)} ] }这里有两个关键点。第一只保留 assistant 的 thought 和 action 作为监督目标observation 归入 user 角色因为它本质上是由环境产生的而不是模型输出的第二最后一个 assistant 回复如果是最终答案则不需要附带 Action。在训练时还需要对 loss 做 mask只计算 assistant 内容中 thought/action 部分的 loss不计算用户消息和 observation 文本的 loss。模型不需要把 observation 一字不差地背下来它只需要参考 observation 来生成下一步动作。这一点很多人会忽略但恰恰是轨迹 SFT 与普通指令微调之间最大的差异。还有一个很实用的经验SFT 阶段千万不要把失败轨迹作为标准答案混进去。模型学到的不是“从失败中反思”而是“失败也无妨继续输出”。失败轨迹的正确定位是负样本应该在偏好对齐阶段使用。这个坑我早期踩过模型训完明显“摆烂”——遇到复杂任务它会更倾向直接放弃或重复无意义的工具调用。3.2 DPO构建成功对失败的轨迹对DPO 是偏好对齐里性价比非常高的方案因为它不需要训练一个独立的奖励模型只需构造“偏好对”数据。所谓偏好对就是同一任务下一条成功轨迹和一条失败轨迹配对让模型学会提高成功轨迹的概率、降低失败轨迹的概率。构造偏好对的难点在于如何保证两条轨迹的重合程度足够高。如果任务完全不同模型学到的只是“这两段话的概率此消彼长”没有实际意义。我常用的方法是对同一 task_id 的轨迹如果存在成功和失败两个版本直接配对。如果没有天然配对可以拿失败轨迹的输入让新模型重新执行一次。如果这次成功了就能得到一对“同一任务、旧失败、新成功”的轨迹。同一成功轨迹如果真的没有失败副本也可以用“成功轨迹的全过程”和“把某几个步骤置乱后的伪造失败轨迹”来凑对但这种手段只能作为补充不建议大量使用。DPO 样本的构造格式是把整条轨迹序列化成一串文本再做 pair。实际效果看凡是轨迹长度适中、差异集中在某几个关键步骤的偏好对对模型提升最明显差异太小的 pair只有一处用词不同反而容易让模型在细节上变得敏感甚至会轻微损害原有生成能力。3.3 PRM给每一步过程打分SFT 和 DPO 都停留在轨迹级但 Agent 任务里一个致命的错误往往只发生在一个步骤上。过程奖励模型PRM的思路是把监督信号细化到步骤级别训练一个模型对“状态 候选下一步动作”打分。自动生成过程标签的方式主要有两条路。第一条基于结果回传轨迹最终成功则其内部所有步骤标为正轨迹最终失败则所有步骤标为负。这种方式噪声较大因为失败轨迹里其实也有正确步骤。第二条规则判定针对常见工具调用用工具返回码、是否触发异常、是否重复调用等规则给每个动作打上“有效/中性/无效”的标签。实际项目里我会结合两条路再加人工抽样修正。PRM 训练数据中一个样本是{ state: 当前任务状态 历史步骤摘要, candidate_step: 模型计划采取的下一步动作, label: 1 }PRM 训练好之后它的价值不止在训练阶段。推理时可以用它对模型生成的多条候选轨迹做步骤级重新排序比单纯靠“最终答案置信度”来选路靠谱得多。这一步如果我们把 PRM 回溯用于下一次轨迹筛选就形成了过程信号层面的闭环。3.4 反思样本把失败轨迹变成修正课真实线上轨迹数据里成功轨迹往往是少数派失败轨迹占大头。如果只靠 DPO 消化失败样本浪费了大量信息。我的做法是把一批失败轨迹转成“反思样本”格式是失败轨迹 反思分析 修正重试。具体操作是把失败轨迹发给一个更强的模型让它分析“问题出在哪一步、为什么出错、应该怎么做”生成一段明确的反思文本然后带着这段反思让模型重新执行原任务得到新轨迹。如果重试成功我们就得到了一条包含“失败反思成功”三段内容的复合轨迹。这种样本的训练收益非常明显。模型学到的不只是一个动作对而是“遇到这类问题时先诊断再修正”的决策习惯。尤其是工具参数错误、信息源选择不当这两类高频失败反思样本能显著降低复发率。反思样本的缺点是构造成本高因为需要额外调用模型还需要判断重试是否成功。我控制的比例大约是训练集的 10% 到 15%再多会让训练数据整体偏“话痨”模型容易在动作前生成大段无谓的自我剖析。3.5 各管线数据的配比参考三条管线不是平均分配。我以一次实际训练任务为例当时数据池里共有约 12 万条轨迹经过清洗、筛选后合格样本约 2.1 万条。最终配比是管线类型样本数占比说明SFT 正样本约 8000 条38%仅使用成功轨迹动作级监督DPO 偏好对约 6400 条3200 对30%同一任务的成败 pairPRM 过程标签约 4800 条23%规则 人工抽样校准反思样本约 1900 条9%失败重试复合轨迹这份配比的关键在于SFT 保证基础能力DPO 修正偏好PRM 强化过程信号反思样本补齐错误恢复能力。顺序上不能打乱——先 SFT 提升动作准确率再 DPO 做偏好对齐最后再引入 PRM 和反思样本。跳步训练会导致模型在不同目标之间反复横跳效果反而更差。4. 闭环的另一半离线回归与线上灰度怎么衔接4.1 评估集怎么造黄金任务与时间分窗训练数据加工好模型也训练完了这时候最怕的是“自我感觉良好”。我用两套评估集来做离线回归。第一套是黄金任务集固定 500 条覆盖各任务类型的评测任务每条任务都有明确的成功标准人工预跑过 baseline确保它们都是可完成的。第二套是时间分窗集从线上日志里按新时间段采样一批任务例如用 T-1 到 T 两周内、且不在训练集里的任务做验证。时间分窗这件事特别重要。Agent 任务和普通 NLP 任务一样存在任务分布漂移上周热门的问题类型这周可能就少了某些工具的上游接口变了返回格式也会漂移。如果把训练集和验证集都从同一时间段取样哪怕做了严格 task 去重分布泄漏依然存在。我见过不止一个团队因为忽略时间分窗离线指标被高估了几个点。4.2 离线指标组合单看成功率一定会被骗评估 Agent 模型不能只看任务完成率那太粗了。我每个版本都会统计四类指标指标说明关注点任务完成率成功完成任务的比例整体能力不下降是底线工具调用失败率调用工具时返回异常的占比下降说明模型更会“用工具”平均决策步数完成任务所需的步骤数明显上升可能是因为犹豫/试探变多拒绝率与越权率直接拒绝任务或调用禁止工具安全与合规维度这四类指标要看组合变化不能单独看。比如新模型任务完成率上升了 2%但平均决策步数同时上升了 20%那很可能是模型学会了“多绕几步混成功率”并不是真正变强。又比如工具调用失败率下降了但拒绝率上升了说明模型可能是在用“不调用工具”规避失败风险。4.3 回归对比逐个看新老模型的输出差异离线评估除了看指标还要做抽样对比。我把新老模型在同一批任务上的输出逐条对照重点看三类变更新增了哪些正确的工具调用之前模型漏掉的哪些原本正确的动作新模型反而做错了这类属于回归哪些步骤虽然结果对但执行路径更绕这类属于效率回退。这个动作很费时间但非常值。我第一次跑完整流程时靠这层逐条对比发现新模型在代码生成类任务里“学会了用代码解释器”但“忘了还能直接读本地文件”导致原本一步能完成的事变成了三步。这种问题在聚合指标里完全看不出来只有逐条对比才能暴露。4.4 线上灰度从小流量到全量的节奏离线评估通过不代表可以直接全量上线。我会按 5% → 20% → 50% → 100% 四步灰度每步至少观察 24 小时。灰度期间重点盯三类线上信号任务完成率与 baseline 模型对比、用户反馈点踩率、人工纠正率、工具网关错误率。如果发现完成率不升反降或者错误率抖动立即回滚到上一个稳定版本。回滚本身要设计成一键操作最好在模型网关层就做分流而不是等到应用层才发现问题。这里有个容易被忽略的细节灰度期产生的轨迹数据要保持独立存放标记上模型版本。这些轨迹就是下一轮训练的原材料也是判断本次迭代真实收益的证据。5. 把反馈接回数据池一套可持续迭代的工程闭环5.1 一轮完整的轨迹闭环长什么样到这里整个闭环的各个环节都出现了。把它们串成一个可持续运转的流水线大概是下面这个顺序线上 Agent 运行原始日志落到数据管道日志按 trace_id 还原聚合生成原始轨迹集清洗去噪、脱敏、去重形成候选池按规则筛选正负样本做分层采样形成训练批次按 SFT / DPO / PRM / 反思四条管线加工训练样本训练完成后跑离线回归黄金任务 时间分窗任务通过后按灰度节奏发布到线上采集效果指标灰度期产生的新轨迹回流到数据池参与下一轮清洗与采样。这八步就是“Agent 执行轨迹 → 训练数据 → 模型迭代 → 新轨迹 → 再训练”的完整闭环。听起来简单但每一步都有各自的坑。5.2 数据血统管理每条轨迹都要有户口本闭环要能长期转最重要的一件事是数据血统管理。每条进入训练池的轨迹必须携带完整的版本元信息。我维护了一张线索表字段包括轨迹 ID、采集时间、来源模型版本、Agent 框架版本、提示词版本、任务类型、清洗规则版本、最终用途SFT/DPO/PRM/反思/未采用。任何一次训练用到的数据都能从血统表反查到源头。血统管理最直接的用处是复盘。有一次新版本模型在某个任务类型上明显退步我用血统表一查发现训练集里混入了大量由旧提示词版本产生的轨迹而旧提示词的决策风格和现在的目标恰好相反。如果没有血统表这种问题几乎不可能定位。5.3 迭代节奏不是每天都要跑一轮闭环能转不代表要天天转。我的建议是每 1 到 2 周跑一轮完整训练前提是候选池新增了足够数量的合格样本。如果这周线上流量平淡新增合格轨迹不足 3000 条那宁可不训练也不要拿凑数的数据硬跑的。频繁用小数据量训练模型很容易在个别任务类型上过拟合整体能力反而下降。数据不足时的替代方案是调低筛选阈值纳入更多“部分成功”轨迹或者补充人工构造的合成轨迹。合成轨迹有个好用的办法——拿合格任务让当前模型多跑几次记录不同随机温度下的多条候选轨迹再用规则打分挑出最好的一条入库。这相当于把模型自己的能力当成数据增强器。5.4 成本与资源估算别让数据工程吃掉训练预算轨迹清洗看起来只是“处理日志”实际消耗的资源一点都不少。以 12 万条原始轨迹的规模为例清洗阶段的算力主要消耗在 embedding 去重和脱敏模型推理上大约需要几天的小型 GPU 实例人工质检 1000 条轨迹大概需要两个标注人员各花两到三个工作日反思样本的构造需要调用强模型一条约 0.1 元左右。整体算下来单个训练批次的数据工程成本约占整体训练预算的 30% 到 40%。所以我的建议是把数据工程当做和训练本身同等重要的一环来排期而不是“跑完训练再说”。数据质量低导致训练返工浪费的算力和时间成本比提前投入数据清洗要高得多。6. 跑了半年踩过的坑常见问题与排查技巧6.1 数据泄漏验证集里混进了训练集轨迹这是最隐蔽、后果最严重的问题。我曾有一版模型离线指标漂亮得反常上线后却明显退步后来排查发现验证集里混进了与训练集高度相似的任务。原因是我用了“按任务文本精确去重”但线上任务经常只改几个字就变成“新任务”embedding 相似度很高精确去重根本拦不住。修复方案有两层。第一层去重改用 embedding 相似度阈值设在 0.85 左右第二层坚持时间分窗确保训练集和验证集来自不同时间段。如果你做不到第二层至少保证验证集任务的采集时间晚于训练集 7 天以上。6.2 格式崩塌模型学会了生成 Observation 而不是 ActionSFT 训练后出现了一个诡异现象模型在中间步骤直接生成“Observation: 这是我从网页里看到的内容”然后不再调用工具。原因是样本构造时我把 observation 也放在 assistant 内容里参与训练模型误以为 observation 是它自己应该输出的东西。修复方案是在样本构建时严格区分角色observation 全部写入 user 字段训练时用 loss mask 屏蔽只让 assistant 生成 thought 和 action。这个问题也提醒我样本构造完成后一定要先抽出少量样本看一眼“模型视角下”的完整上下文是什么而不是只看 JSON 结构是否正确。6.3 奖励黑客PRM 学会了投机取巧PRM 训练初期我给每个步骤的标签是“工具是否调用成功”。结果模型很快就摸到了规律——只要它调用一个无害的工具比如“搜索一下”但根本不看结果这个动作就能获得正标签。于是模型学会了频繁触发无意义调用刷 PRM 分数整体执行路径越来越长任务完成率反而下降。修复方法分两步。第一步标签里加入“这一步是否推动任务向最终目标靠近”的人工抽样判断只靠工具返回码不够第二步在特征里加入“该动作是否重复调用同工具”的惩罚信号重复调用超过两次即使工具成功也降分。6.4 长轨迹训练不稳定loss 震荡越练越差早期训练时包含 20 步以上的长轨迹样本会引发 loss 震荡甚至出现一个 batch 里 loss 特别大、下一个 batch 直接爆炸的情况。排查后发现原因有两个一是 packing 时把多条轨迹拼在一起长样本截断了正常上下文二是我把整段轨迹的全部文本包括长 observation都计入 loss导致模型被极端长度的文本主导。修复方案是对轨迹按长度分层打包超过 1024 token 的样本单独处理loss 只对动作位置计算observation 位置直接 mask 掉。下面是一个 mask 的简化示意# labels: 与输入等长的标签序列 # 所有 observation 位置的标签设为 -100SFT 时不参与 loss labels [ -100 if is_observation(turn) else token_id for turn in trajectory ]这个修改直接把训练稳定性拉回来了。之后我养成了一个习惯训练前先统计轨迹长度分布再决定 packing 策略绝不无脑拼包。6.5 数据新鲜度陷阱旧版本轨迹带偏了新模型闭环跑久之后数据池里会积累很多历史轨迹。最初我舍不得丢弃旧数据结果训练集里混着三个月前的轨迹而三个月内线上工具接口、任务分布、用户习惯全都变了。模型既学不到最新的工具返回格式又被过时数据里的旧行为干扰。我现在的做法是引入时间衰减超过四周的轨迹权重减半超过八周的轨迹降权到 10%超过十二周的直接移出训练池。保留策略是“旧数据只留分析用不进训练集”。这个习惯帮我拦下了至少两版有明显数据泄漏风险的训练批次。如果你也在做 Agent 后训练建议第一件事就是把数据池的“时间账本”和“版本账本”建起来。每条轨迹标清楚采集时间和模型版本训练前先看一眼数据池的时间分布和版本构成。这个账本会帮你避免掉绝大多数让人半夜爬起来排查的问题。
