Loop Engineering：当 AI 不再需要你亲手发号施令

1. 从“对话”到“循环”：一场静默的范式转移

想象一下，你是一位餐厅经理。过去两年，你使用 AI 的方式就像亲自站在厨房里，对着一位极其聪明但缺乏主动性的厨师下达每一条指令：“切洋葱”、“把锅烧热”、“倒酱油”、“尝尝咸淡”。你必须每分每秒盯着他，告诉他下一步做什么。这就是 Prompt Engineering（提示工程）——你在充当 AI 的“即时调度员”。

而现在，硅谷最前沿的工程师们正在实践一种新模式——Loop Engineering（循环工程）。

你不再站在厨房里了。你退后一步，开始设计一套“餐厅运营系统”：几点开门、库存少了谁来补、菜品不合口味了谁来调整、甚至谁来监督厨师长的工作。你设计好这套循环（Loop），然后走出厨房，让系统自己去运转。

正如 Anthropic 旗下 Claude Code 的负责人 Boris Cherny 所说：“我不再直接给 Claude 写提示了。我有循环在运行，是它们在提示 Claude，并自行判断下一步该做什么。我的工作就是写这些循环。”

这不仅仅是一个新概念，它是 AI 从“聊天工具”进化为“工作单元”的必然产物。本文将带你深入拆解什么是循环工程，它的底层逻辑、核心构件，以及为什么这会是 2026 年 AI 开发者的必修课。

2. 解构 Loop：一个无限的 While 循环

对于具有技术背景的读者来说，抛开那些眼花缭乱的术语，Loop Engineering 在本质上并不复杂。它不是什么神秘的魔法，甚至不需要引入新的编程语言。

它核心的底层逻辑，其实就是计算机科学中最基础的结构——While 循环。

2.1 本质代码：Agent 的心脏

任何复杂的多智能体协作系统，如果剥开其外壳，其内部核心都可以简化为以下这个伪代码逻辑：

# 这是一个最小化的 Agent Loop 核心逻辑
context = initial_prompt + user_goal

while True:
    # 1. 调用大模型，传入当前上下文
    response = llm.call(context)
    
    # 2. 判断停止条件（最容易被忽视的一环）
    if response.stop_reason == "end_turn":
        break  # 任务完成，优雅退出
    
    # 3. 如果需要使用工具
    if response.stop_reason == "tool_use":
        result = execute_tool(response.tool_call)
        context.append(result)  # 把执行结果加回上下文
        
    # 如果没有 break，循环继续，模型根据新结果再次推理

这就是 Agentic Loop 的全部。模型并不是一次性地生成答案，而是在一个循环中不断地：思考（Reason）→ 行动（Act）→ 观察（Observe），直到任务完成为止。这个模式被称为 ReAct 模式，早在 2022 年就已提出，但在 2026 年，它被产品化和工程化了。

2.2 停止条件：真正的技术分水岭

写一个让它“跑起来”的循环很容易，难的是写一个让它“知道该停”的循环。

在没有人为干预的情况下，如何防止 AI 陷入死循环（例如反复尝试同一种错误的修复方案）或烧光你的 API 额度？

现代循环工程引入了可验证的目标（Verifiable Goal），而不仅仅是“提示词”。例如，现在的 Claude Code 或 OpenAI Codex 允许你使用 /goal 命令：

/goal "执行 npm run test，确保所有测试通过，且测试覆盖率不低于 80%"

系统会启动循环，AI 自己写代码、运行测试、看哪个测试挂了、改代码、再跑测试。它不需要你告诉它“去读那个报错”。真正的技术难点在于外部验证机制——比如一个独立的 Linter 或测试套件——只有这个外部机制返回“成功”，循环才会终止。否则，哪怕模型自己说“我觉得我做完了”，循环也不会停下。

3. Loop 的五块积木：构建你的自动化飞轮

如果说上面的 While 循环是“发动机”，那么要让这辆车上路、不撞车、自己能加油，你还需要一套完整的“车身组件”。Google 工程师 Addy Osmani 将其归纳为五个核心积木，加上一个“记忆”模块。

3.1 自动化触发（Automations）—— 心跳

Loop 不能依赖你手动敲击回车。它需要一个“心跳”，即定时任务或事件触发。比如：“每天凌晨，自动抓取 GitHub Issues 中标记为‘Bug’的条目，尝试修复”。

3.2 工作区隔离（Worktrees）—— 物理防撞

当你同时跑 5 个 Agent 去改同一个代码库时，必然会引发 Git 冲突。Worktrees 技术让每个 Agent 拥有独立的物理工作目录，它们并行工作，互不干扰。这是大规模并行自动化的基础设施。

3.3 技能沉淀（Skills）—— 长期记忆

这是解决“AI 金鱼大脑”的关键。每次新对话，AI 都会忘记你的代码规范。Skills 是一个 Markdown 文件（如 SKILL.md），里面写满了项目知识：“我们使用 2 空格缩进”、“API 调用必须经过这个中间件”。每次循环启动时，AI 自动读取这个文件，确保行为一致性。

3.4 连接器（Connectors / MCP）—— 手脚延伸

Loop 不能只活在终端里。通过 MCP（模型上下文协议）标准，Agent 可以连接 Slack、数据库、Jira 甚至你的浏览器。它能自己查日志、发 PR、在团队频道里汇报进度。

3.5 子代理（Sub-agents）—— 制衡机制

不要让写代码的人自己去检查代码。 这是 Loop Engineering 中一个非常深刻的人性洞察。模型在给自己的作业打分时“过于仁慈”。因此，你需要建立多代理架构：一个 Agent 负责写代码（充满创造力），另一个独立的 Agent（甚至使用不同的提示词或模型）负责审查代码（极其严苛）。只有审查通过，Loop 才继续。

4. 人类的角色：不仅仅是按下“启动”键

当 AI 开始自己管理 AI 时，作为人类的工程师，我们的位置在哪里？难道就只是坐在旁边喝咖啡，看着代码自动生成吗？

如果你这样想，可能会陷入一种危险的境地，Googe 工程师称之为 “认知投降” 。循环工程并没有降低对工程师的要求，相反，它把技能点转移到了三个全新的维度。

4.1 设计“理解债”的防线

当 AI 在一小时内生成了几千行代码，而你只是瞟一眼就合并了，你正在欠下巨大的 “理解债” 。短期内项目进展神速，但三个月后，没有人理解这个系统是如何运作的，它变成了一个无法维护的“黑盒”。人类的职责是架构审核——不是看每一行代码对不对，而是看这个模块该不该存在，这个抽象层级合不合理。

4.2 定义“价值”的奖励函数

在强化学习中，智能体依靠“奖励函数”来学习。在循环工程中，你就是那个定义“奖励”的人。对于没有技术背景的产品经理或业务方来说，这意味着你不再告诉 AI “怎么做”，而是极其清晰地定义“什么是好的结果”。

你需要像一名产品经理一样思考，为 Loop 设定护栏：

• 预算护栏：这个任务最多允许花费 2 美元 Token。
• 安全护栏：AI 绝对不能执行 rm -rf / 这类命令。
• 质量护栏：什么是“UI 美观”？这很难量化，但你必须想办法把它拆解成 AI 可执行的规则。

4.3 异常处理与回路介入

Loop 在处理标准流程（修 Bug、更新依赖）时表现极佳，但一旦遇到涉及商业权衡（“这个功能是做在 iOS 上还是安卓上？”）或创造性突破（“这个架构太旧了，我们重写吧”）时，它就会卡壳。

最优秀的循环设计，不是全自动的，而是“人在回路”（Human-in-the-Loop）的。

你需要设计“中断点”：当系统遇到不确定性且置信度低于阈值时，它不应该胡乱猜测，而是应该自动停止，在 Slack 上 @ 你，并把上下文整理好等你决策。

Loop Engineering 并不是为了让工程师失业，而是为了把我们从“重复性的指挥”中解放出来，去做更重要的决策和架构设计。正如那位 Google 工程师最后所告诫的：“建立你的 Loop，但请以一个打算继续当工程师的人来建立它，而不是只想按下‘开始执行’按钮的人。”