构建自我改进Agent：基于RLM的反思与经验复用

在 Agent 开发中难度从“让模型回答正确”升级到“让智能体连续执行多次任务都稳定正确”的时间点非常早。Prime Agent 正是一个以 RLMReflective Language Model结构为核心的 self-improving agent 工程原型它的设计目标是让智能体不是每次从零开始思考而是像有经验的开发者一样在执行任务后反思过程、沉淀经验并在下一次任务的规划阶段自动复用这些经验。这篇文章会围绕“如何把一个普通的 LLM Agent 改造成具备自我改进能力的 RLM Agent”这条主线展开。先说明 RLM 和 self-improving 的核心机制再给出一个可运行的 Python 工程骨架带读者实现任务执行、反思生成、经验持久化和经验注入四个关键环节最后补充排错路径和生产化建议。整个方案不依赖重型框架核心逻辑用 Python 和少量依赖就能跑通适合用来理解 Agent 记忆、反思和技能沉淀的核心原理。1. 先理解 RLM 和 self-improving agent 到底解决什么问题1.1 普通 Agent 的局限每次执行都是一次“失忆”普通 LLM Agent 通常只有三层结构接收任务、调用大模型推理、执行工具调用。外部表现是“能聊天、能调用函数、能查资料”但内部没有对“上一次执行是否成功”的记忆。同一个任务今天执行成功明天环境参数变了就可能失败同一个错误智能体会在不同对话里反复踩坑。这种结构的本质问题是模型权重是静态的上下文是临时的经验是瞬时的。模型完成一次任务后过程数据要么被丢弃要么只存在于当前会话里。对个人助手类应用来说问题不大但对需要长期执行复杂任务的系统来说这是致命缺陷。一个数据抽取 Agent 如果每次都要重新摸索字段映射规则一个代码生成 Agent 如果每次都要重新踩一遍同样的 API 参数坑那么它本质上没有积累也没有成长。1.2 Prime Agent 的答案把“反思结果”变成可检索的经验资产Prime Agent 采用的设计思想可以概括为先执行后反思再沉淀下次复用。它不是要在模型推理时临时想得更久而是把曾经执行成功的路径、失败的教训、修正后的代码片段统一转成结构化经验记录下来。这套机制就是 RLM 的核心含义。在本文语境中RLM 更准确的说法是 Reflective Language Model即带反思回路的大语言模型智能体结构。与传统 Agent 相比RLM 多了一条“体验循环”任务执行完成后模型不仅输出最终结果还要输出一份反思记录这条记录会被过滤、抽取、结构化然后写入经验库下一次执行任务时系统会先根据任务描述检索相关经验把它们注入到提示词中让模型“带着记忆”开始工作。用开发者的日常经验类比普通 Agent 是第一次接手的实习生每次都要从头读文档RLM Agent 是带了工作笔记的老员工开工前先翻笔记再决定怎么做。笔记本身会越记越厚能力也就在这个过程中逐步提升。1.3 一图看懂自改进闭环整个 self-improving 过程可以抽象为五个阶段任务输入用户提交一个目标比如“写一个 Python 脚本统计日志文件中的错误类型”。经验检索系统根据任务描述在经验库中检索相关反思记录。执行规划模型结合检索到的经验生成任务步骤并执行。结果反思执行结束后模型对照预期评估执行过程生成反思文本。经验入库反思文本经过过滤和结构化后存入经验库供后续任务复用。这个闭环的关键点在于经验不是模型权重而是外部化的记忆。它的好处是可以随时查看、修改、删除甚至可以做版本管理比微调模型成本低得多效果也更可控。注意RLM 并不要求必须使用某个特定模型。只要是支持函数调用或工具调用的大语言模型接口都可以通过提示词工程实现反思回路。2. 可落地的整体设计不是所有反思都值得进经验库2.1 系统模块划分实际项目里Prime Agent 不能只靠一段提示词实现否则经验会混杂在上下文里无法持久化和复用。建议按五个模块组织代码模块职责对应文件数据模型定义经验、任务记录、反思结果的结构models.py经验存储负责经验的写入、检索、过滤和持久化store.py任务执行器调用大模型完成任务收集过程信息executor.py反思生成器对执行过程进行评估和反思reflector.py主流程控制器串联任务、检索、执行、反思、入库几个阶段pipeline.py这五个模块各司其职。经验存储是核心它是 self-improving 的载体反思生成器是质量阀门它决定哪些经验值得沉淀。2.2 经验数据模型设计经验库不能只存一段反思文本否则检索和复用都会很困难。每条经验至少需要以下字段字段类型说明idstr经验唯一标识task_typestr任务类型用于场景匹配triggerstr经验触发条件用于检索lessonstr经验正文描述怎么做或不要怎么做code_snippetstr可复用的代码片段tagslist[str]标签辅助检索successbool该经验来自成功还是失败案例usage_countint被复用次数created_atstr创建时间在设计层面最关键的是 trigger 和 task_type。trigger 决定了这条经验在什么场景下被召回task_type 决定了它属于哪一类任务。没有这两个字段的经验库相当于没有索引的数据库检索时只能靠全文匹配精度和效率都不行。2.3 经验注入策略在规划阶段给模型“看笔记”经验注入不能把所有经验都塞进提示词。大模型的上下文长度有限经验太多反而会干扰当前任务判断。推荐采用“前两步决策法”第一根据任务描述确定 task_type筛掉明显不相关的经验。第二在同一 task_type 内通过关键词相似度和标签匹配召回最相关的 3 到 5 条经验。第三将召回的教训和代码片段放到规划提示词的“历史经验”段落中要求模型先阅读经验再输出执行计划。这里要特别提醒经验注入是给模型提供参考依据不是让模型放弃独立判断。因此提示词里要加一句“历史经验来自过往任务如果与当前任务冲突以当前任务为准”。这样能避免模型把过时经验当作硬性约束降低错误复用的概率。3. 环境准备和项目结构先把依赖对齐避免后面报错3.1 学习环境与生产环境的要求差异为了快速验证 self-improving 闭环学习环境不需要太重。建议使用 Python 3.10 以上版本配合 openai、fastapi、pydantic 这几个库就能跑通主流程。生产环境则需要额外考虑数据库选型、并发写入、鉴权、监控和任务隔离不能直接把单机 JSON 文件方案原样搬上去。环境Python 版本存储模型接口建议学习环境3.10JSON 文件任一兼容 OpenAI 接口的服务跑通闭环最重要开发环境3.10SQLite同一模型服务增加日志和经验审查生产环境3.10PostgreSQL/Redis按场景拆分模型需要监控、限流、备份和审核核心区别在于存储和可观测性。学习环境里经验库只是一个小 JSON 文件方便直接打开查看内容生产环境里经验库是团队共享资产同一份经验可能被多个业务线复用必须考虑权限、版本和一致性。3.2 项目目录结构下面给出一个最小可运行的项目骨架。实际项目可根据团队习惯调整但这个结构已经能覆盖“检索、执行、反思、入库”四个核心环节。prime_agent/ __init__.py models.py store.py executor.py reflector.py pipeline.py main.py config.yaml requirements.txt experience_store.jsonrequirements.txt 内容如下openai1.30.0 pydantic2.7.0 pydantic-settings2.2.0 PyYAML6.0.1 python-dotenv1.0.1每个文件职责如下models.py定义经验、任务记录等 Pydantic 模型。store.py提供经验存取、检索、去重能力。executor.py封装大模型调用和函数调用逻辑。reflector.py生成反思结果并评估是否入库。pipeline.py把流程串联起来。main.py命令行入口支持交互式输入任务。3.3 环境变量和模型配置在项目根目录创建 .env 文件用于存放模型服务相关配置。示例OPENAI_API_KEYyour_api_key_here OPENAI_BASE_URLhttps://your_model_service_endpoint DEFAULT_MODELgpt-4o-mini这里不要在生产环境把 API Key 写进代码或提交到 Git 仓库。学习环境可以先用本地文件生产环境建议使用密钥管理服务或环境变量注入。配置文件 config.yaml 示例model: provider: openai_compatible model_name: gpt-4o-mini temperature: 0.3 max_tokens: 2048 experience: store_path: ./experience_store.json max_results: 5 min_similarity: 0.4 reflection_threshold: 0.7 agent: max_steps: 5 timeout_seconds: 60temperature 设置为 0.3 是为了在稳定性和生成质量之间取一个平衡。反思生成阶段可以稍微调高到 0.5让模型更愿意提出不同角度执行阶段建议保持较低温度减少随机输出。注意不要试图一次性把所有参数都调到最“完美”。先把闭环跑通再根据实际任务效果迭代参数。4. 核心代码实现从经验模型到反思入库4.1 数据模型定义先用 Pydantic 定义核心数据结构。下面代码是 models.py。from pydantic import BaseModel, Field from typing import Optional from datetime import datetime, timezone def now_utc(): return datetime.now(timezone.utc).isoformat() class Experience(BaseModel): id: Optional[str] None task_type: str Field(..., description任务类型例如 data_extraction, code_generation) trigger: str Field(..., description触发条件例如 统计日志中的错误类型) lesson: str Field(..., description经验正文告诉模型应该怎么做) code_snippet: str Field(default, description可复用的代码片段) tags: list[str] Field(default_factorylist) success: bool True usage_count: int 0 created_at: str Field(default_factorynow_utc) class TaskRecord(BaseModel): task: str task_type: str output: str used_experience_ids: list[str] Field(default_factorylist) success: bool True created_at: str Field(default_factorynow_utc) class ReflectionResult(BaseModel): should_store: bool reason: str experience: Optional[Experience] Noneid 字段在创建时自动生成可以使用 uuid。注意 task_type 是必填字段这要求调用方在任务进入流程前先完成分类不能省略。4.2 经验存储与检索store.py 负责经验的增删改查和相似度检索。这里使用简单的字符重叠和标签匹配来模拟语义检索。生产环境建议替换成向量检索但核心接口可以保持一致。import json import uuid from pathlib import Path from typing import List from models import Experience class ExperienceStore: def __init__(self, path: str ./experience_store.json): self.path Path(path) self.items: List[Experience] [] self.load() def load(self): if self.path.exists(): raw json.loads(self.path.read_text(encodingutf-8)) self.items [Experience(**item) for item in raw] def save(self): self.path.write_text( json.dumps([item.model_dump() for item in self.items], ensure_asciiFalse, indent2), encodingutf-8 ) def add(self, exp: Experience): exp.id str(uuid.uuid4()) self.items.append(exp) self.save() return exp.id def search(self, task: str, task_type: str, top_k: int 3) - List[Experience]: scored [] for exp in self.items: score 0.0 if exp.task_type task_type: score 1.0 overlap len(set(exp.trigger) set(task)) score overlap / max(len(task), 1) if len(exp.tags) 0: tag_hit sum(1 for tag in exp.tags if tag in task) score tag_hit * 0.3 scored.append((score, exp)) scored.sort(keylambda x: x[0], reverseTrue) return [exp for _, exp in scored[:top_k]] def deduplicate(self, exp: Experience) - bool: for item in self.items: if item.trigger exp.trigger and item.task_type exp.task_type: return False return True这个检索方式比向量检索粗糙但足够说明原理。关键点在于 search 方法返回的是带排序的经验列表而不是随机经验。实际项目中可以替换成 embedding 相似度检索不仅支持语义匹配还能处理同义表达。这里要解释一个细节为什么用字符重叠而不是简单的 in 判断因为 in 只能判断子串字符重叠可以捕捉中文分词不精准时的部分命中。这个思路适合原型阶段生产环境还是建议用向量检索或 BM25 这类成熟方案。4.3 任务执行器executor.py 封装大模型调用。它接收任务描述和检索到的经验列表把它们拼接成系统提示词然后调用模型接口返回结果。import os from typing import List from openai import OpenAI from models import Experience class TaskExecutor: def __init__(self): self.client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) self.model os.getenv(DEFAULT_MODEL, gpt-4o-mini) def build_prompt(self, task: str, experiences: List[Experience]) - str: header 你是一名有经验的技术助手请完成以下任务。 if experiences: experience_blocks [] for idx, exp in enumerate(experiences, 1): block f参考经验 {idx}\n block f任务类型{exp.task_type}\n block f触发场景{exp.trigger}\n block f经验教训{exp.lesson}\n if exp.code_snippet: block f代码参考\n{exp.code_snippet}\n experience_blocks.append(block) experience_text \n.join(experience_blocks) reminder \n注意以上经验来自过往任务如果与当前任务冲突以当前任务为准。 return header \n\n experience_text reminder \n\n任务 task return header \n\n任务 task def run(self, task: str, experiences: List[Experience]) - str: prompt self.build_prompt(task, experiences) response self.client.chat.completions.create( modelself.model, messages[ {role: system, content: 你是一个执行任务的技术助手。}, {role: user, content: prompt}, ], temperature0.3, ) return response.choices[0].message.content这段代码有几个要点。第一历史经验放在用户消息中而不是系统消息中因为系统消息一般用于固定角色设定经验是动态内容放用户消息里更灵活。第二每次调用都构造新 prompt避免状态污染。第三使用了 OpenAI 兼容客户端这意味着无论底层是哪个模型服务只要兼容 OpenAI 接口格式就能用。4.4 反思生成器reflector.py 是 self-improving 的关键模块。每次任务执行后它会把任务、输出和预期目标组合成反思提示词让模型输出结构化反思结果。import json import re from openai import OpenAI from models import Experience, ReflectionResult class Reflector: def __init__(self): self.client OpenAI( api_keyos.getenv(OPENAI_API_KEY), base_urlos.getenv(OPENAI_BASE_URL), ) self.model os.getenv(DEFAULT_MODEL, gpt-4o-mini) def reflect(self, task: str, task_type: str, output: str) - ReflectionResult: prompt f 你是一个智能体反思器。请根据以下任务执行记录生成反思结果。 任务{task} 任务类型{task_type} 执行结果 {output} 请从以下维度反思 1. 任务是否成功完成。 2. 执行过程中可能存在的问题。 3. 如果未来遇到类似任务应该复用哪些经验。 4. 是否值得将这条经验存入经验库。 请严格输出 JSON {{ should_store: true 或 false, reason: 简要说明判断理由, lesson: 经验教训正文, code_snippet: 可复用的代码片段没有则留空, trigger: 触发这条经验的场景描述, tags: [标签1, 标签2] }} .strip() response self.client.chat.completions.create( modelself.model, messages[{role: user, content: prompt}], temperature0.5, ) content response.choices[0].message.content return self._parse(content) def _parse(self, content: str) - ReflectionResult: match re.search(r\{.*\}, content, re.S) if not match: return ReflectionResult(should_storeFalse, reason反思输出 JSON 解析失败) try: data json.loads(match.group()) exp Experience( task_typedata.get(task_type, ), triggerdata.get(trigger, ), lessondata.get(lesson, ), code_snippetdata.get(code_snippet, ), tagsdata.get(tags, []), successdata.get(success, True), ) return ReflectionResult( should_storedata.get(should_store, False), reasondata.get(reason, ), experienceexp, ) except Exception as e: return ReflectionResult(should_storeFalse, reasonf解析失败: {e})反思模块的核心是让模型“回顾自己的执行过程”。为什么这里值得单独用一个模型调用而不是复用执行结果因为执行模型的目标是完成任务反思模型的目标是评估任务过程两者关注点不同。让同一个模型边输出答案边反思容易造成结果中混入大量分析性文本干扰执行质量。4.5 主流程控制器pipeline.py 把前面几个模块串起来形成完整的 self-improving 循环。from store import ExperienceStore from executor import TaskExecutor from reflector import Reflector class AgentPipeline: def __init__(self): self.store ExperienceStore() self.executor TaskExecutor() self.reflector Reflector() def run(self, task: str, task_type: str): # 1. 检索历史经验 experiences self.store.search(task, task_type, top_k3) used_ids [exp.id for exp in experiences if exp.id] # 2. 执行任务 output self.executor.run(task, experiences) # 3. 反思 reflection self.reflector.reflect(task, task_type, output) # 4. 经验入库 if reflection.should_store and reflection.experience: exp reflection.experience if self.store.deduplicate(exp): exp.id self._new_id() self.store.add(exp) stored exp.id else: stored None else: stored None return { output: output, used_experiences: used_ids, reflection_reason: reflection.reason, stored_experience: stored, } def _new_id(self): import uuid return str(uuid.uuid4())主流程共四步。第一次运行时经验库为空所以检索结果为空任务会以“无经验”模式执行。执行后反思成功经验写入经验库。第二次运行同一类任务时系统就能检索到经验并注入提示词这就是“自我改进”的第一次体现。4.6 命令行入口main.py 提供一个简单交互入口方便验证效果。from pipeline import AgentPipeline from models import TaskRecord def main(): pipeline AgentPipeline() task_types [data_extraction, code_generation, question_answering] while True: task_type input(f输入任务类型 {task_types}q 退出: ).strip() if task_type.lower() q: break task input(输入任务描述: ).strip() if not task: continue result pipeline.run(task, task_type) print(\n 执行结果 ) print(result[output]) print(\n 反思 ) print(result[reflection_reason]) if result[stored_experience]: print(f新增经验 ID: {result[stored_experience]}) print( * 50) if __name__ __main__: main()5. 运行验证用连续任务观察“改进”是否真的发生5.1 第一次运行无经验冷启动用两个同类型任务验证闭环效果。第一次执行任务“请写一个 Python 函数接收一个字符串列表返回按长度排序后的列表。”当时经验库为空执行结果可能只是最普通的排序实现。执行结束后反思器会生成一条经验记录“这类任务可以直接使用 sorted(keylen) 实现”“如果列表很长要考虑是否保留原始顺序”等信息。关键观察点是经验库是否新增了记录。如果 experience_store.json 里出现了新经验说明反思和入库链路正常。5.2 第二次运行经验注入后行为变化第二次执行同一类型任务“请写一个 Python 函数接收一个字符串元组返回按长度降序排列的列表。”系统会先在经验库中检索到第一次记录的排序经验然后把它注入提示词。一个可能的结果是第二次输出不仅实现了排序还会主动说明排序稳定性、是否使用稳定排序、是否保留索引甚至给出两种实现。此时需要对比两次输出对比项第一次执行第二次执行是否提到排序稳定性可能没有可能体现是否复用旧代码逻辑无可能复用回答结构只给出代码可能包含边界讨论经验库规模0 条1 条以上这个对比就是 self-improving 的直接证据。不需要跑复杂指标只要看到第二次行为受第一次经验影响闭环就成立。5.3 验证经验失效和复用效率再做一个反向测试。手动往经验库里写入一条明显有问题的经验比如“字符串排序永远使用随机顺序”。然后执行相同任务观察模型是否会被误导。这个测试能验证两件事第一经验检索是否真的会把该经验注入第二模型是否具备“以当前任务为准”的判断能力。如果模型完全被错误经验控制就要调整提示词中“冲突以当前任务为准”的权重或者降低经验检索的 top_k 数量。把这个测试写成一个脚本可以用于日常巡检from pipeline import AgentPipeline from store import ExperienceStore from models import Experience pipeline AgentPipeline() store pipeline.store bad_exp Experience( task_typecode_generation, trigger字符串列表排序, lesson排序时使用随机顺序, code_snippet, tags[sort, random], successTrue, ) store.add(bad_exp) result pipeline.run(请写一个按长度降序排列字符串列表的 Python 函数, code_generation) print(result[output])生产环境中不应该用这种破坏性测试直接操作正式经验库建议在开发环境执行或者把经验库拆成测试库和正式库。6. 常见问题排查从现象倒推根因6.1 经验库不断膨胀提示词越来越长现象运行多次后检索到的经验越来越多prompt 长度快速上涨模型响应变慢甚至超时。可能原因经验去重逻辑不严格或者 top_k 设置过大又或者经验检索没有按 task_type 过滤。检查方式查看 experience_store.json 中总条数打印每次检索实际注入的经验数量。处理建议在 search 方法里先过滤 task_type再对同类型经验做相似度排序去重判断不能只看 trigger 完全相同建议用语义相似度阈值同时把 top_k 控制在 3 到 5 条。如果经验库超过几百条应该迁移到向量数据库用 embedding 检索替代字符重叠检索。6.2 反思结果质量差入库经验没有价值现象经验库里有大量内容如“遇到问题要仔细分析”“注意代码规范”这类空话对后续执行没有实质帮助。可能原因反思提示词缺少约束条件模型默认输出泛化结论。检查方式随机抽取 20 条经验统计包含具体代码片段的比例、包含具体参数名的比例。处理建议在反思提示词中强制要求“如果可复用代码片段为空则 should_store 必须为 false”“经验教训中不能只写建议要包含具体操作和参数”。还可以在入库前增加人工审核或规则过滤比如检测 lesson 字数是否大于 20是否包含代码关键字。问题现象常见原因检查方式处理建议经验注入后执行更差错误经验复用打印注入的全部经验文本增加人工审核或降低 top_k同一经验重复入库去重逻辑只查 trigger查看去重方法的匹配条件升级为语义去重反思耗时过长反思调用单独占一次模型请求统计单次任务整体耗时异步反思不阻塞任务主流程经验库 JSON 损坏并发写入查看异常堆栈使用 SQLite 或数据库存储6.3 Agent 执行超时或报错现象模型接口返回超时或出现类似“agent execution terminated due to error”的错误导致任务中断。可能原因模型服务不稳定、prompt 过长、单次任务执行步骤超过限制。检查顺序确认模型接口地址和 Key 是否配置正确。确认 prompt 总长度是否接近上下文上限。确认网络和模型服务状态是否正常。查看模型返回的 error code判断是鉴权、限流还是内容过滤。确认是否需要对长任务做分步执行。处理建议在 executor 和 reflector 中都加上超时和重试机制。第一次失败后等待 1 到 2 秒重试重试不超过 3 次。给每个任务设置最大执行步骤避免死循环。生产环境建议引入消息队列和任务状态机将任务执行从单次 HTTP 调用中解耦出来。6.4 经验在会话之间不可见现象一次任务结束后经验写入成功但新进程启动后检索结果为空。可能原因ExperienceStore 在 init 时从文件加载经验如果进程之间没有共享同一个存储路径或者文件写入失败就会丢数据。检查方式确认所有进程使用的 experience_store_path 是否一致查看文件是否存在且内容非空检查 store.save 是否被成功调用。处理建议学习环境用相对路径时要确保工作目录一致。生产环境不要直接读写 JSON 文件使用数据库存储。如果要支持多实例必须使用共享存储同时加上行级锁或乐观锁避免并发覆盖。7. 从原型到生产self-improving agent 的最佳实践7.1 经验库设计要面向审查和回滚经验库是自我改进系统的“记忆资产”但它也可能包含错误经验。生产环境应该做到三点第一每条经验都带入库来源比如任务唯一 ID、模型版本、执行时间。这样一旦某条经验导致问题可以直接定位到源头。第二保留经验版本同一触发条件下可以有多条候选经验线上优先使用高置信度经验。第三提供人工审核通道定期抽查经验质量。在数据模型层面需要增加 status、source_task_id、model_version 字段。推荐做法是给 Experience 增加一个 audit 字段记录审核状态未审核的经验默认不进入在线检索。7.2 学习环境和生产环境的存储差异能力学习环境生产环境存储介质JSON 文件PostgreSQL/Redis检索方式字符重叠向量检索 过滤并发控制不加锁乐观锁/分布式锁经验审核无必须有可观测性打印日志指标监控 链路追踪备份策略不备份定期备份学习环境用 JSON 文件最大的好处是透明可以直接打开看内容。生产环境必须用数据库原因不只是性能更重要的是并发安全。同一个经验库如果被多个 Agent 实例同时写入JSON 文件会出现覆盖丢失数据库的事务和锁能保证一致性。7.3 经验质量评估怎么落地self-improving 不能只看“经验有没有写进去”要评估“经验有没有让系统变得更好”。一个可执行的评估方案是构造回归任务集。具体做法准备 20 到 50 个代表性任务涵盖常见任务类型。先用无经验模式跑一遍记录结果和成功率。开启经验注入跑相同的任务集。对比两个结果的成功率、输出质量和执行耗时。每次更新经验库后重跑记录指标变化。评估指标建议使用三层任务成功率、关键步骤正确率、人工满意度评分。前两层可以由程序自动判断第三层需要抽样人工评估。下面是回归任务集的简单结构[ { task: 请写一个 Python 函数将驼峰字符串转下划线, task_type: code_generation, expected: def to_snake_case }, { task: 请从文本中提取所有日期, task_type: data_extraction, expected: regex_date } ]如果开启经验注入后的成功率低于无经验模式说明经验库存在污染或者注入方式干扰了模型判断需要回滚经验并调整 prompt。7.4 元学习和多 Agent 协作扩展方向Prime Agent 的原型跑通后可以从两个方向扩展。第一元学习方向。当前系统沉淀的是单条经验元学习则是让模型总结经验规律。比如多次执行“数据导出”类任务后生成一份“数据导出任务通用步骤”的高层策略减少每个新任务的试错成本。这就是热词中“self-to-meta evolution”的含义从具体经验演化出抽象策略。第二多 Agent 协作方向。设置一个管理者 Agent多个执行型 Agent 共享同一个经验库但各自维护独立的任务记录。管理者负责在任务开始时将任务分配给最适合的 Agent在任务结束后统一汇总反思结果。经验库里增加 owner 字段标记经验来源避免不同 Agent 之间互相污染。7.5 发布前检查清单在把 self-improving Agent 接入生产前建议逐项确认经验库是否有访问权限控制防止外部写入污染。是否设置了最大重试次数和超时时间。反思结果是否先进入待审核区再进入在线经验库。是否记录每一条经验的使用次数和效果反馈。是否能一键清空经验库回到冷启动状态。是否配置了任务级日志可以还原某个任务使用了哪些经验。是否有监控指标观察经验注入后的失败率变化。是否限制单条 prompt 的经验数量避免上下文膨胀。是否对模型返回内容做了格式校验防止非 JSON 输出影响反思流程。是否对敏感任务做了隔离避免经验跨场景复用。这份清单几乎是每个 self-improving Agent 上线前都要做的检查。尤其是“一键清空经验库”这一点看起来简单但能救急。一旦经验库污染导致线上 Agent 大面积输出异常立刻清空经验恢复到无经验模式比逐条删除错误经验更快。8. 扩展方向从单体 Agent 走向可进化的 Agent 系统Prime Agent 强调的是单 Agent 的自我改进闭环但真实系统的复杂度远不止于此。当任务类型超过十种、经验超过几百条、Agent 数量超过一个时就需要考虑更细分的结构。一个建议的方向是引入任务分类器。现在的示例里task_type 由调用方手工指定现实中这不可持续。可以在 pipeline 入口增加一个分类模型自动将任务描述归类到已有 task_type再执行经验检索。这样经验库的管理会更加自动化和准确。另一个方向是经验可视化。用一个小型 Web 管理后台展示经验库内容支持搜索、审核、删除、停用经验并显示每条经验被复用后的任务成功率。这能让“自我改进”过程变得可解释、可干预。没有管理的自我进化一旦跑偏就会形成“越努力越离谱”的效果这是生产过程落地中最需要警惕的一点。从学习角度来看当前这套代码已经没有冗余复杂度重点全部放在“经验从哪来、如何存、如何用、如何评估”这几个核心问题上。建议先亲手把工程跑通连续执行三到五个同类型任务观察经验是如何影响后续输出的。只要能感受到“第二次比第一次更了解这个任务”就说明你对 RLM 和 self-improving agent 的理解已经不再停留在概念层面。