2026-06-28 / 图片资料归档

Loop Engineering：从“人追着 Agent 跑”到“系统驱动 Agent 跑”

基于 15 张 Loop Engineering 图片资料，结合 Addy Osmani 原文、OpenAI Codex、LangChain/LangGraph、Claude Code 与 loop-engineering 开源仓库，整理给技术同事和领导都能读的工程报告。

图片批次：15 张 读者：技术团队 / 技术管理者 判断：先做 report-only loop

结论

Loop Engineering 不是一个新模型，也不是某家厂商的新协议。它更像一层“任务运行时”：系统定期或被事件触发，读取状态，判断下一步，调用 Agent 或工具，验证结果，写回记录，并在需要时交给人。

对技术同事

它的落点不是 prompt，而是 state、scheduler、queue、tool allowlist、worktree、skill、subagent、verifier、run log 和 human gate。

对领导

它的价值不是“让 AI 自己干活”这么粗，而是把可重复的工程运营动作做成有证据、有预算、有停机条件、有责任边界的自动化流程。

和 Harness 的关系

Harness 管一次 Agent run 怎么可靠执行；Loop 管多次 run 怎么跨时间持续推进。没有 Harness，Loop 会重复放大错误；没有 Loop，Harness 很难变成持续运营能力。

建议起步方式

从 L1 report-only 开始：只扫描、归类、写报告和提醒，不直接改代码。稳定后再进入 L2 低风险 PR，最后才考虑 L3 半无人值守。

图片归档

本批次共 15 张图，主题可以合并成 8 个信息簇。第 8/10 张是 worktrees 近重复，第 9/11 张是 skills 近重复，报告中合并处理。

01-05概念定义：Loop Engineering 不是模型、协议或神奇框架，而是“发现、计划、执行、验证、记录”的系统循环。
06递归目标：给定目标后持续迭代，直到完成、阻塞、超预算、越权或需要人补充输入。
07Automations：定期或后台重复任务，把结果进入 triage，无结果自动归档，并可接 skills。
08 / 10Worktrees：多个任务并行推进时，用独立 checkout 隔离文件、状态、diff 和测试结果。
09 / 11Skills：把项目知识、流程、脚本和资产写下来，防止 Agent 每次从头猜。
12Subagents：把研究、写作、验证拆给不同上下文和权限的子任务。
13Memory / State：状态不能只放在对话框里，要放到外部文件、数据库、队列或 run log。
14-15生态信号：OpenAI、Claude Code、LangChain 和开源仓库都在补 loop plumbing，npm 工具也已出现。

概念边界

图片里最关键的一句话是：不是你去 prompt agent，而是你设计那个会 prompt agent 的 loop。这句话把设计对象从“单条指令”移到了“循环系统”。

Loop 的最小骨架 发现 CI / PR / Issue 计划 分派 / 优先级 执行 Agent / Tool 验证 Tests / Review 记录 State / Log 停止条件：完成、阻塞、预算耗尽、权限越界、置信度不足、需要人工确认。

这也解释了它和 prompt engineering、context engineering、harness engineering 的区别：prompt 负责表达意图，context 负责给模型正确上下文，harness 负责一次运行的工具和沙箱，loop 负责跨时间的调度、状态、验证和交接。

工程积木

积木它解决什么问题工程要求
Automations让任务按时间或事件重复运行，而不是等人想起来再问。调度周期、空结果归档、结果进入 triage、失败告警。
Worktrees让多个后台任务并行，不互相污染文件、依赖和测试输出。每个任务独立 checkout、独立 diff、独立测试、合并前 review。
Skills把项目规则和重复流程沉淀成可复用知识。SKILL.md、脚本、参考资料、资产、触发条件和维护 owner。
Subagents让研究、实现、验证分开，降低上下文污染和权限混杂。角色边界、工具权限、输入输出契约、maker/checker 分离。
Memory / State让下一轮知道上一轮做了什么，而不是依赖聊天窗口记忆。STATE.md、数据库、队列、run log、artifact、失败原因和下一步。
Budget / Gate防止无人值守任务持续花钱或持续犯错。token 上限、重试上限、写操作审批、发布 gate、kill switch。

具体实现

可以把实现拆成两层：外层用 CLI 或调度器把 loop 跑起来，内层用 LangGraph 这类状态图框架定义任务流。二者不冲突，反而适合组合。

方案 A：CLI 定期跑任务

0 */2 * * * cd /repo && loop run --task ci-triage --write-report

# 或用 GitHub Actions / OpenClaw cron：
# 1. 拉取 repo 和远端状态
# 2. 读取 CI / issue / PR / STATE.md
# 3. 调用 Agent 或脚本做归类
# 4. 输出 run-log、报告、必要时发通知

这种方式适合第一阶段落地，因为简单、可审计、可回滚。把输出限制为报告、评论草稿和 issue 标注，先不直接合并代码。

方案 B：用 LangGraph 定义任务流

State = {
  goal,
  phase,
  evidence,
  attempts,
  budget,
  owner,
  next_action
}

collect -> classify -> draft -> verify -> {
  commit_if_safe,
  ask_human,
  stop
}

LangGraph 的核心抽象是 State、Node、Edge：State 保存当前快照，Node 执行计算或副作用，Edge 决定下一步。对 Loop Engineering 来说，它刚好对应“状态决定下一步”的控制逻辑。需要人工审批时，可以在高风险节点触发 interrupt，保存状态并等待人恢复。

关键设计原则

  • 读和写分级：读日志、读 PR、读 issue 可以自动；写评论、开 PR、改文件要进审批或 allowlist。
  • 副作用后置：先 collect、classify、draft、verify，最后才做 commit/comment/deploy。
  • 验证独立：实现者和检查者分开，至少在 L2 之后引入独立 verifier。
  • 状态外置：每轮都写 run log，包括输入、判断、证据、成本、失败原因和下一步。
  • 停止条件显式：done、blocked、over budget、needs approval、low confidence 都要能停。

落地路线

阶段开放能力适合任务验收指标
L1只读、归类、写报告、提醒。CI 失败日报、issue triage、依赖风险扫描、PR 等待状态汇总。误报率、遗漏率、人工节省时间、报告可读性。
L2可开低风险 PR，但不自动合并。文档修正、测试补充、依赖小版本升级、lint 修复。PR 通过率、review 修改次数、回滚次数、平均恢复时间。
L3allowlist 内半无人值守，强 gate。固定模板变更、可逆脚本、低风险配置同步。自动完成率、人工接管率、成本上限命中率、事故数。

对组织来说，最重要的不是一开始就追求无人值守，而是让 loop 先产生可信记录。只要记录稳定，后续每开放一个动作都有证据支撑。

案例：CI 失败分流 Loop

  1. 每 30 分钟由 cron 或 GitHub Actions 触发一次。
  2. 读取最近失败的 CI run、相关 PR、diff、owner 和历史 run log。
  3. 分类为环境问题、测试不稳定、真实回归、依赖问题、未知问题。
  4. 对环境问题和 flaky test 生成报告或 issue comment 草稿。
  5. 对低风险文档/测试修复，在独立 worktree 开 PR，并附上证据。
  6. 对真实回归或未知问题，交给 owner，并带上日志、复现命令和失败分类理由。
  7. verifier 单独检查 PR diff、测试结果和成本，再决定继续、停止或升级。
  8. 把本轮输入、判断、产物、失败原因、花费和下一步写回 STATE.md / run log。

这个案例的业务价值很清楚：它不是替代工程师判断，而是把重复的收集、归类、证据整理和低风险修复前置处理掉，让工程师只处理真正需要判断的部分。

验证来源