最近一年Agent 开发几乎成了大模型落地的主战场。团队们把模型接上搜索、接上代码解释器、接上 MCP 工具再配上几十个 Skill 文件Agent 看起来“手”越来越长“工具”越来越多。可放到真实生产环境里你会发现一个尴尬的现象同一个 Agent昨天凌晨跑得好好的今天换了一批数据之后它还是在同一个环节犯同样的错误。Log 里记录了错误Prompt 里写满了规则但模型不会自动修正自己的行为。这恰恰是“自改进型 Agent”要解决的问题。如果把 Agent 比作一个员工绝大多数 Agent 框架只给了员工一套办公桌、几部电话和一本说明书却没有给员工总结会、复盘机制更没有让员工在复盘之后把经验沉淀为下一步的行动准则。Prime Agent 这个方向的名字里藏着关键信息Self-Improving自我改进。而其中 RLM 指的不是单纯的“大模型参数”而是一套能在 Agent 运行过程中不断产生反馈信号、把反馈转化为策略更新的强化学习引擎。这篇文章会把 Prime Agent 拆开来看重点讲三件事第一自改进 Agent 和普通工具调用型 Agent 的本质差异是什么第二RLM 在 Agent 里到底承担什么角色它和 Prompt 工程、微调有什么不同第三用一套最小但完整的 Python 示例带你搭一个能记录失败、评估结果、生成反思、更新策略的 Agent 闭环。搭完之后你会理解为什么“让 Agent 记住教训”比“给 Agent 加工具”更重要。1. 这篇文章真正要解决的问题先说一个很常见的现象。很多开发者第一次上手 Agent 时以为把大模型 API 接上、把工具函数写好Agent 就能像人一样自主完成任务。实际上你接到的往往是一个“一次性执行器”模型拿到任务调用工具返回结果如果结果不符合预期这一轮对话就结束了。下一次换一个新会话模型完全不记得上一次为什么失败。所以很多团队开始给 Agent 加“记忆”向量数据库存对话历史Prompt 里塞搜索片段Session 里带上下文字段。可这些做法解决的是“记住信息”并没有解决“从失败中总结规律”。拿一个具体场景来说。假设你的 Agent 要负责从数据库里查订单生成报表。第一次运行它写了一条 SQL语法错误第二次运行换了个表名结果字段名不对第三次运行字段名对了但漏了时间过滤条件。传统 Agent 会在每一次失败后报错退出。自改进 Agent 会在失败后做一件事记录下来分析原因提炼成一条可复用的策略例如“当用户查询最近订单时必须添加 create_time 大于上一个自然日 0 点的过滤条件”并把这个策略写回策略库供下一轮执行调用。这里面最核心的区别不是模型变大了而是系统结构变了。Agent 从“单轮执行器”变成了“执行 评估 反思 更新”的闭环。RLM 在这个闭环里承担的就是“评估和反思”这一环它是让策略持续优化的小发动机。什么样的读者最应该关注这个方向第一你在做基于大模型的生产级应用上线后发现 Agent 回答质量不稳定第二你用 LangChain、LangGraph 或类似框架搭过 Agent但总觉得工具链只是“排列组合”没有真正提升模型能力第三你在研究 Agent 的长期规划、自我改进、记忆与遗忘这类话题。如果你只是想在本地跑一个聊天机器人这篇文章更多是从机制层面帮你看清取舍。2. Agent 和自改进 Agent先分清几个高频概念聊 Prime Agent 之前必须先把几个术语摆到桌面上对照清楚否则后面代码会看晕。2.1 Agent、Workflow、Harness 与 SkillWorkflow一组预先编排好的步骤比如“先搜索再总结再发送”。Workflow 是死的流程固定。Agent由模型自主决策下一步做什么的循环。模型看到当前状态决定调用哪个工具、生成什么内容然后进入下一步。Harness承载 Agent 循环的框架代码。它可以理解为 Agent 的“壳”感知状态、调用工具、处理异常、控制上下文窗口。Skill一份预置的“能力卡”通常是自然语言编写的操作说明加上示例。Skill 帮助模型知道某个工具在什么场景下使用以及具体怎么用。很多人把 Harness 和 Agent 混为一谈。实际上Harness 提供了 Agent 的骨架Agent 的智能来自模型对工具、环境、目标的综合理解。单改进 HarnessAgent 的“思考质量”不会自动提升单改进模型Harness 不稳Agent 还是会跑飞。自改进 Agent 要做的是把两者之间的反馈通道打通。2.2 RLM 到底是什么RLM 这几个字母在不同资料里有不同解释本文采用更贴近 Agent 工程场景的读法Reinforcement Learning Model强化学习模型。但要说明白RLM 不是像 GPT-4 那样可以直接调用的大模型而是一个“策略更新引擎”。在 Agent 闭环里RLM 接收执行过程中产生的轨迹数据Trajectory对轨迹进行打分判断成功还是失败然后生成一条改进建议最终把这个建议写入策略库影响下一次执行的 Prompt 或工具描述。它和普通微调、Prompt 工程最大的区别在于更新频率。Prompt 工程是人在发布前写死规则微调是离线训练模型权重RLM 则是在线更新“系统 2”层面的决策策略。换句话说Agent 不是每次回答前临时思考如何做而是把之前复盘过的规律先变成一套策略指导当前的每一步行动。2.3 Self-Improving 的边界必须泼一盆冷水Self-Improving 不是让模型自己改代码更不是让模型在没有任何监督的情况下无限变强。在 Prime Agent 的设计里自我改进更贴近“系统复盘”每次执行任务后通过奖励信号判断结果好坏再通过反思生成改进项定期把这些改进项沉淀成策略。整个过程可以被审计、被回滚。这是工程上可落地的自我改进而不是 AI 电影里的神谕系统。理解了这几个概念的边界你就能明白为什么很多 Agent 项目看起来功能齐全实际效果却一般。它们大多数只有 Harness没有 RLM只有执行没有反馈。3. 核心原理Self-Improving 的三层闭环自改进 Agent 最关键的机制可以压缩成一个词闭环。我把它拆成三层执行层Agent 完成一个任务产生轨迹、工具调用、最终结果。评估层根据规则、预期、外部反馈给这次执行打分判定是否成功。反思与策略层对失败原因进行归因生成改进策略写回策略库。这三层循环起来后Agent 不需要重新训练模型也不需要人工改 Prompt就能在下一次任务中应用历史教训。用一个实战类比理解。团队里有个初级开发第一次写接口没加参数校验上线后出了问题。如果团队没有复盘机制他下次还会犯如果团队把“接口入参必须校验”写进编码规范下次所有人写接口都会自动加校验。自改进 Agent 就是把这个“编码规范”沉淀过程自动化。在代码实现里闭环通常长这样一个 Agent 执行完任务输出一段 JSON 格式的轨迹。评估器判断轨迹是否满足预设指标。如果不满足反思器把错误信息和上下文发给大模型让模型输出改进建议。改进建议被解析成结构化策略追加到策略库中。下一轮执行时策略库内容作为系统提示词的一部分注入给大模型。注意这个闭环不是每一轮都产生新策略。如果任务成功可以不做反思避免策略库被无效信息污染。只有连续失败达到阈值或者某个失败具有明显可迁移性时才值得生成新策略。另一个容易被忽略的点策略库要有“版本”和“来源”字段。生产环境里一条错误的策略比没有策略更危险。Agent 可能学会了“一律不要调用删除接口”这种过度保守的策略这时团队需要能快速定位并回滚。4. Prime Agent 的架构拆解四组件 一策略库理解了闭环再看架构就清晰了。一个可工作的 Prime Agent 式系统通常由四个组件构成。4.1 组件对照表组件作用输入输出Executor执行任务调用工具任务描述、策略库Agent 轨迹、最终结果Evaluator评估执行质量Agent 轨迹、参考答案/规则评估分数、成功/失败标记Reflector对失败做归因与改进失败轨迹、评分、工具错误信息改进建议结构化Policy Store存储和检索策略改进建议、历史策略策略列表、可供 Executor 注入的内容Executor 基本就是常见的 Agent Loop 代码Evaluator 可以基于规则也可以基于另一个大模型甚至基于用户点击反馈Reflector 一般要调用大模型做结构化输出Policy Store 最简单可以是一个 JSON 文件、SQLite 表或 Redis 列表。4.2 策略注入方式策略不是一直堆在 Prompt 里。策略库可能会积累几十条规则全部塞进 Prompt 会占用大量上下文反而干扰模型。比较常见的做法有两种按任务相关性检索把策略打标签执行前根据任务类型召回相关策略。按策略熟练度分层高频使用且验证有效的策略进入“强制策略”直接注入系统提示低频候选策略只有在新任务中命中相关标签时才注入。这里的取舍本质上是信息密度和执行可靠性之间的平衡。Prime Agent 这类自改进系统能产生价值的前提是策略库里的策略真的“被用到”。如果策略只是躺在数据库里那它和一堆日志没什么区别。5. 环境准备与任务设计下面进入实操环节。我们不做分布式系统而是搭一个最小闭环验证“执行 → 评估 → 反思 → 策略更新”的流程是否真的能让 Agent 第二次做得更好。5.1 场景设定任务让 Agent 根据自然语言查询一个 SQLite 数据库返回结果。我们故意让第一次执行失败然后通过自改进机制让 Agent 在第二次执行时不再犯同样的错误。数据库只有一张表orders。CREATE TABLE orders ( id INTEGER PRIMARY KEY, customer_name TEXT, product_name TEXT, amount REAL, create_time TEXT );5.2 项目依赖与目录建议使用 Python 3.10 及以上版本依赖尽量少方便看清闭环逻辑openai调用大模型pydantic解析结构化输出python-dotenv读取环境变量目录结构prime_agent_demo/ ├── .env ├── policy_store.json ├── agent.py ├── evaluator.py ├── reflector.py ├── db_utils.py └── main.py由于版本迭代较快这里不写死具体版本号。安装时可以视本机环境选择例如pip install openai pydantic python-dotenv如果你使用的是国内大模型 API 或开源模型的兼容接口只需要修改 base_url 和 model 参数即可整体思路不变。6. 核心代码实现一个最小 Self-Improving Agent我会把代码拆成几块每块对应前面架构里的组件。6.1 工具层SQL 执行函数先写一个最普通的工具函数后面 Agent 会调用它。为了模拟失败场景我们让工具函数返回错误信息而不是直接抛异常。# db_utils.py import sqlite3 import os DB_PATH orders.db def init_db(): conn sqlite3.connect(DB_PATH) conn.execute( CREATE TABLE IF NOT EXISTS orders ( id INTEGER PRIMARY KEY, customer_name TEXT, product_name TEXT, amount REAL, create_time TEXT ) ) conn.execute( INSERT OR IGNORE INTO orders (id, customer_name, product_name, amount, create_time) VALUES (1, 张三, 键盘, 299, 2025-01-10 10:00:00), (2, 李四, 鼠标, 129, 2025-01-10 10:05:00), (3, 王五, 显示器, 1299, 2025-01-12 14:30:00) ) conn.commit() conn.close() def run_sql(sql: str) - dict: try: conn sqlite3.connect(DB_PATH) cur conn.cursor() cur.execute(sql) result cur.fetchall() conn.close() return {success: True, result: result} except Exception as e: return {success: False, error: str(e)}这个工具层的异常处理非常关键。生产环境中工具函数的错误信息一定要清晰否则后面反思器根本没法归因。很多 Agent 失败是因为工具返回了 “Error: something wrong”而不是 “SQL syntax error near ...”。设计工具时尽量让错误信息包含可诊断的细节。6.2 策略库策略库用 JSON 文件存储。每个策略包含 id、content、created_at、source、times_used 字段。# policy_store.py import json import os import time POLICY_FILE policy_store.json DEFAULT_POLICIES [] def load_policies(): if not os.path.exists(POLICY_FILE): return DEFAULT_POLICIES with open(POLICY_FILE, r, encodingutf-8) as f: return json.load(f) def save_policies(policies): tmp_file POLICY_FILE .tmp with open(tmp_file, w, encodingutf-8) as f: json.dump(policies, f, ensure_asciiFalse, indent2) os.replace(tmp_file, POLICY_FILE) def add_policy(content, source): policies load_policies() # 避免完全重复的策略 for p in policies: if p[content] content: return policies.append({ id: str(int(time.time())), content: content, source: source, created_at: time.strftime(%Y-%m-%d %H:%M:%S), times_used: 0 }) save_policies(policies)这里用os.replace做原子写避免进程中断导致 JSON 文件损坏。文件型存储适合单机演示在生产环境建议换成 SQLite 或 Redis并加锁控制并发。6.3 Agent 主体执行时注入策略Agent 的基本逻辑如下把任务描述、策略库内容、对话历史拼进 Prompt调用大模型生成 SQL然后执行工具并返回结果。# agent.py import json from openai import OpenAI from db_utils import run_sql from policy_store import load_policies client OpenAI() SYSTEM_PROMPT_TEMPLATE 你是一个数据查询助手。你只能输出一条 SQL 语句不要输出任何解释。 请根据用户问题生成符合 SQLite 语法的 SQL。 以下是从历史复盘中学到的执行策略你必须严格遵守 {policies} def build_system_prompt(): policies load_policies() policy_text if policies: policy_text \n.join( f{i1}. {p[content]} for i, p in enumerate(policies) ) else: policy_text 暂无历史策略请根据常识生成 SQL。 return SYSTEM_PROMPT_TEMPLATE.format(policiespolicy_text) def run_agent(user_query: str) - dict: system_prompt build_system_prompt() resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: system_prompt}, {role: user, content: user_query} ], temperature0, ) sql resp.choices[0].message.content.strip() result run_sql(sql) return { query: user_query, sql: sql, result: result }看到这里你会发现Agent 本身的实现并不复杂。策略注入点就是系统提示词。真正让系统产生“记忆”的是策略库的更新机制。6.4 评估器评估器判断一次执行是否成功。这里我们按场景设计规则# evaluator.py def evaluate(agent_output: dict) - dict: result agent_output.get(result, {}) if not result.get(success): return { score: 0, success: False, reason: result.get(error, 未知错误) } rows result.get(result, []) if not rows: return { score: 0, success: False, reason: 查询结果为空可能缺少数据过滤条件或表名有误 } return { score: 1.0, success: True, reason: 查询成功 }这里的评估是规则化的方便演示。实际项目中评估器可以混合多种输入用户反馈、真值比对、下游任务成功率。评估质量直接决定反思质量这是整个系统最容易出错的一环。6.5 反思器反思器把失败信息发给大模型让它输出结构化的改进建议。# reflector.py import json from openai import OpenAI client OpenAI() REFLECT_PROMPT 你是一个 Agent 复盘专家。根据以下执行轨迹分析失败原因并输出一条可复用的改进策略。 要求 1. 策略必须具体、可操作告诉 Agent 下次遇到类似问题时应该怎么做。 2. 策略不要写“注意”“请小心”这类空话。 3. 只输出 JSON格式为 {strategy: ...} 失败轨迹 {trajectory} def reflect(agent_output: dict) - str: trajectory json.dumps(agent_output, ensure_asciiFalse, indent2) resp client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是一个严谨的复盘助手。}, {role: user, content: REFLECT_PROMPT.format(trajectorytrajectory)} ], temperature0.2, response_format{type: json_object} ) data json.loads(resp.choices[0].message.content) return data.get(strategy, 根据错误信息修正 SQL。)注意这里使用了response_format强制输出 JSON 对象。如果模型不支持也可以让模型输出 Markdown 代码块再解析但可靠性会下降。6.6 主流程组合闭环最后用一个主程序把执行、评估、反思、策略更新串起来。# main.py from agent import run_agent from evaluator import evaluate from reflector import reflect from policy_store import add_policy def main(): query 查询张三最近7天的订单金额 # 第一轮执行 first_output run_agent(query) print(第一轮 SQL:, first_output[sql]) print(第一轮结果:, first_output[result]) first_eval evaluate(first_output) print(第一轮评估:, first_eval) if not first_eval[success]: strategy reflect(first_output) print(反思生成的策略:, strategy) add_policy(strategy, sourcefirst_failure) # 第二轮执行 second_output run_agent(query) print(\n第二轮 SQL:, second_output[sql]) print(第二轮结果:, second_output[result]) second_eval evaluate(second_output) print(第二轮评估:, second_eval) if __name__ __main__: main()这个主流程里第一轮失败后生成策略第二轮重新执行。虽然两轮之间没有真正的“长期在线循环”但已经具备了自改进闭环的完整骨架。7. 运行结果与效果验证我以“查询张三最近7天的订单金额”这个任务为例模拟一下可能的执行过程。第一轮模型根据常识生成了 SQLSELECT * FROM orders WHERE customer_name 张三 AND create_time date(now, -7 days);这个 SQL 在 SQLite 里可能返回空结果因为create_time是文本类型字符串比较和date(now)返回值格式不一致。也可能模型生成的 SQL 语法错误例如SELECT SUM(amount) FROM orders WHERE customer_name 张三 AND create_time NOW() - INTERVAL 7 DAY;这条 SQL 在 SQLite 里会直接报错因为 SQLite 不支持NOW()和INTERVAL语法。工具函数返回success: false评估器判定失败反思器生成策略当查询“最近 7 天”这类相对时间条件时必须使用 SQLite 的 datetime(now, -7 days) 函数并将 create_time 字段与计算出的时间字符串进行比较格式统一为 YYYY-MM-DD HH:MM:SS。策略写入文件后第二轮模型在系统提示词里看到这条规则生成 SQL 的正确率大幅提升。验证成功不能只看第二次是否通过还要看三点策略库是否真的多了一条策略。这条策略是否具备可迁移性而不是针对特定数据的“硬编码”。如果策略错误能否快速定位并回滚。如果你运行之后发现策略没有生效优先检查策略库文件里的 JSON 格式是否正常然后打印build_system_prompt()看一下策略是否真的注入到了系统提示词中。8. 从 Demo 到生产还要补齐哪些能力上面这个最小闭环只有 100 多行代码却已经让你领会了自改进 Agent 的脉搏执行、评估、反思、策略沉淀。但要把它真正部署到生产环境至少还需要补五个能力。8.1 策略的时效性与衰减策略库不能只增不减。随着业务变化某些策略会过时。比如“订单字段叫 goods_name”的策略在数据库表结构变更后就会误导模型。建议给策略增加ttl或last_validated字段定期验证并淘汰失效策略。8.2 奖励信号的可靠性评估器是整套系统的“裁判”。如果裁判乱打分反思器就会学到错误规律。生产环境中建议采用“多信号加权”方式规则打分作为基础分用户显式反馈作为高权重修正重要任务再做人工抽检。不要只依赖大模型自评。8.3 策略冲突处理多条策略可能互相矛盾。例如策略 A 说“订单金额必须大于 0”策略 B 说“允许退款订单金额为负”。两种策略并存时模型会迷茫。解决办法是按业务域分组或为策略设置优先级。冲突策略应该被自动标记进入人工审核队列。8.4 安全边界自改进 Agent 是自动修改行为的系统比普通 Agent 更需要安全控制。第一策略写入必须审计至少记录来源和生成时间第二策略库文件本身要防止被 prompt 注入污染第三当 Agent 在工具执行失败后自动生成策略时要避免极端情况下的“自我强化错误循环”——比如 Agent 因为一次误判把自己的工具调用方式改废了。建议在高风险动作上增加人工审批流。8.5 评估集与回归测试既然策略会更新那就要有“回归测试”准备一组标准测试用例每次策略库更新后用同一组任务跑一遍对比通过率。这个思路和代码 CI/CD 完全一致。没有回归测试的自改进 Agent就像没有测试的代码库越改越慌。9. 常见问题与排查思路问题现象可能原因排查方式解决方案策略库一直没有新策略评估器对所有结果都判定成功打印评估器的打分日志加严评估规则把“查询结果为空”等边界情况判为失败反思生成的策略太泛反思 Prompt 不够具体查看反思器输入的轨迹是否包含完整错误信息在轨迹中加入工具返回的原始报错、已有哪些策略、任务目标策略注入后反而变差策略内容错误或过时对比注入前后两轮输出为策略增加优先级和过期时间必要时回滚策略库模型不遵守策略策略放在 Prompt 里被压缩查看系统提示词是否被截断将策略放在更靠近底部的位置或者拆出独立的策略注入模块并发下策略库文件损坏JSON 文件并发写入冲突查看 policy_store.json 是否半截改用 SQLite 或 Redis 存储加事务和版本号排查时最忌讳直接改代码。自改进 Agent 的问题往往不是单一组件造成你要有一套“看日志 → 查策略 → 看评估 → 看反思”的链路检查习惯。10. 最佳实践与工程建议我建议第一次尝试自改进 Agent 的团队从最轻量、最可控的形态开始不要一开始就上多 Agent、多策略、在线强化学习。10.1 先让“反馈闭环”跑起来再谈自动化哪怕先让策略库由人工审核后写入也行。先把执行、评估、反思三个组件跑通观察模型在拿到策略前后的表现差异。得到正向效果后再逐步增加自动写入的比例。10.2 把策略当作字段设计策略库不是一坨文本它是系统的一部分。建议为每条策略记录应用场景/触发条件策略内容来源人工编写、反思生成生效时间生效次数最近一次验证结果置信度这样你才能真正判断策略的价值而不是“感觉有点用”。10.3 评估器是杠杆值得投入最高资源在自改进 Agent 的四个组件里评估器长期被低估。很多团队把大量精力放在怎么写反思 Prompt 上却忽略了评估器打分不准导致反思全都白做。如果资源有限优先打磨评估器或者增加人工抽检比例。10.4 不要让 Agent 在每条任务上都“改进”高频任务、低风险任务一次成功后不需要反思。只有连续失败、错误模式趋同的任务才值得让反思器介入。否则策略库会被边缘噪声塞满真正的强策略反而被稀释。10.5 保留人工回滚入口不管自动化程度多高都要保留一个回滚入口能够快速删除某条策略、恢复到某个时间点的策略库快照。这个入口在系统上线初期尤其重要因为模型生成的策略质量你还没有足够数据验证。11. 从 Prime Agent 得到的一点启示Prime Agent 这个标题真正值得记录的不是某一个模型或框架的横空出世而是它代表了 Agent 开发思路的一次转向从“给 Agent 更多工具”转向“让 Agent 从经验中进化”。在项目里你可以把 Prime Agent 理解为一条设计准则让 Agent 的每一次执行都成为下一步决策的输入。反过来说如果你的 Agent 系统目前只有“任务输入 → 模型输出 → 工具执行 → 返回结果”这条单行道那么你拥有的其实不是一个 Agent而是一个“自动调用大模型的脚本”。没有闭环就没有自我改进。下一步建议你动手做两件事。第一把手头一个高频出错的 Agent 任务找出来手动记录它最常见的三类失败原因写进策略库看效果有没有提升。第二写一个最简单的评估器把你自己的 Agent 输出结果打分哪怕规则只有 5 条都能立刻暴露很多过去看不出来的问题。自改进 Agent 并不玄乎它的地基是工程里的日志、评估、复盘子系统和版本回滚机制。先把这些基本功补齐再谈在线强化学习和多智能体协同。那时候你再看 Prime Agent 这类项目会发现其中的设计考量你可以完全理解而不会被一个术语唬住。