如果你最近在折腾 AI 智能体Agent大概率遇到过这个场景演示环境里它能自己规划、调用工具、完成多步任务看起来已经接近“自动驾驶”可一旦把任务换一个领域或者把问题描述改两个关键词它就开始原地打转反复试错甚至把原本正确的答案改错。问题往往不是模型不够聪明而是绝大多数智能体缺少一层“自我改进”机制它只能在一次推理里生成方案却没有对生成过程进行系统评估和策略调整的能力。明大通常指明尼苏达大学与首尔大学研究者提出的 Metan 分层自改进智能体切入点正在这里。与其继续堆模型能力不如把“规划—执行—反思—调整”变成显式的分层结构让智能体拥有可观测、可干预、可迭代的自我改进能力。这个方向之所以值得关注是因为它把 Agent 从“单次推理工具”推向“可持续优化的系统”其工程价值远大于一个提示词技巧。这篇文章会做三件事先拆解分层自改进智能体的核心原理再说清楚 Metan 这类研究与 ReAct、Reflexion 等既有方案的差异最后给出一个不依赖真实大模型也能跑通的最小 Python 实现帮你理解分层自改进的完整循环以及落地到真实项目时要注意的坑。1. 这篇文章真正要解决的问题做智能体开发的同学对下面这条曲线应该不陌生刚接上大模型 API、写几十行代码就能做一个“会调用搜索、会查天气、会写周报”的 Demo但一旦进入真实业务事情开始失控。任务稍微复杂一点模型可能规划出无效步骤工具调用失败后Agent 不懂得换一条路径多轮迭代之后它甚至忘了最初用户要什么。这类问题的根源并不是模型能力不够而是大多数 Agent 采用“直筒式”结构一次规划、一次执行、一次返回。错了就重来没有“评估自己哪里错了、提炼经验、调整下一次策略”的环节。所谓自改进不是简单地重试而是让 Agent 具备一种可累积的修正能力每一次失败都要变成下一次规划的输入。Metan 这类分层自改进研究想解决的核心问题就是把这种“修正能力”显式化。它不再把反思和调整隐含在模型的一两句话里而是拆成独立的层级每个层级有明确职责、有输入输出、有验证标准。这带来的直接好处有三个第一系统行为可观测哪一层出错能定位第二改进策略可干预工程师可以在关键节点加入规则或人工审核第三能力可复用一次反思总结出的经验可以被后续任务继承。什么样的读者最应该读完这篇文章如果你正在用 LangChain、Dify、Coze 或自研框架搭建 Agent但对“Agent 跑起来之后怎么变聪明”没有系统思路如果你已经接触过 ReAct、Reflexion 这类论文想知道“分层自改进”和它们的区别如果你是技术负责人在评估 Agent 从 Demo 到生产的落地路径那么这篇文章都能给你一个比较完整的参考框架。2. 从“直筒式 Agent”到“分层自改进”核心概念与原理2.1 智能体的基本工作方式先统一术语。通常说的 AI 智能体是指一个能够理解用户目标、自主规划步骤、调用外部工具搜索、代码、数据库、API 等并最终交付结果的系统。经典工作方式是 ReAct 风格的循环推理Thought→ 行动Action→ 观察Observation→ 再推理。这个循环本身没有问题它让模型可以边做边看比“一次生成最终答案”要稳定得多。但 ReAct 风格有一个盲区模型每一步都在“往前看”却很少“回头看”。当搜索结果不理想、工具返回报错、或者用户的原始需求在过程中被遗忘时模型往往只会换一个说法重新尝试而不是系统性地分析“上一个计划为什么失败”。这就是直筒式 Agent 的局限——它有循环但没有学习。2.2 自改进不等于重试很多初学者会把“自改进”理解成“失败之后换个 prompt 再问一次”。这种理解比较表面。真正的自改进至少包含三个环节评估Evaluation、反思Reflection、调整Adjustment。评估是判断当前结果是否达到目标不能只靠模型拍脑袋反思是找出差距产生的原因是目标理解错了、规划错了、工具选错了还是输出格式不对调整是基于反思结果修改下一次的计划或执行策略。对比一下重试是“再来一次”自改进是“知道为什么失败并改变下一次的行为”。举例来说一个 Agent 第一次搜索“Transformer 论文”结果太泛如果它只知道重试第三次还是会搜同样内容。如果它有反思层就会记录“搜索词过短、结果噪音大”下一次把查询改成“Transformer 论文 自注意力 2017”并附带时间过滤。这种差异在单个 Demo 里看不出来放到多轮任务里差距会非常明显。2.3 分层的核心思想“分层”是软件工程里非常成熟的思路后端开发都知道分层架构把 Controller、Service、DAO 拆开是为了职责单一、可测试、可替换。分层自改进智能体借用了同样的道理把一个 Agent 的完整能力拆成规划层、执行层、反思层、元管理层。每一层只做一件事层与层之间通过结构化数据通信。这里可以用一个组织管理的类比规划层是项目经理负责拆解目标执行层是一线员工负责调用工具干活反思层是质量专员负责检查交付物是否符合要求元管理层是部门负责人根据质量专员的报告决定下一次要不要改流程、换人、换工具。如果没有这些角色分工所有事都压给项目经理一个人项目自然容易乱。下面用表格对比直筒式 Agent 和分层自改进 Agent 的差异对比维度直筒式 Agent常见 ReAct分层自改进 AgentMetan 这类思路规划能力隐含在单次推理里独立的规划层显式输出计划失败反馈重试或换个说法反思层结构化输出问题原因改进策略依赖模型临时发挥元管理层按规则或再次推理调整计划可观测性只能看到最终输出每层都有输入、输出、结果记录工程可控性难以干预可在任意层插入规则、人工审核、监控经验复用一般不复用反思结论可写入记忆或外部知识库这个表格值得收藏因为它基本概括了分层自改进智能体区别于普通 Agent 的全部要点。3. Metan 的分层设计与工作流程3.1 从研究思路看核心框架从“Metan 分层自改进智能体”这个命名可以看出两个关键词一个是“元Meta”强调智能体对自身行为和策略的感知与调整另一个是“分层”强调不同能力之间的解耦。虽然我们在这里无法复现论文中的全部实验细节但从研究方向和公开讨论来看它要解决的问题非常明确给 Agent 增加一条正式的“自我改进回路”。一个通用的分层自改进智能体通常会包含下面四个层级。规划层负责把用户目标拆解成可执行步骤执行层负责按计划调用工具并返回观察结果反思层负责对执行结果进行质量评估判断目标是否达成、差距在哪、问题出在哪个环节元管理层负责接收反思层的结论决定是继续执行、重写计划、更换工具还是终止任务并把有价值的经验沉淀下来。3.2 一次完整的任务循环我们可以把一个分层自改进智能体的运行过程拆成下面的步骤。首次运行时规划层根据用户目标生成初始计划执行层按步骤执行每执行一步都记录上下文反思层拿到完整执行记录后评估当前输出是否满足用户目标如果满足流程结束返回结果如果不满足反思层输出结构化的改进建议例如“搜索关键词过泛建议增加时间范围”元管理层决定采纳并调整计划进入下一轮迭代整个过程会记录为一个历史经验供后续任务参考。这里的关键设计是“改进建议”不是自然语言一句话而是结构化数据。结构化意味着系统可以判断重要性、可以决定是否采纳、可以被日志记录、也可以参与打分。如果反思层只是输出一句“这次效果不好”元管理层是无法稳定做出决策的。Metan 这类研究背后的工程理念就是让改进回路里的每个信号都可被程序消费。3.3 与 ReAct、Reflexion 等方案的差异分层自改进与 ReAct 最核心的差异在于是否把反思和调整拆成独立组件。ReAct 的推理和行动是在同一个模型上下文中交替完成的缺少独立评估环节Reflexion 方案则引入了显式的“反思”步骤让模型用语言描述失败原因但它的反思和策略调整依然在同一层完成缺少分层治理结构。Metan 这类分层设计更进一步的地方在于它把“自我改进”做成工程上可管理的层级。比如你可以单独给反思层换一个更强的模型而完全不影响规划层和执行层你可以在元管理层加入规则当某个工具连续失败两次就自动停用你还可以把反思结果写入外部数据库形成长期记忆。对生产系统来说这种可插拔、可观测、可控制的结构比把所有逻辑揉进一个大 prompt 要可靠得多。3.4 工程启示从“聪明 Agent”到“可治理 Agent”这项研究给开发者最大的启示不是某个具体的提示词而是一种思维方式不要追求一次推理就得到完美结果而是要为一个不完美但可以不断修正的系统设计好“修正机制”。你不需要等模型变强才落地 Agent只要把反思层和元管理层搭建好当前模型就能通过多轮迭代逼近目标。这也是为什么分层自改进智能体在 2025 年的 Agent 工程化进程中受到大量关注。当然分层也会带来额外成本。每一轮反思都需要消耗模型调用每一条经验都需要设计存储结构每增加一层都会增加延迟。因此分层的粒度要结合实际任务复杂度来定不能为了分层而分层。4. 环境准备与前置条件4.1 运行环境本文后面的最小实现以 Python 为主目的是把分层自改进的流程跑通。建议使用 Python 3.10 或更高版本操作系统不限Windows、macOS、Linux 都可以。代码用到的第三方库非常少核心逻辑只依赖 Python 标准库方便你理解机制本身。为了方便管理依赖建议创建虚拟环境。创建和激活虚拟环境的命令如下python -m venv meta_agent_env source meta_agent_env/bin/activate # macOS / Linux # 或者 meta_agent_env\Scripts\activate # Windows PowerShell4.2 依赖安装最小演示不需要安装任何大模型 SDK因为我们会先用模拟器Mock代替真实模型输出。这样可以避免你因为 API Key、网络或费用问题卡在第一步。后面我会给出接入真实大模型 API 的示例代码。如果你希望同步跑通真实模型接入可以安装 OpenAI 兼容接口的客户端pip install openai版本请以实际环境为准本文重点演示通用思路不绑定某个具体版本。4.3 项目结构建议按照下面的结构组织代码方便后续扩展meta-agent-demo/ ├── agent/ │ ├── __init__.py │ ├── core.py # 分层数据结构定义 │ ├── layers.py # 规划层、执行层、反思层 │ └── loop.py # 元管理层与自改进主循环 ├── examples/ │ └── run_demo.py # 入口示例 ├── config/ │ └── agent.yaml # 配置文件可选 └── requirements.txt如果你的项目规模不大也可以把所有代码放在一个文件里。但分层结构的代码从一开始就分开写会更容易体会“分层”带来的好处。5. 核心流程拆解与最小实现5.1 定义分层数据结构数据结构的核心是让每一层之间通过“结构化对象”通信而不是传递裸字符串。这里先定义几种基础类型LayerType 表示层级类型PlanStep 表示计划中的一个步骤TaskResult 表示一次任务的执行结果Improvement 表示反思层产出的改进建议。# 文件路径agent/core.py from dataclasses import dataclass, field from enum import Enum, auto from typing import Dict, List, Any class LayerType(Enum): PLANNER auto() # 规划层 EXECUTOR auto() # 执行层 REFLECTOR auto() # 反思层 META auto() # 元管理层 dataclass class PlanStep: step_id: str description: str tool: str args: Dict[str, Any] field(default_factorydict) dataclass class TaskResult: task: str plan: List[PlanStep] output: str success: bool feedback: str iteration: int 0 metadata: Dict[str, Any] field(default_factorydict) dataclass class Improvement: issue: str # 发现的问题 suggestion: str # 改进建议 reason: str # 问题原因 importance: str medium # 重要性high / medium / low这段代码看起来简单但它决定了整个系统的可维护性。只要各层之间交换的数据结构稳定你就能在不改动其他层的前提下单独升级规划层或者反思层。5.2 实现规划层规划层的职责是根据用户任务生成可执行的计划。真实场景中这里应该调用大模型让模型以 JSON 格式输出步骤数组演示场景中我们先返回一个固定的三步计划方便观察后续的反思与改进过程。# 文件路径agent/layers.py from typing import List from .core import PlanStep, Improvement class Planner: 规划层把一个复杂任务拆成有序步骤。 def __init__(self, llmNone): self.llm llm def plan(self, task: str) - List[PlanStep]: # 生产环境调用大模型返回 JSON 解析为 List[PlanStep] # 演示环境固定返回一个计划聚焦分层循环 return [ PlanStep( step_id1, description理解用户需求, toolnone, args{task: task}, ), PlanStep( step_id2, description搜索相关资料, toolsearch, args{query: task}, ), PlanStep( step_id3, description生成最终回答, toolllm, args{task: task}, ), ]读者可能会问这个规划层没有调用大模型是不是太简单了是的但它足够用来演示“分层”的结构。真实项目中你只需要把 plan 方法里的逻辑替换成一次 LLM 调用然后解析返回的 JSON其他层完全不用改。5.3 实现执行层执行层按计划逐步调用工具并把结果写回上下文。这里我们用字符串拼接模拟工具输出生产环境可以替换为真实的搜索 API、代码执行器或数据库查询。class Executor: 执行层按计划调用工具并返回观察结果。 def run_step(self, step: PlanStep, context: dict) - str: if step.tool none: return f已理解任务{step.args.get(task)} if step.tool search: # 生产环境调用搜索 API演示环境返回模拟结果 return 模拟搜索结果找到 2 条相关资料其中 1 条可能相关。 if step.tool llm: # 生产环境调用大模型生成文本演示环境返回固定回答 task step.args.get(task, ) return f候选回答这是基于任务“{task}”生成的回答。 return f错误未识别的工具 {step.tool}执行层不负责判断结果好不好只负责“执行并返回结果”。这个职责边界很重要如果不小心让执行层同时做判断层与层之间就会耦合后续很难单独优化。5.4 实现反思层反思层是整个系统的核心。它负责评估执行结果是否满足目标并输出结构化的改进建议。演示代码里我们用“任务关键字是否出现在输出中”作为简单的评估规则真实项目中可以把这段逻辑替换为基于大模型的评估器。class Reflector: 反思层根据执行结果判断是否达成目标并给出改进建议。 def __init__(self, llmNone): self.llm llm def reflect(self, task: str, output: str, context: dict) - Improvement: # 生产环境把 task、output、context 一起交给 LLM 评估 # 演示环境用一个简单规则判断回答是否命中任务关键字 # 从任务中提取一个核心词作为简易命中条件 keyword task[0:8] if keyword not in output: return Improvement( issue输出内容不够完整没有覆盖任务核心信息, suggestion在第 2 步搜索中补充更具体的关键词并在第 3 步重新生成回答, reason当前输出未命中任务核心词可能方案过于泛化, importancehigh, ) return Improvement( issue, suggestion, reason, importancelow, )这种“规则式反思”的优点是确定性强、成本低缺点是无法处理复杂语义。实际工程里更推荐的做法是先用一套硬规则做快速失败检查再用 LLM 对关键任务做深度反思。这样可以平衡成本和效果。5.5 实现元管理层与自改进主循环元管理层负责把规划层、执行层、反思层串起来并在反思结果表明“需要改进”时调整计划。它是整个分层自改进机制的“大脑”。下面的 MetaAgent 类实现了完整的循环先规划再执行然后反思如果反思结果的重要性不是 low就生成一个“修复步骤”追加到计划中进入下一轮迭代。# 文件路径agent/loop.py from typing import List from .core import PlanStep, TaskResult, Improvement from .layers import Planner, Executor, Reflector class MetaAgent: 元管理层驱动 规划 - 执行 - 反思 - 调整 的自改进循环。 def __init__( self, planner: Planner, executor: Executor, reflector: Reflector, max_iterations: int 3, ): self.planner planner self.executor executor self.reflector reflector self.max_iterations max_iterations self.history: List[TaskResult] [] def run(self, task: str) - TaskResult: context: dict {} plan self.planner.plan(task) for i in range(1, self.max_iterations 1): outputs [] for step in plan: result self.executor.run_step(step, context) outputs.append(result) context[fstep_{step.step_id}] result final_output \n.join(outputs) improvement self.reflector.reflect(task, final_output, context) result TaskResult( tasktask, planplan, outputfinal_output, successimprovement.importance ! high, feedbackimprovement.issue, iterationi, metadata{improvement: improvement}, ) self.history.append(result) if result.success: return result plan self._revise_plan(plan, improvement) return self.history[-1] def _revise_plan(self, plan: List[PlanStep], improvement: Improvement) - List[PlanStep]: # 演示逻辑追加一个“修复步骤” # 生产环境可以调用 LLM 重写整个计划或按规则调整指定步骤 revised list(plan) revised.append( PlanStep( step_idffix_{len(revised) 1}, descriptionimprovement.suggestion, toolllm, args{ issue: improvement.issue, reason: improvement.reason, }, ) ) return revised这段代码最关键的逻辑在_revise_plan。它把反思层输出的建议转化为新的计划步骤让下一轮执行不再是简单重复而是在修正后的路径上继续。这就是“自改进”和“重试”的本质区别。5.6 运行入口示例有了前面的基础模块写一个运行入口就非常简单了。我们把“任务”设置为“帮我调研分层自改进智能体的最新进展”然后运行一个可以设定最大迭代次数的 Agent。# 文件路径examples/run_demo.py import os import sys sys.path.append(os.path.dirname(os.path.dirname(os.path.abspath(__file__)))) from agent.layers import Planner, Executor, Reflector from agent.loop import MetaAgent def main(): planner Planner() executor Executor() reflector Reflector() agent MetaAgent( plannerplanner, executorexecutor, reflectorreflector, max_iterations3, ) task 帮我调研分层自改进智能体的最新进展 result agent.run(task) print( 任务 ) print(task) print() print( 最终输出 ) print(result.output) print() print( 是否成功 ) print(result.success) print() print( 反思反馈 ) print(result.feedback) print() print( 迭代次数 ) print(result.iteration) print() print( 历史记录条数 ) print(len(agent.history)) if __name__ __main__: main()运行这个脚本你可以清楚地看到第一轮输出没有命中任务关键词反思层给出 high 重要性的反馈元管理层追加修复步骤第二轮输出仍然可能不命中因为模拟 LLM 的输出是固定的第三轮结束后系统返回最后一次结果。虽然这是一个模拟场景但它把“循环—反思—修改计划”的完整路径演示出来了。5.7 如何接入真实大模型进入生产环境时你需要把三处模拟逻辑替换为真实调用规划层调用 LLM 输出 JSON 计划执行层调用真实工具反思层调用 LLM 评估。下面是一个 OpenAI 兼容接口的调用示例。# 文件路径agent/llm.py示例 from openai import OpenAI # 这里以 OpenAI 兼容协议为例base_url 指向你团队自己部署的模型服务 client OpenAI( base_urlhttp://localhost:8000/v1, api_keylocal-test-key, ) def chat(messages): # 模型名称以你实际部署的模型为准 resp client.chat.completions.create( modelyour-model-name, messagesmessages, temperature0.2, ) return resp.choices[0].message.content接入时有一个很容易踩的坑LLM 返回的规划结果不一定是合法 JSON。生产环境一定要加一层“解析与校验”解析失败则让规划层重新生成最多重试两次。否则一个多余的引号就能让整个流程崩溃。6. 运行结果与效果验证6.1 运行命令进入项目根目录后执行python examples/run_demo.py由于演示代码不依赖外部 API正常情况下应该立刻看到输出不需要网络。6.2 预期输出示意因为模拟层的输出是固定的预期输出大致如下实际内容以你的运行环境为准 任务 帮我调研分层自改进智能体的最新进展 最终输出 已理解任务帮我调研分层自改进智能体的最新进展 模拟搜索结果找到 2 条相关资料其中 1 条可能相关。 候选回答这是基于任务“帮我调研分层自改进智能体的最新进展”生成的回答。 修复步骤执行根据改进建议重新生成回答。 是否成功 False 反思反馈 输出内容不够完整没有覆盖任务核心信息 迭代次数 3注意成功标志为 False 是正常现象因为模拟 LLM 永远不会真正命中评估规则。这个示例的目的不是“让任务成功”而是让你观察“反思—改进”机制到底做了什么。6.3 如何判断分层循环是否正常工作判断要点有三个。第一历史记录条数应该等于实际迭代次数说明循环正确运行第二观察metadata中的 Improvement 对象确认反思层是否输出了有意义的建议第三对比每一轮的计划长度第二轮的计划应该比第一轮多一个 fix 步骤证明元管理层确实把反思结论转化成了新的计划。6.4 如果输出不符合预期第一步看哪里先看是否出现导入错误。项目使用了sys.path.append把上层目录加入模块搜索路径如果你直接复制代码时把目录层级改错了会报ModuleNotFoundError。其次看 Python 版本如果使用 3.9 以下版本list[str]类型注解可能不兼容建议直接升级到 3.10。最后看run_demo.py里的 import 路径确保agent包能被正确找到。7. 常见问题与排查思路问题现象可能原因排查方式解决方案ModuleNotFoundError: No module named agent项目目录结构或模块路径不对检查当前工作目录是否在项目根目录检查sys.path.append路径从项目根目录运行脚本或改用正确的包引用方式循环陷入无限迭代max_iterations设置过大或终止条件不完善检查MetaAgent.run中的循环退出条件设置最大迭代次数并在反思层增加“无法继续改进”的终止信号反思层永远输出 high评估规则过于严苛或 LLM 评估器默认负面打印反思层输入输出检查评估规则增加评估阈值或引入多维度评分完整性、准确性、相关性改进建议没有被生效元管理层没有把建议写入新计划打印_revise_plan的返回值确认计划长度变化在元管理层中统一处理反思结果确保每次调整都生成新计划接入真实 LLM 后JSON 解析频繁失败模型返回了格式错误的 JSON在规划层增加 JSON 校验和重试逻辑增加解析失败重试机制或用函数调用能力强制结构化输出每一轮都调用 LLM成本过高没有对反思和调整做成本控制分析日志中每轮调用次数先用规则判断是否值得 LLM 反思再对高置信结果跳过反思排错时最重要的原则是“让每一层可见”。给规划层、执行层、反思层加上日志输出记录每层的输入和输出任何问题都能在日志里找到线索。没有日志排查分层就失去了它最大的意义。8. 最佳实践与工程建议8.1 分层职责要严格清晰规划层只做规划执行层只做执行反思层只做评估。不要在规划层里偷偷执行工具也不要在执行层里顺便判断结果正确性。职责混乱会让程序虽然能跑但出了问题完全无法定位。设计接口时建议以本文的PlanStep、TaskResult、Improvement这类数据结构为基准先把数据契约定好再写各层实现。8.2 成本控制不要所有任务都完整跑反思循环分层自改进的代价是每一轮迭代都可能消耗额外的模型调用。生产环境必须设计“分级反思”策略简单任务用规则判断失败后再用 LLM 反思关键任务才启用完整的多轮自改进循环。否则一次普通问答也可能花掉几十次模型调用成本完全不可控。8.3 建立评估集而不是只做“感觉优化”自改进系统最怕的是“改完这个任务另一个任务又坏了”。建议准备一个任务评估集包含 20 到 100 个有代表性的任务每次调整反思规则或元管理层策略后跑一遍评估集对比成功率、平均迭代次数、成本三个指标。没有评估集“自改进”就只是自我感觉良好。8.4 安全边界与权限控制给执行层配置工具时必须遵循最小权限原则。搜索可以用删除文件不能用查数据库可以用批量删除不能用。工具白名单要显式配置并且对每一次工具调用做好记录。真实项目中建议在元管理层增加一个“审批开关”当 Agent 计划调用高危工具时暂停并等待人工确认。分层架构让这类安全控制变得非常自然因为执行层本来就是独立的一层。8.5 日志与可观测性每一轮迭代都应该记录规划结果、每步执行结果、反思结果、调整后的新计划、总成本和耗时。推荐使用结构化的 JSON 日志方便后续做分析和回放。遇到生产事故时回放 Agent 的完整决策轨迹是排查问题的第一手段。8.6 经验沉淀与版本回滚自改进的最终目标是积累经验。反思层发现的常见错误可以定期沉淀为规则库让下一代 Agent 不再犯同样的问题。元管理层的策略参数如最大迭代次数、反思触发阈值属于配置不要写死在代码里建议放到配置中心方便灰度调整。如果调整后指标异常要能快速回滚到上一版配置。9. 总结与后续学习方向这篇文章把 Metan 分层自改进智能体的核心思路拆成了几个可以落地的部分从直筒式 Agent 的痛点出发解释了为什么“自改进”不是“重试”梳理了规划层、执行层、反思层、元管理层的职责边界并用一个可运行的最小 Python 示例跑通了完整的自改进循环。你应该可以清楚看到分层自改进的工程价值在于让 Agent 的每一次失败都变成可记录、可分析、可调整的数据。下一步建议你做三件事。第一把文中的最小实现跑一遍修改 max_iterations 和反思规则观察行为变化第二把模拟的规划层和反思层替换成真实大模型调用用一个简单业务任务验证完整流程第三建立一个小型评估集开始用数据驱动的方式调整 Agent 的反思策略。从最小闭环开始逐步增加复杂度比一开始就搭建一个庞大的 Agent 平台要稳妥得多。分层自改进智能体目前还处于高速演进阶段但它确定的工程方向值得提前布局把 Agent 当成一个可以持续优化的系统而不是一次性的脚本。能把“自我改进”做成分层、可观测、可控制的工程能力就已经比绝大多数直筒式 Agent 前进了一大步。 分层自改进智能体：从直筒式Agent到可治理系统的工程实践
如果你最近在折腾 AI 智能体Agent大概率遇到过这个场景演示环境里它能自己规划、调用工具、完成多步任务看起来已经接近“自动驾驶”可一旦把任务换一个领域或者把问题描述改两个关键词它就开始原地打转反复试错甚至把原本正确的答案改错。问题往往不是模型不够聪明而是绝大多数智能体缺少一层“自我改进”机制它只能在一次推理里生成方案却没有对生成过程进行系统评估和策略调整的能力。明大通常指明尼苏达大学与首尔大学研究者提出的 Metan 分层自改进智能体切入点正在这里。与其继续堆模型能力不如把“规划—执行—反思—调整”变成显式的分层结构让智能体拥有可观测、可干预、可迭代的自我改进能力。这个方向之所以值得关注是因为它把 Agent 从“单次推理工具”推向“可持续优化的系统”其工程价值远大于一个提示词技巧。这篇文章会做三件事先拆解分层自改进智能体的核心原理再说清楚 Metan 这类研究与 ReAct、Reflexion 等既有方案的差异最后给出一个不依赖真实大模型也能跑通的最小 Python 实现帮你理解分层自改进的完整循环以及落地到真实项目时要注意的坑。1. 这篇文章真正要解决的问题做智能体开发的同学对下面这条曲线应该不陌生刚接上大模型 API、写几十行代码就能做一个“会调用搜索、会查天气、会写周报”的 Demo但一旦进入真实业务事情开始失控。任务稍微复杂一点模型可能规划出无效步骤工具调用失败后Agent 不懂得换一条路径多轮迭代之后它甚至忘了最初用户要什么。这类问题的根源并不是模型能力不够而是大多数 Agent 采用“直筒式”结构一次规划、一次执行、一次返回。错了就重来没有“评估自己哪里错了、提炼经验、调整下一次策略”的环节。所谓自改进不是简单地重试而是让 Agent 具备一种可累积的修正能力每一次失败都要变成下一次规划的输入。Metan 这类分层自改进研究想解决的核心问题就是把这种“修正能力”显式化。它不再把反思和调整隐含在模型的一两句话里而是拆成独立的层级每个层级有明确职责、有输入输出、有验证标准。这带来的直接好处有三个第一系统行为可观测哪一层出错能定位第二改进策略可干预工程师可以在关键节点加入规则或人工审核第三能力可复用一次反思总结出的经验可以被后续任务继承。什么样的读者最应该读完这篇文章如果你正在用 LangChain、Dify、Coze 或自研框架搭建 Agent但对“Agent 跑起来之后怎么变聪明”没有系统思路如果你已经接触过 ReAct、Reflexion 这类论文想知道“分层自改进”和它们的区别如果你是技术负责人在评估 Agent 从 Demo 到生产的落地路径那么这篇文章都能给你一个比较完整的参考框架。2. 从“直筒式 Agent”到“分层自改进”核心概念与原理2.1 智能体的基本工作方式先统一术语。通常说的 AI 智能体是指一个能够理解用户目标、自主规划步骤、调用外部工具搜索、代码、数据库、API 等并最终交付结果的系统。经典工作方式是 ReAct 风格的循环推理Thought→ 行动Action→ 观察Observation→ 再推理。这个循环本身没有问题它让模型可以边做边看比“一次生成最终答案”要稳定得多。但 ReAct 风格有一个盲区模型每一步都在“往前看”却很少“回头看”。当搜索结果不理想、工具返回报错、或者用户的原始需求在过程中被遗忘时模型往往只会换一个说法重新尝试而不是系统性地分析“上一个计划为什么失败”。这就是直筒式 Agent 的局限——它有循环但没有学习。2.2 自改进不等于重试很多初学者会把“自改进”理解成“失败之后换个 prompt 再问一次”。这种理解比较表面。真正的自改进至少包含三个环节评估Evaluation、反思Reflection、调整Adjustment。评估是判断当前结果是否达到目标不能只靠模型拍脑袋反思是找出差距产生的原因是目标理解错了、规划错了、工具选错了还是输出格式不对调整是基于反思结果修改下一次的计划或执行策略。对比一下重试是“再来一次”自改进是“知道为什么失败并改变下一次的行为”。举例来说一个 Agent 第一次搜索“Transformer 论文”结果太泛如果它只知道重试第三次还是会搜同样内容。如果它有反思层就会记录“搜索词过短、结果噪音大”下一次把查询改成“Transformer 论文 自注意力 2017”并附带时间过滤。这种差异在单个 Demo 里看不出来放到多轮任务里差距会非常明显。2.3 分层的核心思想“分层”是软件工程里非常成熟的思路后端开发都知道分层架构把 Controller、Service、DAO 拆开是为了职责单一、可测试、可替换。分层自改进智能体借用了同样的道理把一个 Agent 的完整能力拆成规划层、执行层、反思层、元管理层。每一层只做一件事层与层之间通过结构化数据通信。这里可以用一个组织管理的类比规划层是项目经理负责拆解目标执行层是一线员工负责调用工具干活反思层是质量专员负责检查交付物是否符合要求元管理层是部门负责人根据质量专员的报告决定下一次要不要改流程、换人、换工具。如果没有这些角色分工所有事都压给项目经理一个人项目自然容易乱。下面用表格对比直筒式 Agent 和分层自改进 Agent 的差异对比维度直筒式 Agent常见 ReAct分层自改进 AgentMetan 这类思路规划能力隐含在单次推理里独立的规划层显式输出计划失败反馈重试或换个说法反思层结构化输出问题原因改进策略依赖模型临时发挥元管理层按规则或再次推理调整计划可观测性只能看到最终输出每层都有输入、输出、结果记录工程可控性难以干预可在任意层插入规则、人工审核、监控经验复用一般不复用反思结论可写入记忆或外部知识库这个表格值得收藏因为它基本概括了分层自改进智能体区别于普通 Agent 的全部要点。3. Metan 的分层设计与工作流程3.1 从研究思路看核心框架从“Metan 分层自改进智能体”这个命名可以看出两个关键词一个是“元Meta”强调智能体对自身行为和策略的感知与调整另一个是“分层”强调不同能力之间的解耦。虽然我们在这里无法复现论文中的全部实验细节但从研究方向和公开讨论来看它要解决的问题非常明确给 Agent 增加一条正式的“自我改进回路”。一个通用的分层自改进智能体通常会包含下面四个层级。规划层负责把用户目标拆解成可执行步骤执行层负责按计划调用工具并返回观察结果反思层负责对执行结果进行质量评估判断目标是否达成、差距在哪、问题出在哪个环节元管理层负责接收反思层的结论决定是继续执行、重写计划、更换工具还是终止任务并把有价值的经验沉淀下来。3.2 一次完整的任务循环我们可以把一个分层自改进智能体的运行过程拆成下面的步骤。首次运行时规划层根据用户目标生成初始计划执行层按步骤执行每执行一步都记录上下文反思层拿到完整执行记录后评估当前输出是否满足用户目标如果满足流程结束返回结果如果不满足反思层输出结构化的改进建议例如“搜索关键词过泛建议增加时间范围”元管理层决定采纳并调整计划进入下一轮迭代整个过程会记录为一个历史经验供后续任务参考。这里的关键设计是“改进建议”不是自然语言一句话而是结构化数据。结构化意味着系统可以判断重要性、可以决定是否采纳、可以被日志记录、也可以参与打分。如果反思层只是输出一句“这次效果不好”元管理层是无法稳定做出决策的。Metan 这类研究背后的工程理念就是让改进回路里的每个信号都可被程序消费。3.3 与 ReAct、Reflexion 等方案的差异分层自改进与 ReAct 最核心的差异在于是否把反思和调整拆成独立组件。ReAct 的推理和行动是在同一个模型上下文中交替完成的缺少独立评估环节Reflexion 方案则引入了显式的“反思”步骤让模型用语言描述失败原因但它的反思和策略调整依然在同一层完成缺少分层治理结构。Metan 这类分层设计更进一步的地方在于它把“自我改进”做成工程上可管理的层级。比如你可以单独给反思层换一个更强的模型而完全不影响规划层和执行层你可以在元管理层加入规则当某个工具连续失败两次就自动停用你还可以把反思结果写入外部数据库形成长期记忆。对生产系统来说这种可插拔、可观测、可控制的结构比把所有逻辑揉进一个大 prompt 要可靠得多。3.4 工程启示从“聪明 Agent”到“可治理 Agent”这项研究给开发者最大的启示不是某个具体的提示词而是一种思维方式不要追求一次推理就得到完美结果而是要为一个不完美但可以不断修正的系统设计好“修正机制”。你不需要等模型变强才落地 Agent只要把反思层和元管理层搭建好当前模型就能通过多轮迭代逼近目标。这也是为什么分层自改进智能体在 2025 年的 Agent 工程化进程中受到大量关注。当然分层也会带来额外成本。每一轮反思都需要消耗模型调用每一条经验都需要设计存储结构每增加一层都会增加延迟。因此分层的粒度要结合实际任务复杂度来定不能为了分层而分层。4. 环境准备与前置条件4.1 运行环境本文后面的最小实现以 Python 为主目的是把分层自改进的流程跑通。建议使用 Python 3.10 或更高版本操作系统不限Windows、macOS、Linux 都可以。代码用到的第三方库非常少核心逻辑只依赖 Python 标准库方便你理解机制本身。为了方便管理依赖建议创建虚拟环境。创建和激活虚拟环境的命令如下python -m venv meta_agent_env source meta_agent_env/bin/activate # macOS / Linux # 或者 meta_agent_env\Scripts\activate # Windows PowerShell4.2 依赖安装最小演示不需要安装任何大模型 SDK因为我们会先用模拟器Mock代替真实模型输出。这样可以避免你因为 API Key、网络或费用问题卡在第一步。后面我会给出接入真实大模型 API 的示例代码。如果你希望同步跑通真实模型接入可以安装 OpenAI 兼容接口的客户端pip install openai版本请以实际环境为准本文重点演示通用思路不绑定某个具体版本。4.3 项目结构建议按照下面的结构组织代码方便后续扩展meta-agent-demo/ ├── agent/ │ ├── __init__.py │ ├── core.py # 分层数据结构定义 │ ├── layers.py # 规划层、执行层、反思层 │ └── loop.py # 元管理层与自改进主循环 ├── examples/ │ └── run_demo.py # 入口示例 ├── config/ │ └── agent.yaml # 配置文件可选 └── requirements.txt如果你的项目规模不大也可以把所有代码放在一个文件里。但分层结构的代码从一开始就分开写会更容易体会“分层”带来的好处。5. 核心流程拆解与最小实现5.1 定义分层数据结构数据结构的核心是让每一层之间通过“结构化对象”通信而不是传递裸字符串。这里先定义几种基础类型LayerType 表示层级类型PlanStep 表示计划中的一个步骤TaskResult 表示一次任务的执行结果Improvement 表示反思层产出的改进建议。# 文件路径agent/core.py from dataclasses import dataclass, field from enum import Enum, auto from typing import Dict, List, Any class LayerType(Enum): PLANNER auto() # 规划层 EXECUTOR auto() # 执行层 REFLECTOR auto() # 反思层 META auto() # 元管理层 dataclass class PlanStep: step_id: str description: str tool: str args: Dict[str, Any] field(default_factorydict) dataclass class TaskResult: task: str plan: List[PlanStep] output: str success: bool feedback: str iteration: int 0 metadata: Dict[str, Any] field(default_factorydict) dataclass class Improvement: issue: str # 发现的问题 suggestion: str # 改进建议 reason: str # 问题原因 importance: str medium # 重要性high / medium / low这段代码看起来简单但它决定了整个系统的可维护性。只要各层之间交换的数据结构稳定你就能在不改动其他层的前提下单独升级规划层或者反思层。5.2 实现规划层规划层的职责是根据用户任务生成可执行的计划。真实场景中这里应该调用大模型让模型以 JSON 格式输出步骤数组演示场景中我们先返回一个固定的三步计划方便观察后续的反思与改进过程。# 文件路径agent/layers.py from typing import List from .core import PlanStep, Improvement class Planner: 规划层把一个复杂任务拆成有序步骤。 def __init__(self, llmNone): self.llm llm def plan(self, task: str) - List[PlanStep]: # 生产环境调用大模型返回 JSON 解析为 List[PlanStep] # 演示环境固定返回一个计划聚焦分层循环 return [ PlanStep( step_id1, description理解用户需求, toolnone, args{task: task}, ), PlanStep( step_id2, description搜索相关资料, toolsearch, args{query: task}, ), PlanStep( step_id3, description生成最终回答, toolllm, args{task: task}, ), ]读者可能会问这个规划层没有调用大模型是不是太简单了是的但它足够用来演示“分层”的结构。真实项目中你只需要把 plan 方法里的逻辑替换成一次 LLM 调用然后解析返回的 JSON其他层完全不用改。5.3 实现执行层执行层按计划逐步调用工具并把结果写回上下文。这里我们用字符串拼接模拟工具输出生产环境可以替换为真实的搜索 API、代码执行器或数据库查询。class Executor: 执行层按计划调用工具并返回观察结果。 def run_step(self, step: PlanStep, context: dict) - str: if step.tool none: return f已理解任务{step.args.get(task)} if step.tool search: # 生产环境调用搜索 API演示环境返回模拟结果 return 模拟搜索结果找到 2 条相关资料其中 1 条可能相关。 if step.tool llm: # 生产环境调用大模型生成文本演示环境返回固定回答 task step.args.get(task, ) return f候选回答这是基于任务“{task}”生成的回答。 return f错误未识别的工具 {step.tool}执行层不负责判断结果好不好只负责“执行并返回结果”。这个职责边界很重要如果不小心让执行层同时做判断层与层之间就会耦合后续很难单独优化。5.4 实现反思层反思层是整个系统的核心。它负责评估执行结果是否满足目标并输出结构化的改进建议。演示代码里我们用“任务关键字是否出现在输出中”作为简单的评估规则真实项目中可以把这段逻辑替换为基于大模型的评估器。class Reflector: 反思层根据执行结果判断是否达成目标并给出改进建议。 def __init__(self, llmNone): self.llm llm def reflect(self, task: str, output: str, context: dict) - Improvement: # 生产环境把 task、output、context 一起交给 LLM 评估 # 演示环境用一个简单规则判断回答是否命中任务关键字 # 从任务中提取一个核心词作为简易命中条件 keyword task[0:8] if keyword not in output: return Improvement( issue输出内容不够完整没有覆盖任务核心信息, suggestion在第 2 步搜索中补充更具体的关键词并在第 3 步重新生成回答, reason当前输出未命中任务核心词可能方案过于泛化, importancehigh, ) return Improvement( issue, suggestion, reason, importancelow, )这种“规则式反思”的优点是确定性强、成本低缺点是无法处理复杂语义。实际工程里更推荐的做法是先用一套硬规则做快速失败检查再用 LLM 对关键任务做深度反思。这样可以平衡成本和效果。5.5 实现元管理层与自改进主循环元管理层负责把规划层、执行层、反思层串起来并在反思结果表明“需要改进”时调整计划。它是整个分层自改进机制的“大脑”。下面的 MetaAgent 类实现了完整的循环先规划再执行然后反思如果反思结果的重要性不是 low就生成一个“修复步骤”追加到计划中进入下一轮迭代。# 文件路径agent/loop.py from typing import List from .core import PlanStep, TaskResult, Improvement from .layers import Planner, Executor, Reflector class MetaAgent: 元管理层驱动 规划 - 执行 - 反思 - 调整 的自改进循环。 def __init__( self, planner: Planner, executor: Executor, reflector: Reflector, max_iterations: int 3, ): self.planner planner self.executor executor self.reflector reflector self.max_iterations max_iterations self.history: List[TaskResult] [] def run(self, task: str) - TaskResult: context: dict {} plan self.planner.plan(task) for i in range(1, self.max_iterations 1): outputs [] for step in plan: result self.executor.run_step(step, context) outputs.append(result) context[fstep_{step.step_id}] result final_output \n.join(outputs) improvement self.reflector.reflect(task, final_output, context) result TaskResult( tasktask, planplan, outputfinal_output, successimprovement.importance ! high, feedbackimprovement.issue, iterationi, metadata{improvement: improvement}, ) self.history.append(result) if result.success: return result plan self._revise_plan(plan, improvement) return self.history[-1] def _revise_plan(self, plan: List[PlanStep], improvement: Improvement) - List[PlanStep]: # 演示逻辑追加一个“修复步骤” # 生产环境可以调用 LLM 重写整个计划或按规则调整指定步骤 revised list(plan) revised.append( PlanStep( step_idffix_{len(revised) 1}, descriptionimprovement.suggestion, toolllm, args{ issue: improvement.issue, reason: improvement.reason, }, ) ) return revised这段代码最关键的逻辑在_revise_plan。它把反思层输出的建议转化为新的计划步骤让下一轮执行不再是简单重复而是在修正后的路径上继续。这就是“自改进”和“重试”的本质区别。5.6 运行入口示例有了前面的基础模块写一个运行入口就非常简单了。我们把“任务”设置为“帮我调研分层自改进智能体的最新进展”然后运行一个可以设定最大迭代次数的 Agent。# 文件路径examples/run_demo.py import os import sys sys.path.append(os.path.dirname(os.path.dirname(os.path.abspath(__file__)))) from agent.layers import Planner, Executor, Reflector from agent.loop import MetaAgent def main(): planner Planner() executor Executor() reflector Reflector() agent MetaAgent( plannerplanner, executorexecutor, reflectorreflector, max_iterations3, ) task 帮我调研分层自改进智能体的最新进展 result agent.run(task) print( 任务 ) print(task) print() print( 最终输出 ) print(result.output) print() print( 是否成功 ) print(result.success) print() print( 反思反馈 ) print(result.feedback) print() print( 迭代次数 ) print(result.iteration) print() print( 历史记录条数 ) print(len(agent.history)) if __name__ __main__: main()运行这个脚本你可以清楚地看到第一轮输出没有命中任务关键词反思层给出 high 重要性的反馈元管理层追加修复步骤第二轮输出仍然可能不命中因为模拟 LLM 的输出是固定的第三轮结束后系统返回最后一次结果。虽然这是一个模拟场景但它把“循环—反思—修改计划”的完整路径演示出来了。5.7 如何接入真实大模型进入生产环境时你需要把三处模拟逻辑替换为真实调用规划层调用 LLM 输出 JSON 计划执行层调用真实工具反思层调用 LLM 评估。下面是一个 OpenAI 兼容接口的调用示例。# 文件路径agent/llm.py示例 from openai import OpenAI # 这里以 OpenAI 兼容协议为例base_url 指向你团队自己部署的模型服务 client OpenAI( base_urlhttp://localhost:8000/v1, api_keylocal-test-key, ) def chat(messages): # 模型名称以你实际部署的模型为准 resp client.chat.completions.create( modelyour-model-name, messagesmessages, temperature0.2, ) return resp.choices[0].message.content接入时有一个很容易踩的坑LLM 返回的规划结果不一定是合法 JSON。生产环境一定要加一层“解析与校验”解析失败则让规划层重新生成最多重试两次。否则一个多余的引号就能让整个流程崩溃。6. 运行结果与效果验证6.1 运行命令进入项目根目录后执行python examples/run_demo.py由于演示代码不依赖外部 API正常情况下应该立刻看到输出不需要网络。6.2 预期输出示意因为模拟层的输出是固定的预期输出大致如下实际内容以你的运行环境为准 任务 帮我调研分层自改进智能体的最新进展 最终输出 已理解任务帮我调研分层自改进智能体的最新进展 模拟搜索结果找到 2 条相关资料其中 1 条可能相关。 候选回答这是基于任务“帮我调研分层自改进智能体的最新进展”生成的回答。 修复步骤执行根据改进建议重新生成回答。 是否成功 False 反思反馈 输出内容不够完整没有覆盖任务核心信息 迭代次数 3注意成功标志为 False 是正常现象因为模拟 LLM 永远不会真正命中评估规则。这个示例的目的不是“让任务成功”而是让你观察“反思—改进”机制到底做了什么。6.3 如何判断分层循环是否正常工作判断要点有三个。第一历史记录条数应该等于实际迭代次数说明循环正确运行第二观察metadata中的 Improvement 对象确认反思层是否输出了有意义的建议第三对比每一轮的计划长度第二轮的计划应该比第一轮多一个 fix 步骤证明元管理层确实把反思结论转化成了新的计划。6.4 如果输出不符合预期第一步看哪里先看是否出现导入错误。项目使用了sys.path.append把上层目录加入模块搜索路径如果你直接复制代码时把目录层级改错了会报ModuleNotFoundError。其次看 Python 版本如果使用 3.9 以下版本list[str]类型注解可能不兼容建议直接升级到 3.10。最后看run_demo.py里的 import 路径确保agent包能被正确找到。7. 常见问题与排查思路问题现象可能原因排查方式解决方案ModuleNotFoundError: No module named agent项目目录结构或模块路径不对检查当前工作目录是否在项目根目录检查sys.path.append路径从项目根目录运行脚本或改用正确的包引用方式循环陷入无限迭代max_iterations设置过大或终止条件不完善检查MetaAgent.run中的循环退出条件设置最大迭代次数并在反思层增加“无法继续改进”的终止信号反思层永远输出 high评估规则过于严苛或 LLM 评估器默认负面打印反思层输入输出检查评估规则增加评估阈值或引入多维度评分完整性、准确性、相关性改进建议没有被生效元管理层没有把建议写入新计划打印_revise_plan的返回值确认计划长度变化在元管理层中统一处理反思结果确保每次调整都生成新计划接入真实 LLM 后JSON 解析频繁失败模型返回了格式错误的 JSON在规划层增加 JSON 校验和重试逻辑增加解析失败重试机制或用函数调用能力强制结构化输出每一轮都调用 LLM成本过高没有对反思和调整做成本控制分析日志中每轮调用次数先用规则判断是否值得 LLM 反思再对高置信结果跳过反思排错时最重要的原则是“让每一层可见”。给规划层、执行层、反思层加上日志输出记录每层的输入和输出任何问题都能在日志里找到线索。没有日志排查分层就失去了它最大的意义。8. 最佳实践与工程建议8.1 分层职责要严格清晰规划层只做规划执行层只做执行反思层只做评估。不要在规划层里偷偷执行工具也不要在执行层里顺便判断结果正确性。职责混乱会让程序虽然能跑但出了问题完全无法定位。设计接口时建议以本文的PlanStep、TaskResult、Improvement这类数据结构为基准先把数据契约定好再写各层实现。8.2 成本控制不要所有任务都完整跑反思循环分层自改进的代价是每一轮迭代都可能消耗额外的模型调用。生产环境必须设计“分级反思”策略简单任务用规则判断失败后再用 LLM 反思关键任务才启用完整的多轮自改进循环。否则一次普通问答也可能花掉几十次模型调用成本完全不可控。8.3 建立评估集而不是只做“感觉优化”自改进系统最怕的是“改完这个任务另一个任务又坏了”。建议准备一个任务评估集包含 20 到 100 个有代表性的任务每次调整反思规则或元管理层策略后跑一遍评估集对比成功率、平均迭代次数、成本三个指标。没有评估集“自改进”就只是自我感觉良好。8.4 安全边界与权限控制给执行层配置工具时必须遵循最小权限原则。搜索可以用删除文件不能用查数据库可以用批量删除不能用。工具白名单要显式配置并且对每一次工具调用做好记录。真实项目中建议在元管理层增加一个“审批开关”当 Agent 计划调用高危工具时暂停并等待人工确认。分层架构让这类安全控制变得非常自然因为执行层本来就是独立的一层。8.5 日志与可观测性每一轮迭代都应该记录规划结果、每步执行结果、反思结果、调整后的新计划、总成本和耗时。推荐使用结构化的 JSON 日志方便后续做分析和回放。遇到生产事故时回放 Agent 的完整决策轨迹是排查问题的第一手段。8.6 经验沉淀与版本回滚自改进的最终目标是积累经验。反思层发现的常见错误可以定期沉淀为规则库让下一代 Agent 不再犯同样的问题。元管理层的策略参数如最大迭代次数、反思触发阈值属于配置不要写死在代码里建议放到配置中心方便灰度调整。如果调整后指标异常要能快速回滚到上一版配置。9. 总结与后续学习方向这篇文章把 Metan 分层自改进智能体的核心思路拆成了几个可以落地的部分从直筒式 Agent 的痛点出发解释了为什么“自改进”不是“重试”梳理了规划层、执行层、反思层、元管理层的职责边界并用一个可运行的最小 Python 示例跑通了完整的自改进循环。你应该可以清楚看到分层自改进的工程价值在于让 Agent 的每一次失败都变成可记录、可分析、可调整的数据。下一步建议你做三件事。第一把文中的最小实现跑一遍修改 max_iterations 和反思规则观察行为变化第二把模拟的规划层和反思层替换成真实大模型调用用一个简单业务任务验证完整流程第三建立一个小型评估集开始用数据驱动的方式调整 Agent 的反思策略。从最小闭环开始逐步增加复杂度比一开始就搭建一个庞大的 Agent 平台要稳妥得多。分层自改进智能体目前还处于高速演进阶段但它确定的工程方向值得提前布局把 Agent 当成一个可以持续优化的系统而不是一次性的脚本。能把“自我改进”做成分层、可观测、可控制的工程能力就已经比绝大多数直筒式 Agent 前进了一大步。