Agent Skills 与 MCP智能体能力扩展的两种范式引言MCP 之后我们还需要什么在第十章中我们深入探讨了 MCPModel Context Protocol如何通过标准化协议解决智能体与外部工具的连接问题。你已经学会了如何让智能体通过 MCP 访问数据库、文件系统、API 服务等各种资源。让我们回顾一个典型的 MCP 使用场景from hello_agents import ReActAgent, HelloAgentsLLMfrom hello_agents.tools import MCPToolllm HelloAgentsLLM()agent ReActAgent(name“数据分析助手”, llmllm)连接到数据库 MCP 服务器db_mcp MCPTool(server_command[“python”, “database_mcp_server.py”])agent.add_tool(db_mcp)智能体现在可以访问数据库了response agent.run(“查询员工表中薪资最高的前10名员工”)这段代码工作得很好智能体成功连接到了数据库。但当你尝试处理更复杂的任务时会发现一些微妙的问题一个更复杂的需求response agent.run(“”分析公司内部谁的话语权最高需要综合考虑管理层级和下属数量薪资水平和涨薪幅度任职时长和稳定性跨部门影响力“”)这个任务需要执行多次数据库查询每次查询的结果会影响下一次查询的策略。更关键的是它需要智能体具备领域知识知道如何衡量话语权知道应该从哪些维度分析数据知道如何组合多个查询结果得出结论。此时你会遇到两个根本性的问题第一个问题是上下文爆炸。为了让智能体能够灵活查询数据库MCP 服务器通常会暴露数十甚至上百个工具不同的表、不同的查询方法。这些工具的完整 JSON Schema 在连接建立时就会被加载到系统提示词中可能占用数万个 token。据社区开发者反馈仅加载一个 Playwright MCP 服务器就会占用 200k 上下文窗口的 8%这在多轮对话中会迅速累积导致成本飙升和推理能力下降。第二个问题是能力鸿沟。MCP 解决了能够连接的问题但没有解决知道如何使用的问题。拥有数据库连接能力不等于智能体知道如何编写高效且安全的 SQL能够访问文件系统不意味着它理解特定项目的代码结构和开发规范。这就像给一个新手程序员开通了所有系统的访问权限但没有提供操作手册和最佳实践。这正是Agent Skills要解决的核心问题。2025年初Anthropic 在推出 MCP 之后进一步提出了 Agent Skills 的概念引发了业界的广泛关注。有开发者评论说“Skills 和 MCP 是两种东西Skills 是领域知识告诉模型该如何做本质上是高级 Prompt而 MCP 对接外部工具和数据。” 也有人认为“从 Function Call 到 Tool Call 到 MCP 到 Skills核心大差不差就是工程实践和表现形式的优化演进。”那么Agent Skills 到底是什么它与 MCP 有何本质区别两者是竞争关系还是互补关系本章将深入探讨这些问题。什么是 Agent Skills核心设计理念Agent Skills 是一种标准化的程序性知识封装格式。如果说 MCP 为智能体提供了手来操作工具那么 Skills 就提供了操作手册或SOP标准作业程序教导智能体如何正确使用这些工具。这种设计理念源于一个简单但深刻的洞察连接性Connectivity与能力Capability应该分离。MCP 专注于前者Skills 专注于后者。这种职责分离带来了清晰的架构优势MCP 的职责提供标准化的访问接口让智能体能够够得着外部世界的数据和工具Skills 的职责提供领域专业知识告诉智能体在特定场景下如何组合使用这些工具用一个类比来理解MCP 像是 USB 接口或驱动程序它定义了设备如何连接而 Skills 像是软件应用程序它定义了如何使用这些连接的设备来完成具体任务。你可以拥有一个功能完善的打印机驱动MCP但如果没有告诉你如何在 Word 里设置页边距和双面打印Skill你仍然无法高效地完成打印任务。渐进式披露破解上下文困境Agent Skills 最核心的创新是渐进式披露Progressive Disclosure机制。这种机制将技能信息分为三个层次智能体按需逐步加载既确保必要时不遗漏细节又避免一次性将过多内容塞入上下文窗口。图 1 Agent Skills 渐进式披露三层架构第一层元数据Metadata在 Skills 的设计中每个技能都存放在一个独立的文件夹中核心是一个名为 SKILL.md 的 Markdown 文件。这个文件必须以 YAML 格式的 Frontmatter 开头定义技能的基本信息。当智能体启动时它会扫描所有已安装的技能文件夹仅读取每个 SKILL.md 的 Frontmatter 部分将这些元数据加载到系统提示词中。根据实测数据每个技能的元数据仅消耗约100 个 token。即使你安装了 50 个技能初始的上下文消耗也只有约 5,000 个 token。这与 MCP 的工作方式形成了鲜明对比。在典型的 MCP 实现中当客户端连接到一个服务器时通常会通过 tools/list 请求获取所有可用工具的完整 JSON Schema可能立即消耗数万个 token。第二层技能主体Instructions当智能体通过分析用户请求判断某个技能与当前任务高度相关时它会进入第二层加载。此时智能体会读取该技能的完整 SKILL.md 文件内容将详细的指令、注意事项、示例等加载到上下文中。此时智能体获得了完成任务所需的全部上下文数据库结构、查询模式、注意事项等。这部分内容的 token 消耗取决于指令的复杂度通常在 1,000 到 5,000 个 token 之间。第三层附加资源Scripts References对于更复杂的技能SKILL.md 可以引用同一文件夹下的其他文件脚本、配置文件、参考文档等。智能体仅在需要时才加载这些资源。例如一个 PDF 处理技能的文件结构可能是skills/pdf-processing/├── SKILL.md # 主技能文件├── parse_pdf.py # PDF 解析脚本├── forms.md # 表单填写指南仅在填表任务时加载└── templates/ # PDF 模板文件├── invoice.pdf└── report.pdf在 SKILL.md 中可以这样引用附加资源当需要执行 PDF 解析时智能体会运行 parse_pdf.py 脚本当遇到表单填写任务时才会加载 forms.md 了解详细步骤模板文件只在需要生成特定格式文档时访问这种设计有两个关键优势无限的知识容量通过脚本和外部文件技能可以携带远超上下文限制的知识。例如一个数据分析技能可以附带一个 1GB 的数据文件和一个查询脚本智能体通过执行脚本来访问数据而无需将整个数据集加载到上下文中。确定性执行复杂的计算、数据转换、格式解析等任务交给代码执行避免了 LLM 生成过程中的不确定性和幻觉问题。渐进式披露的效果从 16k 到 500 Token社区开发者分享的实践案例充分证明了渐进式披露的威力。在一个真实场景中传统 MCP 方式直接连接一个包含大量工具定义的 MCP 服务器初始加载消耗16,000 个 tokenSkills 包装后创建一个简单的 Skill 作为网关仅在 Frontmatter 中描述功能初始消耗仅500 个 token当智能体确定需要使用该技能时才会加载详细指令并按需调用底层的 MCP 工具。这种架构不仅大幅降低了初始成本还使得对话过程中的上下文管理更加精准和高效。Agent Skills vs MCP本质区别与协作关系现在我们可以系统地比较这两种技术的本质区别了。图 2 MCP 与 Agent Skills 设计哲学对比从工程视角理解差异让我们通过一个具体的例子来理解这种差异。假设你要构建一个智能体来帮助团队进行代码审查MCP 的职责MCP 提供对 GitHub 的标准化访问github_mcp MCPTool(server_command[“npx”, “-y”, “modelcontextprotocol/server-github”])MCP 暴露的工具简化示例- list_pull_requests(repo, state)- get_pull_request_details(pr_number)- list_pr_comments(pr_number)- create_pr_comment(pr_number, body)- get_file_content(repo, path, ref)- list_pr_files(pr_number)MCP 让智能体能够访问 GitHub能够调用这些 API。但它不知道应该做什么。Skills 的职责name: code-review-workflowdescription: 执行标准的代码审查流程包括检查代码风格、安全问题、测试覆盖率等代码审查工作流审查清单当执行代码审查时按以下步骤进行获取 PR 信息调用get_pull_request_details了解变更背景分析变更文件调用list_pr_files获取文件列表逐文件审查对于.py文件检查是否符合 PEP 8是否有明显的性能问题对于.js/.ts文件检查是否有未处理的 Promise是否使用了废弃的 API对于测试文件验证是否覆盖了新增的代码路径安全检查是否硬编码了敏感信息密钥、密码是否有 SQL 注入或 XSS 风险提供反馈严重问题使用create_pr_comment直接评论建议改进在总结中提出公司特定规范所有数据库查询必须使用参数化查询API 端点必须有权限验证装饰器新功能必须附带单元测试覆盖率 80%示例评论模板严重问题⚠️ 安全风险第 45 行直接拼接 SQL 字符串存在注入风险。建议改用参数化查询cursor.execute(SELECT * FROM users WHERE id ?, (user_id,))Skills 告诉智能体应该做什么、如何组织审查流程、需要关注哪些公司特定的规范。它是领域知识和最佳实践的容器。上下文管理策略的本质差异图 3 MCP 急切加载 vs Skills 惰性加载对比互补而非竞争Skills MCP 的混合架构理解了两者的差异后我们会发现Skills 和 MCP 不是竞争关系而是互补关系。最佳实践是将两者结合形成分层架构图 4 Skills MCP 混合架构设计典型工作流用户问“分析公司内部谁的话语权最高”Skills 层识别这是一个数据分析任务加载 mysql-employees-analysis 技能Skills 层根据技能指令将任务分解为子步骤查询管理关系、薪资对比、任职时长等MCP 层执行具体的 SQL 查询返回结果Skills 层根据技能中的领域知识解读数据并生成综合分析返回结构化的答案给用户这种架构的优势是关注点分离MCP 专注于能力Skills 专注于智慧成本优化渐进式加载大幅降低 token 消耗可维护性业务逻辑Skills与基础设施MCP解耦复用性同一个 MCP 服务器可以被多个 Skills 使用技术实现如何创建和使用 SkillsSKILL.md 规范详解让我们深入了解 SKILL.md 文件的标准结构 必需字段 name: skill-name技能的唯一标识符使用 kebab-case 命名description: 简洁但精确的描述说明这个技能做什么什么时候应该使用它它的核心价值是什么注意description 是智能体选择技能的唯一依据必须写清楚 可选字段 version: 1.0.0语义化版本号allowed_tools: [tool1, tool2]此技能可以调用的工具列表白名单required_context: [context_item1]此技能需要的上下文信息license: MIT许可协议author: Your Name emailexample.com作者信息tags: [database, analysis, sql]便于分类和搜索的标签技能标题概述对技能的详细介绍包括使用场景、技术背景等前置条件使用此技能需要的环境配置、依赖项等工作流程详细的步骤说明告诉智能体如何执行任务最佳实践经验总结、注意事项、常见陷阱等示例具体的使用案例帮助智能体理解故障排查常见问题和解决方案编写高质量 Skills 的原则根据 Anthropic 官方文档和社区最佳实践编写有效的 Skills 需要遵循以下原则精准的 Descriptiondescription 是智能体决策的关键。它应该精确定义适用范围避免模糊的描述如帮助处理数据包含触发关键词让智能体能够匹配用户意图说明独特价值与其他技能区分开来❌不好的 descriptiondescription: 处理数据库查询✅好的 descriptiondescription: 将中文业务问题转换为 SQL 查询并分析 MySQL employees 示例数据库。适用于员工信息查询、薪资统计、部门分析、职位变动历史等场景。当用户询问关于员工、薪资、部门的数据时使用此技能。模块化与单一职责一个 Skill 应该专注于一个明确的领域或任务类型。如果一个 Skill 试图做太多事情会导致Description 过于宽泛匹配精度下降指令内容过长浪费上下文难以维护和更新建议与其创建一个通用数据分析技能不如创建多个专门的技能mysql-employees-analysis专门分析 employees 数据库sales-data-analysis专门分析销售数据user-behavior-analysis专门分析用户行为数据确定性优先原则对于复杂的、需要精确执行的任务优先使用脚本而不是依赖 LLM 生成。例如在数据导出场景中与其让 LLM 生成 Excel 二进制内容容易出错不如编写一个专门的脚本来处理这个任务SKILL.md 中只需要指导智能体何时调用这个脚本即可。渐进式披露策略合理利用三层结构将信息按重要性和使用频率分层SKILL.md 主体放置核心工作流、常用模式附加文档如 advanced.md放置高级用法、边缘情况数据文件放置大型参考数据通过脚本按需查询实践案例MySQL 员工分析 Skill 详解让我们通过 Anthropic 社区的一个真实案例了解 Agent Skills 的具体应用。这个技能用于分析 MySQL 官方的 employees 示例数据库。技能文件结构skills/mysql-employees-analysis/├── SKILL.md # 主技能文件包含元数据和详细指令└── db_schema.sql # 数据库结构参考可选按需加载SKILL.md 核心内容示例这个技能的 Frontmatter元数据层name: mysql-employees-analysisdescription: 将中文业务问题转换为 SQL 查询并分析 MySQL employees 示例数据库。适用于员工信息查询如工号12345的员工信息、薪资统计如平均薪资最高的部门、部门分析如各部门人数分布、职位变动历史如某员工的晋升路径等场景。version: 1.0.0allowed_tools: [execute_sql]tags: [database, mysql, sql, employees, analysis]MySQL 员工数据库分析技能概述这个技能专门用于分析 MySQL 官方提供的employees示例数据库。该数据库包含约 300,000 名虚拟员工的记录涵盖 1985-2000 年的数据。核心能力理解中文自然语言的业务问题转换为高效的 SQL 查询执行查询并解读结果提供业务洞察和数据解读数据库结构核心表结构表名说明关键字段employees员工基本信息emp_no, birth_date, first_name, last_name, gender, hire_datesalaries薪资历史emp_no, salary, from_date, to_datetitles职位历史emp_no, title, from_date, to_datedept_emp员工部门关系emp_no, dept_no, from_date, to_datedept_manager部门经理emp_no, dept_no, from_date, to_datedepartments部门信息dept_no, dept_name关键约定⚠️重要to_date 9999-01-01表示当前有效的记录。查询当前状态时如现任员工、当前薪资必须加此过滤条件。完整的表结构参见db_schema.sql工作流程第一步理解需求仔细分析用户的中文描述识别查询目标要查什么数据员工、薪资、部门…筛选条件有什么限制特定部门、时间范围、薪资区间…聚合维度需要统计吗平均值、总数、排名…时间范围是历史数据还是当前状态第二步构建 SQL根据需求选择合适的查询模式见下方常见查询模式。编写原则使用明确的表别名如efor employeesJOIN 时优先使用主键/外键注意日期过滤特别是to_date合理使用索引字段大结果集要加 LIMIT第三步执行查询调用execute_sql工具执行构建好的 SQL。# 示例调用智能体会自动转换为工具调用resultexecute_sql(querySELECT ...)### 第四步解读结果将查询结果转化为自然语言回答-用表格呈现结构化数据-突出关键数据点-提供业务洞察如趋势、异常-如果结果为空说明可能的原因## 常见查询模式### 模式 1基础信息查询--查询特定员工的基本信息 SELECT emp_no,CONCAT(first_name, ,last_name)AS full_name,gender,birth_date,hire_date FROM employees WHERE emp_no员工号;### 模式 2当前状态查询--查询当前薪资最高的员工TOP10 SELECT e.emp_no,CONCAT(e.first_name, ,e.last_name)AS name,s.salary FROM employees e JOIN salaries s ON e.emp_nos.emp_no WHERE s.to_date9999-01-01--当前薪资 ORDER BY s.salary DESC LIMIT10;### 模式 3历史趋势分析--查询某员工的薪资变化历史 SELECT emp_no,salary,from_date,to_date,salary-LAG(salary)OVER(ORDER BY from_date)AS increase FROM salaries WHERE emp_no员工号ORDER BY from_date;### 模式 4跨表关联查询--查询各部门的平均薪资当前 SELECT d.dept_name,COUNT(DISTINCT de.emp_no)AS emp_count,ROUND(AVG(s.salary),2)AS avg_salary FROM departments d JOIN dept_emp de ON d.dept_node.dept_no JOIN salaries s ON de.emp_nos.emp_no WHERE de.to_date9999-01-01--当前在职 AND s.to_date9999-01-01--当前薪资 GROUP BY d.dept_name ORDER BY avg_salary DESC;### 模式 5复杂业务分析--分析话语权综合管理层级、薪资、任职时长 WITH manager_hierarchy AS(--统计每个经理管理的下属数 SELECT dm.emp_no,COUNT(de.emp_no)AS subordinate_count FROM dept_manager dm JOIN dept_emp de ON dm.dept_node.dept_no WHERE dm.to_date9999-01-01AND de.to_date9999-01-01AND de.emp_no!dm.emp_no GROUP BY dm.emp_no),current_salary AS(--当前薪资 SELECT emp_no,salary FROM salaries WHERE to_date9999-01-01),tenure AS(--任职时长年 SELECT emp_no,TIMESTAMPDIFF(YEAR,hire_date,CURDATE())AS years_employed FROM employees)SELECT e.emp_no,CONCAT(e.first_name, ,e.last_name)AS name,COALESCE(mh.subordinate_count,0)AS team_size,cs.salary,t.years_employed,--简单的话语权评分可根据业务调整权重(COALESCE(mh.subordinate_count,0)*10cs.salary/1000t.years_employed*5)AS influence_score FROM employees e JOIN current_salary cs ON e.emp_nocs.emp_no JOIN tenure t ON e.emp_not.emp_no LEFT JOIN manager_hierarchy mh ON e.emp_nomh.emp_no WHERE cs.salary60000--过滤低薪员工 ORDER BY influence_score DESC LIMIT20;## 注意事项### ⚠️ 时间字段的正确处理-strong当前状态/strong必须使用 to_date9999-01-01 过滤-strong历史查询/strong注意 from_date 和 to_date 的范围-strong时间计算/strong使用 TIMESTAMPDIFF、DATEDIFF 等函数### ⚠️ 性能优化-strong大表 JOIN/strong优先使用索引字段emp_no,dept_no-strong聚合查询/strong合理使用 GROUP BY 和 HAVING-strong结果限制/strong对于展示类查询添加 LIMIT 限制-strong子查询优化/strong复杂查询使用 WITH(CTE)提高可读性和性能### ⚠️ 数据质量-strongNULL 值处理/strong使用 COALESCE 或 IFNULL 处理空值-strong重复记录/strong注意员工可能多次调岗查询时考虑去重-strong数据范围/strong数据库只包含1985-2000年的数据查询时注意时间边界## 故障排查strong问题1查询结果为空/strong-检查是否正确使用了 to_date9999-01-01-验证员工号或部门号是否存在-检查日期范围是否合理strong问题2查询速度慢/strong-检查是否缺少索引字段的 WHERE 条件-考虑将复杂查询拆分为多步-使用 EXPLAIN 分析查询计划strong问题3统计数据不准确/strong-注意区分历史和当前状态-检查 JOIN 条件是否遗漏-验证聚合函数的使用是否正确 这个 SKILL.md 文件展示了一个完整技能的结构-清晰的元数据智能体用于发现和匹配-完整的数据库结构说明-详细的工作流程指导-丰富的查询模式示例可直接复用的 SQL 模板-实用的注意事项和故障排查 技能的使用效果 当用户向支持 Agent Skills 的智能体如 Claude Desktop、Claude Code提问时 用户问题分析公司内部谁的话语权最高需要综合考虑管理层级、薪资水平和任职时长。div aligncenterimg src./images/Extra05-figures/image5.pngaltAgent Skills工作流程width90%/p图5Agent Skills 完整工作流程示意/p/div输出示例 排名 员工号 姓名 团队规模 薪资 任职年限 影响力评分1110022Margareta Markovitch45152,71018692.712110039Vishwani Minakawa38138,27316598.273110085Ebru Alpin32124,05415519.05关键洞察1.话语权最高的员工通常管理大团队30人、薪资前1%12万、任职超15年2.部门经理的影响力远超普通员工管理规模是关键因素3.长期任职的高薪员工即使不担任管理职务也具有较强的话语权 整个过程中技能提供了-领域知识如何衡量话语权管理规模薪资任职时长-技术指导如何编写高效的 SQL使用 CTE、窗口函数、多表 JOIN-业务理解如何解读数据并生成洞察 Skills 的分享与复用 Agent Skills 的另一个重要特性是社区化。Anthropic 建立了官方的 Skills 仓库 官方技能库https://github.com/anthropics/skills 截至2025年已有数百个社区贡献的技能覆盖-开发工具前端设计、API 测试、代码审查、Git 工作流-数据分析SQL 查询、数据可视化、统计分析-文档处理PDF 解析、Markdown 生成、技术文档撰写-业务流程项目管理、客户支持、合规审查 使用社区技能非常简单# 克隆官方技能库git clone https://github.com/anthropics/skills.git# 复制需要的技能到你的项目cp-r skills/frontend-design./my-project/skills/# 智能体会自动发现并加载你也可以分享自己的技能# 发布到 GitHubcd my-custom-skill git init git add SKILL.md git commit-mAdd custom SQL analysis skillgit remote add origin https://github.com/yourname/my-skill.git git push-u origin main# 其他开发者可以直接使用# git clone https://github.com/yourname/my-skill.git行业动态与生态演进 标准化进程与厂商支持 Agent Skills 虽然由 Anthropic 提出但其设计理念正在影响整个行业。 Anthropic Claude-Claude Desktop 和 Claude Code 原生支持 Skills-提供官方 SDK 和开发工具-维护官方技能库 OpenAI 的响应 虽然 OpenAI 尚未官方采用Skills这个术语但在2025年3月的更新中ChatGPT 引入了类似的概念-Custom Instructions 增强支持更复杂的多步骤指令-Memory 与 Context Profiles允许用户保存和复用特定领域的知识-GPTs 的知识库功能可以附加文档和脚本按需加载 这些功能本质上是 Skills 理念的不同实现形式。 Google Vertex AI Google 在 Gemini 模型中引入了Grounding with Functions允许开发者定义函数包Function Packages每个包包含-函数定义类似 MCP 的 tools-使用指南类似 Skills 的 instructions-示例examples 这种设计与 SkillsMCP 的混合架构高度相似。 分层架构的必然性 综合各方观点我们认为Skills 和 MCP 代表了智能体架构中两个必然分离的层级。随着智能体系统的复杂度增加这种分层是不可避免的 应用层Application Layer ↓ Agent Skills ↓ 领域知识、工作流、最佳实践 传输层Transport Layer ↓ MCP ↓ 标准化接口、工具调用、资源访问 基础设施层Infrastructure Layer ↓ 数据库、API、文件系统、外部服务 这与传统软件架构的演进路径完全一致从单体到分层到微服务只是在 AI 领域重新演绎了一遍。 标准化的趋势 随着行业对智能体技术的重视我们预见以下趋势1.协议融合 未来可能出现统一的智能体能力描述协议融合 MCP 的连接性和 Skills 的知识表达# 未来的统一协议示例假想apiVersion:agent.io/v1 kind:Capability metadata:name:enterprise-data-analysis spec:transport:protocol:mcp server:database-mcp-server tools:[query,schema]knowledge:type:skill workflow:data-analysis-workflow.md examples:examples/2.市场化与生态系统 类似于 NPM、PyPI未来可能出现智能体能力的包管理系统# 假想的未来命令agent-cli install anthropic/frontend-design-skill agent-cli install google/data-analysis-suite agent-cli install openai/code-review-assistant 开发者可以发布、分享、售卖自己的 Skills 和 MCP 服务器形成繁荣的生态系统。3.自动化能力发现 智能体可能发展出自动发现和学习新能力的机制# 未来的智能体可能具备自主学习能力agentSelfEvolvingAgent()# 智能体在执行任务时发现缺少某种能力responseagent.run(生成 3D 建模文件)# 智能体自动搜索并安装相关 Skill# [内部日志] 检测到未知任务类型3D建模# [内部日志] 搜索技能库...发现 blender-3d-modeling skill# [内部日志] 请求用户授权安装...已授权# [内部日志] 技能安装完成重新执行任务挑战与风险 与此同时我们也需要警惕潜在的风险strong安全性挑战/strong-Skills 包含可执行脚本存在代码注入风险-MCP 服务器可能暴露敏感数据接口-第三方技能的可信度难以验证strong上下文污染/strong-随着 Skills 数量增加即使是元数据也可能占用大量上下文-需要更智能的技能索引和检索机制strong碎片化风险/strong-虽然 MCP 正在标准化但 Skills 格式尚未统一-不同厂商可能推出不兼容的 Skills 规范 总结 Agent Skills 和 MCP 代表了智能体技术栈中两个关键的抽象层-strongMCPModel Context Protocol/strong解决连接性问题是智能体与外部世界交互的标准化接口相当于神经系统或双手-strongAgent Skills/strong解决能力问题是领域知识和工作流的封装相当于大脑皮层或操作手册两者不是竞争关系而是互补关系div aligncenterimg src./images/Extra05-figures/image6.pngaltMCP与Agent Skills总结对比width90%/p图6MCP 与 Agent Skills 全面对比总结/p/divstrong关键洞察/strong1.strong分层架构是必然趋势/strong随着智能体系统复杂度增加连接层和知识层的分离是不可避免的2.strong上下文效率是核心矛盾/strongSkills 的渐进式披露机制将 token 消耗降低90%以上这是其最大的技术优势3.strong领域知识的民主化/strongSkills 让非开发者也能贡献智能体能力这将极大拓展 AI 应用的边界4.strong混合架构是最佳实践/strong在企业级应用中MCP 提供基础设施连接Skills 提供业务逻辑两者结合才能构建高效、可维护的智能体系统strong实践建议/strong-对于strong外部服务连接/strong数据库、API、云服务优先使用 MCP-对于strong复杂工作流/strong多步骤任务、领域专业知识优先使用 Skills-在strong上下文受限/strong的场景长对话、大量工具使用 Skills 进行渐进式管理-构建strong企业级智能体/strong时采用 MCPSkills 的分层架构 通过本章的学习你应该能够-理解 Agent Skills 和 MCP 的本质区别与协作关系-掌握 Skills 的渐进式披露机制及其优势-编写高质量的 SKILL.md 文件-在实际项目中合理选择和组合两种技术-构建分层清晰、高效可维护的智能体系统 智能体技术仍在快速演进中。MCP 已成为连接层的事实标准Skills 的理念也在影响整个行业。掌握这两种技术将帮助你在 AI 浪潮中构建更强大、更实用的智能体应用。---参考资料1.Anthropic Agent Skills 官方文档https://docs.anthropic.com/en/docs/agent-skills2.Anthropic Skills GitHub 仓库https://github.com/anthropics/skills3.Model Context Protocol 规范https://modelcontextprotocol.io/4.Anthropic 博客Improving Frontend Design Through Skillshttps://www.claude.com/blog/improving-frontend-design-through-skills5.第十章智能体通信协议hello-agents