agent skills rag 違い

做 AI 应用时经常卡在同一个问题上：模型要「会用工具」还是要「懂我的资料」，这两件事到底该用 agent skills 还是 RAG 来解决？很多团队一开始就把两者混着堆，结果调试时说不清是检索没召回还是技能没触发。这篇不重复讲原理，只给判断标准、选路顺序和能直接照着做的落地清单。

做 AI 应用时经常卡在同一个问题上：模型要「会用工具」还是要「懂我的资料」？这两件事该用 agent skills 还是 RAG 来解决？很多团队一开始就把两者混着堆，结果调试时说不清是检索没召回还是技能没触发。这篇不重复讲原理，只给判断标准、选路顺序和能直接照着做的落地清单。

先把一个前提说清楚：agent skills 和 RAG 不是同一层的竞品，一个是让模型「会做事」，一个是让模型「知道事」。真正出问题的团队，多半是没分清失败到底出在哪一层，于是两边都加，链路越来越长，日志越来越看不懂。

先把两者的定位摆正：一个是能力，一个是资料

agent skills

把流程、脚本、调用方式封装成可复用的能力单元，模型按需触发，解决「会不会做某个动作」

RAG

把外部资料切块、向量化、按查询召回再拼进上下文，解决「知不知道某件事」

• 一句话判断：答案在文档里找不到、但流程里有，偏 skills；答案本来就写在资料里，偏 RAG
• 要改外部状态的动作（下单、建单、改文件）只能走 skills 的工具路径，RAG 只读不写
• 反过来，只想要一段引用来源明确的结论，用 RAG 比让模型自己去查更靠谱

选路顺序：先问三个问题，再决定往哪边加

1. 问要什么结果用户要的是「一段结论」还是「一次操作结果」？前者偏 RAG，后者偏 skills。问不清就先看用户的下一步动作是什么
2. 问要不要改状态这个动作要不要写外部系统？要写就得走 skills 的工具路径，并且提前想好幂等键和失败返回
3. 问失败怎么兜底检索失败可以降级成关键词或直接说不知道；技能失败得考虑重试、幂等和人工确认。哪种兜底代价你更能接受，就先把哪边做扎实

三个问题问完，多数场景的答案就出来了。真正需要两者一起上的情况，是「先找事实、再按流程把事实用掉」：RAG 负责把事实找出来，skills 负责把它填进动作的参数里。这时候它们是串联关系，不是二选一，但排障时要能分开看。

落地清单：超时、并发、降级、日志、评测各看什么

• 超时：检索和技能触发分别设超时，别共用一个总超时，否则分不清是召回慢还是工具慢
• 并发与限流：技能调用外部接口会带来并发尖峰，按额度分档排队，具体阈值到 /official-api 和 /ai-status 核对当时的限制口径
• 降级：检索空召回时退回关键词或直接说不知道，技能调用失败时退回人工确认，不要静默重试到超预算
• 日志：一次请求至少要能分出检索耗时、技能耗时、生成耗时三段，不然复盘时只能猜
• 评测：先攒一组小用例，把「该召回没召回」和「该触发没触发」分别记账

评测这块最容易糊弄自己。榜单上的综合数字只能当参考，具体口径和当时的排行去站内 /benchmarks/registry 看，别拿别的任务的分数直接套到自己的场景上。你要的是自己那组小用例的通过率，不是通用榜单的名次。

# 每次请求打三段耗时，便于定位瓶颈
log: {retrieve_ms, skill_ms, generate_ms, fallback: none|keyword|human}

小团队怎么分工：谁管资料、谁管技能

三五人的小团队最容易出现的情况是：一个人既管文档进料又管工具接口，两边都半成品。比较现实的分法是把资料侧和能力侧拆成两条线，交接点是一份明确的字段表。这份表不写清楚，后面一定会在中间加一层转换代码，越加越乱。

• 常见坑一：技能描述写得太笼统，模型该触发时不触发
• 常见坑二：检索结果太长，把技能需要的参数挤出了上下文
• 常见坑三：两边各自重试，叠加起来把预算吃光
• 排查顺序：先看日志三段耗时，再看召回来源字段，最后看技能有没有被触发

分不清失败发生在哪一层，加再多链路也只是把问题藏得更深。