提示词工程过时了吗？为什么 2026 年大家开始谈 Loop Engineering

发布日期：2026-06-22 | 话题：AI 工程范式 | 适用人群：开发者、AI 工程师

Loop Engineering（循环工程）是 2026 年 6 月迅速席卷 AI 开发社区的新范式，起点是 OpenClaw 创始人 Peter Steinberger 一条获得 800 万次浏览的推文："你不应该再给编程 Agent 写提示词，你应该设计循环来提示你的 Agent。"随后 Google Cloud AI 总监、前 Chrome 工程负责人 Addy Osmani 发表长文系统整理其架构，Claude Code 负责人 Boris Cherny 公开实践，三人相互印证使这一概念在一周内引爆全球开发者社区。Loop Engineering 的核心主张：人的工作不再是反复调试单条提示词，而是设计一套能自主运转的闭环系统，让 Agent 在「执行→评估→迭代→终止」的循环中自我推进，直到目标完成。本文系统梳理它与提示词工程的差异、五要素骨架、争议，以及在 Claude Code、Codex 等工具上的实际配置思路。

---

从 Prompt Engineering 到 Loop Engineering：四代演进

过去三年，AI 工程的主流思路历经四次迭代，每一次都是对上一代的降本增效：

阶段	核心工作	人的角色	瓶颈
Prompt Engineering	精心设计单条提示词	反复人工调参	人是最大瓶颈
Context Engineering	管理塞入上下文的信息	挑选相关资料给 Agent	上下文质量决定上限
Harness Engineering	搭建脚手架调度 Agent	设计调度逻辑	单次调用，无闭环
Loop Engineering	设计自迭代闭环系统	站在循环外做设计者	Token 消耗和成本

提示词工程为什么感觉"过时"？

不是它错了，是它处理的问题层次变了。

Prompt Engineering 解决的是"如何向 AI 说清楚需求"，在 AI 只能单次问答时这是核心技能。当 Agent 可以调用工具、读写文件、执行代码、自我修正之后，真正的杠杆点从"这条提示词写得好不好"变成了"这套循环设计得好不好"。前者是对话技巧，后者是系统工程。

Boris Cherny（Claude Code 负责人）在公开演讲中说："我写好一个个运行着的循环，让循环去提示 Claude 并让它自己搞清楚该做什么。我的工作就是写循环。"这段话在 X 平台不到 24 小时获得近 70 万次播放。

---

Loop Engineering 的五要素骨架

Addy Osmani 的长文将 Loop Engineering 拆解为五个构成要素，缺一不可：

1. 明确目标（Clear Goal）

不是一条提示词，而是一个可以被验证的终态描述。

# 差的目标（Prompt 风格）
"帮我优化这个函数的性能"

# 好的目标（Loop 风格）
目标：将 processOrders() 的 P99 延迟从 800ms 降至 200ms 以下
验证标准：benchmark 测试输出 p99 < 200
终止条件：连续三次测试均达标，或超过 10 轮迭代自动停止并输出报告

2. 上下文管理（Context Management）

每轮循环需要主动管理 Agent 能"看见"什么——过去的执行结果、错误日志、任务进度摘要。不做上下文管理的循环会在长任务中遗忘早期状态或重复工作。

# 伪代码示例：每轮循环注入精简的上下文摘要
context = {
    "goal": goal,
    "iterations_done": i,
    "last_result": last_result_summary,   # 不是完整输出，是摘要
    "errors_seen": error_log[-3:],        # 只保留最近 3 条错误
    "files_changed": changed_files,
}

3. 可调用工具（Tool Access）

Agent 需要有能力执行它决策的事：运行测试、修改文件、调用外部 API、读取日志。工具越完整，循环的自主度越高。Claude Code 和 Codex 均内置了文件读写、终端执行、Git 操作等核心工具集。

4. 产出评估（Output Evaluation）

每轮执行后必须有一个评估步骤，判断"这轮有没有推进目标"。评估可以是：

• 程序化验证：运行测试套件，检查返回码
• LLM 自评：让另一个模型或同一模型回顾产出质量
• 指标对比：新指标 vs 目标指标

没有评估的循环是盲目重复，不是迭代。

5. 停止标准（Stop Condition）

没有终止条件的循环会无限消耗 Token，或在达标后继续不必要地执行。停止标准通常包含两类：

• 成功终止：评估通过 → 停止并输出结果
• 保护性终止：超过最大轮次、连续失败超过阈值 → 停止并人工介入

---

争议：Loop Engineering 到底是新范式还是炒冷饭？

这是社区讨论最激烈的部分，双方都有实质性论点。

支持派的核心论据：

• 概念的主张足够清晰且可操作——它明确了一套可以落地的系统设计模式
• Claude Code、Codex 在 2026 年的版本迭代（多轮 Agent、/app 切换、Bedrock 接入）实际上已经在支持这套模式
• 行业已经有公司跑了近 3000 个 Agent loop，在 CI/CD、代码审查、文档生成场景中落地

质疑派的核心论据：

• "Loop 消耗大量 Token，除非有无限 Token，否则很多场景仍需人工测试"
• "这不过是把 Harness Engineering 改了个名字"——ReAct、Multi-Agent Orchestration 早就有类似思路
• "OpenClaw 创始人说话带有产品 IP 立场，他说的 loop 未必和 Addy Osmani 说的是同一件事"

较中立的观察（来自虎嗅等媒体）：

Loop Engineering 可以被理解为 AI 原生研发团队的一个具体实践切面，而非彻底替代一切的革命。提示词工程、上下文工程、harness 工程并没有消失，它们都是 loop 的内部组成部分——loop 是在它们之上多加了一层"闭环与评估"的外壳。

---

在 Claude Code 和 Codex 上的实践思路

Claude Code：用 CLAUDE.md 定义 Loop 目标

# CLAUDE.md

## 当前循环目标
重构 src/payment/ 模块，目标：所有单元测试通过，覆盖率 > 85%

## 验证命令
npm run test:payment && npm run coverage:check

## 停止条件
- 成功：测试全绿且覆盖率达标
- 保护：超过 15 轮或出现 3 次以上语法报错，停止并输出进度报告

## 每轮必须执行
1. 修改代码
2. 运行验证命令
3. 如果失败，分析错误并继续；如果成功，标记完成

CLAUDE.md 的本质就是一个 Loop 配置文件——它把目标、上下文约定、终止条件都内联给 Agent，使 Claude Code 在多轮对话中保持方向一致。

Codex：结合 Profile 切换不同循环深度

Codex 的 --profile 机制（v0.134+）天然适合区分"快速一次性任务"和"深度 Agent Loop"：

# ~/.codex/loop.config.toml —— 深度循环场景
model = "codex-mini-latest"
model_provider = "ccswitch"
model_reasoning_effort = "high"
approval_policy = "on-request"   # 关键操作前人工确认，其余自动推进

codex --profile loop "重构 auth 模块，目标：所有测试通过"

approval_policy = "on-request" 让循环可以自主推进，但在写文件、执行删除等高风险操作前暂停请求确认——这正是 Addy Osmani 反复强调的"别让自己变成只会点开始键的人"。

---

FAQ

Q1：提示词工程要废了吗？
没有废，层次变了。写单条提示词的技能依然是 Loop 的基础——loop 里的每个 Agent 调用仍然依赖提示词质量。变化在于，提示词工程从"全部工作"降级为"循环内部的一个子技能"。

Q2：Loop Engineering 适合什么场景？
最适合有明确可验证终态的任务：测试修复（运行测试即是评估）、代码重构（lint + 测试即是评估）、文档生成（字数 + 结构检查即是评估）。不适合"帮我头脑风暴一些想法"这类主观开放性任务——没有程序化评估手段，loop 就失去了自动迭代的基础。

Q3：Loop 会不会消耗太多 Token？
这是真实成本。保护性终止条件（最大轮次上限）是控制成本的核心手段。另外，上下文管理里的"每轮只传精简摘要而非完整历史"可以显著压缩单轮 Token 消耗。建议先在小任务上跑通循环、测量实际消耗，再扩展到更大任务。

Q4：Loop Engineering 和 Multi-Agent 是一回事吗？
有交集但不等价。Loop Engineering 强调的是单个 Agent 的自迭代闭环，Multi-Agent 是多个 Agent 分工协作。现实中两者经常叠加：一个 Loop 内部可以调用多个专项 Agent 分别执行子任务，外层 Loop 负责整体进度评估和终止判断。

Q5：怎么判断我的 Agent 系统是否达到了 Loop Engineering 的标准？
检查五个要素是否都有：（1）目标可验证吗？（2）每轮上下文有没有主动管理？（3）Agent 有没有实际执行工具？（4）每轮有没有评估步骤？（5）有没有明确的停止条件？五项都有，就是 Loop；缺了评估或停止条件，就是脚本自动化，不是 Loop。

---

小结

Loop Engineering 不是对提示词工程的否定，而是当 Agent 能力成熟到可以执行多步骤任务之后，工程师工作重心的自然上移——从"写好每一条指令"到"设计能自主运转的系统"。概念本身有炒作成分，但五要素骨架（目标、上下文、工具、评估、停止）是可操作的设计框架，Claude Code、Codex 等工具已在 2026 年的版本中提供了基础支撑。本文信息来源：OpenClaw 创始人 Peter Steinberger X 推文、Addy Osmani《Loop Engineering》博客（2026-06）、Boris Cherny 公开演讲、虎嗅/东方财富/博客园等中文技术媒体报道，2026-06-22。

---

参考来源：

• OpenClaw 创始人 Peter Steinberger 推文
• Addy Osmani《Loop Engineering》博客
• Boris Cherny 公开演讲（2026-06）
• 七牛云：AI Agent 与 MCP 应用构建指南
• Fenno 官网：AI 编程