842 lines
35 KiB
Markdown
842 lines
35 KiB
Markdown
---
|
||
title: Loop Engineering 学习指南：从 Prompt 到自主循环的范式转移
|
||
slug: loop-engineering-prompt
|
||
date: 2026-06-26
|
||
views: 0
|
||
likes: 0
|
||
tags:
|
||
- Loop Engineering
|
||
- AI编程
|
||
- Prompt Engineering
|
||
- Claude Code
|
||
- OpenAI Codex
|
||
draft: false
|
||
---
|
||
|
||
## 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 年受到广泛关注的新概念，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]
|
||
|
||
这意味着：
|
||
- **2023 年的技能**：找到那个解锁 MMLU 额外 4 分的 phrase → **边际价值已大幅下降**
|
||
- **2026 年的技能**：设计可测试、可版本化、可调试的系统 → **正在兴起**
|
||
|
||
---
|
||
|
||
## 三、Loop Engineering 的七个关键组件
|
||
|
||
一个成熟的 Loop 不是简单让 agent 反复运行，而是由以下组件共同组成。这个框架整合自 Addy Osmani 的原始文章[1]与小黑盒深度分析[8]。
|
||
|
||
> **关于学术引用的说明**：以下每个要素后都列出了相关的学术论文（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 默认用 Haiku 作为 evaluator model）
|
||
|
||
---
|
||
|
||
### 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** | 并行隔离（避免文件冲突） | 每个 thread 自动创建独立的 git worktree（官方文档：https://developers.openai.com/codex/subagents） | 可通过 `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]**
|