把一个跑了多年的存量业务系统交给 Agent 使用，大多数团队会本能地从一件事开始：改接口、上 MCP。
这条路径听起来很合理——AI 时代要接入能力，先标准化接口是天经地义的事。但真正做过几次改造后，我发现一个反直觉的事实：
让 Agent 用上一个存量系统，第一步往往不是改系统，而是把人脑里的「使用方法」交给 Agent。
而「使用方法」这层东西，恰恰是大多数团队在 Agent 改造里最被低估、也最容易漏掉的一层。
这篇是「存量系统 Agent 化」系列的第一篇，先把战略层想清楚。核心一句话：
API 让能力「接得上」，Skill 让能力「用得对」，MCP 让能力「放得开」。三者不是替代关系，而是不同规模问题的不同答案。
一、最常见的误区：做 Agent 必须先建 MCP
每次有团队启动 Agent 改造，我都会听到同一句话：
“听说 Agent 调业务系统，必须先把接口改造成 MCP。”
这句话只对了一半。
MCP（Model Context Protocol）确实是 Agent 连接外部系统的标准化方式。但「标准化方式」不等于「所有系统都必须从 MCP 改造开始」。
为什么这么多人会把它们等同起来？因为 MCP 的叙事太成功了——它把「能力接入」抽象成了一个清晰的协议、一组工具描述格式。你拿着这套叙事去找存量系统，自然觉得：既然要接，那就按官方标准接。
但这里有个被忽略的前提：
MCP 解决的是规模化复用问题，不是接入问题本身。
一个内部通知系统，目前只有一个 Agent 在用，接口稳定，预算有限。你强行先做 MCP Server，拿到的是什么？
- 一层额外的协议封装；
- 一套工具描述；
- 一个新的部署单元；
- 但业务能力本身，一行都没变。
更糟的是，MCP 只描述「工具有哪些参数、能做什么动作」，它不会告诉 Agent：
- 这个通知系统在什么场景下该用；
- 短信、企微、邮件三个渠道，当前业务该选哪个；
- 缺参数时该问用户还是直接报错；
- 正式发送前要不要先测试；
- 哪些动作必须人工确认。
所以 Agent 接上去之后，表现通常是：能调，但不会用。
这个误区背后的真正问题，不是「MCP 该不该建」，而是把连接方式当成了改造起点。正确的起点永远只有一个：
先问「要解决什么业务问题」，再问「用哪种方式接」。
二、存量系统的三层结构
把误区破掉之后，需要重建一个清晰的心智模型。一个存量系统被 Agent 使用，本质上要回答三个问题：原有 API（系统能做什么）、Skill（Agent 应该怎么做）、Adapter/MCP（Agent 如何调用现有系统）。三层各司其职，缺一不可。
第一层：原有 API——系统能做什么
这是存量系统本来就有的东西。通知系统的「发企微」「发邮件」「建定时任务」，订单系统的「查单」「改单」「退款」，都是这一层。
它应当稳定、可验证、面向机器，但仍必须关心调用者身份、权限、幂等性、前置条件和副作用。参数格式正确不代表业务操作一定正确；绝大多数存量系统这一层已有基础，Agent 改造的第一步通常是把它盘点清楚：有哪些接口、认证和授权如何做、参数与返回值是什么、稳定性如何、有没有副作用。
第二层：Skill——Agent 应该怎么做
这是 Agent 时代最被低估、也最值钱的一层。
一个老练的运营每天用通知系统发活动提醒，他脑子里有一整套判断规则：
- 活动上线要提前 30 分钟提醒项目群；
- 找不到项目群就发给负责人本人；
- 通知内容要带「页面、库存、客服口径」三件套；
- 同时给技术值班发邮件，带时间、范围、异常联系人；
- 发之前要给运营确认，确认后才创建定时任务；
- 找不到具体的人或群，统一回落到发起人本人。
这些规则过去散落在人的经验、产品文档、操作手册、会议纪要、群聊记录和事故复盘里——从来没在接口里。接口只告诉你「调用 send_message 可以发消息」，不告诉你「什么时候发、发给谁、怎么写、错了怎么办」。
Skill 的真正职责，就是把这些隐性业务知识沉淀成 Agent 能理解、能遵守、能执行的规则集。
第三层：Adapter / MCP——Agent 如何调用现有系统
这一层是技术适配，负责把 Skill 描述的业务步骤翻译成接口调用，处理参数转换、身份认证、错误透传。它有两种实现密度：
- 轻量适配器脚本：一个
.mjs/.ts文件，直接调 REST API，适合单一 Agent、少量接口、快速试点； - MCP Server：按标准协议暴露工具，适合多 Agent、多团队、需要统一治理和复用。
两者不是二选一，而是同一层的不同实现密度。
三层放在一起看：
用户自然语言
↓
Agent 理解目标、规划步骤、调用能力
↓
Skill 规定业务规则：何时做、选哪个渠道、
内容怎么写、缺信息怎么办、什么动作要确认
↓
Adapter / MCP 适配现有系统接口：参数转换、REST 调用、错误透传
↓
原有 REST API 提供真实业务能力存量系统在这张图的最底层，通常一行都不需要改。我们只是在它和 Agent 之间补齐了两样东西：一份 Agent 能读懂的业务操作手册，加一个调用现有接口的适配层。
存量系统进入 Agent 时代，第一步通常不是改造系统本身，而是补齐 Agent 与系统之间的「说明书和适配器」。
三、为什么 Skill 这一层不能省
讲清三层结构后，最容易踩两个坑，都和 Skill 有关。
第一个坑：建完 MCP，以为接上就能用了。
很多团队建完 MCP Server长出一口气：「接上 Agent 就能用了。」结果接上之后，Agent 不知道当前场景选哪个工具、不知道多个工具按什么顺序调、缺参数就直接猜、高风险动作不经确认就执行。
MCP 工具描述、服务器指令和注解可以表达一部分用途、风险与交互提示，但通常不能完整承载或强制执行企业业务流程。真正的顺序约束、审批、幂等和高风险确认仍应由 Skill、编排器和服务端策略共同保证。
哪怕 Agent 接入了全部 MCP 工具，它也未必会用，更未必用得对。
MCP 是企业向 Agent 提供的标准化工具箱，Skill 是这套工具箱的业务使用说明和决策规则。
第二个坑：写 Skill 等于把接口文档复制进 SKILL.md。
接口文档描述的是「参数是什么、返回值是什么」。Skill 真正该沉淀的，是企业过去分散在人脑和组织里的隐性知识：产品经理的业务决策规则、运营长期积累的 SOP、技术人员处理异常的经验、群聊里被反复解释的注意事项、事故后增加的保护规则、哪些结果才算真正完成任务。
判断一份 Skill 写得好不好，标准很简单——读一遍 SKILL.md，问自己：
这份文档，能不能让一个完全不懂这个系统的新人，在没人指导的情况下，把这件事做对、做完整、出了问题知道怎么办？
如果不能，它就还停留在「接口说明」的层级，没到「业务大脑」的层级。
这两件事必须分开做，因为它们变化的速度完全不一样：MCP 工具变化慢（接口稳定后基本不动），Skill 规则变化快（业务 SOP、运营经验、事故教训会持续沉淀）。把它们混在一起，业务规则一改就要动 MCP Server，改完还要重新部署发版——这正是 Skill 必须独立成层的代价所在。
接口是手脚，Skill 里的决策规则才是业务大脑。
顺带说一句，Skill 这一层最有趣的地方在于：它把产品经理和运营的价值，重新放回了 AI 工程的核心位置。同一组底层能力——查询、选择、发送、查状态、建任务——通过不同的 Skill，可以组合出活动发布、故障通知、会员召回、经营播报、审批催办等完全不同的业务场景。Agent 时代的创新，不一定是开发更多功能，也可能是把企业已有的能力、数据和经验重新组合。
四、三条改造路径：认清你在哪一阶段
把前面收拢起来，存量系统 Agent 化有三条清晰可走的路径。不同系统所处阶段不同，不应该用同一种改造方式。
路径一：Skill + 脚本 + 原有 API
Agent → Skill → Script → REST API适合：快速试点、单一 Agent、接口数量少、原 API 已稳定、存量系统不便改造、优先验证业务价值。
核心价值：以最低成本让一个已有系统快速被 Agent 使用。关键判断是先别追求架构先进，先证明业务可行。
路径二：仅 MCP + 原有业务服务
多个 Agent → MCP Client → MCP Server → 原有业务服务适合：多个 Agent 接入、多团队复用、需要统一工具发现和统一鉴权、能力需要独立升级、准备平台化运营。
核心价值：把一组业务能力标准化地提供给整个 Agent 生态。关键判断是能力已被验证有价值，现在要让它在组织里安全扩散。
路径三：Skill + MCP（完整形态）
Skill 业务决策、使用规则、工作流
↓
Agent 理解目标、规划步骤、编排能力
↓
MCP 标准化提供工具能力
↓
存量业务系统 稳定、确定性地执行适合：工具能力已标准化、业务流程较复杂、需要组合多个基础工具、希望持续沉淀产品运营经验。
核心价值：MCP 提供标准化能力，Skill 把这些能力组织成真正的业务解决方案。这是存量系统 Agent 化最完整的形态。
三条路径的判断表
| 维度 | 路径一：Skill+脚本 | 路径二：仅 MCP | 路径三：Skill+MCP |
|---|---|---|---|
| 主要解决的阶段 | 试点验证 | 能力平台化 | 业务场景化 |
| 调用方规模 | 单 Agent | 多 Agent / 多团队 | 多 Agent + 复杂业务 |
| 业务知识沉淀位置 | Skill 文件 | 暂未沉淀 | Skill 文件 |
| 接入改造成本 | 最低 | 中 | 高 |
| 治理能力 | 弱 | 强 | 强 |
| 业务规则可演进性 | 强（改 Skill） | 弱（规则散在各 Agent） | 强（Skill 独立于 MCP） |
| 典型适用 | 一个内部系统的 Agent 试点 | 一组稳定能力的对外开放 | 一个完整业务场景的 Agent 化 |
这张表里最容易被忽略的是业务规则可演进性那一行。很多团队选了路径二，把业务规则直接写进各个 Agent 的 prompt——结果业务规则一变，就要改 N 个 Agent 的 prompt，改完每个还要重新评估。这就是没有把 Skill 单独拎出来的代价。
五、先问业务，再问连接方式
工具和技术会变，Skill 格式会变，MCP 协议会演进，但有一条原则短期不会过时：
先问业务问题，再问连接方式。
不要先提「我们要建设 MCP」，再为 MCP 寻找场景——这是把方式当成了问题本身。正确的问题是：
- 我们要让 Agent 解决哪个业务问题？
- 这个问题需要调用哪些能力？这些能力稳定吗？在哪？
- 有几个 Agent、几个团队、几个客户端要用？
- 业务规则是不是足够复杂、足够有价值，值得单独沉淀成 Skill？
回答完这几个问题，该用 Skill+脚本、该建 MCP、还是该两者一起上，自然就有答案。
这一篇讲的是「想清楚」——三层各是什么角色、三条路径怎么选。下一篇 会落到战术层，讲 Agent 物理上怎么够到存量系统：跑了 8 年接口残缺的老系统怎么接、没源码的内部工具怎么办、一个完整任务从识别到上线分几步。
存量系统的最大资产，从来不是它的接口，而是围绕它沉淀下来的多年业务经验。过去我们沉淀系统功能；Agent 时代，我们还要沉淀系统的使用方法。