把所有业务都转成MCP，AI Skill才是正道，这做法不傻吗？

MCP（Model Context Protocol）可能火得有些过头了。自从 Anthropic 把这套协议抛出来，不少同行就开始坐不住，仿佛一夜之间，不把自家的业务接口重写成 MCP Server，就拿不到 AI 时代的入场券了。 每隔几年，技术圈总会刮起一阵“大一统协议”的飓风（前几年大家都把单体，一股脑的改成了微服务）。架构的本质是解决问题，而不是为了追逐某种昂贵的仪式感。把所有业务都强行转成 MCP，不仅是战略上的懒惰，更是战术上的自我折磨。对于真正深耕业务的开发者，Skill（技能）模式才是那个拨云见日的正道。 一、 被神化的 MCP：仪式感不该大于生产力 我们要承认，MCP 的初衷是好的，它试图在异构系统与 AI 智能体（Agent）之间建立一套通用的“对话逻辑”。企业之所以趋之若鹜，无非是想通过一套标准化协议，一劳永逸地解决 AI 与企业内部私有数据的对接问题。 但在高阶架构师眼中，“标准化”往往是“过度设计”的遮羞布。你想想看，咱们做业务系统的，核心诉求是什么？无非是让 AI 能顺畅地调一下那个已经跑了三年的查询接口。为了这点儿醋，MCP 非得让你包一顿极其复杂的饺子：你得专门起一套符合规范的 Server，折腾那一堆复杂的传输协议和资源映射。这哪里是在做集成，这分明是在给业务系统平添一道厚重的城墙。好的架构应该是消融于无形的，而不是这种喧宾夺主的“外交辞令”。 二、 MCP 在业务落地的“三座大山” 在真正的生产环境里，MCP 绝非宣传中那么美好，它至少有三道槛能让一个成熟的团队陷入泥潭。 1. 开发成本与双份代码的诅咒 MCP 要求一套完整的协议实现。这意味着你不仅要维护原有的业务逻辑，还得额外维护一套“协议转换逻辑”。这不只是多写几行代码的问题，而是双份的文档、双份的测试用例以及双份的 Bug 滋生地。对于只想快速让 AI 接管逻辑的团队来说，这种“双重维护”简直是架构设计的灾难。 2. 上下文膨胀与 Token 消耗的矛盾 这是 MCP 最致命的软肋。大量的 Tool 定义，在交互过程中包含了大量的元数据和冗余描述。当 LLM 尝试理解一个 MCP Server 提供的工具列表时，这些繁琐的协议文本会迅速撑爆上下文窗口（Context Window）。随之而来的，是急剧上升的 Token 消耗和不断拉长的响应延迟。在高并发的业务场景下，这种浪费几乎是不可接受的。 3. 调试噩梦的玄学 架构层级每增加一层 当 AI 调用失败时，你是去查提示词（Prompt）跑偏了？协议层封装错了？还是底层的业务逻辑挂了？这种深不见底的排错路径，是任何一个老牌架构师都不想面对的噩梦。 三、 为什么 Skill（技能）才是业务的“本命”？ 跳出协议，我们来看看什么叫 Skill（技能）。在 Solon AI 的设计哲学里，Skill 不是一种沉重的契约，而是一种 “能力的优雅包装” 。 它的核心逻辑非常朴素：业务不需要去适配协议，协议应该反过来适配业务。 代码即技能：你原来写得好好的方法，加个注解，它就是技能。 接口即技能：现成的 Swagger 文档，导入进来，它就是技能。 数据即技能：数据库连接配上只读权限，它就是技能。 这种从底层向上生长的逻辑，才符合系统演进的规律。 四、 降维打击：Solon AI 的 Skill 实践 作为一个高阶开发者，我更看重的是“投入产出比”。让我们来看看 Solon AI 是如何用 Skill 模式对 MCP 进行降维打击的。 示例 1：RestApiSkill —— 零成本激活存量接口 如果你有一堆已经写好的 REST 接口，想让 AI 具备调用它们的能力，你根本不需要给这些接口写任何新代码。