考察点
小美 Agent 岗问 Skill,是因为这个团队的工作方式就是围绕 Agent 能力做拆解和封装。面试官想确认三件事:你是不是真在 Agent 工程里干过(Skill 这个词在 Claude Code、Coze 等体系里有具体含义,不是背概念能糊弄的);你有没有「把重复劳动沉淀成可复用能力」的习惯;你能不能说清 Skill 和 Prompt、Workflow、工具调用的边界。追问通常会落到「你封装过什么具体的 Skill」「怎么判断一个卡点值不值得封装」「Skill 之间冲突怎么办」。
参考答案
Skill 到底是什么
我的理解是:Skill 是「一组完成某类任务的上下文资产」,打包了任务说明、操作步骤、约束条件和必要的参考材料,在 Agent 判断需要时被加载进上下文,指导模型完成这一类任务。它和三个相近概念的区别要拎清:Prompt 是一次性的指令,Skill 是可复用、可版本化的任务手册;Workflow 是确定性的流程编排,分支是写死的,Skill 是指导性的,模型在执行中仍有判断空间;工具调用(Function Calling)是给 Agent 一双手去够外部系统,Skill 是给 Agent 一份经验,告诉它这双手该怎么用。一个 Agent 的能力上限看模型,下限看 Skill——大部分线上翻车不是模型笨,是该给的经验没给够。
什么卡点值得封装
我判断一个卡点值不值得封装成 Skill,看三个信号。第一是重复频率:同一个任务一周出现三次以上,且每次都要人工补充同样的背景信息,这就是封装信号。第二是经验可描述:这件事的「正确做法」能不能写成步骤和判断标准?能写清楚就能封装;完全依赖个人品味的事(比如「写得更有灵气一点」)封装了也没用。第三是出错有代价且模式固定:比如每次发版都要按固定顺序检查七八项配置,漏一项就出事,这种最适合封装——Skill 的价值不只是提效,更是把易错点固化下来。
举两个我自己封装过的例子
一个是「周报生成 Skill」。卡点在于每次写周报都要从四五个系统捞数据、按老板的偏好组织成「进展-风险-下周计划」结构,纯体力活。封装时把数据源查询方式、结构模板、措辞约束(比如数字必须有环比)都写进去,之后一句「生成这周周报」就能拿到八九成可用的初稿,人工只补判断部分。另一个是「竞品更新速览 Skill」,固定监控几家竞品的更新日志和财报电话会纪要,按「新功能/价格变动/战略信号」三类归纳,每周自动出一份摘要。这类信息收集+格式化归纳的任务,是 Skill 收益最高的区间。
封装 Skill 的几个实操经验
一,Skill 的描述(什么时候该被触发)比内容本身更值得打磨,描述写歪了,要么不触发要么乱触发,这是新手最常踩的坑。二,内容里多给「判断标准」少给「话术模板」,模板会让输出僵化,判断标准能让模型在新情况下仍然做对。三,Skill 要像代码一样管理:版本化、有 owner、定期回顾——业务规则变了 Skill 没跟着改,Agent 就会拿着过期的经验一本正经地犯错。四,别贪多,一个 Skill 干一件事;塞了三件事的 Skill,触发准确率和执行质量都会掉。五,别把大段知识塞进 Skill,事实性内容(产品文档、费率表)放知识库检索,Skill 里只写「去哪查、怎么用」——知识会过期,经验不过期,混在一起维护成本翻倍。
可能的追问
- Skill 和把流程写成 Workflow 怎么选? 答:分支能枚举、错了代价高的走 Workflow,比如退款审批;路径灵活、需要语义判断的用 Skill,比如内容归纳。实务上经常混用:Workflow 定主干,节点内部挂 Skill。
- 多个 Skill 触发条件重叠怎么办? 答:先反思是不是拆得不对——重叠通常说明边界没划清。真要共存,就在 Skill 描述里写清互斥条件,或者用一层路由先做意图归类再加载对应 Skill,别让模型自己在一堆相似描述里猜。
- Skill 的效果怎么评估? 答:建一个该任务类型的评测集,对比封装前后的任务完成率和人工修改比例;我自己的经验是,好的 Skill 上线后这类任务的人工介入率应该降一半以上,降不到说明封装质量有问题。
- Skill 会让 Agent 变慢变贵吗? 答:会占上下文,所以 Skill 要按需加载而不是全量常驻,内容也要克制——一个 Skill 控制在几百到一两千 token,把详细参考材料放外部检索,用的时候再取。