Agent 数据闭环：从生产轨迹到持续改进

生产轨迹是最有价值也最容易被浪费的数据

Agent 上线后会产生大量模型调用、工具调用、错误、人工修改和最终结果。如果团队只看成功率和几条用户反馈，就很难知道问题来自模型、上下文、工具还是工作流。更糟的是，直接把全部轨迹拿去“训练”，会把隐私、偶然行为和错误决策一并放大。

数据闭环的目标，是把真实运行转成可复现的问题、可度量的实验和受控改进，而不是不断收集更多日志。

先建立统一运行事件

每条轨迹要能还原任务因果链。建议统一记录运行 ID、任务类型、策略版本、模型调用、工具参数摘要、工具结果码、状态转换、人工动作、成本和最终验证。

不同事件通过父子 ID 关联：

{
  "event": "tool_call_completed",
  "runId": "run-91",
  "stepId": "step-4",
  "tool": "query_incidents",
  "attempt": 2,
  "latencyMs": 842,
  "resultCode": "OK",
  "artifactRef": "artifact-18",
  "policyVersion": "p7"
}

正文、客户数据和密钥不应默认进入分析仓库。通过引用连接受控原始数据，离线分析只使用脱敏字段和必要摘要。采集范围应与用户授权和保留政策一致。

失败分类比一个错误率更有用

建立可以指导工程行动的分类体系：目标理解错误、上下文缺失、检索失败、计划错误、工具选择错误、参数错误、外部依赖失败、权限拒绝、结果验证失败、人工拒绝和成本超限。

同一次运行可能有多个错误，但要标记首个根因和后续影响。例如工具 Schema 含糊导致参数错误，随后三次重试只是症状。若把它们都统计为模型能力不足，团队会在错误方向上调整 Prompt。

分类可以先由规则和模型自动建议，再由人工抽样校准。高风险事故必须人工复盘，不能完全相信自动标签。

从生产问题生成评测用例

每个重要失败都应沉淀为可重复场景：初始状态、用户目标、可用工具、模拟工具响应、成功条件和禁止行为。敏感数据替换为结构等价的合成数据。

评测用例不仅保存最终输入，还要保存当时关键环境版本。检索索引、工具 Schema 和策略变化后，同一句用户问题可能代表不同实验。

可以维护三层集合：固定核心集防止主要能力回归；近期失败集关注当前问题；随机生产样本监控分布变化。只优化近期失败会造成对少数案例过拟合。

人工修改是高价值反馈，但不是绝对真相

用户编辑 Agent 草稿、拒绝审批或选择另一个方案，说明输出与期望存在差距。记录修改前后差异和任务上下文，可以发现风格、事实和动作边界问题。

但用户修改可能出于个人偏好，也可能本身错误。应区分明确负反馈、隐式行为和专家审核。一个用户删除某段话，不代表所有场景都应删除；多次跨用户、同任务模式出现的稳定信号更值得进入默认策略。

对于审批拒绝，记录拒绝原因选项比只有“取消”更有价值：参数错误、时机不合适、风险太高或根本不需要该动作，对应不同改进。

用假设驱动实验

每次改进先写清假设。例如：“将两个相似搜索工具的描述加入反例，可把工具误选率从 8% 降到 4%，且不增加步骤数。”然后在固定评测集和影子流量中比较。

实验单位可能是 Prompt、模型、工具 Schema、检索策略或工作流，不要一次同时改五个部分，否则即使指标提升也无法归因。

除了任务成功率，还要设置护栏指标：安全违规必须为零，成本高分位不能明显恶化，延迟和人工介入率在可接受范围。新版本只在目标指标和护栏同时满足时逐步放量。

防止反馈回路放大偏差

若系统只学习成功完成的任务，会忽略被用户取消或无法服务的人群；只采纳高频用户反馈，又可能让产品越来越适合少数专家。数据分析需要按任务、用户群、语言、风险和难度分层。

模型生成的内容不能未经验证直接成为训练真相。自我生成、自我评分、自我学习容易闭环强化同一种错误。关键事实由工具或人工验证，开放式质量由多个信号共同判断。

删除和隐私请求必须传播到轨迹、评测集、缓存和训练候选数据。数据闭环不能成为绕过产品数据治理的另一个仓库。

建立从发现到发布的节奏

一个可操作周期是：每周聚类失败与人工接管，选择影响最大的两三类；将代表案例加入评测；针对根因提出最小改动；离线回归；小流量影子运行；逐步发布；观察一段稳定窗口；记录结论。

仪表盘应能从指标下钻到脱敏轨迹，再跳转到对应评测和修复版本。这样团队讨论的是证据，而不是某次演示的主观印象。

小结

Agent 数据闭环不是把日志喂回模型，而是把生产事实转成失败分类、评测资产和受控实验。统一事件、隐私治理、根因分析和版本化发布结合起来，系统才能持续变好，并且知道自己为什么变好。