技术 · 熟练
让 agent 自己跑实验，先过四道关
不是「能不能自动优化」，是「那个分数可不可信」
让 Agent 自己改代码、跑测试、看分数，看起来是把「优化」这件事外包了 —— 但真正的分水岭不在模型强不强，而在那个分数本身可不可信。这一页把 Karpathy 那套「棘轮」闭环拆成四道必须先立起来的关：先找一个能用单个数字自动衡量的任务；把评分文件与数据准备逻辑锁成不可变文件（Agent 绝对不能碰，否则它会把「提高分数」变成「降低标准」）；每次尝试锁定同一段固定时间预算（时间不固定，分数就没有可比性）；升则提交、降则回滚这个动作由外层执行，不交给模型自己判断。四关立住之后，你才有资格说「这次改动是改进」。
方法 · 一图看懂
1
先找一个能用一个数字衡量的任务 — 没有评分器就没有循环；「帮我优化这段代码」这类主观目标落不成闭环，得改成「跑测试套件，目标是执行时间低于某条线」这种能被机器判定的目标
2
把评分文件与数据准备逻辑锁成不可变 — 这是最关键的一步：Agent 只许改「游乐场」里的代码，碰不到评分逻辑，否则它一定会为了高分去动评分标准，而这件事从结果上看不出来
3
每次尝试锁定同一段固定时间预算 — 跑 1 分钟与跑 1 小时得到的分数不能比；把每次尝试钉在同一段时长上，是「跨轮可比」的前提条件
4
提交与回滚由外层执行，只进不退 — 分数变高就提交、变低就回滚；这个判断不能交给模型，因为它天然倾向于把「改过了」当成「改好了」
原理 · 为什么有效
这套闭环能成立，靠的是一处很朴素的分工：模型负责提出改动，外层负责裁决改动。模型的任务被压到只剩「写一版代码」，而「这版是好是坏」由一段它看不见、也改不动的评分逻辑回答。于是每一轮的结论都变成一个数字，而数字之间可以比较 —— 这就把「持续优化」从一次主观判断，变成一串可回放、可回滚的提交记录。反过来，只要让模型同时掌握「改代码」和「判断改得好不好」两件事，它就会滑向最容易达成目标的那条路：改判定标准。这不是模型在骗人，是目标设定本身留了后门。
适用场景
适合已经在用 Agent 做「有明确验收标准」的重复工作的人：跑测试、压构建时间、调一个能用指标衡量的脚本或数据管线、把一段反复失败的处理逻辑磨到能过。不适合目标主观的任务（写文案、做设计、想方案）—— 那类任务先想办法把目标翻译成一个数字，翻不出来就先别上闭环。
自测 · 5 问
你的任务能不能写成一个数字？（写不出来 ⇒ 这一轮先别开）
评分逻辑与数据准备是不是放在 Agent 够不到的目录里？
每次尝试的时长是不是同一个值？换个时长分数还比得了吗？
提交与回滚是谁做的？如果是模型自己说「这次更好了」，这一关没过
回滚之后，上一版是不是还能一键取回？
怎么上手 · 验证步骤
落地顺序就四步：先把目标翻译成一个数字（写成一句话，含具体阈值）→ 把评分脚本与数据拆到不可变目录（Agent 的写入范围只留另一个目录）→ 把每次尝试的时长写死（例如固定五分钟，超时按失败计）→ 把「提交 / 回滚」写成外层脚本的一步（读分数、比阈值、决定提交或丢弃），整个过程不要让模型参与判断。
先跑一轮「空转验证」：不启动 Agent，只跑一遍评分脚本，确认它能对同一个代码库稳定给出同一个分数（跑三次分数一致）。分数单次抖动都很大的话，这套闭环的结论从一开始就不成立。然后再跑一轮「作弊测试」：故意让 Agent 看到评分脚本，观察它会不会去改那个文件 —— 会改，说明隔离没做到位。