---
source_url: "https://mp.weixin.qq.com/s/hx7-BQ33JFOHHtJP30TkbA""
ingested: 2026-06-26
sha256: 491612dfec7b6b53
---
sha256: 6da32bfb8422dae2
---
title: "Loop Engineering 详解：把反馈循环放进工程现场"
source_url: "https://mp.weixin.qq.com/s/hx7-BQ33JFOHHtJP30TkbA"
author: "若飞"
feed: "架构师 JiaGouX"
published: "2026-06-11 22:35"
ingested: "2026-06-11"
type: raw
tags: [loop-engineering, harness, codex, claude-code, 若飞, ruofei, jiagoux, 架构师, feedback-loop, worksite, four-tier-architecture, seven-day-pilot, five-conservative-principles, state-memory, plan-md, gated-verification, budget-aware, closed-loop, open-loop, loop-pilot]
sources: [entities/loop-engineering-addy-osmani-challengehub]
sha256: b3b0797c4bac803a521b60817190195468fcd33aa950a4149f929c859a49f541
review_value: 9
review_confidence: 8
review_recommendation: strong
review_stars: 4
---

# Loop Engineering 详解：把反馈循环放进工程现场

> 原文出处：微信公众号「架构师 JiaGouX」，作者若飞，2026-06-11 22:35 发布。
> 全文 ~9000 字，结构：判断 / 提示词 / 控制层 / 闭环 / 验证 / 预算 / 状态 / 人在场 / 试点 / 收束。
> 若飞是「架构师」公众号主笔，长期写 Harness Engineering 系列（前文《长周期 Agent 详解》《5 张卡治理框架》《再看 Harness Engineering》三篇已合并入 entities/long-running-agent-ralph-loop-handover-harness-ruofei）。本文是他将 Harness 体系**再往上推一层**——Loop Engineering——的首篇完整论述。

---

## 1. 判断：Loop 比 Prompt 更高一层

**Loop 不只是 cron，也不只是让 Agent 一直重复"继续优化"**——它更接近一个**带反馈的控制循环**。若飞的核心命题：

> "提示词解决的是'下一句话怎么说'，loop 解决的是'这件事怎么持续做、怎么知道做对、什么时候停'。"

若飞展开 Loop 的"五样必备 + 一条状态记忆"清单：

1. **自动触发**（自动化、定时任务、`/goal`、`/loop`）
2. **隔离工作区**（worktree、临时分支，避免并发覆盖）
3. **过程资产**（Skills、项目规则、计划模板，不每轮重新解释）
4. **外部连接**（MCP、插件、连接器、CLI，否则只能看本地文件）
5. **独立验证**（sub-agent / reviewer / 测试，避免自写自审）
6. **+状态记忆**（plan.md、issue、看板、日志，让下一轮能接上前一轮）

## 2. 提示词层 vs Loop 层

把"人不再写提示词"理解为二选一是误读——更准确的说法：

- 过去：人写 prompt → Agent 改一轮 → 人读 → 再写 prompt → 反复。**适合小任务和探索，不适合长任务。**
- Loop 处理：这些来回动作能不能**变成一个有状态的系统**——每日扫 CI 失败、拆任务卡、独立 worktree、A 修复 + B 复核、生成 PR 证据、不确定进人工队列、所有尝试写回状态文件。
- 提示词没消失，只是从"聊天框里的手工输入"升级为"循环系统里的一个组件"（Skills / 任务模板 / 验证脚本 / 自动化流程）。

## 3. 控制层：Loop > Harness > Prompt

> "Model 负责推理，Tool 负责接触外部世界，Skill 负责沉淀做事方法，Sub-agent 负责分工，Harness 负责让整套东西跑起来、跑得住、跑完还能检查。**Loop 再往上走一层**。如果说 Harness 管的是'这一次任务怎么跑'，Loop 管的是'这类任务怎么持续发生'。"

这与现有 entity `entities/loop-engineering-addy-osmani-challengehub` 的核心叙事（Loop > Harness > Prompt）**完全一致**，但若飞加了**三层关系图（图 2：Prompt→Harness→Loop）**作为视觉锚定。

## 4. 把 Addy Osmani 的 5 模块翻译成 6 个工程问题

Addy Osmani 原文拆 loop 为：自动化、worktree、skills、plugins/connectors、sub-agents、状态记忆。若飞把"再细分"为 **6 个工程问题**（每个问题对应一个能力 + 解决的风险）：

| 问题 | 对应能力 | 解决的风险 |
|------|---------|-----------|
| 什么时候启动 | 自动化、定时任务、`/goal`、`/loop` | 靠人想起来才做 |
| 在哪里改 | worktree、隔离环境、临时分支 | 并行互相覆盖 |
| 按什么规则做 | Skills、项目规则、计划模板 | 每轮重新解释业务 |
| 能连到哪里 | MCP、插件、连接器、CLI | 只能看本地文件 |
| 谁来复核 | sub-agent、reviewer、测试 | 自写自审过于宽松 |
| 怎么接上下一轮 | 状态文件、issue、看板、日志 | 上下文中断和目标漂移 |

并把 6 问题聚成 **4 个"架构口"**：

- **触发入口**：谁能启动，多久启动一次，输入从哪里来
- **执行沙箱**：在哪个 worktree / 分支 / 临时环境里跑，能不能回滚
- **验收出口**：用哪些测试 / 日志 / 规则 / 人工复核来判定结果
- **状态账本**：这轮尝试、证据、失败原因、下一步写到哪里

## 5. 闭环 vs 开环

若飞强烈倾向**闭环先行、开环后置**：

- **闭环**：边界明确的小控制系统，目标写清楚、动作范围受限、反馈足够客观、停止条件能验证。例：CI 分流、链接检查、事实核验、依赖升级预检查。
- **开环**：Agent 可自己继续发现任务、扩展路径、决定下一步，**更"自主"也风险更高**——预算更难控、目标更易漂移、验证更依赖人工。
- **工程老经验**：先让一个小闭环跑稳，再谈更大的自动化。

## 6. 验证：5 项准入表

若飞给出一张**5 行 × 2 列**的 loop 准入表（这是本篇的**核心原创**之一）：

| 检查项 | 可以试 | 暂缓 |
|--------|--------|------|
| 输入 | 日志、issue、测试报告、文档（输入稳定） | 口头描述，边界每天变 |
| 输出 | 分类表、候选 PR、证据清单、风险说明 | 直接改核心逻辑，影响难评估 |
| 验证 | 有测试、lint、链接检查、可复现命令 | 只能靠人读一遍感觉对不对 |
| 权限 | 默认只读，写入走隔离分支 | 直接改主分支或生产配置 |
| 停止 | 有预算、时间、证据不足等停止条件 | 只写"继续优化"，没有退出点 |

> "五项里只要有两项落在右边，我一般会先补测试、补状态、补边界，再考虑自动 loop。"

**事实核验**被列为典型适合先入 loop 的场景：抽取文章断言 → 分头去官方文档 / 仓库 / 论文 / issue / commit 核对 → 标 已确认/来源不足/时间过期/推测/建议删除。**不动生产系统，验证标准清楚，错也只是多花点时间**。

## 7. 预算：Loop 任务卡模板

若飞给出一张**任务卡模板**（与现有 5 张卡治理框架互补——5 张卡是"工作流结构"，本任务卡是"loop 单次运行边界"）：

```
循环名称：每日 CI 分流
触发频率：每天 09:30
输入范围：过去 24 小时失败 job、最近 20 个 commit
最大运行：30 分钟
最大分支：一次最多处理 5 个失败簇
权限：默认只读；修复必须进入独立 worktree
验证：只运行相关测试，不跑全量回归
停止条件：无新失败、证据不足、预算到达、需要人工决策
交付物：失败分类表、可复现命令、候选 PR、剩余风险
```

> "这张卡看着普通，但它把几件事说清楚了：loop 能看什么、能改什么、最多跑多久、哪些情况要停、什么算完成、人什么时候接手。**这些边界如果不写，loop 会很快变成一个乐观的 while 循环。**"

**关键警告**："momentum 不是 progress。动静很大，不代表系统真的变好了。"

## 8. 状态：plan.md 是 Loop 的"对话之外记忆"

Ralph loop 的关键提醒：每一轮都重新读取外部文件 + 当前仓库状态，而不是指望聊天窗口记住一切。

若飞强调**loop 不能只把记忆放在对话里**——长任务里"每轮都像新来的同事"，上下文会压缩、截断、被冲淡；**人第二天也会忘**。需要 plan.md / issue / 看板 / 数据库 作为对话之外的状态载体。

若飞给出一份**plan.md 模板**（这是本篇的**第二个核心原创**）：

```markdown
## 当前目标
修复订单导出最近 24 小时的 CI 失败。

## 已尝试
- 读取 job 1324 日志，失败点在 export timeout。
- 检查最近 20 个 commit，疑似与批量查询改动有关。
- 尝试增加超时，不通过，已回滚。

## 已验证
- 单测 `OrderExportTest.test_large_batch` 复现失败。
- 小批量导出正常。

## 禁止事项
- 不改权限模型。
- 不改导出文件格式。

## 下一步
- 对比批量查询前后 SQL。
- 如无法定位，交给人工看慢查询日志。
```

> "这份文件不复杂，但它能让下一轮 loop 接上前一轮，也能让人快速看懂它到底做了什么。**如果没有状态记忆，loop 就会变成一串断开的 prompt。看起来连续，实际上每轮都在重新开始。**"

## 9. 人在场：5 条保守原则

Loop Engineering 容易被误读为"人从流程里拿掉"。若飞明确反驳：

> "Loop 越强，人的判断越要提前出现。"

5 条偏保守的原则（**第三个核心原创**）：

1. **先只读，后写入**
2. **先低风险，后核心路径**
3. **先小频率，后高频率**
4. **先人工确认，后自动合并**
5. **先写停止条件，再写继续条件**（"很多自动化出问题，不是因为不会继续，而是因为不知道什么时候停"）

**成熟 loop 应能诚实说**："我没有足够证据继续 / 这次修改超过了授权范围 / 预算已经到达 / 验证结果不稳定 / 需要人做产品判断"——**比起"我继续试试"，这种回答更接近工程系统**。

## 10. 7 天试点模板

若飞给出一个**7 天可验证循环**的试点时间表（**第四个核心原创**）：

| 天 | 任务 |
|----|------|
| 1 | 选场景：CI 分流、文档链接检查、技术稿事实核验等低风险任务 |
| 2 | 写任务卡：输入范围、权限、预算、停止条件、交付物 |
| 3 | 做 Skill：把项目规则、常见误区、验证命令、输出格式写成 Skill |
| 4 | 接状态记忆：plan.md / issue / 看板记录已尝试、已验证、阻塞、下一步 |
| 5 | 跑一次手动 loop：人手动触发每一步，看哪些需要自动化 |
| 6 | 加自动触发：固定频率 + 时间上限 + 预算上限；输出先入人工 inbox，不自动合并 |
| 7 | 复盘：看 命中率/误报率/回滚率/成本/证据 5 指标 |

**复盘 5 指标**（**第五个核心原创**）：

| 指标 | 看什么 | 先到什么程度算可继续 |
|------|-------|------------------|
| 命中率 | loop 找到的问题里，有多少确实值得处理 | 人工复核后仍有稳定收益 |
| 误报率 | 有多少输出会浪费人的时间 | 不影响日常节奏 |
| 回滚率 | Agent 写入后有多少需要撤回 | 写入先控制在候选分支 |
| 成本 | token、运行时间、工具调用次数 | 账单和收益能对上 |
| 证据 | 每个结论有没有来源、命令、日志、测试结果 | 人能在 5 分钟内复核一轮 |

## 11. 收束

若飞对 loop 的态度：**可以试，值得学，不用神化**。

- 能放大已经清楚的工作流，但想清楚工作流这件事仍在人这里
- 能持续处理可验证的小闭环，但模糊的业务判断仍要有人负责
- 能让工程师少做重复操作，但不能让工程师少理解系统
- **循环越自动，人的判断越要在场**——"loop 本身不知道你是在加速理解，还是在逃避理解。"

> "这道分界线，最后还是要由人负责。"

## 12. 参考来源（若飞文中列出）

- Addy Osmani：《Loop Engineering》https://addyosmani.com/blog/loop-engineering/
- OpenAI Developers：Using Goals in Codex / Codex Automations / Codex Agent Skills
- Anthropic：Enabling Claude Code to work more autonomously
- Claude Code Docs：Hooks reference
- Peter Steinberger 相关 X 讨论聚合
- Blake Crosley：《Loops Win Where Verification Is Cheap》
- Gergely Orosz 关于 loop 适用面与 token 预算的讨论
- Graham Neubig 关于 basic agent loop 的讨论
- Garry Tan 关于不要把 Agent 做成机械重复工厂的讨论
- AlphaSignal：《Most Developers Do Not Need Agent Loops Yet》

## 13. 若飞相关延伸阅读

- 《长周期 Agent 详解：从 Ralph Loop 到可接管 Harness》（若飞 2026-05-21）→ entities/long-running-agent-ralph-loop-handover-harness-ruofei
- 《Hermes Agent 长周期治理：5 张卡框架》（若飞 2026-06-01）→ 同上 entity
- 《再看 Harness Engineering：可删的工作现场》（若飞 2026-06-10）→ 同上 entity
- 《Harness 之后：状态边界与失败闭环》→ entities/harness-之后-状态边界与失败闭环-若飞
- 《Claude Code Agent Teams 任务分解》→ entities/claude-code-agent-teams-task-decomposition-ruofei
- 《Claude Code 18 Actions 个人 AI 工作台》→ entities/ruofei-claude-18-actions-personal-ai-workbench

---

> → [[entities/loop-engineering-addy-osmani-challengehub|合并到 Loop Engineering 主 entity（4th source）]] ^[raw/articles/loop-engineering-工程现场-ruofei.md]