基于OpenAI 后训练基础设施负责人/核心成员之一翁家翌的文章与开源仓库2026 年 5 月翁家翌发布了一篇博客提出“启发式学习”Heuristic LearningHL不训练神经网络让编码智能体读失败日志、改代码、补测试、看回放把一个程序系统一轮轮养大。配套的开源仓库里有策略脚本、试验记录、视频和复现命令读者可以自己跑。这类文章很容易被两种方式误读要么当成“神经网络要被取代”要么当成“标题党”。下面把它拆成五个观点每个都说清楚接受什么、保留什么。01 真正被学习的是一个会生长的系统不是一个函数最有说服力的是 Breakout。分数从 387 到 507再到 839、864理论满分每一步都对应一个具体机制先是发现策略陷入周期性循环加上“卡住时扰动落点”的规则再是发现快速低球会让挡板过度前冲加一个前瞻修正最后是后期把扰动逐步释放再补上动作延迟的微调。这不是调参而是一次次看视频、定位失败、改结构。取把“策略 状态读取 回放 测试 实验记录”整体当作学习对象这个视角比“生成一个 policy.py”有价值得多。舍864 不能当作泛化证据。它是单个游戏的理论满分且作者说明结构先在 RAM 版本里发现再迁移到图像检测所谓 14.5K 步是迁移预算不是从零开始的步数。02 样本效率很漂亮但不等于总成本低Atari57 实验跑了 57 个游戏、两种观测模式、各 3 次共 342 条无人值守的搜索轨迹。按环境步数算约 1M 步时中位人类归一化得分已明显高于同步数的 PPO 曲线到约 9.7M 步时仍略低于文中的 PPO 参考值。作者自己也写明这个比较没有把智能体读日志、写代码、看视频的成本折算进去。还有两点要留意Ant 的策略用到了本地 MuJoCo 模型做短时域规划这与无模型的 PPO 并不对等大模型本身带着对经典游戏的先验。所以这个结果更适合解读为“当环境交互昂贵、而推理和代码生成便宜时这条路线值得考虑”。取环境步数是稀缺资源时比如昂贵的真机、慢速仿真用智能体把试错压缩进代码迭代是实在的优势。舍不要把它写进“比 PPO 更高效”的结论里除非你同时报告了 token、算力和人工审阅成本。03 最硬的价值不是“更聪明”而是“可回归”原文最耐读的部分是对持续学习的重新表述神经网络的遗忘是旧能力被参数覆盖HL 也会遗忘只是形态变成了工程问题比如新规则破坏旧场景、测试太窄被策略钻空子、共享接口被悄悄改坏、规则越堆越多直到智能体也维护不动。好处是旧能力可以固化为回归测试、固定种子回放、黄金轨迹和版本差异历史可读、可删、可重构。文中还强调一个容易被忽略的操作压缩。只增不压的系统最终会变成一团泥所以健康的系统需要“吸收反馈”和“压缩历史”两个动作。取把测试、回放、失败方向的记录当作一等公民这是任何长期运行的智能体系统都该有的纪律。舍不要以为有了测试就不会遗忘。覆盖不到的地方照样会退化因此“耦合复杂度上限”才是核心约束它由模块边界、测试、可观测性以及模型和上下文能力共同决定。04 表达力有边界神经网络和 HL 更像分工仓库里最诚实的两个案例是 Montezuma 和 HL-ImageNet。Montezuma 的 400 分来自 86 个宏动作拼成的近似开环路线作者明确说它不是通用策略并指出普通的 if-else 状态机很难表达这种需要对齐时序、失败恢复的长程任务下一层抽象大概需要宏动作、可恢复状态、搜索和长期记忆。社区项目 HL-ImageNet 则把 HL 放到符号化视觉分类上指出仅在训练集上优化的符号代码仍可能变成记忆器难点从拟合转向了可复用的视觉表征与泛化。适合交给 HL仍需要神经网络规则、安全边界、局部恢复、回放与测试、快速处理新数据复杂感知、对象状态估计、长程泛化作者设想的分工也是如此浅层神经网络负责感知HL 负责规则与记忆LLM 智能体负责给 HL 反馈并定期把 HL 产出的数据用于更新模型。取“HL 先吃在线数据再把经验整理成可训练、可回归的数据集喂回模型”这条路径工程上最现实。舍别把 HL 当成能通吃的万能解。凡是需要从高维像素里学表征的地方边界依然清晰。05 “下一个范式”是一个值得下注的假设而不是已验证的结论文章把预训练、RLHF、大规模 RL/RLVR 之后的下一步押在“一切可持续迭代的东西都会变得可解”上。我愿意把它读作趋势判断编码智能体越强维护复杂规则系统的成本越低过去被抛弃的启发式就越值得重新拥有。但证据目前主要来自可重置、奖励清晰的模拟环境和一篇博客尚未经过大规模、跨领域的独立验证。作者也说明实验只用了 gpt-5.4更新的模型还没测。另外它与程序合成、专家系统、智能体技能库和记忆机制同属一条脉络这是我的判断不是原文的说法。它的新意在于“维护成本曲线被改变”这一点是否稳固要靠后续复现来回答。取把它当成一个有明确可证伪点的研究方向用更新的模型复现、换更接近真实业务的环境、报告全成本。舍不要用“范式”这个词替代论证写技术方案时先问清楚反馈能否自动化、旧能力能否被测试覆盖。落地到智能体工程可以这样做场景做法风险点固定流程、规则明确用 HL 思路维护代码化策略与回归集规则堆积需定期压缩重构反馈可自动化让智能体读日志与失败样本改代码并重跑测试过窄导致被钻空子需要感知或泛化神经网络负责感知HL 管规则与恢复HL 数据分布影响模型更新稳定性评估收益同时报告环境步数、token、算力、人工审阅时间只报步数会高估效率最后一句话总结这篇文章最值得带走的不是“不要梯度”而是“把智能体产出的东西当作需要长期维护的系统并给它配上测试、回放和压缩机制”。至于它能否成为下一个范式让时间和独立复现来回答。参考原文含附录与复现命令 · GitHub 仓库。文中数字均出自原文与仓库说明具体以原文为准。