AI 面试热题 · · 知识放哪

你去面蚂蚁的 Agent 开发岗，简历上写着一个客服 Agent 项目，手上有一整套资料：产品文档、各类目的退款政策，还有一份客服处理退款的操作流程。面试官问你，这些资料哪些该放进 RAG 检索，哪些该整理成 Skill。

这里的 RAG 是先按问题去资料库里检索相关片段，再交给模型回答。Skill 是给 Agent 准备的一个文件夹，核心是一份写着“遇到什么事、按什么步骤做”的说明文件，还可以带脚本和参考资料。

面试官提问

哪些知识适合用 RAG 动态检索，哪些更适合整理成 Skill 给 Agent 用？你依据什么来选？

直接回答：先别在两者之间二选一，先把这份资料拆开看。两者的区别，在于一份知识什么时候、以什么样子进到模型的上下文里：Skill 平时只露一段描述，用上时整份做法一起读进来；检索每次按问题挑回几块事实片段。

每次都必须遵守的规则，比如超过一定金额必须人工审批，要常驻在 AGENTS.md 这类每次都会自动加载的说明里，不能指望模型自己想起去读。讲怎么做、要按步骤做完的流程，写成 Skill。量大、常变、要看问题才知道用哪条的事实，比如各类目的退款时限，留给检索。

退款资料这样几样都有的，就拆开放：审批红线写进常驻说明，处理步骤写进 Skill，Skill 里写清该去知识库查哪类条款、查不到怎么办，条款本身留在知识库里。

01大多数人怎么答的

典型回答一
“RAG 管知识，Skill 管能力。”

典型回答二
“Skill 是新东西，把业务文档都改写成 Skill。”或者反过来：“全部灌进向量库，让 Agent 自己检索。”

第一种方向没错，可停在了口号上。面试官接着问一份退款政策算知识还是能力，就答不上来了，因为它两样都有：退款时限是事实，核实订单、判断责任是做法。

第二种答法，不管是全写成 Skill 还是全灌进向量库，都是把所有资料放进同一种地方，两种都会出问题。

Vercel 把 Next.js 的框架文档做成 Skill 来测，56% 的用例里 Agent 根本没去读它，通过率 53%，和完全不给文档一样。一篇分析了 8,135 条试验记录的论文也发现，Skill 起作用的情况里，65.7% 是帮 Agent 把操作步骤做稳，只有 4.5% 是给它补上缺的事实。

全灌进向量库也有问题。检索拿回哪几块，看的是片段和问题像不像。用户只问一句“这单能退吗”，“超过一定金额必须先人工审批”那一块和这句话不太像，就可能没被检索回来，审批这一步也就被跳过了。

02整份读进来，还是挑几块

Skill 是分三层加载的：

启动时：只放名字和描述
Agent 启动时，只把每个 Skill 的名字和一段描述放进系统提示，每个 Skill 大约占 100 token。

用上时：读正文
模型判断这次用得上，才去读 Skill 的正文。Agent Skills 规范建议正文不超过 5000 token。

用到时：参考文件和脚本
正文里提到的参考文件，要模型真去读了才会进上下文。附带的脚本由 Agent 去执行，进上下文的只有运行结果，脚本本身不进。

所以要不要用 Skill，是模型看着那段描述决定的。Anthropic 文档里是这么分的：要模型灵活判断的写成说明文字，要求每次结果都一样的写成脚本，要查的事实放进参考文件。

检索是另一条路。传统 RAG 由程序在模型回答之前，按这次的问题检索出片段、塞进上下文；在 Agent 里，它也常被做成一个检索工具，由模型自己决定什么时候去查。

所以两边都可能由模型决定去拿，差别在拿回来的东西。Skill 一旦用上，就是一整份做法；检索拿回的是和这次问题最像的几块片段，没拿回来的部分，模型根本看不到。

03先拆开，再按顺序问

拿到一份资料，先看它是不是规则、做法、事实都混在一起，是就先拆开。拆出来的每一块，再按下面的顺序问，前一个问题答“是”，就不用往下问了：

① 每次都必须遵守、不用就会出错？
答“是”：常驻说明（AGENTS.md、CLAUDE.md）

② 讲的是怎么做、要按步骤做完？
答“是”：写成 Skill

③ 是事实，量大、常变、每次只用一小块？
答“是”：走检索

① 为什么要常驻
放在 AGENTS.md 里的内容，Agent 每一轮都看得到，不用它自己决定去读。

Vercel 在 AGENTS.md 里常驻的是一份 8KB 的文档目录，不是完整文档，只写着各主题的文档放在哪个文件。Agent 需要时照着目录去读原文，这样做的通过率是 100%。AGENTS.md 对 Agent 做的每件事都生效，每次请求都占着上下文，所以里面只放红线和这类目录。

② 做法为什么写成 Skill
要按步骤做完的流程，只在处理这类事时用得上。把它写成 Skill，平时只占一行描述。用上时，整套步骤一起读进来，不会只拿回其中几步。

价格、阈值、政策条款常改，写进 Skill 就得跟着一遍遍改 Skill，所以 Anthropic 要求别把会过时的信息写进去。

③ 事实也不是一律走检索
几张表的结构、字段含义这类事实小而稳定，又只有这个流程用得到，可以做成 Skill 的参考文件。Skill 正文里写明什么情况下去读哪个，这些文件跟着 Skill 走，Skill 没被调用就读不到。

另一种常驻：整库放进提示
连整库资料都可以常驻，不只是红线和目录。条件是这个应用几乎每个请求都要用这份资料，整库又小于约 20 万 token。Anthropic 的说法是，这大约相当于 500 页资料，可以整库放进提示，配合提示缓存更快也更省。

这样做换来的是不会检索漏。资料再大，或者每次只用得上其中一小块，才值得做检索。

04两边各自会卡在哪

Skill 这一侧：描述会被挤掉
Skill 能不能被用上，全看那段描述。Claude Code 给所有 Skill 的描述只留了上下文窗口 1% 的位置，装不下时，它会从最少用的 Skill 开始把描述丢掉。丢掉的正是模型拿来匹配的关键词，这个 Skill 也就不会被调用了。

检索这一侧：切块丢了上下文
一句“营收比上季度增长 3%”单独切出来，看不出是哪家公司、哪个季度。Anthropic 试过给每一块补上它在原文里的上下文，再同时用向量和关键词去检索，检索失败的次数比原来少了 49%。再把检索回来的片段按相关程度重新排一次序，失败次数一共比原来少了 67%。

所以选了检索，就得在切块上花功夫；选了 Skill，就得管住描述的长度和措辞。

05一套客服插件的拆法

Anthropic 开源过一个 customer-support 插件，里面打包了几个客服用的 Skill 和接客服平台的连接器，它就是先拆开再分别放的。

Skill 里只写流程
ticket-triage 负责给工单分类、定 P1 到 P4 的优先级、查重，再决定交给哪个团队；customer-research 按知识库、历史工单的顺序逐级查来源，给答案标上置信度，查不到就明说，请人确认。

事实留在外面
产品文档、runbook、FAQ、政策文档都不写进 Skill，通过知识库和客服平台的连接器去查。

套回开头那份退款资料，可以拆成三份（示意）：

这样拆开以后，政策改了只用改知识库，流程改了只用改 Skill，两边互不牵连。

06面试官追问链

追问 1

你把退款流程写成 Skill 了，可 Agent 就是不去调用，怎么办？

当场这么答：我会先看描述还在不在列表里，再看描述里有没有用户会说的词，最后看常驻说明里有没有写明什么时候调它。

每次都必须用的知识，干脆别做成 Skill，直接常驻。

描述还在不在　就是 04 节说的预算问题。描述被挤掉了，就合并或删掉一些 Skill，把描述写短。

关键词对不对　Claude Code 文档的排障建议，是检查描述里有没有用户自然会说的词。示意对比：写“处理客服工单”太空；写“用户来问退款、退货、换货时，先查订单，再按类目查退款规则”，就带上了用户会说的词。

在常驻说明里写明什么时候调用　Vercel 在 AGENTS.md 里加了一句指令：写代码前先看项目结构，再调用 nextjs-doc 这个 Skill 查文档。触发率升到 95% 以上，通过率到 79%，但仍不如常驻文档目录的 100%。

追问 2

你怎么证明这份退款资料这样分是对的，而不是全放检索或全写成 Skill？

当场这么答：拿同一批有标准答案的历史工单，跑四组对比。前三组分别是不给资料的基线、全放检索、全写成 Skill。第四组先把资料拆成规则、做法、事实，再分别存放。最后比较每组的通过率。

为什么要基线　Vercel 那次，做成 Skill 的通过率和完全不给文档一样，没有基线就看不出这份 Skill 其实没起作用。所以先测不带 Skill 时的表现，记下它错在哪，再写最少的内容去补。SkillsBench 是一套专门测 Skill 有没有用的评测，它就是这样配对测的：同一批任务，带上精心写的 Skill，平均通过率从 33.9% 升到 50.5%。

还看过程　除了通过率，还要看 Skill 该用的时候有多大比例真被调用了，这叫触发率。检索这边，看该找到的片段有多大比例没找到，这叫检索失败率。

追问 3

Skill 越写越多，上百个以后怎么办？

当场这么答：先合并描述相近、处理同一类请求的 Skill，删掉评测里从没被触发的，再考虑像检索文档那样去检索 Skill。

为什么　要是客服团队给每类工单各写一个 Skill，退款、退货、换货的描述就会越写越像。有研究把库从几个有用的 Skill 扩到 202 个，通过率最多降了 21%，主要原因是选错了 Skill，而不是上下文变长。

怎么测　要检索 Skill，就用真实用户的请求去测命中率。自己编的测试问题，容易照搬 Skill 描述里的词。一篇论文里，这样测出的命中率最多虚高了 44 个百分点。

07本题总结

一句话总结

RAG 和 Skill 的区别，在于一份知识什么时候、以什么样子进到上下文：Skill 用上时整份做法一起读进来，检索每次按问题挑回几块事实。所以先把资料拆开，每次都必须遵守的规则常驻，要按步骤做完的流程写成 Skill，量大常变的事实走检索，Skill 里写清去哪查、查不到怎么办。

面试锦囊

先说：Skill 平时只有名字和描述在上下文里。模型看描述决定用不用；一旦用上，整套步骤就一次读进来。检索每次只按问题拿回几块事实片段。所以要按顺序做完的流程写成 Skill，量大、常变的事实留给检索。

再说：每次都必须遵守的规则不能做成 Skill 等模型去读，要常驻在 AGENTS.md 这类说明里。Vercel 测过，框架文档做成 Skill 时，56% 的用例 Agent 根本没去读，通过率跟不给文档一样；换成常驻的文档目录，通过率是 100%。

最后补：退款资料这类混合的知识，要拆开放，红线写进常驻说明，条款留在知识库，处理步骤写成 Skill。分得对不对，就拿同一批历史工单，比较不给资料、全检索、全 Skill 和拆开放这几组的通过率，再看触发率和检索失败率。