跨框架 Skills 互操作是避免供应商锁定的关键

2026 年 5 月，你在 CrewAI 里精心打磨了一个“深度调研”Skill：先并行搜索 Google 和 arXiv，再用浏览器渲染动态页面，最后交给本地模型整理摘要。第二天同事问：“能把这个 Skill 直接挂到 LangGraph 的工作流里吗？”你沉默了几秒，发现自己把 SearchTool、Playwright 和推理逻辑全都写在了 CrewAI 的 @tool 装饰器里——它已经和框架长在了一起。这不是某个团队的偶然失误，而是一个正在扩大的行业隐患：每多选一个 Agent 框架，Skill 就要重写一次；框架一迭代，依赖库一换，几十个 Skill 就成了技术债。

当前的多框架格局正在加速演变。LangGraph、CrewAI、AutoGen、Agno、Semantic Kernel……各自定义了不同的 Tool/Skill 接口、调用协议和任务编排方式。与此同时，两大互通协议——Anthropic 主导的 Model Context Protocol（MCP） 和 Google 推出的 Agent-to-Agent Protocol（A2A）——已于 2025 年底相继进入 Linux 基金会旗下 Agentic AI Foundation (AAIF) 的统一治理，覆盖工具调用、资源访问与智能体间协作。这些协议让“一次定义、跨框架复用”的 Skill 互操作不再是空谈，而是眼下就可落地的架构决策。

本章将拆解三层关键：描述格式、运行时适配、社区验证，让你能够设计一套适配层，让 Skill 的定义与框架彻底解耦——今天在 CrewAI 当研究员，明天换 AutoGen 照样用。

互操作的三个维度：现状与评估

想实现跨框架 Skill 复用，不能只靠“写个适配器”的念头。我们从 Skill 描述格式、运行时代理/自动转换、社区实践 三个维度切入，逐一分析现有方案的可操作性、风险与投入成本。

维度一：通用 Skills 描述格式——基于 OpenAPI 的扩展标准

问题的起点是：如何用一种框架无关的方式把“Skill 能干什么、怎么调用、需要什么权限”完整描述出来？目前社区形成了三种流派：

当前调研资料显示，MCP 的 tools/list 和 A2A 的 Agent Card 已经可以覆盖大部分 Skill 的能力声明——工具名称、描述、输入参数 Schema、输出 Schema。缺失的是更复杂的元信息：超时限制、并发上限、依赖的其他 Skill、执行成本预估等。因此一个务实的方案是：以 OpenAPI 3.1 为基底，扩展自定义字段来承载这些元信息，同时保留一个“协议映射层”将 Skill 描述自动转换为 MCP Tool 或 A2A Agent Card。

示例：一个通用 Skill 描述片段（JSON Schema 混 YAML 表示）：

openapi: "3.1.0"
info:
  title: "Deep Research Skill"
  version: "1.2.0"
x-skill-type: "tool"
x-skill-concurrency: 5
x-skill-timeout: 30s
paths:
  /deep-research:
    post:
      operationId: execute
      requestBody:
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/QueryInput"
      responses:
        "200":
          description: "Structured research results"
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/ResearchResult"
components:
  schemas:
    QueryInput:
      type: object
      properties:
        topic:
          type: string
        max_sources:
          type: integer
          default: 10

这个描述可以自动生成 MCP 的 Tool 结构、A2A 的 Agent Card，同时能被一个运行时代理解读，用于并发控制和超时处理。

维度二：运行时代理与自动转换——动态适配层的设计

有了标准描述只是第一步，真正的难关在于如何让不同框架“执行”同一个 Skill。因为框架内部的调用方式差异很大：CrewAI 要求 Tool 是可调用对象，LangGraph 需要 BaseTool 或函数节点，AutoGen 使用 @tool 装饰且依赖消息流，Semantic Kernel 则通过 KernelFunction 插件系统。

核心思路：构建一个轻量级的 Runtime Proxy，它接收来自任意框架的标准请求（例如根据 MCP 的 tools/call 或自己定义的 HTTP API），将其翻译为目标 Skill 的实际执行体，再把结果按原格式返回。架构如下：

• Skill Execution Engine：负责加载 Skill 定义，管理生命周期、并发、超时、重试等，具体执行可由本地函数、Docker 容器或远程 MCP Server 完成。
• Framework Adapter：每个框架提供一个 Adapter（插件），实现框架特定的 Tool/Skill 接口，内部则向 Proxy 发起调用。这样框架开发者感觉就像一个“本地工具”，但实际执行在统一的 Skill 层。
• Discovery Layer：根据框架的要求提供 Skill 列表。例如在 LangGraph 中，Adapter 可以查询 Proxy，自动生成 ToolNode 列表；在 A2A 中，Adapter 就是 Agent Card 的生成器。

这种设计类似于浏览器中的 Web Component：每个框架通过标准 DOM 事件访问组件，而组件本身与框架无关。我们已经在调研材料中观察到类似实践——GitHub 上的 obra/superpowers 项目使用可组合的 Skill 目录和指令，虽然它侧重编码助手，但其“Skill 与代理指令分离”的理念完全可借鉴。

关键设计决策：调用协议建议统一采用 MCP 的 Streamable HTTP（而非旧版 HTTP+SSE），因为它原生支持请求-响应、流式结果和服务器推送，且 Google AI Agents Intensive 2025 的资料也确认了该方式对现代 Agent 工具的兼容性。安全层统一使用 OAuth 2.1 with Resource Indicators，避免后续跨框架调用时的认证重写。

维度三：验证与社区实践调查——避坑与可行性

实现跨框架适配层之前，必须正视社区已有的尝试和它们暴露出的局限。我们从几个有代表性的项目切入：

从调研材料看，仅靠单一协议或手动适配是无法避免框架锁定的。MCP 解决了工具调用的标准化，A2A 解决了 Agent 间如何发现和委托任务，但二者协同才能构成完成的互操作基础。未来一项重要进展是 MCP/A2A 联合规范（据 zylos.ai 报告，2026 Q3 可能出现），在此之前设计适配层时应明确层次：底层协议适配、中层 Skill 抽象、顶层框架插件，任何一层改动都不应波及其他层。

结论：跨框架 Skill 复用的最佳路径

核心结论：

1. 采用 OpenAPI 3.1 扩展 Schema 作为 Skill 的规范描述，同时生成 MCP Tool 和 A2A Agent Card 协议表示，这是当前性价比最高的解耦方案。
2. 构建 Runtime Proxy + Framework Adapter 的双层架构，让每个框架通过统一 API 执行 Skill，彻底切断 Skill 实现与框架之间的耦合。

将不同方案的对比落在下表，方便你做架构决策：

按场景推荐：从现在开始怎么做

根据你当下的项目阶段，可以分三种策略落地：

• 场景 A：已有多个 MCP 工具，要扩展到多个框架
  立即建立一个内部的 Skills Schema Registry，把现有 MCP 工具注册进来，附带并发限制、超时等元信息。然后为每个框架编写一个 Adapter，封装 Proxy 调用。这样新 Skill 直接按 Schema 定义，无需再为框架不同而重复开发。

• 场景 B：刚开始构建 Agent 系统，希望一步到位避免锁定
  从 Day 1 就采用自定义 Schema + Proxy 架构。Skill 的第一次落地仍然需要绑定到具体框架（比如 CrewAI），但代码中只调用 Proxy 的接口，框架 Adapter 作为薄薄的一层接入。未来换框架时，只需替换 Adapter，Skill 本身零改动。

• 场景 C：已有大量单体 Agent 代码，想逐步解耦
  抽取最常用、跨团队复用频率最高的 Skill（如“网页抓取”“数据库查询”），按 Schema 重构并接入 Proxy。其他低频 Skill 暂时保留原样。逐步用自动化工具扫描代码，将硬编码的 @tool 函数标记为待迁移项，设定季度迁移目标。

实施中的几个关键提醒（基于调研资料中的坑）：

1. 传输层立刻切换到 MCP Streamable HTTP，旧 HTTP+SSE 会在 2026 年底被逐渐弃用。
2. 安全认证统一用 OAuth 2.1 + Resource Indicators，不要为每个框架实现不同认证。
3. Skill 描述中的 operationId 必须保持稳定且唯一，它会成为跨协议调用的唯一标识。
4. 在 Proxy 层内置指标收集（延迟、错误率、并发数），因为跨框架调用链一旦出问题，排查极难。

所有这一切的最终目标不是“用最时髦的协议”，而是确保你的团队在未来三到五年的技术演进中，不会因为框架更替而被迫丢弃积累的领域能力。Skill 不是 UI 组件，换一套框架重新画一遍界面也许可行；Skill 是团队对一个专业问题的经验编码，是时间的沉淀——它们理应比任何框架都活得更久。

至此，你的 Skill 已经可以横跨 CrewAI、LangGraph 和 AutoGen 自由流动了。但另一个问题立刻浮出水面：当多个任务同时触发同一个 Skill，或者一个 Skill 内部需要向数十个数据源并行发出请求，如何保证不超时、不阻塞、不拖慢整个系统？下一章 《异步任务与并发控制决定了 Skills 的吞吐量》 将拆解异步 I/O、任务队列和背压机制，让你的 Skill 在高并发下依然保持毫秒级响应。