本文是「Agent 开发实践与思考」系列第 17 篇。系列目录：
- 2024
- 2025
- 01-28 长任务不失忆：上下文压缩、交接文档与子任务隔离
- 02-25 MCP 用了三个月：工具标准化之后 Agent 设计变了什么
- 03-25 拆解 Coding Agent：为什么”写代码 + 文件系统”是通用 Agent 的内核
- 05-13 Agent 如何用代码完成推理、校验、适配与展示
- 06-03 能看会说的 Agent：语音交互与 Computer Use 这半年
- 06-24 从同步问答到事件驱动：异步 Agent 的架构改造笔记
- 07-08 没有评估就没有迭代：我的 Agent 评估落地记
- 09-09 后训练扫盲：SFT 记知识、RL 学长处，和 Agent 有什么关系
- 10-01 AI Coding 的上下文摘要：几家产品到底在压缩什么
- 10-14 让 Agent 从经验里长本事：失败复盘、经验库与提示词自动优化（本篇）
应用层可更新的三类 Agent 资产
先区分 Agent 系统中三类可发生变化的位置。
第一类是模型权重，即后训练。SFT 和 RL 的机制见后训练扫盲。应用层通常无法采用这条路径：训练成本高，需要成规模的数据；业务产生的失败 case 按周积累，无法匹配按季度进行的训练周期。业务规则也可能在下个月变化，写入权重后难以及时更新。
第二类是上下文。每次任务开始时，将相关经验加入提示词，模型可以在当前任务中使用。上下文按会话管理；会话结束后，其中的经验不会自动进入下一次任务。相同问题若未被整理并写入后续上下文，后续任务仍会重复出现。
第三类是外部资产，包括经验库、记忆条目、流程文档和提示词。这些资产存储在模型之外，可持久化、版本管理、审查，并按需注入上下文。应用层的“学习”通过这一层完成：从日志提炼经验，存为结构化资产，并在满足条件时加入上下文。工程实现需要确定提炼方法、资产结构和检索时机。
失败复盘生成带场景标签的教训
失败复盘参考 Reflexion（2023）：任务失败后，模型生成一段反思文本，并将其加入后续重试的上下文。Reflexion 的原始机制主要用于单个任务的多次尝试，反思文本不会自动改变模型权重。我们将反思内容扩展为跨任务的持久存储。
评估判负或用户差评的 case 会触发一次复盘调用。输入包括任务描述、执行轨迹和失败判据，输出是一条固定格式的教训，包含适用场景、触发条件和建议动作。例如：
{
"scenario": "billing.refund",
"trigger": "用户要求退还已使用部分的费用",
"action": "先查订阅周期和使用量，按剩余天数折算，不要直接全额退款"
}实现中需要处理两个问题。
第一，教训需要绑定场景标签，并在注入时按标签检索，不能全文注入。早期版本将所有教训加入系统提示词；一条“调用退款接口前必须二次确认金额”的教训被用于纯查询任务，模型要求用户再次确认后才执行正常查询。场景不匹配的教训会干扰任务执行。现在我们使用任务类型和向量相似度双重过滤，只取最相关的三五条。数量上限也经过成本核算：教训占用任务的上下文预算，十条教训约为上千 token；条目过多还可能包含部分冲突的指令，使模型行为难以预测。
第二，教训需要定期清理。业务规则会变化；三个月前“赠送额度上限是 500”的教训，在额度政策改为 1000 后会成为错误知识。模型无法自行判断教训是否仍有效，仍可能遵循该条目。我们为每条教训记录来源 case 和写入时间，每两周使用最新评估集进行回归，淘汰被新数据证伪或长期未命中的条目。
将验证过的执行路径存为流程文档
失败复盘记录了需要避免的操作，成功路径也需要保存。这部分参考 Voyager（2023）：它在 Minecraft 中将已学会的技能封装为代码存入技能库，后续任务通过检索复用；整个过程不改变模型权重。
我们的对应物是流程文档。一个任务类型在评估集上稳定通过后，将执行路径提炼为结构化文档，包括步骤、分支条件和每一步的验收点。以退订类任务为例，验证过的标准路径是：先查订阅状态，判断是否在合约期内；在合约期内先计算违约金并告知用户；确认后执行退订；最后检查关联服务是否需要一并处理。这份文档由成功轨迹自动生成初稿，经人工修改确认后入库；同类任务执行时，将其注入上下文。文档以 Markdown 文件存入 Git 仓库，改动经过常规 review 流程。经验资产因此使用代码已有的版本历史、diff、回滚和评审记录，无需额外建设管理系统。Voyager 将可执行技能封装为代码并在后续任务中检索调用；自然语言流程文档不等同于其技能库。
流程文档与提示词中的规则承担不同职责。规则用于约束禁止操作；流程文档描述操作顺序、分支判断和验收点。规则常驻系统提示词，流程文档按需检索。这与记忆篇的结论一致：写入比读取难。错误写入的代价高于遗漏写入，因此条目入库前需要人工审核，并先完成验证。
经验库还可作为新人了解业务的材料。流程文档同时可供机器和人阅读，内容来自事故和成功案例，与入职培训 PPT 相比更贴近实际业务流程。
通过离线任务整理记忆条目
记忆篇介绍了记忆的写入、检索和遗忘，但记忆条目还会逐渐失效：用户偏好会变化，同一事实可能被记录为多条，模型推断的条目可能带有不准确的置信度。运行半年后，这些低质量条目不断累积，检索质量随之下降。
我们通过定期运行的离线任务处理三类操作：合并语义重复的条目；将过期或被新事实覆盖的条目标记为失效；提升频繁命中且已验证有效条目的优先级。整理由 LLM 执行，所有落库改动均保留记录，可逐条审计和回滚。
离线整理的特点是批量执行，不占用在线任务的上下文和延迟预算。在线写入应保持简单和快速；清洗、合并等复杂操作放到离线执行，因为离线任务出错后可以重跑，在线写入出错会污染后续检索。
基于评估集自动优化提示词
教训、流程文档和记忆整理都在更新外部内容，提示词本身也可以优化。手写提示词通常依赖人工调整：改动一句话后，凭经验测试少量 case，再决定是否上线。我在评估篇中记录过这种方式的问题。
DSPy（2023 年起）将提示词中的指令和 few-shot 示例视为可优化参数，将评估集指标作为目标，并用优化器搜索更合适的组合。TextGrad 将 LLM 生成的自然语言反馈作为类似梯度的信号，沿计算图回传至提示词或其他文本参数，再据此改写。两者都依赖可信的目标函数。
我进行过一次小规模实验：在包含 200 条 case 的评估集上，优化器自动改写工单 Agent 的指令并重选 few-shot 示例，运行十几轮。改写后指令的评估分数比手调版本高几个点，也减少了反复调整提示词的时间。实验有两个限制。其一是过拟合：优化器可能得到只适合这批 case 的写法。因此我保留了一部分 case，不参与优化，仅用于最终验证；holdout 分数没有提升时，不采用该改动。其二是搜索成本：十几轮优化的 token 费用较高，只有评估集可自动判分、无需人工持续查看时，成本才合理。
提示词自动优化依赖评估集。缺少评估集时，优化过程没有可验证的目标，无法判断改写是否改善了任务结果。
自动生成的资产需要人工审核
教训、流程文档、记忆整理和提示词改写都可以自动执行，但自动生成的内容进入生产前需要人工审核。这里讨论的是应用层资产更新，并不涉及从头训练或完整后训练模型。应用层可以更新提示词、外部记忆和流程文档，模型权重保持不变。
反馈信号决定 Agent 的优化目标。如果目标定义存在偏差，优化过程会放大该偏差。我们曾遇到一次：评估判据要求“回答覆盖所有要点”，优化器据此将回答写得更长，并加入所有可能相关的信息。评估分数上升，但用户体验下降。与手动调整相比，自动优化会更快放大评估判据中的漏洞。
人工审核的成本相对可控。这些产物都是文本，可以以 diff 形式提交 review；审核一条教训或一段提示词改写所需时间通常少于代码审查。自动改写的提示词还需要经过灰度流程：先在小流量运行，评估集回归通过后再全量发布。自动化用于减少重复工作，人工仍需负责目标定义和上线判断。
评估、复盘和资产更新构成迭代流程
Agent 从经验中更新行为依赖一个闭环：没有评估就没有迭代用于识别失败；复盘将失败整理为教训，将成功整理为流程；这些资产进入经验库和提示词，随后通过评估验证更新是否改善结果。每轮迭代都会增加可复用的经验资产。
我的判断是，使用相同模型权重的应用会因经验资产的积累速度而表现出差异。系统若能在一次失败后记录并在相似任务中检索相应教训，可以避免反复出现同一类问题；未记录经验的系统则会重复处理这些问题。
这一流程依赖评估集和全链路 trace。没有它们，复盘缺少输入，资产更新缺少验证，优化缺少目标。尚未建立这两项基础设施时，应优先完善评估能力。
