切换深色模式
Tool Calling 就是 RPC 吗？
AGENT 去魅 · 图文与录屏 01
接口成功，任务却错了——用“30 分钟变成 30 天”的反例，讲清工具执行与调用决策之间的区别。
本期面向后端程序员：从熟悉的接口调用切入，沿着一个案例依次展开调用链、四项检查、修复前后与适用边界。图片、正文和口播使用相同案例。
| 成品 | 规格与用途 |
|---|---|
| 图文卡片 | 8 张 PNG，1080 × 1440，按 01—08 顺序发布 |
| 发布文案 | 下方可直接复制的短正文，适合配图发布 |
| 深度长文 | 阅读全文，适合博客与公众号 |
| 口播与分镜 | 预计 5—7 分钟，含逐段台词与画面安排 |
| 录屏演示 | 四个可切换案例，离线回放预设参数 |
图文卡片
点击任意卡片查看原图。完整素材包包含全部原尺寸图片。
01 · 封面：Tool Calling 就是 RPC 吗？
02 · 流程：模型提出候选，应用检查执行
03 · 反例：30 分钟变成 30 天
04 · 责任：四项正确性检查
05 · 经验：后端工程与决策质量
06 · 概念：Tool Calling、MCP、Skills
07 · 修复：增加任务范围检查
08 · 结尾：三个架构问题配图发布正文
看到 Agent 调工具，很多后端工程师的第一反应是：这不就是调接口吗？
执行那一半，确实有大量熟悉的东西：参数校验、权限、超时、幂等、错误处理。
但先看一个反例：用户要查最近 30 分钟的日志，候选参数却是 43200 分钟，也就是 30 天。
JSON 合法，字段是整数，接口支持这个范围，当前用户也有权限。服务甚至准确返回了 30 天的记录。
接口没有执行错，任务却已经偏了。
这就是我想拆开的两层：
① 模型根据任务提出工具和参数； ② 程序检查候选请求，执行工具，再核对结果。
Tool Calling 可以落到本地函数，也可以经过 RPC。执行机制相似，不代表产生调用意图的过程完全相同。
在这组图里，我用同一个日志查询案例讲清四道检查：结构、任务语义、权限、结果。MCP 负责能力交换，Skills 可以组织规程和资源；它们各有价值，也各有边界。
配套演示使用预设参数，真实运行离线校验，没有拿模拟过程冒充模型实测。修复也有前提：我们已经拿到了用户确认的结构化任务。
后端经验可以继续用。需要补上的，是对“这次调用为什么应该发生”的检查。
你做过的 Agent 项目里，最常见的是选错工具、传错参数，还是结果解释错了？
#Agent开发 #后端开发 #ToolCalling #AI工程 #技术分享
口播与录屏分镜
本稿用于不出镜的录屏讲解。建议准备卡片 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。语速和时间轴为制作建议，不是实测成片时长。
单独下载稿件
资料核对：2026-09-21。参考 Anthropic 工具设计文章、MCP 官方架构、Agent Skills 官方说明。更完整的概念分析见本专题第 02 篇。