系统已经跑着，突然要在里面加 MCP，最难受的是不知道从哪插进去：是给现有接口套一层，还是单独起服务？权限、日志、回滚怎么保留？这篇按「先定落点、再定边界、最后灰度」的顺序，把改造路径拆成可执行的几步，并说明哪些老系统其实不适合上 MCP。
系统已经跑着，突然要在里面加 MCP，最难受的是不知道从哪插进去：是给现有接口套一层，还是单独起服务？权限、日志、回滚怎么保留？这篇按「先定落点、再定边界、最后灰度」的顺序，把改造路径拆成可执行的几步。
判断标准很简单：改造完成后，原有调用路径不受影响，MCP 只是一个新增入口。如果做不到这一点，说明改造范围划大了，先缩回来。下面每一节都给出具体动作，你照着做就能把风险控制住。
MCP 接进来，到底改的是哪一层
第一步不是写代码，是判断你的系统在这条链路上扮演什么角色。是提供能力给模型调用（服务端角色），还是去调用别人的工具（客户端角色）？两者改造量差别很大：服务端要暴露接口、写 schema、管权限；客户端要管连接、超时、结果解析。
- 服务端角色
- 把已有业务能力包装成工具或资源，供外部客户端调用；改造重点是暴露面与权限划界
- 客户端角色
- 在你的应用里去调用别的 MCP 服务；改造重点是连接管理、超时重试与结果裁剪
- 双向角色
- 既有能力要暴露，又要调用外部工具；建议分两期做，别一次改完
确定角色后，把现有能力按时效性和副作用分成三类：只读查询、低风险写、高风险写。第一批只碰只读查询，剩下的先记在清单里。
- 只读查询：查订单、查配置、查库存明细，适合第一批暴露
- 低风险写：备注、打标签，可以第二批做，但要加确认位
- 高风险写：支付、退款、改权限、删数据，先排除在 MCP 之外
- 需要人工审批的：审批流本身走已有系统，不要用模型代替审批
- 跨多步事务的：一个工具里包三步写操作，先拆开或直接不做
落点选择：旁挂、内嵌还是包一层网关
落点决定后面所有事情的难度。常见三种做法，按团队现状选，别按技术偏好选。
| 落点 | 改动量 | 隔离性 | 回滚难度 | 适用情况 |
|---|---|---|---|---|
| 旁挂进程 | 最小，不动原系统 | 好，独立进程崩溃不影响主流程 | 低，停进程即可 | 老系统不便重编译，只读查询类能力 |
| 内嵌到应用 | 中等，要加依赖和生命周期管理 | 差，MCP 问题可能拖累主进程 | 中，需要重新发版 | 延迟敏感、要复用已有鉴权 |
| 包一层网关 | 中偏大，多一个运维对象 | 好，网关可以独立限流熔断 | 中，网关配置回滚即可 | 多套系统共用一个 MCP 入口 |
选完之后问自己一句：出问题时，我能不能在不发版、不动数据库的前提下把 MCP 关掉？如果答案是能，落点就选对了。
- 清点现有接口把准备暴露的接口列出来，标注调用频率、是否只读、返回体大小
- 试跑旁挂进程用旁挂方式接一个只读接口，验证连通性和延迟
- 评估是否内嵌如果延迟要求高且已有鉴权可复用，再考虑内嵌，否则旁挂就够
- 决定是否上网关如果后面还要接第二套系统，现在就把网关层的位置留出来
把老接口翻译成工具：命名、参数与返回
老接口是给人看的，工具是给模型用的，中间要翻译。翻译质量直接决定模型调得对不对。原则是：名字要能猜到用途，参数要扁平，返回要裁剪。
- 工具名用动词加对象，比如查订单明细、改收货地址，别用内部代号
- 参数扁平化，不要把嵌套对象原样透出；模型对深层嵌套容易填错
- 必填和可选分清楚，枚举值写死在 schema 里，别让模型猜
- 参数里不要出现内部主键、内部状态码这类只有系统自己懂的东西
- 返回结果统一裁剪：长列表截断到合理条数，字段改名成通用语义
- 错误信息脱敏后再返回，不要把堆栈和 SQL 抛出去
{ "name": "query_order", "description": "按订单号查订单状态", "inputSchema": { "type": "object", "properties": { "orderNo": { "type": "string" } }, "required": ["orderNo"] } }返回体这一块最容易埋坑。建议定一个统一包装：成功时只返回需要的字段，失败时返回错误码加一句人话描述。别把内部数据结构原样透出去，后面改结构会牵动一堆客户端。
鉴权与权限：谁的身份在调用工具
MCP 侧最常见的错误是：调用方拿到了服务账号，等于全权访问。模型一旦把参数填错，影响范围是整个库。改造时要区分两个身份。
| 身份 | 含义 | 处理方式 |
|---|---|---|
| 调用方身份 | 谁在发起这次工具调用 | 校验凭证、限流、记录审计 |
| 被执行方身份 | 这次操作最终以谁的名义落库 | 按最小权限映射，不能默认全权透传 |
每个工具单独划数据范围：查订单的工具只能查当前用户或当前租户的订单，不能给一个通用查询。写操作类工具要有二次确认或审批位，不能只靠模型判断该不该执行。
- 每个工具绑定一个权限点，不要共用一个宽泛的权限
- 数据范围按租户、按用户、按组织维度收窄到最小
- 写操作加确认位或审批位，确认通过才真正提交
- 定期对账：抽查工具实际访问的数据范围是否超出预期
日志、审计与成本留痕
MCP 调用要记全，不然出问题查不动。每次调用至少记这几项：调用方、工具名、参数摘要、耗时、返回状态。参数里的敏感字段落库前脱敏，保留可回溯但不留原文。
- 调用方标识与请求 ID，串联整条链路
- 工具名与工具版本，方便定位是哪个工具出的问题
- 参数摘要：记录结构和长度，敏感值脱敏
- 耗时与返回状态，区分超时、鉴权失败、业务报错
- 成本留痕：调用量按天按工具汇总，方便和预算对账
另一件事是把 MCP 调用纳入既有监控，而不是新开一套没人看的面板。告警阈值沿用现有系统的规则，接入方式和普通接口保持一致。想了解同类中转服务的检测维度，可以到 /tools/speed-test 看它怎么测连通与延迟，思路可以直接借鉴。
灰度上线：从只读能力开始放量
第一批只放只读、无副作用、结果好验证的工具。什么叫结果好验证？就是调用完你能人工比对出对不对，不需要读日志猜。
- 先内测只给自己团队开通，验证工具注册、鉴权和返回是否正确
- 小范围放量按调用方或按用户分批放开，观察头两天的失败率和延迟
- 再全量失败率和延迟稳定后放开到全部调用方，同时保留开关
- 设熔断出问题能一键关掉 MCP 入口，主流程照常走
灰度期间最该盯的两个指标是调用量和失败率。失败率突然上升，先看是不是参数结构变了，再看是不是某个工具的权限被调整过。
回退设计与不适用情形
回退设计的原则只有一条：保留原有调用路径，MCP 只是新增入口，不是替换。回滚即关开关，不动数据库、不发版。
- 开关粒度按工具分，不要只能整体关，方便定位问题工具
- 回滚后原有调用路径必须完整可用，提前演练一次
- 数据侧不需要回滚脚本，避免引入新的不一致
- 老系统若强依赖同步事务，先别接 MCP，先做接口治理
- 接口本身不稳定、错误率高的系统，先修稳定性再谈接入
还有一种情况要坦白说：工具数量少、调用频率低、全程有人盯着的场景，人工触发比接 MCP 更划算。接入本身有维护成本，别为了用而用。
落地检查清单与排查顺序
改造前四样东西齐全再动手：能力清单、权限矩阵、日志字段、回滚方案。缺一样就先补，别边做边想。
| 阶段 | 检查项 | 通过标准 |
|---|---|---|
| 改造前 | 能力清单 | 只读能力与写操作分开列 |
| 改造前 | 权限矩阵 | 每个工具对应一个权限点和一个数据范围 |
| 改造前 | 日志字段 | 六项必备字段确认落库 |
| 改造前 | 回滚方案 | 开关粒度与演练记录齐全 |
| 上线后 | 调用量与失败率 | 头一周按天看，异常先查参数结构 |
出问题时的排查顺序固定成四步，别乱跳：客户端能否连上、工具是否注册成功、鉴权是否通过、业务逻辑是否报错。每一步都有对应的日志位置，提前标好能省不少时间。
如果你需要横向对比不同接入方式的成本和延迟表现，站内资料库里有对应的对比页，数字随时间会变，具体到 /price-watch 核对当时的数字更靠谱。
能旁挂就不要内嵌，能只读就不要写，能灰度就不要全量——存量系统改造的三条底线。下一步动手前先跑一遍站内的接口连通性检测，确认现有接口的延迟和稳定性是否支撑 MCP 接入，避免把不稳定因素带进新链路。→
常见问题
现有系统改造成 MCP 服务，要重写原来的接口吗？
多数情况不用重写。做法是在原接口外面加一层适配，把入参出参翻译成工具 schema，原逻辑保持不动。只有原接口本身耦合太深、没有稳定边界时，才需要先抽一层再包。好处是回滚时把适配层摘掉就行。
MCP 接入要不要单独部署一个服务？
看情况。只读查询、调用量不大时，旁挂一个独立进程最省事；如果要求低延迟、复用已有会话和鉴权，内嵌进应用更顺；多套系统共用时用网关。判断标准是有没有多调用方和统一审计需求。
权限怎么划才不会出事？
按工具而不是按系统划权限：每个工具单独声明能访问哪些数据、能不能写。写操作加审批或二次确认，读操作也要限制范围。不要图省事给一个万能工具，那等于把内部接口全暴露。
怎么判断这次改造值不值得做？
先看有没有多个调用方、调用是否高频、能力是否稳定。三个都满足通常划算；只有一个满足，手工调用或简单脚本可能更省事。接 MCP 的成本主要在 schema 维护和权限治理，不在写代码那一步。
上线后发现工具有问题，怎么快速止损？
入口层留一个开关，直接禁用问题工具而不是整站下线，主流程不受影响。同时保留原调用路径作为兜底。排查按连接、注册、鉴权、业务四层往下走，多数问题在前两层。
