从手动编排到自动循环
过去两年，人跟 coding agent 的交互模式基本一致：你写一句，看一眼结果，再写一句，逐轮推进。agent 是工具，你是操作者，整个过程是同步的，你全程在场。
这个模式的问题不是效率低，而是不可扩展。你的注意力带宽是固定上限——同时盯着三个 agent 就到极限了，不管工具多好。三以上，质量开始崩，因为 review 跟不上。
Loop Engineering 的思路是把"你"从循环里摘出来。不再是人驱动 agent，而是系统驱动 agent。你设计系统，系统驱动 agent，agent 干活，系统检查，写入记忆，触发下一轮。
听起来像是 agent harness 或 multi-agent orchestration 换了个名字。某种程度是的。但 Osmani 的观察有价值：这些组件不再是需要你自己拼 bash 脚本搭的东西了——Claude Code 和 Codex 已经把五个核心原语内建到了产品里。这意味着 loop engineering 正在从一个手工活变成一个有标准构件的工程学科。
五个构件 + 一块记忆
一个完整的 loop 需要五样东西，加一个外部记忆。
自动化（心跳）
没有 cron，它不是 loop，只是一次性任务。/goal 让 agent 持续工作直到可验证的停止条件成立，每轮由另一个小模型打分。
Worktree（隔离）
给每个 agent 独立的 working directory 和独立分支，物理上不可能互踩。工具解决机械冲突，review 带宽才是真天花板。
Skill（意图持久化）
agent 每次冷启动都是空白的。Skill 是外部化的项目知识——约定、构建步骤、踩过的坑，写一次，每轮都读，知识复利。
Connector（触达）
MCP 协议让 agent 能读 issue tracker、查数据库、调 API、发消息。只能在文件系统里打转的 agent 是个 tiny loop。
Sub-agent（质量控制）
写代码的和审代码的不应该是同一个模型。拆成 maker 和 checker，用不同的指令甚至不同的模型，防止自我合理化。
外部记忆
markdown 文件、Linear board，任何存活在对话之外的持久状态。模型在运行之间会忘记一切，记忆必须在磁盘上。
杠杆移动了，不等于工作变简单了
Osmani 文章最后那段，才是整篇的刀刃。
两个人可以搭完全相同的 loop，得到完全相反的结果。一个用它加速自己已经深入理解的工作，另一个用它逃避理解工作本身。Loop 分不清区别。你自己分得清。 — Addy Osmani
这就是为什么 loop design 比 prompt design 难，不是更容易。prompt 的杠杆点在你的脑子里——你理解什么就写什么，理解浅就 output 浅。loop 的杠杆点移到了系统设计里，但系统产出的上限仍然是你对自己工作的理解深度。
Cherny 的本意不是说工作变轻松了。他的意思是杠杆点换了位置。从"你能写多好的 prompt"换成了"你能设计多好的循环"。
如果你对工作的理解是清晰的——论文筛选的标准、交易风控的阈值、代码 review 的红线——你的 loop 会忠实地放大这些判断。如果你自己都说不清什么是好的产出，loop 就会忠实地放大这种模糊。Loop 不会替你思考。它只会放大你已有的思考，或者放大你已有的偷懒。
不只是代码的事
Osmani 的文章聚焦在 coding agent 场景（Codex 和 Claude Code），但 loop 的结构是通用的。
我自己现在跑的 cron 定时任务就是一个简单的 loop：每天早上 8 点拉 AI 日报，6:30 生成论文播客，内容写入 markdown 文件推送到飞书。每个任务有明确的触发条件、执行脚本和输出规范。Skill 文件里存着数据源、输出格式、fallback 链——这些就是意图持久化。飞书 API 就是 connector。
交易巡检曾经也是一个 loop：每天三次定时抓市场数据，对照风控规则检查持仓，生成报告推送。后来停了，不是因为 loop 有问题，是因为数据源不稳定导致信噪比太低。这是另一个教训——loop 的价值取决于它喂进去的数据质量。
更复杂的 loop 可以是这样的：agent 自己去 arxiv 扫新论文，用 embedding 做相关性筛选，对命中的论文自动生成解读初稿，存入待审队列，人在晨间花十分钟过一遍，确认的自动推送公众号。这个 loop 里有自动化触发（cron）、skill（论文解读模板和筛选标准）、connector（arxiv API + 公众号 API）、sub-agent（初稿 agent + review agent 分离）、外部记忆（待审队列 markdown）。五个构件齐全。
| Loop 构件 | Coding 场景 | 论文解读场景 | 交易巡检场景 |
|---|---|---|---|
| 自动化 | cron + /goal | arxiv 定时扫描 | 盘前/盘中/盘后 cron |
| Worktree | git worktree 隔离 | /tmp 目录隔离 | N/A |
| Skill | 构建步骤 + 代码规范 | 解读模板 + 筛选标准 | 风控规则 + 输出格式 |
| Connector | GitHub + CI + Slack | arxiv API + 公众号 API | CNBC + akshare + 飞书 |
| Sub-agent | maker + reviewer | 初稿 agent + review agent | 数据采集 + 信号判断 |
| 外部记忆 | CLAUDE.md / Codex skill | 待审队列 markdown | 持仓记录 + 信号日志 |
设计 Loop 的原则
日报、巡检、格式转换——这些天然适合 loop，因为输入输出模式稳定，人工编排没有增量价值。
论文是否值得解读、交易信号是否执行——这些决策点的质量取决于理解深度，不是自动化能提升的。Loop 应该把候选推到人面前，而不是替人做决定。
任何 loop 里，执行者和验证者必须是独立的。这不只是工程最佳实践，是防止自欺的结构性约束。
外部记忆存什么、怎么组织、怎么在轮次之间传递，直接决定了 loop 能累积多深的理解。一个没有好记忆设计的 loop，每轮都是原地踏步。
Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go. — Addy Osmani
你不是在设计一个按下去就不管的系统。你是在设计一个放大你判断力的工具。如果你不理解自己要什么，loop 会以更大的规模帮你产出你不想要的东西。
Loop engineering 的本质不是"把工作交给 AI"。是把你已经理解透的工作，封装成可自动执行的系统，然后你腾出精力去理解下一个问题。