Agent Loop：行动、反馈与停止

循环怎样把一次回答变成持续执行

Agent的一轮通常包含模型选择、工具执行与反馈更新等阶段。工具结果回到下一次模型输入后，系统就能根据新信息调整行动。人们常用“思考、行动、观察”描述这一过程；从使用者能够核对的角度，更重要的是请求、执行结果和状态变化。

这不是让模型在一个回答里写出一大段自述。模型可以生成看似合理的“我已经查询”，但只有真实工具记录才能证明查询发生。本站实验展示的是可观察事件，不是模型内部的隐含推理记录。

沿默认场景逐项看日志

目标仍然是12人、周日14—16点、预算600元。实验中的场地数据是教学预设，用来观察控制关系，不代表真实营业与价格。

注意每一步多知道了什么。查询之前不能知道结果；取得结果后，也需要与目标比较。把这些状态区分开，才能检查模型是否跳过了关键验证。

改一个条件，为什么路线会变化

预算改为400元，B的520元不再符合条件。系统可以继续查C；如果C为680元，也不符合预算，就应报告没有匹配候选。不能因为“已经查了很久”，就悄悄把预算提高到700元。

如果B临时满员，而预算700元，C又满足人数和时间，就可能推荐C。同一条模型指令，在不同反馈与约束下出现不同路径，正是动态决策的用途。

固定工作流也可以提前写好这些分支。本实验使用预设分支保证教学结果可重复；真实Agent会由模型参与选择下一步，应用仍负责实际执行与限制。

为什么必须有轮数与失败上限

每次模型调用都会占用时间与用量。工具连续失败时，无限制循环只会重复消耗资源。应用应设置最多轮数、最长时间或特定错误的重试上限，并在达到限制后停止。

本实验把最终交付也算一轮模型调用。因此，两次查询完成后，即使已经得到B的数据，最多两轮的设置仍可能阻止最终比较与交付。轮数的定义需要明确，不能简单等同于页面按钮点击次数。

工具失败以后，状态应怎样变化

超时意味着本次没有获得可确认结果，不意味着场地关闭。应用可以对只读查询进行有限重试，连续失败后保留未知。若是预约等写入动作，还需确认上一请求有没有已经执行，避免重复操作。

一个可用的Agent应能解释“查到了什么、没查到什么、为什么停在这里”。这比一条笼统的“任务失败”，或没有依据的“全部完成”，更能帮助用户继续处理任务。