## Loop Engineering 学习指南：从 Prompt 到自主循环的范式转移

**"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."**
— Peter Steinberger, OpenClaw 创始人[2]

**"I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops."**
— Boris Cherny, Anthropic Claude Code 负责人[3]

---

## 摘要

**关键词**：Loop Engineering, Prompt Engineering, Agent 设计, Claude Code, OpenAI Codex, 评估机制

Loop Engineering 的核心转变是把"你写 prompt 让 AI 执行"改成"你设计一个系统，让系统持续 prompt AI"。本文梳理这个范式的七个关键组件、常见误区，以及它在工具层面的真实落地状态。

---

## 一、什么是 Loop Engineering？

**Loop Engineering** 是 2026 年在 AI coding agent 社区受到关注的概念，Addy Osmani 在 2026 年 6 月的文章中系统命名和整理，Anthropic Claude Code 负责人 Boris Cherny 和 OpenClaw 创始人 Peter Steinberger 共同推动。

> 需要先说明：**"Loop Engineering"目前更多是社区术语，而非已稳定成型的工程学科。** 它所描述的能力——持续运行、自我评估、记忆管理——本质上是 agent orchestration、workflow automation、eval-driven development 和 stateful automation 的组合。把它理解为"如何设计长期运行的 AI 系统"更准确，而不是一个已经有标准答案的新领域。

### 核心定义

**一句话定义**（Addy Osmani）[1]：

> Loop Engineering 就是把「负责提示 AI 的你」这个角色，换成一套替你做这件事的 **系统**。

### 四个 Engineering 的递进关系

```
Prompt Engineering  →  "怎么说"（写好一句话）
Context Engineering  →  "给什么"（给模型什么信息）
Harness Engineering   →  "在哪里安全运行"（组织 AI 能力的工厂模型）
Loop Engineering      →  "做完成"（让 AI 持续创造结果）
```

**但这不是严格的线性演进**。真实工程实践中，这些能力是并行发展的——2023 年已有 agent 框架在做 context management，2025 年的 harness 设计也包含 loop 意识。理解为一个技能栈的逐层积累会更准确。

> **重要澄清**：Prompt Engineering 没有消亡。Loop 是由多个 Prompt 组成的，写得差的 Prompt 放进 Loop 里只会让糟糕的工作以更快的速度产出。Loop Engineering 是在 Prompt Engineering **之上**的层次，而不是替代它。

---

## 二、为什么只做 Prompt Engineering 不够了？

### IEEE Spectrum 的研究结论

2024 年 3 月 6 日，**IEEE Spectrum** 在线发表封面文章《AI Prompt Engineering Is Dead》，刊于 2024 年 5 月纸刊[4]。

**VMware 研究**（Rick Battle & Teja Gollapudi）：
- 测试了 60 种 prompt 组合，涵盖 3 个开源 LLM，专注于小学数学题
- **人类试错式 prompt engineering 没有一致性能趋势**：甚至连思维链（chain-of-thought）prompting 有时改善结果，有时反而伤害性能
- **唯一真正的趋势可能是"没有趋势"**：对任何给定的模型、数据集和 prompting 策略，最优解很可能就是针对那个特定组合的

**关键结论**：
- AI 自动优化 prompt 在几乎所有测试案例中 outperformed 人类找到的最优 prompt
- 优化时间：2 小时（AI）vs 数天（人工）
- AI 生成的最优 prompt 往往 **bizarre 且反直觉**（比如一个有效的 prompt 是星际迷航的 Captain Kirk 角色扮演）

**Intel Labs 的图像生成研究**（NeuroPrompts）：
- 自动生成的 prompt **同样 outperformed 人类专家 prompt**
- 研究负责人 Vasudev Lal 说："这更像是 LLM 和扩散模型的一个 bug，而不是 feature——你根本不需要做这些专家级的 prompt engineering"

### 从"优化 Prompt"到"设计系统"

IEEE 的研究并不意味着 prompt 本身没用，而是揭示了：

> **"no human should manually optimize prompts ever again"** — 别再手动调 prompt 了，定个评分指标让系统自己优化。[来源：IEEE Spectrum]

这类研究不能直接证明 Loop Engineering 更优，但说明"手工试错调 prompt"的可迁移性有限，支持把优化过程系统化、评估化、自动化。

这意味着：
- **2023 年的技能**：找到那个解锁 MMLU 额外 4 分的 phrase → **边际价值已大幅下降**
- **2026 年的技能**：设计可测试、可版本化、可调试的系统 → **正在兴起**

---

## 三、Loop Engineering 的七个关键组件

一个面向生产使用的 Loop，不只是让 agent 反复运行，而是要把触发、上下文、行动、评估、记忆、停止条件和人工检查点设计清楚。下面的七组件不是 Addy Osmani 原文的逐字框架，而是本文结合 Addy Osmani 的 Loop Engineering 原文、Claude/Codex 工具实践和社区讨论整理出的工程检查表。

> **关于学术引用的说明**：以下每个要素后都列出了相关的学术论文（ReAct[5]、Reflexion[6]、Self-Refine[7]等）。这些论文提出了与 Loop 要素有概念可比性的机制，但**论文本身并非为 Loop Engineering 而写**，不能直接证明"七大核心要素缺一不可"。本文用"可类比到"而非"学术验证"来表述这个关联，读者应理解这里的推断边界。

### 1. Trigger（触发器）

**作用**：什么事件会启动循环？

**类型**：
- **定时任务**：每天早上检查 GitHub issue
- **外部事件**：CI 失败、客户提交工单、竞品发布新版本
- **用户行为**：上传文档、修改需求、提出长期目标

**没有 Trigger 的后果**：agent 只是被动等待，没有"心跳"。

---

### 2. Context（上下文）

**作用**：每次循环开始时，系统应该给 agent 什么信息？

**关键原则**：不是把所有东西都塞进去，而是 **区分管理**。

**应该区分的上下文类型**：
- 项目规则 & 历史决策
- 当前状态 & 任务进度
- 用户偏好 & 限制条件
- 工具说明 & 失败记录

**反面模式**：一个巨大的 prompt 混在一起 → 上下文污染，效果递减。

---

### 3. Action（行动）

**作用**：agent 能做什么？

**范围**：从只生成文本，到调用工具（搜索、编辑代码、运行测试、查询数据库、创建工单、发送草稿、更新文档）。

**关键权衡**：工具越多，能力越强，但 **权限风险也越大**。Loop 不是简单自动化，而是需要边界设计的系统。

---

### 4. Evaluation（评估）

**作用**：谁来判断结果是否合格？

**这是最容易被低估，却最关键的要素**。

**为什么不能只依赖模型自评？**

> 一个 loop 最危险的地方，不是 agent 做不出来，而是它做错了，还不断说自己完成了。[来源：小黑盒][8]

**成熟的评估机制**：
- 单元测试、linter、构建结果（代码场景）
- 事实核查、风格检查、引用检查（内容场景）
- 用户满意度、工单关闭率、升级比例（客服场景）
- 另一个 evaluator agent（公开资料称 Claude Code `/goal` 默认使用 Haiku 或 small fast model 作为 evaluator；具体实现可能随版本变化）

---

### 5. Memory（记忆）

**作用**：什么结果应该写入长期状态？

**记忆选择原则**：不是所有过程都该被记住，真正值得记住的是：
- 决策 & 偏好
- 约束 & 限制
- 失败原因 & 成功经验
- 当前进度

**Memory 的风险**：如果 AI 把错误信息写入长期记忆，未来每次都调用，这个错误就会变成 **系统级偏差**。一次幻觉只是一次回答错误；一旦幻觉被写入 memory，就可能在未来反复出现。

**研究证据**：
- **FORGE**（2026）[arXiv:2605.16233]：提出**基于人群的记忆演化**机制，防止记忆退化和混淆
- **TrustMem**[15]（2026）：专门解决记忆更新可能引入幻觉或腐败内容的问题

---

### 6. Stop Condition（停止条件）

**作用**：什么时候停止？

**常见停止条件**：
- 所有测试通过就停止
- 连续两次修复失败就停止并请求人工介入
- 结果置信度低于阈值就停止
- 涉及付款、删除、发布、上线等高风险动作就停止等待确认

**没有停止条件的后果**：

> Agent 会变成失控脚本，不断修复、不断提交、不断解释，最后把一个小问题变成一堆新问题。[来源：小黑盒][9]

---

### 7. Human Checkpoint（人工检查点）

**作用**：哪些节点需要人类确认、抽查或审计？

**这不是保守，而是必要的系统设计**。

**典型检查点**：
- Agent 可以写 PR，但不一定应该自动 merge
- Agent 可以草拟邮件，但不一定应该自动发送
- Agent 可以分析账单，但不应该随便自动付款

> Loop Engineering 的价值，不是让人彻底退出系统，而是把人放到更关键的判断位置。[来源：小黑盒][9]

---

## 四、工具层面的真实状态

**先说一个事实核查结果**：Codex 相关文档路径在 2026 年仍处于快速变化中。本文核查时，OpenAI Developers 站点已有 Codex Automations、Skills、Subagents 等页面；但具体功能是否对所有账号开放，仍可能受产品版本、权限和地区影响。因此，下面的映射应被理解为"当前公开资料下的能力对照"，不是稳定 API 契约。

| **Loop 原语** | **在 Loop 中的角色** | **OpenAI Codex** | **Claude Code** |
|--------------|--------------------|-----------------|----------------|
| **Automations** | 循环的心跳（定时发现 + 分诊） | 官方文档已有 Codex app Automations 页面，用于排程 recurring Codex tasks；具体可用性可能受账号、地区和产品版本影响 | `/loop`（按间隔定时重跑）、`/goal`（运行至 evaluator 确认满足条件）、cron 任务、Git hooks、GitHub Actions |
| **Worktrees** | 并行隔离（避免文件冲突） | Codex 文档提到 subagents 与并行任务能力；具体 worktree 行为以官方文档和产品界面为准 | 可通过 `git worktree` 或运行标志实现并行隔离；具体隔离模式以当前文档为准 |
| **Skills** | 项目知识编码（避免重复解释） | Agent Skills（`SKILL.md`），用 `$name` 或隐式调用 | Agent Skills（`SKILL.md`） |
| **Plugins / Connectors** | 连接真实工具 | Connectors (MCP) + plugins | MCP servers + plugins |
| **Sub-agents** | 并行 ideate + verify | 可通过 Codex 的 subagents 配置定义专门 agent；具体文件路径和 schema 以官方文档为准 | 可通过 Claude Code 的 subagent/agent 配置或外部脚本组合实现；具体能力以当前文档为准 |
| **State** | 跟踪完成状态 | Markdown 或 Linear（通过 connector） | Markdown（`AGENTS.md`、progress files）或 Linear（通过 MCP） |

### Claude Code 的 `/goal` 命令详解

**工作原理**：
1. 你定义一个完成条件：`/goal all tests in test/auth pass and lint is clean`
2. Claude 每轮执行后，一个 **独立的 evaluator model**（默认 Haiku，不是写代码的那个模型）会检查对话记录，评估条件是否满足
3. 如果没满足，Claude 继续修改代码、运行测试、阅读失败信息、修复、重跑
4. 循环直到 evaluator 确认条件满足

**与 `/loop` 的区别**：

| 命令 | 停止条件 | 适用场景 |
|------|---------|---------|
| `/loop` | 时间间隔 elapsed | 定期检查、监控任务 |
| `/goal` | 条件被 evaluator 确认满足 | "run-until-done" 类型任务 |
| Stop hook | 自定义脚本或 prompt 决定 | 复杂自定义逻辑 |

**可类比到**：`/goal` 的 evaluator 机制直接对应 Reflexion[6]的 **Evaluator Model (M_e)** 角色。

---

## 五、四大典型 Loop 模式

### 1. 轮询循环（Polling Loops）

**机制**：按时间（如每 30 分钟）唤醒，检查数据源，只有发现新数据时才触发行动。

**适合**：监控、数据同步、定期检查任务。

---

### 2. 精炼循环（Refinement Loops）

**机制**：agent 生成内容，根据品质标准自行评分，未达标就重写，直到过关或达到最大尝试次数。

**适合**：内容生成与优化、文案打磨。

**学术参考**：Self-Refine[7]提出了类似的迭代精炼框架。

---

### 3. 队列处理循环（Processing Queue Loops）

**机制**：agent 面对一个任务清单，一件接一件处理、记录结果，直到清空为止。

**适合**：批量处理、工单消化、数据录入。

---

### 4. 事件响应循环（Event-Response Loops）

**机制**：agent 持续监听外部信号（如电子邮件、Webhook），一旦有事件进来就立即执行回应程序，随后回到监听状态。

**适合**：实时响应系统、告警处理、Webhook 驱动工作流。

**学术参考**：AgentEval（arXiv:2604.23581）的 DAG 结构——事件触发有向无环图中的节点执行。

---

## 六、实践案例：构建你的第一个 Loop

### 场景：每日 GitHub Issue 自动分诊

**目标**：每天早上 9 点自动检查 GitHub 仓库的新 issue，按标签分类，并创建对应的 Linear ticket。

#### Step 1: 定义 Trigger
- **类型**：定时任务（每天 9:00 AM）
- **实现**：Claude Code 用 `/loop` 或 cron，Codex 用 Automations tab

#### Step 2: 准备 Context
```
<!-- .claude/context/github-context.md 或 AGENTS.md -->
## 项目信息
- 仓库：ephron_ren/ephron.ren
- 技术栈：Next.js, TypeScript, Tailwind CSS
- 代码规范：见 .cursorrules

## Issue 分类规则
- **bug**：需要修复的错误
- **enhancement**：功能增强建议
- **documentation**：文档相关
- **question**：用户疑问
- **priority: high**：影响核心功能

## Linear 项目映射
- ephron.ren 开发：ENG-123
- 文档更新：DOC-456
```

#### Step 3: 定义 Action
```
<!-- 在 loop prompt 中 -->
1. 使用 `gh issue list --state open --json number,title,body,labels` 获取新 issue
2. 读取 github-context.md 中的分类规则
3. 对每个新 issue 进行分类：
   - 如果符合 bug 特征，打 `bug` 标签并创建 Linear ticket 到 ENG-123
   - 如果符合 enhancement 特征，打 `enhancement` 标签并创建 Linear ticket 到 ENG-123
   - 如果是文档问题，打 `documentation` 标签并创建 Linear ticket 到 DOC-456
4. 在 GitHub issue 评论中标注已创建 Linear ticket 的链接
```

#### Step 4: 设置 Evaluation

**自动检查**（在 loop 结束后运行）：

```bash
# 检查所有新创建的 Linear ticket 是否符合格式
npx linear-cli list-tickets --project ENG-123 --status "Unstarted" | grep -E "\[BUG\]|\[ENH\]"
# 检查 GitHub issue 评论是否包含 Linear 链接
gh issue view <number> --json comments | grep -q "linear.app"
```

**人工检查点**：
- 每周一查看上周的自动分诊结果
- 调整分类规则或 Linear 项目映射

#### Step 5: 配置 Memory
```
<!-- progress.md 或 AGENTS.md 中维护 -->
## 上次运行状态
- 时间：2026-06-26 09:00
- 处理 issue 数：12
- 创建 Linear ticket：8
- 分类准确率：92%（人工抽查 25 个，错误 2 个）

## 已知问题
- 包含 "help" 关键词的 issue 常被误判为 question，需优先检查
- React 相关 bug 的 severity 评估不准，需参考 issue 中的复现步骤
```

**Memory 架构选择**：
- **简单场景**：Markdown 文件（如 `progress.md`）
- **中等复杂度**：Infini Memory[14]的 Topic Documents 结构
- **高复杂度**：MemForest 或向量数据库 + 知识图谱

#### Step 6: 定义 Stop Condition
```
停止条件：
1. 成功：所有 open issue 都已处理（分类 + Linear ticket 创建 + 评论）
2. 失败：连续 3 个 issue 创建 Linear ticket 失败（API 配额用尽）
3. 需要人工介入：出现 priority: high 标签的 issue 且置信度 < 0.8
```

#### Step 7: 设置 Human Checkpoint
- **必须人工确认**：任何涉及 `priority: high` 的 issue 分类结果
- **定期审查**：每周一审查上周的自动分诊准确率，调整规则

---

### 完整 Loop 配置示例（Claude Code）

> ⚠️ **命令示例说明**：本文中的 CLI 命令示例仅供参考，实际使用时请以[官方文档](https://code.claude.com/docs/en/goal)[10]为准。命令语法可能随版本变化，建议先查阅最新文档。

```bash
# 方式 1：在 Claude Code 会话内使用 /loop 命令（推荐）
# 进入 Claude Code 后，输入：
/loop 1d "
你是一个 GitHub issue 自动分诊 agent。请按照以下步骤执行：

1. 读取 .claude/context/github-context.md 获取分类规则
2. 运行 gh issue list --state open --json number,title,body,labels
3. 对每个 issue 进行分类并创建 Linear ticket
4. 在 issue 评论中标注 Linear ticket 链接
5. 更新 .claude/context/progress.md 中的运行状态
6. 检查停止条件：所有 issue 处理完毕 / API 失败 / 需要人工介入

停止条件：
- 成功：所有 open issue 都已处理
- 失败：连续 3 次 Linear API 调用失败
- 人工介入：priority: high 且置信度 < 0.8

完成后，生成一份简报发送到 #ephron-dev Slack 频道。
"

# 方式 2：通过 CLI 非交互式运行（适用于 cron 等排程）
# 注意：-p 参数的行为请以官方文档为准
# 参考：https://code.claude.com/docs/en/scheduled-tasks
```

### 代码示例：Evaluator 逻辑（Python）

```python
def evaluate_issue_triage(new_issues: list, linear_tickets: list) -> dict:
    """评估 issue 分诊质量"""
    result = {
        "total_issues": len(new_issues),
        "tickets_created": len(linear_tickets),
        "missing_tickets": [],
        "accuracy_score": 0.0,
        "needs_human_review": []
    }

    for issue in new_issues:
        has_ticket = any(t["issue_number"] == issue["number"] for t in linear_tickets)
        if not has_ticket:
            result["missing_tickets"].append(issue["number"])

        # 检查高优先级 issue 是否有人工审查记录
        if "priority: high" in issue.get("labels", []):
            if not issue.get("human_reviewed"):
                result["needs_human_review"].append(issue["number"])

    # 计算准确率（这里简化，实际应对比人工标注）
    result["accuracy_score"] = 1.0 - len(result["missing_tickets"]) / max(len(new_issues), 1)

    return result

# 使用示例
evaluation = evaluate_issue_triage(new_issues, created_tickets)
if evaluation["accuracy_score"] < 0.9:
    print(f"⚠️ 准确率 {evaluation['accuracy_score']:.2%}，需要调整规则")
if evaluation["needs_human_review"]:
    print(f"🔴 需要人工审查的 issue：{evaluation['needs_human_review']}")
```

---

## 七、风险与边界：Loop 不是万能银弹

### 1. 错误放大效应

**问题**：一次错误回答只影响一次对话；但如果错误进入循环，它可能被下一轮继续引用、强化、写入状态，最后变成系统默认判断。

**对策**：
- 必须设置可靠的评估机制，不能只依赖模型自评
- 定期审计 Memory 中的信息，及时修正错误
- 设置"连续失败 N 次则停止"的熔断机制

---

### 2. 记忆隐私问题

**问题**：用户不一定希望所有历史都被整理、保存和调用。

**Memory 透明度三要素**：
- 用户必须知道系统 **记住了什么**
- 为什么记住
- 什么时候会用、能不能修改、能不能删除、能不能关闭

**否则**：所谓"个性化"就可能变成另一种不透明。

---

### 3. 过期信息伪装成个性化

**问题**：AI 记得用户过去的偏好，并不等于这个偏好今天仍然成立；AI 记得用户过去的计划，也不等于这个计划还在进行。

**对策**：
- Memory 必须处理时间戳和状态标记
- 区分"进行中"、"已完成"、"已取消"的计划
- 定期回顾 Memory，清理过期信息

---

### 4. 自动化权限边界

**原则**：
- Agent 可以写代码 → 不一定应该自动 merge
- Agent 可以分析合同 → 不一定可以自动签署
- Agent 可以草拟回复 → 不一定可以自动发送
- Agent 可以整理财务信息 → 不一定可以自动转账

**必须有的权限分层**：
1. 哪些动作可以 **自动执行**
2. 哪些动作需要 **确认**
3. 哪些动作 **绝对禁止**
4. 哪些动作必须留下 **审计记录**

---

### 5. 持续运行系统的审计与回滚

**问题**：一个聊天机器人答错了，用户关窗口就行；但一个持续运行的 agent，如果改了文件、调用了 API、更新了数据库、影响了业务流程，就必须留下记录。

**必须追踪的问题**：
- 谁触发了它？
- 它看到了什么上下文？
- 调用了什么工具？
- 为什么做这个决策？
- 改了哪些状态？
- 能不能撤回？

**结论**：这些问题听起来不像 AI 论文里的问题，但它们会决定 AI 产品能不能真正进入企业和个人的长期工作流。

---

### 6. 成本不可预测

**问题**：Loop 一旦跑起来，调用 LLM 的次数是 N 轮 × 每轮工具数。一开始跑得好好的，某个任务突然卡住，转了 50 轮还没结束——账单可能翻几倍。

**必须设置的预算控制**：
- **单次任务预算上限**：超过 X 次 LLM 调用或 $Y 成本就停止
- **日/周预算**：防止异常循环无限烧钱
- **分级熔断**：
  - 黄色：达到预算 80% 时警告并记录
  - 红色：达到预算 100% 时强制停止

**成本控制的落地方法**：

```python
class BudgetTracker:
    def __init__(self, daily_budget: float):
        self.daily_budget = daily_budget
        self.spent = 0.0
        self.llm_calls = 0

    def record_call(self, cost: float):
        self.spent += cost
        self.llm_calls += 1

        if self.spent > self.daily_budget * 0.8:
            print(f"⚠️ 预算使用率 {self.spent/self.daily_budget:.1%}，考虑暂停")

        if self.spent >= self.daily_budget:
            raise RuntimeError(f"💰 日预算 {self.daily_budget} 元已耗尽，停止运行")
```

---

### 7. 不是所有任务都适合 Loop

**适合 Loop 的场景**：
- 需要持续监控的任务（价格跟踪、错误检测）
- 大量重复性文档处理
- 需要多步骤研究的分析任务
- 流水线式内容生成与优化
- 高频、重复、可验证、状态持续变化的任务

**不适合 Loop 的场景**：
- 一次性、创意主导的工作（写诗、写小说）
- 需要强人类判断的伦理决策
- 实时响应更适合**事件驱动 loop**，而不是轮询 loop
- 探索性、方向不明的研究
- 简单问答、小范围创意

---

## 八、学习资源与路径

### 学术论文（按重要性排序）

| 论文 | arXiv | 年份 | 核心贡献 | 重要性 |
|------|-------|------|---------|--------|
| **ReAct** | [2210.03629](https://arxiv.org/abs/2210.03629) | 2023 | 推理与行动交替循环 | ⭐⭐⭐⭐⭐ |
| **Reflexion** | [2303.11366](https://arxiv.org/abs/2303.11366) | 2023 | 语言反馈的强化学习 | ⭐⭐⭐⭐⭐ |
| **Self-Refine** | [2303.17651](https://arxiv.org/abs/2303.17651) | 2023 | 迭代精炼与自我反馈 | ⭐⭐⭐⭐ |
| **AgentEval** | [2604.23581](https://arxiv.org/abs/2604.23581) | 2026 | DAG 步级评估 | ⭐⭐⭐⭐ |
| **Infini Memory** | [2606.10677](https://arxiv.org/abs/2606.10677) | 2026 | 主题文档记忆结构 | ⭐⭐⭐⭐ |
| **Agentic Memory** | [2601.01885](https://arxiv.org/abs/2601.01885) | 2026 | 统一长短期记忆管理 | ⭐⭐⭐⭐ |
| **Verifiability-First** | [2512.17259](https://arxiv.org/abs/2512.17259) | 2025 | 可验证性优先架构 | ⭐⭐⭐⭐ |
| **FORGE** | [2605.16233](https://arxiv.org/abs/2605.16233) | 2026 | 自演化记忆（无权重更新） | ⭐⭐⭐⭐ |
| **TrustMem** | [2606.25161](https://arxiv.org/abs/2606.25161) | 2026 | 可信记忆整合 | ⭐⭐⭐⭐ |
| **Gödel Agent** | [2410.04444](https://arxiv.org/abs/2410.04444) | 2024 | 递归自我改进框架 | ⭐⭐⭐ |

### 官方文档

| 资源 | 链接 |
|------|------|
| Addy Osmani 原文 | https://addyosmani.com/blog/loop-engineering |
| Claude Code `/goal` 文档 | https://code.claude.com/docs/en/goal |
| OpenAI Codex Subagents [11] | <https://developers.openai.com/codex/subagents> |
| OpenAI Codex Skills [12] | <https://developers.openai.com/codex/skills> |
### 开源项目（Stars 数来自 2026 年 6 月）

#### 🔄 Loop 工程

| 项目 | Stars | 说明 |
|------|-------|------|
| [LangChain](https://github.com/langchain-ai/langchain) | 140k | 最成熟的 LLM 应用框架，支持 ReAct 循环 |
| [CrewAI](https://github.com/crewAIInc/crewAI) | 54k | 多 agent 协作框架，角色定义清晰 |
| [ReAct 论文](https://arxiv.org/abs/2210.03629) | - | 提出 Reasoning + Acting 交替范式 |

#### 🧩 Pipeline 工程

| 项目 | Stars | 说明 |
|------|-------|------|
| [Sim Studio](https://github.com/simstudioai/sim) | 29k | 可视化拖拽构建 AI 工作流 |
| [Haystack](https://github.com/deepset-ai/haystack) | 26k | NLP 框架，支持复杂 pipeline |
| [Pipelex](https://github.com/Pipelex/pipelex) | 683 | "AI reasoning 的 Dockerfile" |

#### 🛠 Tool 工程

| 项目 | Stars | 说明 |
|------|-------|------|
| [MCP for Beginners](https://github.com/microsoft/mcp-for-beginners) | 17k | Microsoft 官方 MCP 入门 |
| [MCP Agent](https://github.com/lastmile-ai/mcp-agent) | 8.4k | MCP 集成示例 |

#### 📊 Eval 工程

| 项目 | Stars | 说明 |
|------|-------|------|
| [OpenLIT](https://github.com/openlit/openlit) | 2.6k | LLM 应用可观测性与评估 |
| [Relai-SDK](https://github.com/relai-ai/relai-sdk) | - | simulate → evaluate → optimize 流程 |

#### 🛡 Safety 工程

| 项目 | Stars | 说明 |
|------|-------|------|
| [NeMo Guardrails](https://github.com/NVIDIA-NeMo/Guardrails) | 6.5k | NVIDIA 的 LLM 安全护栏 |
| [Arthur Engine](https://github.com/arthur-ai/arthur-engine) | - | 企业级 AI 治理平台 |

### 推荐学习路径

#### Phase 1：理解 Loop Engineering（1-2 周）

1. **阅读核心论文**：
   - ReAct [arXiv:2210.03629] — 理解推理与行动交替的基础
   - Reflexion [arXiv:2303.11366] — 理解自我反思和记忆机制

2. **动手实验 Claude Code**：
   ```bash
   # 安装 Claude Code（请以官方文档为准）
   npm install -g @anthropic-ai/claude-code

   # 尝试 /goal 命令
   /goal "在 test/auth 目录下所有测试通过且 lint 干净"

   # 或通过 CLI（非交互式）
   # claude -p "/goal 在 test/auth 目录下所有测试通过且 lint 干净"
   ```

   > ⚠️ 命令语法可能随版本变化，请查阅[官方文档](https://code.claude.com/docs/en/goal)。

3. **尝试 OpenAI Codex**：
   ```bash
   # 安装 Codex CLI（请以官方文档为准）
   npm install -g @openai/codex

   # 查看 automations 功能
   codex automations --help

   # 查看 subagents 文档
   codex subagents --help
   ```

   > ⚠️ 命令语法可能随版本变化，请查阅[Codex 文档](https://developers.openai.com/codex)和 [Subagents 文档](https://developers.openai.com/codex/subagents)。

#### Phase 2：构建你的第一个 Loop（2-4 周）

**选择一个适合的场景**：
- 每日 issue 自动分诊（参考本文第六节案例）
- 自动 PR 审查与测试
- 监控 Slack 频道并自动回复常见问题
- 自动生成每日站会简报

**遵循四阶段原则**：
1. **先让一次手动执行稳定可靠** → 不要一开始就做 loop
2. **再把它变成 Skill** → 写成 `SKILL.md` 固化知识
3. **再包成 Loop** → 配置 `/loop` 或 `/goal`
4. **最后才排程** → 加入 cron 或 automations

#### Phase 3：进阶——多 Agent 协作（1-2 月）

学习 **Sub-agents** 和 **Agent Teams**：

```toml
# .claude/agents/reviewer.toml
name = "code-reviewer"
description = "专门审查 PR 的 agent"
model = "claude-sonnet-4-20250514"
tools = ["read_file", "search_files", "terminal"]

[instructions]
你是一个代码审查专家。你的任务是：
1. 检查 PR 的代码质量和风格
2. 运行相关测试
3. 提供具体的修改建议
4. 评估是否适合 merge
```

```yaml
# Claude Code 中的 agent team 配置
agent_teams:
  - name: "full-stack-review"
    agents: ["backend-reviewer", "frontend-reviewer", "security-reviewer"]
    workflow: "parallel-then-merge"
```

---

## 九、总结：从"写提示词的人"到"设计循环的人"

### 核心转变

```
2023 年：Prompt Engineer  →  找到那个解锁模型性能的 phrase
2024 年：Context Engineer  →  把正确的上下文喂给模型
2025 年：Harness Engineer  →  构建安全可靠的 agent 运行环境
2026 年：Loop Engineer     →  设计让 AI 自主持续运转的系统
```

### 你需要掌握的新能力

| 旧能力（Prompt Engineering） | 新能力（Loop Engineering） |
|-----------------------------|---------------------------|
| 写一个完美的 prompt | 设计一个可持续运行的循环 |
| 优化单次交互质量 | 定义"完成"和"好"的标准 |
| 提供一次性的上下文 | 区分并管理多种状态（短期/长期/项目/用户） |
| 关心模型能力 | 关心评估体系、工具稳定性、权限设计 |
| 你驱动每一步 | 你设计系统边界，AI 持续运转 |

### 未来 AI 产品的形态

> 过去的 AI 产品像聊天框，下一阶段的 AI 产品，更像一个 **持续运行的工作系统**。

- 代码 agent：不是回答"这段代码怎么改"，而是发现 bug → 创建分支 → 修改代码 → 运行测试 → 提交 PR → 等待人审查
- 客服 agent：不是回答用户问题，而是识别意图 → 查询订单 → 给出方案 → 记录用户偏好 → 升级复杂工单
- 研究 agent：不是总结一篇文章，而是持续监控领域变化 → 整理资料 → 更新观点 → 标记不确定性 → 形成周期性简报

**这条线一旦看清楚，很多看似零散的技术更新，就会变得连贯起来。**

---

## 十、关键要点回顾

1. **Loop Engineering 是 2026 年 AI 编程工具中的一个重要工程化趋势**：从"你 prompting agent"到"系统 prompting agent"

2. **七个关键组件**：
   - Trigger（触发器）
   - Context（上下文）
   - Action（行动）
   - Evaluation（评估）← **最危险的地方**
   - Memory（记忆）← **持续改进的基础**
   - Stop Condition（停止条件）
   - Human Checkpoint（人工检查点）

3. **Prompt Engineering 没有死，它进化了**：
   - 演变成 Loop / Pipeline / Tool / Eval / Safety 五个新方向
   - 2026 年的稀缺技能是 **设计让 AI 持续运转的系统**

4. **最大的风险不是模型能力，而是系统设计缺陷**：
   - 错误放大
   - 记忆隐私
   - 过期信息伪装成个性化
   - 自动化权限失控
   - 成本不可预测
   - 审计与回滚缺失

5. **从一次手动执行开始，逐步进化到 Loop**：
   - 先稳定 → 再 Skill → 再 Loop → 最后排程
   - 跳步骤是 Loop 在生产环境翻车的主因

---

## 附录：信源交叉验证说明

### 博客类信源

| 信源 | 类型 | 主要贡献 | 一致性验证 |
|------|------|---------|-----------|
| **Addy Osmani 原文** | 权威博客 | Loop Engineering 定义、五大原语、工作流 | ✅ 多个信源支持此框架，但具体范围和定义仍有争议 |
| **IEEE Spectrum** | 学术期刊 | Prompt Engineering 有效性研究 | ✅ 与 Addy Osmani、小黑盒文章观点一致 |
| **Claude Code 官方文档** | 官方文档 | `/goal` 命令详细机制 | ✅ 与 Addy Osmani 描述一致：evaluator model 机制 |
| **小黑盒文章（两篇）** | 中文技术博客 | 七大要素、Dreaming 记忆循环、风险分析 | ✅ 与 Addy Osmani 框架高度一致，补充了实战案例 |

### 学术论文信源

| 论文 | 发表 | 核心贡献 | 与本博客的关联 |
|------|------|---------|---------------|
| **ReAct** | ICLR 2023 | 推理与行动交替循环 | Loop Engineering 的理论基石 |
| **Reflexion** | 2023 | 语言反馈的强化学习 | Evaluation 和 Memory 要素的理论参考 |
| **Self-Refine** | 2023 | 迭代精炼框架 | Refinement Loop 模式 |
| **AgentEval** | 2026 | DAG 步级评估 | Evaluation 的最新研究进展 |
| **Infini Memory** | 2026 | 主题文档记忆 | Memory 要素的结构化存储方案 |
| **Agentic Memory** | 2026 | 统一长短期记忆管理 | Memory 工具化的学术体现 |

**多信源支持的趋势**（范围和命名仍有争议）：
1. Loop Engineering 是 2026 年 AI 编程工具中的一个重要工程化趋势
2. Evaluation 是 loop 最关键的瓶颈（Reflexion 论文强调）
3. 手工试错式 Prompt Engineering 作为独立技能边际价值下降，但作为系统工程的一部分仍然重要

**存在争议的点**：
- Loop Engineering 是否是"换个名字的 cron job"？（部分社区质疑）
  - **本文立场**：cron 是 Loop 的一部分，但 Loop 还包括 Memory、Evaluation、Human Checkpoint 等更复杂的系统设计，不等同于 cron
- Prompt Engineering 是否完全死亡？
  - **本文立场**：作为 2023 年那种"找一个 phrase 提升 4 分"的技能边际价值已下降，但作为系统工程的一部分仍然必要

---

### 来源类型说明

本文按照以下标准标注信源类型：

| 类型 | 说明 | 本文示例 |
|------|------|---------|
| **A** | 学术顶会/顶期刊论文 | ReAct (ICLR 2023)、Reflexion |
| **B** | 官方文档/博客 | Addy Osmani 博客、Claude Code 文档、OpenAI Codex 文档 |
| **C** | 权威技术媒体 | IEEE Spectrum |
| **D** | 社区观点/二手解读 | Twitter 引用、小黑盒文章、知乎专栏 |

> **说明**：本文核心论点以 A/B 级信源为支撑，D 级信源仅用于补充实战视角或社区讨论，不构成主要依据。

---

## 参考文献

[1] Addy Osmani. *Loop Engineering*. https://addyosmani.com/blog/loop-engineering (2026-06-07) **[类型 B]**

[2] Peter Steinberger (via Twitter). "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." (2026) **[类型 D]**

[3] Boris Cherny (via Rohan Paul). "I don't prompt Claude anymore. I have loops running that prompt Claude and figuring out what to do. My job is to write loops." (2026) **[类型 D]**

[4] Dina Genkina. *AI Prompt Engineering Is Dead*. IEEE Spectrum. https://spectrum.ieee.org/prompt-engineering-is-dead (2024-03) **[类型 C]**

[5] Shunyu Yao et al. *ReAct: Synergizing Reasoning and Acting in Language Models*. ICLR 2023. https://arxiv.org/abs/2210.03629 **[类型 A]**

[6] Noah Shinn et al. *Reflexion: Language Agents with Verbal Reinforcement Learning*. 2023. https://arxiv.org/abs/2303.11366 **[类型 A]**

[7] Madaan et al. *Self-Refine: Iterative Refinement with Self-Feedback*. 2023. https://arxiv.org/abs/2303.17651 **[类型 A]**

[8] AI小白起. *从 Prompt 到 Loop：Dreaming 正在把 AI 带入"自我循环"的时代*. 小黑盒. https://www.xiaoheihe.cn/app/bbs/link/f17c72094653 (2026-06-18) **[类型 D]**

[9] 错觉幻视. *来不及悼念了 Prompt Engineering，现在登场的是......* 小黑盒. https://www.xiaoheihe.cn/app/bbs/link/3ae872125f35 (2026-06-26) **[类型 D]**

[10] Anthropic. *Claude Code Documentation: Keep Claude working toward a goal*. https://code.claude.com/docs/en/goal (2026) **[类型 B]**

[11] OpenAI. *Subagents – Codex*. https://developers.openai.com/codex/subagents **[类型 B]**

[12] OpenAI. *Skills – Codex*. https://developers.openai.com/codex/skills **[类型 B]**

[13] AgentEval. *DAG-Structured Step-Level Evaluation for Agentic Workflows with Error Propagation Tracking*. https://arxiv.org/abs/2604.23581 **[类型 A]**

[14] *Infini Memory: Maintainable Topic Documents for Long-Term LLM Agent Memory*. https://arxiv.org/abs/2606.10677 **[类型 A]**

[15] *TRUSTMEM: Learning Trustworthy Memory Consolidation for LLM Agents with Long-Term Memory*. https://arxiv.org/abs/2606.25161 **[类型 A]**