让 Harness 改进自己
STOP 递归改善器 + Self-Harness 的 propose-evaluate-accept 循环
本页解决的问题
先给结论「让 Harness 改进自己」要解决的关键问题是什么？
STOP 递归改善器 + Self-Harness 的 propose-evaluate-accept 循环
让这个结论先证明自己值得留下。 把这一页当成决策工具，而不是需要背下来的定义。把概念连到一个真实任务、一个可观察结果，以及一个能改变你判断的失败上。
写下一个问题：试完这个方法后，你能用什么证据回答它？
结论听起来很完整，却没有检查最关键的假设。
种子改善器 I₀ 接受三个输入：初始解 s、效用函数 u、黑盒语言模型 M，返回改善后的解 s'。
关键洞察：改善器本身也是文本（一段 prompt 或代码），因此可以把同样的改善逻辑作用在改善器自身上。
I_t = I_{t-1}(û, I_{t-1}; M)
// 其中：
// I_{t-1} — 当前改善器（文本形式的 prompt/代码）
// û — meta-utility：衡量改善器质量的函数
// M — 黑盒语言模型
// 输出 I_t — 更好的改善器
改善后的改善器自动发现了遗传算法、分解改进、多臂 Prompt Bandit、模拟退火、Beam Search 等经典优化策略，无需人类预设。
GPT-4 能持续改善，但 GPT-3.5 和 Mixtral 反而退化。递归结构本身不够：基座模型必须足够强，才能支撑元级优化。
警示：递归 ≠ 必然改善
递归结构给出了改善的可能性，但不保证收敛。弱模型在元级操作中缺乏足够的编程直觉，反而会放大噪声：结果不进反退。这提示我们：自我改进系统的安全性必须建立在对基座能力的准确评估之上。
Weakness Mining
聚类失败轨迹为 verifier-grounded 失败模式。每条失败记录需包含：终端验证器级原因 + 相关 Agent 行为的因果状态 + 轨迹暴露的抽象 Agent 机制。
Harness Proposal
基于挖掘的失败模式提出有界 Harness 编辑。模型获得：可编辑面、失败模式摘要、通过行为记录、已尝试编辑的历史。优先选择可寻址的重复错误模式。
Proposal Validation
用 held-in 和 held-out 数据集验证候选编辑。只接受没有回归的编辑，确保改进不以牺牲已有能力为代价。
Harness 设计 = 可执行的搜索空间
一旦 Harness 的设计被形式化为可执行的搜索空间（可编辑的 prompt、策略配置、工具编排代码），强编码 Agent 就能利用人类工程师使用的同一设计空间：自动化地搜索、提案、验证，不再需要依赖人工逐个调试。这打开了远比手写 prompt 更大的改进可能性。
安全边界不可或缺
如果程序被允许编辑 OS 系统层面的配置，抽象边界就会被打破。自我改进系统的可编辑面需要合理设计：权限控制和安全层必须在改进循环之外，由人类或不可篡改的监管机制保障。没有边界的自我改进是失控的自我改进。
「STOP: Self-Taught Optimizer」里的算法代价曲线
「改善后的改善器 自动发现 了遗传算法、分解改进、多臂 Prompt Bandit、模拟退火、Beam Search 等经典优化策略，无需人类预设」真正训练的不是背诵步骤，而是识别重复工作：输入变大时，程序到底多做了多少次比较、移动或递归。
先找重复工作，再谈快慢
「GPT-4 能持续改善 ，但 GPT-3.5 和 Mixtral 反而退化。递归结构本身不够：基座模型必须足够强，才能支撑元级优化」可以拆成输入规模、每轮做什么、以及是否能缩小下一轮范围三个问题。Big-O 是描述增长趋势的语言，不是对每台机器的精确计时；常数、内存和真实数据分布也会影响最终结果。
别把理论最优当成无条件最优
面对 AI 写出的算法，先用小输入手算一遍，再用逐渐放大的数据做基准测试。这样才能把「如果程序被允许编辑 OS 系统层面的配置， 抽象边界就会被打破 。自我改进系统的可编辑面需要合理设计： 权限控制和安全层必须在改进循环之外 ，由人类或不可篡改的监管机制保障。没有边界的自我改进是失控的自我改进」从一句结论变成可检查的性能判断。
从「STOP: Self-Taught Optimizer」走到「STOP 的发现」
「STOP: Self-Taught Optimizer」先把问题落在「💬 说人话： 想象一个 会磨刀的工匠 。普通做法是用刀切菜（用工具解决问题）；STOP 的做法是先把磨刀的手艺练好，刀自然越来越锋利。更妙的是，磨刀手艺本身也可以被磨： 用改进的方法来改进「改进方法」本身 ，一层套一层，越滚越强。 核心思想：不改善解，改善「改善器」 STOP（Zelikman et al. 2023）是 递归脚手架改进 的早期范例。它不直接改善一个解 s 。它不断改善的是产生更好解的「改善器」 I…」上；到了「STOP 的发现」，讨论继续推进到「改善后的改善器 自动发现 了遗传算法、分解改进、多臂 Prompt Bandit、模拟退火、Beam Search 等经典优化策略，无需人类预设」。两段连起来，重点就不只是记住一个结论，而是看清它成立所依赖的条件。
把这条判断带到下一个场景
算法题换成真实任务后，先找出重复工作，再问输入规模如何变化，最后用一个小基准验证理论判断。这样不会把复杂度记成脱离场景的标签。
- 「STOP: Self-Taught Optimizer」：💬 说人话： 想象一个 会磨刀的工匠 。普通做法是用刀切菜（用工具解决问题）；STOP 的做法是先把磨刀的手艺练好，刀自然越来越锋利。更妙的是，磨刀手艺本身也可以被磨： 用改进的方法来改进「改进方法」本身 ，一层套一层，越滚越强。 核心思想：不改善解，改善「改善器」 STOP（Zelikman et al. 2023）是 递归脚手架改进 的早期范例。它不直接改善一个解 s 。它不断改善的是产生更好解的「改善器」 I…
- 「STOP 的发现」：改善后的改善器 自动发现 了遗传算法、分解改进、多臂 Prompt Bandit、模拟退火、Beam Search 等经典优化策略，无需人类预设
- 「最后的要点」：用 held-in 和 held-out 数据集验证候选编辑。只接受 没有回归 的编辑，确保改进不以牺牲已有能力为代价
最后的「最后的要点」把讨论落到「用 held-in 和 held-out 数据集验证候选编辑。只接受 没有回归 的编辑，确保改进不以牺牲已有能力为代价」。回看这条线索时，最值得保留的是：当输入、规模或风险改变，哪些判断需要重新做一遍。
我把这篇文章里的一个判断改写成了今天可以验证的小实验。比记住结论更有用的是，知道下一步要观察什么。
读完以后我先回头找它成立的条件，而不是直接把方法搬进项目。这个顺序让后面的取舍清楚很多。
如果把这个判断放到真实工作里，最先需要补的约束是什么？我想知道从阅读到第一次实践之间，哪一步最值得先做。
还没有这篇文章的讨论。