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 具备调用它们的能力，你根本不需要给这些接口写任何新代码。在 Solon AI 里，这叫“降维打击”：

// 1. 拿来主义：直接读取业务系统的 Swagger 文档
// 只要给一个 URL，AI 就能自动解析所有的 Path、Method 和参数描述
RestApiSkill orderSkill = new RestApiSkill("http://api.yoursite.com/v2/api-docs", "http://api.yoursite.com");

// 2. 扔给智能体，它瞬间就成了“业务专家”
ReActAgent agent = ReActAgent.of(chatModel)
        .role("订单管理员")
        .defaultSkillAdd(orderSkill) // 注入技能
        .build();

// 3. AI 现在知道怎么查库存、下订单、改状态了
agent.prompt("帮我看看尾号 9527 的订单发货了吗？").call();

示例 2：Text2SqlSkill —— 数据直接变报表

以前老板要查个数，你得手写 DAO、手写 SQL、写 Controller。现在，直接把数据库能力给 AI：

// 连上数据库，告诉它哪几张表归它管
Text2SqlSkill sqlSkill = new Text2SqlSkill(dataSource, "users", "orders", "refunds")
        .maxRows(50); // 安全策略：最多返回 50 行

ReActAgent agent = ReActAgent.of(chatModel)
        .role("财务分析专家")
        .defaultSkillAdd(sqlSkill)
        .build();

// AI 会自己思考：查总额需要执行 SUM(...)，然后自己生成 SQL 并执行
agent.prompt("统计一下上个月华东地区的退款总金额是多少？").call();

对比实验很直观：agent.defaultSkillAdd(...) 的操作，比去开发一个复杂的 MCP 节点要高效得多。这才是真正懂业务的“降维打击”。

五、 深度剖析：Skill 模式的架构优势

从架构选型上看，Skill 模式胜在三个字：灵、稳、复。

1. 低耦合（灵）：

Skill 可以是本地的，也可以是远程的。它像插件一样挂在 Agent 身上，不想要了随时拔掉，绝不伤及业务核心。

2. 强类型安全（稳）：

利用 Java 成熟的类型系统和 JSON Schema 校验，我们能精准控制 AI 传入的每一个参数。比起 MCP 散漫的消息传递，Skill 模式在执行前就锁死了风险。

3. 高度复用（复）：

一个 Skill 写好了，可以在简单的 ChatModel / SimpleAgent 里用，也可以在复杂的 ReActAgent 里调。

六、 总结：回归工程本质，审慎选择架构路径

架构设计的真谛不在于追求“最新”，而在于追求“最合适”。相比之下，Skill（技能）模式提供了一种更为务实的选择：它以轻量级的包装形式，实现了业务逻辑与智能体的无缝连接，确保了每一分算力都花在核心业务的推理上。

我们要的是手术刀般的精准与轻量。抛弃那些繁琐的协议转换吧，用 Skill 模式把业务潜能释放出来。记住那句话：最好的技术，是让你感觉不到它的存在。

口号：业务为王，Skill 为径。 别让协议成了你通往 AI 时代的绊脚石。