Loop循环概念详解

Loop（循环，也称 Agent Loop、智能体主循环）是 Agent 执行任务的核心引擎：从接收目标开始，Agent 反复执行"模型推理、工具调用、结果反馈、再推理"的基本循环，直到模型判断任务完成才退出。大语言模型本身无状态且被动，一次调用只能生成一段文本；Loop 赋予模型"行动、观察、修正"的能力，是普通对话系统与智能体的分水岭。

本教程将系统讲解 Loop 的概念定义、工作机制与终止条件，梳理它与 Harness、Tool Calling、Context、Workflow、Hook 等概念的分工，并结合主流 Agent 工具介绍循环的调优方法与常见问题的治理思路，帮助你理解 Agent"跑起来"的底层原理。

前置教程

如想快速开始学习本教程，你可能需要先完成以下前置教程：

• Agent概念详解，Agent 的执行过程由 Loop 驱动，理解 Agent 的整体架构有助于定位 Loop 在其中的角色。
• Harness概念详解，Harness 是 Loop 的宿主环境，模型调用、工具执行、上下文维护都由它提供支撑。
• ToolCalling工具调用技术分析与应用教程，工具调用是 Loop 每一轮的"行动"环节，是循环得以推进的齿轮。
• Context上下文及相关概念详解，Loop 每轮迭代都会向上下文追加内容，理解上下文机制是理解长任务循环的前提。

1. 什么是 Loop

1.1 概念定义

Loop（循环）在编程中指重复执行一段代码的控制结构。在 AI Agent 语境下，Loop 指 Agent 从接收任务到完成任务之间，反复执行"模型推理、工具调用、结果反馈"的基本执行循环。

业界对 Agent 有一个经典概括：Agent 就是在循环中使用工具的 LLM（An LLM calling tools in a loop）。Anthropic 在《Building effective agents》一文中给出的 Agent 定义同样落在循环上——模型根据每一步的观察结果自主决定下一步行动，直到任务完成。

拆解这个定义，Loop 由四个组成部分协作完成：

单次调用大语言模型，得到的是"一段话"；让模型在 Loop 中反复调用工具，得到的是一个能干活的 Agent。Loop 是对话系统与智能体的分水岭。

1.2 从单次调用到循环执行

Loop 与普通的单次 LLM 调用有本质差异：

以"修复一个失败的测试"为例：单次调用只能靠模型凭训练知识猜测原因；Loop 模式下，模型先运行测试、再读取报错、定位代码、修改后重跑验证——每一步都建立在真实的观察之上。

1.3 为什么复杂任务离不开 Loop

现实中的复杂任务几乎都具备"步骤有依赖、环境不可预知、结果需验证"的特征，这些正是单次调用的短板：

2. Loop 的工作机制

2.1 循环的基本结构

一次完整的 Agent 执行由若干轮迭代组成，每轮迭代经历四个阶段：

四个阶段的执行者与职责如下：

循环的每一轮都是一次完整的模型调用。用户在界面上看到的一个"步骤"，背后对应的就是一轮迭代。

2.2 一次完整循环的执行示例

以"修复项目中的失败测试"为例，观察模型如何通过多轮迭代推进任务：

用户目标：修复项目中失败的测试

第 1 轮：调用终端工具运行测试
        观察到 2 个用例失败，报错指向 user_service.py
第 2 轮：调用文件读取工具查看 user_service.py
        观察到 get_user 函数未处理用户不存在的情况
第 3 轮：调用文件编辑工具补充空值判断
        修改完成
第 4 轮：再次运行测试
        全部通过
第 5 轮：不再调用工具，向用户汇报修改内容
        循环自然终止

对应的调用时序如下：

这个例子体现了 Loop 的两个关键性质：

• 决策基于观察：模型先看到报错信息才知道要读哪个文件，先看到代码才知道改哪里，每一步都依赖上一轮的真实结果；
• 完成由模型判断：测试全部通过后，模型认为目标已达成，输出文字答复而不再调用工具，循环随之结束。

2.3 最小可行循环的代码骨架

Loop 的结构用代码表达非常直观，下面是一个约二十行的最小循环骨架：

from openai import OpenAI

client = OpenAI()
messages = [{"role": "user", "content": "修复项目中失败的测试"}]

while True:
    # 每轮迭代就是一次完整的模型调用
    response = client.chat.completions.create(
        model="glm-4.7-flash",
        messages=messages,
        tools=TOOL_DEFINITIONS,
    )
    message = response.choices[0].message

    if not message.tool_calls:
        # 模型不再调用工具，输出最终答复，循环结束
        print(message.content)
        break

    messages.append(message)
    for call in message.tool_calls:
        result = execute_tool(call)          # 在本地执行模型请求的工具
        messages.append({                    # 结果写回上下文，供下一轮推理
            "role": "tool",
            "tool_call_id": call.id,
            "content": result,
        })

代码虽短，却包含了 Loop 的全部要素：while True 是循环骨架，create 调用对应每轮的模型推理，execute_tool 对应工具执行，messages.append 对应结果写回，break 对应自然终止。实际产品中的循环会在此基础上叠加权限审批、上下文压缩、并发调度、预算控制等工程能力。完整可运行的 Tool Calling 示例可参考 ToolCalling工具调用技术分析与应用教程。

2.4 循环的终止条件

循环必须有出口，主流工具设计了多层终止机制：

自然终止由模型主导，代表"任务完成"；其余几种由系统或用户兜底，属于"执行保护"。设计合理的终止条件，本质是在完成质量与执行成本之间取得平衡。

3. Loop 与相关概念的关系

3.1 概念关系图谱

3.2 Loop vs Workflow

Workflow概念详解 讲解的 Workflow 与 Loop 都能驱动多步骤任务，核心区别在于"谁决定下一步"：

两者在实践中经常配合：Workflow 的某个节点内部可以运行一个完整的 Loop（例如"自动修复"节点内部是一个修复循环）；反过来，Loop 中的模型也可以在推理后决定触发某个 Workflow。决策权在模型手中时是 Loop，固化在流程图中时是 Workflow。

3.3 Loop 与 Harness

Harness（见 Harness概念详解）是 Loop 的宿主与供给者：

Loop 本身只定义了"反复调用模型直到完成"的骨架，让它真正跑起来的基础设施全部由 Harness 提供。可以说 Loop 定义了节奏，Harness 提供了乐器。

3.4 Loop 与 Tool Calling、MCP

Tool Calling（见 ToolCalling工具调用技术分析与应用教程）是 Loop 每一轮的"行动"环节：模型在推理后产出工具调用指令，循环执行工具并把结果反馈回来。没有工具调用，模型每轮都只能输出文字，循环在第一轮就会自然终止，Agent 随之退化为普通对话。

MCP（见 MCP概念详解与应用完整教程）则决定了 Loop 的行动空间：接入的 MCP 服务器越多，模型每轮可选的工具就越丰富，同一个循环骨架能覆盖的任务面就越宽。

3.5 Loop 与 Context

Context（见 Context上下文及相关概念详解）与 Loop 是"随行档案"与"行进步伐"的关系——循环每前进一步，上下文就增长一分：

长任务的循环轮次可达数十轮，上下文随之快速膨胀，因此主流工具引入了上下文压缩机制（达到阈值时把早期历史折叠为摘要）。压缩时机与循环关系紧密——Claude Code 的 PreCompact 钩子正是挂在压缩动作之前，详见 Hook钩子概念详解。

3.6 Loop 与 Hook

Hook（见 Hook钩子概念详解）是挂在 Loop 关键事件点上的确定性控制。循环的每一轮都会经过"工具调用前、工具调用后"等事件，钩子在这些位置强制校验、拦截或补充上下文：

Loop 提供节奏，Hook 在每个节拍上植入强制规则：提示词约束影响模型"想做什么"，Hook 决定系统"允许做什么"，两者共同保证长循环任务不越界。

4. Loop 的实践应用

4.1 主流 Agent 工具中的 Loop

理解了 Loop，你在使用这些工具时会看得更懂：界面上的每个"步骤"对应循环的一轮迭代；回合结束时，模型输出了不含工具调用的最终答复，本轮循环随之收尾。

4.2 循环调优的关键参数

4.3 循环常见异常与治理

其中子 Agent 是控制循环规模的重要手段：主循环把独立子任务（如"全局搜索引用"）交给子 Agent，子 Agent 在自己的循环中消化大量工具输出，只把最终结论带回主循环，主上下文因此保持精简（子 Agent 机制见 Agent概念详解）。

循环轮数是 Agent 任务的真实成本计量单位——每一轮都是一次模型调用，轮数翻倍意味着成本与失败风险同步上升。观察一个 Agent 的轮数消耗，是评估其任务设计是否合理最直观的方式。

5. 总结

5.1 核心内容回顾

• Loop（循环） 是 Agent 的核心执行引擎：模型推理、工具调用、结果反馈、终止判断四个阶段反复迭代，直到任务完成。
• 业界对 Agent 的经典概括是"在循环中使用工具的 LLM"，Loop 是对话系统与智能体的分水岭。
• 循环的每轮迭代对应一次完整的模型调用；模型不再调用工具时循环自然终止，步数、预算、超时与人工中断构成系统兜底。
• Harness 是 Loop 的宿主，提供模型接入、工具执行、上下文维护与权限控制；Tool Calling 是循环的行动齿轮，MCP 决定行动空间的宽度。
• Context 随循环逐轮增长，长任务依赖压缩机制；Hook 挂载在循环的事件点上，为概率性执行注入确定性规则。
• Loop 与 Workflow 的区别在于决策权：模型实时决策是 Loop，开发者预先编排是 Workflow，实践中两者经常配合。

5.2 常见问题与解答

问：Loop 和 ReAct 是什么关系？

答：ReAct（推理加行动）是循环内部模型使用的推理模式——"思考、行动、观察"交替进行；Loop 是承载这种模式的执行结构。可以理解为 ReAct 是舞步，Loop 是舞池。

问：模型为什么不把所有工具一次性调用完？

答：因为许多工具调用之间存在依赖——必须先看到测试报错，才知道要读哪个文件。Loop 的价值正在于"观察后再决策"。对于相互独立的调用，主流模型支持在同一轮并行发起，兼顾效率与正确性。

问：循环轮数越多，任务完成得越好吗？

答：并非如此。轮数增加意味着更高的 Token 成本、更长的等待时间和更大的跑偏风险。任务设计的目标是用尽可能少的轮数达成目标，常用手段包括拆解子任务、并行工具调用和使用子 Agent 隔离中间过程。

问：如何判断一个循环该结束了？

答：两层机制配合。模型层面，目标达成后输出纯文本答复，循环自然终止；系统层面，通过最大轮数、预算上限、超时和人工中断兜底，确保循环永远不会失控。前者追求"完成"，后者保证"可控"。