Loop Engineering

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

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

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

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

风险

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 状态必须由证据门控推进

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

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

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

2026-07-22 补充：长期 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

对 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 边界

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

2026-08-18 补充：Graph-Orchestrated Agent Loop

goal-flow-graph-orchestrated-agent-loop 展示了一个值得跟踪的 graph + loop 分层形态：Dify 负责可视化设计 workflow，转译器把 DSL 变成可版本化 LangGraph Python，agent loop 只作为 graph 中的开放式节点运行；同一框架还提供 DataAdapter、streaming/HITL、skills、模型路由和存储边界。

这对 Hermes / llm-wiki 的启发是：复杂 cron 不应无限加长 prompt，而应逐步把 Discover、Score、Fetch、Raw Archive、Promote/Reject、Verify、Report 这些阶段外部化为可检查 graph；agent 负责判断和综合，机械节点负责写入、验证和生成 receipt。这样每日雷达才更像可运营 loop，而不是一次长上下文问答。

2026-08-21 补充：长程电脑使用 loop 需要 checkpoint 与真实环境验证

对 Hermes / llm-wiki 来说，下一步不是把 cron prompt 写得更长，而是把每日 radar 拆成可恢复阶段，并记录 round ledger：候选、晋升/拒绝理由、source fetch 状态、写入文件、验证输出和 reindex receipt。这样无人 loop 才能在 API 限制、网页失败或上下文刷新后稳定恢复。

写入记录

• 2026-08-21 09:06 CST：补充 LongHorizon-Harness 对长程电脑使用 loop、checkpoint/recovery、真实环境验证和 radar round ledger 的启发。

• 2026-08-18 09:00 CST：补充 goalflow 对 graph-orchestrated agent loop、visual workflow → versioned code、agent node 分层和 wiki-radar graph 化的启发。
• 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 对象化和无人自我修改边界的启发。

2026-08-22 补充：长程 loop 需要跨通道状态验证和可重放 benchmark 轨迹

对 Hermes 来说，任何无人长程 loop 都应显式记录：当前状态来自 GUI、CLI、API、文件还是日志；哪些状态被跨通道复核；哪些状态只由模型报告而不可验证；失败恢复是否基于最新 verified state。否则 loop 越长，状态漂移和报告夸大的风险越高。

写入记录

• 2026-08-22 09:30 CST：补充 computer-use loop 的跨通道状态验证、版本化环境和轨迹可回放要求。

2026-08-23 补充：computer-use loop 需要可复制 runtime，coding loop 需要可分叉 trace

写入记录

• 2026-08-23 09:00 CST：补充 Cua 与 DM-Code-Agent 对可复制 runtime、trajectory export、可分叉 trace 和 radar receipts 的启发。

2026-08-24 补充：长期 loop 需要回归 eval、连续观察和规则租金

写入记录

• 2026-08-24 09:00 CST：补充 Agent Belt、AOI 与 Token Warden 对 loop 回归评测、连续观察和自我优化规则租金的启发。

2026-08-25 补充：桌面 loop 的 structured observation contract

对 Hermes 来说，未来任何 GUI/Obsidian/浏览器自动化 loop 都应优先要求 trace/export 与结构化 ref；若只能截图或自然语言自证，报告 confidence 应降级。

2026-08-26 补充：自我改进 loop 需要 frozen evaluator 与候选 lineage

对 llm-wiki radar 来说，这意味着每日“自我优化文章”不应只是经验沉淀，还应逐步绑定一个小型 frozen suite：模拟重复页、网页失败、浅内容 raw-only、深内容晋升、index/log/write-record 检查。只有在这个 suite 上稳定改善的规则，才应进入长期 cron/skill；没有证据的规则应进入 rule-rent review。

写入记录

• 2026-08-26 09:01 CST：补充 RSIHub 对 frozen evaluator、candidate lineage、archive records 和 llm-wiki radar 自我优化边界的启发。
• 2026-08-25 09:05 CST：补充 agent-desktop 对桌面 loop structured observation contract、snapshot/ref/trace 的启发。

2026-08-27 补充：团队级长期 agent 需要身份、runner 和审批控制面

对 Hermes / llm-wiki radar 来说，低风险迁移不是立刻引入重平台，而是先把每个 cron 看成一个具备身份和权限边界的 loop：声明读写路径、网络来源、最大时间、可写文件类型、HOLD 条件、action receipts 和人工审批边界。这样可以逐步防止长期自动化在“能力更强”的表象下扩大权限面。

写入记录

• 2026-08-27 09:00 CST：补充 OneCLI 对团队级长期 agent loop 的身份、runner、sandbox、approval 和 credential gateway 启发。

2026-08-28 补充：长程 loop 的状态推进必须依赖 receipt，而不是 narration

对 llm-wiki radar 自身，这意味着最终报告也应像 loop receipt：发现源、raw hash、source page、概念页补充、index/log 更新、reindex 输出都应可追溯；对 GUI/浏览器/移动端 agent，这意味着每个 action 后要明确 state 来自 tree、pixel、DOM、API 还是外部 verifier，不能让“我看起来完成了”推动下一轮。

2026-08-29 补充：长程 software loop 应优先 structured state 与 semantic action

对 Hermes 来说，这把 verified state path 进一步具体化：每轮推进前应知道 state 来自哪里，行动后应有 before/after structured diff；若只能依赖截图或 agent narration，则必须降低 confidence、增加 wait-stable/pixel diff/外部 verifier，或在高风险动作前 HOLD。

写入记录

• 2026-08-29 09:01 CST：补充 ASIL 对 structured state、semantic action、deepest feasible access path 和 long-horizon loop verified-state 的启发。

2026-08-30 补充：自演化 loop 与多执行者 loop 都需要持久化边界

写入记录

• 2026-08-31 09:00 CST：补充 attention-interface、ContextPilot、NOOA 和 dispatch-level instrumentation 对 loop 注意力政策、上下文行动、对象状态与 receipts 的启发。
• 2026-08-30 09:00 CST：补充 EVOMAL 与 AgentRoom 对自演化 loop 持久化边界、多执行者 coordination protocol 和长期状态审计的启发。

2026-08-31 补充：loop 的下一层稀缺资源是上下文行动与人类注意力

2026-09-01 补充：长期 loop 需要 runtime/gateway receipt，而不是只靠 agent narration

这把 Loop-Engineering 与 Harness-Engineering、Context-Engineering、Agent-Benchmarks 连成一个主题簇：context 决定 agent 可见工具面，harness 决定可执行权限和验证合同，loop 决定跨轮调度与注意力政策，benchmark 则评估 runtime/gateway/sandbox/security policy 是否真的降低失败率，而不是只让报告更像完成。

写入记录

• 2026-09-01 21:16 CST：补齐 MCP / Agent Runtime / Gateway 主题簇互链，明确本页在 runtime、context、harness、loop、benchmark 之间的分工。

2026-09-02 补充：长程 loop 需要可观察环境、程序化 gate 和最小工具 profile

对 Hermes cron / llm-wiki radar 来说，这对应四个 loop receipt：候选发现与拒绝理由、raw hash 与 source page、概念/index/log/reindex 写入证据、以及最终报告中每个完成声明的文件/命令支撑。若某个来源只能提供营销式 README、无法读原文或需要运行未知代码，则正确 loop 状态应是 raw-only / HOLD，而不是继续晋升薄页。

写入记录

• 2026-09-02 09:00 CST：补充 CUArena、da-verify、Bromure、Moor 对长程 loop 的可观察环境、程序化 gate、凭据边界和最小工具 profile 启发。

2026-09-02 补充：A2A 让 loop 进入跨 agent 长任务状态机

A2A-Agent2Agent-Protocol 使长期 loop 的状态不再只在单个 agent 内部推进。A2A task lifecycle、streaming、push notification 和 artifact 让一个 loop 可以委托给远程 agent 后等待、轮询、取消或接收异步更新。

因此 loop ledger 应记录 remote task id、delegated context、Agent Card/version、auth boundary、status update、artifact hash、verifier receipt 和责任归属；否则“远程 agent 说完成了”会成为新的 narration 风险。

写入记录

• 2026-09-02 21:23 CST：补充 A2A-Agent2Agent-Protocol 与本主题簇的关系，明确 A2A 在 agent-to-agent delegation、Agent Card、Discovery、task lifecycle 和实践案例雷达中的位置。

2026-09-03 补充：知识点雷达与自我优化入口

AI-Knowledge-Point-Radar 将长程 loop 的运行时、上下文行动和委托边界纳入雷达；LLM-Wiki-Optimization-Log 要求 loop 的机制改动沉淀为总览规则而不是散落在日报中。

写入记录

• 2026-09-03 21:00 CST：加强与 AI-Knowledge-Point-Radar、LLM-Wiki-Optimization-Log 的 wikilink 串联，统一从知识点价值和机制闭环维护本页。