这两年，Agent 赛道一直在卷“能力”。谁的工具调用更稳，谁的规划链路更长，谁的执行成功率更高，谁就更容易被看作下一代智能体的候选形态。但如果把时间线再往后拉一点，一个更关键的问题其实已经浮出水面：未来真正拉开差距的，可能不是 Agent 会不会做事，而是 Agent 会不会改进自己。
最近这篇《HyperAgents》讨论的，正是这个问题。
https://arxiv.org/pdf/2603.19461
它真正有意思的地方，不是又做了一个更强的任务型 Agent，也不是单纯把“自我改进”这四个字重新包装了一遍，而是把一件过去常常被默认由人来负责的事情，第一次比较系统地交给了 Agent 本身：不仅让它去完成任务，还让它去修改“自己是如何完成任务的”。 更进一步，论文甚至把“如何修改自己”这套机制，也放进了可被继续修改的范围里。
这意味着，Agent 开始从“会做事的程序”，往“会演化的程序”迈了一步。
真正的问题是谁来决定怎么改
过去一段时间，所谓自我改进型 Agent 并不少见。很多系统都能做 prompt 调优、代码 patch、工具选择优化，甚至能根据历史表现自动生成下一轮修改建议。表面看，这似乎已经很接近“Agent 自我进化”了。但这类系统有一个共同特点：它们虽然能改自己，但“怎么改”的方法，往往还是人预先写好的。
也就是说，系统能动的，只是任务执行层；真正负责提出修改策略、控制搜索方向、总结经验教训的元层逻辑，仍然是人工设计的。这样的系统当然可以进步，但它的进步，本质上仍然是在一条人划定好的轨道里移动。
《HyperAgents》对这个问题的判断很直接：这不够。
论文认为，过去那种做法默认了一个前提——只要 Agent 会做任务，它大致也就会改自己。这个假设在 coding 这类任务上勉强成立，因为写程序、改程序、调程序，本来就高度同构。但一旦任务换成论文审稿、机器人 reward 设计、数学答案评分，这种“做任务能力”和“自我修改能力天然一致”的前提就开始松动。你可能很会完成某项任务，但不一定真的知道自己应该怎样系统性地变好。
所以这篇论文真正要解决的，不是“让 Agent 再多做一点自动优化”，而是把元层也开放出来，让 Agent 连“改进方法本身”都能继续演化。
HyperAgents 到底是什么
论文提出的核心概念叫 hyperagent。如果用比较直白的话来讲，它不是一个单层的 Agent，而是一个由两部分组成的系统。
一部分是 task agent，负责真正执行任务；另一部分是 meta agent，负责观察前面的表现、分析问题、设计修改方案，并生成下一版 Agent。关键在于，传统系统里 meta agent 的规则通常是写死的，而在 HyperAgents 里，meta agent 本身也被纳入可编辑对象。换句话说，它不只是在改“我怎么做事”，还在改“我以后该怎么改自己”。
论文基于此前的 Darwin Gödel Machine，做出了扩展版 DGM-H。它仍然保留了进化式搜索的基本框架：维护一个 archive，从中挑选 parent，生成 child，评估之后再放回 archive，让中间版本不断积累，逐渐形成“垫脚石”式的能力跃迁。但和原始 DGM 不一样的是，这里进入 archive 的不只是普通 Agent，而是一个连 task logic 和 meta logic 都一起打包的可自改系统。
这件事的重要性，远比“再加一个模块”大得多。因为它意味着 Agent 的优化目标，从此不再局限于某次任务成不成功，而开始触碰更高一层的问题：什么样的反思机制更有效，什么样的记忆结构更有用，什么样的迭代策略更能避免走弯路。
这已经不是简单的“自动调参”，而是在逼近一种更像“元认知工程”的东西。
跨域的自学习能力
如果只盯着 coding benchmark，这篇论文未必会让人立刻觉得震撼。因为在纯代码任务上，DGM-H 的表现虽然很强，但并没有把原始 DGM 明显甩开。原因其实也不复杂：原始 DGM 本来就是为 coding 场景量身打造的，很多元层机制天然更适合代码类任务。在这种场景里，HyperAgents 的优势不会被完全放大。
真正值得看的是跨域实验。
论文把 paper review 和 robotics reward design 放在同一个演化过程中做联合优化。这个设计非常重要，因为它在检验一件更本质的事：系统学到的到底是某个任务的局部技巧，还是一种可以跨任务迁移的改进能力。
结果显示，传统 DGM 在这些非 coding 场景里几乎直接失效，而 DGM-H 不仅能跑通，而且在测试集上明显优于手工定制的对照版本。这个结果说明，HyperAgents 的意义不在于它把某一项任务又刷高了多少分，而在于它证明了一件更重要的事：“如何改进自己”这件事，本身可以成为一种可学习、可积累、可迁移的能力。
这正是这篇论文和大量 Agent 优化工作拉开差距的地方。
过去很多系统优化的，其实都是“这一次怎么答更好”“这一步怎么调用工具更稳”“这个 prompt 怎样写更有效”。而《HyperAgents》开始优化的是另一层东西：下一轮应该往哪里改、哪些失败值得记住、哪些成功经验可以复用、什么修改方向会导致性能回退。
一旦进入这一层，整个问题的性质就变了。它不再只是任务工程，而开始变成能力生成机制本身的工程。
Agent 学会了“怎么变强”
论文里最值得重视的证据，不是某个单点分数，而是它后面做的迁移实验。
作者专门设计了一个更刁钻的验证方式：把已经在 paper review 和 robotics reward design 上进化出来的 hyperagent，迁移到一个新的任务上——IMO 级别的数学解答评分。这里考察的，不是这个 Agent 自己去做新任务的能力，而是它作为 meta agent，还能不能继续生成更好的 task agents。
结果很有意思。初始版本的 meta agent 几乎没有这种能力，传统 DGM 的跨域迁移效果也基本接近于零；但已经进化过一轮的 HyperAgent，在新任务上却还能继续有效地产生更优的下一代。换句话说，它带过去的不是某个旧任务的技巧，而是某种更抽象的“改进方法论”。
这才是这篇论文最硬的地方。
因为它说明 HyperAgents 学到的，不只是怎么写更好的审稿意见，或者怎么设计更合理的 reward function，而是一些更上层的能力：如何追踪性能、如何维护长期记忆、如何分析多代结果、如何识别过度修正、如何做前瞻性规划。论文附录里展示的几个例子也很能说明问题：系统会自己长出类似 PerformanceTracker 的结构，会跨代记录表现趋势，会总结“第55代更敏锐但过于苛刻，第64代更平衡，因此下一轮应该融合前者的批判性与后者的均衡性”这种经验性判断。
这已经不再像简单的 trial-and-error，而开始像一个真正会做复盘、会做策略收敛的工程系统。
harness 层的自进化
如果把这篇论文放到今天 Agent 工程的大背景下去看，它还有一个特别值得强调的点：它讨论的“自我进化”，并不是模型权重层面的自训练，而是 agent program / harness / workflow 层面的递归改造。
底层 foundation model 在实验中是冻结的。变的是它外面的那套程序结构：prompt、代码、记忆、工具使用流程、任务拆解方式、反思和评估逻辑。这其实很关键，因为现实里大部分企业和开发团队最能动的，也正是这一层，而不是动不动就去重训一个大模型。
换句话说，《HyperAgents》传递出的一个非常现实的信号是：Agent 体系未来的主要竞争，很可能不只是模型能力竞争，而是 harness 层的自演化竞争。 谁更会组织任务，谁更会总结错误，谁更会把经验沉淀成下一轮的结构优势，谁就更可能在相同基座模型上拉开差距。
这和最近很多人谈的 harness engineering，其实正好连上了。不同的是，过去我们讲 harness，更多还是人在设计；而这篇论文往前推了一步，开始让 harness 自己去改 harness。（有关harness engineering的介绍参考之前的文章最近爆火的harness engineering是什么？它与prompt engineering、context engineering、agent框架、tool use的区别是什么？）
如果这条路线继续成立，那么未来 Agent 的核心壁垒，很可能不再只是“模型调用得聪不聪明”，而是“系统能不能持续把自己的经验转化成新的能力结构”。
但它离失控式递归爆炸还很远
当然，这篇论文也不能被神化。
它虽然已经触到了递归自我改进的门槛，但离很多人脑补的那种“系统突然脱离控制、疯狂自我进化”还差得很远。原因也很简单：实验里的很多外层机制其实还是固定的。任务分布是预定义的，评估协议是固定的，parent selection 逻辑基本也是给定的。也就是说，目前真正可变的，主要还是内层的 agent 代码和元层策略，而不是整个外部搜索框架都被完全放开。
这就意味着，它更准确的状态应该叫：受控条件下的局部递归自我修改，而不是完整意义上的无限自我进化。
另外，这篇论文虽然展现出了“复利式改进”的趋势，但并没有把这种趋势在统计意义上彻底钉死。它已经证明了元能力可以迁移，也显示出跨 run 的积累效应，但还没有证明系统会稳定进入那种越来越快、越来越强的指数级自我增强状态。
再直白一点说，这篇论文的重要性在于“方向被打开了”，而不是“终局已经到了”。
安全问题开始从输出层上移到修改层
如果从“模安局”的视角看，这篇论文最值得重视的，其实不是能力，而是治理对象的变化。
过去我们谈 Agent 安全，很多时候盯着的是输出内容、工具调用、权限控制、越狱防护、执行边界这些相对直接的层面。但 HyperAgents 提醒我们，未来真正需要治理的，可能不只是某个 Agent 说了什么、做了什么，而是它是如何变成现在这样的。
因为一旦系统能够修改 task logic、memory policy、evaluation heuristic，甚至未来进一步修改搜索策略、选择策略和迭代规则，那么风险就不再只是“单次执行失控”，而是“能力生成机制本身被带偏”。今天的问题可能还是输出不稳定，明天的问题就可能变成：系统学会了错误的优化目标，沿着错误的指标不断强化自己。
这会把安全边界整体前移。
未来真正关键的，不会只是内容审核 API 或 system prompt 防线，而是更底层的几道闸门：代码修改权限是否受控，评估指标是否可信，长期记忆是否可审计，演化路径是否可回滚，工具和环境权限是否被严格隔离。
换句话说，一旦 Agent 开始具备“改自己”的能力，安全治理就必须同步升级到“治理自我修改回路”的层面。否则你拦住的可能只是表面的输出，却拦不住底层能力结构正在悄悄变形。
结语
《HyperAgents》最值得记住的一句话，不是“我们做出了一个会自我进化的系统”，而是它背后透露出的那个更大的趋势：Agent 竞争，正在从“谁更会完成任务”，转向“谁更会系统化地改进自己”。
这是一个很大的变化。
因为会做任务，意味着它只是一个执行器；会改进自己，意味着它开始变成一个能够沉淀经验、重构方法、逐步塑造自身能力边界的系统。前者决定的是今天能干什么，后者决定的是明天会长成什么样。
所以如果要用一句更尖锐的话概括这篇论文，我会这么说：Agent 的下一场战争，不是能力调用的战争，而是自我演化机制的战争。
而《HyperAgents》做的，就是把这场战争的轮廓，第一次比较清楚地画了出来。
