自我改进是智能体领域被讨论得最多、落地得最少的方向之一。原因不复杂：大多数团队卡在第一步——改进的对象到底是什么。
如果对象是提示词，那它改的是工作方法；如果对象是最终交付物，那它改的是产出结果。这两件事的优化信号不同、验证方式不同、失败模式也不同。把它们混在一个循环里，梯度会互相抵消。
openJiuwen 这个开源智能体平台给出的答案，是把它们拆开。
一、双维度：Harness 与 Artifacts
框架的全称是双维度 RSI（Recursive Self-Improvement，递归自我改进），两个维度各自独立优化：
| 维度 | 优化对象 | 典型问题 |
|---|---|---|
| Harness | 智能体的工作方法：提示词、工具描述、控制流、失败恢复 | 出现失败案例，怎么改工作方式 |
| Artifacts | 交付物本身：论文、算法程序、报告 | 产物质量不够，怎么打磨这一版 |
这个拆分有个直接好处：两者的证据结构不一样。Harness 优化的证据来自「同一批任务上用新方法跑的结果」，Artifacts 优化的证据来自「这一版产物本身的评分」。分开之后，每一侧都能用最合适的信号做决策。
要理解它的位置，需要知道前置背景：openJiuwen 早在今年 6 月就发布过 Auto Harness 能力，那套东西是评测驱动的、覆盖 Harness 全栈组件的端到端自动优化框架。RSI 是在它之上加了两样东西——从真实任务反馈中生成改进方案，以及对非 Harness 对象（即交付物）的优化能力。
二、四层架构
RSI 的工程骨架被分成四层，每层解决一个明确的问题：
任务层 优化什么 / 如何评价 / 能用多少资源
│
迭代优化层 下一步试什么 / 哪些改进可以采纳
│
执行层 尝试优化并检测结果
│
基础框架层 运行 / 模型与上下文 / 沙箱隔离
状态恢复 / 可观测性这个分层值得逐层看，因为每一层都对应一个实际会踩的坑：
任务层负责把「目标」翻译成「可执行可评估的过程」。它要回答三个问题，而第三个问题「能用多少资源」经常被忽略——没有预算约束的优化循环会无限探索下去。
迭代优化层是搜索算法的所在。它决定下一步试什么，以及更重要的：哪些改进可以被采纳。后者的判定标准就是前面说的可验证执行证据。
执行层负责实际跑一遍并检测结果。这一层要处理的是沙箱隔离和状态恢复——长循环里任何一步崩掉，如果状态不可恢复，整轮实验都要重来。
基础框架层提供统一的运行、模型与上下文管理、可观测性能力。
三、两个关键的设计选择
在整套设计里，有两个选择决定了它和「随手写个优化循环」的区别。
第一，优化对象是版本化的。
这不是「生成新版本覆盖旧版本」，而是维护一棵搜索树。框架明确以「版本化优化对象」为核心之一，实验详情页会持续展示得分、迭代轮次、模型用量和搜索树结构。
版本化带来一个隐性好处：未采用的改动不会消失。面板会记录每一轮的改动细节、评测结果，以及没有被采纳的原因。最后这一项是绝大多数优化流程会直接丢掉的信息——而它恰恰是下次搜索时最有价值的负样本。
第二，改进必须有可验证的执行证据。
这是整个闭环能自我纠偏的前提。改进方案不是被「看起来更好」采纳的，而是被「在评测集上确实更好」采纳的。
⚠️ 这条约束同时限制了适用范围：它要求你有评测集。没有可验证的评测信号，框架无从判断哪次改进该被采纳。所以它天然适用于有明确评分规则的场景，对纯开放式任务帮助有限。
四、使用流程
框架被做成了产品化的四步流程，不需要写代码就能发起一轮优化：
第一步，准备评测集。 提交一个 JSON，包含用例知识、任务要求、评测方式、参考答案和评分规则五项。这是整条链路里最需要人工投入的部分，也是效果上限的决定因素。
第二步，创建实验。 在实验页面选择优化类型（Harness 优化或产物优化），然后选优化模型、测试模型、初始插件，再选评测集、评测方式和最大迭代轮次。
选择上有个细节值得注意：优化模型与测试模型是分开的。这意味着可以用强模型做搜索、用目标模型做验证，避免优化出来的方法只适配搜索时用的那个模型。
第三步，执行自动迭代。 页面持续展示得分曲线、迭代轮次、模型用量和搜索树——试错和被采纳的过程是可见的。
第四步，安装结果。 实验产出有效版本后点击「安装插件」，最优 Harness 作为插件包导入并热加载。
五、报告的数字
框架在三个场景上给出了实测，其中两个带明确基准：
Harness 优化
SWE-bench Lite 通过率 61.0% → 87.0%
Evo-Bench General (64 题, 冻结)
单次执行通过率 60.9% → 71.9%
算力亲和（昇腾基础设施）
响应速度 提升近 16%
最慢场景 提升超过 19%
上下文缓存命中率 7.53% → 14.36%
关键存储资源消耗 下降 20% 至 30%第二组数字是整个报告里最值得信赖的部分。61.0% 到 87.0% 是在优化所针对的那套东西上测的，天然有利；而把优化后的 Harness 冻结，拿到 64 道独立题上跑单次执行，得到 60.9% 到 71.9%——这个提升幅度小得多，但它是「泛化了多少」而不是「拟合了多少」。
这两个数字的差距（26 个百分点对 11 个百分点）本身就是信息：搜索得到的改进有一半以上是贴合特定评测集的。这不是缺陷，而是所有自动化优化的固有代价，能被诚实报出来反而说明测量做得认真。
算力侧的那组数字则是纯工程收益。多轮优化的成本瓶颈不在模型能力而在重复计算——提示词、工具描述、任务材料每轮都要重新走一遍，缓存命中率从 7.53% 提到 14.36% 直接意味着重复计算减半。
六、该有的怀疑
第一，评测集是人工前置投入。 五个字段里「用例知识」「参考答案」「评分规则」都要人来写。这决定了冷启动成本不低，也决定了它不适合「先跑起来再说」的探索期。
第二，搜索空间的边界没有明说。 Harness 的可优化范围是提示词、工具描述、控制流、失败恢复全栈，但实际搜索算法的探索能力有多强、会不会陷入局部最优，公开信息不足。
第三，泛化差距需要逐场景验证。 26 个点对 11 个点的差距说明训练集提升不能外推。换任务域时应该重新测冻结后的表现。
第四，算力亲和的收益依赖昇腾栈。 上下文缓存调度的收益与基础设施强相关，在别的计算平台上能复现多少需要实测。
结语
这个框架最值得借鉴的不是它的搜索算法——那部分公开信息有限。真正有价值的是问题拆解：
把「让智能体越干越好」拆成「改工作方法」和「改交付物」两条独立轨道；给每条轨道配上版本化的优化对象；规定每一次采纳都必须有可验证的执行证据；把未采纳的原因也记录下来。
这四条里没有一条依赖特定的模型或算力，任何在搭建自我改进流程的团队都可以直接移植。至于它报告的提升幅度，读法是：看冻结后的独立评测数字，而不是训练集上的数字。