diff --git a/loop-engineering-learning-blog.md b/loop-engineering-learning-blog.md
new file mode 100644
index 0000000..25c3a49
--- /dev/null
+++ b/loop-engineering-learning-blog.md
@@ -0,0 +1,1140 @@
+# Loop Engineering 学习指南：从 Prompt 到自主循环的范式转移
+
+> **"You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents."**
+> — Peter Steinberger, OpenClaw 创始人
+
+> **"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 负责人
+
+---
+
+## 一、什么是 Loop Engineering？
+
+### 核心定义
+
+**Loop Engineering（循环工程）** 是 2026 年 6 月爆火的新概念，由 Google 工程师 **Addy Osmani** 系统整理，Anthropic Claude Code 负责人 **Boris Cherny** 和 OpenClaw 创始人 **Peter Steinberger** 共同推动。
+
+**一句话定义**（Addy Osmani）：
+> Loop Engineering 就是把「负责提示 AI 的你」这个角色，换成一套替你做这件事的 **系统**。
+
+**传统工作流 vs Loop Engineering**：
+
+**传统工作流 vs Loop Engineering 对比**
+
+| 维度 | 传统 Prompt Engineering | Loop Engineering（新范式） |
+|------|------------------------|---------------------------|
+| **你的角色** | 写提示词的人 | 设计循环系统的工程师 |
+| **AI 行为** | 一次问答，等待人类下一步 | 自主发现任务、执行、检查、记录、继续 |
+| **交互模式** | 人驱动每一步 | 人设计系统边界，AI 持续运转 |
+| **核心问题** | "这一轮 AI 怎么答更好？" | "下一轮 AI 为什么会启动、拿到什么信息、做什么动作、如何被检查、结果写入哪里，以及什么时候停止？" |
+
+> 换句话说：Prompt Engineering 关注单轮对话质量，Loop Engineering 关注整个系统的可持续运行。
+
+---
+
+---
+
+### 进化谱系：四个"Engineering"
+
+Loop Engineering 不是凭空出现，而是 AI 工程化的第四层演进：
+
+```
+Prompt Engineering  →  "怎么说"（怎么写好一句话）
+Context Engineering  →  "给什么"（给模型什么信息）
+Harness Engineering   →  "在哪里安全运行"（组织 AI 能力的工厂模型）
+Loop Engineering      →  "做完成"（让 AI 持续创造结果）
+```
+
+> **重要澄清**：Prompt Engineering 没有消亡。Loop 是由多个 Prompt 组成的，写得差的 Prompt 放进 Loop 里只会让糟糕的工作以更快的速度产出。Loop Engineering 是在 Prompt Engineering **之上**的层次，而不是替代它。[来源：菜鸟教程 & 知乎专栏交叉验证]
+
+---
+
+
+> **说白了**：这四个阶段不是替代关系，而是层层递进的技能栈。你仍然需要会写 prompt，但仅仅会写 prompt 已经不够了——2026 年，你需要会设计整个循环系统。
+## 三、为什么 Prompt Engineering 不够用了？
+
+### IEEE Spectrum 的研究结论
+
+2024 年 5 月，**IEEE Spectrum** 发表封面文章《AI Prompt Engineering Is Dead》，核心发现：
+
+**VMware 研究**（Rick Battle & Teja Gollapudi）：
+- 测试了 60 种 prompt 组合，涵盖 3 个开源 LLM，专注于小学数学题
+- **人类试错式 prompt engineering 没有一致性能趋势**：甚至连思维链（chain-of-thought）prompting 有时改善结果，有时反而伤害性能
+- **唯一真正的趋势可能是"没有趋势"**：对任何给定的模型、数据集和 prompting 策略，最优解很可能就是针对那个特定组合的
+
+| 人类测试的 Prompt | AI 自动优化后的 Prompt |
+|-----------------|----------------------|
+| "You are as smart as ChatGPT. Answer the math question. Take a deep breath and think carefully." | "Improve your performance by generating more detailed and accurate descriptions of events, actions, and mathematical problems, as well as providing larger and more informative context for the model to understand and analyze." |
+| "You are highly intelligent. Answer the math question. This will be fun!" | "Command, we need you to plot a course through this turbulence and locate the source of the anomaly. Use all available data and your expertise to guide us through this challenging situation." |
+| "You are an expert mathematician. Answer the math question. I really need your help!" | "Prefix #9: Given the two numbers x and y, if the sum of x and y is even, then output 'even'. Otherwise, output 'odd'." |
+
+**关键结论**：
+- **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 年的技能**：设计可测试、可版本化、可调试的系统 → **正在兴起**
+
+---
+
+
+> **我自己见过太多团队**：花几周时间调 prompt，却不愿意花几天时间把一次手动执行跑通、固化成 Skill、再包成 Loop。结果就是每次都要重新调，永远在"优化"的路上，从未真正跑起来。
+## 三、Loop Engineering 七大核心要素
+
+一个成熟的 Loop 不是简单让 agent 反复运行，而是由以下组件共同组成。这个框架整合自 **Addy Osmani 的原始文章** 与 **小黑盒深度分析**，并得到学术论文的验证。
+
+### 1. Trigger（触发器）
+
+**作用**：什么事件会启动循环？
+
+**类型**：
+- **定时任务**：每天早上检查 GitHub issue
+- **外部事件**：CI 失败、客户提交工单、竞品发布新版本
+- **用户行为**：上传文档、修改需求、提出长期目标
+
+**学术对应**：Reflexion 论文中的**试验循环（trial loop）**——每次试验的启动条件。
+
+**没有 Trigger 的后果**：agent 只是被动等待，没有"心跳"。
+
+---
+
+### 2. Context（上下文）
+
+**作用**：每次循环开始时，系统应该给 agent 什么信息？
+
+**关键原则**：不是把所有东西都塞进去，而是 **区分管理**。
+
+**应该区分的上下文类型**：
+- 项目规则 & 历史决策
+- 当前状态 & 任务进度
+- 用户偏好 & 限制条件
+- 工具说明 & 失败记录
+
+**学术对应**：
+- ReAct 的 **c_t**（上下文向量）= (o_1, a_1, ..., o_{t-1}, a_{t-1}, o_t)
+- Reflexion 的 **记忆 mem** = 自我反思总结的累积
+
+**反面模式**：一个巨大的 prompt 混在一起 → 上下文污染，效果递减。
+
+---
+
+### 3. Action（行动）
+
+**作用**：agent 能做什么？
+
+**范围**：从只生成文本，到调用工具（搜索、编辑代码、运行测试、查询数据库、创建工单、发送草稿、更新文档）。
+
+**学术对应**：
+- ReAct 的 **行动空间 A** = 任务特定动作 + 语言推理
+- Agentic Memory 的 **记忆操作作为工具**：读/写/删除记忆都是行动
+
+**关键权衡**：工具越多，能力越强，但 **权限风险也越大**。Loop 不是简单自动化，而是需要边界设计的系统。
+
+---
+
+### 4. Evaluation（评估）
+
+**作用**：谁来判断结果是否合格？
+
+**这是最容易被低估，却最关键的要素**。
+
+**为什么不能只依赖模型自评？**
+> 一个 loop 最危险的地方，不是 agent 做不出来，而是它做错了，还不断说自己完成了。[来源：小黑盒]
+
+**学术支持**：
+
+| 论文 | 评估机制 | 关键发现 |
+|------|---------|---------|
+| **ReAct** | 环境反馈（任务成功/失败） | 只有结合推理，agent 才能准确判断何时需要检索信息 |
+| **Reflexion** | Evaluator model（M_e）+ 自反思 | 自我评估能力是持续改进的核心 |
+| **AgentEval** | DAG 结构 + 分层失败分类 | 端到端检查掩盖了中间失败，步级评估才能准确定位问题 |
+
+**成熟的评估机制**：
+- 单元测试、linter、构建结果（代码场景）
+- 事实核查、风格检查、引用检查（内容场景）
+- 用户满意度、工单关闭率、升级比例（客服场景）
+- 另一个 evaluator agent（Claude Code 默认用 Haiku 作为 evaluator model）
+
+---
+
+### 5. Memory（记忆）
+
+**作用**：什么结果应该写入长期状态？
+
+**记忆选择原则**：不是所有过程都该被记住，真正值得记住的是：
+- 决策 & 偏好
+- 约束 & 限制
+- 失败原因 & 成功经验
+- 当前进度
+
+**学术支持**：
+
+| 论文 | 记忆机制 | 核心创新 |
+|------|---------|---------|
+| **Reflexion** | 滑动窗口长期记忆（最近 3 条自我反思） | 将奖励信号转化为语言反馈存入记忆 |
+| **Infini Memory** | Topic Documents（主题文档） | 按主题组织证据，支持修订和维护 |
+| **MemForest** | 层级时间索引 | 并行更新，延迟批量处理，降低延迟 |
+| **Agentic Memory** | 统一长短期记忆管理 | 记忆操作作为工具暴露给 LLM agent |
+| **Human-Inspired Memory** | 类脑记忆架构（6 种认知机制） | 睡眠整合、遗忘、印记成熟、再巩固 |
+
+**有 Memory vs 无 Memory 的 Loop**：
+
+| 有 Memory 的 Loop | 无 Memory 的 Loop |
+|-------------------|-------------------|
+| 积累经验，越跑越好 | 每轮都像第一次上班 |
+| 避免重复劳动 | 不断重复犯同样的错误 |
+| 记住失败原因，不再重蹈覆辙 | 不断重新理解项目 |
+
+**Memory 的风险**：如果 AI 把错误信息写入长期记忆，未来每次都调用，这个错误就会变成 **系统级偏差**。一次幻觉只是一次回答错误；一旦幻觉被写入 memory，就可能在未来反复出现。
+
+**研究证据**：
+- **FORGE**（2025）[arXiv:2605.16233]：提出**基于人群的记忆演化**机制，防止记忆退化和混淆
+- **TrustMem**（2026）[arXiv:2606.25161]：专门解决记忆更新可能引入幻觉或腐败内容的问题
+
+---
+
+### 6. Stop Condition（停止条件）
+
+**作用**：什么时候停止？
+
+**学术对应**：
+- Reflexion 算法中的 **`while M_e not pass or t < max trials`**
+- ReAct 的 **任务完成标志**（如 `finish[answer]` 动作）
+
+**常见停止条件**：
+- 所有测试通过就停止
+- 连续两次修复失败就停止并请求人工介入
+- 结果置信度低于阈值就停止
+- 涉及付款、删除、发布、上线等高风险动作就停止等待确认
+
+**没有停止条件的后果**：
+> Agent 会变成失控脚本，不断修复、不断提交、不断解释，最后把一个小问题变成一堆新问题。[来源：小黑盒]
+
+---
+
+### 7. Human Checkpoint（人工检查点）
+
+**作用**：哪些节点必须让人类介入？
+
+**这不是保守，而是必要的系统设计**。
+
+**学术对应**：
+- **Gödel Agent**（2024）[arXiv:2410.04444]：提出**自指涉 agent 框架**，允许递归自我改进，但强调**策略级别的可审计变更**而非响应级别的自校正
+- **ProofAgent Harness**（2025）[arXiv:2605.24134]：为对抗性评估提供开放基础设施，支持多轮试验中的人工审查
+
+**典型检查点**：
+- Agent 可以写 PR，但不一定应该自动 merge
+- Agent 可以草拟邮件，但不一定应该自动发送
+- Agent 可以分析账单，但不应该随便自动付款
+
+> Loop Engineering 的价值，不是让人彻底退出系统，而是把人放到更关键的判断位置。[来源：小黑盒]
+
+---
+
+## 四、Claude Code vs OpenAI Codex：Loop 原语对比
+
+
+---
+
+
+<!-- 第二章已移至此处，原位于第一章之后 -->
+
+
+---
+
+
+## 二、学术基础：从 ReAct 到 Reflexion 的循环机制演进
+
+Loop Engineering 并非凭空出现，而是建立在多项重要学术研究的基础之上。以下是最关键的几篇论文。
+
+### 2.1 ReAct：推理与行动的交替循环（2023 ICLR）
+
+**论文**：*ReAct: Synergizing Reasoning and Acting in Language Models* [arXiv:2210.03629]
+
+**作者**：Shunyu Yao (Princeton) 等  
+**发表**：ICLR 2023
+
+**核心贡献**：
+
+ReAct 首次系统性地提出了 **Reasoning（推理）与 Acting（行动）交替进行**的范式，成为 Loop Engineering 的直接理论基石。
+
+**关键洞察**：
+
+1. **人类智能的独特性**：人类能够无缝结合任务导向的行动与语言推理（内心独白），这种结合被 Vygotsky (1987) 和 Luria (1965) 认为是自我调节和策略制定的关键机制。
+
+2. **ReAct 循环的核心公式**：
+   ```
+   在时间步 t，agent 接收环境观察 o_t，然后采取行动 a_t
+   上下文 c_t = (o_1, a_1, ..., o_{t-1}, a_{t-1}, o_t)
+   策略 π(a_t | c_t) 同时生成：
+   - 推理步骤（thought）：帮助模型归纳、追踪和更新行动计划
+   - 行动步骤（action）：与外部环境交互，获取新信息
+   ```
+
+3. **实验数据**：
+   - **HotpotQA**（多跳问答）：ReAct 通过交互 Wikipedia API，幻觉率从 CoT 的 14% 降至 6%
+   - **ALFWorld**（文本游戏）：ReAct 平均成功率 **71%**，远超 Act-only 的 45% 和 BUTLER 的 37%
+   - **WebShop**（在线购物）：ReAct 比 IL+RL 方法（训练用了 10,587 条数据）的绝对成功率高出 **10%**
+
+| 方法 | ALFWorld 成功率 | WebShop 成功率 |
+|------|----------------|----------------|
+| Act-only | 45% | 30.1% |
+| ReAct (prompting) | 71% | 40.0% |
+| IL + RL (训练) | 28.7% | 28.7% |
+| 人类专家 | 59.6% | 82.1% |
+
+**为什么 ReAct 是 Loop Engineering 的基础**：
+- 它将"思考-行动-观察"变成了一个可重复的循环
+- 这个循环不依赖于特定的模型或任务，可以跨场景应用
+- Claude Code 和 OpenAI Codex 的底层逻辑都是 ReAct 循环的变体
+
+---
+
+### 2.2 Reflexion：通过语言反馈的强化学习（2023）
+
+**论文**：*Reflexion: Language Agents with Verbal Reinforcement Learning* [arXiv:2303.11366]  
+**作者**：Noah Shinn (Northeastern) 等  
+**核心贡献**：
+
+Reflexion 在 ReAct 的基础上增加了一个关键组件：**自我反思记忆（Self-Reflection Memory）**，让 agent 能够在多次试验中持续改进。
+
+**Reflexion 的三组件架构**：
+
+```
+
+**说白了**：这个公式就是 agent 在每一轮"看当前情况 → 思考 → 行动 → 看新情况"的完整循环。
+┌─────────────┐
+│   Actor      │ ← 生成文本和行动（基于 LLM）
+│  (M_a)       │
+└──────┬──────┘
+       │ 轨迹 τ_t
+       ↓
+┌─────────────┐
+│  Evaluator   │ ← 评估输出质量，给出奖励 r_t
+│  (M_e)       │
+└──────┬──────┘
+       │ 奖励信号
+       ↓
+┌─────────────┐
+│Self-Reflection│ ← 将奖励转化为语言反馈，存入长期记忆
+│  (M_sr)      │
+└──────┬──────┘
+       │ 语言反馈 s_r_t
+       ↓
+   更新记忆 mem → 下一轮 Actor 使用
+```
+
+**关键创新**：
+
+1. **语言反馈而非权重更新**：Reflexion 不更新模型权重，而是将环境反馈转化为自然语言总结，存入 agent 的记忆。
+
+2. **记忆的双重结构**：
+   - **短期记忆**：当前试验的轨迹历史
+   - **长期记忆**：自我反思总结的累积（滑动窗口，保留最近 3 条）
+
+3. **自我反思的三种反馈来源**：
+   - 简单的二值环境反馈（成功/失败）
+   - 预定义的启发式规则（针对常见失败模式）
+   - 自评估（LLM 作为评估器）
+
+**实验数据**：
+
+| 任务 | ReAct | ReAct + Reflexion | 提升 |
+|------|-------|-------------------|------|
+| ALFWorld（决策） | 65% → 130/134 任务完成 | 平均成功率提升 **22%**（12 次迭代） |
+| HotpotQA（推理） | 基线 | 准确率提升 **20%** |
+| HumanEval（编程） | 67% | **91%** pass@1（超越 GPT-4 的 80%） |
+
+**消融实验**（Ablation Study）：
+
+| 配置 | 测试生成 | 自我反思 | Pass@1 |
+|------|---------|---------|--------|
+| 基线（GPT-4） | ✗ | ✗ | 60% |
+| 无测试生成 | ✗ | ✓ | 52%（↓8%） |
+| 无自我反思 | ✓ | ✗ | 60%（无提升） |
+| **完整 Reflexion** | ✓ | ✓ | **68%**（↑8%） |
+
+**关键结论**：
+- 测试生成是必要的（没有它，准确率从 60% 降到 52%）
+- 但自我反思是性能提升的关键（只有两者结合才达到 68%）
+- Reflexion 在 Rust  hardest problems 上也达到了 68%，证实了跨语言有效性
+
+---
+
+### 2.3 Self-Refine：迭代精炼与自我反馈（2023）
+
+**论文**：*Self-Refine: Iterative Refinement with Self-Feedback* [arXiv:2303.17651]
+
+**核心机制**：
+
+Self-Refine 提出了一种简单的迭代精炼框架，与 Reflexion 的区别在于它专注于**单次生成任务的精炼**，而不是多步决策：
+
+```
+生成初始输出 → 自我评估 → 精炼输出 → 再次评估 → ...（直到满足停止条件）
+```
+
+**关键特点**：
+- 不需要额外训练数据、训练或强化学习
+- 使用**同一个 LLM** 作为生成器、评估器和精炼器
+- 通过迭代反馈逐步改进输出质量
+
+**与 Reflexion 的关系**：
+- Reflexion = 多步决策 + 记忆（针对 sequential decision-making）
+- Self-Refine = 单步生成 + 迭代精炼（针对 reasoning、generation）
+
+---
+
+### 2.4 记忆系统的研究进展（2025-2026）
+
+Loop Engineering 的核心挑战之一是长期记忆管理。以下是 2025-2026 年的重要研究：
+
+**记忆系统论文速览**：
+
+| 论文 | 年份 | 核心机制 | 解决的问题 | 适合场景 |
+|------|------|---------|-----------|---------|
+| Infini Memory | 2026 | Topic Documents（主题文档） | 孤立记录存储 | 跨会话证据聚合 |
+| MemForest | 2025 | 层级时间索引 | 粗粒度状态管理 | 并行更新、低延迟 |
+| Agentic Memory | 2025 | 记忆作为工具 | 记忆操作与推理耦合 | 端到端优化 |
+| AgentEval | 2025 | DAG 步级评估 | 端到端检查掩盖失败 | 精确定位中间失败 |
+| Verifiability-First | 2025 | 运行时认证 | 意图与行为不一致 | 高安全要求场景 |
+
+---
+
+#### **Infini Memory**（2026）[arXiv:2606.10677]
+
+**核心贡献**：提出 **Topic Documents** 结构，将 agent 记忆视为按主题组织的文档集合。
+
+**机制**：
+- 每个主题文档是一个语义单元，收集相关证据、保留元数据、随时间修订事实
+- 新观察首先与现有文档进行相似度比较
+- 如果相似度 > 阈值，追加到现有文档；否则创建新文档
+- 支持证据聚合、事实修订和维护
+
+**优势**：
+- 解决了现有记忆系统将观察作为孤立记录存储的问题
+- 使得跨会话的证据聚合和事实修订成为可能
+
+---
+
+#### **MemForest**（2025）[arXiv:2605.23986]
+
+**核心贡献**：层级时间索引（Hierarchical Temporal Indexing）记忆系统。
+
+**问题**：现有系统存在两个关键限制：
+1. 粗粒度状态管理
+2. 固有的顺序更新管道（更新与 LLM 推理耦合）
+
+**解决方案**：
+- 记忆组织成森林结构（多个主题树）
+- 每个节点是一个记忆条目，包含时间戳和上下文
+- 支持并行更新，不阻塞 LLM 推理
+- 延迟更新策略：高频操作先入缓冲区，批量处理
+
+---
+
+#### **Agentic Memory (AgeMem)**（2025）[arXiv:2601.01885]
+
+**核心贡献**：**统一的长短期记忆管理框架**，将记忆操作直接集成到 agent 的策略中。
+
+**关键创新**：
+- 将记忆操作（读/写/删除）暴露为**基于工具的行动**
+- LLM agent 可以像调用其他工具一样管理记忆
+- 支持端到端优化，而不是依赖启发式或辅助控制器
+
+**意义**：这是 Loop Engineering "Action" 要素的学术体现——记忆管理本身也是 agent 行动的一部分。
+
+---
+
+### 2.5 评估系统：Loop 的瓶颈
+
+Loop Engineering 最危险的地方是 agent 做错了还不断说自己完成了。以下研究针对这一问题。
+
+**评估系统论文速览**：
+
+| 论文 | 核心机制 | 关键创新 | 对应 Loop 要素 |
+|------|---------|---------|--------------|
+| AgentEval | DAG 结构 + 分层失败分类 | 步级评估定位中间失败 | Evaluation |
+| Verifiability-First | 运行时认证 + 审计 agent | 可验证性优先架构 | Evaluation + Human Checkpoint |
+
+---
+
+#### **AgentEval**（2025）[arXiv:2604.23581]
+
+**核心贡献**：提出 **DAG 结构的步级评估框架**。
+
+**机制**：
+- 将 agent 执行形式化为**评估有向无环图（DAG）**
+- 每个节点携带**类型化的质量指标**
+- 通过**分层失败分类法**（3 层，21 个子类别）分类失败
+- 链接到上游失败，实现错误传播追踪
+
+**价值**：
+- 现有评估实践（端到端结果检查）系统性地掩盖了中间失败
+- AgentEval 能够识别"哪些步骤导致最终失败"
+
+---
+
+#### **Verifiability-First Agents**（2025）[arXiv:2512.17259]
+
+**核心贡献**：提出**可验证性优先**架构，包含：
+1. 运行时认证（ cryptographic 和 symbolic 方法）
+2. 轻量级审计 agent，持续验证意图与行为是否一致
+
+**意义**：这是 Loop Engineering "Evaluation" 和 "Human Checkpoint" 要素的学术体现。
+
+---
+
+
+Addy Osmani 在 2026 年 6 月的分析指出，两大主流 AI 编程工具已原生支持所有核心 Loop 原语，只有命名差异。
+
+| **Loop 原语** | **在 Loop 中的角色** | **OpenAI Codex** | **Claude Code** |
+|--------------|-------------------|-----------------|----------------|
+| **Automations** | 循环的心跳（定时发现 + 分诊） | Automations tab：选择项目、prompt、频率、环境；结果进入 Triage 收件箱 | `/loop`（定时重跑）、`/goal`（运行直到完成）、cron、hooks、GitHub Actions |
+| **Worktrees** | 并行隔离（避免文件冲突） | 每个 thread 内置 worktree | `git worktree`、`--worktree` 标志、subagent 的 `isolation: worktree` |
+| **Skills** | 项目知识编码（避免重复解释） | Agent Skills（`SKILL.md`），用 `$name` 或隐式调用 | Agent Skills（`SKILL.md`） |
+| **Plugins / Connectors** | 连接真实工具 | Connectors (MCP) + plugins | MCP servers + plugins |
+| **Sub-agents** | 并行 ideate + verify | TOML 文件定义在 `.codex/agents/` | `.claude/agents/` 中的 task subagents、agent teams |
+| **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 的 **Evaluator Model (M_e)** 角色。
+
+---
+
+## 五、四大典型 Loop 模式
+
+根据 Addy Osmani 和小黑盒文章的综合整理，常见的 Loop 模式包括：
+
+### 1. 轮询循环（Polling Loops）
+
+**机制**：按时间（如每 30 分钟）唤醒，检查数据源，只有发现新数据时才触发行动。
+
+**例子**：检查 CRM 中的新潜在客户，丰富数据，记录到 Airtable。
+
+**适合**：监控、数据同步、定期检查任务。
+
+**学术对应**：Reflexion 的 **试验循环**——每次试验独立评估。
+
+---
+
+### 2. 精炼循环（Refinement Loops）
+
+**机制**：agent 生成内容（如营销文案），根据品质标准自行评分，未达标就重写，直到过关或达到最大尝试次数。
+
+**例子**：生成产品描述 → 检查 SEO 关键词密度 → 低于阈值则重写。
+
+**适合**：内容生成与优化、文案打磨。
+
+**学术对应**：
+- **Self-Refine**（arXiv:2303.17651）：迭代精炼框架
+- **Reflexion** 的编程任务：生成代码 → 运行测试 → 自我反思 → 重写
+
+---
+
+### 3. 队列处理循环（Processing Queue Loops）
+
+**机制**：agent 面对一个任务清单（如客服工单库），一件接一件处理、记录结果，直到清空为止。
+
+**适合**：批量处理、工单消化、数据录入。
+
+---
+
+### 4. 事件响应循环（Event-Response Loops）
+
+**机制**：agent 持续监听外部信号（如电子邮件、Webhook），一旦有事件进来就立即执行回应程序，随后回到监听状态。
+
+**适合**：实时响应系统、告警处理、Webhook 驱动工作流。
+
+**学术对应**：**AgentEval** 的 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
+
+```markdown
+<!-- .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
+
+```markdown
+<!-- 在 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 项目映射
+
+**学术参考**：这里应该引入 **AgentEval** 的 DAG 评估模式，将检查步骤形式化。
+
+#### Step 5: 配置 Memory
+
+```markdown
+<!-- 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 的 Topic Documents 结构
+- **高复杂度**：MemForest 或向量数据库 + 知识图谱
+
+#### Step 6: 定义 Stop Condition
+
+```
+停止条件：
+1. 成功：所有 open issue 都已处理（分类 + Linear ticket 创建 + 评论）
+2. 失败：连续 3 个 issue 创建 Linear ticket 失败（API 配额用尽）
+3. 需要人工介入：出现 priority: high 标签的 issue 且置信度 < 0.8
+```
+
+**学术参考**：Reflexion 的 `while M_e not pass or t < max trials` 模式。
+
+#### Step 7: 设置 Human Checkpoint
+
+- **必须人工确认**：任何涉及 `priority: high` 的 issue 分类结果
+- **定期审查**：每周一审查上周的自动分诊准确率，调整规则
+
+---
+
+### 完整 Loop 配置示例（Claude Code）
+
+```bash
+# 启动 loop（每天 9:00 AM 运行）
+claude --loop "0 9 * * *" --prompt "
+你是一个 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 频道。
+"
+```
+
+---
+
+### 代码示例：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. 错误放大效应
+
+**问题**：一次错误回答只影响一次对话；但如果错误进入循环，它可能被下一轮继续引用、强化、写入状态，最后变成系统默认判断。
+
+**学术证据**：
+- **Reflexion** 论文指出：如果自我反思生成了错误但看起来很可信的总结，它会被存入长期记忆并持续影响后续行为，形成**记忆混淆（memory confabulation）** [arXiv:2605.29463]
+- **AgentEval** 研究表明：端到端评估会掩盖中间步骤的失败，错误的累积在循环中会被放大
+
+**对策**：
+- 必须设置可靠的评估机制，不能只依赖模型自评
+- 定期审计 Memory 中的信息，及时修正错误
+- 设置"连续失败 N 次则停止"的熔断机制
+
+---
+
+### 2. 记忆隐私问题
+
+**问题**：用户不一定希望所有历史都被整理、保存和调用。
+
+**学术对应**：
+- **NeuSymMS**（2025）[arXiv:2605.17596]：提出**混合神经符号记忆系统**，支持用户/agent/agent-to-agent 作用域，实现记忆的生命周期管理
+- **Governed Collaborative Memory**（2025）[arXiv:2605.04264]：将记忆治理视为**人工选择机制**——哪些记忆应该成为共享的制度化状态？
+
+**Memory 透明度三要素**：
+- 用户必须知道系统 **记住了什么**
+- 为什么记住
+- 什么时候会用、能不能修改、能不能删除、能不能关闭
+
+**否则**：所谓"个性化"就可能变成另一种不透明。
+
+---
+
+### 3. 过期信息伪装成个性化
+
+**问题**：AI 记得用户过去的偏好，并不等于这个偏好今天仍然成立；AI 记得用户过去的计划，也不等于这个计划还在进行。
+
+**学术对应**：
+- **EverMemOS**（2025）[arXiv:2601.02163]：提出**印记生命周期（engram-inspired lifecycle）**，将记忆分为：
+  - 情景痕迹形成（Episodic Trace Formation）
+  - 记忆巩固（Consolidation）
+  - 冲突解决（Conflict Resolution）
+  - 遗忘（Forgetting）
+- **CraniMem**（2026）[arXiv:2603.15642]：提出**门控和边界记忆**机制，通过目标条件门控和效用标记，控制记忆的保留和检索
+
+**对策**：
+- Memory 必须处理时间戳和状态标记
+- 区分"进行中"、"已完成"、"已取消"的计划
+- 定期回顾 Memory，清理过期信息
+
+---
+
+### 4. 自动化权限边界
+
+**原则**：
+- Agent 可以写代码 → 不一定应该自动 merge
+- Agent 可以分析合同 → 不一定可以自动签署
+- Agent 可以草拟回复 → 不一定可以自动发送
+- Agent 可以整理财务信息 → 不一定可以自动转账
+
+**学术对应**：
+- **Verifiability-First Agents**（2025）[arXiv:2512.17259]：提出**运行时认证**和**轻量级审计 agent**，持续验证意图与行为
+- **TrustBench**（2025）[arXiv:2603.09157]：提供**实时信任验证框架**，在 agent 执行前评估动作的可信度
+
+**必须有的权限分层**：
+1. 哪些动作可以 **自动执行**
+2. 哪些动作需要 **确认**
+3. 哪些动作 **绝对禁止**
+4. 哪些动作必须留下 **审计记录**
+
+---
+
+### 5. 持续运行系统的审计与回滚
+
+**问题**：一个聊天机器人答错了，用户关窗口就行；但一个持续运行的 agent，如果改了文件、调用了 API、更新了数据库、影响了业务流程，就必须留下记录。
+
+**学术对应**：
+- **AEMA**（2025）[arXiv:2601.11903]：提出**自适应多 agent 评估框架**，支持可审计的过程追踪
+- **AlphaEval**（2025）[arXiv:2604.12162]：关注**生产环境中的 agent 评估**，承认隐式约束、异构输入、长周期任务
+- **ProofAgent Harness**（2025）[arXiv:2605.24134]：提供**对抗性评估基础设施**，捕获多轮交互中的行为
+
+**必须追踪的问题**：
+- 谁触发了它？
+- 它看到了什么上下文？
+- 调用了什么工具？
+- 为什么做这个决策？
+- 改了哪些状态？
+- 能不能撤回？
+
+**结论**：这些问题听起来不像 AI 论文里的问题，但它们会决定 AI 产品能不能真正进入企业和个人的长期工作流。
+
+---
+
+### 6. 不是所有任务都适合 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) | 2025 | DAG 步级评估 | ⭐⭐⭐⭐ |
+| **Infini Memory** | [2606.10677](https://arxiv.org/abs/2606.10677) | 2026 | 主题文档记忆结构 | ⭐⭐⭐⭐ |
+| **Agentic Memory** | [2601.01885](https://arxiv.org/abs/2601.01885) | 2025 | 统一长短期记忆管理 | ⭐⭐⭐⭐ |
+| **Verifiability-First** | [2512.17259](https://arxiv.org/abs/2512.17259) | 2025 | 可验证性优先架构 | ⭐⭐⭐⭐ |
+| **FORGE** | [2605.16233](https://arxiv.org/abs/2605.16233) | 2025 | 自演化记忆（无权重更新） | ⭐⭐⭐⭐ |
+| **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 | https://developers.openai.com/codex/subagents |
+| OpenAI Codex Skills | 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 命令
+   claude "/goal 在 test/auth 目录下所有测试通过且 lint 干净"
+   ```
+
+3. **尝试 OpenAI Codex**：
+   ```bash
+   # 安装 Codex CLI
+   npm install -g @openai/codex
+
+   # 查看 automations 功能
+   codex automations --help
+   ```
+
+---
+
+#### 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"
+```
+
+**学术参考**：
+- **Gödel Agent**（2024）：递归自我改进框架，支持多 agent 协作
+- **buddyMe**（2025）[arXiv:2606.11926]：多范式 agent 交互框架
+
+---
+
+## 九、总结：从"写提示词的人"到"设计循环的人"
+
+### 核心转变
+
+```
+2023 年：Prompt Engineer  →  找到那个解锁模型性能的 phrase
+2024 年：Context Engineer  →  把正确的上下文喂给模型
+2025 年：Harness Engineer  →  构建安全可靠的 agent 运行环境
+2026 年：Loop Engineer     →  设计让 AI 自主持续运转的系统
+```
+
+### 学术脉络
+
+Loop Engineering 的三大理论支柱：
+
+| 支柱 | 代表论文 | 贡献 |
+|------|---------|------|
+| **循环机制** | ReAct (2023 ICLR) | 推理与行动交替的基础范式 |
+| **自我改进** | Reflexion (2023) | 语言反馈替代权重更新 |
+| **记忆管理** | Infini Memory / MemForest (2025-2026) | 长期记忆的结构化存储与维护 |
+| **评估验证** | AgentEval (2025) | DAG 步级评估，定位中间失败 |
+
+### 你需要掌握的新能力
+
+| 旧能力（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（评估）← **最危险的地方**（Reflexion 论文验证）
+   - Memory（记忆）← **持续改进的基础**（多篇 2025-2026 论文支撑）
+   - Stop Condition（停止条件）
+   - Human Checkpoint（人工检查点）
+
+3. **Prompt Engineering 没有死，它进化了**：
+   - 演变成 Loop / Pipeline / Tool / Eval / Safety 五个新方向
+   - 2026 年的稀缺技能是 **设计让 AI 持续运转的系统**
+
+4. **三大理论支柱**：
+   - **ReAct** (ICLR 2023) — 推理与行动交替循环
+   - **Reflexion** (2023) — 语言反馈替代权重更新
+   - **记忆系统** (2025-2026) — 从滑动窗口到结构化文档
+
+5. **最大的风险不是模型能力，而是系统设计缺陷**：
+   - 错误放大（AgentEval 研究指出中间失败被掩盖）
+   - 记忆隐私（记忆治理成为新研究热点）
+   - 过期信息伪装成个性化（EverMemOS / CraniMem 的解决方案）
+   - 自动化权限失控（Verifiability-First 架构）
+   - 审计与回滚缺失（ProofAgent Harness）
+
+6. **从一次手动执行开始，逐步进化到 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** | 2025 | DAG 步级评估 | Evaluation 的最新研究进展 |
+| **Infini Memory** | 2026 | 主题文档记忆 | Memory 要素的结构化存储方案 |
+| **Agentic Memory** | 2025 | 统一长短期记忆管理 | Memory 工具化的学术体现 |
+
+**核心共识**（所有信源一致认同）：
+1. Loop Engineering 是 2026 年 AI 工程的核心范式转移
+2. Claude Code 和 OpenAI Codex 已原生支持 loop 原语
+3. **Evaluation 是 loop 最关键的瓶颈**（Reflexion 论文强调）
+4. Prompt Engineering 作为独立技能已死，但作为系统工程的一部分仍然重要
+
+**存在争议的点**：
+- Loop Engineering 是否是"换个名字的 cron job"？（部分社区质疑）
+  - **本文立场**：cron 是 Loop 的一部分，但 Loop 还包括 Memory、Evaluation、Human Checkpoint 等更复杂的系统设计，不等同于 cron
+- Prompt Engineering 是否完全死亡？
+  - **本文立场**：作为 2023 年那种"找一个 phrase 提升 4 分"的技能已死，但作为系统工程的一部分仍然必要
+
+---
+
+## 参考文献
+
+[1] Addy Osmani. *Loop Engineering*. https://addyosmani.com/blog/loop-engineering (2026-06-07)
+
+[2] Peter Steinberger (via Twitter). "You shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents." (2026)
+
+[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)
+
+[4] Dina Genkina. *AI Prompt Engineering Is Dead*. IEEE Spectrum. https://spectrum.ieee.org/prompt-engineering-is-dead (2024-03)
+
+[5] Shunyu Yao et al. *ReAct: Synergizing Reasoning and Acting in Language Models*. ICLR 2023. https://arxiv.org/abs/2210.03629
+
+[6] Noah Shinn et al. *Reflexion: Language Agents with Verbal Reinforcement Learning*. 2023. https://arxiv.org/abs/2303.11366
+
+[7] Madaan et al. *Self-Refine: Iterative Refinement with Self-Feedback*. 2023. https://arxiv.org/abs/2303.17651
+
+[8] AI小白起. *从 Prompt 到 Loop：Dreaming 正在把 AI 带入"自我循环"的时代*. 小黑盒. https://www.xiaoheihe.cn/app/bbs/link/f17c72094653 (2026-06-18)
+
+[9] 错觉幻视. *来不及悼念了 Prompt Engineering，现在登场的是......*. 小黑盒. https://www.xiaoheihe.cn/app/bbs/link/3ae872125f35 (2026-06-26)
+
+[10] Anthropic. *Claude Code Documentation: Keep Claude working toward a goal*. https://code.claude.com/docs/en/goal (2026)
+
+[11] OpenAI. *Subagents – Codex*. https://developers.openai.com/codex/subagents
+
+---
+
+**关于作者**
+
+本文由 Hermes Agent 整合多源信息生成，旨在为 AI 工程师和开发者提供一份结构化的 Loop Engineering 学习指南。
+
+**许可**：CC BY-NC-SA 4.0（欢迎转载，请注明来源）
\ No newline at end of file