分层自改进智能体：让Agent从一次性程序变成可增长的系统

最近看到一项来自明大和首尔大的联合研究方向叫 Metan 分层自改进智能体。坦白说第一次看到这个标题我的反应不是兴奋而是有点警惕——“自改进智能体”这几个字这两年被用得太频繁了很多项目只是给 Agent 加了一步“反思”就自称具备自改进能力。但这次前缀多了“分层”两个字把问题抬高了一个台阶。先说我梳理完这个方向之后的判断Metan 这类方案真正要解决的不是让模型单次回答变得更准确而是让智能体具备一种“结构性成长能力”。也就是在一个可控的层级框架里把每次执行的经验沉淀下来反过来优化下一次执行。它试图回答的问题是当智能体不再是一个一次性的对话工具而是像一个长期运行的团队成员一样工作时它靠什么越干越好这个问题对正在做 Agent 开发的工程师来说比想象中更贴近现实。今天这篇不打算复述论文细节——因为原始资料里并没有给出非常完整的实验结论我也不想凭空编造。我更想把这个方向拆开讲讲它背后的工程逻辑以及普通开发者能从中学到什么。1. 为什么现在的大多数智能体“用久了不会变好”1.1 你部署的 Agent其实是一个“一次性程序”如果你用 Dify、Coze或者直接用 LangChain 自己搭过智能体大概率有过这样的体验第一次跑通流程的时候很有成就感。Agent 能读文件、能调工具、能按你的要求输出结构化结果。但换了另一批真实数据“翻车”的时刻来得也很快。可能是某个格式没有处理到可能是某个工具在特定条件下超时也可能只是用户换了一种问法整个流程就开始走偏。于是你开始改 prompt。改完一类问题另一类问题又冒出来改了一个分支逻辑原本正常的场景开始出错。根子在于大多数智能体的运行方式是“无状态推理”。模型在每次请求时读取用户输入结合提示词里的知识和工具生成一次回答。回答完了这次任务对系统来说就结束了。说得尖锐一点你部署的 Agent 更像一个“一次性程序”——每次执行都在重新发明轮子而不是像一个持续工作的人那样把上一次的成败经验带到下一次。这种问题在 demo 阶段看不出来。因为 demo 只有一两个固定场景你预设好了所有输入。但一旦进入真实生产环境输入千奇百怪场景不断叠加一个没有成长能力的 Agent 很快就会被需求的复杂度淹没。1.2 自改进不是一个功能而是一条循环链路很多人以为“自改进”就是让模型多反思一轮比如加一句“请检查你的回答并修正”。这是一种很浅的理解。真正意义上的自改进必须构成一条完整的循环链路执行完成一次任务产出结果评估判断结果是否达到预期差异在哪里沉淀把有效的策略、失败的教训、正确的格式转化为可复用的知识应用把沉淀的知识注入下一次执行影响后续行为。任何一个环节断了自改进都只是空话。Metan 强调的“分层”本质上就是把这条循环链路放到不同的层级去执行而不是让一个庞大的模型在同一层里既做任务又做反思又做知识管理——那样很容易互相干扰而且问题极难定位。注意不要以为“加了反思就是自改进”。如果系统没有把反思结果沉淀下来并在后续任务中实际使用反思就只是多花了一轮 token 的自我安慰。2. 分层不是为了显得高级而是为了把“改进”这件事拆开2.1 用软件架构的思路理解智能体分层分层这个概念做过后端开发的人应该很熟。一个标准的 Web 系统会分表现层、业务逻辑层、数据访问层每层职责清晰层与层之间通过接口通信。为什么要分层因为如果你把所有逻辑都写在一个文件里代码一多就根本改不动。分层不是额外增加复杂度而是为了让你在系统变复杂之后仍然能定位、修改、替换其中某一部分而不影响整体。智能体也是同样的道理。一个复杂的智能体需要处理目标理解、任务规划、工具调用、结果验证、知识记忆、经验沉淀……如果这些职责全部交给同一个模型实例通过不断堆 prompt 来完成最终会变成一团无法维护的“提示词意大利面”。Metan 的分层思路和软件架构里的分层非常相似。它不是哲学层面讨论“智能应该分成几层”而是在工程层面给出一个可操作的拆解方案哪个层级负责思考哪个层级负责执行哪个层级负责审视和调整边界必须清楚。2.2 一个典型的三层结构规划层、执行层、元层从通用工程实践来看一个分层自改进智能体通常可以拆成三层。第一层是规划层也叫决策层。它负责理解任务目标把一个大任务拆解成子任务决定调用哪些工具、按什么顺序执行。这一层的输入是用户目标输出是一个任务序列。比如用户说“帮我把这个 Excel 数据做成分析报告”规划层需要拆出“读取数据”“清洗数据”“生成图表”“撰写结论”这几个步骤并决定每步用什么工具。第二层是执行层负责具体干活。它接收来自规划层的子任务调用代码解释器、搜索引擎、API 等工具产生中间结果或最终输出。执行层的关注点是“把事做对”不需要每次都重新判断全局目标。这一层的设计应该尽量简单、可复用接口清晰——就像写一个函数输入输出明确内部实现可以单独替换。第三层是元层也叫评估与改进层。它观察规划层和执行层的表现评估结果是否符合预期总结失败原因把新的策略写回一个可供后续任务读取的经验库或规则集。这一层是整个自改进闭环的核心也是“Metan”中“Meta”的落点——它不是在解决具体任务而是在管理“解决任务的方式”。三层各司其职之后“自改进”就变成了一个可以管理的过程元层发现执行层在某个场景下经常失败就把修正策略写进经验库规划层在下次遇到相似任务时读取经验库调整任务拆解逻辑。整个过程不需要把模型重新训练一遍也不需要人肉去改 prompt——至少理论上是这样。2.3 为什么要分成三层而不是让一个 Agent 全包直接让一个 Agent 全程自理看起来更简单但在工程上会碰到几个绕不开的问题第一上下文会被污染。任务执行本身需要长上下文反思和策略调整也需要长上下文两者混在一起很容易互相干扰。任务做到一半模型可能突然回忆起“上次反思说要换个工具”结果把当前任务带偏了。第二问题无法归因。任务失败时你分不清是规划错了、执行错了还是评估逻辑有问题。分三层之后每一层的输入输出都有记录排查范围立刻缩小。第三优化无法复用。如果一切都混在同一个 Agent 里你针对某类任务调优 prompt可能会伤害其他场景的表现。分层之后规划层的策略调整只影响规划执行层的优化只影响执行边界隔离让系统更稳定。3. 自改进的几种落地机制从轻到重3.1 机制一结果反思这是最容易落地的自改进入门。每次任务完成后系统把输入、输出、中间工具调用记录统一交给评估器——可以是同一个模型也可以是一个更强或更便宜的模型——让它输出一份结构化的反思报告。报告通常包含这次任务的目标是什么结果是否达成哪里做得好可以固化为经验哪里失败了失败的直接原因是什么下次遇到类似情况应该怎么做。把反思报告作为记忆写入知识库下次任务开始时检索与当前任务最相关的历史反思注入提示词上下文。这是目前不少 Agent 项目采用的轻量自改进方案改动量不大但已经能规避很多重复性错误。3.2 机制二经验记忆与技能库比反思更进一步是构建技能库。每一次成功的任务流程不仅仅是“一段成功的对话”而是可以固化成一段可复用的工具调用序列或模板。比如你的 Agent 经常要处理一份 CSV 数据并生成可视化报告那么第一次手动跑通之后就可以把整个过程抽象成一条技能下次直接调用不需要再重新规划每一步。Voyager 项目展示过类似的思想智能体在游戏环境中学会一个新技能后把它存进技能库之后遇到相关任务时直接复用。这种能力比单纯“记住一个答案”强大得多因为技能是可组合的——你可以把“读取 CSV”“清洗缺失值”“绘制柱状图”三条技能组合起来处理一个全新数据文件。从工程实现上看技能库可以理解为一个版本化的函数库。每一条技能包含触发条件、输入输出格式、执行步骤、错误处理策略。新技能加入前最好经过验证避免把错误的流程固化进库里。3.3 机制三元级策略调整最高一层的自改进是让元层能够调整“系统本身的运行策略”。比如发现某类问题用链式思考效果好就默认启用发现某个工具在特定条件下经常超时就自动切换备选工具发现任务拆得太细会导致上下文过长就调整拆解粒度发现某个经验库检索规则命中率低就调整检索参数。这种调整不再是针对单次任务的而是针对“整个智能体工作方式”的。它是 Metan 中“Meta”含义的完整体现——不直接解决问题而是管理“解决问题的方式”。这一层也是最难实现的。因为它要求系统能够抽象地观察自己的行为并且安全地修改自己的策略。如果修改策略的权限完全放开系统可能朝不可控的方向演进。所以实际落地时通常的做法是元层只生成“策略修改建议”由人来确认之后才生效等运行足够长时间、积累了足够多的建议样本之后再逐步放开自动化。3.4 三种机制的选型建议这三种机制不是互斥的更像是一个递进路径机制改动成本效果适合阶段结果反思低能规避已知重复错误项目初期先跑通闭环技能库中能复用成功流程显著提效有稳定任务模式后元级策略调整高能让系统适应任务分布变化长期运行有充分日志和评估能力后4. 从研究到工程普通开发者可以怎么做4.1 先跑通最小闭环不要一上来就搭全套如果你正在开发自己的智能体看到 Metan 这种研究不要急着照搬全套三层架构。更稳妥的路径是从最小闭环开始。第一步给 Agent 加一个“执行后反思”步骤。任务完成后自动生成一段反思文本存到本地文件或向量数据库里。这个改动很小但会给系统增加一个“回顾”的能力。第二步把反思做成可检索的记忆。在下次任务开始前根据当前任务描述检索之前的反思记录把最相关的几条注入提示词。你会发现很多重复犯过的错误开始被自动规避。第三步根据反思记录人工沉淀规则。比如反思中发现“当输入包含多文件时Agent 经常漏掉其中一个”你就可以在提示词里加一条硬性规则。这一步的人工参与很重要因为当前系统的自动化策略调整还不够可靠。4.2 分层架构的落地建议规划、执行、评估分离即使暂时不做完整的自改进能力仅仅是把 Agent 按规划层、执行层、评估层拆分就会带来立竿见影的好处。定位问题更快。任务规划错了去查规划层的输出工具调用错了去查执行层的日志结果偏差大去查评估逻辑的判断标准。不用再从头到尾把整个链路盘一遍。提示词更短。每一层的提示词只需要关注一件事不需要把所有领域知识、工具说明、输出格式要求全部塞进一个超长 prompt。超长 prompt 的维护成本很高而且模型在长上下文里的注意力容易被稀释。更容易测试。你可以在每一层单独写测试用例。规划层的测试是“给一个复杂任务看拆解是否合理”执行层的测试是“给一个子任务和工具集合看调用是否正确”评估层的测试是“给一批已知好坏的结果看评分是否准确”。更容易替换。执行层想换一个更强或更便宜的模型只要保持接口不变规划层和评估层都不需要动。4.3 日志是自改进的地基我发现很多人在搭智能体时忽略日志直到出问题才想起来。自改进系统的前提是“能观察自己的历史行为”。没有完整的输入输出记录、没有工具调用日志、没有中间步骤快照你根本无从分析改进点。建议至少记录以下几类数据每次任务的完整输入和最终输出规划层生成的子任务序列执行层调用的每个工具、传入参数和返回结果评估层的评分或反思文本每次任务的耗时、token 消耗和错误信息。这些数据不仅是排查问题的基础也是训练自动评估器、构建反思经验库的原料。如果你计划长期运营一个智能体应用日志系统的设计应该从第一天就开始而不是等出问题再补。4.4 常见的坑和排查思路结合我自己的实操经验落地分层自改进智能体时最容易踩的几个坑坑一反思成了“走过场”。加了反思步骤但反思文本没有被使用或者被硬塞进上下文导致模型上下文过长、性能下降。排查思路检查反思内容是否真的被检索并注入到了后续任务中观察注入了反思的任务和不注入反思的任务之间是否有差异。坑二经验库越积越乱。反思记录和技能库没有版本管理也没有去重和淘汰机制时间一长里面充斥着自相矛盾的策略。排查思路定期抽查经验库统计命中率和有效性对长期未被检索到的记录做清理。坑三分层的边界混乱。规划层里偷偷写了执行逻辑执行层又在做自我评估结果还是回到了“一锅粥”的状态。排查思路每一层只允许暴露规定的接口跨层信息传递通过结构化数据而不是自然语言 prompt 完成。坑四评估标准缺失。没有明确的“好坏”定义反思报告只能凭感觉写。排查思路先制定可操作的成功标准比如“输出是否包含指定字段”“工具调用是否成功”“结果是否在预期范围内”再让评估器基于这些标准打分。5. 适用边界不是所有任务都需要分层自改进5.1 适合的场景分层自改进适合的任务有两个特征。第一任务是可重复、可结构化的。比如数据处理、报告生成、代码调试、客服问答、定时巡检。这些任务有明确流程和判断标准执行次数越多沉淀的经验越有价值。第二失败是有成本且可以归因的。如果一次执行失败会导致后续流程出错而你又能从失败日志中定位到具体原因那么自改进的收益就很高。你可以把每一次失败都变成一次学习机会而不是让问题反复发生。5.2 不适合的场景有些场景不适合至少要谨慎使用。高度发散、一次性的创意任务。比如让 Agent 写一首诗、做一个创意方案没有标准结果自改进能帮到的地方有限。这类任务的价值更多来自模型的即兴能力而不是对历史经验的复用。极低延迟要求的场景。如果每次请求都要求毫秒级响应那么反思、记忆检索、多层调度这些步骤会带来明显的额外开销。自改进机制更像“离线沉淀 在线应用”的组合不适合纯实时、超低延迟的在线链路。安全敏感且难以验证的任务。如果系统自动改变自己的行为策略而你又无法充分验证改变后的行为是否符合预期就可能引入新的风险。在医疗、金融、司法这类需要严格合规的领域自动策略调整要非常克制。5.3 当前仍待解决的核心问题从研究角度看Metan 这个方向还有很多开放问题。评估困难。自改进系统到底是变好了还是变坏了需要一套稳定的评估基准。但很多真实任务没有标准答案评估本身就是一个难题。研究者可能需要在“任务完成率”“用户满意度”“错误率下降幅度”等多个维度之间做权衡。反馈循环失控。如果反思逻辑本身有偏差系统可能学到错误的策略并在后续任务中不断强化这个错误导致“越改越差”。这需要设计阻断机制比如对策略修改做差异测试、设定回滚条件或者引入人工审核环节。成本问题。规划、执行、评估三层都需要模型推理token 消耗可能成倍增加需要权衡改进收益和运行成本。一个带完整自改进闭环的 Agent单次任务的成本可能是普通 Agent 的几倍这个账必须提前算清楚。知识污染。经验库中的错误知识如果不能被及时清理会像代码库里的技术债一样不断累积最终拖垮整个系统。这需要建立知识进入的验证机制和淘汰机制。6. 我的最终建议把“自改进”当成工程目标而不是营销词汇回到开头那个判断。Metan 分层自改进智能体的真正价值不是让 AI 突然变聪明而是把智能体从“一次性程序”变成“可增长的系统”。它给行业带来的启示不在于某一个具体的模型或算法而在于一种系统设计思路把智能体的能力发展从“靠人改 prompt”变成“靠系统在运行中积累”。对普通开发者来说短期内最该做的事情不是等一个完美的框架而是从自己的项目里找到一条可以闭环的路径加反思、建记忆、分层次、记日志。先把最小闭环跑通再逐步增加复杂度。对技术选型者来说判断一个智能体平台或框架是否真正支持“自改进”不要看宣传文案里有没有这个词而要追问三个问题它是否提供了完整的“执行—评估—沉淀—应用”链路链路的每一个环节你是否能观察到数据、能干预逻辑经验沉淀之后下一次任务是否真的会用到如果三个问题的答案都是肯定的那才是真自改进。如果只是内置了某种模糊的“记忆”大概率还是在做表面功夫。这个方向值得长期关注因为它触及了一个更深层的命题当智能体不再只是回答问题的一次性工具而是工作流中一个持续运转的组成部分我们如何让它像一个有经验的工程师一样越用越稳、越用越准。Metan 的研究只是这条路上的一步但它指向的方向正是下一代智能体工程需要认真对待的核心问题。