切换深色模式
Tool Calling 就是 RPC 吗？接口没错，任务为什么错了
用户说：“查一下订单服务最近 30 分钟的日志。”
助手提出了一个调用请求：读取订单服务日志，时间范围是 43200 分钟。换算一下，是 30 天。
假设这个接口允许查询最多 30 天，当前用户也有访问权限。请求通过了类型检查和权限检查，服务准确返回了 30 天的记录，监控面板上甚至全是成功状态。
这个任务做对了吗？
显然没有。服务履行了接口契约，却没有完成用户要求。这个很小的反例，恰好解释了后端工程师理解 Agent 时容易漏掉的一层。
本文使用预设参数构造教学反例。配套页面实际执行离线校验，没有调用真实模型，也不代表某个模型的错误率。
先把一次调用拆开
在应用执行工具的常见路径中，模型先根据任务提出工具名和参数；应用接收这个候选请求，检查后调用本地函数或远端服务；结果返回后，再供模型或其他程序继续使用。平台也可能托管执行，责任仍然需要有人承担。
因此，Tool Calling 与 RPC 并不是可以直接画等号的两个词。一次工具执行可能走 RPC，也可能只调用一个本地函数。RPC 描述跨进程调用的机制；这里更值得关注的是，调用意图怎样从自然语言任务中产生。
传统后端同样会出现业务理解错误。变化在于，部分原本由开发者固定下来的工具选择和参数组合，如今交给模型在运行时生成。接口的输入空间还是那个空间，产生输入的策略却变了。
服务端仍要回答“这个请求能否执行”，应用还要回答“这个请求为什么符合当前任务”。两者不能互相代替。
为什么 JSON 合法不够
window_minutes: 43200 在我们的教学接口里完全合法。它是整数，没有超过上限，也没有访问另一个租户。
问题在于：工具的通用能力范围，通常比某一次任务允许的范围更大。
一个日志服务可以支持一个月的查询，不代表每次用户都需要一个月。一个账户具有多个项目的权限，也不代表当前任务允许同时处理这些项目。甚至同一个资源、同一种操作，只要时间、数量或条件偏离目标，仍然可能做错业务。
把这些问题统称为“模型幻觉”太粗了。这里的错误可以准确描述为：候选参数落在接口允许的范围内，却落在当前任务要求的范围外。
错误描述越具体，修复才越可能落到实际执行点。
一个小修复，以及它的适用条件
我们先把已经正确解析、经用户确认的任务保存下来：服务是 orders，时间范围是 30 分钟。然后在调用工具前，将候选参数与这个任务比较。
配套演示保留了两种版本。版本 A 只检查结构与权限，会执行 30 天的模拟查询；版本 B 增加任务范围检查，发现 43200 与 30 不一致，在执行前拒绝候选。
这项检查之所以有效，是因为这个例子的约束已经清楚，而且能确定性地比较。实际调查可能允许合理扩大窗口；这种扩展应当有明确策略，或者取得新的确认。不能把所有任务都写成“参数必须等于原句中的数字”。
更重要的前提是，保存下来的任务本身要正确。如果最初把“30 分钟”解析成“30 天”，候选和任务就可能一致地出错。后续一致性检查无法修复上游的共同误解。
这个修复证明的是一项约束得到了执行。它没有证明模型理解能力提高，也没有证明整套 Agent 已经可靠。
四种正确性，需要分别验收
结构正确，指字段能被程序处理，满足类型、必填项和通用范围。字符串“30”能否接受，要由接口契约决定；本例要求整数。
任务语义正确，指工具与参数符合当前目标和约束。部分约束可以写成规则；另一些需要证据、评测或人工判断，不能假设另一个模型打分就一定正确。
权限正确，指可信身份允许访问目标资源。权限来自服务端和会话上下文，不能因为模型在参数里写了一个租户标识就成立。
结果可用，指执行后实际拿到了什么，以及这些观察支持哪些结论。日志中出现 5xx，只能证明观察到了相应记录；要断言数据库是故障根因，还需要额外证据。
这四项是责任划分，并非所有系统必须照搬的执行顺序。权限要在资源访问前检查，结果核验则在取得观察之后发生。失败处理也应当不同：格式错误可以反馈修正，缺少任务条件可能需要澄清，无权限不能靠不断换参数绕过。
MCP 和 Skills，为什么也不能补上所有保证
MCP 为能力和上下文交换提供协议约定，帮助宿主、客户端和服务器协作。协议让连接和互操作更一致，但协议接通本身不会证明“这次应该查 30 分钟还是 30 天”。MCP 官方架构
Skills 可以组织任务指令、参考资料与脚本，让助手按需使用。一个技能可以要求“先确认时间范围”，但写下这条规程，与执行器强制检查，是不同的保证。规程中的租户要求也不能代替服务端授权。Agent Skills 官方说明
所以，这几个组件可以组合使用。选型时需要说明：哪个组件提出动作，哪个执行约束，哪个记录证据，哪个负责验收。把名词全部装进架构图，并不会自动填上责任空白。
后端工程师的价值，落在这些执行点上
超时、重试、幂等、隔离、授权和审计，仍然决定工具执行是否可靠。与此同时，工具的描述、参数设计和结果表达会影响模型如何使用它，需要结合具体任务验证。工具设计面向模型这一使用者，本身就是工程工作的一部分。Anthropic：为 Agent 编写工具
如果你正在接手一个 Agent 项目，可以先选一个真实任务，回放一次失败，把三个问题问清楚：谁提出动作？谁检查边界？谁验收结果？
“接口返回成功”只能回答其中一部分。把这条链补全，后端经验才真正变成 Agent 系统的可靠性。
作者说明：本文配图为原创排版与教学图示。资料核对日期为 2026-09-21。图片中的候选结构是本地教学协议，不对应特定模型厂商的 API。演示使用固定场景，未评测在线模型，也未实现生产服务端授权。