智能体“换脑”还是“换法”？RSI 自我改进机制与传统人工调优对比

一、对比背景：模型没换，智能体为何会变强？

在实际研发协作中，很多团队会遇到一个看似矛盾的现象：底层模型没有更换，参数没有调整，但智能体的任务完成质量却出现了明显变化。有时是因为提示词被优化，有时是因为技能配置被补充，有时则是因为智能体从一次失败中“学到了”新的处理流程。

这引出了一个关键问题：智能体的能力提升，究竟来自模型本身，还是来自模型之外的工作机制？

围绕这个问题，当前业界逐渐形成两条典型路径：

• 路径 A：传统人工调优——由开发者根据任务反馈，手动修改提示词、技能、工具配置或执行约束；
• 路径 B：递归自我改进（Recursive Self-Improvement，RSI）——让智能体参与问题分析、生成改进方案，并通过评测机制判断改进是否值得保留。

本文将以需求交付类任务为背景，对这两种路径进行系统对比，帮助开发者、技术负责人和架构师理解：它们的区别是什么、各自适合什么场景、迁移时需要注意哪些问题。

二、对象定义：两种路径分别解决什么问题？

2.1 传统人工调优

传统人工调优是指：智能体在执行任务时出现错误，开发者通过观察执行日志、复现问题、分析原因，然后手动调整智能体的工作配置。这些配置通常包括：

• 提示词（Prompt）：调整角色设定、任务描述、输出格式；
• 技能（Skill）：新增或修改智能体可调用的能力模块；
• 工具（Tool）：改变智能体可使用的工具集及其调用方式；
• 上下文与约束：调整上下文注入策略、执行流程、检查清单等。

在这种模式下，改进的驱动力来自人。智能体负责执行任务，人负责发现问题并修正配置。

2.2 递归自我改进（RSI）

RSI 的核心思路是：让智能体在任务完成后，不只交付结果，还能基于反馈分析自身工作流程中的不足，生成改进方案，并通过评测验证改进是否有效。如果有效，改进会被保留并应用到后续任务中；如果无效，则被丢弃或回退。

RSI 通常支持两个优化方向：

• Harness 优化：面向提示词、技能、工具配置等“工作方式”层面的改进；
• Artifacts 优化：面向具体交付产物（如文档、程序、报告）的持续修改与验证。

本文重点讨论 Harness 优化，即智能体如何改进自己的“工作方法”，而不是直接修改模型权重。

三、相同点分析：二者并非对立

在展开差异之前，需要先明确：传统人工调优与 RSI 并不是互斥关系，它们在以下方面高度一致。

维度	共同点
优化对象	都聚焦于模型之外的 Harness 层，而非模型参数本身
目标	都希望减少重复性错误，提高任务一次通过率
依赖反馈	都需要任务结果或人工反馈作为改进依据
验证机制	都需要通过评测或实际运行判断改进是否有效
适用任务	都适用于需求交付、文档处理、研发协作等复杂任务

换句话说，RSI 并不是要取代人工调优，而是尝试把人工调优中“分析问题、提出方案、验证效果”的部分环节自动化，让智能体参与到自身工作方式的改进中。

四、核心差异分析：从六个维度展开

4.1 改进驱动力：人 vs 智能体

传统人工调优的驱动力是开发者。开发者需要：

1. 发现智能体出错；
2. 定位错误原因；
3. 判断应该修改提示词、技能还是工具；
4. 手动修改配置；
5. 重新运行任务验证。

RSI 的驱动力则部分转移给智能体。智能体在任务失败或收到反馈后，可以：

1. 分析失败原因；
2. 生成改进方案；
3. 将方案提交给评测机制；
4. 根据评测结果决定是否保留改进。

这并不意味着人完全退出，而是人的角色从“直接修配置”转变为“设定目标、定义评测标准、审核关键改进”。

4.2 优化粒度：局部修补 vs 系统性沉淀

人工调优往往针对具体问题做局部修补。例如：智能体遗漏了验收检查表中的某项内容，开发者就在提示词中补充“必须同步更新验收清单”。

RSI 则尝试把这类具体纠错抽象为更通用的改进。例如：将“同步更新验收清单”上升为“在业务规则变更时，检查所有关联交付物的一致性”。这种改进一旦被验证有效，可以复用到更多类似任务中。

4.3 验证方式：人工判断 vs 评测驱动

人工调优的效果验证通常依赖开发者经验。开发者修改配置后，重新跑一次任务，观察结果是否改善。这种方式灵活，但难以规模化，也容易受到主观判断影响。

RSI 更强调评测驱动。改进方案需要经过预设的评测集或评测流程验证，只有通过验证的改进才会被保留。这种方式更适合需要长期、多次迭代的场景，但对评测体系的设计要求较高。

4.4 迭代速度与规模

人工调优的迭代速度受限于人的时间和精力。一个开发者同时只能处理有限的问题，改进的积累速度较慢。

RSI 在理论上可以并行处理多个改进方向，并在每次任务后自动触发分析。但它的实际效果取决于评测质量、改进方案的质量以及回退机制是否健全。

4.5 风险与控制

人工调优的风险相对可控，因为每次修改都经过开发者确认。缺点是可能引入人为疏忽，或者修改之间缺乏一致性。

RSI 的风险在于：如果评测机制不完善，可能保留看似有效但实际有害的改进，导致智能体行为漂移。因此，RSI 通常需要配套的回退、审计和边界控制机制。

4.6 适用阶段

阶段	更适合的方式
智能体能力建设初期	人工调优为主，明确基本流程和边界
任务模式稳定、重复性高	RSI 可逐步引入，沉淀通用改进
任务变化频繁、规则不稳定	人工调优更灵活，RSI 可能跟不上变化
需要长期规模化运行	RSI + 人工审核组合更合适

五、对比表格：关键差异一览

对比维度	传统人工调优	RSI 自我改进
改进驱动力	开发者	智能体 + 评测机制
优化对象	提示词、技能、工具、约束	同样面向 Harness，但可自动生成方案
改进粒度	多为局部修补	倾向抽象为通用规则
验证方式	人工判断为主	评测驱动为主
迭代速度	受人力限制	可并行、可自动触发
风险控制	人工确认，风险低但一致性弱	需评测与回退机制，风险中等
适用阶段	初期、规则不稳定期	稳定期、重复性高的任务
迁移成本	低，直接修改配置	中，需要评测体系与回退机制

六、典型场景选择：不同业务下怎么选？

6.1 需求交付类任务

在需求交付中，常见问题是：业务规则变更后，智能体更新了研发任务清单，却遗漏了验收检查表。这类问题重复出现时，人工调优可以快速修补，但难以保证下次不再犯。

如果任务模式相对稳定，且团队已经有一套验收标准，可以引入 RSI，让智能体在每次任务后分析“哪些关联交付物没有同步更新”，并将改进方案沉淀为检查规则。

6.2 文档处理与研发协作

对于文档整理、代码生成、测试用例编写等任务，人工调优适合处理个性化要求；RSI 适合处理重复出现的共性问题，例如格式一致性、命名规范、依赖检查等。

6.3 高合规、高安全场景

在金融、医疗等对合规要求较高的场景中，RSI 的自动改进需要更严格的审核。建议采用“RSI 生成方案 + 人工审核 + 评测验证”的组合方式，避免智能体自动修改关键流程。

七、选型建议：条件化判断

• 如果团队处于智能体应用初期，任务流程尚未稳定，建议以人工调优为主，先明确基本规则和边界；
• 如果任务重复性高、错误模式相似，且已有可量化的评测标准，可以尝试引入 RSI，逐步沉淀改进；
• 如果业务规则频繁变化，RSI 的改进可能很快过时，此时人工调优的灵活性更有优势；
• 如果团队运维能力有限，建议先从 Harness 优化中的小范围试点开始，避免一次性放开所有改进权限；
• 如果对稳定性要求极高，RSI 必须配套回退机制、版本管理和审计日志。

八、迁移与使用注意事项

从人工调优迁移到 RSI，或二者组合使用时，需要关注以下问题：

1. 评测体系是否完备：没有可靠评测，RSI 的改进无法验证；
2. 回退机制是否健全：改进无效时能否快速恢复；
3. 权限边界是否清晰：智能体可以修改哪些配置，不能修改哪些配置；
4. 改进是否可解释：每次保留的改进是否有记录、可追溯；
5. 任务分布是否稳定：RSI 更适合任务模式相对稳定的场景；
6. 人工审核是否保留：关键改进建议仍需人工确认。

九、总结

模型没换，智能体却变强了，背后的关键往往不在模型本身，而在 Harness 层的持续优化。传统人工调优和 RSI 自我改进，本质上都在解决同一个问题：如何让智能体从任务反馈中学习，并保留有效的改进。

二者的核心差异在于：改进的驱动力、验证方式和迭代规模。人工调优灵活、可控，适合初期和规则不稳定阶段；RSI 更适合重复性高、评测体系完善的场景，能够把具体纠错沉淀为通用能力。

在实际选型中，不必二选一。更务实的做法是：以人工调优明确边界，以 RSI 沉淀共性改进，再通过评测和回退机制控制风险。这样才能在模型不变的前提下，让智能体真正越用越强。