明大和首尔大这个 Metan 分层自改进智能体研究最值得讨论的不是又多了个 Agent 模型变体而是它把“分层”和“自改进”这两个方向拧在一起。单层智能体自己总结错误、改改提示词很多框架已经能跑真正难的是让高层规划层和低层执行层各自改进、互不污染。这篇拆解主要面向两类人一类想把智能体从“能跑通 Demo”推到“能持续稳定跑任务”的开发者另一类在做 Agent 框架选型想弄明白分层架构到底解决了什么真实问题。需要先说清楚我这里不打算复述论文内部的实验指标也不准备假装自己读过完整源码。下面所有的模块设计和流程都是从“分层自改进智能体”这个研究方向做的工程化拆解。你可以把这当成一份阅读地图也可以直接当作一个可运行的实现框架来参考。1. 为什么“分层”和“自改进”必须放在一起看1.1 单层自改进为什么容易失控单层自改进的典型做法是把完整任务日志交给同一个 prompt让它总结失败原因再生成新的 prompt 或策略。问题在于一次失败的原因可能同时来自好几个层级任务拆解错了、工具参数错了、生成内容太长被截断、模型版本换了导致输出风格变化。这些原因混在一起时反思器很难给出精准修复合集。常见结果是它改掉了“工具调用参数”的问题但同时把“原本稳定的任务拆解策略”一起带偏了。改进后测试集分数波动很大不是模型随机性造成的而是策略更新把本来正确的部分覆盖了。我见过很多这类系统在一轮“看起来有效”的反思后原来能跑通的场景反而坏掉。原因不是反思逻辑写得差而是单层结构天然做不到精细归因。所有错误都反馈到同一个策略空间里任何一个新增规则都可能影响所有任务成本很高稳定性很低。1.2 分层之后改进信号变干净了如果把系统分成高层规划器和低层执行器失败信号可以先定位到层级是计划本身不合理还是某一步执行时工具参数或提示词有问题。定位清楚之后只有对应层会产生改进建议。高层改的是任务拆解方式、子任务顺序、目标理解策略。低层改的是工具调用方式、生成参数、单步提示词、输入输出解析规则。这样每个策略的更新边界都很小出问题时很容易回滚到上一个版本。分层不是为了表面架构好看而是为了让“改进”这件事可追踪、可验证、可回滚。这种设计还有一个隐性好处不同层级的改进频率不一样。高层规划策略可以比较稳定低层执行策略可能需要频繁调整。混在一起时你只能整体更新等于让稳定部分跟着不稳定部分一起承担风险。1.3 从标题看 Metan 大概在解决什么问题“Metan”这个命名和“分层”“自改进”放在一起我理解研究的核心大概率是让智能体在无需人工反复调整 prompt 的情况下通过多轮任务反馈自动优化自己的策略同时用分层结构避免自改进过程失控。如果你的实践场景是批量任务、多步骤任务、工具调用链特别长的场景这个方向值得重点关注。纯单轮问答或简单生成任务分层自改进带来的收益不会太明显反而会引入额外复杂度和 token 消耗。这也是一个判断点不是所有智能体系统都适合做分层自改进。2. 复现这个思路之前先把运行框架画清楚2.1 五个核心模块一个分层自改进智能体通常至少要有五个模块。少了任何一个系统都能跑但越往后越难排查。规划器负责把任务拆成子步骤、安排顺序对应“高层行为”。执行器负责具体执行每一步比如调用 LLM 生成、调用工具、读写文件。反思器在任务结束后收集完整执行轨迹和结果生成失败原因分析。评估器用统一标准给任务结果打分作为改进是否有效的信号。策略版本库保存规划器和执行器的策略版本包括 prompt、参数、路由规则支持对比和回滚。2.2 一次任务的完整循环核心循环是plan - execute - observe - reflect - update。先有一个计划然后按计划执行每一步中途记录观察和日志任务结束后统一反思最后决定是否更新策略。有个关键点不是每个任务结束都要触发反思。更稳妥的做法是普通任务只积累日志当评分低于阈值或者连续三次都失败在同一类任务上才触发反思。否则每一次失败都花额外 token 去改策略既贵又容易过度反应。分层的意义也在这里你可以让反思器先判断问题属于哪一层再决定是否更新那一层的策略而不是每次都更新全部。2.3 环境与工具条件现在想快速实验不一定要从零写框架。Coze、Dify、Codex 这类 Agent 平台都可以先把串行流程跑起来适合快速理解任务编排和工具调用逻辑。但它们默认更多提供编排能力自改进需要的反思、策略版本控制、自动测试和回滚还是要自己补。如果你准备本地复现建议至少准备好可调用的 LLM API最好是支持不同温度等生成参数切换的接口一个可编程的沙盒执行环境让智能体可以安全调用工具持久化存储用于保存任务日志、策略版本、评估记录统一的任务输入格式和结果评估脚本这是自改进能稳定工作的前提。注意先跑通一条任务的全流程再把反思和策略更新接进去。不要第一天就把整个系统一次性写完。3. 一个最小闭环的实现思路3.1 主循环伪代码这里给出一段通用伪代码不是论文源码只是一个可参考的骨架。真正落地时你需要根据自己的任务类型补评估函数、工具调用逻辑和调度策略。# 主循环plan - execute - observe - reflect - update for task in task_pool: plan planner.generate_plan(task, high_level_memory) execution_trace [] for step in plan: result executor.execute(step, low_level_memory) execution_trace.append(result) score evaluator.evaluate( tasktask, planplan, execution_traceexecution_trace ) if should_reflect(score): critique reflector.collect( tasktask, planplan, execution_traceexecution_trace, scorescore ) suggestions strategy_updater.propose(critique) accepted strategy_updater.apply_guardrails(suggestions) if accepted: strategy_versioning.commit( layercritique.target_layer, changesaccepted, metrics{score: score, cost: cost} )这段代码的核心价值在于更新策略之前先经过 guardrails 过滤并且每次提交都保留 metrics 信息。这样你才能判断“这次改进到底有没有用”。3.2 反思信息怎么设计反思器是自改进系统的发动机但并不需要让 LLM 完全自由发挥。建议把反思输出设计成结构化模板否则很容易出现空泛改进。反思信息至少要分三块客观轨迹任务输入、规划结果、每一步的执行参数、返回内容、错误类型、耗时、token 消耗。原因判断问题发生在规划层还是执行层是输入解析、工具选择、参数设置、输出格式还是任务本身超出能力范围改进建议建议修改哪个策略改成什么为什么这次修改能提升效果。原因判断这一块尤其重要。如果不带结构化模板LLM 很容易输出“下次要注意参数设置”这种无法落地的建议。你需要在 prompt 里明确约束判断维度并且让建议必须关联到具体策略字段。3.3 策略更新、白名单与回滚建议把策略当作配置而不是代码。更新时先创建一个新版本在小规模样例上测试效果通过后再发布。同时保留上一版本发布后如果失败率回升能快速回滚。还需要给策略加白名单和约束规则。例如提示词只能修改特定段落不允许删除安全限制温度参数只能在一定范围内调整工具路由规则不允许指向未授权工具。这样自改进就不会变成“智能体自己绕过限制”。回滚逻辑不能只靠人工盯。建议做成自动阈值新策略成功率比旧版低三个百分点以上自动回滚到上一版并记录回滚原因。人只能处理少量异常大量回滚必须由系统自己完成。3.4 关键参数怎么选反思触发频率默认每 10 到 20 个任务做一次反思或失败率达到 15% 以上时触发。策略测试比例新版策略先在 5% 到 10% 的任务样本上测试通过后再全量发布。回滚阈值新策略成功率比旧版低 3 到 5 个百分点时自动回滚。记忆窗口保留最近 100 到 200 条任务记录。太旧的记录不参与反思避免环境已经变化还拿旧噪声做依据。这些参数都要根据任务成本调整。如果你的任务单次成本很高应该减少反思频率增加测试样本量如果任务成本很低可以频繁反思但回滚阈值必须更严格。4. 评价一个自改进系统不能只看“最终跑通了”4.1 评测集要分三类自改进系统最怕的评测方式在一个固定任务池上反复迭代最后跑出一个看起来很漂亮的成功率。要避免这个问题评测集至少分三类固定验证集用来决定策略是否发布。留出测试集用来判断是否过拟合。这个集合在迭代过程中不参与策略选择。滚动新增集不断加入新任务检验泛化能力。单层自改进常见的致命问题就是在固定任务池上越跑越好换一批新任务又回到原地。分层自改进同样有这个问题所以评测设计从一开始就要做对。4.2 核心指标表指标看什么判断标准说明成功率完成率、正确率、通过率比上一版提升不超过阈值也算有效要区分验证集和测试集单任务成本token 消耗、API 耗时、工具调用次数提升效果不明显时降成本优先反思本身也会产生成本迭代稳定性连续多轮成功率波动幅度波动过大说明策略更新不可控单轮暴涨不如稳步上升失败趋势失败任务是否集中在同一类型分散失败比集中失败更难处理用于定位分层是否有效回滚次数策略发布后回滚比例回滚率过高说明改进质量差要记录回滚原因泛化差异验证集和滚动新增集成功率差差异过大说明过拟合新增集越接近真实场景越好人工介入次数需要人工修策略或改日志的次数生产环境应逐步减少但保留人审完全无人介入目前不现实4.3 分层有效性怎么量化要判断分层自改进是否真的比单层自改进好建议做一组对比实验而不是只跑一个版本。组 1单层自改进所有错误都反馈给同一份策略。组 2高层只改规划策略低层提示词固定。组 3低层只改执行策略规划逻辑固定。组 4高低层都允许自动更新。对比四个版本在相同任务集上的成功率、成本和回滚次数。关键观察点是组 4 是否真的比组 2、组 3 更好。如果提升幅度很小但成本翻倍说明你的场景可能根本不需要分层自改进或者分层粒度需要重新设计。4.4 日志可观测性自改进系统最怕黑盒。没有日志你根本没法判断一次效果回退是模型升级、数据变化还是智能体自己改坏了。至少记录这些字段每次任务的 trace_id当前生效的策略版本号模型版本和生成参数输入输出摘要耗时和 token 消耗评估分数是否触发反思是否更新策略更新了哪一层。日志字段要固定下来最好写成 JSON 格式方便后续做趋势分析和异常回溯。没有这个基础后面所有优化都只能靠猜。5. 实际落地时最容易踩的五个坑5.1 提示词发散反思器不断修改提示词几轮之后提示词越写越长职责边界越来越模糊最终变成一锅乱炖。我建议给提示词做分区管理目标区、约束区、任务输入区、输出格式区。每次策略更新只能改指定区域。反思器生成新内容后还要检查长度和职责边界超出范围就拒绝。5.2 成本爆炸自改进的成本很容易被忽略。每轮反思都要额外调用 LLM如果反思频率设置太高成本增长会非常明显。更好的方式是设置成本预算例如“反思投入不能超过任务执行成本的 10%”。当成本超限时自动降低反思频率或者把多个失败样本合并成一份批次反思报告再生成改进建议。5.3 过拟合评测集固定任务池上成功率越来越高不放心的场景和真实业务任务表现越来越差。这是自改进系统最容易出现的问题。对策就是前面说的滚动新增集。每跑一定轮次就加入一批新任务并且不要让智能体提前看到这些任务的答案。如果只追求单一评测集上的分数自改进很容易变成评测集背诵器而不是真正的能力提升。5.4 环境抖动误判改进效果模型 API 升级、第三方工具接口变化、输入数据格式调整都会造成成功率波动。如果这些抖动被误判成策略改进的收益后续更新方向就会被带偏。排查时先看环境变量模型版本、工具版本、输入数据特征有没有变化。确认环境稳定后再讨论策略更新是否有效。环境抖动时不要触发自动发布否则会把一个本来没问题的策略版本回滚掉。5.5 更新越权自改进系统自己改策略如果不控制权限可能出现越权行为改了系统约束、绕过安全限制、访问了不该访问的工具。这里必须做三件事策略更新前做权限校验危险操作必须人工审批所有策略变更保留完整审计记录。具体排查顺序可以参考看现象是成功率下降、任务卡住、还是成本暴涨。看最近一次策略版本变更记录确认是哪一层改了什么。看是否有新的任务类型进来老策略处理不了新输入。看模型 API 或第三方工具版本有没有变化。看 token 消耗和失败任务时间分布。都不要确认为硬件问题后才大面积调参。6. 不同阶段的人该怎么切入6.1 刚入门先用平台搭一个受控版本如果你想先理解分层自改进的概念不需要从零写框架。用 Coze、Dify 这类现成平台把任务拆成规划节点和执行节点人工实现“先用一组 prompt 跑任务再手动总结失败原因再调整 prompt”的流程。这个阶段不追求自动反思而是要把“策略版本变化会导致结果变化”这个感觉建立起来。比如你在 Dify 里改一个节点的温度参数或提示词观察同一批任务的输出差异。先把这一步跑通再谈自动化。6.2 进阶自己写反思与回滚当你觉得手动改 prompt 的流程太慢就可以开始写反思器和策略版本库。这个阶段的核心不是让系统变得更聪明而是让系统变得更可控。先实现三个能力读取任务日志、用固定模板生成改进建议、把建议包装成可回滚的配置版本。不要一开始就追求全自动更新可以先做成“系统提建议、人确认后发布”的半自动模式。跑一段时间积累足够多的成功和失败案例再逐步放开自动发布。6.3 生产级策略审计与人审进入生产环境后自改进系统必须加入人工审计环节。即使所有策略更新都能自动测试也仍然需要审核机制。建议流程是反思器生成建议策略测试模块在小样本上验证版本库生成新策略人工审核人确认关键变更自动发布并监控回滚阈值定期审计所有策略变更记录。这个流程会比纯自动系统慢但稳定性高很多。在涉及用户数据、支付、内容生成的场景里完全无人值守的自改进目前还不值得冒险。6.4 对照论文复现时的提醒如果你准备照着 Metan 这篇研究复现先确认三个问题它说的分层是模块分层还是 prompt 分层自改进的更新对象是提示词、参数还是整个工具调用策略效果对比的 baseline 是什么是不是单层自改进。原始标题没有给出具体指标和数据版本所以不要只根据一句话介绍就判断它适不适合你的场景。复现时先跑最小闭环再谈提升。最怕的是把别人研究里的实验设置当成生产环境的最佳实践直接套到自己任务上。踩过几次之后我发现这类系统真正让人头疼的往往不是单次任务跑不通而是策略越改越乱、想回滚找不到版本、评测结果不说明问题。生产环境里我一般会把“可控”排在“聪明”前面。分层自改进真正带来的价值不是让智能体变得更厉害而是让它的每一次自我调整都留下痕迹、可以被验证、可以被拒绝。先把这个根基做稳再谈自动化决策也不迟。