那天下午，团队里刚来的实习生小张跑来问我：“这个功能明明测试环境跑得好好的，为什么一到生产环境就卡住了？”我让他把日志打开一看，问题出在一个看似简单的循环逻辑上——测试数据量小，循环几次就结束了；生产环境数据量大，循环逻辑没设边界，直接内存溢出。这种“一次测试通过，批量运行崩溃”的场景，在工程实践中太常见了。而今天要聊的 Loop Engineering（循环工程），正是为了解决这类问题而生——它不是简单地写个 for 循环，而是设计一套能自主运行、自我检查、持续优化的系统。当 Peter Steinberger 说“你不应该再亲自提示编码智能体，而应该设计提示智能体的循环”，当 Anthropic 的 Claude Code 负责人 Boris Cherny 说“我不再提示 Claude，我有循环在运行”时，他们指向的都是同一个方向：从手动操作单次任务，转向设计能自动运转的工作流。但这里有个关键区别——Loop Engineering 真正的价值不在于“自动化”，而在于把一次性的临时操作，沉淀成可复用、可监控、可迭代的工程化流程。1. 先搞清楚 Loop Engineering 真正解决的是哪类问题很多人第一次接触 Loop Engineering 时，会把它理解为“高级自动化脚本”。这个理解只对了一半。自动化脚本解决的是“重复劳动”问题，而 Loop Engineering 解决的是“如何让智能体在无人值守的情况下，持续完成复杂任务并保持质量”的问题。1.1 从临时提示到系统化循环的演进回想一下你使用编码助手的典型场景：你写一个提示词，智能体返回代码；你检查结果，发现有问题，再写下一个提示词修正。这个过程就像手动驾驶——每个转弯、每个加速都需要你亲自操作。Loop Engineering 相当于给这辆车装上了自动驾驶系统。你不再需要时刻握着方向盘，而是设定目的地和规则，让系统自己判断何时转弯、何时加速。但为什么现在这个转变变得如此重要？因为智能体的能力已经从不稳定的“玩具”阶段，进入了可预测的“工具”阶段。当单次交互的可靠性足够高时，把它们串联成循环系统就成为了可能。1.2 循环系统的五个核心组件一个完整的循环系统需要五个关键组件，加上一个记忆系统：自动化调度：系统能够按计划自主启动，而不是依赖手动触发工作树隔离：多个任务并行运行时互不干扰技能封装：把项目特定的知识固化下来，避免每次重新解释插件连接：让循环能够接入你现有的工具链子智能体分工：不同的智能体负责创作、验证等不同环节记忆系统则是整个循环的“脊柱”，记录哪些任务已完成，哪些待处理，确保每次循环都能从上次停止的地方继续。1.3 适用场景与不适用场景Loop Engineering 特别适合以下场景：每日例行任务（CI 失败分析、issue 分类整理）大规模代码库的批量修改（API 迁移、依赖升级）多环境验证（不同配置下的测试用例生成）但不适合：探索性、创新性的编码任务需要深度业务理解的关键决策对质量要求极高的核心逻辑修改理解这个边界很重要——不是所有任
