Loop Engineering 不是凭空出现的。过去三年，AI 工程实践完成了四次清晰的范式跃迁：2023~2024 年的 Prompt Engineering（优化单次对话质量），2025 年的 Context Engineering（解决知识边界与幻觉），2026 年初的 Harness Engineering（优化运行环境，核心哲学「人类掌舵，智能体执行」），再到 2026 年中的 Loop Engineering。每一次跃迁的驱动力都是模型能力的提升暴露了前一层级的人机协作瓶颈——当模型能连续写 100 万行代码时，「人每次都得在中间传话」就成了新的卡点。理解这条演化链，才能看懂为什么「设计循环」比「写提示词」更像一个真正意义上的工程化工作。

Loop Engineering 的 Connectors 层核心是 MCP（Model Context Protocol）。没有 MCP 的 agent 只能读写文件系统，告诉你「bug 对应哪个 issue，修复方案是什么」，但没法自己操作；配上 MCP 后，agent 能直连 Issue Tracker、查询数据库、调用 staging API、在 Slack 通知团队，整个修复链可以自己跑完。MCP 的架构只有三个角色：Server（封装系统接口）、Client（AI 工具内置的发现层）、Transport（支持本地 stdio 和远程 SSE），一次配置后所有工具即插即用。这正是国内工具如 Codex 和 Claude Code 都内置 MCP 支持的原因——决定 loop 规模的，不是模型有多聪明，而是它连了多少个真实系统。

Loop Engineering 主张用子代理（Verifier）自动审查代码，但业内对「完全交 AI 审查」的担忧正在上升。某金融科技公司接入 AI 编程后，月均代码产量从 2.5 万行飙到 25 万行，仓库积压了超 100 万行未审查代码。Reddit 上一笔账显示：贡献者用 AI 生成一个 PR 只需 7 分钟，维护者理解并审查平均要花 85 分钟——这就是 AI 时代的 Brandolini 定律。另一面，清华大学 2026 年循环工程报告也专门列出了「自我校验失效」「上下文失真」等五大风险。Loop 的 maker-checker 分离机制解决了模型自欺问题，但最终决策的「瓶颈」依旧是人：当循环从 1 个扩到 10 个，人工审查成本会线性膨胀还是触发新的危机？

目前能看到的两个关键变量。第一是 Token 成本：Peter Steinberger 明确表示「成本是最主要的顾虑」，每个子代理都是一次独立模型调用，/goal 命令又在后台额外运行一个 Verifier。当 loop 从单任务扩到团队 10 个循环，token 消耗是指数级增长的。第二是治理成熟度：清华大学报告提出的「最小权限」「工具网关」「强制停机」六项治理原则目前仍处于概念阶段，没有标准工具链。真正成熟的标志不是某个技术突破，而是整个 loop 系统的可观测性——能实时告诉你「哪个循环花掉了多少 token、产的代码通过率多少、哪个子代理卡住了」。这个观测层可能需要 6-12 个月才能出现。

文章提到可以用另一个 agent 充当审查角色，但《纽约时报》称之为「代码大爆炸」的现象暗示了一个更深层的问题：当循环 7x24 小时产代码，人类工程师逐渐失去对整个代码库的「理解连续性」——不再清楚每一行代码为什么在那儿。这事真正值得问的不是「AI 审得好不好」，而是「当循环系统的代码复杂度超过人类单点理解上限时，谁来承担最终责任」。这不是一个技术问题，而是一个治理和伦理问题：如果 loop 自动修复的线上 bug 三个月后暴露出更深层的逻辑缺陷，责任在写循环的设计师，还是运行循环的平台？