当智能体数量从两三个涨到几十个，最痛的不是模型能力，而是每个智能体都在用自己的方言定义工具。我们这个项目里做的事情，是先立标准、再接系统，用 MCP 协议把存量系统的工具调用统一收口，把鉴权与可观测一次性补齐。

一、项目背景

某行业头部客户内部已经跑着二十多个智能体，分别服务客服、风控、报表、运维等场景。我们进场做 AI 私有化底座与 AI 网关集成时，立刻撞上一个典型乱象：工具接口各自为政。

同一个"查订单"能力，客服智能体要求传 order_id，风控智能体要的是 orderId，运维智能体干脆用 oid；鉴权方式更是五花八门，有的走 API Key 明文，有的塞在 header，有的干脆没鉴权。更麻烦的是可观测几乎为零——工具调了没调、为什么失败、耗时多少，排障全靠在日志里人肉翻，出了问题谁也说不清是哪一层。

我们当时算了一笔账：接入一个新业务系统，平均要为每个智能体重写一遍适配，周期以周计，且每写一遍就新增一份不一致。底座的模型服务化层（vLLM 推理 + 向量检索）本身很稳，但工具这一层正在变成最大的熵增来源。

判断很清楚：工具必须先标准化再接入，鉴权与可观测不可省。于是我们以 AI 网关为统一接入面，把存量系统封装成符合 MCP 协议的 tool server，所有智能体通过网关的标准协议调用，彻底告别"一个系统一种方言"。

二、落地场景

三个核心场景彼此衔接。

统一工具描述规范。 在网关侧定义工具 schema 基线：命名、参数、返回结构、错误码全部走统一约定，任何新工具接入前必须先过 schema 校验，不合格的拒绝注册。

MCP server 接入存量系统。 把订单、库存、CRM、工单等存量系统封装为 MCP server，对外暴露标准化 tool。智能体不再直连业务系统，而是向网关声明"我要用哪个 tool"，由网关负责协议转换与路由。

权限与可观测归一。 工具调用统一走网关鉴权，按"应用—用户—工具"三级授权；调用链通过网关埋点采集，延迟、成功率、错误归因在管控台统一呈现，排障从猜变成查。

三、关键技术挑战与解决思路

挑战一：工具 schema 标准化，如何让二十多个智能体收敛到一套约定

我们当时没有推倒重来，而是立了一条"网关准入"铁律：工具必须先注册 schema 再被调用。schema 基线强制三项——参数用 snake_case、必填项显式标注、返回包统一含 code/message/data。任何工具注册时由网关做契约校验，不合规直接拒绝。

一份接入网关的标准 tool schema 片段如下：

{
  "name": "query_order",
  "description": "按订单号查询订单详情",
  "input_schema": {
    "type": "object",
    "properties": {
      "order_id": {"type": "string", "description": "订单号"},
      "with_items": {"type": "boolean", "default": false}
    },
    "required": ["order_id"]
  },
  "returns": {"code": "int", "message": "string", "data": "object"}
}

老智能体历史接口不一致的，我们在 MCP server 侧做一层适配映射，把 orderId/oid 全部归一成 order_id，智能体无感。

挑战二：MCP server 接入与适配，如何低成本包住存量系统

存量系统大多只有 REST 或内部 RPC，没有 tool 语义。我们写了一个轻量适配框架，把"一个 HTTP 接口 + 一段 schema"编译成一个 MCP tool，存量系统零改造。

适配层的核心是把上游响应归一：

MCP server 适配流程：
1. 收到网关转发的标准 tool call（tool=query_order, args={order_id}）
2. 映射为内部 RPC：GET /inner/order?oid={order_id}
3. 把内部响应包成 {code,message,data}
4. 回传网关 → 路由到发起智能体

我们当时优先接入了高频工具（订单、库存、工单），约两周完成首批八个系统的封装，验证了"存量系统零改造接入"的可行性。

挑战三：工具调用鉴权与权限，如何防止越权调用

标准化之后反而暴露了风险：以前各自鉴权，现在统一收口到网关，一旦网关授权粗放，越权面会被放大。我们采用三级授权模型——应用级（哪个智能体可用）、用户级（哪个调用身份可触发）、工具级（敏感工具需二次审批）。

网关层的鉴权路由规则示意：

# AI 网关鉴权路由（伪配置）
authz:
  - match: { app: "risk_agent", tool: "freeze_account" }
    require: { user_role: "risk_admin", step_up: true }   # 敏感工具二次审批
  - match: { app: "ops_agent",  tool: "query_order" }
    require: { user_role: "ops_reader" }
  - default: deny

所有调用在网关归一鉴权，业务系统不再各自维护一套，越权调用在入口即被 deny。

挑战四：调用链可观测，如何让排障从"猜"变成"查"

可观测是项目里被低估、上线后最值钱的一块。我们在网关的接入层与编排层统一埋点：每次 tool call 记录 trace_id、调用方、目标 tool、耗时、结果码，并下发到统一追踪系统。智能体 → 网关 → MCP server → 业务系统 形成完整调用链。

管控台看板的关键指标采集点：

span: gateway_in    {app, user, tool, ts_in}
span: route        {selected_server, cost_ms}
span: mcp_call     {upstream, http_code, cost_ms}
span: gateway_out  {result_code, total_ms}

我们当时还设了失败归因聚合：同一 tool 连续失败超阈值自动告警，并标记是网关侧、网络侧还是业务侧，排障平均耗时从小时级降到分钟级。

案例片段（已脱敏）： 灰度期间我们捕获到一次典型的越权拦截与一次超时排障，真实反映了标准化前后的差异： ``` [GATEWAY authz] DENY app=report_agent tool=freeze_account  reason=role mismatch (need risk_admin, got report_reader)  trace_id=8f2c1a9e step_up=false

[TRACE 8f2c1a9e] mcp_call upstream=order-srv http_code=504 cost_ms=8120 归因: business_timeout (DB 慢查询) -> 触发网关熔断 fallback ``` 前者说明三级授权把越权调用挡在了入口；后者说明可观测调用链直接定位到业务侧 DB 慢查询，而非在网关层瞎猜。上线前同类排障平均约 47 分钟/次，标准化后约 8 分钟/次。

四、效果数据

以下为脱敏示意数据，口径为该项目灰度前后对比，非审计级精确值。

备注：接入周期口径不同（前为"每智能体重写"，后为"每系统封装"），体现复用收益；成功率含熔断回退兜底后的最终成功。

五、可复用经验总结

第一，工具先标准化再接入。没有 schema 基线，接入越多越混乱。我们靠网关准入契约把不一致挡在注册环节，老接口在 MCP server 侧适配，智能体无感。

第二，MCP 适配要零改造存量系统。用"HTTP 接口 + schema 编译成 tool"的轻量框架，让订单、库存等系统不动一行代码就被智能体调用，接入成本陡降。

第三，鉴权与可观测不可省，而且要前置设计。统一收口到网关后，授权必须做细到"应用—用户—工具"三级，否则越权面反而放大；可观测埋点要从第一天就铺在网关各层，否则后期补成本极高。

第四，熔断回退是成功率的地基。编排层"主工具失败切备用/返回兜底"的回退策略，让单点故障不再拖垮整个智能体链路。

这个项目最大的收获，不是接了多少工具，而是把"工具的秩序"建了起来。模型能力会持续进化，但工具调用的标准化与治理，才是智能体真正能规模化落地的底座。