做 AI 应用落地这一年多我见过最多的一幕是用户每天早上打开助手跟它说同样的话——“按老规矩来”然后助手一脸茫然地反问“您的老规矩是什么”。这就是 Agent 产品最尴尬的处境功能很强却对你的工作方式一无所知。Agent-Skills 这个方向本质上是想解决一件事让 AI 不仅能听指令还能记住你做事的路数把重复性的“怎么干”沉淀成可复用的技能下次你只需要说“按老规矩”它就能把整条流程自己跑完。理解 Agent-Skills 这件事不需要你有多少机器学习基础。你可以把它想象成带新人一个新同学刚入职你手把手带他走了一遍报销流程下次他就能自己走了再走两遍他不仅知道步骤还知道你说过的“发票拍照要拍全”“摘要不要超过二十个字”这些零碎偏好。Agent-Skills 要做的就是把“带新人”的过程搬到 AI 身上——让 AI 从你的每一次操作中学习最终形成一套只属于你的做事方法。这套思路适合谁三类人最值得关注一是自己搭 Agent 应用的独立开发者二是负责团队工具链的工程师三是对 AI 效率工具有兴趣、愿意折腾的产品经理。如果你属于其中任何一类这篇文章值得看完。我会从概念拆解讲到最小系统搭建再把我实操中踩过的坑原原本本摆出来希望能帮你少走几个月弯路。1. 先搞明白Agent 的技能记忆到底记的是什么1.1 记忆分三层事情、方法、风格我在搭建这套系统之前先花了很长时间想清楚一个问题AI 要“记住”的东西到底有哪些如果只是记一些零碎偏好那用一个配置文件就够了但要让 Agent 真正像老员工一样干活需要记的东西远不止这些。我把需要记忆的内容分成三层这个分层贯穿了我后续所有设计。第一层是事实层对应的是“你喜欢什么、你常用什么”。比如你习惯用 Markdown 写周报你的文档都放在某个目录下你的默认语言是中文你周五下午两点要开例会。这类信息是静态偏好相对稳定适合用简单的键值对或者属性表来存。第二层是流程层对应的是“你做一件事的步骤是什么”。比如整理会议纪要的流程是——先转录录音再提取决议项按“结论-背景-行动项”的格式输出最后同步到文档。这类信息是过程性的有先后顺序有分支条件是一连串动作的组合也是整个 Agent-Skills 系统里最核心、最复杂的一层。第三层是风格层对应的是“你说话办事的调性是什么”。比如你回复邮件喜欢直接给结论不喜欢寒暄你的周报里状态描述习惯用“推进中/有风险/已完成”三个词你写的文案偏爱短句。这一层最难量化但它恰恰是“像不像你”的关键。很多个性化系统做到前两层就停了但真正让 Agent 从“能用”变成“好用”的往往是这一层。这三层不是互相独立的。风格层会渗透到流程层里比如同一个整理纪要流程不同用户输出的标题格式和详略程度完全不同事实层又会决定流程层的分支条件比如有人要求纪要同步到邮箱有人只需要存本地。设计技能系统时如果只抓其中一层效果一定会打折扣。1.2 技能的两副面孔显式规则与隐式习惯继续往下拆你会发现“技能”这个东西有两种完全不同的来源。一种来源是你明确告诉 AI 的。比如你说“以后周报就按这个模板来凡是周五下午你就自动生成。”这种技能适合用规则表达明确的触发条件、固定的执行步骤、清晰的输出格式。把它建模成一段结构化描述就可以了本质上是一套“如果-那么”的逻辑。另一种来源则藏在你的操作记录里。你自己都没意识到每天下午三点你会习惯性地打开某个报表、筛选过去二十四小时的异常数据、再把它贴进日报里。这个过程你重复了上百次但从来没有正式对 AI“声明”过。Agent-Skills 系统的价值很大程度上就在于能发现这类你自己都没察觉的隐性习惯然后主动把它变成可执行的技能。这两副面孔决定了系统的两条能力线一条是技能声明让用户可以用自然语言或可视化界面录入规则另一条是技能发现让系统从历史交互日志里自动挖掘重复模式。从我实测的经验看做好前一条能让你很快用起来做好后一条能让你用得久、用得爽。很多现成框架只做了前一条所以用户一开始觉得新鲜用两周就腻了——因为 AI 只会干你教过的事不会主动变得更懂你。1.3 为什么“记住怎么做”比“记住是什么”难得多这里要说一个很多人容易忽略的认知让大模型记住“事实”容易记住“流程”难。记事实本质上是检索问题。你把用户的偏好向量化存进数据库需要时按相似度捞出来再塞进提示词里这事儿就完成了。现在市面上大多数所谓的“AI 记忆功能”都停留在这个层面说白了就是一个增强版的设置中心。记流程则完全不同。一个流程包含动作序列、判断条件、异常处理、输出规范它不是一个可以一次性读取的静态事实而是一段需要在执行过程中逐步展开的程序。更麻烦的是流程常常是隐式的——用户自己都说不清步骤但他们的操作轨迹里就是存在稳定的模式。我打个比方你要是问一个熟练的剪辑师“你怎么剪一支片子”他大概率会告诉你“看感觉”。但他的“感觉”背后其实藏着一套稳定的决策逻辑先选节奏再铺音乐再卡点最后调色。这套逻辑不会用自然语言直接表达出来但你从他的行为数据里能把它提炼出来。这就要求技能系统具备从行为序列中做模式挖掘的能力而这件事的难度比向量检索高了一个量级。理解了这一层你就能看懂我后面为什么把大部分精力花在“技能抽取”而不是“技能存储”上。2. 技能系统的核心架构从交互流水账到可执行菜谱2.1 一条技能长什么样描述、触发、步骤、参数动手写代码之前我做的第一件事是定义技能的数据结构。这个结构我迭代了好几版最早只有“名称步骤”两项后来发现根本不够用。现在我的技能描述文件长这样以整理会议纪要为例skill_id: meeting_minutes_pipeline name: 会议纪要整理 description: 将会议录音和笔记整理为结构化纪要按固定格式输出 version: 3 trigger: type: 混合触发 conditions: - 包含关键词: [纪要, 会议记录, minute] - 模式识别: 每周一至周五 15:00-18:00 且当日有会议日程 priority: high steps: - input: 会议录音文件路径、参会人笔记 - action: 转写录音生成原始文本 - action: 抽取决议项、行动项、风险点 - decision: 若存在需跨部门协调事项则标注待同步 - action: 按模板生成纪要包含结论/背景/行动项/负责人/截止时间 - output: 发送至文档库并通知相关成员 style: tone: 客观简洁 bullet_style: “-” 开头行动项加粗 length_limit: 每节不超过5条 language: 中文 feedback: auto_validate: true validation_rules: - 行动项必须包含负责人 - 截止时间格式必须为 YYYY-MM-DD这个结构里有几个关键设计。首先是 trigger 字段它决定技能什么时候被激活我后面会专门展开。其次是 steps 字段它不是简单的动作列表而是混合了线性动作、分支判断和输入输出定义的执行流程。再就是 style 字段它把前面说的“风格层”显式放进技能里而不是让 AI 每次靠猜。最后是 feedback 字段它描述了这个技能产出的结果要如何自检。划重点技能不是一块静态数据它是“数据逻辑自检规则”的组合体。这也是它跟普通偏好配置最本质的区别。2.2 完整流转链路观察、抽取、验证、注册一个技能从无到有要经过四个阶段。我把这条链路想清楚了之后才发现市面上很多 Agent 框架只做了最后一步——注册也就是让开发者手动写技能定义文件并加载进去。这当然能用但把最关键的学习能力丢掉了。第一阶段是观察。系统记录用户与 Agent 的每一次完整交互包括输入、输出、中间工具调用、用户对结果的修正。注意用户修正这个信号极其宝贵用户把 AI 生成的周报从三段改成了列表这个行为本身就是一条高质量的训练信号说明用户对“正确格式”有自己的预期。第二阶段是抽取。系统周期性地扫描观察日志寻找重复出现的动作序列。举例来说如果用户连续八次都在周五下午触发“获取数据-生成报表-发送邮件”的链路系统就有理由认为这是一个潜在技能。抽取时不只看动作本身还要看环境上下文星期几、时间段、前置事件因为同一串操作在不同上下文里的含义可能完全不同。第三阶段是验证。抽取出的候选技能不能直接上线。我会用一个“回放测试”来验证把这个技能应用到此前的若干次真实交互场景中看它能否还原出用户当时的操作。如果十次里能还原八次以上说明这个模式足够稳定如果只有一半成功率说明模式还没成形或者混杂了多种变体先压着不发布。第四阶段是注册。验证通过的技能写入技能库分配版本号绑定触发条件。注册之后它就变成 Agent 可以主动调用的能力了。同时技能库里的旧技能如果长期不被触发或者频繁被用户否定就会被降权或淘汰。这条链路里我最想强调两个容易被忽视的点一是观察阶段必须记录“用户修正”很多系统只存成功结果导致 Agent 永远看不到自己哪里做得不对二是验证阶段必须有明确的量化标准否则技能库很快会被一堆质量参差不齐的“半成品”塞满。2.3 触发条件技能召回的灵魂技能库里存了几十条甚至上百条技能之后真正见功夫的地方就来了Agent 面对一个新请求怎么知道该用哪条技能我把触发条件分成三类实际使用中需要配合着用。第一类是关键词触发适合用户会明确表达的场景。用户说“帮我发周报”“周报”这个词就直接命中技能 trigger。这类触发实现简单但太死板——用户换个说法“把这周的进展同步一下”关键词就断了。第二类是语义触发适合意图表达多样化的场景。系统先把用户请求做意图理解再跟技能库里的技能描述做语义匹配。这一层能解决“换说法”的问题但也会带来误召回——用户说“下周要开客户会帮我准备材料”系统可能同时匹配到“会议纪要技能”和“方案撰写技能”这时候就得靠优先级和上下文来排。第三类是上下文主动触发这才是 Agent 从“被动响应”走向“主动协助”的关键。系统监控用户的状态信息时间、日程、当前文档、最近的搜索行为判断哪些技能此刻大概率有用。比如周报技能绑定“周五下午”这个时间特征到点就会主动问一句“需要我生成这周的进展同步吗”。实测下来这种主动触发的体验冲击力很强但分寸很难拿捏问太频繁会变成骚扰问太少等于没有。我的做法是设置“安静期”和“频率上限”同一个技能二十四小时内最多主动触发一次且用户连续拒绝三次就自动降频。触发条件的本质是“在正确的时机把正确的技能摆在用户手边”。这一步做不好前面所有学习都白搭——技能库再大召不出来等于零。3. 从零搭一个最小可用的 Agent-Skills 系统3.1 模块划分与数据流概念聊完了上实操。我当初搭这个最小系统前后大概用了一周的空闲时间核心思路是“四条流水线 一个库”采集管道负责记录交互抽取管道负责提炼技能召回管道负责命中技能执行管道负责跑技能流程技能库作为四者之间的公共存储。整体数据流是这样走的每次用户和 Agent 的会话先经过采集管道存成一份结构化的交互日志后台的抽取管道定期扫描日志产出候选技能候选技能经过验证后写入技能库下一次会话进来时召回管道先查技能库看有没有能匹配的技能有就交给执行管道调用。整个过程中所有的“学习成果”都沉淀在技能库里而不是散落在各个模块里。这样设计的好处是每个环节可以独立迭代我后来单独优化抽取算法或召回策略时不用动其他模块。选型方面我用的是 Python 加一个轻量的向量库做语义召回技能描述文件用 YAML 存。没上重型框架也没引入消息队列——最小系统不需要分布式一台开发机完全够用。3.2 采集层先把交互过程完整记下来采集层的目标就一句话不丢信息。很多人做日志只记用户说了什么、AI 答了什么但我要强调下面这几类信息同样关键用户是在哪一步修改了 AI 的输出记录 diff用户否定了哪个建议记录负面信号用户的请求发生在什么上下文里时间、设备、当前任务Agent 调用了哪些工具、工具返回了什么。下面是我采集层的核心数据结构dataclass class InteractionRecord: session_id: str user_input: str assistant_output: str tool_calls: list[dict] user_correction: str | None # 用户对输出的修改可能是空 feedback_signal: str # accept / reject / silent context: dict # 时间、日期、当前文档、日程等 created_at: datetime这个结构里user_correction 和 feedback_signal 两个字段是我后来加上的它们让系统能区分“用户满意地关掉页面”和“用户沉默地自己重写了一遍”这两种截然不同的情况。采集层的代码本身很简单无非是给 Agent 的执行循环加一个钩子每次交互完成后把上述信息落库。真正要注意的是别在采集阶段做太多加工——原始记录越原始越好加工留给抽取层。提示采集阶段有一个隐私相关的坑要提前想清楚。用户的交互记录里可能包含敏感信息我建议在采集层就做脱敏处理比如把文件名、账号等实体替换成占位符并明确设置日志保留周期。别等技术栈搭完了再回头补这块到那时候存量数据要么不敢用要么用起来心里发虚。3.3 抽取层从重复动作里提炼技能模板抽取层是整个系统里最见算法功底的部分但它的核心逻辑其实不难理解找频繁出现的动作序列。我只用了很朴素的“滑动窗口 序列计数”方法没有上复杂的序列挖掘算法效果已经够用。做法是这样把每个用户的交互日志按会话切分在会话内部把动作序列化每个动作记为“工具名 动作名 关键参数”然后滑过一个固定大小的窗口比如三步统计每个窗口序列出现的次数。出现次数超过阈值的序列就是候选技能的原型。def extract_candidate_skills(records, min_occurrences5, window_size3): sequence_counter defaultdict(int) # 把每个会话压成一条动作序列 for session in group_by_session(records): seq [normalize_action(r) for r in session] for i in range(len(seq) - window_size 1): pattern tuple(seq[i:iwindow_size]) sequence_counter[pattern] 1 # 过滤掉出现次数不足的模式 candidates [] for pattern, count in sequence_counter.items(): if count min_occurrences: candidates.append(PatternCandidate(pattern, count)) return candidates这个方法有个很直接的说明效果假设用户每次整理会议纪要都执行“转写录音、抽取决议、生成模板”三步窗口大小设为 3 时这个三元组就会被反复计数最终浮出水面。如果用户的操作每次都不完全一样比如有时多了“发送邮件”这步那窗口大小为 3 时可能计数不够我会再跑一个大小为 2 的窗口把“转写、抽取”这个更粗粒度的模式先抓出来作为技能的骨架再通过其他方式补细节。抽取层的产出不是一个可以直接使用的技能而是一个“候选原型”它告诉我哪些动作经常一起出现但参数和风格还需要从日志里回填。比如从大量记录里统计出用户生成的纪要总是以“结论”开头、行动项总是加粗这些统计结果最终会被填进技能文件的 style 字段。3.4 召回与执行层让技能在正确时机出现技能进了库接下来是召回。我的召回策略是三路并行关键词匹配走一个轻量的规则引擎语义匹配走向量检索上下文触发走一个简单的定时任务。关键词匹配最快也最可控。用户请求里出现技能 trigger 里的关键词直接命中。语义匹配负责兜底把用户请求向量化跟技能库里的 description 向量做相似度计算取 Top 3 候选。上下文触发则是另一套逻辑我在技能文件里给 trigger 增加了时间条件或日程条件比如“周报技能”配置了“周五 15:00 后且用户当日有日程记录”到点就触发。当多路召回的结果不一致时怎么裁决我定的规则是规则命中 语义命中 上下文触发但同时命中多路会有加分。举例来说“生成周报”这句话同时被规则和语义命中那周报技能稳上只被上下文命中恰逢周五下午则技能要带一句确认话术不能直接执行。执行层相对朴素按技能文件里的 steps 逐条展开每一步调对应的工具函数执行到 decision 节点时按条件分支。执行完把结果输出给用户并把用户是否修改、是否满意写回采集层形成闭环。这样一轮跑下来系统就完成了一次“学习-存储-召回-执行-反馈”的完整循环。4. 实战复盘我踩过的坑和排查方法4.1 技能学歪了单次样本导致的过度拟合第一个让我头疼的问题技能抽取时把偶然的一次操作当成了稳定习惯。那时候我的抽取阈值设得太低一个动作序列出现过三次就被注册成技能。结果用户某周三临时用了一次“下载报表-重命名-发到群聊”的流程一周后相同的临时操作又被做了一次系统就认为这是固定流程开始主动推荐。用户被问了一次之后烦了直接关了自动触发。这个问题的根源在于抽取算法只看频率没有审视“样本的多样性”。一次特定时间的特定操作跟跨多种场景反复出现的操作它们的可信度完全不一样。我后来改了两件事一是提高最低出现次数从 3 次提到 5 次二是增加“场景分散度”校验——同一个模式必须出现在至少 3 个不同的上下文里不同日期、不同前序动作才允许注册。排查这个问题的信号也很典型用户开始忽略 Agent 的主动建议或者技能被触发后用户直接说“不是这个”。如果你的日志里这类信号变多先检查召回条件的宽严再回头看抽取阈值大概率是某个环节学到了噪声。4.2 老技能与新习惯打架版本管理怎么搞另一类高频问题用户的工作方式变了但技能库里存的是旧习惯。比如用户前几个月一直用“周报 数据报表”的格式最近换了团队改成“周报 风险清单”但旧技能触发的优先级更高AI 每次还是会生成一份旧的格式用户就得手动改一遍改了几天之后彻底不用这个技能了。这个问题本质上是缺少技能版本演化机制。我的解决方案有两个第一给技能加衰减权重技能每成功执行一次权重上升每被用户手动修正一次权重下降连续一段时间未被触发权重自然衰减。第二当系统发现某个技能被频繁修正时自动生成一个“候选新版本”并记录修正产生的 diff积累到一定量之后提示用户“我发现你的周报格式有了变化要不要把默认版本升级一下”版本管理最关键的认知是技能不是越老越权威而是越新越贴近当前习惯。技能库的设计要默认接受变化而不是把每条技能当金科玉律。4.3 召回翻车触发条件太宽或太窄召回这块的坑几乎都出在触发条件的“度”上。太宽的例子我给“会议纪要”技能配了包含“会议”关键词的触发结果用户说“明天别安排会议”时技能也蹦出来明显误伤。太窄的例子技能 trigger 写了“生成周报”用户换个说法“把本周进展同步一下”技能就沉默了。针对太宽我引入了否定识别触发前先判断用户请求里是否包含否定意图例如“不用”“取消”“别”有就直接跳过技能触发。针对太窄我依赖语义召回兜底不再强求规则覆盖所有说法。另外我还有一个教训触发条件的权重设计要留余量宁可让技能多确认一次也不要让它妄自行动。主动触发一律带确认规则触发直接执行还有个隐含前提——这个技能的历史准确率要高低于某个阈值时规则触发也降级为“建议使用”。4.4 一张问题排查速查表把这些坑总结成一张表方便你对照排查现象可能原因排查手段解决方案技能从不被触发触发条件太窄 / 语义索引未构建查看召回日志确认三路召回的命中情况扩展同义词补充语义召回通道技能频繁误触发触发条件太宽 / 否定未识别统计误触发的上下文特征引入否定识别降低上下文触发频率技能学到的模式明显不对抽取阈值太低 / 样本场景单一查看候选技能的样本来源分布提高阈值增加场景分散度校验用户频繁手动修正输出技能风格字段缺失 / 版本过旧比较修正 diff 与技能输出的差异补充风格配置启用版本衰减技能库越来越大但命中率低缺少淘汰机制检查技能触发次数分布设定最低触发频率定期清理冷技能这张表看起来简单但每一条都是实打实用调试时间换来的。尤其是最后一条很多人舍不得删技能最后技能库变成了一堆僵尸规则系统越跑越慢召回准确率越来越低。5. 进阶玩法让技能跑得更远5.1 技能拆解与组合技能库到了一定规模你会遇到一个有意思的问题一些大型技能其实是若干子技能的组合。比如“生成季度汇报”这条技能内部就包含了“整理项目进度”“生成数据图表”“按模板排版”三个子流程。如果把大技能整个存下来每次触发的信息量和灵活度都不够好但如果拆成原子技能再通过编排层把它们串起来效果会好很多。拆解后的另一个好处是组合能力用户可能复用了“整理项目进度”这个子技能——做月度同步时也用做周报时也用。这时候 Agent 学到的就不再是某一条大流程而是一个可以拼装的技能积木库。我试过在这个维度上继续做“技能依赖图”可以很直观地看到哪些子技能是高频复用的基础件哪些是偶发场景的专用件。根据这个图来优化比凭手感调整技能库靠谱得多。5.2 技能质量评估和淘汰技能越攒越多迟早要面对一个问题怎么知道哪些技能真的有用我给每条技能维护了三个指标触发率被召回的次数占总请求的比例、成功率被执行后用户没有修改或否定的比例、新鲜度最近一次成功执行距今的时间。三个指标综合出一个健康分定期扫描低于阈值的技能要么降权、要么下架、要么提示用户重新定义。这里有个容易被忽略的原则淘汰技能不等于删除技能。我更推荐把低健康分的技能挪到“休眠区”归档保存但不参与召回。因为用户的工作节奏经常是季节性变化的——季度末那套报表流程平时没人用季度末又会复活。直接删掉太可惜休眠区既能避免干扰又能随时唤醒。5.3 从个人技能到团队沉淀最后一步跨出去Agent-Skills 的价值会发生质变把个人技能变成团队的公共资产。同样是“整理客户反馈”一个人有一个人的格式偏好但团队总有一个“最合适”的版本。如果每个成员的 Agent 技能库可以共享和模板化新人入职时甚至不用问“周报怎么写”直接继承团队技能库就行。实现层面我的做法是给技能文件增加一个 sharing 字段标记是“个人技能”还是“团队模板”。团队模板由资历较深的人维护其他成员可以在模板基础上做个人化覆盖。这本质上把“技能库”变成了一个轻量的知识管理系统而它的独特之处在于这些知识不是静态文档而是可直接执行的流程定义。我个人觉得这可能是 Agent-Skills 最有想象力、也最值得长期投入的方向——让组织里那些“只有老人才知道怎么做”的隐性经验真正沉淀下来并自动运转。把话说回开头那个场景。真正让我觉得这个方向值得做的时刻是我连着三周在周五下午什么都没说系统就自己把周报生成好、发出来、还按我最近的说话习惯改了措辞。那一刻的感觉不是“工具好聪明”而是“它终于开始懂我了”。Agent-Skills 说穿了就是试图把人和 AI 的关系从“发号施令”变成“配合默契”。这条路我还在走中间踩过的坑前面都写了希望你的步子能比我利索一点。如果你也在折腾类似的东西欢迎把你这边的实操经验整理出来——这种让 AI 记住工作方式的探索自己闷头做会走很多弯路互相交换心得能省太多事了。