循环本身不新鲜。while 循环、事件循环、控制论里的反馈回路已经存在几十年。AI 改变的是循环体的性质：过去循环体是确定的代码，终止条件由程序员写死；现在循环体是模型推理。于是"继续还是停"的判断不能再交给执行者自己，得外移成一圈围绕循环的边界。把 Agent 从"能跑的 demo"带到"可靠的系统"，靠的就是这圈边界。
一个动作被反复执行时，需要回答：目标还成立吗、要不要继续下一轮、资源是不是耗太多了、有没有被新指令覆盖、到底完成没有、出错后该不该重试。朴素做法是把这些判断全交给执行者------给模型一句"请持续推进直到完成"。但这样整个循环的可靠性就等于模型自我叙述的可靠性，而这恰恰最不该被信。模型会在上下文变长后忘目标，会因一次工具报错误判进度，会一路重试直到资源耗尽，还会在没真做完时就宣布"完成了"。
更稳的做法是把这些判断从执行者手里拿出来，分给各自该负责的一方。
循环是分层的
用"边界"的眼光看，循环从不单独存在，它们总是嵌套，而且每层骨架相似。做一款新产品，至少四层循环同时在转，只是节奏不同：
| 循环 | 大致周期 | 靠什么判断这一层"转完了" |
|---|---|---|
| 推理--行动（ReAct） | 秒到分钟 | 模型决定不再调用工具，给出一次收尾回答 |
| 任务完成（goal/Ralf-Loop） | 分钟到小时 | 是否完成目标或超过预算 |
| 开发者审视 | 小时 | 产品是否符合开发者心中的愿景 |
| 用户与市场反馈 | 天到周 | 真实用户的行为数据说明了什么 |
用六问清单逐层问之前有一道门槛要先跨：每一层的"停止证据"必须能被机器判定。把目标讲给一个不懂业务的人听，如果他能跑一行脚本或一条命令就知道"成了"还是"没成"，这个证据才算数。停止线要是"看起来不错""更合理了"这种，模型会自信地宣布完成，而没有任何外部机制能反驳它。可判定的停止证据是循环从概念走向工程的第一道闸。
四层每一层都在回答同样六个问题：目标是什么 （目标契约）、状态归谁、存在哪 （状态归属）、谁在真正推进、执行线还活着吗 （执行线）、什么时候允许进入下一轮 （续跑闸门）、什么时候必须停、凭什么算完成 （停止线）、外部怎么知道它正在发生什么（可观察事件）。这六个边界后面会反复用到，全文都围着它们转。
四层的差别不在骨架，在答案。比如"凭什么算完成"：推理--行动这一层由模型是否还想调用工具收束，再由执行环境核验每一步结果（返回码对不对、有没有报错）；任务完成这一层由客观证据核验；开发者审视这一层由人判断；市场反馈那一层只有真实数据能给答案。
不用为每层发明新方法，拿同一张六问清单逐层去问边界填的是什么就行。答得清楚，这层就被工程化了；答不清楚，它就还是一段会跑但不可靠的过程。下面先挑六问里最先崩的三个边界展开：状态归谁、什么时候可以继续、什么时候必须停。
状态归谁：循环的记忆不能只在对话里
对话上下文是会衰减的介质------它会变长、被压缩、被大段工具输出淹没、在某次截断里丢东西。把长期目标寄存在这种介质里，目标漂移几乎是注定的：几十轮之后，模型脑子里的目标早不是你最初给的那个。
可靠的循环把状态从上下文里剥出来，分四个平面放。一是事实层 ，记这件事的客观真相：目标是什么、现在什么状态、花了多少、还剩多少，不依赖模型记不记得。二是控制层 ，记此刻这个过程能不能继续、消耗算到哪、执行线还活着没有，是当下的、易变的。三是给模型看的那一层 ------注意这里给模型的应该是方向，不是全部账本，好系统只在需要时塞一小段引导："继续""目标改了""该收尾了"。"方向变了怎么让执行者知道"就落在这一层，而不是塞进它的长期记忆。四是可观察层，让外部的人和系统能看到循环正在发生什么，每次变化都能追溯。
其实这不是机器专属的设计。一个靠谱的人做长期项目也从不只靠脑子记：心里有"要干成什么"，便签、日历、todo 上有外部账本，还给自己设了到点提醒。四平面只是把这套人人都在用的脚手架显式搬进系统。区别在于可信度------人脑那份"记着"够稳，可以当默认；模型上下文那份不稳，所以得把它降级成不可信的一层，真相挪到外面。当然，模型"持有目标"的方式和人未必是一回事，但正因为拿不准它到底记住了多少，才更该把目标放到它记忆之外。
Codex 的 goal 扩展就是逐层落到代码里的：事实层是 thread_goals 持久表------objective、status、token_budget、tokens_used 这些字段存在库里，不在 prompt 里，模型忘不忘无所谓；控制层是 runtime 的记账与续跑句柄，管 turn 绑到哪个 goal、消耗记到哪、idle 了能不能开下一轮；给模型看的那层不是把整张表塞回去，而是在需要时构造一小段隐藏 context，只带 objective 和剩余预算，告诉它继续、改向或收尾；可观察层是 ThreadGoalUpdated 这类事件，让 UI 和其他客户端能看到状态怎么变。四层各有各的 owner：事实不靠模型记忆，续跑不靠模型自觉，完成也不靠模型的最终回复自说自话。
把这四层揉成一团全塞进提示里，循环就退化成不可恢复、不可审计、无法限流的黑箱。这条对每层都成立：开发者审视那层的"事实"是产品当前的样子，"给模型看的"是开发者把愿景翻译成的规格说明，"可观察层"是他拿给团队看的演示版本。
什么时候可以继续：自动化只能在"不打断人"的空隙里发生
一个长期循环总得自己往下跑。最省事的做法是挂个定时器，目标没完成就每隔一段时间踢它一脚。但稳的系统会拒绝这条路：它让"继续下一轮"必须先过一道闸门------没有正在进行的工作、没有等着被处理的人类输入、也不在需要人确认的状态里，自动续跑才被允许。系统宁可停在原地不动，也不越过人的输入去自作主张。因为默认假设是人随时可能带来系统不掌握的信息。
这给"把人留在循环里"一个工程上的样子：自动化不是取代人，是排在人后面，等人确认没有别的话要说，才往前走一步。
由此能推出一条贯穿所有层的规律：一个循环能不能被自动闭合，看它的"继续"能不能被安全地门控------系统能不能判定"现在往前走不会踩过更要紧的人类信息"。当越来越多关于用户和场景的信息被系统化收集，"完成没"的判定权会一层层向机器移交------今天机器能闭合到任务完成，明天也许能碰开发者审视的一部分。但只要某一层的停止证据还只生成在人脑子里，那一层就不能交给循环自己转。
知道何时该停
人们盯着循环怎么转，却经常忽略另一半：什么时候必须停。
朴素循环里的"停"是一句叮嘱------"遇到问题就停下来"。叮嘱可以被忽略：模型可能在上下文被压缩后忘了它，可能把一次报错误判成正常，可能一路重试到把预算烧光。稳的循环把"停"做成几条明确的、由不同责任方触发的硬边界：执行者声明完成、执行者声明被卡住、系统因错误强制中止、触发用量上限、预算见底、被人主动暂停。其中两点值得单独说。
错误应该是一次状态变更，不是对话里的一句话。 错误只记在上下文里的话，一次压缩、一个工具异常都可能让循环带着病继续跑；把错误升级成"停止"这个硬状态，循环才有真正的刹车。
限流应该是状态。 预算见底时，告诉模型"你花得太多了"没用，它可以不理。有效的做法是把循环切进"只做收尾、不再开新的实质工作"的状态。限流做成状态，它的效力才不依赖被限一方配不配合。
这条也贯穿每层：开发者审视那层的停止线是"这一版愿景被验证或否定"，市场反馈那层是"实验跑到显著性或周期结束"。只要某层的停止线还停在"感觉差不多"，这层就还没被工程化。
Claude Code 的四类原语
理解了六问的几个核心边界，再看别人怎么把它们产品化。Claude Code 团队在《Getting started with loops》里把 agentic loop 定义为"智能体重复工作周期，直到满足某个停止条件"，并按触发方式分成 turn-based、goal-based、time-based、proactive 四类。这分类有用，但它是同一组边界落到产品里的四种入口，不是循环的本质。
Turn-based loop 是最基础的一层：用户发一次 prompt，模型读上下文、行动、检查、必要时修正，最后把结果交回用户。续跑闸门在用户手里，停止线也主要由用户接受或继续追问来关闭。它适合短任务和非固定流程，但验证太依赖人的下一次提醒。Claude 文档建议把人工验证步骤写进 SKILL.md------让模型启动 dev server、打开浏览器、点新控件、截图、查 console、跑性能追踪。换成六问语言，这是把可观察事件和停止线从人的临场检查里抽出来，让模型先自证一部分结果。
Goal-based loop 把任务完成层往机器侧推进一步。用户不只是说"继续做"，而是定义完成长什么样、最多试几次，比如"Lighthouse 分数 90 以上，最多 5 次"。变化的不是模型更努力，是停止线从"模型觉得差不多"变成外部 evaluator 可以反复检查的条件；续跑闸门变成"目标未达成且还没触顶"。这类循环越依赖确定性指标越可靠，因为它减少了模型对"够不够好"的裁决。成功标准本身要是含糊，goal-based loop 只是把含糊判断自动重复很多遍。
确定性指标里，对账比断言靠谱。断言------"测试跑过了"------可以被改写、被 mock、被吞异常；对账------"diff 与参考值 < 0.01""与上游总数轧差为零"------不会。目标证据是对账型的，信用比"自己说自己通过了"高一个量级。
Time-based loop 解决外部世界会变的问题：PR 会收到新 review，CI 过段时间才失败或恢复，每天早上才需要总结消息。/loop 或 /schedule 这类原语的价值不是让模型一直转，是按时间重新打开执行线，检查外部状态有没有变。它的事实层不在对话里，在 PR、CI、消息队列、日程或远端系统；停止线也不是一次回答结束，而是队列为空、PR 合并、用户取消、预算或周期结束。风险是把定时器当智能：被观察对象变化很慢时，过高频率只是在烧 token 和无意义轮询。
Proactive loop 再往外一步，触发源从人和时间变成事件流或任务池。bug report、issue triage、依赖升级、迁移任务这类工作持续流入，每个单元边界相对清楚，才适合无人实时参与。Claude 文档给的组合是：/schedule 定期检查新反馈，/goal 定义每批反馈必须 triage、action、respond 的完成条件，dynamic workflows 让多个 agent 并行探索并由 judge 审查，再用 auto mode 减少权限打断。这里自动化程度最高，边界也得最硬：输入队列要清楚，单个事件的完成证据要清楚，权限和副作用可审计，失败时能升级给人，不能让循环越过人的产品判断和风险判断。
四类原语是同一张六问清单的四组答案：turn-based 把继续权留给人，goal-based 把停止线交给可验证目标，time-based 把触发交给时间和外部状态，proactive 把触发交给事件流并要求更强的权限、审计和回退边界。原语本身不保证可靠，它只是把某些边界产品化了。
先不要升级循环
Claude 建议"从最简单的方式开始"。不是所有任务都需要复杂循环。一次 prompt 能完成的停在 turn-based；有明确验收标准但需要多次尝试的才升到 goal-based；任务依赖外部状态随时间变化的才考虑 time-based；只有工作来自持续流入的事件池、且每个事件都有清楚边界、权限和回滚机制时，才进 proactive。
升级循环的理由不该是"更自动化"，而是当前层的边界不够用了：目标会在对话里漂移、完成判断被模型自述污染、失败需要回流而不是结束、外部状态在等待中变化、同类任务持续进入队列。反过来，目标主观、验收模糊、权限高风险、成本不可控时，就不该往更自动的层级推。能用脚本确定完成的工作别让模型反复推理，脚本比推理便宜也更稳。
这也解释了质量和 token 为什么不是循环之外的附属问题。循环输出质量取决于周围系统：代码库是否整洁、文档是否好取、模型能不能自己验证、有没有第二个 fresh agent 做审查。一次结果不达标时，有杠杆的修复不是改那次输出，是把失败经验写进 skill、验证步骤、脚本或流程规则，让后面每一轮都少犯同类错。token 控制也不是提醒模型省一点，是边界设计：选对原语和模型、定义清楚停止条件、大规模跑之前先小范围试、用脚本承接确定性工作、把轮询频率调到外部状态真实变化的节奏、用 /usage、/goal、/workflows 看清消耗从哪来。
收束
由此能推出两条贯穿所有层的规律，也解释了为什么越往外的循环越慢、越离不开人。
自动化程度从内向外递减。 越靠内的循环，判断"完成"的凭据越能被系统直接核验------返回码、测试、预算数字；越靠外，凭据越是只存在于人的判断里------愿景达成没有、用户是不是真满意。所以自动化的边界不是算力问题，是"谁有资格核验完成"的问题。
时间尺度从内向外递增。 一层循环转一圈要多久，约等于关闭它所需的证据生成一次要多久：推理--行动秒到分钟，任务完成分钟级可验，产品判断要人看几小时，市场信号要跑几天。循环快慢由取证成本决定，不由算力决定。
这两条也给"人相对 AI 有上下文优势"一个更实在的说法。人卡在外两层无法替代，不是因为有什么神秘天赋，是因为关闭外层循环所需的证据眼下只生成在人脑子里。这解释了这步为什么暂时自动化不了，也指明了自动化往哪走------当用户和场景的信息被系统化喂进系统，"核验完成"的资格会一层层向机器移交，边界随之向外推。今天机器能闭合到任务完成，明天也许能碰开发者审视的一部分。
过去我们以函数、模块、服务为单元构建软件。AI 时代正在浮出新的基本单元：循环。区分"能跑的 demo"和"可靠的系统"的，从来不是会不会循环就够，而是这个循环的每一次继续、转向、停止、恢复和完成，是否都被关进了明确的状态边界与证据边界。第一步永远是把那六个边界的每一项写成一段不依赖模型配合的代码或规则。模型的配合会衰减，代码不会。