Metan 分层自改进智能体是近期大模型智能体研究中比较受关注的方向。它要解决的核心问题不是“某个任务能不能跑通”而是“智能体在完成一次次任务之后能不能自动发现自己的不足并在下一次执行前自动调整策略”。与常见的固定 Prompt Agent 相比分层自改进智能体把反思、评估、策略更新这些都纳入系统内部循环而不是等开发者从日志里发现问题再手动改提示词。Metan 这个研究方向的巧妙之处在于它强调“分层”而不是“整体改进”先规划、再执行、再评估、再改进每一层只负责一件事。这样既降低改进的盲目性也方便定位问题。这篇文章会围绕分层自改进智能体的核心概念、模块设计、最小实现、参数取舍、常见坑和生产落地展开。你可以用这套思路去设计自己的 Agent 原型也可以把它改造成自动测试、数据处理、流程优化等场景下的可复用框架。需要说明的是文章中的代码是用于演示思路的最小示例明尼苏达大学与首尔大学研究团队在论文中的实验设计、数据集和评测指标应以原始论文为准。1. 先理解 Metan 分层自改进智能体的核心思路1.1 自改进智能体解决什么问题传统的大模型智能体开发流程是开发者设计 Prompt定义工具调用方式然后把任务交给 Agent 执行。任务失败后开发者查看日志分析失败原因修改 Prompt 或调整调用逻辑再重新执行。这个过程有两个明显问题一是反馈闭环依赖人工效率低二是修改往往针对单个任务缺少对整体策略的系统性改进。自改进智能体把“失败分析”和“策略调整”自动化。它会在每轮任务结束后根据执行结果生成评估信号再把这些信号汇总成改进动作。改进动作可能包括修改 Prompt 模板、调整任务拆解方式、改变工具调用顺序、更新参数阈值等。举个例子假设智能体需要批量处理不同格式的简历。固定 Prompt 可能在处理 Markdown 格式时表现很好但处理 PDF 扫描件时频繁失败。自改进机制会自动统计失败类型发现“PDF 扫描件”这一类任务失败率偏高然后调整策略比如在规划层增加“先做 OCR 预处理”的步骤或者在执行层选择另一个解析工具。这个调整不需要开发者干预。要特别注意的是自改进不等于“模型变大”或“无限重试”。它的本质是让系统能够根据反馈信号持续调整行为是一种系统层面的能力而不是模型参数层面的训练调整。1.2 分层到底分的是哪几层Metan 提出的“分层自改进”一个重要设计是把智能体的能力拆成多个层次每一层职责清晰层与层之间通过稳定的接口通信。在常见工程实现中可以划分为四层层次职责输入输出感知层收集任务描述、上下文、历史反馈原始任务、环境状态结构化任务对象规划层将任务拆解为可执行动作序列结构化任务对象动作计划执行层调用工具、API、函数完成具体动作单个动作结构化执行结果元改进层评估整体结果更新策略库任务执行历史新策略、改进记录这种分层方式与软件架构中的分层思想一脉相承。数据仓库分层会把数据流转拆成 ODS、DWD、DWS、ADS 多层每一层只做一类处理方便排查和维护。嵌入式软件架构设计也经常从分层思想出发把驱动、中间件、应用层分离再结合状态机控制逻辑流转。自改进智能体采用同样思路核心价值是把“思考”和“执行”分离把“改进”和“使用”分离。这里最容易误解的地方是分层不是简单的“把代码拆成几个文件”而是要求每一层有明确的职责边界和稳定的输入输出。如果只是表面分层实际代码仍然互相穿透那改进时会遇到和单层系统一样的混乱。1.3 为什么“分层”能降低自改进的难度如果智能体只有一个巨大的循环内部同时包含任务理解、动作生成、结果解析和策略修改那么当执行效果变差时很难判断问题出在哪个环节。是 Prompt 写得不好是工具选错了是评估指标不合理还是策略更新步长太大信息混在一起排查成本非常高。分层之后每一层可以被独立观察和独立修改。元改进层只负责产生策略变更不直接碰执行代码执行层只负责执行不关心策略是怎么来的规划层只根据当前策略生成计划不需要理解底层工具的每一个细节。这样一来自改进过程就变成了一个更稳定的控制回路规划层根据当前策略生成计划。执行层执行计划并返回结果。评估层计算任务得分并给出问题列表。元改进层根据问题列表更新策略。下一轮规划层使用新策略。每轮循环只改变一处“变量”定位问题就简单得多。比如执行成功率低可以先看是不是重试机制不够如果规划质量低再看是否是任务拆解策略需要调整。这种“一次只改一层”的做法是保证自改进系统不失控的关键。注意分层不是为了追求架构上的美观而是为了让“反馈信号”能准确定位到“产生问题的环节”。如果分层后仍然无法定位问题那说明层与层之间的职责定义还不够清晰。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_factorylist) results: list[ActionResult] field(default_factorylist) score: float 0.0 issues: list[str] field(default_factorylist) dataclass class Strategy: prefix: str 请先确认任务目标再选择合适工具 max_retry: int 2 use_cache: bool TrueActionResult是执行层的结果对象必须包含成功状态和错误信息这样评估层才能分析失败原因。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_idaction.get(type, ), statusfailed, errorsimulated_failure, ) return ActionResult( action_idaction.get(type, ), statussuccess, outputfdone_{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 TruePlanner根据策略前缀决定是否要在执行前增加“确认”动作。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(tasktask) 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 参数速查表参数含义常见范围调大影响调小影响推荐场景分层数智能体模块层级数量3-5解耦更好但维护成本高链路短但问题定位难默认 4 层评估窗口参与一次改进决策的任务数10-50决策稳定但反应慢反应快但抖动大初期 10生产 50改进阈值触发改进的最低平均分0.4-0.8改进更保守改进更激进初期 0.5生产 0.7回滚阈值新策略相对旧策略允许的最大下降幅度0.05-0.15容错高但风险高严格但容易频繁回滚0.1max_retry单个动作失败最大重试次数1-5成功率提高但成本增加节省成本但失败变多2-35. 常见问题排查不收敛、层间耦合、反馈振荡与回归5.1 问题一自改进循环不收敛现象任务得分长期偏低或者在一段时间内反复波动策略参数不断变化但整体效果没有提升。可能原因包括改进信号噪声太大、评估指标与真实目标不一致、策略更新步长过大、评估窗口太小。检查方式固定随机种子重复运行同一组任务确认结果是否可复现。打印每个批次的issues分布看失败原因是否集中。对比新旧策略在“同一组任务”上的表现而不是在不同任务集合上比较。检查策略是否被反复改回例如先增加重试次数分数下降后又减回去。解决方案增加评估窗口减少单次随机失败的影响。缩小策略更新步长每次只改一个参数。使用固定的验证集做离线评估验证通过后再发布。5.2 问题二层间接口频繁变动改一处崩一片现象元改进层只修改了策略参数执行层却报出字段缺失或者规划层生成了执行层无法理解的动作。根本原因通常是层间直接传递了内部对象或者没有对消息结构做校验。检查方式打印执行层收到的action字段确认是否缺少type或target。查看策略更新前后规划层生成的计划结构是否发生变化。检查各层之间是否共用了同一个 schema 定义。解决方案统一使用 JSON 或字典作为层间消息格式。为层间消息增加版本号字段字段变更时保留旧版本兼容。在入口处增加 schema 校验字段缺失时快速失败而不是把错误带到执行层。5.3 问题三评估指标抖动改进方向反复横跳现象策略先增加确认步骤分数提升下一批任务又减少了确认步骤分数下降之后又恢复形成振荡。原因是评估指标方差过大或者每次改进同时改动了多个参数无法判断是哪个参数起了作用。检查方式把评估数据按照任务难度、任务类型分成多个桶观察分数波动来自哪一桶。对比连续几个评估窗口的平均分而不是看单条任务分数。检查每次改进是否只修改了一个策略参数。解决方案增大评估窗口。保持固定验证集验证集不参与策略更新。每次改一个参数记录该参数变更前后的完整评估结果。5.4 问题四新策略提升平均分却让关键场景回归现象整体平均分上涨但某个重要任务类型的成功率反而下降。原因通常是评估时只看了整体平均分忽略了场景分布。检查方式按任务类型拆分成功率单独观察困难任务、长任务或关键业务场景。查看新策略在哪些issues上出现新增类型。解决方案为关键场景设置独立指标比如“困难任务成功率不得低于 0.6”。引入红线指标任何策略如果导致红线指标下降即使平均分提升也不允许发布。建立回归测试集每次策略发布前自动运行。注意自改进系统的核心风险不是“不改进”而是“改错方向”。评估指标设计得越细方向偏掉的风险越小。6. 从研究原型到生产落地工程化建议6.1 学习环境、研究环境、生产环境的差异同一个分层自改进框架在不同环境下的目标完全不同。环境主要目标策略更新方式回滚要求成本控制学习环境跑通闭环理解分层和反馈机制可以直接修改策略参数不严格不敏感研究环境复现实验指标验证改进效果离线跑多组实验对比策略版本需要记录实验版本需要控制 API 调用量生产环境稳定服务防止回归灰度发布逐步放量必须一键回滚必须监控成本学习环境可以用模拟数据快速验证。研究环境需要使用固定数据集和离线评估。生产环境则必须考虑线上流量、真实用户反馈、调用成本、失败重试对下游系统的影响。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 的策略更新。自改进智能体是一个可以不断深入的实践方向。动手做的时候建议从一个很小的闭环开始选定一个任务类型设计最简单评估规则加入一个可控的策略参数让系统跑几十轮之后观察策略是否自动变化。先把循环跑通再去处理复杂场景、优化评估指标和增加生产保障措施。这样积累下来的经验会比直接套用复杂框架更扎实。