07. Tool Calling 与 MCP

七、Tool Calling 与 MCP¶

在企业级 AI 应用开发中，工具调用（Tool Calling / Function Calling）、模型上下文协议（MCP, Model Context Protocol）、技能体系（Skills）以及代理运行时（Agent Runtime）共同构成了无状态大模型与有状态确定性外部系统交互的纽带。为确保分布式系统下的安全性与容灾性，架构设计的核心公理为：大模型仅拥有结构化调用“建议权”，而服务端必须牢牢掌控物理“执行权”与安全“决策权”。

总判断：模型负责建议，服务端保留执行权¶

flowchart LR A["用户请求"] --> B["模型提出结构化调用建议"] B --> C["服务端校验与补参"] C --> D["工具执行 / 审批 / 拒绝"] D --> E["统一结果 envelope"] E --> F["模型总结与解释"] F --> G["最终回答或人工接管"]

大模型通过对自然语言意图的语义解析，将其映射为对外部 API 调用的结构化建议（如提取必填参数、识别操作类型并推荐特定工具）。然而，在进入物理执行阶段前，服务端必须引入多层确定性防线，对调用建议执行严格的动态管控： 1. Schema 与类型硬校验（Schema Validation）：拦截格式非法、参数越界及字段缺失的请求。 2. 多租户安全上下文注入（Context Injection）：强制将服务端可信字段（如 tenant_id、user_id）与模型提取的业务参数融合。 3. ACL 权限与隔离边界阻断（Access Control）：校验当前调用主体是否拥有执行该工具的合法权限。 4. 风控与副作用降级（Side-Effect Control）：根据动作的副作用等级，决定是否拦截、触发人工审批（Human-in-the-Loop）或自动限流熔断。

无法将“建议权”与“执行权”严格剥离的系统，在面对高并发或恶意 Prompt 注入时，极易将模型的逻辑偏移放大为关系型数据库脏写、越权查询或第三方支付失控等物理级生产事故。

调用建议：Schema 设计、Function Calling 机制与字段归属¶

Schema 是大模型与外部系统进行能力协商的代理-计算机接口（ACI, Agent-Computer Interface）。一个健壮的工具 Schema 设计直接决定了模型的调用准确率与错误率。

1. Schema 契约设计要义¶

在 Schema 的 description 字段中，不仅要声明工具的物理用途，更应以确定性的声明式语法界定调用边界、适用前置条件及反向禁用约束。 - 反面示例："description": "查询报销单状态"。此类表述缺乏边界，极易诱发模型在非适用场景下误调用。 - 推荐示例：

{
  "name": "get_expense_claim_status",
  "description": "只读查询报销单审批状态。仅用于只读状态查询，不得用于催办、撤回或修改审批流。若用户未提供 claim_id，但给出明确时间范围和报销场景，可先请求服务端按 tenant_id 补全候选单号。若用户表达的是动作性催办意图，禁止调用本工具。"
}

高质量的描述相当于在语义空间内为模型划定了可信受力范围，是 Schema 工程（Schema Engineering）的核心抓手。

2. 字段归属与信任边界控制（Trust Boundary Control）¶

在 Function Calling 数据流中，字段被严格划分为两类： - 语义抽取字段（Model-Inferred Fields）：可从用户对话中合理推导的参数（如 claim_id、query_text、time_range），归属模型提取。 - 服务端可信字段（System-Trusted Fields）：涉及系统安全、身份鉴权、租户路由的核心参数（如 tenant_id、user_id、auth_scope），必须由服务端在网关层或装配层利用 Session/Token 动态强制注入，绝对禁止由模型在 Prompt 中生成或在参数中指定，防范潜在的参数篡改攻击。

3. 工具执行链最小实现模型¶

在 Go 语言中，一条标准安全的工具调用受控流水线逻辑如下：

suggestion := llm.ProposeToolCall(ctx, input, toolSchemas)
call := validateSchema(suggestion)
call = injectTrustedFields(call, tenantID, userID, policy)
decision := authorizeAndClassify(call)
if decision.RequireApproval {
    return pendingApproval(decision)
}
result := executeTool(ctx, call)
envelope := normalizeResult(result)
return llm.Summarize(ctx, envelope)

通过将上述步骤固化为统一的工作流管道，可确保每一笔 Tool Calling 请求都处于完全可观测、可审计与可熔断的受控状态。

执行控制：多维管控与自愈降级¶

工具调用一旦跨越信任防线，必须在服务端运行时引入完善 of 工业级控制策略： 1. 多维管控：建立精确的超时控制（Timeout Context）、分布式幂等控制（Idempotent Keys）与请求并发背压（Backpressure）。 2. 风险分级策略（Side-Effect Risk Grading）： - 只读级别（Read-Only）：重点关注数据泄露防范与查询延迟。 - 低风险幂等写入（Idempotent Write）：引入强幂等键与状态回滚机制，防范重复投递。 - 高风险物理动作（High-Risk Side Effects）：如转账、外部发信、高特权脚本执行，强制挂起并投递至人工确认队列（Human-in-the-Loop Interrupt），等待物理授权。

3. 故障分类与自愈协议¶

工具执行失败后，必须在网关层进行标准分类，拒绝向模型回传原始堆栈信息： - 格式与构造失败（Schema Mismatch）：属于输入侧错误。服务端将类型冲突或缺失字段包装为结构化 Trace，回传给大模型触发模型级自愈重推理（Self-Correction）。 - 鉴权与权限失败（ACL Deny）：属于强系统边界。立刻切断链路并向客户端返回标准化降级语，绝对禁止重试。 - 瞬态网络与容量故障（Network Jitter / 503 / 429）：服务端独立执行指数退避重试（Exponential Backoff with Jitter），不干扰模型决策。

结果回灌：统一适配层与标准化信封（Envelope）¶

在多工具或多 MCP Server 协同的复杂架构中，不同物理工具的输出格式、报错语系及物理量纲呈现高度异构性。若直接将异构原始输出灌回大模型上下文，将导致模型的上下文空间受到严重语系污染，推高幻觉率。

解决方案是引入统一工具适配层（Tool Adapter Layer），将原始返回标准化为统一的结果信封（Envelope）：

{
  "tool_name": "get_expense_claim_status",
  "execution_status": "success",
  "error_category": "none",
  "normalized_payload": {
    "claim_id": "EXP-2026-001",
    "status": "APPROVED",
    "approver": "Zhang San",
    "last_updated": "2026-05-20T09:00:00Z"
  },
  "original_reference": "raw_db_response_id",
  "trace_id": "trace-ab736cf-829d"
}

统一信封的系统学收益：¶

语义收敛：为大语言模型提供形态固定、高保真且结构化特征分明的语义实体，极大降低解析理解开销。
全局链路追踪：使 trace_id 与 error_category 横跨多个异构组件，奠定了自动化评测与回放测试的基础。
协议解耦：将上层 Agent 运行时与底层物理协议（HTTP/gRPC/MCP stdio）彻底隔离。

MCP 与 Skills：接入标准化与任务复用的受力分界线¶

大模型上下文协议（MCP）与技能（Skills）处于系统设计的不同层级，不可混为一谈。

MCP（Model Context Protocol）：是一种标准化接入通信协议。它界定了 Client 与 Server 之间如何协商发现工具（Tools）、读取数据源（Resources）及共享 Prompt 模板。
系统定位：接入层与协议发现层。
边界约束：MCP 不代替安全隔离、权限校验与运行时风控。通过 MCP 接入的第三方 Server 必须经过宿主系统（Host Application）网关的安全校验与统一信封适配。
Skills（技能体系）：是一种任务级业务逻辑封装形态。它将特定的 Prompt 模板、操作规范、调用工作流、依赖的数据实体及执行成功的质量门槛打包成开箱即用的运行时能力包。
系统定位：业务逻辑复用与任务上下文包。
边界约束：Skills 决定“如何将特定领域的经验沉淀为 Agent 可自主加载的运行包”，而底层工具和数据通道仍依赖 MCP 或标准 API 建立的连接。

MCP 运行时的时序流转：¶

在多 Server 场景下，一次 MCP 调用的核心生命周期涵盖 client、runtime 和 server 三层拓扑： 1. 连接与握手（Connect & Initialize）：宿主运行时驱动 MCP Client，通过 stdio、Server-Sent Events（SSE）或 WebSocket 传输层，与 MCP Server 建立双向长连接，协商协议版本与会话能力。 2. 能力发现（Capability Discovery）：Client 向 Server 发起资源与工具列表协商，将 Server 暴露的能力动态解析并同步至宿主的 Tool Router（工具路由器）。 3. 安全路由与决策（Auth & Route）：当模型发起调用建议时，宿主运行时拦截请求，对照 ACL 安全策略及当前租户上下文进行前置权限裁剪。 4. 受控调用（Controlled Execution）：Client 将安全校验通过的请求序列化为符合 MCP 协议标准的 JSON-RPC 格式，投递至 Server 端执行。 5. 归一化回传（Normalize & Reply）：Server 将物理执行结果或底层 Error 返回，Client 将其收拢并适配为统一结果信封，回灌至模型上下文。

故障诊断与路由策略¶

在大规模工具库场景下，Tool Calling 链路的稳定性依赖于分层的排障顺序与前置路由设计。

1. 工具调用故障排查树¶

当 Tool Calling 链路发生行为偏差时，应按如下级联顺序物理诊断： $$\text{Expression Error (Model Output)} \leftarrow \text{Execution Error (Tool Failure)} \leftarrow \text{ACL Deny (Rule Block)} \leftarrow \text{Schema Error (Contract)} \leftarrow \text{Selection Error (Routing)}$$ - 第一步：检查是否在 Router 阶段选错工具（排查 Description 模糊度）。 - 第二步：检查输入是否违背 Schema 约束（排查 Model Parameter Parsing）。 - 第三步：检查是否被 Ingress 权限与风控规则阻断（排查 ACL / Side-Effect Guard）。 - 第四步：排查工具函数底层的网络与数据库连接（排查 Runtime Infrastructure）。 - 第五步：排查模型对返回信封的解释与归纳质量（排查 LLM Completion）。

2. 分层工具选择与路由策略（Layered Tool Routing）¶

当系统暴露的备选工具达数十甚至上百个时，直接让模型在单次 Prompt 中选择会产生剧烈的注意力稀释（Tool Attention Skew）与时延暴涨。此时必须引入分层路由架构： - 静态规则过滤层（Deterministic Filters）：基于当前租户、用户身份等级与 API 版本，在最外层以硬编码规则直接裁剪掉不具备访问特权的工具，压缩候选集。 - 语义检索层（Retrieval-Augmented Tool Selection）：基于用户提问的语义向量，在向量空间中对备选工具的 Schema 和 Description 进行相似度检索（Recall），召回最相关的 3 $\sim$ 5 个候选工具。 - 模型判别决策层（LLM Agent Selection）：仅将经过前置物理过滤与检索精筛后的极小工具候选集装配至 Prompt 中，驱动模型执行最终的精确调用决策与参数提取。

此架构能够将大规模工具库场景下的路由准确度推向生产高水准，同时大幅压低了模型的输入 Token 负载与网络消耗。