Loop Engineering：别再写 Prompt 了，去设计 Loop
一条推文引来了 700 万人围观。开源大佬说：别再给 AI 写提示词，你应该去设计 Loop。Claude Code 的作者也说：我也不写 Prompt，我写 Loop。
2025-2026 年，Loop Engineering 正在取代 Prompt Engineering，成为 AI 时代的核心工程能力。
一、从 Prompt 到 Loop，范式变了
过去我们和 AI 协作的方式是做填空题——写好一段精美的 prompt，喂给模型，等结果。不满意？改 prompt，再来一遍。人在整个过程中不能离开，盯着 AI 干活。
Prompt Engineering 的本质是"一句话问对"的对话技巧。
Loop Engineering 把这件事反转了：你不再是那个反复改 prompt 的人，而是设计一套规则和检查机制，让 AI 自己跑循环。
Loop Engineering 的本质是"设计一套 AI 能自己跑的流程"的系统工程。
怎么理解这个反转？一句话：
Loop Engineering 出现后，你的位置变了。以前你在 Loop 里面，现在你在 Loop 外面。
| 维度 | Prompt Engineering | Loop Engineering |
|---|---|---|
| 你的角色 | 全程盯着，手动迭代 | 设定规则和退出条件，抽身离开 |
| AI 行为 | 一次生成，品质随缘 | 多轮执行，自我修正 |
| 适用场景 | 简单问答、翻译、摘要 | 复杂任务、代码生成、自动化 |
| 可靠性 | 依赖 prompt 质量，不稳定 | 有检查机制兜底，产出可控 |
| 本质 | 对话技巧 | 系统工程 |
二、Loop 的底层逻辑：三要素
Loop 是计算机最底层的能力之一。任何循环都只包含三件事：
1. 从哪里开始（Entry Condition）
一个 Agent Loop 启动时，需要三样东西：
- 任务描述 — 用户到底想要什么
- System Prompt — Agent 的角色和边界
- 能力声明 — Agent 手上有什么工具、能访问什么数据
2. 重复做什么（Loop Body）
这是 Loop 的核心——每一轮都在干同一件事：
LLM 推理 → 调用工具 → 拿到结果 → 把结果喂给 LLM → 继续推理 → ...
用代码表示就是 completion → tool_call → observation → completion → … 的无限循环，直到退出条件触发。
每一轮的 observation（工具返回的结果）都会追加到 messages 数组里。LLM 每一轮都能看到完整的历史上下文，所以它的推理会越来越准确——这就是 Learn（学习） 环节。
3. 什么时候结束（Exit Condition）
退出条件是 Loop Engineering 最容易被忽视、也最容易出问题的地方。五种常见的退出条件：
| 退出条件 | 说明 |
|---|---|
| 目标达成 | LLM 判断任务完成，不再调 tool，直接返回最终结果 |
| 最大轮次 | maxRounds 兜底，防止死循环 |
| 超时 | 超过时间限制自动终止 |
| 人工介入 | 遇到关键决策/危险操作暂停，等人确认 |
| 错误退出 | tool 连续失败 N 次，判定无法继续 |
三、一个最简 Loop Agent 的完整解剖
理论知识讲完了，我们来看一个最简 Loop Agent 的代码，把它拆开来看：
3.1 Agent 的大脑：LLM
const client = new OpenAI({
apiKey: process.env.DEEPSEEK_API_KEY,
baseURL: process.env.DEEPSEEK_API_BASE_URL
})
LLM 只负责推理和生成。没有 tool，它就是一个只会聊天的脑子，无法和外部世界交互。
3.2 Agent 的手脚：Tool
Tool 是 Agent 行动能力的来源。LLM 推理出"我需要调哪个工具、传什么参数"，工具执行，结果返回给 LLM。
经典例子：
用户问"青岛啤酒股价多少？"→ LLM 推理需要调用
getPrice函数 → tool 返回67.92→ LLM 知道怎么回答了。
Tool 的难点不是实现，而是 description 写得好不好——LLM 能不能准确理解这个工具是干什么的、什么时候该用，全靠 description。
3.3 刹车系统：Limit 限制
const limit = {
maxRounds: 5, // 最多 5 轮
maxTokens: 2000, // 最多消耗 2000 token
sameStop: 2 // 连续 2 次输出相同就停
}
这三个限制对应了三种常见的跑偏场景：死循环、狂烧 token、原地踏步。三者共同构成兜底刹车——即使 Agent 没有达成目标，也不会让它无限跑下去。
3.4 工作循环：gen → check
这是整个 Loop 最核心的部分：
while (!needStop()) {
round++
const { text, tokens } = await gen() // 干活
totalTokens += tokens
sameCount = text === lastText ? sameCount + 1 : 0
lastText = text
const { pass, failReason } = await check(text) // 检查
if (pass) {
console.log('成功', text)
break // 通过 → 退出
} else {
console.log('不合格', failReason) // 不通过 → 下一轮
}
}
gen() 负责生成，check() 负责审查。两个函数调用的是同一个 LLM，但给了完全不同的 system prompt——gen 是创作者，check 是审查者。角色分离是自检查机制能跑稳的关键。
四、检查机制：Loop 的核心工程问题
LLM 生成的东西不一定对。每一轮循环都必须回答一个问题：这轮产出合格了吗？
4.1 五种检查方式，由轻到重
第一层：规则校验（0 token，最轻）
不用 LLM，直接用代码校验格式。比如要求"标题带数字""字数 200 内"，根本不需要 LLM，正则就够了：
function check(text) {
const pass = /\d/.test(text) && text.length <= 200
return { pass, failReason: pass ? '' : '标题没数字或超字数' }
}
适用场景：格式约束、字数、必填字段、JSON Schema 校验。
第二层：LLM 自检（低 token）
这也是上面例子在做的事——用一个独立的 check prompt，让 LLM 以审查者身份审查 LLM 以创作者身份生成的输出。
关键设计点：
- gen 和 check 用不同的 system prompt，角色不同
- check 的输出要结构化（JSON），
{ pass: true/false, failReason: '...' } failReason必须具体，能指导下一轮 gen 修正方向
第三层：执行验证（最可靠）
代码生成后直接跑——能跑就是能跑，报错就是报错，不依赖 LLM 判断：
写代码 → 跑测试/lint/编译 → 报错 → 把报错喂给 LLM → 修 → 再跑
Claude Code、Cursor 的底层逻辑就是这个——测试就是检查机制。
第四层：多维检查
一个 checker 不够，多个 checker 从不同角度审：
生成 → 格式检查 → 安全检查 → 业务规则检查 → 语义检查 → 任一不通过就退回
第五层：人在回路
关键操作暂停，等人来 check。涉及部署、删数据、付款等操作时的最后防线。
4.2 怎么选：一张表
| 检查方式 | Token 成本 | 可靠性 | 适用 |
|---|---|---|---|
| 规则校验 | 0 | 确定性问题 100% | 格式/字数/结构 |
| LLM 自检 | 低 | 依赖 prompt 质量 | 语义/文案/摘要 |
| 执行验证 | 0 | 能跑就是能跑 | 代码/SQL/脚本 |
| 多维检查 | 中-高 | 高 | 生产级任务 |
| 人工确认 | 人的时间 | 最高 | 部署/删数据/付款 |
五、Agent Loop 的五环架构
回到理论层，任何 Agent Loop 都可以拆成五个环节：
┌─────────────────────────────────────────┐
│ Agent Loop │
│ │
│ ① Plan ──→ ② Act ──→ ③ Observe │
│ ↑ │ │
│ └──── ⑤ Learn ←─────────┘ │
│ ↓ │
│ ④ Check │
│ (通过则退出) │
└─────────────────────────────────────────┘
- Plan — LLM 推理：下一步干什么、调什么工具、传什么参数
- Act — 执行工具（读文件、搜网络、写代码、操作浏览器…）
- Observe — 收集工具返回的结果、错误信息
- Check — 结果合格了吗？不合格回到 Plan，合格退出
- Learn — 本轮经验追加到 messages，下一轮推理更准确
六、Loop Engineering 的设计原则
五条实战经验：
1. 明确的退出条件。 死循环是 Loop 最常见的故障。要同时设目标条件（任务完成）和兜底条件（maxRounds / timeout / sameStop）。
2. 上下文管理。 每轮的结果都追加到 messages，长任务会爆 context window。需要摘要压缩、滑动窗口、关键信息提取。
3. 错误处理 ≠ 退出。 Tool 调用失败一次不应该终止整个 Loop。把错误信息喂给 LLM，让它换一种方式重试。
4. 可观测性。 每轮记录：turn 数、LLM 推理、调了哪个 tool、tool 返回了什么。出问题时才能回溯。
5. 渐进式交付。 不要等 Loop 全跑完才给结果。流式输出中间状态，让用户看得见 Agent 在干什么。
七、训练 Loop 与推理 Loop
训练 LLM 的过程本身也是一个 Loop，和 Agent Loop 是同一枚硬币的两面：
| 维度 | 训练 Loop | 推理 Loop（Agent Loop） |
|---|---|---|
| 做什么 | 训练模型参数 | 执行具体任务 |
| 循环内容 | 前向传播 → 算 loss → 反向传播 → 更新参数 | Plan → Act → Observe → Check |
| 终止条件 | loss 收敛 / 达到 epoch | 任务完成 / 达到 maxRounds |
| 产物 | 模型权重 | 任务结果 |
| 跑在哪 | PyTorch / JAX | 你写的 Runtime |
这也解释了为什么 Loop 是 AI 最底层的能力——没有万亿次训练 Loop，就没有 LLM；没有推理 Loop，LLM 就无法自主完成复杂任务。
八、写在最后
2025-2026 年，所有主流 AI 产品底层都是 Agent Loop：
- Claude Code — Plan → Read/Write/Bash → Observe → Check → 继续或完成
- Cursor — 理解意图 → 搜索代码 → 生成 diff → 人确认 → 应用
- OpenAI Codex CLI — 同样的 Loop 模式，换了大脑和工具集
- Devin — 全自动 Loop，关键节点人介入
Loop 已经从"AI 的一种用法"变成了"AI 产品的标准架构"。
你的位置变了。以前你在 Loop 里面，一遍遍改 prompt——现在你站在 Loop 外面，设计规则、定义检查、设好刹车，然后让 Agent 自己跑。
这就是 Loop Engineering。
