导读让 Agent 多想一遍、自己改一版答案，常常能改善当前任务，但不代表它下次会做得更好。真正的自我进化，必须把执行经验变成持久的系统更新，并由独立评测和回滚机制约束。对多数工程团队而言，先搭好“信号—沉淀—更新—验证”闭环，比急着训练模型更实际。
先把一句话说清：改对一次，不等于学会一次
一个 Agent 在任务里发现工具调用错了，重新规划后把结果做对；下一次遇到相似任务，它又从同一个坑里跌进去。这样的系统并不少见。
问题不一定是模型不够聪明。更常见的情况是：这次纠错只停留在上下文里。任务结束，计划、批评和临时规则一起消失；系统的 Prompt、Skill、记忆、工具接口和控制逻辑都没有发生可靠改变。
所以，反思是当前任务内的重试动作；进化则是把任务产生的信号，提交为下一次任务仍会生效的更新。两者可以相连，但不能混用。
2026 年的一篇综述把现代 Agent 写成“基础模型 + Harness”（论文中称为 Scaffolding）。Harness（运行系统）就是包在 LLM 外面、让它能稳定做事的运行系统：它组织 Prompt、记忆、工具、Skill、路由、调度与安全约束。LLM 负责生成和推理，Harness 决定它接到什么上下文、怎样调用工具、保留哪些经验，以及如何被限制和验收；Skill 只是 Harness 中一种可执行的规则或流程。
这套划分也对应两条更新路径：改模型参数，或改 Harness。它很实用，因为 Agent 的行为从来不只由模型权重决定。
图片说明：图中左侧是模型参数更新，右侧是 Prompt、工具、记忆与完整 Harness 的更新。图片来源：Self-Improvements in Modern Agentic Systems: A Survey，Figure 1
如果一次“自我修正”没有留下可追溯、可复用的改变，它更像一次完成得不错的草稿，不是能力积累。
自进化也不等于全自动。它强调的是经验能否经过评测、沉淀和验证，变成后续任务仍会生效的能力；这条链路可以由工程师主导，也可以由 Agent 半自动执行。自动化程度决定谁来完成更新，不决定系统是否真的在积累能力。
真正能转起来的，不是“记忆功能”，而是四环闭环
很多团队会先加一个向量库，或者让模型自动写 Skill。它们都可能有用，但单独存在很容易失效：存进去的经验未必可信，生成出来的改动也未必真的更好。
我更愿意把自进化拆成四个连续环节。
1. 先有可信信号：系统到底哪里做错了
评测不是上线前跑一个总分那么简单。对自进化系统来说，它至少要回答三件事：哪类任务失败了、失败发生在哪一步、这条经验值不值得被保留。
最适合先做闭环的，是结果能被外部规则检查的任务：代码能否通过测试、数据处理是否满足约束、工具调用是否符合接口、表单是否按字段完成。开放式问答也能评测，但评审标准、样本集和人工抽查必须更谨慎。
原因很朴素：错误的信号会被系统当作“经验”沉淀下来。一次误判只是一次失分；错误地把它写入长期规则，才会让同一种错误被放大。
2. 再做经验沉淀：不是把所有轨迹都塞进记忆
原始轨迹有价值，但不等于应该直接进入长期记忆。一次失败可能来自网络波动、外部页面变化、用户输入不完整，或者评测本身的误判。把它们一股脑召回，只会让 Agent 的上下文越来越嘈杂。
更合适的中间层，是把反复出现、能说明原因、并且带有适用条件的经验整理成小而明确的规则。例如，不是保存“上次日期转换失败了”，而是保存“遇到不明确的日期格式时，先识别源格式；无法确认时请求补充，不要默认按本地时区转换”。
这一步要保留来源、适用范围和版本。否则几周后面对一条旧规则，团队无法回答：它解决过什么问题、为什么还存在、是否已经被新流程替代。
3. 然后更新系统：先动可控的地方
经验可以落到不同位置：补充一条 Skill、修正工具调用约定、调整检索策略、更新工作流，或改变一段 Prompt。它们都属于 Harness 更新。
这也是多数团队值得先做的层。它不需要立刻重训模型，改动边界相对清楚，可以版本化，也能针对一个任务域逐步试验。斯坦福 CS329A 的课程范围同样把验证、工具、代码、记忆、多步规划和评估放在一起讨论——自改进从来不是“让模型再想想”这么单一的动作。
模型参数更新当然也重要。把反复验证有效的经验蒸馏成训练数据，再经过微调或强化学习，能让能力更稳定地迁移到更广的任务。但这是更慢、更贵、也更难回滚的一层；它不应替代前面的工程闭环。
4. 最后独立验证：新版本必须允许输
一条新规则看上去很合理，不代表它真的改善了系统。它可能让一类任务更好，却损害另一类任务；也可能只是记住了用来发现问题的那批样本。
因此，更新后至少要用没有参与归因和规则生成的保留样本再评一次。候选版本达不到预设门槛，就拒绝发布或回滚。保留“为什么被拒绝”的记录也很重要：下次系统或工程师不必再用同一种补丁碰同一堵墙。
更隐蔽的风险，是把偶然涨分当成真实进步。一个 Agent 若反复用同一小批验证样本试改动，并遵循“分数涨了就提交”，最终总会挑中一些碰巧高分的规则；错误一旦进入长期流程，就会在后续任务里稳定复现。2026 年的 PACE 预印本在一个提示词层自进化的受控测试中观察到，简单的贪心接受会提交错误甚至有害的修改；这不是生产系统的普遍比例，却足以说明：提出改动的能力之外，决定是否提交的门控规则同样是闭环的薄弱点。
实操上，至少要给这个门控加四道防线：冻结一组不参与规则生成的保留样本；设定提交阈值，不因一次小幅涨分就接受；让新版本先在有限任务上灰度运行并保留回滚点；涉及权限、生产数据或安全约束的更新，保留人工审批。目标不是让系统永远不改，而是让它在证据不足时敢于不改。
这也是人不该从闭环中消失的原因。人不必手工修每一个错误，但应定义不可触碰的边界、审查高风险更新，并负责处理评测难以覆盖的目标偏移。
Agent 进化快，LLM 进化慢：它们应该配合，而不是互相替代
这四环主要服务于 Agent 的快循环。一次任务完成后，团队可以在小时、天或周的节奏里，审核并更新 Skill、记忆、工具策略或工作流；发现退化也能撤回版本。
LLM 的进化则通常是慢循环。只有那些反复出现、经过验证、允许使用且完成脱敏和筛选的经验，才可能进入训练数据，再经历训练、离线评测、安全检查和灰度发布。它解决的是更长期的能力固化，而不是当天修好一条流程。
这里有一个常被误解的边界：Agent 的执行数据不会因为被记录，就自动变成厂商训练基础模型的原料。数据权属、用户同意、企业隔离、敏感信息和错误轨迹都需要处理。即使在自有环境中，未经筛选的失败轨迹也不该直接喂回模型。
更现实的分工是：先在系统层快速适应，再把稳定规律审慎地蒸馏进模型层。前者负责把今天的经验用起来，后者才负责把长期有效的能力写得更深。
从零开始，别先造“全自动进化机”
如果你正在做一个重复执行的 Agent，可以先选一个边界窄、能被验证的任务，而不是试图让整个系统自动改自己。
第一步，固定一小组代表性任务和失败口径，建立当前版本的基线。第二步，只允许更新一个部位，比如工具调用 Skill 或检索前的检查规则。第三步，让候选改动在保留样本上与基线对照。第四步，为每次接受或拒绝留下版本、依据与回滚点。
以我现在的内容生产流程为例：我用 Codex 配合 Skill 工作，发现问题后先由我判断修改目标，再更新 Skill 里的规则或脚本，最后通过测试和真实样例验收。这不是自动自进化，却已经形成“经验—更新—验证—复用”的闭环。比如论文截图误带页边栏，最终不应只手动修一张图，而应把识别规则和回归测试写进脚本，让下一次同类任务自动受益。
这样做看上去没有“自我进化”那么酷，但它会先回答最关键的问题：系统究竟有没有变好，变好的是哪一部分，又牺牲了什么。
Agent 真正需要的不是一个会不断改写自己的魔法开关，而是一套让经验能够被怀疑、被验证、被保留，也能被撤销的工程纪律。
参考资料
Self-Improvements in Modern Agentic Systems: A Survey： https://arxiv.org/abs/2607.13104
PACE: Anytime-Valid Acceptance Tests for Self-Evolving Agents： https://arxiv.org/abs/2606.08106
Stanford CS329A | Self-Improving AI Agents： https://cs329a.stanford.edu/
Anthropic Institute | When AI builds itself： https://www.anthropic.com/institute/recursive-self-improvement
— THE END —
文章仅做学术分享，如有侵权请联系删除，非常感谢！