2026年4月2日 19:30分,来腾讯会议(限30人)了解如何用Openclaw构建企业AI生产力
免费POC, 零成本试错
AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


我要投稿

赛博龙虾:智能体的自我进化

发布日期:2026-03-31 16:19:05 浏览次数: 1542
作者:模安局

微信搜一搜,关注“模安局”

推荐语

智能体进化的未来:当AI不仅能完成任务,还能自我改进和演化,真正的智能革命才刚开始。

核心内容:
1. Agent赛道从"能力竞争"转向"自我改进"的关键转变
2. HyperAgents如何实现元层(meta agent)的可编辑性突破
3. 论文揭示的智能体进化新范式与潜在应用场景

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家

这两年,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》做的,就是把这场战争的轮廓,第一次比较清楚地画了出来。


53AI,企业落地大模型首选服务商

产品:场景落地咨询+大模型应用平台+行业解决方案

承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业

联系我们

售前咨询
186 6662 7370
预约演示
185 8882 0121

微信扫码

添加专属顾问

回到顶部

加载中...

扫码咨询