← 返回藏书阁

Loop Engineering

wiki/ai/concepts/Loop-Engineering.md
分类：ai / concepts · 更新：2026-07-25 09:09

Loop Engineering

定义

Loop Engineering 是把人从“逐轮提示 agent 的操作者”升级为“设计提示 agent 的系统的人”。

Addy Osmani 的定义最直接：Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead.

也就是说，传统用法是：人给 prompt → agent 做一段 → 人检查 → 人再给下一条 prompt。Loop Engineering 关注的是把这个外层人类循环自动化：系统自己发现任务、分派给 agent、检查结果、记录状态、决定下一步，并持续迭代直到达到可验证的停止条件。

它解决的核心问题

Loop Engineering 解决的是：agent 如何持续工作、何时继续、何时停止、失败后如何恢复。

一个好的 loop 至少回答四个问题：

  1. 每一轮 agent 做什么？例如发现任务、计划、执行、调用工具、写代码、生成报告。
  2. 什么触发下一轮？例如定时器、CI 失败、issue、工具结果、状态文件变化。
  3. 什么叫完成？例如测试通过、报告满足结构与引用要求、PR 已开并通过 reviewer。
  4. 出错或停滞怎么办？例如重试、降级、交给 verifier、升级给人类。

常见循环结构

实践中常见的 coding-agent loop 是：

  1. Discover：发现工作，来自 CI、issue、日志、用户 backlog、监控告警。
  2. Plan：把目标拆成步骤，并读约束、规范、技能、上下文。
  3. Execute：agent 执行修改、调用工具、写文件、跑测试。
  4. Verify：用测试、lint、类型检查、事实核查、critic agent 或 human gate 反推结果是否成立。
  5. Iterate：若未达标，把失败证据重新喂给 agent；若达标，记录状态并进入下一项。

关键点：verify 不能只靠模型自己说“我完成了”。 没有外部可验证信号的 loop 很容易变成 agent 自说自话的“slop machine”。

Addy Osmani 的六个组成部分

Osmani 把 loop 拆成五个 primitive 加一个 state/memory：

  1. Automations：定时或事件驱动地发现和触发任务。
  2. Worktrees / isolated workspaces：隔离并行 agent，避免互相覆盖。
  3. Skills：把项目知识、流程和约束写成可复用说明。
  4. Plugins / connectors：连接 GitHub、Linear、CI、数据库、Slack、MCP 等外部系统。
  5. Sub-agents：把 explorer、implementer、reviewer、verifier 等角色拆开。
  6. State / memory：把进度、计划、完成证据写到模型外部，如 markdown、issue、数据库、状态文件。

Ralph 技术：早期形态

Ralph 技术可以看作 Loop Engineering 的原型：

while ! grep -q "ALL TASKS DONE" STATUS.md; do
  claude -p "Read PLAN.md and STATUS.md. Pick the next unchecked task, implement it, run tests, commit on success, update STATUS.md. Then stop."
done

它的关键洞察是：每轮 agent 都是新上下文，模型会忘，但 repo 和状态文件不会忘。状态放在模型外部，loop 负责把下一轮重新启动起来。

2026-07-07 补充：生产维护 Loop 的五动作六组件

[[loop-engineering-autonomous-log-to-stagingLoop Engineering 实战：从日志扫描到预发部署的全自主闭环]] 提供了一个更接近生产维护的案例：Loop 不只是“自动反复调用 agent”，而是把发现、交付、验证、持久化、调度五个动作接成系统；工程组件上则依赖 Connectors、Automations、Skills、Worktrees、Sub Agents、State 六件套。

这篇案例的关键价值在于把 Loop 的边界讲清楚：Harness 解决单次 agent run 的工具、权限和完成条件，Loop 在其外层增加自动发现、跨轮状态和调度。没有验证器或状态的自动化，只是更快地重复 prompt；有独立验证、外部状态、最大重试次数和人类审批边界的系统，才有可能成为可运营的循环。

对 Hermes 来说，cron 巡检、wiki radar、ConversationSpec 发布链路都应按这个模型审视：输入源是否足够真实，状态是否落在模型外，验证是否独立于生成者，失败是否有 HOLD/升级路径，生产动作前是否保留 human gate。

2026-07-10 补充：Loop 的产物应反哺 workflow 本身

[[tthe-test-time-harness-evolutionTTHE]] 提醒：Loop 每轮产生的执行轨迹不仅是状态记录，也可以成为改进下一轮 harness 的训练信号。对 llm-wiki radar 来说，候选来源、评分、未入库原因、访问失败、验证输出、薄页面风险，都是下一次搜索/晋升策略的输入。
[[workflow-as-knowledge-semantic-persistenceWorkflow as Knowledge]] 则补充：Loop 的定义、实例、context snapshot 和依赖关系本身应成为知识对象。这样 cron 不只是“每天跑一次”，而是一个可审计、可恢复、可演化的 workflow。实践上，应把低风险优化写入当天 llm-wiki-optimization-* 页面，把高风险优化列为建议，避免无人 loop 过度自我修改。

2026-07-23 补充：本地治理工作台与 AKM 成熟度评估让 loop 可运营

[[pm-manager-local-project-governancePM Manager]] 把 coding-agent 日常工作包装成 repo-local .pm/ workbench：每日 Top3、incident triage、release scan、dashboard、slash commands 和 agent adapters。它说明 Loop Engineering 需要外部化优先级和健康状态，否则 agent 容易被最近输入或低价值噪音牵引。对 llm-wiki radar 来说，候选池、未入库原因、访问失败、vector/lint 失败和明日 Top3 follow-up 也应逐步进入轻量状态区，而不是只散落在自然语言日报里。
[[akm-eval-agentic-knowledge-managementAKM Eval]] 则把 agentic knowledge management 的成熟度拆成 Prompt、Context、Harness、Loop、Interop/Governance 五层，并要求 artifact evidence。它提醒：Loop 是否“复利”不能靠自我感觉，而要看 30 天运行证据、系统是否修复系统、跨 runtime 是否可恢复和可治理。对 Hermes 来说，每日优化页应区分“建议”和“已执行低风险修正”，并留下证据路径。

风险

Loop Engineering 不会消除风险，只是把风险从“人手动检查每一步”上移到“系统设计得是否足够可靠”。主要风险：

  • 验证弱：loop 会更快地产出错误结果。
  • 成本失控：定时 loop、verifier、sub-agent 会持续消耗 token。
  • 权限过大：无人值守 agent 可能带着人的凭证到处行动。
  • 理解债：agent 改得越快，人越可能跟不上系统实际状态。
  • 自动化蔓延：企业里多个团队复制不同 loop，缺少统一审计、预算、权限和生命周期管理。

实践原则

  1. 从小、闭环、可验证任务开始。
  2. 每个 loop 必须有明确停止条件和最大迭代/预算上限。
  3. maker 和 checker 尽量分离。
  4. 状态放在模型外部，最好版本化。
  5. 关键动作保留 human-in-the-loop。
  6. unattended loop 一旦进入生产，就需要身份、权限、审计、成本、告警和回滚。

与 Harness Engineering 的关系

一句话：Harness Engineering 让一次 agent run 更可靠；Loop Engineering 让可靠的 run 自动重复，并替代人类逐轮检查和再提示。

Harness 是 agent 的运行环境；Loop 是 agent 的工作节奏和外层控制系统。

2026-06-23 补充：cron 也是最小 loop

Karpathy X Radar 的实践显示，最小可用 loop 不一定是复杂平台；一个 cron job 也可以是 loop，只要它具备稳定输入、rubric、外部状态、写入日志和清晰停止条件。今天的 radar 在 X API 不可用、web_search 限额的情况下仍能完成：orient → fallback search/extract → 按 relevance/novelty/durability/actionability/source_quality 打分 → 写 raw note → 只更新高价值已有页面 → 记录 log。

这说明 Loop Engineering 的核心不是“无人值守跑很久”，而是每次循环都可审计、可降级、可复盘。对 Hermes cron 而言，raw note 和 log.md 就是 loop memory；rubric 和 wiki schema 是外部化的判断标准；不新增低价值页面是停止条件的一部分。

2026-07-18 补充：Loop 状态必须由证据门控推进

[[proof-or-stop-evidence-gated-lifecycle-controlProof-or-Stop]] 把 Loop Engineering 的停止条件从“agent 说完成”推进到“证据允许生命周期状态前进”。它的关键不是让 agent 更诚实，而是让 DONE、reviewed、ready-to-merge 这类状态只有在 fresh、绑定当前 source state、可机械复查的 receipt bundle 存在时才可被下游系统消费。

对 Hermes cron / wiki radar 来说，这意味着每轮 loop 的最终报告应尽量保留 claim-level receipts：创建了哪些文件、更新了哪些页面、是否检查了 index/log、是否重建向量索引、哪些来源不可访问。失败或证据不足时，正确状态不是“可能完成”，而是 HOLD / raw-only / not promoted。

2026-07-19 补充：无人 loop 需要身份、授权与回归测试

[[chancery-agent-identity-writ-controlChancery]] 提醒长期 loop 不应共享一个无边界“助手”身份：cron、orchestrator、worker 和 verifier 应有可撤销身份、TTL、只缩窄不扩大的授权和 metadata audit。[[coder-eval-skill-evaluation-cicoder_eval]] 则补上 loop 的回归面：循环本身、它使用的 skills、它依赖的上下文与工具面都可能随模型/提示/依赖变化而退化，因此需要 scheduled eval 或至少结构化 checklist。

对 llm-wiki radar 来说，低成本落地方式是先记录每个 loop 的 identity manifest（目的、读写路径、网络范围、最大运行时间、输出目标）和最小 eval checklist（orient、raw hash、index/log、写入记录、未入库原因、验证/跳过说明）。这比直接引入重型控制平面风险更低。

2026-07-22 补充：长期 loop 的动作历史也需要可验证完整性

[[halo-record-runtime-recordsHalo Record]] 把 loop memory 从状态文件和自然语言 log 推进到 hash-chained runtime records：每个 tool call、model call、data access 和 approval 都能进入 append-only chain。对长期无人 loop 来说，这解决的是“报告声称做过”和“可验证地做过且记录未被篡改”之间的差距。

对 llm-wiki radar 的低风险落地不是立刻全量记录所有 read/search，而是先为 effectful boundary 建简化 action ledger：raw 写入、wiki 页面写入、index/log 更新、vector reindex、发布/外发、失败和 HOLD。这样既避免过度记录敏感上下文，又能让最终报告里的关键 claim 有 receipts。

2026-07-24 补充：长任务 loop 需要跨宿主 adapter 与单任务 bounded loop

[[octopus-skill-long-horizon-agent-disciplineoctopus-skill]] 提醒，长任务 loop 的核心方法论应与宿主差异分离：executor / clean-context supervisor / durable files 是通用纪律，Claude Code、Codex、Cursor、grok 的 loop/goal/stop/notification 只是 adapter。[[agentops-bounded-operating-loopAgentOps]] 则把单个 coding task 压缩为 RPI、Plan、Implement、fresh Validate、durable verdict、report-and-stop 的 bounded loop。

对 Hermes cron 来说，外层每日 loop 不应无限扩展搜索；每个被选中的 source ingest 也应有内层 bounded loop：明确意图、只读验证 source、写 raw、写页面、检查页面合同、更新 index/log、reindex、报告并停止。跨宿主适配的启发是：同一套 llm-wiki 方法论可以服务交互式问答、cron radar、批量书籍 ingest 和发布任务，但每个 adapter 都要显式声明权限、停止条件与验证证据。

2026-07-25 补充：长期 loop 需要 control plane 和 meta-harness 边界

[[preloop-agent-control-planePreloop]] 说明，一旦 loop 会持续调用工具、花费模型预算、触碰本地/生产资源，就需要把 tool calls、model calls、approval、spend、policy decision 和 outcome 放进统一 runtime control plane，而不是只依赖 prompt 约束。[[omnigent-meta-harnessOmnigent]] 则说明 loop 可能跨多个 agent、设备、sandbox 和协作者运行，外部状态不仅是 STATUS.md，还包括 session、terminal、files、sub-agents、policy 和 sandbox lifecycle。

对 Hermes cron 来说，这把 Loop Engineering 的最低要求再提高一层：每个无人 loop 都应声明读写范围、预算/时间上限、需要人工审批的动作、失败/HOLD 状态和关键 action ledger。meta-harness 方向有价值，但无人 cron 不应自动安装或改写 agent runtime；这类控制面接入属于高风险操作，需要用户确认。

写入记录

  • 2026-07-25 09:00 CST：补充 Preloop 与 Omnigent 对长期 loop control plane、multi-agent session、sandbox 和 action ledger 边界的启发。
  • 2026-07-24 09:01 CST：补充 octopus-skill 与 AgentOps 对跨宿主 loop adapter、clean-context supervisor 和 bounded operating loop 的启发。
  • 2026-07-23 09:00 CST：补充 PM Manager 与 AKM Eval 对本地治理工作台、候选/失败状态、成熟度证据和系统自修复评估的启发。
  • 2026-07-22 09:00 CST：补充 Halo Record 对无人 loop action ledger、tamper-evident runtime records 与 claim receipts 的启发。
  • 2026-07-19 09:04 CST：补充 Chancery 与 coder_eval 对无人 loop 身份/授权、TTL、audit 和 scheduled regression eval 的启发。
  • 2026-07-18 09:00 CST：补充今日 radar 对证据门控、上下文质量、技能安全或控制原语的启发。
  • 2026-07-07 09:29 CST：补充阿里云开发者 Loop Engineering 生产维护案例，提炼五动作六组件与 Hermes loop 审视清单。
  • 2026-07-10 09:00 CST：补充 TTHE 与 Workflow as Knowledge 对 loop 轨迹反哺、workflow 对象化和无人自我修改边界的启发。
藏书阁 · Published from llm-wiki · 2026-08-03 09:15:52