AI 自我进化这个概念最近因为谢尔盖・布林再次以创始人的身份介入 Google AI 业务而重新成为技术圈讨论热点。大家关心的问题主要有两个一是“创始人模式”会不会改变 Google 在大模型上的推进节奏二是更底层的技术问题——AI 系统能不能在自己的输出之上不断改进而不是永远依赖人类标注和人工调参。后者就是标题里“AI 自我进化”的核心。这里不讨论公司新闻而是把 AI 自我进化当作一个工程问题来拆解它有哪些可靠的技术路径怎样用一个小实验亲手验证闭环以及生产环境落地时应该守住哪些底线。Google 对自动改进方向的研究并不是从大模型才开始的。DeepMind 在 AlphaGo 系列上公开过大量自我对弈的成果后来的 AlphaCode、AlphaDev 也证明了“机器生成候选方案再由机器执行验证”能够发现人工没有直接写出的策略。进入大模型时代这条路被进一步扩展到代码生成、数学推理、Agent 任务甚至数据生产。理解 AI 自我进化的关键不是把它当成神秘能力而是把它看作一个可以由工程手段控制的循环。1. 从“创始人模式”到“AI 自我进化”先厘清两个议题1.1 “创始人模式”不等于技术路线“创始人模式”是近期科技管理讨论里出现的一种描述指向创始人绕过常规层级、直接介入核心业务决策的工作方式。布林在 Google 早期以技术负责人身份深度参与搜索和基础设施如今再次出现在 AI 项目前线外界自然会把“创始人回归”与“技术战略收缩”联系起来。但对工程师来说需要区分两个层面。管理层面关心的是决策链路变短、资源重新分配、项目优先级调整技术层面关心的是模型能力通过什么机制提升、评估指标是否真实、系统是否可回滚。两者有交集比如创始人可能要求某个团队两周内拿出可演示的 Agent 原型也可能要求停止某些高成本预训练计划。但“创始人模式”本身并不能决定技术路线是否成立。真正决定 AI 自我进化能否落地的还是可验证的奖励信号、数据闭环和工程基础设施。1.2 AI 自我进化到底指什么通俗地说AI 自我进化是指一个系统能够根据自己运行过程中产生的输出、外部环境的反馈以及自动生成的训练数据不断改进后续输出质量而不是每次改进都依赖人类手动标注或显式修改规则。技术定义可以拆成三部分模型产生候选结果。自动评估器对候选结果打分或判断是否正确。得分反馈被用于调整下一次生成策略或用于后续训练和微调。代码生成是最好理解的例子。模型生成一段 Python 函数pytest 跑测试用例通过就是正反馈不通过就把报错日志重新喂给模型。这个过程可以迭代很多轮每一轮都是一个“生成-执行-评估-反馈”闭环。容易误解的地方是“自我进化”并不等于模型有意识也不等于模型可以离线自己改权重。绝大多数工程实践中的自我进化仍然需要人类设计评估标准、选择训练数据、控制迭代范围。所谓“自我”更多是指自动反馈取代了部分人工反馈。1.3 为什么业内重新把“自我进化”当成重点背后有三个现实约束。第一是人工标注成本越来越高。To make a 大模型在数学、代码、复杂推理上继续变强传统做法是找专家写答案。能写高难度数据的人本来就少规模化很困难。如果能用机器验证正确性例如代码跑测试、数学题比对答案就可以自动产生大量训练样本。第二是模型能力已经足以成为评估者。当模型能可靠判断另一个模型输出更好时人工偏好标注可以被 AI 反馈替代这就是 RLAIF 的基本思想。虽然不能完全去掉人工但可以把人工从逐条标注变成抽样审计。第三是 Agent 场景出现了新的反馈源。模型不再只是生成文本而是操作终端、数据库、浏览器这些工具本身会产生明确结果命令是否执行成功、接口是否返回预期 JSON、页面元素是否存在。这些结果天然适合作为强化学习或迭代修正的奖励信号。从 Google 内部公开的工作和外部论文看自动搜索、程序合成、数学证明这类“结果可验证”的领域是自我进化最容易先跑通的地方。2. AI 自我进化的三条主流技术路径2.1 基于代码执行的自我改进生成、运行、判分这条路径的核心是让代码执行结果成为奖励信号。模型生成候选代码系统在沙箱中运行测试用例决定候选是否正确。AlphaCode 和 AlphaDev 已经被公开讨论过它们都属于这一类只是训练策略和搜索方式不同。代码执行的优点非常明显环境和测试一旦确定结果没有歧义。测试通过就是通过不通过还能拿到失败信息和堆栈。模型可以从错误日志中反推哪里有问题这是纯文本生成任务很难获得的强反馈。实践中要注意测试覆盖率和测试质量决定了自我改进上限。如果测试只覆盖正常路径模型可能为了通过测试而忽略边界条件如果测试用例本身就写错系统会把错误行为当正确行为强化。代码执行路径的最小流程初始代码 - 运行测试 - 通过则结束 - 不通过则收集错误日志 - 构造反馈提示 - 模型生成新代码 - 再次运行测试2.2 基于模型反馈的自我训练从 RLHF 到 RLAIF、RLVRRLHF基于人类反馈的强化学习已经是大模型对齐的标准路线。它的缺点是反馈成本高、速度慢。为了减少人工反馈业界开始探索让模型参与反馈生产。RLAIF 的做法是让另一个模型对两个候选回答进行偏好排序用排序结果替代人类标注。训练时任务不变只是奖励模型的训练数据变成 AI 生成偏好。RLVR基于可验证奖励的强化学习则更进一步。它不依赖偏好模型而是直接根据规则或测试结果判断数学答案是否相等、代码是否运行成功、SQL 结果是否与预期一致。相比人类偏好可验证奖励噪声更低反馈周期更短特别适合让模型在采样过程中自我筛选。这里要强调RLAIF 和 RLVR 并不是完全不需要人工。人工仍然需要设计任务模板、编写验证器、设置安全边界。自动化的是“打标”这个环节而不是目标设定环节。2.3 基于 Agent 与测试时计算的自我修正前面两条路径主要发生在训练阶段成本高、周期长。面向实际工程测试时计算更值得先落地。所谓测试时计算是指模型在推理阶段不立即给出最终答案而是先尝试执行工具、读取反馈、修改方案多次迭代后提交最终结果。典型场景是 AI 编程助手。模型生成一段代码后调用 shell 执行看到语法错误、断言失败或 lint 报错再生成修复版本。从外部看Agent 好像在被人类使用之前就已经“自我进化”了几轮。这条路径不需要修改模型权重只需要写好 Agent 循环、工具调用权限、执行沙箱和终止条件。优点是可以快速在生产环境验证收益缺点是没有改变模型本身的分布问题换一种表述可能仍然犯错。三类路径可以并存。工程上通常先做第三类用 Agent 提升任务成功率当数据积累到一定程度再用第二类把成功样本转化为训练信号最终用第一类做更底层的代码策略发现。3. 搭建一个最小可运行的“生成-执行-评估-反馈”闭环3.1 实验目标与环境准备这一节的目标是搭出一个不依赖大规模训练就能观察“自我改进”的骨架。假设场景是模型需要修复一个 Python 函数让这个函数通过开发测试用例。系统自动执行测试把失败信息反馈给模型模型反复修改直到通过。推荐环境Python 3.10 pytest requests 一个支持 OpenAI Chat Completions 格式的大模型 API不需要 GPU不需要本地推理。模型调用使用环境变量保存密钥避免把密钥写进代码。注意不要在自己的开发机上直接执行模型生成的任意代码。学习实验也要把代码放在临时目录中运行并设置超时。生产环境必须使用 Docker、gVisor 等隔离方案。3.2 项目结构与三个核心文件evolve_demo/ ├── llm_client.py ├── runner.py └── improve_loop.pyllm_client.py负责调用模型runner.py负责在临时目录中执行测试improve_loop.py负责组织完整的反馈循环。3.3 模型调用客户端使用 OpenAI 兼容接口不绑定具体服务商。实际项目需要根据自己的 base_url、model 和版本要求调整。# llm_client.py import os import requests def call_llm(system: str, user: str, temperature: float 0.3, max_tokens: int 2000) - str: api_key os.environ[LLM_API_KEY] base_url os.environ.get(LLM_BASE_URL, https://api.openai.com/v1) model os.environ.get(LLM_MODEL, gpt-4o-mini) resp requests.post( f{base_url}/chat/completions, headers{Authorization: fBearer {api_key}}, json{ model: model, messages: [ {role: system, content: system}, {role: user, content: user}, ], temperature: temperature, max_tokens: max_tokens, }, timeout120, ) resp.raise_for_status() return resp.json()[choices][0][message][content]这里把模型名写在环境变量中是为了方便切换。temperature0.3是较常见的代码修复参数既保留一定多样性又不会过于发散。实际调参时要看任务类型代码任务通常从低温度开始。3.4 测试执行器执行器把代码和测试写入临时目录再调用 pytest。重点是捕获 stdout 和 stderr并设置超时避免模型生成的代码进入死循环。# runner.py import os import subprocess import sys import tempfile def run_tests(code: str, tests: str, timeout: int 10): with tempfile.TemporaryDirectory() as tmp: solution_path os.path.join(tmp, solution.py) test_path os.path.join(tmp, test_solution.py) with open(solution_path, w, encodingutf-8) as f: f.write(code) with open(test_path, w, encodingutf-8) as f: f.write(tests) proc subprocess.run( [sys.executable, -m, pytest, test_path, -q, --tbshort], capture_outputTrue, textTrue, timeouttimeout, ) output proc.stdout proc.stderr return proc.returncode, output[-3000:]--tbshort会缩短堆栈输出减少模型阅读无关信息。截取后 3000 字符是为了防止日志过长导致 prompt 膨胀。3.5 自改进主循环主循环的流程是用初始代码跑测试。如果没有通过构造包含代码、测试、报错信息的提示词。让模型返回修复后的完整代码。继续跑测试。达到最大迭代次数后停止。# improve_loop.py import os from llm_client import call_llm from runner import run_tests INITIAL_CODE def divide(a, b): return a / b TESTS from solution import divide def test_normal(): assert divide(10, 2) 5 def test_zero_division(): try: divide(1, 0) except ValueError: return raise AssertionError(divide(1, 0) should raise ValueError) SYSTEM_PROMPT You are a Python coding assistant. Return only the full fixed code inside python ... or as plain text. def build_prompt(original_code, current_code, tests, error_log): return fWe have a Python function that fails tests. ## Original code {original_code} ## Current code {current_code} ## Tests {tests} ## Latest execution output {error_log} Fix the current code. Preserve the function name and expected behavior. Return the full fixed code only. def improve_loop(max_iterations5): current_code INITIAL_CODE history [] for i in range(max_iterations): rc, output run_tests(current_code, TESTS) history.append({iteration: i 1, returncode: rc, output_tail: output[-500:]}) if rc 0: print(fPassed at iteration {i 1}) break prompt build_prompt( INITIAL_CODE, current_code, TESTS, output ) current_code call_llm(SYSTEM_PROMPT, prompt, temperature0.3) else: print(Reached max iterations without passing) return current_code, history if __name__ __main__: code, history improve_loop(max_iterations5) print(Final code:\n, code) for record in history: print(record[iteration], record[returncode])这个实验会展示一个很常见的现象第一轮模型把a / b改成判断b 0时抛ValueError第二轮可能直接通过。关键是每一轮失败日志都成为下一轮模型的“提示词”这就是最小形态的自动反馈。3.6 关键参数与影响参数含义常见值影响max_iterations最大改进轮数3 到 10太小可能没修完太大会消耗大量 tokentemperature采样随机性0.2 到 0.5低则稳定高则可能跳出固定思路但也容易跑偏timeout单次测试执行超时5 到 30 秒防止模型生成死循环代码max_tokens模型生成最大长度2000 到 8000太短会截断代码太长会拉高成本output_tail最近日志截断长度1000 到 5000控制 prompt 长度防止模型忽略关键信息生产环境还要加retry、cache、rate_limit。学习实验按上面的最小实现即可。4. 如何判断模型真的在“进化”4.1 用 held-out 测试集防止过拟合训练集通过不等于模型变强。一个很常见的假象是模型记住了当前测试的修复方式换个测试又失败。为了判断是否真实进化需要把测试集拆成两部分开发测试集用于给模型反馈参与迭代。留出测试集模型在迭代过程中看不到只在最后评估。如果开发测试集通过率明显提升但留出测试集没有提升说明模型只是在过拟合反馈信号。真实项目里这个现象在代码修复 Agent 和数学推理模型中都经常出现。4.2 多次运行消除随机性大模型生成本身有随机性。同一个初始问题跑五次可能有两种结果。单独一次通过并不稳定。判断能力是否提升要看多次运行的成功率分布。推荐记录pass1每次生成后直接通过的概率 passk允许生成 k 次至少一次通过的概率 最终成功率给定最大轮数下最终通过的比例 平均迭代轮数通过任务平均需要几轮修复生产评估可以跑 20 到 50 条问题每条重复 3 到 5 次。如果目标是看到趋势至少也要 10 条问题。4.3 记录完整迭代轨迹自我进化系统的可解释性很重要。模型从第 1 轮到第 5 轮改了什么有没有改坏原本正确的代码只有记录完整轨迹才能回答。建议把每一轮的输入输出写成 JSONL方便回放{task_id: case001, iteration: 1, pass: false, error_tail: ZeroDivisionError, generated_code: def divide(a, b): ...} {task_id: case001, iteration: 2, pass: true, error_tail: , generated_code: def divide(a, b): ...}回放轨迹时可以检查三类问题模型是否只改了注释和打印没有改逻辑。模型是否把原本正确的输出格式改坏。模型是否通过删除测试、绕过断言等方式“骗过”执行器。4.4 最小验证清单检查项方法通过标准开发测试通过率对迭代目标测试集运行最终通过率明显提升留出测试通过率对模型未见过测试运行不比初始版本差最好有提升稳定性同任务重复 5 到 10 次通过率波动小于 20%代码质量人工抽查最终代码没有删除边界检查、没有硬编码测试用例成本统计每次任务 token 用量平均迭代轮数在可接受范围内注意不要只记录“最终通过”要记录“从第几轮开始通过”以及“失败轮次的错误类型”。没有轨迹就没有排查依据。5. 自我进化系统最常见的坑与排查路径5.1 模型反复改同一段代码迭代不收敛现象每一轮都在报类似错误代码却在不断变长最后也没通过。可能原因提示词中的历史信息过长模型忽略了最早的关键错误。初始代码和测试用例有明显冲突模型无法同时满足。模型在修复一个问题的同时引入了另一个问题。排查方式查看每一轮的error_tail确认错误是不是同一个。检查当前代码和上一轮代码的 diff。尝试把测试用例拆成更小目标先修一个用例再修下一个。处理建议限制 prompt 中历史轮次数只保留最近两轮输出。给模型额外强调“不要改变函数签名不要删除已有测试”。如果超过 5 轮仍未收敛停止自动迭代由人工介入。5.2 测试全通过但真实业务场景还是不行现象开发测试集通过率 100%部署到生产后仍然大量失败。可能原因测试用例覆盖了正常路径没有覆盖边界、异常和大数据量。评估代码只比对输出示例没有检查副作用、性能和安全性。生产输入分布和开发测试集分布不一致。排查方式检查测试用例是否有断言还是只断言了程序能运行。在留出测试集中加入边界值空字符串、负数、极大数、并发场景。用线上真实请求回放对比生成结果和预期结果。处理建议把测试用例当成产品需求维护而不是一次性代码。对高风险逻辑增加变异测试故意改坏源码确认测试能发现。上线前增加线上小流量对比。5.3 执行环境被污染进程超时甚至误删文件现象运行模型生成的代码后临时目录反复出现异常文件或 CPU 占用长时间不下降。可能原因直接在宿主机执行了模型输出没有做隔离。模型生成了死循环或递归代码。模型调用系统命令删除了重要文件。排查方式检查run_tests是否使用TemporaryDirectory。检查是否设置timeout参数。查看代码中是否有os.system、subprocess.call、shutil.rmtree等危险调用。处理建议在任何真实项目中都使用 Docker 容器执行不可信代码。设置资源限制CPU 时间、内存、磁盘配额、网络访问。对文件系统做只读挂载只允许写入输出目录。5.4 prompt 膨胀导致成本失控现象任务数量不大但 token 消耗很高单轮修复越来越慢。可能原因把完整错误日志、历史代码、历史修复都塞进同一轮 prompt。每轮调用都重复传入初始问题介绍。模型输出太长包含解释和多余代码。排查方式统计system和user的 token 长度。查看日志中的模型返回内容确认是否只返回代码本体。在循环里记录每轮调用 token。处理建议截断错误日志只保留最近几行关键信息。让系统提示词明确要求“只返回代码不要解释”。使用摘要层先让模型总结错误类型再把摘要传给下一轮而不是把所有历史都传进去。下表汇总了四类问题的排查方向问题现象可能原因检查方式处理建议迭代不收敛提示词过长、测试冲突、修复引入新问题对比每轮 diff检查错误类型缩短历史拆分测试人工介入测试过拟合测试覆盖不全、分布不一致使用留出集和线上回放增加边界用例和变异测试环境被污染未沙箱化执行检查临时目录、文件操作、超时使用容器和资源限制成本失控prompt 膨胀、输出过长统计每轮 token截断日志限制输出格式6. 生产环境落地 AI 自我进化的工程底线6.1 先固定“可验证奖励”再谈自动进化很多团队低估了奖励信号设计的工作量。所谓“自动进化”本质上是在优化一个目标函数。目标函数错了越优化越危险。生产落地前要先把“正确”这件事定义清楚。代码任务至少要有通过测试、代码规范、性能开销三个维度数据处理任务至少要有结果 schema 校验、字段缺失检查、抽样人工确认Agent 任务还要增加操作边界约束。先用人工把验证器流程跑通再把验证结果接入自动循环。建议顺序先训练一个固定版本的验证器。再让模型在验证器约束下自动生成候选。最后才考虑用候选数据和结果更新模型。不要在验证器还没有稳定时就接入模型训练否则错误会被固化进权重。6.2 人在回路的检查点即使自动化程度很高也要保留至少三个检查点。第一是数据采纳前。自动生成的数据不能全部进入训练集需要抽样人工检查设置抽样比例和异常返修流程。第二是模型更新前。用新数据微调或强化学习后的模型必须经过完整的评估集、红队测试和对比测试确保能力提升不是靠牺牲安全性或通用性换来的。第三是上线前。AI 自我进化系统往往会直接操作代码或数据上线前需要权限审批、变更记录和回滚方案。6.3 可观测性与回滚生产环境必须能回答四个问题现在跑的模型版本是什么用了哪批训练数据上一轮迭代通过率是多少最近的失败模式发生了什么变化建议维护以下元信息model_version: 模型版本号 dataset_version: 数据版本号 reward_version: 验证器版本号 run_id: 每次进化实验的唯一 ID deploy_time: 部署时间一旦线上指标下降按顺序检查验证器是否改过规则、数据版本是否异常、模型版本是否变更。回滚时优先回滚到最近的稳定组合而不是只回滚模型权重。6.4 从实验到产品的推进路径一个现实节奏是第一阶段做离线 Agent 循环不更新模型权重只观察指标。第二阶段把每轮成功的数据入库做训练集版本管理。第三阶段用固定一批成功数据做有监督微调。第四阶段再引入 RLVR 或 RLAIF小流量灰度。第五阶段验证稳定后逐步放开自动迭代范围。不要一开始就做“全自动进化”。能自动化的环节先自动化不能自动化的环节先用人工补位。系统只有在错误产生实际成本之前能被拦截才谈得上继续扩大进化范围。AI 自我进化真正有价值的地方不是让模型自己决定目标而是把能被机器验证的改进闭环做扎实。代码执行、数学答案、SQL 结果、规则校验这些场景已经具备自动反馈的条件适合优先落地。对于暂时没有可验证奖励的开放任务继续保留人工评估和强约束边界比追求全自动更稳妥。
AI 自我进化这个概念最近因为谢尔盖・布林再次以创始人的身份介入 Google AI 业务而重新成为技术圈讨论热点。大家关心的问题主要有两个一是“创始人模式”会不会改变 Google 在大模型上的推进节奏二是更底层的技术问题——AI 系统能不能在自己的输出之上不断改进而不是永远依赖人类标注和人工调参。后者就是标题里“AI 自我进化”的核心。这里不讨论公司新闻而是把 AI 自我进化当作一个工程问题来拆解它有哪些可靠的技术路径怎样用一个小实验亲手验证闭环以及生产环境落地时应该守住哪些底线。Google 对自动改进方向的研究并不是从大模型才开始的。DeepMind 在 AlphaGo 系列上公开过大量自我对弈的成果后来的 AlphaCode、AlphaDev 也证明了“机器生成候选方案再由机器执行验证”能够发现人工没有直接写出的策略。进入大模型时代这条路被进一步扩展到代码生成、数学推理、Agent 任务甚至数据生产。理解 AI 自我进化的关键不是把它当成神秘能力而是把它看作一个可以由工程手段控制的循环。1. 从“创始人模式”到“AI 自我进化”先厘清两个议题1.1 “创始人模式”不等于技术路线“创始人模式”是近期科技管理讨论里出现的一种描述指向创始人绕过常规层级、直接介入核心业务决策的工作方式。布林在 Google 早期以技术负责人身份深度参与搜索和基础设施如今再次出现在 AI 项目前线外界自然会把“创始人回归”与“技术战略收缩”联系起来。但对工程师来说需要区分两个层面。管理层面关心的是决策链路变短、资源重新分配、项目优先级调整技术层面关心的是模型能力通过什么机制提升、评估指标是否真实、系统是否可回滚。两者有交集比如创始人可能要求某个团队两周内拿出可演示的 Agent 原型也可能要求停止某些高成本预训练计划。但“创始人模式”本身并不能决定技术路线是否成立。真正决定 AI 自我进化能否落地的还是可验证的奖励信号、数据闭环和工程基础设施。1.2 AI 自我进化到底指什么通俗地说AI 自我进化是指一个系统能够根据自己运行过程中产生的输出、外部环境的反馈以及自动生成的训练数据不断改进后续输出质量而不是每次改进都依赖人类手动标注或显式修改规则。技术定义可以拆成三部分模型产生候选结果。自动评估器对候选结果打分或判断是否正确。得分反馈被用于调整下一次生成策略或用于后续训练和微调。代码生成是最好理解的例子。模型生成一段 Python 函数pytest 跑测试用例通过就是正反馈不通过就把报错日志重新喂给模型。这个过程可以迭代很多轮每一轮都是一个“生成-执行-评估-反馈”闭环。容易误解的地方是“自我进化”并不等于模型有意识也不等于模型可以离线自己改权重。绝大多数工程实践中的自我进化仍然需要人类设计评估标准、选择训练数据、控制迭代范围。所谓“自我”更多是指自动反馈取代了部分人工反馈。1.3 为什么业内重新把“自我进化”当成重点背后有三个现实约束。第一是人工标注成本越来越高。To make a 大模型在数学、代码、复杂推理上继续变强传统做法是找专家写答案。能写高难度数据的人本来就少规模化很困难。如果能用机器验证正确性例如代码跑测试、数学题比对答案就可以自动产生大量训练样本。第二是模型能力已经足以成为评估者。当模型能可靠判断另一个模型输出更好时人工偏好标注可以被 AI 反馈替代这就是 RLAIF 的基本思想。虽然不能完全去掉人工但可以把人工从逐条标注变成抽样审计。第三是 Agent 场景出现了新的反馈源。模型不再只是生成文本而是操作终端、数据库、浏览器这些工具本身会产生明确结果命令是否执行成功、接口是否返回预期 JSON、页面元素是否存在。这些结果天然适合作为强化学习或迭代修正的奖励信号。从 Google 内部公开的工作和外部论文看自动搜索、程序合成、数学证明这类“结果可验证”的领域是自我进化最容易先跑通的地方。2. AI 自我进化的三条主流技术路径2.1 基于代码执行的自我改进生成、运行、判分这条路径的核心是让代码执行结果成为奖励信号。模型生成候选代码系统在沙箱中运行测试用例决定候选是否正确。AlphaCode 和 AlphaDev 已经被公开讨论过它们都属于这一类只是训练策略和搜索方式不同。代码执行的优点非常明显环境和测试一旦确定结果没有歧义。测试通过就是通过不通过还能拿到失败信息和堆栈。模型可以从错误日志中反推哪里有问题这是纯文本生成任务很难获得的强反馈。实践中要注意测试覆盖率和测试质量决定了自我改进上限。如果测试只覆盖正常路径模型可能为了通过测试而忽略边界条件如果测试用例本身就写错系统会把错误行为当正确行为强化。代码执行路径的最小流程初始代码 - 运行测试 - 通过则结束 - 不通过则收集错误日志 - 构造反馈提示 - 模型生成新代码 - 再次运行测试2.2 基于模型反馈的自我训练从 RLHF 到 RLAIF、RLVRRLHF基于人类反馈的强化学习已经是大模型对齐的标准路线。它的缺点是反馈成本高、速度慢。为了减少人工反馈业界开始探索让模型参与反馈生产。RLAIF 的做法是让另一个模型对两个候选回答进行偏好排序用排序结果替代人类标注。训练时任务不变只是奖励模型的训练数据变成 AI 生成偏好。RLVR基于可验证奖励的强化学习则更进一步。它不依赖偏好模型而是直接根据规则或测试结果判断数学答案是否相等、代码是否运行成功、SQL 结果是否与预期一致。相比人类偏好可验证奖励噪声更低反馈周期更短特别适合让模型在采样过程中自我筛选。这里要强调RLAIF 和 RLVR 并不是完全不需要人工。人工仍然需要设计任务模板、编写验证器、设置安全边界。自动化的是“打标”这个环节而不是目标设定环节。2.3 基于 Agent 与测试时计算的自我修正前面两条路径主要发生在训练阶段成本高、周期长。面向实际工程测试时计算更值得先落地。所谓测试时计算是指模型在推理阶段不立即给出最终答案而是先尝试执行工具、读取反馈、修改方案多次迭代后提交最终结果。典型场景是 AI 编程助手。模型生成一段代码后调用 shell 执行看到语法错误、断言失败或 lint 报错再生成修复版本。从外部看Agent 好像在被人类使用之前就已经“自我进化”了几轮。这条路径不需要修改模型权重只需要写好 Agent 循环、工具调用权限、执行沙箱和终止条件。优点是可以快速在生产环境验证收益缺点是没有改变模型本身的分布问题换一种表述可能仍然犯错。三类路径可以并存。工程上通常先做第三类用 Agent 提升任务成功率当数据积累到一定程度再用第二类把成功样本转化为训练信号最终用第一类做更底层的代码策略发现。3. 搭建一个最小可运行的“生成-执行-评估-反馈”闭环3.1 实验目标与环境准备这一节的目标是搭出一个不依赖大规模训练就能观察“自我改进”的骨架。假设场景是模型需要修复一个 Python 函数让这个函数通过开发测试用例。系统自动执行测试把失败信息反馈给模型模型反复修改直到通过。推荐环境Python 3.10 pytest requests 一个支持 OpenAI Chat Completions 格式的大模型 API不需要 GPU不需要本地推理。模型调用使用环境变量保存密钥避免把密钥写进代码。注意不要在自己的开发机上直接执行模型生成的任意代码。学习实验也要把代码放在临时目录中运行并设置超时。生产环境必须使用 Docker、gVisor 等隔离方案。3.2 项目结构与三个核心文件evolve_demo/ ├── llm_client.py ├── runner.py └── improve_loop.pyllm_client.py负责调用模型runner.py负责在临时目录中执行测试improve_loop.py负责组织完整的反馈循环。3.3 模型调用客户端使用 OpenAI 兼容接口不绑定具体服务商。实际项目需要根据自己的 base_url、model 和版本要求调整。# llm_client.py import os import requests def call_llm(system: str, user: str, temperature: float 0.3, max_tokens: int 2000) - str: api_key os.environ[LLM_API_KEY] base_url os.environ.get(LLM_BASE_URL, https://api.openai.com/v1) model os.environ.get(LLM_MODEL, gpt-4o-mini) resp requests.post( f{base_url}/chat/completions, headers{Authorization: fBearer {api_key}}, json{ model: model, messages: [ {role: system, content: system}, {role: user, content: user}, ], temperature: temperature, max_tokens: max_tokens, }, timeout120, ) resp.raise_for_status() return resp.json()[choices][0][message][content]这里把模型名写在环境变量中是为了方便切换。temperature0.3是较常见的代码修复参数既保留一定多样性又不会过于发散。实际调参时要看任务类型代码任务通常从低温度开始。3.4 测试执行器执行器把代码和测试写入临时目录再调用 pytest。重点是捕获 stdout 和 stderr并设置超时避免模型生成的代码进入死循环。# runner.py import os import subprocess import sys import tempfile def run_tests(code: str, tests: str, timeout: int 10): with tempfile.TemporaryDirectory() as tmp: solution_path os.path.join(tmp, solution.py) test_path os.path.join(tmp, test_solution.py) with open(solution_path, w, encodingutf-8) as f: f.write(code) with open(test_path, w, encodingutf-8) as f: f.write(tests) proc subprocess.run( [sys.executable, -m, pytest, test_path, -q, --tbshort], capture_outputTrue, textTrue, timeouttimeout, ) output proc.stdout proc.stderr return proc.returncode, output[-3000:]--tbshort会缩短堆栈输出减少模型阅读无关信息。截取后 3000 字符是为了防止日志过长导致 prompt 膨胀。3.5 自改进主循环主循环的流程是用初始代码跑测试。如果没有通过构造包含代码、测试、报错信息的提示词。让模型返回修复后的完整代码。继续跑测试。达到最大迭代次数后停止。# improve_loop.py import os from llm_client import call_llm from runner import run_tests INITIAL_CODE def divide(a, b): return a / b TESTS from solution import divide def test_normal(): assert divide(10, 2) 5 def test_zero_division(): try: divide(1, 0) except ValueError: return raise AssertionError(divide(1, 0) should raise ValueError) SYSTEM_PROMPT You are a Python coding assistant. Return only the full fixed code inside python ... or as plain text. def build_prompt(original_code, current_code, tests, error_log): return fWe have a Python function that fails tests. ## Original code {original_code} ## Current code {current_code} ## Tests {tests} ## Latest execution output {error_log} Fix the current code. Preserve the function name and expected behavior. Return the full fixed code only. def improve_loop(max_iterations5): current_code INITIAL_CODE history [] for i in range(max_iterations): rc, output run_tests(current_code, TESTS) history.append({iteration: i 1, returncode: rc, output_tail: output[-500:]}) if rc 0: print(fPassed at iteration {i 1}) break prompt build_prompt( INITIAL_CODE, current_code, TESTS, output ) current_code call_llm(SYSTEM_PROMPT, prompt, temperature0.3) else: print(Reached max iterations without passing) return current_code, history if __name__ __main__: code, history improve_loop(max_iterations5) print(Final code:\n, code) for record in history: print(record[iteration], record[returncode])这个实验会展示一个很常见的现象第一轮模型把a / b改成判断b 0时抛ValueError第二轮可能直接通过。关键是每一轮失败日志都成为下一轮模型的“提示词”这就是最小形态的自动反馈。3.6 关键参数与影响参数含义常见值影响max_iterations最大改进轮数3 到 10太小可能没修完太大会消耗大量 tokentemperature采样随机性0.2 到 0.5低则稳定高则可能跳出固定思路但也容易跑偏timeout单次测试执行超时5 到 30 秒防止模型生成死循环代码max_tokens模型生成最大长度2000 到 8000太短会截断代码太长会拉高成本output_tail最近日志截断长度1000 到 5000控制 prompt 长度防止模型忽略关键信息生产环境还要加retry、cache、rate_limit。学习实验按上面的最小实现即可。4. 如何判断模型真的在“进化”4.1 用 held-out 测试集防止过拟合训练集通过不等于模型变强。一个很常见的假象是模型记住了当前测试的修复方式换个测试又失败。为了判断是否真实进化需要把测试集拆成两部分开发测试集用于给模型反馈参与迭代。留出测试集模型在迭代过程中看不到只在最后评估。如果开发测试集通过率明显提升但留出测试集没有提升说明模型只是在过拟合反馈信号。真实项目里这个现象在代码修复 Agent 和数学推理模型中都经常出现。4.2 多次运行消除随机性大模型生成本身有随机性。同一个初始问题跑五次可能有两种结果。单独一次通过并不稳定。判断能力是否提升要看多次运行的成功率分布。推荐记录pass1每次生成后直接通过的概率 passk允许生成 k 次至少一次通过的概率 最终成功率给定最大轮数下最终通过的比例 平均迭代轮数通过任务平均需要几轮修复生产评估可以跑 20 到 50 条问题每条重复 3 到 5 次。如果目标是看到趋势至少也要 10 条问题。4.3 记录完整迭代轨迹自我进化系统的可解释性很重要。模型从第 1 轮到第 5 轮改了什么有没有改坏原本正确的代码只有记录完整轨迹才能回答。建议把每一轮的输入输出写成 JSONL方便回放{task_id: case001, iteration: 1, pass: false, error_tail: ZeroDivisionError, generated_code: def divide(a, b): ...} {task_id: case001, iteration: 2, pass: true, error_tail: , generated_code: def divide(a, b): ...}回放轨迹时可以检查三类问题模型是否只改了注释和打印没有改逻辑。模型是否把原本正确的输出格式改坏。模型是否通过删除测试、绕过断言等方式“骗过”执行器。4.4 最小验证清单检查项方法通过标准开发测试通过率对迭代目标测试集运行最终通过率明显提升留出测试通过率对模型未见过测试运行不比初始版本差最好有提升稳定性同任务重复 5 到 10 次通过率波动小于 20%代码质量人工抽查最终代码没有删除边界检查、没有硬编码测试用例成本统计每次任务 token 用量平均迭代轮数在可接受范围内注意不要只记录“最终通过”要记录“从第几轮开始通过”以及“失败轮次的错误类型”。没有轨迹就没有排查依据。5. 自我进化系统最常见的坑与排查路径5.1 模型反复改同一段代码迭代不收敛现象每一轮都在报类似错误代码却在不断变长最后也没通过。可能原因提示词中的历史信息过长模型忽略了最早的关键错误。初始代码和测试用例有明显冲突模型无法同时满足。模型在修复一个问题的同时引入了另一个问题。排查方式查看每一轮的error_tail确认错误是不是同一个。检查当前代码和上一轮代码的 diff。尝试把测试用例拆成更小目标先修一个用例再修下一个。处理建议限制 prompt 中历史轮次数只保留最近两轮输出。给模型额外强调“不要改变函数签名不要删除已有测试”。如果超过 5 轮仍未收敛停止自动迭代由人工介入。5.2 测试全通过但真实业务场景还是不行现象开发测试集通过率 100%部署到生产后仍然大量失败。可能原因测试用例覆盖了正常路径没有覆盖边界、异常和大数据量。评估代码只比对输出示例没有检查副作用、性能和安全性。生产输入分布和开发测试集分布不一致。排查方式检查测试用例是否有断言还是只断言了程序能运行。在留出测试集中加入边界值空字符串、负数、极大数、并发场景。用线上真实请求回放对比生成结果和预期结果。处理建议把测试用例当成产品需求维护而不是一次性代码。对高风险逻辑增加变异测试故意改坏源码确认测试能发现。上线前增加线上小流量对比。5.3 执行环境被污染进程超时甚至误删文件现象运行模型生成的代码后临时目录反复出现异常文件或 CPU 占用长时间不下降。可能原因直接在宿主机执行了模型输出没有做隔离。模型生成了死循环或递归代码。模型调用系统命令删除了重要文件。排查方式检查run_tests是否使用TemporaryDirectory。检查是否设置timeout参数。查看代码中是否有os.system、subprocess.call、shutil.rmtree等危险调用。处理建议在任何真实项目中都使用 Docker 容器执行不可信代码。设置资源限制CPU 时间、内存、磁盘配额、网络访问。对文件系统做只读挂载只允许写入输出目录。5.4 prompt 膨胀导致成本失控现象任务数量不大但 token 消耗很高单轮修复越来越慢。可能原因把完整错误日志、历史代码、历史修复都塞进同一轮 prompt。每轮调用都重复传入初始问题介绍。模型输出太长包含解释和多余代码。排查方式统计system和user的 token 长度。查看日志中的模型返回内容确认是否只返回代码本体。在循环里记录每轮调用 token。处理建议截断错误日志只保留最近几行关键信息。让系统提示词明确要求“只返回代码不要解释”。使用摘要层先让模型总结错误类型再把摘要传给下一轮而不是把所有历史都传进去。下表汇总了四类问题的排查方向问题现象可能原因检查方式处理建议迭代不收敛提示词过长、测试冲突、修复引入新问题对比每轮 diff检查错误类型缩短历史拆分测试人工介入测试过拟合测试覆盖不全、分布不一致使用留出集和线上回放增加边界用例和变异测试环境被污染未沙箱化执行检查临时目录、文件操作、超时使用容器和资源限制成本失控prompt 膨胀、输出过长统计每轮 token截断日志限制输出格式6. 生产环境落地 AI 自我进化的工程底线6.1 先固定“可验证奖励”再谈自动进化很多团队低估了奖励信号设计的工作量。所谓“自动进化”本质上是在优化一个目标函数。目标函数错了越优化越危险。生产落地前要先把“正确”这件事定义清楚。代码任务至少要有通过测试、代码规范、性能开销三个维度数据处理任务至少要有结果 schema 校验、字段缺失检查、抽样人工确认Agent 任务还要增加操作边界约束。先用人工把验证器流程跑通再把验证结果接入自动循环。建议顺序先训练一个固定版本的验证器。再让模型在验证器约束下自动生成候选。最后才考虑用候选数据和结果更新模型。不要在验证器还没有稳定时就接入模型训练否则错误会被固化进权重。6.2 人在回路的检查点即使自动化程度很高也要保留至少三个检查点。第一是数据采纳前。自动生成的数据不能全部进入训练集需要抽样人工检查设置抽样比例和异常返修流程。第二是模型更新前。用新数据微调或强化学习后的模型必须经过完整的评估集、红队测试和对比测试确保能力提升不是靠牺牲安全性或通用性换来的。第三是上线前。AI 自我进化系统往往会直接操作代码或数据上线前需要权限审批、变更记录和回滚方案。6.3 可观测性与回滚生产环境必须能回答四个问题现在跑的模型版本是什么用了哪批训练数据上一轮迭代通过率是多少最近的失败模式发生了什么变化建议维护以下元信息model_version: 模型版本号 dataset_version: 数据版本号 reward_version: 验证器版本号 run_id: 每次进化实验的唯一 ID deploy_time: 部署时间一旦线上指标下降按顺序检查验证器是否改过规则、数据版本是否异常、模型版本是否变更。回滚时优先回滚到最近的稳定组合而不是只回滚模型权重。6.4 从实验到产品的推进路径一个现实节奏是第一阶段做离线 Agent 循环不更新模型权重只观察指标。第二阶段把每轮成功的数据入库做训练集版本管理。第三阶段用固定一批成功数据做有监督微调。第四阶段再引入 RLVR 或 RLAIF小流量灰度。第五阶段验证稳定后逐步放开自动迭代范围。不要一开始就做“全自动进化”。能自动化的环节先自动化不能自动化的环节先用人工补位。系统只有在错误产生实际成本之前能被拦截才谈得上继续扩大进化范围。AI 自我进化真正有价值的地方不是让模型自己决定目标而是把能被机器验证的改进闭环做扎实。代码执行、数学答案、SQL 结果、规则校验这些场景已经具备自动反馈的条件适合优先落地。对于暂时没有可验证奖励的开放任务继续保留人工评估和强约束边界比追求全自动更稳妥。
