Loop Engineering 深度解析：从写Prompt到设计自主工作流的范式跃迁

2026年6月，AI编程领域发生了一次静悄悄的范式转移。

Anthropic Claude Code负责人Boris Cherny在一次分享中语出惊人："我已经不再手动给Claude写提示词了。我搭建了自动运行的循环体系，由它向Claude下发指令、判断执行方向。我的工作就是搭建这套循环。"

与此同时，OpenAI的Peter Steinberger（龙虾之父）也在社交媒体上表达了相似观点："你不该再给编程Agent写提示词了。你应该设计一套循环机制，让这些循环去提示你的Agent。"

两位顶尖从业者的共识，把一个新概念推到了台前：Loop Engineering（循环工程）。Google工程师Addy Osmani在6月7日的博文中正式为其命名，由此这个词开始在开发者社区迅速流行。

本文将深入解析Loop Engineering的核心架构、五大模块，并通过实战案例展示如何用Claude Code搭建一个真正可用的自主工作流。

---

一、什么是Loop Engineering？

1.1 定义：从"人驱动"到"目标驱动"

一句话定义：Loop Engineering是把"那个不停prompt agent的人"换成"一个不停prompt agent的系统"，而你负责设计这个系统。

这里的loop是一个递归目标（recursive goal）：你定义一次目的，agent自行迭代直到任务真正完成。不再是你在每次响应后敲下一条指令，而是一个小系统去发现工作、分派工作、校验结果、记录已完成项、决定下一步——然后由这个系统去戳agent，而不是你。

这与传统的定时任务（Cron）有本质区别：

• Cron只负责在固定时间点触发一个动作，不知道任务做到了什么程度，不判断结果质量，也不决定是否需要再来一轮
• Loop有明确的终止条件，系统持续运行，直到条件被满足或触发人工介入阈值

1.2 四层技术栈：逐层叠加，而非替代

把Loop Engineering放进整个AI编程技术栈里看最清楚：

层级	优化对象	工作单元
Prompt Engineering	单条指令怎么措辞	你手敲的一个turn
Context Engineering	窗口里还放什么：文档、历史、工具定义	一次回答的周边条件
Harness Engineering	AI在什么环境里工作：工具调用、沙箱、权限控制	单次Agent运行的环境
Loop Engineering	决定prompt什么、何时prompt、结果是否可接受的那个系统	跨多个turn的自运行周期

关键认知：四层是叠加关系，而非替代关系。 Prompt Engineering不会消失——loop由prompt构成，loop里一个糟糕的prompt只会更快地产出糟糕的工作。Context Engineering也不会消失——loop每一个turn仍要把对的文件、历史、工具定义摆到模型面前。

Loop Engineering增加的是包裹在这一切之上的自主控制结构。

---

二、五大核心模块详解

一个能用的loop需要五样东西，再加一处存放状态的地方（外部记忆）。这一架构已得到主流Agent平台（Claude Code、OpenAI Codex、Cursor 2.0）的原生支持。

2.1 Automations（触发机制）：自动发现与分诊

Automations是整个循环的起点，负责按计划触发任务，自行做发现与分诊（triage）。

核心能力：

• 定时调度：按设定频率自动运行（如每天早上6点检查CI失败）
• 事件触发：基于Webhook、PR创建、Issue更新等事件触发
• 智能分诊：自动分类问题优先级，区分"可自动修复"和"需要人工干预"
• /goal 原语：驱动执行直到满足可验证的停止条件

实际应用场景：

• 每日CI失败分诊与自动修复
• 新Issue自动分类与打标签
• 代码库定期健康检查（依赖更新、安全漏洞扫描）
• 文档自动同步与更新

据Woofun AI分析，这些自动化可以处理80%的例行但关键的运维工作，让工程师专注于真正需要判断的问题。

2.2 Worktrees（并发隔离）：多Agent并行不冲突

Worktrees解决的是多Agent并行操作时的文件冲突问题。通过Git Worktree技术，每个Agent在独立的工作目录中操作，共享同一份代码库历史，但互不干扰。

工作原理：

主仓库 (main branch)
├── worktree-1 (bugfix/ci-failure-123)  ← Agent A 操作
├── worktree-2 (feature/new-login)       ← Agent B 操作
└── worktree-3 (refactor/auth-module)    ← Agent C 操作

核心价值：

• 真正的并行开发：多个Agent可以同时处理不同任务，无需排队
• 隔离性：一个Agent的错误不会影响其他Agent的工作
• 高效分支管理：无需重复clone仓库，节省磁盘空间和时间
• 干净合并：每个worktree产出独立的PR，人工审查后合并

在Claude Code中，你可以通过 --worktree 参数创建隔离工作环境；在Codex中，每个Thread内置了worktree隔离。

2.3 Skills（外部知识）：让Agent不再"金鱼记忆"

Skills解决的是Agent的上下文遗忘问题——模型在两次运行之间会忘掉一切，所以状态必须落在磁盘上，而不是上下文窗口里。

典型的Skills结构（SKILL.md）：

# Code Review Skill

## 目的
确保所有提交的代码符合项目规范且没有明显缺陷。

## 检查清单
- [ ] 代码风格符合ESLint配置
- [ ] 有适当的单元测试覆盖
- [ ] 没有硬编码的密钥或敏感信息
- [ ] 错误处理完整
- [ ] API变更有对应的文档更新

## 评分标准
- 0-2分：严重问题，必须修复
- 3-4分：中等问题，建议修复
- 5分：通过

Skills的价值：

• 项目知识固化：把团队积累的规范、最佳实践、历史决策结构化存储
• 一致性保障：无论哪个Agent执行任务，都遵循同一套标准
• 减少重复解释：不用每次启动新会话都从头讲解项目背景
• 可迭代优化：Skills本身也可以由Agent持续改进

2.4 Plugins/Connectors（真实世界连接）：基于MCP协议的工具生态

Connectors是让Loop从"理论练习"变成"实际生产力"的关键。基于**MCP（Model Context Protocol）**协议，Agent可以连接你已经在用的各种工具。

MCP协议架构：

┌─────────────────────────────────────────┐
│           Host (Claude/Cursor)          │
│  ┌──────────┐  ┌──────────┐             │
│  │ Client A │  │ Client B │  ...        │
│  └────┬─────┘  └────┬─────┘             │
└───────┼──────────────┼──────────────────┘
        │              │
       MCP            MCP
        │              │
┌───────▼─────┐  ┌────▼──────────┐
│  GitHub MCP │  │  Slack MCP    │
│   Server    │  │    Server     │
└─────────────┘  └───────────────┘

常见的连接器类型：

• 代码协作：GitHub、GitLab（创建PR、查看Issue、触发CI）
• 项目管理：Jira、Linear、Notion（更新工单、同步状态）
• 通讯工具：Slack、Teams、飞书（发送通知、同步进度）
• 数据库：PostgreSQL、MySQL（查询数据、执行迁移）
• 监控告警：Prometheus、Grafana（查询指标、分析异常）

MCP的出现把"M x N"的集成问题变成了"M + N"的问题——工具提供方只需实现一个MCP Server，客户端只需实现一个MCP Client，双方就能互相连接。

2.5 Sub-agents（执行与审查分离）：Maker-Checker模式

Sub-agents引入了职责分离的设计原则：一个负责实现（Maker），另一个负责验证（Checker）。

为什么需要分离？让编写代码的模型来评判自己的代码，就像让学生给自己的考试打分一样不可靠。单一Agent容易陷入"自我说服"，忽略自己的错误。

经典的三层Agent协作架构：

          ┌───────────────────┐
          │   Orchestrator    │  任务分配与进度管理
          └─────────┬─────────┘
                    │
          ┌─────────▼─────────┐
          │   Maker Agent     │  编写代码、实现功能
          └─────────┬─────────┘
                    │
          ┌─────────▼─────────┐
          │  Checker Agent    │  代码审查、测试验证
          └───────────────────┘

子Agent配置示例（Claude Code风格）：

# .claude/agents/ci-fixer.toml
name = "ci-fixer"
description = "修复CI失败问题的专业Agent"
model = "claude-3-5-sonnet-20260514"
tools = ["edit", "run-command", "git"]
skills = ["code-fixer", "testing"]

# .claude/agents/code-reviewer.toml
name = "code-reviewer"
description = "独立的代码审查Agent，不参与编码"
model = "claude-opus-4.8"
tools = ["read", "github"]
skills = ["code-review", "security-audit"]

Woofun AI的分析指出，这种"执行者与校验者分离"的设计是Loop中最有价值的结构性设计，因为它提供了让系统无人值守运行所需的信任基础。

2.6 Memory（外部记忆）：Loop的脊柱

第六块构件是外部记忆。它可以是一个Markdown文件、一块Linear看板、一份GitHub Issue列表——任何活在单次会话之外、记录"做了什么、下一步是什么"的载体。

状态文件示例（STATE.md）：

# CI Fix Loop State

## 运行历史
### 2026-06-10
- 发现3个CI失败
- 自动修复2个简单问题（依赖版本不兼容、语法错误）
- 1个复杂问题标记为需要人工干预（测试逻辑重构）
- 打开PR: #125, #126

## 待处理
- [ ] 修复#127：复杂的测试失败，需要人工审查
- [ ] 跟进PR #125的代码审查意见

状态文件是整件事的脊柱：它记得试过什么、过了什么、还开着什么，所以明早的运行从今天停下的地方接着跑。

---

三、实战案例：搭建一个CI自动修复Loop

让我们用Claude Code从零搭建一个完整的CI自动修复循环，看看五大模块是如何协同工作的。

3.1 目标定义

目标： 每天早上自动检查前一天的CI失败，对可自动修复的问题创建修复PR，对复杂问题生成分析报告。

停止条件： 所有可自动修复的CI失败都已创建PR或标记为需要人工干预。

3.2 完整实现

第一步：创建Skill（代码修复技能）

在 .claude/skills/code-fixer.md 中定义修复规范：

# Code Fixer Skill

## 目的
快速修复CI中发现的常见问题。

## 常见问题类型及修复策略
1. 依赖版本不兼容 → 升级/降级对应依赖
2. 语法错误 → 修复语法问题
3. 测试失败 → 修复测试或被测试代码
4. Lint错误 → 自动格式化或修复

## 工作流程
1. 仔细阅读错误日志
2. 定位问题代码
3. 实施最小必要修复
4. 本地运行测试验证
5. 提交修复并创建PR

第二步：定义子Agent

创建 .claude/agents/ci-fixer.toml：

name = "ci-fixer"
description = "专注修复CI失败的Agent"
model = "claude-3-5-sonnet-20260514"
tools = ["edit", "run-command", "git", "github"]
skills = ["code-fixer"]

创建 .claude/agents/code-reviewer.toml：

name = "code-reviewer"
description = "独立代码审查Agent"
model = "claude-opus-4.8"
tools = ["read", "github"]
skills = ["code-review"]

第三步：配置MCP连接器

在 .mcp.json 中配置GitHub连接器：

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

第四步：创建Loop启动脚本

创建GitHub Actions工作流 .github/workflows/ci-fix-loop.yml：

name: CI Fix Loop

on:
  schedule:
    - cron: '0 6 * * *'  # 每天早上6点运行
  workflow_dispatch:     # 允许手动触发

jobs:
  fix-ci:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      
      - name: Set up Node.js
        uses: actions/setup-node@v4
        
      - name: Install Claude Code
        run: npm install -g @anthropic-ai/claude-code
        
      - name: Run CI Fix Loop
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          claude-code --worktree ci-fix-$(date +%Y%m%d) "
          Use the ci-triage skill to analyze all failed CI runs from yesterday.
          
          For each auto-fixable issue:
          1. Create a new branch
          2. Spawn the ci-fixer subagent to fix the issue
          3. Spawn the code-reviewer subagent to review the fix
          4. If approved, open a PR with a clear description
          5. Update STATE.md with the results
          
          Write all findings and actions to STATE.md.
          "
          
      - name: Commit state update
        run: |
          git add STATE.md
          git commit -m "Update CI fix loop state for $(date +%Y-%m-%d)" || true
          git push

第五步：初始化状态文件

创建 STATE.md：

# CI Fix Loop State

## 运行历史
- 暂无运行记录

## 待处理
- [ ] 等待第一次运行

3.3 运行效果

这个Loop每天早上6点自动运行，整个过程无需人工干预：

1. Automation触发：GitHub Actions定时启动
2. Worktree隔离：每个运行在独立worktree中，不影响主分支
3. Skills指导：Agent按照预设的修复规范操作
4. Connectors连接：通过GitHub MCP Server获取CI状态、创建PR
5. Sub-agents协作：ci-fixer写修复，code-reviewer做审查
6. Memory记录：所有操作记录在STATE.md中，下次运行接着来

---

四、挑战与注意事项

4.1 成本问题

Loop Engineering虽然强大，但Token消耗也是巨大的。Peter Steinberger曾透露其月度Token成本高达130万美元。

成本管控策略：

• 设置严格的迭代限制（max-iterations）
• 从小规模开始，观察行为后逐步扩大
• 计算ROI：500元的循环节省20小时工作？值得。完成30分钟能做的任务？不值得
• 简单任务用低成本模型（如Sonnet而非Opus）
• 设置每日API使用警报，避免意外账单

4.2 三大陷阱

1. 理解债（Comprehension Debt） Loop越快地发布你没写的代码，仓库里实际存在的东西和你真正理解的东西之间的鸿沟就越大。一个顺滑的loop只会让这道鸿沟长得更快——除非你去读loop产出的东西。

2. 认知投降（Cognitive Surrender） 当loop自己跑起来，停止持有观点、照单全收它给的东西，很有诱惑力。带着判断去设计loop，它是解药；为了逃避思考去设计loop，它是助燃剂。

3. 验证盲区 无人值守地跑的loop，也是无人值守地犯错的loop。把verifier子agent从maker拆出来，正是为了让loop的"完成了"有分量。但即便如此，"完成"是一个声明，不是一个证明。

---

五、总结与展望

Loop Engineering代表了AI编程范式的一次重要跃迁：

• 从"人驱动"到"目标驱动"
• 从"单次对话"到"持续迭代"
• 从"手动操作"到"系统设计"

它不是Harness的替代品，而是叠在它之上的一层。杠杆点移动了，但工作没有变简单。一个设计良好的loop会放大一个好工程师；一个设计糟糕的loop会同样快地放大一个坏决定，而且你盯着的时间更少。

对于普通开发者来说，现在是开始学习Loop Engineering的好时机。你可以从一个简单的自动化开始——比如每天早上把CI失败分诊进markdown文件——在信任它去开PR之前先看清它的行为。

Loop Engineering仍在早期，手动直接prompt agent依然有效。目标是平衡：把反复的、可验证的工作交给loop，把你的判断才是价值所在的部分留给直接控制。

搭好你的loop。但要像一个打算继续当工程师的人那样搭它。 —— Boris Cherny, Claude Code 创建者

---

参考来源：

• Loop Engineering:你不再 prompt agent，而是设计 prompt agent 的系统 - CSDN博客
• Loop Engineering replaces prompt writing with 5-module autonomous agent workflows - Woofun AI
• Loop Engineering 深度解析与实战指南 - 51CTO
• 大人，AI编程又变天了!Claude Code之父、龙虾创始人同时力捧新范式 - InfoQ
• The rise of loop engineering and the shift toward autonomous software factories - hplus.club