一、演进脉络
过去三年，AI 应用工程化经历了 四个关键阶段，每一次都是抽象层级的跃迁：
| 阶段 | 时间 | 核心关注 | 人的角色 |
|---|---|---|---|
| Prompt Engineering | 2023 | 怎么写好单次提示词，诱导模型输出 | "问话者"------雕琢咒语 |
| Context Engineering | 2025 上 | 管理上下文窗口------塞什么、不塞什么、顺序如何 | "信息架构师"------设计信息边界 |
| Harness Engineering | 2025 下--2026 初 | 给 Agent 加约束框架------工具权限、反馈循环、护栏 | "驯兽师"------设安全护栏 |
| Loop Engineering | 2026 中 | 设计循环系统让 Agent 自己提示 Agent，不再手动发指令 | "系统建筑师"------设计运转规则 |
这四者不是替代关系，而是 叠加包含。新范式解决旧范式无法处理的问题，实践中往往共存。
二、Loop Engineering 是什么
2026 年 6 月，两位关键人物几乎同时发声：
-
Boris Cherny（Anthropic 工程师，Claude Code 创建者）：
"我不再提示 Claude 了。我在写一堆循环（loops），它们才是在提示 Claude 并决定下一步做什么。"
-
Peter Steinberger（OpenAI，原 Lobster/OpenClaw 创始人）：
"你不该再给编程 Agent 写提示词了。你应该设计循环机制，让循环去提示你的 Agent。"
Steinberger 的推文引发了 800万+ 次浏览，全网热议。
核心转变
从"人提示 AI" → "人设计系统，系统提示 AI"
开发者不再手动向 Agent 输入指令，而是设计一个 持续运转的循环系统，由系统自动调度、提示、验证 Agent。
三、Agent Loop 的工作原理
一个典型的 Agent Loop 流程：
目标 → 行动 → 观察 → 评估 → 修正 → 下一轮行动
| 对比维度 | 传统编程循环（for/while） | AI Agent Loop |
|---|---|---|
| 执行对象 | 固定的指令序列 | 目标（Goal） |
| 每一步 | 相同逻辑代码重复 | 行动→观察→评估→修正 |
| 处理不确定性 | 需提前覆盖所有 if/else | Agent 自主调整路径 |
| 结束条件 | 计数器或固定条件 | 目标达成/失败/资源耗尽/人工介入 |
四、关键里程碑
1. Ralph（2025.7）------第一个典型 Agent Loop
- 澳大利亚开发者 Geoffrey Huntley 发布
- 本质是个 Bash 脚本：反复将同一个提示词文件喂给 Agent
- 关键创新：每次迭代重置上下文到固定锚点文件，解决上下文污染
- 用此方法构建了一门完整编程语言，仅花 ~297 美元
- 证明了 Loop 的核心价值：让 Agent 在持续改进环境中试错迭代
2. /goal 命令产品化（2026 春）
- Codex （OpenAI）和 Claude Code （Anthropic）都推出了
/goal - 持续运行循环直到某个验证条件完成
- 将 Ralph 的实践思路产品化
3. Loop Engineering 引爆讨论（2026.6）
- Google Cloud AI 总监 Addy Osmani 发布系统博客定义 Loop Engineering
- 提出五个核心组件 + 内存系统
- 警告 "理解债"（Comprehension Debt） 和 "认知投降"（Cognitive Surrender）
五、核心设计组件
一个有效的 Loop 系统需要设计：
1. 清晰可验证的目标
- ❌ "帮我优化一下"------不好
- ✅ "接口响应时间从 800ms 降到 300ms 以下，所有测试通过"------好
- 目标必须可自动验证
2. 结构化的上下文管理
- 太脏/太少/太随机都导致表现差
- Ralph 方案：每次重置到固定锚点文件
- 2026 趋势：基于 Git 的状态管理，每轮改动 commit
3. 精简工具集
- 工具不是越多越好，每增加一个就扩大决策空间
- 只给完成任务必需的工具
4. 分层评估机制
-
"评估是 Loop 的灵魂"
-
自动化处理常规判断，Human-in-the-loop 处理高风险决策
-
Claude Code 的实践：生成器（Generator）---评估器（Evaluator）---规划器（Planner） 架构
- 生成器：构建应用
- 评估器：独立上下文窗口，用 Playwright 真实测试
- 规划器：将需求拆解为规格和冲刺
5. 多维度停止条件
- 成功条件：评估全部通过
- 失败条件：连续多轮无改进/错误超阈值
- 资源限制：时间/成本上限
- 风险检查点：高风险操作前等待人工确认
六，具备哪些能力
从 Prompt → Loop 的演进，要求开发者具备的新能力：
- 元提示设计（Meta-Prompting） ：不再写具体提示词，而是写生成提示词的规则
- 系统架构思维：设计多 Agent 协作拓扑（串行、并行、对抗、投票）
- 验证工程：设计可自动化验证的评估体系，而非靠肉眼判断
- 状态管理：跨会话持久化上下文，管理长期运行的心智状态
- 成本控制：理解 token 消耗模型，在质量与成本间做权衡
- 护栏设计：设置安全边界，防止 Agent 失控
七、当前解决什么问题
Loop Engineering 解决的核心矛盾是：
人类注意力有限，AI 执行能力无限 ------ 人无法一直坐在终端前按回车。
具体场景：
| 场景 | Prompt 时代 | Loop 时代 |
|---|---|---|
| 代码迁移 | 人逐文件写 prompt | Agent 自动遍历全部文件 |
| Bug 修复循环 | 人提 bug → 改 → 提交 → 等 CI → 再改 | Loop 自动修复 → 验证 → 重试 |
| 夜间批处理 | 人熬夜盯着 | 提交数百个任务并行执行，明早看结果 |
| 持续重构 | 人手动规划每一步 | 系统自动拆解任务，持续执行 |
Boris Cherny 提到，他现在每晚提交 数千个 AI Agent 并行运行，次日早上查看结果。
八、争议与局限
质疑声
- Token 消耗：一次 Loop 1 分钟执行一次 × 8 小时 = 480 次 API 调用。批评者指出两位倡导者都有"无限预算"
- 调试困难："调试跑了 47 轮的状态机，比修好一个 prompt 难 10 倍"
- 新瓶装旧酒：本质就是 ReAct 范式（2022 年已有论文），或 CI/CD 的 AI 翻版
- Concept Fatigue：Vibe Coding → ReAct → Harness → Loop，一年内多个新词
- 门槛高："20 美元的套餐根本不可能"
建设性提醒（Addy Osmani）
- 理解债（Comprehension Debt） ：Agent 产生大量代码，人越来越不读，团队对系统的理解逐渐下降
- 认知投降（Cognitive Surrender） ：Loop 越顺畅，人越容易停止思考
Loop 适合的四个条件：任务高重复性 + 验证已自动化 + 有 Token 预算 + Agent 有完整权限。
九、总结
从 Prompt Engineering 到 Loop Engineering，本质是 人在工作流中的位置不断后撤：
- Prompt Engineering：人亲自发问，控制每一次交互
- Context Engineering：人管理信息边界，Agent 在边界内自主发挥
- Harness Engineering：人设安全护栏，Agent 在护栏内跑长程任务
- Loop Engineering：人设计运转系统，系统决定何时启动 Agent
每一次抽象层级提升，人的决策权上移了一层，但设计难度和系统后果也上升了一档。
正如一位知乎答主所言：
"Context Engineering 让你从在 Prompt 里写细节升级到设计信息边界；Harness Engineering 让你从设计信息边界升级到设计任务安全护栏；Loop Engineering 让你从设计单次任务的护栏升级到设计一项持续职能的运转方式。"
人类工程师的核心价值正从 "写代码/写提示词" 转向 "设计能够持续产出代码的系统" 。
Sources: