我不再 prompt Claude 了。我有一套 loops 在运行，它们会 prompt Claude，并决定接下来做什么。我的工作是写 loops。
在上一篇文章中，我们了解到什么是 Loop Engineering，今天，我们来看下如何将 Loop Engineering 应用到实际工作中。
从 Harness 到 Loop：差在哪里
我之前写过 Harness Engineering（构建让 AI 可靠工作的运行环境）。如果你没看过，一句话补课：
Harness 是为单个 Agent 搭舞台；Loop 是让整出戏自己演下去。
Harness 解决"一次做对"，Loop 解决"持续做对"。
Harness 是静态的——规则、文档、检查项在那儿等 Agent 来用。
Loop 是动态的——它自己发现工作、分发工作、检查工作、记录进度，然后决定下一步做什么。
| Harness | Loop | |
|---|---|---|
| 触发方式 | 你手动启动 | 按时间 / 事件自动触发 |
| 运行周期 | 单次会话 | 持续运行，跨会话 |
| 状态管理 | 在 context 里 | 在磁盘上（文件/看板） |
| 你的角色 | 操作者 | 设计者 |
一个真正能跑起来的 Loop，需要五样东西 + 一个记忆层：
| 构建块 | 一句话 | 核心机制 |
|---|---|---|
| Automations | 让它自己动起来 | /loop、cron、hooks、GitHub Actions——给 Loop 一个节奏 |
| Worktrees | 让并行 Agent 不打架 | 每个 Agent 独立分支 + 目录，共享 repo 历史，互不干扰 |
| Skills | 让 Agent 不靠猜 | 写一次项目约定（CLAUDE.md、me.md），每次运行都复利 |
| Connectors (MCP) | 让 Loop 连接真实世界 | 读 issue、查 DB、调 API、发 Slack——Agent 自己开 PR 而不是只给建议 |
| Sub-agents | 让"写的人"和"查的人"分开 | Maker ≠ Checker；独立 verifier 是你能放心走开的唯一原因 |
| Memory | Loop 的脊柱 | markdown / Linear board / state file——跨会话记住"做了什么、还剩什么" |
实战案例：知识编译 Loop
我有一个个人知识库，它的核心就是一条 Loop：
inbox/ → /triage 过滤 → raw/ → /compile 编译 → wiki/ → /briefing 推送洞见 → 我
↑ |
└──── RSS/Twitter 自动抓取 ←←←← 我的行动产生新素材 ←←←←←←←←←←←←←←←←←←←←←←←←←←┘
拆开看五个构建块怎么落地的：
| 构建块 | 我的实现 |
|---|---|
| Automation | 每天 6:03 自动触发 briefing；RSS 和 Twitter 定时抓取进 inbox |
| Worktree | 编译时用独立 worktree，避免和我正在编辑的文件冲突 |
| Skills | /triage、/compile、/briefing 各是一个 Skill，包含完整执行逻辑 |
| Connectors | Twitter fetch、RSS fetch 通过 MCP/脚本接入外部数据源 |
| Sub-agents | compile 时用独立 agent 做"涟漪更新"检查，避免主 agent 自己判断是否需要更新 |
| Memory | wiki/_changelog.md + raw/_registry.md 作为跨会话状态 |
两个月跑下来的数据：
- 自动过滤了 200+ 篇 inbox 素材，真正进入 raw/ 的不到 30%
- wiki 从 0 编译到 50+ 概念条目，全部由 AI 写和维护
- 每天早上收到 briefing，平均唤醒 2-3 个我已经忘了的知识连接
关键体感：我没有"管理"这个系统。我只是每天早上花 3 分钟看 briefing，偶尔手动扔一篇文章进 inbox。Loop 自己在转。
三个设计 Loop 的实操原则
先跑最小 Loop，再加层
不要一上来就搭五层全家桶。
我的第一版 Loop 只有：一个 cron + 一个 skill + 一个 markdown 文件当 memory。
跑了一周确认基本逻辑对了，再加 sub-agent 做质量检查，再加 connector 接数据源。
Loop 是迭代长出来的，不是一次设计出来的。
Maker 和 Checker 必须分开
这是最反直觉但最重要的一条。
我早期让 /compile 自己判断"这次编译是否需要更新已有条目"——结果它总是说"不用"。
后来拆成两步：一个 agent 编译，另一个 agent 拿着新素材去对比所有已有条目。更新率从 5% 跳到 30%。
自检是无效检测。
Silent failure 是 Loop 最大的敌人
Loop 在你不看的时候运行。如果它悄悄失败了，你可能一周后才发现。
我的做法：
- 每次运行写
_changelog.md，格式可 grep - briefing 里有一个"异常"模块，专门报告 Loop 运行中的问题
- 关键步骤失败时发通知，而不是静默跳过
谁该用 Loop，谁不该
先泼盆冷水：Loop 不是所有人都需要的东西。
| 适合 | 不适合 |
|---|---|
| 有重复性工作需要持续执行 | 偶尔用 AI 写个代码 |
| 你的判断力已经足够好，想放大它 | 你还没想清楚要 AI 做什么 |
| 愿意投入时间设计系统 | 只想快速拿到一个结果 |
还有一个更深层的警告：
两个人可以构建完全一样的 Loop，却得到截然相反的结果。一个人用它在自己深刻理解的工作上跑得更快。另一个人用它来避免理解工作本身。
Loop 不知道这两者的区别。但你知道。
如果你对自己领域的判断力不够，Loop 只会帮你更快地犯错。
从今天开始的最小行动
如果你想试试 Loop Engineering，不需要搭一个完整系统。从这三步开始：
第一步：找一个你每天/每周重复做的 AI 任务。
比如：review PR、整理笔记、扫描新闻、检查代码质量。
第二步：把它写成一个 Skill 文件。
不是 prompt，是 Skill——包含执行逻辑、输入输出规范、项目上下文。写一次，永久复用。
第三步：给它加一个触发器。
哪怕只是一个 cron job，让它每天自己跑一次。
恭喜，你有了第一个 Loop。
剩下的——sub-agent 验证、worktree 隔离、memory 持久化——等你觉得 Loop 不够可靠的时候再加。
最后
从 Prompt Engineering 到 Context Engineering 到 Harness Engineering，再到 Loop Engineering——每一次演化，人的角色都在后退一步。
但"后退"不是"消失"。
你从"写 prompt 的操作者"变成"设计系统的架构师"。
你的判断力、品味、对质量的要求——这些东西不是被替代了，而是被放大了。
Loop 是放大器。放大好的判断，也放大坏的判断。
所以这件事比 prompt engineering 更难，而不是更简单。
杠杆点移动了。构建你的 Loop——但要像一个仍然打算做 engineer 的人那样去构建它。