Anthropic内部Agent递归自我改进方法论：从轨迹采集到回归验证的工程化实践

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执行必须留下结构化的完整轨迹。什么叫结构化至少包含这些字段字段说明为什么重要step_id步骤序号定位问题到具体步骤thought模型当时的推理判断是想错了还是做错了action调用的工具及参数检查工具选择是否正确observation工具返回结果判断是环境问题还是理解问题timestamp时间戳分析耗时瓶颈token_usage该步消耗成本归因没有这张表你的改进就是拍脑袋。有了这张表你才能回答到底是第几步开始跑偏的。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。如果一有失败就改提示词最后提示词会变成一锅粥什么都想兼顾什么都做不好。我的触发规则是这样的条件是否触发改进单次失败无同类不触发记录观察同类失败≥3次触发进入改进流程某维度平均分连续下降触发优先排查改进后回归集下降回滚重新分析这个规则的核心是用统计显著性代替直觉。三次是个经验值团队可以根据任务量调整。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这套东西难的不是技术是纪律。记录轨迹要纪律评估要纪律一次只改一个变量要纪律维护回归集要纪律。技术方案网上都能找到但能坚持把纪律执行下去的团队不多。我见过太多团队方案设计得漂漂亮亮跑了两周就嫌麻烦不记录了循环自然就转不起来了。所以如果你打算做这件事先问问自己能不能坚持每天记录、每周评估、每次改进都走完整流程。能再开始。