从一次天气查询，看懂 Agent 的控制循环

假设用户对出行助手说我明天上午去上海见客户需要带伞吗如果系统直接把问题交给大模型模型当然可以给出一个语言通顺的答案。但它并不知道上海明天上午的真实天气也不知道天气查询是否成功。即使给模型增加一个天气工具问题仍然没有完全解决。模型可能调用错误的城市工具可能超时返回的数据可能已经过期。更重要的是模型最后说出“建议带伞”并不能证明这个建议真的建立在有效天气数据上。所以Agent 的核心问题不是如何让模型生成更多内容而是如何可靠地推进一个任务。在每一步运行中Agent 都必须回答三个问题目标判断当前究竟要完成什么 执行判断下一步行动是否有效 证据判断已有结果能否证明目标完成目标确定方向执行改变状态证据决定是否停止。三者首尾相接才构成一个完整的 Agent 控制循环。一、目标判断先定义完成再决定下一步用户说“需要带伞吗”表面上是在询问天气真正目标却不是获得一份天气数据而是形成一个可靠的出行建议。这一区别很重要。如果将任务目标定义为“调用天气工具”那么工具返回数据后系统就可以结束。但此时用户仍然没有得到“是否带伞”的答案。如果将目标定义为“生成一段回复”模型又可能绕过天气查询直接凭常识建议带伞。系统有了答案却没有可靠依据。因此这个任务的完整目标应该是获得上海明天上午的有效天气数据基于该数据形成带伞建议并把建议交付给用户。这个定义同时包含了事实、判断和交付。它把“系统做过什么”与“用户得到了什么”区分开来。这也是设计 Agent 时首先要完成的工作把自然语言愿望转化成可以判断的任务目标。在程序里这个目标不一定要写成复杂的任务描述但至少要能被完成条件表达constisFinal(state)state.memory.weather!undefinedstate.memory.recommendation!undefinedstate.memory.deliveredtrue;这里的关键不是这段代码本身而是它改变了系统的判断方式。Agent 不再因为“模型已经回复”而结束而是因为“完成目标所需的事实和结果已经齐备”而结束。目标一旦明确下一步行动也有了依据。初始状态中Agent 已经知道用户要去上海见客户也知道用户关心是否带伞但它还不知道明天上午的天气。当前状态与目标状态之间存在一个缺口已知城市、时间、用户目的 未知天气事实 目标基于天气给出建议因此下一步不是继续生成文字而是补齐天气事实。这就是目标判断的作用它不直接执行任务而是指出当前状态距离目标还缺少什么。二、执行判断模型提出行动运行时验证行动目标判断发现天气事实缺失后模型可以提出调用天气工具{name:get_weather,arguments:{city:上海,date:明天上午}}这时最容易产生一个误解模型返回了 Tool Call就等于系统已经开始查询天气。实际上Tool Call 只是一份行动请求。它说明模型认为下一步应该调用哪个工具、携带什么参数但不能证明工具存在、参数正确更不能证明行动已经成功。模型擅长在不完整信息中作出判断却不适合成为最终执行边界。它可能写错工具名称也可能把“明天上午”解析成错误日期。因此Agent 必须把决策权和执行权分开模型负责提出下一步行动 运行时负责判断行动能否执行 工具负责产生真实结果。在 NanoAgent 中这个边界由工具注册、参数解析和 Schema 校验共同建立。天气工具可以声明自己的输入{type:object,properties:{city:{type:string},date:{type:string}},required:[city,date]}运行时收到 Tool Call 后先根据名称寻找工具再解析参数最后按照 Schema 校验。只有通过这些检查调用才会真正进入天气服务。这套机制解决的不是代码整洁问题而是行动安全问题。模型可以参与决策但它生成的内容不能因为采用了 JSON 格式就自动获得执行资格。所有会访问数据、调用服务或改变外部状态的请求都必须经过确定性程序验证。工具执行之后系统还要判断结果是否有效。假设天气服务返回{city:上海,time:明天上午,condition:中雨,precipitationProbability:80}这次执行补齐了任务需要的天气事实所以 Agent 可以进入下一步。如果工具返回“城市不存在”继续原样重试没有意义。系统应该修正参数或者请用户确认地点。如果工具只是暂时超时可以进行有限次数的重试。若服务持续不可用则应该降级或明确告诉用户暂时无法获得可靠数据。因此错误处理不能统一写成“失败就重试”。不同错误意味着当前状态中的不同问题参数错误行动本身不合法需要修正 业务错误输入含义不成立需要用户确认 瞬时故障行动合理但暂时失败可以有限重试 状态未知不能确认行动是否完成应先查询外部状态。执行判断的标准也由此明确有效执行不是“函数被调用过”而是行动经过验证并为任务带来了新的可靠事实。三、证据判断有了结果还要证明任务完成天气工具成功返回后Agent 获得了新的事实。但用户的目标仍未完成因为天气数据还没有转化成出行建议。运行时需要把工具结果写回 Agent 状态然后再次交给模型。这里涉及两类不同的状态载体。第一类是消息用户我明天上午去上海需要带伞吗 助手调用天气工具。 工具上海明天上午有中雨降水概率为 80%。消息主要给模型使用。模型通过消息理解发生过什么并根据天气结果组织最终回答。第二类是结构化 Memory{weather:{city:上海,time:明天上午,condition:中雨,precipitationProbability:80}}Memory 主要给程序使用。它让完成判断、失败恢复和状态持久化不必依赖对自然语言的再次解析。两者不能相互替代。如果天气结果只保存在消息里程序就很难稳定判断数据是否存在、是否过期、是否对应正确的城市和时间。如果天气结果只保存在 Memory 里模型又无法看见这些事实也就不能据此生成建议。所以更稳定的方法是对话过程进入 Messages控制事实进入 Memory同一份结果如果同时服务模型和程序就分别以适合它们的形式表达。带着新的天气事实模型再次执行决策中雨降水概率 80% → 户外出行存在明显淋雨风险 → 建议携带雨伞随后它向用户回答上海明天上午预计有中雨降水概率约为 80%。你还要外出见客户建议随身带伞并预留一些路上时间。现在看起来任务已经完成但运行时还需要进行最后一次证据判断。它不能只检查是否出现了一条 AssistantMessage而应该检查天气数据是否真实存在 数据是否对应上海和明天上午 建议是否已经生成 建议是否已经交付给用户。只有这些证据同时成立任务才能进入Done状态。如果缺少天气数据即使模型已经回答也属于无依据输出如果已经生成建议但尚未交付则完成的是内部计算不是用户任务。这就是证据判断的价值系统不是根据模型的语气判断完成而是根据任务状态中的证据判断完成。至此整个天气 Agent 可以表示成一个连续闭环目标判断 发现缺少上海明天上午的天气事实 ↓ 执行判断 验证并调用天气工具获得有效结果 ↓ 证据判断 确认事实充分但用户建议尚未生成 ↓ 目标判断 发现还需要形成并交付带伞建议 ↓ 执行判断 模型根据天气事实生成建议 ↓ 证据判断 确认事实、建议和交付全部成立 ↓ 任务完成这条链比“模型调用工具然后给出答案”多了几层判断却更接近真实系统。模型可能选错工具工具可能执行失败结果可能不满足目标最终答案也可能缺少依据。Agent Runtime 的职责就是在这些不确定环节之间建立确定的推进规则。在 NanoAgent 中相关实现分散在几个文件里但从职责上看可以归纳为同样的三类判断判断主要对象解决的问题目标判断AgentContext.isFinal、HaltStatus还缺什么何时结束执行判断Model、ToolRegistry、Schema、Tool Handler下一步做什么行动是否合法证据判断AgentState.messages、memory、Memory Patch行动产生了什么是否足以证明完成stepAgent把三个判断连接成一次状态转换loopAgent则不断重复转换直到任务进入明确终态。因此Agent 架构真正稳定的核心并不是某个模型、工具协议或者框架而是一条完整的判断链目标决定需要什么 执行负责获得它 证据证明是否已经获得 证据不足时再回到目标继续推进。天气查询可以替换成订单处理、日志诊断、报告生成或者代码修改底层问题依然相同。设计一个 Agent 时最先应该问的也不是“使用哪个模型”而是三个更基础的问题目标如何被明确表达 每个行动如何被约束和验证 什么证据能够证明用户目标已经完成能够连续回答这三个问题Agent 才不只是一个会调用工具的模型而是一个可以被理解、验证和恢复的任务系统。