
你的企业有多少套老系统?ERP、OA、CRM、自研后台……光登录密码就得记七八个。当大模型浪潮袭来,所有人都说要“拥抱 AI”,但看着这些跑了十年、百万行代码的存量系统,到底怎么拥抱?重写?不可能。改接口?牵一发动全身。本文用一次真实项目经验告诉你:不用改一行存量代码,三天内让所有老系统对 AI 对答如流。
某天,公司技术负责人找到我:“我们有个想法,能不能让 AI 直接查库存、下订单、看报表?就像跟人聊天一样。”
我说:“当然可以,这不就是 AI Agent 嘛。”
他眼睛一亮,随即又黯淡下来:“但问题是——我们的进销存系统是七八年前做的,接口倒是齐全,50 多个 REST API,有 GET 有 POST,有的要 Token 鉴权,有的要路径参数,有的 POST body 里还嵌套了复杂的查询条件……难道要重写?”
“不用重写,”我说,“我们刚验证完一条路,三天出活,老系统一行不改。”
他半信半疑。三天后,他的 AI 助手已经能说:“好的,我帮你查一下今天的库存”了。
如果你在传统企业做技术,下面的场景一定不陌生:
GroupList → WhereList → WhereField,结构复杂得像俄罗斯套娃这就是传统企业数智化转型的最大堵点:不是不愿意 AI 化,而是历史包袱太重,改不动。
回到正题。我们是怎么做到“三天出活,一行不改”的?
答案出奇的简单——让网关替你翻译。
想象这个场景:你和外国客户开会,中间坐了个翻译。你说中文,翻译翻成英文;客户说英文,翻译翻回中文。你和客户都无需学对方的语言。
在 AI 领域,这个“翻译”的角色就叫 MCP(Model Context Protocol,模型上下文协议)。它是 Anthropic 于 2024 年 11 月开源的协议,目标是成为 AI 世界的“通用语”——不管你底层是什么系统,包装成 MCP 之后,任何 AI 工具都能用同一套语言跟你对话。
而我们选择的“翻译官”,是 Higress 网关。它能自动把 AI 说的 MCP 语言,翻译成你的老系统听得懂的 HTTP 请求。

一句话说清楚这个方案:给老系统前面加一个网关,一行代码不改,零部署变更,0 成本让 AI 读懂你的老系统。
┌─────────────────────────────────────────────────────────────────────┐
│ AI 平台(控制面) │
│ │
│ ┌────────────┐ ┌────────────┐ ┌────────────┐ ┌────────────┐ │
│ │ API 服务 │ │ MCP Server │ │ MCP Tool │ │ 产品/订阅 │ │
│ │ 管理 │ │ 管理 │ │ 管理 │ │ 管理 │ │
│ └──────┬─────┘ └──────┬─────┘ └──────┬─────┘ └──────┬─────┘ │
│ │ │ │ │ │
│ └───────────────┴───────────────┘ │ │
│ │ │ │
│ Nacos AI Admin API (/v3/admin/ai/*) │ │
│ │ │ │
│ ┌───────────────┴───────────────┐ │ │
│ │ Nacos AI Registry 写入 │◄──────────────┘ │
│ │ · mcp-server (元数据) │ 产品 upsert / 订阅审批 │
│ │ · mcp-tools (工具定义) │ │
│ │ · mcp-server-versions │ │
│ │ · mcp-endpoints (自动生成) │ │
│ └───────────────┬───────────────┘ │
└───────────────────────────┼──────────────────────────────────────────┘
│
▼
┌─────────────────────────┐
│ Higress AI 网关 │
│ · 自动发现 Nacos MCP │
│ · 协议转换 HTTP ↔ MCP │
│ · 暴露 SSE 端点: │
│ /mcp/{name}/sse │
└────────────┬────────────┘
│
▼
┌─────────────────────────┐
│ 存量 REST API 服务 │
│ (Nacos Naming 实例) │
│ /api/order/query │
│ /api/inventory/list │
└─────────────────────────┘
组件 | 角色 | 一句话 |
|---|---|---|
Nacos 3.2 | 登记处 + AI 注册中心 | 记录“老系统在哪、有哪些接口、怎么调用” |
Higress 2.2 | 翻译官 + AI 网关 | 接收 MCP 指令,翻译成 HTTP 请求发给老系统 |
Redis 7 | 会话本 | 维护 SSE 长连接的会话状态 |

当 AI Agent 说“帮我查一下产品 P001 的库存”时,背后发生了什么?
tools/call 请求 → Higress 的 SSE 端点 /mcp/{name}/sse/api/inventory/query,method 填 POST,body 填 {"productCode":"P001"}{"stock": 150, "warehouse": "A01"}全程老系统一行代码没改,它甚至不知道自己被 MCP 化了。
下面是可以直接复制使用的 docker-compose.yml:
version: "3.8"
services:
# Redis 7: MCP 会话保持
redis:
image: redis:7-alpine
container_name: mcp-redis
ports:
- "6379:6379"
volumes:
- redis-data:/data
command: redis-server --appendonly yes
healthcheck:
test: ["CMD", "redis-cli", "ping"]
interval: 10s
timeout: 3s
retries: 5
restart: unless-stopped
networks:
- mcp-net
# Nacos 3.2: 配置中心 + AI Registry + Naming
nacos:
image: nacos/nacos-server:v3.2.0
container_name: mcp-nacos
ports:
- "8848:8848" # API
- "9848:9848" # gRPC
- "8081:8080" # 控制台
environment:
- MODE=standalone
- NACOS_AUTH_ENABLE=true
volumes:
- nacos-logs:/home/nacos/logs
restart: unless-stopped
networks:
- mcp-net
# Higress 2.2: AI 网关
higress:
image: higress-registry.cn-hangzhou.cr.aliyuncs.com/higress/all-in-one:2.2.0
container_name: mcp-higress
ports:
- "8001:8001" # 控制台
- "8088:8080" # HTTP 网关 ⚠️ 注意容器内是 8080,映射到 8088
environment:
- REDIS_ADDR=redis:6379
volumes:
- ./higress-data:/data # ⚠️ 必须持久化,否则重启配置丢失
depends_on:
nacos:
condition: service_started
redis:
condition: service_healthy
restart: unless-stopped
networks:
- mcp-net
volumes:
redis-data:
driver: local
nacos-logs:
driver: local
networks:
mcp-net:
driver: bridge
部署后立即验证的 4 件事:
# | 验证项 | 怎么做 |
|---|---|---|
1 | Nacos 控制台可登录,左侧有 MCP 菜单 | 浏览器打开 http://localhost:8081 |
2 | Higress 控制台可打开 | 浏览器打开 http://localhost:8001 |
3 | Redis 可达 | redis-cli ping 返回 PONG |
4 | Higress 能连通 Nacos | 进入 Higress 容器执行 curl nacos:8848/nacos |
Higress 控制台 → 服务来源 → 添加 Nacos 3.x,指向同一个 Nacos 实例。这一步不配,后续所有 SSE 端点都会 404。
老系统要先注册到 Nacos Naming,Higress 以后才能通过服务发现找到它:
# 先获取 Nacos 的访问 Token
NACOS_TOKEN=$(curl -s -X POST "http://localhost:8848/nacos/v1/auth/login" \
-d "username=nacos&password=nacos" | jq -r '.accessToken')
# 把老系统注册为 Nacos 服务实例
curl -X POST "http://localhost:8848/nacos/v1/ns/instance" \
-H "Authorization: Bearer ${NACOS_TOKEN}" \
-d "serviceName=my-old-system" \
-d "groupName=DEFAULT_GROUP" \
-d "ip=192.168.1.100" \
-d "port=8081" \
-d "ephemeral=false"
这一步就像给老系统发了一张身份证。服务名 my-old-system 是之后所有配置的“锚点”,MCP Server 和 Tool 都要引用它。
在 Nacos 控制台 → MCP 管理 → 创建 MCP Server,填写:
{
"name": "my-old-system",
"description": "老系统业务查询服务",
"protocol": "mcp",
"version": "1.0.0",
"exportPath": "/sse",
"mcpSpecificationVersion": "1.0",
"remoteServerConfig": {
"serviceProtocol": "HTTP",
"serviceRef": "my-old-system:1.0.0",
"exportPath": "/sse"
}
}
几个关键字段说明:
字段 | 含义 | 为什么重要 |
|---|---|---|
name | MCP Server 名称 | 决定 SSE 入口 URL:/mcp/{name}/sse,不能包含中文 |
remoteServerConfig.serviceRef | 引用第一步注册的 Naming 服务名 | 格式 {服务名}:{版本},让 Higress 知道去哪里找老系统 |
exportPath | 固定 /sse | 告诉 Higress 用 SSE 方式暴露 |
这是最关键的一步。每个存量接口都需要配一个 Tool,Tool 包含两层信息:
A. 给 AI 看的(Agent 契约)——告诉 AI 这个工具叫什么、接受什么参数:
{
"name": "query_inventory",
"description": "根据产品编码查询当前库存数量",
"args": [
{ "name": "productCode", "type": "string", "description": "产品编码", "required": true },
{ "name": "page", "type": "number", "description": "页码,从1开始" }
]
}
B. 给网关看的(HTTP 转发)——告诉网关怎么把 MCP 请求翻译成 HTTP 调用。
根据老系统接口的不同风格,有四种常见配置模式:
模式一:简单 GET 查询
{
"url": "/api/health/check",
"method": "GET"
}
适用于无参数的健康检查、系统状态类接口。
模式二:GET + 参数自动转 Query
{
"url": "/api/inventory/get",
"method": "GET",
"argsToUrlParam": true
}
网关会自动把 Agent 传入的参数拼到 URL 后面:/api/inventory/get?productCode=P001&page=1。
模式三:POST JSON Body
{
"url": "/api/order/create",
"method": "POST",
"argsToJsonBody": true,
"headers": [
{ "key": "Content-Type", "value": "application/json" }
]
}
Agent 传入的参数会自动序列化成 JSON 放在请求体里。
模式四:路径参数 + 自定义 Body 模版
这是最灵活的模式,适用于复杂的查询接口——比如老系统的查询条件嵌套了三层 JSON 结构:
{
"url": "/users/{{ .args.userId }}/status",
"method": "PUT",
"body": "{\"status\":\"{{ .args.status }}\",\"remark\":\"{{ .args.remark }}\"}",
"headers": [
{ "key": "Content-Type", "value": "application/json" }
]
}
{{ .args.xxx }} 是 Go Template 语法,网关会自动把 Agent 传的参数填充进去。URL 里的 {{ .args.userId }} 会被替换成实际值,请求体同理。
这一点是新手最容易踩的坑:配完 Tool 之后,Nacos 不会自动生效,必须回到 MCP Server 页面点「发布为最新版本」。 不点这步,Higress 读到的永远是旧配置。
到这里,你已经掌握了核心原理和手动操作流程。但如果你面对的是 50 个接口、10 个老系统、需要反复调整 Tool 配置的场景,每次都在 Nacos 控制台里手写 JSON 显然不现实。
我们做了一件事:把上面所有手动步骤,封装成了一个自建平台,用 Java 后端 + Vue 前端驱动整个流程。
下面我拆解这个平台是怎么设计的,以及它如何把“三天出活”变成“十分钟出活”。
自建平台在原有三件套(Nacos + Higress + Redis)之上,增加了一个 控制面,负责:
┌──────────────────────────────────────────────────────────────────┐
│ 自建平台(控制面) │
│ │
│ ┌────────────────────┐ ┌────────────────────┐ │
│ │ Vue 前端 │ │ Java 后端 │ │
│ │ · ApiServiceList │ │ · McpServerService │ │
│ │ · McpServerList │ │ · ApiServiceService │ │
│ │ · McpServerDetail │ │ · NacosAiAdminClient│ │
│ │ · ToolEditor │ │ · McpProductSyncApi │ │
│ └────────┬───────────┘ └──────────┬───────────┘ │
│ │ │ │
│ │ REST API │ 调用 Nacos AI Admin API │
│ │ /api/mcp/* │ /v3/admin/ai/mcp │
│ │ │ │
│ └─────────────┬───────────┘ │
│ │ │
│ ┌──────────┴──────────┐ │
│ │ MySQL 数据库 │ │
│ │ · api_service │ │
│ │ · mcp_server │ │
│ │ · mcp_tool │ │
│ │ · product │ │
│ └─────────────────────┘ │
└──────────────────────────────────────────────────────────────────┘
平台的核心数据模型只有三张表,对应三个实体类:
ApiService(老系统登记表)
字段 说明
─────────────────────────────────
name 老系统展示名称,如“进销存系统”
nacosServiceName Nacos Naming 服务名,如“inventory-api”
host 老系统 IP 地址
port 老系统端口
healthCheckPath 健康检查路径,如 /api/health
status 状态:已注册 / 未注册
这张表是“老系统的身份证”。录入后,平台会调用 Nacos Naming API 自动注册服务实例,不用手动 curl。
McpServer(MCP 服务定义表)
字段 说明
─────────────────────────────────
name MCP Server 名称,决定 /mcp/{name}/sse
fromType 来源类型:HTTP_TO_MCP / NATIVE_MCP
apiServiceId 关联哪个老系统
protocol sse / streamable
version 版本号,固定 1.0.0
status 0=草稿 1=已发布 2=已下线
exposeUrl 对外暴露的 SSE URL
productId 关联的产品市场 ID
McpTool(工具定义表)
字段 说明
─────────────────────────────────
serverId 关联哪个 MCP Server
name Agent 看到的工具名称
description 工具描述
argsJson 入参定义 JSON
httpMethod GET/POST/PUT/DELETE
path 接口相对路径
argMapping 参数映射方式:url_param/json_body/form_body/body
headersJson 请求头配置
requestBody 自定义请求体模版
这是整个平台最核心的逻辑——McpServerService.publish() 方法。当用户在平台上点击“发布”按钮时,后端执行以下编排:
publish()
├── Step 1: 校验 MCP 名称合法性
│ ↳ 只允许英文、数字、-、_、/、.,最长 128 字符
│
├── Step 2: 校验关联的老系统已注册到 Nacos
│ ↳ 如果还没注册,自动调用 ApiServiceService.register() 注册
│
├── Step 3: 查询该 Server 下所有 Tool
│ ↳ SELECT * FROM mcp_tool WHERE server_id = ?
│
├── Step 4: 组装三份 Nacos Spec JSON
│ ├── buildServerSpecification() → mcp-server.json
│ │ { name, description, protocol, version,
│ │ remoteServerConfig: { serviceRef, serviceProtocol } }
│ │
│ ├── buildToolSpecification() → mcp-tools.json
│ │ 遍历每个 Tool,组装扁平 HTTP 配置:
│ │ { url, method, headers, argsToUrlParam/argsToJsonBody/body, ... }
│ │
│ └── buildEndpointSpecification() → mcp-endpoints.json
│ { exportPath: "/sse", ... }
│
├── Step 5: 调用 NacosAiAdminClient 写入 Nacos AI Registry
│ ↳ createMcpServer(serverSpec, toolSpec, endpointSpec)
│ ↳ 底层调用 Nacos 3.2 的 /v3/admin/ai/mcp 接口
│
├── Step 6: 生成对外暴露的 SSE URL
│ ↳ exposeUrl = "http://{gateway}:8088/mcp/{name}/sse"
│
├── Step 7: 同步到产品市场
│ ↳ McpProductSyncApi.upsert() → 创建/更新 product 记录
│ ↳ 用户可以在产品市场看到这个 MCP Server,申请订阅
│
└── Step 8: 更新数据库状态
↳ mcp_server.status = 1(已发布)
关键代码片段(Step 4,组装 Tool 的扁平 HTTP 配置):
private JSONObject buildFlatHttpConfig(McpTool tool) {
JSONObject config = new JSONObject();
config.put("url", tool.getPath());
config.put("method", tool.getHttpMethod());
// 参数映射方式
switch (tool.getArgMapping()) {
case "url_param": config.put("argsToUrlParam", true); break;
case "json_body": config.put("argsToJsonBody", true); break;
case "form_body": config.put("argsToFormBody", true); break;
case "body": config.put("body", tool.getRequestBody()); break;
}
// 请求头
if (StrUtil.isNotBlank(tool.getHeadersJson())) {
config.put("headers", JSON.parseArray(tool.getHeadersJson()));
}
return config;
}
关键代码片段(Step 5,写入 Nacos AI Registry):
public void publish(McpServer server) {
// 组装三份 Spec
String serverSpec = buildServerSpecification(server);
String toolSpec = buildToolSpecification(tools);
String endpointSpec = buildEndpointSpecification(server);
// 一键写入 Nacos
nacosAiAdminClient.createMcpServer(serverSpec, toolSpec, endpointSpec);
// 生成 exposeUrl
String exposeUrl = String.format("http://%s:%d/mcp/%s/sse",
gatewayHost, gatewayPort, server.getName());
// 同步产品市场
productSyncApi.upsert(Product.builder()
.type("mcp_server")
.name(server.getName())
.exposeUrl(exposeUrl)
.build());
// 更新状态
server.setStatus(1);
mcpServerMapper.updateById(server);
}
发布有发布流程,下线也有对应的清理逻辑:
offline()
├── 1. 调用 NacosAiAdminClient.deleteMcpServer() 删除 Nacos 中的 MCP 声明
├── 2. 产品置为下架(status=inactive)
└── 3. 更新 mcp_server.status = 2(已下线)
自建平台的前端用 Vue 3 + Arco Design 实现,核心里有三个页面:
页面一:API 服务管理(ApiServiceList.vue)
一个表格页面,列出所有已登记的老系统。每条记录显示名称、Nacos 服务名、IP:端口、健康检查路径、注册状态。操作按钮包括:
ApiServiceService.register(),把老系统实例注册到 Nacos Naming页面二:MCP Server 列表(McpServerList.vue)
卡片式布局,每张卡片展示一个 MCP Server 的名称、服务名、类型标签(存量 REST / 原生 MCP)、协议、状态。顶部有搜索框和筛选器,支持按名称、类型、状态过滤。操作按钮:
页面三:MCP Server 详情(McpServerDetail.vue)
这是最复杂的页面,分成三个区域:
操作 | Nacos 控制台手动 | 自建平台驱动 |
|---|---|---|
登记老系统 | 复制 curl 命令,改 IP 和端口 | 表单填写,点保存 |
注册到 Nacos Naming | 跑 curl 命令,注意 Token | 点「注册到 Nacos」按钮 |
创建 MCP Server | 手写 JSON,注意字段名不能错 | 表单填写,自动校验 |
创建 Tool | 手写 JSON,含入参定义和 HTTP 转发配置 | 可视化编辑器,下拉选择 |
发布 | 回到 Nacos 点「发布为最新版本」 | 点「发布」按钮,一键完成 |
修改 Tool | 重新写 JSON,重新发布 | 编辑表单,重新发布 |
下线 | 手动删除 Nacos 配置 | 点「下线」按钮,自动清理 |
预览 Nacos Spec | 无 | 点「预览」看即将写入的 JSON |
最关键的差异:手动操作时,你需要在 Nacos 控制台和 curl 命令之间反复横跳;平台驱动下,所有操作都在一个页面里完成,发布链路是事务性的——要么全部成功,要么全部回滚。不会出现“Nacos 写进去了但产品表没同步”这种半吊子状态。
在真正发布之前,平台提供了一个 previewNacosSpec() 接口,可以预览即将写入 Nacos 的三份完整 JSON,但不实际调用远端。这个功能在调试阶段极其有用——你可以在数据库里把 Tool 配好,点「预览」看一眼生成的 JSON 对不对,确认无误再点「发布」。
# 预览接口
GET /api/mcp/servers/{id}/preview-nacos-spec
# 返回三份 JSON:
{
"serverSpec": { ... },
"toolSpec": { ... },
"endpointSpec": { ... }
}
80% 的存量系统都有鉴权,而且很多系统的 Token 每两小时就过期一次。如果每次过期都重新配一遍 Tool,那不叫“零改造”,叫“换了个地方折腾”。
我们经过验证,推荐三种方案:
方案 | 做法 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
固定 Token | Tool headers 里直接写死 Bearer xxx | 最快上手 | Token 过期需重新发布 | POC 验证 |
Nacos 配置引用 | Token 存 Nacos 配置中心,Tool 里用 ${nacos.xxx} 引用 | 热更新、无需重新发布 | 需要多维护一个配置项 | 推荐 |
Token 中转服务 | 旁路代理自动刷新 Token | 全自动 | 架构复杂 | 生产环境 |
推荐方案(Nacos 配置引用)的具体操作:
my-token,Group = DATA,内容为:{ "token": "eyJhbGciOiJIUzI1NiIs..." }
{
"headers": [
{ "key": "Content-Type", "value": "application/json" },
{ "key": "Authorization", "value": "Bearer {{ ${nacos.my-token/DATA}.token }}" }
]
}
这里有两个语法细节要注意:
${nacos.dataId/group} 是 Nacos 配置引用语法,注意中间是 / 不是 .curl -N http://localhost:8088/mcp/my-old-system/sse
正常输出应该看到 endpoint、sessionId 和定时 ping 心跳。如果只看到 ping 没有业务数据,这是正常的——真实业务数据需要通过 MCP tools/call 触发。
MCP Inspector 是官方提供的调试工具,可以图形化地查看工具列表和调用结果:
npx @modelcontextprotocol/inspector
# 在弹出的界面中:
# Transport 选择 SSE
# URL 填 http://localhost:8088/mcp/my-old-system/sse
连接成功后,你应该看到:
query_inventory、create_order 等你配置的工具在 IDE 的 MCP 配置文件中添加:
{
"mcpServers": {
"my-old-system": {
"type": "stdio",
"command": "npx",
"args": ["-y", "mcp-proxy", "http://localhost:8088/mcp/my-old-system/sse"]
}
}
}
重启 IDE 后,你就能在对话中直接触发工具调用:
调用 my-old-system 的 query_inventory 工具,查询产品 P001 的库存信息。
AI 助手会返回老系统查到的真实数据。
以下是 POC 验证过程中踩过的坑,每一个都浪费了至少半小时:
# | 现象 | 根因 | 正确做法 |
|---|---|---|---|
1 | SSE 端点 404 | 端口映射写成了 8088:8088,但容器内网关端口是 8080 | 映射必须写 8088:8080 |
2 | 重启容器后服务列表为空 | All-in-One 镜像不支持 Nacos 做配置存储 | 挂载 -v ./higress-data:/data 持久化 |
3 | Nacos 里改了配置,调用还是旧的 | 改完没点「发布为最新版本」 | 每次修改完必须点发布 |
4 | SSE 端点只返回 ping | 正常现象,不是错误 | 用 MCP Inspector 做 tools/call 验证 |
5 | requestTemplate.url 填了完整 URL 报错 | 只能填相对路径,如 /api/xxx | 真实地址靠 Naming 服务发现的 IP:Port |
6 | Higress 服务列表为空 | 没在 Higress 控制台添加 Nacos 服务来源 | 控制台 → 服务来源 → 添加 Nacos 3.x |
7 | tools/call 返回 401 | Token 过期或模版引用语法错误 | 检查 ${nacos.xxx/DATA} 语法,注意是 / 不是 . |
8 | 容器内连通性失败 | 安全组/防火墙未放行 | 确保 Higress 容器能访问 Nacos 8848 端口 |
如果你现在就想开始,建议按这个节奏推进:
curl 验证 SSE 端点是否可达目标:亲眼看到 AI 调用了你的老接口并返回了正确数据。
目标:50 个接口全部接入,AI 能完成 80% 的日常查询。
我们算一笔保守的账:
方案 | 时间 | 人力 | 风险 | 后续维护 |
|---|---|---|---|---|
重写或改造老系统 | 3-6 个月 | 5-10 人 | 高(牵一发动全身) | 高 |
手写 MCP Server | 每接口约 0.5 天 | 2-3 人 | 中(维护成本高) | 中 |
网关声明式转换 | 3 天 | 1 人 | 低(不改业务代码) | 低 |
对于有 50 个接口的存量系统,网关方案能省下 90% 以上的时间和人力。
更关键的是 零风险:不需要改老系统一行代码,不存在“改坏了回不去”的担心。最坏的情况,删掉 Nacos 里的配置,老系统恢复原样,AI 助手不再能调用它而已。

如果你正在考虑让传统系统接入 AI,这三条建议请收好:
1. 不要一上来就想“重构”
传统企业最怕听到“重构”两个字。一个跑了好几年没出过问题的系统,谁敢动?网关方案的最大优势就是不碰存量代码——你只管加一层“翻译层”,出问题随时可以关掉。
2. 先跑通一个接口,再谈全面铺开
选一个最简单的接口——比如“查询当前用户信息”这种 GET 请求——先跑通端到端。等你亲眼看到 AI 真的调用了你的老接口并且返回了正确数据,再决定要不要批量铺开。我们就是这么做的,从第一个接口到 50 个接口,后面的复制粘贴十分钟一个。
3. 把 Token 管理做成可配置的
不要图省事把 Token 写死在配置里。用 Nacos 的配置引用功能,让 Token 可以随时更新。这是从 POC 到生产最关键的细节,也是后续运维成本最低的做法。
2024 年 11 月 MCP 协议问世以来,AI 行业最大的变化不是模型本身,而是 连接方式。以前我们教 AI 理解世界,现在我们给 AI 接入世界。
对于传统企业来说,数智化转型最大的障碍从来不是“技术不够先进”,而是“历史包袱太重,改不动”。
好在,我们找到了不改代码的办法。
你的老系统,在等 AI 敲门。