1. 从"RSI"这个词说起：它到底指什么

先把概念理清楚，不然后面全是空中楼阁。RSI在这类语境下指的是递归自我改进（Recursive Self-Improvement），核心思路是让系统具备"改进自身能力"的闭环——不是让模型自己改权重（那是另一回事），而是让Agent在真实任务中不断沉淀经验、优化自己的提示词、工具链、编排逻辑，从而在下一轮任务里表现更好。

Anthropic这次公开的内部方法论，最有价值的点不在于"他们做了个多强的Agent"，而在于他们把"改进"这件事拆成了可工程化的步骤。很多人做Agent卡在同一个地方：Demo跑得挺漂亮，一上真实任务就崩，崩了之后也不知道从哪改。原因就是缺少一个系统化的"自我诊断—修改—验证"回路。

我先把这套方法论的核心骨架摆出来，后面再逐层拆：

• 执行层：Agent跑任务，产生完整的执行轨迹（trajectory），包括每一步的思考、工具调用、返回结果。
• 评估层：不是简单看"成功/失败"，而是对轨迹做细粒度打分，定位到具体哪一步出了问题。
• 改进层：根据评估结果，修改Agent的配置——可能是提示词、可能是工具描述、可能是编排策略。
• 验证层：改完之后必须在回归集上验证，防止"改好一个、弄坏三个"。

这四层循环起来，才叫RSI落地。缺任何一层，都只是"手动调Prompt"而已。

注意：RSI不等于让模型自己训练自己。绝大多数团队能落地的RSI，改的是Agent的配置和策略，不是模型权重。这个边界一定要清楚，否则方向就偏了。

2. 执行轨迹才是这套方法论的真正燃料

2.1 为什么大多数人根本没在记录轨迹

我见过太多Agent项目，日志里只有一行"任务完成"或者"任务失败"。这种日志拿来debug都费劲，更别说做自我改进了。Anthropic方法论里第一个硬性要求就是：每一次Agent执行，必须留下结构化的完整轨迹。

什么叫结构化？至少包含这些字段：

没有这张表，你的"改进"就是拍脑袋。有了这张表，你才能回答"到底是第几步开始跑偏的"。

2.2 轨迹采集的三个实操坑

第一个坑：轨迹太长导致上下文爆炸。一个复杂任务跑50步很正常，全塞进上下文做分析，模型直接懵。我的做法是分层压缩——每10步做一次摘要，保留关键决策点，丢弃重复的探索步骤。

第二个坑：工具返回结果太大。比如一次网页抓取返回几万字，直接进轨迹会淹没真正的信息。必须在采集层就做截断和摘要，只保留和当前目标相关的片段。

第三个坑：敏感信息混入。轨迹里可能包含用户数据、内部路径、密钥片段。采集时就要做脱敏，别等出事再补。

# 轨迹记录的最小可用结构 trajectory = { "task_id": "xxx", "goal": "用户原始目标", "steps": [ { "step_id": 1, "thought": "我需要先查一下当前目录结构", "action": {"tool": "list_dir", "args": {"path": "."}}, "observation": "...", "tokens": 320 } ], "outcome": "success/fail", "final_answer": "..." }

这个结构看着简单，但它是后面所有评估和改进的基础。我建议一开始就把字段定死，别中途改，否则历史数据全废。

2.3 轨迹的存储与检索策略

轨迹数据量会涨得很快。一个中等规模团队，一天几千条轨迹很正常。存储上我推荐两个思路：

• 热数据：最近7天的轨迹，放关系库或文档库，支持快速查询和人工review。
• 冷数据：超过7天的，压缩后归档，只在做批量分析时拉取。

检索维度至少要支持：按任务类型、按成功/失败、按工具名、按耗时区间。这样你才能快速捞出"所有用了某个工具且失败的轨迹"，针对性分析。

3. 评估层：把"好不好"拆成可打分的维度

3.1 二元评估是最大的浪费

"成功/失败"这个标签信息量极低。一个失败的任务，可能是工具选错了、可能是参数传错了、可能是推理链断了、也可能是环境本身有问题。这四种情况的改法完全不同。

Anthropic的做法是把评估拆成多个维度，每个维度独立打分。我实践下来，这几个维度最有用：

• 目标达成度：最终结果是否解决了用户的问题（0-1分）。
• 路径效率：是否走了弯路，步数是否明显多于必要（0-1分）。
• 工具使用正确性：选的工具对不对，参数对不对（0-1分）。
• 推理连贯性：思考链有没有断裂或自相矛盾（0-1分）。

四个维度一打分，问题定位就清晰了。比如"目标达成但路径效率低"，说明Agent能做对但太笨，优化方向是提示词里加"先规划再执行"。"工具使用错误"，说明工具描述写得不好，模型不知道什么时候该用哪个。

3.2 用模型评估模型：怎么避免自欺欺人

评估这件事，人工做不起，只能靠模型。但模型评估模型有个天然风险：评估模型和被评估模型共享同样的盲区。

我的应对办法有三条：

第一，评估提示词要独立设计，不能复用Agent的提示词。评估者的角色是"挑剔的审查员"，不是"帮忙的同事"。

第二，关键任务做人工抽检。我一般抽5%-10%，用来校准模型评估的准确率。如果发现模型评估和人工判断偏差大，先修评估提示词。

第三，引入对抗样本。故意构造一些"看起来成功实际失败"的轨迹，看评估模型能不能识别。识别不出来，说明评估维度设计有漏洞。

# 评估提示词的核心结构（简化版） eval_prompt = """ 你是一个严格的Agent执行审查员。请对以下轨迹打分。 任务目标：{goal} 执行轨迹：{trajectory} 请从四个维度打分（0-1），并给出理由： 1. 目标达成度 2. 路径效率 3. 工具使用正确性 4. 推理连贯性 输出JSON格式，不要有多余文字。 """

3.3 评估结果的聚合与归因

单条轨迹的评估分数只是原料，真正有用的是聚合分析。我一般按这几个维度切：

• 按任务类型聚合：哪类任务整体得分低？
• 按工具聚合：哪个工具相关的失败率最高？
• 按步数区间聚合：是不是步数一多就容易崩？

聚合之后做归因。比如发现"所有涉及文件写入的任务，工具使用正确性都低"，那基本可以确定是文件写入工具的描述有问题，或者参数设计反直觉。

这一步是RSI的"诊断"环节，诊断不准，后面改也是白改。

4. 改进层：改什么、怎么改、改完怎么不翻车

4.1 改进的三个层次

改进不是只有"改提示词"一条路。按影响范围从小到大，分三层：

第一层：工具描述优化。这是最安全、见效最快的。模型选错工具，八成是工具描述写得含糊。比如一个"搜索"工具，描述里只写"搜索信息"，模型根本不知道什么时候该用。改成"当需要查找最新事实性信息时使用，输入为自然语言查询"，准确率立刻上来。

第二层：提示词策略调整。比如加"先列计划再执行"、加"每步执行后检查是否符合目标"、加"遇到不确定时先询问"。这一层影响面大，改之前一定要有回归集。

第三层：编排逻辑重构。比如从"单Agent串行"改成"规划Agent+执行Agent分离"，或者引入"反思Agent"做中间检查。这一层改动最大，风险也最高，一般只在评估显示系统性问题时才动。

4.2 改进的触发条件：别一有失败就改

这是我最想强调的一点。不是每次失败都值得改。有些失败是任务本身太难、有些是环境问题、有些是长尾case。如果一有失败就改提示词，最后提示词会变成一锅粥，什么都想兼顾，什么都做不好。

我的触发规则是这样的：

这个规则的核心是用统计显著性代替直觉。三次是个经验值，团队可以根据任务量调整。

4.3 改进的验证：回归集是生命线

改完必须验证，而且不能只验证"改的那个case"。我一般维护一个回归集，包含：

• 核心场景：必须一直成功的任务，20-30条。
• 边界场景：容易出错的，30-50条。
• 历史失败case：之前修过的，防止复发，越多越好。

每次改进后，全量跑一遍回归集。只有核心场景不退化、边界场景有提升、历史case不复发，才算改进成功。

# 回归测试的简化流程 1. 加载回归集（JSON格式，每条含goal和期望结果） 2. 对每条跑Agent，记录轨迹和结果 3. 用评估模型打分 4. 对比改进前后的分数 5. 生成报告：哪些提升、哪些退化、哪些不变

提示：回归集要持续维护。每次发现新的失败模式，就把它加进回归集。这样回归集会越来越强，你的Agent也会越来越稳。

4.4 改进的版本管理

改进必须可回滚。我见过团队改提示词改嗨了，结果某天发现效果变差，想回退却找不到旧版本。

做法很简单：每次改进都打版本号，提示词、工具描述、编排配置全部纳入版本管理。改进记录里写清楚：改了什么、为什么改、回归结果如何。这样出问题能快速定位到是哪次改动引入的。

5. 让循环真正转起来：工程化的几个关键决策

5.1 循环频率：别追求实时

有人想做成"每次任务后自动改进"，我不建议。原因有二：一是改进需要聚合分析，单条数据噪声太大；二是频繁改配置会让系统不稳定，难以debug。

我的建议是按批次：每天或每几天跑一次改进循环。收集一批轨迹，统一评估，统一改进，统一验证。这样既保证数据量足够，又给系统留出稳定期。

5.2 人工介入的边界

RSI不是全自动。至少这几个环节需要人：

• 评估维度的设计：模型不知道该关注什么，人得定。
• 改进方案的审核：模型可以提建议，但改不改、怎么改，人拍板。
• 回归集的维护：哪些case该进回归集，人判断。
• 异常情况的处理：评估分数突然暴跌，人得介入排查。

把人的角色定位成"规则制定者+最终审核者"，而不是"每步都手动操作"，这样既保证质量，又不会累死。

5.3 成本控制

这套循环是烧token的。评估要调模型，改进要调模型，验证还要跑Agent。我算过一笔账：一个中等规模团队，如果全量评估所有轨迹，成本会高得离谱。

控制成本的办法：

• 采样评估：不是所有轨迹都评估，按比例采样，比如20%。
• 分级评估：先用便宜模型做粗筛，可疑的再用强模型细评。
• 缓存复用：相同或相似的轨迹，评估结果可以复用。
• 回归集精简：回归集不是越大越好，覆盖关键场景即可，控制在100条以内。

5.4 一个容易忽略的点：改进的"副作用"

改A可能影响B。比如你为了提升"文件操作"的准确率，把提示词改得更强调"谨慎确认"，结果"快速执行"类任务的效率下降了。这种副作用在单维度评估里看不出来，必须靠回归集的全量对比。

我的经验是：每次只改一个变量。改提示词就别同时改工具描述，否则出了问题不知道是谁的锅。改完观察一段时间，确认稳定了，再动下一个。

6. 我在实操中踩过的几个坑

6.1 轨迹记录不全，事后无法归因

早期我觉得"记录thought和action就够了"，结果发现很多失败是"observation理解错了"导致的。没有完整的observation，根本定位不到。后来我把工具返回的原始结果也存了，虽然占空间，但排查问题时真香。

6.2 评估模型太"宽容"

一开始用的评估提示词写得太客气，模型给分普遍偏高，导致很多问题被掩盖。后来改成"你是严格的审查员，默认怀疑，除非有明确证据证明成功"，分数才回归真实。评估提示词的语气，直接影响评估结果的严厉程度，这个要反复调。

6.3 改进太激进，回归集崩了

有次我发现某类任务失败率高，一口气改了提示词、工具描述、编排逻辑三处。结果回归集跑下来，核心场景挂了两个。排查了半天才定位到是编排逻辑改动引入的问题。从那以后我坚持"一次只改一个变量"。

6.4 回归集不更新，新问题漏网

回归集如果一直不变，只能防旧问题，防不了新问题。我现在的做法是：每次线上发现新的失败模式，第一时间把它加进回归集。这样回归集是"活"的，跟着系统一起进化。

7. 这套方法论适合什么样的团队

不是所有团队都需要完整的RSI循环。我的判断标准是：

• 任务复杂度高：简单任务（比如固定格式转换）不需要RSI，写死规则就行。
• 任务量大：量小的话人工调优更划算。
• 有持续迭代需求：一次性项目不需要，长期运行的Agent才需要。
• 有工程能力：轨迹采集、评估、回归测试都需要工程投入，纯靠手工做不起来。

如果这四条都满足，那这套方法论值得投入。如果只满足一两条，可以先从"轨迹记录+人工review"做起，跑顺了再上自动化。

最后分享一个我自己的体会：RSI这套东西，难的不是技术，是纪律。记录轨迹要纪律，评估要纪律，一次只改一个变量要纪律，维护回归集要纪律。技术方案网上都能找到，但能坚持把纪律执行下去的团队不多。我见过太多团队，方案设计得漂漂亮亮，跑了两周就嫌麻烦不记录了，循环自然就转不起来了。所以如果你打算做这件事，先问问自己：能不能坚持每天记录、每周评估、每次改进都走完整流程。能，再开始。