做LLM应用开发的团队大概率都经历过这样的循环同一个系统提示词在上一批数据上跑得很好换了一组真实请求后效果就明显下滑。于是又开始人工改prompt、调工具描述、加few-shot示例一轮下来大半天就没了。这种人肉调优的路径依赖很强因为你调出来的prompt本质上是你对任务分布的理解的编码。一旦真实输入偏离预设的模板Agent的表现就会回落。人工跟进还有一个更隐蔽的问题反馈周期太长。线上数据回流到可用的改进依据往往需要几天甚至几周同一个Agent在不同任务类型上的失败模式还可能完全不同人工很难在有限时间内覆盖所有场景。这正是自我改进型智能体Self-Improving Agent值得关注的原因。它想解决的问题很朴素既然模型能生成文本、能调用工具、能写代码那能不能让它基于运行过程中沉淀的经验自动调整自己的策略形成运行—评估—改进的闭环标题里的Prime Agent可以看作这个方向的一个具体实践一个以RLMRecursive/Reasoning Language Model具备递归推理能力的大语言模型为核心的自我改进Agent。这篇文章不会停在概念讨论我会从工程视角拆解自我改进Agent最少需要哪几个模块并给出一个可以跑通的最小闭环示例。读完你会理解为什么经验正在成为LLM应用开发的重要资产self-improving、self-evolving、meta-evolution这几个层次的真实区别如何用最小的代码实现经验驱动prompt自动迭代以及真正容易踩坑的地方在哪里。1. 这篇文章真正要解决的问题先给一个比较直接的判断自我改进Agent的核心价值不是模型自己会写prompt这个噱头而是把LLM应用开发的调优成本从人肉加运气变成数据加闭环。传统LLM应用开发有一个很典型的流程人工设计system prompt设定角色、任务规则、输出格式招少量测试样本人工跑一遍看输出质量发现问题修改prompt再跑上线后靠用户反馈继续迭代。这个流程最大的问题在于反馈链路太长。线上日志、用户反馈、失败案例没有回流到策略层下一次改进仍然依赖人重新分析。而且一旦Agent接入的工具变多、任务类型变多人工就很难判断当前效果差到底是prompt问题、工具选择问题还是任务拆解问题。自我改进Agent的思路是把经验当作一等公民沉淀下来。每次任务执行的结果、评分、上下文、错误信息都变成结构化的记录。系统在一个批次运行结束后自动分析这些经验找出失败共性生成新的策略候选再通过回归验证决定是否替换当前策略。这个闭环让调优从人工手艺变成可以自动运转的工程系统。这篇文章的读者不是只想要一个新概念的人而是真正想把Agent调到更好用的工程师。最适合的场景包括你有一个稳定运行的Agent服务但效果总差口气又不想频繁人工调prompt你需要Agent在多个任务类型上持续工作人工跟进不过来了你已经积累了运行日志但不知道怎么把这些日志变成模型能力你在设计Agent框架想提前把自我改进能力留出扩展位。如果只是想了解概念看综述就够了。但这篇文章更希望推动你动手做一个最小版本。看完之后你可以在自己的项目里先落地一个简单的运行—评估—改进循环再逐步扩展。2. 核心概念RLM、自我改进与经验闭环2.1 RLM到底是什么RLM这个缩写在近期的论文和项目中出现过多种含义Recursive Language Model递归语言模型、Reasoning Language Model推理语言模型、Reward Language Model奖励语言模型。不同的团队在用词上有自己的偏好。在Self-Improving RLM Agent这个组合里理解成具备递归/推理能力的大语言模型更符合直觉。它强调的不是单纯的文本生成而是模型在执行任务时可以反复推理、审视中间结果、修正路径。你可以把它类比为一个边做边想的Agent先推理再行动看结果再调整。之所以要强调RLM而不是普通LLM是因为自我改进的前提是对错误有感知。如果模型只能一次性输出而不能回看自己的推理过程那改进就无从谈起。具备递归推理能力的模型可以把一次失败拆解成哪一步决策出了问题为后续改进提供更精准的信号。2.2 自我改进的三个层次社区里讨论的自我改进实际上包含几个递进层次很容易混淆Self-execution模型自己执行任务这是基础能力不算改进Self-improvement模型基于执行结果反馈在固定任务上改进自己的策略Self-evolution模型在一个分布不断变化的任务流上持续调整自身能力而不是只优化某一个静态任务Meta-evolution模型开始改进改进过程本身比如学会如何选择经验、如何设计评估指标、如何决定更新时机。从self-improvement到meta-evolution本质上是控制权从人逐步让渡给系统。第一层仍然依赖人来设计反馈信号第二层开始由系统自动从经验中学习第三层则把学习策略本身也纳入优化对象。2.3 经验为什么成为关键资产在传统机器学习里数据通常是标注好的静态样本。但Agent的运行经验不是这样它天然带有时序性、场景性和上下文性。一条经验通常包含任务描述、输入上下文、Agent采取的步骤、最终输出、评估结果、错误信息、耗时等。这些经验的价值在于它们是模型在真实运行环境中踩坑后留下的痕迹。相比人工构造的测试集运行经验更贴近真实分布相比静态benchmark它能持续反映线上场景的变化。后面我们会看到一个自我改进系统本质上就是经验采集—经验分析—策略更新—回归验证的闭环。3. 自我改进Agent的技术架构拆解这一节很重要。理解了架构你才知道一个能自我改进的Agent系统最少需要哪些组件也才能分辨哪些项目是概念包装哪些是真能力。一个最小闭环系统至少包含四层执行层、经验层、评估层、改进层。执行层是Agent本体负责接收任务、调用工具、生成输出这一层就是我们熟悉的LLM加工具调用框架。经验层负责记录每次执行产生的结构化经验包括成功的、失败的、异常的。评估层负责对执行结果打分评估器可以是规则、独立模型、人工反馈或多个混合。改进层负责基于经验池中的失败样本生成策略改进候选并通过回归验证决定是否更新。整体流程是执行层产生输出评估层打分经验层存储改进层定期分析失败样本生成新的prompt或few-shot示例再回到执行层做回归验证。这里的关键不是某个单点能力而是四层之间的数据协议是否稳定。3.1 执行层的关键是可观测执行层最大的坑是只记录最终输出不记录过程。Agent每执行一步都应该留下日志当前任务、当前步骤、调用的工具、输入的参数、输出内容、引发的异常。没有这些过程数据后面的评估和改进都无法定位具体问题。3.2 经验层不只是数据库经验层承担经验检索的作用。改进层分析失败时需要按任务类型、错误类型、时间范围等维度检索经验。建议按任务类型分桶存储避免不同任务的失败样本混在一起。如果经验量很大还需要去重、过滤和生命周期管理。3.3 评估层决定上限评估器是自我改进系统里最容易被低估的组件。如果分数不可靠后面的改进都是错误方向的强化。评估器的设计决定了整个闭环的上限它必须和生成器解耦避免自己评价自己的偏差。3.4 改进层要支持版本回溯改进层负责把经验转化为策略。常见策略包括优化system prompt、增加few-shot示例、调整工具描述、修改任务拆解方式、改变模型参数。每一次改进都应该生成一个新的策略版本并绑定评估结果方便回滚。4. 环境准备与最小系统搭建在动手之前先说清楚本文示例所需的环境。这里不写死具体版本以你实际项目为准Python 3.9以上建议3.10或3.11一个可调用的LLM服务可以是OpenAI兼容的API也可以是本地部署的模型服务一个简单的文件系统或SQLite用于存储经验记录git用于对策略版本做代码级管理。为了演示我会模拟一个典型场景有一个Agent负责从日志中判断异常原因并给出修复建议。我们希望这个Agent能随着经验积累自动改进自己的prompt提高修复建议的准确率。本文的代码是教学型的最小实现重点不是工程完备性而是把闭环思路跑通。你在生产环境中可以直接复用这套设计再替换成自己的评估器和存储方案。4.1 初始化项目结构建议把项目拆成下面几个文件agent/ ├── experience.py # 经验数据结构与存储 ├── evaluator.py # 评估器 ├── improve_loop.py # 改进闭环 ├── runner.py # Agent执行入口 ├── client.py # LLM客户端封装 ├── experiments/ │ └── prompts/ │ ├── prompt_v1.txt │ └── prompt_v2.txt └── experience_store/ └── records.jsonl这样做的目的是让每个模块职责单一执行、评估、存储、改进互相解耦。后续如果要替换存储方案或评估模型只需要改对应模块。4.2 初始化LLM客户端不管你是用OpenAI SDK还是其他兼容服务都可以按下面方式封装一个简单的客户端# 文件路径client.py from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlyour-base-url # 自建服务或兼容接口 ) def chat(system_prompt: str, user_message: str, model: str your-model) - str: resp client.chat.completions.create( modelmodel, messages[ {role: system, content: system_prompt}, {role: user, content: user_message} ], temperature0.2 ) return resp.choices[0].message.content注意这里的模型名和API地址要根据你的部署环境替换。如果是自建模型重点确认服务是否兼容OpenAI的chat completions接口这是目前最通用的协议。5. 完整示例从经验池驱动Agent自我改进这一节会给出一个能跑起来的完整最小闭环。我们分三部分来实现经验记录、评估器、改进循环。5.1 定义经验数据结构经验记录是整个系统的数据基础。我们用dataclass定义一个结构保证每条经验都有统一的字段方便后续聚合分析。# 文件路径experience.py import json import time from dataclasses import dataclass, field, asdict from typing import Any, Dict, Optional dataclass class ExperienceRecord: task_id: str task_desc: str prompt_version: str input_payload: Dict[str, Any] output: Optional[str] None score: Optional[float] None error: Optional[str] None created_at: float field(default_factorytime.time) def to_json(self) - str: return json.dumps(asdict(self), ensure_asciiFalse) staticmethod def from_json(line: str) - ExperienceRecord: data json.loads(line) return ExperienceRecord(**data)这段代码里值得注意的地方是task_desc和prompt_version两个字段。task_desc用于区分任务类型改进时按任务聚合失败样本prompt_version用于把经验和当时的策略版本关联起来这是回滚和版本追溯的关键。5.2 实现一个可组合的评估器评估器决定了什么算好。这里的示例混合了规则和LLM判断两种方式。规则评估稳定、免费、即时适合硬性校验LLM评估灵活适合开放性任务但成本和随机性更高。生产环境通常组合使用。# 文件路径evaluator.py import json from experience import ExperienceRecord def rule_based_score(record: ExperienceRecord) - float: if record.error: return 0.0 if not record.output: return 0.0 try: data json.loads(record.output) if data.get(status) ok and suggestion in data: return 1.0 return 0.5 except json.JSONDecodeError: return 0.3 def llm_judge_score(record: ExperienceRecord, judge_client) - float: prompt f 你是一个严格的评估员。请根据以下任务和模型输出从正确性、完整性和可执行性三个维度评分。 任务{record.task_desc} 输入{json.dumps(record.input_payload, ensure_asciiFalse)} 模型输出{record.output or 无输出} 请只返回 0 到 1 之间的小数不要输出其他内容。 resp judge_client.chat.completions.create( modeljudge-model, messages[{role: user, content: prompt}], temperature0 ) try: return float(resp.choices[0].message.content.strip()) except ValueError: return 0.0评估器使用独立的模型进行判断而不是让执行模型自己评价自己。实际项目中可以采用规则预筛 LLM精判的组合先过滤掉明显不合格的输出再对边界样本做深度评估这样能明显降低成本和延迟。5.3 实现经验驱动的改进循环改进循环是整个系统的核心。它读取经验池中的失败样本交给LLM进行诊断加生成新prompt然后触发回归验证。注意这里没有自动替换prompt而是先产出候选版本再由人工或回归测试决定是否上线。# 文件路径improve_loop.py import json from collections import defaultdict from experience import ExperienceRecord def load_records(path: str): records [] with open(path, r, encodingutf-8) as f: for line in f: line line.strip() if line: records.append(ExperienceRecord.from_json(line)) return records def find_failed_records(records, threshold0.6): failed [] for r in records: if r.score is not None and r.score threshold: failed.append(r) return failed def analyze_failures(failed_records): 按任务描述聚合失败样本找出集中失败的任务类型 task_buckets defaultdict(list) for r in failed_records: task_buckets[r.task_desc].append(r) return task_buckets def generate_new_prompt(client, task_desc, failed_records): examples \n.join([ 任务{0}\n输入{1}\n输出{2}\n评分{3}.format( r.task_desc, json.dumps(r.input_payload, ensure_asciiFalse), r.output, r.score ) for r in failed_records[:5] ]) prompt f 你是一名提示词工程专家。下面是当前 Agent 在任务「{task_desc}」上的失败案例。 请分析失败原因并生成一个新的 system prompt。 新 prompt 要解决这些失败案例暴露的问题同时保持原有能力。 只输出新的 system prompt 本身不要输出解释。 resp client.chat.completions.create( modelimprove-model, messages[{role: user, content: prompt}], temperature0.5 ) return resp.choices[0].message.content.strip() def improve_once(client, current_prompt, records, threshold0.6, min_failed3): failed find_failed_records(records, threshold) if len(failed) min_failed: return current_prompt, False, {} buckets analyze_failures(failed) # 只改进失败任务最集中的那个任务类型 top_task max(buckets.items(), keylambda x: len(x[1])) new_prompt generate_new_prompt(client, top_task[0], top_task[1]) return new_prompt, True, {task_desc: top_task[0], failed_count: len(top_task[1])}这里的关键点是min_failed阈值。它的作用是防止系统在失败样本太少时就盲目改prompt。从实际经验看一次改进只针对一个失败最集中的任务类型比一次性改所有任务类型更可控也更容易验证归因。5.4 用一个Runner串起整个流程最后需要一个Runner把执行任务—记录经验—触发改进串起来。# 文件路径runner.py import json import uuid from client import chat from experience import ExperienceRecord from evaluator import rule_based_score SYSTEM_PROMPT open(experiments/prompts/prompt_v1.txt, encodingutf-8).read() def run_task(task_desc: str, payload: dict, record_path: str): task_id str(uuid.uuid4()) record ExperienceRecord( task_idtask_id, task_desctask_desc, prompt_versionv1, input_payloadpayload ) try: output chat(SYSTEM_PROMPT, json.dumps(payload, ensure_asciiFalse)) record.output output except Exception as e: record.error str(e) record.score rule_based_score(record) with open(record_path, a, encodingutf-8) as f: f.write(record.to_json() \n) return record这样一个最小的自我改进系统就成型了。当前版本里改进是离线触发的先积累一批经验再调用improve_once生成新prompt验证通过后再替换SYSTEM_PROMPT。6. 运行效果与验证方法6.1 如何运行先用一个脚本批量执行若干任务生成经验python -c from runner import run_task tasks [ (日志异常诊断, {log: 2024-06-01 10:32:11 ERROR OrderService NPE at line 42}), (日志异常诊断, {log: 2024-06-01 10:35:29 ERROR PaymentService timeout after 3000ms}), (日志异常诊断, {log: 2024-06-01 10:36:01 ERROR CacheService connection refused}), ] for task, payload in tasks: record run_task(task, payload, experience_store/records.jsonl) print(record.task_id, record.score) 一条经验记录写入文件后看起来是这样{ task_id: 4f2e0b12-9a0c-4b7e-8f6d-3a1d9e2c5b00, task_desc: 日志异常诊断, prompt_version: v1, input_payload: { log: 2024-06-01 10:32:11 ERROR OrderService NPE at line 42 }, output: {\status\: \ok\, \suggestion\: \检查OrderService第42行空指针\}, score: 1.0, error: null, created_at: 1717234330.123 }6.2 如何判断改进是否有效当失败样本累计到一定数量后调用改进循环python -c from client import client from improve_loop import load_records, improve_once records load_records(experience_store/records.jsonl) old_prompt open(experiments/prompts/prompt_v1.txt, encodingutf-8).read() new_prompt, changed, info improve_once(client, old_prompt, records) print(changed:, changed) print(info:, info) if changed: with open(experiments/prompts/prompt_v2.txt, w, encodingutf-8) as f: f.write(new_prompt) 判断改进有效不能只看生成的新prompt是否看起来更有道理。更稳妥的做法是保留一个固定回归测试集这个测试集不参与改进只用于前后对比用旧prompt在回归集上跑一遍记录分数分布用新prompt在回归集上跑一遍记录分数分布比较平均分、失败样本数、任务完成率等指标只有当新prompt在回归集上整体不劣于旧prompt且失败任务上明显提升时才替换。如果失败第一步应该检查评估器是否稳定。LLM评估的随机性、JSON解析失败、超时未记录都会导致经验池里出现噪声样本。一个噪声严重的经验池会把改进方向带偏。7. 常见问题与排查思路自我改进Agent看起来只有三四个模块但真正跑起来后问题往往出在数据质量、评估稳定性和版本管理上。下面整理了一些高频问题问题现象可能原因排查方式解决方案新prompt在旧任务上能力下降没有做回归验证就替换对比新旧prompt在固定回归集上的分数增加不可变的回归集验证通过后才替换评分忽高忽低改进方向不稳定评估模型temperature设置过高检查评估调用参数和日志评估时temperature置0多次采样取均值经验池增长过快分析越来越慢缺少去重、过滤和分桶查看records文件中的重复任务按任务类型分桶定期清理重复和低质量记录改进过拟合到失败样本训练分布和测试分布不一致对比改进前后在回归集上的表现将经验池拆分为改进集和验证集循环不收敛每次都在改不同方向失败样本噪声大或改进信号弱人工抽查失败样本和评分调高min_failed阈值降低改进频率增加人类审核API调用成本持续上升每次改进都调用多个大模型查看日志中LLM调用次数增加缓存用小模型预筛批量评估代替逐条评估这里还想多说一句很多自我改进项目做不出来效果不是因为模型能力不够而是因为经验池本身就是脏的。如果采集阶段没有把输入、步骤、输出、异常完整记录后面的分析就是空中楼阁。所以经验采集接口比改进算法更值得优先投入。8. 工程落地的最佳实践与安全边界如果看到这里你已经对自我改进Agent有了基本动手能力。接下来的内容是你在把它推向生产环境之前必须想清楚的事情。8.1 经验是资产要用资产管理的方式对待它经验数据一旦积累起来价值不亚于标注数据集。建议做三件事结构化每条经验都必须有统一schema字段尽量细分不要把所有内容塞进一个自由文本字段版本化经验记录里要带上prompt_version、模型版本、Agent代码版本方便追溯生命周期管理定期对经验池做清洗、去重、归档避免脏数据长期污染改进过程。8.2 评估器要与生成器解耦在架构上评估模型、执行模型、改进模型可以共用同一个底座但在逻辑上必须解耦。不要让执行模型来评价自己的输出。更稳的方案是规则预筛 独立评估模型精判 关键样本人工抽检三级结构。规则负责拦截硬错误独立评估模型负责质量打分人工抽检负责发现系统性问题。8.3 自动修改Prompt必须设置安全边界自我改进意味着系统可以自动修改自己的行为策略。在开放环境中这存在风险。生产环境建议采用以下控制方式human-in-the-loop自动生成策略候选人工确认后再发布灰度与回滚新prompt先在少量流量上灰度观察指标后再全量上线后保留历史版本随时回滚变更审计每次策略改动都生成一条审计日志记录修改时间、触发原因、涉及的任务类型和通过的回归结果权限最小化自动更新prompt的能力只授予信任的进程不放在公共调用链上。8.4 关注成本与延迟每轮改进都会产生额外的大模型调用。如果是高频Agent服务建议只在批量离线阶段执行改进不在线上同步链路中执行对评估结果做缓存同一输入在评估器里不要重复计费对改进频率做限制比如累计失败样本超过50条且时间超过24小时才触发一次改进。8.5 先做垂直再做通用最容易成功的落地方式是选择一两个任务类型的Agent先跑通闭环比如日志诊断、工单分类、代码审查。垂直场景里任务边界清晰、评估标准相对明确自我改进的效果容易量化。等积累了成熟的经验管道再扩展到通用场景。9. 从Self到Meta下一阶段的演进方向最后我们回到self-improving agents in the era of experience这个更大的背景。从近期的综述和项目来看关注点正在从模型能不能自我改进转向如何设计一种能持续演进的经验机制。这个演进趋势可以概括为从self到meta的上升。第一代自我改进系统关注的是一个固定任务上能否用失败样本反哺策略这是经验驱动的单点优化。第二代系统开始考虑任务分布漂移经验不只是用来修bug还用来发现新任务类型、新工具需求Agent会主动感知当前能力覆盖不了哪些输入并决定是否扩展工具或重写流程。第三代系统也就是meta-evolution阶段优化对象变成了改进过程本身系统会学习哪些经验对改进最有价值评估标准应该偏向精确率还是召回率什么情况下应该停止改进以避免过拟合。改进策略本身成为可学习的对象。从工程角度看现阶段更值得投入的是第一代和第二代能力。建议你把本文的最小闭环跑通沉淀自己的经验数据和评估体系。这块基础设施越扎实未来引入更复杂的meta层时就越容易。如果回到文章开头那个人肉调prompt的问题我的建议是不要急着构建一个大而全的自我改进平台。先选一个任务、定一个评估指标、攒一个经验池跑通最小闭环。自我改进的价值不在于模型自己会写prompt这个噱头而在于它把经验变成了可沉淀、可复用、可自动化的工程资产。方向是确定的但路径需要一点点验证。先从一个最小闭环开始你会对这套系统里的每一个环节都有更实在的体感。