Agent Skills的本质：与工具调用、RAG对比

作者：KAKAKA2026.11.04 12:34浏览量：0

简介：本文围绕“Agent Skills的本质是什么”这一高频疑问，将技能包与函数调用、标准化连接协议、检索增强生成（RAG）三类主流方案进行系统对比，从知识类型、载体结构、执行主体、加载机制、成本与可控性等维度拆解差异，并给出典型场景选型建议与落地注意事项，帮助读者快速判断何时用技能、何时用工具、何时用检索。

一、对比背景：为什么要追问 Skills 的本质

Agent Skills（智能体技能）近期成为智能体领域的热门概念，但许多开发者看完介绍后仍会产生典型疑问：Skills 是不是又一种工具调用方式？它和函数调用、插件、知识库有什么区别？已经有 RAG 和工具调用了，为什么还需要 Skills？

这些疑问的根源在于：Skills 处于“提示工程、上下文管理、工具生态”三者的交叉地带，边界天然模糊。单独看它的形态（一个装着文档的目录），很难判断它到底新增了什么能力。只有把它与相邻方案放在一起对比，才能看清它解决了什么问题、没有解决什么问题。

因此，本文明确对比以下四类对象：

  1. Agent Skills（技能包）：以自然语言指令文档为核心的程序性知识包；
  2. 函数调用（Function Calling / 工具调用）：通过结构化 schema 让模型驱动外部函数执行；
  3. 标准化工具连接协议：业界出现的统一“模型—工具”连接层方案，将外部工具与数据源包装为标准化服务端点；
  4. 检索增强生成（RAG）：将外部知识切片、向量化，按需检索注入上下文。

二、对象定义：它们分别是什么

agent-skills">2.1 Agent Skills

  • 形态上：一个 Skill 通常对应文件系统中的一个目录，核心是一份用 Markdown 编写的入口指令文档（业界常见约定是命名为 skill.md 一类的描述性文件），内容说明“某一类任务的标准做法、执行步骤、注意事项”，并可附带脚本、模板、参考样例等资源。
  • 机制上：智能体平时只在上下文中保留每个技能的一两行简短描述；当判断当前任务与某技能匹配时，才把完整指令文档加载进上下文，必要时再读取附属脚本或参考资料执行。
  • 内容上：传递的是“怎么做”——流程、规范、经验与最佳实践，即认知科学中所说的“程序性知识”。

一句话概括：Skills 的本质是把领域专家经验“文档化、结构化、可按需加载化”的上下文管理方案，而不是新的模型能力接口。

一个示意性的技能文档如下：

  1. # 技能名称：季度经营分析报告
  2. > 描述：当用户要求撰写经营分析、业绩复盘类报告时使用
  4. ## 工作流程
  5. 1. 与用户确认报告范围、时间窗与核心指标口径
  6. 2. 调用数据查询工具获取原始数据
  7. 3. 运行 scripts/clean.py 完成数据清洗
  8. 4. 按"总览—分项—异常—建议"结构成文
  10. ## 注意事项
  11. - 指标口径以知识库《指标字典》为准
  12. - 差异超过 20% 的项目必须在正文说明原因

2.2 函数调用（工具调用）

开发者预先定义函数的名称、描述与参数 schema，模型在对话中输出结构化的调用请求，由应用层执行后将结果回传。它扩展的是模型的能力边界——让模型能够操作外部系统。示意性定义：

  1. {
  2.   "name": "query_order",
  3.   "description": "查询订单状态",
  4.   "parameters": {
  5.     "type": "object",
  6.     "properties": {
  7.       "order_id": { "type": "string" }
  8.     },
  9.     "required": ["order_id"]
  10.   }
  11. }

2.3 标准化工具连接协议

将外部工具、数据源统一包装为遵循同一协议的服务端点，智能体应用作为客户端按标准方式发现与调用。它解决的是接入方式的标准化问题——避免每个工具与每个应用之间重复做点对点集成。

rag-">2.4 检索增强生成（RAG）

把外部文档切片、向量化并建立索引；查询时先检索相关片段，再注入上下文供模型参考。它补充的是模型知道什么——事实性、陈述性知识。

三、相同点分析：它们为何常被混淆

  1. 目标一致：都为了让智能体超越预训练知识与能力的边界，完成更复杂、更贴近真实业务的任务；
  2. 作用路径一致：无论哪种方案，最终都通过“把外部信息注入模型上下文”生效——函数返回值、检索片段、技能指令，最后都以文本形式进入上下文；
  3. 都强调按需：函数按需调用、知识按需检索、技能按需加载，共同目标都是避免上下文超载；
  4. 都需要持续运营：函数要维护接口与权限，知识库要更新与治理，技能要打磨与评测。

正因如此，四者并非互斥的竞争关系，而是同一智能体系统中承担不同职责的层次。

四、核心差异分析

4.1 传递的知识类型不同（最本质的差异）

  • 函数调用传递的是能力（能做什么）；
  • 标准化连接协议规范的是接入方式（怎么连）；
  • RAG 传递的是事实（是什么，即陈述性知识）；
  • Skills 传递的是方法（怎么做，即程序性知识与流程经验）。

这四个问题彼此正交、各管一段，是理解 Skills 本质的钥匙：模型“知道事实、能调工具”之后，仍然可能“不知道这件事的正确流程”，Skills 补的正是最后这块短板。

4.2 载体与结构化程度不同

  • 函数与协议方案是强结构化的：有 schema、类型系统与协议字段，机器可校验，参数传错能被拦截；
  • Skills 是弱结构化的：以自然语言文档为载体，靠描述性约定组织内容，没有强制类型检查；
  • RAG 介于两者之间：切片与向量构成语义层面的“软结构”。

结构化程度直接决定确定性与可控性：函数调用行为确定、结果可校验；技能文档的遵循程度依赖模型的理解能力，属于“软约束”。

4.3 执行主体不同

  • 函数调用与协议方案中，真正的执行发生在智能体之外的应用或服务进程里，是确定性的系统行为；
  • Skills 中，执行主体仍是模型本身——模型阅读文档后“照着做”，附带脚本只是可选的加速与兜底手段；
  • RAG 没有执行概念，只提供参考信息。

这决定了风险模型不同：工具调用的风险集中在接口权限与副作用控制；Skills 的风险集中在“模型是否正确理解并遵循了指令”，需要靠评测而非类型系统来保障。

4.4 加载触发机制不同

  • 函数 schema 通常常驻上下文（或动态注册），模型每一轮都可见；
  • 协议方案在连接阶段发现工具列表；
  • RAG 由查询触发检索；
  • Skills 采用渐进式披露（progressive disclosure）：先只加载所有技能的一行描述，命中任务后再展开完整文档，需要时才读取更深层资源。示意如下：
  1. 启动阶段 → 仅加载各技能的一行描述（极低上下文占用）
  2. 任务命中 → 加载对应技能的完整指令文档
  3. 执行需要 → 读取附属脚本、模板、参考资料

渐进式披露是 Skills 在上下文经济性上的核心设计：把占用方式从“常驻”改为“分层按需”，使得挂载大量技能而不显著膨胀基础上下文成为可能。

4.5 开发与维护成本不同

  • Skills：写好 Markdown 即可上线，开发门槛最低；但“能写”不等于“写得好”，效果高度依赖文档质量，且缺乏编译期校验，需要建立评测集做回归验证；
  • 函数调用：需要编码、部署、鉴权与监控，工程成本较高，但行为确定、可审计；
  • 协议方案：需要服务化改造，一次性投入较大，换来的是多工具、多应用间的复用；
  • RAG：需要数据清洗、切片策略、索引与检索调优，属于数据工程成本。

4.6 组合关系：Skills 常扮演编排层

实践中，技能文档经常“指挥”其他三者：一份技能可以写明“第二步通过连接协议调用数据查询工具，第三步参照知识库的指标口径”。也就是说，在成熟架构中，Skills 往往承担流程编排职责，工具承担执行职责，协议承担接入职责，检索承担知识供给职责。

五、对比表格

维度 Agent Skills 函数调用 标准化连接协议 RAG
解决的问题 怎么做（流程与经验） 能做什么（动作接口） 如何统一接入 知道什么（事实）
知识类型 程序性知识 能力描述 接入规范 陈述性知识
载体 Markdown 指令文档+可选脚本 函数 schema 协议服务端点 向量索引+切片
执行主体 模型（+可选脚本） 外部应用 外部服务 无执行
结构化程度 弱（自然语言约束） 强（类型校验） 强（协议约束） 中（语义检索）
上下文占用 分层按需加载 schema 常驻 工具列表+调用时 检索片段
行为确定性 软约束，受模型能力影响 高，结果可校验 高 取决于检索质量
开发门槛 低（写文档即可） 中高（编码与部署） 高（服务化改造） 中（数据工程）
典型失效模式 误触发、步骤被跳过 参数错误、误调用 连接与鉴权故障 检索不准、内容过时
更适合的任务 流程性、规范类任务 精确事务操作 多工具生态接入 事实问答与查询

六、典型场景选择

场景一：撰写季度分析报告。 步骤多、规范多，而数据查询工具已经具备。瓶颈在“模型不知道正确的分析框架与口径”——Skills 价值最大，把方法论沉淀为技能文档。

场景二：查订单、发起退款等事务操作。 要求精确、可审计、失败可追责——应走函数调用路径，用结构化参数与确定性执行兜底。

场景三：企业内有十几个内部工具要接入多个智能体应用。 重复集成成本高——先建设统一连接协议层，再让各应用复用。

场景四：客服回答产品参数、制度条款。 知识频繁更新、量大且以事实为主——RAG 更合适，注意知识库治理与更新流程。

场景五：财务月结这类复杂业务。 通常是组合方案：技能定义整体流程与检查清单，函数执行各环节动作，协议统一工具接入，检索补充制度口径。

在百度智能云等平台上构建智能体应用时，同样可以借鉴这一分层思路：把领域经验沉淀为可版本化管理的提示词资产与知识库配置，再与工具调用能力组合，逐步形成“经验资产化”的沉淀机制。

七、选型建议

选型时不应问“哪个更好”，而应先定位当前任务的瓶颈：

  • 瓶颈是模型不知道正确流程或规范 → 优先 Skills；
  • 瓶颈是模型做不到某个动作 → 优先函数调用或协议接入；
  • 瓶颈是模型不知道事实 → 优先 RAG；
  • 团队工程能力强、对确定性与审计要求高 → 倾向工具化方案；由业务专家、运营团队主导、需要快速沉淀经验 → 技能化方案上手更快；
  • 大多数成熟的智能体系统最终走向“四层并存”：技能做编排、工具做执行、协议做接入、检索做知识。

八、落地与迁移注意事项

  1. 触发精度：技能描述写得过于宽泛会误触发，过于狭窄会漏触发，描述措辞应与用户真实任务表述对齐，并通过评测持续校准；
  2. 上下文预算：技能数量增多后，描述列表本身也占用上下文，需要控制技能粒度与总量，必要时引入两级索引；
  3. 文档质量决定上限：步骤必须可执行、无歧义，且不能与系统提示词或其他技能相互冲突；
  4. 安全边界：技能附带脚本若会被执行，应配套沙箱隔离、最小权限与关键操作人工确认机制，同时防范将不可信内容写入技能文件带来的注入风险；
  5. 版本管理与回归评测：技能本质是“软代码”，修改没有编译期检查，必须建立评测集，每次改动做回归验证；
  6. 迁移成本：从纯函数调用架构向“技能+工具”混合架构演进时，工具接口通常无需重写，主要成本在流程知识整理与评测体系建设；反向迁移则会损失已沉淀的专家经验，需谨慎评估。

九、总结

回到最初的问题——Skills 的本质是什么？它既不是新协议，也不是新的工具接口，而是把专家经验以自然语言文档形式外置、再通过渐进式披露按需注入上下文的知识承载机制。用一句话归纳四者分工：

  • 函数调用解决“能做什么”；
  • 标准化连接协议解决“怎么接入”；
  • RAG 解决“知道什么”；
  • Skills 解决“怎么做”。

四个问题正交，四类方案互补。做技术决策时，先诊断瓶颈属于哪一层，再决定引入哪类能力，组合使用才是常态——这比争论“谁会取代谁”更接近问题的真相。

最热文章