我对 RSI（Recursive Self-Improvement，递归自我改进）有一个判断：通用长程能力，是 RSI 的先决条件。
AI 能修改自己的代码，并不是最难想象的部分。真正值得期待的是：这一轮工作，让它拥有更好的工具、更可靠的执行方式和更有效的经验；这些变化又参与下一轮工作，帮助它继续改善自己。
智能不只是被调用，而是开始形成复利。
这里讨论的是 Agent 系统对自身代码、工具和工作方式的持续改进，不是模型权重训练。它不必从一个完全无人参与的超级智能开始，也可以先出现在真实项目中：人定义方向、提供反馈和验收，Agent 持续参与改进自己的运行环境。
LoopX 正是我沿着这条路径做的实践。它既是我用来推进项目的长程 Agent meta-harness，也是 LoopX Agent 持续开发、验证和维护的对象。
为什么先决条件是“通用长程”？
“递归”意味着，下一轮改进建立在上一轮的结果上。
如果每一轮都要重新解释目标、重建环境、寻找上次的结论，那么系统可以反复产生改动，却很难积累能力。一次优秀的推理，未必能变成一个持续变好的系统。
长程能力的意义，是让目标、工作状态、验证结果和经验跨越上下文、会话、执行者以及系统版本。换一个 Agent，工作仍是同一份工作；重启一次环境，改进仍能成为下一轮的起点。
LoopX 期望的是大量能持续深入工作的长会话，让 Agent 有足够的时间研究、执行、验证和自我修正。外置状态用来支撑长会话，并在上下文压缩、中断或交接时保留目标、约束与成果，使已经推进的工作继续累积。
而“通用”同样重要。真实的自我改进不会只发生在一个固定题型里：今天可能是发现工具的缺陷，明天是改进研究方法，后天是调整协作方式，再后来要重新验证这些变化对整体产出的影响。系统需要把研究、实现、评估与采用连起来，而不是只让某个专用脚本重复跑分。
所以，我说的先决条件，不是“在线时间足够长”，而是：系统能持续推进开放的目标，并把已经取得的改进带入后续工作。
从“用 AI 做项目”，到“用改善后的系统继续改善系统”
模型提供智能，runtime 提供工具与执行环境，长程系统负责把一次次执行连接成持续的工作。
在这个结构里，自我改进的对象可以比模型权重更广：工具、上下文组织、工作流、验证机制、记忆，以及人与 Agent 的协作方式，都可能成为改进的空间。
Sakana AI 的 Darwin Gödel Machine已经展示过这条研究路径：让 Agent 修改自身代码，通过任务评估保留候选，再从已有候选继续探索。它使我更确信，系统层面的演进值得认真对待。
Anthropic 对长程 Agent harness 的研究则从另一个角度指出：有限上下文下，工作要依靠增量执行与可接续的材料跨会话延续。
我的理解是，这两件事最终会合到一起：自我改进负责产生变化，通用长程能力让变化得以累积。 前者提供新的台阶，后者让系统真正沿着台阶往上走。
LoopX 从早期就把自己作为一个长期任务
这段历史不应只从最近几周算起。
前期：goal-harness 的 meta 自举。 2026 年 5 月 31 日，公开仓库的第一个提交建立了 goal-harness 的小型控制面。到了 6 月 1 日，仓库便加入了一个 Goal Harness Meta Goal：把自己的项目作为目标，持续检查可运行性、工作接续与验证，再推进下一段改进。
这意味着，自举并不是项目成熟以后才添加的功能。它从很早就开始用自己管理自己的研发。随着系统暴露出新的问题，目标状态、后续工作和验证机制也在同一过程中生长。
到 6 月 19 日，公开仓库已有专门的仓库级自迭代案例。该案例采用的 6 月 20 日固定快照记录了 801 个提交，描述的不是单个功能，而是控制面、规划、验证、界面与多条研发线的并行推进。当时它甚至还没有正式改名为 LoopX。
中期：从自举工具，发展为通用长程系统。 6 月 21 日，goal-harness 更名为 LoopX。此后，工作从个人开发循环扩展到多 Agent、跨 runtime 和社区协作。7 月的 peer runtime 与 v0.2 控制面，把工作归属、执行边界与交接继续推进为产品契约。
这阶段最有意义的，不是多接入了几个模型，而是让不同执行者能够围绕同一份持久工作状态推进。负责实现、审阅与验证的角色可以不同，工作仍然需要被接住、被验收。
后期：从工程控制面，走向个人工作区与社区共同演进。 9 月 6 日，LoopX 1.0 发布 Personal Workspace。 状态内核之外，工作终于有了更完整的日常操作入口。人可以在工作区与 IM 参与目标、决策和结果；Agent 则继续参与底层系统、工具和产品表面的改进。这个阶段，系统自举与社区贡献交织，LoopX 已不再只是一个人的开发循环。
三段历史连起来，才是我更想讲的自迭代过程：先把自己作为长期目标，再把长程工作做成通用能力，最后让更多人和 Agent 在同一个产品上持续演进。
四个月的公开迭代节奏
我把同一份公开 Git 历史按上面的两个转折点分期，统一排除 merge commits：
| 阶段 | 时间范围 | 非合并提交 | 日均提交 | 00:00–08:00 提交 | 凌晨占比 |
|---|---|---|---|---|---|
| 前期 · meta 自举 | 5 月 31 日—6 月 20 日 | 739 | 35.2 | 298 | 40.3% |
| 中期 · 通用长程系统 | 6 月 21 日—9 月 5 日 | 3,870 | 50.3 | 1,399 | 36.1% |
| 后期 · 工作区与社区 | 9 月 6 日—10 月 1 日 | 2,239 | 86.1 | 556 | 24.8% |
整个公开历史快照共有 8,613 个提交，其中 6,848 个为非合并提交。上表三阶段合计就是这 6,848 个，统计时区统一为北京时间。
最近 14 个完整自然日（9 月 18 日—10 月 1 日），节奏达到日均 96.9 个非合并提交，总计 1,356 个，单日最高 144 个；凌晨 384 个，占 28.3%，14 天每天凌晨都有提交。
这些数据给我的启发，并不是“凌晨占比必须越来越高”。事实上，阶段占比在下降，而日均提交在增加。更值得观察的是：工作能否跨昼夜延续，改进是否进入下一轮环境，以及多人、多 Agent 的加入能否形成持续产出。
这里统计的是整个项目的开发活动，包含社区贡献，不是“全自动 RSI”的比例，也不是能力提升的计量。其价值是把持续演进的规模和时间分布变得可复核；自迭代的核心证据，仍是系统在真实工作中被使用、反馈、改进，再用于后续工作。
长程系统的价值，不只是“多跑一会儿”
LoopX 从外置目标与任务状态出发，逐渐把工作接续、授权、资源预算、验证和经验积累组织到同一个控制面，再通过 Personal Workspace 与 IM 让人参与其中。模型和 runtime 可以不同，但一份工作的目标、约束和验收依据需要延续。公开架构与产品入口。
我最在意的是三个能力：
目标延续。 局部任务做完，不意味着整体目标达成。系统需要根据验收结果重新规划，让工作继续向真正的目标推进。
反馈累积。 用户的纠正、有效的改进和失败的尝试，不只存在于某一次聊天里，而要改变后续执行所处的环境。
改进接续。 研究结论不能停在文档里，代码修改不能停在分支里。它们需要被验证、采用，并继续接受真实工作的检验。
这三者连起来，才有机会把更多时间、更多算力和更多并行 Agent，转化成逐渐积累的能力，而不是更多彼此独立的输出。
我把 LoopX 在真实工程里形成的、人在回路的自举过程，视为早期的系统级 RSI。它的意义不是给普通开发换一个名字，而是让“执行工作的系统”也成为持续改进的对象，并用改善后的系统推进下一轮改进。
人在回路，不是递归性的反面
我并不认为早期 RSI 必须从完全排除人类开始。
高质量的 human reward 可以帮助系统识别什么值得做、什么真的有效。人提供方向和关键判断，系统承担持续执行与接续；人的反馈不必变成下一次从头解释，而可以成为环境、工作状态和验证要求的一部分。
递归性取决于：改进后的系统，是否参与了后续改进。 它不取决于每一轮有没有人说话。
与此同时，候选改动不能靠放松自己的评价标准来获得“成功”。真实采用、独立验证和可回滚的工作阶段，是这个反馈环能够积累价值的基础。
我想把它推进到哪里？
模型越来越强，token 越来越便宜，个人能够组织的 Agent 数量也会越来越多。
接下来值得探索的，不只是让 Agent 完成更多任务，而是让一个数字团队在长期工作中逐渐形成自己的方法：更好的工具、更有效的协作、更扎实的验证，以及能被后续工作真正使用的经验。
单次智能解决一个问题，长程智能积累解决问题的能力。
这也是我对 LoopX 的期待：一个人定义目标、提供关键判断，数字团队持续推进；它不仅完成工作，也在工作中改善完成工作的系统。
最大化 Agent 的有效产出，最小化人的注意力投入。通用长程能力是这条路的地基，也是我认为 RSI 绕不过去的先决条件。
数据与进一步阅读
统计固定于 main 在北京时间 2026 年 10 月 1 日结束前的最后一个主线提交 b9b758c。按 Git committer timestamp 划分自然日，时区为 Asia/Shanghai；凌晨定义为 00:00（含）至 08:00（不含）。统计该快照可达的全部提交，主指标排除多父提交（merge commits）；三阶段按首个公开提交、更名为 LoopX、1.0 工作区发布划分；日均分母分别为 21、77、26 个自然日（第一天为不足一日的公开起点）。全历史另有 1,765 个 merge commits，不混入 6,848 的主指标。提交对象不是独立功能或验收结果，时间戳也不识别作者是否使用 AI。
公开采用与后续修正的例子，见 RSI-Harness 采用审计、PR #4984 与 后续修正 #5119。它们用于查看改进如何进入实际路径；细节不作为本文的主叙事。
项目：LoopX。
下载分期统计与口径（JSON） · 按日期分期，不按事件当天的具体时刻分割。
在完整 Git 克隆中复核
git rev-list --count b9b758ca4dfc30d0d610b45398fc31acd62781f6
git rev-list --count --no-merges b9b758ca4dfc30d0d610b45398fc31acd62781f6
TZ=Asia/Shanghai git log --no-merges b9b758ca4dfc30d0d610b45398fc31acd62781f6 \
--format='%cI' # committer timestamps; group by the stated calendar intervals