




















Agent技术的讨论正陷入技能堆砌的误区,而忽略了真正的核心——可靠性。本文从思维转变、拆解定义、训练集构建到迭代评估,系统化拆解如何训练出真正可用的Skills。你将学到如何从质检员视角打造合规执行模块,构建可组合的AI能力矩阵,让Agent告别炫技走向真正落地。

最近人人都在聊Agent,但聊着聊着就歪了——变成了比拼谁家的Agent能一口气写十篇报告、能自动订咖啡。热闹过后,真正能用起来的没几个。
问题出在哪?大家太关注Agent“能做什么”,却忽略了它“做得怎么样”。这就好比招了个员工,只看他简历上写了多少技能,却从不考核他干一件具体活的质量。这些所谓的“技能(Skills)”,根本就没经过系统化的“训练”。它们只是被匆匆“安装”上去的半成品。
今天,我想分享一套自己的方法:
从“LLM”到“Skills”,训练的目标也就随之改变了。
训练一个大语言模型,目标是让它学会“说话”和“思考”的通用模式。而训练一个Skill,目标要具体得多:是在特定上下文、遵循特定规则、调用特定工具,去可靠地完成一个具体任务。
举个例子:
看,目标变了。前者是认知,后者是合规的执行。你的心态,要从“老师”变成“教练+质检员”。
想清楚,你的Skills,到底要“考”什么?
这是最关键的一步,也是绝大多数人直接跳过的一步。上来就写Prompt、调工具,全是纸上谈兵。
你要像做实验一样,为你的Skills制定 《说明书》 ,它必须包含:
1)输入规范:Skills启动的“契机”是什么?(用户说“总结会议”?还是收到一个钉钉文档链接?)输入的数据格式、长度、边界是什么?
2)执行流程:这是Skills的“肌肉记忆”。必须拆解成一步一步进行的详细步骤。
3)输出格式:是纯文本?还是Markdown表格?还是必须调用某个API返回JSON?格式必须死板,没有商量余地。
4)边界与异常:什么情况下Skills应该坦然承认“我做不到”?(例如,输入是一首诗,而不是会议记录。)遇到模糊信息(如“下周搞定”)是追问还是按规则默认处理?
实战案例:我们训练一个“GitHub Issue 分类”的Skill。
如果没有这份《说明书》,那么你后续所有的“训练”都是盲目的。
我们要用正反案例教会它什么效果是“好”
现在,我们可以像准备模型训练数据一样,为Skills准备数据了。但这里的数据,不是海量文本,而是 “任务-执行-结果”的三元组。
核心方法:提供“优秀案例”与“争议案例”
1.优秀案例(正例):这是Skills执行的完美范本。每一个优秀案例,都必须与《说明书》严格对应。
2.争议案例(反例):这是区分Skills水平高低的关键。它教会Skills“不要做什么”。
那又该如何获取这些案例?
最后,再对Skills进行质检
Skills训练好了,怎么知道它靠谱?你需要一套评估标准,我称之为 “A.S.S.”标准:
建立你的“Skills测试沙盒”:
这个流程,就是你的“持续集成/持续部署(CI/CD)”管线。没有这条管线,任何对Skills的修改都是一场危险的赌博。
当我们谈论训练Skills时,,其实我们最终训练的,是一个可预测、可信任的“行为模块”。
单个Skills再强,价值也有限。真正的厉害之处,在于它的可组合性:让“会议纪要整理”工具,自动调用“日历查询”工具,来补全参会人信息,再调用“邮件发送”工具,将纪要发给相关人员。
而要实现安全、可靠的组合,前提是每一个单独的Skill都必须像我们前面说的那样,经过严格的“训练”和“质检”。它的输入输出必须像乐高凸点一样标准、可靠。
所以,别再只盯着Agent的“大脑”(大语言模型)有多聪明了。从现在开始,去训练你的Agent的Skills吧。可靠,永远比炫技更重要。
本文由 @周周粥粥 原创发布于人人都是产品经理。未经作者许可,禁止转载
题图来自Unsplash,基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。