Anthropic内部RSI方法论：Agent递归自我改进的工程化闭环

1. 这套方法论到底在讲什么

先把话说在前头，Anthropic 这次公开的所谓“内部 RSI 落地方法论”，核心不是某个新模型，也不是某个新工具，而是一套让 Agent 自己迭代自己、自己评估自己、自己改进自己的工程化流程。RSI 在这里指的是 Recursive Self-Improvement，递归式自我改进。听起来很玄，但拆开看，它其实就是把“人写提示词、人调参数、人做评测”这套传统流程，尽可能交给 Agent 自己跑起来。

我第一时间把公开出来的材料通读了一遍，又结合 Claude Code、Agent 框架、评测集这些关键词做了交叉验证。结论很明确：这套方法论真正有价值的地方，不在于“AI 自己进化”这种科幻叙事，而在于它给出了一条可复现、可度量、可回滚的工程路径。它解决的是 Agent 开发里最痛的一个问题——你改了一版提示词或者换了一个工具链，到底变好了还是变坏了，很多时候说不清楚。

适合谁来参考？三类人。第一类是正在做 Agent 项目的开发者，尤其是用 Claude Code、Claude CLI 这类工具链的人；第二类是做 AI 测试开发、需要搭建评测体系的工程师；第三类是产品经理或者技术负责人，想搞清楚 Agent 迭代到底该怎么管。如果你只是偶尔用 AI 聊聊天，这篇文章可能偏重，但里面关于“怎么判断一个改动是不是真的有效”的思路，对任何做 AI 应用的人都适用。

我先把这套方法论的骨架摆出来，后面再逐层拆。它大致分四层：任务定义层、执行层、评估层、改进层。任务定义层负责把目标拆成可验证的子任务；执行层用 Agent 去跑；评估层用自动化指标加人工抽检去打分；改进层根据评估结果反向修改提示词、工具配置或者流程。四层形成一个闭环，跑一轮就是一次 RSI 迭代。

注意：RSI 不是让模型自己改自己的权重，那是另一回事。这里说的自我改进，改的是提示词、工具调用策略、任务分解方式这些“外层配置”。这一点必须先厘清，否则很容易被带偏。

2. 为什么这套方法论值得认真看

2.1 传统 Agent 开发的三个死结

我自己做 Agent 项目有一段时间了，踩过的坑基本能归成三类。第一类是改动不可度量。你调了一版系统提示词，感觉回答变好了，但到底是这一版好还是上一版好，没有数据支撑，全靠感觉。第二类是评测成本太高。想认真评测就得人工一条条看，几十条还能忍，几百条就崩了。第三类是改进不可复现。某次改动效果不错，但过两天想复现，发现当时改了哪些地方记不清了。

Anthropic 这套方法论的价值，就是针对这三个死结来的。它用结构化任务定义解决不可度量，用自动化评估加抽检解决评测成本，用版本化配置管理解决不可复现。说白了，它把软件工程里那套 CI/CD 的思路，搬到了 Agent 开发上。

2.2 和普通 Prompt 调优的本质区别

很多人会把 RSI 和 Prompt 调优混为一谈，其实差别很大。普通 Prompt 调优是“我改一版，跑几个例子看看”，样本量小、主观性强、没有回归测试。RSI 方法论要求的是：每次改动都要跑完整评测集，要有基线对比，要有统计意义上的显著性判断。

我举个具体例子。假设你在做一个客服 Agent，原来回答准确率是 78%。你改了一版提示词，抽了 20 条测试，准确率变成 85%。普通调优到这里就结束了，觉得改得不错。但 RSI 方法论会要求你：20 条样本够不够？这 7 个百分点的提升是不是随机波动？有没有哪类问题变差了？这些问题的答案，决定了这次改动到底该不该合并。

2.3 这套方法论的适用边界

不是所有 Agent 项目都适合上这套东西。我的判断标准是：如果你的 Agent 任务有明确的成功判据，且单次评测成本可控，那就值得上。比如代码生成、结构化信息抽取、分类判断这类任务，成功与否比较容易判定。但如果是开放式创作、情感陪伴这类任务，成功判据模糊，硬套这套方法论反而会增加负担。

另外，这套方法论对工程能力有一定要求。你需要能写评测脚本、能管理配置文件、能跑批量任务。如果团队里没有人能搭这套基础设施，建议先从最小可用版本开始，别一上来就追求完整闭环。

3. 四层闭环的逐层拆解

3.1 任务定义层：把模糊目标变成可验证子任务

这一层是最容易被忽视的，但恰恰是最重要的。Anthropic 的做法是，把一个大任务拆成若干可独立验证的子任务，每个子任务都有明确的输入、输出和成功判据。

我拿代码生成举例。假设你要做一个“根据需求文档生成接口代码”的 Agent。直接评测“生成的代码好不好”太模糊了。拆解之后可以变成：语法是否正确、是否能通过编译、是否符合接口规范、是否有边界处理、是否有单元测试。每个子任务都可以单独打分，最后加权汇总。

这里有个关键细节：子任务的判据要尽量机械化。能自动判定的就不要人工判，能二值判定的就不要用打分。比如“语法是否正确”可以用编译器直接判定，“是否符合接口规范”可以用静态检查工具判定。只有实在没法机械化的部分，才留给人工抽检。

提示：任务拆解不要一步到位追求完美。我自己的做法是先拆出 3 到 5 个核心子任务，跑一轮看看评估结果是否合理，再逐步细化。一上来拆太细，维护成本会很高。

3.2 执行层：Agent 怎么跑才稳定

执行层要解决的是“怎么让 Agent 稳定地把任务跑完”。这里涉及几个工程细节，我逐个说。

第一个是环境隔离。Agent 执行任务时可能会读写文件、调用工具、访问网络，如果不做隔离，很容易污染环境或者互相干扰。常见做法是用容器或者虚拟机跑，每次任务开始前重置环境。热词里提到的“Claude 的 workspace 需要虚拟机平台”就是这个层面的问题。

第二个是超时和重试。Agent 执行任务时可能卡住，必须有超时机制。超时之后是重试还是标记失败，要看任务性质。我的经验是，对于网络抖动这类瞬时问题，重试 2 到 3 次；对于逻辑错误，重试没用，直接标记失败。

第三个是执行日志。每次 Agent 执行都要记录完整的输入、输出、工具调用序列、耗时。这些日志是后续评估和改进的依据。没有日志，评估层就是空中楼阁。

# 一个简化的执行层封装示例 import subprocess import json import time def run_agent_task(task_input, config, timeout=300): start = time.time() try: result = subprocess.run( ["claude", "--config", config, "--input", task_input], capture_output=True, timeout=timeout, text=True ) elapsed = time.time() - start return { "status": "success" if result.returncode == 0 else "failed", "output": result.stdout, "error": result.stderr, "elapsed": elapsed } except subprocess.TimeoutExpired: return { "status": "timeout", "output": "", "error": "task exceeded timeout", "elapsed": time.time() - start }

这段代码只是示意，实际项目里还要考虑并发控制、资源限制、结果持久化等问题。但核心思路就是：把 Agent 执行当成一个可观测、可控制、可重放的函数调用。

3.3 评估层：自动化指标加人工抽检

评估层是整套方法论的核心。Anthropic 的做法是自动化指标为主，人工抽检为辅。

自动化指标怎么定？取决于任务类型。代码生成可以用编译通过率、测试通过率、静态检查告警数。信息抽取可以用准确率、召回率、F1。分类任务可以用混淆矩阵。关键是要有一个综合评分，能把多个指标合成一个可比较的数值。

人工抽检怎么做？我的经验是，按分层抽样来。先按任务类型分层，每层随机抽 5 到 10 条，人工打分。抽检的目的不是替代自动化指标，而是发现自动化指标覆盖不到的问题。比如自动化指标显示准确率提升了，但人工抽检发现回答变得很啰嗦，用户体验下降，这种问题自动化指标是看不出来的。

这张表是我自己项目里用的，不一定通用，但思路可以参考。核心是自动化和人工各管一段，不要互相替代。

3.4 改进层：根据评估结果反向修改

改进层要做的是：拿到评估结果之后，判断哪些改动有效，哪些无效，然后决定下一步改什么。

这里有个关键概念叫基线对比。每次改动都要和当前基线比，只有显著优于基线才合并。什么叫显著？我的做法是，综合评分提升超过 3 个百分点，且没有哪个子任务明显变差，才算显著。这个阈值可以根据任务敏感度调整。

改进的方向通常有三个：改提示词、改工具配置、改任务分解方式。改提示词是最常见的，比如增加约束条件、调整输出格式、补充示例。改工具配置包括换工具、调参数、改调用顺序。改任务分解方式是最后考虑的，因为改动成本最高。

注意：不要一次改多个地方。我踩过的坑是，一次同时改了提示词和工具配置，结果效果变好了，但不知道是哪个改动起的作用。后来改成每次只改一个变量，虽然慢一点，但每次改动的归因很清楚。

4. 实操过程：从零搭一套最小闭环

4.1 准备阶段：环境、工具、评测集

先说环境。如果你用 Claude Code 或者 Claude CLI，建议在 Linux 或者 macOS 上跑，Windows 上会有一些兼容性问题。热词里提到的“无法将 claude 项识别为 cmdlet”就是 Windows 环境变量没配好。我的建议是，如果条件允许，直接用 Ubuntu 或者 macOS，省去很多麻烦。

工具方面，核心是三个：Agent 执行工具、评测脚本、配置管理。Agent 执行工具用 Claude Code 或者自己封装的 CLI 都行。评测脚本用 Python 写，配合 pytest 或者自定义的评测框架。配置管理用 Git，每次改动都提交，方便回滚。

评测集的准备是最花时间的。我的做法是分三步：第一步，从真实业务场景里收集 50 到 100 条典型任务；第二步，给每条任务标注预期输出或者成功判据；第三步，按难度和类型分层，确保评测集有代表性。评测集不是一次性的，要随着业务变化持续更新。

4.2 第一轮迭代：建立基线

第一轮迭代的目标不是提升效果，而是建立基线。用当前最好的配置跑一遍完整评测集，记录各项指标。这个基线是后续所有改动的参照物。

跑基线的时候要注意几点。第一，样本量要够。我的经验是至少 50 条，最好 100 条以上。样本太少，指标波动大，没法判断改动是否有效。第二，环境要一致。每次跑评测的环境要尽量相同，否则指标差异可能来自环境而不是改动。第三，记录要完整。每条任务的输入、输出、耗时、Token 消耗都要记录，方便后续分析。

# 跑一轮评测的简化命令 python evaluate.py \ --config configs/baseline.yaml \ --testset testsets/v1.jsonl \ --output results/baseline_$(date +%Y%m%d_%H%M%S).json

跑完之后，你会得到一份基线报告。报告里应该有综合评分、各子任务评分、失败案例列表。失败案例特别重要，它是下一轮改进的起点。

4.3 第二轮迭代：针对性改进

拿到基线报告之后，先看失败案例。把失败案例分类，看看主要问题出在哪里。常见的问题类型有：理解偏差、格式错误、遗漏步骤、工具调用失败、超时。

针对不同问题，改进方向不同。理解偏差改提示词，增加任务描述和示例。格式错误改输出约束，明确要求输出格式。遗漏步骤改任务分解，把大任务拆得更细。工具调用失败改工具配置，换工具或者加错误处理。超时改超时阈值或者优化执行流程。

我拿一个真实案例说。之前做一个信息抽取 Agent，基线准确率 72%。看失败案例发现，大部分错误是把“公司名称”和“产品名称”搞混了。于是我在提示词里加了一条：“注意区分公司名称和产品名称，公司名称是组织实体，产品名称是具体产品”。改完再跑，准确率到 81%。这就是一次典型的针对性改进。

4.4 第三轮迭代：验证与合并

改完之后要跑完整评测集，和基线对比。如果综合评分显著提升，且没有子任务明显变差，就可以合并。合并的意思是，把这版配置设为新基线，提交到 Git，记录改动说明。

如果提升不显著，或者有子任务变差，就要分析原因。可能是改动方向不对，也可能是改动引入了新问题。这时候要么回滚，要么继续调整。我的经验是，不要在一个方向上死磕。如果一个方向改了两三次都没效果，就换个方向。

这里有个细节：改动说明要写清楚。我见过太多项目，改了一堆东西，过两个月没人记得当时为什么改。改动说明至少包含：改了什么、为什么改、评测结果如何、有什么副作用。这份记录是团队协作的基础。

5. 常见问题与排查技巧

5.1 评测结果波动大怎么办

这是最常见的问题。同一版配置跑两次，综合评分差好几个百分点。原因通常有三个：样本量太小、任务本身有随机性、环境不一致。

解决办法：第一，增加样本量，至少 50 条起步。第二，对于有随机性的任务，固定随机种子，或者多次运行取平均。第三，检查环境是否一致，包括模型版本、工具版本、系统负载。我自己的做法是，评测跑三次取平均，如果三次之间差异超过 5 个百分点，就说明评测集或者评测流程有问题，先解决这个问题再谈改进。

5.2 Agent 执行失败怎么排查

Agent 执行失败的原因很多，我整理了一个排查顺序。

这个顺序是从外到内，先排查环境问题，再排查逻辑问题。大部分失败都是前两项引起的，别一上来就怀疑模型。

5.3 改进效果不明显怎么办

改了好几版，效果就是上不去。这种情况我遇到过好几次。原因通常是：改进方向不对、评测指标不合理、任务本身太难。

先检查改进方向。如果失败案例主要是理解偏差，你却在改输出格式，那肯定没效果。再检查评测指标。如果指标设计得不合理，比如把不重要的维度权重设得太高，那改进方向就会被带偏。最后检查任务本身。如果任务难度远超当前模型能力，那再怎么改提示词也没用，需要考虑换模型或者拆任务。

提示：我自己的经验是，如果连续三轮改进都没有显著提升，就停下来重新审视任务定义和评测指标。很多时候问题不在执行层，而在定义层。

5.4 怎么判断改动是否值得合并

这个问题前面提过，这里再展开说。我的判断标准是三条：综合评分显著提升、没有子任务明显变差、改动成本可接受。

综合评分显著提升，前面说了，3 个百分点起步。没有子任务明显变差，意思是不能为了提升一个维度而牺牲另一个维度。比如准确率提升了，但耗时翻倍，这就要权衡。改动成本可接受，意思是改动不能太复杂，否则维护成本会吃掉收益。

三条都满足才合并，有一条不满足就再想想。这个标准看起来严格，但能避免很多“看起来变好了其实埋了坑”的改动。

6. 我踩过的坑和几条实在建议

第一个坑是评测集和训练集重叠。早期做项目的时候，我用同一批数据既调提示词又做评测，结果指标虚高，上线之后效果差很多。后来改成评测集和调优集分开，评测集只在最终验证时用，指标才真实。

第二个坑是过度依赖自动化指标。有一版配置自动化指标很好，但人工抽检发现回答变得很机械，用户体验下降。后来我固定了人工抽检环节，每轮至少抽 20 条，专门看自动化指标覆盖不到的问题。

第三个坑是配置管理混乱。早期改配置直接改文件，没有版本管理，想回滚都回不去。后来所有配置都进 Git，每次改动都有 commit message，回滚就是一条命令的事。

几条实在建议。第一，先从最小闭环开始，别一上来就追求完整。任务定义、执行、评估、改进四层，先跑通一层再加下一层。第二，评测集是资产，要持续维护，别用完就扔。第三，改动要小步快跑，每次只改一个变量，归因清楚。第四，日志要全，执行日志、评测日志、改动日志，一个都不能少。

这套方法论说到底，核心不是技术，是工程纪律。它要求你把 Agent 开发当成正经软件工程来做，有评测、有版本、有回滚、有记录。做到这些，效果提升是自然的事。做不到这些，再好的模型也白搭。