Loop Engineering

导读

过去两年，我们大部分时间都在学怎么提示 AI：怎么写 prompt，怎么补上下文，怎么让它按格式输出。

但最近几个月，硅谷 AI 圈开始频繁讨论另一个词：Loop Engineering。

它不是说 prompt 不重要了，也不是给 Agent 起一个新名字。更准确地说，它是在回答一个更现实的问题：当 Agent 不再只是一次对话里的助手，而是要被放进长期运行的任务里，系统该怎么设计？

---

先从一个常见问题说起

很多人第一次用 coding agent 或工作流 Agent，都会有一个Aha Moment：它真的能完成一些事情。

你给它一个目标，它会读文件、查资料、写代码、跑测试、修报错。中间哪怕犯错，人也在旁边看着，随时补一句：“这里不对，重新来。”

这时候 Agent 像一个很聪明的实习生，它不一定都能把事情做对，但你盯着它，它就能往前走。

真正的问题出现在下一步：你不想每次都坐在旁边，但是你又希望Agent能24小时不间断的干货。

你希望它每天自己醒来，检查有没有新任务；发现问题后自己处理；处理不了就挂起；需要人批准时再叫你；执行完以后把状态记下来，下一次接着跑。

到了这里，就变成了另一个问题。它不再是“模型这次回答得好不好”，而是：

• 谁来启动下一轮任务；
• Agent 这次该拿到哪些上下文；
• 结果由谁检查；
• 错了以后是重试、跳过，还是停下来；
• 状态存在哪里；
• 哪些动作不能让 AI 直接做；
• 跑到第 1000 次时，系统还能不能知道自己在干什么。

上面这些如果人在监控，还可以及时进行纠正，大不了清理上下文重新开启任务，可是一旦你真的把 Agent 放到持续不间断的工作流里，就会发现 prompt 写得再漂亮，也挡不住这些问题：

• 模型输出偶尔少一个字段；
• 外部 API 偶尔超时；
• 一次失败留下的上下文污染了下一次判断；
• Agent 自己看自己的结果，容易过于宽容；
• 任务跑到一半中断，下一轮不知道从哪里恢复；
• 副作用动作已经发生，重试反而造成重复发送、重复写入或重复扣款。

这些都不是“再补一句 prompt”能解决的。

这就是 Loop Engineering 发挥价值的场景。

---

为什么Loop Engineering开始爆火

Loop Engineering 不是一个突然从论文里冒出来的新概念。它更像是过去几条线走到一起以后，被大家重新命名了。

早一点，Andrew Ng 讲 agentic workflows，重点是让模型不要只回答一次，而是能反思、规划、调用工具、多 Agent 协作。那一层讲的是：怎么让 Agent 做得更好。

到 2026 年 5 月前后，大家已经开始讲更长周期的 Agent：memory、cron、skills、自我改进循环、持续维护。这些都在指向同一个变化：Agent 不再只是聊天窗口，它开始像一个后台进程。

真正把 Loop Engineering 这个词推到台前的，是 6 月初Peter Steinberger 在 X 上分享，与其一条条 prompt coding agents，还不如设计能 prompt agents 的 loops。Addy Osmani 随后写了《Loop Engineering》，把 loop 拆成 automation、worktrees、skills、plugins/connectors、sub-agents，再加一层 memory。

这些人的表达不完全一样，但指向很一致：人的工作正在从“亲自给 Agent 下每一步指令”，变成“设计一个能让 Agent 反复持续不间断的工作的系统”。

这也是为什么我觉得 Loop Engineering 不是一个学术概念。它更像是一线工程师被 Agent实践中摸索出来的词。

---

从 prompt 到 loop的四层递进

其实从Prompt到Loop，是层层递进的：

prompt → context → harness → loop

Prompt 是一次性指令。你告诉 Agent 做什么，它回答一次，或者执行一段任务。

Context 是上下文管理。你把项目规则、历史记录、文件、记忆库、检索结果喂给它，让它不要每次都从零开始。

Harness 是单次 Agent 执行的装备层。它让 Agent 能读文件、跑命令、调用工具、访问 API，并在一定权限边界里完成一个任务。

Loop 再往上一层。它不只关心“这一次 Agent 怎么跑”，而是关心：

• 任务怎么被发现；
• 哪个 Agent 或工具该被调用；
• 输出怎么验证；
• 失败怎么分类；
• 状态怎么保存；
• 下一轮怎么接上；
• 什么时候必须停止或转人工。

很多所谓“AI 自动化”，其实只做到 harness 层。它能把一次任务跑起来，但外层仍然靠人盯着：人发现任务，人判断失败，人决定重试，人记录状态。

Loop Engineering 要补的，就是这一层外循环。

---

Loop 不是一直循环，而是让Agent闭环

“Loop”这个词很容易让人误解成：让 Agent 一直跑，直到它把事情做完。

这其实太粗糙了。

一个真正可用的 Loop，不是简单的while循环，它更接近这样的：

Observe → Classify → Route → Act → Verify

先观察系统当前状态，比如日志、数据库、队列、外部 API 返回。再判断这是什么信号：正常、警告、错误，还是必须立刻停下来的风险。然后决定路由给哪个 Agent、脚本或工具。执行之后，不能让 Agent 自己说“我觉得完成了”，还要用确定性方式验证结果。

这也是 Loop Engineering 和普通 Workflow 的差别。

Workflow 更像是定义“事情按什么顺序发生”：A 到 B，B 到 C，C 到 D。它当然有价值，成熟的 Workflow 也可以做分支和重试。

但真实长任务里，麻烦通常不在成功路径上：

• A 节点返回空值，B 节点却继续判断；
• 模型输出格式不合规，但后面节点仍然解析；
• 外部服务限流，系统马上重试，把问题放大；
• 上一次已经发送成功，下一次重试又发了一遍；
• 质量检查只是模型自评，结果它对自己很客气；
• 人工审批没有挂起机制，只能在流程外靠人盯。

Workflow 是骨架。Loop 是在骨架上加反馈、状态、验证、重试、停止条件和人工接管。

---

Memory 不是让会话永远不丢

这里有一个很容易写错、也容易理解错的点：Loop Engineering 当然需要 memory，但它需要的不是“把所有会话上下文都留着”。

长会话上下文很有用，但它不是可靠的业务记忆。

原因很简单：上下文会变长，会混入失败尝试，会塞进临时判断，也可能在模型下一轮推理里被错误放大。你不能把“系统运行到哪一步”“上次失败原因是什么”“这次是否允许重试”“某个动作是否已经产生副作用”这些状态，寄托在一次会话里。

更合理的做法是分开两种东西：

• 工作上下文：Agent 这一次执行任务需要看到的材料、约束和局部历史。它可以被重建，也可以在任务结束后丢弃。
• 长期状态 / 外部记忆：任务进度、结构化结果、失败原因、审批状态、重试次数、外部副作用记录。它应该存在数据库、文件、任务板、队列或其他可恢复的介质里。

所以“上下文可丢弃”和“memory 可持续”并不矛盾。

真正要丢弃的是临时会话噪声；真正要保存的是结构化、可恢复、可审计的状态。

这也是我在实际落地中才发现的：model 会忘，conversation 会断，context 会满，但文件和数据库不会忘。长期运行的 Agent 必须把状态写到外部，不能只放在上下文里。

---

一个能跑的 Loop，通常要有这些东西

一个可用的 Loop 大概离不开六部分。

第一是 automation。没有自动触发，就还是人在手动启动任务。它可以是定时任务、webhook、事件队列，也可以是某个后台心跳。

第二是隔离。coding agent 里常见的是 worktree；其他场景里可能是独立任务空间、独立缓存、独立浏览器环境，或者至少是每轮任务的独立上下文。没有隔离，多 Agent 并行很容易互相污染。

第三是 skills。这里的 skill 不只是 prompt 模板，更像项目知识包：规则、边界、SOP、常见坑、构建方式、验收标准。Agent 每次冷启动，都能先读到稳定知识，而不是靠上一轮会话残留。

第四是 plugins 和 connectors。一个只能写文档的 Agent，离生产还很远。真正的 Loop 要接进工具：数据库、CI、GitHub、飞书、邮件、日志系统、监控系统。连接器决定它是玩具，还是能进入真实工作环境。

第五是 sub-agents。多 Agent 的价值不在于热闹，而在于分工。尤其是 maker / checker 分离：生成结果的 Agent，不应该独自给自己的结果打分。能用规则验证的先用规则，规则判断不了的，再交给独立 Checker 或人。

第六是 memory。不是模型脑子里的记忆，而是外部长期状态：做过什么，失败过什么，下一步是什么，哪些问题需要人处理，哪些规则需要沉淀回 skill。

这些部件不是为了把架构画复杂，而是因为没有它们，Loop 很快会在真实运行里暴露问题。

---

最容易被低估的是风险

Loop Engineering 听起来很诱人：少写 prompt，让 Agent 自己推进任务。

也风险也在这里，Loop 一旦无人值守，错误也会跟着无人值守地持续发生。

实际Loop Engineering在实践过程中也会有问题：

第一是验证债。你知道系统有问题，但没有把验证写进闭环。已知问题越来越多，最后变成“只要没人问就当没事”。

第二是理解腐烂。系统越来越能自动跑，但人越来越看不懂它为什么能跑。文档分散、状态分散、日志分散，新接手的人只能从一堆历史痕迹里猜。

第三是 token 和 API 成本失控。Loop 一旦无人值守，如果没有预算上限、停止条件和退避策略，异常重试会非常贵。

第四是认知投降。最危险的不是系统犯错，而是人因为它大部分时候都能跑，就慢慢放弃理解、review 和判断。

所以好的 Loop 不是“尽量全自动”，而是：

• 可停止；
• 可验证；
• 有记忆；
• 有边界；
• 有预算；
• 可观察。

这六个词比“自动化程度高”更重要。

---

人没消失，只是位置变了

Loop Engineering 最容易被误读成“全自动”。我觉得这反而是危险的。

越是接近真实用户、真实资金、生产数据和外部发送，越不能让 Agent 自己一路跑到底。

更稳的分工是：

• Agent 处理模糊判断：理解内容、分类、匹配、生成候选方案；
• 代码处理确定动作：抓取、传输、写入、校验、权限、状态流转；
• Checker 或规则系统处理质量闸门：字段、格式、重复、异常、风险词、约束；
• 人处理高风险放行：发送、付款、删除、部署到生产环境、不可轻易撤销的动作。

这不是降低自动化程度，而是把人的注意力放到更值钱的位置。

如果人还在复制粘贴每一条低风险数据，系统没有放大效率；如果人完全不看任何高风险动作，系统又会放大事故。

好的 Loop 不应该追求“人彻底不在场”，而应该追求“人只在该出现的时候出现”。

写在最后

Loop Engineering，不是“又多了一个 AI 新名词”，而是它把一个很朴素的问题摆到台面上：

以前人站在循环里，靠耐心和经验推动 AI 往前走；现在如果要让 Agent 真正进入长期任务，就必须把这个循环本身设计出来。

这套设计里，prompt 仍然重要，context 仍然重要，harness 也重要。但它们都只是 Loop 的前置条件。

真正决定系统能不能跑住的，是它有没有稳定的调度、干净的工作上下文、可靠的长期状态、确定性校验、失败恢复、成本边界，以及必要的人工接管。

换句话说，Loop Engineering 不是让 Agent 更像人，而是让 Agent 更像一个可以被调度、被约束、被检查、被恢复的系统组件。

这可能没有“一个超级 Agent 接管所有工作”听起来刺激。但如果目标是让 AI 在真实环境里持续工作，这是一条更可行的路。