先说清楚这次发布的是什么
据公开报道，由华为 2012 实验室、华为云、终端、计算等团队联合构建的开源 AI Agent 平台 openJiuwen，发布了完整的 RSI（Recursive Self-Improvement，递归自我改进）框架，并在其办公场景产品 WorkSwarm 蜂群办公智能体上落地。官方称，该框架支持「可插拔的 Harness + Artifacts」双维度优化，其中 Artifact 当前包含科研论文与算法程序两类交付产物。RSI 实验模式已在 WorkSwarm 上线。截至目前，该框架在更多任务类型上的泛化效果、长期运行的成本曲线以及社区贡献路线图，官方及行业暂未披露更多细节，后续将持续跟进迭代动态。
需要先澄清一个容易误读的点：RSI 在这里并不是「让模型自己训练自己」。它的定义更窄也更工程化——让智能体从真实任务的反馈中生成改进方案、执行验证、保留有效改进。改进的对象是智能体的「工作装备」与「交付产物」，而不是模型权重。
「交付即定型」为什么会成为瓶颈
官方对现状的描述相当直接：让智能体干完一件事并不难，难的是让它越干越好。长期以来，多数办公智能体是「交付即定型」——一旦任务失败或未达预期，需要人工复盘日志、修改提示词、补充工具，再重新测试。这个循环有三个成本：调优周期长、有效经验难以积累、失败经验无法复用。
这个描述其实指向一个行业共识：智能体的能力上限不只由模型决定，还由模型之外的「装备」决定。Prompt 决定如何理解任务，Skill 提供专业方法，Tool 负责实际操作，Rail 约束执行过程。当问题出在这些环节时，仅靠换一个更强的模型往往解决不了，因为模型本身并没有错。
四层结构：把「优化」拆成可分工的活
据公开介绍，openJiuwen RSI 的核心不是一套固定的优化算法，而是一个让不同自我迭代任务都能稳定运行的工程框架。它以版本化优化对象、可验证的执行证据、可扩展的算法为三根支柱，通过四层协作把任务目标转化为可执行、可评估的改进过程。
任务层定义「优化什么、如何评价、能用多少资源」；迭代优化层决定「下一步试什么、哪些改进可以采纳」；执行层负责「真正跑起来并返回证据」；基础框架层提供运行、模型与上下文、沙箱隔离、状态恢复和可观测性等统一能力。
这套分工里最值得关注的是可靠性设计。据官方说明，AgentLoop 负责单次任务的「推理—行动—观察—反馈」，控制器负责跨版本优化，两者分开，目的是避免「用生成者的主观判断代替验证」。每份证据都绑定版本和评价上下文；候选经过过滤、融合或配置变更后必须重新测试；执行失败、证据无效、效果不佳会被分别记录。问题、假设、改进点以及采纳或未采纳的原因都会保留，让下一轮既能借鉴成功，也能避开无效方向。这一点比「让 AI 自我反思」的口号更实在——它把反思变成了带证据链的工程流程。
六阶段闭环：从基线到归档
整个流程串起六个阶段：评测与验证建立基线；分析与优化定位从失败、轨迹和指标中找原因；提案与构建生成候选并按同一标准重新评测；采纳与融合消解冲突、组合有效改进、形成新版本；RSI 经验沉淀提炼方法及适用条件；归档与停止保存结果并判断是否结束。只要还有预算和改进空间，系统就会选择父版本继续迭代。
在统一的任务表达、阶段接口与生命周期之下，不同优化对象可以采用各自的算法。科研论文优化接收研究目标、初稿或实验材料及评价标准，通过 Frontier 选择父版本，提出研究方案并构建包含研究内容和实验结果的论文，再经论文评测决定是否采纳；科研算法程序优化接收程序文件树、任务数据与标准，通过 PUCT 选择父版本并安排搜索，生成源码修改或修复方案，候选构建运行后以脚本评测、规则匹配和指标聚合比较效果；Harness 优化则先运行当前版本，依据任务结果与轨迹诊断，再装载候选重跑同一组任务。
Harness 优化：四步把失败案例变成可安装能力
三类轨道中，Harness 优化与开发者关系最直接，官方给出的操作路径是四步。
构建优化数据。准备一份 JSON 评测集，每条用例包含用例标识、任务要求、评测方式，以及参考答案和评分规则。官方建议优先选择真实失败过的任务，因为失败案例最能暴露装备的短板。
创建实验。在 WorkSwarm 的「实验」页面选择 Harness 优化，填写实验名称，选择优化模型、测试模型和初始插件，再选择评测集、评测方式与最大迭代轮次。
自动迭代。系统先运行当前 Harness 建立基线，再从失败用例和执行轨迹中定位问题，围绕 Prompt、Skill、Tool 和 Rail 生成候选修改。候选先在目标用例上验证是否修好，再回放完整评测集确认整体有提升、没有改坏原本通过的任务。页面持续展示得分、迭代轮次、模型用量与搜索树。
安装使用。实验产出有效版本后，点击「安装插件」即可把最优 Harness 作为插件包导入并热加载，版本信息保留，需要时可以回退。
官方公布的效果数据是：在 DeepSeek-V4-Flash 作为任务模型、最多 5 个 Epoch 的配置下，Harness 优化在 SWE-bench Lite Dev 全部 23 道题上的通过率由 61.0% 提升至 87.0%；冻结优化后的 Harness 后，在 Evo-Bench General 64 道独立评测题上的单次执行通过率由 60.9% 提升至 71.9%。官方据此认为，优化收益不仅覆盖参与迭代的任务，也能泛化到未参与优化的任务。
这两组数字需要分开读。一组（61%→87%）是在参与优化的同一批题上取得的，属于「训练集内」表现；另一组（60.9%→71.9%）是在独立评测集上取得的，才反映泛化能力。泛化提升约 11 个百分点，幅度不小但明显低于训练集内的 26 个百分点——这个差距本身说明，优化仍然存在一定程度的「针对特定任务过拟合」风险。
算力亲和：把多轮优化的成本压下来
RSI 的本质被官方概括为「拿算力换智力」：反复生成候选、执行任务、评测结果，一次完整实验动辄成千上万次模型调用；优化过程中，提示词、工具描述和任务材料会反复使用，工具调用、评测与重试又带来频繁的暂停与恢复。如果每轮都重新计算相似上下文，优化规模越大，等待和资源开销就越高。
openJiuwen 的应对是算力亲和，依托昇腾算力基础设施，让推理引擎读懂智能体的任务状态。框架通过 Agent Hint 把任务运行、等待、恢复和结束等信息传给引擎，帮助引擎在昇腾 NPU 显存、鲲鹏 CPU 内存和远端缓存池之间主动调度上下文缓存（KV Cache）：等待时卸载到低成本存储，恢复前提前预取，结束后及时释放。
官方在科研算法程序优化实验中给出的数据是：开启算力亲和后，首 Token 时延（TTFT）均值下降 15.83%、P90 下降 19.16%；Token 加权 KV Cache 命中率由 7.53% 提升至 14.36%；HBM 与 DDR 峰值使用率分别下降 22.82% 与 30.74%。这些指标的改善方向是合理的：减少重复 Prefill，首 Token 更快，显存与内存压力也更低。不过 14.36% 的命中率绝对值仍然不高，说明上下文复用还有较大优化空间。
中立思辨
需要辩证看待这套框架。其一，评测集由用户自建，这既是灵活性也是风险。如果评测用例设计得过于贴近已知失败案例，优化会「应试化」，泛化能力被高估；官方公布的 61%→87% 与 60.9%→71.9% 之间的落差，正是这一风险的量化体现。其二，Harness 优化的收益依赖评测质量，而写好一份带评分规则的评测集本身就是专业工作，普通用户的上手门槛并不低。其三，RSI 目前明确落地的是论文与算法程序两类 Artifacts，以及 Harness 这一维度，模型权重优化与混合优化标注为暂不支持，能力边界需要如实认知。其四，算力亲和深度绑定昇腾与鲲鹏，对非该体系的用户而言，这部分收益能否兑现需要单独验证。其五，openJiuwen 此前已有分布式蜂群架构与鸿蒙 PC 版蜂群智能体的积累，RSI 是在同一平台上的延续，而非全新项目，评估时应放在这条产品线里看。其六，「越干越好」的效果需要时间验证，官方数据来自受控实验，真实办公场景的任务分布更杂、评价标准更模糊，效果可能打折。
趋势研判
短期，智能体的竞争力会从「单次任务能不能做完」转向「同类任务能不能稳定做好」，围绕 Harness 与评测集的工程实践会快速增加；中期，评测集与优化经验的资产化可能成为企业的新壁垒——谁的失败案例库更厚、评分规则更准，谁的智能体迭代更快；长期，如果 RSI 这类框架走向成熟，智能体的交付形态可能从「一次性项目」变成「可持续优化的服务」，运营团队的角色会从「改提示词」变成「设计评价标准」。
对团队来说，一个务实的起步方式不是马上接入框架，而是先把自己业务里反复失败的任务整理成带评分规则的评测集。这份评测集无论用不用 RSI，都是衡量智能体是否真的在进步的基础。