本文经原作者授权转载，版权归原作者所有。原作者：知野（@knoYee_）。
今天，我刷到了由Addy Osmani大神写的一篇讲 Loop Engineering 的文章，颇有感触，驱使我写下了这篇万字长文。
这两年以来，我们不难发现：
我们和 Agent 的协作方式正在变化
从人写 prompt 推着 Agent 往前走，变成人设计一套 loop，让系统自己持续推着任务走。
以前怎么用 Agent？
过去两年，我们用 coding agent 的方式很直白。
写提示词---agent执行---一步后，agent停止---继续写提示词来调整
我们要告诉它下一步做什么，哪里错了，要不要继续，什么时候停，结果合不合格。
本质上还是我们自己在不断推动agent的执行。
Loop Engineering 改了什么？
核心变化是：
我们不再直接给 Agent 一轮轮写 prompt，而是设计一个会自己推动 Agent 的系统。
你设计的不是一句 prompt，而是一套循环。
这套循环会自己发现任务、分配任务、执行、检查结果、记录状态、判断下一步，然后继续推进，直到满足停止条件。
以前你会说：
帮我修一下这个 bug。
Loop 的思路是：
- 每天早上自动检查 issue 列表和 CI 日志，判断哪些问题值得处理，
- 开一个隔离 worktree，让 coding agent 写修复，让 reviewer agent 检查，跑测试，
- 测试通过后开 PR，把结果写回任务板，没解决的进入 triage inbox。
我们不再亲自推动每一步，而是设计一个持续推进任务的系统。
和 Workflow 区别在哪？
很多人会问：
这不就是 workflow 吗？
不完全是。
Workflow 是固定流程。
A 到 B，到 C，到 D。
比如：
抓热点 → 写文章 → 生成配图 → 发布
中间出问题，要提前写好分支规则。
但 Loop 是带反馈的持续系统。
它更像：
发现问题 → 尝试解决 → 检查结果 → 不合格就重试 → 合格就记录 → 决定下一步
它不是简单按步骤执行，而是在围绕一个目标持续推进。
区别在于：
- 反馈。
- 状态。
- 验证。
- 重试。
- 停止条件。
- 人工接管。
所以更准确地说：
Workflow 是 Loop 的骨架。 Loop 是有反馈、有记忆、有判断的 Workflow。
和 Harness Engineering 什么关系？
Harness Engineering 解决的是：
- 怎么给单个 Agent 搭运行环境。
- 让它能读文件、跑测试、调用工具、获得项目上下文，并且在安全边界里执行。
但 Loop Engineering 往上一层。
它关心的不是单个 Agent 怎么跑，而是：
- 多个任务怎么被发现？
- 多个 Agent 怎么被调度？
- 结果怎么验证？
- 状态怎么保存？
- 下一轮怎么接着做？
- 什么时候停止？
- 什么时候转人工？
Harness Engineering 是给 Agent 搭环境。 Loop Engineering 是让 Agent 在系统里持续工作。
一个偏执行环境。
一个偏持续循环。
一个 Loop 需要什么？
Addy 在文章里列了五件重点：
1. Automations
这是 loop 的心跳。
没有 automation，就是你手动跑了一次任务。
有了 automation，它才能按固定节奏自己动起来。
比如：
- 每天早上检查 issue。
- 每小时扫描 CI 日志。
- 每天总结 commit。
- 定期寻找新 bug。
automation 负责让 loop 持续运行。
2. Worktrees
这是隔离。
两个 Agent 同时改一个 repo，很容易文件冲突。
worktree 给每个 Agent 一个独立的 checkout，让它们互不干扰。
多 Agent 并行不是开得越多越好。
没有隔离，越并行越混乱。
3. Skills
skill 不是简单的 prompt 模板。
它更像项目知识包。
里面可以写：
- 项目规则。
- 代码规范。
- 构建方式。
- 常见坑。
- 团队约定。
- 某类任务的 SOP。
Agent 每次开新 session 都是冷启动。
有了 skill，每次运行时都能读到稳定的项目知识，不用从零理解。
4. Plugins 和 Connectors
一个只能看本地文件的 loop，能力很有限。
真正有价值的 loop，需要接入真实工具。
比如：
GitHub。 Linear。 Slack。 数据库。 CI。 日志系统。
Plugins 和 connectors 让 Agent 不只是给你建议，而是真的能进入工作环境里操作。
它可以开 PR、更新 ticket、查日志、发通知、读取 issue、等待 CI 结果。
这一步决定了 loop 是玩具，还是生产系统。
5. Sub-agents
Loop Engineering 不淘汰多 Agent。
它淘汰的是“人肉调度式多 Agent”。
以前的多 Agent 协作是：
- 手动切角色。
- 手动分任务。
- 手动复制结果。
- 手动判断谁该接下一步。
这套方式会越来越落后。
但 loop 里的 sub-agent 是底层机制。
- 一个 agent 负责实现。
- 另一个 agent 负责检查。
- 一个 agent 负责探索。
- 另一个 agent 负责验证。
尤其是 maker 和 checker 的分离非常重要。
因为写代码的 Agent，不适合给自己的代码打分。
6. Memory
这是最朴素，但也是最关键的一层。
memory 可以是 markdown 文件，可以是 Linear board，也可以是数据库。
它保存：
- 已经做了什么。
- 尝试过什么。
- 什么失败了。
- 什么通过了。
- 下一步是什么。
- 哪些问题还没解决。
为什么必须有 memory？
因为 model 会忘。 conversation 会断。 context 会满。
但文件不会忘。
长期运行的 Agent，必须把状态写到外部，不能只放在上下文里。
最大的风险
主要有三个问题。
第一，验证环节还是在我们的手里
一个 unattended loop，也可以 unattended 地犯错。
所以必须有测试、review、日志、权限边界和人工审核。
不能因为它能自动跑，就默认它是对的。
第二，理解会退化
如果 loop 不断帮你 ship 你看不懂的东西，你和项目真实状态之间的距离会越来越大。
这就是 comprehension debt。
最后你可能拥有一个能跑的系统，但你已经不知道它为什么能跑。
第三，最舒服的状态最危险
当 loop 能自己跑时，我们很容易只负责按启动键。
你不再判断，不再理解，不再 review，只是接受结果。
这不是工程化。
这是放弃工程判断。
Loop Engineering 的重点不是让人消失。
人不消失。
人的位置往上提。
从写每一句 prompt，变成设计目标、规则、验证和边界。
对 Agent 产品意味着什么？
过去很多产品喜欢标榜自己有：
多 Agent。 workflow。 tools。 memory。
但这些单点能力正在变成基础设施。
未来真正重要的是：
能不能把它们组织成一个稳定的 loop。
也就是：
有上下文。 有状态。 有工具。 有权限。 有验证。 有失败重试。 有人工接管。 有长期记忆。
只做一个聊天窗口，价值会越来越弱。
只做一个 workflow builder，也很容易被替代。
只做一个多 Agent 聊天室，更危险。
真正有壁垒的，可能是：
AI Loop 的状态层、记忆层、验证层和调度层。
最后总结
Loop Engineering 描述的是 Agent 工程化的一个实际变化：
从 prompt 单次驱动， 到 workflow 流程驱动， 再到 loop 持续目标驱动。
Prompt Engineering 解决的是：
怎么让 Agent 一次回答得更好。
Harness Engineering 解决的是：
怎么让 Agent 在更好的环境里执行任务。
Loop Engineering 解决的是：
怎么让系统持续发现任务、调用 Agent、验证结果、保存状态，并自动推进下一步。
所以它不是简单的自动化。
它更像是 Agent 时代的工作系统设计。
Build the loop. Stay the engineer.