导语
过去一段时间，很多人使用 Coding Agent 的方式其实还停留在"远程结对"：把需求写清楚，补一段上下文，等它返回结果，再继续追问。这个办法有用，但杠杆不高。人始终站在循环中心，Agent 只是被动响应。
Loop Engineering 想解决的是另一件事：让人从每一轮对话里退出来，改去设计一套会自动启动、自动分派、自动验证、自动记账的运行系统。Agent 仍然负责读代码、写代码和调用工具，但驱动它们的已经不是人的即时输入，而是一条稳定运行的工程闭环。
图：从"写好一次 Prompt"转向"设计会持续运行的 Loop"
这听起来像换了一个名词，其实不是。Prompt 关心"这一轮怎么说清楚"，Loop 关心"这件事以后如何反复、可靠、可审计地发生"。前者偏技巧，后者更像软件工程。
从人肉循环到系统循环
传统 Prompt 模式里，循环由人手动推进。发现问题、整理上下文、选择下一步、判断是否完成，全都压在操作者身上。Agent 做得再快，人也要不断回到键盘前接下一棒。
Loop 模式把这条链路拆开，让系统接管大部分机械动作：
图：Loop Runtime 将触发、分派、执行、验证和写回连成闭环
这张图里的关键不是 Agent，而是 Agent 周围的控制面。没有控制面，Agent 只是一个聪明的命令行工具；有了控制面，它才有机会变成一段可运行的工程流程。
Prompt 模式和 Loop 模式的差异可以压缩成一张表：
| 维度 | Prompt 模式 | Loop 模式 |
|---|---|---|
| 驱动者 | 人手动发起每一轮 | 系统按事件或计划触发 |
| 上下文 | 临时粘贴、临时解释 | 从文件、Issue、日志和历史状态中读取 |
| 执行环境 | 当前工作区，容易互相踩文件 | Worktree 或独立沙箱 |
| 验证方式 | 人读一遍，再让模型自查 | 独立 Reviewer/Verifier 复核 |
| 记忆方式 | 依赖会话上下文 | 写入仓库、任务系统或数据库 |
| 人的角色 | 操作者、追问者、兜底者 | 流程设计者、权限裁剪者、最终审查者 |
Loop Runtime 的六块基础设施
一个能工作的 Loop 不只是"每隔几分钟跑一次 Agent"。真正的 Loop Runtime 至少要有六块东西：触发器、隔离层、知识层、工具连接层、角色分工层和外部状态。
图：Trigger、Controller、Isolation、Agent Pool、Memory、Connectors 和 Skills 共同构成控制面
图：Loop 不是单个工具，而是一组围绕控制面的工程基础设施
Trigger：让系统自己醒来
触发器是 Loop 的心跳。它决定系统什么时候开始工作，也决定它会盯住哪些信号。
常见触发源有几类：
- 每天固定时间扫描 CI、Issue、依赖版本和告警。
- PR 创建后自动做风险检查、补测试建议和文档核对。
- CI 失败后拉取日志，尝试定位失败范围。
- Commit 合入后检查高风险目录、权限变更和配置变更。
- 线上监控出现异常后聚合日志，生成初步归因。
触发器越随意，Loop 越像一个乱跑的脚本。触发器越明确，Loop 越接近真正的工程系统。这里最需要设计的是边界：哪些事件只能分析，哪些事件允许改代码，哪些事件必须等人确认。
Worktree Isolation：并行之前先隔离
多 Agent 并行的第一道坎不是智能，而是文件冲突。两个 Agent 同时改同一份代码，结果通常不会比两个工程师抢同一个工作区更好。
Git worktree 的价值很朴素：每个任务有自己的工作目录、自己的分支、自己的修改空间。它不保证方案正确，但能先把机械冲突隔开。
图：多个 Agent 可以并行工作，但每个任务都应有独立 worktree 和分支空间
但隔离不是免费的午餐。工具可以让十个 Agent 同时开工，不代表人能认真审十份改动。Loop 的吞吐上限最后往往不是模型，而是 Review 带宽。
Skills：把团队的隐性知识写成可执行上下文
Agent 每次启动时都像新人入职。如果项目的测试命令、目录红线、提交规范、历史事故约束没有写下来，它就会用猜的。
Skill 的作用不是把所有背景都塞进 Prompt，而是把稳定知识沉淀成运行时会读取的上下文。适合写进 Skill 的内容包括：
- 项目如何安装依赖、构建、运行测试和做本地验证。
- 哪些目录不能自动修改，哪些文件需要人工确认。
- 日志、错误上报和埋点里不能出现哪些敏感信息。
- 某些字段、接口或配置为什么不能随便删。
- 线上事故后形成的工程禁区。
- Review 时必须检查的性能、安全和兼容性约束。
没有 Skills，Loop 每一轮都在重新理解项目。有 Skills，Loop 才能把过去的坑变成下一轮的护栏。
Connectors：让 Loop 进入真实工程现场
只会读本地文件的 Agent，能做的事很有限。真实的软件工作发生在 Issue、CI、日志、监控、PR、IM 和数据库之间。Loop 要闭环，必须能连接这些系统。
MCP 或类似 Connector 的价值就在这里：它们把 Agent 从"看代码"扩展到"处理工作流"。
一条完整链路可能是这样：
图：Loop 通过 Connector 进入 Issue、日志、CI、PR 和协作通知系统
这也是 Loop 和普通自动化脚本的分水岭。脚本通常按固定路径执行；Loop 会读真实输入，选择下一步，并把结果写回协作系统。
Agent Roles：写的人不要自己给自己判卷
让同一个 Agent 完成实现、解释和验收，风险很高。模型一旦在某个方案上投入上下文，就容易替自己的选择辩护。人类团队不会让开发者独自合并自己的核心改动，Loop 里也不应该这么做。
更稳的分工是把角色拆开：
| 角色 | 主要职责 | 设计要点 |
|---|---|---|
| Explorer | 读代码、看日志、缩小问题范围 | 只读权限，速度优先 |
| Builder | 修改代码、补测试、整理 Patch | 写权限受控，必须记录假设 |
| Reviewer | 审查变更、找回归和规范问题 | 独立上下文，标准要严格 |
| Verifier | 跑测试、核对停止条件 | 不参与实现，只看证据 |
图：Loop 不是让一个 Agent 从头包到尾，而是让不同角色接力完成发现、执行、验证和写回
这个分工会多花 token，也会拉长一次任务的链路。它不适合所有小事，但适合那些"错了会很麻烦"的任务：权限、数据迁移、核心链路、兼容性和安全相关改动。
State / Memory：把进度写在模型之外
Loop 最容易被低估的一层是状态。单次会话会结束，上下文窗口会被压缩，模型会忘记自己昨天试过什么。仓库、Issue、数据库和 Markdown 文件不会。
State 至少要记录几件事：
- 当前待处理队列。
- 每个任务已经尝试过的方案。
- 失败原因、测试输出和 Review 结论。
- 哪些任务被人确认过，哪些还不能自动推进。
- 下一轮启动时应该从哪里继续。
一个没有外部状态的 Loop 很容易变成失忆的自动化：重复扫描、重复失败、重复解释。状态写清楚后，下一轮才有资格叫"继续"，否则只是"重来"。
一次完整迭代应该怎么跑
下面是一条比较现实的 Coding Loop。它不追求全自动合并，而是把可自动化的部分交给系统，把高风险判断留给人。
图：从 Scheduler 触发到 Explorer、Builder、Reviewer、Verifier 接力，再写回外部状态
这里有一个容易忽略的细节：停止条件也要设计。不能让 Builder 自己说"我完成了"就结束。完成必须有外部证据，比如测试通过、接口返回符合 schema、Reviewer 没有阻塞问题，或者人明确批准。
工程师的能力重心会变
Prompt 写得好仍然有用，但它不再是唯一的杠杆。Loop 做起来后，更值钱的能力会偏向系统设计：
| 过去更重要 | 以后更重要 |
|---|---|
| 单轮 Prompt 写得清楚 | 把任务拆成可重复运行的闭环 |
| 临时补上下文 | 维护 Skills 和外部状态 |
| 手动判断下一步 | 设计触发条件和停止条件 |
| 盯着 Agent 改代码 | 设计 Maker/Checker 分工 |
| 靠人记住项目约束 | 把约束写进工具和流程 |
| 让 Agent 多做一点 | 决定哪些事绝不能自动做 |
这更接近 SRE、工作流编排和软件架构，而不是传统意义上的 Prompt 技巧。写 Prompt 是在影响一次回答；设计 Loop 是在影响一类工作以后怎么发生。
真正危险的地方
Loop 最大的诱惑是"我可以走开了"。这句话一半对，一半很危险。
第一，验证责任不会因为 Loop 存在而消失。Reviewer Agent 说通过，只能说明它没有发现问题，不等于代码已经被证明正确。线上配置、权限、资金链路、数据迁移这类任务，必须保留人工闸门。
第二，理解力会被产能反噬。Loop 产出越快，人越容易只看结论，不再理解细节。短期看效率很高，长期看会形成理解债：系统里有越来越多"不是我写的、我也没认真读过"的代码。
第三，舒适感会降低判断力。一个运行顺滑的 Loop 很容易让人误以为它理解业务，实际上它只是很好地执行了你设计的流程。流程没有覆盖的风险，它一样看不见。
所以 Loop 的正确姿势不是放弃判断，而是把判断放到更高的位置：少做机械追问，多做边界设计、证据审查和风险取舍。
落地前先回答这八个问题
如果要在团队里真正落一个 Loop，不建议一上来就追求全自动修复。先把下面八个问题写清楚：
| 问题 | 需要明确的内容 |
|---|---|
| 什么时候启动 | 定时、CI 失败、PR 创建、Issue 打标、线上告警 |
| 读取哪些输入 | 代码、日志、测试报告、监控、Issue、最近提交 |
| 能执行哪些动作 | 只分析、可改代码、可开 PR、可发消息、是否允许改配置 |
| 用什么隔离 | Worktree、容器、临时分支、只读沙箱 |
| 如何验证完成 | 测试、Lint、Schema 校验、Reviewer 结论、人工确认 |
| 状态写在哪里 | Markdown、Issue、PR Comment、SQLite、任务队列 |
| 哪些必须人审 | 权限、数据、安全、核心链路、外部可见行为 |
| 失败后怎么处理 | 重试次数、降级策略、告警对象、回滚路径 |
这八个问题比"选哪个 Agent 工具"更重要。工具会变，Loop 的边界和责任不会自动变清楚。
结语
Loop Engineering 的重点不是让 Agent 看起来更勤奋，而是把 AI 协作从一次次聊天改造成可运行、可检查、可延续的工程系统。
我更愿意把它看成一次角色迁移：工程师不再只负责把话说给模型听，还要负责设计模型工作的轨道。轨道设计得好，Agent 可以在很多低风险、高重复的任务上持续给你省时间；轨道设计得烂，它也会很稳定地把错误放大。
所以不要只问"这个 Agent 能不能自动干活"。更应该问：它什么时候启动，拿什么证据判断，在哪个边界内行动，失败后写回哪里，最后谁负责拍板。
Loop 可以跑起来，但工程判断力不能下线。
