← 返回

架构师视角：Claude Skills 与 MCP 的深度解析

EN
返回
EN

架构师视角：Claude Skills 与 MCP 的深度解析

在构建 AI 辅助的工程工作流时，我们经常听到两个术语：Claude Skills 和 MCP (Model Context Protocol)。初学者容易将二者混淆，认为它们都是“给 AI 增加功能”的方式。

但这是一种肤浅的理解。作为架构师，我们需要从系统分层的角度来看待它们。

本文将深入探讨这两种技术的本质区别，并展示如何在企业级架构中将它们结合，构建高可靠的 AI Agent。

架构分层：认知 vs 执行

要理解它们的区别，我们需要引入两个概念：执行层 (Execution Layer) 和 认知层 (Cognitive Layer)。

1. 执行层：MCP (Model Context Protocol)

MCP 的本质是一个标准化的 I/O 协议。它解决了 AI 模型面临的“孤岛问题”。

从技术实现上看，MCP 采用了经典的 Client-Host-Server 架构：

  • Protocol: 基于 JSON-RPC 2.0。
  • Transport: Stdio 或 SSE (Server-Sent Events)。
  • Payload: 标准化的资源 (Resources)、提示 (Prompts) 和工具 (Tools)。

MCP Server 是无状态 (Stateless) 和被动 (Passive) 的。它只负责暴露原子能力，例如 read_file 或 query_database。它不关心这些工具被调用的顺序，也不关心业务逻辑的上下文。

工程格言：MCP 给了 Claude "手" 和 "眼"，但没有给它 "脑子"。

2. 认知层：Claude Skills

Claude Skills (在不同的上下文中可能被称为 System Prompts, Agentic Workflows 或 Custom Instructions) 属于认知层。

它的本质是可移植的上下文与逻辑编排。从代码视角看，Skill 通常定义在一个 Markdown (SKILL.md) 文件中，包含元数据和结构化指令：

  • Frontmatter: 元数据（如名称、描述）。
  • # Role: 角色定义。
  • ## Objective: 目标定义。
  • ## Rules: 关键约束。

Skills 负责编排 MCP 提供的原子工具。它定义了任务的“元数据”和“状态机”。

深度实例：生产环境数据库变更

让我们通过一个高风险场景来展示这种分层架构的必要性：生产数据库的数据迁移。

场景 A：仅使用 MCP (裸奔模式)

你配置了一个 Postgres MCP Server 给 Claude。Claude 拥有了执行 SQL 的能力。

用户：“删除 users 表中所有 status=inactive 的用户。” Claude：调用 execute_query("DELETE FROM users WHERE status='inactive'")。

风险：如果这是生产环境？如果需要软删除？如果需要先备份？MCP Server 本身无法阻止这种“合法的愚蠢行为”，因为它只负责执行 SQL。

场景 B：MCP + Database Ops Skill (工程模式)

我们引入一个 "Database Ops Skill"。这个 Skill 不包含任何 SQL 连接代码，它包含的是资深 DBA 的思维模型。

Skill 定义 (SKILL.md)：

---
name: db_safe_ops
description: 安全地执行数据库变更，防止生产环境数据丢失。
---

# Role: 数据库可靠性工程师 (DBRE)

## Objective
安全地执行数据库变更，防止生产环境数据丢失。

## Critical Rules
1. 禁止在未开启事务并 SELECT 验证行数的情况下执行 DELETE/UPDATE/DROP。
2. 生产环境变更前必须确认备份状态。

## Workflow SOP
1. 调用 `check_connection_safety()` 识别环境。
2. 调用 `begin_transaction()` 开启隔离。
3. 运行 `explain_query()` 检查影响。
4. 执行 `SELECT count(*)` 验证范围。
5. 请求人工确认后才可 COMMIT。

执行流程：

  1. 用户：“删除 users 表中所有 status=inactive 的用户。”
  2. Claude (受 Skill 约束)：
    • 思考：检测到破坏性操作。根据 db_safe_ops 规则，我不能直接删除。
    • 行动：调用 MCP 工具 execute_query("BEGIN")。
    • 行动：调用 MCP 工具 execute_query("SELECT count(*) FROM users WHERE status='inactive'")。
  3. Claude：“我已开启事务。查询显示将有 500 个用户被删除。请确认是否继续提交？”

核心机制解密：从静态文本到动态推理

为什么简单的 Markdown 文本能控制复杂的行为？这不仅仅是“提示词工程”，而是涉及到大语言模型（LLM）底层的概率计算与注意力机制。

1. 提示词编译与语义锚点 (Prompt Compilation & Semantic Anchors)

当你加载一个 Skill 时，系统并非是在“运行代码”，而是进行了一次上下文注入 (Context Injection)。

  • System Message 的特殊权重：SKILL.md 中的 # Role 和 ## Rules 通常被注入到 Context Window 的最前端（System Slot）。在 Transformer 架构中，位置编码（Positional Encoding）使得这部分信息具有全局性的注意力权重。
  • 语义锚点：Skill 中的特定术语（如“DBRE”、“ACID”）充当了语义锚点。它们激活了模型在预训练阶段形成的高维向量空间中的特定区域，强制模型的后续生成收敛到“专业模式”，而不是“闲聊模式”。

2. 熵减与思维链引导 (Entropy Reduction via CoT)

Skill 中的 ## Workflow SOP 实际上是为模型的 Chain of Thought (CoT) 铺设了强制轨道。

  • System 2 慢思考：LLM 默认倾向于 System 1（快思考，直觉反应），这容易导致幻觉。SOP 强制模型进入 System 2（慢思考，逻辑推理）。
  • 概率视角的解释：
    • 无 Skill：模型预测 $P(Answer|Question)$。这是一个巨大的搜索空间，错误率高。
    • 有 Skill：模型被迫预测 $P(Step1|Question) \rightarrow P(Result1|Step1) \rightarrow P(Step2|Result1)$。
    • 通过将大问题拆解为小步骤，每一步的条件概率熵 (Conditional Entropy) 被显著降低。中间步骤（如 explain_query 的输出）充当了**Grounding（落地）**信号，修正了模型原本可能偏离的轨迹。

3. 隐式状态机与上下文管理 (Implicit State Machine)

MCP Server 是无状态的，但对话历史 (Conversation History) 实际上构成了一个隐式的、概率性的状态机。

  • KV Cache 的作用：当 Claude 完成 SOP 的第一步时，该操作的结果（Tool Result）被写入上下文并编码为 KV Cache。
  • 软状态管理：传统的程序状态机是硬编码的（If A then B）。LLM 的状态机是“软”的——它通过阅读上下文中的 Tool Result 来推断当前所处的阶段。
  • 抗噪性：Skill 定义了状态转移的规则（图纸），而 Context Window 存储了当前状态实例。高质量的 Skill 还能通过明确的“停止条件”，防止长对话中的上下文漂移 (Context Drift) 问题。

工程化启示：Thick Skill, Dumb Tool

在设计 AI 系统时，我推荐遵循 "Thick Skill, Dumb Tool" (厚技能，哑工具) 的原则。这不仅仅是代码组织方式，更是关乎 AI 基础设施的生命周期管理。

1. 原子化工具 (The "Dumb" Layer)

保持 MCP Server 的纯粹性和原子性。它们应该像标准的 UNIX 工具一样——只做好一件事（如 cat 或 grep）。

  • 反模式：在 Python/Go 工具代码中嵌入业务逻辑，例如“只有管理员才能操作”或“只能在周五部署”。
  • 最佳实践：工具只应返回原始数据或执行原始命令。这最大化了工具在不同 Agent 和部门间的复用性。一个“Postgres 工具”应该能同时被“DBA Agent”和“数据分析师 Agent”使用。

2. 逻辑上浮 (The "Thick" Layer)

将复杂性转移到 Prompt/Skill 层。业务规则是动态的，而基础设施是静态的。

  • 逻辑热修补 (Hot-Patching)：如果团队决定将部署窗口从“周五”改为“周四”，你只需要更新一个 Markdown 文件（Skill），而不需要重新编译和部署二进制服务。
  • 迭代速度：Prompt 逻辑可以在几分钟内完成迭代。而硬编码的逻辑需要完整的 CI/CD 流程。“厚技能”模式使得 "Software 2.0" 级别的开发速度成为可能。

3. 架构解耦 (Architectural Decoupling)

这种分离创造了一个清晰的抽象边界，类似于 OS Kernel (MCP) 与 User Space Applications (Skills) 的关系。

  • 迁移韧性：当你的基础设施发生迁移（例如从 AWS 迁移到 Azure，或从 Postgres 迁移到 MySQL）时，你只需要更换底层的 MCP 驱动程序。高层的认知推理——即“数据库运维 Skill”——对底层驱动是不可知的，几乎不需要修改。这极大地保护了你在“提示词工程”上的资产投入。

4. 测试策略 (Testing Strategy)

解耦架构简化了 AI Agent 这一臭名昭著的难以测试的领域。

  • 单元测试：MCP Server 可以使用标准的、确定性的单元测试（Mocks/Stubs）进行验证。
  • Evals (评估)：Skills 可以使用 "LLM-as-a-Judge" 框架进行评估。你可以验证模型在特定上下文中是否正确遵守了 SOP，而无需在每次测试运行时都启动真实的数据库基础设施。

结论

MCP 是硬件接口，Skills 是驱动程序。

真正的 AI 工程化能力，不在于你能接入多少个 MCP Server，而在于你能否编写出高质量的 Skills 来驾驭这些工具。

不要试图用 MCP 去解决认知层的问题，也不要指望 Skills 能突破物理隔离。理解并尊重这两者的边界，是构建稳定 AI Agent 的第一步。