Loop Engineering 深度解析：2026 年 AI 工程范式从 Prompt 到 Loop 的四阶跃迁——Boris Cherny 和 Peter Steinberger 联手定义的 Agent 循环工程实战指南

2026 年 6 月，Claude Code 创始人 Boris Cherny 和 OpenClaw 创始人 Peter Steinberger 在同一周说出几乎相同的话："别再手动提示 AI 了，应该设计让 AI 自己运行的 Loop。" AI 工程范式从 Prompt Engineering → Context Engineering → Harness Engineering → Loop Engineering 的四阶跃迁，标志着程序员角色的根本性转变——从"流水线上的操作工"变成"流水线的设计者"。本文从概念溯源、架构原理、六块核心积木、47 次实验验证数据、到完整生产级实战，全方位拆解这场正在发生的 AI 工程革命。

一、开场：一个面试故事引出的范式革命

某大厂面试官问："你在项目里怎么用 Claude Code 写代码的？"

候选人说："写好 Prompt，等它回复，然后根据结果再调整 Prompt，来回几轮搞定。"

面试官笑了笑："那你有没有试过，连 Prompt 都不自己写，让 AI 帮你写？"

候选人愣住了。

面试官接着说："Claude Code 的作者 Boris Cherny 已经不写 Prompt 了，他只写 Loop。让 Loop 去指挥 AI，AI 自己搞清楚该干什么。"

这个场景发生在 2026 年 6 月。彼时，AI 编程圈被一个概念引爆——Loop Engineering（循环工程）。

OpenClaw 创始人 Peter Steinberger 在 X 上发了一条推："别再搞 coding agent 了，去设计能提示 agent 的 loop。"

几乎同时，Anthropic 旗下 Claude Code 负责人 Boris Cherny 在开发者大会上说了句更狠的话："我已经不给 Claude 写提示词了。我有循环在跑，它们自己决定该干什么。我的工作是写 Loop。"

Google Cloud AI 总监 Addy Osmani 随后发表了一篇系统化的长文，把 Loop Engineering 的概念框架、核心构件、实战模式和踩坑经验完整地拆解了一遍。

这不是又一个造出来的buzzword。这是 AI 工程领域过去三年演进的自然终局。

二、AI 工程的四次范式跃迁

2.1 四阶段全景图

回顾过去三年，AI 应用工程化经历了四个关键阶段的范式升级：

关键洞察：这四个阶段不是互相替代的竞争关系，而是嵌套关系。 每个 Loop 系统内部都在做 Harness 工程；每个 Harness 内部都在做上下文工程；每个上下文架构内部都在做提示词工程。提示词工程没有死，它被重新归类了——从主要杠杆变成了嵌套组件。

2.2 Prompt Engineering 时代（2022-2024）

跟 AI 一锤子买卖。你问一句，它答一句。质量全靠你那句 Prompt 写得好不好——说白了就是"玄学调参"。

这个阶段的核心痛点是：措辞的微小变化就能导致产出质量天差地别。"请你扮演一个资深后端工程师"和"你是一个有 10 年经验的后端架构师"产出的代码质量可能完全不同。

# Prompt Engineering 时代的日常
prompt_v1 = "帮我写一个 FastAPI 接口"
prompt_v2 = """你是一个资深 Python 后端工程师，请用 FastAPI 写一个 RESTful 接口，
要求：使用 Pydantic v2 做数据校验，异步处理，包含错误处理和日志记录，
遵循 PEP 8 规范。"""
# v1 产出的代码可能只有 20 行，v2 可能有 200 行
# 区别？全靠你 Prompt 写得好不好

2.3 Context Engineering 时代（2025）

发现光有好 Prompt 不够，得给 AI 喂足够的背景信息。

Andrej Karpathy 给出了最被引用的定义："在恰当时刻用恰到好处的信息填充上下文窗口——这是一门精细的艺术和科学。"

RAG（Retrieval-Augmented Generation）火起来了，向量数据库开始普及。核心理念是：模型看到什么信息，决定了它能产出什么质量的结果。

# Context Engineering 时代的典型架构
class ContextEngine:
    def __init__(self):
        self.vector_store = ChromaDB()
        self.document_loader = DocumentLoader()
        self.chunk_size = 512
    
    def build_context(self, query: str) -> str:
        # 1. 从向量库检索相关文档
        relevant_docs = self.vector_store.similarity_search(query, k=5)
        # 2. 拼接上下文
        context = "\n\n".join([doc.page_content for doc in relevant_docs])
        # 3. 控制上下文窗口大小
        return self.truncate_to_window(context)

2.4 Harness Engineering 时代（2025-2026初）

AI 不只回答问题，开始执行任务了。你得给它配工具、定权限、看日志。

Martin Fowler 的表述最清晰："Agent = Model + Harness。" Harness 是 Agent 中除了模型之外的一切——引导文件、传感器、工具链管理、记忆系统、生命周期管理。

Ryan Lopopolo（OpenAI Codex 团队成员）说得更直白："Agent 不难，Harness 才难。"

Mitchell Hashimoto（HashiCorp 联合创始人）给了 Harness 工程一个核心心法：每次 Agent 犯了错，不要指望它下次能自动变好。去改造环境，让这种错误不可能以同样的方式再次发生。

# Harness Engineering 时代的典型架构
class AgentHarness:
    def __init__(self):
        self.model = load_model("claude-sonnet-4")
        self.tools = ToolRegistry()      # 工具注册
        self.permissions = PermissionManager()  # 权限管理
        self.memory = MemorySystem()      # 记忆系统
        self.logger = StructuredLogger()   # 日志
        self.guardrails = GuardrailChain()  # 安全护栏
    
    def run(self, task: str):
        # Harness 武装单次运行
        context = self.memory.load_relevant(task)
        tools = self.permissions.filter_allowed(self.tools)
        result = self.model.execute(task, context=context, tools=tools)
        self.memory.save(result)
        self.logger.log(task, result)
        return result

LangChain 做过一个有力的实证：只改 Harness（不改模型、不改数据、不改提示词），就把一个编程 Agent 在 Terminal Bench 2.0 上的排名从 30 名以外拉到了前 5。同样的模型、同样的数据、同样的提示词，从 42% 的任务成功率跳到 78%——纯靠改进运行环境。

2.5 Loop Engineering 时代（2026）

Cobus Greyling 的区分最精准："Harness 武装的是单次 Agent 运行；Loop 是在这之上持续调度 Agent、派生帮手、自我喂养。"

这是质的飞跃：

三、Loop 的本质：一个技术定义

3.1 最小可运行 Loop

剥到最底层，一个 AI Loop 就是一个 while 循环。Amit Shekhar（Outcome School 创始人）给出了最干净的代码骨架：

import anthropic

client = anthropic.Anthropic()

def run_loop(goal: str, tools: list, max_iterations: int = 50):
    """最小可运行的 AI Loop —— 约 20 行核心代码"""
    messages = []
    system_prompt = f"你的目标是: {goal}\n完成后输出 <DONE/>"
    
    for i in range(max_iterations):
        # 1. 调用 LLM 做决策
        response = client.messages.create(
            model="claude-sonnet-4",
            max_tokens=4096,
            system=system_prompt,
            tools=tools,
            messages=messages
        )
        
        # 2. 检查停止信号
        if response.stop_reason == "end_turn":
            text = response.content[0].text
            if "<DONE/>" in text:
                print(f"目标达成！共迭代 {i+1} 轮")
                return text
        
        # 3. 执行工具调用
        if response.stop_reason == "tool_use":
            tool_results = []
            for block in response.content:
                if block.type == "tool_use":
                    result = execute_tool(block.name, block.input)
                    tool_results.append({
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": str(result)
                    })
            # 4. 回传结果，继续下一轮
            messages.append({"role": "assistant", "content": response.content})
            messages.append({"role": "user", "content": tool_results})
    
    print("达到最大迭代次数，未完成目标")
    return None

整个核心逻辑就是一个 for 循环、一个 LLM 调用、一个停止信号检查、一个工具调用分支。所有后来加上的记忆系统、并行工具调用、重试机制、日志记录，都是在这个核心循环上做的打磨。

3.2 五个组成部分

每一个 AI Loop 都有完全相同的五个组成部分：

从 Claude Code 到 Codex 到 Copilot 到 Gemini CLI，尽管界面不同、底层模型不同，架构惊人地相似——因为它们本质上都在实现同一组原语。

3.3 Loop vs Workflow vs Cron

很多人混淆这三者。核心区别：

Workflow 是确定性脚本：你提前画好流程图，第一步做什么、第二步做什么，系统按图跑。

Cron 是定时任务：按固定时间间隔执行固定脚本。你写好 if-else，它照着跑。

Loop 是非确定性决策循环：每一步做什么，不是你预先画好的，是模型根据当前状态动态决定的。它可能在第 5 轮决定前 4 轮的方向是错的，全部推翻重来。

# Workflow: 确定性的
def workflow():
    step1_fetch_data()      # 总是第一步
    step2_process()          # 总是第二步
    step3_validate()         # 总是第三步
    step4_deploy()           # 总是第四步

# Loop: 非确定性的
def loop(goal):
    while not is_done():
        observation = observe_current_state()
        decision = llm.decide_next_action(observation)  # AI 决定做什么
        execute(decision)
        # 可能在第 3 轮发现方向错了，推翻重来

Boris Cherny 自己承认他在 cron 上跑 Loop。 Claude Code 的 /loop 命令底层也是 cron。但普通 cron 执行的是固定脚本；Loop 中间多了一个关键的东西：一个会观察当前状态、自己决定下一步做什么、做了之后自己检查效果、然后自己决定要不要继续的 AI 模型。

四、Loop 的六块核心积木

一个能真正跑起来的 Loop，由 5+1 块积木拼成。

4.1 积木一：自动化调度（Automation）

这是 Loop 的起搏器。没有自动化，Loop 就不是 Loop，只是一串手动执行的任务。

三种触发模式：

定时触发（cron）：每天早上 9 点自动启动检查 CI 失败记录

# 定时触发：每天早上 9 点自动跑
import schedule
import time

def morning_triage_loop():
    """每天早上 9 点的分诊 Loop"""
    failures = check_ci_failures(since="yesterday")
    open_issues = get_open_issues(priority="high")
    recent_commits = get_recent_commits(hours=24)
    
    triage_report = analyze_and_prioritize(
        failures, open_issues, recent_commits
    )
    
    for item in triage_report.items:
        if item.estimated_effort == "small":
            spawn_fix_agent(item)  # 自动派 Agent 修
        else:
            add_to_inbox(item)     # 放进收件箱等人处理

schedule.every().day.at("09:00").do(morning_triage_loop)

事件触发（hook）：有新 Issue 创建时自动启动分析

# 事件触发：新 Issue 创建时自动分诊
@on_event("github.issue.created")
def on_new_issue(event):
    issue = event.payload
    analysis = loop_analyze_issue(issue)
    
    if analysis.complexity == "trivial":
        spawn_auto_fix_agent(issue, analysis.suggested_fix)
    elif analysis.complexity == "medium":
        spawn_investigation_agent(issue)
    else:
        create_triage_card(issue, analysis)

目标触发（/goal）：设定一个目标，"不达目标不罢休"

# 目标触发：持续运行直到目标达成
def goal_loop(goal: str, verification_fn):
    """
    /goal 的核心逻辑：
    1. 给 Agent 一个目标
    2. Agent 自己跑
    3. 独立验证器检查是否完成
    4. 没完成就继续
    """
    attempts = 0
    while attempts < MAX_ATTEMPTS:
        result = agent.execute(goal)
        verification = verification_fn(result)
        
        if verification.passed:
            return result
        
        # 根据验证反馈调整策略
        goal = refine_goal_based_on_feedback(
            goal, verification.feedback
        )
        attempts += 1
    
    return FailedGoalReport(goal, attempts)

4.2 积木二：工作树（Worktrees）——安全并行

当多个 Agent 同时改代码，冲突怎么办？

Git Worktree 的思路：给每个 Agent 配独立工位。在同一个仓库里切出独立的 worktree，Agent A 的修改完全碰不到 Agent B 的文件。互不干扰，各干各的，最后再合并。

# 为每个 Agent 创建独立的 worktree
git worktree add ../project-agent-a -b fix/auth-bug
git worktree add ../project-agent-b -b feat/new-api
git worktree add ../project-agent-c -b refactor/db-layer

# 每个 Agent 在自己的 worktree 里独立工作
# Agent A 修 auth bug
# Agent B 写新 API  
# Agent C 重构数据库层
# 互不干扰，最后 merge

Steve Yegge 的 Gas Town 项目是代表：20 到 30 个 Claude Code 实例由一个"市长 Agent"协调，巡逻 Agent 持续运行，状态存在 Git 里。每个 Agent 都有自己的 worktree，物理隔离。

4.3 积木三：技能包（Skills）——项目知识持久化

Skill 是你对项目所有要求的持久化存储：

• 代码风格规范
• 架构约定
• 踩过的坑
• 测试要求

Agent 每跑一圈就读一次 Skill，不用你每次都重新讲一遍。Skill 就是 Loop 的长期记忆。

<!-- SKILL.md - 项目技能文件 -->
# 项目规范

## 代码风格
- 使用 Python 3.12+，严格类型标注
- 所有函数必须有 docstring
- 异步优先：能用 async 的地方不用 sync

## 架构约定
- 分层架构：router → service → repository → model
- 数据库操作只在 repository 层
- API 响应统一用 `ApiResponse` 包装

## 测试要求
- 新功能必须有单元测试
- Bug 修复必须有回归测试
- 测试覆盖率不低于 80%

## 踩过的坑
- PostgreSQL 连接池在高并发下会耗尽，必须用 asyncpg
- Redis 缓存 key 必须加前缀，防止命名冲突
- 文件上传用流式处理，不要一次性读入内存

没有技能的 Loop，每个循环都从零重新推导你的整个项目。有技能的 Loop，它会积累。

4.4 积木四：连接器（MCP）——扩展 Loop 的感知范围

一个只能读文件的 Loop 叫小 Loop，能操作真实工具的才是大 Loop。

通过 MCP（Model Context Protocol）协议，Agent 可以：

• 读 Issue Tracker（GitHub Issues、Linear、Jira）
• 查数据库（PostgreSQL、MongoDB）
• 操作 CI/CD（GitHub Actions、Jenkins）
• 发 PR、更新工单
• 发消息通知（Slack、飞书、Discord）

# MCP 连接器配置示例
mcp_connectors = {
    "github": GitHubConnector(
        token=os.environ["GITHUB_TOKEN"],
        capabilities=["issues", "pull_requests", "actions"]
    ),
    "database": PostgresConnector(
        dsn=os.environ["DATABASE_URL"],
        capabilities=["query", "migrate"]
    ),
    "slack": SlackConnector(
        token=os.environ["SLACK_TOKEN"],
        capabilities=["send_message", "read_channel"]
    ),
    "ci": GitHubActionsConnector(
        token=os.environ["GITHUB_TOKEN"],
        capabilities=["trigger", "read_logs"]
    )
}

连接器决定了 Loop 的"手脚"能伸多远。

4.5 积木五：子智能体（Sub-agents）——写的人和检查的人分开

这是 Loop 里最关键的一步——把"干活"和"检查"拆成两个人。

让写代码的 Agent 给自己打分？太容易放水了。正确做法：

• Agent A：负责写代码、修 Bug
• Agent B：独立 Agent，配不同指令（甚至不同模型），专门审查 Agent A 的工作

Lance Martin（Anthropic，前 LangChain 团队）的一手数据证实：验证子代理的表现优于自我批评。 因为评分是在独立的上下文窗口中完成的，避免了"自己评价自己"的偏差。

def loop_with_sub_agents(task):
    """双 Agent 架构：写代码 + 审查"""
    
    # Agent A: 写代码
    coding_agent = Agent(
        model="claude-sonnet-4",
        role="资深开发者",
        tools=["file_edit", "terminal", "search"]
    )
    
    # Agent B: 审查代码（不同的指令和上下文）
    review_agent = Agent(
        model="claude-sonnet-4",
        role="严格代码审查者",
        tools=["file_read", "terminal"],
        instructions="""
        你是一个极其严格的代码审查者。
        检查：安全性、性能、可维护性、测试覆盖。
        不要轻易通过——找到真正的问题。
        """
    )
    
    for attempt in range(MAX_ATTEMPTS):
        # Agent A 写代码
        code_result = coding_agent.execute(task)
        
        # Agent B 审查
        review = review_agent.execute(
            f"审查以下代码变更:\n{code_result.diff}"
        )
        
        if review.approved:
            return code_result
        
        # 根据审查反馈让 Agent A 修改
        task = f"根据审查反馈修改代码:\n{review.feedback}\n原代码:\n{code_result.code}"
    
    return FailedReport(task, attempts)

4.6 积木六：记忆层（Memory）——Loop 的脊椎

最简单也最容易被忽略的一块。

Loop 跑着跑着，Agent 会忘。上下文窗口装不下所有历史。所以需要一个磁盘上的状态文件——Markdown、Linear 看板、任何活在会话之外的东西——记录"什么做了、什么没做、什么失败了、下一步干啥"。

Agent 会忘，文件不会。

# 状态文件示例
"""
# Loop 状态文件 - 2026-07-07

## 当前目标
修复 CI 测试失败问题

## 已完成
- [x] 分析 CI 日志，定位 3 个失败测试
- [x] 修复 test_auth.py 的 mock 问题
- [x] 修复 test_db_connection 的超时配置

## 进行中
- [ ] 修复 test_api_rate_limit（Agent A 正在处理）

## 失败记录
- 2026-07-07 09:15: 尝试修复 test_api_rate_limit，方法 1 失败
  原因：rate limiter 的时间窗口配置不对
  下次尝试：改用滑动窗口算法

## 下一步
1. 等 Agent A 完成 test_api_rate_limit 修复
2. 派 Agent B 审查所有修复
3. 如果全部通过，自动创建 PR
"""

五、一个真实的 Loop 实战场景

Addy Osmani 展示了他自己每天在用的一个 Loop，看完你就懂了。

5.1 早上 9:00 —— 分诊 Loop 启动

每天早上 9:00，一个定时任务自动启动。它调一个"分诊" Skill——像个急诊护士翻病历——翻昨天的 CI 失败记录、Open Issue、最近的 commit。翻完后，把发现的问题写进 Markdown 文件。

# 分诊 Loop - 每天 9:00 自动运行
def morning_triage():
    # 1. 收集信息
    ci_failures = github.actions.get_failures(since="yesterday")
    open_issues = github.issues.list(
        state="open", 
        labels=["bug", "p0"],
        sort="created"
    )
    recent_commits = github.commits.list(since="yesterday")
    
    # 2. AI 分析和优先级排序
    triage = llm.analyze(
        f"""分析以下信息，按优先级排序：
        CI 失败: {ci_failures}
        Open Issues: {open_issues}
        最近提交: {recent_commits}
        
        对每个问题给出：
        1. 严重程度 (P0-P3)
        2. 预计修复时间
        3. 建议的修复方案
        4. 是否可以自动化修复
        """
    )
    
    # 3. 分发任务
    for item in triage.items:
        if item.auto_fixable:
            # 小问题：自动开 worktree，派 Agent 修
            worktree = git.create_worktree(f"fix/{item.id}")
            agent = spawn_coding_agent(worktree)
            agent.fix(item)
        else:
            # 大问题：放进收件箱，附上分析
            create_inbox_card(item)

5.2 自动修复 Loop

对每个值得修的小问题 → 自动开一个独立 worktree → 派 Agent A 起草修复方案 → 派 Agent B（配项目规范和测试）审查方案 → 过了 → 连接器自动开 PR、更新工单。

def auto_fix_loop(issue):
    """自动修复 Loop"""
    # 1. 创建隔离工作区
    worktree = git.create_worktree(f"fix/{issue.id}")
    
    # 2. Agent A: 修复
    fix_result = coding_agent.execute(
        task=f"修复以下问题:\n{issue.description}",
        worktree=worktree,
        skill="project-standards"
    )
    
    # 3. Agent B: 审查
    review = review_agent.execute(
        task=f"审查修复:\n{fix_result.diff}",
        worktree=worktree
    )
    
    if review.approved:
        # 4. 自动开 PR
        pr = github.create_pull_request(
            title=f"fix: {issue.title}",
            body=f"自动修复 #{issue.id}\n\n{fix_result.summary}",
            branch=worktree.branch
        )
        # 5. 更新工单
        github.issues.update(issue.id, 
            labels=["auto-fixed"],
            comment=f"已自动创建 PR #{pr.number}"
        )
    else:
        # 审查不通过，放进收件箱
        create_inbox_card(issue, review.feedback)

5.3 搞不定的 → 放进 Triage 收件箱

不是所有问题都能自动解决。搞不定的放进 Triage 收件箱等人处理。

5.4 全程状态追踪

全程串起来的是一条状态文件，记录什么试过、什么通过、什么还开着。明天早上从今天停下的地方继续。

从发现问题到分配、修复、审查、开 PR——一个字都不用敲。

六、Loop 的五阶段演进史

Loop 不是 2026 年凭空冒出来的。它有至少五年的技术积累。

6.1 第一阶段：学术上的 while 循环（2022）

ReAct 论文把"推理→行动→观察→重复"的循环形式化了。一个模型、一个循环、一个人盯着看。学术上说得通，离工程实践还很远。

ReAct 论文的核心循环：
Thought: 我需要搜索相关信息
Action: search("Python async best practices")
Observation: 找到了 5 篇相关文章
Thought: 第 3 篇最相关，我需要提取关键信息
Action: read(article_3)
Observation: 文章提到了 asyncio.gather 和 TaskGroup
Thought: 现在我有足够的信息来回答了
Answer: ...

6.2 第二阶段：AutoGPT 和"AI Agent 是玩具"时代（2023）

AutoGPT 给 Loop 加了一个目标，让模型自己给自己发指令。然后它就出名了——以"无限空转不出活"出名。

这个失败留下了一个持久的副作用：它给"AI Agent 都是玩具"这个论调提供了两年的弹药。

6.3 第三阶段：Ralph Loop 和极简主义的胜利（2025年7月）

Geoffrey Huntley 发布了一个简单到几乎侮辱人的方案：一个 Bash 单行命令，把同一个提示词文件反复喂给 AI Agent。

# Ralph Loop —— 一行命令的 Loop
while true; do
    cat PROMPT.md | claude-code --no-interactive
    echo "检查产出，按 Enter 继续，Ctrl+C 停止"
    read
done

Ralph Loop 真正的创新不是复杂度，而是纪律——每次迭代，它把 AI 的上下文重置到一组固定的锚点文件，不让对话越来越长。Huntley 用这个方案构建了一整个编程语言，Token 成本约 297 美元。

6.4 第四阶段：产品化的目标命令（2026年春）

Codex 和 Claude Code 几乎同时发布了 /goal 命令。本质上是把 Ralph Loop 包装成产品功能：你给一个目标，一个小型验证模型持续检查是否完成了，完成了就停。

6.5 第五阶段：多 Agent 编排（2026年现在）

Boris Cherny 和 Steinberger 真正在说的东西。四件事变了：

1. Loop 变成了工作单元——不再是单一循环，而是可以组合的模块
2. Loop 开始监督其他 Loop——层级化的调度
3. 调度替代了人工触发——全自动运行
4. 持久化成为显式需求——跨运行的状态管理

七、为什么 2026 年是质变点

三个条件刚好同时成熟：

7.1 模型终于好到可以无人值守运行

Lance Martin 分享了一组硬数据：在 Parameter Golf 挑战赛中，Claude Fable 5 模型比 Claude Opus 4.7 在循环任务上的表现好了约 6 倍。关键差异：Opus 4.7 做完第一个实验拿到一个小改进后，几乎后续所有实验都沿同一个模板。Fable 5 则大胆下注更大的结构性变更，并且在遇到挫折时展现出了韧性。

这意味着：模型不再是 Loop 的瓶颈。以前模型跑着跑着就"傻了"，现在它能在长时间运行中保持决策质量。

7.2 两家前沿实验室在同一周公开推动

Anthropic 和 OpenAI 几乎同时鼓励开发者"写 Loop 而不是写提示词"。这不是巧合——是因为模型能力到了，基础设施到了，就差工程范式这一步了。

7.3 工具链成熟到"一行命令就能启动"

一年前搭 Loop 要写一堆 Bash 脚本、维护复杂的状态管理。现在能力直接内嵌在产品里了：Claude Code 的 /loop 和 /goal、Codex 的 Automations、OpenClaw 的 cron + skill 系统。

八、47 次实验验证的四个核心发现

The Deep Feed 跑了 47 次真实的 Agent Loop，花了 1.77 美元。结论：命名是营销，底层的技术转型是真实的。

8.1 发现一：验证函数才是产品

同一个任务，两种提示词。第一种说"做到能用为止"（弱停止条件），第二种说"pytest 全部通过之前不要停"（精确停止条件）。

精确停止条件快 31%、便宜 7%。更重要的区别：弱停止条件的产出质量方差很大（有时好有时差），精确停止条件的产出质量稳定。

启示：你花在设计验证函数上的时间，比花在写提示词上的时间更值。

8.2 发现二：子 Agent 验证优于自我批评

让同一个 Agent 写完代码后自己审查 vs 让独立 Agent 审查：

子 Agent 审查的 Bug 检出率高 44%，误报率低 47%。

原因：独立的上下文窗口避免了"自己评价自己"的偏差。就像让作者自己校对，永远不如让另一个人校对。

8.3 发现三：状态持久化是 Loop 的命脉

有状态文件的 Loop vs 无状态文件的 Loop（每次从零开始）：

有状态文件的 Loop 任务完成率高 57%，Token 消耗反而更低。

8.4 发现四：Loop 的成本曲线是非线性的

前 3 轮迭代通常消耗 70% 的 Token，但只完成 30% 的工作。后面每轮的边际成本递减，因为 Agent 已经积累了足够的上下文。

启示：不要心疼前几轮的 Token 消耗，那是"暖机"成本。

九、三个大坑：Loop 越强，你越危险

Addy Osmani 在讲完 Loop 的构成后，花了同样篇幅讲三个坑。这很说明问题。

9.1 坑一：验证还是你的活

别以为"AI 说完成了"就等于真的完成了。"完成了"是声明，不是证明。

子 Agent B 审查过 ≠ 代码没问题。发布前你还是要亲自确认——就像老板签合同之前还是要自己看一眼。

# 危险：盲目信任 Loop 的产出
def bad_practice():
    result = loop.run("修复所有 CI 失败")
    # ❌ 直接合并，不验证
    git.merge(result.branch)

# 正确：Loop 产出 + 人工验证
def good_practice():
    result = loop.run("修复所有 CI 失败")
    # ✅ 人工检查关键部分
    review = human_review(result.diff)
    if review.approved:
        git.merge(result.branch)
    else:
        loop.refine(result, review.feedback)

9.2 坑二：理解债务会滚雪球

Loop 产出速度越快，你真正能理解的代码就越少。

代码不是你写的，你没参与过程，出问题时你连从哪下手都不知道。这叫理解债务——一个丝滑的 Loop 只会让它膨胀得更快。

除非你愿意认真阅读 Loop 产出的东西，而不是闭眼接收。

9.3 坑三：最舒服的姿势最危险

当 Loop 自己在那撒欢跑，你很容易被诱惑——直接收下它给的一切结果，不再思考，不再判断。

Addy 管这个叫**"认知投降"**。

设计 Loop 是解药还是毒药，取决于你是用判断力设计 Loop 来提效，还是用 Loop 来逃避思考。

同一个 Loop，两个人用：

• 一个人用它加速自己透彻理解的工作
• 另一个人用它避开理解工作本身

Loop 分不清。你自己要分清。

十、怎么开始你的第一个 Loop

10.1 Level 1：从 /goal 开始

最简单的 Loop 入口。告诉 AI 你的目标，让它自己判断"完成了吗"：

# Claude Code
/goal 把这个项目的所有 TypeScript 文件加上 JSDoc 注释

# Codex
/goal 修复所有标记为 P0 的 GitHub Issues

Agent 会自己跑、自己检查、自己继续——直到目标达成。

10.2 Level 2：加上 Hook 自动化

在 Claude Code 里，stop hook 是天然的 Loop 触发器。Agent 每完成一轮 → hook 自动触发下一轮决策。

// .claude/settings.json
{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "command": "node scripts/decide-next.js"
      }
    ]
  }
}

decide-next.js 的作用：读取当前状态，判断是否需要继续，如果需要就返回一个新的任务描述。

// scripts/decide-next.js
const fs = require('fs');

// 读取状态文件
const state = JSON.parse(fs.readFileSync('.loop-state.json', 'utf8'));

// 检查是否还有未完成的任务
if (state.pendingTasks.length > 0) {
    const nextTask = state.pendingTasks.shift();
    fs.writeFileSync('.loop-state.json', JSON.stringify(state));
    console.log(`继续下一个任务: ${nextTask.description}`);
    process.exit(0); // 继续
} else {
    console.log('所有任务完成！');
    process.exit(1); // 停止
}

10.3 Level 3：搭完整流水线

把六块积木拼起来：

1. cron 定时触发
2. worktree 隔离工作区
3. skill 持久化规范
4. MCP 连接器 连接真实工具
5. 子 Agent 干活 + 审查
6. 状态文件 记录进度

# 完整的生产级 Loop 架构
class ProductionLoop:
    def __init__(self):
        self.scheduler = CronScheduler()
        self.worktree_manager = GitWorktreeManager()
        self.skill_loader = SkillLoader("./skills/")
        self.mcp = MCPConnectorRegistry()
        self.state = PersistentState(".loop-state.json")
        
        # 双 Agent 架构
        self.coder = Agent(
            model="claude-sonnet-4",
            role="开发者",
            tools=["file_edit", "terminal", "search"]
        )
        self.reviewer = Agent(
            model="claude-sonnet-4",
            role="审查者",
            tools=["file_read", "terminal"]
        )
    
    def run(self, goal: str):
        """主循环"""
        self.state.set_goal(goal)
        
        while not self.state.is_goal_reached():
            # 1. 观察当前状态
            observation = self.observe()
            
            # 2. AI 决定下一步
            action = self.coder.decide_next(observation)
            
            # 3. 在隔离的 worktree 中执行
            worktree = self.worktree_manager.create()
            result = self.coder.execute(action, worktree=worktree)
            
            # 4. 子 Agent 审查
            review = self.reviewer.execute(
                f"审查: {result.diff}",
                skill=self.skill_loader.load("project-standards")
            )
            
            # 5. 更新状态
            self.state.record(action, result, review)
            
            if review.approved:
                self.mcp.github.create_pr(result)
            else:
                self.state.add_pending(review.feedback)
        
        return self.state.get_summary()

十一、Loop Engineering 的未来展望

11.1 从单 Loop 到 Loop 网络

2026 年下半年的趋势是：多个 Loop 协同工作。一个 Loop 负责 CI/CD，一个 Loop 负责代码审查，一个 Loop 负责文档更新——它们通过共享状态文件和 MCP 连接器互相通信。

11.2 Loop 市场的兴起

就像现在的 npm 生态一样，未来会出现"Loop 市场"——你可以下载别人写好的 Loop 模板，改改配置就能用。"分诊 Loop"、"安全扫描 Loop"、"性能优化 Loop"——开箱即用。

11.3 Loop 的可观测性

当你的 Loop 在后台 24/7 运行，你需要知道它在干什么。Loop 的可观测性（Observability）将成为新的工程挑战：

• 每轮迭代的决策日志
• Token 消耗追踪
• 任务完成率仪表盘
• 异常告警（无限循环检测、成本失控预警）

十二、总结：你的角色变了

Loop Engineering 不是什么神秘的黑科技。它的本质就是：把你从流水线上解放出来，让你去设计流水线本身。

但别忘了 Addy Osmani 最后的提醒：

"搭好你的 Loop，但别忘了直接给你的 Agent 写 Prompt 仍然有效。关键是找到正确的平衡。"

Loop 替你省掉的是繁琐的重复操作，不该替你省掉的，是作为工程师的参与感和判断力。

Boris Cherny 说"我的工作是写 Loop"——这句话不是在说工作变少了，而是在说工作的难点变了。

Loop Engineering 是大势所趋，学它、用它，但要保持思考。做一个还在思考的工程师，而不是只会按"开始键"的人。

附录：Loop Engineering 核心概念速查表

参考资源：

1. Boris Cherny - Claude Code 团队在 Anthropic 开发者大会上的分享
2. Peter Steinberger - OpenClaw 创始人关于 Loop Engineering 的推文
3. Addy Osmani - Google Cloud AI 总监关于 Loop 架构的系统化长文
4. The Deep Feed - 47 次 Agent Loop 实验的技术报告
5. Geoffrey Huntley - Ralph Loop 极简主义方案
6. Lance Martin - Anthropic 关于子 Agent 验证的实验数据
7. Steve Yegge - Gas Town 多 Agent 编排项目