想给 AI 加新工具?两种主流姿势讲清楚

最近在做 AI Agent 落地的朋友越来越多。

一个绕不开的问题：怎么给 AI 加新工具？

今天把两条主流路径讲清楚 ——Wasm 插件模式和Nacos 存量业务接入模式。

看完你就会知道，自己的场景该选哪条路。

一、先说大背景

AI Agent 要调用外部能力，必须通过 MCP Server。

但 MCP Server 怎么来？大致两条路：

路径 A：基于 Wasm 插件扩展 MCP Server        适合”封装新的 API 能力”        新写的、自己实现的 API 接入路径 B：基于 Nacos 适配存量业务        适合”老系统 0 改造接入”        已有业务系统不用改代码

两条路不冲突，可以并存。

下面分别讲清楚。

二、路径 A：基于 Wasm 插件扩展 MCP Server

这条路径又有两种玩法：用现成的和自己写。

玩法 1：接入 Higress Market MCP 服务

Higress 维护了一个 MCP 服务市场：mcp.higress.ai

里面有不少现成的 MCP 服务（高德地图、天气查询等）。

接入流程是三步：

步骤 1：添加服务来源        在 Higress 控制台配置从 Market 拉取服务步骤 2：添加路由        把请求路由到目标 MCP 服务步骤 3：添加 MCP Server        声明要加载的工具集合

配完之后，在支持 MCP 协议的客户端（比如 Cherry Studio）里填上 Higress 的地址，就能用了。

这种玩法适合：

快速验证 MCP 能力
接入常见的 SaaS 服务
不需要深度定制

玩法 2：自定义 Higress Wasm Plugin MCP 服务

如果你要封装一个自己的 API，就需要自己写 Wasm 插件了。

整个流程是三步：

步骤 1：Wasm Plugin 本地开发        ↓        - 准备 Go 环境（Go 1.19+）        - 编写插件工程（main.go）        - 编译成 Wasm 字节码        - 用 Docker 本地调试步骤 2：上传插件镜像        ↓        - 搭建镜像仓库        - 写 Dockerfile        - 构建并推送镜像步骤 3：Higress 配置新插件        ↓        - 安装新插件        - 配置插件参数        - 配置路由规则        - 测试验证

关键细节：

# Go 环境准备wget https://go.dev/dl/go1.19.linux-amd64.tar.gztar -C /usr/local -xzf go1.19.linux-amd64.tar.gzexport PATH=$PATH:/usr/local/go/bin# 安装依赖go env -w GOPROXY=https://proxy.golang.com.cn,directgo get github.com/higress-group/proxy-wasm-go-sdkgo get github.com/alibaba/higress/plugins/wasm-go@maingo get github.com/tidwall/gjson

# 构建镜像示例docker build -t your-registry/wasmplugin/wasmdemo:1.0.0 -f Dockerfiledocker push your-registry/wasmplugin/wasmdemo:1.0.0

这种玩法适合：

封装企业内部 API
需要深度定制的工具
对性能有要求（无额外跳转）

三、路径 B：基于 Nacos 存量业务 0 改造接入

这是企业落地最关心的部分。

核心诉求：让老系统不用改代码就能被 AI 调用。

改造流程

存量服务注册   ├── 方式 1：SDK 注册   │           业务系统引入 SDK，主动注册到 Nacos   └── 方式 2：持久化注册                配置即生效，业务代码完全不动Higress MCP 网关代理   ├── 拉取接口信息   └── 协议转化（业务接口 → MCP 协议）

Higress 和 Nacos 在这里的分工

┌──────────────────────────────────────┐│           Higress 的作用              │├──────────────────────────────────────┤│ • SSE 会话保持（用 Redis 缓存）        ││ • 暴露 Tool/List 接口（让 AI 发现工具）││ • 协议转化（HTTP/RPC → MCP）          │└──────────────────────────────────────┘┌──────────────────────────────────────┐│            Nacos 的作用               │├──────────────────────────────────────┤│ • 后端服务路由信息（服务发现）          ││ • Tool 信息管理（工具定义、参数描述）   │└──────────────────────────────────────┘

两者的边界很清晰：

Nacos 负责"有什么、叫什么、参数是啥"
Higress 负责"怎么调过去、怎么转协议、怎么保持会话"

环境要求

Nacos  ≥  3.0.1Higress  ≥  2.1.4Redis  服务监听启动

配置路径

Nacos 配置端：  1. 创建 MCP Server  2. 配置 MCP Server（后端服务地址）  3. 添加工具（Tool 定义、参数描述）  4. 发布Higress 配置端：  1. 服务来源（对接 Nacos）  2. 服务列表查看（确认发现成功）  3. ConfigMap 配置（路由规则）

配完之后做访问测试，AI 就能调用老系统的接口了。

四、Higress + Nacos 的核心优势

把两个组合起来用，有六大核心优势。

Nacos 管理 MCP 服务的优势

✅ 存量 API 可以快速构建 MCP Server   老系统的接口自动映射成 MCP 工具✅ MCP 信息动态下发实时生效   改了配置，AI 立刻看到新工具，不用重启✅ MCP 信息历史版本管理   工具定义改错了可以回滚✅ MCP 信息灰度管理   新工具先给一部分用户用✅ 密码配置加密   敏感信息不裸奔✅ MCP 服务管理及健康检查   服务挂了自动摘除

部署与运维优势

✅ 弹性伸缩   基于 Kubernetes 自动伸缩，根据流量调整实例数✅ 灰度发布   支持 MCP Server 的灰度发布和 A/B 测试✅ 一键部署   提供 Helm Chart，简化部署流程

五、两条路径怎么选？

选 Wasm 模式的场景

✅ 接入新的外部 API（SaaS、云服务、第三方数据）✅ 简单的接口封装✅ 对性能敏感（无额外跳转）✅ 团队有 Go 开发能力✅ 工具数量不多（个位数到几十个）

选 Nacos 模式的场景

✅ 有大量存量业务系统✅ 业务团队没资源配合改造✅ 老系统接口稳定、变更不频繁✅ 需要动态发现和配置管理✅ 工具数量多（几十到几百个）

实际生产中的建议

两条路都用：

新接入的外部 API  → Wasm 模式存量老系统        → Nacos 模式两者在 Higress 网关层统一汇聚

这种组合是企业落地的最常见形态。

六、容易踩的几个坑

坑 1：Wasm 插件里直连数据库

❌ Wasm 沙箱不适合维护数据库连接池✅ 让业务系统提供 REST API，Wasm 调用 REST API

坑 2：忽略 SSE 会话保持

❌ 会话数据只存在网关实例内存里，换实例就断✅ 用 Redis 缓存会话数据

坑 3：Nacos 配置改完没发布

❌ 改了 Tool 定义但没点发布，AI 看不到新工具✅ 改完一定要点”发布”才会实时生效

坑 4：版本兼容性

Nacos  ≥  3.0.1Higress  ≥  2.1.4低于这个版本可能某些功能不可用

七、最后总结

给 AI 加新工具的两条主流路径：

路径	核心场景	适合
Wasm 插件	封装新 API	个人/小团队、新接入能力
Nacos 存量适配	老系统 0 改造接入	大型企业、存量系统激活

两条路不冲突，企业落地往往组合使用。

如果你的场景比较简单（接入几个外部 API），从 Higress Market 拉现成的最快。

如果场景复杂（大量老系统），上 Nacos 走存量适配。