2026 年 7 月,硅谷突然火了一个词:Agent Loop。
引爆点是 Open Cloud 创始人 Peter Stenberg 发了一句话:"我们所有人都应该停止写 Prompt,应该转向去为你的 Agent 设计 Loops。" 这句话 24 小时内获得了两百多万的浏览量。
紧接着,Cloud Code 的创始人 Boris 在访谈里说:"我现在根本不写 Prompt。我的工作就是设计 Loops。"
我看了之后的感觉很复杂——一方面觉得"这个方向我做了半年了",另一方面也觉得"终于有一个词能描述清楚我在做什么了"。
这篇文章把我的理解和实践串起来,讲清楚三个问题:
先别有什么心理负担。这个概念本质很朴素。
你写程序的时候写过 while 循环吗?就是 while (条件成立) { 做一件事 }。Agent Loop 就是把这个思路搬到 AI 系统里。
不是让模型一次性回答,而是让模型在一个循环里反复执行:"想一下 → 做一步 → 看看结果 → 再想一下"。
这个循环的每一圈叫一次迭代。一个复杂任务可能需要三五圈甚至十几圈。每一圈的开销就是一次 LLM 调用 + 工具调用。
但 Agent Loop 不是只有这一层。真正让懂行的人兴奋的,是循环可以嵌套、可以组合、可以形成多层体系。
理解了这个三层结构,你就理解了 Loop Engineering 的核心:不是一个循环解决所有问题,是多个循环分层协作。
回头看我自己搭了半年的 Harness 体系:
这是最底层的循环。模型在里面"想→做→看"反复循环。没有这个循环,Agent 只是一个高级聊天机器人。有了它,Agent 能调用工具、能多步推理、能基于实时信息决策。
对应 Harness 什么? Harness 不替代这个循环——它是这个循环的基础设施。上下文管理给循环提供高质量的输入,输出约束给循环设定产出格式。
这是套在 ReAct Loop 外面的第二层循环。ReAct 每产出一个结果,Quality Loop 检查一次。不通过就回到 ReAct 重新生成,通过就放行。
对应 Harness 什么? 验证闭环。三层检查:格式 → 语义 → 安全。每一层都是一个判断节点,不通过就走修正路径。
这个 Loop 的关键设计参数是阈值——多严格才算通过。阈值太松,垃圾输出放过去;太严,好输出也被卡住。我在实践中发现这个阈值需要根据不同任务动态调整——复杂任务可以松一点,安全敏感任务必须严。
Quality Loop 发现了问题,修正了,但如果不记住,下次同样的坑还会再踩。Learning Loop 就是在每次循环结束后,把经验提取出来固化为可复用的东西。
对应 Harness 什么? 知识沉淀 + 记忆系统。从 Session 到 Skill 的管道,就是这个 Loop 的具体实现。
这是最大的一层循环。不关心一次对话的质量,关心的是系统整体的进化。采集所有下级 Loop 的运行数据 → 分析模式 → 发现问题 → 生成改进方案 → 部署 → 继续观察。
对应 Harness 什么? 自进化引擎。就是这两天刚写完的那套代码。
Peter Stenberg 那句话说得很绝对,但他说到了点子上。
Prompt 是一次性的。你写了一个 Prompt,用在特定的场景、特定的上下文、特定的模型。换一个场景,Prompt 要重写。换一个模型,Prompt 可能不生效。迭代 Prompt 到一定程度后,收益急剧递减——改一次 Prompt 提升 2%,但调试花了半天。
Loop 是可复用的。你设计了一个 Quality Loop,它可以用在任何 Agent 上。你设计了一个 Retry Loop,它在所有场景下的行为一致。Loop 跟 Prompt 的核心区别:
| 维度 | Prompt | Loop |
|---|---|---|
| 复用性 | 差,换场景基本重写 | 强,配置化可复用 |
| 可调试性 | 差,出问题不知道是哪句 Prompt 导致的 | 强,每个 Loop 独立可观测 |
| 确定性 | 低,模型自由发挥 | 高,有检查和修正机制 |
| 进化能力 | 无,靠人工改 | 有,可以自进化 |
| 管理成本 | 低,写一个字符串就行 | 高,需要设计测试和运维 |
所以"不写 Prompt"的意思是:不要靠一个无所不能的 Prompt 解决所有问题。改成设计多个专门负责一件事的 Loop,让它们协同工作。
在我的系统里,没有一个"终极 Prompt"。Harness 的四根缰绳、记忆系统的三层模型、自进化引擎的五层架构——全是不同的 Loop 在各自的职责范围内运转。
市面上最新的一份 Loop Engineering 手册给出了五步设计流程,我用自己的语言翻译一遍:
不要把整个任务丢给一个 Loop。拆开。我写文章让 Agent 帮我,拆成了四个独立的 Loop:研究 Loop(查资料)→ 写作 Loop(写初稿)→ 审计 Loop(检查质量)→ 发布 Loop(上线)。每个 Loop 只做一件事。
对照你的系统: 你的 Multi-Agent 编排模式就是在做这件事。Supervisor 负责拆,Worker 负责干。
每个 Loop 需要一个"专家"——要么是一个专门的 Agent,要么是一个专门的 Skill。专家的能力范围要窄(不要一个专家什么都会),深度要够。
对照你的系统: 你的每个 Skill 就是一个专家。从 Session 到 Skill 的管道,就是在"培养专家"。
Loop 之间怎么传数据?是同步还是异步?超时怎么办?失败怎么通知?
对照你的系统: delegate_task 在做这件事。但目前通信协议没有标准化——每个 Worker 返回什么格式,没有统一约定。
这是最容易被忽略的一步。每个 Loop 的输入输出格式、错误码、调用约定——需要白纸黑字写下来。市面上有人用 claude.md 做这件事。你在用 SKILL.md。
对照你的系统: SKILL.md 目前只描述了"这个 Skill 做什么",还没有标准化"输入输出格式"和"错误处理"。这是一个可以升级的方向。
上线前检查:每个 Loop 有没有最大迭代次数?有没有超时设置?失败回调有没有定义?日志有没有打开?
对照你的系统: 自进化引擎里的 system_config 表就是做这个的。但目前是代码级的,还没有变成可视化的检查清单。
这篇文章不是为了介绍一个新概念。是为了让你看清楚:
一句话: 你不需要学 Loop Engineering——你已经在用它了。你需要的是给它一个名字,然后把你已经做的东西用 Loop 的视角重新表述一遍。用这个新视角,可能帮你发现之前忽略的缺口和新的优化空间。
💬 评论