Agent 后训练与持续进化：何时改模型，何时改系统

当 Agent 失败时，最容易想到的办法是换一个更大的模型。但很多问题其实来自上下文缺失、工具契约模糊、检索结果过期或验证器没有覆盖目标。模型后训练很重要，却不应该成为所有系统问题的默认答案。

一、先定位失败属于哪一层

可以按成本从低到高检查：

任务表达 -> 上下文组织 -> 记忆/检索 -> 工具与权限
    -> Harness 与验证 -> 模型参数与后训练

如果模型没有看到关键文件，增加训练数据不会让它凭空获得事实；如果工具返回“成功”却没有验证，换模型也不能保证外部状态正确。只有当轨迹显示模型在信息充分、工具正确、验证清晰的情况下仍然系统性做错，才值得考虑模型层面的训练。

监督微调（SFT）从高质量示例学习“应该如何回答或行动”。它适合统一格式、教授稳定流程和补充领域表达，但示例覆盖不到的长链路情况仍可能失败。

强化学习则通过奖励让模型偏向更好的结果。对 Agent 来说，奖励可以来自最终结果，也可以来自中间过程，例如工具选择是否合理、参数是否合规、是否及时验证。奖励设计不准确时，模型可能学会投机：看起来完成了任务，却绕开了真正的验收。

因此，训练前要先确认奖励对应真实目标，并保留独立的验证器。一个可执行的结果奖励应该来自外部状态或测试，而不是只让另一个模型凭印象打分。

高质量轨迹不只是“输入和最终答案”，还包括：观察到什么、选择了哪些工具、工具返回了什么、在哪一步失败、怎样恢复以及最终是否通过验收。

对轨迹分类后，可以产生不同的改进动作：

这种分层能避免用模型训练掩盖系统设计缺陷。

如果 Agent 可以根据线上轨迹自动改写提示词、工具或记忆，就必须把“学习”和“发布”分开。候选改动先在固定评估集、对抗样例和安全检查中运行，只有达到门槛后才进入小范围流量。

最小发布链路可以是：

轨迹采集 -> 失败分类 -> 生成候选改动 -> 离线评估
    -> 安全审查 -> 小流量验证 -> 发布或回滚

每个版本都要能追溯到使用的模型、提示词、工具 schema、知识库快照和评估结果。否则一旦成功率下降，系统无法判断是哪个变量造成了变化。

持续进化的边界应该明确：Agent 可以总结经验、提出候选规则和生成测试，但不能自行扩大权限、修改审计逻辑、删除失败记录或跳过人工确认。自我改进的对象必须处于受控配置和版本管理之下。

另外，线上用户反馈不能直接当作真值。一个“有帮助”的评价可能只说明表达顺畅，并不证明数据库状态正确；一个负面评价也可能来自超出权限的合理拒绝。反馈要和确定性验收、人工复核结合起来。

如果问题能用明确的规则、工具或验证器表达，优先把它做成系统约束；如果问题是稳定地从大量示例中学习行为模式，再考虑 SFT 或强化学习。真正成熟的 Agent 不是每天自动改变自己，而是能从轨迹中找到问题、用实验验证改动，并且在结果变差时安全回到上一版本。