企业官网建设流程全解析

Metan 分层自改进智能体是近期大模型智能体研究中比较受关注的方向。它要解决的核心问题不是“某个任务能不能跑通”，而是“智能体在完成一次次任务之后，能不能自动发现自己的不足，并在下一次执行前自动调整策略”。与常见的固定 Prompt Agent 相比，分层自改进智能体把反思、评估、策略更新这些都纳入系统内部循环，而不是等开发者从日志里发现问题再手动改提示词。Metan 这个研究方向的巧妙之处，在于它强调“分层”而不是“整体改进”：先规划、再执行、再评估、再改进，每一层只负责一件事。这样既降低改进的盲目性，也方便定位问题。

这篇文章会围绕分层自改进智能体的核心概念、模块设计、最小实现、参数取舍、常见坑和生产落地展开。你可以用这套思路去设计自己的 Agent 原型，也可以把它改造成自动测试、数据处理、流程优化等场景下的可复用框架。需要说明的是，文章中的代码是用于演示思路的最小示例，明尼苏达大学与首尔大学研究团队在论文中的实验设计、数据集和评测指标，应以原始论文为准。

1. 先理解 Metan 分层自改进智能体的核心思路

1.1 自改进智能体解决什么问题

传统的大模型智能体开发流程是：开发者设计 Prompt，定义工具调用方式，然后把任务交给 Agent 执行。任务失败后，开发者查看日志，分析失败原因，修改 Prompt 或调整调用逻辑，再重新执行。这个过程有两个明显问题：一是反馈闭环依赖人工，效率低；二是修改往往针对单个任务，缺少对整体策略的系统性改进。

自改进智能体把“失败分析”和“策略调整”自动化。它会在每轮任务结束后，根据执行结果生成评估信号，再把这些信号汇总成改进动作。改进动作可能包括：修改 Prompt 模板、调整任务拆解方式、改变工具调用顺序、更新参数阈值等。

举个例子，假设智能体需要批量处理不同格式的简历。固定 Prompt 可能在处理 Markdown 格式时表现很好，但处理 PDF 扫描件时频繁失败。自改进机制会自动统计失败类型，发现“PDF 扫描件”这一类任务失败率偏高，然后调整策略，比如在规划层增加“先做 OCR 预处理”的步骤，或者在执行层选择另一个解析工具。这个调整不需要开发者干预。

要特别注意的是，自改进不等于“模型变大”或“无限重试”。它的本质是让系统能够根据反馈信号持续调整行为，是一种系统层面的能力，而不是模型参数层面的训练调整。

1.2 分层到底分的是哪几层

Metan 提出的“分层自改进”，一个重要设计是把智能体的能力拆成多个层次，每一层职责清晰，层与层之间通过稳定的接口通信。

在常见工程实现中，可以划分为四层：

这种分层方式与软件架构中的分层思想一脉相承。数据仓库分层会把数据流转拆成 ODS、DWD、DWS、ADS 多层，每一层只做一类处理，方便排查和维护。嵌入式软件架构设计也经常从分层思想出发，把驱动、中间件、应用层分离，再结合状态机控制逻辑流转。自改进智能体采用同样思路，核心价值是把“思考”和“执行”分离，把“改进”和“使用”分离。

这里最容易误解的地方是：分层不是简单的“把代码拆成几个文件”，而是要求每一层有明确的职责边界和稳定的输入输出。如果只是表面分层，实际代码仍然互相穿透，那改进时会遇到和单层系统一样的混乱。

1.3 为什么“分层”能降低自改进的难度

如果智能体只有一个巨大的循环，内部同时包含任务理解、动作生成、结果解析和策略修改，那么当执行效果变差时，很难判断问题出在哪个环节。是 Prompt 写得不好？是工具选错了？是评估指标不合理？还是策略更新步长太大？信息混在一起，排查成本非常高。

分层之后，每一层可以被独立观察和独立修改。元改进层只负责产生策略变更，不直接碰执行代码；执行层只负责执行，不关心策略是怎么来的；规划层只根据当前策略生成计划，不需要理解底层工具的每一个细节。

这样一来，自改进过程就变成了一个更稳定的控制回路：

1. 规划层根据当前策略生成计划。
2. 执行层执行计划并返回结果。
3. 评估层计算任务得分并给出问题列表。
4. 元改进层根据问题列表更新策略。
5. 下一轮规划层使用新策略。

每轮循环只改变一处“变量”，定位问题就简单得多。比如执行成功率低，可以先看是不是重试机制不够；如果规划质量低，再看是否是任务拆解策略需要调整。这种“一次只改一层”的做法，是保证自改进系统不失控的关键。

注意：分层不是为了追求架构上的美观，而是为了让“反馈信号”能准确定位到“产生问题的环节”。如果分层后仍然无法定位问题，那说明层与层之间的职责定义还不够清晰。

2. 从研究框架到工程架构：分层自改进的模块划分

2.1 四个核心模块：感知、规划、执行、元改进

在研究框架中，模块划分可能偏向算法层面；落到工程上，则需要把每个模块当成一个可独立测试的组件来设计。

感知层的职责是接收外部任务，并把它转换成统一的结构化表示。实际项目中，任务可能来自用户输入、消息队列、文件或数据库。感知层需要做的是字段标准化、格式校验和基础清洗，避免规划层看到各种不一致的任务格式。

规划层是智能体“思考”的地方。它根据当前策略，把任务拆解成若干动作。动作类型可以是调用搜索、读取文件、调用大模型生成文本、写入数据库等。规划层不直接执行动作，只负责生成动作序列，这样便于评估和改进拆解逻辑。

执行层是最接近“物理世界”的一层。它负责把规划层产出的动作变成真实调用。每个动作都应该返回结构化结果，至少包含状态、输出、错误信息和耗时。

元改进层是自改进系统的核心。它不直接参与具体任务执行，而是观察一批任务的表现，分析失败规律，然后决定是否需要修改策略库。策略库中保存的是规划层和执行层读取的参数，包括 Prompt 模板、重试次数、动作优先级、工具选择规则等。

2.2 数据流与控制流：“谁”能改“什么”

分层之后，重要的是明确数据流和控制流的关系。

数据流的顺序是：

任务输入 -> 感知层 -> 结构化任务 -> 规划层 -> 动作计划 -> 执行层 -> 执行结果 -> 评估层 -> 评分与问题列表 -> 元改进层 -> 策略更新 -> 策略库 -> 影响下一轮规划层

控制流的重点是：元改进层只能修改策略库，不能直接修改执行层的代码；规划层只能读取策略库，不能在任务中途随意改变策略；执行层只负责执行当前计划，不接收未经验证的策略更改。

这种限制看起来有些“死板”，但非常必要。如果执行层在任务中途发现策略被修改，那么同一批任务的评估标准就不一致了，后续的改进判断也会失真。正确的做法是：批任务运行结束后，统一评估，然后再决定是否发布新策略。

在工程中，可以用版本号把策略管理起来。每次改进后生成新版本，并记录该版本是在哪一批任务之后生成的，评估结果如何。这样一旦新策略表现不佳，可以快速回滚到上一个版本。

2.3 层间接口要用稳定消息结构

分层架构是否可靠，很大程度上取决于接口设计。如果层与层之间传递的是内部对象，一旦某一层实现变化，其他层跟着崩。更稳定的做法是使用 JSON 或字典结构，并提前定义好 schema。

下面是四个核心模块的最小接口示例：

class Planner: def plan(self, task: dict) -> list[dict]: # 输入结构化任务，输出动作列表 ... class Executor: def execute(self, action: dict) -> dict: # 输入单个动作，输出结构化结果 ... class Evaluator: def evaluate(self, task: dict, plan: list[dict], results: list[dict]) -> dict: # 输出评分与问题列表 ... class MetaLearner: def improve(self, history: list[dict]) -> bool: # 根据历史记录更新策略，返回是否发生变化 ...

接口稳定的好处有三个：第一，各层可以并行开发；第二，任何一层都可以单独测试；第三，策略变更可以被隔离在元改进层与策略库之间，不会因为一次调整引起全链路连锁反应。

3. 用 Python 实现一个最小可运行的分层自改进闭环

3.1 环境准备与最小依赖

这个最小实现只需要 Python 3.9 及以上版本，使用标准库即可，不需要安装大模型 SDK。核心依赖是dataclasses、random、typing。如果你希望在 Jupyter Notebook 中逐段观察，也可以直接复制代码到 notebook 中运行。

为了让结果可复现，示例中会固定随机种子。实际项目中，随机模拟需要替换成真实的大模型调用和工具调用。

3.2 定义任务结果、策略和动作结果

先定义几个基础数据结构。它们的作用是让各层传递的数据格式保持一致。

from __future__ import annotations from dataclasses import dataclass, field from typing import Any, Optional import random @dataclass class ActionResult: action_id: str status: str # success / failed / retryable output: Any = None error: Optional[str] = None latency_ms: float = 0.0 @dataclass class TaskRecord: task: dict plan: list[dict] = field(default_factory=list) results: list[ActionResult] = field(default_factory=list) score: float = 0.0 issues: list[str] = field(default_factory=list) @dataclass class Strategy: prefix: str = "请先确认任务目标，再选择合适工具" max_retry: int = 2 use_cache: bool = True

ActionResult是执行层的结果对象，必须包含成功状态和错误信息，这样评估层才能分析失败原因。TaskRecord记录一次任务从计划到结果的完整信息，它是元改进层的输入。Strategy是策略库中的一份参数集，规划层和执行层都会读取它。

3.3 实现 Planner、Executor、Evaluator、MetaLearner

下面是四个模块的具体实现。这个例子模拟了一个简单场景：任务包含三种难度，执行结果受到任务难度和策略参数影响。

class Planner: def __init__(self, strategy: Strategy): self.strategy = strategy def plan(self, task: dict) -> list[dict]: plan = [{"type": "analyze", "target": task.get("target")}] if "确认" in self.strategy.prefix: plan.append({"type": "confirm", "target": task.get("target")}) plan.append({"type": "execute", "target": task.get("target")}) return plan class Executor: def execute(self, action: dict) -> ActionResult: target = action.get("target", "") difficulty = {"简单": 0.1, "中等": 0.4, "困难": 0.8}.get(target, 0.5) if random.random() < difficulty: return ActionResult( action_id=action.get("type", ""), status="failed", error="simulated_failure", ) return ActionResult( action_id=action.get("type", ""), status="success", output=f"done_{target}", ) class Evaluator: def evaluate(self, task: dict, plan: list[dict], results: list[ActionResult]) -> tuple[float, list[str]]: issues = [] if not plan: issues.append("empty_plan") success_count = sum(1 for r in results if r.status == "success") total = len(results) score = success_count / total if total else 0.0 if score < 0.5: issues.append("low_success_rate") if any(r.error == "simulated_failure" for r in results): issues.append("simulated_failure") return score, issues class MetaLearner: def __init__(self, strategy: Strategy): self.strategy = strategy def improve(self, history: list[TaskRecord]) -> bool: if len(history) < 3: return False recent = history[-3:] avg_score = sum(r.score for r in recent) / len(recent) if avg_score < 0.4: self.strategy.max_retry = min(self.strategy.max_retry + 1, 5) if "确认" not in self.strategy.prefix: self.strategy.prefix = "请先确认任务目标，再选择合适工具" else: if self.strategy.max_retry > 1: self.strategy.max_retry -= 1 return True

Planner根据策略前缀决定是否要在执行前增加“确认”动作。Executor用随机概率模拟执行失败，难度越高失败概率越大。Evaluator根据成功率和问题类型生成评估结果。MetaLearner则是实现自改进的关键：它看最近 3 条任务记录，如果平均分很低，就增加重试次数并保留确认步骤；如果表现好转，就逐步减少重试次数。

这里是一个简化版的控制策略。真实系统中，策略更新通常要基于更大样本，并且会引入离线评估和 A/B 验证。

3.4 运行三层任务并观察策略变化

再写一个LayeredAgent把上述模块串起来，并运行一组任务。

class LayeredAgent: def __init__(self): self.strategy = Strategy() self.planner = Planner(self.strategy) self.executor = Executor() self.evaluator = Evaluator() self.learner = MetaLearner(self.strategy) self.history: list[TaskRecord] = [] def run_task(self, task: dict) -> TaskRecord: record = TaskRecord(task=task) record.plan = self.planner.plan(task) for action in record.plan: result = self.executor.execute(action) record.results.append(result) record.score, record.issues = self.evaluator.evaluate(task, record.plan, record.results) self.history.append(record) return record def improve(self) -> bool: return self.learner.improve(self.history) def current_strategy(self) -> dict: return { "prefix": self.strategy.prefix, "max_retry": self.strategy.max_retry, } random.seed(42) agent = LayeredAgent() tasks = [{"target": "简单"}, {"target": "中等"}, {"target": "困难"}] * 5 for i, task in enumerate(tasks, 1): record = agent.run_task(task) print(f"第 {i} 轮: score={record.score:.2f}, issues={record.issues}") if i % 3 == 0: changed = agent.improve() if changed: print("策略变化:", agent.current_strategy()) else: print("策略不变:", agent.current_strategy())

运行结果会显示每一轮任务的得分。由于固定了随机种子，输出整体可复现：前几轮“困难”任务会比较容易出现失败，MetaLearner会在连续几轮低分后增加max_retry，后续成功率会有所上升。

这个验证过程主要检查三点：

• 程序是否能完整运行。
• 策略中的max_retry是否随着低分批次发生变化。
• 低分问题是否从“到处失败”逐步变成“集中在困难任务”。

这样就能确认分层自改进闭环已经跑通。

4. 关键参数与设计取舍：分层粒度、改进频率、评估指标

4.1 分层粒度：太粗和太细都会失控

分层数量没有绝对标准，常见范围为 3 到 5 层。太少，反馈信号难以定位到具体环节；太多，层与层之间的通信开销和维护成本会显著上升。

判断粒度是否合适，可以参考一个原则：一次改进动作是否只需要改动一层？如果调整策略时经常要同时改三个层，说明分层粒度有问题。

在实际项目中，推荐从 4 层开始：感知层、规划层、执行层、元改进层。后续根据业务复杂度，可以把执行层拆成工具层和状态管理层，也可以把元改进层拆成评估子模块和策略更新子模块。

4.2 改进对象：先改策略，再改提示词，最后才改结构

自改进系统可以修改的对象很多，但优先级不同。

最安全的是修改策略参数，比如重试次数、超时时间、缓存开关。这类修改影响范围小，回滚容易。其次是修改 Prompt 模板，因为只影响规划层的生成逻辑，不改变模块接口。再往后是修改工具调用顺序，这会影响执行结果，需要更谨慎。最后才是修改模块结构，比如把执行层从单工具改成多工具路由，这类变更通常需要重新做接口兼容测试。

元改进层在自动修改策略时，应该设定“最大修改范围”。比如只允许修改策略参数和 Prompt 模板，不允许自动改代码结构。结构变更仍然需要人工介入。

4.3 改进频率与评估窗口

改进频率直接关系到系统稳定性。

每执行一个任务就立刻改进，风险很高。单个任务的结果受到随机性影响很大，可能只是因为一次偶然失败就触发策略变化。更合理的做法是累积一个评估窗口，比如最近 10 条或 50 条任务记录，然后统一计算平均分和失败模式，再决定是否改进。

评估窗口越大，决策越稳定，但反应越慢。窗口越小，反应越快，但抖动越大。初始阶段可以用较小窗口快速试探，生产环境建议用较大窗口并配合固定验证集。

4.4 参数速查表

5. 常见问题排查：不收敛、层间耦合、反馈振荡与回归

5.1 问题一：自改进循环不收敛

现象：任务得分长期偏低，或者在一段时间内反复波动，策略参数不断变化但整体效果没有提升。

可能原因包括：改进信号噪声太大、评估指标与真实目标不一致、策略更新步长过大、评估窗口太小。

检查方式：

• 固定随机种子，重复运行同一组任务，确认结果是否可复现。
• 打印每个批次的issues分布，看失败原因是否集中。
• 对比新旧策略在“同一组任务”上的表现，而不是在不同任务集合上比较。
• 检查策略是否被反复改回，例如先增加重试次数，分数下降后又减回去。

解决方案：

• 增加评估窗口，减少单次随机失败的影响。
• 缩小策略更新步长，每次只改一个参数。
• 使用固定的验证集做离线评估，验证通过后再发布。

5.2 问题二：层间接口频繁变动，改一处崩一片

现象：元改进层只修改了策略参数，执行层却报出字段缺失，或者规划层生成了执行层无法理解的动作。

根本原因通常是层间直接传递了内部对象，或者没有对消息结构做校验。

检查方式：

• 打印执行层收到的action字段，确认是否缺少type或target。
• 查看策略更新前后，规划层生成的计划结构是否发生变化。
• 检查各层之间是否共用了同一个 schema 定义。

解决方案：

• 统一使用 JSON 或字典作为层间消息格式。
• 为层间消息增加版本号字段，字段变更时保留旧版本兼容。
• 在入口处增加 schema 校验，字段缺失时快速失败，而不是把错误带到执行层。

5.3 问题三：评估指标抖动，改进方向反复横跳

现象：策略先增加确认步骤，分数提升；下一批任务又减少了确认步骤，分数下降；之后又恢复，形成振荡。

原因是评估指标方差过大，或者每次改进同时改动了多个参数，无法判断是哪个参数起了作用。

检查方式：

• 把评估数据按照任务难度、任务类型分成多个桶，观察分数波动来自哪一桶。
• 对比连续几个评估窗口的平均分，而不是看单条任务分数。
• 检查每次改进是否只修改了一个策略参数。

解决方案：

• 增大评估窗口。
• 保持固定验证集，验证集不参与策略更新。
• 每次改一个参数，记录该参数变更前后的完整评估结果。

5.4 问题四：新策略提升平均分，却让关键场景回归

现象：整体平均分上涨，但某个重要任务类型的成功率反而下降。

原因通常是评估时只看了整体平均分，忽略了场景分布。

检查方式：

• 按任务类型拆分成功率，单独观察困难任务、长任务或关键业务场景。
• 查看新策略在哪些issues上出现新增类型。

解决方案：

• 为关键场景设置独立指标，比如“困难任务成功率不得低于 0.6”。
• 引入红线指标，任何策略如果导致红线指标下降，即使平均分提升也不允许发布。
• 建立回归测试集，每次策略发布前自动运行。

注意：自改进系统的核心风险不是“不改进”，而是“改错方向”。评估指标设计得越细，方向偏掉的风险越小。

6. 从研究原型到生产落地：工程化建议

6.1 学习环境、研究环境、生产环境的差异

同一个分层自改进框架，在不同环境下的目标完全不同。

学习环境可以用模拟数据快速验证。研究环境需要使用固定数据集和离线评估。生产环境则必须考虑线上流量、真实用户反馈、调用成本、失败重试对下游系统的影响。

6.2 生产级自改进系统至少要有的 6 个机制

第一，配置外置化。策略参数不要写死在代码里，要放在配置中心或数据库中，这样元改进层才能通过标准接口更新策略，而不需要重新发布代码。

第二，策略版本管理。每次改进都要生成新版本，并记录触发改进的评估数据。没有版本管理，就无法回溯“是哪一次改进导致效果变差”。

第三，固定评估集与回归集。评估集用于判断策略好坏，回归集用于防止关键场景退化。两者都不能参与策略训练过程。

第四，灰度发布与自动回滚。新策略先在小流量上观察，如果关键指标下降超过阈值，自动回滚到上一个版本。

第五，日志与监控。每条任务需要有一个trace_id，关联任务输入、计划、执行结果、策略版本和评估结果。否则策略出了问题，根本无法定位。

第六，成本与速率限制。自改进系统在调整重试次数或者工具调用顺序时，可能成倍增加 API 调用量和下游请求量。必须设置单任务最大调用次数、单策略最大成本等限制。

6.3 发布前检查清单（可直接复制使用）

• [ ] 是否使用固定评估集，评估集是否与训练集分离。
• [ ] 策略是否带版本号，是否记录了触发改进的任务范围。
• [ ] 本次改进是否只修改了一个策略参数。
• [ ] 是否设置了关键场景的红线指标。
• [ ] 是否在回归集上运行通过。
• [ ] 是否有灰度发布方案和一键回滚入口。
• [ ] 是否限定了单任务最大重试次数和最大调用成本。
• [ ] 日志中是否能通过trace_id查到任务全链路。
• [ ] 是否有人工审核入口，防止自动策略更新绕过业务规范。
• [ ] 是否区分了学习环境配置和生产环境配置。

7. 扩展方向：用分层自改进思路改造更多 AI 系统

7.1 从“调 Prompt”到“调策略层”

很多开发者在实际工作中已经手动做过类似事情：任务效果不好，就修改 Prompt，再跑一次。分层自改进把这种人工操作变成自动化流程之后，Prompt 就不再是“写一次就不动”的静态文本，而是策略层里的一个可更新参数。

更进一步，可以让大模型生成结构化的反思报告，再由元改进层从反思报告中提取可执行的策略变更。这样就把“语言层面的反思”和“代码层面的策略更新”连接起来，形成一个更完整的自改进回路。

7.2 与状态机、规则引擎结合

分层自改进智能体并不排斥传统软件工程手段。相反，可以用状态机来管理自改进循环本身。每一轮任务可以建模为“等待任务 -> 规划中 -> 执行中 -> 评估中 -> 策略更新中 -> 发布完成”等状态，每个状态有明确的进入条件和退出条件。

这种设计的好处是，自改进流程不会因为异常输入或策略更新失败而陷入不可控状态。状态机加上分层架构，正好对应嵌入式软件架构设计中“从分层思想到状态机实现”的工程思路，是一种可维护、可移植、可测试的落地方式。

7.3 多智能体协作中的分层自改进

当系统中有多个 Agent 协作时，每个 Agent 可以分别维护自己的策略库。元改进层不只是单个 Agent 内部的模块，也可以升级为协作层，负责汇总多个 Agent 的经验，形成共享知识库。

例如，一个 Agent 在文本分类任务中发现需要先做关键词归一化，这个经验可以被写入共享策略库，另一个 Agent 在处理类似任务时直接复用。这种“经验共享”模式，本质上也是分层思想的延伸：执行层负责个体任务，策略层负责群体经验，元改进层负责跨 Agent 的策略更新。

自改进智能体是一个可以不断深入的实践方向。动手做的时候，建议从一个很小的闭环开始：选定一个任务类型，设计最简单评估规则，加入一个可控的策略参数，让系统跑几十轮之后观察策略是否自动变化。先把循环跑通，再去处理复杂场景、优化评估指标和增加生产保障措施。这样积累下来的经验，会比直接套用复杂框架更扎实。