2026 年 6 月的同一周,两个AI大佬几乎说了同一句话。
Boris Cherny,Claude Code 的创始人,在推特上写道:
Peter Steinberger,OpenClaw 的创始人,在同一周的博客中说:
两个不同背景、不同产品的人,得出了相同的结论。这不是巧合,这是范式转移的信号。
一个新的工程学科正在浮现——Loop Engineering。

四大概念对比
一句话定义: Loop Engineering 是设计和优化 AI 自主运行循环的工程实践。它关注的不是「如何写好一个 prompt」,而是「如何设计一个让 AI 能持续、自主、可靠地完成任务的循环系统」。
| 维度 | Prompt Engineering | Agent Engineering | Loop Engineering |
|---|---|---|---|
| 工作单元 | 单次 prompt-response | 多步任务编排 | 持续运行的循环 |
| 人的角色 | 每次都要写 prompt | 设计 Agent 逻辑 | 设计 Loop 结构 |
| AI 的角色 | 被动回答 | 半自主执行 | 自主循环运行 |
| 可靠性来源 | prompt 质量 | Agent 规划能力 | Loop 的收敛设计 |
| 典型产出 | 一段文本 | 一个完成任务的 Agent | 一个持续运行的系统 |
一个典型的 Loop 包含 5 个要素:
这不是一个简单的 for 循环,而是一个有收敛条件的自适应循环。好的 Loop 会越跑越精准,坏的 Loop 会无限打转。
上一个话题我们聊了 Harness Engineering。很多人会问:Loop 和 Harness 有什么区别?
答案是:它们是同一枚硬币的两面。
Harness 是 Loop 运行的基础设施,Loop 是 Harness 上跑的行为模式。
想象一辆赛车:
没有赛道,赛车跑不起来。没有跑法,赛道只是个空壳。
| 维度 | Harness Engineering | Loop Engineering |
|---|---|---|
| 关注点 | 运行环境和中间层 | 行为模式和迭代策略 |
| 核心问题 | Agent 能访问什么工具?如何管理状态? | Agent 如何观察-决策-行动-评估-迭代? |
| 设计产物 | 环境配置、工具链、状态管理 | 循环结构、收敛条件、迭代策略 |
| 衡量指标 | Token 效率、轨迹长度、环境利用率 | 收敛速度、任务完成率、自主程度 |
| 典型论文 | Recursive Agent Harnesses (2026-06) | Agentic Loop Patterns (2026-05) |
在实践中,两者密不可分:
复制代码Harness(基础设施层)
├── 文件系统工具
├── 代码执行环境
├── 状态管理器
└── 错误处理机制
│
└── Loop(行为模式层)运行在 Harness 之上
├── Observe:读取 Harness 提供的环境状态
├── Decide:基于目标选择下一步行动
├── Act:调用 Harness 提供的工具
├── Evaluate:检查结果质量
└── Iterate:决定是否继续循环
关键洞察: Harness 决定了 Loop 的「能力上限」,而 Loop 决定了 Harness 的「价值释放」。一个好的 Harness 配一个差的 Loop,就像一条好赛道配一个不会开车的司机。
SuperPower 是 2024-2025 年间流行的一个概念——通过精心设计的 prompt 和工具链,让 AI 展现出「超能力」般的表现。
| 维度 | SuperPower | Loop Engineering |
|---|---|---|
| 哲学 | 让 AI 在单次任务中表现惊人 | 让 AI 在持续运行中稳定可靠 |
| 设计目标 | 最大化单次输出质量 | 最大化长期运行的收敛性和自主性 |
| 失败模式 | 单次表现惊艳但不可重复 | 单次表现平淡但持续进步 |
| 人的参与度 | 每次都需要人触发和校准 | 设计一次,长期自主运行 |
| 适用场景 | 创意生成、代码编写、文档撰写 | 持续监控、自动修复、知识积累 |
SuperPower 方式: 你每天给 AI 一个精心设计的 prompt,让它帮你做代码审查。每次审查都很出色,但你每天都得写 prompt。
Loop Engineering 方式: 你设计一个 Loop,让 AI 自动监听 Git 提交,每次有新代码就自动审查,发现问题自动创建 issue,审查质量通过反馈机制持续提升。你只需要设计一次 Loop。
SuperPower 和 Loop Engineering 不是替代关系,而是互补关系:
最好的实践是:用 SuperPower 的方法提升 Loop 中每一步的质量,用 Loop Engineering 的方法让这些步骤自主运行。
RalphLoop 是 2025 年底出现的一个开源项目,它实现了一个简单的 Agent 循环框架。Loop Engineering 作为一个工程学科,与 RalphLoop 这个具体实现有何不同?
| 维度 | RalphLoop | Loop Engineering |
|---|---|---|
| 性质 | 具体的开源框架/工具 | 工程学科/方法论 |
| 类比 | React 之于前端工程 | 前端工程本身 |
| 关注点 | 实现一个可用的 Agent 循环 | 设计最优的循环策略和模式 |
| 成熟度 | 原型级,适合学习和实验 | 工程级,面向生产环境 |
| Loop 模式 | 单一的 observe-act 循环 | 多种 Loop 模式(收敛、探索、修复、学习) |
RalphLoop 是一个很好的起点,但它有几个工程级场景下的局限:
Loop Engineering 作为学科,提供了 RalphLoop 缺失的工程实践:
在 Loop Engineering 的语境下,Goal(目标)是一个核心概念。没有明确目标的 Loop 只是一个死循环。
| 关系类型 | 描述 | 示例 |
|---|---|---|
| Goal-as-Target(目标靶) | Loop 持续向 Goal 收敛 | 「把 API 响应时间降到 200ms 以下」 |
| Goal-as-Constraint(目标约束) | Loop 在 Goal 约束下优化其他指标 | 「在准确率 > 95% 的前提下,最小化推理成本」 |
| Goal-as-Direction(目标方向) | Loop 朝 Goal 方向前进,但不要求精确到达 | 「持续提升代码可读性」 |

根据 2026 年的实践总结,Loop Engineering 有 5 种核心模式:
适用场景: 有明确目标和度量标准的任务
复制代码while not goal_reached(state):
observation = observe(environment)
action = decide(observation, goal)
new_state = act(action)
progress = evaluate(new_state, goal)
if progress < threshold:
break # 收敛停滞,退出
state = new_state
典型案例: 自动代码优化、自动测试生成、自动文档补全
适用场景: 目标不精确,需要边探索边明确
复制代码while budget > 0:
candidates = generate_hypotheses(current_knowledge)
best = select_most_promising(candidates)
result = test(best)
update_knowledge(result)
budget -= cost(result)
典型案例: 研究调研、方案探索、竞品分析
适用场景: 持续监控并修复问题
复制代码while monitoring:
issues = detect_problems(environment)
for issue in prioritize(issues):
fix = generate_fix(issue)
if validate(fix):
apply(fix)
else:
escalate_to_human(issue)
sleep(interval)
典型案例: 自动 bug 修复、安全漏洞修复、性能问题修复
适用场景: 需要从历史中学习并改进
复制代码for task in task_queue:
strategy = select_strategy(task, past_experience)
result = execute(strategy)
feedback = collect_feedback(result)
update_experience(task, strategy, feedback)
refine_strategies(feedback)
典型案例: 客服问答优化、推荐策略调整、写作风格适应
适用场景: 复杂任务需要分解为子任务
复制代码def recursive_loop(task, depth=0):
if is_simple(task):
return solve_directly(task)
if depth > max_depth:
return escalate(task) subtasks = decompose(task)
results = []
for subtask in subtasks:
result = recursive_loop(subtask, depth + 1)
results.append(result) return synthesize(task, results)
典型案例: 复杂代码重构、多步骤研究、跨领域分析

在写任何代码之前,先回答 3 个问题:
根据任务性质选择:
| 任务类型 | 推荐模式 | 理由 |
|---|---|---|
| 优化已有代码 | 收敛型 | 有明确目标(质量指标) |
| 调研新技术 | 探索型 | 目标不确定 |
| 监控系统健康 | 修复型 | 持续运行 |
| 改进用户体验 | 学习型 | 需要从反馈中学习 |
| 重构大型系统 | 递归型 | 任务可分解 |
以一个「自动代码审查 Loop」为例:
复制代码# Observe: 检测新的代码变更
new_commits = git.detect_new_commits(branch="main")for commit in new_commits:
# Decide: 确定审查策略
review_plan = ai.plan_review(
code_diff=commit.diff,
context=commit.related_files,
standards=team.coding_standards
) # Act: 执行审查
review_result = ai.execute_review(review_plan) # Evaluate: 检查审查质量
quality_score = evaluate_review(review_result)
if quality_score < 0.7:
# 质量不够,重新审查
review_result = ai.execute_review(review_plan, attempt=2) # Iterate: 将结果反馈到知识库
knowledge_base.add(commit.id, review_result) # 创建 issue(如果发现问题)
for issue in review_result.issues:
if issue.severity >= "high":
github.create_issue(issue)
任何 Loop 都必须有安全边界,否则可能失控:
max_iterations = 50max_tokens_per_loop = 100_000max_duration_minutes = 30escalate_after_n_failures = 3auto_revert_if_tests_fail = True 复制代码# 每次循环记录
loop_metrics.log({
"iteration": i,
"tokens_used": token_count,
"duration_seconds": elapsed,
"progress_toward_goal": goal_distance,
"actions_taken": action_count,
"errors_encountered": error_count,
"escalated_to_human": escalated
})
在让 AI 自主运行之前,先手动执行几次,确认流程正确。Loop 放大了错误,也放大了正确。
「提升代码质量」 → 「将圈复杂度 > 15 的函数数量从 23 降到 5」
不要在一个循环里让 AI 同时做 10 个决定。拆分循环,每个循环聚焦一个决策。
每个 Loop 都必须回答:什么情况下我应该停下来?
不要在 Loop 里硬编码工具调用。通过 Harness 提供工具,Loop 只负责编排。
Loop 的每一步都应该知道:
| 错误类型 | 处理方式 |
|---|---|
| 临时性错误(网络超时) | 自动重试(最多 3 次) |
| 逻辑错误(AI 做出了不合理的决策) | 回退到上一个检查点 |
| 系统性错误(Loop 设计有问题) | 停止 Loop,升级到人工 |
Loop 不需要每次循环都完美。它需要的是整体趋势向好。如果 Loop 在 10 次循环后比 1 次循环后好了 30%,那就是成功的 Loop。
每运行 100 次 Loop,回顾一次:
不要一上来就设计递归型 Loop。从最简单的收敛型开始,验证基本流程,然后逐步增加复杂度。
如果你是技术负责人,Loop Engineering 给你 3 个具体的行动建议:
找出团队中「每天都在手动 prompt AI 做同一类任务」的场景。这些就是 Loop Engineering 的最佳起点。
常见候选:
不要试图一步到位。选一个简单场景(比如自动代码审查),按上面的 5 步指南设计你的第一个 Loop。
Boris Cherny 和 Peter Steinberger 在同一周说出相同的话,不是因为他们商量好了,而是因为他们都在实践中发现了同一个规律:
当 AI 足够强大时,瓶颈不再是「AI 能做什么」,而是「AI 能自主做多久」。
Prompt Engineering 解决了「AI 能做什么」。Agent Engineering 解决了「AI 能做多复杂的任务」。Harness Engineering 解决了「AI 在什么环境中做」。Loop Engineering 解决了「AI 能自主、持续、可靠地做」。
这不是取代关系,而是叠加关系。每一层都建立在前一层之上。
对于技术负责人和 AI 从业者来说,Loop Engineering 不是「未来要学的东西」,而是「现在就该开始实践的东西」。
从今天开始,别再手动 prompt 了。设计一个 Loop,让 AI 自己跑起来。
原文来源于公众号文章: mp.weixin.qq.com/s/OC0YjjeQn…