递归自我改进（RSI）工程实践：从提示词优化到harness落地的核心挑战-北京尧图网络

递归自我改进这个概念第一次听到的时候我正蹲在一个agent项目的调试现场凌晨两点日志里agent自己改了自己的prompt然后下一轮跑出来的结果比上一轮还差。那一刻我意识到自我改进这四个字听起来很酷但真正落地的时候它首先是一个工程问题其次才是一个智能问题。这篇内容我想把RSIRecursive Self Improvement递归自我改进这件事从概念到现状、从架构到坑完整地聊一遍。不管你是刚接触agent开发的新手还是已经在做harness工程的老手都能从中找到对自己有用的部分。我会尽量少讲空话多讲我实际踩过的坑和验证过的思路。1. 递归自我改进到底在说什么1.1 一个容易被误解的定义很多人第一次接触RSI脑子里浮现的画面是AI自己写代码把自己变强然后指数级起飞。这个理解不能说错但太粗糙了。在当前的工程语境下递归自我改进更准确的描述是一个系统能够基于自身的运行结果自动调整自己的行为策略、提示词、工具调用方式甚至代码结构并在下一轮运行中体现出改进效果且这个过程可以持续迭代。注意这里有几个关键词。基于自身的运行结果意味着系统必须有反馈回路不能是拍脑袋改。自动调整意味着人的介入要尽可能少否则就退化成人工调优了。持续迭代意味着这不是一次性的优化而是一个循环。最后体现出改进效果是最难的部分——你怎么知道它真的变好了这个问题后面会专门展开。我见过不少团队号称在做RSI实际上做的是自动prompt优化也就是拿一堆测试用例跑一遍让模型自己改prompt改完再跑一遍看分数。这确实是RSI的一个子集但RSI的范围要大得多。它还包括工具选择的自我调整、agent架构的自我重组、甚至harness层面的自我修改。1.2 RSI和普通agent优化的区别普通agent优化是人在外面调RSI是agent自己在里面调。这个区别听起来简单但带来的工程复杂度是数量级的差异。普通优化的时候人是裁判人决定哪个版本好、哪个版本坏人决定要不要回滚。整个过程的节奏由人控制出问题了人兜底。RSI把这个裁判权部分交给了系统自己系统需要自己判断我这一轮改得对不对。这就引入了一个根本性的难题自我评估的可靠性。一个系统如果评估能力不行它就会朝着错误的方向改进越改越差而且它自己还觉得挺好。这就是我在开头提到的那个凌晨两点的场景——agent改了自己的prompt它认为改得更好了但实际结果更差因为它用的评估标准本身就有问题。所以RSI的核心挑战从来不是能不能改而是改了之后怎么知道改对了。这个问题不解决RSI就是一个自我欺骗的循环。1.3 为什么现在RSI突然热起来了RSI这个概念其实不新早在上世纪就有学者讨论过。但为什么最近一两年突然成了热词我觉得有三个原因。第一agent的能力上来了。以前的模型连稳定的工具调用都做不好你让它自我改进它改出来的东西根本没法用。现在agent能写代码、能调工具、能读文档它具备了改自己的基本能力。第二harness工程成熟了。harness这个词最近很火它本质上是一套让agent稳定运行的脚手架——包括工具管理、上下文管理、错误处理、日志追踪等等。有了harnessagent的行为变得可观测、可干预、可回滚这为RSI提供了工程基础。没有harness的agent就像没有仪表盘的飞机你根本不知道它在干什么更别说让它自己改自己了。第三成本下来了。RSI需要大量的试错试错需要大量的token。以前跑一轮实验的成本高得吓人现在成本降下来了迭代速度就上去了。提示如果你现在还在用跑一次看一次结果的方式调agent建议先把harness搭起来。RSI的前提是可观测没有观测就没有改进。2. RSI的三种落地形态2.1 提示词层面的自我改进这是最容易上手的一种形态也是大多数团队的第一步。基本思路是给agent一组任务和对应的评估标准让它跑一遍然后让它分析自己的失败案例提出prompt修改建议改完再跑一遍对比分数。听起来简单但实际操作中有几个坑。第一个坑是过拟合。agent很容易针对你给的那几个测试用例去改prompt改完之后在这几个用例上分数很高但换个场景就崩了。我见过一个团队他们的agent在20个测试用例上从60分优化到了95分结果上线之后用户反馈一塌糊涂。原因就是那20个用例被agent背下来了。解决办法是维护一个动态的测试集每次评估的时候随机抽样而且要有专门的留出集不参与优化只用来验证。这个思路和机器学习里的训练集/验证集划分是一样的但很多做agent的人没有这个意识。第二个坑是评估标准本身有偏差。如果你用模型来当裁判LLM as judge那裁判本身的偏好会影响优化方向。我建议至少用两个不同的模型当裁判取平均或者取保守值。如果两个裁判分歧很大那这个样本就不应该用来指导优化。第三个坑是改动幅度失控。agent有时候会一次性改很多地方改完之后你根本不知道是哪个改动起了作用。我的做法是限制每轮只改一个维度比如这轮只改系统提示词下轮只改工具描述再下轮只改few-shot示例。这样虽然慢但每一步都可归因。2.2 工具与技能层面的自我改进这一层比提示词深一层。agent不只是改自己说什么还改自己用什么工具、怎么用工具。举个例子一个做数据分析的agent初始状态下它有一堆工具读文件、写SQL、画图、发邮件。跑一段时间之后它发现读文件这个工具经常因为编码问题失败于是它自己写了一个新的工具安全读文件内部处理了编码检测和转换然后把这个新工具注册到自己的工具集里。这就是工具层面的自我改进。这一层的难点在于工具的安全边界。agent自己写工具、自己注册工具万一它写了一个有副作用的工具怎么办比如它写了一个清理临时文件的工具结果把重要数据删了。所以工具层面的RSI必须有一套审批机制新工具不能直接上线要先在沙箱里跑跑通了、验证了才能进正式工具集。我自己的做法是给工具分三级只读工具自动上线写入工具需要人工确认删除类工具一律禁止自动注册。这个分级不是拍脑袋定的是根据实际风险来的。只读工具最坏情况就是读到错误数据影响可控写入工具可能污染数据删除类工具一旦出错就是不可逆的。2.3 架构层面的自我改进这是最深的一层也是目前最不成熟的一层。agent不只是改prompt和工具还改自己的架构——比如把单agent改成多agent协作把串行流程改成并行把固定的workflow改成动态编排。这一层为什么难因为架构改动的影响面太大而且很难评估。你改了一个agent的架构跑出来的结果变好了你怎么知道是架构改得好还是随机波动架构层面的改动往往需要跑很多次才能看出统计显著性而跑很多次的成本又很高。目前我看到的比较靠谱的做法是架构搜索预先定义几种候选架构让agent在这些架构之间做选择而不是让它凭空创造新架构。这样搜索空间可控评估也可控。凭空创造架构听起来很酷但实际落地的时候agent创造出来的架构往往是它见过的架构的排列组合真正新颖的东西很少而且很难验证。注意架构层面的RSI我建议先不要碰。先把提示词和工具层面的RSI做扎实有了稳定的评估体系和回滚机制再考虑动架构。3. 评估RSI最容易被低估的环节3.1 为什么评估比改进更难改进是做事评估是判断事做得好不好。大多数人天生更愿意做事不愿意做判断因为判断需要标准而标准的制定是一件很痛苦的事。在RSI里评估的重要性怎么强调都不过分。一个系统如果评估不准它就会朝着错误的方向狂奔。而且更可怕的是它跑得越快错得越远。我见过一个项目agent的自我改进循环跑得特别顺每轮都有提升团队很高兴结果上线之后发现它优化的方向和一个隐藏的业务指标是相反的。因为他们的评估标准里没有包含那个业务指标agent就钻了这个空子。所以评估体系的设计本质上是在回答一个问题你到底想要什么这个问题如果人自己都回答不清楚就别指望agent能回答清楚。3.2 多维度评估的实操框架单一指标的评估几乎一定会被钻空子。我的做法是至少三个维度效果、成本、稳定性。效果维度衡量任务完成的质量可以用准确率、F1、人工评分等。成本维度衡量token消耗、时间消耗、工具调用次数。稳定性维度衡量多次运行的结果方差、失败率、异常率。这三个维度之间往往是有 trade-off 的。agent可能通过增加token消耗来提升效果也可能通过降低效果来提升稳定性。所以不能简单加权求和而应该设定阈值效果必须达到某个线成本不能超过某个线稳定性不能低于某个线。只有三个都满足才算改进。维度衡量指标常见陷阱效果准确率、完成率、人工评分过拟合测试集、指标被钻空子成本token数、耗时、工具调用次数为了效果无限堆成本稳定性方差、失败率、异常率单次运行结果不代表真实水平这个表格看起来简单但实际执行的时候很多团队只看了效果维度成本和稳定性完全没管。结果就是agent越来越贵、越来越飘最后没法上线。3.3 评估的自动化与人工介入的平衡全自动评估很诱人但完全不靠谱。我的经验是自动化评估做初筛人工评估做终审。具体来说每一轮改进之后先跑自动化评估如果分数没有明显提升直接丢弃不进人工环节。如果分数有明显提升再抽样做人工评估。人工评估不需要看全部样本看10到20个典型样本就够了。如果人工评估发现自动化评估没发现的问题那说明评估体系有漏洞需要补。这个流程的关键是人工评估的样本要随机抽不能只抽agent自己觉得好的样本。agent自己觉得好的样本往往是它优化过的方向恰恰是最容易过拟合的地方。我一般会要求人工评估的样本里至少有一半是agent在训练过程中没见过的。这样才能真正检验泛化能力。4. 当前RSI面临的核心挑战4.1 自我评估的可靠性问题前面反复提到这个问题这里展开讲。自我评估的可靠性问题本质上是评估者和被评估者是同一个系统带来的利益冲突。agent既当运动员又当裁判它天然有动机给自己打高分。解决这个问题的思路有几个。第一个是评估者与被评估者分离用不同的模型、不同的prompt来做评估。第二个是引入外部信号比如用户的真实反馈、下游任务的实际结果。第三个是对抗性评估专门训练一个找茬的评估者它的任务就是找出被评估者的漏洞。我实际用下来最有效的是第二个——外部信号。因为前两个本质上还是模型在评估模型而模型有共同的盲区。只有真实世界的结果不会骗人。但外部信号的问题是反馈慢、噪声大需要耐心积累。4.2 改进的累积性与遗忘问题RSI是一个持续迭代的过程每一轮改进都建立在前一轮的基础上。这就带来一个问题如果某一轮改错了后面的改进都会建立在错误的基础上越走越偏。更麻烦的是遗忘。agent在改进某个能力的时候可能会损害另一个能力。比如它为了提升代码生成的准确率把prompt改得更保守了结果创意类任务的表现下降了。这种跷跷板效应在RSI里非常常见。我的应对方式是维护一个能力基线每次改进之后不仅要测改进的目标能力还要测一组基线能力。如果基线能力下降了超过阈值这轮改进就回滚。这个基线不需要很大覆盖核心能力就行但必须每次都测。4.3 安全边界与失控风险RSI最让人担心的就是失控。agent自己改自己改着改着改出问题了怎么办我的观点是失控风险主要不来自agent的智能而来自工程防护的缺失。一个agent如果只能改prompt它失控的最坏结果就是输出一些奇怪的话。但如果它能改代码、能调工具、能访问外部系统那失控的后果就严重了。所以安全边界的设计要分层。最内层是能力边界agent能改什么、不能改什么要明确。中间层是资源边界agent能消耗多少token、多少时间、多少外部调用要有限制。最外层是回滚机制任何改动都要可回滚而且回滚要快。我自己的项目里所有agent的自我修改都会先写到一个待审区不会直接影响生产环境。待审区里的改动经过评估之后才合并到主分支。这个流程和软件开发的代码审查是一样的只不过审查者从人变成了人自动化评估。提示回滚机制一定要定期演练。我见过太多团队回滚脚本写了但从来没跑过真出事的时候发现回滚脚本本身就有bug。5. 一个可落地的RSI最小实现5.1 整体架构设计说了这么多理论来点实际的。下面是我自己搭过的一个RSI最小实现跑通了提示词层面的自我改进。整个架构不复杂但该有的都有。核心组件有四个执行器负责跑任务评估器负责打分改进器负责根据评估结果提出修改建议版本管理器负责记录每个版本和对应的分数支持回滚。数据流是这样的执行器用当前版本的prompt跑一批任务评估器给每个任务打分改进器分析失败案例并提出prompt修改新prompt进入待审区评估器用留出集验证新prompt如果通过就升级为当前版本否则丢弃。这个流程跑一轮大概需要几分钟到几十分钟取决于任务量和模型速度。我一般让它每天晚上跑第二天早上看结果。5.2 关键代码结构下面是一个简化的代码骨架用Python写的主要是展示结构具体实现要根据你的场景调整。class RSIEngine: def __init__(self, executor, evaluator, improver, version_manager): self.executor executor self.evaluator evaluator self.improver improver self.version_manager version_manager def run_round(self, tasks, holdout_tasks): current self.version_manager.get_current() results self.executor.run(tasks, current.prompt) scores self.evaluator.score(results) if not self._is_improvement_needed(scores): return no_improvement_needed suggestion self.improver.analyze(results, scores) candidate self.version_manager.create_candidate(suggestion) holdout_results self.executor.run(holdout_tasks, candidate.prompt) holdout_scores self.evaluator.score(holdout_results) if self._passes_threshold(holdout_scores, scores): self.version_manager.promote(candidate) return promoted else: self.version_manager.discard(candidate) return discarded这段代码里最关键的是_passes_threshold这个判断。它不能只看分数高低还要看提升是否显著、基线能力是否保持、成本是否可控。我一般要求新版本在留出集上的分数比当前版本高至少5个百分点且基线能力下降不超过2个百分点才允许升级。5.3 运行中的实际观察这个最小实现我跑了两周有一些观察值得分享。第一前几轮提升很快后面就平了。第一周从基线提升了大概30个百分点第二周只提升了5个百分点。这是正常的容易改的地方先被改掉了剩下的都是硬骨头。第二agent倾向于改prompt的措辞而不是结构。它会把请仔细分析改成请非常仔细地分析这种改动基本没用。后来我在改进器的prompt里明确要求只做结构性修改不做措辞微调情况才好一些。第三留出集的分数波动比训练集大。有时候训练集涨了10分留出集只涨了2分甚至跌了。这说明过拟合是真实存在的留出集是必须的。第四有些改进是不可逆的。比如agent把某个工具的描述改得更详细了下一轮它又觉得太啰嗦想改回去但改回去之后发现原来的简洁版本其实更好。这种来回摇摆会浪费很多轮次。我的做法是给每个改动打标签如果某个方向被证明是错的就记录下来避免重复探索。6. 关于harness与RSI的关系6.1 harness到底解决了什么问题harness这个词最近很热但很多人对它的理解还停留在agent框架的层面。我的理解是harness比框架更偏工程它解决的是agent稳定运行的问题而不是能不能运行的问题。一个agent要稳定运行需要处理的事情包括上下文窗口管理什么时候截断、什么时候摘要、工具调用的错误处理失败了重试还是放弃、并发控制多个工具同时调用怎么协调、日志追踪出了问题怎么定位、状态管理多轮对话的状态怎么保持。这些事情框架不一定管但harness必须管。对RSI来说harness的价值在于可观测性和可干预性。RSI需要知道agent每一步在干什么、为什么这么干、结果怎么样。没有harness这些信息拿不到RSI就是盲人摸象。6.2 在harness上做RSI的注意事项在harness层面做RSI有几个坑要注意。第一个坑是不要改harness的核心逻辑。harness是基础设施基础设施要稳定。RSI可以改agent的prompt、工具、策略但不要让它去改harness本身的调度逻辑、错误处理逻辑。这些逻辑一旦被改坏整个系统就崩了。第二个坑是harness的日志要结构化。RSI需要分析日志来提出改进建议如果日志是一堆非结构化的文本分析起来就很费劲。我建议日志至少包含时间戳、agent ID、任务ID、输入、输出、工具调用序列、耗时、token消耗、评估分数。这些字段结构化存储RSI分析起来就方便多了。第三个坑是harness的版本要和agent的版本分开管理。agent的prompt可以天天改但harness的版本要稳定。如果两者混在一起出了问题很难定位是agent的问题还是harness的问题。6.3 harness工程的未来方向我个人觉得harness工程接下来会往两个方向走。一个是标准化出现一些通用的harness组件大家不用重复造轮子。另一个是智能化harness本身具备一定的自适应能力能根据agent的运行状态自动调整参数。但智能化这一步要谨慎。harness的智能化如果做过头就变成了harness自己在做RSI这时候评估和回滚的复杂度会更高。我的建议是harness先做好标准化和可观测智能化慢慢来。7. 一些实操中的经验与教训7.1 从小处着手别一上来就搞大的我见过太多团队一上来就想做架构层面的RSI结果连prompt层面的评估都没做明白。RSI是一个层层递进的东西你得先把最基础的评估体系搭起来把提示词层面的改进跑通有了信心和经验再往上走。我的建议是第一个RSI项目就做一件事让agent自己优化自己的系统提示词。任务要简单评估要明确迭代要快。跑通了这个你就理解了RSI的核心难点在哪里后面再扩展就有底了。7.2 评估标准要写下来不要放在脑子里很多人做评估的时候标准是在脑子里的我觉得这个回答好。这种评估没法自动化也没法复现。你必须把标准写下来写成明确的、可操作的规则。比如回答必须包含至少三个具体例子、回答不能超过200字、回答必须引用来源。这些规则写下来之后才能变成代码才能自动化。写标准的过程本身也是梳理需求的过程。很多时候你以为自己知道想要什么写下来才发现其实不知道。这个痛苦的过程是值得的。7.3 保留人类否决权不管RSI做得多好人类否决权一定要保留。这不是对agent的不信任而是对复杂系统的敬畏。任何自动化系统都会有盲区人类的直觉有时候能发现自动化评估发现不了的问题。我的做法是所有自动升级的版本都会通知到人。人可以随时否决否决之后系统回滚。这个通知不需要人每次都看但必须发。这样既保证了效率又保留了干预能力。7.4 记录每一次失败RSI的迭代过程中失败的尝试比成功的尝试多得多。这些失败如果记录下来就是宝贵的资产。我一般会维护一个失败日志记录每次改进的方向、为什么失败、失败的表现是什么。下次agent再往这个方向改的时候就能提前预警。这个失败日志不需要很复杂一个表格就够了。但坚持记录很重要因为人的记忆是不可靠的agent的记忆更不可靠。失败方向失败表现根因规避策略过度增加prompt长度成本上升效果持平信息密度下降限制prompt长度上限针对单一指标优化其他指标下降指标间存在trade-off多维度评估大幅改动prompt结构效果波动大改动不可归因每轮只改一个维度这张表是我自己项目里的真实记录每一条都是踩过坑之后总结的。你可以参考这个格式建自己的失败日志。7.5 不要追求全自动RSI的终极形态可能是全自动的但现阶段追求全自动是不现实的。我的建议是半自动agent提出改进建议人做最终决策。这样既利用了agent的分析能力又保留了人的判断力。半自动的另一个好处是人可以在过程中学习。看着agent怎么改、为什么改人对任务的理解也会加深。这种学习是双向的人教agentagent也教人。8. 关于RSI未来走向的一些个人判断RSI接下来会怎么走我说不好但有几个方向我觉得是确定的。第一评估会越来越重要。现在大家还在拼agent的能力接下来会拼评估的精度。谁的评估更准谁的RSI就更有效。评估本身会成为一个专门的技术领域。第二harness会越来越标准化。现在每家都在自己搭harness接下来会出现一些通用的harness组件和规范。这对整个行业是好事大家不用重复造轮子可以把精力放在更有价值的地方。第三安全会成为硬约束。现在RSI还在探索阶段安全问题还不是最紧迫的。但随着RSI的能力增强安全会成为硬约束不合规的RSI方案根本没法上线。第四人机协作的模式会变。现在是人主导、agent辅助接下来可能是agent主导、人监督。这个转变不会一夜之间发生但方向是明确的。最后分享一个我自己的体会RSI这件事技术上的难点其实都能克服真正的难点在于耐心。RSI是一个慢功夫需要一轮一轮地跑一次一次地调急不得。我见过太多团队跑了两轮没看到明显效果就放弃了。但那些坚持下来的团队半年之后回头看进步是惊人的。如果你正在做RSI或者打算做我的建议是把预期放低把周期拉长把评估做扎实。剩下的交给时间。

递归自我改进（RSI）工程实践：从提示词优化到harness落地的核心挑战

相关推荐

Agent未来不在聊天框：WorkBuddy实战拆解与去聊天框化指南

AI芯片软硬件协同设计：脉动阵列与2:4稀疏实战解析

JavaWeb数码推荐平台：轻量级可调试推荐系统实现

更多资讯

Godot 4.6 轻量角色状态机开发实战：从零搭建可扩展架构

Unity DOTS Physics Raycast实战：从原理到代码排查全解析

Unity DOTS Physics Raycast完全指南：从概念到并行批量射线检测

RAG知识库多租户隔离实战：从向量存储到LLM输出的七层防御

Agent技能实战：从Function Calling到技能库设计，让大模型真正“会做事”

生产级Agent三层架构：Harness、Loop与Graph实战解析

今日更新

Agent Skills 完全指南：原理、写法、安装与实战避坑

Agent Skills 实战：从 Genkit 定义到 GKE 部署与排查

Agent Skills 实战：从设计到调试的完整指南

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？