# Tool Calling 就是 RPC 吗？——口播与录屏稿

本稿用于不出镜的录屏讲解。建议准备卡片 01—08，以及同包 recording.html 演示页。下面时间仅是剪辑规划，实际时长以试读为准，预计约 5—7 分钟；没有生成或声称已经录制视频。

## 00:00—00:35｜先给一个矛盾

**画面：** 卡片 01 停留约 3 秒，切到卡片 03。圈出“30 分钟”和“43200 分钟”。

**口播：**

如果你做后端，第一次看到 Tool Calling，可能会觉得：这不就是调接口吗？

执行那一半，这个理解很有用。但先看一个问题：用户要查最近三十分钟的日志，候选请求却传了四万三千二百分钟，也就是三十天。

字段是整数，JSON 没问题，接口也支持这个范围。服务准确返回了三十天的记录。所有组件都正常，为什么任务还是做错了？

## 00:35—01:15｜把调用拆成两层

**画面：** 卡片 02。先指向“提出候选”，再指向“检查并执行”。

**口播：**

关键在于，谁决定了这次调用。

我们这里讨论的是应用执行工具的常见路径。模型先提出工具名和参数，应用解析并检查，再调用本地函数或者远端服务，最后把结果交回模型。

所以一次工具调用可以经过 RPC，也可以只运行一个本地函数。模型所在的平台也可能托管工具执行，那只是执行位置变了，检查责任仍然需要明确。

执行端的权限、超时、幂等，都是熟悉的后端问题。额外要判断的是：模型为什么选这个工具，为什么传这组参数？

## 01:15—02:25｜展示错误版本与修复版本

**画面：** 打开演示页，选择“① 错误时间范围”。先看候选 JSON，再依次指向两列的最终状态。

**口播：**

我准备了一个离线回放。这里没有调用模型，参数是预设的；实际运行的是两套校验逻辑。这样可以单独检查程序在收到错误候选时会做什么。

先看顶部，用户已经确认了任务：订单服务，最近三十分钟。我们把这个确认后的结构当作可信输入。

版本 A 只检查字段结构和访问权限。四万三千二百这个值在工具允许的通用范围内，所以请求执行了。工具没有违约，它只是按参数工作。

版本 B 增加了一项：把候选参数与当前任务比较。它发现时间范围不同，于是在执行前拦截。

注意，修复没有证明模型更聪明，也没有证明所有语义问题都能写成规则。它只证明这一项已经明确的任务约束，终于被程序检查了。

## 02:25—03:15｜正例、错误类型和边界

**画面：** 依次选择“② 正确参数”“③ 字段类型错误”“④ 无权访问”，最后切回正确参数。

**口播：**

把参数改为三十，两个版本都可以执行，说明修复不是把所有请求都拒绝。

如果把三十传成字符串，结构检查就应当拦截。如果请求一个当前会话无权访问的服务，就应该在权限层拒绝。

这些错误不能都用“请模型重新想一遍”来处理。字段错误可以反馈修正，权限不足不能靠不断换参数尝试，缺少任务信息则可能需要澄清。

还有一个前提：如果用户原本说三十分钟，最初的任务解析却已经写成三十天，那么后面的“一致性检查”也可能一起错。任务理解本身仍需要校验，必要时让用户确认。

## 03:15—04:05｜四道检查各负责什么

**画面：** 卡片 04，按结构、任务语义、权限、结果逐项指示；卡片 05 用作转场。

**口播：**

我会把一次调用拆成四道检查。

结构，检查字段能不能被程序处理。任务语义，检查这组参数是否符合当前目标。权限，检查当前身份是否允许访问这个资源。结果，检查实际返回了什么，以及它是否足以支撑后续结论。

这四项是责任划分，不要求所有系统机械使用同一种执行顺序。例如权限应该在资源访问之前检查；结果核验则发生在得到观察之后。

查到了日志，并不代表已经证明故障根因。工具成功与任务成功，需要分别说明。

## 04:05—04:55｜MCP、Skills 放在哪一层

**画面：** 卡片 06。保持画面稳定，不切到协议细节。

**口播：**

顺便放好两个经常一起出现的词。

MCP 标准化能力和上下文的交换方式，有自己的消息与互操作约定。它有接入价值，但不会替你判断这次日志查询是不是符合用户任务。

Skills 可以打包操作规程、资料和脚本，让助手按需使用。规程写“只能查当前租户”，不能代替服务端的租户检查。

Tool Calling、MCP 和 Skills 可以组合，但它们分别涉及调用意图、连接协议和任务规程。一个组件正常，不能替其他层作担保。

## 04:55—05:45｜回到后端工程师真正要做的事

**画面：** 卡片 07，停留后切到卡片 08。结尾展示演示页的边界说明。

**口播：**

回到最初的问题，Tool Calling 是不是 RPC？

更准确的说法是，工具执行可以复用函数调用和 RPC 的技术；模型提出调用的过程，还增加了一项对决策质量的检查。

你可以先问三个问题：谁提出动作？谁检查权限和任务范围？谁核验执行结果与最终结论？

如果都回答“模型会处理”，系统的责任边界还没设计清楚。如果只回答“接口返回成功”，也没有完成任务验收。

后端工程师已有的经验非常有用。我们需要把它用到具体执行边界上，再为语义决策补上证据和检查。

这期的卡片和离线案例使用同一组数据。你遇到过哪些“接口完全正常，业务却做错了”的 Agent 问题？可以从那个案例开始拆。

## 录制前检查

- 演示页顶部“预设候选、离线运行”保持可见；不得描述为在线模型输出。
- 先试点四个按钮，确认两列状态与口播一致。键盘 1—4 同样可以切换。
- 显示比例以代码、结果和边界说明清晰为准；窗口窄时两列会纵向排列。
- 鼠标停在当前讲解位置，不连续晃动。可以剪掉切页和等待。
- 演示页面在浏览器里运行逻辑；生产服务端授权并未在本例实现。
- 结尾保留“工具返回日志不等于证明根因”，不要把局部修复讲成整个 Agent 已经可靠。

资料与图片内容核对日期：2026-09-21。语速和时间轴为制作建议，不是实测成片时长。