1. 从“循环”到“工程”：为什么我们需要Loop Engineering？
如果你最近在关注AI Agent的开发，尤其是那些需要自主执行复杂任务的智能体，那么“循环”这个词你一定不陌生。无论是让Agent去分析一份财报，还是让它自动完成一个多步骤的流程，背后都离不开一个核心机制：循环。但很多时候，我们只是简单地写一个while循环，设定一个最大迭代次数，然后祈祷它能顺利完成任务。结果呢？Agent要么在某个步骤里卡死，陷入无意义的重复；要么早早退出，留下一个半成品；更糟糕的是，它可能因为一个错误的判断，在错误的道路上越走越远，消耗大量资源却一无所获。
这就是“Loop Engineering”（循环工程）要解决的问题。它不是一个花哨的新概念，而是将我们过去在软件工程、控制系统里积累的关于“循环”的设计智慧，系统性地应用到AI Agent架构中。今天，我们就来深度拆解这个看似基础、实则决定Agent成败的“循环”问题。我会从最核心的“内循环”与“外循环”的职责划分讲起，一直深入到如何科学地定义“退出条件”，让你设计的Agent既能“钻得进去”深入思考，又能“跳得出来”果断决策，最终稳定、高效地完成任务。
2. 循环的双层结构：内循环与外循环的职责边界
一个健壮的Agent循环，绝不是单层while True那么简单。我习惯将其划分为两个层次：内循环（Inner Loop）和外循环（Outer Loop）。它们就像人的思考与行动：内循环负责“深思熟虑”，外循环负责“审时度势”。
2.1 内循环：单次推理的完整闭环
内循环的核心是完成一次从“感知”到“行动”的完整推理周期。你可以把它想象成Agent的一个“心跳”或“思考-行动”单元。一个标准的内循环通常包含以下步骤：
- 状态感知与信息整合：Agent获取当前环境的最新状态。这可能来自用户输入、工具调用结果、数据库查询、传感器数据等。关键是将这些原始信息整合成一个结构化的“当前状态”表示，供后续推理使用。
- 目标与上下文分析：Agent需要明确“我当前要解决的具体子问题是什么？”以及“我手头有哪些历史信息和约束条件？”。这一步决定了思考的焦点。
- 规划与决策生成：基于状态和目标，Agent调用其核心模型（如LLM）进行推理，生成下一步的行动计划。这个计划可能是一个简单的工具调用（如
search_web），也可能是一个复杂的子任务分解。 - 行动执行与验证：执行上一步生成的计划。如果是工具调用，就执行工具并获取结果；如果是信息输出，就格式化并返回。执行后，必须有一个验证环节。例如，调用搜索工具后，要检查返回的结果是否为空、是否相关；调用代码执行后，要检查是否有报错、输出是否符合预期。
- 状态更新与记忆：将行动的结果整合到Agent的内部状态中，并可能将其写入长期或短期记忆，为下一次循环提供上下文。
注意：内循环的“验证”环节至关重要，却常被忽略。没有验证的行动就像闭着眼睛走路，很容易偏离轨道。验证逻辑需要根据具体工具和任务来设计，可以是简单的非空检查，也可以是调用另一个验证模型进行相关性评估。
内循环的设计目标是高内聚：它应该专注于把一次推理做对、做完整。它的退出，通常意味着本次“心跳”结束，准备进入下一次“心跳”，或者因为完成了某个原子任务而向上汇报。
2.2 外循环：任务进程的宏观调度
如果说内循环是士兵，外循环就是指挥官。它不关心单次推理的细节，而是站在更高的维度，管理整个任务的进程。外循环的核心职责包括：
- 任务分解与初始化：在任务开始时，将用户的高层目标（如“写一份市场分析报告”）分解为一系列有序或可并行的子任务（如“1. 收集行业数据，2. 分析竞争对手，3. 撰写报告草稿”），并初始化任务状态机。
- 子任务调度与激活：决定当前应该执行哪个子任务。这可能基于依赖关系（任务B需要任务A的结果）、优先级，甚至是资源可用性。然后，它将激活的子任务目标“注入”到内循环中。
- 监控与异常处理：持续监控内循环的执行情况。这里要处理的是跨循环的问题。例如：
- 停滞检测：内循环是否连续多次输出相同或相似的动作而无进展？
- 资源超限：本次任务消耗的Token数、API调用次数或时间是否接近预设上限？
- 子任务失败：内循环经过多次尝试后，是否明确反馈当前子任务无法完成？
- 协调与整合：当一个子任务完成后，外循环需要评估其结果，决定是标记为成功、失败，还是需要重试。然后，它要整合子任务的结果，更新整体任务进度，并调度下一个子任务。
- 全局退出决策：这是外循环最重要的职责之一。它需要综合所有信息——所有子任务是否完成？是否出现了无法解决的致命错误？用户是否发出了中断指令？——来做出“整个任务是否结束”的最终判断。
外循环的设计目标是松耦合与健壮性。它要让内循环可以专注执行，同时自己牢牢把控任务的生命周期，防止系统在局部失效时整体崩溃。
2.3 内外循环的协作模式
一个典型的协作流程如下：
外循环启动 -> 设定当前子目标 -> 进入内循环 -> 内循环执行单次推理 -> 内循环验证结果并更新状态 -> 返回控制权给外循环 -> 外循环评估子任务完成度 -> 若未完成，继续内循环；若完成，调度新子目标 -> 循环直至全局退出条件触发。这种分离带来了清晰的结构和更好的可维护性。你可以独立优化内循环的推理质量（比如更换更好的LLM），也可以独立增强外循环的调度策略（比如实现更复杂的任务编排），而不会相互干扰。
3. 退出条件设计：告别武断的max_iterations
很多初级Agent实现用一个简单的max_iterations=10来防止无限循环。这很粗暴，但远远不够。一个优秀的退出条件体系应该是多维度、分层级的“安全网”和“终结者”。我将退出条件分为三类：成功条件、失败条件和安全条件。
3.1 成功条件：如何定义“任务完成”？
这是最理想的情况，但也是最难明确定义的。你需要根据任务类型来设计。
- 目标达成验证：对于有明确输出标准的任务，如“生成一份包含A、B、C三部分的报告”，成功条件就是检查最终输出是否结构化地包含了这三个部分，且内容质量通过某种校验（可以是规则，也可以是另一个轻量级模型的判断）。
- 状态满足判断：对于状态驱动的任务，如“将室温调节到24度”，成功条件是传感器读数稳定在24度附近。
- 用户确认：在交互式任务中，最直接的成功条件是用户的明确肯定，如“好的，就这样”或点击“确认”按钮。
- 子任务全集完成：在外循环层面，当所有预先分解或动态生成的子任务都标记为“完成”或“成功”时，即可判定全局任务成功。
实操心得：不要依赖LLM自己说“我完成了”。它可能会在未真正完成任务时就过早宣布成功。一定要有客观的、可编程的验证逻辑。对于复杂输出，可以设计一个“验证链”，先检查格式，再抽样检查内容合理性。
3.2 失败条件：如何识别“此路不通”？
允许失败，并优雅地处理失败，是系统健壮性的关键。失败条件帮助我们及时止损。
- 明确错误反馈：工具调用返回了错误码（如API调用失败、数据库连接异常）。这是最清晰的失败信号。
- 逻辑矛盾与不可能任务：内循环的推理结果自相矛盾，或试图执行一个已知不可行的操作（如“向一个只读文件写入数据”）。
- 资源耗尽：任务预算（Token、金钱成本、时间）已用完，但目标远未达成。这属于“战略性失败”。
- 用户否定与中断：用户明确表示“不对”、“停止”或直接发送中断指令。
- 子任务持续失败：外循环发现某个关键子任务经过多次重试（例如3次不同的方法）后仍然无法完成，这可能导致整个任务链无法推进。
设计技巧：为不同的失败条件定义不同的严重等级和恢复策略。例如，“工具临时错误”可以触发重试；“逻辑矛盾”可能需要外循环介入，重新解释用户目标或调整任务分解；“用户中断”则必须立即无条件终止。
3.3 安全条件：如何防止“失控循环”？
这是系统的保险丝，防止在成功和失败条件都未触发时，系统陷入无限循环或产生不可控行为。
- 迭代次数上限：经典的
max_iterations，但它应该是最后一道防线，而不是主要控制手段。这个值应该设得足够大，以容纳合理的任务复杂度，但又不能无限大。 - 循环停滞检测：这是比简单计数更智能的安全条件。监测内循环的状态变化：
- 动作重复：连续N次循环，Agent都尝试执行完全相同的或语义高度相似的动作。
- 状态停滞：Agent的内部核心状态表示在多次循环中没有发生有意义的变化。
- 目标偏移：Agent当前执行的动作序列，与初始设定的子目标之间的相关性越来越低。
- 时间预算：为整个任务或单个子任务设定最长执行时间。超时即强制退出，避免长时间阻塞。
- 成本监控：实时累计Token消耗和API调用费用，接近预算红线时主动退出并报告，避免产生意外高额账单。
避坑指南：停滞检测的阈值（N）需要谨慎设置。设得太小，可能会在Agent正常思考时误判；设得太大，则失去保护意义。一个实用的方法是结合具体任务来动态调整，对于探索性任务，阈值可以高一些；对于执行性任务，阈值可以低一些。
4. 状态机与上下文管理：循环的“记忆”与“导航”
要让循环智能地运行，Agent必须拥有良好的“记忆”（上下文）和知道自己身处何方的“导航”（状态）。这就是状态机和上下文管理的用武之地。
4.1 设计一个清晰的任务状态机
状态机是外循环的核心逻辑框架。它明确定义了任务可以处于哪些状态，以及状态之间如何转换。一个典型的状态可能包括：
IDLE：就绪，等待任务。IN_PROGRESS：任务执行中。WAITING_FOR_USER：等待用户输入或确认。SUB_TASK_FAILED：某个子任务失败，正在重试或等待处理策略。PAUSED：任务被主动暂停。SUCCEEDED：任务成功完成。FAILED：任务失败。CANCELLED：任务被取消。
状态转换由事件驱动，例如“用户输入新指令”事件可能将状态从WAITING_FOR_USER切换到IN_PROGRESS；“子任务完成”事件可能触发状态评估，决定是进入下一个IN_PROGRESS还是SUCCEEDED。
为什么需要状态机？它使得外循环的逻辑变得清晰、可预测、易于调试。你可以通过查看当前状态，立刻知道Agent在“干什么”以及“卡在哪里”。它也便于实现持久化，任务中断后可以从某个状态恢复。
4.2 分层级的上下文管理策略
上下文是Agent的“工作记忆”。管理不当，轻则效率低下，重则导致遗忘关键信息或受到无关信息干扰。
- 会话上下文：最全局的记忆，包含整个对话历史。它用于理解用户的长期意图和偏好。但全部灌给LLM会导致成本高、焦点分散。通常需要做摘要或选择性保留。
- 任务上下文：当前正在执行的任务相关信息，包括任务目标、已完成的步骤、产生的中间结果、遇到的错误等。这是内循环和外循环共享的核心上下文。
- 子任务上下文：更细粒度的记忆，只与当前活跃的子任务相关。当子任务切换时，这部分上下文可以被部分清空或归档，以保持LLM推理窗口的“清洁”。
- 工具上下文：记录工具调用的历史、参数和结果，便于进行链式调用或结果验证。
经验技巧：我强烈建议使用“滚动窗口”加“关键信息摘要”的策略。将最新的、最相关的对话和结果放在上下文窗口的前部。同时，定期（或在关键节点）对之前的长期交互进行摘要，将摘要而非原始冗长文本放入上下文。例如，在完成“收集数据”子任务后，生成一句摘要“已收集到关于X市场的三家主要竞争对手A、B、C的2023年营收数据”，而不是把几十行的原始数据表格再塞进去。
5. 实战案例：构建一个带健壮循环的网页研究Agent
让我们通过一个具体例子，将以上理论串联起来。假设我们要构建一个“网页研究Agent”，其目标是：根据用户给出的一个复杂问题，自动搜索、阅读多篇网页，并综合整理出一份答案。
5.1 系统架构与循环设计
外循环（研究协调器）：
- 状态：
PLANNING->COLLECTING->ANALYZING->SYNTHESIZING->FINALIZING。 - 职责：将“研究问题X”分解为“生成搜索词”、“获取并评估N篇来源”、“提取关键信息”、“综合对比”、“撰写答案”等子任务。调度这些子任务，并监控整体进度和资源。
- 状态：
内循环（单次搜索-分析单元）：
- 输入：当前子任务（如“评估第i篇网页的相关性”）、网页内容。
- 过程：感知网页文本 -> 分析其与问题的相关性 -> 决策（如“标记为高相关并提取要点”/“标记为低相关并丢弃”）-> 执行（更新知识库）-> 返回结果。
- 退出：单篇网页处理完毕，返回控制权。
5.2 多层退出条件定义
成功条件（外循环）：
- 综合答案已生成，并且答案中引用了至少3个高相关度的独立来源。
- 生成的答案通过了格式校验（包含引言、主体、结论）和内容质量抽查（由另一个LLM判断是否直接回答了核心问题）。
失败条件：
- 收集阶段：连续5次搜索返回的结果都被评估为“完全不相关”。
- 分析阶段：所有找到的高相关度网页在关键信息上互相矛盾，且无法通过进一步搜索解决。
- 用户干预：用户对中间产出表示“完全不对路”。
安全条件：
- 迭代上限：外循环总步骤数超过20步。
- 停滞检测：在
ANALYZING状态，连续3次循环提取到的“新关键信息”重复率超过90%。 - 成本/时间：总Token消耗超过200K，或总执行时间超过5分钟。
5.3 上下文管理实现
- 任务上下文：维护一个结构化的“研究笔记”对象，包含
research_question、search_queries、sources: List[Source]（每个Source包含url, content, relevance_score, key_points）、current_hypothesis等字段。 - 内循环上下文：每次处理一篇网页时，只将
research_question和该篇网页的content作为主要上下文，保持焦点。 - 摘要策略：当
source列表超过5个时，外循环会触发一个摘要动作，将已有的key_points汇总成一段精简的“当前发现摘要”，用于后续综合步骤，避免上下文爆炸。
通过这样的设计，这个研究Agent能够自主地、有方向性地进行多轮探索，在收集到足够证据时自动合成答案，在遇到死胡同时及时停止并报告，从而成为一个真正可用、可靠的自动化工具。Loop Engineering的精髓，就在于将这些控制逻辑从临时的、隐式的想法，变成明确的、可调试的工程代码。
