Agent 持续优化

Agent 上线后的持续优化问题通常不再是“能不能完成一次任务”，而是怎样让同类任务越做越好，并把人的纠正沉淀成系统能力。只靠人工不断修改 Prompt、补充 AGENTS.md 或在每次会话里重新提醒，能够解决局部问题，却很难形成复利：会话结束后，很多高质量反馈也随之消失。

更可持续的做法，是把 Agent 持续优化做成一个受控闭环：

Agent 执行
   |
   v
外部评测 + 人类反馈
   |
   v
失败聚类与原因分析
   |
   v
提出最小改进
   |
   v
Eval / 保留集验证
   |
   v
人工 Review
   |
   v
更新 Skill / Prompt / Harness / Tool
   |
   +------------------> 下一轮真实任务

优化对象不只是 Prompt。错误来自哪里，就应该修改哪里：知识缺失进入 Skill 或上下文；流程不稳定进入 Harness；工具能力不足修改 Tool；完成标准不清修改 Eval 和 Gate；只有真正属于模型行为表达的问题才优先修改 Prompt。

从一次纠错变成永久能力

Warp 在基于 Claude 构建自改进 Agent 时采用了一个值得复用的结构：业务 Agent 负责 Code Review、Issue Triage 等任务，独立的 Improver Agent 定期读取真实工作中的人类反馈，分析 Agent 做了什么、为什么被纠正，再提出对 Skill 的小幅修改。修改仍通过 PR、Review 和 Merge 进入生产，而不是让 Agent 无约束地改写自己。

这个设计的关键不是“自动改 Prompt”，而是三层分离：

• 执行层：完成真实任务并留下 Trace、结果和上下文。
• 学习层：从多次反馈中识别可泛化的问题，而不是为单个样本打补丁。
• 治理层：用 Eval、代码评审、版本控制和回滚决定改动能否进入生产。

因此，自改进不等于自修改。Agent 可以自动发现问题和提出改进，但稳定知识和生产行为仍需要可验证、可审计的发布流程。

参考：How Warp builds self-improving agents on Claude。

优先优化重复错误

一次失败可能只是偶发问题；同一种失败反复出现，才说明系统存在结构性缺口。

可以把反馈分成几类：

反馈类型	典型现象	优先沉淀位置
知识缺失	不知道组织术语、业务规则、历史决策	Context / Skill
流程缺失	漏步骤、顺序错误、没有验证	Skill / Harness
工具缺失	知道该做什么，但无法执行或读取结果	Tool / MCP
判断偏差	误报、漏报、优先级不合理	Prompt / Skill / Eval
边界问题	越权、修改范围过大、危险操作	Harness / Policy
完成误判	自称完成但测试或业务状态未通过	Eval / Gate / Loop

优化时应先聚合同类反馈，再寻找共同原因。对每个个案追加一条规则，最终会得到越来越长、相互冲突、难以评测的 Prompt。

一个有用的核心指标是 重复纠错率（Repeated Correction Rate）：

已被人类纠正过的问题类型，在后续同类任务中再次需要相同纠正的比例。

调用量衡量使用规模，成功率衡量当前能力，重复纠错率则衡量系统有没有学习。

高质量反馈比大量反馈更重要

简单的 👍 / 👎 可以提供偏好信号，但很难直接指导工程改进。最有价值的反馈通常同时说明：

• 哪个结果不对。
• 为什么不对。
• 正确判断依赖什么证据或原则。
• 这是一次例外，还是以后都应遵循的规律。

反馈入口应尽量嵌入现有工作流。PR Review、Issue 评论、人工接管原因、Eval 失败和用户对产物的直接修改，都比额外要求员工填写一套“AI 反馈表”更容易持续。

反馈也需要去噪。单个用户偏好、一次偶发失败和互相冲突的意见，不应自动升级为全局规则。进入稳定 Skill 前，应至少确认适用范围，并尽可能通过多个样本或专家判断验证。

写原则，而不是堆规则

可泛化的优化应尽量解释“为什么”，而不是不断增加特例。

例如 Code Review Agent 误报某类问题时，与其追加“遇到 A 不要报、遇到 B 不要报、遇到 C 不要报”，更好的改法可能是明确：

只有当问题能够在当前变更引入的可达执行路径上发生，并且存在可说明的实际影响时，才报告为缺陷。

原则给模型留下推理空间，也更容易跨任务迁移。具体案例可以放进参考资料或 Eval 集，而不是全部塞进主指令。

这也是 Progressive Disclosure 的价值：主 Skill 保持短而稳定，细节、示例、脚本和领域资料按需加载。

Skill 与 Memory 不承担同一种职责

持续优化很容易把所有历史信息都塞进 Memory，但稳定能力与运行时记忆应分开：

• Skill 保存经过验证、可复用、需要版本管理的程序性知识。
• Memory / Context 保存用户、任务、项目和当前环境中会变化的信息。
• Trace 保存一次执行实际发生过什么，用于诊断和学习。

“这个仓库提交前必须运行哪些检查”适合 Skill；“用户这次要求只修改文档”属于当前 Context；“Agent 第三步为什么失败”属于 Trace。

稳定规则从反馈进入 Skill 前需要提炼和审核，不能把原始历史直接当成长期能力。

能评测的任务先建立 Eval

没有 Eval 的优化很容易变成“改完感觉更好”。对于存在明确正确答案或可验证结果的任务，应先建立评测集，再优化 Agent。

评测至少分三层：

• 任务结果：最终答案、代码、分类或业务状态是否正确。
• 过程约束：是否越权、是否调用不允许的工具、是否产生不必要副作用。
• 成本效率：Token、耗时、工具调用、人工介入是否合理。

每次优化都应同时跑目标样本和保留集。只验证刚刚失败的案例，很容易过拟合；只看平均分，又可能掩盖关键场景退化。

对于没有标准答案的判断型任务，可以使用专家 Review、成对比较和明确 Rubric，但仍要保存历史基线，避免标准随着 Agent 一起漂移。

Improver 本身可以平台化

不同 Agent 的业务 Skill 差异很大，但优化流程高度相似：

1. 收集一段时间内的执行 Trace、Eval 和人工反馈。
2. 聚合同类失败，区分偶发问题和重复问题。
3. 找到最可能的系统层原因。
4. 每次只提出少量、可解释的修改。
5. 在目标样本和保留集上验证。
6. 生成 PR 或变更提案。
7. 人工 Review 后发布，并继续观察真实效果。

因此可以把 Improver 做成组织级基础设施，而不是每个 Agent 单独开发一套“学习系统”。业务团队主要维护自己的 Skill、Eval 和领域反馈，平台负责采集、聚类、实验、版本和回滚。

与 Agent 执行循环的关系

Agent 执行循环解决的是一次任务怎样根据反馈继续执行直到收敛；Agent 持续优化解决的是多次任务之间怎样根据历史反馈改进系统本身。

可以把两者理解为两个时间尺度：

• Task Loop：分钟到小时，优化当前任务产物。
• Improvement Loop：天到周，优化 Agent 的 Prompt、Skill、Harness、Tool 和 Eval。

前者没有可靠停止条件会无限消耗；后者没有独立评测和治理，会把偶发反馈写成永久规则，甚至为了提高分数降低标准。

成熟的 Agent 系统需要两者同时存在：当前任务能够闭环，历史反馈也能沉淀为下一次更好的起点。

优化是否真正有效

不要只看 Agent 调用量或修改次数。更值得持续观察：

• 任务成功率：真正达到完成标准的比例。
• 重复纠错率：相同问题被再次人工纠正的比例。
• 人工接管率：需要人完成或纠偏的任务比例。
• 一次通过率：无需额外人工修改即可验收的比例。
• 回归率：一次优化导致既有能力退化的比例。
• 单位成功成本：成功任务对应的模型、工具、基础设施和人工成本。

最终目标不是让 Agent “自己改自己”，而是让组织形成一条稳定的数据飞轮：

真实使用产生反馈，反馈沉淀为能力，能力提升带来更多可托管任务，新的真实任务再产生更高质量反馈。

当同一种人工纠正越来越少，人主要处理新的目标、例外和标准变化时，Agent 持续优化才真正产生复利。