Loop 构建思路

Loop 基本思想与实践结构

Loop 的核心不是“让 agent 一直跑”，而是把一个目标拆成可反复执行、可观察、可改进的闭环：触发 → 执行 → 记录 → 复盘 → 再触发。下面用几张草图梳理 loop 的基本思想、文件结构和实践要点。

loop 基本思想

1. 从一次性任务变成持续改进闭环

这张图以 support 场景为例：agent 每 30 分钟处理一次支持工单，处理完成后记录摩擦点和新想法，再回到下一轮执行。上半部分是最小闭环：定时触发、响应工单、记录反馈；下半部分增加了 performance monitor，让 loop 不只是重复执行，还能根据结果观察质量、效率和瓶颈。

2. 通用 loop 生命周期

一个通用的 agent loop 可以抽象成四个阶段：Trigger 触发、Investigate & Act 调查并行动、Backlog gen / Assign task 生成待办并分配任务、Review & learn 复盘学习。关键点是每一轮执行都要产出可回收的信号：哪些任务完成了、哪些问题暴露了、下一轮应该优先做什么。

基础结构

3. loop 的文件结构

为了让 loop 可维护，最好把运行所需的信息落到清晰的文件结构里：左侧是 Artifacts，例如 docs、signals、tasks、contents 等；中间是 Loop contract，用来描述 goal、workflow、task、timeline；右侧是 LOGS.md，用来记录每轮运行的证据。这样 agent 不需要完全依赖上下文记忆，而是从文件系统里恢复状态。

4. loop 的四个核心要素

这张图把 loop 的核心配方拆成四类：第一是 Trigger，包括 cron、webhook、daemon；第二是 File structure，也就是 memory、file、logs；第三是 Tools，包括 skills、workflow、MCP；第四是 Verify，包括 codebase harness、git worktree、/verify 等验证机制。没有验证的 loop 只是自动重复，有验证的 loop 才能安全迭代。

5. 实践一：构建 codebase harness

第一条实践是先构建 codebase harness。它包括三层要求：约束要清晰，例如 CLAUDE.md、docs、自定义 lint；执行要可重复，例如本地开发脚本、worktree friendly、不同状态切换；验证要独立，例如 playwright-cli、单元测试、集成测试、e2e tests，以及不要让 agent 自我验证。这里的重点是：loop 不是先追求自动化，而是先让自动化有边界、有入口、有验收。

6. 触发方式：从人工 prompt 到自动触发

这张图展示了触发层的演进：最简单的方式是你手动 prompt agent；进一步可以把 cron job、agent、webhooks 都汇聚成 trigger prompts agent。也就是说，loop 的入口可以来自时间、外部事件或另一个 agent，但最后都应该变成清晰的触发提示词，让执行逻辑稳定可控。

7. agent loop 与项目上下文的关系

这张图强调 loop 不是孤立运行的。右上角的 /loop、/goal、/workflow 和 codebase setup 决定了目标与工作流；右下角的 system prompt assembly、agent-loop、sub-agent、context management、tools 决定了执行环境；左侧的 orchestration/workflow、state & memory、skills、verification 则构成运行时状态。中间的 execution 只是其中一环，真正重要的是上下文如何被组装、执行结果如何回写、下一轮如何继续。

8. 多个 loop 之间通过 signals 协作

最后一张图展示了更复杂的组织方式：support、SEO、ads、product growth 等多个 loop 分别运行，并把关键信号写入 /signals，例如用户导出困难、转化率差距、广告点击成本较好等。Product growth loop 再读取这些信号，优先级排序并交付 PR。这样，多个 loop 不是各自为政，而是通过文件化 signals 形成跨职能协作。

小结

一个可靠的 loop 至少需要四件事：稳定的触发器、可恢复的文件结构、可调用的工具链、独立的验证机制。真正的价值不在于“自动跑很多次”，而在于每次运行都能沉淀日志、信号和任务，让下一轮比上一轮更清楚、更安全、更有效。