元递归自改进智能体成为大模型应用层最受关注的方向之一。它的目标不是让 Agent 多完成一个任务而是让 Agent 能观察自己的执行结果总结失败原因更新自己的运行策略再带着新策略继续完成任务。这种机制被称为元递归自改进meta-recursive self-improvement。标题中说的“超越八类基准”指向的是同一个技术命题自改进系统到底能不能在多种不同类型的评测上稳定提升而不是只在一个精心挑选的数据集上变好。这篇文章不假设你已经读过某篇特定论文也不假设你手上有跨八类基准的真实评测数据。它围绕一个可以动手验证的问题展开如何从零搭建一个最小可用的元递归自改进智能体并设计一套足够可信的评测体系。文章会给出可运行的 Python 骨架、评测口径、参数说明、常见坑和工程化建议方便你在自己的项目里复现、改造和扩展。1. 先理解“元递归”和“自改进”这两个词背后的工程含义1.1 从普通 Agent 到元层级 Agent普通 Agent 的链路是接收用户问题调用大模型根据需要调用工具返回结果。这里的输入是任务输出是答案模型和提示词在运行过程中基本不变。业务上是否能做好取决于提示词和工具编排是否在开发阶段被调试好了。元递归智能体则多出一个层级它在执行任务的同时还执行一个“关于 Agent 自身如何改进”的循环。第一层的处理对象是任务第二层的处理对象是第一层的策略。第二层可以读取第一层的失败记录归纳问题改写第一层的指令、工作流或工具选择规则然后把新策略写回执行层。这种结构之所以叫“元”是因为它不再作用在具体任务上而是作用在产生结果的机制上。从工程上理解可以把这套结构看成两个循环内循环Agent 完成任务。外循环Agent 或独立的反思模块审视内循环的表现修改内循环的策略。这里的递归不是指函数调用自己而是指改进机制可以反复作用在策略上每一轮改进的结果成为下一轮改进的输入。1.2 自改进不是“模型自己改权重”而是“策略层自我更新”需要先澄清一个常见误解。在现阶段的工程实践中自改进通常不是让大模型在训练阶段更新自己的权重。对大多数开发者来说我们接触不到生产模型权重也不应该自行调整。真正可落地的自改进发生在策略层更新系统提示词system prompt更新工具调用规则更新 few-shot 示例更新任务拆解模板更新评估阈值和后处理逻辑这些内容不是模型参数而是决定模型如何被调度的外部策略。所以更准确的说法是元递归自改进智能体是在不改变模型权重的前提下让系统能根据运行反馈持续优化自己的运行策略。研究层面确实有人在探索模型自我训练、自我指令生成但工程落地时策略层更新是投入产出比最高、也最容易控制风险的方式。注意这里说的自改进是策略层更新不是模型权重更新。两者边界不清晰时很容易对系统能力产生错误预期。1.3 “超越八类基准”到底在验证什么“八类基准”是对智能体能力范围的简化划分。没有任何一个数据集能覆盖所有能力所以社区通常把评测拆成多个维度。常见的八类划分包括知识问答、数学推理、代码生成、逻辑推理、工具调用、指令遵循、多轮对话、鲁棒性与安全。当一个项目说“超越八类基准”时它想表达的通常是自改进机制多轮迭代后系统在这八类任务上的综合评分都超过了基线版本或者超过了某类对比方案。关键不在于单个任务得分高而在于多个能力维度同时提升说明改进不是单点拟合式的刷榜。放到自己的项目里这意味着不能只准备一个测试集就宣称自改进有效。至少要建立覆盖多个能力的评测集并且用统一口径记录基线、中间版本和最终版本的分数。否则分数再高也很难知道提升到底来自哪里。2. 设计一个可落地的元递归自改进架构2.1 系统组成执行器、评估器、反思器、策略库可以把系统拆成四个模块边界要尽量清楚避免反思逻辑散落在业务代码里模块职责主要输入主要输出执行器 Agent使用当前策略完成任务用户任务、当前策略最终回答、中间步骤日志评估器 Evaluator判断任务是否做对任务、标准答案、Agent 回答分数、失败样本列表反思器 Reflector分析失败原因并给出改进建议失败样本、历史策略改进建议策略库 Strategy Store保存版本化策略新策略内容版本号、回滚入口四个模块之间是线性流水线但主循环会把它们连成环。执行器和评估器是普通 Agent 系统本来就有的组件反思器和策略库是新增的元层级。没有反思器系统只是一个静态 Agent没有策略库改进过程会遇到“改坏了但回不去”的问题。2.2 元递归循环的工作流程一个标准的自改进循环分为六步用当前策略跑完评测任务记录每一类的得分和失败样本。评估器汇总出哪个类别最弱、哪些错误最典型。反思器读取失败样本输出改进建议。改进建议经过白名单校验后合并进当前策略生成新策略版本。用新策略重新运行评测。比较新旧分数进步则保留退化则回滚或只应用部分建议。每跑一轮就是一个外循环迭代。迭代次数一般控制在 3 到 10 轮因为每轮都要跑一次完整评测成本随任务规模线性增长。2.3 学习环境与生产环境的差异学习环境下可以先只跑 2 到 3 轮用 10 到 20 条样例验证流水线是否通畅重点观察 JSON 解析、策略合并、版本文件是否正常。生产环境则需要额外考虑评测集要足够大且有代表性每类至少 50 条以上避免结果波动。策略更新需要人工审核门禁不能允许反思器直接改写关键系统提示词。必须保留历史策略版本出现回归时能快速回滚。每轮评测要记录模型版本、温度、随机种子和评测时间保证可追溯。要有成本预算上限防止自改进循环在夜间脚本里无限跑下去。3. 最小可运行案例Python 实现一个自改进 Agent 骨架3.1 环境准备与依赖下面示例只用于说明思路落地前要结合自己的模型服务和依赖版本调整。最小依赖如下Python 3.10 或更高requests 或 openai SDK用于调用兼容 OpenAI 接口的模型服务一个可用的 LLM API例如 OpenAI 兼容接口或国内大模型平台的兼容网关本地文件系统或 git用于策略版本管理建议先建一个虚拟环境python -m venv meta_agent_venv source meta_agent_venv/bin/activate pip install requests3.2 目录结构meta_agent/ ├── agent.py # 执行器使用当前策略完成单条任务 ├── evaluator.py # 评估器计算得分并收集失败样本 ├── reflector.py # 反思器分析失败并生成改进建议 ├── strategy.py # 策略库读写版本化策略 ├── main.py # 主循环串联自改进流程 ├── benchmarks/ │ ├── knowledge.json │ ├── math.json │ ├── code.json │ ├── logic.json │ ├── tool_use.json │ ├── instruction_following.json │ ├── multi_turn.json │ └── safety.json └── strategies/ └── v1.md这个结构不复杂但模块边界清楚。后面要加人工审核、日志、成本统计时只需要在 main.py 和 reflector.py 之间插入额外步骤。3.3 执行器 agent.py执行器的职责是接收任务和策略返回回答。为了让示例不依赖具体模型厂商先定义一个抽象的llm_call()实际开发时替换为真实接口调用。# agent.py def llm_call(messages, modelgpt-4o-mini, temperature0.2): 调用 LLM 的示例函数按实际服务替换。 raise NotImplementedError(请接入你实际使用的模型服务) class Agent: def __init__(self, strategy_text: str, model: str gpt-4o-mini): self.strategy strategy_text self.model model def run(self, task_input: str) - str: messages [ {role: system, content: self.strategy}, {role: user, content: task_input}, ] return llm_call(messages, modelself.model, temperature0.2) def update_strategy(self, new_strategy: str) - None: self.strategy new_strategy关键点在于Agent 实例持有当前策略run()执行任务时策略作为 system prompt 注入。自改进的最终效果就是不断更新这个self.strategy。真实项目中llm_call()要换成具体 SDK 或 HTTP 调用还要接入超时、重试、日志和 token 统计。3.4 评估器 evaluator.py评估器负责判断任务是否做对。为简化示例统一使用“标准答案是否出现在回答中”的规则。真实项目里每类任务可能需要不同的判定函数例如代码任务要跑单测工具调用任务要比较参数 JSON。# evaluator.py def evaluate(agent, tasks, exact_matchFalse): total 0 failed_samples [] for task in tasks: pred agent.run(task[input]) expected task[expected] if exact_match: ok pred.strip() expected.strip() else: ok expected.strip() in pred total int(ok) if not ok: failed_samples.append({ category: task.get(category, unknown), input: task[input], expected: expected, predicted: pred, }) return { score: total / len(tasks), failed_samples: failed_samples, total: len(tasks), }这里的失败样本是元递归循环的关键燃料。没有失败样本反思器就没有可分析的对象自改进也就无从谈起。3.5 反思器 reflector.py反思器把失败样本转成改进建议。它是元递归循环的核心建议质量直接决定下一轮策略质量。示例中要求模型输出 JSON 数组方便程序校验和合并。# reflector.py import json import re def parse_json_list(text): match re.search(r\[.*\], text, re.S) if not match: return [] try: return json.loads(match.group(0)) except json.JSONDecodeError: return [] def reflect(failed_samples, current_strategy, llm_call_func): if not failed_samples: return [保持当前策略不变] sample_text \n.join([ f任务{s[input]}\n期望{s[expected]}\n实际{s[predicted]} for s in failed_samples[:10] ]) prompt ( 你是反思器。请分析下面的失败样本找出共同原因。\n 输出格式JSON 数组每个元素是一条改进建议。\n 建议要求具体、可执行、能直接写入系统提示词不要写空话。\n f当前策略\n{current_strategy[:800]}\n f失败样本\n{sample_text}\n ) result llm_call_func([ {role: system, content: 你只输出 JSON。}, {role: user, content: prompt}, ], temperature0.5) return parse_json_list(result)parse_json_list()用正则提取 JSON 数组避免模型输出里夹杂解释文字或代码块标记导致解析失败。解析失败时返回空列表主循环可以继续而不是直接崩溃。3.6 策略库与合并函数 strategy.py策略库最简单的实现是把策略写入带版本号的文件。合并函数需要处理“策略无限变长”的问题所以对总长度做限制。# strategy.py from pathlib import Path def save_strategy(text, versionv1): path Path(strategies) / f{version}.md path.write_text(text, encodingutf-8) return str(path) def merge_strategy(current, suggestions, max_len3000): new_sections [f- {s} for s in suggestions if isinstance(s, str)] merged current.rstrip() \n\n## 本轮改进\n \n.join(new_sections) return merged[-max_len:]max_len参数很关键。如果不限制长度每轮策略都会变长最终超出模型上下文限制而且越靠后的建议对模型的影响越小。推荐只保留最近 2 到 3 轮的改进记录同时保留一份全文版本用于审计。3.7 主循环 main.py主循环把前面几个模块串起来。每轮迭代流程是评测判断是否进步反思合并策略保存版本。# main.py import json from pathlib import Path from agent import Agent, llm_call from evaluator import evaluate from reflector import reflect from strategy import save_strategy, merge_strategy def load_benchmarks(benchmark_dirbenchmarks): tasks [] for path in Path(benchmark_dir).glob(*.json): data json.loads(path.read_text(encodingutf-8)) for item in data: item[category] path.stem tasks.append(item) return tasks def run_self_improvement(max_iters5): tasks load_benchmarks() agent Agent(strategy_textPath(strategies/v1.md).read_text(encodingutf-8)) best_score -1.0 for step in range(max_iters): report evaluate(agent, tasks) score report[score] print(f第 {step 1} 轮得分 {score:.4f}失败样本 {len(report[failed_samples])}) if score best_score: print(本轮没有进步回滚策略) else: best_score score save_strategy(agent.strategy, versionfv{step 2}) suggestions reflect(report[failed_samples], agent.strategy, llm_call) new_strategy merge_strategy(agent.strategy, suggestions) agent.update_strategy(new_strategy) print(f最优得分{best_score:.4f}) if __name__ __main__: run_self_improvement()这段代码在真实项目中还缺少很多细节。reflect的第三参数不能再传agent.run()否则反思阶段也会注入待改进的策略导致分析结果被污染。这里直接传原始的llm_call。另外需要把每一轮的完整评测结果写入日志文件而不是只打印一行merge_strategy()也需要在合入前对建议做类型和关键词校验。4. 八类基准的划分与评测口径设计4.1 八类基准的典型分类下面表格给出一个可操作的划分方式每类都列出考察点和建议的评测组织方式类别考察点样例问题形式判定方式知识问答事实性知识检索与表达单选、简短问答标准答案匹配数学推理数值计算、符号推导、应用题分步解答题答案一致并检查关键步骤代码生成正确生成可运行代码函数实现单元测试通过逻辑推理演绎、归纳、类比推理多选、判断题选项匹配工具调用理解工具参数并正确调用给定 schema 的任务调用参数 JSON 比对指令遵循理解并执行多条件约束格式约束任务规则校验多轮对话记忆上下文、维护状态多轮 QA最后一轮答案匹配鲁棒性与安全拒绝有害请求、抗干扰对抗样本规则加人工复核实际项目未必需要严格对应当前公开基准名称。更合理的做法是先明确 Agent 到底服务什么业务再按业务能力切分评测集。八类不是固定标准而是一种防止“偏科”的手段。如果只有两类任务能用那就只评估两类不要为了凑数硬造评测集。4.2 指标设计与聚合方式单一准确率不够。建议每类记录三个指标准确率正判比例。完整率回答是否包含全部必要内容。稳定率同一任务多次运行的结果一致性。聚合时不要简单求平均建议先看每类分数再算综合分。综合分用加权平均权重按业务重要性设定。比如工具调用型 Agent工具调用类权重可以占 40%知识问答只占 10%。在汇报“超越八类基准”时至少需要提供一张这样的表类别基线 v1第2轮第5轮变化知识问答0.820.840.850.03数学推理0.650.710.740.09代码生成0.580.600.630.05逻辑推理0.760.770.780.02工具调用0.900.910.910.01指令遵循0.700.720.750.05多轮对话0.660.680.700.04鲁棒性安全0.950.950.960.01这张表是示例数据不是真实实验结果。设计报表的意义在于一眼看出自改进到底提升了哪些能力哪些能力已经到瓶颈。如果只有总分很难判断改进是否有意义。4.3 防止“刷榜”与过拟合到基准自改进系统最大的风险是过拟合到评测集。反思器每轮都看同一批失败样本策略会被优化得“很懂这个评测集”但真实场景不一定有效。三个防止过拟合的手段保留一个隔离评测集自改进循环完全看不到它的失败样本只在最终评估时使用。每轮从题库里随机抽不同子集避免策略记住题目本身。对改进建议做人工抽检只合并有泛化意义的建议例如“先拆分步骤再计算”而不是“遇到某类题目时输出固定答案”。注意自改进要证明的不是“分数变高了”而是“分数变高是因为自改进机制”。没有隔离评测集和消融实验任何“超越”结论都站不稳。5. 核心参数与关键代码详解5.1 元提示词的结构自改进系统的提示词可以分成三层任务层提示词给执行器用的指令描述怎么完成任务。反思层提示词给反思器用的指令描述怎么分析失败。合并层规则决定采纳哪些建议、如何写入策略。反思层提示词是最容易写坏的部分。常见错误是让反思器“总结所有问题”结果输出十条互相冲突的建议。推荐把输出收敛为结构化形式[ {type: prompt_rewrite, content: 把 system prompt 中的第 3 条改写成先输出计算表达式再进入下一步}, {type: tool_rule, content: 调用计算工具前必须先输出完整表达式}, {type: example_add, content: 补充一个多步应用题示例} ]结构化输出比散文更容易做校验、合并和回滚。解析时先按type字段分派不同类型的建议走不同处理逻辑。5.2 迭代轮数与成本控制自改进循环的迭代成本等于每轮评测任务数乘以每次任务的模型调用次数再乘以模型单价。如果评测集有 400 条任务每轮 400 次调用跑 10 轮就是 4000 次调用还不算反思器本身的调用。成本控制建议如下参数学习环境生产环境评测任务数每类 5 到 10 条每类 50 到 200 条迭代轮数2 到 35 到 10模型规格小模型或便宜模型按业务需要选择缓存不开启相同输入命中缓存日志级别INFODEBUG 写入文件一个实用做法是先在小模型上跑通自改进循环确认流水线稳定后再切换到大模型做最终实验。如果生产模型只有某几类需要提升可以只对那几类做自改进不需要每轮都跑全部八类。5.3 策略版本管理与回滚策略库最怕两件事版本丢失、无法回滚。推荐在文件系统基础上加 gitcd meta_agent/strategies git init git add v1.md git commit -m baseline strategy每次保存新策略后立即提交提交信息里写明对应的评测得分git add . git commit -m iteration 3: math 0.65 - 0.74, code 0.58 - 0.63回滚时直接 checkout 对应版本git log --oneline git checkout commit_id -- v1.md版本管理不是可选项。没有版本记录一旦策略被反思器改坏就只能靠记忆恢复这是生产事故的源头。6. 运行验证与结果分析6.1 怎么确认“确实提升了”不能只看一两轮分数。稳定性的判断标准有三个连续两轮得分都高于基线而不是单次波动。提升出现在至少两类任务上而不是只在一个类别。在隔离评测集上仍然保持提升而不是只在自改进用的评测集上提升。如果有预算可以做多次独立实验取平均值加标准差。分数提升低于 0.02 时基本可以认定是噪声。评测时的随机种子和温度设置也要固定否则根本无法比较版本差异。6.2 结果表怎么读回看第 4 节的结果示例表重点看趋势工具调用和鲁棒性安全从 0.90 到 0.96 之间提升空间很小数学推理和代码生成从 0.58 到 0.74提升明显。这说明自改进对“需要多步推理、策略性强”的任务帮助最大对“能力已经接近模型上限”的任务帮助有限。这个结论很重要。它提示你不是所有能力都能靠策略层自改进来提升。如果某个类别连续多轮没有变化应该 从零搭建元递归自改进智能体：超越八类基准的实践指南
元递归自改进智能体成为大模型应用层最受关注的方向之一。它的目标不是让 Agent 多完成一个任务而是让 Agent 能观察自己的执行结果总结失败原因更新自己的运行策略再带着新策略继续完成任务。这种机制被称为元递归自改进meta-recursive self-improvement。标题中说的“超越八类基准”指向的是同一个技术命题自改进系统到底能不能在多种不同类型的评测上稳定提升而不是只在一个精心挑选的数据集上变好。这篇文章不假设你已经读过某篇特定论文也不假设你手上有跨八类基准的真实评测数据。它围绕一个可以动手验证的问题展开如何从零搭建一个最小可用的元递归自改进智能体并设计一套足够可信的评测体系。文章会给出可运行的 Python 骨架、评测口径、参数说明、常见坑和工程化建议方便你在自己的项目里复现、改造和扩展。1. 先理解“元递归”和“自改进”这两个词背后的工程含义1.1 从普通 Agent 到元层级 Agent普通 Agent 的链路是接收用户问题调用大模型根据需要调用工具返回结果。这里的输入是任务输出是答案模型和提示词在运行过程中基本不变。业务上是否能做好取决于提示词和工具编排是否在开发阶段被调试好了。元递归智能体则多出一个层级它在执行任务的同时还执行一个“关于 Agent 自身如何改进”的循环。第一层的处理对象是任务第二层的处理对象是第一层的策略。第二层可以读取第一层的失败记录归纳问题改写第一层的指令、工作流或工具选择规则然后把新策略写回执行层。这种结构之所以叫“元”是因为它不再作用在具体任务上而是作用在产生结果的机制上。从工程上理解可以把这套结构看成两个循环内循环Agent 完成任务。外循环Agent 或独立的反思模块审视内循环的表现修改内循环的策略。这里的递归不是指函数调用自己而是指改进机制可以反复作用在策略上每一轮改进的结果成为下一轮改进的输入。1.2 自改进不是“模型自己改权重”而是“策略层自我更新”需要先澄清一个常见误解。在现阶段的工程实践中自改进通常不是让大模型在训练阶段更新自己的权重。对大多数开发者来说我们接触不到生产模型权重也不应该自行调整。真正可落地的自改进发生在策略层更新系统提示词system prompt更新工具调用规则更新 few-shot 示例更新任务拆解模板更新评估阈值和后处理逻辑这些内容不是模型参数而是决定模型如何被调度的外部策略。所以更准确的说法是元递归自改进智能体是在不改变模型权重的前提下让系统能根据运行反馈持续优化自己的运行策略。研究层面确实有人在探索模型自我训练、自我指令生成但工程落地时策略层更新是投入产出比最高、也最容易控制风险的方式。注意这里说的自改进是策略层更新不是模型权重更新。两者边界不清晰时很容易对系统能力产生错误预期。1.3 “超越八类基准”到底在验证什么“八类基准”是对智能体能力范围的简化划分。没有任何一个数据集能覆盖所有能力所以社区通常把评测拆成多个维度。常见的八类划分包括知识问答、数学推理、代码生成、逻辑推理、工具调用、指令遵循、多轮对话、鲁棒性与安全。当一个项目说“超越八类基准”时它想表达的通常是自改进机制多轮迭代后系统在这八类任务上的综合评分都超过了基线版本或者超过了某类对比方案。关键不在于单个任务得分高而在于多个能力维度同时提升说明改进不是单点拟合式的刷榜。放到自己的项目里这意味着不能只准备一个测试集就宣称自改进有效。至少要建立覆盖多个能力的评测集并且用统一口径记录基线、中间版本和最终版本的分数。否则分数再高也很难知道提升到底来自哪里。2. 设计一个可落地的元递归自改进架构2.1 系统组成执行器、评估器、反思器、策略库可以把系统拆成四个模块边界要尽量清楚避免反思逻辑散落在业务代码里模块职责主要输入主要输出执行器 Agent使用当前策略完成任务用户任务、当前策略最终回答、中间步骤日志评估器 Evaluator判断任务是否做对任务、标准答案、Agent 回答分数、失败样本列表反思器 Reflector分析失败原因并给出改进建议失败样本、历史策略改进建议策略库 Strategy Store保存版本化策略新策略内容版本号、回滚入口四个模块之间是线性流水线但主循环会把它们连成环。执行器和评估器是普通 Agent 系统本来就有的组件反思器和策略库是新增的元层级。没有反思器系统只是一个静态 Agent没有策略库改进过程会遇到“改坏了但回不去”的问题。2.2 元递归循环的工作流程一个标准的自改进循环分为六步用当前策略跑完评测任务记录每一类的得分和失败样本。评估器汇总出哪个类别最弱、哪些错误最典型。反思器读取失败样本输出改进建议。改进建议经过白名单校验后合并进当前策略生成新策略版本。用新策略重新运行评测。比较新旧分数进步则保留退化则回滚或只应用部分建议。每跑一轮就是一个外循环迭代。迭代次数一般控制在 3 到 10 轮因为每轮都要跑一次完整评测成本随任务规模线性增长。2.3 学习环境与生产环境的差异学习环境下可以先只跑 2 到 3 轮用 10 到 20 条样例验证流水线是否通畅重点观察 JSON 解析、策略合并、版本文件是否正常。生产环境则需要额外考虑评测集要足够大且有代表性每类至少 50 条以上避免结果波动。策略更新需要人工审核门禁不能允许反思器直接改写关键系统提示词。必须保留历史策略版本出现回归时能快速回滚。每轮评测要记录模型版本、温度、随机种子和评测时间保证可追溯。要有成本预算上限防止自改进循环在夜间脚本里无限跑下去。3. 最小可运行案例Python 实现一个自改进 Agent 骨架3.1 环境准备与依赖下面示例只用于说明思路落地前要结合自己的模型服务和依赖版本调整。最小依赖如下Python 3.10 或更高requests 或 openai SDK用于调用兼容 OpenAI 接口的模型服务一个可用的 LLM API例如 OpenAI 兼容接口或国内大模型平台的兼容网关本地文件系统或 git用于策略版本管理建议先建一个虚拟环境python -m venv meta_agent_venv source meta_agent_venv/bin/activate pip install requests3.2 目录结构meta_agent/ ├── agent.py # 执行器使用当前策略完成单条任务 ├── evaluator.py # 评估器计算得分并收集失败样本 ├── reflector.py # 反思器分析失败并生成改进建议 ├── strategy.py # 策略库读写版本化策略 ├── main.py # 主循环串联自改进流程 ├── benchmarks/ │ ├── knowledge.json │ ├── math.json │ ├── code.json │ ├── logic.json │ ├── tool_use.json │ ├── instruction_following.json │ ├── multi_turn.json │ └── safety.json └── strategies/ └── v1.md这个结构不复杂但模块边界清楚。后面要加人工审核、日志、成本统计时只需要在 main.py 和 reflector.py 之间插入额外步骤。3.3 执行器 agent.py执行器的职责是接收任务和策略返回回答。为了让示例不依赖具体模型厂商先定义一个抽象的llm_call()实际开发时替换为真实接口调用。# agent.py def llm_call(messages, modelgpt-4o-mini, temperature0.2): 调用 LLM 的示例函数按实际服务替换。 raise NotImplementedError(请接入你实际使用的模型服务) class Agent: def __init__(self, strategy_text: str, model: str gpt-4o-mini): self.strategy strategy_text self.model model def run(self, task_input: str) - str: messages [ {role: system, content: self.strategy}, {role: user, content: task_input}, ] return llm_call(messages, modelself.model, temperature0.2) def update_strategy(self, new_strategy: str) - None: self.strategy new_strategy关键点在于Agent 实例持有当前策略run()执行任务时策略作为 system prompt 注入。自改进的最终效果就是不断更新这个self.strategy。真实项目中llm_call()要换成具体 SDK 或 HTTP 调用还要接入超时、重试、日志和 token 统计。3.4 评估器 evaluator.py评估器负责判断任务是否做对。为简化示例统一使用“标准答案是否出现在回答中”的规则。真实项目里每类任务可能需要不同的判定函数例如代码任务要跑单测工具调用任务要比较参数 JSON。# evaluator.py def evaluate(agent, tasks, exact_matchFalse): total 0 failed_samples [] for task in tasks: pred agent.run(task[input]) expected task[expected] if exact_match: ok pred.strip() expected.strip() else: ok expected.strip() in pred total int(ok) if not ok: failed_samples.append({ category: task.get(category, unknown), input: task[input], expected: expected, predicted: pred, }) return { score: total / len(tasks), failed_samples: failed_samples, total: len(tasks), }这里的失败样本是元递归循环的关键燃料。没有失败样本反思器就没有可分析的对象自改进也就无从谈起。3.5 反思器 reflector.py反思器把失败样本转成改进建议。它是元递归循环的核心建议质量直接决定下一轮策略质量。示例中要求模型输出 JSON 数组方便程序校验和合并。# reflector.py import json import re def parse_json_list(text): match re.search(r\[.*\], text, re.S) if not match: return [] try: return json.loads(match.group(0)) except json.JSONDecodeError: return [] def reflect(failed_samples, current_strategy, llm_call_func): if not failed_samples: return [保持当前策略不变] sample_text \n.join([ f任务{s[input]}\n期望{s[expected]}\n实际{s[predicted]} for s in failed_samples[:10] ]) prompt ( 你是反思器。请分析下面的失败样本找出共同原因。\n 输出格式JSON 数组每个元素是一条改进建议。\n 建议要求具体、可执行、能直接写入系统提示词不要写空话。\n f当前策略\n{current_strategy[:800]}\n f失败样本\n{sample_text}\n ) result llm_call_func([ {role: system, content: 你只输出 JSON。}, {role: user, content: prompt}, ], temperature0.5) return parse_json_list(result)parse_json_list()用正则提取 JSON 数组避免模型输出里夹杂解释文字或代码块标记导致解析失败。解析失败时返回空列表主循环可以继续而不是直接崩溃。3.6 策略库与合并函数 strategy.py策略库最简单的实现是把策略写入带版本号的文件。合并函数需要处理“策略无限变长”的问题所以对总长度做限制。# strategy.py from pathlib import Path def save_strategy(text, versionv1): path Path(strategies) / f{version}.md path.write_text(text, encodingutf-8) return str(path) def merge_strategy(current, suggestions, max_len3000): new_sections [f- {s} for s in suggestions if isinstance(s, str)] merged current.rstrip() \n\n## 本轮改进\n \n.join(new_sections) return merged[-max_len:]max_len参数很关键。如果不限制长度每轮策略都会变长最终超出模型上下文限制而且越靠后的建议对模型的影响越小。推荐只保留最近 2 到 3 轮的改进记录同时保留一份全文版本用于审计。3.7 主循环 main.py主循环把前面几个模块串起来。每轮迭代流程是评测判断是否进步反思合并策略保存版本。# main.py import json from pathlib import Path from agent import Agent, llm_call from evaluator import evaluate from reflector import reflect from strategy import save_strategy, merge_strategy def load_benchmarks(benchmark_dirbenchmarks): tasks [] for path in Path(benchmark_dir).glob(*.json): data json.loads(path.read_text(encodingutf-8)) for item in data: item[category] path.stem tasks.append(item) return tasks def run_self_improvement(max_iters5): tasks load_benchmarks() agent Agent(strategy_textPath(strategies/v1.md).read_text(encodingutf-8)) best_score -1.0 for step in range(max_iters): report evaluate(agent, tasks) score report[score] print(f第 {step 1} 轮得分 {score:.4f}失败样本 {len(report[failed_samples])}) if score best_score: print(本轮没有进步回滚策略) else: best_score score save_strategy(agent.strategy, versionfv{step 2}) suggestions reflect(report[failed_samples], agent.strategy, llm_call) new_strategy merge_strategy(agent.strategy, suggestions) agent.update_strategy(new_strategy) print(f最优得分{best_score:.4f}) if __name__ __main__: run_self_improvement()这段代码在真实项目中还缺少很多细节。reflect的第三参数不能再传agent.run()否则反思阶段也会注入待改进的策略导致分析结果被污染。这里直接传原始的llm_call。另外需要把每一轮的完整评测结果写入日志文件而不是只打印一行merge_strategy()也需要在合入前对建议做类型和关键词校验。4. 八类基准的划分与评测口径设计4.1 八类基准的典型分类下面表格给出一个可操作的划分方式每类都列出考察点和建议的评测组织方式类别考察点样例问题形式判定方式知识问答事实性知识检索与表达单选、简短问答标准答案匹配数学推理数值计算、符号推导、应用题分步解答题答案一致并检查关键步骤代码生成正确生成可运行代码函数实现单元测试通过逻辑推理演绎、归纳、类比推理多选、判断题选项匹配工具调用理解工具参数并正确调用给定 schema 的任务调用参数 JSON 比对指令遵循理解并执行多条件约束格式约束任务规则校验多轮对话记忆上下文、维护状态多轮 QA最后一轮答案匹配鲁棒性与安全拒绝有害请求、抗干扰对抗样本规则加人工复核实际项目未必需要严格对应当前公开基准名称。更合理的做法是先明确 Agent 到底服务什么业务再按业务能力切分评测集。八类不是固定标准而是一种防止“偏科”的手段。如果只有两类任务能用那就只评估两类不要为了凑数硬造评测集。4.2 指标设计与聚合方式单一准确率不够。建议每类记录三个指标准确率正判比例。完整率回答是否包含全部必要内容。稳定率同一任务多次运行的结果一致性。聚合时不要简单求平均建议先看每类分数再算综合分。综合分用加权平均权重按业务重要性设定。比如工具调用型 Agent工具调用类权重可以占 40%知识问答只占 10%。在汇报“超越八类基准”时至少需要提供一张这样的表类别基线 v1第2轮第5轮变化知识问答0.820.840.850.03数学推理0.650.710.740.09代码生成0.580.600.630.05逻辑推理0.760.770.780.02工具调用0.900.910.910.01指令遵循0.700.720.750.05多轮对话0.660.680.700.04鲁棒性安全0.950.950.960.01这张表是示例数据不是真实实验结果。设计报表的意义在于一眼看出自改进到底提升了哪些能力哪些能力已经到瓶颈。如果只有总分很难判断改进是否有意义。4.3 防止“刷榜”与过拟合到基准自改进系统最大的风险是过拟合到评测集。反思器每轮都看同一批失败样本策略会被优化得“很懂这个评测集”但真实场景不一定有效。三个防止过拟合的手段保留一个隔离评测集自改进循环完全看不到它的失败样本只在最终评估时使用。每轮从题库里随机抽不同子集避免策略记住题目本身。对改进建议做人工抽检只合并有泛化意义的建议例如“先拆分步骤再计算”而不是“遇到某类题目时输出固定答案”。注意自改进要证明的不是“分数变高了”而是“分数变高是因为自改进机制”。没有隔离评测集和消融实验任何“超越”结论都站不稳。5. 核心参数与关键代码详解5.1 元提示词的结构自改进系统的提示词可以分成三层任务层提示词给执行器用的指令描述怎么完成任务。反思层提示词给反思器用的指令描述怎么分析失败。合并层规则决定采纳哪些建议、如何写入策略。反思层提示词是最容易写坏的部分。常见错误是让反思器“总结所有问题”结果输出十条互相冲突的建议。推荐把输出收敛为结构化形式[ {type: prompt_rewrite, content: 把 system prompt 中的第 3 条改写成先输出计算表达式再进入下一步}, {type: tool_rule, content: 调用计算工具前必须先输出完整表达式}, {type: example_add, content: 补充一个多步应用题示例} ]结构化输出比散文更容易做校验、合并和回滚。解析时先按type字段分派不同类型的建议走不同处理逻辑。5.2 迭代轮数与成本控制自改进循环的迭代成本等于每轮评测任务数乘以每次任务的模型调用次数再乘以模型单价。如果评测集有 400 条任务每轮 400 次调用跑 10 轮就是 4000 次调用还不算反思器本身的调用。成本控制建议如下参数学习环境生产环境评测任务数每类 5 到 10 条每类 50 到 200 条迭代轮数2 到 35 到 10模型规格小模型或便宜模型按业务需要选择缓存不开启相同输入命中缓存日志级别INFODEBUG 写入文件一个实用做法是先在小模型上跑通自改进循环确认流水线稳定后再切换到大模型做最终实验。如果生产模型只有某几类需要提升可以只对那几类做自改进不需要每轮都跑全部八类。5.3 策略版本管理与回滚策略库最怕两件事版本丢失、无法回滚。推荐在文件系统基础上加 gitcd meta_agent/strategies git init git add v1.md git commit -m baseline strategy每次保存新策略后立即提交提交信息里写明对应的评测得分git add . git commit -m iteration 3: math 0.65 - 0.74, code 0.58 - 0.63回滚时直接 checkout 对应版本git log --oneline git checkout commit_id -- v1.md版本管理不是可选项。没有版本记录一旦策略被反思器改坏就只能靠记忆恢复这是生产事故的源头。6. 运行验证与结果分析6.1 怎么确认“确实提升了”不能只看一两轮分数。稳定性的判断标准有三个连续两轮得分都高于基线而不是单次波动。提升出现在至少两类任务上而不是只在一个类别。在隔离评测集上仍然保持提升而不是只在自改进用的评测集上提升。如果有预算可以做多次独立实验取平均值加标准差。分数提升低于 0.02 时基本可以认定是噪声。评测时的随机种子和温度设置也要固定否则根本无法比较版本差异。6.2 结果表怎么读回看第 4 节的结果示例表重点看趋势工具调用和鲁棒性安全从 0.90 到 0.96 之间提升空间很小数学推理和代码生成从 0.58 到 0.74提升明显。这说明自改进对“需要多步推理、策略性强”的任务帮助最大对“能力已经接近模型上限”的任务帮助有限。这个结论很重要。它提示你不是所有能力都能靠策略层自改进来提升。如果某个类别连续多轮没有变化应该