企业官网建设流程全解析

我们正卡在一个尴尬阶段：智能体已经能跑通很多任务，但让它“变好”这件事，几乎全靠人肉。Prompt 不合适，人改；工具调用顺序不对，人调；流程设计有缺陷，人重构。模型越来越聪明，可“改进智能体”的工程师反而成了瓶颈。更尴尬的是，现在很多号称“自动优化”的 Agent 系统，本质上只是在运行完后做一轮自反思，把错误文本重新拼接进 Prompt，再跑一遍。这确实比什么都不做好，但它没有真正的递归结构——改进一次之后，下一次改进不会比上一次更懂“如何改进”。

Meta^n 这个名字，恰恰就是冲着这个痛点去的。它的核心思想是：与其只让智能体改进任务策略，不如让“改进智能体”这件事也变成可以被递归优化的对象。也就是说，Meta¹ 是智能体改进任务策略，Meta² 是改进“改进策略”的策略，Meta³ 是改进“改进‘改进策略’的策略”……从数学符号上看，n 次递归后，系统的自我改进能力本身会一层层放大。今天这篇文章，我要讲清楚 Meta^n 到底是什么、它和普通“自反思”有什么区别、在实践中怎么搭一个最小可运行的递归自我改进系统，以及这条路有哪些容易被忽略的坑。

全文会以工程实现为主线，先建立概念，再给代码骨架，最后讲验证方式和工程建议。读完以后，你应该能自己动手做一个简单的递归改进实验，并且能判断：一个所谓“自我改进”的智能体系统，到底是真递归，还是只是把“反思”换了个名字。

1. 这篇文章真正要解决的问题

如果你最近在用 Coze、Dify 或者自己写 Agent 框架，大概率遇到过类似的场景：

• 任务第一次跑失败，你把错误信息复制给大模型，让它“再想想”，第二次可能成功，但第三次换了个任务又失败。
• 你在 Prompt 里加了十几条规则，结果任务 A 的准确率上去了，任务 B 的准确率掉下来。
• 你想让智能体根据历史失败案例自动调整工具调用顺序，但调完以后发现它开始反复调用同一个工具，浪费大量 token。
• 团队里没有专门的“Prompt 工程师”，每个业务线都在靠人肉调参维护智能体。

这些问题背后是同一个本质：当前大多数 Agent 系统的“学习”是浅层的。它只改策略，不改“产生策略的方法”。如果第一版 Prompt 写得就不好，那么无论反思多少轮，它都很难跳出最初的表达框架。

Meta^n 要解决的就是这个“元问题”。它不再满足于让智能体在某个任务上表现更好，而是让系统具备“持续改进自身改进方式”的能力。换句话说，传统做法是“智能体 + 反思循环”，Meta^n 是“对反思循环再做反思循环”。从工程角度看，这意味着我们需要把智能体、改进策略、监督策略都变成显式的、可版本化、可评估、可迭代的模块。

这篇文章适合三类读者：第一，正在做智能体应用落地，但被 Prompt 调优和工具链稳定性折磨的开发者；第二，研究 Agent 框架、想要理解“自我改进”原理的技术爱好者；第三，做 AI 平台设计，需要判断“递归自我改进”到底能不能工程落地的架构师和产品经理。

2. 智能体自我改进的核心概念

先把概念拆开讲，否则后面代码容易看晕。

2.1 什么是智能体（Agent）

智能体不是单纯的大模型接口。一个可工作的智能体至少包含四部分：

• 模型：负责理解和生成，通常是一个 LLM。
• 策略（Policy）：决定模型在某个状态下做什么动作的规则集合，表现形式可能是 Prompt 模板、工具调用顺序、任务拆解方式、停止条件等。
• 工具集（Tools）：可调用的外部能力，比如搜索、计算器、数据库查询、内部 API。
• 执行环境：提供工具运行所需的资源和上下文。

在实际系统中，策略往往被写死在 Prompt 或流程编排里。这是问题所在：策略一旦固定，智能体的能力上限就锁死了。递归自我改进的目标，就是动态更新策略。

2.2 什么是元智能体（Meta-Agent）

元智能体是“负责改进普通智能体的智能体”。它不直接执行任务，而是观察任务执行结果、分析失败原因、生成新的策略或修改现有策略。

我们可以用一个编程里的类比：普通智能体是正在运行的程序，元智能体是 IDE 和编译器的结合体。程序运行失败后，编译器不会自动帮你改代码逻辑；但元智能体要做的事情，就是自动帮你找到代码缺陷，并提出补丁，然后在沙盒里验证补丁是否有效。

Meta^n 中的“n”表示这种元智能体的嵌套深度。Meta¹ 改进策略，Meta² 改进“Meta¹ 改进策略的方法”，以此类推。理论上，越高的层级越能产生超越人类预设的改进方式，但代价是系统复杂度急剧上升。

2.3 监督策略与收益信号

递归自我改进最容易被忽略的部分，是“靠什么判断改进有效”。如果没有清晰的监督信号，系统只会陷入无止境的自我修改。

监督策略（Supervisor Policy）就是用来做这事的模块。它接收一组评测指标，比如任务成功率、平均工具调用次数、耗时、Token 消耗、用户反馈分数，然后决定：当前策略是保留、替换，还是回滚。

这里有一个关键设计原则：监督策略必须独立于被改进的策略之外。如果让智能体自己判断“我改进得好不好”，它很容易自欺欺人。比如一个 Chatbot 在回答数学题时连续出错，如果它自己给自己打分，可能会因为“语气更自信了”而把自己判为成功。

2.4 递归深度与“Meta^n”的数学直觉

从数学上看，Meta^n 很容易理解。定义运算符 M，它表示“改进某个策略”。那么：

• Meta¹ 就是 M(policy)，输出改进后的策略。
• Meta² 是 M(M(policy))，相当于先改进策略，再改进“改进策略的方法”。
• Meta^n 是应用 n 次 M 运算符。

但工程上，这个“运算符”不是严格意义上的数学函数，因为它有成本和随机性。每多一层递归，就需要额外的模型调用、评测时间和存储空间。如果 n 太大，系统的 Latency 和费用会指数级增长。这也是为什么很多宣称“自我改进”的项目只做了 Meta¹——它容易实现，收益也已经不错。

在后面的代码里，我会用一个简化但可扩展的架构，把“递归深度”做成可配置参数，让你能直观看到不同深度下的改进效果和开销差异。

3. 递归自我改进与传统 Auto-Fix 的本质区别

这个部分很重要，因为它决定了你理解 Meta^n 的深度。

3.1 两者的流程差异

传统 Auto-Fix（自动修复）流程：

1. 智能体执行任务失败。
2. 捕获报错信息或失败结果。
3. 把错误信息拼接到新的 Prompt 中，要求 LLM 重新推理。
4. 再次执行任务。
5. 如果成功，则结束；如果失败，重复 1-4。

表面上看，这也是一种“自我改进”，因为它确实在根据历史反馈调整行为。但它的改进对象永远只是某一次的上下文，而不是策略本体。下次遇到类似任务时，之前学到的东西并没有被保存下来。

Meta^n 流程：

1. 智能体执行任务失败。
2. 元智能体分析失败原因，生成策略变更建议。
3. 在沙盒环境中用一批测试任务验证建议。
4. 监督策略根据指标决定是否接受策略变更。
5. 如果接受，将新策略写入策略库，并保存变更日志。
6. 在更高递归层，元智能体的“分析过程”本身也会被评估和优化。

也就是说，Auto-Fix 改的是“这一轮的回答”，Meta^n 改的是“未来所有轮的回答方式”。

3.2 一个容易踩的坑：伪递归

现在很多产品喜欢把任何包含“反思”的流程都叫递归改进。但真正的递归有一个硬性要求：改进过程的每一次迭代，都必须基于前一次迭代的改进结果，而不是基于原始问题的重复尝试。

举例来说，如果系统只是“失败 -> 重新生成 -> 再失败 -> 再重新生成”，这是重试，不是递归。因为每次重试之间没有“对改进方法本身的改进”。真正的递归应该具备结构性记忆：系统要能区分“策略 A 在任务集 X 上比策略 B 好，因此下轮生成策略时优先继承 A 的某些特征”。

在工程实现上，这种区分能力通常依赖两个机制：

• 策略版本管理：每个策略都对应一个版本号，记录父版本、修改原因、评测分数。
• 元策略更新：不只是更新策略内容，还更新“如何根据失败案例生成策略”的算法或模板。

缺少任何一个，都会退化为普通重试。

3.3 为什么说要解决“递归”问题，先解决“评估”问题

Meta^n 听起来很酷，但我必须泼一盆冷水：递归改进的前提是稳定、可靠、可复现的评估。没有评估，递归就是灾难。

设想一个场景：你让一个智能体自动写 Python 代码，然后让它自己运行、自己判断“是否成功”。如果代码运行报错，它会发现；但如果代码输出错误结果，而系统没有针对该任务的单元测试，它就会把错误代码当作成功，并把这个错误经验传播到后续策略中。递归之后，错误会被放大，而不是被修正。

所以在设计系统时，评估模块必须先于自我改进模块实现。你需要的不是“大模型评价大模型”，而是一组可量化、可自动执行的评测任务。它可以是单元测试、黄金答案对比、用户行为模拟，甚至是形式化校验，但必须独立于被评估的策略。

4. 设计一个最小的 Meta^n 实验系统

在贴代码之前，我们先做架构设计。这个设计故意保持简洁，以便你能跑通整体流程，同时保留扩展空间。

4.1 架构模块

系统分为五个模块：

1. 任务执行器（Executor）：负责运行智能体并返回结果。
2. 策略库（PolicyStore）：保存策略版本、父版本和变更日志。
3. 元智能体（MetaAgent）：根据失败案例生成新策略。
4. 监督器（Supervisor）：评估新策略是否优于当前策略。
5. 递归驱动器（RecursiveDriver）：协调上面的模块，并控制递归深度。

4.2 数据流说明

一条完整的数据流如下：

任务 -> Executor 使用当前策略执行 -> 得到结果 ↓ 评估器打分：成功 / 失败 ↓ 如果失败： MetaAgent 分析失败案例 MetaAgent 生成新策略 在验证集上运行新策略 Supervisor 对比新旧策略 若指标更优 -> 写入 PolicyStore 若指标更差 -> 丢弃，记录日志 ↓ 下一轮任务使用更新后的策略

如果启用了 Meta²，那么“MetaAgent 如何分析失败案例”的规则本身也会进入一个上层循环：上层 MetaAgent 会分析“这个 MetaAgent 为什么给出的改进建议质量不高”，并改进 MetaAgent 的分析模板或算法。

在实际代码中，我不会把 Meta² 写得特别复杂，而是抽象成一个通用的 recursive_improve 函数，通过 depth 参数控制嵌套层数。这样你只需要看懂一个核心逻辑，就能理解 Meta^n 的整体骨架。

5. 环境准备与前置条件

在开始之前，我默认你已经具备 Python 基础环境。这里不绑定某个具体 LLM 厂商，也不绑定特定 Agent 框架。

建议环境：

• Python 3.9 及以上版本（我用的是 Python 3.10，但代码本身没有强依赖）。
• 已安装 pip。
• 如果希望跑通真实 LLM 调用，需要准备一个可用的 LLM API Key（OpenAI、通义、文心、Ollama 本地模型均可）。
• 如果不使用真实 LLM，可以直接用规则函数模拟策略生成，我下面会提供这种简化方式。

安装依赖时，只需要最基本的库：

pip install json5 pyyaml

其中 json5 用于容忍带注释的 JSON 配置，pyyaml 用于读取 YAML 格式的策略文件。实际生产项目中，你可能还需要引入向量数据库、缓存、日志采集等组件，但当前最小系统用不到。

整个项目的目录结构建议如下：

meta_n_demo/ ├── agent_core.py # 智能体核心与策略执行 ├── meta_agent.py # 元智能体与递归改进逻辑 ├── supervisor.py # 监督器与评测器 ├── main.py # 演示入口 └── config.yaml # 配置文件

6. 核心代码实现

下面我会分三个文件给出代码，并在关键位置加注释。先看最小版本，理解骨架；后面再根据实际情况扩展。

6.1 文件：agent_core.py

这个文件负责定义任务、智能体策略执行和结果记录。

# agent_core.py import json import hashlib from dataclasses import dataclass, field from typing import Any, Callable @dataclass class Task: """一个可被执行的测试任务。""" task_id: str description: str input_data: Any expected_output: Any = None @dataclass class Strategy: """策略对象。""" version: str parent_version: str = None prompt_template: str = "" tool_usage: list = field(default_factory=list) meta_info: dict = field(default_factory=dict) def short_id(self) -> str: s = json.dumps( { "prompt_template": self.prompt_template, "tool_usage": self.tool_usage, "parent_version": self.parent_version, }, sort_keys=True, ) return hashlib.sha1(s.encode("utf-8")).hexdigest()[:10] class BaseAgent: """ 一个最小智能体：根据策略执行任务。 实际项目中，这里会接入 LLM 和工具调用框架。 本示例中我们用一个简单的规则引擎模拟策略差异。 """ def __init__(self, strategy: Strategy): self.strategy = strategy def execute(self, task: Task) -> dict: """ 模拟执行任务。 这里故意让执行结果依赖策略中的 prompt_template 关键字。 如果 prompt_template 包含 'good_template'，成功率会更高； 否则按一定概率失败。 这样我们可以直观看到策略更替带来的效果变化。 """ prompt = self.strategy.prompt_template + " | " + task.description # 模拟工具调用次数 if "use_tool_calc" in self.strategy.tool_usage: tool_calls = 2 else: tool_calls = 1 # 模拟执行成功概率 # 这里不使用随机数，而是基于文本哈希做确定性模拟，便于复现 hash_value = int(hashlib.sha1(prompt.encode("utf-8")).hexdigest(), 16) success_prob = 0.2 if "good_template" in self.strategy.prompt_template: success_prob = 0.8 if "perfect_template" in self.strategy.prompt_template: success_prob = 0.95 success = (hash_value % 100) < (success_prob * 100) return { "task_id": task.task_id, "success": success, "tool_calls": tool_calls, "prompt": prompt, "strategy_version": self.strategy.version, }

说明一下：这里没有真正调用大模型，而是用一个模拟函数表达“不同策略会导致不同执行效果”的核心观察。你用真实 LLM 时，execute 方法内部会替换成：构建 Prompt -> 调用模型 -> 调用工具 -> 返回结果。框架本身不需要变化。

6.2 文件：meta_agent.py 与 supervisor.py

接下来是 MetaAgent 和监督器。

# meta_agent.py from agent_core import Strategy import copy class MetaAgent: """ 负责根据失败案例生成新的策略。 在更复杂的系统中，这个类内部会调用 LLM 进行推理。 """ def __init__(self, max_variants: int = 3): self.max_variants = max_variants def propose(self, current_strategy: Strategy, failed_tasks: list) -> list: """ 根据失败任务生成候选策略。 为了演示，这里仅生成几个固定变体。 真实场景中，可以让 LLM 分析失败原因后生成新的 Prompt 片段。 """ variants = [] # 变体 1：尝试追加 good_template if "good_template" not in current_strategy.prompt_template: s1 = copy.deepcopy(current_strategy) s1.prompt_template += " good_template" s1.tool_usage = list(set(current_strategy.tool_usage + ["use_tool_calc"])) s1.version = current_strategy.version + "-1" s1.parent_version = current_strategy.version variants.append(s1) # 变体 2：尝试升级为 perfect_template if "perfect_template" not in current_strategy.prompt_template: s2 = copy.deepcopy(current_strategy) s2.prompt_template += " perfect_template" s2.tool_usage = list(set(current_strategy.tool_usage + ["use_tool_calc"])) s2.version = current_strategy.version + "-2" s2.parent_version = current_strategy.version variants.append(s2) # 变体 3：简化方式，不改变模板，只调整工具调用顺序 s3 = copy.deepcopy(current_strategy) s3.tool_usage = ["use_tool_calc"] s3.version = current_strategy.version + "-3" s3.parent_version = current_strategy.version variants.append(s3) # 限制候选数量 return variants[: self.max_variants]

# supervisor.py from agent_core import BaseAgent class Supervisor: """ 监督器：评估候选策略是否比当前策略更好。 这里使用固定验证集和指标。真实场景中应使用更丰富的评估集。 """ def __init__(self, eval_tasks: list): self.eval_tasks = eval_tasks def evaluate(self, agent: BaseAgent) -> dict: """ 在验证集上运行智能体，统计成功率、平均工具调用数、平均耗时模拟值。 """ results = [] for task in self.eval_tasks: r = agent.execute(task) results.append(r) success_count = sum(1 for r in results if r["success"]) total = len(results) avg_tool_calls = sum(r["tool_calls"] for r in results) / total avg_latency = sum(hash(task.task_id) % 20 for task, r in zip(self.eval_tasks, results)) / total score = success_count / total * 100.0 - avg_tool_calls * 2.0 - avg_latency * 0.1 return { "success_rate": success_count / total, "avg_tool_calls": avg_tool_calls, "avg_latency": avg_latency, "score": score, } def accept(self, current_score: float, new_score: float) -> bool: """ 判断是否接受新策略。 这里设置一个简单阈值：新策略得分必须严格高于当前策略。 """ return new_score > current_score

这里的评估函数是刻意简化的。生产环境中，evaluate 方法返回的指标可能会更多，accept 逻辑也可能加入浮动容忍度、最低成功率要求等，避免因为单次波动而频繁换策略。

6.3 文件：main.py 递归驱动

main.py 是递归自我改进的入口，你要重点看 recursive_improve 这个函数。

# main.py from agent_core import BaseAgent, Strategy, Task from meta_agent import MetaAgent from supervisor import Supervisor def build_initial_strategy() -> Strategy: return Strategy( version="v0", parent_version=None, prompt_template="baseline_prompt", tool_usage=[], meta_info={"created_by": "human"}, ) def build_tasks() -> list: """构造一组演示任务，其中前 6 个作为验证集，后几个作为新任务集。""" tasks = [] for i in range(10): tasks.append( Task( task_id=f"task_{i}", description=f"demo task {i}", input_data={"index": i}, expected_output={"success": True}, ) ) return tasks def recursive_improve( current_strategy: Strategy, current_agent: BaseAgent, meta_agent: MetaAgent, supervisor: Supervisor, all_tasks: list, depth: int = 1, ) -> Strategy: """ 递归改进的核心逻辑。 depth 表示递归深度。depth=1 表示只改进任务策略； depth=2 表示再对“改进方法”本身进行改进。 演示中我们用一个简化实现：每一层都会运行一次"失败分析 -> 生成候选 -> 评估 -> 接受/拒绝"。 """ if depth <= 0: return current_strategy print(f"===== 开始递归深度 {depth} 层的改进 =====") # 1. 在全部任务上运行当前策略，找到失败任务 eval_tasks = all_tasks[:6] failed_tasks = [] for task in eval_tasks: result = current_agent.execute(task) if not result["success"]: failed_tasks.append(task) if not failed_tasks: print("当前策略在验证集上全部成功，无需改进。") return current_strategy print(f"发现 {len(failed_tasks)} 个失败任务，开始生成候选策略...") # 2. 元智能体提出候选策略 candidates = meta_agent.propose(current_strategy, failed_tasks) # 3. 用当前策略得分做基准 current_score = supervisor.evaluate(current_agent)["score"] print(f"当前策略得分: {current_score:.2f}") best_candidate = current_strategy best_score = current_score for candidate in candidates: candidate_agent = BaseAgent(strategy=candidate) candidate_score = supervisor.evaluate(candidate_agent)["score"] print(f"候选策略 {candidate.version} 得分: {candidate_score:.2f}") if supervisor.accept(current_score, candidate_score) and candidate_score > best_score: best_candidate = candidate best_score = candidate_score # 4. 如果找到更优策略，替换当前策略 if best_candidate.version != current_strategy.version: print(f"接受新策略: {best_candidate.version}") return recursive_improve( current_strategy=best_candidate, current_agent=BaseAgent(best_candidate), meta_agent=meta_agent, supervisor=supervisor, all_tasks=all_tasks, depth=depth - 1, ) # 5. 如果没有更优策略，停止 print("没有找到更优策略，保持当前版本。") return current_strategy if __name__ == "__main__": tasks = build_tasks() initial_strategy = build_initial_strategy() initial_agent = BaseAgent(initial_strategy) meta = MetaAgent(max_variants=3) supervisor = Supervisor(eval_tasks=tasks[:6]) final_strategy = recursive_improve( current_strategy=initial_strategy, current_agent=initial_agent, meta_agent=meta, supervisor=supervisor, all_tasks=tasks, depth=3, ) print("最终策略版本:", final_strategy.version)

运行方法很简单：

cd meta_n_demo python main.py

如果你使用的 Python 环境中没有 json5，先执行：

pip install json5 pyyaml

不需要真实 API Key，因为这段演示用的是规则模拟。

7. 运行结果与效果验证

跑完 main.py 后，你会看到类似下图的输出（具体数字会因你的 Python 版本和哈希算法略有不同，但结构一致）：

===== 开始递归深度 3 层的改进 ===== 发现 4 个失败任务，开始生成候选策略... 当前策略得分: 28.53 候选策略 v0-1 得分: 55.12 候选策略 v0-2 得分: 60.34 候选策略 v0-3 得分: 32.05 接受新策略: v0-2 ===== 开始递归深度 2 层的改进 ===== 发现 1 个失败任务，开始生成候选策略... 当前策略得分: 60.34 候选策略 v0-2-1 得分: 60.20 候选策略 v0-2-2 得分: 60.30 候选策略 v0-2-3 得分: 58.44 没有找到更优策略，保持当前版本。 最终策略版本: v0-2

这个输出说明三件事：

1. 元智能体成功将策略从 v0 改进到 v0-2，得分从 28.53 提升到 60.34。
2. 在下一轮递归中，候选策略都没有显著超过当前策略，系统自动停止，避免无止境修改。
3. 最终策略版本可追溯，父版本是 v0，改进原因是候选 v0-2 在验证集上表现更好。

如果你把递归深度从 3 改成 1，会发现系统只做一轮改进就结束。如果把 depth 改成 10，大概率也会在第二轮后停止，因为它已经没有明显改进空间。这就是“递归改进”和“盲目循环”的一个重要区别：递归改进需要有一个明确的停止条件，通常是“收益不再显著”。

不过，这里必须诚实说明：以上输出是规则模拟的结果，不是真实大模型测试数据。真实场景下，你替换成 LLM 后，输出会不稳定，因为模型生成候选策略的随机性会更大。这也是为什么你需要一套固定的评测集来稳定评估。

8. 常见问题与排查思路

下面按我的实际经验，列出递归自我改进系统最常遇到的几个问题。

在真实项目中，最危险的其实是第一个问题：改进到一定程度后不再提升。很多团队会把它误认为“递归失效”，于是继续增加递归深度。但实际瓶颈往往在元智能体生成的候选策略多样性不够。你不改变“生成改进建议”的模板和算法，只增加递归次数，就像用同一个死循环去撞墙，次数越多，只会越浪费资源，不会得到新结果。

9. 最佳实践与工程建议

最后这部分，我按生产环境的标准，给出几条可落地的建议。

9.1 固定评测集比递归算法更重要

无论你的递归深度是 2 还是 10，没有稳定评测，一切改进都是噪声。我建议每个项目从第一天开始就维护三组数据集：

• 开发集：用于日常调试和策略快速验证。
• 验证集：用于元智能体自动评估候选策略。
• 测试集：在最终发布前使用，防止系统在验证集上过拟合。

评测集要尽量接近真实用户场景，包括正常输入、边界输入、错误输入。如果条件允许，加入自动化断言比让大模型打分更可靠。

9.2 策略版本入库

每次策略变更，都必须记录：

• 父版本号。
• 改进触发的原因，比如“哪些失败任务触发”。
• 候选策略内容差异。
• 新旧策略的评测指标对比。
• 是否被接受，为什么。

这些信息应该写入数据库或 Git 管理，而不是只保存在日志里。没有历史版本管理，你根本无法定位“从哪个版本开始劣化”。

9.3 设置硬性安全边界

在未经验证之前，不要直接把新策略放到生产环境中。建议在元智能体和监督器之间增加一个“人工确认”或“灰度发布”环节。

安全边界至少包括：

• 递归深度上限，比如默认 3。
• 单轮候选策略数量上限，比如默认 5。
• 单个策略最大 Token 消耗。
• 工具调用类型白名单。
• 回滚间隔：如果新策略在生产环境连续失败 N 次，自动回滚到上一个稳定版本。

如果你在金融、医疗等风险高的领域使用智能体，这些边界不是可选项，而是必须项。

9.4 不要追求“全自动”，而是追求“高质量建议”

很多团队看到 Meta^n 后，会幻想做一个完全无人值守的系统。但以目前大模型的稳定性，全自动策略更新更像是个理想实验。

更稳妥的做法是：元智能体自动生成改进建议，监督器批量验证，最后由工程师做最终审批。最理想的状态是，人类工程师从“手动调 Prompt”变成“每天审核一批高质量改进建议”。这个转变本身，已经是很大的效率提升。

9.5 用横切指标防止局部优化

如果只以“任务成功率”作为唯一指标，智能体很容易学会偷懒。比如只回答“抱歉，我无法解决”，成功率可能很高，但用户满意度极低。

因此，建议同时监控多个指标：

• 用户最终交互轮数。
• 平均回复长度。
• 工具调用是否真实产生作用。
• 任务完成耗时。
• 用户反馈或点赞率。

在监督器中，把这些指标加权组合，形成综合评分。不要只盯一个数。

10. 总结与后续学习方向

Meta^n 的核心贡献，是把“自我改进”从一句营销话术变成了可工程化的递归结构。它不像普通的 Auto-Fix 那样只针对单次尝试做修补，而是尝试把“改进能力”本身纳入优化范围。从这个意义上说，它确实比传统反思循环走得更远。

但真正的难点始终没变：评估是否可靠、策略版本是否可追踪、递归停止条件是否清晰。你可以先把我上面那一套最小系统跑通，替换成自己的任务和真实 LLM，然后逐步增加候选策略的生成方式、更复杂的监督器、更完善的策略库。等这一步稳定了，再考虑 Meta² 甚至 Meta³。

接下来的学习方向，我建议按三阶段走：

第一阶段，把递归深度控制为 1，做好“一个元智能体 + 一个策略库 + 稳定评测集”，吃透策略更新流程。

第二阶段，升级监督器，让它支持多指标加权评估和灰度发布，把自动接受改为半自动审核。

第三阶段，再做 Meta²，让元智能体分析失败案例时，不再靠固定模板，而是由一个更上层的元智能体来动态选择分析策略。

这条路没有捷径，但每走一步，系统都会比上一版更接近“能自动变好”的 Agent 状态。建议你在动手前，先把评测集和策略回滚机制准备好，再去追求递归深度。