3.1 自动化调度（Automations）—— Loop 的”心跳”#

Automations 负责让 Loop 自己启动，而不是等人来喊。它包括两类触发方式：

关键设计原则：**不要让”人记得启动”成为系统的前提。**一个好的 Loop 应该是自驱动的。

3.2 工作树（Worktrees）—— 隔离运行环境#

当多个 Agent 并行工作时，它们不能共享同一个文件系统——会互相覆盖对方的修改。

基于 Git 的 Worktree 机制解决了这个问题：

1
# 每个子任务在独立的 Worktree 中运行
2
git worktree add ../fix-auth-bug main
3
cd ../fix-auth-bug
4
# Agent 在此环境中工作，互不干扰

Worktree 的三大价值：

• 并行安全：10 个 Agent 同时修 Bug 不会冲突
• 可回滚：Agent 改坏了直接删 Worktree，不影响主干
• 可审查：每个 Worktree 一个分支，改动隔离、可独立 Review

3.3 技能（Skills）—— 持久化项目知识#

如果说 Context Engineering 解决的是”单次会话给 Agent 看什么”，Skills 解决的是**“跨会话如何积累知识”**。

Skills 是存放在项目中的 Markdown 文件，Agent 每轮自动加载。它们包含：

1
.claude/
2
├── SKILL.md          # 总体项目规范
3
├── agents/
4
│   ├── reviewer.md   # 代码审查 Agent 的行为定义
5
│   └── fixer.md      # Bug 修复 Agent 的行为定义
6
└── skills/
7
    ├── coding-style.md   # 代码风格约定
8
    ├── architecture.md   # 系统架构约定
9
    └── pitfalls.md       # 踩过的坑

你踩过的每一个坑、总结的每一条规范，都会沉淀为 Skill，成为后续所有 Agent 的”肌肉记忆”。Skill 的质量决定了 Loop 产出的质量。

3.4 连接器（Connectors）—— 让 Agent 接入真实世界#

基于 MCP（Model Context Protocol），Agent 可以连接外部工具：

1
Agent ←→ MCP Server ←→ 外部系统
2
                           ├── GitHub API（读 Issue、开 PR）
3
                           ├── Slack（发通知、接收指令）
4
                           ├── 数据库（查询数据、验证结果）
5
                           ├── CI/CD（触发构建、读取日志）
6
                           └── Linear / Jira（更新工单状态）

没有 Connectors，Agent 只是在”沙箱里自言自语”。有了 Connectors，它才能真正影响外部世界——开 PR、更新工单、通知团队。

3.5 子 Agent（Sub-agents）—— Maker/Checker 分离#

这是 Loop Engineering 中最容易被低估但最重要的设计模式：不要让同一个 Agent 既写代码又审查代码。

1
// 错误设计：一个 Agent 自产自审
2
const result = await agent("修复这个 Bug，然后审查自己的修复");
3

4
// 正确设计：Maker 和 Checker 分离
5
const fix = await agent("修复这个 Bug", { role: "maker" });
6
const review = await agent(`审查这个修复：${fix.diff}`, { role: "checker" });

为什么要分离？

Checker 应该被提示为”默认不信任，除非证明正确”，而不是”默认通过，除非明显有问题”。 这个提示词的微小差别，决定了验证的有效性。

3.6 记忆 / 状态（Memory）—— 超越上下文窗口#

Agent 的上下文窗口（Context Window）是有限的，但一个持续运行的 Loop 需要记住已经做了什么、还剩什么没做。

Memory 层的实现可以很简单：

1
## 当前状态
2
- 最后运行: 2026-06-16 09:00 UTC
3
- 进行中: fix-login-timeout（PR #42 等待 Review）
4

5
## 已完成
6
- [x] 修复 API 超时重试逻辑 — #41 已合并
7
- [x] 更新依赖版本 — #40 已合并
8

9
## 待处理
10
- [ ] 排查 CI 偶发失败 — 已分配 Worktree ci-flaky-test
11
- [ ] 升级 Node.js 到 v26 — 等待 LTS

Osmani 强调：“每个成功的 Loop 背后，都有一套默默工作的状态文件。” 状态文件是 Loop 的”短期记忆”，Skills 是 Loop 的”长期记忆”。

6.1 验证仍是人的责任#

Loop 可以自动完成”声明完成”，但不能自动完成”证明正确”。

“完成了”是一份声明。“做对了”是一个事实。声明不等于事实。——Addy Osmani

Checker Agent 可以减少遗漏，但不能替代人的判断。安全变更、架构决策、用户体验问题——这些需要人的确认。

原则：Loop 可以自动处理你充分理解的问题；面对你不理解的问题，Loop 只是帮你把问题变得更清晰，决策仍然在你。

6.2 理解债务（Comprehension Debt）#

这是 Osmani 提出的一个关键概念，比技术债务更隐蔽也更危险。

1
Loop 生成代码的速度
2
         >
3
你理解代码的速度
4
         =
5
理解债务在累积

当 Loop 每天产出数万行代码，而你的理解速度是恒定的，理解债务会以指数级增长。总有一天，你会面对一个自己完全不知道如何运作的系统。

缓解策略：

• 设置 Loop 的”产出速率上限”——不是让它跑得越快越好
• 定期停下来，人工 Review 近期所有自动变更
• 对核心模块禁止 Loop 自动修改，只允许人工操作

6.3 认知投降（Cognitive Surrender）#

这是最深刻的风险——当系统能自己运转，人会本能地停止思考。

Cherny 的原话：“最舒服的姿势恰恰是最危险的。当你不再理解 Loop 在做什么但 Pipeline 还能跑的时候，你已经把工程师的核心能力交出去了。”

对抗策略：

• 定期”离线日”：每周有一天不用 Agent，纯手写，保持手感
• 自问测试：如果这个 Loop 明天消失了，你还能不能自己做完它做的事？
• 保持”以工程师的身份”搭建 Loop：你是在设计系统，不是在按”开始键”