技能与工具、MCP 和子智能体

摘要

本课程深入探讨了技能（Skills）、工具（Tools）、MCP（模型上下文协议）和子智能体（Subagents）在AI智能体生态系统中的定位与协作关系。MCP负责连接外部系统和数据，工具提供底层能力，技能封装可重复的工作流程，而子智能体实现隔离上下文和并行执行。理解这些组件的差异与协同，有助于构建高效、可扩展的AI应用。

要点

• MCP（模型上下文协议）：连接智能体与外部数据系统（如数据库、Google Drive），提供模型未知的外部上下文
• 工具与技能的区别：工具是底层能力（如锤子、锯子），技能是使用工具完成特定任务的指令（如如何制作书架）
• 子智能体的价值：提供隔离的上下文窗口、细粒度权限控制和并行任务执行能力
• 协同工作模式：MCP引入数据和工具 → 子智能体并行处理 → 技能封装可预测、可重复的工作流程
• 使用场景：技能适用于程序化、可预测的工作流；子智能体仅在全智能体逻辑必要时的专业任务中使用

视频信息：Skills vs Tools, MCP, and Subagents

中文翻译

你可以将技能（Skills）与工具（Tools）、MCP（模型上下文协议）和子智能体（Subagents）结合起来，创建强大的智能体工作流。让我们逐一了解每个组件，看看它们如何协同工作，并学习何时使用什么。一会见。在本节课中，我们将探讨技能如何融入智能体生态系统。面对如此多的不同技术，如 MCP、技能、工具和子智能体，我们要确保理解它们是如何协同工作的。

在你现有的应用程序中，我们可以引入 MCP 服务器来获取我们所需的上下文。利用子智能体来实现它们自己的主线程和并行化，并引入技能来实现那些可重复的工作流。让我们更深入地了解这一点。当我们将技能与模型上下文协议进行比较时，我们要多考虑与外部数据系统的协作，以及引入我们所需的工具和资源。模型上下文协议将我们的智能体或 AI 应用程序与外部系统和数据连接起来。这可能是一个外部数据库，或者来自 Google Drive 的数据。虽然使用的是各种各样的系统，但任何时候你需要模型不知道的外部数据和上下文时，模型上下文协议都非常有帮助。

你拥有的技能可以利用模型上下文协议中的那些底层工具和数据，来教你的智能体如何处理这些数据。你可以将模型上下文协议视为引入我们需要的所有底层工具，而将技能视为一组指令，用于将这些工具组合在一起，以构建可重复的特定工作流，并生成你想要的数据类型。当我们考虑利用外部数据来计算指标、进行研究和计算数据时，所有这些底层工具都可以通过模型上下文协议在外部提供。

当我们稍微思考一下技能与工具的区别时，我喜欢把工具比作更底层一点的东西。你可以想象你有像锤子、锯子和一些钉子这样的工具。而你有一项技能，比如如何制作书架。工具本身是访问系统和为智能体提供完成任务所需能力的底层方式。事实上，工具在底层被用来支持生成技能、读取技能的能力，甚至用于生成执行代码和加载这些技能的文件系统。技能通过专业知识扩展了能力，引入了需要执行的额外文件和脚本，但执行这些底层脚本以及加载这些文件和文件夹的能力是由工具提供的。

有些工具是内置于某些智能体生态系统中的，有些工具我们可以自己编写，还有些工具我们可以通过模型上下文协议加载。工具定义总是存在于上下文窗口中，而技能则是在必要时逐步加载的。当我们思考这些如何协同工作时，技能允许我们创建可预测的工作流，而这些技能可以引入可以像按需工具一样执行的脚本。如果有一个我们在每次对话中都不需要的工具，我们可以仅在需要时通过技能和逐步披露来使用它。

当我们思考子智能体如何融入其中时，让我们首先定义一下我们认为什么是子智能体。我们有一个主智能体，它可以生成或创建子智能体，子智能体可以向父智能体汇报。这些子智能体可以通过像 Claude Code 或 Agent SDK 这样的生态系统创建，或者我们也可以自己制作。当我们思考子智能体提供的价值时，我们更多考虑的是拥有一个具有细粒度权限的隔离上下文，以及并行执行任务。当我们思考这些子智能体可以访问什么时，我们拥有有限的工具权限，我们还可以指定每个子智能体可以访问哪些技能。因此，虽然主智能体可以充当协调者并利用任何必要的技能，但子智能体也可以通过使用特定技能来做同样类型的事情。

子智能体与技能的配合非常好，例如我们可以有一个特定的子智能体，如代码审查员（Code Reviewer），其唯一任务是分析和审查代码库，并利用技能来确切指定你、你的团队或你的公司可能如何执行代码审查。当我们把这一切放在一起时，我们可以提供一个客户洞察分析器（Customer Insight Analyzer）的类比。让我们看看这一切是如何协同工作的。我们有一个被赋予了一组工具的主智能体。这些工具可以由 MCP 服务器提供，我们可以引入执行所需任务所需的数据、资源和工具。为了调度子智能体来分析客户，我们可能会分析客户访谈或客户调查，并在隔离环境中并行执行这些操作，以便更快地获取数据。

当我们思考如何实际分析客户洞察，如何分类反馈、总结发现，如何分析访谈和调查，以及如何确保我们在正确的时间加载正确的工具以可预测的方式完成这些工作时，这就是技能发挥作用的地方。我们在外部引入数据。如果我们需要并行化并在单独的线程和上下文窗口中执行，我们会利用子智能体，并且我们引入技能以一种可预测、可重复和可移植的方式来消费所有这些信息。

总结一下，当我们考虑构建 AI 应用程序时，AI 生态系统中有许多不同的部分。从根本上说，我们有提示词（Prompts），这是对话中最底层的原子单位。提示词是我们与模型交流的底层工具。但是提示词本身在团队和公司之间的扩展性不是很好。为了捆绑这些底层提示词、对话、代码和资产，我们可以利用技能。我们委派任务的子智能体可以使用技能。然后，这些子智能体可以从主智能体那里消费通过模型上下文协议定义的必要工具。

当我们思考这些特定功能旨在解决什么问题时，我们要非常有意地考虑我们如何加载这些信息以及它的最佳用途是什么。当我们把上下文窗口视为一种公共资源时，我们要有意地考虑子智能体何时可以帮助我们最小化进入主上下文窗口的内容，以及 MCP 如何加载必要的数据，而技能如何逐步加载它。当我们谈论一点关于持久性以及我们如何思考将事物通过子智能体提取到长期记忆中时。通过子智能体，我们可以跨越子智能体和父智能体的许多不同会话进行持久化。通过技能，我们可以跨越我们与用户和 AI 应用程序进行的对话进行持久化。

因此，当我们思考每个步骤用在哪里时，我们希望将技能用于程序化、可预测的工作流，而仅在专业任务必要时才将子智能体用于完整的智能体逻辑。在下一节课中，我们将看看 Claude 自带的一些预构建技能。我们将查看这些技能的代码库，深入研究一些 SKILL.md 文件，并讨论一个非常有用的技能，称为技能创建器（Skill Creator），这样我们就不必手动从头开始创建我们所有的技能了。

English Script

You can combine skills with tools, MCP, and subagents to create powerful agentic workflows. Let’s go through each component, see how they work together and learn when to use what. I’ll see you there. In this lesson, we’re going to explore how skills fit in to the agent ecosystem. With so many different technologies, like MCP, skills, tools, and subagents, let’s make sure we understand how they all work together.

In your existing applications, we can bring in MCP servers for the context that we need. leverage subagents for their own main thread and parallelization and bring in skills for those repeatable workflows. Let’s see this in a little more depth. When we compare skills with the model context protocol, we want to think a lot about working with external data systems and bringing in the tools and resources that we need. The model context protocol connects our agent or AI applications with external systems and data. That could be an external database, data from Google Drive. using a various array of systems, but anytime that you need external data and context that the model doesn’t know about, the model context protocol is extremely helpful.

The skills that you have can leverage those underlying tools and data from the model context protocol to teach your agent what to do with that data. Think of the model context protocol as bringing in all of the underlying tooling that we need, and the skill as the set of instructions to put those tools together to build particular workflows that are repeatable and produce the kind of data that you want. As we think about leveraging external data to compute metrics and research and calculate data, all of those underlying tools can be provided externally through the model context protocol.

When we think a little bit about skills versus tools, I like to draw the analogy of tools as a little bit more lower level. You can imagine that you have tools like a hammer and a saw and some nails. And you have a skill, like how to build a bookshelf. The tools themselves are underlying ways of accessing systems and providing agents with the capabilities they need to accomplish a task. In fact, tools are used under the hood to power the ability to generate skills, to read skills, and even to produce a Filesystem for executing code and loading these skills. Skills extend the capabilities with specialized knowledge, bringing in additional files and scripts that need to be executed, but the ability to execute those underlying scripts and load those files and folders is provided by tools.

There are tools that are built in to certain agentic ecosystems, there are tools that we can write on our own, and tools that we can load through the model context protocol. Tool definitions always live in the context window, whereas skills are progressively loaded when necessary. When we think about how these work together, skills allow us to create predictable workflows, and those skills can bring in scripts that can be executed kind of like a tool on demand. If there is a tool that we do not need in every single conversation we can use that only when needed through skills and progressive disclosure.

When we think about how subagents fit into the mix, let’s first define what we think of as a subagent. We have a main agent that can spawn or create subagents that can report back to the parent agent. These subagents can be created through ecosystems like Claude Code or the agent SDK, or we can also make our own. When we think of the value that subagents provide, we think a lot about having an isolated context with fine-grained permissions, as well as executing tasks in parallel. When we think about what these Subagents can access, we have limited tool permissions, and we also can specify what skills each subagent can access. So while the main agent can serve as an orchestrator and can leverage whatever Skills necessary, Subagents can do the same type of idea with making use of particular skills.

Subagents work quite nicely with skills where we can have a particular subagent like a Code Reviewer, whose sole task is to analyze and review a code base and leverages skills which specify exactly how you, your team, or your company might perform a code review. When we put this all together, we can provide an analogy of a Customer Insight Analyzer. Let’s think about how this all works together. We have a main agent that is given a set of tools. Those tools could be provided from MCP servers we can bring in the data, the resources, the tools necessary to perform the tasks needed. For dispatching subagents to analyze customers, we might analyze interviews from customers or surveys from customers, do those in isolation and parallelize them to get data back even faster.

When we think about how to actually analyze insights from customers, how to categorize feedback, summarize findings, how to analyze interviews and surveys, and how to make sure we do those in a predictable fashion with the right tools loaded at the right time, that’s where skills come into play. We bring in data externally. We leverage subagents if we need to parallelize and execute in a separate thread and context window, and we bring in skills to consume all of this information in a predictable, repeatable, and portable fashion.

To summarize this, there are many different pieces in the AI ecosystem when we think about building AI applications. Fundamentally, we have prompts, the underlying most atomic unit in a conversation. Prompts are the underlying tool for us to communicate with models. But prompts themselves don’t scale very well across teams and companies. To bundle these underlying prompts and conversations and code and assets, we can leverage skills. Subagents that we have tasks delegated to can make use of skills. Those subagents can then consume tools necessary from a main agent that are defined through the model context protocol.

As we think about what these particular features aim to solve, we want to be really intentional about how we’re loading this information and what this is best used for. When we think about the context window as a public good, we want to be intentional about when subagents can help us minimize what goes in the main context window and how MCP can load the data necessary and skills can load it progressively. When we talk a little bit about the persistence and how we can think about drawing things into a longer-term memory. With subagents, we can persist across many different sessions from the subagent and the parent agent. With skills, we can persist across conversations that we have with the user and the AI application.

So as we think about where each of these steps are used, we want to use skills for procedural, predictable workflows and subagents for full agentic logic only when necessary for specialized tasks. In the next lesson, we’ll take a look at some of the pre-built skills that come with Claude. We’ll take a look at the repository for these skills, dive deep into some of the SKILL.md files and talk about a very useful skill called the skill creator, so that we don’t have to manually create all of our skills from scratch.