五个构件与状态中枢

Loop engineering 最实用的贡献之一，是把一堆零散 agent 能力压缩成一个清晰骨架： 调度、worktree、skills、connectors、sub-agents，再加上状态 / memory。

先看全景

源仓库把 loop 的构件总结成“五个 building blocks + memory”。这个提法好用，因为它避免你一上来就陷入某个工具的专有功能，而是先回到能力层：

• 调度 / 自动化
• 隔离执行环境
• 项目知识与规则
• 外部系统连接
• 角色分工
• 状态中枢

把它们串起来，大概就是这样一条链：

schedule -> triage -> read/write state -> isolated worktree -> implementer -> verifier -> connector actions -> human gate

这条链不一定每次都完整出现，但多数能长期运行的 loop 都绕不开这些问题。

一、调度 / 自动化：决定 loop 什么时候活过来

这是所有 loop 的起点。

没有调度，就没有“持续运行”，只有“我想起来时手动叫 agent 做点事”。

调度层负责解决：

• 每 5 分钟、每小时、每天还是事件触发
• 首次启动后要不要立刻跑
• 是否能跨重启继续存在
• 夜间要不要降频或暂停
• 待办清空后是否自动停机

一个成熟团队不会一上来追求高频，而是先问：

这个问题的发现延迟，值不值得我为它付出这条 loop 的 token 和噪音成本？

比如：

• Daily Triage 适合天级或小时级
• PR Babysitter 适合 5-15 分钟
• CI Sweeper 适合更密，但成本也更高

所以调度不是“越快越高级”，而是“和问题时效性匹配”。

二、Worktree：让自动化改动别直接污染主工作区

如果 loop 只做报告，worktree 不是刚需；一旦 loop 开始尝试修复、改依赖、生成提交，worktree 基本就该成为标配。

它的价值很朴素：

• 每次自动尝试都有隔离空间
• verifier 可以在独立环境里验证
• 失败后直接丢弃，不污染主分支
• 并行尝试时彼此不打架

这一步的重要性往往被低估。很多“自动修复很危险”的体验，本质上不是 agent 太蠢，而是执行环境没有隔离。

更直接地说：

• 没有隔离，自动化错误会直接变成本地混乱
• 有隔离，自动化错误大多只是一次可丢弃的实验

三、Skills：让 loop 不是每次都重新解释项目

Loop 不是一次性会话，所以它必须有长期稳定的任务描述和项目规则载体。

这就是 skills 的位置。

一个好用的 loop skill 一般会明确：

• 本轮先读哪些文件
• 输出写到哪里
• triage 后怎样分类
• 哪些情况下禁止改代码
• build / test / verifier 怎么执行

和普通 prompt 相比，skill 的价值在于：

• 可复用
• 可版本化
• 可被多个 loop 共用
• 可被不同工具迁移

如果你准备把一条 loop 长期跑下去，skill 应该写得平淡、具体、可验证，而不是写成“像一个资深工程师一样聪明地判断一切”。

四、Connectors / MCP：让 loop 接触真实世界

只会读本地仓库的 loop 很快会遇到天花板。

真实工程里，loop 往往还要接触：

• GitHub 的 issue、PR、Actions
• Linear / Jira 的任务状态
• Slack / 飞书的通知出口
• 依赖和安全扫描结果
• CI 平台和日志系统

这就是 connectors 或 MCP 的位置。

它们让 loop 不只是一段“仓库内自动化”，而是能把判断写回外部系统，形成真正闭环。

但这层同时也是风险放大的开始。因为只要接了外部系统，loop 就可能：

• 创建或修改工单
• 评论 PR
• 开分支、提 PR
• 触发 Actions
• 修改远程状态

所以这层最重要的原则不是“能接多少”，而是：

最小权限、先读后写、先建议后执行。

五、Sub-agents：把 maker / checker 分开

这是 loop 从“自动写东西”升级到“有基本工程纪律”的关键一步。

最常见的分工就是：

• Implementer / Maker：负责生成改动、提建议、做修复
• Verifier / Checker：负责跑测试、检查约束、决定是否通过

为什么必须拆开？

因为同一个 agent 同一个上下文里，最容易出现的就是“自我合理化”：它写了改动，于是更倾向于相信改动已经够好了。

maker / checker 分离至少能带来三层好处：

• 降低自评偏差
• 让验证逻辑更稳定
• 便于后续替换不同模型或不同权限

这也是为什么很多 loop 设计都强调：

实现者不能自己宣布完成，完成必须由 verifier 或人类 gate 决定。

六、状态 / Memory：loop 的脊柱

前面五个构件都重要，但状态层是脊柱。

为什么？

因为 loop 的本质是跨时间运行。只要跨时间，就一定要解决“上次发生了什么、这次从哪继续”的问题。

状态层至少要回答这些问题

• 上次运行是什么时间
• 找到了哪些待办
• 哪些已经处理，哪些还在观察
• 哪些项重试了几次
• 哪些项必须升级给人
• 哪些 loop 被暂停了，为什么暂停

常见状态载体

• STATE.md
• LOOP.md
• loop-budget.md
• loop-run-log.md
• issue board / Linear / GitHub Projects

重点不在文件名，而在每轮都要读、每轮都要写、团队能独立审查。

如果 loop 只把信息留在聊天记录里，它就不是工程系统，只是对话副产品。

一个建议的状态分层

为了让状态不至于越写越乱，可以按职责拆成三层：

一、运行规则层

写在 LOOP.md 之类的文件里，放：

• loop 目标
• cadence
• denylist
• human gate
• verifier 规则

这是“这条 loop 应该怎样运行”。

二、当前世界状态层

写在 STATE.md，放：

• 高优先级事项
• watch list
• 最近动作
• 最后运行时间
• 升级记录

这是“这条 loop 当前看见了什么”。

三、预算与审计层

写在 loop-budget.md、loop-run-log.md，放：

• token 预算
• 每日上限
• 运行次数
• 失败和暂停原因

这是“这条 loop 花了什么代价、发生过什么事故”。

一个最低配 loop 的组合方式

如果你第一次搭 loop，不需要把所有构件都堆满。最低配版本可以是：

1. 每天一次调度
2. 一个 triage skill
3. 一个 STATE.md
4. 只读 GitHub / 仓库
5. 只输出报告，不改代码

这已经足够形成 L1 报告型 loop。

等它稳定后，再逐步加：

• worktree
• verifier
• 写权限 connector
• 小范围自动修复
• budget / run log / kill switch

设计顺序建议

如果按重要性排序，我会建议这样搭：

1. 先定义状态
2. 再写 triage skill
3. 再决定 cadence
4. 再引入 verifier
5. 最后才引入自动写回和外部写权限

原因很简单：

• 没有状态，loop 无法连续
• 没有 triage，loop 无法稳定输出
• cadence 太早定，容易空转
• verifier 太晚加，容易越权
• 写权限放太早，最容易出事故

一个实用判断

如果你发现某条 loop 主要时间都花在：

• 解释上下文
• 找上次结果
• 追踪自己做过什么
• 人工帮它判断这次能不能继续

那通常说明它的状态层没有设计好，而不是模型不够强。

延伸阅读