Loop Engineering：从提示词走向可运营的 Agent 循环
基于 Addy Osmani 的 loop engineering 文章、Agent Harness Engineering、Anthropic 长运行 agent / effective agents 文章、cobusgreyling/loop-engineering 实践仓库，以及 loop-engineering-orange-book 整理。
核心判断
1. Loop 是运营层，不是模型能力层
它关注的是系统如何定时或被事件触发，如何读取状态、调用技能、分派子代理、验证结果、记录进度，并在不确定时交给人。
2. Harness 是内层运行环境
Harness 包括 prompt、tools、context policy、sandbox、hooks、subagents、observability。它让一次 agent run 更可靠。
3. Loop 必须建立在 Harness 之上
没有可靠 harness，loop 只是把不可靠行为重复更多次；没有 loop，harness 只能改善单次任务，无法形成持续运营。
4. 第一个 loop 应该 report-only
先让系统发现、整理和记录，不自动改代码。等信号质量稳定，再逐步开放低风险动作。
概念定义
Loop engineering 可以定义为：为 AI agent 设计一个可重复运行的外部控制循环，使它能够按固定节奏或事件触发发现任务、读取上下文、调用技能、分派子代理、隔离执行、验证结果、更新状态，并在高风险或不确定时交还给人。
| 发现 | 定时或事件触发，扫描 CI、PR、issue、数据源、日志、消息和外部信号。 |
|---|---|
| 归类 | 调用 triage skill，把信号分成噪音、建议、待行动和需要人判断的事项。 |
| 分派 | 为可行动项开 worktree，交给实现 agent、研究 agent、测试 agent 或专门技能。 |
| 验证 | 由独立 checker 运行测试、审查 diff、核对证据、判断是否满足停止条件。 |
| 记录 | 把尝试、结果、失败原因、下次动作和人类决策写入外部 state。 |
| 升级 | 遇到高风险、歧义、多次失败或预算超限时，带上下文交给人。 |
这套流程里最关键的不是“循环”两个字，而是循环外部的工程约束：状态文件、预算、权限、停止条件、回滚路径、观察指标和人类交接规则。
为什么现在流行
工具原语成熟
调度、skills、MCP connector、subagent、worktree 这些能力已经从自建脚本变成主流 agent 工具的内置能力。工程师开始能把 agent 从“一次聊天”变成“周期性后台流程”。
单次 prompt 的边际收益下降
复杂工程任务的问题不只是模型听不懂，而是它需要跨多个运行窗口保持上下文、处理失败、避免重复劳动、控制成本并知道何时停止。单次 prompt 很难承担这些运营职责。
长任务暴露记忆断层
Anthropic 的长运行 agent 经验强调，多窗口任务会遇到“每个新 session 都像新人接班”的问题。Loop 的 state/memory 机制就是为了解决跨运行交接。
团队开始关心运营指标
当 agent 从玩具变成团队工具，问题从“能不能生成代码”变成“能否降低响应时间、减少人类扫尾、稳定处理重复流程”。这天然需要 loop，而不是更多聊天。
与 Harness Engineering 的区别
| 维度 | Harness Engineering | Loop Engineering |
|---|---|---|
| 关注层级 | 单个 agent run 的上下文、工具、沙箱、提示、hook、观察性。 | 跨运行、跨时间、跨任务的发现、分派、验证、记忆和升级。 |
| 核心问题 | 怎样让这个 agent 在这次任务中不迷路、不误操作？ | 怎样让系统每天/每小时自己发现该做什么，并可靠推进？ |
| 典型产物 | AGENTS.md、skill、工具描述、沙箱规则、hook、测试命令。 |
STATE.md、调度器、run log、budget、watchlist、handoff inbox。 |
| 失败模式 | 工具危险、上下文不够、prompt 不清、验证缺失。 | 重复修错、状态漂移、通知疲劳、成本失控、无人确认却自动行动。 |
一句话：Harness 是给 agent 配工具、护栏和验收标准；loop 是设计班次、工单流、质检、交接记录和升级机制。
工程实践
1. 从 report-only 开始
第一个 loop 不要自动改代码。最稳妥的起点是 Daily Triage：每天或每 2 小时读取 CI、issue、PR、近期 commit、项目状态，输出优先级清单，写入 STATE.md。运行一周后，对比它与人工判断的差异，再决定是否放开行动权限。
2. 把任务写成 skill，而不是写成长 prompt
Loop 的 prompt 应该短，真正的项目规则放在 skill 里。例如 loop-triage 规定如何读 CI、如何判定优先级、输出格式是什么；minimal-fix 规定小修复边界。
3. 会写文件的 loop 应该使用 worktree
并行 agent 最常见的灾难是互相覆盖文件。worktree 把不同 agent 的改动隔离在不同 checkout 里，让并行探索从机械上可控。
4. Maker 与 Checker 必须分离
写代码的 agent 不应该给自己判定“已完成”。至少需要一个独立 verifier：检查 diff 是否只改目标范围、测试是否真的跑过、有没有安全/权限/依赖风险。
5. 状态文件是 loop 的脊柱
每次运行都要先读状态，结束时写状态。最低限度记录：上次运行时间、发现项、行动项、尝试次数、失败原因、等待人类决策的事项、已关闭事项。
6. 预算和停止条件写进系统
高频 loop 很容易烧 token。PR babysitter 或 CI sweeper 每 5 分钟跑一次，如果没有 early exit、预算上限和最大尝试次数，会迅速变成成本黑洞。
GitHub 仓库拆解
cobusgreyling/loop-engineering 的价值不只是整理概念，它更像一个“loop engineering 参考实现”：用文档定义方法论，用 patterns 把方法论产品化，用 starters 降低采用门槛，用 skills 固化执行规则，用 CLI 工具做评分、成本估算和脚手架，再用 GitHub Actions 在仓库自己身上运行这些规则。
| 层级 | 仓库里的对应物 | 工程含义 |
|---|---|---|
| 概念层 | docs/primitives.md、docs/loop-design-checklist.md、docs/safety.md、docs/operating-loops.md |
把 loop 拆成调度、状态、技能、验证、预算、升级等原语，避免大家把它误解成“定时 prompt”。 |
| 模式层 | patterns/*.md、patterns/registry.yaml |
把常见 loop 做成可选模式，例如 daily triage、PR babysitter、CI sweeper、dependency sweeper。registry.yaml 让模式可以被工具读取。 |
| 脚手架层 | starters/*、templates/* |
把“我想试试”变成“复制一套最小可运行结构”。每个 starter 通常包含 LOOP.md、state 示例、预算和运行日志模板。 |
| 技能层 | skills/loop-triage、loop-verifier、loop-budget、minimal-fix |
把执行纪律写进可复用 skill：如何 triage、如何验收、如何控制预算、如何限制小修复边界。 |
| 工具层 | tools/loop-init、loop-audit、loop-cost |
把方法论变成可运行命令：初始化 loop、检查成熟度、估算 token 成本。 |
| 运行层 | LOOP.md、STATE.md、loop-budget.md、loop-run-log.md、.github/workflows/* |
仓库自己 dogfood：记录活跃 loop、预算、状态、运行历史，并用 CI 做 registry/audit 验证。 |
1. LOOP.md 是运营合同，不是普通 README
它列出当前活跃 loop：Daily Triage 是 L1 report-only，PR Babysitter 是 L2 assisted，Dependency Sweeper 是 L2 patch-only，Changelog Drafter 是 L1 draft-only。每个 loop 都有 cadence、状态文件、技能、允许动作和人类交接规则。这相当于把“自动化可以做什么、不能做什么、什么时候升级”写成仓库级合同。
2. loop-audit 把“成熟度”变成可检查信号
这个 CLI 会给项目打 0-100 的 Loop Readiness 分数，检查是否有 state file、triage skill、verifier、LOOP.md、AGENTS.md、safety docs、GitHub workflow、MCP/connectors、worktree evidence、registry、budget、run log 和真实活动证据。最重要的是 L3 不是“文件齐了就行”，还要求 verifier、状态、成本可观测性和 proven loop activity。
3. loop-cost 把 token 成本放到设计阶段
高频 loop 最大的问题不是写不出来，而是运行成本被 cadence 线性放大。仓库里的 cost model 区分 no-op、full triage、action every run 和 realistic blend。比如 CI sweeper、PR babysitter 这类 5-15 分钟级 loop，如果没有 early exit 和预算上限，很容易从“自动化助手”变成成本黑洞。
4. loop-init 解决采用门槛，但也暴露模板化风险
它可以按 pattern 和工具生成 starter，例如 daily-triage、pr-babysitter、ci-sweeper，并支持 Grok、Claude、Codex 等不同运行环境。好处是团队能快速起步；风险是容易 cargo cult：文件都复制了，但没有结合本项目修改 allowlist、denylist、状态字段、预算和验收标准。
5. Skills 是执行纪律的载体
loop-triage 要求只输出今天工程师真正该关心的高优先级事项；loop-verifier 默认从怀疑出发，要求检查 scope、测试、diff 和风险；loop-budget 在运行前检查预算和 kill switch，在结束时记录 run log；minimal-fix 限制 agent 只解决一个明确问题。这些 skill 把“经验丰富的工程师会怎么做”沉淀成可重复约束。
6. GitHub Actions 的 dogfood 很关键，但它不是魔法自治
daily-triage.yml 会更新状态、追加 run log、跑 validate/audit gates，并通过 PR 形式写回仓库。这个设计很实际：先用确定性 CI 和脚本承载 loop 外壳，再逐步加入 agent 能力。它说明 loop engineering 的第一步不是追求完全自主，而是把后台运行、状态变更、验证和人类 review 通路先搭起来。
仓库优点与不足
优点：方法论有可执行物
不是只讲概念，而是提供 starter、skill、registry、CLI 和 workflow。读完可以直接在项目里试一个 L1 loop。
优点：治理意识强
预算、运行日志、kill switch、human gate、denylist、maker/checker 分离都是默认一等公民。
优点：从 L1 到 L3 有梯度
先 report-only，再 assisted，再 unattended-capable，符合真实团队采用自动化的信任曲线。
不足：评分不等于业务价值
loop-audit 能检查结构完整性，但不能证明 loop 真能减少人工负担、降低故障时间或提高交付质量。
不足：安全多数仍是策略层
文档和 denylist 很重要，但更强的生产级方案还需要权限隔离、沙箱、密钥边界、审计日志和回滚机制配合。
不足：非代码场景样例还少
仓库以工程仓库维护为主。研究、投研、内容分析、知识库维护这类 loop，需要再抽象 object type、证据标准和发布 gate。
我的判断：这个仓库目前最适合当“loop 工程化检查表 + starter kit”，不应该直接当生产系统照搬。真正落地时，要把它的结构迁移到自己的工作流：明确数据源、状态字段、预算、动作边界、验收人和发布规则。
工程价值
响应速度
CI 红了、PR 卡住、issue 噪音增加时，不再等人主动巡检。
质量控制
Maker/checker 分离让验证成为流程，而不是事后补救。
组织记忆
state、run log、skills 把隐性经验变成可读资产。
并行吞吐
worktree + subagent 让探索、实现、验证可以并行，但仍受 review 边界约束。
运营化
Agent 不再只是“问一下”，而是团队工程系统中的 watcher、triager、drafter、sweeper。
治理
权限、记录、升级和停止条件显式化，自动化行为可以被审计。
风险与反模式
| 反模式 | 表现 | 治理方式 |
|---|---|---|
| Prompt cron | 只把长 prompt 放进定时器，没有 state、预算、验证。 | 补齐 state、run log、skill、early exit。 |
| 自我验收 | 同一个 agent 写代码并宣布完成。 | 独立 verifier；必要时更强模型或人工 gate。 |
| 无限修复循环 | 同一个 PR/CI 失败被反复修改，越修越乱。 | 最大尝试次数；三次失败自动升级给人。 |
| 通知疲劳 | 每次运行都 ping 人，导致人忽略真正信号。 | 只在需要决策、超预算或高风险时通知。 |
| 理解债务 | loop 产出越来越多，人越来越不理解系统。 | 定期读 diff、写决策记录、限制自动改动范围。 |
落地建议
| 阶段 | 目标 | 允许动作 | 退出条件 |
|---|---|---|---|
| L0 草案 | 定义 loop 目的、范围、非目标。 | 只写设计文档。 | 有 owner、cadence、数据源、状态格式。 |
| L1 报告型 | 自动发现和整理信号。 | 写报告、更新 state，不改业务代码。 | 连续一周信号质量稳定，噪音可控。 |
| L2 协助型 | 处理低风险小动作。 | 开 worktree、起草 PR、补测试、修格式。 | 验证通过率高，人工返工率低。 |
| L3 半无人值守 | 在 allowlist 内持续运行。 | 有限自动提交、自动评论、自动关单。 | 有预算、日志、审计、回滚和 kill switch。 |
推荐第一个 loop：Daily Research Triage
每天从指定来源发现高价值 AI engineering / agent engineering 信号，写入 research-triage-state.md：候选主题、证据链接、对象类型、优先级、建议动作。L1 阶段只整理，不自动发布；发布需要人确认。
| 组件 | 建议设计 | 原因 |
|---|---|---|
| 输入源 | Follow/RSS、GitHub trending、用户丢来的 URL、OpenClaw memory、已有报告索引。 | 先覆盖高信号入口，不追求全网爬取。 |
| 对象类型 | 博客文章、GitHub 仓库、技术点、论文/标准、产品发布、争议话题。 | 不同对象不能用同一套分析模板，否则会变浅。 |
| 分析模板 | 博客看论点链路；仓库看架构、文件结构、工具链、维护活跃度；技术点看定义、边界、替代方案和实践路径。 | 深度来自对象适配，而不是加长 prompt。 |
| 状态文件 | research-triage-state.md + research-run-log.md。 | 避免重复研究同一话题，保留上次判断和待验证假设。 |
| 预算 | 无新高信号来源时 early exit；深研任务单独申请预算。 | 日常 triage 低成本，深研按需启动。 |
| 发布 gate | L1 只产出候选；L2 可起草 Pages 报告；发布前保留人工确认。 | 研究报告会影响判断，不能把自动发布作为默认动作。 |
适合 OpenClaw / 个人工作流的三个候选
研究报告 loop
从 Follow、RSS、GitHub、博客里发现候选话题，先做 triage，再由人选题深研。
项目维护 loop
定时检查 Pages 发布、数据抓取、脚本失败、仓库状态，只在异常时提醒。
链接深读 loop
收到博客、GitHub 仓库或技术链接时，自动识别对象类型，选择对应分析模板。
PR/CI 辅助 loop
先只报告红灯和卡点，稳定后再允许小修复和 verifier 审查。
资料来源
- Addy Osmani: Loop Engineering — 提出 loop engineering 的主流定义，并把它放在 harness 之上。
- loop-engineering-orange-book — 中文/英文橙皮书，适合作为概念入门材料。
- cobusgreyling/loop-engineering — 实践型仓库，包含 primitives、patterns、starter、audit、cost 等材料。
- Anthropic: Effective harnesses for long-running agents — 长任务、多 context window、handoff artifacts。
- Anthropic: Building effective agents — workflows 与 agents 的区分，以及从简单可组合模式开始。
- Addy Osmani: Agent Harness Engineering — 定义 harness engineering，并说明 model 外部脚手架的工程价值。
- OpenAI Codex Automations — Codex 中 schedule、worktree、skills、sandbox 与自动化风险的说明。
- OpenAI Codex Agent Skills — skills 作为可复用 workflow authoring format 的说明。
- OpenAI Codex Subagents — subagents 并行探索、专门化和 token 成本的说明。