Lovely Cabin - lilac.
所有文章 标签 分类 系列 文档 关于
Lovely Cabin - lilac.

目录

目录

Agent范式：Skills与MCP

lilac avatar  收录于  类别 Agent
     约 9856 字   预计阅读 44 分钟 
目录

介绍 AI 从“烟囱式 Agent”转向“工业化分层”的演进，核心在于利用 MCP 协议标准化外部连接，并通过 Agent Skills 的声明式封装与渐进式披露，实现企业级能力的资产化、治理标准化与成本极致压缩。

25 年多智能体突然变热，并不只是追潮流，而是企业把大模型接入真实系统后，被迫面对三类结构性矛盾：

  1. 知识更新与时效性：模型训练完成后不会自动获得新知识。只要业务依赖“最新状态”（政策、价格、库存、工单、权限、流程变更），就必须引入检索与工具调用，把“世界的变化”接回系统。
  2. 来源可信与可追溯：检索到信息不等于可信。企业要的是可验证、可追溯、可审计的事实链路，否则“看起来合理”的回答会变成风险输出。
  3. 私有数据可控接入：企业核心数据在内网与权限体系里。没有受控连接与最小权限，模型要么答不准，要么越权；两者在生产上都不可接受。

当你把这三件事都引进来，系统就不可能还停留在“一个 Prompt 搞定一切”的阶段——你必然进入 工程化分层：推理、连接、规则与流程需要被拆开治理。

企业 AI Agent 常见的起步方式是“按场景堆 Agent”：财务 Agent、法务 Agent、HR Agent、销售 Agent、研发 Agent 等 Demo 很快能跑起来。但业务一旦深入，就会遭遇典型的 “Agent Zoo”危机：

  1. 碎片化治理：口径漂移与逻辑冲突 每个 Agent 由不同团队独立构建：独立 Prompt、独立工具定义、独立规则口径。结果是同一业务概念被多套解释。

    典型例子：信贷审批 Agent 与风控 Agent 对同一条规则定义不同，导致对同一客户给出相反结论——这不是模型聪明不聪明，而是治理对象分裂导致的“逻辑孤岛”。

  2. 维护成本指数级增长：复制粘贴式扩展 能力被绑定在 Agent 上。你要更新一项全公司通用的合规流程，只能逐个去改几十个 Agent 的系统提示词与规则片段。Agent 越多，改动面越大，回归验证越难，最终不可维护。

  3. Token 成本与注意力稀释：上下文“公地悲剧” 为了让每个 Agent“什么都会”，团队往往把工具 schema、业务规则、参考文档一次性塞进上下文。 结果是：不管任务多简单，基础输入成本居高不下；更关键的是，上下文越长越容易“迷失在中间”，无关信息干扰推理，幻觉与误调用工具概率上升。

因此行业才会出现一个关键转向： 把能力从“Agent 个体的大脑”中解耦出来，沉淀为可复用、可版本化、可治理的技能资产。

最终收敛为清晰的分层协作架构：

  • Agent Core（LLM）：大脑，负责理解意图、规划步骤、编排调用与生成输出
  • Agent Skills（知识/流程资产）：章法，封装 SOP、规则边界、模板与兜底策略
  • MCP（连接协议）：手脚，标准化连接外部系统并执行动作（DB / API / GitHub / 文档等）

这三层是本文后续展开的骨架。下面先把 MCP 讲清楚，因为 MCP 往往是企业最先引入、也最容易“只用 MCP 就以为够了”的那一层。

一句话定义 MCP：MCP（Model Context Protocol，模型上下文协议）是一种开放、标准化的连接协议，用于统一大模型与外部工具、数据源的交互方式。

它解决的不是“业务怎么做”，而是更底层的问题： 模型如何以稳定、安全、可复用的方式连接外部世界，并把动作执行下去。

1）MCP 的分层架构 MCP 把“连接”拆成经典的“Host—Client—Server”结构，实现模型与工具的物理、逻辑解耦：

  • MCP Host（宿主应用）：交互发起者（桌面端、IDE、企业应用或 AI OS）

  • MCP Client（连接器）：Host 内的协议翻译层，与 Server 建立通信链路

  • MCP Server（资源提供方）：对外暴露标准能力集合，包括：

    • Resources（资源）
    • Tools（工具）
    • Prompts（提示模板）

  • Backend（最终数据源）：Database、GitHub、Slack、Cloud API、内部系统等

这一层的工程价值可以概括为： 把工具与数据源“产品化”为标准接口，让模型像插拔外设一样使用它们。

2）定位类比：LLM 是内核，MCP 是驱动接口 如果把 AI 系统类比为操作系统：

  • LLM 是 内核（Kernel）：负责推理与调度
  • MCP 是 驱动接口（Driver Interface）：负责把外部系统接进来、把指令跑下去

因此 MCP 的角色不是“更聪明”，而是“能稳定地动手”。

做过企业集成的人会对一个问题非常敏感：工具与模型一多，就会出现 N×M 的集成灾难。

1）传统模式：每一对组合都要写胶水代码

在没有统一协议时，你要让：

  • N 个模型/Agent 运行时
  • 连接 M 个系统/工具（云文档、数据库、工单、代码仓库、内部 API……）

现实往往是：每一对组合都要单独适配。后果很直接：

  • 集成成本高、交付周期长
  • 适配代码难复用
  • 生态被割裂为“孤岛”

2）MCP 的解法：统一翻译层，“连接一次，处处可用”

MCP 的核心价值是把网状依赖压平： 你把某个工具/数据源实现为 MCP Server 后，任何支持 MCP 的 Host 都能按同一协议连接并使用。

这是典型的工程去耦合： 从“每对组合单独适配”，变成“围绕标准接口线性集成”。

3）工程落地要点：传输层覆盖本地到云端

MCP 覆盖多种传输形态，适配从本地助手到云端服务的不同部署方式，例如：

  • Stdio：本地进程通信，低延迟
  • SSE（Server-Sent Events）：远程 HTTP 通信

这也是 MCP 能快速落地的原因：协议统一，但部署形态不被锁死。

MCP 统一了连接标准，但孤立使用反而暴露新的工程瓶颈。

如果你把 MCP 当成完整方案，你会遇到一种典型的结构性缺陷： 有手有脚，但没有章法。能执行动作，但不保证做得对、做得一致、做得便宜。

1.4.1 痛点 1：上下文爆炸 —— Token 成本与注意力稀释

先给结论：MCP 是协议，本身不强制“急切加载”。但大量落地会走向“省事的急切加载”，从而引发上下文爆炸。

典型做法是：为覆盖所有场景，把工具 schema、API 说明、规则片段一次性塞进 System Prompt。常见后果：

  1. 基础输入成本上升：工具越多，Prompt 越长，单次交互“起步价”持续抬高。
  2. 推理质量下降：上下文过长导致注意力被稀释，无关工具干扰选择，误调用概率上升。
  3. 响应变慢且不稳定：模型需要在更大噪声空间里做路由与决策，延迟抖动更明显。

本质上：你不是在“给模型更多能力”，而是在“给模型更多噪声”。

1.4.2 痛点 2：能力鸿沟 —— 只有原子工具，没有企业 SOP

第二个痛点更致命，因为它不是钱的问题，而是“组织能不能一致做事”。

核心结论：MCP 暴露的是原子化工具接口，不包含业务流程与口径（SOP）。 模型能查数据库、能读文档，但并不知道：

  • 哪些口径必须统一（退款是否扣除、权限边界如何判定）
  • 哪些检查必须强制执行（合规、审计、双人复核）
  • 输出必须长什么样（模板、字段、证据引用）

因此企业会很容易滑回 Agent Zoo：

  1. 不同团队各写各的 Prompt 与规则 → 口径不一致
  2. 同一流程被重复实现 → 逻辑冗余与系统熵增
  3. 同一事实链路给出冲突结论 → 业务信誉受损

前面我们把 MCP 讲透了：它统一了连接标准，终结了 N×M 的集成灾难。 但也把一个现实摆在你面前——仅靠 MCP，“能连上”不等于“会做事”。

孤立使用 MCP，就像给新人配齐了全套工具（能查、能改、能提交），却没有《操作规程》与《验收标准》：

  • 为了“随时可用”，他把所有工具说明都背在身上 → 上下文爆炸、成本上升
  • 每个团队各有一套用法 → 口径漂移、输出不一致

这也是为什么MCP 给了手脚，但企业要规模化落地，还必须有一层来提供章法与按需加载机制。 所以问题就变成一句话：当模型已经能接触世界之后，我们到底要用什么方式，让它“按企业的正确方式做事”，并且能规模化治理、复用、降本？

答案就是：Agent Skills。

Agent Skills 不是另一个 Agent。它是一种结构化的、声明式的知识库，是 AI 的“动态说明书”。

它的目标也很明确：

  • 把企业内部隐性的专家经验（财务分析流程、代码审查规范、合规检查清单等）
  • 变成可版本控制、可分享、可复用的数字资产
  • 并且以文件系统资产的形式固化下来（典型就是 SKILL.md）

它的范式意义： 过去我们管理的是“思考的实体（Agents）”。 未来我们管理的是“可执行的知识（Skills）”。

这是治理对象的改变，也是成本结构的改变。

这里是 Agent Skills 最容易被误解、但也最关键的地方。 很多人听到“Skill”，第一反应是： 是不是又做了一套工作流引擎？是不是把每一步硬编码成流程？ 但得强调：不是。

1）核心思想：What > How（声明“需要什么”，而不是硬控“怎么做”）

  • 不告诉模型“怎么做（How）”——不把模型当成一台只能按步骤执行的机器。
  • 而是声明“需要什么样的能力和约束（What）”——给它一个结构化框架（SOP、规则、案例），让模型在框架内发挥理解与生成能力，自主匹配与应用。 这是一种非常“云原生”的思想： 就像 Kubernetes 的声明式配置——你声明期望状态，系统负责实现路径。 Skills 也是一样：你声明业务章法与边界，模型负责在边界内推理与编排。

2）Skills 的工作方法：给模型一个“知识框架”，而不是塞一堆散乱的 Prompt 一个高质量 Skill 通常会包含这些元素：

  • 步骤框架（Steps）：建议的思考路径，告诉模型“先看什么、后看什么”
  • 规则与约束（Rules）：业务红线、合规边界、必须检查的事项
  • 案例（Examples）：问题—答案对照，用 Few-shot 引导输出风格与结构
  • 输出模板（Templates）：让交付物结构化、可审计、可复用 这带来非常好的表达：“柔性的精确”： 既通过规则提供精确边界，又允许模型在框架内灵活应对场景变化。

我们回到 MCP 暴露的两大痛点：

  1. 上下文爆炸（Context Explosion）
  2. 能力鸿沟（缺业务 SOP，导致逻辑孤岛与决策冲突）

Agent Skills 的解决方式不是“再堆 Prompt”，而是两件事：

  • 把业务章法从 Prompt 中剥离出来，变成可治理的资产（解决能力鸿沟与治理碎片化）
  • 用“渐进式披露（Progressive Disclosure）”实现按需加载（解决上下文爆炸与 Token 公地悲剧）

所以可以用一条极其工程化的话概括： MCP 提供工具接口，Skills 定义如何正确组合并使用工具；MCP 解决“有无”，Skills 解决“方法论与约束”。

一个非常真实的悖论：

  • 为了让模型变强，我们塞入更多工具与知识
  • 但塞得越多，模型越慢、越贵、越容易“迷失在中间”

渐进式披露就是为了解决这个矛盾，它模仿人类专家的认知过程：

先看目录 → 再翻手册 → 最后动手执行

1）困境：急切加载（Eager Loading）把上下文变成垃圾场 传统 MCP/Agent 方案常见做法：

  • 在连接时把所有工具定义、API 规范、说明文档一次性注入 System Prompt
  • 于是出现典型量级： 含多种工具的服务器 → 16,000 Tokens，工具定义把上下文窗口占满

三个非常关键的后果：

  • 成本激增：90%+ Token 被浪费在与当前任务无关的工具定义上
  • 性能下降：模型出现 “Lost-in-the-Middle”
  • 推理被稀释：幻觉与错误路由风险增加

2）理想：按需加载（Lazy Loading）——“先给目录，你要哪个再拿哪个” 非常形象：

  • Eager：像急性子，不管你需不需要，先把所有 API 说明塞给你
  • Lazy：先给你看目录，你需要哪个，再给你详细内容

3）三层加载架构：把 Token 消耗降低 60%–90%，并引入“认知聚焦”

“该机制引入了认知聚焦（Cognitive Focus），在初始阶段隐藏细节，使模型在任务路由阶段保持更高准确性。”

这句实际上解释了为什么省 Token 还能提升质量： 省掉的不只是成本，更是噪声。

第一层：元数据层（Discovery / 发现）

  • 加载时机：Agent 启动时，始终加载
  • 加载内容：只加载技能的 name 和 description（YAML 元数据）
  • Token 消耗：极低（约 50–100 Tokens/技能）
  • 作用：构建轻量级“技能目录”，让模型知道“我会什么”，用于任务匹配
  • 价值：挂载成千上万技能也不拖慢启动，不污染上下文

第二层：指令层（Activation / 激活）

  • 加载时机：当用户请求与 skill 的 description 匹配时加载
  • 加载内容：匹配 skill 的完整 SKILL.md 正文（Markdown 指令）
  • Token 消耗：中等（~500–2000 Tokens）
  • 作用：把 SOP、规则、输出模板真正注入上下文
  • 价值：只在“需要的时候”加载，避免无关规则干扰推理

第三层：资源层（Execution / 执行）

  • 加载时机：执行指令过程中，按需/条件触发
  • 加载内容：
    • 调用外部脚本（.py 等）执行确定性任务
    • 读取参考文档（.md）做厚重知识查阅
  • Token 消耗：高，但只在命中条件时发生
  • 作用：把确定性工作（计算、上传、文件处理）卸载到代码，把“准确性”从概率变成确定

1.10 Skill 的物理形态：一个标准 Skill 由核心定义文件 + 可选资源组成

文件结构及其含义：

.claude/skills/
  financial-report-analyzer/
    SKILL.md                 # 核心定义文件（必需）
    scripts/
      validate_math.py       # 脚本（可选）
    references/
      accounting_manual.md   # 参考文档（可选）

SKILL.md 的两个部分：元数据 + 指令正文

  • YAML Frontmatter（元数据）：技能“身份证”
    • name / description（以及可选的 allowed_tools 等限制）
    • 这是 Discovery 阶段唯一可见的信息
    • description 的质量直接决定技能被调用的准确率
  • Markdown Body（指令正文）：技能“大脑”
    • SOP、规则、步骤、输出格式
    • 这是 Activation 阶段按需加载的部分

一句非常工程化的价值判断：脚本与资源 = “代码即工具”，用于执行确定性任务，弥补 LLM 概率性输出缺陷，确保结果 100% 准确。

这句话是企业落地的关键： LLM 负责推理与语言，确定性动作交给脚本与工具。

现在我们把抽象机制落到一个具体例子：会议总结助手。

要求：

  • 总结会议录音
  • 提取参会人、核心议题、行动项
  • 必须按公司模板输出
  • 若涉及预算，必须合规检查
  • 总结完成后上传到 云文档

这就是典型的企业工作流：既有内容生成，又有合规约束，还有确定性交付动作。 Skill 的价值就在于：把这些“章法”一次性固化，并能被无数 Agent 复用。

  • 元数据

    • name：会议总结助手
    • description：用于总结会议录音，提取关键信息并按模板输出

  • 会议总结规则

    • 参会人员：@提及所有参与者
    • 核心议题：总结讨论要点
    • 行动项：明确结论与负责人（必要时含截止日期）

  • 注意事项（条件触发）

    若涉及预算：引用 财务手册.md 做合规性检查（条件触发加载参考文档）

  • 交付动作（确定性执行）

    调用 upload.py 脚本上传至公司 云文档（脚本执行，保证 100% 落地）

两类触发： Reference 是“按需加载的专家知识库”，Script 是“确保结果 100% 准确的执行单元”。

一个特别形象的比喻：

  • 传统 Agent：服务员把菜单上所有菜的制作流程都背给你听
  • Skill 模式：只给你一张精简菜单，你点什么才做什么

然后进入三阶段对比：

阶段 A：启动（Initialization）

  • 传统模式：加载所有 Prompt、规则、参考资料

    消耗：~3000+ Tokens

  • Skill 模式：只加载元数据（name & description）

    消耗：~100 Tokens

  • 节省原理：目录索引机制——不读正文，只看封面

阶段 B：激活（Activation） 场景：用户说“总结这条会议录音”

  • 传统模式：已全量在上下文，直接推理（但也意味着任何场景都背着这份成本）

  • Skill 模式：按需激活，加载 SKILL.md 正文

    消耗：+500 Tokens（量级）

  • 节省原理：不干活不拿工具——如果用户问天气，这 500 Tokens 根本不会加载

阶段 C：执行（Execution） 场景：会议内容涉及“预算审批”

  • 传统模式：厚重《财务手册》始终在上下文里占位

  • Skill 模式：条件触发，临时加载 references/财务手册.md

  • 节省原理：无关知识不进脑子

    如果会议只讨论团建，财务手册完全不占用上下文

这一段的真正结论不是“省钱”，而是： 你不再需要用“上下文堆叠”换能力，而是用“资产化 + 按需加载”换规模化。

在前面两部分，我们已经分别把 MCP 和 Agent Skills 单独讲清楚了。

但真正决定这套体系能否在企业级落地的，并不是它们各自“多强”，而是它们如何协同。

一句话先给出结论： MCP 负责把 AI “安全地连到外部世界并执行动作”， Agent Skills 负责把组织的 SOP 与最佳实践沉淀为“可复用、可组合、按需加载的程序性知识资产”。

两者不是替代关系，而是严格分层、各司其职。

2.1 核心区别：协议 / 执行面 vs 流程 / 知识面

我们先用一张“架构级”的对照，把边界划清楚。 这一步非常重要，因为很多误解，都是从“把 Skills 当成另一个 MCP、或把 MCP 当成 Workflow 引擎”开始的。

1）本质与定位

  • MCP
    • 本质是一个 连接协议 / 基础设施标准
    • 它解决的是： 模型如何以统一、安全、可控的方式，连接外部工具与系统
    • 它的关注点在 接口、鉴权、执行、返回
  • Agent Skills
    • 本质是 程序性知识资产（Procedural Knowledge Assets）
    • 它解决的是： 连上之后，事情应该怎么做才“对”、才“一致”、才“合规”
    • 它的关注点在 流程、规则、边界、输出标准

一句话总结： MCP 管“能不能做”，Skills 管“该不该这样做、怎么做才对”。

2）能力形态：工具接口 vs 方法论说明书

  • MCP 暴露的是：
    • query_database
    • read_file
    • post_comment
    • …… 这些都是原子化能力，本身不带业务语义。
  • Skills 封装的是：
    • SOP（先做什么、再做什么）
    • 风险点（哪些情况必须检查）
    • 模板（输出必须长什么样）
    • 条件分支（出现什么关键词就触发什么规则）

所以说 “MCP 是手脚，Skills 是大脑”，是非常精确的工程抽象。

3）加载与上下文策略的根本不同

这里需要非常严谨地澄清一个容易被误解的点： MCP 本身并不规定“急切加载”或“按需加载”——它是协议。真正内建“渐进式披露”的，是 Agent Skills 架构。

  • MCP 解决的是： 工具如何被描述、如何被调用、如何返回结果
  • Skills 解决的是： 什么时候值得把哪些规则、哪些知识塞进模型的上下文

所以在实际工程中，上下文是否爆炸，往往取决于：你有没有 Skill 这一层。

4）安全与治理关注点不同，但互补

  • MCP 的安全重心
    • 接口级安全
    • 鉴权、最小权限
    • 隔离执行
    • 审批、确认、回滚
  • Skills 的安全重心
    • 流程级安全
    • 强制检查点（如合规、审计）
    • 风险提示与红线声明
    • 输出规范与留痕要求

一句非常重要的判断： Skills 不能替代平台级安全，但它把“应该做的检查”固化成了不可忽略的流程约束。

理解了区别之后，协作关系就非常清晰了。

Step 1：用户提出“目标”，而不是“命令” “分析上周的销售数据，并给出结论与建议。” 注意：这不是“查数据库”，而是一个业务目标。

Step 2：Agent Core + Skills 层（规划与约束）

  • Agent Core（LLM）做两件事：
    1. 意图理解
    2. 在技能目录中匹配最合适的 Skill
  • 命中 sales-analysis.skill 后：
    • 加载其 SKILL.md
    • Skill 告诉模型：
      • 数据范围是什么
      • 口径如何定义（是否扣退款）
      • 输出需要哪些结构
      • 是否需要校验或审批 此时，模型已经知道怎么做才“对”。

Step 3：MCP 层（连接与执行）

  • Skill 指导模型调用 MCP 工具：
    • query_database
    • fetch_report
  • MCP Server：
    • 在受控权限下执行真实操作
    • 返回原始数据或执行结果 此时，模型已经真的“碰到外部世界”。

Step 4：Skills 层（处理、校验与交付）

  • 根据 Skill 的规则：
    • 清洗数据
    • 计算指标
    • 必要时调用脚本做确定性计算
  • 按 Skill 定义的模板输出结果

最终交付的是： “既可执行、又符合企业标准”的结果。

这个案例非常典型。

模型可以：

  • read_file
  • list_pr
  • post_comment

问题是什么？

  • 不知道该重点看什么
  • 不知道公司安全红线
  • 不知道评论模板
  • 不知道哪些情况必须阻断

本质上： 你给了一个新手程序员管理员权限，但没给他《代码审查规范》。

2.3.2 场景二：MCP + Agent Skills

Code Review Skill 固化了什么？ Skill 明确声明：

  1. 获取 PR 与变更范围
  2. 检查是否有硬编码密钥
  3. 检查 SQL 注入与越权
  4. 按公司模版输出评论
  5. 命中高风险规则时，触发阻断或审批

MCP 负责什么？

  • 拉 PR
  • 读文件
  • 发评论
  • 触发 CI 或安全扫描

结果是什么？ Skill 保证“审查做得对、做得一致”，MCP 保证“动作真的执行到位”。

一个可规模化的 Agent 体系，通常具备以下特征：

  1. 用 Skills 沉淀方法论
    • 减少“每个 Agent 都要重写 Prompt”
    • 把经验变成资产
  2. 用 MCP 接入系统并执行确定性动作
    • 所有外部操作都走标准通道
    • 权限、审计、回滚可控
  3. 配套治理能力
    • Skill 发布流程
    • 版本管理、灰度与回滚
    • 权限分级
    • 审计留痕
    • 来源可信（代码审查）

这一章的收尾语： 真正可落地的 Agent 架构，不是“多几个 Agent”，而是“Skill 资产 + MCP 执行面 + 治理体系”的组合。

如果回顾过去两年生成式 AI 的发展，会发现一个非常清晰的演进轨迹：

  • 第一阶段：谁的模型参数更大、推理更强
  • 第二阶段：谁能更快做出 Demo、Agent、插件
  • 正在到来的阶段： 👉 谁能把能力沉淀为可治理、可复用、可交易的技能资产

MCP 与 Agent Skills 的出现，并不是零散的工程技巧，而是AI 应用层走向成熟的必然信号。

当能力被封装为标准化的 SKILL.md 文件，并且可以跨模型、跨平台运行时，一个趋势几乎不可避免：技能将像 App 一样被分发、订阅与复用。

从“自建一切”到“能力采购”

未来的企业不会再问： “我们要不要做一个税务合规 Agent？” 而是会问： “有没有已经被验证过的 税务合规 Skill，可以直接接入？”

这意味着：

  • 咨询公司（四大、律所、审计机构） → 将专业流程封装为 付费 Skills
  • SaaS 厂商（云文档、Stripe、Salesforce） → 提供官方 Skills，而不只是 API 文档
  • 企业内部 → 只需组合、配置、治理，而不是从零开发

这正是： 从“构建 Agent”，转向“组合 Skills”。

在这一范式下，企业的核心竞争力将发生根本转移。

过去的竞争力是什么？

  • 有多少 Agent
  • 有多少 Prompt
  • 有多少人会“调模型”

未来的竞争力是什么？ 沉淀了多少高质量、可复用、可审计的 Skills。

这意味着：

  • 资深员工的直觉与经验 → 被固化为 SOP + 校验脚本
  • 组织知识不再随人流失 → 而是进入版本库
  • AI 系统具备“机构记忆”

一句话非常有分量： AI 治理的对象，正在从“思考的实体（Agents）”转向“可执行的知识（Skills）”。 这是一次治理对象的转移，而不是简单的技术升级。

Agent Skills 的设计哲学，本质上与 Kubernetes、Terraform 一脉相承。

从 Imperative 到 Declarative

  • 旧模式： 告诉模型 每一步怎么做（How）
  • 新模式： 声明 需要什么能力（What）+ 必须遵守什么约束（Constraints）

模型负责：

  • 理解意图
  • 选择技能
  • 动态规划路径

Skills 负责：

  • 提供边界
  • 提供标准
  • 提供校验

这就是反复强调的那条主线： AI 开发正从“写 Prompt”，转向“定义标准化资产”。

随着 MCP 与 Agent Skills 规范被捐赠给 Linux 基金会旗下的 Agentic AI Foundation (AAIF)，一个非常重要的信号已经出现： AI 应用层，开始进入“工业标准时代”。

这意味着：

  • 技能不再被锁定在 Claude / GPT / 某个 IDE
  • MCP 解决“连接标准化”
  • Skills 解决“能力标准化”
  • 真正实现： 一次编写，到处运行

这也是为什么多次强调： 真正的竞争焦点，将从模型本身，转向工程化能力与生态完整度。

当技术范式变化，组织结构一定会跟着变化。 一个新角色正在浮现：Skill Architect（技能架构师）

Skill Architect 并不是：

  • 纯开发
  • 纯业务
  • 纯产品 而是三者的融合体。

他们负责什么？

  • 定义 Skill 的颗粒度
  • 设计 SKILL.md 的语义接口
  • 规划 Skills 与 MCP 的协作方式
  • 管理技能生命周期（发布 / 灰度 / 回滚）
  • 把控安全、合规与复用性

可以非常明确地说： 未来的 AI 能力差距，往往不在模型，而在 Skill 架构。

上游：知识生产者（Knowledge Producers）

  • 业务专家
  • 咨询公司
  • SaaS 厂商 → 把领域经验封装为 Skills

中游：技能市场（Skill Marketplace）

  • 云厂商
  • 模型厂商
  • 开源社区 → 提供分发、托管、安全审计与交易

下游：能力消费者（Capability Consumers）

  • 企业
  • 集成商
  • 终端用户 → 像搭积木一样组合 Skills，构建定制化 Agent

如果把大模型比作 CPU（算力核心）：

  • MCP 是 驱动程序（Drivers） → 让 CPU 能识别硬件、系统与外部世界
  • Agent Skills 是 应用程序（Apps） → 定义 CPU 要做什么事、遵循什么规则
  • Agent Core 是 调度与内核 → 负责理解、规划与编排

那么我们正在经历的转变是： 从“自己焊电路板、手写 Prompt 和胶水代码”，走向“安装驱动、安装应用、治理资产”的 AI 操作系统时代。

AI 开发的核心，正在从“孤立的多智能体模式”， 转向“管理可复用的技能资产”。

  • MCP 让 AI 连得上世界
  • Agent Skills 让 AI 做得对事情
  • 渐进式披露让 AI 用得起、管得住
  • 技能资产化让 AI 真正进入企业级时代
更新于 2026-01-26
 | 主页