架构视角对比：传统RPC调用链与模型驱动工具调用的控制权差异

一、对比背景：为什么需要重新审视“谁在发起调用”

在经典微服务体系中，服务之间的调用关系由确定性代码编写和编排。无论是简单的点对点调用，还是复杂的服务编排（如Saga、工作流引擎），决策逻辑始终是可审计、可回放、可测试的代码路径。调用链的控制权牢牢掌握在开发者手中：什么条件下调用哪个服务、传什么参数、失败后如何补偿，全部由代码定义。

随着大模型能力被引入业务流程，一种新的调用形态开始出现：由模型决定“是否需要调用工具、调用哪个工具、传什么参数”，协议层负责把模型生成的意图搬运到后端服务。这一形态在协议层面看似只是“换了一种传输格式”，但在架构层面发生的是一次控制权的迁移——调用发起者从确定性代码变成了概率性模型。

本文对比的对象正是这两类调用链：

• 对象A：传统RPC调用链——由确定性代码编排、参数结构化、决策路径可审计的服务调用方式；
• 对象B：模型驱动工具调用链——由大模型进行意图判断与参数生成、协议层原样转发、后端服务被动接收的调用方式。

需要强调的是，本文讨论的是架构控制权与责任边界问题，而非具体传输协议之争。JSON-RPC只是对象B常见的一种传输形式，换成其他序列化方式并不会改变问题的本质。

二、对象定义：两类调用链分别是什么

2.1 传统RPC调用链

传统RPC调用链的核心特征是“代码即决策”。一次调用通常包含以下要素：

• 调用条件由if/else、状态机或编排引擎的规则决定；
• 调用参数由结构化输入构造，类型系统或校验层可以在调用发起前拦截非法参数；
• 调用链路上的每一步都可打点、可回放、可单元测试；
• 权限校验通常内嵌在服务端或网关层，与调用方身份绑定。

在这种模式下，即使编排逻辑复杂，决策路径仍然是“可审计的代码路径”。出现问题时，可以通过日志、链路追踪和代码回溯定位到具体分支。

2.2 模型驱动工具调用链

模型驱动工具调用链的核心特征是“模型即决策者”。其典型流程为：

1. 用户以自然语言表达意图；
2. 模型进行概率推断，判断是否需要调用工具、调用哪个工具；
3. 模型生成参数，参数往往是自然语言解析后的结构化结果；
4. 协议层将模型生成的意图原样搬运到后端服务；
5. 后端服务执行并返回结果。

从协议视角看，这一链路完全合法：消息格式正确、方法名存在、参数结构清晰。但从架构视角看，协议层只承担了“搬运”职责，它不做也无法做参数语义校验、权限校验和业务上下文一致性验证。一旦后端服务默认信任协议层的转发行为，系统就发生了一个危险的等价变换：不是给模型接工具，而是把内部接口暴露给一个不可控的决策者。

三、相同点分析：两者在工程目标上的交集

尽管控制权归属不同，两类调用链在工程目标上仍有明显交集：

• 都追求服务复用：两者都希望后端能力被多次调用，而不是为每个前端场景重复实现；
• 都需要可观测性：无论调用由代码还是模型发起，日志、链路追踪、指标监控都是定位问题的基础设施；
• 都面临权限与安全问题：调用方身份认证、数据隔离、最小权限原则在两类链路中同样重要；
• 都依赖接口契约：工具描述或RPC接口定义本质上都是一种契约，契约清晰度直接影响调用质量；
• 都存在失败处理需求：超时、重试、幂等、补偿在两类链路中都是必须考虑的问题。

这些共同点意味着：传统RPC体系中积累的很多治理经验（如网关鉴权、参数校验、审计日志）并非作废，而是需要以新的方式重新安置到模型驱动链路上。

四、核心差异分析：控制权、校验责任与安全边界

4.1 控制权归属：确定性代码 vs 概率推断

这是最根本的差异。传统RPC中，“调用什么”由代码决定，决策逻辑可回放、可测试；模型驱动链路中，“调用什么”由模型推断决定，同一输入在不同时刻可能产生不同调用决策。这种不确定性不是缺陷，而是模型能力的固有属性，但它对系统设计提出了新要求：不能假设调用行为是稳定可复现的。

4.2 参数来源：结构化输入 vs 自然语言解析结果

传统RPC的参数来自结构化输入，类型系统和校验层可以在调用前拦截明显错误。模型驱动链路的参数来自自然语言解析，模型可能生成语法合法但语义危险的参数。例如下面这段示意性请求：

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "database_query",
    "arguments": {
      "sql": "DELETE FROM users WHERE id = 'U123'; -- 注意此处语义危险"
    }
  },
  "id": 1
}

从协议视角看，这条请求没有任何问题：格式合法、方法名正确、参数结构清晰。但从架构视角看，它暴露的是一次责任缺失——协议层只负责搬运，不负责判断这条SQL是否应该被执行。参数语义校验、权限校验、业务上下文一致性验证，协议层不做也无法做。

4.3 校验责任：内嵌于调用方 vs 下沉到后端

传统RPC中，校验责任通常分布在调用方（参数构造校验）和服务端（权限与业务校验）两侧，形成多层防线。模型驱动链路中，协议层把校验责任几乎全部推给了后端服务。如果后端服务默认信任转发行为，就等于把内部接口直接暴露给一个不可控的决策者。因此，模型驱动链路必须显式补齐三道防线：

• 参数语义校验：在执行前判断参数是否符合业务语义，而非仅仅格式合法；
• 权限校验：以调用方真实身份（而非协议层身份）进行鉴权，避免模型成为权限放大器；
• 业务上下文一致性验证：判断当前调用是否与业务流程所处阶段一致，防止跨阶段越权操作。

4.4 安全与合规：可审计性差异

传统RPC的决策路径可审计、可回放，出现异常时可以定位到具体代码分支。模型驱动链路的决策路径包含概率推断环节，审计难度更高。这要求在链路上补充“决策记录”：记录模型为何选择该工具、参数如何生成、当时上下文是什么，以便事后追溯。同时，高风险操作（如删除、转账、权限变更）应引入人工确认或二次校验，而不是完全依赖模型判断。

4.5 运维与成本结构

传统RPC的运维重点在服务可用性、容量规划和版本兼容；模型驱动链路的运维额外增加了模型行为监控、工具描述维护、误调用率跟踪等成本。工具描述（契约）的清晰度直接影响模型调用质量，描述模糊会显著提高误调用概率，这部分维护成本在传统RPC中并不存在。

五、对比表格：关键差异一览

对比维度	传统RPC调用链	模型驱动工具调用链
调用发起者	确定性代码	概率性模型
调用条件	if/else、状态机、编排规则	概率推断
参数来源	结构化输入	自然语言解析结果
协议层职责	传输 + 部分校验	原样搬运意图
参数语义校验	调用方与服务端分担	需后端显式补齐
权限校验	与调用方身份绑定	需防止模型成为权限放大器
可审计性	决策路径可回放	需额外记录决策上下文
高风险操作控制	代码硬编码限制	需人工确认或二次校验
运维重点	可用性、容量、兼容性	额外关注模型行为与契约维护
典型适用场景	确定性业务流程、强合规场景	探索性交互、自然语言入口、低频复杂操作

六、典型场景选择：什么情况下用哪类方案

更适合传统RPC调用链的场景：

• 业务流程确定、步骤可枚举，且对可审计性要求高；
• 涉及资金、权限、数据删除等高风险操作，需要严格控制调用条件；
• 需要回放和单元测试覆盖的链路；
• 合规审计要求决策路径可追溯的场景。

更适合模型驱动工具调用链的场景：

• 用户以自然语言表达意图，操作路径无法提前枚举；
• 低频但种类繁多的内部工具，希望以统一契约暴露给模型；
• 探索性、辅助性操作，失败代价可控；
• 作为传统RPC之上的“自然语言入口层”，而非替代底层确定性调用。

需要谨慎混合使用的边界：

当模型驱动链路需要触达高风险接口时，不建议让模型直接调用底层RPC，而应在中间增加确定性编排层：模型只负责选择“意图”，由编排层将意图映射为受控的、参数经过校验的确定性调用。这样既保留自然语言入口的便利，又不把控制权完全交给模型。

七、选型建议：条件化判断而非绝对化推荐

• 如果业务对可审计性、可回放性要求高，且操作路径可枚举，优先采用传统RPC调用链，模型只作为辅助入口；
• 如果业务需要自然语言交互且操作失败代价可控，可采用模型驱动工具调用链，但必须补齐参数语义校验、权限校验和业务上下文一致性验证三道防线；
• 如果团队运维能力有限，应优先选择校验责任边界清晰、审计手段成熟的方案，避免在模型行为监控能力不足时直接暴露高风险接口；
• 如果已有成熟RPC体系，引入模型驱动链路时应把它定位为“入口层”而非“替代层”，底层调用仍由确定性代码编排。

八、迁移与使用注意事项

从传统RPC向模型驱动链路扩展时，需要重点关注以下风险：

• 接口暴露面扩大：原本只在内部服务间调用的接口，可能因工具化而被模型触达，需重新评估最小权限；
• 权限模型适配：确保鉴权基于真实调用方身份，而非协议层身份，防止模型成为权限放大器；
• 参数校验前置：在协议层与后端之间增加语义校验层，不能仅依赖格式合法性；
• 高风险操作兜底：删除、变更、支付类操作应引入人工确认或二次校验；
• 审计日志补全：记录模型决策上下文，保证事后可追溯；
• 契约维护机制：工具描述需要版本管理和评审，描述模糊会直接提高误调用率；
• 灰度与回滚：新链路应支持灰度放量和快速回滚，避免模型行为变化影响生产稳定性。

九、总结

传统RPC调用链与模型驱动工具调用链的核心差异，不在于传输格式，而在于“谁决定要调用什么”。前者把控制权交给确定性代码，决策可审计、可回放、可测试；后者把控制权交给概率性模型，协议层只负责搬运意图，校验责任必须由后端显式补齐。

理解这一差异的实践意义在于：引入模型驱动调用时，不能简单地把内部接口工具化后直接暴露，而应重新设计校验边界、权限模型和审计机制。把模型驱动链路定位为自然语言入口层，把确定性编排保留在底层，是兼顾便利性与安全性的务实路径。选型时应基于业务的可审计性要求、操作风险等级和团队运维能力做条件化判断，而非追求单一方案的绝对优劣。