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，都可以从三个问题开始：
目标是否清楚？ 执行是否受控？ 完成是否有证据？这也是后续整个系列的主线。
