
导语过去一段时间很多人使用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 时必须检查的性能、安全和兼容性约束。没有 SkillsLoop 每一轮都在重新理解项目。有 SkillsLoop 才能把过去的坑变成下一轮的护栏。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 可以跑起来但工程判断力不能下线。