克劳德技能和子代理：逃离即时工程仓鼠轮|走向数据科学
作者：Ruben Broekx
这篇文章反映了截至 2026 年 2 月 Claude Skills、MCP 和子代理的状态。人工智能发展很快，因此当您阅读本文时，一些细节可能已经过时。然而，这篇文章所关注的概念是永恒的。
如果您已经使用法学硕士进行了一段时间的构建，那么您可能已经一遍又一遍地经历过这个循环：您花时间精心设计一个出色的提示，从而获得出色的结果，然后几天后您再次需要相同的行为，因此您再次从头开始提示。经过几次重复后，您可能会意识到效率低下，因此您要将提示模板存储在某处，以便以后可以检索它，但即使如此，您也需要找到提示，将其粘贴进去，并针对此特定对话进行调整。这太乏味了。
这就是我所说的提示工程仓鼠轮。这是一个从根本上被破坏的工作流程。
克劳德技能是 Anthropic 对这个“可重复使用的提示”问题的答案，还有更多。除了让您免于重复提示之外，它们还引入了一种根本不同的方法来进行上下文管理、代币经济学和人工智能驱动的开发工作流程的架构。
在这篇文章中，我将解析技能和子代理的实际含义、它们与传统 MCP 有何不同，以及技能/MCP/子代理组合的发展方向。
什么是技能？
技能的核心是可重复使用的指令集，像克劳德这样的人工智能代理可以在与对话相关时自动访问这些指令集。你写一个技能.md包含一些元数据和指令正文的文件，将其放入.克劳德/技能/目录，克劳德从那里获取它。
他们的样子
最简单的形式是，技能是一个带有名称、描述和指令正文的 Markdown 文件，如下所示：
---名称：<技能名称>描述：<简短技能描述>---<技能详情>他们的优势
技能的主要优势在于自动调用。当开始新对话时，代理仅读取每个技能的名称和描述，以节省令牌。当它确定某项技能相关时，它会加载主体。如果正文引用其他文件或文件夹，代理也会读取这些文件或文件夹，但仅当它决定需要它们时才读取。本质上，技能是延迟加载的上下文。代理不会预先使用完整的指令集。它逐步向自身披露信息，仅提取当前步骤所需的信息。
这种渐进式披露跨越三个层面，每个层面都有自己的背景预算：
- 元数据（启动时加载）：技能名称（最多 64 个字符）和描述（最多 1,024 个字符）。每个技能的成本大约为 100 个代币，即使注册了数百个技能，开销也可以忽略不计。
- 技能主体（调用时加载）：里面有完整的指令集
技能.md，最多约 5,000 个代币。仅当代理确定技能相关时，才会进入上下文窗口。 - 参考文件（按需加载）：技能目录中的其他 Markdown 文件、文件夹或脚本。这里实际上没有限制，只有当指令引用它们并且当前任务需要时，代理才按需读取这些内容。
洞察力：技能是可重用、延迟加载和自动调用的指令集，它们使用跨三个级别的渐进公开：元数据、正文和引用文件。这样可以防止将所有内容转储到上下文窗口中，从而最大限度地减少前期成本（看看你，MCP ð）。
代币经济学的问题
成本因素
这不是什么秘密；代理的上下文窗口空间不是免费的，填充它会产生复合成本。上下文窗口中的每个令牌都会以三种方式消耗您的费用：
- 实际费用：显而易见的是，您要为每个代币付费。这可以直接通过 API 使用来实现，也可以通过使用限制来间接实现。
- 延迟：您还付出了时间的代价，因为更多的输入令牌意味着更慢的响应。不能很好地随上下文窗口的长度扩展的东西（~注意机制）。
- 质量：最后，由于上下文窗口过长，质量也会下降。当法学硕士的上下文中充斥着不相关的信息时，法学硕士的表现显然会更差。
MCP 的昂贵开销
让我们通过快速的粗略计算来正确看待这一点。我首选的 MCP 编程选择是：
- AWS用于基础设施部署。三台服务器（
AWS-MCP,aws-官方,AWS 文档）合计产生约 8,500 个代币（13 种工具）的成本。 - 背景7用于文档。元数据约为 750 个令牌（2 个工具）。
- 菲格玛将设计引入前端开发。元数据约为 500 个令牌（2 个工具）。
- GitHub用于在其他存储库中搜索代码。元数据约为 2,000 个令牌（26 个工具）。
- 线性用于项目管理。元数据约为 3,250 个令牌（33 个工具）。
- 瑟琳娜用于代码搜索。元数据约为 4,500 个令牌（26 个工具）。
- 哨兵用于错误跟踪。元数据约为 12,500 个令牌（22 个工具）。
这总共大约是约 32,000 个代币工具元数据，加载到每一条消息，无论您是否正在与该工具交互。
用一个美元数字来表示：Claude Opus 4.6 每百万输入代币收费 5 美元。闲置 MCP 元数据的 32K 令牌添加每条消息 0.16 美元你发送。这听起来很小，直到您意识到即使是简单的 5 条消息对话也已经增加了 0.8 美元的纯开销。大多数开发人员不会只发送 5 条消息；还会发送 5 条消息。添加一些简短的说明和背景收集问题，您很快就会收到 10 条（如果不是 100 条）消息。假设您在 20 天的工作月内平均每天发送 50 条消息，即每天 8 美元，~$160/月* 在纯开销，仅用于上下文中的工具描述。这还没有考虑延迟和质量影响。
*一个小星号：大多数模型对缓存输入令牌的收费要低得多（90% 折扣）。这个星号的一个星号是，其中一些在启用缓存时会收取额外费用，并且它们并不总是默认启用 (API) 缓存（咳克洛德咳嗽）。
具有成本效益的技能方法
技能的加载模式从根本上改变了所有三个成本因素。一开始，代理只能看到每个技能的名称和简短描述，每个技能大约有 100 个令牌。像这样，我可以注册 300 个技能，并且仍然比我的 MCP 设置消耗更少的代币。完整的指令主体（约 5,000 个令牌）仅在代理认为相关时才加载，引用的文件仅在当前步骤需要时才加载。
在实践中，典型的对话可能会调用一种或两种技能，而其余的技能对上下文窗口来说仍然不可见。这就是关键的区别：MCP 成本与数量成正比已注册工具（跨所有服务器），而技能成本则与实际使用情况更加密切相关。
洞察力：MCP 是“渴望的”，会预先加载所有工具元数据，无论是否使用。技能是“懒惰的”，并且仅在相关时才逐步加载上下文。这种差异对于成本、延迟和输出质量都很重要。
等等，这有误导性吗？技能和MCP是完全不同的两个东西！
如果上面的内容看起来像是技能是新的、更好的 MCP，那么请允许我纠正这个框架。目的是放大其加载模式及其对代币消费的影响。从功能上来说，它们有很大不同。
MCP（模型上下文协议）是一种开放标准，使任何 LLM 都能够与外部应用程序交互。在 MCP 之前，连接中号模型到氮所需工具中号*中号定制集成。MCP 将其折叠为中号+中号：每个模型实现一次协议，每个工具公开一次，并且它们都可以互操作。这是一个简单的基础设施变革，但却真正强大（难怪它席卷了世界）。
另一方面，技能在某种程度上是“美化的提示”，我的意思是以尽可能最好的方式。他们为代理提供有关如何处理任务、遵循哪些约定、何时使用哪种工具以及如何构建其输出的专业知识和指导。它们是可重用的指令集，在相关时按需获取，仅此而已。
洞察力：MCP 赋予代理能力（“什么”）。技能赋予它专业知识（“如何”），因此它们是互补的。
下面是一个具体的例子。假设您将 GitHub 的 MCP 服务器连接到您的代理。MCP 使代理能够创建拉取请求、列出问题和搜索存储库。但它并没有告诉代理，例如，您的团队如何构建 PR，您始终包含测试部分，您按更改类型进行标记，您在标题中引用线性票证。这就是技能的作用。MCP 提供工具，技能提供剧本。
因此，当我早些时候表明技能比 MCP 更有效地加载上下文时，真正的要点不是“使用技能而不是 MCP”，而是“延迟加载作为一种模式起作用。因此，值得一问的是：为什么 MCP 工具访问也不能延迟加载？这就是子代理发挥作用的地方。
子代理：两全其美
子代理是专门的儿童特工具有自己独立的上下文窗口和连接的工具。有两个属性使它们变得强大：
- 孤立的上下文：子代理从一个干净的上下文窗口开始，预加载了自己的系统提示符以及分配给它的工具。它读取、处理和生成的所有内容都保留在自己的上下文中，主代理只能看到最终结果。
- 隔离工具：每个子代理都可以配备自己的一套 MCP 服务器和技能。主代理不需要了解（或支付）其从未直接使用的工具。
一旦子代理完成其任务，其整个上下文就会被丢弃。工具元数据、中间推理、API 响应：全部消失了。只有结果流回主代理。这实际上是一件很棒的事情。我们不仅可以避免不必要的工具元数据使主代理的上下文膨胀，还可以防止不必要的推理标记污染上下文。作为一个说明性示例，想象一个研究图书馆 API 的子代理。它可能会搜索多个文档源，阅读数十页，并在找到正确答案之前尝试多个查询。您仍然需要为子代理自己的令牌使用付费，但是一旦子代理完成，所有中间工作、死胡同、不相关的页面、搜索查询都会被丢弃。主要好处是，这些内容都不会融入主要代理的上下文中，因此对话中的每条后续消息都保持干净且廉价。
这意味着您可以设计设置，以便只能通过特定的子代理访问 MCP 服务器，而根本不会加载到主代理上。主代理不是在每条消息中携带约 32,000 个工具元数据标记，而是携带几乎为零。当它需要打开拉取请求时，它会启动 GitHub 子代理、创建 PR 并返回链接。类似于延迟加载技能上下文, 子代理是延迟加载的工人：主代理知道它可以呼叫哪些专家，并且仅在任务需要时才启动一名专家。
一个实际的例子
让我们让这一点变得切实可行。我每天使用的一个工作流程是“功能分支总结”，它可以自动完成我的开发周期中非常繁琐的部分：打开拉取请求。以下是技能、MCP 和子代理如何一起发挥作用。
当我和主代理完成编码工作后，我要求它完成功能分支。主代理本身不处理这个问题；它将整个公关工作流程委托给专门的子代理。该子代理配备了 GitHub MCP 服务器和变更报告定义我的团队如何构建 PR 的技能。其技能.md看起来大致是这样的：
---名称：变更报告描述：在为 PR 生成变更报告时使用。定义团队的 PR 结构、分类规则和格式惯例。---1. 确保没有任何暂存更改，否则请报告给主要代理人2. 运行 `git diff dev...HEAD --stat` 和 `git log dev..HEAD --oneline`收集此功能分支上的所有更改。3. 分析差异并按类型对最关键的变化进行分类（新功能、重构、错误修复或配置更改）。4. 按照模板生成结构化变更报告在 `pr-template.md` 中。5. 通过 GitHub MCP 打开 PR，填充标题和正文生成的报告。6. 用 PR 链接回答。的pr-模板.md同一目录中的文件定义了我团队的 PR 结构：摘要、更改细分和测试说明部分。这是渐进披露的第 3 级：子代理仅在步骤 4 指示时才读取它。
这就是此设置发挥作用的原因。该技能提供了有关我的团队如何报告变更的专业知识，GitHub MCP 提供了实际创建 PR 的功能，子代理提供了执行所有这些工作的上下文边界。另一方面，主代理仅调用子代理，等待其完成，然后收到确认信息或出现问题的消息。
洞察力：技能、MCP 和子代理协调工作。技能提供专业知识和指导，MCP 提供能力，子代理提供上下文边界（保持主代理的上下文干净）。
更大的图景
在法学硕士的早期，竞争的焦点是更好的模型：更少的幻觉、更敏锐的推理、更多的创造性产出。这场竞赛还没有完全停止，但重心肯定已经转移了。MCP 和 Claude Code 是真正的革命性的。老实说，将 Claude Sonnet 从 3.5 升级到 3.7 并不是。我们今天所获得的增量模型改进远不如我们围绕它们构建的基础设施重要。技能、子代理和多代理编排都是这一转变的一部分：从“我们如何使模型变得更智能”到“我们如何从现有的东西中获得最大价值”。
洞察力：人工智能开发的价值已经从更好的模型转向更好的基础设施。技能、子代理和多代理编排不仅仅是开发人员体验的改进；它们是使代理人工智能在经济上和规模上可行的架构。
我们今天在哪里
技能通过将最佳提示转化为可重复使用、自动调用的指令集来解决提示工程仓鼠轮的问题。子代理通过将工具访问和中间推理隔离给专门的工作人员来解决上下文膨胀问题。它们共同使您可以一次将您的专业知识编纂成文，并自动将其应用到未来的每次互动中。这就是遵循实践现状的工程团队已经通过文档、风格指南和操作手册所做的事情。技能和子代理只是使这些工件变得机器可读。
子代理模式还解锁了多代理并行性。您可以同时启动多个子代理，让它们独立工作并收集结果，而不是让一个代理按顺序执行任务。人类自己的多智能体研究系统已经这样做了：Claude Opus 4.6 进行编排，而 Claude Sonnet 4.6 子代理并行执行。这自然会导致异构模型路由，其中昂贵的前沿模型进行编排和计划，而更小、更便宜的模型则负责执行。协调者推理，工人执行。这可以显着降低成本，同时保持输出质量。
这里有一个重要的警告。并行性适用的场合读任务，变得更加困难写涉及共享状态的任务。例如，假设您正在并行启动后端和前端子代理。后端代理重构 API 端点，而前端代理根据更改之前拍摄的快照生成调用旧端点的代码。单独来看，这两种因素都没有错误，但它们一起产生了不一致的结果。这是一个典型的并发问题，来自不久的将来的人工智能工作流程，迄今为止仍然是一个悬而未决的问题。
前进的方向
我预计技能构成会变得更加复杂。如今，技能相对平坦：带有可选参考的 Markdown 文件。但该架构自然支持引用其他技能的分层技能，从而创建类似于专业知识的继承层次结构的东西。考虑通过特定于语言的变体扩展的基本“代码审查”技能，并通过特定于团队的约定进一步扩展。
如今，大多数多代理系统都是严格分层的：主代理委托给子代理，子代理完成并控制返回。目前，子代理之间还没有太多的点对点协作。Anthropic 最近推出Opus 4.6 的“代理团队”功能是朝着这个目标迈出的早期一步，允许多个代理直接协调，而不是通过协调器路由所有内容。在协议方面，Google 的 A2A（代理到代理协议）可以跨提供商标准化这种模式；MCP 处理代理到工具的通信，A2A 将处理代理到代理的通信。也就是说，与 MCP 的爆炸性增长相比，A2A 的采用速度缓慢。值得一看的，还不是值得下注的。
代理将成为新职能
这里出现了一个更广泛的抽象概念，值得退后一步来欣赏。安德烈·卡帕蒂 (Andrej Karpathy) 著名的推文– 最热门的新编程语言是英语 –捕捉到了我们如何与法学硕士互动的真实情况。但技能和子代理将这种抽象进一步提升了一个层次：代理正在成为新的职能。
子代理是一个独立的工作单元：它接受输入（任务描述），具有自己的内部状态（上下文窗口），使用特定工具（MCP 服务器），遵循特定指令（技能），并返回输出。它可以从多个地方调用，可重用，并且可组合。这是一个函数。主代理成为执行线程：编排、分支、委托和综合来自专门工作人员的结果。
除了类比之外，它还可以具有与软件工程中的函数相同的实际含义。隔离限制了代理发生故障时的影响范围，而不是破坏整个系统，并且可以通过 try- except 机制捕获故障。专业化意味着每个代理都可以针对其特定任务进行优化。可组合性意味着您可以从简单、可测试的部分构建日益复杂的工作流程。可观察性自然也就随之而来。由于每个代理都是一个具有清晰输入和输出的离散单元，因此可以跟踪– 为什么系统执行 X –变成检查调用堆栈而不是盯着 200K 令牌上下文转储。
结论
从表面上看，技能看起来像是简单的“可重复使用的提示”，但它们实际上代表了对人工智能工具中一些最困难问题的深思熟虑的答案：上下文管理、令牌效率以及原始能力和领域专业知识之间的差距。
如果您还没有尝试过技能，请从小处开始。选择您最常重复的提示模式，将其提取到技能.md，看看它如何改变您的工作流程。点击后，采取下一步：确定哪些 MCP 工具不需要在您的主代理上运行，或者哪些子流程需要在找到答案后使用的大量推理，并将其范围改为专用子代理。当每个代理只携带其实际需要的内容时，您会惊讶地发现您的设置变得多么干净。
这篇文章的主要见解
- 技能是可重用、延迟加载和自动调用的指令集，它们使用跨三个级别的渐进公开：元数据、正文和引用文件。这样可以防止将所有内容转储到上下文窗口中，从而最大限度地减少前期成本（看看你，MCP ð）。
- MCP 是“渴望的”，会预先加载所有工具元数据，无论是否使用。技能是“懒惰的”，并且仅在相关时才逐步加载上下文。这种差异对于成本、延迟和输出质量都很重要。
- MCP 赋予代理能力（“什么”）。技能赋予它专业知识（“如何”），因此它们是互补的。
- 技能、MCP 和子代理协调工作。技能提供专业知识和指导，MCP 提供能力，子代理提供上下文边界（保持主代理的上下文干净）。
- 人工智能开发的价值已经从更好的模型转向更好的基础设施。技能、子代理和多代理编排不仅仅是开发人员体验的改进；它们是使代理人工智能在经济上和规模上可行的架构。
最终见解：提示工程仓鼠轮是可选的。是时候下台了。