惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

G
Google Developers Blog
酷 壳 – CoolShell
酷 壳 – CoolShell
量子位
C
Check Point Blog
B
Blog RSS Feed
Y
Y Combinator Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
A
About on SuperTechFans
Microsoft Azure Blog
Microsoft Azure Blog
博客园 - 聂微东
阮一峰的网络日志
阮一峰的网络日志
人人都是产品经理
人人都是产品经理
小众软件
小众软件
Last Week in AI
Last Week in AI
博客园 - 【当耐特】
GbyAI
GbyAI
The Cloudflare Blog
博客园 - 叶小钗
S
SegmentFault 最新的问题
博客园 - Franky
Engineering at Meta
Engineering at Meta
F
Fortinet All Blogs
B
Blog
Jina AI
Jina AI

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理,
手把手:如何像训练模型一样,为你的Agent“训练”出靠谱的Skil...
周周粥粥 · 2026-03-26 · via 人人都是产品经理

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

最近人人都在聊Agent,但聊着聊着就歪了——变成了比拼谁家的Agent能一口气写十篇报告、能自动订咖啡。热闹过后,真正能用起来的没几个。

问题出在哪?大家太关注Agent“能做什么”,却忽略了它“做得怎么样”。这就好比招了个员工,只看他简历上写了多少技能,却从不考核他干一件具体活的质量。这些所谓的“技能(Skills)”,根本就没经过系统化的“训练”。它们只是被匆匆“安装”上去的半成品。

今天,我想分享一套自己的方法:

第一步:思维转变

从“LLM”到“Skills”,训练的目标也就随之改变了。

训练一个大语言模型,目标是让它学会“说话”和“思考”的通用模式。而训练一个Skill,目标要具体得多:是在特定上下文、遵循特定规则、调用特定工具,去可靠地完成一个具体任务。

举个例子

  • 训练模型:让它学会“什么是会议纪要”。
  • 训练Skills:让它拿到一段杂乱的会议录音转写稿后,能稳定地提取出“议题、结论、待办事项(含负责人和截止日期)”,并严格地按照公司模板输出。

看,目标变了。前者是认知,后者是合规的执行。你的心态,要从“老师”变成“教练+质检员”。

第二步:拆解与定义

想清楚,你的Skills,到底要“考”什么?

这是最关键的一步,也是绝大多数人直接跳过的一步。上来就写Prompt、调工具,全是纸上谈兵。

你要像做实验一样,为你的Skills制定 《说明书》 ,它必须包含:

1)输入规范Skills启动的“契机”是什么?(用户说“总结会议”?还是收到一个钉钉文档链接?)输入的数据格式、长度、边界是什么?

2)执行流程:这是Skills的“肌肉记忆”。必须拆解成一步一步进行的详细步骤。

  • badcase:“整理会议纪要。”
  • goodcase:① 识别并过滤闲聊、测试语句 → ② 按发言段落切分 → ③ 识别“结论性语句”与“待办动词”(如“跟进”、“决定”、“负责”) → ④ 将待办与发言人、上下文关联 → ⑤ 填充到模板的指定字段。

3)输出格式:是纯文本?还是Markdown表格?还是必须调用某个API返回JSON?格式必须死板,没有商量余地。

4)边界与异常:什么情况下Skills应该坦然承认“我做不到”?(例如,输入是一首诗,而不是会议记录。)遇到模糊信息(如“下周搞定”)是追问还是按规则默认处理?

实战案例:我们训练一个“GitHub Issue 分类”的Skill

  • 输入:一个Issue的标题和正文。
  • 流程:① 提取关键词 → ② 对照内部标签体系(bug/feature/question/docs) → ③ 结合历史相似Issue的分类结果进行加权判断 → ④ 输出分类和置信度。
  • 输出:{“label”: “bug”, “confidence”: 0.92, “reason”: “关键词:报错、崩溃、无法启动”}
  • 边界:如果Issue与代码完全无关,或置信度低于0.6,则标为“需要人工复审”。

如果没有这份《说明书》,那么你后续所有的“训练”都是盲目的。

第三步:构建“训练集”

我们要用正反案例教会它什么效果是“好”

现在,我们可以像准备模型训练数据一样,为Skills准备数据了。但这里的数据,不是海量文本,而是 “任务-执行-结果”的三元组

核心方法:提供“优秀案例”与“争议案例”

1.优秀案例(正例):这是Skills执行的完美范本。每一个优秀案例,都必须与《说明书》严格对应。

  • 输入:一段具体的、真实的(或高度仿真的)任务数据。
  • 期望输出:完全符合格式和质量要求的完美结果。
  • 关键步骤注释(可选但强烈推荐):在复杂步骤旁注明判断理由。例如:“此处将‘小王说要跟进一下’识别为待办,因为‘跟进’是核心动词,且‘小王’是发言人。”

2.争议案例(反例):这是区分Skills水平高低的关键。它教会Skills“不要做什么”。

  • 常见错误:展示了常见错误结果(如格式错误、信息提取遗漏)。
  • 边界问题:展示了边缘情况的处理方式(如模糊输入、信息矛盾)。
  • 安全隐患:展示了如何拒绝不当请求(如输入包含恶意指令或敏感信息)。

那又该如何获取这些案例?

  • 从真实场景中挖掘:让人类专家处理多个真实任务,他们的操作记录和结果就是最好的训练集。
  • 刻意构造“陷阱”:基于你的领域知识,设计出各种“坑”和“陷阱”。
  • 让模型生成初版,我们再修正:这也是一种高效的“数据增强”方式。

第四步:迭代与评估

最后,再对Skills进行质检

Skills训练好了,怎么知道它靠谱?你需要一套评估标准,我称之为 “A.S.S.”标准

  • A – Accuracy(准确性):任务完成得对不对?这是基础。通过与“黄金案例”对比来度量。
  • S – Stability(稳定性):对同一批量的类似任务,输出是否一致、波动小?随机抽样10个“会议纪要整理”任务,看输出质量是否都在同一水准线。
  • S – Security(安全性):是否遵守了所有边界规则?能否抵御提示词注入等攻击?这需要专门用“安全案例”进行测试。

建立你的“Skills测试沙盒”

  1. 1.准备一个包含优秀案例、错误案例、争议案例的测试集。
  2. 2.每次对Skills(或其Prompt、工具调用逻辑)进行修改后,必须在沙盒中跑一遍全量测试。
  3. 3.记录每一次的通过率。目标是:在优秀案例上100%通过,在争议案例上按要求正确处理。

这个流程,就是你的“持续集成/持续部署(CI/CD)”管线。没有这条管线,任何对Skills的修改都是一场危险的赌博。

Skills的应用是一套“组合拳”

当我们谈论训练Skills时,,其实我们最终训练的,是一个可预测、可信任的“行为模块”

单个Skills再强,价值也有限。真正的厉害之处,在于它的可组合性:让“会议纪要整理”工具,自动调用“日历查询”工具,来补全参会人信息,再调用“邮件发送”工具,将纪要发给相关人员。

而要实现安全、可靠的组合,前提是每一个单独的Skill都必须像我们前面说的那样,经过严格的“训练”和“质检”。它的输入输出必须像乐高凸点一样标准、可靠。

所以,别再只盯着Agent的“大脑”(大语言模型)有多聪明了。从现在开始,去训练你的Agent的Skills吧。可靠,永远比炫技更重要。

本文由 @周周粥粥 原创发布于人人都是产品经理。未经作者许可,禁止转载

题图来自Unsplash,基于CC0协议