Agent 自进化：它究竟在修改什么

“Agent 可以在使用中不断进化”是一句很吸引人的话，也是一句信息量很低的话。

有的系统只是把失败经验追加到 Prompt，有的会重写 Memory 规则，有的生成新的 Skill，还有的真的修改 Agent 代码并运行基准测试。它们都被叫作自进化，风险和技术难度却不在一个量级。

我更愿意先问一个朴素的问题：下一次运行与这一次相比，到底有什么东西被保存并改变了？

如果没有任何跨任务保留的变化，Agent 只是在当前任务里反思；如果变化只存在于临时上下文，它属于 test-time adaptation；只有当经验经过选择后进入可复用状态，系统才获得了累积能力。

Agent 自进化从上下文到模型权重的六种更新对象

一、先区分反思、学习与进化

三个词经常混在一起：

行为	是否跨任务保留	例子
反思	否	当前任务失败后让模型重新检查计划
学习	可以	把一次经验写入 Memory 或 Skill
进化	是，并经过选择	生成多个候选版本，评测后保留更优版本

一次任务里执行 plan → act → reflect → retry，即使成功率提高，也不一定是自进化。任务结束后状态全部丢弃，下一次还会从原点开始。

反过来，简单地把所有经验永久追加到 Prompt 也不是有效进化。上下文越来越长、规则互相冲突、早期错误被反复继承，系统可能越用越差。自进化真正困难的部分不在“产生修改”，而在选择哪些修改值得进入下一代。

自进化 Agent 综述把问题概括为三个维度：改什么、什么时候改、怎样改。这套坐标比按项目名称分类更实用。

二、第一层：Context 进化

最轻量的路径是修改模型下次看到的上下文，例如系统指令、操作手册、错误案例或领域经验。

假设一个数据分析 Agent 多次把“同比”和“环比”混淆。系统可以从失败轨迹中整理出一条新规则：

当用户说“同比”时，默认比较去年同期；
如果数据不足以确定周期，先向用户确认，不要自动改成环比。

下次任务开始时，这条规则进入上下文。模型参数没有变化，行为却可能改善。

Agentic Context Engineering（ACE）把这类过程做成生成、反思和整理循环。系统从轨迹中提取有用经验，再增量更新 playbook，而不是每次让模型从头重写整个 Prompt。

增量更新能降低一种常见退化：模型在“优化 Prompt”时喜欢缩短内容，结果把少见但重要的规则一起删掉。ACE 将这种现象称作 brevity bias 或 context collapse，并通过保留已有条目、局部修改来减少信息损失。

Context 进化的优点是便宜、可读、容易回滚。缺点也很直接：规则只能通过自然语言影响模型，无法保证被遵守；条目越来越多以后，需要处理冲突、重复、适用条件和优先级。

三、第二层：Memory 进化

Memory 不只是存储内容，也包含一组策略：

什么值得写入；
写成事实、偏好、事件还是规则；
新旧记忆怎样合并；
检索时使用哪些关系和预算；
什么时候遗忘或降权。

自进化可以发生在内容上，也可以发生在策略上。

内容级更新比较直观。Agent 记住用户偏好或任务事实。策略级更新更有意思：系统发现“把整段日志存入长期记忆会污染检索”，于是改变写入条件；发现某类任务需要时间关系，便为记忆增加事件顺序。

Memory 的危险是错误积累。一次幻觉若被写成长期事实，后续模型会把它当作可信上下文，再生成更多与之相容的错误。每条长期记忆最好保留来源、时间、置信度和适用范围。无法追溯来源的“经验”很难安全更新。

四、第三层：Skill 进化

Skill 比一句规则更接近可执行知识。它可以包含适用条件、步骤、工具说明、模板、脚本和验收方式。

例如，Agent 多次处理数据库慢查询后，不应该只记住“要检查索引”。更完整的 Skill 可能包括：

触发条件：用户提供 SQL 并询问性能
输入检查：SQL、表结构、执行计划、数据量
诊断步骤：过滤选择性 → 索引 → 回表 → join 顺序 → 锁等待
工具：EXPLAIN、慢日志、指标查询
验收：给出修改前后执行计划与耗时
禁止：没有证据时直接建议强制索引

EvoSkill从失败分析中发现能力缺口，提出候选 Skill，经过评测后保留有效版本。它的意义不是“让模型再写一份 Markdown”，而是把 Skill 当作有版本、可验证的优化对象。

Skill 进化比 Context 进化更容易复用，也更容易测试。风险来自执行能力：一条错误规则可能让回答变差，一段错误脚本则可能改坏真实环境。生成 Skill 与启用 Skill 应当是两个独立阶段。

五、第四层：Workflow 与工具进化

Agent 也可以修改任务流程：先检索还是先规划，失败后是否引入 Reviewer，哪些步骤并行，什么条件触发人工确认。

下面两个流程调用相同模型和工具，结果可能完全不同：

流程 A：读取需求 → 修改代码 → 运行测试

流程 B：读取需求 → 定位调用链 → 写失败测试
      → 修改代码 → 定向测试 → 回归测试 → Review

Workflow 进化适合处理重复出现的过程问题。例如大量失败都源于 Agent 修改前没有找到数据兼容逻辑，系统可以增加一个显式的影响分析步骤。

工具也可以被更新：补充一个结构化日志查询工具，给现有工具增加分页和错误类型，或把频繁组合的五次调用封装成一个领域工具。

这一层开始接触 Harness。新 Workflow 可能改变状态机，新工具可能扩大权限，因此需要验证死循环、预算、幂等性和副作用。

六、第五层：Agent 代码进化

Darwin Gödel Machine（DGM）将 Agent 自身代码作为搜索对象。系统从一个 Agent 档案中选择父代，让模型修改其实现，在编码基准上评测，再把有价值的新版本加入档案。

它不是沿着一条线不断覆盖旧版本，而是保留多样化的候选。某个版本当前分数不是最高，却可能携带之后有用的编辑工具、上下文管理或 peer review 机制。

论文报告，DGM 在实验中把 SWE-bench 表现从 20% 提高到 50%，Polyglot 从 14.2% 提高到 30.7%。这证明 Harness 代码本身可以成为优化对象，但也暴露了最严肃的风险：被修改的正是负责运行、评测和进一步修改的程序。

代码级进化必须在隔离环境中运行。候选版本不能拥有修改评测集、绕过沙箱或伪造结果的权限。每次变化要有 diff、构建产物、测试轨迹和可恢复快照。

七、第六层：模型权重进化

最重的更新对象是模型参数，包括微调、强化学习、持续预训练和模型合并。

权重更新能把能力内化，不再依赖长 Context，却面临训练成本、灾难性遗忘、数据治理和回归定位问题。一次 Prompt 变更可以直接查看 diff，一次权重更新很难解释具体哪条行为为何变化。

对大多数应用团队来说，自进化应从 Context、Memory 和 Skill 开始。只有当某类行为高频、稳定、数据充足，并且外部脚手架已经无法满足延迟或效果要求时，权重更新才值得进入选项。

八、AlphaEvolve：把可验证程序放进进化循环

AlphaEvolve提供了另一种很清楚的结构：语言模型生成程序，自动评估器运行并打分，程序数据库保存候选，进化算法决定哪些候选进入后续 Prompt。

Program Database
      ↓ 选择父代与历史候选
Prompt Sampler
      ↓
LLM 生成程序变体
      ↓
Evaluator 执行并评分
      ↓
接受、归档或丢弃

它最适合答案能够写成程序、效果能够自动测量的领域，例如算法性能、调度、芯片设计和数学构造。评估器提供了清晰的优化信号，系统不必只依赖另一个 LLM 的主观判断。

这也说明自进化的上限经常由评估器决定。没有可重复的评分，生成再多候选也只是扩大随机试错。

九、系统什么时候更新

自进化还要决定更新周期。

时机	特点	适用对象
单次任务内	反馈快，不一定长期保留	计划、临时 Memory、重试策略
任务结束后	可以读取完整轨迹	Context、Skill、Workflow 候选
定期离线	允许回放和批量评测	Skill 发布、策略更新、模型训练
在线持续	适应快，风险最高	低风险路由与个性化记忆

生产环境最好把“发现候选”和“发布候选”分开。线上轨迹负责提出问题，离线管道负责生成与评测，达到门槛后再灰度发布。让 Agent 在同一个线上请求中修改自己并立即使用，虽然更像科幻里的自进化，却很难审计和回滚。

十、反馈信号决定系统会学成什么样

更新算法会优化它能看到的信号：

测试是否通过；
任务是否完成；
用户是否接受结果；
LLM Judge 给出的分数；
延迟、成本和工具调用数；
人工写下的文本反馈。

这些指标都不完整。只优化测试通过率，Agent 可能写死答案；只优化用户点赞，系统可能学会迎合；只优化调用成本，复杂任务会被过早终止；只依赖 LLM Judge，Agent 可能适应 Judge 的语言偏好。

因此自进化通常需要多目标约束：质量达到底线后再降低成本，安全规则作为硬约束，线上收益还要通过独立数据确认。

十一、自进化系统的最小闭环

一个可控实现至少包含六步：

采集轨迹
→ 定位重复失败
→ 生成候选修改
→ 在隔离环境评测
→ 达到准入条件后发布
→ 持续监控并允许回滚

其中任何一步缺失都会产生典型问题：

缺失环节	后果
没有失败归因	针对偶然现象修改系统
没有候选版本	新规则直接覆盖旧行为
没有隔离评测	候选污染数据或环境
没有准入门槛	改动只凭几条成功案例上线
没有线上监控	分布变化后仍沿用旧结论
没有回滚	错误经验继续生成错误经验

十二、我更看好哪一层

短期内，我更看好 Context、Memory 和 Skill 的受控进化。它们不需要训练模型，改动可读，能够按领域拆分，也方便做版本和回滚。对 Coding Agent 来说，一个被真实失败轨迹打磨过的 Skill，往往比再加一句通用 Prompt 更有价值。

Workflow 和代码级进化会继续发展，但必须与强评测、沙箱和权限系统一起出现。缺少这些基础设施时，“会修改自己的 Agent”只是把普通软件更新的风险交给了一个概率模型。

自进化可以被写成一句不神秘的话：系统从执行轨迹里提出修改，用独立证据筛掉退化版本，再把通过验收的变化带到下一次任务。变化发生在哪一层，决定了它的能力上限，也决定了我们要承担的风险。