工具使用与函数调用

Gemini Robotics 2 里那个负责规划的推理模型，把动作模型和导航 API 声明为工具——它自己不移动机器人，它调用一个会移动机器人的东西。这和一个聊天产品调用搜索接口是同一个形状。

这个形状比任何协议都更老、也更通用，而认出它，是在比较协议、SDK 和智能体产品时不被品牌包装带走的唯一办法。

为什么要把推理和行动分开

不分开，两类完全不同的失败会混在一起：想错了（该不该调、调哪个、参数怎么填）和做错了（接口超时、翻页错、返回不合预期）。混在一起的直接后果是没法归因，于是修复动作只剩「重试」。

Ai2 的 Shippy 把这条推到了尽头：行动一侧是确定性的 CLI，可以单独测试；不确定性被压缩在推理一侧。而 GitHub 重写 Copilot 代码审查的经历给了反向证据——同一批工具在不同指令下表现差很多，说明方差确实主要长在推理这一侧。

一次工具调用其实是三件事

1. 决定要不要调、调哪一个——推理。
2. 把意图变成一次合法调用——结构化输出。
3. 读懂返回值并决定下一步——又是推理。

只有第 2 步可以被机械验证，所以它也是最早被标准化的一步（函数调用、JSON schema）。第 1 步和第 3 步没有 schema 可依，它们只能靠评测和轨迹回放去看。很多团队以为接好了函数调用就等于接好了工具使用，缺的正是这两头。

协议是这个模式的包装，不是模式本身

MCP 从有状态改成无状态之后，工具还是那些工具、三步还是那三步，变的是部署形态。Ollama 把本地运行时变成智能体工作台，托管智能体把 runtime 搬到平台侧——同样没有改变这个模式。

所以评估一个新协议或新 SDK 时，先把它翻译回上面那三步：它替你做了哪一步，剩下的还归你。

失败的调用是数据，不是噪声

NVIDIA 在阐述智能体时代的数据主张时点名了工程轨迹、工具调用失败、多步推理这几类数据——它们是训练与评测的材料。一个把失败调用直接吞掉的系统，等于每天都在扔掉最有价值的那部分记录。

与相邻条目的分工

这一条是概念：为什么把推理与行动分开、一次调用由哪三步组成。单个工具怎么接得可维护，是「工具集成模式」；输入输出约定本身怎么定，是「API 契约与接口边界」；整条链路怎么分层与交接，是「智能体工作流设计」；而调用完成之后这一步算不算做完，是「完成判定与验收信号」。