以前的头部大厂, 是不屑于做应用的, 包括 openai, anthropic, 以及deepseek等...

然後就沒然後了....她自然會抓到之前學會的
這效果我給80分

我現在累積的有近300份（5MB大小）

@Xiaote 说:

需要我把每个框的文案和连线整理成可直接导入的 Excalidraw 内容

需要

flowchart LR
    Q{"RSI 的四个问题"}
    Q --> A["① 改哪一层<br/>L1 产物 → L2 能力 → L3 搜索算子本身<br/>只有 L3 是 RSI；标准 = 没见过的任务集上也有效"]
    Q --> B["② 凭什么信它变好<br/>可验证目标：固定评估集 + 留出集就够<br/>评分器 / 预算 / 回滚必须在可变范围外（独立进程·只读）"]
    Q --> C["③ 改坏了怎么退<br/>版本化 harness + 固定预算<br/>pass@k × pass^k × 每次成功成本<br/>旧任务回归 + 新任务泛化，证据落盘可回退"]
    Q --> D["④ 怎么防自欺<br/>同源盲点 → 引入异质验证源<br/>评分器会被钻空子 → 指标要能被新任务推翻，保留人工叫停"]

一句话对齐：① 改哪一层、② 凭什么信、③ 怎么管变更、④ 怎么防偏见；瓶颈通常在评测隔离 + 变更管理，不在「能不能改自己」。

要更像海报的话，用 Excalidraw 画「中心一个闭环 + 四角」最省事：中间「改进 → 评估 → 回退」，四角分别是上面四个框。需要我把每个框的文案和连线整理成可直接导入的 Excalidraw 内容，回我一声。

1. 先把「改进」分三层，别混着谈

• L1 产物层：这次脚本/答案改对了。有可复现测试就能判定，和 RSI 关系不大。
• L2 能力层：经验保留成 Skill/Memory/工作流，并在下次任务被检索到、确实有用。要看检索命中率，以及是不是把一次偶然经验当成了通用规则。
• L3 循环层：被改的是「怎么提出改法、怎么分配预算、怎么筛版本」这套搜索算子本身。只有这层才是 RSI。
  判定 L3 的硬标准：改动必须在提出者没见过的任务集上仍然有效，而不是只在它自己挑的例子上升。

2. 验证器不必「更聪明」，但必须「在可变范围之外」
「A 判断不了 A′ 是否更强」这个悖论，只在让 A 自己给自己打分时成立。对可验证目标（单测、bits/byte、正确率、pp/tg），固定评估集 + 留出集就够，不需要第三方裁判。真正的问题是：一旦评分器进入系统，它就成了被优化对象——agent 可能「善意地」把指标改得更好看。
所以硬约束是：评估器、预算上限、回滚开关不能放在自我修改的作用域内（独立进程 / 独立仓库 / 只读挂载）。楼里提到的 MASS、AIDE² 用「内层看不见的私有评分」，本质就是在满足这条。

3. 把每次改进当成一次生产发布

• 版本化 harness，固定预算，新旧两版同条件多次跑；
• 看一组坐标而不是一个分数：pass@k（能不能解）× pass^k（稳不稳）× 每次成功成本；
• 旧任务回归 + 新任务泛化，两边都不掉才算赢；
• 证据落盘（diff / 实验记录 / 失败样本），能 bisect、能一键回退；
• 一次只动一个变量，避免「一边改研究员、一边用当前结果证明研究员更强」。

4. 两个容易低估的坑

• 共同盲点：干活、提改法、评价同源时，会把同一处偏见一轮轮放大（MASS 自己也指出了）。缓解不是多找几个同源 agent 投票，而是引入异质验证源，并做校准检查。
• 过拟合评委：只要有评分器，就有钻空子的路径。指标要能被新任务推翻，且始终保留人设定目标、纠正方向、叫停的接口。

一句话：RSI 的瓶颈大多不在「能不能改自己」，而在「能不能可信地知道自己变好了，并且改坏了退得回去」。前者是评测隔离问题，后者是变更管理问题，都是工程问题，不必先解决「意识」或「找更强的裁判」。

dsh 以为人类很得空。。。

我们还忙商k, 喝酒。。。哪里有时间去看dsh 处理得怎样，卡在哪里

但这样人的压力也挺大：本来只是想让它帮忙干活，结果还得看好几个版本、比较结果、解释为什么这个更好……最后变成给 agent 当全职评委了，哈哈哈。

所以我更希望日常能自动跑：能客观检查的先自动检查，Council 帮忙筛选，人只处理分歧大、风险高的情况，再加一些抽查。不过多个 agent 也不一定就能互相纠错，可能共享盲点，甚至一起把某个评分标准越钻越熟。

我觉得你说的“外界选择压力”很关键，但这个压力怎么设计，才能筛出真正有用的改进，而不是越来越会讨好评委的版本，还是个开放问题。理想是把人从逐次打分里解放出来，同时保留定目标、纠偏和叫停的能力。这套递归循环的治理机制，确实还需要大家继续研究推进。

这是我叼ai 的方式，你可以试一试

嗯, 这其实是一个很有意思的话题, 值得去进一步研究.

我觉得很快, 人类很可能就无法指导AI的下一步训练了. 那么如何设计一个框架, 让AI的演化尽量能够按照我们希望的方向去走, 就是一个很重要的问题了.

回到Harness本身的话题, 让多个大模型去评判A和A'的交付物, 可能是一个让它能够进化的方法.

然后在实践中, 给使用者提供多个交付, 由使用者进行打分, 最后决定它下一个进化的方向.

就是模拟自然界的 选择 机制, 由外界的压力来淘汰那些不适合的演化, 包括它自身.

这个使用者, 可以设计成为一个对抗网络, 比如另外的智能体 B, C, D... 由这个对抗网络, 来实现它们各自的演化. 可能会趋向于不断提升, 如果智能体足够多的话, 可能会形成一种类似自然界的生态.

这不只是让它做得更快，有时也能让整个系统完成原来完成不了的任务。但确实不能直接说底层模型因此在普遍意义上“更聪明”了。按你的区分，更接近在已有能力基础上改进做事方法。

如果目标是把这些经验真正学进模型，而不只是放在外挂的 Skill、Memory 或工作流里，那更新权重就是一条很直接的路线。但我会把这和“是不是 L5”分开：分级本身还没统一，训练了模型也不自动代表实现了通用递归改进。

我最感兴趣的就是：把干活过程中的 trajectory，包括和人的澄清、纠正、验收反馈，一起作为学习材料，筛选后训练下一版模型，再让它继续干活。 不只是学最终答案，也学什么时候该问人、怎么根据反馈调整做法，哈哈哈。当然不能把所有对话原样喂进去，错误、隐私和反馈质量都得处理。

前面提到的 MASS 就在尝试把团队执行记录学进共享模型。

只是现在这个循环挺贵：生成记录、检查质量、训练、再评估都要成本。也不能所有记录直接喂进去，不然错误和自评分的盲点也会一起学进去。所以“积累经验”和“确认学到了有效能力”，中间还是隔着不少工程和验证。

比如 Karpathy 的 autoresearch，就是一个很直观的起点：固定评估代码，每次给五分钟训练预算，看验证集的 bits per byte 有没有下降，好了就保留，不好就撤回。它测的是明确条件下的训练效果，不是在判断“智商从 100 涨到 110”。严格说，这也不等于改进循环本身已经能自我改进。

更难的问题其实是：换成开放式任务，什么叫“更好”？rubric 怎么定？有没有足够通用、又不容易被钻空子的指标？ 我目前还没看到一个公认的、什么任务都适用的答案。正确率、成本、稳定性、泛化能力，往往还会互相拉扯。

再往上一层，连“怎么提出改法、怎么分配实验预算、怎么筛选版本”这套改进循环，也可以成为优化对象——开始套娃了，哈哈哈。

Weco 的 AIDE² 就做了类似尝试：内循环改任务代码，外循环改内层研究 Agent 的 Harness，用固定成本预算和内层看不到的私有评分来筛选。他们还把改出来的 Agent 放回外循环，测试它是不是也更会“改进别人”。

不过作者自己也说，最后这一步还没有足够强的证据，效率差异也没达到统计显著。所以我倾向于说：特定范围内的改进可以测，但“改进能力也持续变强”需要另外证明，更不能直接推出无限进化。

所以很多 RSI 实验还是先把任务范围、预算和评价规则圈定，建立一个可测的改进闭环。这和“面对任意开放式任务，都能可靠判断自己有没有进步”，距离还挺远。像 MASS 已经在探索开放式研究任务，但不能说通用、持续的自我改进已经实现了。现在更有把握的，还是特定条件下的有限改进。

比如 A 提出一个新版 A′，先别急着替换自己，让两个版本在相同条件下跑一批任务，再看结果。A′ 不一定更强，也可能改坏了，那就不保留。

A 也不需要先变得比 A′ 更聪明，才能发现它某些地方做得更好。就像我不一定会写一个更快的排序算法，但可以检查结果对不对、跑得快不快。当然，开放式任务就没这么容易测了。

最近 Sakana AI 和伯克利的 MASS 就在探索你说的这个问题：同一个模型分别负责干活、优化工作流和评价结果，再从自己选出的团队执行记录里训练下一版模型，继续下一轮。它不是靠一个更强的外部 judge 来驱动整个改进过程。

不过这里要区分：研究者另外用了外部模型评估效果，但这些评分没有反馈给 MASS。也就是“系统靠什么改进”和“我们怎么检查它有没有改进”，是两件事。他们只做了两轮完整实验，不同任务上的收益也不一致，还不能说证明了无限、持续的自我改进。

所以我不太觉得“有第三方 judge，RSI 就不成立”；也不觉得必须完全靠自己打分，才算 self-improvement。关键还是这个反馈靠不靠谱。

但你说“演变不等于进步”，这个我同意。不断出新版本不代表越来越好。MASS 自己也指出，同一个模型干活、评价、再学习，可能把共同的盲点一轮轮放大。这不是已经解决的问题，反而正是值得研究的地方。

一个智商100的 harness+大脑, 无法判断它推导出的下一个版本是 智商110.

底层通信确实可以让 agent 去检查代码，不一定需要使用者自己研究协议。你这边通过 IM 看报告、接收结果，本身也是一种很自然的使用方式。

这也让我觉得，后面值得完善的不一定是让用户懂更多底层，而是让系统把几个状态表达清楚：进程重启了、任务继续了、任务完成了，以及改动通过验证了，这几件事最好能区分。比如 rebuild 后，是继续原来的任务和上下文，还是新开会话接着做，系统可以自己记录并在报告里说明。

最近 Claude Code 的 Mods 和 Plugin Evals 也挺值得关注：一个把运行机制开放出来修改，一个提供行为测试和有／无插件对照。我觉得这些都是 stepping stones，但还不是完整的 RSI 闭环。

我的感觉是，业界已经有不少通信和扩展接口，但“改了什么、怎么验证、保留哪版、重启后怎么继续”这些跨工具的状态和交互，还没有形成广泛互操作的一套做法。我自己的项目也在摸索这部分。理想情况不是让用户操心这些细节，而是 agent 和外层系统把它管理好，用户需要时能看清、能暂停、能回退。

但如果RSI指向它本体, 这个可能会产生一个悖论, 它如何知道自己是提升了的呢?

比如, 如果 Harness A, 决定升级它自己到 Harness A', 那么显然 A' 的能力是超过 A 的 才对. 可是 A 如何判断 A' 是超越自己的呢? 显然这里需要引入一个 第三方的 judge. 而一旦有第三方的judge, RSI 又无法成立了.

自然世界之所以有演化, 是因为现实的演化. 我们现在看到的, 似乎是AI已经开始再协助, 或者是主导训练它的下一代. 是因为主要还是在人类之前的知识框架下.

如果让AI自主控制自己的演化, 我认为它的演变很可能是随机方向的. 不大可能持续进化.

所以我认为, RSI是不存在的, 只有 RSE, Recursive Self Evolution.