---
title: 'Loop Engineer 入门:四大组件、共享文件系统与回路契约'
video_id: W6x-hb44C0c
url: https://youtu.be/W6x-hb44C0c
title_en: "wtf is Loop Engineer & how to setup for real"
channel: AI Jason
published: 2026-06-18
duration: "20:03"
topics: [Agent 工程, 多 Agent 协作, AI 自动化, Claude Code 定制扩展]
noted: 2026-07-08
value: A
views: '4.2万'
---


[![封面](https://i.ytimg.com/vi/W6x-hb44C0c/maxresdefault.jpg)](https://youtu.be/W6x-hb44C0c)

> AI Jason · 20:03 · 发布 2026-06-18 · 4.2万次观看(截至抓取) · [观看原视频](https://youtu.be/W6x-hb44C0c)

## 主旨

Loop engineer 是一类新角色:不再 prompt 编码 agent,而是设计让 agent 跨 session 持续自动跑的环境——四大组件(触发器、文件结构、工具、可验证代码库)加上共享文件系统和每 loop 一份的"契约",就能让多个并行的 loop 互相喂信号、复利累加。

## 核心论点

1. **Loop engineer 不是 prompt 写手,是设计 agent 持续运行环境的人**——agent 被定时/事件/其他 agent 唤醒,在跨 session 状态上持续推进,人只在 review 信号时介入。([[#1-loop-engineer-是什么不再-prompt设计环境-0029|→ 详解1]])
2. **优化分两层,loop engineer 只管外层**——内层是单个 agent session 怎么把任务做对(交给 Claude Code/Codex),外层是这个 agent 助手怎么决定"现在该做什么",后者才是 loop engineer 的工作面。([[#2-内层-vs-外层loop-engineer-只管外层-0511|→ 详解2]])
3. **四大组件缺一不可,且"可验证代码库"是最被忽视的一个**——很多人只搭 trigger 和文件结构,但不把代码库改成可独立验证,loop 跑起来也只是制造垃圾 PR。([[#3-四大组件缺一不可-0910|→ 详解3]])
4. **可验证代码库 = legible + executable + work-tree friendly + verifiable 四件套**——agent 能看懂、能一键起服务、并行 worktree 互不冲突、有 playright(视频口播对工具名的转写误听,wikilink 见详解4) + PR skew 工具自检。([[#4-可验证代码库四件套legible--executable--worktree--verifiable-0947|→ 详解4]])
5. **共享文件系统是让多个 loop 复利起来的关键**——artifact、signal、log 三类文件,被所有 loop 读写,各 loop 互为彼此的"记忆体"。([[#5-共享文件系统三类文件跨-loop-读写-1300|→ 详解5]])
6. **每个 loop 一份 README 当 contract,作为该域的规约入口**——goal、workflow、backlog、timeline 四要素,下次 loop 触发时先读它再动手,代替每次都重述 prompt。([[#6-每个-loop-一份-readme-当-contract-1443|→ 详解6]])
7. **PR skew 里"spawn 一个 read-only verifier agent"是底线**——不要让 agent 自评自纠,否则复合错误率会随步数灾难性放大。([[#7-pr-skew必须-spawn-read-only-verifier-agent-1210|→ 详解7]])

## 知识点详解

### 1. Loop engineer 是什么:不再 prompt,设计环境 [00:29](https://youtu.be/W6x-hb44C0c?t=29)

作者给出的工作画面:凌晨 1 点,codebase 不断收到 PR,但不是有人在加班,是一堆 agent loop 各自在自动找事做、提交工作。

更具体的例子是作者本人的 SEO go loop——已经连续跑两天,每天自动产出 20-40 篇高质量 SEO 页给作者公司拉流量,全程他没碰。

这就引出 loop engineer 这个新角色:过去一年所有人都在谈"别再 prompt 编码 agent 了",不是说你不需要思考,而是核心动作从"写 prompt"换成了"设计让 agent 反复被唤醒并持续推进的环境"。

### 2. 内层 vs 外层:loop engineer 只管外层 [05:11](https://youtu.be/W6x-hb44C0c?t=311)

作者用一组二分把领域切清。一边是 agent loop 本身(Claude Code、Codex、或自己写个 Pi agent),它关心的是"给一个任务,怎么把它做对"。

另一边是这个 agent 助手系统的外圈,关心的是"这个任务现在该不该做、谁来做"——具体点说,是"用什么 trigger 把 agent 唤醒、跑完结果落到哪里、下次怎么续上"。

作者强调"loop engineer"这个新词专指外圈。整体效果是把人从"手把手 prompt"里彻底解放——trigger 可以是 cron、可以是另一个 agent、可以是服务端 incident 的 webhook,任一发生 agent 都会被自动唤醒去交付一段有意义的产出,人不用在场。

### 3. 四大组件,缺一不可 [09:10](https://youtu.be/W6x-hb44C0c?t=550)

要真把这种"复利 loop"在自己生意上跑起来,作者列了四个 ingredient:trigger、文件结构、工具与连接器,以及最容易被忽略的一项——把 codebase 本身改成"允许多 agent 并行且能各自验证自己工作"的环境。

它们是顺序依赖的:没有合适的 trigger,loop 起不来;没有正确的文件结构,loop 跑出来的产物不能被其他 loop 消费;没工具,agent 干不了真活;最后,没可验证的代码库,前面三项搭好了也只会在 PR review 阶段暴露成吨的低质变更。

下面详解 4-6 依次展开后三项——触发器在第 1 节的描述里已经覆盖核心。

### 4. 可验证代码库四件套:legible + executable + worktree + verifiable [09:47](https://youtu.be/W6x-hb44C0c?t=587)

第一件 legible:代码库要 agent 容易看懂。视频里提到一个团队维护一份约 100 行的 agents.md 作为索引,指向其他文档系统,让 agent 渐进式探索信息(口播转写为 "Open keeps their agents.m MD file");这套大家应该已经在做。作者额外加的一条是 custom linter——你不能指望 agent 自己找到所有规则,所以把"禁用某些 import""必须用某种模式"这些规则编进 linter,agent 写文件时违反就自动报错。这条本质是"主动 context engineering":与其让 agent 满仓库乱找信息,不如把规则注入它必经的检查路径。

第二件 executable:agent 应该一条命令就把 dev server 拉起来,理想是零 token、零认知开销,直接进入工作。具体的做法是 repo 里写好 dev local script,agent 调用即可。

第三件 work-tree friendly:当五六个并行 agent 各自在 worktree 上干活时,每个 agent 都能起自己的 dev server 而不互相冲突,还能靠脚本跳到指定状态(全登录/全登出)测特定场景——所有这些都是"给 agent 验证自己工作的捷径"。

第四件 verifiable:给 agent 真正能自检的工具。作者最推的是 Playwright CLI——它不仅让 agent 控浏览器,还能录视频片段上传到 PR 附件,人 review 时直接看录屏,比日志友好太多。再叠几套 end-to-end 测试覆盖关键流程(升级、注册、Superdesign 的"创建设计")、再加 PR skew 把 PR 提交前的步骤写死,基本就把"低质变更"挡在 PR 阶段。

作者把他这套封装成了一个叫 `set up a codebase harness` 的 skill(开源在 description 的 GitHub repo 里),可以直接丢给 Claude Code / Codex,让它把当前 codebase 改成 agent-friendly 的形态。

### 5. 共享文件系统:三类文件、跨 loop 读写 [13:00](https://youtu.be/W6x-hb44C0c?t=780)

loop 之间的复利怎么产生?作者的经验是把"文件与日志系统"做成共享的:不归属于任何单个 loop,所有 loop 都读、都写。具体的最佳实践,他观察下来有三类文件属于合适的抽象粒度。

第一类是 artifacts——每个 agent 工作的产出,作为"共享知识层"。可以是文档、信号、任务,作者场景下还分 SEO loop、support loop、product growth loop、pricing loop、口播里被转写为 "red loop" 的 loop,每个 artifact 类型有自己的文件夹,文件夹内放 README 写明"什么进、什么不进、添加新项的流程、schema";每条具体 artifact 有 metadata、主体内容、timeline 三个部分。

第二类是 signals——任何 loop 观察到的东西(产品想法、用户反馈、机会),生成一个 signal md 文件,链回原始来源(用户反馈、support ticket 等),并按"同一议题多来源追加"的模式持续累积。某次跑发现多人在问"如何导出文件",就建一个 export-files.md,每次又有人问就 append 同一条。

第三类是 logs——和前两类不重叠,专给人用:作者白天一半时间在 review loop 产出、一半在和 agent 协作做真活,需要 agent 能跨域快速读"最近发生过什么",以及能随手记杂项信息。办法就是一个全局 work log.md,每个 agent 完成大块工作时追加一段,开工前先读最近 5-10 条。

这套共享文件系统直接带来复利:SEO loop 看到某个词点击高、转化低,记一条"转化缺口"signal;ads loop 看到某关键词 clickthrough rate 不错但没有自然内容,signal 一进,SEO loop 下次跑就读到了,主动给该词做内容。各 loop 共用一个脑,自然就把短板补上。

### 6. 每个 loop 一份 README 当 contract [14:43](https://youtu.be/W6x-hb44C0c?t=883)

每个 loop 本身要带一个"contract"——goal、workflow、backlog、timeline 四要素写成一个 README,作为该域的规约入口。

下次 loop 触发时,agent 先读 contract,再行动——goal 告诉它"这次该做哪类事",workflow 是"怎么动手的步骤",backlog 告诉它"上次的待办",timeline 告诉它"上次跑完时停在哪"。

作者每个 loop 单独一个文件夹,文件夹里就是这个简单 README。contract 真正落地之前要人工 + agent 一起跑一次 test run,test run OK 之后再让 agent 把合同写出来、再 setup loop——这是把"边跑边改"的风险关进 test run 这一道闸里。

### 7. PR skew:必须 spawn read-only verifier agent [12:10](https://youtu.be/W6x-hb44C0c?t=730)

最后一条具体到 PR skew 的设计:别让 agent 自评自纠,这是作者反复强调的"重要一点"。

复合错误率随步数灾难性放大(参考既有笔记 复合错误率 的论证),自评很容易过拟合"我觉得我做对了",实质上等于没验证。正确的做法是在 PR skew 里写死:"agent 必须 spawn 一个 read-only 的 verifier 子 agent,带上详细背景,然后拿回结果";这个 verifier 是独立上下文、独立目标,正符合 Verifier Agent 的双层设计范式。

## 可执行步骤

- [ ] 先把 codebase 改造成 legible + executable + work-tree friendly + verifiable 四件套(用 `set up a codebase harness` skill 或自己照四件套改),这是任何 loop 工程的前置条件。
- [ ] 在共享文件系统里建三类目录:`artifacts/`、`signals/`、`logs.md`,README 写明每类文件的入项规则与 schema。
- [ ] 把现有想自动化的流程逐个改成 loop:先与 agent 一起手动 test run 一次,calibrate 完再让 agent 写出 contract,最后把 contract 转成定时/事件触发的 loop。
- [ ] 每个 loop 一个独立文件夹,根上放一份 README 作为 contract(goal / workflow / backlog / timeline 四要素),loop 触发时第一步就 read this contract。
- [ ] PR skew 写死"spawn 一个 read-only verifier agent"这一步,不允许自评替代。
- [ ] 给 agent 装 Playwright CLI 录屏 + 端到端测试套件,让 PR 附件里直接有视频证据,review 速度比读日志快一个量级。
- [ ] 多 loop 共用一个共享脑:SEO loop 发现的转化缺口,自然应该被 product loop 读;ads loop 看到的高 clickthrough rate 无内容词,自然应该被 SEO loop 读。

## 关联

- 进阶:[[Harness]]——本片是 harness 工程的具体落地形态,既有笔记停在"harness 是什么"层面,本片给的是"用四大组件 + 共享文件系统把 harness 真正跑成持续产出"的可操作版本。先读 [[Harness]] 理解"非模型的一切",再读本片上手。
- 互补: Signal Engine——两者都强调"事件沉淀到统一层"以驱动后续决策,但关注点不同:信号地图是仪表盘/可视化(展示权与控制权分离),本片的 signals 是 loop 之间的共享文件系统写入接口(读写对称)。前者是给人看的,后者是给其他 loop 看的,层级互补。
- 冲突/更新:复合错误率 vs PR skew 的自评禁令——本片给出的具体对策是"spawn read-only verifier agent",这与既有 复合错误率 主张的"多步串联需独立审查"完全一致;判定变量:任何 ≥2 步的自动 PR 流程,执行主体是 agent 时一律走 verifier,人写代码时按 Human-in-the-Loop审批 处理。
- 同批互补:同属 Loop engineering 主题——本片是"怎么把 loop 环境搭起来"的建造侧;[[2026-06-18-Loop engineering 真香还是噱头：Claude Code 与 OpenClaw 主创力推背后的三大代价与 Harness 化方案|Loop engineering 真香还是噱头]] 是"三大代价 + Harness 化"的冷思考侧;[[2026-06-19-终于把Agent循环讲清楚了|终于把Agent循环讲清楚了]] 从最简 reason-act-observe 骨架讲清 Agent loop 本身。三篇合看=概念→建造→代价的完整闭环。

## 一手来源与延伸

- 视频所引用的 loop engineer 开源模板(本片核心产物,作者团队最佳实践封装):https://github.com/JayZeeDesign/loop-engineer-template
- 作者在 AI Builder Club 的 step-by-step workshop(把整套四大组件从 0 搭一遍的实操):https://www.aibuilderclub.com/lp/loop-engineer
- 作者的 `set up a codebase harness` skill,封装本片第 4 节"四件套"的具体改造:见上述 loop-engineer-template 仓库

## 术语

- Loop Engineer(循环工程师:设计 agent 持续运行环境而非写 prompt 的新角色)
- Cross-session work(跨会话工作:多个 agent session 通过共享状态接力完成长任务的模式)
- Loop(循环:一次 agent session + 产物的反复执行单元)
- Loop Trigger(循环触发器:唤醒 loop 的来源,cron / 事件 / 其他 agent / webhook)
- Loop Contract(循环契约:每个 loop 一份 README,含 goal/workflow/backlog/timeline 四要素,作为下次执行的规约入口)
- Artifact(产物:loop 跑完后写入共享文件系统的结构化产出)
- Signal(信号:loop 观察到的用户反馈/想法/机会,跨 loop 累积的"记忆"单位)
- Compounding Loops(复利回路:多个 loop 通过共享文件系统互相喂信号,各自短板被其他 loop 补上的复利效应)
- Legible codebase(可读代码库:agent 容易定位修改点、渐进式探索信息的环境)
- Executable codebase(可执行代码库:agent 一条命令拉起 dev server 的环境)
- Work-tree friendly(并行工作树友好:多 agent 并行 worktree 不互相冲突、可同时起 dev server)
- Verifiable codebase(可验证代码库:给 agent playright(video 转写误听,实指对应工具) + e2e + PR skew 等自检工具)
- Custom linter(自定义 linter:把"禁用某些 import"等规则编进 linter,主动给 agent 注入约束,代替让 agent 自己找)
- Shared file system(共享文件系统:跨 loop 读写的 artifact / signal / log 三类文件,各 loop 互为记忆体)

## 金句

> It is the hardest thing everyone was talking about last week that you should no longer prompting the coding agent anymore. Instead designing loops that autoomsy prompts agents.
> → 一句话点出 loop engineer 与传统 prompt 工程师的核心分水岭:价值从"写好 prompt"转向"搭好让 prompt 被自动触发的环境"。

> Share the same brain and this is where this compounding effect really taking off.
> → 复利回路的真正机制不是 loop 本身变强,而是多个 loop 共享一个脑后,各自短板被其他 loop 补上。

> Don't get agent to selfverify its own work. It just generally doesn't work that well.
> → 直接对应 复合错误率:agent 自评存在系统性偏正(类似 Self-grading bias),独立 verifier 是底线。

## 立场与利益

作者与本片内容有直接利益关系:loop engineer 模板是他 AI Builder Club 课程的卖点,视频末尾引导 description 里的 GitHub repo 与 AI Builder Club workshop 链接,说"if you want to set up your first loop for your business, definitely come and join it"。

但可与推广剥离、站得住的部分:四大组件的拆分、PR skew 里 spawn read-only verifier 的反自评禁令、legible + executable + work-tree friendly + verifiable 四件套的属性解耦、shared file system 作为 loop 互记忆体的设计——都是不依赖买课即成立的工程主张。token 数字未给出具体测试,可信度不打折但也无独立基准。

整体主张倾向:作者是 loop engineer 这套体系的最大受益者之一,任何"loop 比手动更高效"的具体数字(每天 20-40 个 SEO 页等)都偏向促销;但"loop engineer 是一个新角色"这个范式判断,与 [[Harness]] 等既有笔记的方向一致,即便去销售化也站得住。

## 价值定位

- 适合谁:已经在用 Claude Code / Codex 类编码 agent 跑单次任务、并想把"每隔几小时就该跑一次"的那类流程(SEO 监控、support triage、PR triage、定价监控)真正自动化的人;以及专门为独立产品搭持续运营自动化的人。
- 解决什么:从"反复手动开 session 跑同一件事"升级到"loop 自动跑 + 信号互相喂 + 复利累加";具体给出"四大组件 + 共享文件系统 + 每 loop 契约"这套可直接套用的工程骨架。
- 认知 vs 实操:认知 + 实操各半。认知层给了"loop engineer 是什么"的角色定位、与 harness 的关系;实操层给了触发器、文件结构、可验证代码库、loop contract 的具体形态,以及 PR skew 必须有 verifier 的硬规则。
- 与 [[Harness]] 重叠:都在讲"非模型层",但 [[Harness]] 偏概念框架,本片独有"共享文件系统让多个 loop 复利"与"PR skew spawn read-only verifier"两条具体工程范式。

## 自检问题

1. Loop engineer 与 prompt engineer 的核心区别是什么?
   **答案**:loop engineer 不再写 prompt 触发 agent,而是设计让 agent 跨 session 被自动唤醒并持续推进的环境(触发器 + 文件系统 + 可验证代码库)。见详解1。[00:29](https://youtu.be/W6x-hb44C0c?t=29)
2. 作者把 loop 优化分成哪两层?loop engineer 只管哪一层?
   **答案**:内层是单次 agent session 怎么把任务做对(交给 Claude Code/Codex);外层是这个 agent 助手怎么决定"现在该做什么",loop engineer 只管外层。见详解2。[05:11](https://youtu.be/W6x-hb44C0c?t=311)
3. 四大组件中作者认为最容易被忽视的是哪个?为什么?
   **答案**:可验证代码库——很多人只搭 trigger 和文件结构,但不把代码库改成可独立验证,loop 跑起来只会制造低质 PR,验证关要在 PR 阶段就拦下。见详解3。[09:10](https://youtu.be/W6x-hb44C0c?t=550)
4. 可验证代码库的"四件套"具体是哪四件?分别解决什么问题?
   **答案**:legible(代码库要 agent 容易看懂) + executable(一条命令起 dev server) + work-tree friendly(并行 worktree 互不冲突) + verifiable(playright 即 Playwright CLI + e2e + PR skew 自检)。见详解4。[09:47](https://youtu.be/W6x-hb44C0c?t=587)
5. 为什么 PR skew 里要强制 spawn read-only verifier agent?不让 agent 自评?
   **答案**:agent 自评存在系统性偏正,加上 复合错误率 随步数灾难性放大,自评等价于没验证;read-only verifier 拿独立上下文独立目标做校验,符合 Verifier Agent 的双层设计。见详解7。[12:10](https://youtu.be/W6x-hb44C0c?t=730)