最近在做 AI Agent 项目时我遇到一个很典型的卡点模型单次生成的结果往往只是“看起来合理”细看之后总能发现逻辑漏洞、边界遗漏或者执行步骤不够具体。过去我们习惯的做法是人工把输出结果再贴回提示词手动让它“再改一版”改完再评评完再改。这个流程本身没有错但它完全依赖人工介入一个任务要来回好几轮而且这套经验到了下一个任务几乎无法复用。于是我开始尝试一个更“自动化”的思路让智能体自己评价自己的输出自己把改进意见再喂给自己循环往复直到结果收敛。这个设计在数学上很自然地可以写成 Meta^n也就是把“改进”这个操作递归地作用 n 次。本文会围绕这个思路从概念、原理、最小实现到完整工程示例逐一拆解并给出可以复制运行的 Python 代码和排错清单。无论你是刚开始接触智能体开发还是已经在用 Dify、Coze、LangChain 等平台搭过 Agent这篇文章都会对你有实际帮助。1. 背景与核心概念1.1 为什么需要“自我改进”传统的大模型调用方式是“单次问答式”用户给出 prompt模型给出 completion。这种模式对简单任务够用但面对复杂任务时一次生成的方案往往有三大问题。第一是覆盖不全。模型容易漏掉任务边界、异常分支和资源限制。第二是自洽性不足长篇输出容易前后矛盾。第三是缺少验证机制模型不会站在评审者角度重新审视自己。说白了单次生成没有“反思”环节就像写完代码不 review 一样出问题是必然的不出问题才是偶然。那为什么不能靠人反复改因为人肉迭代的效率太低而且不稳定。每个人对“好方案”的标准不同改两版和三版的人得到的质量也不同。更关键的是人工改进的经验很难沉淀成可复用的能力。如果能把“生成—评判—改进—再评判”这个闭环自动化等于把一位资深工程师 review 代码的能力注入到智能体的运行流程里。1.2 Meta^n 到底指的是什么Meta^n 这个写法直观上是数学里的函数幂记号。如果有一个算子 Meta它表示“对一段内容执行一次改进”那么 Meta(x) 表示对初始内容 x 改进一次Meta(Meta(x)) 表示在第一次改进结果的基础上再改进一次。连续作用 n 次就可以记为 Meta^n(x)。放在智能体语境里Meta 就是一个改进算子算法n 是递归改进的轮数。每一轮输入是上一轮的输出每一轮输出又作为下一轮输入这个过程在数据结构上就是典型的递归或迭代推进。需要注意Meta^n 不是某个官方框架或者固定 API它是一类设计思想的统称。你可以用纯 OpenAI API 实现也可以基于 LangChain、Dify、Coze 这类平台搭建。实现方式不同但核心都围绕三件事谁来做改进改进算子。怎么判断改得好不好评判算子。改到什么时候停终止条件。理解了这三件事Meta^n 就不再是一个神秘名词而是一套可落地的智能体自我改进架构。1.3 “递归”和“循环”在工程中的区别很多初学者会把“递归”理解成程序里函数调用自身。实际上在 Meta^n 的实现里我们通常会用循环去写因为每一轮的状态可以自然保存到变量和列表里。但从思想层面它仍然是递归当前状态的输出是下一轮状态的输入整个过程对“自己”的输出进行自我引用。工程上建议优先使用循环而不是函数递归原因是 Python 默认递归深度有限而且深递归容易导致调用栈溢出。更重要的是循环结构方便记录每一轮的中间结果便于日志回溯和断点恢复。如果你在文章或代码中看到“递归自我改进”它指的更多是“递归式思想”而程序落地时往往表现为“for 循环 历史记录”。2. 环境准备与实验框架2.1 开发环境本文示例以 Python 为主操作系统不限。建议环境如下Python 3.10 或更高版本。一个兼容 OpenAI 接口的大模型 API例如 OpenAI 官方接口或国内支持 OpenAI 格式的模型服务。需要能在命令行执行 Python 脚本。不需要非常高的机器配置因为所有计算都在模型 API 侧完成本地只负责组织 prompt 和解析结果。2.2 依赖安装需要安装两个核心依赖openai负责调用模型接口python-dotenv负责读取本地环境变量。pip install openai python-dotenv如果之后想加入 LangChain 风格的结构化输出还可以安装pip install langchain-core不过本文为了让大家看清原理尽量不引入太重的外层封装直接用 OpenAI SDK 写最小闭环。2.3 模型与 API 配置在项目根目录新建一个.env文件保存 API Key 和模型名称。OPENAI_API_KEYsk-你的密钥 OPENAI_BASE_URLhttps://api.openai.com/v1 OPENAI_MODELgpt-4o-mini如果你用的是国内兼容 OpenAI 格式的服务把OPENAI_BASE_URL改成服务商提供的地址即可。读取方式如下import os from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) model os.getenv(OPENAI_MODEL, gpt-4o-mini)这里需要注意不同模型对 JSON 输出的支持程度不同。gpt-4o-mini 和 gpt-4o 这类模型支持response_format{type: json_object}如果你的模型不支持就需要在 prompt 里强调“只输出 JSON不要输出多余内容”然后在代码里做容错解析。3. Meta^n 核心设计拆解3.1 改进算子Meta Operator改进算子是整个流程的引擎它的输入是原始任务、当前版本的内容以及上一轮的评判反馈输出是改进后的新版本同时最好附带一句“本轮的改动点说明”。在实际实现中改进算子通常只是一次精心构造的 LLM 调用。关键在于 prompt 设计要让模型明确自己是在“改进旧版本”而不是“重新生成一个回答”。避免模型输出和上一版本完全无关的内容。下面是最小化的改进算子设计思路你是一名严谨的方案评审专家。 当前任务{task} 当前版本{current} 上一轮评审意见{feedback} 请基于以上信息输出改进后的新版本。 要求 1. 保留上一轮中的合理内容 2. 修复上一轮中已经指出的问题 3. 不要重写一个无关方案 4. 直接输出改进后的完整内容不要解释。为什么要把“上一轮评审意见”也放进去因为如果没有反馈信息模型其实不知道要往哪个方向改结果就是每轮都在变但未必越变越好。把反馈作为输入等于让改进算子有了“问题清单”从而做针对性修改。3.2 评判算子Judge Operator评判算子是闭环的“方向盘”。它决定这一轮改进是合格、不合格还是已经达到了终止标准。评判算子要做三件事给当前版本打分比如 0 到 10 分。列出当前版本的主要问题。给出下一轮改进的具体建议。如果将评判结果也设计成结构化的 JSON后续程序处理会非常方便。例如{ score: 6.5, problems: [缺少异常处理, 步骤描述不够具体], suggestion: 补充超时重试机制并给出每一步的输入输出示例 }评判算子的质量直接决定整个 Meta^n 的上限。如果评判过于宽松模型可能两三轮就自认为完成了实际质量却不达标如果评判过于严苛则可能陷入无限改进。因此在工程实践中评判算子最好使用与改进算子不同的系统提示词甚至可以使用不同的模型避免同一模型自评自改带来的“自我感觉良好”偏差。3.3 终止条件设计递归改进必须设置终止条件否则就可能无限循环浪费 API 预算。常见的终止条件有四类终止条件说明适用场景最大轮数达到预设的 n 轮后强制停止所有场景最基础分数阈值评判分数达到预设值后停止质量要求明确的任务连续无提升连续两轮分数没有提高则停止防止无效迭代内容不再变化相邻轮次输出一致则停止内容稳定性要求高的任务实际项目里应该组合使用。比如“最大轮数为 5且同时满足分数不低于 8 或连续两轮无提升时停止”。3.4 改进轨迹记录每一轮改进后都应该把本轮结果记录下来至少包括轮次、内容、分数、反馈、修改说明、耗时和 Token 消耗。这些记录的价值在于便于追溯最终结果是从哪一轮演化而来的。如果最终结果不好可以回退到历史高分轮次。可以对比不同轮次之间的变化量判断是否收敛。我习惯用列表存储每一轮是一个数据类对象。如果未来要落地到生产环境还可以把记录写入本地 JSON 文件或数据库中。4. 最小闭环一次递归自我改进示例4.1 直接循环调用 LLM 的写法先来看一个最简单的闭环。这里不追求工程完整性只为了展示 Meta^n 的核心骨架。# meta_simple_demo.py import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) MODEL os.getenv(OPENAI_MODEL, gpt-4o-mini) def call_llm(prompt: str) - str: resp client.chat.completions.create( modelMODEL, messages[{role: user, content: prompt}], temperature0.7, ) return resp.choices[0].message.content.strip() def improve(task: str, current: str, feedback: str) - str: prompt f 你是一名方案改进专家。请基于旧版本和评审意见输出改进后的方案。 【原始任务】 {task} 【旧版本】 {current} 【评审意见】 {feedback} 【输出要求】 直接输出改进后的完整方案不要输出任何解释。 return call_llm(prompt) def judge(task: str, current: str) - dict: prompt f 你是一名方案评审专家。请为当前方案打分并给出改进建议。 【原始任务】 {task} 【当前方案】 {current} 【输出格式】 score: 0-10 之间的数字 problems: 用分号分隔的主要问题 feedback: 针对问题的改进建议 text call_llm(prompt) # 这里做了最简单解析实际项目建议让模型输出 JSON score 0.0 problems feedback for line in text.splitlines(): if line.startswith(score:): score float(line.replace(score:, ).strip()) elif line.startswith(problems:): problems line.replace(problems:, ).strip() elif line.startswith(feedback:): feedback line.replace(feedback:, ).strip() return {score: score, problems: problems, feedback: feedback} def run(task: str, initial: str, max_rounds: int 5, target_score: float 8.0): current initial history [] for i in range(1, max_rounds 1): print(f\n 第 {i} 轮 ) result judge(task, current) print(f当前评分{result[score]}) history.append({round: i, content: current, score: result[score]}) if result[score] target_score: print(已达到目标分数停止改进。) break current improve(task, current, result[feedback]) else: print(f已达最大轮数 {max_rounds}停止改进。) return current, history if __name__ __main__: task 为在线商城设计一套用户登录方案的步骤说明 initial 用户输入账号密码系统校验后登录成功。 final, history run(task, initial) print(\n 最终方案 ) print(final)这段代码把“评判—改进—再评判”的循环写出来了。虽然解析方式比较粗糙但它足够解释 Meta^n 的基本流程每一轮都会生成一个新的 current这个 current 再进入下一轮。4.2 运行结果分析正常运行时每一轮会输出当前评分。你会发现第一轮评分通常较低因为初始版本太简陋。改进算子拿到反馈后会补充细节后面几轮评分逐渐上升。当评分超过阈值或达到最大轮数时循环退出。这其实就是 Meta^n 的基本形态n 表示实际执行的轮数。假设第 3 轮评分达到 8.2 分那么 n 就等于 3最终结果就是 Meta^3(initial)。4.3 这个版本的局限性这个演示版本有三个明显问题。第一结果解析不稳定。用startswith文本解析要求模型严格按格式输出一旦模型输出顺序变化就会出错。第二没有记录改进算子给出的修改说明无法判断模型到底改了哪些点。第三没有对历史结果做比较可能出现评分先升后降但最终留下了较低分的版本。这些问题说明最小闭环只适合理解原理不适合直接放进项目。生产环境需要更严谨的数据结构和判断逻辑也就是下一章的增强版实现。5. 完整实战增强版 Meta^n 智能体5.1 项目结构为了演示更接近实际的写法我设计了一个增强版 MetaAgent。它的核心思路是用 Pydantic 或 dataclass 定义统一的数据结构。改进算子和评判算子都要求模型输出 JSON。每一轮自动记录改进轨迹。支持基于“分数阈值 最大轮数 连续无提升”的复合终止条件。项目结构如下meta_agent_demo/ ├── .env ├── meta_agent.py ├── run_demo.py └── requirements.txtrequirements.txt 内容openai1.0.0 python-dotenv1.0.05.2 实现 MetaAgent 核心类# meta_agent.py import json import os from dataclasses import dataclass, field from typing import List, Optional from dotenv import load_dotenv from openai import OpenAI load_dotenv() dataclass class MetaResult: 记录每一轮的改进结果。 round: int content: str score: float problems: str feedback: str change_reason: str model: str dataclass class MetaAgent: model: str field(default_factorylambda: os.getenv(OPENAI_MODEL, gpt-4o-mini)) max_rounds: int 5 target_score: float 8.0 no_improve_limit: int 2 temperature: float 0.7 def __post_init__(self): self.client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) self.history: List[MetaResult] [] def _chat_json(self, system: str, user: str) - dict: 调用模型并强制解析 JSON 返回。 resp self.client.chat.completions.create( modelself.model, temperatureself.temperature, response_format{type: json_object}, messages[ {role: system, content: system}, {role: user, content: user}, ], ) text resp.choices[0].message.content try: return json.loads(text) except json.JSONDecodeError as e: raise ValueError(f模型输出不是合法 JSON: {text}, 错误: {e}) def _judge(self, task: str, content: str) - dict: system 你是严格的方案评审专家。你只输出 JSON格式为{\score\: 数字, \problems\: \问题描述\, \feedback\: \改进建议\} user f 【原始任务】 {task} 【当前方案】 {content} 请评审当前方案并输出 JSON。 return self._chat_json(system, user) def _improve(self, task: str, current: str, feedback: str) - dict: system 你是方案改进专家。你只输出 JSON格式为{\content\: \改进后的完整方案\, \change_reason\: \本轮修改说明\} user f 【原始任务】 {task} 【当前方案】 {current} 【上一轮评审反馈】 {feedback} 请基于反馈输出改进后的完整方案并说明修改点。 return self._chat_json(system, user) def run(self, task: str, initial_content: str) - MetaResult: current initial_content no_improve_count 0 last_score -1.0 final_result: Optional[MetaResult] None for i in range(1, self.max_rounds 1): judge_data self._judge(task, current) score float(judge_data[score]) problems judge_data.get(problems, ) feedback judge_data.get(feedback, ) if score - last_score 0.1: no_improve_count 1 else: no_improve_count 0 print(f第 {i} 轮评分{score:.1f}连续未提升次数{no_improve_count}) if i self.max_rounds: improve_data self._improve(task, current, feedback) improved_content improve_data[content] change_reason improve_data[change_reason] else: improved_content current change_reason 达到最大轮数未继续改进。 result MetaResult( roundi, contentcurrent, scorescore, problemsproblems, feedbackfeedback, change_reasonchange_reason, modelself.model, ) self.history.append(result) final_result result if score self.target_score: print(已达到目标分数提前终止。) break if no_improve_count self.no_improve_limit: print(连续多轮未提升提前终止。) break current improved_content if final_result is None: raise RuntimeError(至少需要执行一轮请检查 max_rounds 配置。) return final_result这个类的设计有几个关键点。第一_chat_json强制要求模型输出 JSON并统一从这里走避免每个方法各自解析文本。第二history保存每一轮的完整状态方便后续分析。第三no_improve_limit用于检测长时间卡在同一个分数区间的情况防止无效消耗。需要说明的是response_format{type: json_object}需要模型支持结构化输出。如果你使用的是不支持该参数的模型可以把response_format去掉并在系统提示词中更严厉地强调 JSON 格式。5.3 实现任务运行脚本# run_demo.py from meta_agent import MetaAgent def main(): agent MetaAgent( modelgpt-4o-mini, max_rounds5, target_score8.0, no_improve_limit2, temperature0.7, ) task 为在线商城设计一套用户登录流程需要覆盖正常登录、密码错误、账号锁定和忘记密码四个场景。 initial 1. 用户输入账号密码。 2. 系统校验。 3. 登录成功或失败。 final_result agent.run(task, initial) print(\n 改进轨迹 ) for item in agent.history: print(f\n--- 第 {item.round} 轮 ---) print(f评分{item.score}) print(f内容{item.content}) print(f问题{item.problems}) print(f修改说明{item.change_reason}) print(\n 最终方案 ) print(final_result.content) if __name__ __main__: main()运行命令cd meta_agent_demo python run_demo.py5.4 运行与验证预期输出大致如下第 1 轮评分4.5连续未提升次数0 第 2 轮评分6.8连续未提升次数0 第 3 轮评分8.2连续未提升次数0 已达到目标分数提前终止。 改进轨迹 ... 最终方案 1. 用户输入账号密码。 2. 系统校验账号是否存在如果不存在则提示“账号不存在”。 3. 校验密码是否正确如果错误则提示剩余尝试次数。 4. 连续失败 5 次后锁定账号并提示通过邮箱找回。 5. 忘记密码时通过绑定手机或邮箱验证身份后重置。这里 n 的实际值会根据任务难度和模型表现变化。如果第一轮就达到了 8 分n 等于 1如果五轮都没上 8 分n 等于 5。这也符合 Meta^n 的定义n 不是预先写死的固定参数而是实际运行到终止时执行的轮数。6. 带记忆与成本控制的变体6.1 为什么需要控制上下文每一轮改进都会把“当前方案”和“评审反馈”拼进下一轮的 prompt。如果任务越来越复杂方案内容会越来越长十几轮下来上下文可能从几千 token 膨胀到几万 token。API 费用会迅速上升而且模型对长上下文的注意力也会下降反而影响改进质量。所以生产环境里的 Meta^n 不能无脑把全部历史都塞进 prompt必须做“记忆裁剪”。6.2 增加历史记忆摘要一个简单有效的做法是在进入第 i 轮时不再传第 i-2 轮之前的完整内容而是传“截至上一轮的修改摘要”。修改摘要可以由改进算子顺带生成也可以单独调用一次模型生成。在 MetaAgent 中可以增加一个字段memory每一轮改进后把新的修改说明追加进去同时限制历史长度def _build_compact_memory(self, history: List[MetaResult], window: int 2) - str: 将历史改进轨迹压缩为最近 window 轮的摘要。 recent history[-window:] if len(history) window else history if len(history) window: return lines [f第 {item.round} 轮修改说明{item.change_reason} for item in recent] return \n.join(lines)下一轮改进时把这段摘要作为“历史背景”传入 prompt而不是把历史完整方案全部拼进去。这样既保留了演进脉络又控制了 token 消耗。6.3 成本估算与轮次设置在调用 API 前我们可以估算单轮请求的平均 token 消耗。OpenAI 接口返回结果里包含usage字段可以获取 prompt_tokens 和 completion_tokens。做一个简单的累加统计就能知道每次任务的实际费用。# 在 _chat_json 中增加成本统计示例 usage resp.usage prompt_tokens usage.prompt_tokens if usage else 0 completion_tokens usage.completion_tokens if usage else 0 total_tokens prompt_tokens completion_tokens print(f本轮消耗 tokens{total_tokens})轮次设置方面建议普通任务从 3 到 5 轮开始尝试。不是轮数越多越好很多任务在 3 轮左右就会收敛。设置过大的 max_rounds一旦评判 prompt 设计不合理模型会陷入“为了改进而改进”的状态每一轮都在调整措辞但实际质量没有提升。7. 常见问题与排查思路在实现 Meta^n 智能体时我遇到过的坑基本可以汇总成下表。问题现象常见原因解决思路每一轮输出内容完全重写旧版本优点丢失改进 prompt 没有强调“保留原方案合理内容”在系统提示中加入“保留旧版本中合理的部分不要推倒重来”评分一直不变化循环到最大轮数评判 prompt 过于宽松或过于严苛检查评判标准必要时换更强的评判模型模型输出不是合法 JSON模型不支持 response_format 参数去掉该参数在 system 提示中强调输出 JSON并做异常重试点击运行后报 API Key 错误.env 文件没有正确加载或变量名不对确认.env路径检查OPENAI_API_KEY是否通过load_dotenv加载Token 消耗增长过快历史记录全部塞进下一轮 prompt使用记忆摘要裁剪策略限制最近窗口改进后分数反而下降改进算子过度激进或评判误差较大增加“连续无提升”终止条件记录分数并选择历史最高分版本最终结果不符合业务约束初始 prompt 缺少硬性约束在任务描述中明确约束条件如合规、安全、边界条件同一任务多次运行结果差异大温度参数过高将 temperature 调低到 0 到 0.3让输出更稳定如果遇到“模型输出内容自相矛盾”的问题通常不是 Meta^n 本身的问题而是评判算子缺少维度拆解。建议在评判 prompt 中引入多个评价维度例如完整性、准确性、可执行性、安全合规性分别打分再输出综合分。这样既能减少单维打分的随机性也能让反馈更有针对性。8. 最佳实践与工程建议Meta^n 看起来只是一个循环调模型的思路但要真正落地很多细节决定了最终效果和成本。第一算子和评判算子最好分离。不要让同一个模型、同一个提示词既负责改进又负责打分。因为“自己改自己”容易陷入路径依赖选择性地忽略某些明显问题。更合理的做法是改进算子和评判算子使用不同的系统提示词甚至在预算允许时使用不同模型。第二使用结构化输出。从第一版就使用 JSON 输出会让后续统计、回溯、回滚都方便得多。不要在第一版用文本解析等出了问题再改那时候你会有大量脏数据需要清洗。第三把每一轮的改进原因记录下来。很多项目只记录最终结果导致无法回答“这个方案为什么长这样”。改进原因是最有价值的中间数据它在复盘时能帮你发现模型反复出现的共性问题从而优化任务描述。第四增加版本回退机制。实际运行中最终轮并不一定是分数最高的一轮。因此运行结束后应该从 history 里挑出分数最高的一轮作为正式结果返回。不要默认最后一轮就是最好的。第五注意安全边界与合规要求。如果在业务中使用必须对模型的输出做敏感信息过滤对涉及用户数据、金融、医疗等场景要加入人工审核环节。Meta^n 只是提高了生成质量不会消除模型本身的风险。第六控制 API 预算。每次调用前估算成本轮次上限不要设置过高。可以为单个任务设置 Token 预算上限达到上限后强制输出当前最佳结果而不是继续尝试。第七适当使用缓存。对于相同任务和相同初始方案结果存在随机性。可以在内存或磁盘中缓存每一轮的 prompt 和结果便于对比不同温度参数或不同模型的效果。9. 总结与后续学习路线Meta^n 本质上是把“人工 review 循环”自动化。它不算复杂核心就是改进算子、评判算子、终止条件和历史记录四个部分。读完这篇文章你应该已经能够理解 Meta^n 的原理并用 Python 实现一个最小可用版本。如果你打算继续深入我建议按下面几条路线推进改造为异步并发版本。多个任务并行执行 Meta^n提高批处理效率。将评判打分从“单模型判断”升级为“多模型投票”减少单模型偏差。接入 LangChain 的 Memory 模块或向量数据库让改进过程具备跨任务的长期记忆。将 Meta^n 应用在代码生成、文案生成、数据分析等垂直场景对比不同任务下的收敛轮数。最后给你一个很实际的建议不要一上来就追求 10 轮、20 轮递归。先在两到三个真实任务上跑通 3 轮以内的闭环观察模型在哪一轮开始收益递减然后针对性地调整评判标准。等你积累了足够的改进轨迹数据再逐步放开轮数限制。这样既能控制成本也能让每一步改进都有据可查。 智能体自我改进实战：Meta^n 递归优化原理与实现
最近在做 AI Agent 项目时我遇到一个很典型的卡点模型单次生成的结果往往只是“看起来合理”细看之后总能发现逻辑漏洞、边界遗漏或者执行步骤不够具体。过去我们习惯的做法是人工把输出结果再贴回提示词手动让它“再改一版”改完再评评完再改。这个流程本身没有错但它完全依赖人工介入一个任务要来回好几轮而且这套经验到了下一个任务几乎无法复用。于是我开始尝试一个更“自动化”的思路让智能体自己评价自己的输出自己把改进意见再喂给自己循环往复直到结果收敛。这个设计在数学上很自然地可以写成 Meta^n也就是把“改进”这个操作递归地作用 n 次。本文会围绕这个思路从概念、原理、最小实现到完整工程示例逐一拆解并给出可以复制运行的 Python 代码和排错清单。无论你是刚开始接触智能体开发还是已经在用 Dify、Coze、LangChain 等平台搭过 Agent这篇文章都会对你有实际帮助。1. 背景与核心概念1.1 为什么需要“自我改进”传统的大模型调用方式是“单次问答式”用户给出 prompt模型给出 completion。这种模式对简单任务够用但面对复杂任务时一次生成的方案往往有三大问题。第一是覆盖不全。模型容易漏掉任务边界、异常分支和资源限制。第二是自洽性不足长篇输出容易前后矛盾。第三是缺少验证机制模型不会站在评审者角度重新审视自己。说白了单次生成没有“反思”环节就像写完代码不 review 一样出问题是必然的不出问题才是偶然。那为什么不能靠人反复改因为人肉迭代的效率太低而且不稳定。每个人对“好方案”的标准不同改两版和三版的人得到的质量也不同。更关键的是人工改进的经验很难沉淀成可复用的能力。如果能把“生成—评判—改进—再评判”这个闭环自动化等于把一位资深工程师 review 代码的能力注入到智能体的运行流程里。1.2 Meta^n 到底指的是什么Meta^n 这个写法直观上是数学里的函数幂记号。如果有一个算子 Meta它表示“对一段内容执行一次改进”那么 Meta(x) 表示对初始内容 x 改进一次Meta(Meta(x)) 表示在第一次改进结果的基础上再改进一次。连续作用 n 次就可以记为 Meta^n(x)。放在智能体语境里Meta 就是一个改进算子算法n 是递归改进的轮数。每一轮输入是上一轮的输出每一轮输出又作为下一轮输入这个过程在数据结构上就是典型的递归或迭代推进。需要注意Meta^n 不是某个官方框架或者固定 API它是一类设计思想的统称。你可以用纯 OpenAI API 实现也可以基于 LangChain、Dify、Coze 这类平台搭建。实现方式不同但核心都围绕三件事谁来做改进改进算子。怎么判断改得好不好评判算子。改到什么时候停终止条件。理解了这三件事Meta^n 就不再是一个神秘名词而是一套可落地的智能体自我改进架构。1.3 “递归”和“循环”在工程中的区别很多初学者会把“递归”理解成程序里函数调用自身。实际上在 Meta^n 的实现里我们通常会用循环去写因为每一轮的状态可以自然保存到变量和列表里。但从思想层面它仍然是递归当前状态的输出是下一轮状态的输入整个过程对“自己”的输出进行自我引用。工程上建议优先使用循环而不是函数递归原因是 Python 默认递归深度有限而且深递归容易导致调用栈溢出。更重要的是循环结构方便记录每一轮的中间结果便于日志回溯和断点恢复。如果你在文章或代码中看到“递归自我改进”它指的更多是“递归式思想”而程序落地时往往表现为“for 循环 历史记录”。2. 环境准备与实验框架2.1 开发环境本文示例以 Python 为主操作系统不限。建议环境如下Python 3.10 或更高版本。一个兼容 OpenAI 接口的大模型 API例如 OpenAI 官方接口或国内支持 OpenAI 格式的模型服务。需要能在命令行执行 Python 脚本。不需要非常高的机器配置因为所有计算都在模型 API 侧完成本地只负责组织 prompt 和解析结果。2.2 依赖安装需要安装两个核心依赖openai负责调用模型接口python-dotenv负责读取本地环境变量。pip install openai python-dotenv如果之后想加入 LangChain 风格的结构化输出还可以安装pip install langchain-core不过本文为了让大家看清原理尽量不引入太重的外层封装直接用 OpenAI SDK 写最小闭环。2.3 模型与 API 配置在项目根目录新建一个.env文件保存 API Key 和模型名称。OPENAI_API_KEYsk-你的密钥 OPENAI_BASE_URLhttps://api.openai.com/v1 OPENAI_MODELgpt-4o-mini如果你用的是国内兼容 OpenAI 格式的服务把OPENAI_BASE_URL改成服务商提供的地址即可。读取方式如下import os from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) model os.getenv(OPENAI_MODEL, gpt-4o-mini)这里需要注意不同模型对 JSON 输出的支持程度不同。gpt-4o-mini 和 gpt-4o 这类模型支持response_format{type: json_object}如果你的模型不支持就需要在 prompt 里强调“只输出 JSON不要输出多余内容”然后在代码里做容错解析。3. Meta^n 核心设计拆解3.1 改进算子Meta Operator改进算子是整个流程的引擎它的输入是原始任务、当前版本的内容以及上一轮的评判反馈输出是改进后的新版本同时最好附带一句“本轮的改动点说明”。在实际实现中改进算子通常只是一次精心构造的 LLM 调用。关键在于 prompt 设计要让模型明确自己是在“改进旧版本”而不是“重新生成一个回答”。避免模型输出和上一版本完全无关的内容。下面是最小化的改进算子设计思路你是一名严谨的方案评审专家。 当前任务{task} 当前版本{current} 上一轮评审意见{feedback} 请基于以上信息输出改进后的新版本。 要求 1. 保留上一轮中的合理内容 2. 修复上一轮中已经指出的问题 3. 不要重写一个无关方案 4. 直接输出改进后的完整内容不要解释。为什么要把“上一轮评审意见”也放进去因为如果没有反馈信息模型其实不知道要往哪个方向改结果就是每轮都在变但未必越变越好。把反馈作为输入等于让改进算子有了“问题清单”从而做针对性修改。3.2 评判算子Judge Operator评判算子是闭环的“方向盘”。它决定这一轮改进是合格、不合格还是已经达到了终止标准。评判算子要做三件事给当前版本打分比如 0 到 10 分。列出当前版本的主要问题。给出下一轮改进的具体建议。如果将评判结果也设计成结构化的 JSON后续程序处理会非常方便。例如{ score: 6.5, problems: [缺少异常处理, 步骤描述不够具体], suggestion: 补充超时重试机制并给出每一步的输入输出示例 }评判算子的质量直接决定整个 Meta^n 的上限。如果评判过于宽松模型可能两三轮就自认为完成了实际质量却不达标如果评判过于严苛则可能陷入无限改进。因此在工程实践中评判算子最好使用与改进算子不同的系统提示词甚至可以使用不同的模型避免同一模型自评自改带来的“自我感觉良好”偏差。3.3 终止条件设计递归改进必须设置终止条件否则就可能无限循环浪费 API 预算。常见的终止条件有四类终止条件说明适用场景最大轮数达到预设的 n 轮后强制停止所有场景最基础分数阈值评判分数达到预设值后停止质量要求明确的任务连续无提升连续两轮分数没有提高则停止防止无效迭代内容不再变化相邻轮次输出一致则停止内容稳定性要求高的任务实际项目里应该组合使用。比如“最大轮数为 5且同时满足分数不低于 8 或连续两轮无提升时停止”。3.4 改进轨迹记录每一轮改进后都应该把本轮结果记录下来至少包括轮次、内容、分数、反馈、修改说明、耗时和 Token 消耗。这些记录的价值在于便于追溯最终结果是从哪一轮演化而来的。如果最终结果不好可以回退到历史高分轮次。可以对比不同轮次之间的变化量判断是否收敛。我习惯用列表存储每一轮是一个数据类对象。如果未来要落地到生产环境还可以把记录写入本地 JSON 文件或数据库中。4. 最小闭环一次递归自我改进示例4.1 直接循环调用 LLM 的写法先来看一个最简单的闭环。这里不追求工程完整性只为了展示 Meta^n 的核心骨架。# meta_simple_demo.py import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) MODEL os.getenv(OPENAI_MODEL, gpt-4o-mini) def call_llm(prompt: str) - str: resp client.chat.completions.create( modelMODEL, messages[{role: user, content: prompt}], temperature0.7, ) return resp.choices[0].message.content.strip() def improve(task: str, current: str, feedback: str) - str: prompt f 你是一名方案改进专家。请基于旧版本和评审意见输出改进后的方案。 【原始任务】 {task} 【旧版本】 {current} 【评审意见】 {feedback} 【输出要求】 直接输出改进后的完整方案不要输出任何解释。 return call_llm(prompt) def judge(task: str, current: str) - dict: prompt f 你是一名方案评审专家。请为当前方案打分并给出改进建议。 【原始任务】 {task} 【当前方案】 {current} 【输出格式】 score: 0-10 之间的数字 problems: 用分号分隔的主要问题 feedback: 针对问题的改进建议 text call_llm(prompt) # 这里做了最简单解析实际项目建议让模型输出 JSON score 0.0 problems feedback for line in text.splitlines(): if line.startswith(score:): score float(line.replace(score:, ).strip()) elif line.startswith(problems:): problems line.replace(problems:, ).strip() elif line.startswith(feedback:): feedback line.replace(feedback:, ).strip() return {score: score, problems: problems, feedback: feedback} def run(task: str, initial: str, max_rounds: int 5, target_score: float 8.0): current initial history [] for i in range(1, max_rounds 1): print(f\n 第 {i} 轮 ) result judge(task, current) print(f当前评分{result[score]}) history.append({round: i, content: current, score: result[score]}) if result[score] target_score: print(已达到目标分数停止改进。) break current improve(task, current, result[feedback]) else: print(f已达最大轮数 {max_rounds}停止改进。) return current, history if __name__ __main__: task 为在线商城设计一套用户登录方案的步骤说明 initial 用户输入账号密码系统校验后登录成功。 final, history run(task, initial) print(\n 最终方案 ) print(final)这段代码把“评判—改进—再评判”的循环写出来了。虽然解析方式比较粗糙但它足够解释 Meta^n 的基本流程每一轮都会生成一个新的 current这个 current 再进入下一轮。4.2 运行结果分析正常运行时每一轮会输出当前评分。你会发现第一轮评分通常较低因为初始版本太简陋。改进算子拿到反馈后会补充细节后面几轮评分逐渐上升。当评分超过阈值或达到最大轮数时循环退出。这其实就是 Meta^n 的基本形态n 表示实际执行的轮数。假设第 3 轮评分达到 8.2 分那么 n 就等于 3最终结果就是 Meta^3(initial)。4.3 这个版本的局限性这个演示版本有三个明显问题。第一结果解析不稳定。用startswith文本解析要求模型严格按格式输出一旦模型输出顺序变化就会出错。第二没有记录改进算子给出的修改说明无法判断模型到底改了哪些点。第三没有对历史结果做比较可能出现评分先升后降但最终留下了较低分的版本。这些问题说明最小闭环只适合理解原理不适合直接放进项目。生产环境需要更严谨的数据结构和判断逻辑也就是下一章的增强版实现。5. 完整实战增强版 Meta^n 智能体5.1 项目结构为了演示更接近实际的写法我设计了一个增强版 MetaAgent。它的核心思路是用 Pydantic 或 dataclass 定义统一的数据结构。改进算子和评判算子都要求模型输出 JSON。每一轮自动记录改进轨迹。支持基于“分数阈值 最大轮数 连续无提升”的复合终止条件。项目结构如下meta_agent_demo/ ├── .env ├── meta_agent.py ├── run_demo.py └── requirements.txtrequirements.txt 内容openai1.0.0 python-dotenv1.0.05.2 实现 MetaAgent 核心类# meta_agent.py import json import os from dataclasses import dataclass, field from typing import List, Optional from dotenv import load_dotenv from openai import OpenAI load_dotenv() dataclass class MetaResult: 记录每一轮的改进结果。 round: int content: str score: float problems: str feedback: str change_reason: str model: str dataclass class MetaAgent: model: str field(default_factorylambda: os.getenv(OPENAI_MODEL, gpt-4o-mini)) max_rounds: int 5 target_score: float 8.0 no_improve_limit: int 2 temperature: float 0.7 def __post_init__(self): self.client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) self.history: List[MetaResult] [] def _chat_json(self, system: str, user: str) - dict: 调用模型并强制解析 JSON 返回。 resp self.client.chat.completions.create( modelself.model, temperatureself.temperature, response_format{type: json_object}, messages[ {role: system, content: system}, {role: user, content: user}, ], ) text resp.choices[0].message.content try: return json.loads(text) except json.JSONDecodeError as e: raise ValueError(f模型输出不是合法 JSON: {text}, 错误: {e}) def _judge(self, task: str, content: str) - dict: system 你是严格的方案评审专家。你只输出 JSON格式为{\score\: 数字, \problems\: \问题描述\, \feedback\: \改进建议\} user f 【原始任务】 {task} 【当前方案】 {content} 请评审当前方案并输出 JSON。 return self._chat_json(system, user) def _improve(self, task: str, current: str, feedback: str) - dict: system 你是方案改进专家。你只输出 JSON格式为{\content\: \改进后的完整方案\, \change_reason\: \本轮修改说明\} user f 【原始任务】 {task} 【当前方案】 {current} 【上一轮评审反馈】 {feedback} 请基于反馈输出改进后的完整方案并说明修改点。 return self._chat_json(system, user) def run(self, task: str, initial_content: str) - MetaResult: current initial_content no_improve_count 0 last_score -1.0 final_result: Optional[MetaResult] None for i in range(1, self.max_rounds 1): judge_data self._judge(task, current) score float(judge_data[score]) problems judge_data.get(problems, ) feedback judge_data.get(feedback, ) if score - last_score 0.1: no_improve_count 1 else: no_improve_count 0 print(f第 {i} 轮评分{score:.1f}连续未提升次数{no_improve_count}) if i self.max_rounds: improve_data self._improve(task, current, feedback) improved_content improve_data[content] change_reason improve_data[change_reason] else: improved_content current change_reason 达到最大轮数未继续改进。 result MetaResult( roundi, contentcurrent, scorescore, problemsproblems, feedbackfeedback, change_reasonchange_reason, modelself.model, ) self.history.append(result) final_result result if score self.target_score: print(已达到目标分数提前终止。) break if no_improve_count self.no_improve_limit: print(连续多轮未提升提前终止。) break current improved_content if final_result is None: raise RuntimeError(至少需要执行一轮请检查 max_rounds 配置。) return final_result这个类的设计有几个关键点。第一_chat_json强制要求模型输出 JSON并统一从这里走避免每个方法各自解析文本。第二history保存每一轮的完整状态方便后续分析。第三no_improve_limit用于检测长时间卡在同一个分数区间的情况防止无效消耗。需要说明的是response_format{type: json_object}需要模型支持结构化输出。如果你使用的是不支持该参数的模型可以把response_format去掉并在系统提示词中更严厉地强调 JSON 格式。5.3 实现任务运行脚本# run_demo.py from meta_agent import MetaAgent def main(): agent MetaAgent( modelgpt-4o-mini, max_rounds5, target_score8.0, no_improve_limit2, temperature0.7, ) task 为在线商城设计一套用户登录流程需要覆盖正常登录、密码错误、账号锁定和忘记密码四个场景。 initial 1. 用户输入账号密码。 2. 系统校验。 3. 登录成功或失败。 final_result agent.run(task, initial) print(\n 改进轨迹 ) for item in agent.history: print(f\n--- 第 {item.round} 轮 ---) print(f评分{item.score}) print(f内容{item.content}) print(f问题{item.problems}) print(f修改说明{item.change_reason}) print(\n 最终方案 ) print(final_result.content) if __name__ __main__: main()运行命令cd meta_agent_demo python run_demo.py5.4 运行与验证预期输出大致如下第 1 轮评分4.5连续未提升次数0 第 2 轮评分6.8连续未提升次数0 第 3 轮评分8.2连续未提升次数0 已达到目标分数提前终止。 改进轨迹 ... 最终方案 1. 用户输入账号密码。 2. 系统校验账号是否存在如果不存在则提示“账号不存在”。 3. 校验密码是否正确如果错误则提示剩余尝试次数。 4. 连续失败 5 次后锁定账号并提示通过邮箱找回。 5. 忘记密码时通过绑定手机或邮箱验证身份后重置。这里 n 的实际值会根据任务难度和模型表现变化。如果第一轮就达到了 8 分n 等于 1如果五轮都没上 8 分n 等于 5。这也符合 Meta^n 的定义n 不是预先写死的固定参数而是实际运行到终止时执行的轮数。6. 带记忆与成本控制的变体6.1 为什么需要控制上下文每一轮改进都会把“当前方案”和“评审反馈”拼进下一轮的 prompt。如果任务越来越复杂方案内容会越来越长十几轮下来上下文可能从几千 token 膨胀到几万 token。API 费用会迅速上升而且模型对长上下文的注意力也会下降反而影响改进质量。所以生产环境里的 Meta^n 不能无脑把全部历史都塞进 prompt必须做“记忆裁剪”。6.2 增加历史记忆摘要一个简单有效的做法是在进入第 i 轮时不再传第 i-2 轮之前的完整内容而是传“截至上一轮的修改摘要”。修改摘要可以由改进算子顺带生成也可以单独调用一次模型生成。在 MetaAgent 中可以增加一个字段memory每一轮改进后把新的修改说明追加进去同时限制历史长度def _build_compact_memory(self, history: List[MetaResult], window: int 2) - str: 将历史改进轨迹压缩为最近 window 轮的摘要。 recent history[-window:] if len(history) window else history if len(history) window: return lines [f第 {item.round} 轮修改说明{item.change_reason} for item in recent] return \n.join(lines)下一轮改进时把这段摘要作为“历史背景”传入 prompt而不是把历史完整方案全部拼进去。这样既保留了演进脉络又控制了 token 消耗。6.3 成本估算与轮次设置在调用 API 前我们可以估算单轮请求的平均 token 消耗。OpenAI 接口返回结果里包含usage字段可以获取 prompt_tokens 和 completion_tokens。做一个简单的累加统计就能知道每次任务的实际费用。# 在 _chat_json 中增加成本统计示例 usage resp.usage prompt_tokens usage.prompt_tokens if usage else 0 completion_tokens usage.completion_tokens if usage else 0 total_tokens prompt_tokens completion_tokens print(f本轮消耗 tokens{total_tokens})轮次设置方面建议普通任务从 3 到 5 轮开始尝试。不是轮数越多越好很多任务在 3 轮左右就会收敛。设置过大的 max_rounds一旦评判 prompt 设计不合理模型会陷入“为了改进而改进”的状态每一轮都在调整措辞但实际质量没有提升。7. 常见问题与排查思路在实现 Meta^n 智能体时我遇到过的坑基本可以汇总成下表。问题现象常见原因解决思路每一轮输出内容完全重写旧版本优点丢失改进 prompt 没有强调“保留原方案合理内容”在系统提示中加入“保留旧版本中合理的部分不要推倒重来”评分一直不变化循环到最大轮数评判 prompt 过于宽松或过于严苛检查评判标准必要时换更强的评判模型模型输出不是合法 JSON模型不支持 response_format 参数去掉该参数在 system 提示中强调输出 JSON并做异常重试点击运行后报 API Key 错误.env 文件没有正确加载或变量名不对确认.env路径检查OPENAI_API_KEY是否通过load_dotenv加载Token 消耗增长过快历史记录全部塞进下一轮 prompt使用记忆摘要裁剪策略限制最近窗口改进后分数反而下降改进算子过度激进或评判误差较大增加“连续无提升”终止条件记录分数并选择历史最高分版本最终结果不符合业务约束初始 prompt 缺少硬性约束在任务描述中明确约束条件如合规、安全、边界条件同一任务多次运行结果差异大温度参数过高将 temperature 调低到 0 到 0.3让输出更稳定如果遇到“模型输出内容自相矛盾”的问题通常不是 Meta^n 本身的问题而是评判算子缺少维度拆解。建议在评判 prompt 中引入多个评价维度例如完整性、准确性、可执行性、安全合规性分别打分再输出综合分。这样既能减少单维打分的随机性也能让反馈更有针对性。8. 最佳实践与工程建议Meta^n 看起来只是一个循环调模型的思路但要真正落地很多细节决定了最终效果和成本。第一算子和评判算子最好分离。不要让同一个模型、同一个提示词既负责改进又负责打分。因为“自己改自己”容易陷入路径依赖选择性地忽略某些明显问题。更合理的做法是改进算子和评判算子使用不同的系统提示词甚至在预算允许时使用不同模型。第二使用结构化输出。从第一版就使用 JSON 输出会让后续统计、回溯、回滚都方便得多。不要在第一版用文本解析等出了问题再改那时候你会有大量脏数据需要清洗。第三把每一轮的改进原因记录下来。很多项目只记录最终结果导致无法回答“这个方案为什么长这样”。改进原因是最有价值的中间数据它在复盘时能帮你发现模型反复出现的共性问题从而优化任务描述。第四增加版本回退机制。实际运行中最终轮并不一定是分数最高的一轮。因此运行结束后应该从 history 里挑出分数最高的一轮作为正式结果返回。不要默认最后一轮就是最好的。第五注意安全边界与合规要求。如果在业务中使用必须对模型的输出做敏感信息过滤对涉及用户数据、金融、医疗等场景要加入人工审核环节。Meta^n 只是提高了生成质量不会消除模型本身的风险。第六控制 API 预算。每次调用前估算成本轮次上限不要设置过高。可以为单个任务设置 Token 预算上限达到上限后强制输出当前最佳结果而不是继续尝试。第七适当使用缓存。对于相同任务和相同初始方案结果存在随机性。可以在内存或磁盘中缓存每一轮的 prompt 和结果便于对比不同温度参数或不同模型的效果。9. 总结与后续学习路线Meta^n 本质上是把“人工 review 循环”自动化。它不算复杂核心就是改进算子、评判算子、终止条件和历史记录四个部分。读完这篇文章你应该已经能够理解 Meta^n 的原理并用 Python 实现一个最小可用版本。如果你打算继续深入我建议按下面几条路线推进改造为异步并发版本。多个任务并行执行 Meta^n提高批处理效率。将评判打分从“单模型判断”升级为“多模型投票”减少单模型偏差。接入 LangChain 的 Memory 模块或向量数据库让改进过程具备跨任务的长期记忆。将 Meta^n 应用在代码生成、文案生成、数据分析等垂直场景对比不同任务下的收敛轮数。最后给你一个很实际的建议不要一上来就追求 10 轮、20 轮递归。先在两到三个真实任务上跑通 3 轮以内的闭环观察模型在哪一轮开始收益递减然后针对性地调整评判标准。等你积累了足够的改进轨迹数据再逐步放开轮数限制。这样既能控制成本也能让每一步改进都有据可查。