在构建 AI Agent 的过程中，开发者往往会面临一个核心的架构抉择：当我们需要 AI 完成一套复杂流程时，控制权到底该交给谁？
是写死在 Python/TypeScript 代码里，还是通过自然语言教给 AI？
Claude Code 的架构给出了一个精妙的答案。它通过 MCP (手)、Skills (脑) 和 Agent (灵魂) 三者的分层，重新定义了人机协作的边界。
- 一个架构上的迷思：MCP 其实能做所有事
首先，我们需要打破一个误解：MCP 只能做简单的原子操作吗？
答案是否定的。从技术实现上看，MCP Server 的代码拥有图灵完备性。
正如我们所讨论的，你完全可以写一个名为 deploy_to_production 的 MCP 工具。在这个工具的内部代码里，硬编码写死了一连串复杂的逻辑：
git pull → run tests → build docker → push registry → kubectl apply
对 Claude 来说，它只需要调用一次这个工具，幕后就会自动跑完所有流程。既然 MCP 可以已经在代码层面实现了"组合拳"，为什么 Claude Code 还需要设计 Skills 这一层？
这引出了两者最本质的区别：逻辑的载体不同。 - 核心对决：逻辑在代码 (Code) vs. 逻辑在提示词 (Prompt)
方案 A：硬编排 (Hard Orchestration) ------ MCP 的方式
- 逻辑载体：代码（Python/Go/TS）。
- 决策者：程序员（在写代码时已决定）。
- 执行模式：黑盒（Black Box）。
当我们把 deploy_to_production 做成一个 MCP 工具时：
- 确定性：流程绝对稳定，测试挂了就是挂了，必定终止。
- 不可见性：Claude 像是按下了一个按钮。按钮按下后，机器内部怎么运转，Claude 看不见，也插不上手。如果第二步报错，Claude 只能拿到一个最终的报错结果，无法在第二步和第三步之间进行微调。
方案 B：软编排 (Soft Orchestration) ------ Skills 的方式
- 逻辑载体：自然语言（Markdown/Prompt）。
- 决策者：AI 模型（在运行时动态决定）。
- 执行模式：白盒（Glass Box）。
当我们把部署流程写成一个 Deployment Skill 时：
- 灵活性：Skill 是一份"操作手册"。它告诉 Claude："先试着跑测试，如果测试挂了，看看是不是网络问题，如果是网络问题重试一次，如果是代码问题则停止。"
- 介入能力：这是多轮对话的过程。每一步操作（调用原子 MCP）的结果都会反馈给 Claude，Claude 可以利用它的推理能力（Reasoning） 动态调整接下来的动作。
结论：Skills 的设计初衷，是为了将"业务逻辑"从"底层工具"中剥离出来，交还给 AI 的大脑去实时编排。
- Skills 的构成与加载机制
为了支撑这种"软编排"，Skills 在设计上必须轻量且动态。
组成部分
一个 Skill 本质上是一个结构化的 Markdown 文件，它不包含二进制代码，只包含"教导"：
- Metadata (元数据)：告诉系统"我是谁，我能干什么"（如 name, description）。
- Instruction (指令)：核心的业务逻辑。例如："在重构代码前，必须先阅读 CONTRIBUTING.md" 或者 "如果遇到 404 错误，尝试去掉 URL 的后缀重试"。
- Tool Definitions (工具映射)：说明这个 Skill 依赖哪些底层的原子 MCP 工具（如 read_file, bash_execute）。
按需加载 (On-Demand Loading)
由于 Skills 是 Prompt 的一部分，直接塞入所有 Skill 会撑爆上下文窗口（Context Window）。因此 Claude Code 采用了动态路由机制：
-
意图识别：当用户说"帮我修个 Bug"时，系统扫描所有 Skill 的描述。
-
挂载 (Mounting)：系统发现 Debug Workflow Skill 最匹配，于是将该 Skill 的 Prompt 临时注入 到当前的对话中。
-
卸载：任务结束后，该 Skill 的上下文被释放。
-
终极拼图：Agent 到底是什么？（System Prompt 的角色定义）
既然有了工具（MCP）和手册（Skills），那么那个"使用工具、阅读手册"的Agent究竟是什么？
在 Claude Code 的体系里，Agent 本质上就是一段精心设计的 System Prompt（系统提示词）加上一个运行时死循环（Runtime Loop）。
Agent 的"灵魂"：System Prompt
Agent 不是一个新的 AI 模型，而是被 System Prompt "催眠"后的 Claude。这段 Prompt 定义了它的角色定位（Identity）：
- 你是谁：你不是通用聊天机器人，你是 Claude Code，一个运行在终端里的资深全栈工程师。
- 你的职责：你需要通过思考（Chain of Thought）来解决复杂的编程任务，而不是直接给出空洞的建议。
- 你的边界：对于只读操作可以直接执行，对于删除操作必须询问用户。
Agent 的"肉体"：Runtime Loop
光有 Prompt 只是"脑后插管"的幻觉，Agent 还需要一个程序去执行它的意志。Claude Code 的 CLI 程序就是一个Runtime Loop：
- 它监听模型的输出。
- 如果模型（Agent）决定使用工具，Runtime 就去调用 MCP。
- Runtime 把 MCP 的运行结果抓回来，喂给模型，触发下一次思考。
Agent=Model+System Prompt (角色设定)+Runtime Loop (执行回路)\text{Agent} = \text{Model} + \text{System Prompt (角色设定)} + \text{Runtime Loop (执行回路)}Agent=Model+System Prompt (角色设定)+Runtime Loop (执行回路)
- 进阶：为什么要引入 Multi-Agent（多智能体）？
有了上述设计，Claude Code 实际上已经是一个很强的"主 Agent"了。但正如你敏锐指出的：System Prompt 定义了它的天花板。
单一 Agent 的局限性
Claude Code 的主 Agent 默认 System Prompt 是："你是一个编程专家 (Coding Expert)"。
- 它的思维模式是：构建、修复、优化代码。
- 但在软件工程中，我们还需要完全不同的角色，比如"测试专家 (QA)"。
如果我们强行让"编程专家"去测试，他会下意识地想去"修代码"，而不是"找茬"。这就导致了角色冲突。
Multi-Agent 的泛化设计
为了解决这个问题，Claude Code 引入了 Sub-agent（子智能体） 概念，其本质是 System Prompt 的动态切换与特化。
- 主 Agent：负责统筹、分发任务。
- System Prompt: You are a Coding Expert...
- 测试 Agent (Sub-agent)：当主 Agent 觉得需要深度测试时，它唤起一个子 Agent。
- System Prompt: You are a QA Engineer. Your goal is to break the code, find edge cases...
- 安全 Agent (Sub-agent)：
- System Prompt: You are a Security Auditor. Focus only on vulnerabilities...
设计初衷：
- 角色隔离（Role Isolation）：防止"既当运动员又当裁判员"。让"写代码的脑子"和"测代码的脑子"分开。
- 上下文纯净（Context Hygiene）：Sub-agent 拥有独立的上下文窗口，专注于特定任务，不会被主对话中冗余的历史信息干扰。
- 能力的无限泛化：通过定义不同的 System Prompt，Claude Code 可以瞬间从"程序员"变成"产品经理"、"架构师"或"安全员"，而不需要重构底层的 MCP 或代码逻辑。
总结
Claude Code 的设计哲学，展现了 AI 工程化的成熟形态：
- MCP 负责连接数字世界，提供能力（Hands）。
- Skills 负责承载业务流程，提供经验（Brain/SOP）。
- Agent 负责定义角色与思维，提供灵魂（Identity）。
- Multi-Agent 负责角色分工，提供泛化能力（Generalization）。
这一架构不再试图把所有逻辑都塞进代码里，也不再试图让一个 System Prompt 包打天下，而是构建了一个**"专业分工、动态协作"**的 AI 研发团队。