Agent 的本质不是让大模型反复调用工具而是把用户意图转化为可验证的任务目标由 Skill 提供解决方法Model 根据当前状态决定下一步Tool 负责执行真实动作Runtime 通过状态机约束执行、处理失败并持续推进最终依据工具结果、外部回执和交付状态等证据而不是模型的一句“已完成”判断用户目标是否真正实现。用户目标 │ ▼ ┌──────────────┐ │ Runtime │ │ 推进与约束任务 │ └──────┬───────┘ │ 当前状态 ▼ ┌──────────────┐ │ Model │ │ 判断下一步 │ └───┬──────┬───┘ │ ▲ 方法约束 │ 行动结果 │ │ ┌──────▼───┐ │ ┌──────────┐ │ Skill │ │ │ Tool │ │ 专家方法 │ └──│ 外部行动 │ └──────────┘ └────┬─────┘ │ ▼ 外部世界很多 Agent 演示都从一个循环开始模型生成工具调用系统执行工具再把结果交还给模型。这解释了 Agent 怎么跑却没有解释它为什么可靠。真正困难的问题是模型为什么要调用这个工具执行失败后怎么办模型说“完成了”任务就真的完成了吗从第一性原理看Agent 只需要持续回答三个问题目标用户真正想完成什么 执行为了接近目标下一步应该做什么 证据凭什么判断任务已经完成Model、Skill、Tool、Memory、Workflow 看似分散本质上都服务于这三类判断。下面用一个真实任务贯穿这条主线我明天去上海迪士尼。请根据天气告诉我带什么并在早上 7 点提醒我。一、目标把用户表达转化为任务契约用户给出的通常是一段自然语言而不是一份严格的任务定义。在这个例子中用户表面上提出了三个要求查询天气、生成建议、创建提醒。但系统还需要确认日期、时区、具体地点以及“提醒我”究竟意味着创建成功还是最终送达。如果不先定义目标模型很容易生成一句明天可能下雨建议带伞我会在早上 7 点提醒你。这段话听起来完成了任务但系统可能既没有查询天气也没有创建提醒。因此Agent 首先要把用户意图整理成可执行、可验收的任务目标 根据上海迪士尼明天的天气生成出行建议 在 Asia/Shanghai 时区早上 7 点发送提醒。 完成条件 获得对应地点和日期的天气数据 建议确实基于该数据 提醒成功创建并在指定时间送达。Skill 在这里提供解决问题的方法。它规定这类任务应该先规范化时间和地点再查询天气、生成建议、创建提醒并保存执行结果。所以Skill 不是 Tool。Tool 说明系统“能做什么”Skill 说明遇到某类任务“应该怎样做”。目标层最终要解决的是不让模型用一段看似合理的回答替代用户真正想要的结果。二、执行用状态转换持续缩小目标差距Agent 的核心不是大模型而是 Agent Runtime 模型只能根据上下文提出概率性的下一步Skill 提供任务方法Tool 执行真实动作Runtime 才是整个系统的控制中枢它维护任务状态、校验模型行动、调度工具、处理失败与恢复、控制预算和生命周期并依据工具结果、外部回执等可靠证据判断目标是否真正完成从而把不可控的模型生成转化为可执行、可恢复、可验证的任务过程。目标明确后Agent 比较当前状态与目标已经知道 出行地点、日期和提醒时间。 仍然缺少 天气事实、出行建议、提醒记录。模型根据 Skill 判断下一步应该查询天气于是提出一个 Tool Call{name:get_weather,arguments:{location:上海迪士尼,date:2026-09-04}}Tool Call 只是行动请求不是已经发生的行动。Runtime 仍需检查工具是否存在、参数是否合法、用户是否有权限以及当前状态是否允许执行。天气工具返回“阵雨降雨概率 75%”后结果进入 Agent 状态。模型据此生成携带雨具、防滑鞋和替换袜子的建议然后请求创建早上 7 点的提醒。整个过程是连续的状态转换只有用户目标 → 获得天气事实 → 生成出行建议 → 创建提醒 → 等待触发 → 发送提醒Messages 和 Memory 在这里承担不同责任。Messages 保存模型需要理解的过程Memory 保存程序需要判断的事实例如天气数据、提醒 ID 和当前执行状态。Messages 服务于模型理解 Memory 服务于程序控制。NanoAgent 把这种结构表达得很直接AgentState保存消息、Memory 和停止状态stepAgent推进一步loopAgent持续推进直到任务完成、等待用户、发生错误或达到执行上限。Skill、Model、Tool 和 Workflow 也在执行过程中形成明确分工Skill 提供方法 Model 决定下一步 Tool 执行具体动作 Workflow 固化不能跳过的步骤 Runtime 验证行动并更新状态。关键不在于循环运行了多少次而在于每次执行是否获得了新事实、完成了新行动或者减少了一个关键未知。三、证据完成必须由事实(与检查契约)证明假设提醒服务返回{reminderId:rem_78431,status:scheduled}这只能证明提醒已经创建不能证明用户已经收到提醒Scheduled ≠ Sent ≠ Delivered如果 Agent 此时宣布整个任务完成就产生了“假成功”中间步骤成功被误认为用户目标已经实现。可靠的完成判断需要三类证据事实证据天气数据、地点、日期和数据来源 行动证据提醒 ID、计划时间和外部系统状态 交付证据实际发送时间和送达回执。错误处理同样要依据证据。如果创建提醒时请求超时系统不能直接再次创建。外部服务可能已经成功只是响应没有返回。正确方法是携带幂等标识查询原请求状态再决定是否重试避免用户收到两条提醒。这说明 Agent 的错误处理不能只有一句“失败就重试”参数错误 → 修正参数 信息不足 → 询问用户 权限错误 → 停止并请求授权 瞬时故障 → 有界重试 外部状态未知 → 先查询状态 持续不可用 → 降级或结束。最终Agent 不是根据模型的语气判断完成而是检查任务契约中的完成条件。只有天气有来源、建议有依据、提醒有记录、通知有回执系统才拥有一条从目标到结果的完整证据链。因此Agent 的核心可以压缩成一句话Agent 使用 Skill 明确方法使用 Model 判断下一步使用 Tool 作用于外部世界再由 Runtime 根据状态和证据决定继续、恢复还是结束。理解任何 Agent都可以从三个问题开始目标是否清楚 执行是否受控 完成是否有证据这也是后续整个系列的主线。
Agent 的本质不是让大模型反复调用工具而是把用户意图转化为可验证的任务目标由 Skill 提供解决方法Model 根据当前状态决定下一步Tool 负责执行真实动作Runtime 通过状态机约束执行、处理失败并持续推进最终依据工具结果、外部回执和交付状态等证据而不是模型的一句“已完成”判断用户目标是否真正实现。用户目标 │ ▼ ┌──────────────┐ │ Runtime │ │ 推进与约束任务 │ └──────┬───────┘ │ 当前状态 ▼ ┌──────────────┐ │ Model │ │ 判断下一步 │ └───┬──────┬───┘ │ ▲ 方法约束 │ 行动结果 │ │ ┌──────▼───┐ │ ┌──────────┐ │ Skill │ │ │ Tool │ │ 专家方法 │ └──│ 外部行动 │ └──────────┘ └────┬─────┘ │ ▼ 外部世界很多 Agent 演示都从一个循环开始模型生成工具调用系统执行工具再把结果交还给模型。这解释了 Agent 怎么跑却没有解释它为什么可靠。真正困难的问题是模型为什么要调用这个工具执行失败后怎么办模型说“完成了”任务就真的完成了吗从第一性原理看Agent 只需要持续回答三个问题目标用户真正想完成什么 执行为了接近目标下一步应该做什么 证据凭什么判断任务已经完成Model、Skill、Tool、Memory、Workflow 看似分散本质上都服务于这三类判断。下面用一个真实任务贯穿这条主线我明天去上海迪士尼。请根据天气告诉我带什么并在早上 7 点提醒我。一、目标把用户表达转化为任务契约用户给出的通常是一段自然语言而不是一份严格的任务定义。在这个例子中用户表面上提出了三个要求查询天气、生成建议、创建提醒。但系统还需要确认日期、时区、具体地点以及“提醒我”究竟意味着创建成功还是最终送达。如果不先定义目标模型很容易生成一句明天可能下雨建议带伞我会在早上 7 点提醒你。这段话听起来完成了任务但系统可能既没有查询天气也没有创建提醒。因此Agent 首先要把用户意图整理成可执行、可验收的任务目标 根据上海迪士尼明天的天气生成出行建议 在 Asia/Shanghai 时区早上 7 点发送提醒。 完成条件 获得对应地点和日期的天气数据 建议确实基于该数据 提醒成功创建并在指定时间送达。Skill 在这里提供解决问题的方法。它规定这类任务应该先规范化时间和地点再查询天气、生成建议、创建提醒并保存执行结果。所以Skill 不是 Tool。Tool 说明系统“能做什么”Skill 说明遇到某类任务“应该怎样做”。目标层最终要解决的是不让模型用一段看似合理的回答替代用户真正想要的结果。二、执行用状态转换持续缩小目标差距Agent 的核心不是大模型而是 Agent Runtime 模型只能根据上下文提出概率性的下一步Skill 提供任务方法Tool 执行真实动作Runtime 才是整个系统的控制中枢它维护任务状态、校验模型行动、调度工具、处理失败与恢复、控制预算和生命周期并依据工具结果、外部回执等可靠证据判断目标是否真正完成从而把不可控的模型生成转化为可执行、可恢复、可验证的任务过程。目标明确后Agent 比较当前状态与目标已经知道 出行地点、日期和提醒时间。 仍然缺少 天气事实、出行建议、提醒记录。模型根据 Skill 判断下一步应该查询天气于是提出一个 Tool Call{name:get_weather,arguments:{location:上海迪士尼,date:2026-09-04}}Tool Call 只是行动请求不是已经发生的行动。Runtime 仍需检查工具是否存在、参数是否合法、用户是否有权限以及当前状态是否允许执行。天气工具返回“阵雨降雨概率 75%”后结果进入 Agent 状态。模型据此生成携带雨具、防滑鞋和替换袜子的建议然后请求创建早上 7 点的提醒。整个过程是连续的状态转换只有用户目标 → 获得天气事实 → 生成出行建议 → 创建提醒 → 等待触发 → 发送提醒Messages 和 Memory 在这里承担不同责任。Messages 保存模型需要理解的过程Memory 保存程序需要判断的事实例如天气数据、提醒 ID 和当前执行状态。Messages 服务于模型理解 Memory 服务于程序控制。NanoAgent 把这种结构表达得很直接AgentState保存消息、Memory 和停止状态stepAgent推进一步loopAgent持续推进直到任务完成、等待用户、发生错误或达到执行上限。Skill、Model、Tool 和 Workflow 也在执行过程中形成明确分工Skill 提供方法 Model 决定下一步 Tool 执行具体动作 Workflow 固化不能跳过的步骤 Runtime 验证行动并更新状态。关键不在于循环运行了多少次而在于每次执行是否获得了新事实、完成了新行动或者减少了一个关键未知。三、证据完成必须由事实(与检查契约)证明假设提醒服务返回{reminderId:rem_78431,status:scheduled}这只能证明提醒已经创建不能证明用户已经收到提醒Scheduled ≠ Sent ≠ Delivered如果 Agent 此时宣布整个任务完成就产生了“假成功”中间步骤成功被误认为用户目标已经实现。可靠的完成判断需要三类证据事实证据天气数据、地点、日期和数据来源 行动证据提醒 ID、计划时间和外部系统状态 交付证据实际发送时间和送达回执。错误处理同样要依据证据。如果创建提醒时请求超时系统不能直接再次创建。外部服务可能已经成功只是响应没有返回。正确方法是携带幂等标识查询原请求状态再决定是否重试避免用户收到两条提醒。这说明 Agent 的错误处理不能只有一句“失败就重试”参数错误 → 修正参数 信息不足 → 询问用户 权限错误 → 停止并请求授权 瞬时故障 → 有界重试 外部状态未知 → 先查询状态 持续不可用 → 降级或结束。最终Agent 不是根据模型的语气判断完成而是检查任务契约中的完成条件。只有天气有来源、建议有依据、提醒有记录、通知有回执系统才拥有一条从目标到结果的完整证据链。因此Agent 的核心可以压缩成一句话Agent 使用 Skill 明确方法使用 Model 判断下一步使用 Tool 作用于外部世界再由 Runtime 根据状态和证据决定继续、恢复还是结束。理解任何 Agent都可以从三个问题开始目标是否清楚 执行是否受控 完成是否有证据这也是后续整个系列的主线。
