Kyle Mistele 的 “Loop Engineering from first principles” 是当天最像工程课的一场。他没有把 loop 当新词，而是把它放回控制论：测量状态、比较目标、计算误差、做小步调整。
原视频：https://www.youtube.com/watch?v=htM02KMNZnk
loop 不是重复执行
很多人听到 agent loop，会以为就是让模型一直跑。失败了再试，没完成就继续。这类 Ralph loop 看起来自动化，实际很危险，因为它没有真实测量。
Kyle 从 thermostat、Kubernetes autoscaling、Postgres autovacuum、React virtual DOM 这些例子讲起。它们共同点不是 “重复”，而是有目标状态、有当前状态、有误差、有 controller。
把这个框架放到 agent 里，问题就清楚了。一个好的 agent loop 要知道：目标是什么，当前状态是什么，差距在哪里，下一步最小调整是什么，什么时候停止。
为什么要小步增量
Kyle 强调，控制 loop 通常是增量改变系统，而不是一次性推倒重来。这个原则对 coding agent 特别重要。
模型很容易生成大改动。大改动看起来进展快，但验证半径也会变大。一个 PR 改了几十个文件，测试又不完整，人就很难判断它到底对不对。最后你不是省时间，而是在更复杂的 diff 里还债。
小步增量的好处，是让验证跟得上生成。每次只改一个可测量问题，观察结果，再决定下一步。Karpathy 说 tight leash，也是这个意思。短绳不是保守，而是把模型的速度关进可验证的步长里。
HumanLayer 的控制 loop
Kyle 还用 HumanLayer 内部实践说明 control loop。转录里提到，他们用 loop 去识别坏模式、清理代码、处理复杂 codebase 中的工作。重点不是让 agent 自由发挥，而是围绕可测量目标行动。
这和当天后面 Dex 的提醒也能连起来。loop 不是魔法。如果目标不可测、反馈不可用、权限过大、停止条件模糊，loop 只会更快制造问题。
我会把这场当作 software factory 的底层定义：loop 是带测量的反馈控制，不是无脑重试。
如果你要在团队里上 agent loop，可以先问四个问题：目标能不能写成可检查条件？当前状态能不能测量？每次改动能不能小到可 review？失败以后系统能不能告诉你错在哪里？四个都答不上来，就别急着自动化。
控制论给 agent 设计降温
Kyle 把 loop 拉回控制论，非常有价值。现在很多 agent 产品喜欢说自己有 loop，但实际只是“失败后再问一次模型”。这不叫控制系统，只是重复尝试。
真正的控制 loop 要有 sensor、desired state、error、controller 和 actuator。放到软件开发里，sensor 可能是测试、lint、静态分析、用户反馈、性能指标；desired state 是 spec；error 是当前结果和目标的差距；controller 决定下一步；actuator 执行修改。
少掉任何一环，loop 都会变形。没有 sensor，系统不知道自己错了；没有 desired state，系统不知道该往哪走；没有 controller，系统只会随机试；没有停止条件，系统会越跑越偏。
lights-off 工厂的教训
他提到自己团队跑过接近 lights-off 的软件工厂，后来留下了伤疤。这部分很重要，因为它不是反 AI，而是反对没有控制的自动化。
当代码变得“免费”，系统很容易生成越来越多改动。短期看任务完成了，长期看坏代码会复利。agent 产生的问题，有时又会被新的 agent 修补，最后整个代码库变成难以理解的层层补丁。
这就是为什么小步增量重要。小步不是慢，而是降低每次验证成本。软件工厂想稳定，必须把生成速度和验证能力匹配起来。
loop engineering 是团队纪律
我会把 Kyle 这场当作一条纪律：任何自动化 loop 上线前，都要写清楚目标、传感器、动作边界和停止条件。比如“修复测试失败”这个目标太宽；更好的目标是“只修改某个模块，让这三个测试从失败变成通过，不改公共 API”。
这样 agent 才有可控空间，人也能 review。否则 loop 越强，越可能把错误规模化。
来源与说明
本文基于 AI Engineer World’s Fair 2026 Day 1 主舞台视频转录、官方日程信息，以及本地 AI engineering 知识库整理。文章不是逐字稿，而是按单场分享的主线、上下文和工程启发重写。
评论前必须登录！
立即登录 注册