最近很多团队在做 AI 智能体Agent项目时都会遇到同一个困扰同一个 Prompt简单任务表现还不错任务稍微复杂一点输出就开始飘忽不定。于是大家开始手动调 Prompt、加示例、拆任务流程但每次调整都是一次“人肉循环”。这个循环能不能交给智能体自己完成这就是本文要讨论的主题——Meta^n一种让智能体具备递归自我改进能力的方法。为便于理解我会先解释 Meta^n 的概念来源和核心思想再拆解递归自我改进的工程原理然后给出一个可以本地运行的最小 Python 示例最后补充常见问题、排查思路和工程化建议。无论你是刚开始接触 Agent 智能体的新手还是已经在做智能体落地的开发者都能从中找到可以落地的思路。1. 为什么要研究智能体递归自我改进1.1 智能体开发的现实痛点传统智能体开发本质上是在做一件事把人类的经验通过 Prompt、工具、流程编排固化成代码。开发者的日常工作通常是设计一套系统提示词告诉大模型“你是谁、你要做什么、你有哪几步”。定义好工具列表比如搜索、计算、读写文件。编写一个状态机让智能体按“计划→执行→观察→再计划”的模式循环。这套路子对固定任务有效但遇到开放性问题时就很容易出问题。比如任务目标变化、输入格式变化、用户描述不完整智能体就会在同一个步骤上反复失败开发者只能一遍一遍改 Prompt。改动 Prompt 之后可能原来正常的场景又变差了这就是典型的“按下葫芦浮起瓢”。根本原因是智能体在执行任务时缺少对自己行为的观察能力。它不知道这一步做得对不对、哪里偏离了目标、下一步该调整什么。或者说它对所有任务都采用同一套固定策略不具备“策略级自适应”。1.2 什么是 Meta^nMeta^n 这个符号可以从数学中的“幂次”来理解。Meta 本身是“元”的意思指更高一层的抽象。把一个智能体看作 Meta^1那么Meta^1能执行任务的基础智能体。Meta^2能观察自己执行过程、评估输出质量、修改自身策略的智能体。Meta^3能改进“自己观察与修改策略”这套机制的智能体。Meta^n把上述元认知过程递归叠加到第 n 层。用一句话概括Meta^1 在做事Meta^2 在看自己怎么做事Meta^3 在看自己怎么“看自己怎么做事”。每一层都比上一层多一次抽象而抽象的递归叠加就是符号中的 n 次幂。需要说明的是目前在学术论文和工程社区里Meta^n 还没有一个完全统一的标准定义。不同文章可能强调“元学习”“自我模型”“递归自我改进”等不同侧面。本文采用工程化的理解Meta^n 是把“执行—反思—改进”的过程递归应用让智能体不仅会改进结果还会改进改进方法本身。1.3 递归自我改进与传统方案的区别对比维度传统 Prompt 工程静态 Agent 编排Meta^n 递归自我改进改进主体开发者人工调整开发者 少量规则智能体自身 高层元规则对动态任务的适应能力较弱中等较强可复用性依赖个人经验流程固定换场景重写策略可迁移运行成本低中较高需要配额控制失控风险低低需要设计停止条件传统 Prompt 工程里“谁改 Prompt”这个问题很明确人。静态 Agent 编排中你可以在代码里写死一些条件分支比如“如果返回 JSON 解析失败就加一条修正提示”但这种分支只能覆盖有限的异常情况。Meta^n 的思路是把“改进策略”本身变成可学习的对象如果当前策略不适用智能体不只是换一句提示词而是会去思考“当前这套改进规则是否合理”“是否应该用另一种方式评估输出”。这更接近人类面对新任务时的做法。只看概念可能还是有点抽象下面从工程原理入手把递归自我改进拆开分析。2. Meta^n 的核心原理拆解2.1 从“执行—评估”到“元认知闭环”任何自我改进系统都要先形成一个闭环。经典智能体执行链路是任务理解 → 规划 → 工具调用 → 输出这个链路里没有反馈。Meta^n 的第一步是把链路升级为执行 → 评估 → 改进 → 再执行 → 再评估 → 达到标准或到达上限其中“执行”负责调用大模型生成结果“评估”负责判断结果是否满足任务要求“改进”负责根据评估结果调整执行策略。这个闭环在单轮内并不新鲜类似 Reflexion、Self-Refine 等方案都有体现。Meta^n 的特别之处在于它会把这个闭环递归地应用在“改进策略”自身。假设第 1 轮评估发现输出太长改进器建议“控制输出长度”第 2 轮评估发现输出虽然短了但丢了关键信息改进器又建议“保留核心名词”。如果两轮改进仍然不达标普通方案就停在那里等人介入。而 Meta^n 会继续上升到更高层去审视“改进器使用的规则映射是否合理”然后调整规则映射本身。2.2 递归让改进动作自身可被改进说到递归很多读者会想到汉诺塔、二叉树遍历一个函数调用自己每次调用处理更小的子问题。在 Meta^n 中递归的对象不是“某个数据集合”而是“改进动作”。第一层递归智能体执行任务发现结果不好于是提升一次提示词约束。第二层递归改进器生成的提示词仍然不理想因此系统要调整改进器自身的参数比如从“追加约束”改为“重写提示词”从“只看关键词是否出现”改为“综合衡量语义完整性”。第三层递归如果调整参数后依然不收敛系统继续上升去优化“选择改进器参数的策略”。这个过程的数学表达可以写成M^n(prompt, task) if 满足停止条件: return result else: result execute(M^{n-1}(prompt, task)) feedback evaluate(result) new_prompt improve(feedback, prompt) return M^n(new_prompt, task)注意这里的 n 不是简单的循环次数而是“元层级”的深度。循环次数是同一个层级内的重复尝试元层级则是不断抽象“改进者”本身。这里存在一个工程上必须解决的问题递归层级越深系统越复杂越难预测。所以实际实现时不能真的让系统无限递归下去必须设置清晰的停止条件。2.3 安全边界与终止条件在讨论“递归自我改进”时很多人第一时间会担心两个问题系统会不会改着改着就失控会不会为了优化一个指标把其他重要目标全部忽略这种担心在实践中是真实存在的。如果不加约束改进器可能为了把“输出长度”指标做到满分把结果压缩到只留下几个词丢掉所有关键信息也可能为了让评估得分更高不断堆叠提示词规则最后系统提示词比任务说明书还长既增加了 token 成本又让模型输出变得呆板。因此任何一个 Meta^n 系统上线前都必须设计好以下安全边界最大递归深度比如最多只能递归 5 层超过即停止。评估分数阈值达到指定分数就立即收敛不追求每次都 100 分。改进收敛判断如果连续两轮分数没有明显提升说明已经进入平台期继续递归意义不大。资源预算单次任务允许消耗的最大 token 数、最大 API 调用次数。人工审批兜底对于高风险任务改进后的 Prompt 在执行前需要经过人工确认。这些边界不仅是工程需要也是让系统行为可控的前提。下一节我会把这些设计原则落到一个小型架构上。3. 简化版工程架构设计3.1 模块划分一个最小可运行的 Meta^n 智能体至少需要五个模块模块英文名职责大模型客户端LLM Client统一封装大模型调用支持模拟实现与真实 API 实现执行器Executor携带系统提示词和任务调用大模型生成输出评估器Reflector根据任务要求对输出打分输出具体问题列表改进器Improver根据问题列表生成新的系统提示词或新策略递归引擎MetaN Engine控制整个递归过程判断何时停止、何时进入下一层这里把“执行器”和“大模型客户端”分开是为了保持职责清晰。实际项目中执行器还可以负责工具调用、上下文组装、多轮对话等逻辑。评估器是整个系统真正的“标尺”它决定了智能体朝哪个方向改进。改进器则是“方向盘”负责把评估结果转成下一步行动。3.2 递归调度流程整个流程可以概括为用初始系统提示词和任务调用大模型。评估器检查输出质量给出得分和问题。如果得分达标直接返回结果。如果未达标改进器基于问题生成新的系统提示词。递归引擎将递归深度加 1带着新提示词继续执行。如果递归深度达到上限返回当前最优结果。这里有一个关键之处改进器本身可以拥有多种策略默认策略是“在现有提示词上追加约束”另一种策略是“重写整个提示词”还有一种是“把约束组织成结构化格式”。选择哪种策略就是元规则。更高层级的 Meta^n 系统会在递归过程中动态调整这个选择而不是写死。3.3 安全性设计原则结合 2.3 节的终止条件讨论工程上可以这样落地在递归引擎中保存max_depth参数每个任务运行时都会校验当前深度。评估器必须输出“可解释的问题列表”不能只给一个抽象分数。改进器对每轮生成的提示词做长度检查如果超过预设上限则触发降级策略。所有递归执行过程都要写日志方便事后回溯问题。这些原则听起来不难但在真实系统中很容易被忽略。很多团队只关注“效果是否提升”忽略了系统在无人干预时是否安全可控。对生产环境来说安全和可控永远排在效果前面。4. Python 实战实现最小可运行版本4.1 项目结构与环境准备为了让读者能直接跑通我设计了一个不需要第三方依赖的演示项目。项目结构如下meta-n-demo/ ├── meta_n_agent.py └── main.py运行环境使用 Python 3.9 及以上版本即可。示例中我用一个MockLLM模拟大模型目的是把“递归自我改进”的调度逻辑讲清楚。你在真实项目中可以把这个类替换为 OpenAI SDK、本地部署模型或其他大模型平台的客户端。如果你的环境还没有准备好可以先执行python --version确认 Python 版本。如果已经可以正常运行就可以开始写代码了。4.2 模拟 LLM 接口新建meta_n_agent.py先定义大模型调用抽象接口和模拟实现。# 文件meta_n_agent.py Meta^n Agent 演示一个极简的递归自我改进智能体。 说明Demo 使用规则模拟大模型方便本地运行。 读者可以把 MockLLM 替换为真实的 LLM API 客户端。 class BaseLLM: LLM 抽象接口保证真实模型与 Mock 模型可以互换。 def generate(self, system_prompt: str, task: str) - str: raise NotImplementedError class MockLLM(BaseLLM): 模拟大模型根据 system_prompt 中的约束条件返回不同的处理结果。 设计意图 - 没有约束时输出一段冗长的文本代表模型第一次回答时的“冗余输出”。 - 有“不超过50字”约束时模型为了满足长度压缩过度丢掉关键信息。 - 同时有“不超过50字”和“缓存”等关键信息约束时输出达到平衡。 def generate(self, system_prompt: str, task: str) - str: has_limit 不超过50字 in system_prompt mention_cache 缓存 in system_prompt if has_limit and mention_cache: return Redis是开源内存存储系统支持多种数据结构常用于缓存和消息队列。 if has_limit: return Redis是开源内存存储系统。 if mention_cache: return Redis是开源内存键值存储系统支持多类型性能高常用作缓存。 return ( Redis是一个开源的、基于内存的数据结构存储系统它可以用作数据库、缓存和消息中间件 支持字符串、哈希、列表、集合、有序集合等多种数据类型并提供持久化、主从复制、高可用、 分布式集群等丰富功能因此被广泛用于各类互联网应用的缓存场景、会话管理、排行榜、消息队列等场景。 )上面这段代码里MockLLM并不是一个真正的大模型它只是用规则模拟“大模型在不同提示词约束下会给出不同风格回答”的现象。这个设计有两点好处不依赖网络和 API Key任何人都可以快速运行。能模拟出真实模型常见的两种问题首次回答冗长、过度压缩导致丢信息。后文会说明如何把MockLLM替换成真正的模型接口。4.3 反射评估器继续在meta_n_agent.py中定义评估结果对象和评估器。class EvalResult: 评估结果对象。 def __init__(self, score: int, issues: list, passed: bool): self.score score self.issues issues self.passed passed class Reflector: 评估器根据任务要求判断输出质量。 这里只用一个最小可运行规则 - 输出不能超过 50 字。 - 必须包含核心名词 Redis。 - 必须包含关键信息“缓存”。 实际项目中这个角色可以由大模型 规则校验共同承担。 MIN_PASS_SCORE 90 def evaluate(self, task: str, output: str) - EvalResult: score 100 issues [] if len(output) 50: score - 40 issues.append(输出超过50字需要压缩) if Redis not in output: score - 30 issues.append(缺少核心名词Redis) if 缓存 not in output: score - 20 issues.append(缺少关键信息缓存) passed score self.MIN_PASS_SCORE return EvalResult(scorescore, issuesissues, passedpassed)评估器的核心职责是“量化好坏”。判断标准越清晰后续改进越有方向。在这个演示里评估标准是硬编码的规则适合用来展示流程。但在真实项目中评估标准本身也可以是有权重的、多维度的甚至由另一个模型来打分。注意评估结果里一定要包含issues问题列表而不是只给分数。因为“改进器”需要知道具体要改什么。如果只给一个 60 分改进器根本不知道应该加长还是缩短、补信息还是改格式。4.4 提示词改进器接下来定义改进器。class Improver: 改进器根据评估问题列表生成新的系统提示词。 默认采用 append追加约束策略。 扩展思路 - style rewrite 表示重写提示词 - style structured 表示把约束组织成结构化清单 - 更高层的 Meta 循环可以在递归过程中切换 style。 def __init__(self, style: str append): self.style style self._used_rules set() def improve(self, system_prompt: str, issues: list) - str: if self.style ! append: # 其他策略在真实项目中按需补充 return system_prompt additions [] for issue in issues: if 超过50字 in issue: rule 必须把回答控制在不超过50字 elif 缺少 in issue: rule 必须保留关键信息 issue.split()[-1] else: rule 请继续优化输出 if rule not in self._used_rules: additions.append(rule) self._used_rules.add(rule) if additions: return system_prompt 。 .join(additions) return system_prompt改进器的逻辑很直白把问题列表翻译成提示词约束拼接到系统提示词后面。比如“输出超过50字”被翻译成“必须把回答控制在不超过50字”这样下一轮执行时模型就会看到新的约束。self._used_rules用于去重避免同一规则被反复拼接导致提示词越来越臃肿。这个细节在生产环境中非常重要因为大多数场景的问题是重复出现的。4.5 Meta^n 递归引擎核心调度逻辑如下。class MetaNEngine: 递归引擎控制执行、评估、改进的循环并记录元层级。 def __init__(self, llm: BaseLLM, reflector: Reflector, improver: Improver, max_depth: int 5): self.llm llm self.reflector reflector self.improver improver self.max_depth max_depth def run(self, task: str, system_prompt: str, depth: int 1): depth 从 1 开始计数 depth1 表示 Meta^1即基础智能体执行。 depth2 表示 Meta^2即智能体具备自我反思与改进能力。 depthn 表示 Meta^n即递归自我改进持续到第 n 层。 print(f\n 第 {depth} 次执行Meta^{depth}) # 1. 执行阶段 output self.llm.generate(system_prompt, task) print(f[执行] 系统提示词: {system_prompt}) print(f[执行] 智能体输出: {output}) # 2. 评估阶段 result self.reflector.evaluate(task, output) print(f[反思] 得分: {result.score}, 问题: {result.issues}) # 3. 达标则收敛 if result.passed: print([通过] 达到质量要求不需要继续改进。) return output # 4. 达到递归深度上限 if depth self.max_depth: print(f[终止] 达到最大递归深度 {self.max_depth}返回当前最优结果。) return output # 5. 改进阶段 new_prompt self.improver.improve(system_prompt, result.issues) print(f[改进] 新提示词: {new_prompt}) # 6. 进入下一元层 return self.run(task, new_prompt, depth 1)这个类是整个示例的“心脏”。它完成了三个阶段执行把系统提示词和任务交给 LLM。反思评估输出。改进生成新的系统提示词后递归调用。在代码里depth变量体现了元层级。depth 每次加 1就代表系统多了一层抽象。当一次执行已经通过评估时系统会直接收敛不再递归。这也是递归自我改进工程实现中最重要的设计有明确收敛条件。4.6 运行与验证新建main.py把各个模块串起来。# 文件main.py from meta_n_agent import MockLLM, Reflector, Improver, MetaNEngine if __name__ __main__: llm MockLLM() reflector Reflector() improver Improver(styleappend) engine MetaNEngine(llmllm, reflectorreflector, improverimprover, max_depth5) task ( 请基于下面资料生成一段不超过50字的Redis简介。 资料Redis是开源的基于内存的数据结构存储系统可用作数据库、缓存和消息中间件。 ) initial_prompt 你是一个文本摘要助手。 final_result engine.run(task, initial_prompt) print(\n最终结果:, final_result)运行命令python main.py预期输出如下 第 1 次执行Meta^1 [执行] 系统提示词: 你是一个文本摘要助手。 [执行] 智能体输出: Redis是一个开源的、基于内存的数据结构存储系统它可以用作数据库、缓存和消息中间件支持字符串、哈希、列表、集合、有序集合等多种数据类型并提供持久化、主从复制、高可用、分布式集群等丰富功能因此被广泛用于各类互联网应用的缓存场景、会话管理、排行榜、消息队列等场景。 [反思] 得分: 60, 问题: [输出超过50字需要压缩] [改进] 新提示词: 你是一个文本摘要助手。必须把回答控制在不超过50字 第 2 次执行Meta^2 [执行] 系统提示词: 你是一个文本摘要助手。必须把回答控制在不超过50字 [执行] 智能体输出: Redis是开源内存存储系统。 [反思] 得分: 80, 问题: [缺少关键信息缓存] [改进] 新提示词: 你是一个文本摘要助手。必须把回答控制在不超过50字必须保留关键信息缓存 第 3 次执行Meta^3 [执行] 系统提示词: 你是一个文本摘要助手。必须把回答控制在不超过50字必须保留关键信息缓存 [执行] 智能体输出: Redis是开源内存存储系统支持多种数据结构常用于缓存和消息队列。 [反思] 得分: 100, 问题: [] [通过] 达到质量要求不需要继续改进。 最终结果: Redis是开源内存存储系统支持多种数据结构常用于缓存和消息队列。从这个输出可以看到Meta^n 的逻辑非常直观Meta^1基础智能体只执行任务输出很长不达标。Meta^2智能体对自己的输出进行反思发现“超过字数限制”于是改进策略下一轮输出变短了但短过头了。Meta^3系统继续反思发现“丢了缓存这个关键信息”再次修正策略最终输出达到平衡。这就是一个完整的递归自我改进