AI News
中文资讯 掘金 AI Sun, 04 Oct 2026 正文 ok 434 words

2.skill

英文标题：2.skill

Agent Skill 核心指南：本质解析、两种存储加载架构与渐进式披露代码实战 一、 Skill 的物理本质剖析 一句话结论：全局 Prompt 决定了 Agent 是个怎样的人（通用性格、通用底线
打开原文相关 3 · 机会 1
media3.2 KB media589 B media5.0 KB

中文

Agent Skill 核心指南：本质解析、两种存储加载架构与渐进式披露代码实战

【核心主旨】：Skill 的物理本质是“按需激活、用完即弃的垂直专业 SOP（提示词）”；小项目通过内存注册表全量预加载，大项目通过 MCP 封装实现渐进式披露，彻底解决 Token 爆炸与注意力稀释。

一、 Skill 的物理本质剖析

  • 一句话结论 ：全局 Prompt 决定了 Agent 是个怎样的人（通用性格、通用底线），而 Skill 是 Agent 面临具体专业工种时，临时翻开的那本专业操作手册。

1. 为什么不能把所有规则都写在全局 Prompt 里？（致命痛点）

  • 注意力稀释（Lost in the Middle） ：模型面前摆了上万字的全局规则，注意力被极度分散，极易出现前后矛盾、遗忘核心业务边界。
  • Token 账单爆炸 ：无论用户问一句多么简单的“你好”，几十条无关的业务规则全量随每一轮对话重复发送，费用呈指数级浪费。
  • 业务域规则互斥与污染 ：跨业务域规则（如“国内退换货规范”与“跨境海外退货流程”）若同时常驻，极易引发模型在判断逻辑上的逻辑打架。

2. 全局 Prompt vs 动态 Skill 深度对比

  • 常驻内存 vs 动态链接库（DLL） ：
    • 全局 Prompt 像电脑的常驻内存，每一轮对话必须死死占据上下文窗口。
    • Skill 像按需加载的动态插件，平时只暴露极简的索引目录（几十个字），只有触发特定场景时才把详尽正文动态载入上下文，任务结束后随对话窗口滑动退出，不长期霸占 Context。
  • 粗粒度泛化 vs 垂直纵深 SOP ：
    • 全局 Prompt 受限于长度，只能写概要原则。
    • 独立的 Skill 拥有充足的空间把规则写得极度详尽、垂直专业，包含所有边界异常处理和输入输出标准。

二、 两种存储与加载架构对比（小项目 vs 大项目）

  • 一句话结论 ：小项目用“本地/云存储 + 字典注册表”求快；大项目用“MCP 工具化 + 渐进式披露”求稳求省。

1. 方案一：小项目架构（本地/云存储 + 内存注册表预加载）

  • 存储位置 ：直接作为 Markdown/文本文件保存在代码目录，或统一托管在云端对象存储中（如阿里云 OSS、字节火山引擎 TOS）。
  • 加载逻辑 ：系统启动时，维护一个内存字典（注册表 Registry），通过启动自拉取或定时轮询将所有 Skill 全量加载到内存，对话时一股脑拼进 Prompt。
  • 适用边界 ：规则极少（10个以内）、单业务域的小型应用。

2. 方案二：大项目架构（MCP 服务封装 + 渐进式披露）

  • 核心难题 ：系统庞大、涉及众多业务域时，Skill 数量成百上千。若全量加载，Token 直接撑爆；若每个 Agent 项目都自己写一套注册表逻辑，重复造轮子且极难集中维护。
  • 解决策略（渐进式披露） ：
    • 能力工具化 ：把“读取和查询 Skill”封装为标准化 MCP 工具服务，部署在中心端。
    • 两段式渐进披露（Progressive Disclosure） ：
      • 第一阶段（看目录）：仅向 Agent 暴露 list_skills 工具，返回轻量的技能名称与一句话功能摘要。
      • 第二阶段（翻正文）：Agent 自主决策判定需要哪项能力后，主动调用 get_skill_detail 工具精准读取对应业务长文本。

三、 两种架构代码实现与对比手册

1. 方案一实现代码：内存注册表 + 全量预加载

skill_registry = {}

def init_skill_registry():
    """系统启动时：从本地文件或 OSS/TOS 全量预加载到内存字典"""
    skill_registry["refund_rule"] = "【退款规则正文】7天无理由退款，包装完好，运费自理..."
    skill_registry["invoice_rule"] = "【发票规则正文】企业发票需提供税号，3个工作日内开具..."

def chat_with_agent(user_query: str):
    """对话时：把注册表里的所有规则全量拼进 Prompt"""
    all_rules = "\n".join(skill_registry.values())
    prompt = f"参考以下所有业务规则：\n{all_rules}\n\n用户问题：{user_query}"

【代码解析】：小项目将注册表简单实现为 dict，对话时无脑拼接全局规则。当技能规模膨胀时，Token 浪费严重且无法支撑多业务域隔离。

2. 方案二实现代码：FastMCP 渐进式披露

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("SkillHub")


SKILL_DATABASE = {
    "refund_rule": {
        "summary": "处理用户退货退款时效及运费承担规则",
        "detail": "【退款详细规则】：7天内未拆封全额退款；质量问题包邮退换；拆封扣10%折旧费..."
    },
    "invoice_rule": {
        "summary": "处理企业专票、普票开具及税号资质核验",
        "detail": "【发票详细规则】：增值税专用发票必须提供一般纳税人资质，每月25日后停止开票..."
    }
}


@mcp.tool()
def list_skills() -> dict:
    """获取所有可用业务技能清单及其简短功能概述（仅返回摘要索引）"""
    return {name: info["summary"] for name, info in SKILL_DATABASE.items()}


@mcp.tool()
def get_skill_detail(skill_name: str) -> str:
    """根据技能唯一名称，按需精准拉取该技能的完整详细操作规则"""
    return SKILL_DATABASE.get(skill_name, {}).get("detail", "未找到对应技能")

if __name__ == "__main__":
    mcp.run(transport="stdio")

【代码解析】：通过分离“查目录”与“取正文”两个 MCP 工具，大模型先快速扫描轻量目录，锁定目标后才精确读取对应长文本，彻底实现上下文按需解耦。

3. 真实运行时交互全过程拆解（以售后咨询为例）

假设用户在聊天界面提问：“你好，我买的车厘子烂了，能全额退款吗？”

  • 第 0 步（初始化：零上下文开销） ：
    • 客户端仅向大模型注入 list_skills 与 get_skill_detail 两个工具的函数定义与说明。
    • 此时模型上下文中完全没有任何业务正文长文本，消耗 Token 几乎为零 。
  • 第 1 步（看目录：轻量索引初筛） ：
  • 第 2 步（翻正文：精准靶向披露） ：
    • 大模型主动发起第二轮工具调用：get_skill_detail(skill_name="fresh_refund_rule")。
    • FastMCP 精准读取并返回生鲜退款详尽细则（如：签收24小时内留证、坏果率超30%全额赔付且无需退回原物）。
    • 长文本正文在这一瞬间才首次且精准地进入模型当前上下文 。
  • 第 3 步（组织回答与即用即弃） ：
    • 大模型根据获取的专业细则给用户提供标准严谨的解答。本轮任务完成后，该长文本随着对话上下文推进自然滑出，绝不长期常驻污染全局记忆。

4. 【核心细节与避坑指南】

  • 细节 1（元数据摘要设计法则） ：
    • list_skills 中的 summary 必须精炼且带有鲜明的触发边界（例如明确说明“适用退款”、“适用开票”），大模型全靠这段几十个字的摘要决定翻哪本书。
  • 细节 2（多 Agent 共享与中心化治理） ：
    • 大项目中，MCP Server 可独立部署在内网云端。客服 Agent、财务 Agent、运营 Agent 只需挂载同一个 MCP 服务，避免在每个项目中重复维护注册表解析逻辑。

四、 架构深思：为什么不给每个 Agent 独立绑定？（多 Agent 分工 vs 技能中台）

  • 一句话结论 ：健康的架构绝不允许单 Agent 强挂百个技能；宏观上“专人专事拆 Agent”，微观上“抽离 MCP 中台共享规则”，二者结合才是企业级终局。

1. 架构师的灵魂质问：专人专事不好吗？

  • 正统的多 Agent 专家模式 ：
    • 在 LangGraph、CrewAI 等多 Agent 体系中，最佳实践本就是“领域拆分”：
      • 客服 Agent ➡️ 只绑定 3 个售后 Skill；
      • 财务 Agent ➡️ 只绑定 2 个发票 Skill；
      • 运维 Agent ➡️ 只绑定 2 个排障 Skill。
    • 结论 ：让一个巨石 Agent 强行背负上百个 Skill，本身就是反模式，必须通过多 Agent 进行领域垂直拆分。

2. 既然已经拆了多 Agent，为什么还要搞统一的 MCP 技能中台？

许多开发者会问：“既然每个 Agent 都有自己的专属技能，各管各的不就行了吗？为什么还要特意把 Skill 抽离出来做成统一的 MCP 服务？” 在大型企业级落地中，主要是为了解决以下三大致命的工程现实痛点：

3. 终局架构：分层协同模型

  • 宏观层（多 Agent 纵向切分） ：严格按业务域拆分 Agent（Supervisor 路由 ➡️ 专属领域 Agent），专人专事，杜绝上下文污染。
  • 微观层（MCP 技能中心横向拉通） ：各个领域 Agent 背后不写死业务规则，而是统一连入企业级 MCP 技能中台，按需做双阶段渐进式披露。

五、 全局大串联 (终极总结)

1. 架构选型决策思维链条

明确业务体量 ➡️ 少于10个规则单业务域？ ➡️ 是：本地文件/OSS + 字典注册表快速落地 ➡️ 否：宏观拆分领域 Agent ➡️ 横向抽象中心化 MCP 技能中台 ➡️ 双阶段渐进披露按需调用 ➡️ 实现单一事实来源与免发版热更新

2. 【终极一句话速记】

“全局 Prompt 筑底线，垂直 Skill 当手册；小项目注册表全量灌，大项目 MCP 渐进翻；专人专事拆 Agent 避混乱，抽离中台共享规则防打架。”

English / 原文

Agent Skill 核心指南：本质解析、两种存储加载架构与渐进式披露代码实战

【核心主旨】：Skill 的物理本质是“按需激活、用完即弃的垂直专业 SOP（提示词）”；小项目通过内存注册表全量预加载，大项目通过 MCP 封装实现渐进式披露，彻底解决 Token 爆炸与注意力稀释。

一、 Skill 的物理本质剖析

  • 一句话结论 ：全局 Prompt 决定了 Agent 是个怎样的人（通用性格、通用底线），而 Skill 是 Agent 面临具体专业工种时，临时翻开的那本专业操作手册。

1. 为什么不能把所有规则都写在全局 Prompt 里？（致命痛点）

  • 注意力稀释（Lost in the Middle） ：模型面前摆了上万字的全局规则，注意力被极度分散，极易出现前后矛盾、遗忘核心业务边界。
  • Token 账单爆炸 ：无论用户问一句多么简单的“你好”，几十条无关的业务规则全量随每一轮对话重复发送，费用呈指数级浪费。
  • 业务域规则互斥与污染 ：跨业务域规则（如“国内退换货规范”与“跨境海外退货流程”）若同时常驻，极易引发模型在判断逻辑上的逻辑打架。

2. 全局 Prompt vs 动态 Skill 深度对比

  • 常驻内存 vs 动态链接库（DLL） ：
    • 全局 Prompt 像电脑的常驻内存，每一轮对话必须死死占据上下文窗口。
    • Skill 像按需加载的动态插件，平时只暴露极简的索引目录（几十个字），只有触发特定场景时才把详尽正文动态载入上下文，任务结束后随对话窗口滑动退出，不长期霸占 Context。
  • 粗粒度泛化 vs 垂直纵深 SOP ：
    • 全局 Prompt 受限于长度，只能写概要原则。
    • 独立的 Skill 拥有充足的空间把规则写得极度详尽、垂直专业，包含所有边界异常处理和输入输出标准。

二、 两种存储与加载架构对比（小项目 vs 大项目）

  • 一句话结论 ：小项目用“本地/云存储 + 字典注册表”求快；大项目用“MCP 工具化 + 渐进式披露”求稳求省。

1. 方案一：小项目架构（本地/云存储 + 内存注册表预加载）

  • 存储位置 ：直接作为 Markdown/文本文件保存在代码目录，或统一托管在云端对象存储中（如阿里云 OSS、字节火山引擎 TOS）。
  • 加载逻辑 ：系统启动时，维护一个内存字典（注册表 Registry），通过启动自拉取或定时轮询将所有 Skill 全量加载到内存，对话时一股脑拼进 Prompt。
  • 适用边界 ：规则极少（10个以内）、单业务域的小型应用。

2. 方案二：大项目架构（MCP 服务封装 + 渐进式披露）

  • 核心难题 ：系统庞大、涉及众多业务域时，Skill 数量成百上千。若全量加载，Token 直接撑爆；若每个 Agent 项目都自己写一套注册表逻辑，重复造轮子且极难集中维护。
  • 解决策略（渐进式披露） ：
    • 能力工具化 ：把“读取和查询 Skill”封装为标准化 MCP 工具服务，部署在中心端。
    • 两段式渐进披露（Progressive Disclosure） ：
      • 第一阶段（看目录）：仅向 Agent 暴露 list_skills 工具，返回轻量的技能名称与一句话功能摘要。
      • 第二阶段（翻正文）：Agent 自主决策判定需要哪项能力后，主动调用 get_skill_detail 工具精准读取对应业务长文本。

三、 两种架构代码实现与对比手册

1. 方案一实现代码：内存注册表 + 全量预加载

skill_registry = {}

def init_skill_registry():
    """系统启动时：从本地文件或 OSS/TOS 全量预加载到内存字典"""
    skill_registry["refund_rule"] = "【退款规则正文】7天无理由退款，包装完好，运费自理..."
    skill_registry["invoice_rule"] = "【发票规则正文】企业发票需提供税号，3个工作日内开具..."

def chat_with_agent(user_query: str):
    """对话时：把注册表里的所有规则全量拼进 Prompt"""
    all_rules = "\n".join(skill_registry.values())
    prompt = f"参考以下所有业务规则：\n{all_rules}\n\n用户问题：{user_query}"

【代码解析】：小项目将注册表简单实现为 dict，对话时无脑拼接全局规则。当技能规模膨胀时，Token 浪费严重且无法支撑多业务域隔离。

2. 方案二实现代码：FastMCP 渐进式披露

from mcp.server.fastmcp import FastMCP

mcp = FastMCP("SkillHub")


SKILL_DATABASE = {
    "refund_rule": {
        "summary": "处理用户退货退款时效及运费承担规则",
        "detail": "【退款详细规则】：7天内未拆封全额退款；质量问题包邮退换；拆封扣10%折旧费..."
    },
    "invoice_rule": {
        "summary": "处理企业专票、普票开具及税号资质核验",
        "detail": "【发票详细规则】：增值税专用发票必须提供一般纳税人资质，每月25日后停止开票..."
    }
}


@mcp.tool()
def list_skills() -> dict:
    """获取所有可用业务技能清单及其简短功能概述（仅返回摘要索引）"""
    return {name: info["summary"] for name, info in SKILL_DATABASE.items()}


@mcp.tool()
def get_skill_detail(skill_name: str) -> str:
    """根据技能唯一名称，按需精准拉取该技能的完整详细操作规则"""
    return SKILL_DATABASE.get(skill_name, {}).get("detail", "未找到对应技能")

if __name__ == "__main__":
    mcp.run(transport="stdio")

【代码解析】：通过分离“查目录”与“取正文”两个 MCP 工具，大模型先快速扫描轻量目录，锁定目标后才精确读取对应长文本，彻底实现上下文按需解耦。

3. 真实运行时交互全过程拆解（以售后咨询为例）

假设用户在聊天界面提问：“你好，我买的车厘子烂了，能全额退款吗？”

  • 第 0 步（初始化：零上下文开销） ：
    • 客户端仅向大模型注入 list_skills 与 get_skill_detail 两个工具的函数定义与说明。
    • 此时模型上下文中完全没有任何业务正文长文本，消耗 Token 几乎为零 。
  • 第 1 步（看目录：轻量索引初筛） ：
  • 第 2 步（翻正文：精准靶向披露） ：
    • 大模型主动发起第二轮工具调用：get_skill_detail(skill_name="fresh_refund_rule")。
    • FastMCP 精准读取并返回生鲜退款详尽细则（如：签收24小时内留证、坏果率超30%全额赔付且无需退回原物）。
    • 长文本正文在这一瞬间才首次且精准地进入模型当前上下文 。
  • 第 3 步（组织回答与即用即弃） ：
    • 大模型根据获取的专业细则给用户提供标准严谨的解答。本轮任务完成后，该长文本随着对话上下文推进自然滑出，绝不长期常驻污染全局记忆。

4. 【核心细节与避坑指南】

  • 细节 1（元数据摘要设计法则） ：
    • list_skills 中的 summary 必须精炼且带有鲜明的触发边界（例如明确说明“适用退款”、“适用开票”），大模型全靠这段几十个字的摘要决定翻哪本书。
  • 细节 2（多 Agent 共享与中心化治理） ：
    • 大项目中，MCP Server 可独立部署在内网云端。客服 Agent、财务 Agent、运营 Agent 只需挂载同一个 MCP 服务，避免在每个项目中重复维护注册表解析逻辑。

四、 架构深思：为什么不给每个 Agent 独立绑定？（多 Agent 分工 vs 技能中台）

  • 一句话结论 ：健康的架构绝不允许单 Agent 强挂百个技能；宏观上“专人专事拆 Agent”，微观上“抽离 MCP 中台共享规则”，二者结合才是企业级终局。

1. 架构师的灵魂质问：专人专事不好吗？

  • 正统的多 Agent 专家模式 ：
    • 在 LangGraph、CrewAI 等多 Agent 体系中，最佳实践本就是“领域拆分”：
      • 客服 Agent ➡️ 只绑定 3 个售后 Skill；
      • 财务 Agent ➡️ 只绑定 2 个发票 Skill；
      • 运维 Agent ➡️ 只绑定 2 个排障 Skill。
    • 结论 ：让一个巨石 Agent 强行背负上百个 Skill，本身就是反模式，必须通过多 Agent 进行领域垂直拆分。

2. 既然已经拆了多 Agent，为什么还要搞统一的 MCP 技能中台？

许多开发者会问：“既然每个 Agent 都有自己的专属技能，各管各的不就行了吗？为什么还要特意把 Skill 抽离出来做成统一的 MCP 服务？” 在大型企业级落地中，主要是为了解决以下三大致命的工程现实痛点：

3. 终局架构：分层协同模型

  • 宏观层（多 Agent 纵向切分） ：严格按业务域拆分 Agent（Supervisor 路由 ➡️ 专属领域 Agent），专人专事，杜绝上下文污染。
  • 微观层（MCP 技能中心横向拉通） ：各个领域 Agent 背后不写死业务规则，而是统一连入企业级 MCP 技能中台，按需做双阶段渐进式披露。

五、 全局大串联 (终极总结)

1. 架构选型决策思维链条

明确业务体量 ➡️ 少于10个规则单业务域？ ➡️ 是：本地文件/OSS + 字典注册表快速落地 ➡️ 否：宏观拆分领域 Agent ➡️ 横向抽象中心化 MCP 技能中台 ➡️ 双阶段渐进披露按需调用 ➡️ 实现单一事实来源与免发版热更新

2. 【终极一句话速记】

“全局 Prompt 筑底线，垂直 Skill 当手册；小项目注册表全量灌，大项目 MCP 渐进翻；专人专事拆 Agent 避混乱，抽离中台共享规则防打架。”