背景：多能力 Agent 的挑战
在大语言模型驱动的 Agent 系统中，存在一个核心矛盾：我们希望 Agent 拥有尽可能多的能力，但在任何时刻它只会用到其中一小部分, 同时 Agent 的上下文空间是有限的。
以一个客服系统为例：我们希望它能同时处理订单查询、退款申请、产品推荐、技术支持等多个领域的问题，但在任何一次对话中，用户通常只会涉及其中一两个领域。但是又要支持Agent同时具有这些能力如何在有限的上下文中高效管理这些能力？
三种常见上下文加载方案
方案 1：全量加载
-
核心思路：将所有领域的知识预先加载到 SystemPrompt 中
-
优势：简单直接，无需额外机制
-
局限：上下文占用 15k+ tokens，资源浪费，可扩展性差
方案 2：多 Agent 架构
-
核心思路：每个 Agent 独立加载专业领域知识
-
优势：隔离不同领域的上下文
-
局限：局部看某个 Agent 时，本质上还是全量加载，只是每个 Agent 只加载自己专业领域的知识
方案 3：RAG（检索增强生成）
-
核心思路：通过向量检索动态加载知识
-
优势：灵活高效，按需获取
-
局限：流程性知识检索失真，上下文碎片化，准确率上限 70-80%
问题的本质
这三种方案的困境本质上源于同一个问题：缺乏灵活的上下文加载机制。它们在三个维度上都存在不足：
-
空间维度：无法区分\”必需知识\”与\”潜在知识\”，导致过度加载
-
时间维度：无法实现\”按需加载\”，只能选择\”全量加载\”或\”检索加载\”
-
结构维度：无法保持知识的完整性，在碎片化和全量化之间缺少中间态
用一个类比来说明：想象你是一位电商平台的全能客服，需要处理订单、退款、技术故障、投诉等各类问题。
-
全量加载：就像入职培训时把几十本产品手册、退款流程、技术文档全部背下来，即使用户只是问个快递单号也要承载所有复杂退款规则的记忆负担；
-
多 Agent 方案：就像把你拆分成订单客服、退款客服、技术客服，每通电话都需要\”语音导航\”判断转给谁，用户说不清问题时就在各个专员之间来回转接；
-
RAG 方案：就像有个助手根据用户问题去知识库搜索，但可能搜到过期的退款政策，或者只搜到零散的操作步骤却漏掉关键的前置条件。
我们需要的是：让 Agent 像一个经验丰富的客服一样，脑子里有个清晰的\”目录\”——平时只记住\”退款问题看《退款处理手册》、技术问题看《故障排查指南》\”（元数据），遇到退款咨询时快速调出完整的退款流程和话术（按需加载），碰到罕见的特殊情况再去查阅详细的政策文档（资源按需）。这就是 Skill 机制要解决的问题：让 Agent 知道有哪些知识，需要时才调用，调用时保持完整。
Skill 机制：渐进式披露
核心思想：让 Agent 先知道\”有什么能力\”，需要时再学习\”如何使用\”，而不是一开始就把所有知识装进上下文。
核心定义
Skill（技能） 是一个独立的、可复用的知识和能力单元，包含三个核心组成部分：
1. 结构化指令：用 Markdown 编写的标准作业流程（SOP）
-
定义何时使用此 Skill（触发条件）
-
描述具体的执行步骤（操作流程）
-
说明可用的工具和资源（支撑材料）
2. 资源文件：支撑指令执行的参考材料
-
详细的 API 文档和技术规范
-
使用示例和最佳实践指南
-
模板文件和配置样例
3. 可执行脚本：提供确定性操作的代码
-
数据处理和转换脚本
-
验证和校验工具
-
与外部系统的集成接口
渐进式披露（Progressive Disclosure）
