重磅！Loop Engineering 实操手册公开
一句话概括
这篇 Loop Engineering 实操文把“该不该上 loop”“最小 loop 该怎么搭”“上线后最容易怎么翻车”拆成一张可执行清单，强调 loop 的价值不在让 agent 更聪明，而在于把自动触发、状态持久化、硬闸门和独立验证串成闭环。
实践内容
动手前的五个判断
- 任务是否重复，能否摊薄 loop 的建设成本。
- 是否存在自动化验收器，例如测试、类型检查、linter、构建脚本。
- 团队是否承受得起 loop 的 token 浪费。
- Agent 是否能运行并观察自己写出的代码与日志。
- 人是否真的愿意 review 最终产出；如果不 review，就不该建 loop。
Loop 的五个核心构件
| 构件 | 作用 | 本文强调 |
|---|---|---|
| Automations | 作为 loop 的心跳 | 停止条件必须写死，避免无限自转 |
| Worktrees | 并行隔离多个 agent | 避免改同一份工作区互相打架 |
| Skills | 固化项目背景和约定 | 减少每轮重复解释成本 |
| Connectors | 接入 GitHub / Ticket / Slack / Sentry | 让 loop 进入真实工具链 |
| Sub-agents | 写的人和验的人分开 | 独立验证器是无人值守 loop 的信任前提 |
最小 Loop 配方
1. 一个 automation：按节奏触发，按明确条件停
2. 一个 skill：项目背景、约定、常见坑
3. 一个状态文件：记录上次做到哪、下一步是什么
4. 一道硬闸门：测试 / 类型检查 / 构建不过就拒绝文中给出的顺序也很重要：先让一次手动运行稳定，再做成 skill，再包成 loop，最后才上调度。
上线后的常见翻车方式
- 假装干完了：没有硬闸门，agent 很容易“活干一半就宣布完成”。
- 理解债务：loop 越快交付你没读过的代码，仓库真实状态和你的理解差距越大。
- 认知投降：人不再判断，只会接受 loop 的产物。
- 安全失控：无人值守 loop 也是无人值守攻击面，要补 SAST、依赖审计、密钥扫描和权限复审。
摘录
Loop 不是免费的。它烧 token、要花时间搭、出了问题你还得去 debug 一个你没亲眼看它跑的系统。所以先问自己四个问题，都想清楚之后，再动手：这个任务是重复的吗？有没有东西能自动判定“这活干砸了”？你的 token 预算扛得住浪费吗？Agent 能跑自己写的代码吗？还有个附加题，比上面四个都重要：你打算 review 它产出的代码吗？不打算，就别建 Loop。
搭好之后盯一个指标：每个被接受的改动的成本。如果接受率低于 50%，这 loop 就在亏本。loop 跑起来后还会以三种方式翻车：一是假装干完了，二是理解债务，三是认知投降。安全上还有一条红线：无人值守的 loop，就是无人值守的攻击面。生成代码未审就上线、自动安装泄露凭证的 skill、把敏感信息写进 verbose 日志，都会把自动化优势反过来变成系统性风险。
涉及实体
- Loop-Engineering —— 本文把 loop 的“适用门槛 + 最小配置 + 上线风险”讲得最像工程清单。
- Harness-Engineering —— loop 延伸了 harness 的边界，把单次运行升级为可调度的重复闭环。
- Generator-Evaluator —— 独立验收 sub-agent 是无人值守 loop 的质量底线。
- MCP —— Connectors 通过 MCP 等外部连接器让 loop 真正触达 GitHub、Slack 与告警系统。
- Claude-Code —— 文章把 Claude Code 与 Codex 的 Automations / 命令面当作 loop 原语的具体落点。
涉及主题
我的评注
这篇的贡献是把最近偏概念化的 Loop 讨论拉回“工程可行性检查表”：不是先迷信闭环，而是先判断任务重复性、自动验收条件、token 预算和 review 能力。它适合作为 Loop-Engineering 实体里“不是所有人都该立刻上 loop”的证据来源，也能给 Harness-Engineering-主题 补上最小可行配置与安全红线。