外层六构件：把 Loop 放大成系统
前四篇讲的是「怎么设计一个 Loop」——三张卡、独立评审、交付物、校准。那个 Loop 能跑，但它像一辆只有发动机的车：能转，但没有油箱、轮子、方向盘。
这一篇讲外层六构件——把单个 Loop 放大成「能生产用的系统」。
一、内层 vs 外层
内层（前四篇）：单个 Loop 怎么转 —— 三张卡（标准/反馈/终止）
外层（本篇）： Loop 系统怎么搭 —— 让 Loop 真正生产可用
一句话：内层是「发动机」，外层是「整车」——发动机让它转，整车给它油箱、轮子、导航、方向盘。
二、外层六构件总览
Automations 谁触发这个 Loop？ （定时/事件）—— 什么时候开始
Worktrees 在哪儿跑？ （隔离）—— 多个 Loop 不打架
Skills 靠什么知识？ （规范）—— 不用每轮重复解释
Connectors 能碰什么工具？ （GitHub/Slack/数据库）—— 接入工作流
Sub-agents 谁写谁查？ （分工）—— 防假达标
记忆持久化 记住做到哪了？ （写盘）—— 崩溃能续跑
| 构件 | 可能早就做过的 |
|---|---|
| Sub-agents | 登录模块的「独立评审」 |
| Skills | 你写的 SKILL.md |
| Connectors | 你写的 MCP 服务 |
| 记忆持久化 | 你的笔记 / 记忆系统 |
三、构件逐个详解
构件 ① Automations：谁触发 Loop？
是什么：触发 Loop 的机制。没有它，Loop 只能手动喊「开始」。
三种触发方式（强度递增）：
方式 A：手动触发（最弱）
你：按这份设计开发登录模块 → Loop 跑一次，做完停
→ 适合：一次性任务
方式 B：定时触发（中）
「每天早上 9 点检查 token 是否过期，过期就自动修复」
→ 适合：周期任务
方式 C：事件触发（最强）
「GitHub 新 issue 提到登录 bug → 自动触发修复 Loop」
→ 适合：响应式任务
在 Claude Code 里的工具：
手动触发 → 你说「按这个开发」/ 输入命令
定时触发 → cron / 定时任务（按时间重复）
事件触发 → GitHub Actions / Hook（事件时触发）
和内层关系：内层卡 3（终止条件）= 什么时候停；外层 Automations（触发）= 什么时候开始。配对使用。
构件 ② Worktrees：Loop 在哪儿跑？
是什么：给每个 Loop 一个独立工作副本，各改各的，互不干扰。
没有 Worktrees：
多个 Loop 同时改一个目录 → 改同一行 → 互相覆盖 → 冲突
有 Worktrees：
Worktree A ← Loop 1 改
Worktree B ← Loop 2 改
→ 并行干活不打架 → 干完再合并
和内层关系：内层「交付物清单」防止单个 Loop 结构漂移；Worktrees 防止多个 Loop 互相干扰。一个管「单个不乱」，一个管「多个不打架」。
注意：不是所有 Loop 都需要 Worktrees——单个 Loop 不需要，多个并行才需要。
构件 ③ Skills：AI 靠什么知识干活？
是什么：把「项目怎么做的约定」写成文件，AI 不用每轮重新猜。
没有 Skills：
AI 每轮问「项目用什么架构？」→ 你答 → 下轮又问 → 烦死
有 Skills：
写一份项目规范 → AI 读一次 → 后面所有轮都知道了
和内层关系：卡 1（验收标准）是 Skill 的一个子集——Skill 更全面，还包含架构、风格、验证方式。
注意区别：
交付物清单 → 告诉 AI「要生成哪些文件」（范围，做什么）
Skills → 告诉 AI「按什么规范生成」（方式，怎么做）
构件 ④ Connectors：Loop 能碰到什么外部工具？
是什么：让 Loop 连接外部系统（GitHub、Slack、数据库、issue 追踪器）。
没有 Connectors：
Loop 只会读写本地文件 → 修完 bug 不能建 issue、不能通知团队
有 Connectors：
Loop 修完 bug → 自动更新 issue → 自动开 PR → 自动通知 Slack
和 Automations 的区别（容易混） ：
Automations → 谁触发 Loop？（什么时候开始）
Connectors → Loop 能碰什么工具？（能干什么）
关键：Connectors 让「全自动」真正成立——没有它，Loop 自动了但结果「困在本地」。
构件 ⑤ Sub-agents：谁写谁查？
是什么：把「写代码的」和「检查代码的」分开。这是 02 篇「独立评审」的系统化。
没有 Sub-agents：
一个 AI 又写又查 → 自己评自己 → 假达标
有 Sub-agents：
生成 Agent 写代码 → 评审 Agent 检查
→ 不同脑子，能发现真问题
独立程度决定可靠性：
同一个 AI 换 prompt 假装评审 → 还是同一个脑子 → 效果差
独立的 Agent（不同进程/模型）→ 真正分开 → 效果好
构件 ⑥ 记忆持久化：记住做到哪了？
是什么：把 Loop 的进度、状态、决策写到磁盘，中断后能接着跑。
没有记忆持久化：
Loop 跑到一半 → 会话崩溃 → 进度全丢 → 从头再来
有记忆持久化：
每轮状态写进 progress.md → 崩溃后读取 → 从断点继续
关键原则：记忆存在磁盘，不存在 AI 的「脑子」里。
AI 上下文窗口会丢 → 会话长了旧信息就没了
磁盘文件不会丢 → 状态永远在
四、六构件解决什么问题（一张表）
Automations 让 Loop 自动开始（不靠人触发）
Worktrees 让 Loop 并行不打架（隔离）
Skills 让 AI 不用每轮重复问（知识注入）
Connectors 让 Loop 接入工作流（外部工具）
Sub-agents 让 Loop 不假达标（分工检查）
记忆持久化 让 Loop 扛住中断（状态落盘）
五、和已学能力对应（这很重要）
你可能已经发现——六构件不是抽象概念，是你早就在用的能力的「命名」：
| 构件 | Claude Code 里的实际工具 |
|------|------------------------|
| Automations | cron / GitHub Actions / Hook |
| Worktrees | git worktree（EnterWorktree）|
| Skills | .claude/skills/ 的 SKILL.md |
| Connectors | MCP（连接 GitHub/Slack/数据库）|
| Sub-agents | 子代理（生成 Agent / 评审 Agent）|
| 记忆持久化 | progress.md / 记忆系统 |
关键认知：外层六构件的价值不在「新」，在「系统化」——你散落会用的能力，被命名成一个完整的框架，能组合出「生产级 Loop 系统」。
六、一个清醒的提醒：不是所有 Loop 都要六构件
单 Loop（简单任务）：
→ 只需要：三张卡 + 独立评审
→ 六构件是「锦上添花」，硬加是过度工程
生产级 Loop（长期/无人值守/多人）：
→ 六构件才都用到
→ Automations（自动触发）+ 记忆（断点续跑）是关键
判断标准：这个 Loop 要不要「自动、并行、持久、接工作流」？
要 → 上六构件
不要 → 三张卡就够
七、这一篇总结
内层三张卡 = 单 Loop 怎么转（发动机）
外层六构件 = Loop 系统怎么搭（整车）
六构件：
Automations 触发 / Worktrees 隔离 / Skills 知识
Connectors 连接 / Sub-agents 分工 / 记忆持久化
关键认知：
① 六构件是你已会能力的「命名」→ 不是新概念
② 生产级 Loop = 内层三张卡 + 外层六构件
③ 别硬加——简单 Loop 三张卡就够
