3-1 什么是 Loop，为什么现在可行
Loop 的本质
先把概念说清楚，避免和"循环"这个词的日常含义混淆。
这里说的 Loop，不是 for 循环，不是硬编码的分支流程。
Loop 的本质是：cron + 决策者。
- cron：有一个外部驱动在周期性触发
- 决策者：每次触发时，由模型决定这个 tick 该做什么——不是代码里写死的
if-else，是模型根据当前状态动态判断
传统自动化脚本的逻辑是硬编码的：条件 A 执行操作 X，条件 B 执行操作 Y，覆盖不到的情况就挂掉。
Loop 的逻辑是软编码的：模型拿到当前状态，自己判断下一步，遇到没预料到的情况可以尝试适应——而不是直接崩。
这个差异决定了 loop 能处理的任务类型远比脚本复杂。
为什么现在才可行
Loop 的概念不新，但工程上真正可用是近两年的事。两个条件同时成熟了：
条件一：Context Window 够大
早期模型的 context window 只有 4K、8K token。一个稍微复杂的代码库，光文件列表就撑满了，根本没法让模型"看到全局再决策"。
现在主流模型的 context window 在 100K 到 200K token 量级。一次能装下整个中型代码库的核心文件、完整的错误日志、历史操作记录——模型终于有足够的信息做出合理判断，而不是在盲人摸象。
条件二：成本降到合理区间
Loop 意味着模型会被反复调用。每次 tick 都是一次推理请求，成本直接乘以迭代次数。
2023 年之前，让模型跑 50 次迭代处理一个任务，成本可能高到不可接受。现在主流模型的 token 价格相比两年前已经下降了一到两个数量级，一个合理设计的 loop 跑下来成本可以控制在几美元甚至更低。
这两个条件缺任何一个，loop 都只是 demo，不是工程。
演化路径：从 ReAct 到现在的编排 Loop
理解演化路径，能帮你看清每一代方案在解决什么问题、又留下了什么新问题。
ReAct（2022）
论文提出的框架：Reasoning + Acting 交替进行。模型先推理（Thought），再行动（Action），看到结果（Observation），再推理，再行动。
这是第一个把"模型 + 工具调用 + 反馈"串成循环的完整框架。核心贡献是证明了这条路可行。
问题：单轮推理能力有限，context 一长就降级，没有工程约束，容易跑偏。
AutoGPT（2023）
把 ReAct 的思路工程化，加了记忆、工具调用、自我驱动——号称"给它一个目标，它自己跑完"。
在 demo 上很震撼，实际工程里很难用。核心问题是：没有可靠的 verification gate。模型给自己打分、自己判断任务完成没有，系统性偏宽，经常"以为完成了但其实没有"。同时 context rot 问题非常严重，跑着跑着就开始兜圈子。
Ralph 模式（概念逐渐成形）
对 AutoGPT 问题的直接反应。核心洞察是：长 session 是问题根源，不要试图维护一个越来越长的对话，而是每次迭代都重置 context，状态持久化到磁盘。
这个思路把"session 里的记忆"和"工程上的状态"彻底分开——session 可以随时销毁，状态（代码、文件、git history）活在外部。3-3 会专门讲这个模式。
/goal 命令 + 现在的编排 Loop
Claude Code 的 /goal 是 Ralph 模式的产品化实现：给 agent 一个目标，它自己跑迭代，每次迭代从磁盘读状态，完成一个工作单元，commit，进入下一轮。
现在的编排 loop 在此基础上进一步结构化：orchestrator 负责拆任务和调度，sub-agent 负责执行，verifier agent 负责检查——三角结构把"执行"和"验证"分开，解决了 AutoGPT 时代"自己给自己打分"的根本问题。
两种 Loop 拓扑：串行 vs 并发
上面讲的 Ralph 模式和 /goal，本质都是串行：一个 agent，一次处理一个工作单元，commit，退出，再开下一轮。适合单个大任务拆成顺序子任务的场景。
但大规模 issue 流水线用的是另一种拓扑——并发：
orchestrator 拉取 issue 队列
↓
skill 判断每个 issue 能不能自动处理
↓
能处理的：各自开独立 git worktree
├── issue-1 → worktree-1 → agent A → PR
├── issue-2 → worktree-2 → agent B → PR
└── issue-3 → worktree-3 → agent C → PR
（同时并发跑，互不干扰）
↓
处理不了的：挂起，等人介入
每个 issue 有自己独立的 worktree，agent 在各自的分支上工作，代码修改互不污染，最终各自提 PR 等待合入。
"一周处理几千个 issue"的吞吐量来源不是单个 agent 跑得快，而是几百个 agent 在同时跑。
两种拓扑的选择标准很简单：
任务之间有依赖、需要顺序完成，用串行（Ralph）；任务之间相互独立、可以同时开工，用并发（worktree）。大多数 Bug 修复属于后者——每个 Bug 改的是不同的地方，天然适合并发。
注意并发拓扑里真正的核心不是循环本身，而是skill 里的判断逻辑——它决定哪些 issue 可以自动处理、哪些需要人介入。skill 质量直接决定自动化的准确率，写错了会批量提错误 PR，比手动处理更麻烦。
这样 3-1 就覆盖了两种拓扑，读者能判断自己的场景该用哪种。
一个直觉模型
把 loop 想成一个有判断力的流水线：
┌─────────────────────────────────────────┐
│ Loop │
│ │
│ 读状态 → 模型决策 → 执行工具 → 验证结果 │
│ ↑ │ │
│ └────────────────────────────┘ │
│ (下一个 tick) │
└─────────────────────────────────────────┘
每个 tick：
- 从磁盘/外部读当前状态
- 模型看到状态，决定这一步做什么
- 执行（受 harness 约束）
- 验证结果是否达到终止条件
- 没达到就进入下一个 tick，达到就退出
终止条件是 loop 设计里最重要的部分——没有可靠终止条件的 loop 要么跑不停，要么在错误的地方停下来。这是 3-2 的核心话题。
本节核心一句话
Loop 是 cron + 决策者，context window 够大 + 成本够低，是它从 demo 变成工程的两个前提。
