清华大学清新研究团队最近发布了一份技术报告《循环工程研究报告》。

这份报告把AI编程从"人跟AI聊天式协作"升级成"人设计一套自动化流水线（循环），让流水线自己去调度AI干活"。 流水线要有刹车、有账本、有质检、有急停按钮，不能让它瞎跑。

核心金句： Build the loop, stay the engineer.——把循环搭起来，但人得始终坐在工程师那把椅子上，别当甩手掌柜。

一、报告内容的梳理

第一块：范式转移

文档说清楚了为什么这事儿现在能搞——模型会调工具了、MCP这类标准化接口让AI能连真实业务系统了、Worktree和Skills这些基础设施也成熟了。三个条件同时到位，才让"循环"从一个想法变成能落地的东西。

它还把"循环"的边界划死了：不是无限while，不是cron，是Agent工作流系统。这句话很关键，防止有人把定时脚本硬说成"循环工程"。

第二块：产品底座

这部分详细拆了Claude Code和Codex各自提供了什么能力：

Claude Code这边：

• /loop
  会话里周期性地反复跑任务（心跳）
• /goal
  不跑满时间，跑到达成条件就停（条件驱动）
• Routines
  脱离本地，云端跑（变成团队资产）
• Skills
  SKILL.md记录项目规矩，按需加载（不用每轮重新猜项目）
• Worktrees
  每个Agent有自己的独立工作区（并行不打架）
• MCP
  接外部系统（数据库、监控、Slack）

Codex这边：

• Agent Loop
  底层就是模型-工具-结果反复交替（这是它所有功能的基础）
• Automations
  定时/事件唤醒Agent干活
• Triage
  干活结果先进收件箱，让人决策，不直接执行

这一章的底色其实是：你看，大厂都在搞这套，证明这不是瞎编的概念，是真实趋势。

第三块：核心架构

文档自己抽象了一套通用公式——Loop Stack六件套

1. 心跳：谁来叫醒它？
2. 隔离：多任务并行怎么不踩脚？
3. 知识：Agent上哪找项目规矩？
4. 触手：怎么连真实业务系统？
5. 审查：谁来把关？写和查必须分开
6. 记忆：跑了一半断了，下次怎么接着干？

光有这六件套还不够，还加了三条底线： 预算底线（不能烧钱烧到爆）、权限底线（不能瞎碰核心系统）、停止底线（必须有铁证证明干完了）。

这部分的思路很好——把"神奇的自动化"拆成可审计、可追责的组件，不像有些人一谈AI就玩玄学。

第四块：设计模式

这部分是报告的精华。它发明了9个概念，把循环工程从"玄学"变成"工程学"：

• Loop Kernel（循环内核）：
   把循环拆成8个模块——调度器、加载器、执行器、评估器、门控、记账器、停止检查器、人类交接，每个模块都有明确的失败模式。
• Proof-of-Done（完成证据）：
   不接受"我觉得好了"，只接受测试报告、监控截图、API返回码这些硬证据。
• Repo Memory（仓库记忆）：
   状态不留在对话上下文里，写进仓库或数据库，跨会话能恢复。
• No-Gate Evaluator（否决门控）：
   必须有个独立角色能说"不"，写代码的和检查代码的不是同一个Agent。
• Triage Buffer（收件箱缓冲）：
   自动化发现的东西别直接执行，先进队列让人过一眼。
• Loop Ledger（循环账本）：
   每一轮花了多少钱、调了什么工具、改了哪些文件，一笔笔记清楚。
• Worktree Fleet（工作树舰队）：
   并行不是多开窗口，是管理一群有序的、可追踪的工作树。
• Entropy Janitor（熵值清洁工）：
   循环不能只生产代码，还得主动删代码、降复杂度。
• Engineer Seat（工程师席位）：
   人必须保留理解代码、踩刹车、担责任的权力。

这些概念里最有价值的是Proof-of-Done、No-Gate Evaluator和Loop Ledger——这三样是把"循环"从玩具变成生产工具的硬门槛。

第五块：11条典型场景

文档列了11种具体用法，覆盖了从CI修复到Agent自我改进的全链路：

1. CI失败修复——最稳妥的练手项目
2. PR评论处理——把Review反馈变成队列
3. 依赖升级——比Dependabot多了语义修复
4. 文档漂移——让文档跟着代码变
5. 上线验证——发布后自动观察，异常升级给人
6. 缺陷回收——从故障里生成测试用例和规则
7. 技术债清理——专门删废代码、降复杂度
8. 设计一致性——避免"AI味"UI乱飘
9. 安全修复——高危漏洞强制人类审批
10. Backlog Triage——让AI先整理需求，别急着写代码
11. Agent Improvement Loop——循环也要被循环优化

这11条覆盖得挺全面，从"修Bug"到"管需求"到"优化自身"，形成了一个闭环。尤其是第11条（用Loop优化Loop），听着有点赛博朋克但逻辑上站得住。

第六块：风险与治理

这部分是给"循环热"泼冷水的。

五大风险：

1. 自我确认
   ——AI觉得"我好了"，其实半成品
2. 上下文腐烂
   ——对话太长，前面的要求被忘了
3. 权限扩散
   ——连的系统越多，被黑的风险越大
4. 成本黑洞
   ——轮数多了账单能吓死人
5. 理解债
   ——全是AI写的代码，你从来不读，最后不敢动

六条治理原则：

1. 最小权限——默认只给最少的权限
2. 工具网关——每个连接都要回答"要什么权限、谁能用、能审计吗"
3. SSDF化——AI生成的代码也得走安全开发流程
4. AI RMF化——把Loop纳入NIST的AI风险管理框架
5. 人类交接——出事了知道找谁
6. 可关闭——急停按钮必须存在

这部分是文档最有良心的地方——它没把循环工程包装成"按一个键就啥都搞定了"的神器，而是老老实实承认：这东西搞不好比人手干还危险。

第七块：运营与成熟度

这是"怎么落地"的部分。

• Loop Registry（循环登记簿）：
   所有Loop像服务一样登记，有名称、目标、停止条件、允许工具、禁止动作、交接人、最大轮次、紧急制动阀门。
• 成熟度模型：
   L1手动协作 → L2单条会话Loop → L3事件驱动Loop → 关键跨越 → L4可登记可记账Loop Fleet → L5自优化循环系统。
• 启动Checklist：
   10个问题——目标可验证？证据外部化？权限最小化？记忆持久化？成本可控？失败能停？环境隔离？影响可逆？监控实时？退出条件明确？
• 四个反模式：
   不要无限循环、不要让生成者自评分、不要直接给生产写权限、不要用运行时长当成功指标。
• 最佳试点：
   从CI修复这种低风险、高反馈的活儿开始，逐步扩展。

这套"从试点到舰队"的路径设计得很务实，不是一上来就让所有Loop全开。

第八块：结语

回到最核心的那句话：Build the loop, stay the engineer. 三个角色的分工：工程师定目标+边界+验收+担责任；Agent执行+调工具+写代码；Loop调度+管状态+控成本+记审计。

二、我的一些看法

1. "证明"比"执行"难一万倍

文档反复强调Proof-of-Done，这确实是最清醒的认知。但说句大实话：在软件工程里，验证"真的修好了"这件事本身，比"修"难得多。 尤其在UI、体验、业务逻辑正确性这些领域，目前没有任何小模型能当合格的No-Gate Evaluator。所以大部分Loop最终只能在编译通过、Lint通过、单测通过这种确定性极强的地带发光发热。涉及业务模糊判断的，老老实实升给人。

2. 这是工程化包装，不是新科学

坦率地说，报告把/loop、Skills、MCP包装成"六件套"，本质上是用一套漂亮的概念语言重写了DevOps + 自动化运维的思路。以前我们用Jenkins、GitHub Actions写编排脚本，现在只是把执行节点换成了大模型Agent。这东西工程价值巨大，但理论创新一般。 它最牛的地方不是发明了什么新东西，而是给混沌的AI编程世界建了一套可审计、可度量、可追责的治理框架。

3. "Engineer Seat"不是口号，是活命的本事

文档最后反复强调"保持工程师席位"，这句话分量很重。AI写的代码越来越多，你没读过的代码也越来越多。如果哪天你看着Loop提交的PR，想都不想就点"合并"，那你离被替代就不远了。工程师的价值不在于"会写代码"，而在于"理解系统、判断取舍、承担责任"。 循环越顺，人越容易变成"点头机器"，这才是最危险的地方。

三、小结

这份报告是一份相当完整的循环工程体系说明。它最大的价值在于：把AI编程从"聊天的艺术"变成了"可审计的工程"。 概念框架完整、治理思路清醒、落地路径务实。

我的核心建议是：

• 如果你们是大厂基建团队
  照着这份报告的框架去搭Loop Fleet，思路完全正确。但请把80%的精力花在"三条底线"和"Proof-of-Done"上，而不是研究怎么调Prompt。
• 如果你是普通开发者
  别被"六件套"、"九大概念"吓到。从最简单的开始——写个脚本让AI读CI日志，失败了自动重试三次。Run the loop, but keep your finger on the kill switch.

最后一句大实话： 循环工程不会让AI变聪明，它只是把AI的随机性关进了一个工程化的笼子里。这个笼子有预算锁、权限锁、证据锁和人工紧急制动闸。笼子造得再好，人也得守在笼子旁边，不能走远。