Claude Skills 架构解析：从提示工程到上下文工程，深入剖析其设计理念与实现细节，帮助你理解现代 AI 系统的构建方法。原文：Claude Skills Architecture Decoded: From Prompt Engineering to Context Engineering

过去二十年，软件架构领域经历了深刻变革，从单体应用向微服务的转变标志着系统设计理念的一个分水岭。如今，我们正处于 LLM 应用领域同样重大的范式转变的边缘。作为一名多年构建生产级 AI 系统的架构师，我认为必须从根本上重新构想智能应用的构建方式 —— 从传统“提示工程”转向我称之为“上下文工程”的更具结构化和模块化的方法。Anthropic 于 2025 年 10 月推出的 Claude Skills 架构，是这一转型中的一个里程碑成就。

核心主张：三项可验证的保障

为避免“引入功能却没有可测试结论”的陷阱，我将 Skills 架构的价值浓缩为一个可验证的命题：Skills 将 LLM 系统从“基于文本的单一提示”转变为“版本控制、可审计、可组合的运行时模块”。核心利益源自三项可衡量的保障：

• 情境预算控制：利用渐进披露区分“常驻/激活/执行”情境成本，防止一次性加载
• 执行路径控制：将关键逻辑从自然语言推理迁移到可测试脚本，将模型定位为编排器而非解释器
• 权限边界控制：利用沙盒、网络代理和权限提示，将工具执行限制在可审计、可治理的边界内

这三个“控制”构成我们分析的骨干，我们将深入探讨每个工程模式。

上下文窗口的“公地悲剧”

在 Skills 出现之前，构建复杂 AI 代理面临着“上下文共享悲剧（context commons tragedy）”。当试图将通用模型如 Claude 3.5 Sonnet 转变为领域专家时，传统方法是将所有业务规则、品牌指南、API 文档和错误处理程序塞入一个庞大的系统提示词中。

这种方法论产生了三种严重的技术债务：

• 注意力稀释：随着上下文窗口充满无关信息，模型处理特定指令的精度下降 —— 学术界称之为“中间迷失（Lost in the Middle）”现象。
• 推理成本和延迟：即使处理简单请求，如果系统提示符包含 50 页文档，每次 API 调用都会为这些非活跃知识付费，同时显著增加首个 token 时间（TTFT，Time To First Token）。
• 维护不可持续性：庞大的提示文本块难以进行版本控制，无法进行单元测试，且极易因小幅修改而出现不可预测的“蝴蝶效应”。

2026 年 1 月，Anthropic 工程团队记录显示，仅工具定义在优化前就可能消耗 134K token —— 典型的 GitHub MCP 服务器会增加约 46,000 token，Jira 则消耗约 17,000 token。团队报告称，仅 MCP 工具在编写一行代码前就占用了 72% 的上下文。

动态加载：“闪存”的隐喻

Claude Skills 核心设计理念是将“知识”与“推理”分离开来。如果我们将 LLM 的上下文窗口比作计算机 RAM，传统提示工程试图在启动时将所有数据加载到内存中。相比之下，Claude Skills 更像是可热插拔的外置存储设备（USB 闪存驱动器）。

在这种架构下，代理不必“记住”所有知识，只需要知道自己具备哪些能力。当（只有当）用户触发特定任务时，相关知识模块（技能）才会动态加载到内存中。这种设计使代理能够掌握数千项技能 —— 从“SQL 性能优化”到“法律合规审查” —— 在初始化过程中无需额外上下文资源，从而实现无限的可扩展性潜力。

渐进披露（Progressive Disclosure）：三层加载算法

Claude Skills 通过一种独特的加载算法 —— 渐进披露，实现了高效扩展。这种分层加载策略最大限度减少了 token 消耗，同时最大化模型在特定任务上的性能。

三层账本模型（The Three-Tier Ledger Model）

如果我们将“上下文窗口”概念化为系统账本，每个请求支付三种类型的预算，所有后续优化策略都可以被理解为“在不牺牲目标的情况下减少一种预算类型”：

• 常驻成本：会话启动时持续占据空间的内容，如技能元数据索引和全局约束（对应第一级）
• 激活成本：技能加载时注入的指令体（对应2级）
• 执行成本：运行时进入上下文的运行时构件 —— 工具返回值、文件内容、脚本标准输入输出（对应第3级）

从工程角度看，该账本同时确定了三个因素：

• Token 成本：账本的直接计费项目
• 延迟：常驻/激活费用直接影响 TTFT；执行成本影响整体完成时间和交互节奏
• 确定性：当执行成本主要来自“可测试脚本输出”时，系统行为比“模型实时写入和解释”更稳定。

渐进披露状态机

运行时过程可以形式化为有四个状态的状态机，以澄清“当前在上下文中存在的、可回收的以及污染的来源”：

S0（空闲）：基础系统提示符 + 元数据索引（总共 ~100–500 个 token）
S1（技能激活）：S0 + 选定 SKILL.md 内容（~1K-5K token）
S2（执行中）：S1 + 工具输出、文件读取、脚本结果（变量，可能无界）
S3（总结）：返回 S0/S1，仅保留提炼结果

状态机揭示了两个关键洞见：

• 上下文污染源：主要来源于 S2 大量的中间输出（工具返回、错误、调试日志）
• 污染隔离机制：主会话可以保留在 S0/S1，将试错过程分发给分支的子会话；子会话终止后，只有摘要回填到 S3，避免主上下文膨胀

根据 Anthropic 的工程数据，2026 年 1 月启用工具搜索后，系统实现了 token 开销降低 85% —— 从 7.7 万降至 50+ MCP 工具下的约 870 万。

物理解剖：SKILL.md 规格

作为架构师，理解 Skills 的物理结构至关重要。与封闭数据库记录不同，Claude Skills 采用基于文件系统的设计，本质上支持 Git 版本控制、CI/CD 流水线以及现有 IDE 开发流程。

标准目录结构

data-analysis-pro/           # 根目录，必须与 Skill ID匹配
├── SKILL.md                 # [必选] 核心定义文件
├── README.md                # [可选] 人类可读文档
├── scripts/                 # [建议] 可执行代码库
│   ├── clean_data.py       # Python 清理脚本
│   ├── visualize.R         # R 可视化脚本
│   └── query_db.sh         # Bash 数据库查询包装器
├── templates/              # [建议] 输出模版
│   ├── report_format.md    # 报告结构定义
│   └── email_draft.txt     # Email 草稿模版
└── resources/              # [可选] 静态知识库
    ├── schema.json         # 数据库结构定义
    └── glossary.csv        # 术语表

该结构体现了“关注点分离”：SKILL.md 处理与 LLM 的自然语言交互，scripts/ 处理确定性逻辑计算，resources/ 存储静态知识。

YAML 前置配置

YAML 前置文件作为 Skill 的 API 签名，决定系统如何识别和调用：

---
name: data-analysis-pro
description: Analyzes CSV/Excel datasets using advanced statistical methods. Use when the user asks for "trends", "forecasts", or "data insights".
allowed-tools: Read,Bash,Grep
user-invocable: true
context: fork
agent: plan
---

关键字段定义：

• name（必填）：必须与目录名称完全匹配；仅限小写字母、数字和连字符；最多 64 个字符
• description（必填）：最关键的字段（最多 1024 字符）—— 不仅仅是文档；更是触发逻辑。Claude 对文本进行语义匹配来决定是否加载该 Skill。最佳实践：“当用户请求时使用这项 Skill ……”
• allowed-tools（可选）：在 Skill 激活时限制可调用工具范围，缩小执行表并整合权限请求。如果省略，则不适用约束；标准许可模式遵循 Claude Code 的标准审批流程
• context: fork（高级）：设置为 fork 时，Skill 在独立子代理上下文中运行，防止中间步骤污染主会话

企业团队的生产部署数据显示，正确配置 Skill 可减少 84% 的权限提示，而团队报告生产力提升 8 倍，部署周期加快 25%。

安全治理：双重隔离架构

随着代理获得执行代码和操作文件系统的能力，安全性成为不可妥协的核心关注点。Claude Skills 引入了基于原语的操作系统级沙盒机制，以防止“越狱”或恶意操作。

二维隔离

Claude Code 的沙盒环境（Linux 上的 Bubblewrap，macOS 上的 Seatbelt）实现了二维隔离：

1. 文件系统隔离

默认行为：写权限限制于工作目录和子目录；读权限覆盖大多数机器路径，但排除某些被拒绝的目录；工作目录外的修改需要明确权限，通过允许/拒绝规则进行细化。

该设计在语义上将“读”与“写”解耦：在保持故障排除可观察性的同时，持续的写破坏半径仍局限于工作区内。

2. 网络隔离

Skill 网络请求不能直接穿越主机网卡，所有网络流量都必须经过维护允许列表的专用代理服务器。这一出站限制同样适用于 Skill 发起的脚本和子进程，形成工程闭合边界。

举个例子：“GitHub PR 审核” Skill 只能访问 api.github.com，如果恶意代码试图连接 attacker.com 泄露数据，代理层会立即丢弃请求。

攻击链与控制点

为了将安全控制转化为可审计的治理行动，这里有一个最小威胁模型骨架图：

典型攻击链：诱导决策 → 尝试读取敏感信息 → 尝试窃取 → 尝试持久写入

控制点映射：

1. 通过拒绝规则控制读操作，缩小敏感路径
2. 写控制默认为工作目录；跨目录修改需要权限
3. 通过代理和域限制实现出站控制；新域名触发权限请求
4. 通过 PreToolUse 和 PermissionRequest 钩子实现允许/拒绝/请求策略的行为控制

实际实现：工程团队用 Rust 构建自定义权限钩子，通过允许特定命令模式减少权限提示，同时阻止 shell 注入字符，实现批准操作的零开销执行。

Skill 与 MCP：合作而非竞争

在 Anthropic 生态系统中，模型上下文协议（MCP）和 Skill 代表了两个常被混淆的概念，两者的澄清对架构设计至关重要。

核心区别矩阵

从“系统边界”角度来看，它们的角色可以更严格的定义为边界契约：

• MCP 是工具平面：解决连接、认证、数据访问和可观测性问题 —— 使“工具调用”变得可实现且可治理
• Skill 是流程平面：解决意图映射、步骤编排、异常策略和输出规范 —— 使“工作流”模块可以实现版本控制且具备可审计性

效能：Token 经济学的现实

2026 年 1 月的基准测试显示，token 开销存在显著差异。Twilio 的 MCP 性能测试显示，支持 MCP 的代理平均消耗多出 27.5%，缓存读取量增长了 28.5%，缓存写入量激增了 53.7%。

一个开发团队记录了他们的 MCP token 的爆炸式增长：在 10 多个 MCP 服务器上，每个请求需要约 150 个工具定义，模型甚至在处理用户查询前就消耗了大量上下文。他们采用“代码模式”的解决方案将 token 使用率降低了 60–70%，交互次数从 6–10 次减少到 3–4 次。

相比之下，Skills 的渐进披露确保元数据在激活前每个技能仅消耗约 100 个代币，平台数据显示 Skills 可将代币使用量从每次手动指令的 5,000–10,000 个减少到极低的元数据成本，直到需要时才加载。

合约与失败模式

MCP 提供了工具功能面；Skills 提供流程协调面。为防止异常期间的系统偏离，定义 MCP 调用的返回合约和失败策略，至少涵盖四种常见故障模式：

1. 工具超时：设定超时和重试限制（建议包含回退）;超限触发快速失败和退化/人为干预
2. 工具返回不稳定或模式漂移：验证关键字段结构（如有必要，指定版本）;在漂移模式下，降级为“只读显示原始返回+即时人工确认”。
3. 权限被拒绝：定义清晰的降级路径（例如，只读模式，最小可行结果）;明确提示用户输入“需要人工批准的点”。
4. 数据不可得或不一致：优先返回可解释的错误分类（可重试/不可重试）;如有必要，允许返回“过时但可用”的缓存结果并带有一致性风险警告

企业团队报告称，将 Skills 与 MCP 结合（MCP 服务器收集数据、Skill 进行分析）能够实现最佳效果。Skill 激活频率追踪和错误率监控实现持续优化。

高级代理模式：递归、分叉与自我进化

掌握基础架构后，可以利用 Skills 构建更复杂的代理行为。

上下文分叉：平行宇宙隔离

在处理极其复杂的任务（如“重构整个后端 API”）时，主会话的上下文常常充满数百次尝试、错误和调试信息，导致模型“疲劳”并遗忘初始目标。

context: fork 是解决这个问题的关键功能。其工作流程如下：

• 机制：当 Skill 激活时，Claude 创造了一个临时的、孤立的“平行宇宙”（子代理）
• 流程：子代理在这个隔离环境中完成所有脏工作（运行测试、修复错误、重跑测试）
• 合并：只有最终成功结果（或精炼后的失败报告）返回主会话；丢弃所有中间进程标记
• 应用：类似于 Git 的功能分支工作流 —— 主分支（主会话）保持干净；所有开发噪声仅限于临时分支（子代理）

生产数据显示，子代理能显著减少上下文污染。一项分析发现，分叉上下文使得 token 的探索效率更高，而主会话则保持可读性，避免每回合重复发送垃圾数据。

组合与元技能

更严格的说，Claude 可以在同一会话中按需激活多个 Skills，通过编排形成复合工作流程。是否允许嵌套调用，以及调用链如何受权限和运行时影响，应由实际运行时和权限设置来决定。

示例：构建 software-architect Skill，其指令不直接编写代码，而是：

1. 调用 requirement-analysis Skill 来分析文档
2. 调用 database-design Skill 来生成模式
3. 调用 api-scaffolding Skill 来生成代码框架

这种可组合性使智能体系统能力能够呈现指数级增长，而非线性增长。

自我提升技能：长期记忆

利用文件系统的持久性，可以构建“长期记忆”技能：

情景：代码审查 Skill 机制：

1. Skill 执行代码审查
2. 如果用户拒绝了评论意见（反馈）
3. Skill 会自动调用脚本，并将用户反馈附加到文件 resources/review_guidelines.md 中
4. 下一次执行会读到更新的指南

重要性：实现真正的“在职学习” —— 代理会越来越多的根据团队的使用偏好调整，无需再训练模型。

一个实施前端代码审查模式的团队发现，由于审查频率高，Skill 消耗 token 的速度令人担忧，但自我提升周期不断提升审核质量，形成了良性反馈循环。

企业生产部署：经过实战考验的实战手册

实际生产部署需要超越演示，转向可持续且可治理的系统。以下是基于 2026 年 1 月现场数据的精简企业策略。

每周实施

第 1 周：基础

• 配置所有禁止权限、基于允许列表的权限：仅工作区文件系统、仅需工具的外壳、允许列表的网络域
• 在仓库根目录建立 CLAUDE.md 以获取项目背景
• 对 SIEM 实施全面日志
• 从部署/生产环境进行分段构建/测试

第 2 周：Skill 发展

• 针对投资回报率最高的工作流，培养 2–3 项核心 Skill
• 实现确定性测试：<2 分钟运行时间，TDD 周期（失败 → 通过 → 审查 → 提交）
• 运行多模型交叉验证
• 建立沙盒测试环境

第 3 周：团队规模扩展

• 部署各部门的专业项目
• Skill 版本化：生产环境固定稳定版本，开发环境使用最新版本
• 默认为 private；选择性分享
• 记录每个 Skill 的全面输入/输出

第 4 周：监控与迭代

• 追踪：token 使用率、Skill 激活率、生产力提升、错误率、安全异常
• 围绕会话重置安排高负载使用时间
• 实施持续反馈循环以提升 Skill

量化结果

实施本战术手册报告的团队：

• 目标工作流的生产力提升 8 倍
• 部署周期加快 25%
• 复杂任务准确率达 83%
• 通过确定性测试减少 10–15% 的错误
• 通过渐进披露优化，token 成本降低 60%

一家金融服务公司利用 Skill 构建了全公司范围的知识层，将专业知识组织到四个领域（AI、数据、基础设施、用户界面），实现了团队间专业知识的无缝转移。

战略转折点

Claude Skills 不仅是一项新功能，更是将 AI 代理工程化为生产系统的基础步骤。通过将软件工程成熟的模块化、封装、版本控制和权限管理原则引入生成式 AI，我们终于拥有了构建可维护、可扩展和安全企业级智能代理的完整工具链。

对于每一位技术领导者来说，战略优先级应从完善单一提示词转向构建组织的技能库。这个存储库（嵌入独特的企业流程、知识和工具）将成为 AI 时代最关键的数字资产。

范式已经发生了转变，架构经过了验证，结果可以衡量。问题不再是是否采用上下文工程，而是能多快建立在这方面表现出色的组织能力。

Hi，我是俞凡，一名兼具技术深度与管理视野的技术管理者。曾就职于 Motorola，现任职于 Mavenir，多年带领技术团队，聚焦后端架构与云原生，持续关注 AI 等前沿方向，也关注人的成长，笃信持续学习的力量。在这里，我会分享技术实践与思考。欢迎关注公众号「DeepNoMind」，星标不迷路。也欢迎访问独立站 www.DeepNoMind.com^[1]，一起交流成长。