AI Agent 如何持续改进：从运行轨迹到可复用经验

AI Agent 上线并不意味着优化工作结束。真实业务中的用户表达、工具状态、权限边界和异常组合会持续变化，即使模型和提示词没有改动，同一个任务也可能走出不同的执行路径。

传统软件可以依靠固定输入、确定逻辑和回归测试控制行为，而 Agent 的结果还会受到模型采样、上下文内容、任务规划和工具返回影响。一次评测成功，只能证明它在某个样本上完成了任务，不能证明它已经具备稳定的生产能力。

Agent 自进化的核心不是让系统自己修改模型权重，而是从真实运行中持续发现有效方法，再把经过验证的经验用于后续任务。

为什么只改提示词很难持续解决问题

Agent 出现问题时，团队通常会先修改系统提示词，例如增加一条规则：

遇到空结果时不要重复调用同一个工具。

这种方式对单个问题有效，但规则不断累积后，系统提示词会越来越长，也越来越难维护。

更麻烦的是，很多失败并不是通用规则缺失，而是特定场景中的行动选择不合理，例如：

• 选错了数据入口；
• 没有检查工具调用的前置条件；
• 参数范围过大，导致查询超时；
• 空结果后反复执行相同操作；
• 工具已经返回错误，却继续沿用旧计划；
• 输出内容看起来完整，但没有真正满足业务目标。

这些问题与其写进一份不断膨胀的提示词，不如沉淀为带有适用范围的行动经验，在遇到相似任务时再按需召回。

从 Trace 到经验，中间还需要哪些处理

Agent 每次运行都会留下模型调用、工具调用、观察结果和错误信息，这些原始记录通常称为 Trace。

但 Trace 不等于经验。它可能包含大量基础设施日志、重复消息、无关参数和中间状态，直接把整段记录塞回上下文不仅成本高，也很难帮助模型做出更好的决定。

更合理的处理链路可以分为三层。

Trace：还原真实执行过程

Trace 用于回答“Agent 实际做了什么”，通常包括：

• 用户目标；
• 模型生成的计划；
• 调用了哪些工具；
• 每次工具调用使用了什么参数；
• 工具返回了什么；
• 发生了哪些错误；
• Agent 如何恢复；
• 最终交付了什么结果。

Trace 应尽可能完整，但不适合直接作为长期经验使用。

Trajectory：提取与决策相关的轨迹

Trajectory 是经过清洗和整理的执行轨迹，只保留真正影响任务结果的内容：

任务目标
  → 关键决策
  → 工具调用
  → 观察结果
  → 错误与恢复
  → 最终结果

它应过滤网络重试日志、重复消息和无关基础设施信息，同时统一工具名称、错误分类和完成状态，方便后续比较不同任务。

Experience：形成可以复用的行动经验

经验不是对单条轨迹做摘要，而是比较多条成功与失败轨迹后，提炼具有重复价值的规律。

常见经验可以分为：

• 入口经验：某类任务优先从哪个系统或接口开始；
• 参数经验：工具需要哪些前置参数，范围应如何限制；
• 顺序经验：哪些操作必须先执行，哪些可以并行；
• 恢复经验：出现空结果、超时或权限错误后应该怎么处理；
• 反模式：哪些看似合理的路径经常导致失败；
• 完成规则：交付前必须检查哪些内容。

例如：

适用场景：查询某个云资源最近一小时的异常指标

经验：
先确认资源所在地域，再调用监控接口。
如果返回空结果，不要立即扩大时间范围；
先检查资源 ID、指标名称和地域是否匹配。

这类经验比“查询失败时仔细检查参数”更具体，也更容易在下一次任务中发挥作用。

Agent 持续优化闭环怎么建立

一套可落地的闭环通常包含七个步骤。

1. 定义任务成功标准

如果系统只记录最终回答，却没有明确什么算成功，就无法判断哪条轨迹值得学习。

不同任务需要不同标准，例如：

• 是否拿到了正确数据；
• 是否调用了允许使用的工具；
• 是否遗漏必填字段；
• 是否引用了指定知识；
• 是否需要人工修改；
• 是否在规定时间和成本内完成。

成功标准应尽量由业务结果决定，而不是只看文字是否流畅。

2. 采集完整运行轨迹

采集内容至少应覆盖模型调用、工具调用、错误、恢复过程和最终结果。对于长链路任务，还要能关联同一次运行中的全部步骤。

如果只能看到最终答案，就无法判断问题出在规划、工具、知识、权限还是完成检查。

3. 清洗并标准化轨迹

把不同 Agent、模型和工具产生的日志转换成统一结构。需要重点统一：

• 任务类型；
• 工具名称；
• 参数结构；
• 错误类型；
• 结果状态；
• 人工介入情况；
• Token、耗时和调用次数。

标准化后，系统才能比较不同运行之间的共同点。

4. 比较成功和失败路径

经验提取不应只学习成功案例。失败轨迹通常能暴露更明确的边界条件，例如某个参数组合容易超时，或者某种恢复方式会造成重复调用。

可以从以下角度比较：

• 成功路径是否使用了不同入口；
• 工具调用顺序是否不同；
• 参数范围是否更小；
• 是否做了额外验证；
• 失败任务在哪一步开始偏离；
• 哪些错误恢复动作真正有效。

5. 生成并审核候选经验

系统可以自动生成候选经验，但生产环境中不宜让未经验证的经验立即影响全部任务。

每条经验至少应包含：

名称
适用任务
触发条件
建议动作
禁止或高风险动作
验证样本
版本
有效期

高风险场景还应经过人工审核，尤其是涉及生产数据、凭证、删除操作和外部消息发送的经验。

6. 在关键决策点召回

经验不是越多越好。一次向 Agent 注入大量历史内容，可能增加 Token 成本，也可能让模型受到无关经验干扰。

更合适的召回时机包括：

• 任务刚开始，需要选择入口时；
• 调用关键工具之前；
• 出现错误或空结果之后；
• 准备判断任务已经完成时。

召回结果应结合当前任务、工具、执行进度和错误状态进行过滤，只提供少量真正相关的经验。

7. 重新评估并持续淘汰

经验加入系统后，需要比较优化前后的结果。如果任务成功率没有提高，或者成本和延迟明显上升，就应限制、修改或下线这条经验。

模型、工具和业务规则都会变化，过去有效的方法可能逐渐失效。因此经验需要版本、有效期和回归评测，不能永久累积而不治理。

应该用什么指标判断是否真的变好

只看平均正确率并不足以证明 Agent 可以稳定上线。至少应同时观察下面几类指标。

质量指标

• 任务成功率；
• 首次完成率；
• 多次执行的结果一致性；
• 最低表现；
• 必填内容遗漏率；
• 人工返工率。

执行指标

• 平均工具调用次数；
• 重复调用次数；
• 错误恢复成功率；
• 超时率；
• 平均执行时间。

成本指标

• 单次任务 Token；
• 每个成功任务消耗的 Token；
• 每个成功任务的工具调用成本；
• 人工介入时间；
• 轨迹存储和分析成本。

最值得关注的通常不是“每次调用用了多少 Token”，而是：

完成一个成功任务，需要付出多少综合成本？

某条经验可能增加少量上下文，却显著提高成功率。这种情况下，单位成功成本反而可能下降。

经验库与 Memory、RAG、Workflow 有什么区别

这些能力解决的问题不同，不应该混在一起。

例如，RAG 可以告诉 Agent 某个接口有哪些参数；经验库则可以告诉它，在某类任务中应该先确认地域，否则这个接口经常返回空结果。

Workflow 适合确定性较强的流程；经验更适合处理存在多种路径、需要根据上下文做选择的任务。

小团队可以怎样逐步落地

不需要一开始就建设复杂的经验平台。小团队可以按三个阶段推进。

第一阶段：先让失败可观察

选择一类高频任务，记录完整的工具调用和错误过程，建立明确的成功标准。先解决“为什么失败看不见”的问题。

第二阶段：人工总结高频经验

定期查看失败轨迹，优先整理重复出现的问题：

• 参数缺失；
• 工具选错；
• 范围设置过大；
• 空结果后无效重试；
• 没有完成验证。

把这些经验以结构化规则保存，并在任务开始或错误发生时按需提供。

第三阶段：自动生成候选经验

当轨迹和评估数据积累到一定规模后，再让模型比较成功与失败样本，自动生成候选经验。仍然保留审核、版本和下线机制，避免错误经验被持续放大。

落地时需要注意什么

经验系统会接触用户输入、工具参数、错误日志甚至业务数据，因此需要建立清晰的数据边界：

• 不把密码、Token 和密钥写入经验；
• 对个人信息和业务敏感数据进行脱敏；
• 按团队、项目和环境隔离经验；
• 生产与测试经验不要默认混用；
• 高风险动作必须保留权限校验和人工确认；
• 经验只能提供建议，不能绕过工具本身的安全限制。

Agent 自进化不是让系统脱离控制地修改自己，而是建立一个可观察、可评估、可回滚的持续优化过程。

当真实运行轨迹能够被转化为经过验证的行动经验，并在恰当的决策点重新使用，Agent 才可能从“偶尔完成任务”逐步走向稳定、可管理的生产能力。