为了扩展大模型能力，先后有了mcp（调用外部工具）、A2A（调用其他agent）等协议能力，现在又来一个skills，那么这几个的关系啥样？
先说结论，无论mcp、 子agent、skills，都是设计模式，从实现角度看，对于一个功能上面几种方式都能实现，只不过从最佳实践角度看，应用场景不同
（比如想实现一个写PPT的agent，可以直接让agent自己实现，也可以基于mcp去调用第三方，还也可以调用其他子agent，甚至也可以利用skills去实现）
Skills VS MCP
Skill和MCP的职责不同：如果你需要解释这个事情“怎么做”，那么就使用Skill；如果你需要Agent来"访问"某数据，那么就使用MCP
更通俗的说：MCP让Agent链接到工具，Skill是告诉Agent如何使用工具
MCP指令：如何正确使用服务器和工具（查询语法、API各式）
Skill指令：如何在特定流程中使用它们（先查哪些记录、如何交叉引用、如何格式化输出）
以上面"PPT编写agent实现"为例子，按照skill和mcp进行拆分
怎么实现ppt编写：使用skills来描述，主要描述ppt的操作流程，包括需求确认、制定大纲、图片检索、文案以及模版选择等。
做ppt需要哪些题材：比如使用mcp来实现图片库检索、PPT-api调用等
基于上面原则，两者应用场景有倾向性：
使用MCP的场景:
需要访问数据库
需要调用外部API
需要操作文件系统
需要与第三方服务集成
使用Skills的场景（定义复杂的工作流）
涉及工具的多步骤工作流：会议准备需要从多个源拉取信息,然后生成结构化文档
需要一致性的流程：每季度的财务分析必须遵循相同方法论,合规审查有必须检查的项
想要捕获和分享的领域专业知识：研究方法论、代码审查标准、写作指南
即使团队成员离职也应保留的工作流：这就是制度知识一-把"只有老员工才知道的事"变成可复用的指令
Skills VS 子Agent
从职责角度看，Skills 和 子Agent比较像，都是承载一个功能，去实现它。
但是从实现方向角度看，Skills较轻量，可以类比为SDK；而子Agent相当于远程调用请求
Agent Skills 设计模式：一个 Agent，带一堆“能力插件”。只有一个主 Agent（一个策略/一个人格/一套记忆），在一次对话里，根据需要选择调用哪些 skill，但整个决策和对话流程都在这个单 Agent 里完成。
子 Agent 构建模式（多 Agent / 分层模式）：一个“总控 Agent” + 多个“专长子 Agent”。有一个顶层的“编排/路由”Agent，负责判断当前任务应该由谁来处理，每个子 Agent 都是一个服务，拥有有自己独立的prompt和上下文。
根据业务场景的复杂度（问题复杂度 + 业务多样性 + 团队规模）来划分应用场景：
Skills模式：业务核心是“一个智能体 + N 个工具”，业务集中在一个主任务上，对“角色”和“语气”的需求比较一致，决策链不长，不怎么需要跨领域协作，系统偏 MVP / 单产品。
子Agent模式：业务很多元，像一个“多角色团队”，就用子 Agent 模式，让不同 Agent 分工合作，比如具备强领域差异 + 强定制需求，需要清晰的组织/团队边界，具备多阶段、多角色协作的特点等。
总结
Skills是个设计模式，目的是定义日常工作中复杂的工作流程固化下来，并可以以文件或者git的方式维护版本和沉淀传递。
使用Skills，MCP，还是子Agent模式取决于业务需要，并没有明确要求，只不过从最佳实践角度看：
从定位角度看，Skills倾向于描述，在解释这个工作怎么做；MCP更像工具，强调的是标准化和互操作性，方便agent去调用外部数据；它们不是竞争关系，而是互补关系。
从实现角度看，Skills更像SDK，依附于主Agent实现；子Agent更像是远程调用，主Agent只负责分发。