Self-improving Agents

flowchart LR
  A["Self-improving Agents"]
  A --> B["分类：智能体 (Agents)"]
  A --> C["关键词：Agent"]
  A --> D["关键词：Self-improvement"]
  A --> E["关键词：Voyager"]
  A --> F["关键词：RLHF"]

前面几篇文章里，我们已经把 Agent 的几个核心部件讲得差不多了：会规划、会执行、会反思、会协作、会记忆。到了这里，一个很自然的问题就会出现：

如果 Agent 已经有了记忆和反思，它能不能真的“越用越好”？

这正是 Self-improving Agent 想解决的问题。它的核心吸引力在于：不通过重新训练底层模型，也不等待漫长的“收集数据—标注—重训—部署”周期，而是在运行过程中，逐步积累经验、优化策略、沉淀技能，让系统在同类任务上越来越稳、越来越快、越来越贴近用户需求。Voyager、Reflexion、OPRO 等工作，分别从技能库、经验反思、Prompt 优化等角度展示了这种可能性。(arXiv)

但这个方向也最容易被过度浪漫化。 “越用越好”听起来像理所当然，真正落到工程上，问题会立刻变得具体：

什么叫“变好”？
是回答更准，还是执行更稳？
是更符合用户偏好，还是更省成本？
哪些经验值得保留，哪些会污染系统？
自动更新策略时，如何避免越改越差？

所以，Self-improving Agent 更适合作为一种系统演进能力来理解，而不是一句口号。本文讨论的就是：这类 Agent 可以通过哪些路径变好，哪些路径在 2026 年已经有现实可行性，哪些仍然主要停留在研究或受限试点阶段。

愿景：让 Agent 在使用中持续改进，而不是每次都从零开始

先看定义：Self-improving Agent 的目标，不是让模型自己重训自己，而是让 Agent 在运行中逐步积累可复用经验，并把这些经验转化为更好的后续行为。

传统机器学习系统的改进路径通常是：

收集数据 -> 标注 / 反馈 -> 训练 / 微调 -> 部署新版本

这种路径并没有过时，今天依然重要；但它有两个现实限制：

周期长：不是每个小问题都值得走一轮模型更新。
颗粒度粗：很多问题并不是底层能力不足，而是任务策略、记忆组织、Prompt、工具使用方式不够好。

于是，Agent 层面的自我改进就变得有意义。它更关注这些事情：

把成功执行路径沉淀成可复用套路；
把失败模式记录成负经验，避免重复踩坑；
根据反馈调整 Prompt 或示例选择；
根据用户行为优化个性化策略；
在仿真或 sandbox 中练习并筛选更好的行为模式。

Anthropic 在 Agent 工程文章里一再强调，很多成功系统靠的不是复杂框架，而是简单、可组合的模式加上持续反馈与评估。OpenAI 的 Agent 指南也把 memory、evaluation、orchestration 放在核心位置，实际上已经隐含了一个判断：Agent 的进步，很大一部分发生在系统层，而不是只发生在模型层。(Anthropic)

Self-improvement 不等于“模型自己变强”，而是“系统更会用已有能力”

这是最需要先讲清楚的一点。

很多人一提到 self-improving，会下意识想到：

模型自己更新参数；
模型自己训练自己；
模型自动演化出更高智能。

现实里，更常见也更可落地的 self-improvement，其实是下面这些更“系统工程”的东西：

经验被记住并在相似任务中召回；
成功子流程被抽象成技能；
Prompt 根据反馈不断微调；
few-shot 示例池越来越高质量；
用户偏好被持续吸收；
反思结果被写回记忆，改变下一轮决策；
外部评估器或测试机制帮助系统筛选更稳的策略。

从工程上看，Self-improving Agent 现在最现实的理解，不是“会自我训练的模型”，而是会利用运行经验改进未来行为的 Agent 系统。

从经验中学习：最朴素、也最现实的改进路径

最直接的 self-improvement 来源，不是 fancy 的算法，而是执行经验本身。

一个 Agent 在运行中天然会不断产生这些信息：

做了什么任务；
用了什么路径；
哪些步骤成功；
哪些步骤失败；
用户采纳了哪些结果；
哪些输出被修改；
某个策略在什么场景下有效；
某个工具组合在什么情况下高风险。

如果这些经验只是执行完就消失，那系统每次都近似重新开始。如果这些经验能被结构化保留下来，并在后续相似任务里检索出来，它就开始具备“从用中学”的基础。

可以学什么

学习内容	典型来源	后续作用
成功路径	执行日志、通过案例	相似任务优先复用
失败模式	错误记录、用户纠正、测试失败	避免重复犯错
用户偏好	采纳行为、修改行为、显式反馈	个性化输出和策略选择
领域经验	长期任务过程中的稳定规律	改进规划、检索和表达方式
工具使用经验	哪些工具组合更有效、哪些常失败	优化执行策略

为什么这件事比“记住更多知识”更重要

因为很多 Agent 的低效，不是由于缺知识，而是由于缺经验：

明明这个用户一向讨厌太长解释，系统还不断写长文；
明明这类代码问题最先应该跑测试，系统却总先大改实现；
明明上次用某工具组合已经失败过，系统还在重复试同一条路；
明明某类问题的最佳结构已经很清楚，系统还是每次从头想一遍。

这些问题靠扩大知识库不一定能解决，但靠经验回放往往能明显改善。

一个更可用的经验日志思路

原文里给的 schema 方向是对的，但工程上更值得强调的是：经验日志最好不要只存“原始过程”，而应该同时存“可复用结论”。

例如：

{
  "task_type": "code_review",
  "user_profile_hint": "prefers_functional_feedback",
  "strategy_used": ["analyze_types", "run_linter", "check_edge_cases"],
  "outcome": "partial_success",
  "user_feedback": "accepted_functional_comments_rejected_naming_comments",
  "lesson": "for this user, prioritize correctness and edge cases over style suggestions"
}

这比把整个长对话扔进向量库更接近真正可用的自我改进。

技能库：让 Agent 从“每次从零开始”走向“先查有没有现成套路”

这是 Self-improving Agent 里最直观、也最容易和“程序记忆”对应起来的一条路线。

Voyager 是这个方向最典型的代表之一。它在 Minecraft 环境中让 Agent 持续探索、自动生成任务，并把成功完成的行为片段沉淀进一个不断增长的技能库；后续遇到相似任务时，Agent 可以优先检索并复用这些技能，而不是重新从零生成。论文摘要明确把 “an ever-growing skill library of executable code” 列为 Voyager 的三大核心组成之一。(arXiv)

技能库为什么重要

因为很多任务并不需要“重新发明方法”，而只需要：

判断当前是不是某类已知子任务；
如果是，优先复用现有套路；
如果不是，再从头探索。

这会带来两个明显收益：

效率提升：不必每次都完整规划和生成。
稳定性提升：复用已验证过的子流程，通常比每次重新想更稳。

技能库更像什么

它并不一定总是“代码函数库”。更广义地说，技能库可以是：

可复用的子流程；
模板化策略；
已验证的工具链调用顺序；
某类任务的最小 SOP；
带前置条件和适用边界的解决套路。

例如：

“遇到 API 文档比对任务，先统一字段，再逐项比差异”
“遇到代码修复任务，先跑测试，再看报错，再改最小变更”
“遇到竞品分析任务，先统一维度，再搜集证据，再出建议”

但技能库不是越大越好

这里也有明显 trade-off：

技能太粗：复用时不够精确；
技能太细：检索和匹配开销上升；
技能太多：容易匹配错或出现重叠；
技能跨域复用：很容易看起来相似，实际上不适用。

Voyager 在 Minecraft 这种封闭、规则相对稳定、动作反馈明确的环境中效果很好，但这并不自动意味着开放世界里的通用 Agent 也能无缝照搬。论文自己强调的是 open-ended embodied setting 下的 skill library 收益；这类结果更应理解为“证明方向可行”，而不是“开放域已经成熟”。(arXiv)

先看定义：技能库是程序记忆的工程化形式，但它最适合那些子任务结构相对稳定、可重复、可验证的场景。

Prompt 进化：不改模型，先改“怎么问”

如果说技能库更接近“做事套路”的沉淀，那么 Prompt 进化更接近“调教接口”的持续优化。

这条路线的吸引力很强，因为它成本低、改动快，而且不需要触碰底层模型参数。

Prompt 进化的核心思想

不是把 prompt 当成一次写好的文案，而是把它当成一个可迭代对象：

根据反馈调整表述；
根据任务表现做 A/B 测试；
根据用户或任务类型切换不同 prompt 变体；
用更高层的 meta-optimizer 帮助寻找更好的 prompt。

OPRO 就是这一方向的重要代表。其论文提出用 LLM 充当优化器，在 prompt 中带入已有候选解及其分数，再让模型生成新的候选，并迭代寻找更优指令；论文报告说，在若干任务上，优化后的 prompts 可以超过人工设计的 prompts。(arXiv)

为什么 Prompt 进化特别适合 Agent

因为 Agent 的很多问题，并不是“模型不会”，而是：

没有被清楚告知优先级；
没被明确要求检查某类边界条件；
对工具选择、输出格式、终止条件的约束不够明确；
没有结合用户偏好或任务历史做差异化引导。

这类问题常常可以通过 Prompt 迭代明显改善，而不需要模型更新。

Prompt 进化的现实边界

当然，它也有局限：

它更像“行为调优”，不是“能力跃迁”；
容易针对局部 benchmark 过拟合；
如果评估信号设计不好，容易把 prompt 优化到奇怪方向；
prompt 越多，配置管理越复杂。

所以更稳妥的思路通常不是“让系统自动无止境改 prompt”，而是：

明确任务评估标准；
维护若干版本；
用小规模实验验证收益；
对高风险场景保持人工审核。

先看定义：Prompt 进化是成本最低的 self-improvement 路线之一，但前提是你知道“什么叫更好”。

Few-shot 示例池：让示例也能“越用越准”

另一个非常实用、也很容易被忽略的自我改进方向，是 few-shot examples 的动态化。

很多 Agent 在 Prompt 中依赖示例来告诉模型：

这类任务应该怎么拆；
这类输出应该长什么样；
遇到什么情况该拒答；
某种工具调用应该如何组织。

但如果这些 examples 永远写死，它们迟早会暴露两个问题：

对不同任务和用户不够贴合；
没法吸收系统运行中产生的高质量案例。

更好的做法：把 few-shot 也做成可检索资源

一个更成熟的设计通常会维护一个 example pool，其中每个 example 带有：

task_type
输入特征
输出样式
质量评分
适用边界
来源（人工/自动沉淀）

当新任务到来时，系统不是把固定示例塞进去，而是：

按任务类型筛一轮；
再按相似度和质量排序；
动态选择最相关的 K 个示例注入上下文。

这和 RAG 有点像，但检索对象不是知识，而是行为样本。

这为什么有效

因为很多任务的表现，不只是取决于模型本身，还取决于“它看到过什么样的范例”。当 example pool 随使用不断增长、筛选不断变严，few-shot 本身就会成为一套不断改善的程序记忆。

人机反馈循环：最可靠的改进信号，往往来自“用户到底有没有接受结果”

任何 self-improvement 最终都离不开反馈。没有反馈，所谓“变好”就没有方向。

而在 Agent 场景里，反馈并不只来自显式打分。很多时候，更有价值的反而是行为信号。

三类常见反馈

反馈类型	典型来源	更适合用来改进什么
显式反馈	点赞 / 点踩、打星、通过 / 不通过	总体质量判断
隐式反馈	是否采纳、是否重写、是否中断、是否追加说明	用户偏好与实用性
纠正反馈	用户指出错误、给出正确做法	错误模式和改进方向

为什么隐式反馈尤其重要

因为用户不一定愿意每次都打分，但他们的行为已经在表达偏好：

直接复制输出，说明可用性高；
大幅改写后再使用，说明原输出偏了；
常常删掉某一类建议，说明这类建议价值低；
总是在某一步要求补充，说明系统那里长期不足。

这类信号虽然不如显式打分那样整洁，却往往更接近真实使用价值。

但别把所有反馈都直接自动写回策略

这是工程上必须克制的地方。

因为反馈可能是：

局部性的；
偶然性的；
用户特定的；
甚至是误导性的。

所以更合理的做法通常是：

先记录反馈；
聚合后看模式；
满足一定置信度再更新 example、prompt 或经验库；
对高影响更新保留人工审阅。

先看定义：人类反馈是自我改进最宝贵的信号，但它不该被天真地直接转成自动策略更新。

Reflection + Memory：很多“自我改进”其实是反思结果的长期化

上一篇讲 Reflection 时已经提到，反思不只是为了这一轮修正；它也可以沉淀为经验。这恰好就是 Self-improving Agent 最现实的一条路径。

从工程上看，很多今天真正落地的 self-improvement，并不是“系统自动发明新能力”，而是：

通过 Reflection 找到问题；
把这次问题和修正结论写入 Memory；
在相似任务里重新召回；
让下一轮表现变好。

这实际上把 Reflection、Memory 和自我改进连成了一个闭环：

执行 -> 评估 -> 反思 -> 写入经验 -> 下次检索复用

这种方式之所以现实，是因为它不要求底层模型变化，只要求：

经验能被抽取；
经验能被存好；
经验能在对的时候被召回。

Self-play 与仿真：在可控环境中“练出来”的能力

Self-improving Agent 最令人着迷的一条路线，是让系统在 sandbox 里反复练习，而不是只在真实用户请求里被动学习。

这和游戏 AI 里的 self-play 有明显相似性，但在 Agent 领域，形式更宽。

哪些场景更适合

代码 Agent：可以在隔离环境里写代码、跑测试、修复、再跑；
游戏 / 仿真 Agent：环境反馈清晰，reward 明确；
流程型 Agent：可以在模拟数据和虚拟任务上练标准流程；
客服 / 办公 Agent：可以与模拟用户交互，测试不同处理策略。

这条路为什么吸引人

因为它意味着 Agent 不必等真实用户“喂养”全部经验。它可以在受控环境里提前探索：

哪些策略更稳；
哪些工具组合更高效；
哪些 prompt 变体更好；
哪些失败模式可以提前发现。

但它为什么没有想象中那么容易落地

关键难点在于：

仿真环境与真实环境有 gap
reward 很难定义得足够好
容易过拟合到模拟任务
在开放世界任务里，自动评估质量很难

所以，Self-play 在代码、游戏等有明确反馈和验证器的领域比较有希望；一旦进入开放业务场景，它的收益会迅速受限。

当前最现实的 Self-improvement 形态，其实都比较“保守”

如果把今天能落地的 Self-improving Agent 机制按成熟度排序，大致更接近这样：

已经相对现实的

经验日志与相似案例检索
用户偏好记忆
Reflection 结果写回经验库
动态选择 few-shot examples
小范围 prompt A/B 与迭代
技能库在封闭或半封闭任务中的复用

已经能试，但需要很谨慎的

自动 prompt 优化进入线上
基于用户行为自动更新策略
自动选择和淘汰技能
半自动化反馈驱动的策略更新

仍然更偏研究或强约束试点的

大范围无人监管的全自动自我改进
自主生成并部署新执行策略
通用开放域下稳定的技能发现与迁移
面向生产关键任务的持续自我演化系统

Anthropic 的实践建议本质上也是类似立场：成功系统通常不是一开始就追求高度自动演化，而是优先选择简单、可组合、易验证的模式。(Anthropic)

当前局限：为什么“越用越好”在 2026 年还不是默认能力

这个愿景很强，但距离“默认标配”还有明显距离。主要限制至少包括下面几类。

1. 评估困难：你得先知道什么叫变好

这是所有 self-improvement 的前提。如果没有稳定评估信号，系统就很难知道：

某次变化是进步还是退步；
某种策略在哪些任务上有收益；
某次用户采纳是因为真的好，还是因为懒得改。

对代码这类强可验证任务，问题小很多；对开放式写作、分析、研究辅助，问题就复杂得多。

2. Reward hacking：系统可能学会“优化指标”，而不是真正优化任务

这在所有反馈驱动系统里都是老问题。如果你奖励的是：

更短响应；
更高通过率；
更少报错；
更高用户点击；

系统可能学到的是“讨好指标”的行为，而不是更好的任务完成方式。

例如：

为了少出错而过度拒答；
为了更高通过率而做更保守但价值更低的回答；
为了更高点击而牺牲严谨性。

3. 学新容易，稳住旧能力很难

原文里用了 catastrophic forgetting，这个方向在系统层也成立。即使不是模型参数遗忘，策略层面也可能出现：

新 prompt 提升了 A 类任务，却伤害了 B 类任务；
新技能在相似任务里有效，但在边界条件下更脆；
某个用户偏好被误泛化到其他用户。

所以，自我改进不能只看局部收益，还要看是否破坏原有稳定性。

4. 研究和生产之间有明显落差

Voyager、Reflexion、OPRO 这些工作都非常重要，但它们更多是在特定设置里证明“这条路线值得继续探索”。(arXiv)

到了生产里，你还要再面对：

稳定性要求；
安全和合规；
回滚机制；
审计需求；
可解释性；
成本约束；
用户信任。

这也是为什么很多团队虽然认同 self-improvement 的方向，但在真实系统里采用的往往是更保守的版本：记录经验、人工筛选、半自动更新，而不是让 Agent 直接自由演化。

一个更克制的判断：Self-improving Agent 现在最像“持续优化系统”，还不像“自主成长生命体”

这是本文最重要的结论。

当人们说“Self-improving Agent”时，很容易联想到一种很强的想象：系统会像人一样，自己总结、自己训练、自己进化、越来越厉害。

现实里，更可靠的表述其实是：

Self-improving Agent 是一种能利用运行经验持续优化自身行为的系统。

它的“自我改进”主要来自：

更好的记忆组织；
更好的经验检索；
更稳的技能复用；
更精细的 Prompt 和示例管理；
更真实的反馈吸收；
更清晰的评估闭环。

这意味着，它离“自发进化的智能体”还有距离，但离“可持续优化的 Agent 系统”已经不远。

实践建议：如果你真想做 Self-improvement，先从这几件事开始

1. 先把反馈闭环搭起来

没有反馈，就没有改进方向。先记录：

输出是否被采纳；
哪类错误最常见；
哪些任务最常失败；
用户在哪一步最常介入。

2. 先做经验检索，而不是自动策略更新

先证明经验真的能帮助未来任务，再决定要不要让系统自动改策略。这会更安全，也更容易验证收益。

3. 先沉淀技能或模板，再谈自动发现新技能

先看哪些成功子流程值得固定下来。别一上来就让系统自动“发明技能”，那通常过于乐观。

4. Prompt 优化先做人审或小流量试验

不要让 prompt 自动进化直接改动关键业务链路。先把它当实验对象，而不是默认生产策略。

5. 把“可回滚”当硬要求

任何自我改进机制，如果不能回滚，都不该轻易进入关键生产场景。

核心概念速查

概念	一句话
Self-improving Agent	能利用运行经验持续优化后续行为的 Agent 系统
技能库	把成功子任务抽象成可复用 skill，避免每次从零开始
Prompt 进化	不改模型，只通过 Prompt 迭代提升表现
动态 few-shot	从示例池中按任务检索最相关的高质量示例
反馈循环	用显式或隐式反馈判断什么策略更有效
Self-play	在仿真环境中反复练习并筛选更优行为
Reward hacking	系统优化了代理指标，却没有真正变得更好

小结

Self-improving Agent 的吸引力，在于它给了我们一个非常强的愿景：Agent 不是静态配置好的软件，而是一个能在使用中逐步变好的系统。它不一定要重训底层模型，也可以通过经验积累、技能沉淀、Prompt 演进、few-shot 检索、反馈吸收和仿真练习，慢慢把已有能力用得更好。

但 2026 年的现实也很清楚：这条路已经被证明有价值，却还远没有成熟到“默认上线就该自动开启”。Voyager 展示了技能库与持续探索的潜力，OPRO 说明了 Prompt 可以被系统化优化，而业界 Agent 实践又反复提醒我们，真正能落地的改进机制往往是简单、可验证、可回滚的。(arXiv)

所以，更稳妥的判断是： Self-improving Agent 不是今天生产系统的标准配置，但已经是设计 Agent 时不能忽视的演进方向。你不一定马上让 Agent 自动优化一切，但应该从现在开始，让系统具备积累经验、读取经验、利用经验的能力。因为一旦这条闭环跑通，Agent 才真正有机会从“会完成任务”走向“会在任务中持续成长”。