引言：AI 协作范式的拐点

2026 年 6 月，硅谷 AI 圈被三句话点燃：

黄仁勋："Nobody writes prompts anymore. The new job is to write and handle loops."

Boris Cherny（Claude Code 负责人）："I don't prompt Claude anymore. I have loops running. My job is to write loops."

Peter Steinberger（OpenClaw 创始人）："You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."

这三句话宣告了一场范式迁移：人类从 Agent 循环的内部走向外部，从执行者变成设计者。如果说 AI 时代的上半场是“人以言驭物”，那么下半场正在全面转向“系统自我迭代”。

本文将围绕这一技术演进脉络，深入盘点驱动这场范式重塑的四次核心浪潮，并给出从判断到落地的完整实操指南。

一、AI 开发范式的四次跃迁

为了帮助大家直观理解，我们可以将 AI 范式的演进历程看作一条沿着“教 AI 说话 → 给 AI 资料 → 帮 AI 建办公室 → 让 AI 自己打工”脉络不断演进的进化史。

1. Prompt Engineering —— 沟通艺术

这一阶段的核心问题是“如何跟 AI 沟通”。经典方法包括 Zero-shot、Few-shot、Instruction Prompting 以及 APE 自动 Prompt 搜索等。

正确的 Prompt Engineering 是一套工程方法论：定义问题 → 构造示例集 → 候选 prompt → 实测准确率 → 成本/精度权衡 → 持续迭代。与之相对的是只靠 trial-and-error、缺乏测试的 Blind Prompting。

业界开始尝试把 Prompt 程序化。以 DSPy 为代表的声明式框架提出了关键转变：开发者不再手写指令字符串，而是声明输入输出的签名，再交给优化器自动搜索最优的 Prompt 与 Few-shot 组合，使 Prompt 第一次从“人工手写”变成了“可编译、可学习的程序”。

然而，纯粹的 Prompt Engineering 很快遇到了天花板：受限于上下文窗口、缺乏记忆与工具调用、容错率极低。更深层的影响是随之而来的“技术债”——模型升级或业务微调时，精心打磨的 Prompt 极易集体失效。

2. Context Engineering —— 对话管理

这一阶段的核心演进在于将注意力从“如何写提示词”转向“信息怎么喂给模型”。就像发邮件前，帮 AI 把附件、参考资料和背景画像都准备好。

针对“信息怎么喂”，业界演进出了三套核心方法论：

轻量化装配（MVC）：严控单次请求体积，只组合最必需的用户目标、检索结果与当前工具定义。

知识图谱增强检索（GraphRAG）：用实体关系网络取代传统向量相似度，解决多跳推理与可解释性问题。

即时检索（Just-in-Time）：初始阶段仅维护资料的轻量引用，运行时按需实时加载。

此外，信息的排列顺序直接决定模型响应质量与成本。利用大模型的提示词缓存（Prompt Caching）机制，将确定性内容（工具定义、系统提示）放在前缀，动态内容（当前日期、用户消息）放在末尾，可大幅降低计算成本。

3. Harness Engineering —— 系统约束

随着 AI 越来越多地应用于企业真实业务场景，人们意识到仅仅把资料喂对不足以让大模型独立支撑高可靠的工业级应用。行业内逐渐确立了 Agent = Model + Harness 的研发范式。

一个生产级别的 Harness 系统主要由四大核心支柱构成：

环境资产与工具集：Tools、Skills、MCP 服务、文件系统、安全沙箱等。

控制与编排逻辑：子 Agent 派发、状态接力与模型路由。

规则中间件（Hooks）：上下文压缩、代码静态检查、提交网关等。

运行即可观测性：Trace 链路、Token 成本、延迟实时计量。

从信任边界来看，这些组件构成了“物理基础设施 → 安全沙箱 → Agent Harness → 运行时 → 模型”的层层防御结构。模型处于最核心、也最不可信的位置，其执行的每一个高风险动作都必须经过外围 Harness 规则的解析与沙箱隔离。

4. Loop Engineering —— 自主闭环

在 Harness 的基础上，Loop Engineering 成了最新的进化方向。如果说 Harness 解决的是“AI 能不能在真实环境里干活”，那 Loop 解决的就是“AI 能不能在这个环境里持续干活、自己推进任务、不需要人一步步盯着”。

它的核心不再是单次执行能力，而是一个闭环系统的运行能力。人类只做一次高价值设计：定义目标与停止条件、搭建验证机制、建立持久化记忆、配置发现与调度。之后，AI 循环系统可以自主发现任务 → 执行 → 验证 → 持久化 → 再次发现，24/7 运行，人类只在必要时介入。

二、循环工程的五大核心组件与记忆机制

一个完整的 Loop 需要五个核心组件，外加一个用于存储信息的载体。

1. 自动化（Automations）—— 循环的心跳

自动化让“循环”名副其实。在 Codex 中，你可以在“自动化”标签页创建任务，指定项目、提示词、执行频率。Claude Code 则通过 /loop（按节奏重复）、/goal（持续运行直到满足条件）和 /schedule（云端定时任务）实现。

关键设计：停止条件必须写死，避免无限跑。

2. 工作树（Worktrees）—— 并行不打架

多个 Agent 同时干活，最怕改同一个文件。Git Worktree 给每个 Agent 一份独立工作区，互不干扰，最后再合并。Codex 和 Claude Code 都内置了对 Worktree 的支持。

3. 技能（Skills）—— 把背景写下来

项目用什么框架、有什么约定、踩过什么坑，写成一个 skill 存着，Agent 每轮直接读，省得每次从零解释。Codex 使用 SKILL.md 文件，Claude Code 使用 CLAUDE.md 或 .claude/skills/ 目录。

4. 连接器（Connectors）—— 连上真实工具链

通过 MCP 协议接上 GitHub（开 PR）、Linear/Jira（更新 ticket）、Slack（发汇总）、Sentry（查告警），loop 才算真正接入你的工作流。Codex 和 Claude Code 都支持 MCP 标准，因此你为其中一个编写的连接器通常也能直接在另一个中运行。

5. 子智能体（Sub-agents）—— 写的和验的分开

写代码的模型给自己打分太宽容。换一个带不同指令的第二个 Agent 来验收，能抓到第一个自我说服过去的问题。Claude Code 的 /goal 命令在底层使用一个独立的模型（如 Haiku）来判断循环是否结束，而非执行任务的那个模型。

6. 记忆（Memory）—— 记住昨天做到哪了

模型会遗忘，但磁盘不会。记忆可以是一个 Markdown 文件、一块 Linear 看板，或是任何独立于单次对话之外、用于记录已完成工作及后续计划的载体。例如：

Loop state · ci-triage
上次运行
2026-06-09 03:30 UTC · 7 个失败已分类，3 个草拟修复，4 个上报
进行中
claude/fix-auth-token-refresh — 本地测试通过，等 CI
今日完成
claude/bump-axios-1.7.4 → 已合并（CI 绿，依赖 loop 已验证）
上报给人
src/billing/refund.ts — 测试三种崩法，根因不明
经验教训
2026-06-08: 这台 Windows runner 上 PowerShell 撞 TLS 1.2 问题，改用 bash。

三、从判断到落地：构建最小可行循环

第一步：判断是否需要循环

在动手之前，先回答四个问题：

任务是重复的吗？ 一次性的活，好 prompt 更划算。

有自动验证手段吗？ 测试、类型检查、linter，至少一个。

Token 预算扛得住吗？ Loop 不产出也照样烧钱。

Agent 能跑自己写的代码吗？ 有日志、能复现、看得到哪里崩了。

附加题：你打算 review 它产出的代码吗？不打算，就别建。

第二步：搭建最小可行循环

先让一次手动运行稳定下来。

把项目背景沉淀成一个 Skill。

加一个状态文件，记下做完了什么、下一步干啥。

设一道硬闸门：测试/构建过不了就自动拒。

配一个 Automation，按节奏触发，用 /goal 设停止条件。

多个 Agent 并行就上 Worktree。

接上 Connectors，让 loop 能开 PR、更新 ticket、发 Slack。

拆出 Sub-agents，写代码的和验收的分开。

顺序很关键：先手动跑通一次 → 写成 Skill → 包进 loop → 最后才上定时。跳步是 loop 死在生产环境的主要原因。

第三步：衡量指标

唯一有用的指标是：每个被接受的改动，平均成本是多少。如果接受率低于 50%，说明 loop 在亏本。

四、实战：用 Claude Code + step-3.7-flash 搭建一个 Loop

下面是一个最小可行示例，使用 Claude Code 和阶跃星辰的 step-3.7-flash 模型。

文件一：Agent 定义

在 .claude/agents/builder.md 中：

markdown

name: builder
description: 负责编写和修复代码。
tools: Read, Write, Edit, Glob, Grep, Bash
model: sonnet
你只负责构建和修复，不做其他任何事情。
接到任务时
先读项目的 CLAUDE.md、README、package.json，理解架构分层和编码约定。
确认任务涉及的文件范围。
写一行任务简报：目标、涉及文件、完成标准。然后开始实现。
红线
绝不弱化测试来让它通过。
绝不通过删除、注释、跳过失败的检查来达到通过。
绝不在没有跑过检查的情况下声称已修复。

在 .claude/agents/checker.md 中：

markdown

name: checker
description: 运行所有检查并报告失败项。绝不修改代码。
tools: Read, Grep, Glob, Bash
model: sonnet
你只检查，绝不修复。
发现检查命令
先读 package.json 的 scripts 字段，找出项目实际使用的检查命令。
报告格式
全部通过：输出 "ALL GREEN"，然后逐项列出每项检查的名称和通过证明。
任何失败：输出 "FAILED"，然后逐条列出 file:line - 什么坏了 - 哪个检查抓到的。
红线
绝不意译失败信息。
绝不因为看起来是小问题而省略失败项。
绝不自己尝试修复。

文件二：循环编排器

在 .claude/commands/loop.md 中：

markdown

description: 循环运行 builder 和 checker，直到所有检查通过
argument-hint: 
allowed-tools: Read, Grep, Glob, Bash, Task
model: sonnet
以循环方式执行此任务：$ARGUMENTS
第 0 步：对齐目标
写一行任务简报：目标、涉及文件、完成标准。
循环
派 builder 实现任务（或修复上一轮的失败）。
派 checker 运行所有检查。
如果 checker 说 ALL GREEN：停止，向我展示 diff 和检查结果。
如果 checker 说 FAILED：把 checker 的完整失败报告原样转发给 builder。
回到第 1 步。
轮次管理
最多 5 轮。每轮开始时公开声明 "Cycle N/5"。
如果同一失败连续出现两次，停止循环。
如果修复导致之前通过的检查失败，停止循环。

文件三：停止规则

在项目根目录的 CLAUDE.md 中：

markdown
Loop stop rules
循环在以下任一条件成立时停止：
ALL GREEN：所有检查通过。
轮次用尽：达到 5 轮上限。
同一失败连续两轮：builder 在猜，不是在修。
回归：修复导致之前通过的检查失败。
无实质进展：连续 2 轮失败项数量没有减少。
疑似超出能力边界：builder 反复尝试但失败原因涉及它无法访问的外部依赖。
升级协议
停止并升级给我时，必须携带：
当前轮次
仍失败的项列表
每项已尝试过的修复方法
你的判断：为什么继续循环不会解决问题

配置模型

修改 ~/.claude/settings.json：

json
{
  "env": {
    "ANTHROPIC_AUTH_TOKEN": "你的 StepFun API Key",
    "ANTHROPIC_BASE_URL": "https://api.stepfun.com/step_plan",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "step-3.7-flash",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "step-3.7-flash"
  },
  "model": "sonnet"
}

API Key 在阶跃星辰开放平台申请。把 sonnet 和 haiku 两个别名都映射到 step-3.7-flash，整套 Loop Engineering 只用一个模型。

五、成本与边界：循环工程不是银弹

三种翻车方式

假装干完了：Agent 提前发“完成”信号，活干一半就退。原因只有一个：没有硬闸门。

理解债务：loop 越快交付你没写过的代码，“仓库里有什么”和“你理解什么”的差距就越大。

认知投降：你慢慢不再自己判断，loop 返回啥就收啥。

安全红线

无人值守的 loop 就是无人值守的攻击面。

生成代码未审就上线：闸门里得加 SAST、依赖审计、密钥扫描。

Skill 是注入入口，自动安装前先读源码。

凭证泄露进日志：生产 loop 关掉 verbose 日志。

权限蔓延：每 30 天复审一次。

六、总结：从写提示词到设计循环

从 Prompt 到 Context，再到 Harness，最终到 Loop，这是一条连续的迁移路径：人类对 AI 的控制粒度不断上移，从“写一句话”变成“提供信息”，再变成“搭建系统”，最终变成“设计循环”。

这个转变的核心是：你不再是那个写 prompt 的人，而是设计 prompt 系统的人。

想深入了解 Agent 工作流的构建，可参考 AI Agent 与多智能体。如果你对 Prompt 的系统化设计感兴趣，可以阅读 提示工程。对于 Harness 工程中的工具链集成，API 集成 和 工作流 提供了更详细的指导。

FAQ

Q1: Loop Engineering 和传统的 CI/CD 流水线有什么区别？

A: 传统 CI/CD 流水线的逻辑是硬编码的 if-else（如“如果 CI 红了，运行修复脚本”）。而 Loop Engineering 内部的决策者是 LLM，同样是“CI 红了”，它可能判断“这是个 flaky test，跳过”，也可能判断“这涉及三个文件的依赖变更，需要分步处理”。它的行为在运行时才确定，因为决策者有判断力。

Q2: 我是否需要一个单独的模型来运行循环？

A: 不一定。你可以使用同一个模型，但需要将“执行”和“验证”角色拆分为不同的 Agent，并给予不同的指令和工具权限。更推荐的做法是使用不同的模型（如一个强模型负责写代码，一个轻量模型负责验证），以降低成本并提高验证的独立性。

Q3: 循环工程适合哪些类型的任务？

A: 适合满足以下条件的任务：任务重复发生、有自动化验证手段（测试、类型检查等）、Token 预算充足、Agent 能访问执行环境。典型场景包括 CI 失败分类、依赖更新 PR、Lint 自动修复、Flaky 测试复现等。不适合架构重写、鉴权代码、支付逻辑等需要人类判断的活。

Q4: 如何防止循环无限运行导致 Token 成本失控？

A: 必须设置硬停止条件：Token 上限、迭代次数上限（如 5 轮）、时间限制。同时，在编排器中加入“同一失败连续两次”或“无实质进展”等刹车逻辑。此外，使用支持 Prompt Caching 的模型可以降低重复调用的成本。