Loop Engineering：从手动提示词到自主编排——AI Agent 的下一层抽象
2026 年 6 月，Anthropic Claude Code 负责人 Boris Cherny 在 Meta @Scale 大会上说了一句话，随后在整个 AI 工程社区里迅速传播：
"我已经不再直接提示 Claude 了。我有 loop 在运行，它们负责提示 Claude，决定下一步做什么。我的工作是写 loop。"
这句话不是预言，是对工作方式的陈述。它意味着一件事：如果你还在手动、逐轮地和 Agent 交互，你可能已经在对的工具上做着错误层级的事情。
什么是 Loop Engineering
最简洁的定义来自 Addy Osmani（Google Chrome VP，2026 年 6 月）：
"Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead."
中文直译：你不再是那个提示 Agent 的人，你设计那个会提示 Agent 的系统。
从操作定义上看，loop engineering 是将手动的逐轮 Agent 提示替换为一个自主的编排系统——这个"loop"会：
- 发现工作（轮询任务队列、监听 git diff、扫描 issue）
- 向 Agent 下发任务（构建上下文、注入工具、传递目标）
- 验证结果（运行测试、检查约束、评估输出质量）
- 决定下一步（继续、重试、上报人工介入、终止）
整个过程无需人类在每个循环周期介入。
这与 Agent 本身的设计不同——Agent 是循环的执行者，loop engineering 是循环的架构师。
它站在哪个历史坐标上
Loop engineering 出现在一条演进链的末端：
| 层级 | 学科 | 核心问题 | 时期 |
|---|---|---|---|
| 1 | 提示词工程 (Prompt Engineering) | 怎么措辞才能得到好的单次回答？ | 2022–2024 |
| 2 | 上下文工程 (Context Engineering) | 每一步该把什么信息放进上下文窗口？ | 2025 |
| 3 | Harness 工程 (Harness Engineering) | 怎么构建整个运行时环境让 Agent 可靠执行？ | 2026 上半年 |
| 4 | Loop 工程 (Loop Engineering) | 怎么构建系统让 Agent 自主驱动自身？ | 2026 年 6 月起 |
每一层都包含上一层，而不是替代它。一个好的 loop 内部仍然需要精心设计的提示词、细心的上下文交付和可靠的 harness。
Cherny 对这个跃迁的评价是："Loops are as big as the step from source code to agents was."（loop 的重要性，和从源代码到 Agent 这一步一样大。）这是一个强烈的说法——但它是一句引用，不是实证结论，后文会讨论它面临的合理质疑。
Loop 的解剖：五个必要组件
"一个任务加上一个检查就是一个 loop。没有检查的任务只是希望。" —— DEV Community 实践者指南（2026 年 6 月）
一个生产级 loop 必须包含五个组件，缺少任何一个都会产生可预测的故障模式：
| 组件 | 作用 | 缺失后果 |
|---|---|---|
| Trigger（触发器） | 什么事件启动这个 loop？（时间表、git push、PR 开启、外部 webhook） | Loop 永远不运行，或在错误时机运行 |
| Inputs（输入） | Loop 启动时 Agent 收到什么上下文？（任务描述、相关文件、历史状态） | Agent 在错误假设下运行，输出偏离目标 |
| Action（动作） | Agent 被授权做什么？（写文件、调用 API、提交代码、调用子 Agent） | Loop 无法执行实际工作 |
| Check（检查） | 输出如何被验证？（运行测试、lint、类型检查、LLM-as-judge） | Loop 永远「成功」，即使输出是错的 |
| Stop（退出） | 在什么条件下 loop 终止？（目标达成、最大重试次数、人工干预请求） | Loop 无限运行，消耗 API 配额直到耗尽 |
Trigger 和 Stop 是最容易被忽略的两个，但它们恰恰是最重要的两端——一个控制 loop 何时开始，一个控制它何时结束。一个没有可靠退出条件的 loop 是一个不受控制的成本中心。
评估难题：pass@k vs pass^k
当 loop 中的 Agent 行为是非确定性的，传统的测试思路会失效。Anthropic 工程博客（Demystifying Evals for AI Agents）明确定义了两个关键指标：
- pass@k：在 k 次尝试中，至少有一次正确的概率
- pass^k：在 k 次尝试中，全部正确的概率
两者在 k=1 时相同。但随着 k 增大，它们告诉的是完全相反的故事：
| k（尝试次数） | pass@k（至少一次成功） | pass^k（全部成功） | 工程含义 |
|---|---|---|---|
| 1 | p | p | 两者一致 |
| 5 | 1-(1-p)⁵ | p⁵ | 已开始分化 |
| 10 | → 接近 100% | → 接近 0% | 完全相反 |
（假设每次独立成功概率为 p = 0.7）
这个分化揭示了一个根本性的设计选择：
- 如果你在设计 loop，你需要的是 pass^k——每次运行都要可靠，因为你的系统会依赖这些输出做下游决策。一个 10 次里有 3 次失败的 Agent 会让整个 pipeline 产生静默错误。
- 如果你在评估能力边界，pass@k 更合适——它告诉你这个模型是否"会"这件事，而不是它在生产中是否"稳定"。
混用这两个指标是 loop 评估中最常见的错误：用 pass@k 评估出来的"高分"放到 pass^k 要求的生产环境里，结果一塌糊涂。
自主 loop 的安全代价
让 loop 完全自主运行，引入了两类在手动提示场景中不存在或影响极小的安全威胁：
威胁一：Agentic Denial of Service / "Denial of Wallet"
攻击者通过向 loop 注入逻辑悖论或触发自我繁殖的子任务，使 API 调用量爆炸式增长，在短时间内耗尽预算。
这不是理论威胁。Sysdig 记录的一起真实事件中，AWS Bedrock 上的一个被入侵的 loop 系统产生了 每天 46,000 美元的 API 费用（即"LLMjacking"）；另一起事件中，一个泄露的 Google Gemini API key 在 48 小时内累计消费 82,000 美元（2026 年 3 月）。OWASP LLM Top 10 2025 将此列为 LLM10（Unbounded Consumption）。
威胁二：间接提示注入（Indirect Prompt Injection）
Loop 需要从外部环境（网页、代码库、邮件、数据库）读取内容并处理。这些内容本身可以携带隐藏的恶意指令，当 Agent 处理时，指令会被执行——攻击面从「你的提示词」变成了「你的检索数据」。
CVE-2025-32711（EchoLeak）是一个已确认的实例：攻击者通过构造恶意邮件内容，触发 Microsoft 365 Copilot 执行了未授权的操作，完整利用了间接提示注入漏洞。OWASP LLM01（Prompt Injection）将此列为头号风险。
| 威胁类型 | 攻击向量 | 已知事件 | 防御原则 |
|---|---|---|---|
| Agentic DoS / Denial of Wallet | 逻辑悖论、自繁殖子任务 | AWS Bedrock $46K/天、Gemini key $82K/48h | 硬性 token/cost 上限；最大迭代次数；预算断路器 |
| 间接提示注入 | 被检索的外部内容（邮件、网页、文档） | CVE-2025-32711 (EchoLeak, M365 Copilot) | 输入隔离；最小权限工具调用；输出内容标记 |
两者都有一个共同根源：loop 将对外部内容的信任程度从「只读」提升到了「可执行」。手动提示场景下，人类在循环里充当隐式的过滤器；全自主 loop 把这个过滤器移除了。
正当的质疑：这只是改了名字的 cron 吗？
Loop engineering 面临一个相当尖锐的批评：这不就是 Airflow、Temporal、cron job 加上了 LLM 吗？
这个批评有其道理。把这些任务编排工具替换成"loop engineering"的底层机制，并没有发生本质变化——你依然需要触发器、状态管理、错误处理、重试策略。StationX 等质疑者直接将其标注为"rebranded automation"。
这个质疑目前没有被实证反驳。Loop engineering 领域缺乏：
- 任何经同行评审的学术论文对这个概念做出形式化定义
- 受控对比实验，证明"loop engineering 思维"相较于"workflow orchestration 思维"在系统设计质量上有可量化优势
- 一个被广泛接受的正式定义（截至 2026 年 6 月 28 日，这个术语只有约三周历史）
但批评不能成立的地方在于：即使底层机制相似，概念框架改变了工程师关注的问题。将 Agent 纳入循环的核心，迫使你面对一组传统 workflow 工程不需要正面处理的问题——非确定性的评估（pass@k vs pass^k）、间接提示注入攻击面、基于 token 而非时间或资源的成本模型，以及对"Agent 自主性边界"的问责机制。
这不等于说 loop engineering 是一门独立学科；它可能只是 harness engineering 的一个专门化分支。但它也不是单纯的重新命名。
尚未回答的问题
研究过程中，有四个问题没有找到令人满意的答案，它们代表着这个领域真正的前沿：
-
Loop engineering 和 Airflow/Temporal/LangGraph 的形式边界在哪里？ 有没有一个可操作的判断标准，而不只是"加了 LLM"？
-
pass@k 和 pass^k 在层级化多 Agent 系统中如何重新定义？ 当子 Agent 的非确定性叠加时，这两个指标还适用吗，还是需要重新建模？
-
一个完全自主的 loop 产生数据丢失或安全事件时，问责边界在哪里？ 电路断路器、审计日志、人工介入门控——哪些属于工程最佳实践，哪些应该成为合规要求？
-
当"模型"本身是一个多 Agent loop 时，test-time scaling 的策略建议（问题难度×模型类型×计算预算）如何调整？ arXiv 2512.02008 的结论是针对单一 LLM 的——loop 场景下它的推论是什么？
结论
Loop engineering 是真实的——但它目前还是实践先行于理论的状态。Boris Cherny 的那句话描述了一个真实发生的工作方式转变：从手动驱动 Agent，到设计驱动 Agent 的系统。Addy Osmani 给了它一个名字和一套初步框架。但这个领域还没有经过足够时间的检验。
我的判断：这是一个值得追踪的真实方向，但不值得现在就全面押注。 具体来说：
- 应该做的：开始识别你现有工作流中哪些手动提示循环可以被自动化驱动，先建一个小的、有硬性退出条件和成本上限的 loop，验证 pass^k 达标后再扩大范围。
- 不应该做的：把所有 Agent 交互都"loopify"，或者在没有可靠检查机制的情况下让 loop 完全自主运行——这是通往 denial of wallet 和静默错误积累的捷径。
- 需要盯住的：pass^k 而不是 pass@k；Stop 条件和 Check 条件的设计质量；外部输入的信任边界。
Cherny 说他的工作是写 loop。在那个层级工作是真实的杠杆。但一个写得不好的 loop，比一个写得不好的提示词，代价大一个数量级。
参考资料
- Boris Cherny (Anthropic) — Meta @Scale 大会发言（2026 年 6 月），多家二手媒体转载
- Cobus Greyling — Loop Engineering — The core of Loop Engineering（Medium，2026 年 6 月）
- Addy Osmani — Loop Engineering（addyosmani.com，2026 年 6 月 7 日）
- Ben Dickson — Demystifying loop engineering: Get more from AI agents, avoid loopmaxxing（TechTalks，2026 年 6 月 22 日）
- Anthropic Engineering — Demystifying Evals for AI Agents
- arXiv 2512.02008 — The Art of Scaling Test-Time Compute for Large Language Models（2025 年 12 月）
- OWASP — LLM Top 10 2025: LLM01 Prompt Injection / LLM10 Unbounded Consumption
- CVE-2025-32711 — EchoLeak: Indirect Prompt Injection via Email Content in Microsoft 365 Copilot
- Sysdig — LLMjacking on AWS Bedrock ($46,000/day incident documentation，2026 年）
- truongpx396 — The Agentic Loop: A Practical Field Guide（DEV Community，2026 年 6 月 25 日）
- arXiv 2510.23883v2 — Agentic AI Security: Threats, Defenses, Evaluation, and Open Challenges