Loop Engineering完整拆解：从操作员到系统设计者的范式转变

从 Prompt Engineering 到 Context Engineering，再到如今的 Loop Engineering，AI 编程范式正在经历一次根本性的转变。这个新概念在 AI Vibe Coding 圈迅速传播开来。本文将系统拆解 Loop Engineering 的核心理念、五大构建模块以及实践应用。

从「操作员」到「系统设计者」的范式转变

OpenAI 联合创始人 Peter 发了一条推文："你不需要再给你的 Coding Agent 输入提示词了，你应该设计一个循环，让循环自己去提示你的 Coding Agent。" 随后，Claude Code 的创造者 Boris 在一档节目上表达了类似观点："我现在不自己提示 Claude，我在跑循环，是循环在提示 Claude，是循环在决定下一步做什么，而我的工作就是设计这个循环。"

这两句话揭示了 AI 编程范式的核心转变：

• 过去的模式：你写 Prompt → Agent 执行 → 你读结果 → 你做决策 → 再写 Prompt。你是那个不停在"戳" Agent 的人，每一步都需要你来驱动。
• 新的模式：一个系统在自动循环——调度、触发、Agent 执行、验证、交付、感知分析，再回到调度。而你是圆圈中间那个虚线圈出来的设计者。

简言之，你从 Human in the Loop（深度参与者）变成了 Human out of the Loop（系统设计者）。

什么是 Human in the Loop？ 这一概念源自控制论与自动化系统设计，指在自动化流程的关键决策节点保留人工干预能力。在早期 AI 系统中，Human in the Loop 是安全性的保障——机器负责执行，人类负责判断。Loop Engineering 的范式转变并非消除人的作用，而是将人的介入点从「每一步操作」上移至「系统设计层」，这与工业自动化从手工操作到流水线设计的演进逻辑高度一致。

Loop Engineering 的演进脉络

Loop Engineering 并非凭空出现，它有一条清晰的演进路径，每个阶段都对应着模型能力与工程实践的双重成熟：

• Prompt Engineering 时代：大家精心设计提示词，让 AI 给出更满意的回答。Prompt Engineering 自2020年 GPT-3 发布后逐渐成为一门显学，从零样本（Zero-shot）、少样本（Few-shot）到思维链（Chain-of-Thought）提示，工程师们发展出一套系统方法论。其中思维链技术由 Google 研究员 Jason Wei 等人于2022年正式提出，通过让模型逐步展示推理过程来提升复杂任务准确率，是 Prompt Engineering 最重要的突破之一。然而这一时代的本质局限在于：每次交互仍需人工介入，所有技术都是单次、同步、人工驱动的交互模式，模型的能力上限受制于单次对话窗口，无法支撑需要持续迭代的复杂工程任务。

• Context Engineering 阶段：开始关注如何给 Agent 提供完整的上下文，而不只是问题本身。这是对 Prompt Engineering 的升级——核心思想是将 Agent 运行所需的完整信息，包括项目文档、历史记录、工具说明、约束规则，系统性地注入上下文窗口。随着 Claude、GPT-4 等模型上下文窗口扩展至数十万 token，Context Engineering 成为构建可靠 Agent 系统的关键工程实践。值得注意的是，Context Engineering 的兴起与 RAG（检索增强生成）技术的成熟密切相关——当上下文窗口无法容纳所有信息时，如何动态检索并注入最相关的片段，本身就是一门独立的工程学问。

• Rail of Loop 模式出现：工程师 Jeffrey 发现了一个有趣的模式——把 Coding Agent 扔进一个无限的 Shell 循环里，每次循环读同一个文件、修改代码、重新开始。他给这个模式取名 "Rail of Loop"，取自《辛普森一家》里那个永不放弃的 Rail——不聪明，但非常有效。这个看似简单的发现，实际上触及了 Agent 系统设计的核心洞见：持续性比单次智能更重要。一个能够反复尝试的普通 Agent，往往比一个只执行一次的聪明 Agent 更能解决实际问题。

• 工具层面就绪：Claude Code 和 Codex 先后上线了 /go 命令，意思是"持续跑直到条件满足再停"，工具层面的 Vibe Coding 已经就绪。

• 概念系统化：Google 工程师 Eddie 发表了一篇定义性长文，将 Loop Engineering 系统化为五大构建模块，概念正式在圈内传开。

五大构建模块：Loop 的完整拼图

Automation（调度）——Loop 的心跳

没有调度，Loop 就只能跑一次而不是循环。在 Claude Code 中有两种触发模式：

• /loop：按固定节奏重复，比如每5分钟检查一次代码是否有 bug。
• /go：条件驱动模式，比如"所有测试通过 + Lint 干净"才停下来。

这两种模式对应了自动化系统设计中的两种经典范式：时间驱动（Time-driven） 与 事件驱动（Event-driven）。时间驱动调度简单可预测，适合定期巡检类任务；事件驱动调度更高效，资源只在条件满足时消耗，适合目标明确的收敛性任务。在实际的 Loop Engineering 设计中，两者往往结合使用——外层用时间驱动触发整个 Loop，内层用条件驱动控制单次执行的终止。

Worktrees（工作树）——并行的基础

当你需要跑多个 Agent 并行处理任务时，最大的问题是文件冲突。Git Worktree 是 Git 2.5（2015年）引入的原生功能，允许同一个仓库在文件系统上同时拥有多个独立的工作目录，共享 .git 对象数据库和提交历史，但各自维护独立的工作区和暂存区。其底层原理是：所有 Worktree 共享同一个 .git 目录下的对象数据库（objects）和引用（refs），但每个 Worktree 拥有独立的 HEAD 指针和暂存区（index）。相比传统的「克隆多个副本」方案，Worktree 节省了磁盘空间，且分支间的同步通过标准 Git 机制自动处理。在多 Agent 并行场景中，这意味着每个 Agent 可以在自己的分支上独立修改文件，完全避免文件锁冲突，合并时再通过标准 Git 流程处理差异。这是实现多 Agent 并行的关键基础设施。

为什么不直接克隆多个仓库副本？ 表面上看，克隆多份仓库同样能实现隔离。但这种方案存在三个致命问题：一是磁盘占用随 Agent 数量线性增长；二是各副本之间的同步需要额外的协调机制；三是无法利用 Git 原生的分支合并与冲突检测能力。Worktree 方案则将并行隔离与版本控制无缝集成，每个 Agent 的工作成果天然就是一个可审查、可回滚、可合并的 Git 分支，这与软件工程中「利用已有基础设施而非重新发明轮子」的最佳实践高度吻合。

Skills（技能库）——偿还意图债务

没有 Skills，每次 Agent 启动都是"失忆"状态：不知道项目约定、不知道配置规范、不知道为什么不能用某个库、不知道密钥存在哪里。Skills 就是把这些知识写下来，每次循环自动读取。

这其实是在偿还一种叫 Intent Debt（意图债务） 的东西。Intent Debt 是对技术债务（Technical Debt）概念的延伸——技术债务指为了短期速度而积累的代码质量问题；意图债务则指 Agent 系统中未被显式记录的设计决策、约定俗成和隐性知识。每当 Agent 需要「猜测」开发者意图时，就在消耗这笔债务的利息，表现为错误的技术选型、违反项目约定的实现方式，以及需要人工反复纠正的低效循环。

从知识管理的角度看，Skills 文件本质上是在将团队的隐性知识（Tacit Knowledge）显性化。管理学家野中郁次郎在其知识创造理论中指出，组织中大量关键知识以隐性形式存在于个人经验和团队默契中，无法直接传递。在人类团队中，这些知识通过师徒制、代码审查和口耳相传缓慢扩散；而 Agent 系统没有这种社会化学习机制，必须通过显性化的 Skills 文档来弥补。Skills 让 Agent 不再靠猜测来填补你意图的空白，而是能真正理解你想要什么。

Plugins & Connectors（插件和连接器）——打通外部世界

基于 MCP（Model Context Protocol）协议，让 Agent 能够读 Issue Tracker、查数据库、调 API、在 Slack 里发消息。MCP 是 Anthropic 于2024年11月以开源形式发布的标准化协议，基于 JSON-RPC 2.0 构建，其设计哲学借鉴了微软的 LSP（Language Server Protocol）——后者通过统一编辑器与语言工具的通信接口，终结了「每个编辑器为每种语言单独开发插件」的碎片化局面。MCP 试图解决类似问题：在 MCP 之前，每个 AI 应用需要为每个外部服务单独开发集成层，维护成本极高。MCP 定义了标准化的工具调用（Tools）、资源读取（Resources）和提示模板（Prompts）三类原语，类似于 USB-C 统一了硬件接口，为 Agent 提供了统一的「插槽」，使其能够以一致的方式调用各类外部能力。目前已有 GitHub、Slack、Linear 等数百个官方和社区 MCP Server 可用。

MCP 与 Function Calling 的区别是什么？ OpenAI 于2023年推出的 Function Calling 同样允许模型调用外部工具，但它是各家模型厂商私有的实现，工具定义与特定模型 API 深度绑定。MCP 的核心价值在于跨模型、跨平台的标准化——同一个 MCP Server 可以被 Claude、GPT、Gemini 等不同模型调用，工具开发者只需维护一套实现。这种「一次开发，处处可用」的特性，正是 MCP 在短时间内获得广泛采用的根本原因，也是 Loop Engineering 能够灵活组合不同 Agent 和工具的技术前提。

这是区别于普通对话式 Agent 的关键——Loop 可以直接开 PR、关联 Ticket、通过后自动发通知，全程不需要你介入，你只要写好验证规则就行。

Subagents（子代理分离）——最重要的结构设计

Eddie 原话说得很直白："写代码的模型自己给自己评分，实在是太手软了。" 同一个 Agent 既当裁判又当运动员，打分肯定不合理。

Maker-Tracker 分离在认知科学层面有深刻的理论依据。心理学家 Daniel Kahneman 在《思考，快与慢》中提出的「双过程理论」（Dual Process Theory）指出，生成创意与批判性评估需要不同的认知模式，由同一主体同时承担会产生「确认偏误」——倾向于为自己的输出辩护而非客观审查。在 LLM 领域，研究表明自我评估存在系统性高估：模型在评估自己生成的内容时，会因为生成过程中已经「投入」了计算资源而产生类似「沉没成本效应」的偏差。独立的 Verifier Agent 使用不同的上下文窗口和提示框架，能够以更接近「第三方审查」的方式评估输出质量。这也是软件工程中「关注点分离」原则在 Agent 系统中的自然延伸。

Eddie 建议采用 Maker-Tracker 分离 架构：

• Implementer Subagent（Maker）：负责写代码
• Verifier Subagent（Tracker）：负责验收，跑测试、检查 Lint，不通过就退回重做

数据很有说服力：Maker-Tracker 分离后，验证覆盖率可达 73%；而既当裁判又当运动员的模式，只有 7%-33%。

Verifier 必须是另一个 LLM 吗？ 不一定，这正是 Loop Engineering 的精妙之处。最强的 Verifier 往往不是 LLM，而是确定性工具——编译器、测试框架、Lint 工具、数学验证器。这类工具的判断完全客观，不存在「手软」问题。LLM 作为 Verifier 适用于需要语义理解的验证场景，如代码风格审查、需求符合度检查。在实际设计中，最佳实践是分层验证：先用确定性工具做基础验证（快速、客观），再用 LLM Verifier 做高层语义验证（灵活、深入），两层都通过才算真正完成。

Memory（记忆）——被低估的复利引擎

这是 Anthropic 工程师补充的第六个构建模块。模型会忘记，但记忆不会。记忆可以是一个 Markdown 文件，或任何跨会话持久化的东西。没有记忆，每次循环都从零开始，Agent 看起来就会很"蠢"。

Agent 记忆系统在技术实现上通常分为四个层次：In-context Memory（上下文内记忆）直接将历史信息写入当前对话窗口，受限于 token 上限；External Memory（外部记忆）将信息持久化到文件系统或向量数据库（如 Chroma、Pinecone），通过检索增强生成（RAG）在需要时调取相关片段；Episodic Memory（情节记忆）记录具体的执行历史和决策过程；Semantic Memory（语义记忆）则提炼抽象规则和约定，类似于 Skills 文件。在 Loop Engineering 实践中，最常见的轻量级实现是结构化 Markdown 文件——既人类可读，又易于 Agent 解析。

记忆系统的价值在于将每次循环的经验沉淀为可复用的知识：踩过的坑、发现的约定、验证过的解法，都可以写入持久化存储，让下一次循环从更高的起点出发。这正是「复利」的本质——不是线性积累，而是每次迭代都在前一次的基础上加速。

向量数据库在记忆系统中扮演什么角色？ 当记忆内容超过上下文窗口容量时，不能简单地截断历史——这会丢失关键信息。向量数据库通过将文本转化为高维向量并建立语义索引，使 Agent 能够根据当前任务的语义相关性动态检索最相关的记忆片段，而非按时间顺序机械地读取。这种「按需检索」的记忆机制，使 Agent 在理论上可以拥有无限容量的长期记忆，同时保持每次调用的上下文窗口精简高效。Chroma、Pinecone、Weaviate 等向量数据库正是为此场景设计的基础设施。

三个实战案例：从最小Loop到企业级应用

案例一：最小 Loop——一行命令搞定 Lint 修复

场景：一个 Python 项目，想清掉所有 Lint 错误但不想手动改。

只需输入：/go 修复这个文件下所有 Python 相关的 Lint 错误，直到 flake8 输出为空。Agent 自己跑 flake8、发现错误、修复、再跑，直到输出为空停止。不需要 Worktrees，不需要 Connectors，只需要客观的停止条件。这就是 Loop Engineering 最小的形态，今天就可以在 Claude Code 里用起来。

这个案例完美诠释了 Loop Engineering 的核心设计原则：停止条件的客观性决定了 Loop 的可靠性。flake8 输出为空 是一个完全确定性的条件，不依赖任何主观判断，Agent 无法「自欺欺人」地宣布完成。这也是为什么代码质量工具类任务是 Loop Engineering 最理想的起点——工具链本身就提供了天然的客观 Verifier。

案例二：Agentic Auto Research 自动化研究

之前非常火的 Auto Research 本质上也是 Loop Engineering：

• program.markdown → Skills（研究方向和约定）
• 无限循环每轮跑5分钟 → Automation
• Agent 修改 chain.py → Implementer Subagent
• 数学公式验证结果 → Verifier（这里不是 LLM，而是真实的数学标准）
• 保留/回滚代码、记录实验日志 → Memory

设计者写好 program.markdown 然后退出循环，系统自己跑完约100次实验，睡醒直接看结果。

这个案例揭示了 Loop Engineering 在科研场景的独特价值：将假设验证的迭代成本从「人工时间」转化为「计算时间」。传统科研中，一个研究员每天能手动尝试的实验变体极为有限；而 Loop Engineering 使得夜间无人值守的大规模实验搜索成为可能，本质上是在用算力换取研究速度。这与 AlphaFold、AlphaCode 等 AI 科研系统的底层逻辑一脉相承。

案例三：企业级 Bug 修复 Loop

Eddie 自己分享的企业级案例，分三个阶段：

1. 感知阶段：每天早上8点触发调度，读取昨天失败的 CI、Open Issues、Recent Commits，写到 Linear 看板。
2. 执行阶段：对每个 Finding 开一个隔离的 Worktree，Implementer Agent 写修复代码，Verifier Agent 跑测试验收，不通过自动退回。
3. 交付阶段：Connector 自动开 PR、关联 Ticket、发通知。搞不定的带上完整上下文进入你的 Inbox 等待决策。

设计一次，不手动参与任何步骤，每天早上起来 PR 已经开好了。

这与传统 CI/CD 流水线有何本质区别？ 传统 CI/CD（持续集成/持续交付）流水线擅长执行确定性的构建、测试和部署步骤，但无法处理「发现问题→理解问题→生成修复方案」这一需要语义理解的环节。Loop Engineering 的企业级 Bug 修复 Loop 实际上是在 CI/CD 流水线的「红灯」节点插入了一个具备代码理解和生成能力的 Agent 层，将原本需要工程师人工介入的「分析-修复」环节自动化。这是 AI 与 DevOps 工具链深度融合的典型形态，也预示着未来软件工程流程的演进方向。

Loop Engineering 的适用边界与落地条件

一个关键问题：Loop Engineering 在哪些领域更容易落地？

从左到右有一条谱带：代码测试、数学证明、物理仿真等在最左边（机器可客观验证，自主性高）；文案写作、策略规划在最右边（需要人工判断，主观性强）。

背后有三个原因：

1. 停止条件存在于模型之外：通过还是失败，编译器说了算，不是 Agent 说了算。
2. Verifier 能做真正的验证：跑测试、检查 Lint 错误，这些是可量化的标准。
3. 失败信号清晰可见：测试报错、编译失败等反馈信号让 Loop 能够修正而非重复。

这三个条件共同指向一个更深层的概念：可验证性（Verifiability）。在计算机科学中，可验证性是形式化方法（Formal Methods）的核心关注点——一个系统的正确性能否被机械地证明，而非依赖人工审查。Loop Engineering 的适用边界，本质上就是「可验证性谱系」的边界。越靠近谱系左端（高可验证性），Loop 的自主性越强、可靠性越高；越靠近右端（低可验证性），人类判断越不可替代，Loop 的价值更多体现在辅助加速而非完全自主。

在设计 Loop 之前，先问自己：这个任务的输出，Agent 能独立判断对错吗？ 能，就大胆建 Loop；不能，Loop 仍有价值，但你自己就是最关键的 Verifier。

三条核心实践总结

第一，停止条件是真正的产品。 如何评判 Loop 的好坏，取决于你定义的验证条件。在非量化领域能定义出好的量化标准，你就成功了一大半。

第二，Maker-Tracker 分离是质量保证。 不要让同一个 Agent 既写代码又验收代码，这是 Loop 质量的核心保障。

第三，记忆系统是复利引擎。 让 Agent 能做经验总结和沉淀，从踩过的坑中学习，下次从更高的起点出发。

最后需要警惕的是 认知投降：当 Loop 自动运行时，你的大脑容易停止思考，直接接受 Loop 的结果。两个人用同样的 Loop 可能得到完全相反的结果——一个用它加速自己深度理解的工作，另一个用它来逃避理解。Loop 不知道区别，但你知道。

Loop Engineering 并没有让工作变得更容易，而是变成了一个更强大的杠杆。