最近在折腾 AI Agent 项目时我发现自己绕不开一个问题很多 Agent 跑起来之后同一个错误会反复出现换一种问法就翻车甚至完全依赖人工调 Prompt 才能稳定一点。如果 Agent 只能“执行指令”不能从失败中总结、更新自己的经验那它和一段硬编码的流程几乎没有本质区别。这篇文章我会围绕 Prime Agent 这个“自我改进型 RLM Agent”展开拆解它的核心思路、架构设计、奖励机制和反思流程并给出一个可以直接运行的教学原型。无论你是刚接触 Agent 开发还是已经在用 LangChain、自研 Agent 框架都能从里面拿到一套相对完整的落地思路。1. 什么是 Prime Agent从普通 Agent 到自我改进1.1 为什么普通 Agent 不够用在进入 Prime Agent 之前我们先对齐一下“普通 Agent”的定义。一个典型的 LLM Agent通常包含四部分大语言模型作为“大脑”。工具集例如搜索、计算器、代码执行器、数据库查询接口。Prompt 模板告诉模型当前任务、工具用法和输出格式。执行循环推理 - 选择工具 - 执行工具 - 观察结果 - 再次推理。这套流程已经能解决很多问题比如根据自然语言查询数据库、自动生成报告、调用 API 完成业务操作。但它有个明显的短板模型不会因为“上次失败了”而自动调整自身行为。举一个非常常见的例子用户让 Agent 写一段 Python 代码Agent 生成后代码报错报错原因是KeyError: name。Agent 马上重新生成一次结果还是访问了不存在的字段。重复三次之后它可能仍然没有意识到“需要先检查字典中是否存在 name 字段”。为什么因为大多数 Agent 在每轮对话之间是“无状态”的。你的 Prompt 没变Few-shot 示例没变模型参数没变模型怎么可能突然就学会规避KeyError这就是普通 Agent 的天花板它擅长生成但不擅长从错误中学习。而 Prime Agent 这类“自我改进型 Agent”想解决的问题正是这个。1.2 RLM Agent 的关键词拆解标题里有一个组合词RLM Agent。在 Agent 相关的论文和技术文章中RLM 并没有一个全世界统一的定义。不同语境下它可能指Reinforcement Learning Language Model通过强化学习方式训练语言模型让模型在多次交互中根据奖励信号调整策略。Reasoning Language Model具备更强推理能力的语言模型能根据任务拆解中间步骤。Robot Learning Model在具身智能领域使用的基础模型。在 Prime Agent 的语境下我更愿意把 RLM 理解为“通过强化学习反馈闭环来持续优化语言模型决策的 Agent”。也就是说它不再是“单次调用 LLM 完成任务”而是把每次任务执行都变成一个“尝试 - 得到奖励 - 更新策略”的强化学习过程。和传统 Agent 相比RLM Agent 有几个明显特征维度传统 AgentRLM Agent行为更新靠修改 Prompt靠奖励信号和策略更新失败处理随机重新生成反思错误并沉淀经验记忆使用单轮上下文长期经验库演进能力无可以持续改进可靠评估人工观察奖励函数 评估集这里要注意RLM Agent 并非一定要微调模型。它可以通过 Prompt 动态组装、Few-shot 示例动态选择、工具调用策略调整等方式实现“自我改进”微调只是更重的一种方式。1.3 理解“Self-Improving”“自我改进”这个词看起来很有吸引力但在工程实现上要足够克制。一个真正可落地的自我改进 Agent通常具备以下能力能感知失败任务执行失败时能拿到具体错误信息而不是只拿到一个“失败”的状态码。能定位原因知道错误发生在规划阶段、工具调用阶段还是结果解析阶段。能沉淀经验把失败案例、正确做法、反思过程写入经验库后续可以检索。能影响后续决策新任务到来时会优先参考历史相似经验避免重复踩坑。能在足够样本下更新策略当某一类错误反复出现时能从 Prompt 模板、示例选择或模型参数层面做出调整。当然自我改进也存在风险。如果 Agent 从错误经验中学习了错误结论那改进就变成了“稳定地犯错”。所以后面我又补了一节“安全边界与人工审核”这是生产环境必须考虑的部分。现在我们把 Prime Agent 定位成一个“以 RLM 为内核、带自我改进闭环的 Agent 原型”。2. Prime Agent 整体架构与运行循环2.1 架构模块从工程实现角度我把 Prime Agent 拆成六个模块感知模块接收用户任务解析目标提取约束条件。规划模块把任务拆解成执行步骤决定调用哪些工具。执行模块真正运行工具、执行代码、请求外部 API。记忆模块保存短期上下文和长期经验支持相似度检索。反思模块对失败结果进行归因分析生成改进建议。策略更新模块根据反思结果更新 Prompt、Few-shot 示例或模型参数。整体关系可以用下面的 ASCII 图表示用户任务 | v 感知模块 - 规划模块 - 执行模块 | | | | v v | 工具调用 执行结果 | | | | ---- 反思模块 ---- | | | | v | | 经验库/记忆模块 | | | | ------------------------------- | v 策略更新模块 | v 下一次任务执行从图中可以看到反思模块是整个闭环的关键。没有反思失败只会停留在“这次没成功”而无法变成“下次不失败”的资产。2.2 Agent Loop 的完整流程Prime Agent 的单次任务执行会走完下面这个循环接收任务感知模块提取意图。规划模块根据任务类型选择执行模板和工具列表。执行模块开始调用工具。判断执行结果是否满足预期。如果满足任务结束并把成功经验写入经验库。如果不满足反思模块分析错误类型生成修复建议。把修复建议作为上下文再次进入规划阶段。如果超过最大步数仍然失败则记录失败案例等待人工分析。这里的“判断执行结果是否满足预期”会用到奖励信号。简单任务中奖励信号可以是代码是否编译通过、单元测试是否通过、返回 JSON 是否合法复杂任务中可能需要借助一个独立的评估模型来打分。2.3 与传统 Agent 框架的差异很多 Agent 框架已经提供了“Agent Loop”的能力比如 ReAct 模式Reason Act。但它们的循环和 Prime Agent 的循环有一个关键区别ReAct 的循环Reason - Act - Observe - ReasonObserve 结果仍然只存在于当前上下文窗口不会沉淀成跨任务经验。Prime Agent 的循环Reason - Act - Observe - Reflect - Update PolicyObserve 结果会经过反思并更新策略。所以你甚至可以在 LangChain 这类框架的基础上构建 Prime Agent关键在于补上“反思”和“策略更新”两个环节而不是重新发明轮子。3. 环境准备与项目结构由于本文的实战案例是一个偏教学性质的原型我不会把版本号写死因为不同模型的 API、不同 Agent 框架的依赖差异很大。下面以常见的 Python 环境为例进行说明。3.1 运行环境建议操作系统Windows / Linux / macOS 均可。Python建议 3.10 及以上。模型获取方式本地推理或云端 API 均可。代码执行需要安装 Python 环境建议在虚拟环境中运行。如果你想接大模型 API常见的做法是使用 OpenAI 兼容接口的 SDK或者通过 vLLM、Ollama 等工具启动本地模型服务。例如# 本地模型服务示例按实际模型调整 ollama pull qwen2.5:7b ollama run qwen2.5:7b# 云端 API 示例仅示意不同平台不同 export OPENAI_API_KEYyour-api-key请注意这些命令只是环境准备的一种方式。实际项目中你需要根据自己可用的模型服务调整。3.2 项目目录规划我们用一个固定的项目目录来组织代码prime_agent/ ├── agent/ │ ├── __init__.py │ ├── environment.py # 环境代码执行器、结果判断 │ ├── memory.py # 经验库写入、检索 │ ├── reflector.py # 反思模块 │ ├── policy.py # 策略更新模块 │ └── loop.py # Agent 主循环 ├── tasks/ │ └── sample_tasks.json # 测试任务集 ├── experience/ │ └── .gitkeep # 经验库持久化目录 └── main.py # 入口脚本这个小项目没有引入复杂框架主要依赖 Python 标准库方便你理解核心逻辑。如果你后面需要接入 LangChain 或自研框架可以按模块迁移。3.3 依赖选择说明以下库不是硬性要求只是为了演示json标准库用于经验数据持久化。subprocess标准库用于隔离执行 Python 代码。diff_match_patch可选依赖用于生成代码差异你可以直接用字符串对比代替。openai或requests可选用于调用大模型 API。在最小版本里我会把“大模型生成”做成一个可替换函数默认给出一个基于规则的实现确保代码在没有外部 API 时也能直接跑通。4. 核心机制拆解奖励、记忆、反思与策略更新4.1 奖励信号设计奖励信号是 RLM Agent 的“指挥棒”。设计得好不好直接决定 Agent 往哪个方向自我改进。在设计奖励信号时我通常遵循三个原则可计算奖励必须能从任务结果中自动提取不能依赖人工主观打分。可解释拿到奖励后能知道 Agent 因为什么被奖励、因为什么被惩罚。可分级不要只给 0 和 1要尽量提供中间档位比如“部分成功”“超时但输出正确”。以一个“写代码并运行得到结果”的 Agent 为例奖励可以这样设计情况奖励说明代码执行报错-1.0越早报错说明方案越不可行执行成功但没有输出0.0代码可运行但任务未完成执行成功且输出非空0.5基本完成任务输出与预期完全一致1.0完美完成任务超过最大重试次数-2.0消耗大量资源需人工介入在实际项目中建议把奖励函数单独提取成一个类方便后面做回归测试。4.2 记忆系统与经验库自我改进 Agent 的记忆系统和普通聊天记忆不一样。普通聊天记忆是“上一轮说了什么”而 Prime Agent 需要的是“结构化经验”。一条经验通常包含任务描述失败步骤错误信息反思结论修复后的解决方案对应的奖励分数经验库不只是一个 JSON 列表它还需要支持检索。最朴素的检索方式是关键词匹配进阶方案是向量检索。在本文的示例中我会用简单的标签匹配和关键词匹配来演示这样无需额外依赖向量数据库。4.3 反思机制反思是“从失败中学习”的核心实现。一个常见的误区是把错误信息和正确答案直接拼在 Prompt 里让模型重新生成。这种方式只能解决“当前这一次”不能让 Agent 在下一次任务中主动避免同类问题。真正的反思应该输出结构化结论例如{ task: 统计列表中的偶数个数并返回, error_type: TypeError, root_cause: 对列表中的非整数元素直接取余, fix_suggestion: 先检查元素类型或者使用 isinstance(ele, int) 过滤, improved_rule: 对列表元素做数学运算前需要先确认元素类型 }其中improved_rule是策略更新的关键。它不是一个临时补救而是一条通用规则可以写入经验库后续任务开始时作为参考。4.4 策略更新方式Prime Agent 的策略更新从轻到重有四档Prompt 模板更新把根据错误总结出的通用规则追加到系统 Prompt 里。Few-shot 示例更新从经验库中挑选高奖励的“成功轨迹”作为示例。工具描述更新如果 Agent 经常选错工具就优化工具描述让模型更容易理解每个工具的适用场景。模型微调当经验数据积累到一定规模比如上千条高质量轨迹可以对模型做 LoRA 微调。在原型阶段我们通常只做前两档。因为它们成本低、立竿见影也更容易解释。5. 完整实战实现一个能自我修复代码的 RLM Agent接下来我会构建一个简化但完整的 Prime Agent 原型。它的任务是根据自然语言描述生成 Python 代码运行代码若报错则反思并修复若成功后则提取经验规则。5.1 案例目标我们要让 Agent 完成这样一个任务输入一个包含数字和字符串的列表返回所有数字的和。正确输出可能是6例如[a, 1, 2, 3]数字之和为 6。这个任务很简单但足够体现“代码报错 - 反思 - 修复 - 沉淀规则”的完整闭环。5.2 环境模块执行代码并计算奖励先看环境模块的代码。# 文件路径prime_agent/agent/environment.py import subprocess import sys import json class CodeEnvironment: 代码执行环境负责运行 Agent 生成的 Python 代码并计算奖励。 def __init__(self, timeout: int 10): self.timeout timeout def execute(self, code: str, expected_output: str None): 执行代码返回执行结果、输出和奖励分数。 # 注意subprocess 只是用于教学演示生产环境请使用 Docker 等沙箱 try: result subprocess.run( [sys.executable, -c, code], capture_outputTrue, textTrue, timeoutself.timeout, ) except subprocess.TimeoutExpired: return { success: False, error: TimeoutError: code execution timed out, output: , reward: -1.0, } if result.returncode ! 0: return { success: False, error: result.stderr.strip(), output: , reward: -1.0, } output result.stdout.strip() reward self._calculate_reward(output, expected_output) return { success: reward 0.5, error: , output: output, reward: reward, } def _calculate_reward(self, output: str, expected_output: str) - float: 根据输出和预期结果计算奖励分数。 if output: if expected_output and output expected_output: return 1.0 return 0.5 return 0.0这段代码用subprocess新建子进程运行 Python 代码避免当前进程被死循环卡死。需要说明的是subprocess只是隔离级别最低的一种方式生产环境务必使用 Docker 沙箱或无网络权限的隔离容器避免 Agent 生成的恶意代码造成破坏。5.3 反思模块从错误中提取规则反思模块是本案例里最有价值的模块。这里我提供了一个纯规则版本的反思器方便离线演示。如果接大模型可以把reflect函数中的“规则匹配”替换为“LLM 调用”让模型输出更复杂的归因结论。# 文件路径prime_agent/agent/reflector.py import re import json class RuleReflector: 规则反思器根据错误信息提取修复建议。 ERROR_PATTERNS [ { pattern: re.compile(rKeyError), error_type: KeyError, fix_suggestion: 访问字典前先检查 key 是否存在可以使用 dict.get(), improved_rule: 当访问字典字段时优先使用 .get() 并处理默认值, }, { pattern: re.compile(rTypeError), error_type: TypeError, fix_suggestion: 检查变量类型必要时使用 isinstance 或 type() 做类型判断, improved_rule: 对数据做数学运算前务必先确认元素类型, }, { pattern: re.compile(rIndexError), error_type: IndexError, fix_suggestion: 访问列表前检查索引范围或使用边界判断, improved_rule: 访问列表或元组时先确认索引不超过长度减一, }, { pattern: re.compile(rNameError), error_type: NameError, fix_suggestion: 检查变量是否已定义避免使用拼写错误的变量名, improved_rule: 使用任何变量前先确认该变量已经赋值, }, ] def reflect(self, task: str, code: str, error: str) - dict: 输入任务、失败代码和错误信息输出反思结构。 if not error: return { task: task, error_type: , root_cause: , fix_suggestion: , improved_rule: , } for item in self.ERROR_PATTERNS: if item[pattern].search(error): return { task: task, error_type: item[error_type], root_cause: error, fix_suggestion: item[fix_suggestion], improved_rule: item[improved_rule], } # 未匹配到规则的情况建议交给 LLM 处理 return { task: task, error_type: Unknown, root_cause: error, fix_suggestion: 建议人工分析错误日志, improved_rule: , }在这个反思器里我把错误类型分成了 KeyError、TypeError、IndexError、NameError 四类并给出了通用的改进规则。真实项目中这些规则应该来自历史失败案例的统计分析而不是人工臆测。5.4 记忆模块经验库的写入与检索为了让经验能跨任务复用我们需要一个简单的经验库。# 文件路径prime_agent/agent/memory.py import json import os import re class ExperienceMemory: 基于 JSON 文件的经验库支持关键词检索。 def __init__(self, storage_path: str experience/exp.json): self.storage_path storage_path self._ensure_file() def _ensure_file(self): os.makedirs(os.path.dirname(self.storage_path), exist_okTrue) if not os.path.exists(self.storage_path): with open(self.storage_path, w, encodingutf-8) as f: json.dump([], f, ensure_asciiFalse, indent2) def save(self, experience: dict): 保存一条经验。 records self.load_all() records.append(experience) with open(self.storage_path, w, encodingutf-8) as f: json.dump(records, f, ensure_asciiFalse, indent2) def load_all(self): 加载全部经验记录。 with open(self.storage_path, r, encodingutf-8) as f: return json.load(f) def search_by_keyword(self, keyword: str, top_k: int 3): 根据关键词检索经验记录。 records self.load_all() matched [] for rec in records: text json.dumps(rec, ensure_asciiFalse) if keyword and keyword in text: matched.append(rec) return matched[:top_k] def get_successful_rules(self): 获取所有成功案例中沉淀的改进规则。 records self.load_all() rules [] for rec in records: if rec.get(reward, 0) 0.5 and rec.get(improved_rule): rules.append(rec[improved_rule]) return rules检索能力这里故意做得很简单只是为了让你理解“经验库复用”的思路。如果要支撑更大的规模建议升级为向量检索把任务描述和错误信息做 embedding然后计算相似度取出最相关的案例。5.5 Agent 主循环生成 - 执行 - 反思 - 修复下面是最核心的 Agent Loop。为了不依赖外部大模型示例里的generate_code用了一个规则模板加关键词替换的方式生成初始代码实际项目应替换为大模型调用。# 文件路径prime_agent/agent/loop.py from .environment import CodeEnvironment from .reflector import RuleReflector from .memory import ExperienceMemory class PrimeAgentLoop: Prime Agent 主循环。 def __init__(self, max_steps: int 3): self.env CodeEnvironment() self.reflector RuleReflector() self.memory ExperienceMemory() self.max_steps max_steps def generate_code(self, task: str) - str: 根据任务生成代码。 教学演示中使用规则模板生成实际项目请替换为 LLM 调用。 # 非常粗糙的模板如果任务提到“数字和”就生成求和的代码 if 数字 in task and 和 in task: return ( data [a, 1, 2, 3]\n result sum(data)\n print(result) ) return print(task not supported) def reflect_and_fix(self, task: str, code: str, error: str) - str: 根据错误信息生成修复后的代码。 reflection self.reflector.reflect(task, code, error) if reflection[error_type] TypeError: return ( data [a, 1, 2, 3]\n total 0\n for item in data:\n if isinstance(item, int):\n total item\n print(total) ) if reflection[error_type] KeyError: return ( data {name: Tom}\n print(data.get(name)) ) # 其余情况简化处理原样返回 return code def run(self, task: str, expected_output: str None) - dict: 执行整个 Agent Loop返回最终结果。 code self.generate_code(task) experience { task: task, steps: [], reward: 0.0, improved_rule: , } for step in range(1, self.max_steps 1): print(fStep {step}: 执行代码) result self.env.execute(code, expected_output) if result[success]: experience[reward] result[reward] experience[improved_rule] 成功无需额外规则 experience[steps].append({ step: step, code: code, error: , output: result[output], }) self.memory.save(experience) return { success: True, output: result[output], steps: experience[steps], } # 执行失败进入反思修复环节 reflection self.reflector.reflect(task, code, result[error]) print(fStep {step}: 反思 - {reflection[error_type]}) experience[steps].append({ step: step, code: code, error: result[error], output: result[output], }) if reflection[improved_rule]: experience[improved_rule] reflection[improved_rule] self.memory.save(experience) # 根据反思结果生成修复代码 code self.reflect_and_fix(task, code, result[error]) experience[reward] -2.0 self.memory.save(experience) return { success: False, output: , steps: experience[steps], }这段代码虽然简单但已经具备闭环如果第一次生成的sum(data)因为字符串参与求和而报TypeErrorAgent 会反思出错类型然后修复成“先判断isinstance(item, int)再累加”的版本彻底解决问题。5.6 运行与验证写一个入口脚本# 文件路径prime_agent/main.py from agent.loop import PrimeAgentLoop def main(): agent PrimeAgentLoop(max_steps3) task 给定一个包含数字和字符串的列表返回所有数字的和 result agent.run(task, expected_output6) print(\n Agent 执行结果 ) for step in result[steps]: print(f第 {step[step]} 步代码\n{step[code]}) if step.get(error): print(f错误信息{step[error]}) print(最终成功, result[success]) print(最终输出, result[output]) if __name__ __main__: main()运行命令cd prime_agent python main.py预期输出大致如下Step 1: 执行代码 Step 1: 反思 - TypeError Step 2: 执行代码 Agent 执行结果 第 1 步代码 data [a, 1, 2, 3] result sum(data) print(result) 错误信息TypeError: unsupported operand type(s) for : int and str 第 2 步代码 data [a, 1, 2, 3] total 0 for item in data: if isinstance(item, int): total item print(total) 最终成功 True 最终输出 6可以看到Agent 经历了从“失败”到“反思”再到“修复成功”的过程。任务完成后经验库experience/exp.json中会写入一条包含任务描述、错误类型和改进规则的经验记录。后续遇到同类任务时就可以从经验库中检索这条规则指导生成阶段直接绕过TypeError陷阱。6. 常见问题与排查思路在尝试编写类似自我改进 Agent 的过程中你可能会遇到下面这些问题我把高频现象和解决思路整理成了一个表格。问题现象常见原因解决思路Agent 反复生成同一段错误代码反思模块没有真正影响下一轮生成错误没有作为上下文传入检查循环里是否把reflection的修复建议拼到下一轮 Prompt 中任务成功了但奖励永远为 0.5奖励判断只检查了“有输出”没有和期望结果比对完善expected_output的比对逻辑支持数值、字符串、JSON 等多格式经验库越来越大检索越来越慢全量加载 关键词匹配导致效率低升级为向量检索或对经验按错误类型建索引Agent 在找不到工具时报错且无法恢复Agent 的工具选择策略缺少“兜底方案”增加默认工具或让 Agent 明确返回“无法完成”避免死循环反思结论经常是错的规则型反思器覆盖场景有限或 LLM 反思时上下文不足给反思模块提供更多执行信息代码、错误堆栈、输入数据样例、历史经验代码执行环境可能被恶意代码破坏直接在宿主进程执行 Agent 生成的代码强制使用 Docker、Firejail 等沙箱限制网络、文件系统、CPU 和内存Agent 学到了“错误规则”并稳定复现经验库缺少人工审核低质量经验被当作真理对经验增加置信度分数只有多轮验证通过后才自动生效排查这类问题我建议按下面顺序来先看 Agent Loop 是否完整有没有漏掉“反思”环节。再看反思结果是否真的写入了下一轮 Prompt 或经验库。然后看奖励函数能不能区分“成功”和“看起来成功”。最后看经验库是否存在脏数据。7. 工程化落地建议与安全边界7.1 安全边界代码执行与沙箱如果你要让 Agent 生成代码并执行安全是最高优先级。即使你的 Agent 只是内部工具也强烈建议使用 Docker 容器执行代码设置网络禁用、文件系统只读。限制 CPU 核数和内存大小防止死循环和内存溢出。设置单次执行超时时间例如 5 到 10 秒。禁止执行包含敏感路径、环境变量读取、socket 连接等特征的代码。记录所有执行日志便于事后审计。下面是一个 Docker 沙箱的简化思路docker run --rm \ --network none \ --memory 256m \ --cpus 1 \ --read-only \ -v /tmp/agent_workspace:/workspace \ python:3.10-slim \ python /workspace/main.py在生产环境中任何由 Agent 生成的代码都应该被当作“不可信输入”来处理。7.2 可观测性与日志自我改进 Agent 的调试难度比普通脚本高很多因为它的行为会随经验变化。建议从一开始就做好日志每一轮执行的代码。完整的错误栈。反思模块的输出。奖励分数。经验库的读写操作。日志格式建议使用 JSON方便后续做离线分析。{event: execution_start, task: 任务描述, step: 1} {event: execution_error, error_type: TypeError, error: ...} {event: reflection, error_type: TypeError, improved_rule: ...} {event: execution_success, reward: 1.0, output: 6}有了这些日志你才能回答“Agent 为什么突然变好了/变差了”这类问题。7.3 评估与回归当 Agent 具备自我改进能力后一个很重要的事情是如何确保改进不破坏已有能力。因此我建议维护一个固定的回归测试集。每次策略更新后都跑一遍回归测试集比较整体奖励分数的变化。如果某个旧任务因为新规则的引入而失败说明策略更新过于激进需要回滚。回归测试集不需要很大20 到 50 个覆盖不同错误类型的任务通常就够用。重点是要包含那些曾经失败并沉淀过经验的任务。7.4 策略更新与人工审核自我改进不是“全自动放任不管”。一个合理的流程是反思模块生成改进规则。改进规则先进入“待审核队列”。开发者在预览环境验证规则效果。规则通过后才写入线上经验库。特别是当 Agent 用于生产环境、涉及数据库操作或外部 API 调用时必须设置人工确认环节。从输入材料中的热词可以看到“agent 安全”被反复提及这提示我们自我改进能力越强越需要把“安全护栏”放在架构层面去考虑。8. 总结与后续学习路线8.1 本文要点回顾这篇文章围绕 Prime Agent 展开核心内容可以归纳成几条普通 Agent 和 RLM Agent 的本质区别在于“是否能从失败中学习”。自我改进闭环至少包含执行、奖励、反思、记忆、策略更新。奖励信号要可计算、可解释、可分级。反思模块必须输出结构化结论而不是简单地把错误信息拼进 Prompt。经验库要支持检索和沉淀不能只存不取。代码执行类 Agent 必须做沙箱隔离。文中给出的原型代码虽然简单但已经形成了一条完整的 Agent Loop你可以直接复制到本地运行再逐步替换成真实的大模型调用和更强的反思策略。8.2 下一步学习方向如果你打算继续深入可以按下面的路线走把generate_code替换为真实 LLM 调用让 Agent 真正根据任务动态生成代码。把规则反思器升级为“LLM 反思 历史经验注入”的混合反射器。调研 LangChain 的 AgentExecutor、ReAct 模式理解它们与自研 Agent 的关系。学习向量检索如 Chroma、FAISS把经验库从关键词匹配升级为语义检索。有条件的话可以用强化学习框架如 RLlib、TRL做小规模策略微调实验。阅读 Agent 安全相关论文和项目把安全设计纳入 Agent 评估体系。在训练集里放 20 个左右的小任务跑通“失败 - 反思 - 修复 - 回归测试”这个最小闭环你会比直接去研究复杂框架收获更多。祝开发顺利。