Agent 运行循环：工具反馈如何改变下一步

机制分析

三种角色，分别改变什么？

天气案例里，用户给出任务，规则要求先查询再建议。模型先读取这组输入，生成一个天气工具调用：调用哪个工具、带什么参数。Harness 接收请求，找到工具实现并执行；天气服务再返回实际结果。工具请求、工具执行和模型答复因此是三类不同事件。

Harness 保存原任务与新增反馈，组织下一轮输入。模型这次读到“下雨18°C”，才有依据生成带伞建议。答复生成后，仍要由程序交付给用户。装置里的消息册、输入复制台和答复打印机，分别对应这些状态，不能用一个“完成”标记替代。

保留同一个带伞任务，只替换天气反馈，能看出反馈在循环中的作用。下雨时给带伞建议，晴天时可以给不同建议；主服务超时，则没有正常天气证据，案例转向备用查询。备用工具也是一次新的动作，不能把“准备重试”写成“已经查到”。

本例的分支是预设策略，但它揭示了一个可检查的关系：后续行为应该依赖实际收到的反馈。若服务超时后仍生成确定的天气结论，应先查看输入和执行记录，而不能仅凭答复流畅就认定任务成功。

工程取舍

对短暂网络故障，程序可以按规则重试，省下一次模型调用；对参数错误、证据矛盾或需要改变工具的情形，再让模型参与判断更有价值。重试应有次数、超时和成本上限。对于会产生外部副作用的工具，还要确认重复执行是否安全，不能直接照搬天气查询的处理方式。

模型输出最终答复，可以作为一个结束信号，但真实任务往往还需要独立条件：工具是否完成、必要证据是否齐全、是否触发了人工确认。程序也需要预算或步数上限，防止工具失败与模型重试相互推动，形成一直运行却没有进展的循环。

完整保留便于追溯，却会增加输入体积，重复噪声也可能掩盖当前状态。可以把完整执行档案留在外部，为模型选择当前任务、有效约束、近期结果与可回查来源。整理改变了模型本轮看到什么，因此必须保留关键失败证据，不能把错误摘要成一个没有依据的“已解决”。

落到实现

遇到“工具查过了，答复却不对”，可以依次检查：模型提出了什么请求、程序实际执行了什么、返回值保存在哪里、下一轮到底发送了什么，以及最终交付了哪份答复。这比把全部问题归结为“模型没理解”更容易找到可修改的位置。

这里展示离线预设回放，不调用真实天气服务或语言模型，也不展示内部思维链。它说明一种常见运行循环；真实宿主可以自行完成重试、验证、压缩和调度，不必把每一步都交给模型决定。

能提出动作、能执行动作、能看见结果、能据此继续，是一条需要逐段接通的链。Agent 的可靠性，就藏在这些衔接处。