当前位置：首页 > news >正文

字节面试题：Agent 里的 Skill 到底怎么做才算高质量？

news 2026/6/29 1:09:59

很多人做 Agent 项目，最容易讲成这样：

接了大模型。

加了工具调用。

封装了一些 Prompt。

支持多轮对话和任务执行。

听起来好像没问题，但真到大厂面试里，面试官往往不会只问这些表层能力。

他很可能继续追问一句：

你的 Agent 系统里面，Skill 是怎么编写的？你怎么保证一个 Skill 是高质量的？

这个问题一出来，很多人就容易卡住。

因为如果你只回答：

Skill 就是把常用 Prompt 封装起来。

这个答案基本不够。

在真正的 Agent 工程里，Skill 不是一段更长的提示词，也不是一个漂亮的 Prompt 模板。

它更像是一个可复用、可验证、可迭代的专家能力包。

一个高质量 Skill，至少要回答清楚几个问题：

什么时候应该触发？
什么时候不应该触发？
任务应该按什么流程执行？
遇到边界情况怎么判断？
哪些行为禁止做？
输出结果如何验证？
失败以后如何修正和迭代？
所以，这道面试题真正考察的不是你会不会写 Prompt，而是你有没有能力把专家经验沉淀成系统能力。

一、面试官真正想听的，不是“我会写 Skill”
这道题表面上问的是 Skill，实际上考察的是 Agent 工程化能力。

可以拆成三层：

考察点
面试官真正想听什么
任务抽象能力
你能否判断什么任务适合 Skill 化
专家经验沉淀能力
你能否把人的判断规则写进 Skill
质量保障能力
你有没有验证、评测和迭代机制
所以回答这个问题时，不要一上来就说“我会写 SKILL.md”。

更好的回答方式是：

我不会把 Skill 简单理解成 Prompt 模板，而是把它看成 Agent 系统中的可复用任务能力单元。一个高质量 Skill 应该包含触发条件、专家决策逻辑、反模式约束、资源导航、模板脚本、验证闭环和持续迭代机制。它的目标不是让 Agent 偶尔答得好，而是让 Agent 在一类任务上稳定、可控、可复用地完成工作。

这句话，就是这道题的核心答案。

二、第一步：不是写 Skill，而是判断任务值不值得 Skill 化
很多团队刚开始做 Agent 时，最容易犯一个错误：

什么任务都想封装成 Skill。

最后 Skill 越写越多，Agent 反而越来越难维护。

因为 Skill 不是免费的。

它需要写说明、配模板、放参考资料、维护脚本、做测试验证，还要随着业务变化持续迭代。

所以第一步不是写 Skill，而是判断：

这个任务到底值不值得做成 Skill？

一般可以从三个维度判断。

任务里有没有专家判断？
如果一个任务，熟手和新手做出来差距很大，那它通常适合做成 Skill。

比如测试开发场景里：

根据 PRD 生成测试用例
判断接口测试覆盖是否充分
分析线上缺陷根因
评估自动化用例是否值得写
Review 测试报告是否可信
判断一次发版有没有高风险点
这些任务不是简单执行步骤，而是包含大量经验判断。

新手可能只会根据需求写几个正常流程。

但有经验的测试开发会继续追问：

有没有异常流程？
有没有边界条件？
有没有权限问题？
有没有数据一致性问题？
有没有幂等问题？
有没有灰度和回滚风险？
哪些场景适合自动化？
哪些场景反而不值得自动化？
这些判断，才是 Skill 最值得沉淀的部分。

Skill 的价值，不是让 Agent “照着做”，而是让 Agent 具备接近专家的判断框架。

任务是不是足够复杂？
如果一个任务一句 Prompt 就能说清楚，通常没必要做成 Skill。

比如：

帮我润色这段话。

这种任务直接写 Prompt 就够了。

但如果任务变成：

根据 PRD、接口文档、历史缺陷和业务规则，生成高质量测试用例，并标注优先级、风险点、自动化建议和验收标准。

这就明显复杂很多。

因为它涉及：

输入信息抽取
业务流程理解
测试场景拆解
风险识别
优先级判断
自动化价值评估
输出格式约束
质量自检
这种任务就很适合沉淀成 Skill。

任务会不会反复出现？
Skill 的核心价值是复用。

如果一个任务只做一次，没必要封装。

但如果团队每天、每周都在做类似事情，就很值得 Skill 化。

比如：

每个需求都要写测试用例
每次发版都要做风险评估
每次接口变更都要补充自动化用例
每次线上事故都要做缺陷复盘
每次代码提交都要做质量 Review
这些任务一旦沉淀成 Skill，长期收益会非常明显。

可以总结成一个判断公式：

适合做成 Skill 的任务 =
反复出现

足够复杂
有专家判断
对输出质量有要求
反过来，如果只是简单、低频、一次性的任务，就不要强行做成 Skill。

Skill 不是越多越好，能稳定解决高价值重复问题才重要。

三、第二步：Skill 不是把流程写长，而是把判断写清楚
很多人写 Skill，会犯一个很典型的问题：

把 Skill 写成一大段说明书。

里面写了很多背景、理念、注意事项，看起来很完整，但 Agent 真正执行时抓不住重点。

高质量 Skill 的关键不是写得多，而是写得准。

尤其要提取三类内容：

专家决策树
反模式约束
模板和示例

提取专家决策树
Skill 最重要的价值，是告诉 Agent：

什么情况下走方案 A
什么情况下切到方案 B
什么情况下必须停止
什么情况下需要补充信息
什么情况下只能给建议，不能直接执行
比如一个“测试用例生成 Skill”，不能只写：

根据需求生成测试用例。
这句话太泛了。

更好的写法应该是：

当需求描述包含完整业务流程时：

先生成主流程用例
再补充异常流程
最后补充边界、权限、数据一致性和幂等场景

当需求描述不完整时：

不要编造不存在的业务规则
先标记缺失信息
再基于已有信息生成可确认的用例草稿

当需求涉及支付、权限、资金、删除、审批时：

必须标记为高风险需求
必须补充回滚、审计、重复提交、异常中断场景
这才是真正有价值的 Skill。

因为它不是简单告诉 Agent 做什么，而是告诉 Agent 怎么判断。

提取反模式：明确不要做什么
在 Agent 系统里，“不要做什么”往往比“要做什么”更重要。

因为大模型很容易为了完成任务而过度发挥。

比如：

为了让答案完整，补充不存在的信息
为了快速给结论，跳过验证步骤
为了显得专业，写很多无法落地的套话
为了执行任务，直接修改高风险文件
为了覆盖全面，输出一堆没有优先级的内容
所以 Skill 里必须明确反模式。

例如：

不要把来源不明的信息当成事实写进结果。
不要为了让答案完整，擅自补充不存在的业务规则。
不要在高风险操作中直接修改文件，必须先生成计划。
不要跳过验证步骤直接给最终结论。
不要只覆盖正常流程，必须补充异常、边界、权限和数据一致性场景。
不要输出无法执行、无法验证的空泛建议。
这类约束能明显降低 Agent 的幻觉和误操作。

尤其是在测试开发、代码修改、数据库变更、自动化执行这类场景里，反模式非常关键。

提供模板和示例，保证输出稳定
如果任务对输出结构要求很高，就应该提供模板。

比如测试用例模板：

用例编号	场景类型	测试点	前置条件	操作步骤	预期结果	优先级	自动化建议
如果任务对表达风格、分析深度要求很高，就应该提供示例。

比如缺陷复盘 Skill 可以给出这样的结构：

一、问题现象

二、影响范围

三、复现路径

四、根因分析

五、风险等级

六、修复方案

七、回归验证点

八、后续预防措施

模板解决的是格式稳定。

示例解决的是表达稳定。

两者结合，才能让 Skill 的输出质量更可控。

四、第三步：写 Skill 指令时，要控制上下文成本
一个常见误区是：

Skill 写得越详细，效果越好。

其实不一定。

Skill 不是独占上下文的。

它要和系统提示词、用户输入、历史对话、工具说明、其他 Skill 一起共享上下文窗口。

如果 Skill 里塞满了模型本来就知道的通用知识，反而会浪费上下文。

例如下面这种内容价值就不高：

你是一个专业、严谨、负责的智能助手。
你需要认真分析用户需求。
你需要给出高质量回答。
这些话太通用了。

更值得写进 Skill 的，是任务特有的判断和边界：

当输入缺少业务规则时，不要自行补全。
必须先列出缺失信息，再基于已有内容生成可确认的结果。
涉及资金、权限、删除、审批类需求时，必须提升风险等级。
Skill 里真正值得保留的是：

触发条件
任务边界
专家判断
禁止行为
输出模板
工具导航
验证方式
其他通用废话，都应该删除。

五、第四步：高风险任务低自由度，分析任务高自由度
不同类型的 Skill，对 Agent 的自由度要求不一样。

不能所有任务都用同一种写法。

高风险任务：必须降低自由度
比如：

批量修改代码
数据库迁移
线上配置修改
删除文件
CI/CD 发布
权限策略调整
这些任务不能让 Agent 自由发挥。

Skill 里必须明确要求：

执行任何修改前，必须先输出计划。
计划必须包含修改文件、修改原因、影响范围、验证方式和回滚方案。
未完成计划验证前，不得直接执行修改。
执行后必须运行验证命令。
验证失败必须停止，并输出失败原因和修复建议。
这类 Skill 的核心是：

先控风险，再做执行。

这也是面试里很加分的点。

因为它说明你不是简单“让 AI 干活”，而是知道如何控制 Agent 的行为边界。

分析类任务：保留一定自由度
比如：

技术方案评估
代码 Review
测试策略设计
需求风险分析
内容选题策划
这些任务需要 Agent 有一定分析空间。

如果约束太死，反而会降低质量。

这类 Skill 更适合规定：

必须从风险、收益、成本、落地难度四个维度分析。
必须给出优先级。
不确定信息必须单独标注。
结论必须有依据，不能只给判断。
也就是说：

Skill 不是把 Agent 管死，而是根据任务风险，给它合适的边界。

六、第五步：复杂任务要配工作流，不要让 Agent 自己猜
如果一个任务链路比较长，只靠自然语言描述是不够的。

因为任务步骤越多，Agent 越容易漏。

比如“接口测试用例生成”这个任务，至少包含：

读取接口文档
提取请求参数
区分必填和非必填字段
识别参数类型和边界
分析认证和权限
生成正向用例
生成异常用例
生成边界用例
生成安全测试点
输出自动化建议
如果 Skill 里不写清楚工作流，Agent 很可能只生成一批表面用例。

更好的方式是把流程写成明确的执行链路。

这个流程的价值不在于画图，而在于让 Agent 明确：

每一步做什么
每一步产出什么
哪些步骤不能跳
什么时候需要修正
什么条件下才能输出最终结果
七、第六步：Skill 要分层组织，不要全塞进一个文件
一个成熟 Skill，最好不要只有一个巨大的 SKILL.md。

更合理的结构是：

test-case-skill/
├── SKILL.md
├── references/
│ ├── checklist.md
│ ├── anti-patterns.md
│ └── examples.md
├── templates/
│ ├── test-case-template.md
│ └── risk-report-template.md
└── scripts/
├── validate_cases.py
└── extract_api_fields.py
不同文件承担不同职责。

文件位置
主要作用
SKILL.md
写核心流程、触发条件、资源导航
references/
放详细规则、检查清单、反模式
templates/
放输出模板、报告模板、用例模板
scripts/
放确定性校验、格式检查、数据处理逻辑
这样做有几个好处：

主文件更短
规则更容易维护
细节可以按需读取
脚本负责确定性动作
Agent 不需要每次都消耗大量上下文
这也是 Skill 工程化和普通 Prompt 最大的区别之一。

普通 Prompt 解决的是一次对话效果。

而 Skill 解决的是一类任务的稳定复用。

八、第七步：一定要关注 Skill 的触发质量
很多人只关注 Skill 内容写得好不好，却忽略了一个更基础的问题：

Agent 能不能在正确的时候调用这个 Skill？

一个 Skill 如果触发不稳定，也很难算高质量。

常见问题有两类。

第一类是该触发时没触发。

比如用户明明输入了：

根据这个 PRD 帮我生成测试用例。

但 Agent 没有调用“测试用例生成 Skill”，而是直接用普通对话方式回答。

第二类是不该触发时乱触发。

比如用户只是想简单问一个测试概念，Agent 却误触发了复杂 Skill，开始输出一大堆流程和表格。

所以 Skill 的名称和描述非常重要。

它们不是摆设，而是 Agent 判断是否调用 Skill 的重要依据。

一个好的 Skill 描述，应该写清楚：

这个 Skill 用于根据 PRD、接口文档或业务需求生成结构化测试用例。
适用于需要输出测试场景、优先级、风险点和自动化建议的任务。
不适用于简单概念解释、单句润色或无需结构化测试设计的任务。
注意，这里不仅写了“什么时候用”，还写了“什么时候不用”。

这能减少误触发，提高 Skill 的稳定性。

九、第八步：验证闭环是高质量 Skill 的关键
很多 Skill 效果不稳定，不是因为写得不够长，而是因为没有验证闭环。

一个高质量 Skill，不能只写：

完成后输出结果。
而应该写成：

完成初稿后，必须根据 checklist 自检：

是否覆盖主流程
是否覆盖异常流程
是否覆盖边界条件
是否标注优先级
是否存在编造业务规则
是否存在无法验证的结论
是否给出自动化建议

如果检查不通过，必须先修正，再输出最终结果。
这就是反馈循环。

对于能脚本化验证的内容，最好交给脚本，不要完全依赖模型自检。

比如：

Markdown 表格格式检查
JSON Schema 校验
文件命名规范检查
测试用例字段完整性检查
链接有效性检查
代码格式检查
单元测试执行
可以写一个简单的校验脚本：

import json
import sys

REQUIRED_FIELDS = [
“case_id”,
“scenario”,
“steps”,
“expected_result”,
“priority”
]

def validate_case(case):
missing = [field for field in REQUIRED_FIELDS if field notin case ornot case[field]]
return missing

def main(path):
with open(path, “r”, encoding=“utf-8”) as f:
cases = json.load(f)

errors = [] for index, case in enumerate(cases, start=1): missing = validate_case(case) if missing: errors.append({ "case_index": index, "missing_fields": missing, "fix_hint": "请补齐缺失字段，并确保 steps 和 expected_result 可执行、可验证。" }) if errors: print(json.dumps({ "status": "failed", "errors": errors }, ensure_ascii=False, indent=2)) sys.exit(1) print(json.dumps({ "status": "passed", "case_count": len(cases) }, ensure_ascii=False, indent=2))

ifname== “main”:
main(sys.argv[1])
脚本最好对 Agent 友好：

要求
原因
输出 JSON
Agent 更容易解析
错误信息带修复建议
Agent 能根据反馈自行修正
尽量幂等
避免重复调用导致结果混乱
明确成功/失败状态
方便决定是否进入下一步
能降级就降级
避免一个小问题导致整个任务中断
这就是工程化 Skill 和普通提示词模板的核心差别。

十、第九步：用评测集验证 Skill，而不是只看一次演示效果
很多 Skill 在演示场景里看起来很好，但换一个真实任务就失效。

这类 Skill 其实不算高质量。

验证 Skill，一般可以分四步。

先建立基线
先不用 Skill，让 Agent 直接做一次真实任务。

记录它会犯哪些错误。

比如：

漏掉异常场景
输出格式不稳定
优先级判断混乱
编造不存在的业务规则
只给结论不给依据
忽略高风险操作
没有验证步骤
输出内容无法执行
这些失败样本非常重要。

因为它们就是后续 Skill 的评测用例。

根据失败样本提取 Skill 初稿
不要凭空写 Skill。

应该从真实失败里提炼规则。

Agent 原始问题
Skill 里应该补什么
经常漏异常场景
增加异常场景 checklist
喜欢编造规则
增加“不允许补全缺失业务规则”
输出格式不稳定
增加固定输出模板
结果无法验证
增加验证脚本或自检清单
高风险操作直接执行
增加“先计划，再执行”机制
触发不稳定
优化 Skill 的 name 和 description
这种 Skill 不是拍脑袋写出来的，而是从真实问题中长出来的。