十、第九步：用评测集验证 Skill，而不是只看一次演示效果很多 Skill 在演示场景里看起来很好，但换一个真实任务就失效。这类 Skill 其实不算高质量。验证 Skill，一般可以分四步。1. 先建立基线先不用 Skill，让 Agent 直接做一次真实任务。记录它会犯哪些错误。比如：漏掉异常场景输出格式不稳定优先级判断混乱编造不存在的业务规则只给结论不给依据忽略高风险操作没有验证步骤输出内容无法执行这些失败样本非常重要。因为它们就是后续 Skill 的评测用例。2. 根据失败样本提取 Skill 初稿不要凭空写 Skill。应该从真实失败里提炼规则。3. 用新会话重新测试为什么要用新会话？因为旧会话里有大量上下文，可能会掩盖 Skill 本身的问题。真正的测试方式应该是：新建会话只加载 Skill输入真实任务看 Agent 是否能稳定完成对比没有 Skill 时的结果如果新会话里效果明显更好，说明 Skill 真的起作用了。4. 持续迭代，直到结果稳定Skill 不是一次写完的。它应该像测试用例、自动化脚本、代码库一样持续迭代。每次发现新问题，都要判断：是不是触发条件不清楚？是不是反模式没写进去？是不是模板不够明确？是不是需要脚本验证？是不是任务本身不适合 Skill 化？最终可以形成一个小型评测集。比如“测试用例生成 Skill”，可以准备这些评测样本：十一、面试时可以这样回答如果面试官问：你的 Agent 系统里 Skill 是怎么编写的？如何保证高质量？可以这样回答：我一般不会把 Skill 简单理解成 Prompt，而是把它看成 Agent 系统中的可复用专家能力单元。我们写 Skill 通常分几个步骤。第一步，先判断任务是否值得沉淀成 Skill。如果一个任务反复出现、具备一定复杂度，并且里面有明显的专家判断，比如边界识别、风险判断、优先级取舍，那它就适合做成 Skill。反过来，如果一句 Prompt 就能完成，或者只是一次性任务，就没必要封装。第二步，提取专家决策逻辑。这里的重点不是把流程写长，而是把判断写清楚。比如什么情况下走方案 A，什么情况下切到方案 B，什么情况下需要停止或者补充信息。同时还会提取反模式，比如不能编造缺失信息，不能跳过验证，不能在高风险操作里直接执行修改。
发布于 北京
分享
评论
赞
未登录
友善发言
评论
加载中
