★ FEATURED ARTICLE 最近老被人问一个问题AI 开始修改自己了吗直接给答案如果指的是模型权重目前绝大多数在线系统都不会让 AI 动自己的底层参数但如果把目光放到 AI Agent、AI 工作流、AI 编程助手这些真实战场AI 确实每天都在“改自己”——代码跑挂了自动改代码Prompt 效果不行自动换 Prompt多个 Agent 互相 review 之后再提交最终结果。这篇文章不聊科幻只讲工程所谓“自我修改”到底改在哪一层、有哪些能落地的玩法以及我实际给这套机制上了哪些保险。1. 自我修改这个说法先分清三个层面1.1 权重更新、行为更新和流程更新不是一回事很多人一听到“AI 修改自己”第一反应是模型在训练服务器里悄悄调整参数。这个想象目前基本不成立。权重更新需要训练数据、算力、评测和上线流程不是模型自己喊一句“我要更新权重”就能完成的。大多数团队也不会为了一次普通对话或代码生成任务就做在线训练。真正在发生的是行为层面和流程层面的“自改”。行为层面很好理解同一个模型输入输出没有改变但你把 system prompt 换了个写法或者给它接上一个代码执行工具它会因为外部反馈而修正上一次的答案。流程层面更外围也更实用把运行日志、测试结果、用户反馈重新喂给 AI让它在下一轮决策时调整策略。我日常说的“AI 会改自己”九成指的都是这两层。1.2 为什么 2025 年被反复提起核心原因是 Agent 架构普及了。以前 ChatGPT 式的产品是单轮对话答完就结束现在的 AI Agent 天然带着循环执行任务、观察结果、反思、再执行。这个“循环”让机器第一次真正能根据自身输出质量去调整后续行为所以旁观者看起来就像它在修改自己。行业里同期还发生了不少事。DeepSeek 之前公开过一个做法让模型先自动生成一批高质量推理轨迹再筛选出其中正确的数据用于后续训练。这本质上是一种“用自己产出喂自己”的闭环。再加上企业里 AI 工作流越铺越广工程师很容易就能搭出一个“AI 写完方案 - 另一个 AI 挑毛病 - 修改方案”的流水线“自己改自己”就不再是纸面概念而是每人电脑里都能跑起来的工程。1.3 把“规则内自改”和“失控自改”区分开网上标题越写越惊悚但工程上的自我修改通常是在严格边界内运行的。我给客户做方案时经常打一个比方这更像汽车的自适应巡航不是让汽车自己决定去哪座城市。系统规定好目标函数、终止条件、安全护栏AI 在圈子里反复试错。所以真正要回答的问题不是“AI 敢不敢改自己”而是“我们敢不敢给它画一个足够小的圈”。2. 目前实战里常用的六条“自我修改”路径2.1 提示词自反馈迭代这是门槛最低的一种。先写一版 Prompt拿去跑一个任务让另一个模型或同一个模型做“评审”指出哪里回答得不好再把评审意见拼回 Prompt重新执行。如此循环几轮输出的质量通常会明显提升。好处是不动模型、不动权重几分钟就能见效代价是每个任务要多消耗几倍 token。这种模式下评审 Prompt 的质量直接决定迭代质量。如果评审只会说“不错”那循环就是摆设如果评审过度苛刻又容易把原本正确的答案改歪。我一般要求评审输出三类信息错误点、改进建议、最终结论结论里必须有明确的 PASS 或 FAIL 字样方便程序判断。2.2 代码生成加测试反馈闭环这是目前实现“AI 自改”最扎实的场景因为代码对不对有客观标准测试用例。让模型先写一段代码自动执行单元测试失败就收集报错信息和断言结果把错误反馈给模型并要求重新生成。实测下来普通编码任务在三轮以内就有很高概率修到能通过测试。这个闭环之所以稳是因为反馈信号不是“我觉得”而是“程序真的跑挂了”。但这里有个隐藏的坑测试本身要写得足够准。反馈里如果只有“assert 失败”模型很难定位问题我会要求在异常信息里带上具体变量值、预期值和实际值这样模型才知道该改哪里。2.3 多 Agent 互相挑刺让一个 Agent 干活、另一个 Agent 审稿比“自己写自己评”更容易发现问题。原因是角色错开了生成者容易对自己的输出有路径依赖审查者因为没有参与创作反而能看到逻辑漏洞。现在主流的多 AI 协作框架基本都是这个套路区别只在于审查者的数量和审查维度。代价很明显token 消耗成倍上涨。一个简单文案任务生成加评审加修改成本可能变成原来的三倍。我的经验是只有在任务价值较高或出错代价较大的时候才启动多 Agent 互评日常琐事不值得这么折腾。2.4 RAG 知识库动态更新权重改不动那就改“知识来源”。很多团队的 AI 问答系统挂着 RAG外部文档、FAQ、向量库就是模型的记忆外挂。今天知识库里发现了过时信息直接更新文档和索引明天模型回答就跟着变了。这算是一种温和的自我修改不碰模型本身但模型对外表现出来的知识边界在不断变化。这种路径特别适合企业知识库、产品文档、客服问答这类场景。风险最大的是更新过程中向量检索质量抖动旧文档删了新文档还没来得及建索引这几天问答效果反而变差。落地时要给索引变更做灰度切换别一次性替换干净。2.5 AutoML 与超参数搜索这是更“学院派”的自我修改通过算法自动尝试不同的模型结构、超参数组合用验证集得分决定选哪一组配置。实践中常用于模型选型和训练阶段调参不太会在生产环境里频繁跑。它的本质目标是让算法自己寻找更好的参数而不是有人手工凭经验改。这类方案重成本高普通应用层项目一般用不上。如果你只是想要“让 AI 改改自己的配置”不妨把超参数选择这类任务交给 AutoML但要做好实验预算管理。2.6 工具调用纠错这是 Agent 最常见的“伪自改”形态。模型先估算一个结果发现不放心就调用计算器、搜索引擎、数据库或者代码执行器来确认然后根据返回结果修正自己的下一步动作。表面上看它在自我纠错实际上等于人类在桌上放了一把尺子AI 量过之后才敢写答案。这条思路的关键是给 Agent 提供可信的外部工具并明确工具响应的优先级高于模型记忆。如果工具本身返回错误数据那自我纠错就会变成自我误导。3. 实操搭建一个“会改自己”的最小闭环3.1 需要哪几个核心组件我给新同事演示时通常只搭一套最简单的回路生成器、评审器、修正器、终止条件再加一个日志记录器。生成器负责出答案评审器负责判断好坏修正器根据意见重写终止条件负责在“通过”或“超轮数”时结束。听起来复杂实际代码不超过一百行。3.2 一个可以直接跑的 Python 骨架下面是基于 OpenAI 风格接口的最小实现核心逻辑可以平移到任何兼容的模型服务上。import logging from openai import OpenAI logging.basicConfig(levellogging.INFO, format%(asctime)s | %(levelname)s | %(message)s) logger logging.getLogger(self-refine) client OpenAI() def call_model(messages, modelgpt-4o-mini, temperature0.4): resp client.chat.completions.create( modelmodel, messagesmessages, temperaturetemperature, ) return resp.choices[0].message.content def generate(task): return call_model([ {role: system, content: 你是一个严谨的工程师输出简洁可运行的代码。}, {role: user, content: task}, ]) def review(task, solution): feedback call_model([ {role: system, content: 你是严格评审指出错误并给出修改建议。如果答案已经正确只输出 PASS。}, {role: user, content: f任务{task}\n\n答案\n{solution}}, ]) return feedback def refine(task, feedback, solution): return call_model([ {role: system, content: 你是严谨的工程师根据评审意见重新修改答案。}, {role: user, content: f原任务{task}\n\n评审意见{feedback}\n\n原答案{solution}}, ]) def self_refine(task, max_rounds3): solution generate(task) for i in range(1, max_rounds 1): logger.info(第 %s 轮自我迭代开始, i) feedback review(task, solution) if PASS in feedback: logger.info(第 %s 轮通过结束, i) return solution, i logger.info(收到修改意见长度%s, len(feedback)) solution refine(task, feedback, solution) return solution, max_rounds if __name__ __main__: task 写一个 Python 函数输入若干个文件路径返回按文件大小排序后的路径列表。 result, rounds self_refine(task) print(最终结果, result) print(迭代轮数, rounds)这段代码的逻辑非常直接先生成答案再评审不通过就改改完再评。评审意见中只要出现“PASS”就结束。为什么这样设计因为字符串匹配足够简单可靠而“改成多轮对话判断”反而容易引入状态管理上的复杂度。temperature 设在 0.4 也是刻意的——太低了输出容易重复太高了容易在一次修改中偏离原题意。max_rounds 限制在三轮防止个别难题无限循环烧 token。注意这套骨架只是教学演示生产环境不要直接照搬。真实系统里至少还需要把 API Key 放到环境变量、对文件读写做白名单、把每轮往返记录下来。3.3 运行结果怎么读跑一轮之后日志里至少要有本轮是否通过、修改意见长度、最终轮数。如果任何任务第一轮就 PASS说明任务太简单或评审太宽松如果几乎每次都跑满三轮说明生成质量或评审质量有待优化。我建议拿 20 个已知标准答案的任务做基准先看平均通过轮数再看最终准确率否则很容易被单次成功案例误导。4. 能“改”但更要有刹车四道防线4.1 限制轮次与退出条件最容易被忽视的就是“终止条件”。很多演示 Demo 看起来神奇是因为演示者只跑了一遍真实系统里没有终止条件会跳进死循环。必须设置 max_rounds同时强化评审输出的 PASS 识别。还有一个实用技巧记录每一轮的输出长度如果连续两轮输出长度变化极小说明答案已经收敛继续改也不过是在原句子上打转可以直接停止。4.2 沙盒环境与权限控制自我修改本身不可怕可怕的是它拥有过大的权限。让 AI 修改代码之前先把它放进一个隔离的容器或虚拟机文件系统只读网络按需开放数据库只给最小权限。这就像用厨房里最锋利的那把刀一定要在专用砧板上切菜。很多生产事故不是模型“想坏”而是工具链权限开得太宽一次错误操作直接把生产文件覆盖了。4.3 人工审批闸门预算允许的情况下在自我修改链路末端加一道人工确认。AI 可以不停地提出修改方案但真正上线前必须由人点一下“确认”。这不是不信任 AI而是把责任边界划清楚。实验环境里可以全自动生产环境里一定要留人工闸门模型负责提效人类负责兜底。4.4 全链路审计日志我踩过最大的坑是AI 改了代码最终效果也确实变好了但没人说得清它到底改了什么。所以现在任何 AI 自改项目我都会在进入循环前生成一个 trace_id把初始输入、每一轮生成的答案、评审意见、final 版本全部落盘。审计字段至少包括这些字段说明trace_id本次任务的唯一标识task_hash输入任务的哈希便于批量对比round当前迭代轮数prompt_version使用的 Prompt 版本output_text本轮生成的完整输出review_text本轮评审返回的完整意见cost_tokens本轮消耗的 tokenpass_flag是否判定为通过有了这些记录后续排查问题、做效果回归、人工抽查都会容易得多。不要嫌日志多AI 自改变的其实就是不可预测性日志是唯一能对抗不可预测性的东西。4.5 常见翻车现场最典型的是“评审 Agent 过度苛刻”。如果评审者永远在挑错答案就会从一个正确版本被改成另一个正确但面目全非的版本改动成本直线上升。针对这个问题我在评审 Prompt 里增加了一条规则只指出会让答案变错或变差的问题纯风格偏好不写。另一个翻车场景是反馈太笼统。模型收到“你再想想”这种反馈基本等于没有反馈改不出来还要白白耗一轮 token。所以反馈必须具体错误在哪一行、违反了哪个约束、预期结果是什么。5. 怎么判断它“改对了”评估方法与实测记录5.1 先定成功标准再谈自我优化如果你问“AI 改自己以后到底变好了吗”但没有定义“好”那就没法回答。我习惯用一套简单指标衡量初始通过率、经过自我修改后的最终通过率、平均修改轮数、单任务 token 成本。举个例子我拿 30 道中等难度代码题做基准初始通过率 63%经过最多三轮自改后通过率到 91%平均轮数 1.8 轮但 token 成本涨了大约 2.7 倍。这个数据说明自改有效但边际收益在下降再往后加轮数不划算。5.2 LLM-as-judge 的用法与三个坑让模型评价模型很流行但坑也不少。第一评审模型如果和生成模型同源容易产生同质化偏见两边都顺着一个逻辑说话错误反而被内部消化掉。我通常要求评审用不同的 system prompt甚至换一个更强或更保守的模型。第二评审意见不稳定同样的答案换个说法可能给出不同结论。解决方法是给评审一个结构化模板错误清单、违反约束、修改建议、最终判定不允许自由发挥。第三评审有时候被长答案带偏只盯着一两个亮眼之处忽略整体缺陷。所以我会在评审任务里强调“公共边界错误优先”。5.3 实测经验不是越多轮越好我做了很多组对比实验结论很一致大多数任务第一轮修正确实能带来显著提升但从第三轮开始收益基本消失甚至出现“改坏”的情况。原因是模型进入过度拟合状态开始为了改而改把原来没问题的部分也动了。所以与其把 max_rounds 设成十轮不如把精力花在提高第一轮生成质量上。现在我在生产项目里的默认配置是两到三轮宁可多跑几个候选方案也不要让单个任务反复横跳。6. 我的几点工程体会回到标题那个问题AI 开始修改自己了吗我的答案是在规则划定的范围内它已经开始这么做了。它改的是输出行为、代码实现、知识内容、决策策略而不是模型权重本身它靠的是反馈循环、工具调用和评测机制而不是所谓的自我意识。这套东西之所以让人兴奋是因为工程上第一次出现了“机器根据自身执行结果反向调整”的可能它之所以需要冷静是因为反馈质量、终止条件和安全护栏决定了自改是财富还是灾难。我目前做项目时最坚持的一点是先给 AI 配一套可量化的“考试卷”再谈自我优化。没有基准、没有指标、没有审计就让它自己改自己本质上是把方向盘交给了一个看不见的优化目标。反过来一旦测试集、评估器、护栏和日志都齐了我反而很乐意放开循环——那种“上一秒还在报错下一秒模型自己把代码修到通过测试”的感觉确实只有亲手跑过的人才知道有多爽。
阅读完成 · 觉得有帮助？
