Loop Engineering 实战笔记：让 Agent 自己发现、执行和复盘

Loop Engineering 的核心，不是把 prompt 写得更漂亮，而是把一次次人工驱动的 Agent 调用，设计成能持续运转的工程循环。

Loop Engineering 讨论的是一个很具体的问题：

当 Agent 已经能读仓库、跑命令、开 PR、查 CI、调用工具之后，怎样让这些能力在一个可控的循环里持续发生。

过去我们更多是在做单次调用：给 Agent 一个任务，等它执行，拿到结果，再由人决定下一步。

Loop Engineering 要把“下一步”也纳入系统设计。

谁来发现任务，谁来交给 Agent，谁来判断结果，状态写到哪里，下一轮怎么启动，失败时在哪里停下来。

这些问题设计清楚后，Agent 才可能从“一次回答”，变成一套可以反复运行、留下证据、接受审计的工作流。

这篇文章只讨论一件事：

Loop Engineering 到底是什么，它怎么转起来，工程师应该怎么开始。

01 它先解决什么问题

先不急着接受一个新名词。

只看今天使用 Agent 的真实断点，会发现问题通常不在“模型不会写”，而在这三处。

第一，启动靠人。

CI 挂了、issue 新增了、PR 卡住了，Agent 本身不会自动知道“现在该处理这件事”。只要人没把任务喂进去，链条就停在原地。

第二，接力靠记忆。

这轮分析过什么、哪些问题被跳过、哪个任务需要明天继续，如果只留在对话窗口里，下一轮就会失忆。

第三，放行靠自觉。

Agent 很容易说“已完成”，但完成到底依据什么测试、日志、截图或审查结果，如果没有独立检查，就只是一次自我确认。

Loop Engineering 解决的不是“怎么让一句 prompt 更聪明”，而是把这三个断点系统化：

自动发现任务，跨轮保存状态，用独立评判器决定能不能进入下一步。

你设计的对象，从 Agent 的一次回答，变成了驱动 Agent 的整个循环。

02 四层栈：Prompt、Context、Harness、Loop

要理解 Loop Engineering，先把它放回整张栈里看。

每往上一层，工程师操心的对象都变大一圈。

Prompt 关心一句话。

Context 关心一个窗口。

Harness 关心一次运行。

Loop 关心一套自动化生命周期。

这里最容易混的是 Harness 和 Loop。

Harness 解决的是“Agent 跑一次时怎么跑”。

比如它能不能读文件、能不能改代码、能不能跑命令、能不能访问外部系统、什么时候需要审批、什么结果算完成。

Loop 解决的是“这次跑完以后，下一次怎么自动发生”。

比如每天早上自动启动，读昨天失败的 CI、open issue 和最近 commit，挑出值得处理的任务，给每个任务开隔离 worktree，让一个 Agent 起草修复，让另一个 Agent 审查，通过后开 PR，没把握的进人工收件箱，然后把状态写到文件里，第二天接着跑。

这就是“上一层楼”的含义。

Harness 武装一次运行。

Loop 调度一串运行。

03 一句话定义：把你从 Prompt 位置上换下来

Loop Engineering 的定义可以很短：

循环工程，就是把“负责给 Agent 写 prompt 的那个人”，替换成一套系统。

以前你是那个发号施令的人：

你提出任务
Agent 执行
你看结果
你补上下文
Agent 再执行
你继续判断

这个模式有效，但它把人绑在循环里。

Loop Engineering 要做的是：

系统发现任务
系统组装上下文
系统交给 Agent
系统验证结果
系统保存状态
系统安排下一轮

你不再负责每一拍。

你负责设计节拍器。

你写的不再只是给 Agent 的话，而是会自动给 Agent 发话的机制。

这个机制可以很小，比如每天帮你扫一次 CI 失败；也可以很大，比如企业内部自动响应 Slack 指令、准备上下文、生成代码、跑门禁、开 PR、等待人类 review 的流水线。

规模不同，底层问题一样：

谁发现任务，谁交付任务，谁判断结果，状态存在哪里，下一轮怎么启动。

Loop Engineering 讨论的就是这些问题。

04 Loop 不是一段 while：一圈有五个动作

一听“循环”，很容易想到一段反复执行的代码。

但 Loop Engineering 里的 loop 不是空转的 while。

它每转一圈，都要完成一组具体动作：

发现、交付、验证、持久化、调度。

少任何一个动作，loop 都会变形。

没有发现，它只是一个等待人工输入的 Agent。

没有交付，任务边界会混在一起。

没有验证，它会自信地产出一堆没人敢收的东西。

没有持久化，它每次醒来都像第一次见这个世界。

没有调度，它只是你手动跑过的一次流程。

一个真正的 loop，要能回答这五个问题：

## Discovery
这一轮从哪里发现任务？

## Handoff
任务怎么拆、怎么隔离、交给谁？

## Verification
谁检查结果，依据什么证据说通过或不通过？

## Persistence
状态写在哪里，下一轮怎么接着上一次？

## Scheduling
下一轮什么时候、由什么触发？

这五个问题，比“prompt 怎么写得更聪明”重要得多。

因为当你不在现场时，真正决定结果的，是循环本身的结构。

05 一个具体 Loop：早晨 Triage 怎么转

只讲概念容易飘。

我们看一个具体 loop。

假设你每天早上都要做一次工程分诊：

昨天 CI 有没有失败；

有没有新开的线上 bug；

最近 commit 有没有引入可疑变化；

哪些 PR 卡住了；

哪些测试又开始 flaky。

过去这件事靠人做。

你打开 CI，看失败记录；打开 issue，看新问题；翻 commit；判断优先级；把上下文复制给 AI；让它分析；再手动决定下一步。

如果做成 loop，它可以这样运转：

每天 9 点自动启动
  -> 读取 CI 失败、open issue、最近 commit、未处理 PR
  -> 按规则分诊：线上风险、发布阻塞、重复失败优先
  -> 每个可处理任务单独开 worktree
  -> Agent A 起草修复或分析报告
  -> Agent B 独立审查结果
  -> 通过则开 PR 或更新 ticket
  -> 不确定则进入人工收件箱
  -> 状态写入 loop-state.md
  -> 下一轮继续从状态文件接着跑

这个流程的价值不在“自动跑”，而在每个环节都有边界：发现源明确，任务隔离，审查者独立，状态能跨天保存，不确定的问题会进人工收件箱。

如果你把它写成下面这样，就很危险：

每天自动检查仓库，发现能优化的地方就优化。
能修的 bug 直接修。
能合并的 PR 直接合并。
目标是让项目质量变好。

“检查仓库”没有发现源。

“能优化”没有范围。

“直接修”没有验证。

“直接合并”没有复核。

“质量变好”没有指标。

这类配置不是 loop 设计，而是把模糊愿望交给自动化。

06 六个零件：搭一个 Loop 需要什么

把 loop 拆成工程材料，大概需要六个零件。

这六个零件和前面的五个动作能对应起来。

发现通常依赖 Skills 和 Connectors。

交付通常依赖 Worktrees。

验证通常依赖 Sub-agents。

持久化依赖 Memory 和 Connectors。

调度依赖 Automations。

也就是说，一个 loop 不是“一个很长的 prompt”。

它是一组工程零件拼起来的系统。

如果你把一大段 prompt 贴进定时任务里，短期能跑，长期很难维护。

因为没有人愿意维护一堵提示词墙。

更好的做法，是把稳定知识沉淀成 skill。

比如：

## Skill: backend-ci-triage

## Purpose
分诊 Go 后端仓库过去 24 小时内的 CI 失败。

## Inputs
- CI job 列表
- 失败测试名称
- 最近 24 小时 commit
- 相关 PR 和 owner

## Rules
- 发布阻塞优先
- 重复失败优先
- 只失败一次且无法复现的问题标为观察
- 业务预期不明确的问题进入人工收件箱

## Output
生成一份分诊报告，并更新 loop-state.md。

Automation 触发这个 skill，而不是触发一段永远没人更新的长 prompt。

这样发现逻辑变了，改 skill 就行。

这才是可维护的 loop。

07 Worktree：并行之前先隔离

Loop 一旦开始自动派活，很快会遇到并行问题：一个 Agent 修测试，一个 Agent 改文档，一个 Agent 分析接口，一个 Agent 补迁移脚本。

如果它们都在同一个工作目录里写文件，最后很容易变成一锅粥。

两个 Agent 同时改同一个文件，本质上和两个工程师同时改同几行代码一样麻烦。

所以 handoff 不是简单地说“去做这个”。

它至少要回答三个问题：

第一，这个任务的边界是什么。

它只处理一个 CI 失败，还是可以顺手修相关 lint？

第二，它能改哪些文件。

只读哪些目录，允许改哪些模块，哪些文件需要审批？

第三，它在哪里改。

是否使用独立 worktree，是否和其他任务隔离？

一个更稳的交付单元应该像这样：

## Handoff: auth-flaky-test

## Goal
复现并修复 auth_test 中偶发失败的用例。

## Worktree
worktrees/loop-auth-flaky-test

## Allowed Files
- internal/auth/**
- tests/auth/**
- go.mod / go.sum 只读，新增依赖必须审批

## Out of Scope
- 不重构登录流程
- 不修改接口协议
- 不调整数据库 schema
- 不处理非 auth 模块的 lint

## Verification
go test ./internal/auth/... -count=50
go test -race ./internal/auth/...

## Stop Conditions
无法复现、需要改接口协议、需要新增依赖、发现问题来自外部服务时，停止并进入人工收件箱。

这才是可交付的任务单元：边界清楚、目录隔离、验证明确、遇到高风险情况会停。

Loop Engineering 里，任务切得越干净，后面的验证和合并越省事。

08 生成器与评判器：写代码的 AI 不能给自己打分

一个 loop 最难的地方，不是让 Agent 跑起来。

真正难的是往循环里放一个能说“不”的东西。

如果 Agent A 写了代码，又让 Agent A 自己评价这段代码，它很容易给自己一个不错的分数。

不是它故意糊弄。

而是它的上下文里已经塞满了“我为什么这么写”的理由。

它看自己的代码，看见的是意图。

评判者应该看见的是结果。

所以，一个靠谱的 loop 要把 generator 和 evaluator 分开。

Generator Agent
  -> 提方案、写代码、补测试、生成初稿

Evaluator Agent
  -> 读 diff、跑验证、查证据、挑问题、决定是否通过

这两个 Agent 最好有不同指令。

必要时甚至用不同模型，让评判者不容易复制生成者的盲点。

Generator 的默认姿态是“把事做成”。

Evaluator 的默认姿态应该是“这东西可能是坏的，除非证据证明它能跑”。

评判器也不能只会读代码。前端任务要能打开页面、点击按钮、检查 DOM、看截图；后端任务要能跑测试、构造请求、检查日志、确认状态；文档任务要能检查章节是否漏项、示例是否自洽、引用是否能追溯。

一个 evaluator 的检查清单可以这样写：

## Evaluator Checklist

- 目标问题是否被复现？
- 修改是否真的解决了目标问题？
- 是否运行了要求的测试和验证命令？
- 证据是否足以支撑“完成”这个结论？
- 是否出现超出 scope 的改动？
- 是否新增依赖、配置、权限或迁移？
- 是否把未验证路径说成已经验证？
- 如果交给人类 review，证据是否完整？

没有 evaluator 的 loop，是 Agent 在反复给自己点头；有 evaluator，循环才开始具备自我纠错能力。

09 Memory：Agent 会忘，仓库不会

很多所谓 loop，其实只是 recurring prompt。

比如每 10 分钟跑一次：

检查一下部署状态，有问题就提醒我。

这当然有用。

但它还不是真正的 loop。

因为它不知道上一轮发生了什么。

真正的 loop 需要 memory。

这个 memory 不能只活在模型上下文里。

上下文会清空，对话会结束，Agent 会忘。

状态要落到磁盘、仓库、工单或看板里。

比如一个 loop-state.md：

## Loop State: morning-triage

## Last Run
2026-06-23 09:00

## Findings
- CI auth_test 连续失败，已创建 worktree: loop-auth-flaky-test
- Issue #1842 需要业务确认，已进入 human-inbox
- PR #927 超过 48 小时未 review，已提醒 owner

## In Progress
- auth-flaky-test: generator 已提交初稿，等待 evaluator 验证

## Blocked
- Issue #1842: 缺少预期行为说明，不自动修复

## Next Run Notes
- 优先检查 auth-flaky-test 是否仍然失败
- 如果 Issue #1842 仍无回应，保留在人工收件箱

这份文件就是 loop 的复盘记录，不是形式主义。

它至少有三层价值。

第一，让 loop 能接力。

今天没处理完的事情，明天不需要重新发现。

第二，让人能审计。

你可以回头看它为什么处理这个、跳过那个、把哪个问题交给了人。

第三，避免错误在上下文里漂移。

关键事实写到文件里，下一轮按文件读取，而不是靠模型模糊记忆。

没有 memory，每一轮都是失忆后的重新开始。

有了 memory，loop 才真正跨过了单次对话。

10 Connector：让 Loop 看见真实世界

一个只能看文件系统的 loop，能力很小。

它可以读代码、改代码、跑测试。

但真实工程问题往往不只在代码里，还散落在 CI、issue、Jira、数据库状态、日志监控、聊天记录和 PR review comment 里。

所以 loop 需要 connector。

Connector 让它能连接外部系统：

Connector 决定了 loop 的视野半径。

只看文件系统，它就是一个本地代码助手；接上 CI，它知道什么坏了；接上 issue，它知道什么需要处理；接上 PR 和消息系统，它才能把结果带回协作流程，并在该停的时候找人。

但 connector 也意味着风险。

它能读更多，就可能泄漏更多。

它能写更多，就可能误操作更多。

所以 connector 必须配权限边界。

能只读就先只读，能写 comment 就不要直接合并，能开 PR 就不要直接推主干，能进人工收件箱就不要自动拍板。

Loop 的能力来自连接，安全来自边界。

11 让它在你睡觉时跑：调度不是一个按钮

“让 Agent 在你睡觉时干活”是 Loop Engineering 最容易让人兴奋的地方。

但这里要分清几种调度。

本地调度可以看见本地文件、开发服务器和临时状态，但机器关了就停。云端调度能长期运行，但通常拿到的是干净环境，未必能看见你本机的状态。

所以，“睡觉时跑”不是一句口号。

它要回答：

这个 loop 是否依赖本地环境？

它是否需要访问公司内网？

它是否能从 fresh clone 开始？

它的凭证放在哪里？

它出问题时谁会收到通知？

它跑飞时谁能停掉？

很多 loop 一开始不需要云端。先在本地验证发现逻辑、状态文件和 evaluator，稳定后再搬到长期运行环境。

12 真实案例：个人早晨和企业流水线

Loop Engineering 已经有一些清楚的实践形态。

一种是个人级的早晨 triage loop。

每天自动读取 CI、issue 和 commit，挑出值得处理的问题。能自动处理的，开 worktree 派 Agent；没把握的，进人工收件箱；处理状态写回文件，第二天继续。

它的价值不是替你做所有判断，而是先把重复巡检过一遍，把值得你看的东西整理出来。

另一种是企业级流水线。

比如 Stripe 的 Minions（据 Stripe 工程师 Steve Kaliski 在播客 How I AI 的公开分享），任务可以从 Slack 消息或 emoji 反应触发。系统先用确定性 orchestrator 收集上下文，扫描会话里的链接、拉取 Jira 工单、查文档、用 Sourcegraph 搜代码，再让 Agent 在隔离环境里写代码。写完以后，硬编码 pipeline 跑 lint、commit、开 PR，最后仍然交给工程师 review。靠这套分工，Stripe 每周能合并 1,300+ 个几乎全部由 Agent 生成的 PR。

这个案例最值得学的不是 PR 数量，而是分工方式：

能用确定性逻辑解决的，不交给概率模型；能用硬门禁拦住的，不只靠 Agent 自觉；能让机器重复做的，不让人天天手动做；必须由人判断的，不假装 loop 已经替你负责。

企业级 loop 的可靠性，不只靠模型能力，更靠约束、隔离、门禁、审计和复核。

13 代价：Loop 也会替你欠债

Loop 最迷人的地方，是它让一个人能干一组人的活。最危险的地方，也在这里：一个没人看着的 loop，也是一个没人看着犯错的 loop。

它会替你省时间，也会替你欠债。

最常见有四笔账。

验证债最容易发生。

loop 每天开 PR、改文件、补测试，看起来效率很高。但如果没有真正审查，这些产出只是“看起来完成”的堆积物。

理解腐烂更隐蔽。

代码是 loop 写的，测试是 loop 跑的，PR 描述也是 loop 生成的。你如果只看绿勾，不读实现，几个月后会发现自己像在看别人的项目。

认知投降最舒服，也最危险。

因为持续有判断很累。loop 越可靠，人越容易把判断也外包出去。

token 失控最直接。

一个会自动重试、自动孵化子 Agent、自动按时间运行的系统，如果没有预算上限，跑飞一次就可能烧掉一晚上。

所以，loop 上线前至少问四个问题：产出由谁验，改过的代码谁读，哪些点必须停下来等人，一次最多能花多少钱、跑多少轮。

问不清这四个问题，不要把 loop 放到无人值守环境里。

14 当工程师，不只是按下启动键

Loop Engineering 很容易让人产生一个幻觉：既然 loop 会自己跑，那工程师是不是只剩下按启动键？

恰恰相反。当生成变得越来越便宜，判断会变得更贵。

代码、方案、PR、测试、文档，都可以被批量生成。

但哪个方案是对的，哪段代码该拦下来，哪个结果虽然能跑但根上错了，这些判断不会自动变便宜。

Loop 会放大你。如果你本来理解系统，它会放大你的理解；如果你本来只是想绕过理解，它也会放大这种逃避。

同样一个 loop，两个人用，结果可能完全相反。

一个人用它加速自己已经吃透的事情，定期读产出，保留复核点，知道什么时候说不。

另一个人用它逃避理解，只看结果，闭眼合并，最后变成一套自己也看不懂的自动化的看门人。

Loop 本身不替你做这个选择。

它只会忠实执行你写进去的逻辑，也会忠实放大你漏掉的边界。

所以，造 loop 的时候要像一个打算留下来的人：把重复劳动交出去，把判断能力留下来。

造循环，但要像一个还打算继续当工程师的人去造。

15 最小落地清单

如果要今天就开始，不建议一上来做一个自动修 bug、自动开 PR、自动合并的大系统。

第一个 loop 应该小到几乎不像系统。

比如：

每天早上检查 CI 失败，并生成分诊报告。

先不要自动改代码。

先把发现、记忆、评判和人工复核做出来。

可以按这个清单开始。

第一，选一个重复出现、低风险、验证明确的任务。

CI 分诊、flaky test 跟踪、依赖扫描、PR 证据包整理，都比“自动修所有 bug”更适合做第一个 loop。

第二，写清发现源。

它定时读什么？CI、issue、commit、PR、日志、看板，还是收件箱？发现源不清，loop 就会乱找活。

第三，写一个 skill，而不是一堵 prompt 墙。

把稳定规则固化下来。逻辑变了改 skill，不要每次在排程里贴一大段没人维护的指令。

第四，把状态落到对话之外。

至少有一个 loop-state.md，记录每轮发现、处理状态、阻塞原因和下一轮要继续看的东西。

第五，把 generator 和 evaluator 分开。

写报告或写代码的是一个 Agent，判断是否通过的是另一个 Agent。不要让同一个 Agent 自己写、自己夸、自己放行。

第六，保留人工收件箱。

业务预期不清、无法复现、需要新增依赖、要改接口协议、涉及生产数据，都必须进人工确认。

第七，设置预算和停止条件。

单次最多多少 token，每天最多跑几轮，连续失败几次必须停，全部提前写清楚。

一份最小 loop 配置可以这样写：

## Loop Config

## Name
ci-triage-report

## Trigger
每个工作日 09:00 自动运行。

## Discovery
读取过去 24 小时失败的 CI job、失败测试名、相关 commit 和未处理 PR。

## Skill
backend-ci-triage

## Output
更新 loop-state.md，并生成当日分诊报告。

## Evaluator
独立 Agent 检查是否遗漏失败 job、是否有证据链接、是否把不确定判断写成确定结论。

## Human Gates
无法复现、业务预期不清、新增依赖、跨模块改动，全部进入人工收件箱。

## Budget
单轮最多 3 次重试，每天最多运行 1 次，连续 2 天失败则停止并通知 owner。

这已经是一个 loop 的雏形：有发现源、有 skill、有 memory、有 evaluator、有人工复核点、有预算。

等它稳定跑一两周，再考虑让它自动开 worktree、起草修复、跑验证、开 PR。

不要一开始就追求全自动。先让 loop 可观察，再让它可执行，最后再扩大规模。

总结

一套值得上线的 loop，至少要过五道关。

它有稳定的发现源，而不是让 Agent 到处乱搜。

它有清楚的交付边界，而不是把“顺手优化”写进自动化。

它有独立 evaluator，而不是让生成者自己宣布完成。

它有 memory，把发现、阻塞、处理状态写到对话之外。

它有预算、停止条件和人工收件箱，知道什么时候该停下来找人。

做到这些，loop 才不是“定时跑一段 prompt”，而是一套能持续工作的工程系统。

Loop Engineering 最后考验的也不是谁的自动化更激进，而是谁能把自动化关进合适的边界里。

让 Agent 多跑几轮不难，难的是每一轮都可观察、可验证、可停止、可接力。