即将到来的 Loop

The Coming Loop @mitsuhiko 即将到来的 Loop 与我们让渡的判断力！ 在 Claude Code 构建者 Boris Cherny 和 OpenClaw 构建者 Peter Steinberger 几乎同时提出「Loop Engineering」的概念后，这篇对 Loop 的反思更值得认真阅读。 https://t.co/oICshWEIc7 把 Loop 区分为两层循环 1. 内层是 agent loop（模型说"完成"即止） 2. 外层是 harness loop——由 harness 判定"完成"是否为真，否则续接 session、注入任务、转交他机，把任务生命延长到模型本会主动停下的点之外。 对 loop 的抗拒：循环放大了 LLM 代码的系统性缺陷 LLM 产出的代码本就过度防御、回避强不变量、用 fallback 兜底而非让坏状态不可表达（Karpathy 称其"恐惧异常"）。 循环会放大这一倾向：每轮叠加一层局部防御，系统在看似更健壮的同时变得更难理解，越放手越严重。 作者甚至判断，当下放手式 harness 产出的代码反而不如去年秋天——因为模型现在能连续无人干预运行数十分钟。 loop 真正有效的领域及共性 移植（Bun 从 Zig 到 Rust、MiniJinja 到 Go）、性能探索、安全扫描、研究——共性是要么不产生新代码（只变换已有代码），要么产出无需长寿（POC、机械翻译）。 关键在于 harness 续接所需的信号不必客观二元，只需"有用到足以驱动下一轮"。 核心隐喻：从"机器"到"有机体" · 传统工程文化追求可剥开理解的确定性机器 · LLM 把我们推向"软件即有机体"——用机器写、用机器诊断施治、生产事故首步已是机器读日志提补丁并被另一机器 review 合入。 我们治疗、监控、稳定它，但未必理解它。 为何无法退出：安全与竞争的双重夹击 即便你不 loop，攻击者与安全研究者会持续对你的软件 loop（curl 维护者已被 AI 报告淹没，防御方也不得不 loop 来分流复现）；竞争上，少数掌握机器编排的团队将以极小规模跑出过去几十人的速度。速度、试错、覆盖率至上的领域，循环几乎无可阻挡。 最深的隐忧：认知依赖 金钱依赖之外更危险的是认知依赖。 若代码库由循环产出、review、打补丁、维持生命，一旦失去同类系统访问权（贸易限制、成本失控、或团队彻底丧失不靠机器理解代码的能力）将如何？ 这已在发生：人合并不完全能解释的代码，不借 LLM 就写不出 issue、聊不清问题。 本质：判断与责任的让渡 内层循环里人仍 steering、能学习；外层循环里"完成"信号失去意义，只被传递给另一台机器评判，人的角色退化为信使。 作者立场清醒：问题不再是"是否会 loop"（答案已是"会"），而是"在循环的未来里，如何不让渡判断力、保留工程规则、确保人能持续监督、重新思考代码架构以维持理智"。 他对 Pi 的态度亦如此——不抵制循环，但必须主动实验以理解如何让这个未来有界、可存活。