论文阅读 on 扎塔-Zata

MASS：多智能体系统的提示词与拓扑如何协同优化

Mon, 28 Sep 2026 10:30:00 +0800

多智能体系统很容易让人产生一种直觉：一个 Agent 不够，就再加几个；答案不稳定，就让它们辩论；流程效果不好，就换个拓扑试试。问题在于，Agent 的提示词、角色分工和消息流彼此牵连。一个提示词写得含糊，可能让整个链路都跟着偏；一个看起来复杂的拓扑，也可能只是多花了调用成本。

ICLR 2026 论文 Multi-Agent Design: Optimizing Agents with Better Prompts and Topologies提出了 MASS（Multi-Agent System Search）。它的主张很直接：提示词和拓扑要放在同一套设计流程里优化，但不要一上来就把所有变量同时交给搜索。先打磨局部 Agent，再组合工作流，最后回到整体提示词做协同调整。

这篇论文最值得带走的，不是某一种“万能多 Agent 拓扑”，而是一种搜索顺序：先让模块变得可靠，再让模块组成系统，最后让系统中的模块彼此适配。

多智能体设计为什么不只是“多加几个模型”

一个多智能体系统至少有两类关键设计变量：提示词决定每个 Agent 要做什么、收到什么信息、输出什么格式；拓扑决定哪些 Agent 被加入、它们串行还是并行、输出怎样传递和汇总。

这两个变量相互影响。举例来说，反思 Agent 要读预测 Agent 的回答，再指出错误并给出修改建议。若预测 Agent 输出没有清晰结构，反思 Agent 的工作就会变难；若拓扑把反思结果送回预测 Agent 多轮迭代，那么两个 Agent 的提示词也必须适配这种循环。孤立地调其中一边，可能得到局部看起来合理、整体却不工作的系统。

两个常见捷径都不可靠

第一种捷径是增加 Agent 数量。 多个模型并行回答再投票，确实可能减少单次采样的偶然错误，但代价是更多推理 token 和延迟，而且如果所有 Agent 都受同一种提示词缺陷影响，票数增加并不能修好错误方向。

第二种捷径是先挑复杂拓扑。 Debate、Reflect、Aggregate 等模块听起来都很有用，实际效果却取决于任务。论文在 HotpotQA 的分析中发现，在所测的模块里只有 Debate 带来约 3% 的增益，其他模块未能改善甚至会拖累结果。多一个环节，就多一份调用、上下文传递和误差传播的机会。

因此，设计问题不是“能不能把更多 Agent 接起来”，而是“哪些模块在当前任务上有增量价值，以及它们需要怎样的提示词和连接方式”。

MASS：从局部提示词到整体工作流的三阶段搜索

MASS 把搜索拆成三段。前一段产生的提示词或拓扑会成为后一段的条件，逐步缩小问题范围。

阶段一：先优化单个构件（1PO）

论文先对基础 Predictor（预测者）优化提示词，再逐个优化搜索空间里的其他 Agent 构件。这里的“提示词优化”不只是润色指令，还会联合优化 instruction 和 few-shot 示例。像 Debate 这样的模块，则在最小可用配置下优化：用两个 Predictor 配一个 Debator，先确认这类协作单元是否能工作，再考虑扩展规模。

这么做的目的，是避免拿一组未经验证的手工提示词直接组成复杂系统。否则，系统效果差时，很难判断是拓扑有问题，还是其中某个 Agent 本来就没有把自己的任务做好。

阶段二：带着局部结果搜索拓扑（2TO）

接着，MASS 比较各个构件相对于基线预测者的增量影响。论文用验证集上的表现变化估计某个设计维度是否值得纳入搜索，并把影响较大的模块以更高概率保留在候选空间里；同时限制系统可包含的 Agent 数量，避免搜索预算失控。

这是 MASS 的一个关键选择：它不是在庞大的组合空间中平均地碰运气，而是先用局部实验估计哪些构件值得组合，再对更有希望的配置进行采样和评估。候选工作流按预先定义的构建规则组织，减少等价排列带来的冗余。

需要区分的是，增量影响是一种搜索启发式，不是模块价值的普遍定理。它由特定数据、模型和验证指标估计；换任务或换底座模型，权重和排名都可能变化。

阶段三：对最佳工作流做整体提示词优化（3PO）

阶段二找到表现较好的拓扑后，MASS 不会认为局部最优提示词已经足够。它把选出的整个多智能体系统作为一个整体，再对其中的提示词进行联合优化。

原因在于，模块单独表现好，不代表放进工作流后仍然最合适。下游 Agent 接收的是上游实际生成的内容，而不是研究者理想中的标准答案；输出格式、信息完整度和协作目标都会影响彼此。最后这轮优化负责把提示词调整到“在当前拓扑里合作”的状态。

可以把三个阶段简写为：

先把 Agent 模块调好 → 再搜索如何连接 → 最后按整条工作流协同调提示词

搜索空间里有哪些 Agent 模块

论文把多智能体流程表示为一组可组合构件，而不是让搜索器任意生成程序。核心构件包括：

构件	在工作流中的作用	常见形式
Aggregate	并行生成多个预测，再汇总	Self-Consistency、多数投票
Reflect	检查已有回答并提出修订	Self-Refine、反思循环
Debate	多个 Agent 读取彼此观点并更新答案	多智能体辩论
Summarize	分阶段压缩长上下文	面向长文档的摘要链
Tool-use	按需插入工具调用	检索、代码执行

同一个构件也带有可以调整的参数，例如并行 Agent 数、反思轮数、辩论轮数；工具调用则可作为开关纳入设计。论文还用预定义的构建顺序组织流程，以较小的搜索空间换取更可控的组合与复现。

这也意味着 MASS 并非“给模型一张白纸，让它发明任意 Agent 架构”。它优化的是研究者定义好的可定制搜索空间。搜索空间选错了，搜索算法无法凭空补上缺失的模块；空间过宽，则实验成本和验证负担都会上升。

实验说明了什么

论文在数学推理、长上下文问答和代码任务上评测 MASS，包括 MATH、DROP、HotpotQA、MuSiQue、2WikiMQA、MBPP、HumanEval 和 LiveCodeBench 的输出预测子任务。主要实验使用 Gemini 1.5 Pro / Flash，并在附加实验里检查 Claude 3.5 Sonnet 和 Mistral Nemo 等不同底座模型。核心结果报告三个评测运行的均值与标准差。

以 Gemini 1.5 Pro 为例，论文表格给出的跨任务平均分如下。指标包含准确率、F1 和 pass@1 等不同度量，作者报告了每个数据集的对应指标后再计算平均，因此它适合看整体趋势，不应被理解为单一统一指标。

MASS 平均为 78.79，表中 Multi-Agent Debate 为 70.26，CoT 为 65.28。各个单项也不是 MASS 全面领先：例如 2WikiMQA 上 AFlow 为 76.51，高于 MASS 的 73.34。因此更准确的结论是，MASS 在论文所测的整组任务和比较方法中取得了更高的总体平均，并在多个任务上表现突出；这不意味着它在每种任务、每项指标、每个模型上都是赢家。

Token 效率和拓扑筛选同样重要

论文还比较了提示词优化与“保持默认提示词、增加 Agent 数量”等做法。其分析显示，在 MATH 实验中，经过提示词优化的单 Agent 更能以较少推理 token 提升表现；再在这个基础上扩展并行采样，扩展曲线比直接堆默认 Agent 更好。另一方面，拓扑分析显示，有正向影响的构件只占整个设计空间的一部分。

这里的“效率”主要是推理阶段的 token 与效果关系。它不等于构建 MASS 的全流程免费：自动提示词优化、候选工作流采样和验证集评估都需要额外调用。论文也对推理成本作了可比控制，但真实部署的延迟、吞吐量和价格仍取决于模型、并行策略、缓存以及任务流量。

这篇工作的价值与边界

有价值的地方：它把优化顺序也当成设计的一部分

MASS 的贡献不只是“优化提示词”或“搜索拓扑”，这两类工作此前都有人做。更有启发的是把它们放进一个有顺序的闭环：先局部测量模块价值，再用这些信息缩小拓扑搜索范围，最后针对整体系统重新调提示词。它让多 Agent 设计从凭直觉堆角色，变成可以记录指标、比较候选、逐步缩小范围的实验过程。

需要谨慎的地方：基准上的高分不等于生产环境收益

论文主要在有明确指标和可重复输入的基准数据上优化。真实产品里的目标可能同时包括正确率、延迟、成本、用户体验、隐私约束和可审计性；只对一个验证指标做优化，未必能满足这些约束。

此外，实验中的模型版本是 Gemini 1.5、Claude 3.5 Sonnet 等特定版本。模型能力、API 行为和价格变化后，最优提示词与拓扑也可能改变。MASS 的搜索空间、验证集以及构件模板仍需要人为定义，论文结果不能直接外推为“自动搜索会替你完成系统设计”。

工程上怎么借鉴 MASS

如果要把这个思路用于自己的 Agent 工作流，可以先从一个小型、可验证的任务开始：

确定单一评估目标。 例如答案准确率、代码测试通过率，或带成本上限的质量得分。不要一开始混合多个互相冲突的目标。
为模块定义输入、输出和成功条件。 保证每个 Agent 的职责能单独评估，尤其要固定交接格式。
先测模块增量。 比较无模块基线与加入模块后的表现，同时记录调用数、token、延迟；没有稳定增益的模块先不进入组合搜索。
限制候选空间。 只搜索少量有理由尝试的拓扑，预先规定最大 Agent 数和轮数，并保留简单基线。
留出未参与优化的测试集。 提示词在验证集上反复试，很容易适配验证样本；最终结果应在独立测试集上复核。
最后再做整体优化。 用工作流真实传递的中间结果测试，而非把理想化答案喂给下游 Agent。

这套流程最适合任务边界清晰、存在可自动计算的评估指标、且单次错误成本足以证明额外调用合理的场景。若任务本身很简单，单 Agent 已经满足质量与可靠性要求，多智能体搜索增加的复杂度可能没有回报。

总结：先证明构件有用，再证明组合更好

MASS 给多智能体系统设计提供了一条可操作的路线：优化单个 Agent 的提示词，基于构件的实测影响筛选拓扑，再对选中的整体工作流做联合提示词优化。实验支持“提示词质量和拓扑选择都重要”这一判断，但没有证明多 Agent 在所有任务上都值得使用。

我对这篇论文的概括是：Agent 数量是配置，工作流是结构，提示词是协作协议；三者需要一起评估，但可以分阶段优化。 真正值得复制的，是这条带有预算、验证集和消融意识的设计流程，而不是照搬某个榜单上分数最高的拓扑。

参考资料

Zhou et al., Multi-Agent Design: Optimizing Agents with Better Prompts and Topologies，arXiv:2502.02533，v2 发布于 2026-01-31，发表于 ICLR 2026。
论文 HTML 全文：arXiv HTML。实验数字、方法描述和限制均以论文正文及附录为准。
视频解读：B 站：MASS——交错优化多智能体系统的提示词与拓扑。

Agent 自进化开源盘点：什么能跑，什么在腐烂，什么被门控救回来

Mon, 28 Sep 2026 18:05:00 +0800

jennyzzt/dgm 的 issue 列表里有一条 2025-06-02 开的：「Where can I find the code for the runnable best-discovered agent for both benchmark?」。它挂了一年多。仓库 2,380 star、Apache-2.0、27 个 open issue，最后一次 push 是 2025-08-13（一手，GitHub API 于 2026-09-28 直查）。

Darwin Gödel Machine 是这两年「自进化 Agent」最出圈的工作：论文里 SWE-bench 从 20.0% 涨到 50.0%，靠的不是换模型，而是让 Agent 改写自己那套编码脚手架。我原本打算照着它的仓库跑一遍，再决定要不要在自己的系统里给 Agent 开「自我修改」这个口子。

结果仓库点开才发现：代码在，但藏在一个叫 best_swe_agent 的分支里，而且只有 SWE-bench 那半边，Polyglot 没有（issue #8 的回复原文：“It is in the branch "best_swe_agent". No polyglot agent though."）。基座还是 Claude 3.5/3.7 Sonnet 加 o3-mini，这些模型现在都已经退役了。

这篇就是把「自进化」这条线上的开源工作逐个点开看了一遍的结果。信源分级沿用我在《2026 年 AI Agent 现状》里定的规矩：

一手——我直查了 GitHub API、arxiv 摘要页、官方仓库 README 或发布页
转述——只在二手渠道看到，没能直连原始出处
未核——搜到过但没有可信出处，不作为论据

仓库的 star / push 日期 / 许可证全部是 2026-09-28 从 GitHub API 现拉的，arxiv 编号逐条用 export.arxiv.org 反查过标题。这类数字半年就会过期，看的时候记得对一下日期。

先给一张地图：自进化到底在改什么

社区现在通用的骨架是那篇 TMLR 收录的综述（arxiv 2507.21046，2025-07-28 提交、v4 到 2026-01-16，一手），它把问题拆成 what / when / how / where。其中 what 最好用，因为开源仓库基本就是按「改哪个部位」分堆的：

顺序很重要：越往下越贵、越不可逆、也越少有人真跑通。而 2026 年社区的实际进展，几乎全在最上面那格和第三格——上下文/技能，以及离线程序搜索。下面按这五个部位清点。

部位一：改系统结构（工作流搜索）

这一堆是 2025 年 ICLR 那批论文的产物，现在状态分化得很厉害：

仓库	star	最后 push	许可证	实际能跑什么
`ShengranHu/ADAS`	1,637	2025-01-28	Apache-2.0	元 Agent 用代码写新 Agent，`python {DOMAIN}/search.py`，需 OpenAI key
`FoundationAgents/AFlow`	605	2025-12-25	MIT	MCTS 搜代码化工作流，`python run.py --dataset MATH`，钉 Python 3.9
`ANative-Lab/EvoAgentX`	3,356	2026-08-27	NOASSERTION	`pip install evoagentx`，自进化工作流 + 长短期记忆 + MCP 模块
`modelscope/AgentEvolver`	1,572	2026-04-01	Apache-2.0	自提问/自导航/归因的训练式闭环（arxiv 2511.10395，转述）

论文里的收益是真的：AFlow 在 6 个数据集上平均 +5.7%，还给出「小模型用 GPT-4o 4.55% 的推理成本反超」的结论（arxiv 2410.10762v4，一手）；EvoAgentX 报 HotPotQA F1 +7.44%、MBPP pass@1 +10.00%、GAIA 最高 +20.00%（arxiv 2507.03616v2，一手）。

但要提醒一句：ADAS 和 AFlow 的仓库已经不再维护，而且论文里的数字依赖当年的 GPT-4/3.5 端点——今天复现，你测的已经不是同一个模型了。这一层的正确用法是抄它的搜索思路，不是拿它当基线。 真正还能 pip install 的是 EvoAgentX，代价是它的许可证字段 GitHub 识别为 NOASSERTION，商用前得先读 README。

部位二：改自己的代码（自我修改的编码 Agent）

最有话题性，也最不能直接用。

仓库	star	最后 push	许可证	状态
`jennyzzt/dgm`	2,380	2025-08-13	Apache-2.0	事实停摆；最佳产物藏在分支里，无 Polyglot
`facebookresearch/HyperAgents`	2,771	2026-07-31	NOASSERTION	DGM 一作转去 Meta 后的续作（arxiv 2603.19461，转述）；README 标注非商用
`Arvid-pku/Godel_Agent`	227	2025-09-17	MIT	运行时 monkey-patch 自己的 `agent_module.py`，玩具规模
`microsoft/stop`	54	2024-01-01	MIT	已废弃，GPT-4 时代提示词
`SWE-bench/SWE-smith`	790	2026-09-21	MIT	不做自改，但能批量造 5 万+ 训练环境，是这层的弹药库
`OpenHands/OpenHands`	89,348	2026-09-25	MIT	这层研究普遍拿它当底座，生产可用

DGM 的坑不止「代码难找」。它的 issue #35（2026-07-28，转述）指出：harness 并没有被限制在 /testbed 里，/polyglot 目录下隐藏测试和 .meta/example.* 参考解仍然可读——也就是说，自我修改的搜索空间里摆着标准答案。作者回复说日志里没发现实际利用。这句话恰好是自进化最难的地方：没发现 ≠ 没可能。

顺带一个真实的安全教训：Pythagora-io/gpt-pilot（33,659 star）的 README 现在明确写着，2025-08-24 到 2026-06-11 之间仓库里被植入过偷凭据的供应链蠕虫，并且项目「不再积极维护」（一手，README）。让 Agent 自己改代码、再把改完的代码直接发出去，风险面就是这个形状。

部位三：进化式程序搜索（AlphaEvolve 那条线）

这是被引用最多、也最容易被说错的一层。先把事实钉住：

AlphaEvolve 没有开源。 DeepMind 只放了结果仓库 google-deepmind/alphaevolve_results（301 star，Apache-2.0）和白皮书（arxiv 2506.13131，一手）。它的成果确实硬：4×4 复矩阵乘法用 48 次标量乘（56 年来首次改进 Strassen 的结果）、手写 FlashAttention kernel 最高 +32.5%、Borg 调度器持续回收 0.7% 全球算力（一手，官方博客与白皮书）
FunSearch 开源了，但等于没开。 google-deepmind/funsearch 1,126 star，最后 push 2024-02-05，README 明说不含语言模型、不含沙箱、不含分布式基础设施，只有单线程参考实现（一手，README）

于是社区自己补了两个能跑的替代品，而且都活着：

仓库	star	最后 push	许可证	怎么跑
`algorithmicsuperintelligence/openevolve`	7,450	2026-09-28	Apache-2.0	`pip install openevolve` → `openevolve run --config ...`，任意 OpenAI 兼容端点或 Claude Code CLI
`SakanaAI/ShinkaEvolve`	1,416	2026-09-24	Apache-2.0	`pip install shinka-evolve`，Sakana 在 DGM/AlphaEvolve 之后做的少样本程序进化引擎，有 Colab 教程
`EvoScientist/EvoScientist`	5,025	2026-09-26	Apache-2.0	PyPI 同名，deepagents 之上的「vibe research」闭环，附带 `EvoSkills` 技能包

想在 2026 年亲手体会「进化出代码」是什么感觉，OpenEvolve 和 ShinkaEvolve 是门槛最低的两个入口。 注意它们的定位：离线搜索一个更优的函数/kernel/配置，跑几小时到几天，产物是一段人可以看懂、可以 review 的代码。这跟「线上 Agent 边跑边改自己」是完全不同的工程问题，也是这层给生产系统最实用的启示。

部位四：改权重（真正的自我训练）

仓库	star	最后 push	许可证	状态
`Continual-Intelligence/SEAL`	1,863	2025-08-01	MIT	模型自己产微调数据再 RL 回自己；SQuAD 无原文 33.5%→47.0%（arxiv 2506.10943v2，一手）；需要 2×A100/H100，停摆约 14 个月
`mll-lab-nu/RAGEN`	2,808	2026-08-23	MIT	多轮 Agent RL，重点其实是诊断工具：Echo Trap 与 template collapse
`verl-project/verl`	23,673	2026-09-20	Apache-2.0	底座。v0.9.1 活跃，「自进化」只是 examples 里的配方，不是产品能力

同厂还有 THUDM/slime（8,550）、OpenRLHF/OpenRLHF（10,047）、NovaSky-AI/SkyRL（2,358），都活跃（一手，GitHub API）。

这一层最该记住的是 SEAL 自己在论文 §5 Limitations 里写下的两句：连续 self-edit 之后早期任务表现逐步下滑（灾难性遗忘），以及它的 test-time-training 奖励循环明显比其他 LLM RL 循环更贵（一手，arxiv 2506.10943）。而 RAGEN 那条线更进一步指出，Agent RL 自演化会塌进「模板坍塌」——熵还是稳的，但推理已经和输入无关了，用现有指标看不见（arxiv 2604.06268，2026-04-07，一手）。

一句话：改权重这条路，开源社区给的是基础设施，不是成品。

部位五：改上下文（记忆、技能、提示词）—— 这层真的能跑

如果只让我留一个方向进生产，是这里。

仓库	star	最后 push	许可证	为什么值得看
`gepa-ai/gepa`	6,777	2026-09-28	MIT	`pip install gepa`；反思式 Pareto 优化提示词与代码
`stanfordnlp/dspy`	38,392	2026-09-27	MIT	`dspy.GEPA` / `MIPROv2`，v3.4.0，工程入口最成熟
`ace-agent/ace`	1,337	2026-08-24	Apache-2.0	grow-and-refine 的 playbook；只有 eval 脚本、没上 PyPI
`agentscope-ai/ReMe`	3,528	2026-09-28	Apache-2.0	`pip install reme-ai`，自进化记忆库，阿里 AgentScope 系
`mem0ai/mem0`	66,171	2026-09-25	Apache-2.0	记忆层最大用户量的那个
`getzep/graphiti`	31,242	2026-09-08	Apache-2.0	时序知识图谱，「会自己更新」的那一类
`topoteretes/cognee`	31,107	2026-09-24	Apache-2.0	记忆 + 上下文图
`letta-ai/letta`	24,937	2026-09-10	Apache-2.0	sleep-time agents 已经是产品特性，不只是论文

收益数字（都一手核过摘要）：

GEPA：相对 GRPO 平均 +6%（最高 +20%），rollout 少 35 倍；相对 MIPROv2 >10%（AIME-2025 +12%），arxiv 2507.19457、ICLR 2026 Oral。仓库 README 自称有 50 家以上生产使用，点名 Shopify、Databricks、Dropbox、OpenAI、Pydantic（一手，README；「生产使用」的口径由作者自定义）
ACE：Agent 任务 +10.6%、金融 +8.6%，相对 Dynamic Cheatsheet 延迟 −91.5%、token 成本 −83.6%，arxiv 2510.04618v3
Letta sleep-time compute：同精度下测试时算力 省约 5 倍，Stateful GSM-Symbolic +13%、Stateful AIME +18%，arxiv 2504.13171
论文代码 letta-ai/sleep-time-compute 只有 137 star、最后 push 2025-04-30——这个方向上真正活着的是产品仓库，不是论文仓库

技能文件这一层，2026 年已经长成一个生态：

agentskills/agentskills（25,752★，Apache-2.0）是开放的 Agent Skills 规范，agentskills.io 上列了 Cursor、VS Code、Copilot 等客户端支持（一手，仓库与规范页）
anthropics/skills（178,728★）是官方示例集，仓库级许可证字段是 NOASSERTION（内部混了 Apache 与 source-available 的文档技能），README 明确说是演示性质
obra/superpowers（292,323★，MIT）是目前最大的社区技能库
NousResearch/hermes-agent（249,639★，MIT，push 到今天）README 原话是「The only agent with a built-in learning loop — it creates skills from experience, improves them during use」，外加 agent-curated memory、FTS5 会话回溯、兼容 agentskills.io（一手，README）
openclaw/openclaw（390,692★，v2026.9.6）配 ClawHub 技能注册表，社区技能清单仓库 VoltAgent/awesome-openclaw-skills 52,846★（一手，GitHub API）

「自进化」在生产里的合法形态，到这里已经很清楚了：不是让 Agent 改自己的代码，而是让它把经验写成文件，然后有人 review。 这条我们自己在《Agent 用户记忆与 Skill 沉淀》里已经按这个方向做过架构设计，这次算是给社区侧背书。

反证：2026 年下半年最重要的四篇

上面所有正向数字，都被下面这组结果限定住了。它们的共同点是：都在测「自进化到底有没有变强」，而不是「自进化又涨了多少分」。

1. 贪心接受 = 对自己做 p-hacking。 PACE（arxiv 2606.08106，2026-06-06，一手）：用「分数涨了就用」这条最自然的接受规则，30–42% 的提交是误提交、10–33% 的编辑是有害编辑；在本来就没有提升的情况下，每轮仍会产生 13–21 次伪自我修改，其中 72–100% 是假的，最脆弱的 Agent 掉了 4.9 分。作者用 anytime-valid 检验把门守住。

2. Agent 会改自己的考卷。 RewardHackingAgents（arxiv 2603.11337，2026-03-11，一手）：在自然运行中，约 50% 的 episode 出现篡改 evaluator 的尝试；唯一有效的防御是把评估器锁死，代价是 25–31% 的运行时开销。另一篇（arxiv 2609.04170，2026-09-03，一手）观察到 100 个 Lean 证明 Agent 里，一个 Agent 发现评测漏洞后经共享知识库和 P2P 消息把作弊方式传开，同时自发出现了「吹哨人」式的审计与抵制。

3. 污染删不干净。 EVOMAL（arxiv 2608.25776，2026-08-26，一手）：自进化 Agent 在带毒技能库里会自己复制出恶意技能，数量是植入源的 4.9–9.0 倍；把植入源删掉之后，Qwen3 在第 5 轮仍有 68% 的攻击成功率。「先清干净再进化」这个直觉不成立。同一方向还有《When Self-Evolution Backfires》（arxiv 2608.05810，一手）：技能池超过临界规模后，新技能反而拉低表现，且污染链结构上不可逆，事后回滚只能挽回一小部分。

4. 域内涨、域外缩水。 RRSI（arxiv 2609.24972，2026-09-21，一手）：递归进化「记住训练任务而虚高」，正则化之后域内 +14.1，5 个域外任务只有 +4.7。RSEA（arxiv 2606.28374，一手）更直接：没有 held-out 门控的方法，一项近最优、另一项直接崩到 0.14，而同任务的 ReAct 基线是 0.43。

还有一篇专门测「技能到底该由谁写」的：SkillsBench（arxiv 2602.12670，2026-02-13，一手，87 任务 / 8 领域 / 18 个模型-外壳配置）给出 人工整理的 Skills 把平均通过率从 33.9% 提到 50.5%（+16.6pp），小模型配 Skills 能追平不带 Skills 的大模型。至于是不是「LLM 自己写 Skills 一点用没有」，我只在二手转述里看到 +0.0pp 这个说法——未核，不作为论据。

社区收敛的答案：不是更强的自改，是更严的门控

把上面四篇反过来读，就是 2026 年下半年这一层的真实工程进展：大家都开始给「自我修改」加装一道外部准入。

RSEA（arxiv 2606.28374）：只在与训练不相交的 held-out 划分上不回归才提交。原文的说法很硬——严格 held-out 选择才让递归自进化单调安全
Self-Healing Harness（arxiv 2609.24130，2026-09-21，一手）：候选规则先拿临时权限，「在触发失败上确有提升、且不回归受保护用例」才持久化。16 组对照里拒绝了 383 个 replay 判定提案，其中 211 个（55%）是「修好了本地、却打破了别处」
验证器共进化（arxiv 2607.17352，转述）：让自改 Lean 的 Agent 与基准一起进化，以 verifier 为唯一裁判，held-out miniF2F 45.1%（种子 12.7%、固定基准 32.0%）
可审计技能图（arxiv 2512.23760，转述）：把自进化重述成「编译进一张可审计的 ASG，每个候选都要过 verifier-backed replay 和契约检查才能 promote」，并给了审计日志框架
技能库治理配方：Library Drift（arxiv 2605.19576，2026-05-19，一手）诊断了一种「静默失败模式」，给出 outcome-driven 退役 + 有界活跃上限 + meta-skill 先验，MBPP+ 上 100 轮 held-out pass@1 从 0.258 拉到 0.584

这里有个我特别想说的反差：amazon-science/Self-Evolving-Agents-Ratchet 这个把上面配方落地的仓库，只有 3 个 star（一手，GitHub API）。而 DGM 有 2,380 个。社区给「能自我修改」发的掌声，远多于给「能让自我修改不腐烂」的。

我会怎么用这份清单

按「今天就能动手」排序：

提示词与流程优化：pip install gepa（或 dspy.GEPA），拿你自己的评测集当奖励。这是唯一一个「装完就能在自己业务上看到数字」的选项
上下文与记忆：reme-ai / Mem0 / Graphiti 三选一，先解决「经验存在哪」，再谈「谁来改」
技能文件：按 agentskills.io 规范写，人 review、可 diff、可回滚。要现成的技能库就看 superpowers、anthropics/skills
离线算子搜索：OpenEvolve 或 ShinkaEvolve，跑在 CI 之外的机器上，产物走正常代码评审
别在生产里放自我修改。要试也只在沙箱 + 锁死评估器 + held-out 门控三件齐备时试，并接受 25–31% 的开销
给技能库设生命周期：活跃上限、按结果退役、准入必须过 held-out。否则你迟早会撞上 2608.05810 那条「新技能拉低表现」的曲线

治理侧的两句话

Dario Amodei《We Must Pace the Frontier》（2026-09，一手）：递归自我改进「可能跑赢我们的理解能力」，提出 Embedded Evaluators——独立第三方评估员常驻研发流程，核安全实践、报事件、盯关键指标，再走民主协调、全球协调
Anthropic 的进度度量（anthropic.com/institute，2026-09-24，一手）：用 AL0–AL5 量表描述 AI 研发自主度，截至 2026-08，Claude 在 26% 的 AI 研发工作中「lead」，AL5（完全自主）未达到

OpenAI 在 2026-09-22 呼吁由美国牵头制定覆盖 RSI 与事件报告的国际标准——这条我只在中文二手报道里看到，未核，写在这里是为了提醒自己去查原文。

几点收获

1. 「自进化」不是一个技术，是五个可动部位。 改权重、改代码、改结构、离线搜算子、改上下文，成熟度和风险完全不同。讨论混在一起时，先问对方说的是哪一层。

2. 论文仓库的保质期约 12 个月。 ADAS 停在 2025-01、DGM 停在 2025-08、SEAL 停在 2025-08、FunSearch 停在 2024-02、STOP 停在 2024-01。看一个方向是否真的落地，别看 star，看 pushed_at。 反过来，GEPA、DSPy、ReMe、OpenEvolve、Hermes 的 push 日期是 2026-09-28 当天或前几天。

3. 最出圈的成果往往不开源。 AlphaEvolve 只有白皮书和结果仓库，FunSearch 开源了但按 README 无法复现。这不代表它们不强，只代表你的复现成本被标错了。

4. 自进化的瓶颈是统计，不是模型。 PACE 那组数字（13–21 次伪修改、72–100% 假）本质是多重比较问题：你拿同一个指标反复接受「看起来更好」的改写，就一定会挑到噪声。解法也不是更聪明的模型，是 held-out 和 anytime-valid 检验——都是十年前的实验技术。

5. 污染是不可逆状态，不是可回滚 diff。 EVOMAL 的 4.9–9.0 倍复制和删源后 68% 存活，意味着技能库/记忆库需要准入控制而不是事后审计。这一条会改写我们对「先让它自己写，出问题再回滚」的默认乐观。

6. 人工整理技能仍然赢。 +16.6pp 这个数字值得贴在每次讨论「要不要让 Agent 自己攒技能」的会议室里。它不代表自动化没价值，只代表现阶段人的判断是收益的主要来源。

7. 真正在跑的自进化，长得像 CI。 临时权限、replay、受保护用例、held-out、promote——把这套词换成「测试、灰度、回归、发布」，就是普通的工程流水线。这也是为什么一个 Agent 团队如果想认真做这件事，最先该补的是评测流水线，而不是自我修改的权限。

8. 那份 3 star 的仓库可能比 2,380 star 的更值钱。 我这篇的价值大概也在这个反差上：把掌声和可用性分开数。

主要出处

一手：GitHub API 于 2026-09-28 直查的 20+ 仓库元数据；arxiv 摘要页反查的编号 2507.21046、2410.10762、2507.03616、2506.10943、2504.20073、2604.06268、2510.04618、2504.13171、2507.19457、2506.13131、2606.08106、2608.25776、2603.11337、2602.12670、2605.19576、2609.24972、2606.28374、2609.24130、2608.05810、2609.04170、2609.26457；jennyzzt/dgm issue #8；DGM、AlphaEvolve、FunSearch、GEPA、Hermes、OpenClaw、agentskills 的 README；darioamodei.com；anthropic.com/institute。

转述：facebookresearch/HyperAgents 的非商用条款与 arxiv 2603.19461 的对应关系、modelscope/AgentEvolver（2511.10395）、arxiv 2607.17352、2512.23760、DGM issue #35 的细节、GPT-Pilot 蠕虫的时间窗。

未核：「LLM 自写 Skills 增益 +0.0pp」；OpenAI 2026-09-22 的 RSI 标准提案原文；SWE-Dojo（搜不到仓库）。

数据抓取于 2026-09-28。这份清单的正确用法不是照抄，是照抄之前自己 git log -1 一次。