从脚手架到自我改进系统：RSI 的现实路径是让模型改进 Harness，而不是改写权重

开场：递归自我改进不需要从改写权重开始

Harness 不只是包裹模型的外壳。它正在成为 AI 递归自我改进的核心引擎。

一句话速览：递归自我改进（RSI）的历史与近期路径：模型改进 Harness，不直接改写权重。

Recursive Self-Improvement：一个系统，能用自己当前的智能去改善产生智能的机制本身。

内容来源：本篇框架、概念与案例源自 Lilian Weng 于 2026 年 7 月发表的长文《Harness Engineering for Self-Improvement》。她多年来在 AI 安全与 Agent 前沿领域持续输出，博客是行业公认必读。强烈建议读完本文后回去读原文。

一、RSI 的演进：从理论设想到 Harness 路径

时间	里程碑
1965 · Good	「Ultra-intelligent machine」：能设计更好机器的机器。理论设想。
2008 · Yudkowsky	正式提出「Recursive Self-Improvement」：AI 用自身智能改进产生智能的认知机制。
2023–2024	Self-play、合成数据、Test-time training 等早期尝试。模型开始改善自己的训练数据。
2025–2026	Harness 工程成为 RSI 的核心路径：模型不直接改写权重，它改进的是围绕自身的部署系统、工作流和上下文管理。

二、什么是 Harness：模型周围的一切编排系统

Harness = 模型周围的一切编排系统。 它是围绕基座模型的运行时系统，决定模型如何：

思考与规划
调用工具与行动
感知与管理上下文
存储制品
评估结果

成功的 AI 产品（如 Claude Code、Codex、Cursor）已经证明：Harness 层与原始模型智能同等重要。一个平庸的模型加上优秀的 Harness，往往胜过裸露的更强模型。

三、为什么 Harness 是近期 RSI 的实际路径？

近期 RSI 的三步预测

模型不会直接改写自己的权重，但它能改进训练管线和部署系统，使下一代模型更强。
Harness 工程走向元方法论： 改善的对象从答案本身，变成得到更好答案的机制。Harness 本身成为优化目标。
成熟 Harness + 智能模型 = 正反馈循环： 更好的 Harness 催生更强模型，更强模型又让 Harness 不必过度工程化。

与 Prompt Engineering 的类比

我们已经见过更软的版本：随着指令微调和推理能力提升，手动 Prompt 技巧变得不那么核心了，但指定目标、约束、上下文和评估的需求并没有消失。

同理，最终很多 Harness 改进会被内化为模型行为，但与外部上下文和工具的接口将永远存在。

核心观点： 递归自我改进不需要从模型直接修改权重开始。更现实的路径是让模型改进围绕它的 Harness 系统（上下文管理、工作流、工具编排、评估），形成持续改进的飞轮。这就是 Harness Engineering for Self-Improvement 的核心论点。

四、Harness 的三大设计模式

好的 Harness 有清晰的模式语言，绝非一堆脚本拼起来。三个核心模式，覆盖了当前最强 Agent 系统 90% 的架构决策：工作流自动化 / 文件系统持久记忆 / 子 Agent 与后台任务。它们不是可选优化，它们是任何生产级 Agent 的结构性需求。

Pattern 1：Workflow Automation 工作流自动化

核心思想：Agent 是一个目标导向的循环，不能当成执行一次就结束的脚本。

Plan → Execute → Observe/Test → Improve → Execute again：每一轮生成都是下一轮优化的起点。

分析自身轨迹： 优秀的 Agent 会回头看自己前几轮做了什么、哪里失败了、为什么失败，然后调整策略，避免重复同一个 Prompt。
强调运行时迭代： 改进发生在 Agent 执行过程中，不依赖人类事先写好的静态模板。
失败是信号，不是终止： 测试不通过、命令报错、输出不符合预期，这些都是 Agent 自我纠正的触发条件。

设计启示： 不要把 Agent 设计成一次性回答器。让它拥有自己审查自己的能力：看到测试失败后自动分析原因、看到 linter 报错后自动修复、看到用户反馈后调整策略。这就是工作流自动化的核心：把反馈循环内置到系统里。

Pattern 2：File System as Persistent Memory 文件系统做持久记忆

核心问题：在长期运行的 Agent 中，制品会迅速超出上下文窗口。

制品种类繁多： 实验日志、代码 diff、论文摘要、错误追踪记录、过去的完整执行轨迹，这些都是有价值的状态，但塞不进上下文。
Harness 的正确做法： 把持久状态存在文件系统中，让 Agent 学会按需读写。不要试图把全部工作历史压入 Prompt。
文件读写是 LLM 基础技能： 读写文件系统不需要复杂的外部工具链，它受益于核心模型能力的提升。模型越聪明，文件管理越高效。
结构化存储： 好的 Agent 会自己维护 scratchpad、todo 列表、实验记录，像人类程序员一样管理工作区。

上下文 vs 文件：何时放哪里？

放上下文中： 当前正在处理的任务指令、即时的工具调用结果、最近 2-3 轮对话——需要即时参考的信息。
放文件系统中： 历史实验结果、累积的错误日志、已完成子任务的摘要、长期策略和规则——需要持久保存但不必时刻在视野中的信息。

关键原则：上下文是工作记忆，文件系统是长期记忆。 好的 Harness 像人脑一样，在两者之间智能地搬运信息。

Pattern 3：Sub-agent and Backend Jobs 子 Agent 与后台任务

核心思想：一个 Agent 不够用时，生成多个子 Agent 并行执行，同时监控后台长任务。

父 Agent 作为进程管理器： 启动子任务、检查日志和进度、取消失败的分支、合并成功的结果。这是操作系统层面的思维。
并行性必须显式且可检查： 不能「发射后不管」。父 Agent 需要能查看每个子 Agent 的状态、输出和错误。
子 Agent 输出持久化： 每个子 Agent 的结果存为文件、日志或状态记录（而不仅是返回到父 Agent 的上下文中），这样即使中断也能恢复。
容错与恢复： 后台任务可能超时、崩溃或产出低质量结果。Harness 需要设计重试策略和优雅降级机制。

关键设计决策： 子 Agent 模式的核心取舍是并行带来速度，但也带来复杂性。成功的实现（如 Cursor 的 Task 系统、Claude Code 的子进程）都遵循同一原则：让每个子 Agent 在独立的沙箱中工作，输出到明确的文件路径，父 Agent 通过轮询文件状态来协调，不做内存共享。 这极大简化了并发控制。

五、三大模式如何协同：三层叠加，无需三选一

工作流自动化提供了执行的脊椎： 循环结构和反馈机制。
文件系统记忆为循环提供了硬盘： 让每轮迭代的成果不会丢失，即使上下文被清空。
子 Agent 并行为循环提供了多核： 当任务可分解时，用并行加速取代串行等待。

三者组合，一个 Agent 就具备了迭代优化 × 长期记忆 × 并行扩展的能力。这正是当前最强编码 Agent 的共同架构。

六、Case Study：编码 Agent 的 Harness

主流编码 Agent（Claude Code、Codex、OpenCode、Cursor）都围绕相似的工具集构建 Harness。按功能分组对比它们的核心接口：

工具分组	核心能力	典型工具
File System	读、写、搜索、编辑文件；管理工作区状态	Read, Write, Edit, Glob, Grep, StrReplace
Shell Execution	执行终端命令、运行测试、安装依赖	Shell, BashExec, RunCommand
I/O	与用户交互、确认操作、展示结果	Ask, UserConfirm, ShowResult
External Context	获取外部信息、文档、API 响应	WebFetch, ReadURL, DocSearch
Web Search	搜索互联网获取最新信息	WebSearch, BingSearch
Artifacts	生成、管理和版本化制品	CreateFile, SaveArtifact, VersionControl
Backend Processes	后台运行长任务、监控进程状态	BackgroundShell, AwaitProcess, Monitor
Agent Delegation	生成子 Agent、分配并行任务、合并结果	Task, Subagent, Fork, ParallelRun

结语

Harness 设计不是随机拼凑工具。它遵循三个结构性模式：目标导向的自动化循环（让 Agent 能自我纠错）、文件系统做长期记忆（突破上下文窗口限制）、子 Agent 做并行扩展（把串行瓶颈变成多线程）。

递归自我改进不需要从模型直接修改权重开始。更现实的路径是让模型改进围绕它的 Harness 系统——上下文管理、工作流、工具编排、评估——形成持续改进的飞轮。理解这三个模式，就掌握了构建生产级 Agent 系统的架构语言，也看清了 RSI 从理论走向工程的那条最现实的路。