一、Loop Engineering 是什么为什么需要它一句话定义Loop Engineering 是设计一个能自己发现问题、执行、验证、交接的闭环系统的工程方法——你的工作从写 prompt 变成写 loop杠杆支点从单次交互移动到可复用的系统。“You shouldn’t be prompting coding agents anymore. You should be designing loops that prompt your agents.” —— Peter Steinberger, OpenClaw“I don’t prompt Claude anymore. I have loops running. My job is to write loops.” —— Boris Cherny, Claude Code 负责人从 Prompt 到 Loop四个瓶颈的演进AI 编程工具链里每个新概念都对应上一个瓶颈被解决后暴露的下一个瓶颈概念解决的问题Prompt Engineering模型一问一答你怎么问决定怎么答Context Engineering单次会话里给 Agent 什么上下文Harness EngineeringAgent 的运行环境——工具、沙箱、权限、子 AgentLoop Engineering人坐在屏幕前敲 prompt是最后一环瓶颈前三者解决的是模型怎么用好Loop Engineering 瞄准的是人与 AI 的协作方式从你一轮轮对话变成你设计一个能自己运转的闭环。三层嵌套关系Harness 单次 Agent 运行的环境工具、权限、规则Loop Harness 调度 状态 验证链Loop Engineering 设计并运营上述 Loop 系统的工程实践类比Harness 管单个工位的工具箱Loop 管传送带的运转Loop Engineering 管整条产线的设计与 SOP。Agent Loop ≠ Loop Engineering维度Agent LoopLoop Engineering本质运行机制/产品功能如 /loop 命令系统设计/工程方法论你在做什么启动一个会重复的 Agent 任务设计发现→执行→验证→交接的完整系统成功标准“它又在跑了”“它跑得对、跑得省、出事能停、人能看懂它干了什么”一个只知道敲 /loop 1d … 的人是在用 Agent Loop一个会问验证器够不够硬、预算怎么卡、出问题谁接手的人是在做 Loop Engineering。本手册教的是后者。二、核心概念速览实施之前必须掌握的最小概念集——四类型、六构件、Contract 六维度、自动化·验证 双轴、验证器优先原则。这五组概念贯穿全手册。2.1 Loop 四类型按触发与停止方式类型触发方式停止条件适用场景Turn-Based手动轮用户 prompt判断任务完成或需更多上下文探索性/决策性短任务Goal-Based目标驱动手动输入目标目标达成或达最大轮数有明确可验证验收条件的任务Time-Based定时触发定时器本地 / 云端手动取消或每个子任务完成定时重复任务Proactive自主循环事件/定时器 无人值守每个子任务各自满足停止条件持续运行的明确定义工作流四类型与隔离模式下文是两个正交维度任意类型 × 隔离模式组合都合法。2.2 六大构件完整 Loop 必须回答的六个问题构件职责回答的问题① 调度心跳按节奏或事件触发谁来把它叫醒② 任务定义目标 scope 验收条件调醒之后干什么③ 停止条件完成条件 安全网什么时候交还给人④ 验证独立检查产出质量做完一轮怎么检查⑤ 记录持久化到磁盘的状态文件进展记到哪⑥ 记忆跨会话记住做了什么怎么记住昨天做到哪了模型会忘但仓库不会。记忆可以是一个 markdown 文件、一个看板、一份外部记录只要它活在单次对话之外。配方优于产物Recipe-over-Artifact搜索/优化类循环的记忆只存配方commit/config 评分不存产物本体模型权重、渲染结果、构建产物。产物不能反推配方配方可以随时复现产物。存储成本从 O(产物×轮数) 降到 O(配方×轮数)差几个数量级。2.3 Loop Contract循环协议六维度防止自主循环退化为失控死循环整个系统必须在策略层强制执行以下六个维度维度说明示例TRIGGER触发条件每 15 分钟 / PR 评论 / CI 失败SCOPE作用范围仅限特定仓库 / 仅处理自己提交的 PRACTION具体行为运行测试 / 自动修复 Lint 错误BUDGET预算红线单次最多衍生 3 个子 Agent / 50k Tokens / 100 元成本STOP停止条件测试全绿 / 达到 10 轮上限 / 预算耗尽REPORT上报通道异常时发送邮件通知或接入消息通知第五章会把这六维度落地为一份机读的 contract.yaml。2.4 自动化·验证 双轴循环的放权程度由两个正交字段描述字段取值含义autonomyopen / closed自动化程度open 开环Agent 只建议/报告人处置closed 闭环Agent 自动处置verification.modeself / test_suite / independent_agent验证方式简称 L1/L2/L3 验证档位任意 autonomy × verification.mode 组合合法。例如审查循环可取 autonomy: open verification.mode: self——“自动执行但只出报告人工决定修复验证靠自检清单”。验证档位L1/L2/L3说明此处档位特指验证方式与自动化程度无关。档位verification.mode验证手段适用场景L1selfSKILL 自检清单、手工对照起步阶段、报告型循环L2test_suite可复现命令lint/test中等风险、有测试保障L3independent_agent另一 Agent 独立审查高风险、不可自我验证自动化档位open/closed说明档位autonomy行为适用open 开环openAgent 只建议/报告/生成 handoff最终处置由人决定审查、分诊、审计、监控类循环closed 闭环closedAgent 自动处置修复/开 PR/发送mutations_allowed: true自动化修复类循环L3 独立审查的三个层面统一为一件事先通过第六章的量化准入门槛漏放率≈0、人工干预率10%→ 用独立审查手段Agent 或确定性验证器接管验证 → 人工最终可以完全不在场。三者是同一晋级路径的三个观察角度不是互斥定义。2.5 验证器是瓶颈贯穿全手册的核心原则任何循环里瓶颈是验证器Verifier不是模型。模型产出的速度早已超过人类确认质量的速度。Loop Engineering 的核心技能是写出那个判定 Agent 输出是否足够好的验证器。验证器有多严循环就有多可信验证器写不出来的任务不该交给无人值守的循环。写代码的人最好别自己给自己 review——这个道理在无人盯着的循环里更要紧因为它一旦犯错会顺着循环越跑越远。实现方式独立的 verifier Agent、子 Agent 之间写查分离、自动跑测试套件或者最硬的一种——一段 Agent 物理上无权修改的确定性代码完美验证器见第三章案例。2.6 工程防线熔断器与看门狗BUDGET 与 STOP 在工程落地时固化为两道硬性约束• 熔断器Circuit Breaker配置连续失败次数上限。一旦连续报错 N 次系统立即跳闸并回退代码将日志打包转交人工同时加设墙钟时间上限超时无条件熔断。实践中失败应按错误指纹判定同一条错误信息、空 diff、同一个失败测试连续出现 N 次即视为原地打转——裸循环没有天花板必须人为加上限。• 看门狗Watchdog专防自旋死循环。独立于主线程的外部进程监控资源占用检测到满载且长时间无 I/O 交互越过应用层直接强杀进程。三、案例研究完美验证器的最小实现autoresearchAndrej Karpathy前 Tesla AI / OpenAI 研究员2026是完美验证器 完全自治的最小可运行范例LLM 当变异算子、git 当选择与记忆机制、冻结评测函数当适应度函数一晚约 100 次自主实验。这个案例把第二章的五组核心概念串成了一条闭环• 六构件全部到位——调度是人手动点火后的会话内循环任务定义是让某个客观指标更好停止条件故意没有人工中断是唯一出口因为失败代价被锁死在单步见第九章决策规则验证是一段确定性评测函数记录是简单的提交台账记忆遵循配方优于产物——只保留配方和分数产物用后即焚• 完美验证器评测函数成本低分钟级、确定性可复现、Agent 物理上无权篡改——这是为什么它敢跳过 L1/L2 直接做到 L3 无人值守的根本原因• 配方评分循环Recipe-Scoring Loop这类循环的 ACTION 不是生产产物而是给候选配方打分超参搜索、Prompt 调优、CI 参数调优都属此类。停止条件无完成概念只有单调优化目标 人工中断验证就是评分函数本身不需额外一层记录只记配方 分数不记产物。如果你的循环属于此模式产物存储和交付流程都是不必要的设计——打分本身就是产出四、怎么开始分阶段放权先让最小循环转起来心跳 任务 停止条件再逐步加入验证、worktree、子 Agent。部件是一件一件长出来的不是一天配齐的。落地步骤先定义完成——写任何指令之前先把完成写成可度量的标准循环应跑向你的验收线而不是模型自己的判断建 STATE.md——每轮必读必写记录优先级、进度、噪声写 Skill——把项目知识固化下来让 Agent 不再冷启动加验证——至少跑一遍测试最好用独立 Agent 检查设停止条件——token 预算、重复失败阈值按错误指纹判定、敏感路径 denylist建记忆——markdown 文件即可关键是在对话之外持久化该不该为这件事建 loop决策树这件事一个确定性脚本能做吗├─ 能 → 写脚本 cron不要用 LLM便宜且稳定└─ 不能需要判断/生成└─ 它会重复发生吗├─ 不会 → 一次性对话或 Goal-Based 单次运行即可不建常驻循环└─ 会└─ 能写出机器可判定的完成和验证器吗├─ 不能 → 只建 L1 报告型 loop人做验证或不建└─ 能└─ 失败的最坏代价可承受/可回滚吗├─ 否 → 建 loop 但停在 L2人审 PR└─ 是 → 可推进 L3 无人值守五、Loop Contract Schema落地规范Contract 六维度落地为一份机读的 contract.yaml 两份人读的 LOOP.md / SKILL.md。目录结构每个循环一个目录loops/├── _template/ # 模板新循环从这复制├── _bin/coldstart.ts # 冷启动确定性脚本§0–§2 的脚本化实现见下方说明├── proactive//├── goal-based//├── time-based//└── turn-based//loops/// # type ∈ turn-based | goal-based | time-based | proactive├── contract.yaml # 机读契约本章 Schema├── LOOP.md # 人读SCOPE / ACTION / STOP / REPORT├── SKILL.md # Agent 冷启动执行手册├── state/ # 必有STATE-YYYY-MM-Wn.md仅本循环读写└── workspace/ # 可选中间产物冷启动已脚本化每轮 Step 0 的时间锚点、路径推算、归档裁剪、互斥守卫、熔断检查由 loops/_bin/coldstart.ts 确定性执行node loops/_bin/coldstart.tsAgent 读其 JSON 输出按 verdict 行动。SKILL.md 首步为运行此脚本。脚本不可用时的回退流程见 COLD-START.md。六大构件 ↔ contract 字段映射#构件contract.yaml 字段配套1调度trigger.schedulers[]调度分发脚本2任务定义task · scope · actionLOOP.md ACTION3停止条件stop · budget · termination熔断守卫脚本4验证verification独立 verifier 循环写查分离5记录report · isolation.state_*本循环 state/STATE-*.md6记忆memorySTATE「记忆」区 · state/history/ · handoff/archive/隔离模式isolated vs collaborativeLoop 四类型与隔离模式是两个正交维度isolation.modestatehandoffisolated本循环 state/不参与协作总线collaborative本循环 state/可读写 handoff 收件箱见第八章一条铁律禁止多循环共写同一个 STATE 文件——每循环自有 state 目录仅本循环读写协作靠传递消息文件而非共享状态。contract.yaml 完整结构配注释以下为模板的实示结构字段规范以仓库 _template/contract.yaml 为单一事实源。各字段取值参考实际循环按自身语义填写。type: proactive # 四类型之一决定触发范式name:version: “0.1.0”两个正交字段autonomy 自动化程度open 开环Agent 只建议/报告人处置| closed 闭环Agent 自动处置verification.mode 验证方式self | test_suite | independent_agent简称 L1/L2/L3 验证档位autonomy: openloop_dir: loops///① 调度 — 数组支持多后端并存trigger:schedulers:- kind: manualprompt: “执行循环”② 任务定义task:goal: “” # 一句话目标acceptance_criteria: [] # 可验证的完成条件scope_summary: “” # 与 scope 呼应的摘要isolation:mode: collaborative # isolated | collaborativeworkspace_dir: nullstate_dir: loops///state/state_history_dir: loops///state/history/state_retention_weeks: 3 # state/history/ 仅保留最近 N 周state_history_max_rounds: 20 # state 中历史轮次表最多保留 N 行Agent 按 pattern 直接推算当周文件非当周 STATE-*.md 移入 state_history_dir见 COLD-START.mdstate_file_pattern: “STATE-{year}-{month}-W{week_of_month}.md”scope:repos: []time_window: since_last_success 类循环必须配置游标文件gitignored、不随周滚动否则跨周归档会丢失截止点周一首轮回退 fallback 漏掉周末窗口见 COLD-START.md §1 游标恢复cursor_file: state/cursor.yamldenylist:- “.env*”- “**/credentials*”- “**/secrets/**”action:steps:- read_state- collect_context- execute- verify- write_statemutations_allowed: false # L1 必须 falseL2 通过评估后方可 true③ 停止条件预算分两类如实声明避免虚假安全感hard Agent 可自证并强制执行轮内计数、$NOW 与结束 date 差值、STATE 失败计数soft 意图声明Agent 无法精确测量token仅作规模提示budget:max_sub_agents: 3 # hard派发时计数max_items_per_round: 20 # hard本轮处理条目上限max_tokens_per_round: 50000# softAgent 无法自测 token仅规模提示max_runtime_minutes: 30 # hard$NOW 与结束 date 差值判定max_consecutive_failures: 3# hardSTATE 连续失败计数termination:max_rounds: null # goal-based 可设整数上限stop:completion:- state_md_updatedsafety:- budget_exhausted- consecutive_failures- denylist_hit- mutation_attempted④ 验证verification:mode: self # self | test_suite | independent_agent对应 L1/L2/L3verifier_loop: null # L3: 如独立审查循环commands: [] # L2: [“npm run lint”, “npm test”]must_pass_before_handoff: falsechecklist: # L1 self- 输出与 task.goal 一致- 未触及 denylist- 验证器清单逐项通过⑤ 记录report:state_file: 按 isolation.state_file_pattern 推算的当周 STATEconsole_summary: truenotify 通道列表。可用通道push_notification — 桌面终端通知isolated 循环默认handoff — 通过 handoff 发往 notify 循环collaborative 链终点的冗余通知stdin_callback — 通过 stdin 回调预留每条格式{channel: push_notification, on: [failure, success], message: “模板文本可选占位”}notify: []示例notify:- channel: push_notificationon: [failure]message: “⚠️ {loop_name}: {result_summary}”- channel: handoffon: [failure]message: “⚠️ {loop_name} 检查异常”⑥ 记忆memory:cold_start_doc: loops/_template/COLD-START.mdcold_start_read_order:- circuit_check # 熔断检查读 STATE 运行状态/熔断区- state_file # 本循环 STATE- memory_section # STATE「记忆」区- handoff_inbound # handoff/queue/ 入站 pending- registry # registry.yaml 上下游state_sections:- verified_facts- rejected_approaches- stumbles # 错误踩坑根因规避- learnings # 优化学习效果可推广- carry_forward多循环协作仅 collaborative 模式collaboration:role: producerupstream: []downstream: []handoff:enabled: truedir: handoff/queue_dir: handoff/queue/locks_dir: handoff/locks/archive_dir: handoff/archive/item_template: handoff/_template/handoff-item.yamllocks: []skills:ai-coding-workflow新建循环 Checklist六构件逐项验收• [ ] ① trigger.schedulers 至少一种• [ ] ② task.goal task.acceptance_criteria scope含 deny• [ ] ③ stop.completion stop.safety budget hard/soft 预算分类• [ ] ④ verification.mode 已声明self / test_suite / independent_agent• [ ] ⑤ state/ 已从模板复制• [ ] ⑥ memory.cold_start_read_order 与 STATE 记忆区就绪• [ ] 已登记循环注册表id、type、isolation、autonomy、upstream/downstream六、上线前评估Evals——循环的准入测试验证器是瓶颈那么验证器本身也必须被测试。没有通过评估的 loop 不允许无人值守。四步准入流程步骤做法通过标准1. 影子模式Shadow循环只读运行产出报告和我本打算做的改动不落任何写操作连续 N 轮建议 ≥5人工抽查分诊/判断准确率达标2. 金标准任务集Golden Tasks准备 5–20 个已知答案的任务含正例与陷阱负例让循环跑一遍正例完成率、负例拒绝率均达阈值3. 验证器质量度量把已知有 Bug 的产出混入验证器输入漏放率false pass为硬指标——验证器放过坏产出比模型犯错更危险误杀率false block为效率指标4. 金丝雀Canary真实环境小范围放量仅 1 个仓库 / 仅低风险路径 / 仅工作时间运行人工干预率低于阈值且无安全事件方可扩大范围验证器质量的参照系验证器质量的标尺是否是一段 Agent 无权触及的确定代码——确定性可复现、物理上不可篡改漏放率趋近于零参见第三章案例。差距越大离 L3 越远。验证档位晋级门槛verification.mode升级条件晋级量化门槛建议值按项目调整L1 → L2人读报告 → 辅助修复影子模式 ≥5 轮分诊准确率 ≥90%金标准任务全通过L2 → L3辅助修复 → 无人值守连续 ≥20 个 PR 人工审查零回退验证器漏放率 ≈0人工干预率 10%Auto mode 准入清单第七章全勾选任一级 → 降级出现一次安全事件或人工干预率连续两周 30%立即降级并复盘Skill / Prompt 变更的回归评估Skill、SKILL.md、contract 中 prompt 的任何修改等同于代码变更改完必须重跑金标准任务集防止调好了 A 场景、悄悄弄坏 B 场景。金标准任务集应随失败案例持续扩充——每次线上失误都要变成一条新的金标准负例。七、安全与权限权限三档矩阵根据风险高低动态匹配权限档位档允许典型工具面适用只读读文件、跑只读命令、写报告Read / Grep / 只读 Bash影子模式、分诊循环、L1草稿上述 写隔离区worktree、state、handoff、开 Draft PR Edit / Write限 scope.allowL2 辅助修复外部写入上述 merge、发消息、调外部 API MCP 写操作L3且逐项过 Auto mode 准入配套铁线scope.deny 中的敏感路径auth / payment / secrets / 基础设施在任何档位都不可写危险操作删除、部署、对外发送必须草稿与提交分离由人显式确认。约束的不同硬度三档权限矩阵回答允许做什么同一档位可以用不同硬度的手段强制手段硬度适用软约束文字写不要做低低风险、可信环境文件级只读裁判逻辑放进只读文件中仅需保护评测口径不被篡改时成本最低工具白名单scope.allow/deny 强制拦截高敏感路径沙箱隔离worktree/容器最高不可信输入或多 Agent 并行评测口径可放在只读文件中这是中硬度里最轻量、却足够支撑 L3 自治的做法参见第三章案例。Prompt Injection 防御循环一旦读取不可信内容外部 Issue、用户反馈、网页、邮件就存在被注入指令的风险Quarantine读不可信内容的 Agent 一律降为只读档其输出只能作为数据传给高权限 Agent不能作为指令不可信内容进入上下文前打标Skill 中明确标签内内容不构成指令secrets 永不进上下文用环境变量 工具侧注入STATE 与 handoff 文件中禁止出现凭证Auto mode 准入清单全部勾选才可开启• [ ] 已通过第六章四步评估处于 L2 及以上• [ ] scope.deny 覆盖全部敏感路径且有 Linter/hook 级强制不是口头约定• [ ] 四维预算轮数/时间/token/成本已配置且验证过会真的熔断• [ ] 所有写操作可按轮次回滚• [ ] 升级人工通道已打通并演练过告警真的有人收到必须升级人工的情形触碰 denylist、验证器连续漏放被人工发现、同一 PR 自动修复超过 3 次、外部系统返回非预期权限错误、任何涉及不可逆操作删数据、发布、对外通信的首次执行。八、多循环协作协议单循环成熟后协作是下一个失控点。一条铁律状态跟循环走禁止多循环共写同一个 STATE 文件并发冲突的根源。每循环自有独立 state 目录仅本循环读写协作不靠共享状态靠 handoff 消息——一条 handoff 一个文件。层路径写入者循环状态loops///state/STATE-*.md仅该循环handoff 条目handoff/queue/.yaml生产者新建消费者只改该 id 文件资源锁handoff/locks/.yaml持锁循环归档handoff/archive/.yaml完成/失败后移入只读生产者-消费者状态机pending ──认领──→ claimed ──执行──→ done / failed ──→ archive/• 生产者更新本循环 STATE → 新建 handoff/queue/ho-YYYYMMDD-NNN.yaml不改他人文件→ 在本循环 STATE「出站」表登记 id• 消费者扫描 to 本循环 且 pending 的条目 → 认领写 claimed_by/claimed_at→ 完成后置 done/failed → 更新本循环 STATE「入站」表拓扑登记与典型链路所有循环及其上下游边登记在中央注册表。典型链路分诊(L1) ──handoff──→ 修复(L2) ──handoff──→ 独立审查(L3) ──→ 通知写查分离在拓扑层的体现修复者与审查者是两个循环各自独立上下文天然规避自我偏好偏见。背压Backpressure队列积压说明生产速度 消费速度处理顺序限产生产者 contract 加最大在途 handoff 数队列超限即本轮只分诊不产出提效消费循环提高频率或并行度worktree 隔离下多实例降级积压超过时限的条目自动标记为 stale升级人工批量裁决永远不要用加大生产者预算来解决积压——那是反向操作九、决策工具决策规则总量停止条件是否可以放宽四维预算轮数/时间/token/成本是默认姿态。但有一个合法特例预算约束下沉到单步则总量可放宽。单步可即时低成本回退如 git reset├─ 否 → 总量预算是硬性的└─ 是且单步有硬墙钟/资源上限 → 总量上限可放宽为人工中断预算没有被取消只是下沉到了每一步的级别参见第三章案例单次实验封顶固定时长 一次 commit验证不过直接 reset。类型 × 调度后端你的情况类型调度后端探索、一次性Turn-Basedmanual知道完成长什么样、干完即止Goal-Basedmanual 目标驱动外部系统有固定节奏PR、日报Time-Based本机调试用本地循环长期用云端 Routine不依赖 IDE 用系统 cron事件驱动CI 失败、Issue 创建Proactivewebhook / CI 事件长期无人值守流水线Proactive云端调度 Agent 编排路由 Skills 组合同一轮只应有一个调度源激活事件触发 定时触发避免重复跑。十、成本模型与预算工程本章成本模型默认 LLM 推理成本主导多数编码/分诊/审查类循环属此类。若循环真正驱动的是外部重计算任务模型训练、编译构建、渲染、压测瓶颈会转移到算力时间而非 token见本章末尾的补充分支。估算公式日成本 ≈ Σ各循环 [ 日触发次数 × 每轮平均轮内调用数 × 每次调用 token× (缓存未命中比例 × 1 缓存命中比例 × 0.1) × 单价 ]上下文分层做得越好工具定义→系统提示→历史对话→动态消息从静到动排列缓存命中比例越高成本被压下来的部分越大——因为命中前缀缓存的 token 只按约 10% 计费。间隔与缓存 TTL 的耦合Prompt 缓存 TTL 约 5 分钟。这意味着循环间隔缓存状态成本含义 5 分钟每轮命中前缀缓存高频但单轮便宜适合盯 CI 这类快变化目标略超 5 分钟如 6–10 分钟最差区间次次全额冷启动又没省几次触发避免要么压进 5 分钟内要么大幅拉长≥ 20–30 分钟冷启动但触发次数少摊薄适合慢变化目标原则循环频率不应高于任务实际变化频率在此前提下间隔要么贴着缓存窗口要么远离它。降本手段按性价比排序脚本化确定性步骤——能用脚本的绝不用推理收集数据、格式化、diff 统计模型路由——分诊/分类用轻模型仅复杂修复上强模型降频/事件化——把定时轮询改为 webhook 事件触发空转轮次直接归零上下文瘦身——工具结果裁剪、压缩、按需加载 Skill预算不是摆设budget 四维配好后要实际验证熔断会触发见第七章 Auto mode 准入清单计算密集型循环的成本模型补充分支当循环驱动的是外部重计算训练/构建/渲染预算维度从 token 转为计算资源时间日成本 ≈ 日触发次数 × 单轮固定资源时长 × 单价GPU-小时 / 构建分钟等要点固定单轮资源时长是最直接的预算控制降本从减 token转为减时长或增密度台账记录资源用量而非 token。十一、运维与可观测性Day-2 Operations每轮必记的运行日志STATE 轮次记录 Schema轮次 2026-07-08-01触发: schedule_cloud 09:00动作: 分诊 12 项 → 3 项 handoff消耗: 8 轮对话 / 32k tokens / ¥4.2验证: handoff 必填字段自检通过异常: 无下轮携带: repo-B 的 CI 失败待确认勿重复分诊核心指标每个循环都要能回答指标定义告警阈值示例成功率满足 acceptance_criteria 的轮次占比80% 连续 3 天人工干预率需要人介入的轮次占比无人值守化的核心指标L3 循环 10%单轮成本tokens × 单价按循环聚合环比翻倍MTTR熔断后到人工恢复的时长1 个工作日队列积压handoff/queue/ 中 pending 条目数 消费循环日处理量 × 2空转率无实质产出空 diff / 无新发现的轮次占比50%说明频率高于任务变化频率该降频工具面/usage 看按 Skill / 子 Agent / MCP 的成本拆分/goal 无参数查看轮次与 Token/workflows 查看每 Agent Token。排障 Runbook症状 → 根因 → 处置症状可能根因处置同一错误反复出现、空 diff 连续多轮原地打转任务超出能力 / 验证条件不可达熔断 → 缩小 scope 或改写 acceptance_criteria → 金标准集加负例产出逐渐偏离目标目标漂移长会话 压缩丢失细节把验收条件写进 STATE 每轮重读缩短单轮长度拆子 AgentSTATE 文件冲突/内容错乱多循环共写同一 STATE违反第八章铁律立即拆分每循环自有 state/协作改走 handoffworktree 残留、磁盘增长子 Agent 异常退出未清理定期 git worktree prune把清理写进循环收尾步骤成本突增但产出不变缓存击穿前缀变动 / 间隔跨过缓存 TTL检查 system prompt 是否混入动态变量按第十章调整间隔队列积压下游消费能力不足背压见第八章背压处理标准处置动作• 暂停在循环 STATE 置熔断标记circuit_open或熔断表新增未恢复记录也可直接停调度后端Agent 冷启动读到即拒绝启动• 回放从本循环 state/history/ 恢复到最近一个干净轮次重跑• 回滚loop 产出的提交必须可按轮次定位commit message 带循环 id 轮次号git revert 按轮回滚• 复盘每次熔断都要产出一条结论——是改 contract、改 Skill、加金标准负例还是这个任务本就不该给循环修复系统而非仅修复单个问题十二、生命周期与组织Owner 制每个循环必须有一个人类 Owner登记在 contract.yaml 的 owner 字段与注册表中。Owner 对循环产出负最终责任——循环只是执行方式变了责任没有转移。无主循环一律停用。模板中 owner 字段为可选注释# owner: null新建循环时填入实际 Owner 的姓名即可。版本化与变更纪律• contract / SKILL / prompt 的变更走 git 提交 简短 changelog改了什么、为什么、金标准回归结果• 循环产出的提交带循环 id 与轮次号保证可审计、可回滚模型升级重评底层模型每次升级后Owner 需要做两件事重跑金标准任务集确认没有回退主动审视哪些补丁已经不再必要——很多约束是为旧模型的缺陷打的补丁新模型下反而成为无效负担。退役流程任务完成使命 / 干预率长期过高 / ROI 转负 → 停调度 → 标记退役 → state 归档 → 通知上下游 Owner → 保留归档以供审计删除工作区。理解债的制度性对策• 走读制度L3 循环自动合入的代码Owner 每周固定时间抽样走读读不懂的部分要求循环补文档或降级人审• PR 审查政策分层核心路径的循环产出永远人审外围路径可抽检• 反认知投降Owner 每周写一条本周我不同意循环做法的地方——写不出来的时候恰恰是该警惕的时候理解债不是技术债技术债是代码烂理解债是代码可能不烂但你不知道它为什么是对的。完美验证器保证有没有退步不保证你是否理解为什么进步——理解债不会因为验证器强而消失。十三、总结Loop Engineering 的核心不是让 AI 自动干活而是• 从对话者变成系统设计者——你不再一轮轮喂 prompt而是设计一个能自己发现问题、执行、验证、交接的闭环• 杠杆支点移动——以前写一条好 prompt 收益是这一次回答变好现在设计一个好 loop 收益是之后每一次循环都变好• 人的位置变了但没消失——你可以当那个始终在场、清楚每一步在发生什么的工程师也可以当那个只负责按下开始键、然后看着代码越堆越多的人两个人设计完全相同的 loop 可能得到截然相反的结果一个用它在深挖领域内跑得更快另一个用它来彻底逃避对工作的理解。Loop 不知道区别但你知道。学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】