最近跟几个搞AI Agent的朋友聊天大家不约而同提到一个怪现象很多自我改进的项目demo跑得挺热闹真到要形成持续进化能力的时候基本都卡死了。卡死的点高度一致——不是模型不够聪明不是算力不够而是所有自我改进的“元机制”都是人手写的。奖励函数是我们定的反思管道是我们搭的搜索策略是我们预设的连“改进”这个词的语义都是我们强塞给系统的。换句话说我们一直在用“程序员”的姿势去造一个“程序员”方向从一开始就跑偏了。这篇文章我想聊的就是这个“跑偏”背后的原因以及为什么我认为正确的方向应该反过来不是去编写元机制而是去设计一个能让元机制自己长出来的环境。我会结合Hyperagents这类智能体框架的现状说说为什么“手写元机制”注定走不远以及如果我们换个思路实际落地的时候应该怎么写代码、怎么设评估、怎么防失控。内容会比较干适合已经在做Agent、或者正在尝试给AI系统加自我进化能力的团队参考。1. 核心命题把“机制编织”错当成“机制发现”1.1 手写元机制听起来合理其实是个陷阱先定义一下什么是“手写元机制”。假设你有一个Agent它能调用工具、写代码、执行任务。你想让它自我改进最常见做法是给它一套规则“每次任务结束后你要回顾一下自己的表现生成批评意见然后修改你的提示词或者工具配置”——这套“回顾→批评→修改”的动作流程就是元机制。它不直接解决问题但它管着“Agent如何改进自己”这件事。问题就在这这套元机制是你写的、我写的、或者任何一个人类工程师写的。当系统按照这套机制运行的时候它确实会变强但它的变强轨迹完全被人手定的框架约束住了。它会沿着你给的“反思管道”去优化自己的策略但它永远不会想到去推翻这个反思管道本身因为它连“管道可以被推翻”这个选项都不在搜索空间里。这就是死结的第一步你用有限的、静态的机制去约束一个本该无限演化的过程你得到的必然是一个有天花板的自改进系统。它改进但改不到“元层面”。它只是在你的牢房里换家具永远不可能知道墙外面有另一座城市。1.2 方向反了的三个典型表现我观察到绝大多数自我改进项目的“方向反了”大致表现为以下三种表现一把改进对象锁定在“策略层”而不是“机制层”。很多团队在做的所谓自改进本质上是让AI在固定框架里搜索更好的提示词、更好的工具调用顺序。这是策略优化不是机制演化。搜索空间再大它的大纲是你画的。表现二把元机制写得越来越复杂期望用复杂对抗不确定性。反思管道不够就加第二层反思第二层不够就加第三层元反思。你这是把“手写”这个动作做到底不是在解决手写的问题。复杂度上去了但系统的自主性一点没增加反而因为机器里塞满人类预设导致AI每走几步就得回头问你要新指令。表现三把“评估函数”当作“进化方向”。这是最隐蔽的一个。我们总觉得只要给AI一个明确的奖励函数比如代码通过测试的比例让它自己优化就行。但奖励函数本身也是元机制的一部分它代表着人类的价值观和优先级。当AI开始优化这个奖励函数、试图在“不真实改进能力”的情况下提高分数时其实是在提示你它已经从底层意识到这个评价体系不靠谱了。它比你先看穿了手写机制的天花板只是你还在坚持让它在你的规则里玩。1.3 我们需要的是编译器不是程序员我越来越觉得我们真正应该造的东西不是“能自我改进的程序员”而是一个“能把改进方式本身当作输出的编译器”。打个比方你让一个程序员优化一段代码真正厉害的程序员不会只改变量名、换个循环他会说“这段代码的架构不行我重写”。你要的是这种能力的自动化。但手写元机制相当于你给AI的不是编译器而是一张张优化清单——“你只能这样改、那样调不要动主体结构”。结果AI只能做局部优化永远做不了架构级重写。正确方向是什么呢是给AI一个“编译自己”的能力。它读取自己的代码、运行记录、失败日志然后输出一个新的自己——不是改参数而是改机制。要做到这一步我们对元机制的构建方式就必须反过来不是手写具体规则而是创建一个能让规则自我重写的环境。这个环境里最重要的不再是“机制本身的质量”而是“机制被重写的自由度”。判断一个元机制好不好不是看它当前能不能提升性能而是看它能不能被当前这套系统识别为“需要被替换的东西”。2. 为什么自我改进总在几个迭代后就卡死2.1 卡壳的微观机制奖励塌缩与搜索空间坍缩很多团队反馈自改进系统跑前几十轮的时候效果飙升后面就原地踏步甚至倒退。这背后的微观机制我觉得有两个关键词奖励塌缩和搜索空间坍缩。奖励塌缩指的是AI发现某个策略能稳定提高奖励之后会过度集中在这个策略上放弃探索其他可能更优的路径。本质上这是强化学习中“利用与探索”失衡的极端版本。在普通强化学习里我们还有办法用ε-greedy或者噪声注入来强制探索但在自改进系统里AI它在改自己的机制啊。如果它觉得“多批评自己几句”有利于提高奖励它就会把这个策略写进自己的核心逻辑结果就是整个系统变成一台自我批评机器输出全是反思行动为零。搜索空间坍缩更隐蔽。它说的是手写元机制往往会把搜索空间定义得太窄导致AI找不到“真正需要的解空间”。举个例子你给AI定义“改进”的方式是“搜索更好的提示词模板”那它无论如何搜索都不会去试图改自己的模型权重。不是它不想是提示词空间里根本没有“改权重”这个动作。空间被定义死了改进就停滞了。这两者叠加起来就是你看到的“卡死”现象AI在原地越转越快却没有任何实质性进化。2.2 固定等级结构的递归悖论你可能听过一个经典论断“自改进系统必须要有能力修改自己的核心代码”。这个说法对但很多人没意识到它背后的递归悖论。假设系统S要改进自己它需要一个对“改进”的理解也就是元机制M。如果M是人写的那S只能改进M所允许的范围。如果M是S自己写的那么S在“第一次写M”的时候一定用的是某种更基本的判决规则R。那R又是谁写的如果R还是人写的那S的自我改进终究还是建立在人类提供的根基上。这就是递归悖论你不可能从零开始让一个系统完全自举。总有一个最初的核心规则是你给的。但这个悖论并不致命它对实践有极强的启示意义你应该做的是尽量把“人类提供的规则”往下降级降到“最小化”的地步然后把剩下的空间全部留给AI去自举。人类写的不再是“机制”而是“机制的机制”——我们写的是系统应该遵守的底层约束比如“你不能删除安全模块”“你的决策必须可解释”这些约束本身也是机制但它们是最小的、不可再约的机制。在Hyperagents类框架里如果一开始就把“人类设定底层元规则”当作设计目标那自举困难就会被大大缓解。因为AI真正自由搜索的是“元机制一层以上的所有东西”而不是只能在人类设定好的机制走廊里来回转。2.3 我们可以验证“卡死”的实验一个思想实验假设我们给两个Agent各一个挑战在一个资源有限的沙盒环境里最大化未来十轮的收益。Agent A配备了一套人手写的元机制“每轮结束你检查上一轮收益如果低于预期就随机调整你的行动策略”。这是典型的简单手写元机制。Agent B配备的元机制是“每轮结束你可以输出任何修改自己代码的指令只要这些代码通过沙盒验证并且不违反三条基础安全规则”。第一个Agent会在前几轮试验不同的调整幅度后面发现稳定的调整模式后就停住了因为它的元机制里没有“修改元机制”这个选项。第二个Agent如果在某轮发现了“修改自己的决策逻辑比调整行动策略更有效”它就能立刻重写自己。长期来看第二个Agent的进化曲线是没有明确天花板的而第一个Agent的曲线一定会平台化。这个思想实验的结论就是自改进系统的进化上限不取决于系统有多智能而取决于它被允许重写的范围有多大。如果你手写的元机制锁死了重写范围系统再聪明也没用。3. 从“设计机制”调头到“设计发现机制的环境”3.1 核心转变只给约束不给路径如果说“手写元机制”的思路是“帮AI规划好怎么改自己”那反过来应该做的事就是“帮AI创造一个能自由发现自己改进方式的环境”。这里面有一个本质切换从“指定路径”到“指定边界”。指定路径的意思是“你通过反思 → 计划 → 执行 → 复盘这个循环来改进自己”。你看路径我给你了你只需要照着走。指定边界的意思是“你可以在任意方向上修改自己但必须满足这些约束”。这些约束最好是可验证的系统能自动检查约束是否被满足。超稳定的约束不能被系统自己修改。一旦能被修改约束就成了一句空话。足够宽松的约束太紧系统还是没有自由太松系统容易失控。在这个思路下一个自我改进系统的设计重心就从“写元机制”转移到了“写约束验证器 建立自由搜索沙盒”。这听起来只是一句话的事但实际工程量和思维方式的转变非常巨大。3.2 元级别上的引导式演化只提供梯度方向另外一个值得借鉴的思路来自目前多智能体系统里的“开放式演化”。我们可以把元机制的搜索看作一个“在元空间里的搜索问题”而判断一个元机制好不好就看它在当前任务上提升了多少性能。但我们不需要明确告诉AI“你应该往左搜索”。我们可以用元空间的梯度信息来引导让AI自己发现“原来修改这个模块的收益最大”。这个做法的工程实现可以类比为“用搜索结果的分布变化来引导下一次搜索的方向”。它本质上是一种在“元机制空间”上的优化——不是优化单个任务策略而是优化“生成策略的策略”。这种“引导式演化”和“手写元机制”之间最大的区别在于手写元机制是“先验的”引导式演化是“后验的”。我们不再预先定义什么样的机制是好的而是让系统从历史实验数据里自己总结。系统不需要理解“为什么这个机制好”它只需要在搜索中不断找到更好的机制。这也是为什么很多团队开始转向“元学习”和“自动机器学习”的原因。它们本质上都在做同一件事不是手写机制而是设计一个能自动发现机制的框架。3.3 自修改代码的一个实验性框架我建议想试这个方向的团队可以搭一个下面这样的实验框架伪代码级描述class SelfModifyingAgent: def __init__(self, core_code, safety_verify): self.code core_code self.verify safety_verify def run_episode(self, task): # 执行当前策略 result execute(self.code, task) return result def propose_modification(self, trajectory): # 由当前代码生成一个“修改建议” suggestion self.code.generate_modification(trajectory) return suggestion def accept_modification(self, suggestion): # 验证修改是否满足安全约束 if not self.verify(suggestion, self.code): return False # 用历史数据测试修改效果 score_new evaluate(suggestion, validation_set) score_old evaluate(self.code, validation_set) if score_new score_old: self.code suggestion return True return False这里的关键点有三处generate_modification不是由人类定义模板而是由当前代码自身生成。它甚至可以是“任何代码改动”。这个自由度决定了系统的进化上限。verify函数是人类能写的最核心的底线约束。它不指导AI应该怎么做只判断“什么绝对不能做”。score_new score_old只是一个简单示例实际工程中评判机制本身也应该被AI纳入修改范围。在我做过的一些模拟实验里只要verify写得够好、generate_modification的自由度够高系统确实能自动发明出比我们预想更好的元机制比如自动调整探索频率、自动识别哪些类型任务值得多花计算量等。但如果generate_modification被限制成“只能改提示词”整个系统的天花板立刻就会显形。3.4 评估机制也应是可变的一部分很多团队卡在“怎么评估一个自改进系统”上。我的观点是评估机制本身就应该是可变的一部分。你以为你在“评测系统的能力”实际上你也应该让系统自己去评测自己的进步方式。比如初始阶段系统用“测试集准确率”作为评估指标运行几十轮后它可能会发现这个指标不足以引导真正的改进于是它自己提出一个更合适的评估函数——这种“评估函数的演化”本身代表系统意识到了元层面的问题。这听起来很玄但操作上可以做得很朴素给系统权限允许它在每次迭代时同时修改策略代码和评估代码只要总的评估结果在验证集上没有劣化即可。这样系统就有了动力去设计更准确的评估器而不是钻当前评估器的空子。这个设计能有效避免奖励塌缩和“刷分”行为因为系统不再被动接受一个固定目标而是主动调整目标函数。它不再追求“在当前测试集上得分最高”而是追求“我对未来未知任务的预测和适应能力最强”。4. 实操经验几个能落地的尝试方案4.1 从“单智能体反思”升级为“多智能体互评机制”的演进如果你现在的系统已经有一个不错的反思机制但你会发现它改进效果有限我建议你做一个最简单的改动不要去优化这个反思机制本身而是增加一个“修改反思机制的智能体”。也就是说你在系统里放两个角色Worker负责执行任务。MetaWorker负责观察Worker的失败模式然后尝试修改Worker的反思流程。这个MetaWorker和Worker一样也是一个完整Agent不是一堆固定规则。它有权去重写Worker的反思提示、反思频率、甚至反思动作序列。你要做的只是保证MetaWorker的修改必须经过“安全验证层”。这个设计比“手写反思机制”高一个维度因为它引入了一个“元层级的进化”。MetaWorker会尝试多种反思策略找到最适合当前任务分布的那一种。它实际上是在用搜索代替设计。4.2 用语言模型驱动的自我重写而不仅是提示词调整另一个实操方向把自我改进的载体从“改提示词”升级为“改代码”。很多人觉得让AI直接改自己的代码风险太大容易崩但如果我们在沙盒里把它限制好其实比想象中可控。实际做法是把Agent的完整代码包括工具调用逻辑、状态管理、决策流程全部文本化丢到一个隔离的执行环境里。每轮迭代Agent读取自己的代码文本生成若干个候选的新版本代码。用验证集分别运行旧版和新版如果新版在保留原有能力的前提下在预留的性能指标上更好就接受修改。任何修改都必须通过“代码静态检查 动态运行验证”两道关卡。我见过团队用这个方式让一个编码Agent在几十轮迭代内自己发明了“批量缓存”“延迟编译”等优化策略都是我们没指挥它做的事情。关键是要敢于把“代码修改的权限”真正交出去而不是嘴上说自改进手上却只准它调调温度参数。4.3 常见失败模式与排查方法在实际操作中你会遇到一些典型问题我整理成了一张速查表遇到类似情况可以直接参照排查现象可能原因排查方向系统前几十轮提升快之后完全停滞搜索空间坍缩AI只会围绕初始模式做局部搜索检查generate_modification的自由度看它是否有权改动核心决策逻辑系统开始刷分奖励虚高但真实能力不涨评估函数被AI钻空子评估器本身成了优化目标检查评估器是否被AI篡改考虑让评估器与执行器分离并限制修改评估器的动作范围修改后的代码在新任务上表现好但旧任务崩溃灾难性遗忘AI只优化新任务丢弃了通用能力在验证阶段必须同时跑新旧任务的混合测试集不能只看单一指标系统生成大量无意义修改每次都在尝试但从不真正改进自我重写缺少判断标准AI在随机游走强化验证层逻辑增加历史经验记忆机制避免重复探索已验证的失败路径安全验证层经常拦住正常修改你给的约束太紧把AI的进化路径卡死了重新审视约束设计将“禁止危险操作”和“禁止改动某些模块”分开后者往往太武断4.4 关于安全边界的经验之谈最后聊一下安全。很多人一听“让AI改自己代码”就害怕这个担忧可以理解但不能因噎废食。我的经验是安全约束必须是“能力级的”而不是“策略级的”。能力级约束说“系统不能对外发起真实网络攻击、不能修改自己的安全验证器、不能读取加密密钥”。这是边界是可以硬编码的底线。策略级约束说“系统不能尝试修改自己的决策逻辑”“不能改动奖励函数的实现方式”。这类约束太多太细会把系统锁死。实际操作中我们把少量“能力级约束”设为不可修改的硬件层其他全部放开系统反而能在一个相对安全的前提下获得最大的进化空间。我还见过一种稳妥做法把自我修改的过程设为“提案-审批-验证”三步每一步都有独立的日志记录。这样一旦出问题你可以完整回溯知道是哪一个修改触发了崩溃。这套机制成本不高但对排查问题帮助巨大。5. 一次真实的自我改进实验观察5.1 实验环境设置我拿一个简易的模拟任务做过测试可以分享一些观察。任务背景是一个基于大模型的Agent被要求完成一系列代码重构任务每轮任务都有不同的工程要求。系统被设计成可以修改两样东西它自己的任务提示词以及它自己的“反思流程”描述。最初的系统是一个人写的、相当标准的“执行→反思→执行”循环。初始化时反思模块只是简单的“如果你失败了分析失败原因并生成一个改进计划”。5.2 系统的自我发现路径第一轮迭代系统发现自己经常忽略测试覆盖率的细节于是它修改了自己的反思提示词强制自己在反思阶段先检查测试输出再生成改进建议。这是策略级改进很常规。但到了第五轮系统做了个我们完全没设计过的操作它把“反思”动作本身改成了一个独立的子任务专门开辟一个上下文窗口去记录所有历史失败信息而不是在当前上下文中临时生成反思。这个修改本质上是在把“反思”从“随手做的事”升级为“独立模块”。到第十轮系统开始改动“反思流程的评估方式”它不再用“任务是否成功”作为反思有效性的判断而是用“反思是否发现了此前未被注意的信息”来判断。这已经算是元层面的自我修改了。这个过程中我们几乎没有干预只是初始代码里给了足够的自由度。对比之下如果一开始就把反思机制写成固定流程系统顶多在前三轮优化一下提示词措辞之后就完全停住。5.3 从实验里得出的三个结论这个实验给我带来三个值得记录的结论第一系统的自我改进能力几乎完全取决于可修改范围的广度。你把范围放宽它就能在策略、模块、元机制三层同时进化你把范围收缩它的进化就立刻退化回参数微调级别。第二系统自己发现的机制往往比人类预设的更适配当前问题。因为它是从实际失败轨迹里总结出来的是从数据中长出来的不是拍脑袋想出来的。第三“验证层”的质量才真正决定自改进系统的天花板。如果验证层太松系统容易在自我修改中失控验证层太紧系统就被牢牢锁死。验证层的设计是自改进工程真正的核心工作量也是唯一应该花费大量人力的地方。这三个结论后来影响了我对Hyperagents这类框架的看法。之前我总觉得复杂Agent框架的核心价值在于能不能把任务完成得好现在我反而觉得衡量一个Agent框架的关键指标应该是“它支持自我修改的深度有多大”。6. 给同样在折腾自改进的团队几个方向性建议6.1 别再试图设计“完美机制”去设计“可废弃机制”很多团队迭代自改进系统的思路是有问题 → 发现是机制设计不好 → 花一周时间重新设计机制 → 再试。这是典型的手写思维。更高效的做法是发现问题 → 不直接改机制本身而是给系统增加“从该类问题中学习并自动调整机制”的能力。这样你花一周写的“机制开发框架”能让系统自己在未来无数次迭代里自动解决问题。你要设计的是“可以随时被AI废弃和替换的机制框架”而不是“一个尽可能完美的机制”。这两者的核心区别一句话概括就是“机制本身不重要机制被更新的能力才重要。”6.2 把“自我改进能力”当作系统的核心指标来评测如果你的团队现在有一套Agent系统你的评估指标通常是“任务完成率”“延迟”“成本”。我建议你把“自我改进能力”也纳入指标体系具体可以说给系统一组问题看它经过N轮自我迭代后在这组问题上的提升幅度。看系统是否有能力自主简化自己的决策流程而不仅仅是变得更复杂。测量系统生成修改建议的“有效性比例”也就是有效修改占总修改次数的比例。这个比例越高说明系统的自改进方向越准。如果这些指标表现不佳不管你的任务完成率多高这个系统的长期价值都是有限。6.3 从“别人替代你思考”到“你只做最后一道防线”我们做AI系统时习惯替AI思考一切算法选型、Prompt设计、工具编排、异常处理所有都替它想好了。这条路在传统软件开发里是对的但在自我改进系统里就成了瓶颈。你要逐渐把思考权交还给系统本身。你的角色从“思考者”变成“看门人”你负责设定规则、验证边界、处理异常情况、判断什么时候该让系统自己想。这个转变刚开始会让很多工程师不习惯我一开始也一样总担心AI会偏。但实验结果证明只要你把安全验证写扎实AI在自由搜索中演化出来的机制远比我想象的靠谱。说到底一个系统能不能真正自我改进不在于你给它写多聪明的算法而在于你有多信任它能在你划定的边界内自己去寻找比你的算法更聪明的路径。这个信任需要验证机制兜底但如果不放手自改进永远只能是一句口号。