Loop Engineering · 2026-06-15 核验版

关于 Loop Engineering 的一张全景图

从“我一句句指挥 agent”升级为“我设计一个会发现、执行、验证、记忆、调度 agent 的系统”。这不是更会写 prompt，而是把人从循环内移到循环外。

核心定义

Loop Engineering = 设计一套 会 prompt agent 的系统，而不是继续做人肉时钟。

本页依据

主材料：GitHub 仓库 loop-engineering-orange-book，v260615，中英文 PDF 全文已抽取。

补充核验：Addy Osmani 原文、Anthropic harness 文章、Claude Code 文档、OpenAI Codex Automations 文档、Stripe Minions 公开材料。

说明：本页是结构化提炼和可视化解读，不复刻原书全文。

4层能力栈

5个循环动作

6个工程零件

4类核心代价

1. 它到底是什么

旧工作方式：你在屏幕前，给 agent 一个 prompt，等它做完，再给下一句。agent 停下来的每一拍，都要你来敲。

新工作方式：你设计一个外层系统，让它按时间或事件醒来，自己找活，分派给 agent，检查结果，把状态写下来，再决定下一轮。

身份变化：从“操作 agent 的人”，变成“调度 agent 的系统设计者”。

最容易误解的点

不是：写一段更长的提示词。

不是：把同一个任务手动重复跑十遍。

不是：让 AI 自己说自己做得很好。

而是：把“触发、上下文、隔离、验证、持久化、预算、人工复核”做成一套可运行的工程系统。

2. 四层栈：Prompt → Context → Harness → Loop

Loop 不是替代前面几层，而是坐在它们上面。越往上，人离单次执行越远，系统风险也越需要工程化管理。

Prompt Engineering 管一次输入怎么说：角色、目标、约束、例子。核心问题：我该告诉模型什么？

Context Engineering 管这一轮窗口里放什么：资料、检索、摘要、清理。核心问题：模型此刻该看见什么？

Harness Engineering 管 agent 单次运行的装备：工具、权限、完成条件、失败收尾。核心问题：一次运行怎么可控？

Loop Engineering 管 harness 之上的外循环：定时、发现、分派、验证、记忆、下一步。核心问题：怎么让它自己持续转？

3. 一个 Loop 转一圈的五个动作

任何 loop 都可以拆成这五步。缺“调度”，只是一次运行；缺“验证”，就是自动化自我催眠。

发现

系统自己判断这一轮该处理什么。

例：读 CI 失败、issue、commit、收件箱。

交付

把任务切小并隔离，交给具体 agent。

例：每个发现开一个 worktree。

验证

用独立评判者检查，不让生成者自评。

例：第二 agent 跑测试、查页面、审 diff。

持久化

把状态写到对话之外。

例：PR、ticket、Markdown 状态文件。

调度

决定下一轮何时、以什么输入继续。

例：cron、Automation、Cloud Routine。

4. 六个零件：把动作落成工程系统

调度

Automations

挂在时间表或事件触发器上，让任务不用人每天点开始。

隔离

Worktrees

让并行 agent 在不同工作区行动，避免同一份文件被多路改坏。

知识复用

Skills

把项目规则、检查表、上下文策略固化为可维护的 SKILL.md。

外部世界

Connectors / MCP

接入 issue、数据库、PR、Slack、飞书、监控，让 loop 看到真实工作现场。

能说不

Sub-agents

把生成者和评判者拆开，必要时换指令、换模型、换工具。

记忆

Memory

把状态放到磁盘、看板或仓库里，而不是只放在上下文窗口。

5. 生成器与评判器：Loop 的下限由评判器决定

Generator 生成者

负责写代码、生成方案、起草修复、构建页面。

它的强项是推进产出，弱点是容易相信自己的解释。

Evaluator 评判器

负责挑错、跑测试、打开页面、点按钮、截图、检查验收标准。

它的默认态度应该是怀疑：坏，除非被证明能跑。

评判方式	问题	更好的做法
agent 自评	同一个上下文里已经装满自我说服，容易高估结果。	只用于低风险草稿，不作为放行条件。
独立 evaluator	仍需调教，否则会看得太浅、太宽容。	给它明确 rubric、测试命令、截图和失败判定。
工具化 evaluator	成本更高，速度更慢。	让它用 Playwright、测试框架、lint、curl、像素检查等客观证据。
人类复核	不可完全省掉，尤其是业务判断和高风险改动。	把人从“写”移动到“审”和“决策”。

6. 三个真实场景：个人、企业、调度层

Addy 的早晨分诊

每天早上自动读 CI、issue、commit，分派 worktree，生成修复并审查，通过后开 PR，处理不了的进收件箱。

意义：个人也能搭出小而完整的 loop。

Stripe Minions

从 Slack 触发，云端 devbox 隔离运行，确定性流程准备上下文和 gate，agent 写代码，人类 review PR。

意义：企业级 loop 的核心不是更大的模型，而是更强的约束和开发基础设施。

本地与云端调度

意义：调度位置要按数据位置和可靠性要求选。

调度方式	跑在哪里	适合	限制
Cloud / GitHub Actions	云端	关机也要跑、仓库级周期任务。	本地文件、私有工具、低频间隔受限。

7. 四笔账：Loop 省下的时间不会凭空消失

风险 1

验证债

产出堆起来，但没有足够强的独立检查，错误安静积累。

防法：独立 evaluator + 客观测试 + 人工卡点。

风险 2

理解腐烂

代码库在长，你脑中的地图停在旧版本。

防法：定期读产出，能讲清再合并。

风险 3

认知投降

loop 越顺，人越懒得有自己的判断。

防法：执行可外包，最终判断不可外包。

风险 4

Token 失控

自主重试、子 agent、定时空转会把账单放大。

防法：单次预算、每日预算、最大重试次数。

8. 第一个 Loop 怎么搭

选一个发现源
CI、issue、commit、收件箱、飞书群、客户反馈都可以。

写一个 skill
把如何分诊、如何判断价值、如何输出结果固化下来。

落一个状态文件
每轮发现、处理状态、失败原因、下一步要在磁盘上。

加 evaluator
至少有测试、lint、截图、链接检查或人工复核。

隔离并行任务
涉及代码改动时用 worktree，避免多个 agent 抢同一份文件。

钉死预算与停止条件
明确什么时候算完成、什么时候停、失败几次后不再重试。

11. 一句话收束

Loop Engineering 的本质不是让 AI 更自由，而是把自由包进边界：它可以自动跑，但必须有人设计目标、证据、预算、记忆和刹车。

最值得带走的行动：今天就搭一个小 loop，但别省掉 evaluator 和人工复核点。第一个 loop 宁可慢，也要能说“不”。

来源

GitHub 原书仓库：alchaincyf/loop-engineering-orange-book，v260615。
Addy Osmani：Loop Engineering，2026-06-07。
Anthropic Engineering：Harness design for long-running application development。
Claude Code Docs：Keep Claude working toward a goal；Run prompts on a schedule。
OpenAI Developers：Codex app Automations。
Stripe Dot Dev Blog：Minions: Stripe’s one-shot, end-to-end coding agents；Part 2。