执行循环怎样推进
这就是 Agent 的执行循环与终止条件。
先回到同一个任务：查清下一次项目例会的安排，把通知保存成草稿。系统刚接到要求时，还没有会议资料。它可以先查询日历，再根据返回结果读取详情，随后生成和保存通知。
这些动作之间存在依赖。没有先取得会议记录，就缺少撰写通知的依据；文件尚未保存成功，就不能把“草稿已保存”当作实际结果。
Agent 循环，就是把获取信息、选择下一步、执行操作和接收结果组织成能够重复的运行过程。每一轮使用已有进展，决定是否还有必要继续。
可以把本例中的一次推进理解为：
读取当前任务状态 → 调用模型参与判断 → 检查并执行允许的操作 → 收到结果 → 更新状态 → 判断继续、等待或结束
这不是所有系统都必须照搬的代码顺序。有些检查会发生在模型调用之前，有些会在工具执行之后。重要的是，每一步都要把实际结果与后续处理接起来。
例如，模型先提出查询日历的请求。应用实际执行查询，再把返回的候选会议交给模型。模型可能接着提出读取详情的请求，也可能发现资料已经足够，直接生成通知。工具调用文档中，这类请求、执行、返回结果、继续处理的过程，就是一类具体循环实现。工具调用循环的运行过程
这里的“一轮”，也不等于模型生成一个 Token。Token 生成发生在模型内部的推理过程中；本篇说的循环，关注应用怎样把模型调用、工具操作和任务状态衔接起来。
一次模型调用可能提出多个工具请求，一个工具请求也可能在外部服务中执行一段时间。不同系统怎样计数“步骤”，需要看实际定义，不能把模型调用次数、工具次数和输出 Token 数混为一谈。
循环的价值，是让系统利用执行中出现的新信息。
假设第一轮只查到一个会议简称，第二轮读取详情后发现参与人不匹配。系统应当据此调整查询，而不是继续为这场错误会议生成通知。先前得到的结果，需要改变接下来怎样做。
但能重复，并不意味着应该无限继续。一个没有终止条件的系统，可能不断查询相同资料、反复修改已经合适的句子，或者因为看不到进展而继续消耗资源。
因此，在安排循环时，需要同时考虑“怎样向前”和“什么时候结束”。
完成需要什么证据
先说完成。
完成条件描述用户要求已经满足的证据。 对会议任务而言，可以是：正确会议已经确定，必要信息已经核实，通知内容与资料一致，文件保存成功，而且用户能找到结果。
完成条件应当在任务开始时尽量明确。否则，系统可能把“找到一场会议”误当作整个任务结束，也可能已经完成保存，还继续无意义地改写通知。
核对可以由不同机制共同完成。日期字段是否缺失，可以用程序检查；文字有没有加入资料里不存在的地点，可能需要结合正文与原始记录比较；文件是否实际存在，则需要保存结果或相应查询支持。
模型对结果的判断也可以参与其中，但最后输出“任务完成”，不能代替这些结果本身。
等待与恢复
再说等待。
假设系统找到了两场无法区分的同名会议，需要用户指出是哪一场。此时，任务还没完成，但继续查询也不一定能解决缺少的意图信息。系统可以保存进展，提出具体问题，并进入等待状态。
等待期间，不必让模型一直生成内容或反复问同一个问题。应用可以记录待回答的问题，等收到新输入后再恢复处理。支持状态保存的中断机制，就是一种实现这种等待与恢复的方式。暂停并接收外部输入
恢复也不只是重新发送一句“继续”。系统需要知道原来在等什么，已经查到了哪些资料，哪些操作已经发生。否则，用户刚回答会议名称，系统可能又从头重复查询，甚至重复创建文件。
运行状态能够在程序结束后继续使用，需要相应的持久化设计。只在内存中暂存信息，与写入可持续使用的存储，效果并不相同。保存任务状态与恢复进展
失败、受阻与结果未知
接下来是失败或受阻。
例如，日历服务暂时无法连接，与当前账号根本没有访问权限，是两种不同情况。前一种也许适合在限定范围内重试；后一种反复发送相同查询，通常不会产生新的权限。
系统需要根据原因处理。有的错误可以自动恢复，有的需要更换已有的有效方式，有的需要用户完成账号连接。不能把所有失败都变成“再试一次”，也不能把每个小错误都立即推给用户。
还有一种容易误判的情况：没有收到成功结果，不一定能证明外部操作完全没有发生。
假设系统请求保存文件，但响应在返回途中超时。文件可能尚未写入，也可能已经写入，只是程序没有收到最终回复。直接再次创建，可能得到重复文件。
这时，系统需要结合工具能力，查询实际保存状态，或使用避免重复操作的机制。只有分清执行情况，才能知道该重试、继续还是说明问题。相关的超时、重试与幂等知识，后面会分别学习。
运行限制与停止原因
除了成功、等待和失败，系统还可能因为运行限制停止。
假设某个应用为了控制资源，规定一次任务最多执行一定数量的工具操作，或者运行到指定时限就先结束。这些限制可以防止任务长时间没有进展，也能帮助控制使用成本。
具体上限需要根据任务设计。次数足够处理简单会议，不代表也适合复杂资料查证；固定等待时间过短，可能会打断正常操作。这里没有适用于所有 Agent 的统一数字。
达到次数、时间或费用限制，表示本次运行触及了边界，不等于用户目标已经实现。
因此，系统需要说明停止原因，以及已经完成和仍未完成的部分。比如，会议时间已经确认，但文件保存仍未得到结果；这比一句笼统的“处理结束”更有用。
模型服务本身也会给出结束信号，例如输出达到长度限制，或当前轮次不再请求工具。应用需要解释这些信号与任务的关系。一次模型输出结束，不一定等于整个任务成功，后续可能还要处理缺失内容或验证结果。
用户取消与已有结果
用户主动取消，又是另一种停止方式。
当用户要求停止，系统应当不再安排新的相关操作，并处理仍在执行中的工作。向界面显示“已取消”是一部分，确认任务实际停止，是另一部分。已经在外部系统完成的操作，也不会因为后续循环停止而自动撤销。
例如，通知草稿已经保存，取消后续处理不应让人误以为文件从未产生。系统需要交代已有结果；如果确实需要撤销，则要按照具体工具能力和授权处理。
暂停和取消也不同。暂停通常保留等待恢复的可能，取消则结束当前任务的后续安排。应用可以根据任务需求设计这些状态，但应当让用户清楚它们意味着什么。
长任务恢复与重复执行
长任务还需要注意，恢复时可能重新执行某一段程序。具体框架会有自己的恢复规则，开发者必须知道哪些步骤可能再跑一次，并避免重复产生有影响的操作。恢复执行与重复副作用
因此，设计循环时，保存状态、判断完成和处理重复执行，是相互关联的事情。只写一个不断调用模型的循环，还不足以支持可靠的长任务。
对于初学者，可以先检查一个小任务的完整过程：系统为什么选择这一步，拿到了什么结果，这个结果怎样进入下一步，最后又依据什么停止。这些问题清楚了，才容易继续理解更复杂的规划和协作。
循环也不是一种保证任务永远运行的能力。它需要实际的程序、执行环境和触发条件。程序停止、机器关机或关键服务不可用以后，需要有相应的恢复安排，任务才可能接着运行。
这就引出了下一篇 01.10：Agent Harness——运行环境与控制设施。我们会继续看，哪些程序设施负责把模型、工具、状态和这些停止规则真正接起来。
当前学习编号：01.09 Agent 循环与终止条件。
下一学习编号：01.10 Agent Harness：运行环境与控制设施。后续还有其他学习编号。
关联分支：循环推进对应 18.01 感知、决策、执行与观察循环、18.08 计划修订与失败重规划、18.09 结果检查与评价优化循环；停止与续接对应 18.10 停止条件与完成判定、18.11 步数、时间与费用预算、18.12 检查点与持久化执行、18.13 暂停、恢复与取消。
异常处理对应 24.04 超时与截止时间、24.05 取消传播与任务确实停止、24.06 重试、指数退避与抖动、24.07 幂等键与去重、24.10 状态恢复与故障补偿；完成评价对应 23.02 任务成功标准与评测集、23.09 工具选择、参数与执行正确性、26.05 进度反馈与结果呈现。