# Tool Calling 就是 RPC 吗？接口没错，任务为什么错了

用户说：“查一下订单服务最近 30 分钟的日志。”

助手提出了一个调用请求：读取订单服务日志，时间范围是 43200 分钟。换算一下，是 30 天。

假设这个接口允许查询最多 30 天，当前用户也有访问权限。请求通过了类型检查和权限检查，服务准确返回了 30 天的记录，监控面板上甚至全是成功状态。

这个任务做对了吗？

显然没有。服务履行了接口契约，却没有完成用户要求。这个很小的反例，恰好解释了后端工程师理解 Agent 时容易漏掉的一层。

> 本文使用预设参数构造教学反例。配套页面实际执行离线校验，没有调用真实模型，也不代表某个模型的错误率。

## 先把一次调用拆开

![模型提出候选，应用检查并执行](02-flow.png)

在应用执行工具的常见路径中，模型先根据任务提出工具名和参数；应用接收这个候选请求，检查后调用本地函数或远端服务；结果返回后，再供模型或其他程序继续使用。平台也可能托管执行，责任仍然需要有人承担。

因此，Tool Calling 与 RPC 并不是可以直接画等号的两个词。一次工具执行可能走 RPC，也可能只调用一个本地函数。RPC 描述跨进程调用的机制；这里更值得关注的是，调用意图怎样从自然语言任务中产生。

传统后端同样会出现业务理解错误。变化在于，部分原本由开发者固定下来的工具选择和参数组合，如今交给模型在运行时生成。接口的输入空间还是那个空间，产生输入的策略却变了。

服务端仍要回答“这个请求能否执行”，应用还要回答“这个请求为什么符合当前任务”。两者不能互相代替。

## 为什么 JSON 合法不够

![30 分钟的任务被转换成 30 天的候选查询](03-counterexample.png)

`window_minutes: 43200` 在我们的教学接口里完全合法。它是整数，没有超过上限，也没有访问另一个租户。

问题在于：工具的通用能力范围，通常比某一次任务允许的范围更大。

一个日志服务可以支持一个月的查询，不代表每次用户都需要一个月。一个账户具有多个项目的权限，也不代表当前任务允许同时处理这些项目。甚至同一个资源、同一种操作，只要时间、数量或条件偏离目标，仍然可能做错业务。

把这些问题统称为“模型幻觉”太粗了。这里的错误可以准确描述为：**候选参数落在接口允许的范围内，却落在当前任务要求的范围外。**

错误描述越具体，修复才越可能落到实际执行点。

## 一个小修复，以及它的适用条件

我们先把已经正确解析、经用户确认的任务保存下来：服务是 `orders`，时间范围是 30 分钟。然后在调用工具前，将候选参数与这个任务比较。

配套演示保留了两种版本。版本 A 只检查结构与权限，会执行 30 天的模拟查询；版本 B 增加任务范围检查，发现 43200 与 30 不一致，在执行前拒绝候选。

![同一个候选在两套检查下得到不同结果](07-fix.png)

这项检查之所以有效，是因为这个例子的约束已经清楚，而且能确定性地比较。实际调查可能允许合理扩大窗口；这种扩展应当有明确策略，或者取得新的确认。不能把所有任务都写成“参数必须等于原句中的数字”。

更重要的前提是，保存下来的任务本身要正确。如果最初把“30 分钟”解析成“30 天”，候选和任务就可能一致地出错。后续一致性检查无法修复上游的共同误解。

这个修复证明的是一项约束得到了执行。它没有证明模型理解能力提高，也没有证明整套 Agent 已经可靠。

## 四种正确性，需要分别验收

![结构、任务语义、权限、结果四项检查](04-checks.png)

**结构正确**，指字段能被程序处理，满足类型、必填项和通用范围。字符串“30”能否接受，要由接口契约决定；本例要求整数。

**任务语义正确**，指工具与参数符合当前目标和约束。部分约束可以写成规则；另一些需要证据、评测或人工判断，不能假设另一个模型打分就一定正确。

**权限正确**，指可信身份允许访问目标资源。权限来自服务端和会话上下文，不能因为模型在参数里写了一个租户标识就成立。

**结果可用**，指执行后实际拿到了什么，以及这些观察支持哪些结论。日志中出现 5xx，只能证明观察到了相应记录；要断言数据库是故障根因，还需要额外证据。

这四项是责任划分，并非所有系统必须照搬的执行顺序。权限要在资源访问前检查，结果核验则在取得观察之后发生。失败处理也应当不同：格式错误可以反馈修正，缺少任务条件可能需要澄清，无权限不能靠不断换参数绕过。

## MCP 和 Skills，为什么也不能补上所有保证

MCP 为能力和上下文交换提供协议约定，帮助宿主、客户端和服务器协作。协议让连接和互操作更一致，但协议接通本身不会证明“这次应该查 30 分钟还是 30 天”。[MCP 官方架构](https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture)

Skills 可以组织任务指令、参考资料与脚本，让助手按需使用。一个技能可以要求“先确认时间范围”，但写下这条规程，与执行器强制检查，是不同的保证。规程中的租户要求也不能代替服务端授权。[Agent Skills 官方说明](https://agentskills.io/home)

所以，这几个组件可以组合使用。选型时需要说明：哪个组件提出动作，哪个执行约束，哪个记录证据，哪个负责验收。把名词全部装进架构图，并不会自动填上责任空白。

## 后端工程师的价值，落在这些执行点上

超时、重试、幂等、隔离、授权和审计，仍然决定工具执行是否可靠。与此同时，工具的描述、参数设计和结果表达会影响模型如何使用它，需要结合具体任务验证。工具设计面向模型这一使用者，本身就是工程工作的一部分。[Anthropic：为 Agent 编写工具](https://www.anthropic.com/engineering/writing-tools-for-agents)

如果你正在接手一个 Agent 项目，可以先选一个真实任务，回放一次失败，把三个问题问清楚：谁提出动作？谁检查边界？谁验收结果？

“接口返回成功”只能回答其中一部分。把这条链补全，后端经验才真正变成 Agent 系统的可靠性。

---

作者说明：本文配图为原创排版与教学图示。资料核对日期为 2026-09-21。图片中的候选结构是本地教学协议，不对应特定模型厂商的 API。演示使用固定场景，未评测在线模型，也未实现生产服务端授权。