考察点
这道题出自字节跳动 Agent 开发实习一面（2026 年牛客面经），紧跟在项目深挖之后，属于"你真的动手做过 agent 吗"的验证题。面试官想看的不是你能背出几个 skill 名字，而是三件事：你是否理解 skill 这种"可复用流程知识"的设计动机（为什么不用超长 system prompt）；你的分类和组织方式有没有工程逻辑；最关键的是第三问——skill 和 tool 的边界在哪，这是判断候选人是否理解 agent 架构分层的关键。追问通常会往"skill 召回冲突怎么办""怎么评测 skill 写得好不好"上走。
参考答案
我的 skills 有哪些
我做的 coding agent 里 skill 大致分三类。第一类是流程类 skill，把一套 SOP 固化下来，比如 code-review skill（按 变更意图→正确性→并发/边界→测试覆盖 的顺序走查，输出分级问题清单）、发布前检查 skill（跑 lint、单测、确认 changelog、检查迁移脚本幂等）。第二类是约定类 skill，沉淀团队规范，比如 commit message 格式、错误处理规范（不允许裸 catch、错误必须带 trace ID）、接口文档模板。第三类是工具编排类 skill，把多个工具串成一个常用动作，比如"定位线上问题"skill 会引导 agent 先查监控指标、再按 trace ID 捞日志、最后定位到代码提交。
每个 skill 是一个目录：一个带 front matter 的 SKILL.md（name、description、允许调用的工具），正文写流程，旁边放它引用的脚本和模板文件。
为什么这么设计
核心原因是上下文是最贵的资源，知识要按需加载。如果把所有规范、所有 SOP 都塞进 system prompt，几万 token 的固定开销会挤占真正干活用的上下文，而且大部分知识在大部分任务里用不上。skill 的机制是渐进披露：agent 启动时只把每个 skill 的 name 和 description（几十 token）放进系统提示；模型判断当前任务匹配某个 skill 时，才去读完整正文；正文里引用的脚本、模板又是再下一层，用到才加载。这样一个库里有几十个 skill，常态开销也就几百 token。
第二个原因是可维护性。skill 是普通文件，可以进 git、可以 code review、可以单独迭代，改一个流程不用动主提示词。第三个原因是可组合：skill 里可以声明它依赖哪些工具、引用哪些脚本，天然形成"知识层 + 能力层"的分层结构。
skill 能替代工具调用吗
不能，两者解决的是不同问题，是互补关系。tool 是能力，skill 是知识。工具是结构化、强类型、有确定性语义的执行单元：参数有 schema 校验，行为可预测，有权限边界（比如文件写工具限制在工作目录内），是模型与真实世界产生副作用的唯一通道。skill 是一段流程性知识，告诉模型"在什么情况下、按什么步骤、用什么标准"去做事，它本身没有执行力，最终还是要落到工具调用上。
实践中我的判断标准是：确定性的动作做成 tool，经验性的流程写成 skill。比如"执行 SQL 查询"必须是 tool——需要参数校验、超时控制、只读账号；而"排查慢查询的方法论"是 skill——先 explain、再看索引命中率、最后看锁等待，这是经验不是能力。反过来的误用也常见：有人把流程写进工具描述里让模型每次调用都背一遍，浪费 token；也有人把本该做成工具的动作（比如调内部发布 API）写成 skill 让模型自己拼 curl，失去校验和权限控制，这两种都是设计味道不好的信号。
可能的追问
skill 多了以后召回冲突怎么办？ description 是召回的关键，要写成"什么时候用我"的触发条件式描述，而不是功能罗列；数量到几十上百个时可以加一层检索或按任务域分组，但大多数场景几十个以内靠 description 足够。
怎么判断一个 skill 写得好不好？ 看 trace：agent 在该触发时没触发是 description 问题，触发了但执行走偏是正文问题；好的 skill 还应该带验收标准，让 agent 做完能自检，也让评测有抓手。
skill 和 few-shot 示例、system prompt 规则的区别？ system prompt 放全局不可违反的约束，skill 放按需加载的流程知识；few-shot 是教"格式和风格"，skill 是教"流程和判断"，两者可以共存，skill 正文里就经常内嵌示例。