Loop Engineering 深度解读：从 Prompt 到自主智能体的工程跃迁

一问一答的是 Chatbot，会自己盯着目标把活干完的才是 Agent——差距就在一个"循环"。

本文系统梳理 Loop Engineering（循环工程）的概念起源、演进脉络、技术架构、典型模式、失败护栏、应用场景与未来走向，帮助读者从工程视角理解"让智能体真正自主"的那一环。

一、为什么需要 Loop Engineering

在 2020 年代早期，与大语言模型（LLM）交互的主流范式是"单轮"——即 Prompt。成功的标准是：人能把多少意图塞进一段文本里。到了 2024 年，这种范式演化为"链式调用"（chaining）；2025 年初又稳定为 Andrej Karpathy 所说的"Vibe Coding"（凭感觉编码）。但进入 2026 年中期，单次 Prompt 能达到的上限已经被触及 [1]。

新的工程表面不再是 Prompt，而是 Loop（循环）。

核心矛盾在于：真实任务几乎从不是一次性的。一个单次的"提问—回答"可以回答问题，却无法修复一个失败的测试、重构一个模块、或完成"第三步依赖第二步返回结果"的多步任务。Prompt 工程假设的是单次交互——你给输入、模型给输出。但现代 AI 智能体不是这样工作的：它们在循环中观察环境、推理下一步、采取行动、验证结果，然后决定是继续还是停止 [2][3]。

一个关键洞察是：两个基于同一模型构建的智能体，表现可以天差地别。 智力相同、Loop 设计不同——一个放弃或在原地打转，另一个能检测到失败、修订计划并完成任务。Loop Engineering，就是拉开这层差距的那门工程 [3]。

Steinberger 指出："你不应该再去 Prompt 编码智能体了。你应该设计那些去 Prompt 智能体的 Loop。" [4][5]

Anthropic Claude Code 负责人 Boris Cherny 说："我不再 Prompt Claude 了。我让 Loop 运行，Loop 去做这些工作。" [4][5]

Karpathy 则强调：要把你自己从瓶颈中移除——"安排好一切让它们完全自主，然后按下 go。" [5]

二、概念定义：Loop Engineering 到底是什么

2.1 权威定义

IBM 给出的定义是：Loop Engineering 是设计代理式工作流（即"循环"）的实践，这些循环以迭代方式引导 AI 智能体在最少人工介入下完成用户定义的目标。 与其在每一步都要求人工 Prompt 不同，智能体循环让智能体能够动态地行动、观察、做决策并迭代，直到任务完成 [2]。

对开发者而言，Loop Engineering 将其角色从"向 AI 智能体写 Prompt"重新定位为"设计那些去 Prompt、检查和引导智能体的自动化系统"。在一个设计良好的循环内，智能体能够推理、行动、审查其行动的结果，并相应地调整后续行动 [2]。

2.2 Loop Engineering vs Prompt Engineering

一个关键论断来自 Steinberger 与 Osmani 2026 年 6 月的开创性文章《Loop Engineering: The Architecture of Autonomous Iteration》：AI 的"价值单元"已从 response（响应） 转移到 trajectory（轨迹）。如果模型在第一轮产出了一个 bug，没关系——只要系统能检测到 bug、执行测试、并在第四轮修复它。工程师的目标，就是设计这个"四轮循环"的边界与目标函数 [1]。

2.3 与上下文工程、线束工程的关系

Loop Engineering 是构建可靠智能体的一个层次，与另外两个相伴：

• Loop Engineering 设计的是"循环"本身——智能体如何一轮轮迭代；
• Context Engineering（上下文工程） 决定每一轮循环里模型"看到什么"——如何打包工具、文档、历史，塞进 200k+ token 窗口；
• Harness Engineering（线束工程） 是包裹在模型外的整套系统——循环、上下文管理、工具、记忆、沙箱 [3]。

用坐标轴来理解：Anthropic 2025 年 9 月的文章聚焦"横轴"——如何把工具、文档、历史打包进上下文窗口；而 Loop Engineering 聚焦"纵轴"——模型说完话之后，下一步发生什么的逻辑 [1]。一个设计精良的 Loop 若上下文管理糟糕，依然会失败，因此这三门学科最好一起学 [3]。

三、发展脉络：从 Prompt 到 Loop 的演进史

理解 Loop Engineering 的最佳方式，是看清它是如何从之前的范式一步步演化而来的。

3.1 四级智能层级

业界对模型交互模式可以区分为四个层次，混淆"链"与"循环"是早期许多代理式原型无法走向生产的首要原因 [1]：

1. Prompt（一次性）：Input → Model → Output。无状态、无反馈机制。输出错了，流程就结束。
2. Chain（有向无环图）：Prompt A 的输出作为 Prompt B 的输入。是"轻量循环"，但没有返回路径。脆弱，因为第一步的错误会线性传播。
3. Workflow（分支）：带 if/else 逻辑的链。硬编码路径决定调用模型 A 还是 B。这是传统 RPA 加上 LLM 的领域。
4. Loop（迭代）：模型进入 Plan → Act → Observe → Evaluate → Revise 的循环，直到目标停止条件被满足或资源预算耗尽 [1]。

正如 Simon Willison 所论证的，循环是第一个展现出"涌现式问题解决"能力的模式：链能照着菜谱走，而循环能调试一个它从未见过的失败测试用例 [1]。

3.2 Vibe Coding 到 Agentic Engineering 的弧线

2025 年 2 月，Karpathy 在一条爆款推文中创造了"Vibe Coding"一词，描述开发者花更少时间写语法、更多时间与模型"凭感觉"协同的工作流。然而"凭感觉"缺乏严谨——它对 Todo 应用有效，在架构层面却会崩塌。到 2026 年 Sequoia 演讲时，Karpathy 重新框架了这一点：这些"感觉"其实是 Agentic Engineering 的前奏。开发者的角色正在从"编码者"变为"线束设计者" [1]。

单次 Prompt 触及天花板，是因为 LLM 在统计上容易"漂移"——在真空中，模型犯致命错误的概率随任务复杂度上升。基于循环的系统（如 Devin、Claude Code、以及受 Simon Willison "LLM-as-CLI" 实验启发的开源变体）通过引入 环境反馈 打破了这个天花板 [1]。

一句话总结这段历史：Prompt 已死，循环是它的继任者。工程表面已从输入字符串转移到执行周期。 [1]

四、核心架构：一个 Loop 由什么构成

4.1 标准 Agentic Loop

智能体循环通常遵循一个标准模式，可概括为四个阶段 [2]：

1. Goal（目标）：一个在循环每次迭代中都被递归评估的目标，帮助智能体保持聚焦、防止不必要的迭代并控制 token 成本。递归目标给智能体明确靶心，包括清晰可验证的停止条件。"让我的网站加载更快"是模糊的；"当代码通过所有单元测试并满足需求时停止迭代"则是可测量的 [2]。
2. Action（行动）：智能体考虑目标与当前进度后行动。行动可能是生成代码、运行单元测试或修复 bug [2]。
3. Observation（观察）：系统评估行动结果。例如在自动代码生成中，运行 CI 测试看代码是否通过 [2]。
4. Adjustment（调整）：基于观察，系统评估反馈并在重启循环前调整方法 [2]。

更精炼的表述是 reason → act → observe——推理、行动、观察，外面包一层"目标是否达成"的检查来决定是否再迭代一轮 [3]。这一模式可追溯到 ReAct（Reason + Act，Yao 等人 2023 年提出），它把模型的推理与工具调用交错，此后经由 Reflexion（自我批判）、Plan-and-Execute 以及现代编码智能体的长时"while not done"循环演化而来 [3]。

4.2 Loop 的八大组件

要从"凭感觉的脚本"走向生产系统，需要架构以下八个组件 [1]：

1. 目标：北极星，必须具体且理想情况下可验证。"重构认证逻辑"是糟糕的目标；"把 auth.py 从 session 改为 JWT 同时保持 100% 测试覆盖率"是可循环的目标 [1]。
2. 状态：世界的当前表示。状态管理是 Loop 设计最困难的部分——状态增长过大会让模型在"噪音"中丢失"信号" [1]。
3. 模型调用：LLM 是大脑。同一循环内不同环节可用不同模型——快速模型做工具选择，推理模型做核心评估 [1]。
4. 工具：模型可调用的函数，遵循 MCP（Model Context Protocol，Anthropic 2024 年 11 月发布）标准化接口 [1]。
5. 观察：工具执行的输出。循环的价值完全依赖这些观察的质量 [1]。
6. 评估器：一个常被"凭感觉编码"的智能体遗漏的关键组件——决定上一步是否让系统更接近目标的次级逻辑门 [1]。
7. 记忆：过去尝试的记录。没有记忆，循环会陷入"无限递归"，反复尝试同一个失败命令 [1]。
8. 停止条件与预算：安全护栏。循环必须在目标达成、达到最大迭代次数、或 token/美元预算超限时终止 [1]。

4.3 伪代码：最小可运行循环

一个最小而完整的 Loop 骨架大致如下 [1][2]：

def migration_loop(target_schema, sample_data):
    # 1. 目标 + 预算
    budget = ResourceBudget(max_iterations=20, max_tokens=50000)
    plan = agent.generate_plan(target_schema)

    # 2. 循环：Act → Observe → Adjust
    while not testing_harness.passed(plan) and budget.can_continue(state):
        logs = testing_harness.run(plan, sample_data)   # Action + Observation
        if logs.contains_errors():
            plan = agent.reflect_and_fix(plan, logs)     # Adjustment
        else:
            break
        state.update(plan, logs)                          # Memory / State

    return plan

注意核心分工：模型负责"走哪一步"，工程负责"整段路怎么走、何时到站"。 循环、终止、状态更新这些骨架必须写在代码里，而不是嵌进 Prompt 里求模型自觉 [6]。

五、技术架构：六层闭环与四层堆叠

业界对 Loop 的架构有两种高度互补的切分方式：六层闭环架构（从"自改进"视角）与四层堆叠循环（从"循环叠加"视角）。

5.1 六层闭环架构

当下生产中大多数 AI 智能体是"glorified function call（美化的函数调用）"——接收输入、推理、输出，响应流回的那一刻就忘了一切。周一上线，六周后依然和第一天一样"聪明"：同样的边界情况、同样的错误答案。这是一个开环系统 [7]：

Input → Process → Output → (stop)

闭环系统则不同 [7]：

Input → Process → Output → Feedback → Improve → (回到 Input)

那条弯回起点的箭头，就是全部的关键。但它不是魔法——闭环由六层真实的架构决策撑起，每层都有真实的权衡 [7]：

一个关键判断：校验胜过更大的模型。 一个单独的子智能体对照政策和已知失败模式检查输出，才是把 60% 的智能体提升到 90% 的关键——因为模型抓不到自己的盲点 [7]。

重要澄清：循环不会让模型更聪明，模型权重从不改变。改变的是系统带入每一轮的上下文。记忆是让反馈累积而非归零的基底 [7]。

六层缺一不可，且会以不同方式失败：有触发器没记忆只是自动化；有记忆没校验是"自信地记住错误答案"；有校验没连接器是"智能体在评判它从未真正做过的工作"。只有六层齐备且按序连接，循环才会复利 [7]。

5.2 四层堆叠循环（Loopcraft）

LangChain 与 swyx 提出的"Loopcraft（循环工艺）"视角认为：智能体由内向外是循环的堆叠，每一层循环扩展上一层的能力 [8][5]。

前三层循环"自动化工作"，第四层（也是最重要的）"自动化改进"。每一次外循环的转动，都让内循环更有效——返回的箭头不只是回到顶部，而是直接伸进去更新智能体循环本身 [8]。

swyx 把这个时代命题称为**"Agent 的咸味教训（Salty Lesson）"**：不要像过去那样自己亲手修东西，而要聚焦于随更多智能体扩展的系统——目标和编排。在早期，知道何时"向下"钻进一个循环（为了可靠性）有价值；但知道如何"向上"升级一个循环（为了杠杆）随模型进步会更有价值 [5]。

Satya Nadella 把组织层面的利害关系概括为：尽早构建学习循环的公司，会建立难以复制的优势 [8]。

5.3 IBM 的组件视角

IBM 则从组件清单角度描述一个设计良好的循环，通常包含以下要素 [2]：

• Automations/Scheduling（自动化/调度）：重复是循环区别于一次性 Prompt 的本质。GitHub Actions、cron job 设定循环的节奏。
• Hooks（钩子）：由事件（生成代码、编辑文件、调用工具、完成任务）触发的指令，发生在事件前或后。用于安全和质量——把治理和质量检查从循环里的智能体上移走，降低 token 成本。
• Context Engineering（上下文工程）：每轮循环产生的"上下文"喂给后续轮次。策略包括对历史迭代做摘要压缩、用 markdown 改善上下文结构。
• Tool Access（工具访问）：通过 MCP 服务器及其他 API/集成让智能体执行自主动作。没有工具访问，智能体只能描述"会做什么"而无法真正行动。
• Worktrees（工作树）：git worktree 让多个工作目录共享单一仓库，实现并行分支互不干扰。
• Skills（技能）：单一重复工作流的任务特定项目知识，以 SKILL.md 文件格式存放。
• Subagents（子智能体）：主智能体委派专门子智能体（研究、探索、实现、验证），采用 maker/checker 结构。
• Spine（脊柱/持久状态）：一个持久状态或记忆，跟踪项目进度、防止错误重复。每轮把行动结果写入持久状态（markdown 文件或 Linear 看板）。

六、经典 Loop 模式

不同任务需要不同形状的循环。以下是值得掌握的模式，大致按复杂度递增 [3][6]：

6.1 模式速查表

6.2 三种研究范式与企业级 Loop

从学术范式看，有三种经典 Loop [6]：

• ReAct Loop（Reasoning + Acting）：Yao 等人 2023 年提出。节奏是 Think → Act → Observe 循环。边想边做边看，适合路径不确定、需探索的任务；局限是缺乏全局规划时可能"走偏"。
• Plan-Execute Loop：节奏是 Plan → Execute → Verify。先全局规划再逐步执行，适合步骤较明确、需统筹的任务；代价是计划被证伪时调整比 ReAct 笨重。
• Reflexion Loop：行动后对结果做反思，把"哪里做得不好"沉淀下来改进下一次，给循环加一层自我批判。

企业落地需要更完整的版本，把 Prompt、Context、Harness 这些层串成一个持续运转的系统，节奏为六步 [6]：

逐环对应：Retrieve 是上下文工程（喂对信息）→ Decide 是 LLM 在决策点判断 → Execute 是线束调度工具 → Validate 是线束校验器拦幻觉/查约束 → Update State 是 Loop 的核心职责（把结果写进状态供下轮使用）→ Repeat 在受控预算下进入下一轮 [6]。

Update State 这一环是 Loop 独有、别人替不了的职责。 Context 负责"喂什么"、Harness 负责"怎么执行"，但"这一轮做完后整个任务进度走到哪、哪些已确认、哪些悬而未决、下一轮从哪接着干"——这份贯穿全程的任务状态，只有 Loop 在维护。它就像项目经理手里那张不断更新的进度表：没有它，每一轮都像失忆一样从头开始 [6]。

6.3 选型判据

一个实用的选型判据：任务的路径越不可预测，越偏 ReAct；任务的步骤越清晰、越需要全局统筹，越偏 Plan-Execute。 现实中成熟的企业智能体往往是混合的——在需探索的子任务里用 ReAct，在需规划的子任务里用 Plan-Execute，必要时叠一层 Reflexion 做质量回看 [6]。

七、关键工程机制：让 Loop 上生产的四道安全带

Loop 跑起来容易，跑得可靠难。让一条 Loop 真正能上生产，有四个机制必须显式设计——这是一份 Loop 体检清单 [6]：

1. 终止条件（Termination Condition）：什么情况算做完了？什么情况该停手？没有它，循环要么永不停止，要么过早收尾。
2. 循环预算（Loop Budget）：给每次任务设最大轮数、最大 token 上限。这是防成本失控的硬约束——连 Anthropic 都坦言缺一个好用的"单次任务成本硬上限"，所以预算闸必须自己建。
3. 错误恢复（Error Recovery）：某一步失败时，把错误喂回上下文让模型自我修正（self-heal）；但设三振机制，连续失败就升级给人，绝不无限重试。
4. 状态更新（State Update）：把执行状态和业务状态统一管理，做到可暂停、可恢复（pause/resume）——任务中断能续上，重启不会从头再来 [6]。

一条来自一线的反直觉经验值得牢记：带 error counter、会及时升级给人的小 Loop，比塞了一堆复杂恢复逻辑的大 Loop 更可靠。 把它拆成职责单一的小循环，每个做到 3–10 步的可靠区间，超过 20 步就拆。简单 + 早升级，几乎总是胜过复杂 + 强恢复 [6]。

7.1 Token 预算管理

LLM 有上下文限制，长时循环不能无限往 Prompt 里追加。常用策略 [3]：

• 摘要（Summarization）：周期性把历史压缩成摘要。
• 滑动窗口（Sliding Window）：只保留最近 N 轮迭代。
• 选择性记忆（Selective Memory）：只存储关键决策与结果。

if len(history) > MAX_HISTORY:
    summary = summarize(history[:len(history)//2])
    history = [summary] + history[len(history)//2:]

7.2 验证策略

智能体如何知道自己成功了 [3]：

• 直接观察：检查预期的变化是否发生。
• 不变量检查：验证某些条件是否仍成立。
• 目标分解：把目标拆成子目标逐一验证。
• 置信度评分：对成功打分，低则重试。

八、失败模式与护栏

大多数 Loop 失败都是已知模式，每个都有标准护栏。从设计之初就要为这些做准备 [3]：

最后一条——通过循环观察到的内容进行的 Prompt 注入——很少在 Loop Engineering 指南中被提及，但同样重要：智能体读取的每个网页或文件都是不可信输入，因此采取真实行动的循环应在隔离沙箱内运行 [3]。

8.1 五种反模式

把上述机制反过来，就是几种最常见、最致命的 Loop 反模式 [6]：

• 无终止条件 → 死循环：模型在某个判断上反复横跳、永不收敛。
• 无预算 → 成本失控：一个开放式难题可能让循环打转几十轮、单次烧掉惊人的 token。
• 状态丢失/不更新 → 重复劳动与遗忘：模型忘了自己做过什么，反复检索同一份资料。
• 把控制权交给模型 → 不可控：让模型自己决定"要不要再循环一次"，等于放弃方向盘。
• 一个大 Loop 扛所有 → 脆弱：用巨型 Loop + 复杂恢复逻辑硬扛长链路。

它们的共同点是：都源于"放任循环"而非"掌控控制流"。 [6]

最致命的误解：很多人一听"让智能体自己循环"，就真的放手让大模型漫无目的地自我循环。这正是无数智能体不可靠、烧钱、失控的根源。Loop 不是让 LLM 自由循环，而是一个显式的、由代码掌控的控制流。 [6]

九、如何度量一个 Loop

大多数文章描述模式却从不说如何评估一个循环。以下才是真正重要的指标 [3]：

用一个固定的代表性任务集来跑这些指标，每次改动循环后复查。要避免的陷阱：一个"感觉"更聪明却悄悄花了更多迭代（和 token）达到同一目标的循环，是退化而非升级——只有数字会告诉你真相 [3]。

9.1 基准测试实证

Mininglamp 在 OSWorld 基准（一套真实世界计算机任务）上对比了三种架构 [3]：

自纠正循环在单步基础上提升了 28+ 个百分点，多步基础上提升 13+ 个百分点——且这完全来自 Loop 工程，而非更强的模型。失败模式分析显示：单步循环 38% 的失败源于初始观察错误；多步循环 52% 的失败源于未处理的中间状态；自纠正循环则通过重试和策略调整恢复了 71% 的这些失败模式 [3]。

其产品 Mano-P 用仅视觉感知、端侧运行（Apple M4/32GB）的自纠正循环架构，在 OSWorld 上以 58.2% 登顶，领先第二名 13.2 个百分点，证明精良的 Loop 工程能让更小、更专的模型在代理式任务上超越大得多的通用模型 [3]。

核心洞察：一个 AI 智能体的质量，较少取决于模型的原始能力，更多取决于其 Loop 架构的质量。一个设计良好的循环，能让一个 4B 参数的模型在真实世界任务上超越 72B 模型。 [3]

十、应用场景

虽然软件工程是 AI 循环的"零号病人"——得益于编译器和测试套件的二元反馈——但这些模式正快速殖民其他垂直领域 [1]。

10.1 软件工程与编码智能体

Loop Engineering 是许多 AI 编码智能体的底层实践，包括 IBM Bob、Claude Code 和 OpenAI Codex [2]。典型工作流 [4]：

• 一条自动化每天早上在仓库上运行，调用 triage 技能读取昨天的 CI 失败、开放 issue、近期提交，把发现写进 markdown 文件或 Linear 看板；
• 对每个值得做的发现，循环打开隔离 worktree，派一个子智能体起草修复，第二个子智能体对照项目技能和现有测试评审草稿；
• 连接器让循环打开 PR 并更新工单；
• 处理不了的事项进入 triage 收件箱；状态文件记住试过什么、通过什么、还开着什么，明天的运行从今天停下的地方继续。

10.2 研究与分析

循环防止"幻觉深陷"。与其让 AI"总结 NVMe 存储最新趋势"，一个循环工程化的系统用 MCP 搜索 ArXiv、抓取三篇论文、提取矛盾主张，然后专门 Prompt 模型去解决这些矛盾。循环不停止，直到"解决分数"达到阈值 [1]。

10.3 运营与销售

循环正在取代线性的 zap 或工作流。一个循环可以监控线索回复、在 CRM 检查历史上下文、模拟一个回复、让第二个"批评者"模型评估回复是否太机械，然后迭代直到"感觉检查"通过 [1]。

10.4 企业流程自动化

以保险理赔分诊为例 [7]：一个开环智能体上线首日处理 60% 常规理赔，六周后仍 60%——同样的歧义条款被同样的方式误读。诊断不是模型，而是架构。闭环修复方案：加一个连接器读取理赔员的"接受或覆盖"信号、一个校验子智能体在起草前强制政策约束、一个记忆层把每次覆盖存为新案例。一个月内，智能体就移出了平台期——因为它第一次能真正从纠正它的人类那里学习 [7]。

10.5 招投标分析（中文场景）

以招投标智能体为例 [6]：单次调用"读完招标文件告诉该不该投、报多少"给出的是信息过载下的粗判断。但放进闭环：第一轮判断"硬性资质是否满足"→ 第二轮基于结论比对历史中标价 → 第三轮结合前两轮测算报价与风险……每轮站在前轮结论之上，单步判断不难，但一圈圈叠下来就逼近了一个单次调用永远给不出的严谨结论。Chatbot 拿到的是"一次性的回答"，智能体拿到的是"层层逼近的结论" [6]。

十一、人机协作与风险

即便最健壮的循环也仍需人类介入。组织在用 AI 加速软件交付、用人类把控质量、安全和业务结果时获得最大价值 [2]。

11.1 四大风险

11.2 人机协同的四个触点

自动化不意味着把人移出循环。在每一层都有人类监督增加价值的自然触点 [8]：

1. 在智能体循环中，敏感动作/工具调用前要求人工输入；
2. 在校验循环中，人类可作为敏感工作流的评分器；
3. 在应用循环中，人类可在输出返回终端用户前批准；
4. 在爬山循环中，线束改进可经人工评审后再部署。

Addy Osmani 的忠告：设计 Loop 是解药——当你带着判断力去做时；也是加速器——当你用它来逃避思考时。同样的动作，相反的结果。 循环不知道差别，你知道。两个人可以构建完全相同的循环，得到截然相反的结果——一个用它在自己深刻理解的工作上跑得更快，另一个用它来逃避理解工作本身 [4]。

十二、工具与生态

一个值得注意的趋势：一年前想要循环，你得写一堆 bash 并永远维护它；现在这些组件已直接内置在产品里。Steinberger 列出的清单几乎逐项对应 Codex 应用，又几乎同样对应 Claude Code——一旦你注意到形状相同，就不再争论用哪个工具，而是设计一个无论坐在哪个里都依然有效的循环 [4]。

LangChain 则提供了对应的原语：create_agent（智能体循环）、RubricMiddleware（校验循环）、LangSmith Deployment 的 cron/webhook 或 Fleet channels（事件驱动循环）、LangSmith Engine（爬山循环）[8]。

十三、未来展望

随着 AI 智能体变得更自主，Loop Engineering 将变得和今天的 Prompt Engineering 一样基础。可观察到的趋势 [3][8]：

1. 分层循环：管理子智能体的嵌套循环结构。
2. 学习循环：通过经验改进自身循环策略的智能体。
3. 多模态循环：在循环推理中结合视觉、文本和结构化数据。
4. 协作循环：多个智能体通过共享状态协调。
5. RL 微调闭环：爬山循环的发现可作为训练信号，喂给开权重模型的强化学习微调；辅助上下文（记忆、检索到的技能）也能同样改进 [8]。

整个时代的主线，可以用一句话概括："The Loop is the Product（循环即产品）。" [1]

• 如果你是 PM，你在设计循环的成功标准；
• 如果你是工程师，你在构建让循环执行的基础设施（MCP 服务器、沙箱）；
• 如果你是创始人，你卖的是只有闭环系统才能提供的可靠性 [1]。

十四、结语

回到开篇那个问题：同样接了大模型，凭什么有的叫智能体，有的只是 Chatbot？

因为 Chatbot 只有一次固定的智能，而智能体有一个把固定智能复利起来的闭环。智能体真正的"智能"，从来不是因为它的模型更聪明，而是因为它被一个会持续观察、判断、行动、校验、自我修正的 Loop 驱动着，盯着目标不放，直到做完 [6]。

把四层 runtime——Prompt、Context、Harness、Loop——从内到外看一遍，会发现一条清晰主线：每往外走一层，解决的就是上一层管不了的问题。Prompt 解决"怎么思考"，但管不了"基于什么思考"，于是有了 Context；Context 解决"喂什么"，但管不了"模型之外怎么可靠执行"，于是有了 Harness；Harness 给出可靠的执行积木，但管不了"何时调哪个、循环到何时停、状态怎么演进"，于是有了 Loop [6]。而 Loop，是给这台机器点火、让它持续运转的那一环。

最后，留给读者一把检查 Loop 健康度的尺子——拿出你的智能体循环，问四个问题 [6]：

有没有明确的终止条件？有没有循环预算？有没有错误恢复与升级？有没有严谨的状态更新？

四个里缺任何一个，循环就埋着一颗在生产里随时会爆的雷。

而最重要的工程姿态，是 Addy Osmani 那句收尾 [4]：

Build the loop. But build it like someone who intends to stay the engineer, not just the person who presses go.

构建循环。但要像一个打算继续做工程师的人那样去构建——而不只是那个按下"go"的人。

参考资料

1. Sunil Ramlochan. Agentic Loops - Designing the Systems That Design Themselves. Prompt Engineering Institute, 2026-06-20. https://promptengineering.org/agentic-loops-designing-the-systems-that-design-themselves/
2. Ivan Belcic, Cole Stryker. What is loop engineering?. IBM Think, 2026-07-17. https://www.ibm.com/think/topics/loop-engineering
3. Mininglamp. Loop Engineering: The Next Step After Prompt Engineering for AI Agents. dev.to, 2026-06-15. https://dev.to/mininglamp/loop-engineering-the-next-step-after-prompt-engineering-for-ai-agents-449m
4. Addy Osmani. Loop Engineering. addyosmani.com, 2026-06-07. https://addyosmani.com/blog/loop-engineering/
5. swyx. AINews: Loopcraft — The Art of Stacking Loops. Latent Space, 2026-06-12. https://www.latent.space/p/ainews-loopcraft-the-art-of-stacking
6. 技术方舟. Loop Engineering —— Agent 真正"智能"的来源. 腾讯云开发者社区, 2026-06-29. https://cloud.tencent.com/developer/article/2700306
7. Shakti Mishra. Loop Engineering: The Six-Layer Architecture Behind Self-Improving Agents. dev.to, 2026-07-12. https://dev.to/shakti_mishra_308e9f36b5d/loop-engineering-the-six-layer-architecture-behind-self-improving-agents-9m4
8. Sydney Runkle. The Art of Loop Engineering. LangChain, 2026-06-16. https://www.langchain.com/blog/the-art-of-loop-engineering
9. Happycapy. Loop Engineering for AI Agents: The 2026 Guide. happycapy.ai, 2026-06-14. https://happycapy.ai/blog/loop-engineering-ai-agents
10. Anthropic. Effective Context Engineering for AI Agents. Anthropic Engineering Blog, 2025-09. https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
11. Yao, S. et al. ReAct: Synergizing Reasoning and Acting in Language Models. arXiv, 2023. https://arxiv.org/abs/2210.03629