拆解AI Agent架构：MCP不只是API封装，Skills over MCP值得关注

近九成MCP服务器只是REST API的包装壳

一项针对官方MCP服务器的调查给出了一个颇为尴尬的数字：接近九成的服务器只是对REST API做了一层简单封装。换句话说，大多数开发者只用到了MCP协议能力的冰山一角，而真正能让AI Agent发挥威力的部分，被大量忽略了。

这篇来自YouTube频道Technomi HQ的内容系统地拆解了一个AI Agent究竟由哪些部件构成、每个部件扮演什么角色，并重点介绍了一个容易被忽视的新特性——Skills over MCP。理解这套架构，是从"能跑"到"用好"的关键一步。

大脑、身体、双手与经验：Agent的四个核心部件

要理解Agent，可以把它画成一张图。中心是LLM，也就是大脑——它负责阅读、推理，并决定下一步该做什么。但光有大脑只能写文字，它没法点击按钮、运行代码或打开文件。

于是我们给它配上双手，这就是MCP（Model Context Protocol），一种接入工具和数据的标准方式。再给它经验，也就是Skills，被打包好的、关于如何把一件事做好的指令。最后给它一个身体把所有部件连起来，这就是harness（运行框架）。

harness是模型外围的软件，比如Claude Code，或者你自己构建的Agent应用。它负责运行核心循环：思考（Think）、行动（Act）、观察（Observe），不断重复直到任务完成。当模型请求调用某个工具时，harness实际执行这个工具并把结果喂回给模型。它同时还管理记忆，并设置护栏（guardrails），比如在执行任何有风险的操作前先征求你的批准。

MCP的三种原语：谁来控制是关键

放大看"双手"这部分。使用MCP时，你的应用运行一个客户端，去和MCP服务器对话——服务器可以是GitHub、一个数据库，或是公司内部的API。而每个服务器可以提供三样东西：工具（Tools）、资源（Resources）和提示（Prompts）。

三者的区别在于控制权在谁手里。

Tools：模型自主决定调用

Tools是模型决定去调用的函数，用来执行动作或查询信息。你让Agent记录一个bug，它会自己调用create issue。Tools能改变现实世界的状态，所以它们理应配上护栏，比如运行前先问你一句。

Resources：由应用控制的上下文

Resources是上下文，控制权在应用手里。一个文件、一张数据库schema、一份设计文档，每一个都有自己的地址（类似URL）。它们是用来读取的上下文，而非用来执行的动作，所以应用可以精准地只附加当下需要的内容。

Prompts：由用户发起的模板

Prompts是用户选择的模板，通常以斜杠命令的形式出现。输入/review PR，你就能拿到一个预设好、经过测试的提示词，并自动填入你的pull request信息。

这里有一个常见错误：很多服务器把所有东西都做成了Tool——获取schema是个工具，读文档又是个工具，每个工作流都变成更多工具。结果模型要在几十个工具里挑选，而每一条工具描述都在消耗token。

所以只需要问自己一个问题：谁应该掌握控制权？ 如果由模型决定何时使用，做成Tool；如果由应用或用户作为上下文附加进来，做成Resource；如果由人来发起工作流，做成Prompt。

MCP（Model Context Protocol）是由Anthropic于2024年底提出并开源的协议，旨在为AI模型接入外部工具和数据提供一套统一标准，类似于USB-C在硬件领域的作用。在MCP出现之前，每个AI应用都需要为不同的数据源或工具单独开发集成方案，维护成本极高。MCP通过定义标准化的客户端-服务器通信协议，让任何支持MCP的应用都能复用同一批服务器。服务器可以本地运行（通过stdio通信），也可以远程部署（通过HTTP+SSE通信）。这种架构解耦了"模型能力"和"工具生态"，理论上一个MCP服务器可以同时被Claude、GPT或任何其他支持该协议的Agent框架调用。

Skills：用渐进式披露打包"做事的经验"

接下来是"经验"这部分。一个Skill本质上就是一个文件夹，里面有一个skill.md文件，记录了针对某类任务的步骤、技巧，甚至脚本。

巧妙之处在于渐进式披露（progressive disclosure）。Agent平时只看到每个Skill的一行描述，只有当某个任务确实需要时，才加载完整的指令；更深入的额外文件，也只有在真正用到时才加载。这意味着你可以安装一百个Skill，而平时只有它们简短的描述在占用上下文。

渐进式披露（Progressive Disclosure）是一种源自用户界面设计的原则：将信息按需分层展示，用户只在需要时才获取更深层的细节，避免一次性暴露过多内容导致认知负担。在LLM的语境中，这一原则与"上下文窗口"的物理限制直接挂钩——模型每次推理能处理的token数量有限，任何放进上下文的内容都有代价。Skills的渐进式披露设计正是基于此：将技能目录压缩为一行简介，使得安装大量Skills的边际成本接近于零；只有模型判断当前任务与某个Skill相关时，才触发完整指令的加载。这与RAG（检索增强生成）的按需检索思路异曲同工，区别在于Skills的粒度是"整套操作规范"而非碎片化的文档片段。

Skills over MCP：把"说明书"随产品一起交付

过去这里一直存在一个缺口。MCP服务器交付了工具，却没有附带使用手册——Agent看得到create issue，却不知道你的团队喜欢怎样写issue。而Skills过去只能存在本地文件夹里，靠手动复制，还会慢慢过时。

Skills over MCP正是用来填补这个缺口的。它对应的是SCP-2640提案，并于2026年9月正式定稿。现在，服务器可以通过和工具相同的连接，把自己的Skills一起交付出去。

有意思的是，Skills并不是一个全新的原语，它搭载在Resources之上。一个Skill里的每个文件都是一个Resource，其地址以skill://开头。你的应用调用skills/list，只把名称和描述展示给模型；模型只在任务匹配时才加载完整的Skill，而你的应用可以要求你先批准。这样一来，服务器把说明书随产品一起交付，并在服务器更新时同步更新。

至于当前的落地情况：支持才刚刚开始。在录制时，MCP Inspector和FastAgent已有早期支持，OpenAI的plugins可以把服务器的skills作为快照导入。大多数主流Agent应用尚未跟进。正因如此，现在是提前准备的好时机。

SCP（Skills over Context Protocol）提案编号2640，是MCP协议的扩展规范，由社区讨论并于文中所述时间线完成定稿。"搭载在Resources之上"这一设计选择有其深意：Resources本身已经具备URI寻址、按需加载、应用层权限控制等基础设施，Skills复用这套机制可以避免为协议引入全新的传输层复杂度，同时让现有的MCP客户端只需增量实现skills/list等少数接口即可获得支持。skill://前缀的URI方案则在命名空间上将Skills与普通文件资源区分开来，方便客户端识别并进行差异化处理，例如在展示给用户时单独列出可用技能清单，而非混入通用资源列表中。

完整图景：三种原语缺一不可

把所有部件拼起来：LLM是大脑，harness是身体，MCP给它双手——Tools由模型调用、Resources提供上下文、Prompts由你发起，而Skills提供做事的经验，如今也能由服务器以Resources的形式交付。

核心启示很直接：不要再把一切都塞进Tool。构建能同时用好三种原语的服务器，尤其别忽视那些被大量服务器跳过的Resources——它正是Skills over MCP得以建立的基础。做到这一点，你的Agent才真正准备好迎接下一步的演进。