这篇文章只讲一件事：怎么真的把 Agent 自改进搭出来。

不是论文综述，而是一条从采集、反思、归纳、激活到注入的完整工程路径，附带八条不可破坏的红线、一个真实的静默故障，以及从零复现的最小清单。

内容融合了公开研究范式与某企业级实现的真实工程经验（已做匿名化与通用化处理，不指向任何具体系统）。文末附参考资料与事实核查说明。

一、先说清楚：什么才叫「自改进」

我们对工具有一个朴素期待：越用越好用。

但今天绝大多数 Agent 不是这样。你用了三个月的 Agent，和第一天用它，感觉差不多。它不记得上周你纠正过它三次的同一个错误，不记得哪条路走过是死胡同。每次对话都像重新认识。

自改进要解决的就是这件事，一句话概括：

让 Agent 把「这次是怎么做成 / 做砸的」变成下次的先验。

Warp 团队把这个问题的根因说得更精准——反馈是无状态的（stateless）：会话结束后，人给 Agent 的反馈就消失了，那些最关键的上下文被直接踢出了 agentic loop。

他们还给出了一个很传神的症状描述：「80% 正确」陷阱。一次性写好的 prompt 能把任务做对约 80%，但剩下的 20% 会产生大量噪音，体验反而很差。而靠人工不断重写 prompt 来补那 20%，根本无法规模化。

它是一个闭环，六步：

图 1：六步闭环。注意三种颜色的分工——运行/留痕/注入在在线路径，反思/归纳在离线路径，而激活是人在环的显式决策。这个分工是整套架构最重要的决定。

学术上这个闭环被抽象为四个要素：System Inputs / Agent System / Environment / Optimiser（综述 arXiv:2508.07407）。你要优化的是前两者，信号来自环境，而"反思器"就是那个 Optimiser。

先划清一条边界，避免一开始就跑偏：

经验归 Agent，不归用户——这是最容易做错也最关键的一条立场，第四节第 1 步会详细展开为什么。

二、第一性问题：改什么？

自改进不是一个动作，而是四个不同层级的动作。选错层级，项目基本就废了。

图 2：四层选型。越往上能力上限越高，但风险、成本和不可逆性也越高。

结论很明确：绝大多数团队应该只做 L1，而且应该先只做 L1。

这不是保守。有一个很强的实证支撑：GEPA（arXiv:2507.19457，ICLR 2026 Oral）用纯 L1 的反思式提示词进化，平均比 GRPO 这类 L4 强化学习方法高约 10%（最高 20%），而 rollout 少到 1/35。

L1 的另一个隐性优势是可解释。规则是人类可读的自然语言，出问题时你能直接看到"它学到了什么错东西"，然后删掉。L4 权重更新出了问题，你只能重训。

关于 L3 的一句提醒：Darwin Gödel Machine（arXiv:2505.22954）让 Agent 改写自己的代码库，学术上极其漂亮，把 Schmidhuber 2003 年的思想实验落成了工程。但自动改代码不该出现在你的第一版生产系统里。前述那套企业级实现在"非目标"里明确写了：不自动改写子 Agent 描述、不自动改代码。

三、第二性问题：什么时候改？

生产系统几乎都选第二种。学界称之为 sleep-time compute（arXiv:2504.13171）——让模型在"睡觉"时预先思考。这个隐喻和人类睡眠巩固记忆是一致的：白天经历，夜里整理。

这条切分落到架构上，就是整套系统最重要的一条纪律：

图 3：在线只做三件轻活（读经验、运行、写证据并入队），重加工全部离线。两侧只通过数据库解耦。

在线路径只做三件轻活：读已激活经验 + 写证据 + 入队。

由此得到两条必须写进设计文档的降级语义：

1. 没有已激活经验时，prompt 里的经验块为空——这是预期降级，不是采集失败。
2. 存储层故障时，整条自改进链路降级，主对话照常可用。

四、落地蓝图：七步

第 1 步：定义经验的载体与归属

先定数据分层。只需两段，别搞三层四层：

作用域只需两个值，不要更多：

• agent：只约束某一个目标 Agent
• global：隔离域内全局生效

注意这里没有任何以用户为维度的作用域。 想跨用户共享，只能通过 global 或 Agent 级规则实现——绝不能把 user_id 写进经验层，再靠放宽查询条件来实现共享。这条一旦破防，隐私和复用都会一起崩。

第 2 步：采集要克制

新手最容易犯的错：把所有事件都写库。流式输出一个 token 一条 INSERT，数据库直接被打爆。

正确做法是白名单，只持久化重建轨迹必需的那几类事件：

匿名案例里的实测数据很有说服力：相比"每条事件都 INSERT"的旧行为，典型长请求的写入量只剩原来的 0.5%–2%。

而且过滤要放在两处：写库函数入口直接返回，以及异步派发前就跳过（避免白建一堆任务对象）。

可观测性靠文件日志，不靠数据库。 这条想清楚了，采集就能放心地克制。

第 3 步：门控——先问"值不值得反思"

不是每条轨迹都有信息量。反思一条"你好 / 你好，有什么可以帮您"的对话，纯属浪费 token 并污染经验库。

跳过条件：

反过来说，有反馈、有重试、有错误、有子 Agent 链路的轨迹才值得反思——因为那里才有"哪里做对了、哪里踩坑了"的信号。

这一步直接决定整个经验库的信噪比，别省。

第 4 步：轻反思——单轨迹原子提取

图 4：轻反思对每条轨迹 1:1 提取候选；深反思跨轨迹 N:1 归纳成规则。两者的信息密度完全不同，必须分开。

轻反思的处理单元是一次完整运行（用 会话ID + 运行ID 定位），做三件事：

1. 按标识重建轨迹（如有子 Agent，补全子轨迹，首次结果落快照、重放复用，别反复回源）
2. 通读全文，提炼 3–5 条关键要点，不臆造——原文没有的不写
3. 幂等写入候选表

幂等键必须足够完整，建议包含：隔离域 + 来源运行ID + 目标Agent + 内容指纹 + 反思器版本。加上反思器版本，是为了让你升级 prompt 后能重新反思同一批轨迹而不冲突。

置信度分流：低于阈值（如 0.6）的候选进 review 而不是直接可用。

经验分类建议固定枚举，别让模型自由发挥（否则标签会漂移到无法分组）。可参考这九类：路由、规划、工具选择、知识使用、查询生成、答案质量、校验、重试与兜底、效率。未知标签一律归一为空串，避免污染后续分组。

信号只需三值：helpful / harmful / neutral。

第 5 步：深反思——跨轨迹归纳

图 5：领取候选 → 分组 → 聚类 → 归纳 → 写规则 → 写证据边 → 留痕，整个处理块加锁串行。

深反思消费的是轻反思积累的 pending 候选，流水线七步：

1. 领取：status=pending，用跳过已锁行的方式并发安全地取
2. 分组：按 作用域 + 目标Agent + 经验类型
3. 聚类：文本相似度，如 bigram Jaccard ≥ 0.4
4. 归纳：簇大小 ≥ 2 才归纳——孤例不成规则
5. 写规则：状态固定为 candidate
6. 写证据边：规则 ↔ 来源候选，保证可回溯
7. 留痕：记录本次运行的状态与摘要

产出的规则应该带适用条件和例外，而不只是一句干瘪的结论：

- {规则标题}: {规范化表述}
  - applicability: 什么场景下适用
  - exceptions: 什么情况下不适用

深反思应该默认关闭。 理由非常实际：没有轻反思的稳定产出，开深反思几乎无产出。 先让浅层跑稳、有量，再开归纳。这个顺序反了会浪费大量调试时间。

第 6 步：激活——整套系统的安全阀

图 6：状态机。只有 active 参与注入，激活与下线都是显式动作。

这是我认为最重要的一条设计：

机器唯一能自动写入的终态是 candidate。从 candidate 到 active 必须经过一次显式决策。

没有自动晋升。 为什么值得如此保守？

• 反思是 LLM 生成的，会有幻觉。一条错误规则被自动激活，会污染此后所有请求，而且很难归因。
• 经验注入是全局影响，不像单次回答错了那么容易发现。
• 激活前需要人确认一件事：规则里不含用户事实或可识别个人信息。

那套企业级实现甚至主动放弃了早期版本设计的自动质量门禁和灰度晋升链，改回人工激活。在没有可靠自动评估之前，这是更诚实的选择。

conflicted 是个有用的中间态：与已有规则矛盾的规则，既不注入也不归档，挂起等人裁决。不要让机器自己选边。

第 7 步：注入——让经验真正生效

• 加载：按隔离域取 status=active，且作用域为 global 或匹配当前 Agent
• 限量：如最多 50 条，按 置信度 → 证据数 → 更新时间 排序
• 渲染：拼成 Markdown 块，进 system prompt，按文本预算截断（如 2000）
• 稳定性：⭐ 单次运行内这份上下文必须不变，新激活的规则从下一次运行才可见

最后一条容易被忽略但很重要：如果同一次运行的不同节点（比如分类、规划、反思三个节点）加载到了不同版本的经验，行为会漂移，问题也将无法复现。

五、另一条路线：把经验写进文件，用 PR 审核

上面七步是「经验存数据库」的路线：候选表、规则表、改状态激活。但还有一条同样成立、而且更轻的路线——把经验写成文件，让改进走标准代码评审流程。

Warp（AI 终端 / agentic 开发环境）的公开实践是这条路线的一个很好的样本。规模上有参考价值：80 万月活开发者、财富 500 强中 56% 在用、每周 40 万+ Claude Code 会话在其中运行。他们最初的痛点也很具体——内部的代码评审 Agent 被工程师抱怨"评论无用"。

双层 Skill 循环

图 7：内层 Skill 按任务干活，人在原有工作流里给反馈，外层 Improver Skill 定时把反馈转化成对内层的最小修改，走 PR 审核后合并。

对照我们前面的结构，映射关系相当清晰：

Zach Lloyd（Warp CEO）的原话很值得记：“框架其实非常简单：一个领域特定的 base skill，加一个用来打磨它的 improver skill。这种简单性就是这个方案的美感所在。”

最值得注意的一点：机器在这里只提建议（开 PR），从不直接改生效内容。这和第六节的不变量 I-4「未激活不注入」是完全同构的设计——只是把"改数据库状态"换成了"合并 PR"。两条路线在这条红线上不约而同。

Skills 与 Memory 不是一回事

这个区分很锋利，也是很多人混淆的地方：

本文第四节讲的那套（候选 → 规则 → 激活）本质上是在构建 Skills，而不是 Memory。这也解释了为什么"未激活不注入"如此重要：程序性知识一旦出错，影响是全局且持续的。

编写自改进 Skill 的 6 条准则

第 3 条是本文前面缺的一环。 我们讲了"有反馈的轨迹才值得反思"，但没讲反馈从哪来。答案是：不要新建一个反馈系统，而是去人已经在做事的地方（PR 评论、Issue 回复）把信号捡起来。让人为了喂 Agent 而多做一步操作，信号就会枯竭。

落地案例：Issue Triage Agent

Warp 开源了一个完整示例（warpdotdev/warp-agents-demo-github-issue-triage），链路值得抄：

1. 触发：有人提新 Issue → CI 启动 Agent → 分析复杂度与可行性 → 打标签、建议修复方向
2. 发现缺口：首轮表现不错，但漏掉了 ready to spec 标签
3. 就地反馈：维护者直接在该 Issue 下留言，同时说明"期望什么 + 为什么"
4. 外层运行：定时 Agent 认证 → 跑 Skill 内捆绑的脚本拉取近期带反馈的 Issue → 汇总为结构化文件 → 读回上下文
5. 最小修改：开 PR 修改内层 Skill——当 Issue 描述了真实问题时即应用该标签，即使 UI 形态尚未确定；PR 描述里写明哪些信号触发了改动
6. 闭环：人 review → merge → 下次运行继承

注意第 4 步的"捆绑脚本"——这正是准则 4 的体现：Skill 引用脚本，避免每次运行都让模型重新写一遍取数代码。

Warp 现在把这套模式跑在整个开源仓库上，有独立的 spec 撰写 Agent、评审 Agent、triage Agent，每个都带自己的自改进循环。

两条路线怎么选

如果你的 Agent 本来就工作在代码仓库里，优先选文件路线——你能白捡 diff、review、回滚、历史四件套。如果是面向用户的在线对话 Agent（轨迹在数据库里、没有天然的 PR 载体），那就是第四节那套。

六、八条不变量（破坏即事故）

这是评审任何改动的第一标尺。我把匿名案例的八条红线抽象成了通用形式：

如果只能记两条，记 I-6（自改进永远不能拖垮主业务）和 I-4（未验证的东西永远不上线）。

七、一个真实的静默故障

这是匿名案例里最有价值的一段记录，建议原样贴到你团队的复盘文档里。

现象：测试环境轻反思全部失败，任务队列进 failed，候选表始终为空。

根因：序列化轨迹时没处理数据库游标读出的时间类型：

Object of type datetime is not JSON serializable

为什么没被测出来：本地单测用 None 和 ISO 字符串手搓轨迹对象，从没覆盖真实游标读出的数据形状。

修复很简单——序列化时统一把时间类型转 ISO 字符串。但教训有三条，价值远超这个 bug 本身：

① 任务 completed ≠ 写出了经验

跳过反思时任务照样标记 completed。所以监控必须同时看产物表，不能只看任务表：

SELECT status, count(*) FROM 任务队列   GROUP BY 1;
SELECT status, count(*) FROM 候选经验表 GROUP BY 1;
SELECT status, count(*) FROM 规则表     GROUP BY 1;

队列全绿而候选表为空，就是这个故障的特征信号。

② 测试要用真实数据形状

用真库 + 真实游标读出的行跑端到端，而不是手搓理想对象。整条链路里最容易碎的地方，恰恰是跨系统边界的数据形状转换。

③ 测行为，不测实现

断言"未激活不注入"“跨域读不到"“白名单外不落库"这些意图，而不是断言 SQL 文本。否则测试会固化实现，反过来阻碍演进。

另外：历史 failed 任务通常不会自动重跑。部署修复后要手动把它们打回 queued，再观察候选表是否开始增长。

八、还有一条战略级教训

那套企业级实现的 1.0 版本，设计了一份相当宏大的蓝图：用户画像、策略手册 + 版本化发布链、灰度分桶、自动晋升与回滚、软遗忘、向量检索……

结果几乎全部未落地。 2.0 果断砍掉，收敛为单一产品线：只做 Agent 经验。

自改进系统最常见的死法，是一次性设计太多层。

先把"一条轨迹 → 一条经验 → 注入生效"这条最小闭环打通并跑稳，再考虑加东西。

九、从零复现的最小清单

不需要向量库，不需要多组件存储。一个关系库 + 两个 worker 就能起步。

数据骨架

证据段
├── messages          # 用户输入与最终回答
└── events            # 白名单生命周期事件（含子轨迹快照）

任务段
└── offline_queue     # 反思任务：入队/领取/回收/完成/失败

经验段
├── candidates        # 浅层：单轨迹原子经验（分类/信号/置信度）
├── patterns          # 深层：规范规则（适用条件/例外）
├── pattern_evidence  # 证据边：规则 ↔ 来源候选
└── reflect_runs      # 留痕：每次归纳运行的状态与摘要

实施顺序

1. 建证据段 + 采集：白名单过滤，终态事件先于入队落库
2. 建队列 + 轻反思 worker：门控 → 重建 → 提炼 → 幂等写候选
3. 建注入：加载 active（一开始手工插一条测试规则验证链路）
4. 验证最小闭环：手工规则能进 prompt，且断开存储时主对话仍可用
5. 跑量：让轻反思稳定产出一段时间，观察候选表增长与质量
6. 再开深反思：分组 → 聚类 → 归纳 → 写 candidate
7. 建激活流程：人工审核台（哪怕先是一条 SQL + 一个 checklist）

注意第 3、4 步的顺序：先打通注入链路再做深反思。这样你能尽早验证"经验真的能影响行为"这件最核心的事。

避坑对照表

十、怎么知道它真的有效

这是最容易被忽略的一环。两条腿都要有：

学术侧：固定 benchmark 上的通过率/准确率对比。GEPA、ACE 这些工作都是这么验证的。

生产侧：

• 三张表状态分布的日常巡检（上面那三条 SQL）
• 有/无经验注入的 A/B——这是唯一能真正回答"值不值得"的手段
• 失败原因的可查性：失败任务要把错误写进 payload，方便 grep

值得强调的是：在你有可靠自动评估之前，别开自动激活。人工审核慢，但错误规则污染全局的代价更高。

五个治理问题（来自 Warp 的实践问答）

这几条把"怎么评估"从原则推进到了可操作层面：

最后一条尤其值得抄：把业务指标回灌给改进器，让它知道自己的修改到底有没有让整体变好，而不是只盯着单条反馈。

部署节奏上，推荐 crawl-walk-run（爬 → 走 → 跑）：先小范围只读观察，再半自动，最后才扩大自动化范围。

十一、一句话总结

自改进的门槛并不在算法，而在纪律：

• 在线只做轻活，重加工离线 → 主链路永不被拖慢
• 采集克制 → 系统扛得住
• 浅层与深层分离 → 信噪比可控
• 机器只提建议，人做最终决定 → 错误不会全局扩散
• 证据可回溯、操作幂等 → 出问题能查、能重放
• 反馈就地采集、零额外摩擦 → 信号不会枯竭

把这几条守住，剩下的就是让时间和使用量替你积累复利。Agent 会不会越用越会做事，取决于你有没有把"这次的经验"稳稳地存下来、审好、再喂回去。

而且如 Warp 的结论所说：任何 Agent，只要从一开始就内建"捕获反馈 → 转化为知识更新 → 沉淀复用"这个循环，就能从一次性的小助手，长成在组织内复利增长的能力系统。

参考资料与事实核查说明

综述与课程

1. A Comprehensive Survey of Self-Evolving AI Agents：https://arxiv.org/abs/2508.07407（提出 System Inputs / Agent System / Environment / Optimiser 统一反馈环框架）
2. A Survey of Self-Evolving Agents: On the Path to Artificial Super Intelligence：https://arxiv.org/abs/2507.21046
3. Stanford CS329A《Self-Improving AI Agents》（2025 秋季研究生研讨课）：https://cs329a.stanford.edu/

L1 上下文/经验层

4. Reflexion: Language Agents with Verbal Reinforcement Learning（NeurIPS 2023）：https://arxiv.org/abs/2303.11366
5. ExpeL: LLM Agents Are Experiential Learners（AAAI 2024）：https://arxiv.org/abs/2308.10144
6. Agentic Context Engineering (ACE): Evolving Contexts for Self-Improving Language Models：https://arxiv.org/abs/2510.04618（Generator–Reflector–Curator 三角色，把上下文当作不断演化的 playbook）
7. GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning（ICLR 2026 Oral）：https://arxiv.org/abs/2507.19457

L3 架构层 / L4 权重层

8. Automated Design of Agentic Systems (ADAS)（ICLR 2025，Meta Agent Search）：https://arxiv.org/abs/2408.08435
9. Darwin Gödel Machine: Open-Ended Evolution of Self-Improving Agents：https://arxiv.org/abs/2505.22954
10. SEAL: Self-Adapting Language Models：https://arxiv.org/abs/2506.10943

离线计算范式

11. Sleep-time Compute: Beyond Inference Scaling at Test-time：https://arxiv.org/abs/2504.13171

工业界实践

12. How Warp builds self-improving agents on Claude（Anthropic 官方博客，Michael Segner，2026-08-26）：https://claude.com/blog/how-warp-builds-self-improving-agents-on-claude（双层 Skill 循环、6 条 Skill 编写准则、治理问答）
13. Warp 开源示例：GitHub Issue Triage Agent — github.com/warpdotdev/warp-agents-demo-github-issue-triage

事实核查说明

• 上述 arXiv 编号、会议归属（Reflexion NeurIPS 2023、ExpeL AAAI 2024、ADAS ICLR 2025、GEPA ICLR 2026 Oral）与 Stanford CS329A 课程信息均经公开来源检索核对。
• GEPA 的"平均超出 GRPO 约 10%、最高 20%、rollout 少至 1/35"来自其论文摘要的自述结果，适用于其评测设置，不应外推为普适结论。
• 第五节的 Warp 案例（双层 Skill 架构、6 条准则、Issue Triage 链路、治理问答、80 万月活 / 财富 500 强 56% / 每周 40 万+ 会话等规模数据、Zach Lloyd 引语）均来自上述 Anthropic 官方博客一文，属公开可引用信息。其中规模数据为该文发布时（2026-08）的口径。
• 第四、七、八节的工程细节（白名单五类事件、写入量降至 0.5%–2%、置信度阈值 0.6、聚类 Jaccard 0.4、成簇 ≥ 2、最多 50 条 active、渲染预算 2000、时间类型序列化故障等）来自某企业级实现的内部架构文档，已做匿名化与通用化处理，去除了全部内部平台名、仓库标识、环境变量名与表名，不指向任何具体系统。这些数值是该系统的经验取值，不是通用最优值，请结合自身场景调参。
• “轻反思 / 深反思"是对该实现分层设计的通用化描述；睡眠巩固记忆的隐喻属于业界通用类比，另可参见 sleep-time compute 一文。
• 第五节末尾"两条路线怎么选"的对比表是本文作者的归纳，用于串联两个来源不同的案例，不出自任何单一原始资料。