Loop 设计 + 体检

一句话前提：LLM 本身是前馈系统（prompt 进 → token 出，跨轮之间没有内建的"朝目标纠偏"能力）。要它表现得像目标导向系统，得在外面包一条反馈回路（loop）。这个 skill 帮你写对这条回路、并体检它不会跑飞。

何时用 / 不用

用：

• 想把一个重复任务交给 agent 自动反复跑（写完测、测完修、改完验…）。
• 已经写了个 loop，但担心它空转 / 作弊 / 跑飞，要体检。

不用：

• 一次性任务 → 直接做，别套循环。
• 纯定时提醒 / 轮询 → 用 /loop 命令即可，不需要"设计"。
• "怎么搭循环的工程架构（管道→DAG、长跑恢复）" → 那是机制层，看 autonomous-loops / continuous-agent-loop。本 skill 只管"目标定得对不对、会不会跑飞"这层判断，不重写机制。

红线前提：两层反馈（先记死，违反则全盘皆输）

层	谁管	干什么
执行层（低层）	机器 / agent	测"离字面目标还差多少"，死磕缩到 0。机器很强。
判断层（高层）	人	判"这目标本身对不对、要不要改、要不要停"。机器跳不出自己的回路质疑目标。

空调能反馈"离 26 度差多少"，但你发烧想要 28 度时，它判断不了"26 度对不对"——只会死磕 26。"今天该设几度"永远是人。 把判断 / 验收 / 最后一格交给机器 = 撤掉高层反馈 = 机器照着没人质疑的目标又快又狠地狂奔 → 出错。

---

动作一：写一个 loop（5 步）

步 0 · 先做减法：该不该建？（四条件入场券，缺一票否决）

① 任务每周以上重复　② 验证能自动化　③ token 预算扛得住　④ agent 有"能真跑起来看结果"的工具

任一不满足 → 别建 loop，手动做或换别的方式。

卡住大多数人的不是"会不会写循环"，是"你那个仓库配不配得上一个循环"。配得上的仓库 = 有对账基线（golden sample / 上游合计）+ 单测 + lint 守护。配不上循环的仓库，循环只会放大错。

步 1 · 定一个"可判定"的目标（最吃劲，loop 成败全在这）

整条回路靠"比较器"那句"达成了吗"。比较器能不能干活，全看你给的退出条件能不能被机器清楚判 yes/no。

• ❌ 模糊（"把这个做好""写高级点"）→ 比较器没法判 → 要么永远不放行（卡死反复重试），要么瞎放行/瞎拦截。
• ✅ 可判定（"96 个单测全绿且出改动清单""模块02字段补全、pytest 全过、没改业务逻辑"）→ 一查就知道，回路干净收敛。

目标定义五条框架：

1. 完成标准可被机器验证。
2. 边界条件和完成标准一起定义（"不能怎么做"）——防 Goodhart，缺边界 = 给 agent 发作弊许可证。
3. 有失败降级方案——重试上限 N + 超了升级人工。
4. 目标分层。
5. 完成标准优先"对账型"而非"断言型"——锚外部事实（golden sample / 上游合计 / 财务勾稽 / 平台后台数字），其次才是自己写的断言。"测试全过"能被钻（改松断言、注水 mock、吞异常）；"和 VBA 差异 < 0.01"钻不了。

自检：把目标念给一个不懂业务的人，他能不能跑一条命令就判出"到没到"？不能 → 还不够可判定，回来改。

步 2 · 选回路类型

你的任务	回路（控制论对应）	怎么停
有明确"完成"判据（写到 done / 一批图处理完 / researcher 出 findings）	servo（/goal 型，闭环伺服）	到目标就停
没终点、要持续维持（库存预警 / 报表定时体检）	regulator（/loop 型，恒温器）	不停，有变化才动作（[SILENT] 死区压噪声）
周期采样、满足条件就停（盯 PR 直到 CI 绿）	带退出的 regulator	退出条件满足就停
要"确保某事按时发生"	把上面包进 /schedule	cron 到点触发

经验法则：有"完成"判据 → servo；要持续维持没终点 → regulator；要"按时发生" → regulator 包进 schedule。 （/goal 本质就是一个总返回 block 的 Stop 钩子：agent 想停但"不准停"直到达标——是 veto，不是 push。）

步 3 · 选骨架

守成型（看护已有东西）→ 文档驱动派活 loop 不是"定时跑固定检查"，是 "定时读文档、文档变了才派活"。文档 = 任务队列 + 状态机 + 人机接口。 三条纪律：① 问题列只人写、结果列只 loop 写、状态单向推进不回头 ② 退出码是终审（脚本 exit 1 就以脚本为准）③ 状态推到"待验证"为止，"已完成"那格只有人能扳——loop 当工人，不当验收官。

产出型（从零搭东西）→ plan / build / judge 三角色循环

角色	干啥	关键
Plan	把目标拆成 spec + 可判定的验收条件	验收条件必须能被脚本判
Build	照 spec 写	不准改验收条件
Judge	独立跑验收，过→停 / 不过→带失败原因回 Build	独立 + 确定性规则

三条铁律（全押在 judge）：① Judge 必须独立——不能是 Build 那个 agent（自己批作业必放水）② 用确定性规则——pytest / 对账差异 / 类型检查 / diff，不靠"看着对" ③ 不准 Build 改验收条件过关。重试 3 次还不过 → 升级人工。

步 4 · 加阻尼（防震颤 / 跑飞）

重试上限、硬停、人扳最后一格 = 阻尼。没有阻尼的负反馈会震颤（Ralph Wiggum loop：在原地空转烧钱）。

步 5 · 落地三档（别一上来就全自动）

① 先手动跑通一次（逼自己讲清"judge 到底怎么判"）→ ② 固化成 skill / Claude Code sub-agents（主 Claude 循环派 plan/build/judge）→ ③ 挂 cron / hermes 全自动。

---

动作二：检查一个 loop 对不对（体检清单 = 五个崩法防呆）

拿写好的 loop 逐条过。命中任一条 = 这 loop 会出事，打回重写。 这五条是负面经验（gotchas），比正面规则值钱。

#	崩法（会怎么坏）	体检问题（命中即红）	抗体
1	目标是句正确的废话 → 空转烧钱	退出条件能被机器判 yes/no 吗？还是"管好 / 做好"这种？	换成可判定的结果条件（动作一·步1）
2	验证写成"检查对不对" → agent 自信说没问题就停	judge 是不是被告自己？验证靠"看着对"还是确定性规则？	对账 + 退出码说了算 + judge 独立
3	（最痛）只卡"测试全过" → agent 删了测试	有没有边界条件（"不能怎么做"）？还是只有完成标准？	完成标准 + 边界 一起定（Goodhart 抗体）
4	指望 agent 中途来确认 → 它不会，把错的干到底	有没有"运行中才需要人澄清"的点？	所有澄清前置，出发前一次答死
5	CLAUDE.md 膨胀 + 记忆过期 → loop 越快错越多	它依赖的文档 / 记忆新鲜吗？谁维护？	记忆三层 + 定期 lint 体检

再加判 3 条红线（违反任一 = 不准上自动）：

• 判断留人：验收 / "已完成"那格人来扳，loop 不当验收官。
• 责任不可转移：凡"失败后果你担不起"的事（合错 PR / 发错图 / 分错钱），不自动交权。
• 反直觉警告：越是"自改进 / 自己改规则"的 loop，越需要更严的人审（看它把规则改成了啥），不是更放手。机器快到来不及拦，人的判断必须卡在动手之前（硬 gate），不能出错了再补。

---

一句话收口

写 loop 真正吃劲的不是"会不会写循环"，是"定一个机器能对账的目标"——可判定、带边界、对账型。控制器要确定性且外置；判断和标准留人；系统会熵增所以要持续维护。 循环只奖励已经想明白的人。指望它替你想，它会很乐意带着你一起想错。

---

来源：小磊《控制论×Loop×Goal——把 LLM 管成目标导向系统》（vault 01-AI实践经验/10）。plan/build/judge 源 Anatoli《Loops explained》/ Addy《Loop Engineering》；两层反馈 + 红线源 维纳《人有人的用处》(1950)。 机制层（怎么搭循环架构）见 autonomous-loops / continuous-agent-loop；本 skill 不重写机制，只管目标与防跑飞。