blog-drafts/loop-engineering-prompt-v4.md at a9671b2819a718bccb10c48043a7cc4ac6df8e8c

Elaina/blog-drafts

Fork 0

Files

Elaina 523c51dba6 Add: Loop Engineering 学习指南 v4（修复 Worktrees 链接、七组件来源表述）

2026-06-26 22:08:58 +08:00

35 KiB

Raw Blame History

title, slug, date, views, likes, tags, draft

title

slug

date

views

likes

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 原文的逐字框架，而是本文结合 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 默认用 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	并行隔离（避免文件冲突）	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` 命令详解

工作原理：

你定义一个完成条件：/goal all tests in test/auth pass and lint is clean
Claude 每轮执行后，一个 独立的 evaluator model（默认 Haiku，不是写代码的那个模型）会检查对话记录，评估条件是否满足
如果没满足，Claude 继续修改代码、运行测试、阅读失败信息、修复、重跑
循环直到 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 结束后运行）：

# 检查所有新创建的 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 命令示例仅供参考，实际使用时请以官方文档[10]为准。命令语法可能随版本变化，建议先查阅最新文档。

# 方式 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）

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 可以整理财务信息 → 不一定可以自动转账

必须有的权限分层：

哪些动作可以 自动执行
哪些动作需要确认
哪些动作 绝对禁止
哪些动作必须留下 审计记录

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

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

必须追踪的问题：

谁触发了它？
它看到了什么上下文？
调用了什么工具？
为什么做这个决策？
改了哪些状态？
能不能撤回？

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

6. 成本不可预测

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

必须设置的预算控制：

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

成本控制的落地方法：

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	2023	推理与行动交替循环	⭐⭐⭐⭐⭐
Reflexion	2303.11366	2023	语言反馈的强化学习	⭐⭐⭐⭐⭐
Self-Refine	2303.17651	2023	迭代精炼与自我反馈	⭐⭐⭐⭐
AgentEval	2604.23581	2026	DAG 步级评估	⭐⭐⭐⭐
Infini Memory	2606.10677	2026	主题文档记忆结构	⭐⭐⭐⭐
Agentic Memory	2601.01885	2026	统一长短期记忆管理	⭐⭐⭐⭐
Verifiability-First	2512.17259	2025	可验证性优先架构	⭐⭐⭐⭐
FORGE	2605.16233	2026	自演化记忆（无权重更新）	⭐⭐⭐⭐
TrustMem	2606.25161	2026	可信记忆整合	⭐⭐⭐⭐
Gödel Agent	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	140k	最成熟的 LLM 应用框架，支持 ReAct 循环
CrewAI	54k	多 agent 协作框架，角色定义清晰
ReAct 论文	-	提出 Reasoning + Acting 交替范式

🧩 Pipeline 工程

项目	Stars	说明
Sim Studio	29k	可视化拖拽构建 AI 工作流
Haystack	26k	NLP 框架，支持复杂 pipeline
Pipelex	683	"AI reasoning 的 Dockerfile"

🛠 Tool 工程

项目	Stars	说明
MCP for Beginners	17k	Microsoft 官方 MCP 入门
MCP Agent	8.4k	MCP 集成示例

📊 Eval 工程

项目	Stars	说明
OpenLIT	2.6k	LLM 应用可观测性与评估
Relai-SDK	-	simulate → evaluate → optimize 流程

🛡 Safety 工程

项目	Stars	说明
NeMo Guardrails	6.5k	NVIDIA 的 LLM 安全护栏
Arthur Engine	-	企业级 AI 治理平台

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

核心转变

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：不是总结一篇文章，而是持续监控领域变化 → 整理资料 → 更新观点 → 标记不确定性 → 形成周期性简报

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

十、关键要点回顾

Loop Engineering 是 2026 年 AI 编程工具中的一个重要工程化趋势：从"你 prompting agent"到"系统 prompting agent"
七个关键组件：
- Trigger（触发器）
- Context（上下文）
- Action（行动）
- Evaluation（评估）← 最危险的地方
- Memory（记忆）← 持续改进的基础
- Stop Condition（停止条件）
- Human Checkpoint（人工检查点）
Prompt Engineering 没有死，它进化了：
- 演变成 Loop / Pipeline / Tool / Eval / Safety 五个新方向
- 2026 年的稀缺技能是 设计让 AI 持续运转的系统
最大的风险不是模型能力，而是系统设计缺陷：
- 错误放大
- 记忆隐私
- 过期信息伪装成个性化
- 自动化权限失控
- 成本不可预测
- 审计与回滚缺失
从一次手动执行开始，逐步进化到 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 工具化的学术体现

多信源支持的趋势（范围和命名仍有争议）：

Loop Engineering 是 2026 年 AI 编程工具中的一个重要工程化趋势
Evaluation 是 loop 最关键的瓶颈（Reflexion 论文强调）
手工试错式 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]

35 KiB Raw Blame History Unescape Escape