9月16号的技能榜一出来群里就聊开了。以前大家讨论的还是“哪个模型推理强”现在问的是“这个技能你接到Agent里没”。这周榜单和上周相比变化比想象中大新上榜的几乎都是冲着解决具体问题去的纯炫技型技能明显少了一圈。如果你也在做Agent类应用或者正在纠结该把哪些能力沉淀成可复用技能这份周榜值得停下来多看两眼。以下榜单数据来自主流技能市场、开源社区公开仓库和几个活跃开发者社群的本周热度汇总我在整理时额外滤掉了一周内发布但尚未积累真实调用的条目尽量让排名反映真实使用热度而不是发布热度所以它和单纯按GitHub Star数排序的榜单一眼就能看出差别。1. 9月16日当周热门SKILLS总榜速览先上总榜。这次我用热度指数来排序综合了调用次数、开发者反馈、一周新增安装量、升级频率、上下文召回率、公开测试用例覆盖度等维度权重上适当加大了一周内新增调用的比例为的是让真正在被人用的技能浮出来。排名技能名称适用场景热度指数本周变化1多表查询助手数据分析98.6上升5位2周报/日报一键生成效率办公97.2上升2位3会话情绪识别与建议客服支持96.8新上榜4合同摘要与风险点提取法务助手95.4上升1位5会议纪要到任务清单项目管理94.7新上榜6代码评审助手研发效能93.9下降1位7多语言本地化翻译出海业务93.0新上榜8数据图表描述生成报告写作92.6上升3位9产品需求文档初稿生成产品经理91.8下降2位10日志异常定位与修复建议运维监控90.5新上榜几个值得注意的信号我先点一下。第一本周新上榜的四个技能没有一个是“聊天向”的全是任务型、工具型、分析型这说明技能市场正在从“会聊天”走向“能干活”。第二排名靠前的技能都在解决数据流转问题不管是从表格取数、从会议纪要取任务还是从日志里取异常核心都是把散落的信息结构化。第三上一周霸榜的通用对话增强类技能这周普遍回落开发者对“万金油”型技能的新鲜感在快速消退大家开始觉得“能解决一个具体问题”比“什么都能聊”更有价值。这份总榜适合谁看我的建议是有三类人值得逐条研究正在做Agent产品、需要给Agent挑选基础能力的开发者企业内部做AI工具选型想快速判断当前主流方案的人以及刚接触技能生态、想找一个学习切口的新人。前三名技能尤其适合作为第一个接入Agent的试点。2. 从排名变化看趋势这周的好技能都在往“干活”方向挤如果你只看排名本身会错过榜单里最值钱的信息。我把这周和上周的数据放一起对比之后发现三个明确趋势背后其实是技术选型和产品思路的变化。2.1 场景化技能成了绝对主流单一提示词模板不再能打可能有人觉得技能不就是把一个提示词封装起来吗如果你还这么想真得重新看了。这周榜单前十里面除了一两个通用型技能其余全部绑定了一个明确场景多表查询、合同摘要、会议纪要到任务清单、日志异常定位。这种场景化技能的典型特征是可以独立完成一个“输入到输出”的闭环而不是只负责对话里的一段话。举个例子“会议纪要到任务清单”这个技能新上榜我看了一下它的实现思路输入是会议录音转写文本或文字纪要输出不是简单的摘要而是一个结构化的任务表里面包含责任人、截止时间、关联需求、风险等级。要做到这一步技能内部至少拆了四个阶段先识别参会人和发言片段再提取带有动作含义的语句然后把动作归到具体责任人最后还要判断时间词是“下周”“周五前”还是“尽快”这类相对表达。这已经不是一个提示词能搞定的事了而是典型的“采集-清洗-结构化-输出”流水线。我给要做技能的同学一个建议与其做一个无所不能但边界模糊的技能不如把一个场景做到“用户拿到输出就能直接用”。榜单已经给出了答案本周热度上升最猛的就是场景清晰度最高的那批。2.2 上下文管理能力决定了技能上限多数热门技能都在做同一件事第二个趋势更技术向。拆开这周前十名技能的内部实现我几乎在每个技能里都看到了同一个核心逻辑怎么在有限的上下文窗口里只保留最该让模型看到的信息。多表查询助手就是一个典型。它的输入可能是一堆Excel文件或者数据库表结构信息如果全量塞给模型几十张表的结构说明就能把上下文窗口撑爆。我看它的设计是先做表结构扫描自动生成一份精简的“表字段字典”只保留表名、关键字段、字段类型、表间关联关系然后让模型基于这份字典生成查询逻辑。这本质上是把“理解数据”和“执行查询”分离了用工程手段减少模型需要关注的信息量。同样的思路也出现在“合同摘要与风险点提取”里。一份合同动辄几十页它不会把全文直接丢给模型而是先按章节切块先用规则把乙方、甲方、金额、期限、违约责任这些实体抽出来再让模型在关键段落上做精读。这么做有两个实打实的好处一是上下文占用大幅下降长文档也能在有限窗口里处理二是错误率降下来了因为模型看到的是被筛选过的关键片段而不是夹在无关条款里的信息。如果你自己设计技能我强烈建议先把上下文管理画成一张流程图标清楚哪些步骤用规则、哪些步骤用模型、哪些步骤需要汇总。你会发现一张清晰的上下文流向图比调参管用得多。2.3 轻量与可插拔小团队也能用上大技能还有一个比较隐蔽的趋势就是上榜技能对底层模型的要求明显在往“轻量可用”的方向走。注意看这周排名靠前的技能几乎没有必须依赖超大参数模型的很多技能明确要求只要支持Tool Calling或Function Calling的中小规模模型就能跑通。这意味着什么技能市场正在把“大模型能力”和“具体场景能力”解耦。过去我们要做一个合同摘要功能可能得微调模型小团队基本折腾不动。现在只需要找一个做过类似场景的成熟技能租一个还行的模型接口就能做到七十分的效果。这周“日志异常定位与修复建议”新上榜也是这个逻辑它把日志解析、异常聚类、规则过滤这些重活放在传统代码里完成大模型只负责最后一公里的推理和解释所以整体资源消耗并不高。可插拔则是另一个关键词。我观察这周热门技能的作者们都在做“标准描述文件”把技能的输入参数、输出格式、需要的工具列表写成统一结构。这样做的好处是同一个技能可以挂到不同的Agent框架里不用为每个平台单独适配。对我们开发者来说这其实是变相降低了沉没成本因为今天接进来的技能未来迁移到别的框架时不用重写。3. 新上榜黑马拆解三个值得反复研究的技能细节总榜看的是整体热度但真正能学到东西的是那几个新上榜的黑马。我挑三个印象最深的拆开讲重点不是结论而是内部的设计逻辑。3.1 “多表查询助手”凭什么冲上第一这个技能这周直接冲到榜首说实话不太意外。只要做数据分析的人谁没被取数这种重复劳动折磨过。它的核心流程是“意图识别-表结构扫描-SQL生成-结果转述”四步每一步都有值得琢磨的地方。拿意图识别来说用户可能问“上个月华东区的销售额是多少”“对比一下Q2和Q3的退款率”“哪个品类的库存周转最慢”这三句话背后需要的表完全不一样。技能的做法是先维护一张“业务名词-字段映射表”把“销售额”“退款率”“库存周转”这些词映射到具体的字段表达式上。映射不到的再调用模型的语义理解能力结合表字段字典做推断。这种“规则兜底模型兜底”的双通道设计比纯靠模型理解要稳得多。SQL生成阶段也有细节。它没有直接让模型写完整SQL而是先让模型输出一个“查询计划”包含涉及哪些表、需要哪些字段、用什么聚合函数、有没有过滤条件。计划确认后再生成正式SQL。这样做的好处是一旦结果不对可以回溯到计划层排查而不是在一大段SQL里瞎猜。我在自己项目里试过类似策略排查效率至少提升了一半。最后的结果转述也不是简单把查询结果念一遍。它会根据数据形态自动决定用文字还是图表描述连续型数据给趋势说明分类数据给对比说明还会标注数据口径和截止时间避免其他人拿到数据以后产生误解。3.2 “会话情绪识别”不只是贴个正面负面标签这个技能上榜让我有点意外因为情绪识别听起来不算新。但点进去细看之后发现它做的深度比市面上大多数方案强不少输出结构是“情绪标签-情绪强度-应对动作建议”三层不是简单给个“正面”或“负面”。情绪标签分了八个维度除了常见的高兴、愤怒、失望还有焦虑、困惑、犹豫、讽刺、平静。它内部先做了一个情绪强度打分范围是0到1然后根据置信度决定要不要触发下一步的应对建议。比如一个客户的咨询消息被判为“高强度的愤怒”技能会自动生成一段安抚话术、一个升级工单建议、一个需要同步的团队成员的清单。这就不再是单纯分析而是直接能落地到客服工作流里。它的实现对新手很有参考价值的地方在于“关键词触达模型判别”的两阶段方案。第一波先用规则快速筛选命中情绪关键词的才进入模型做深度判断这样能省掉大量不必要的大模型调用成本。如果所有客服消息都直接丢给模型分析成本会翻好几倍而且响应速度也跟不上。3.3 “日志异常定位”覆盖了运维场景的真实痛点这个技能新上榜背后是运维同学的长期痛点日志太多、报错太杂、定位太慢。它的设计思路有一个特别值得说的点就是它没有让大模型直接看原始日志而是先做了三段预处理。第一段是日志切分把连续日志按请求ID或会话ID切成片段第二段是规则过滤把已知的、无风险的信息用正则表达式直接滤掉第三段是异常聚类把相同模式出现的报错归到同一类统计频率和首次出现时间。预处理好之后模型才登场它看到的是聚类结果、异常模板、关联的上下文片段而不是几千行密密麻麻的原始日志。这样一来模型不但能吃得更准消耗的token也小了一个量级。我自己对照了一下这个技能要复现的难度其实不高核心工程量在预处理逻辑上模型部分反而很轻。所以它上榜也说明一个道理给大模型做好前置过滤比换个更强的模型更有效。4. 从周榜到实操把热门SKILLS接到自己的Agent里看完榜单和拆解肯定有人想直接动手接一个到自己项目里。这一章我把接入流程和参数取舍写细一点照着做基本能跑通。4.1 先确认你需要的到底是什么技能我的建议是不要看到榜单第一就无脑接“多表查询助手”先梳理一下你自己项目里的高频重复任务。判断标准有三个这个任务每周是不是要花掉你两个小时以上它是不是有相对明确的输入输出结构以及它出错以后是不是能被快速发现。满足这三个条件就值得用一个Skill来承接。以我做过的项目为例当时最耗时的不是模型调优而是每周手工汇总多个业务群的反馈并分类。这个任务输入杂乱、输出结构固定、重复性强后来接了一个文本分类技能内部按“功能需求-体验问题-故障报告-咨询建议”四类分桶准确率虽然赶不上人工精细判断但已经能把每周两小时的活压缩到十五分钟。接入之前一定要想清楚这个技能是给你“省时间”还是“提质量”两者选型逻辑完全不同。4.2 一个常用的技能接入流程不管是什么技能接入流程大体都可以分成四步读取技能定义、注册依赖工具、初始化参数、跑边界测试。我以“多表查询助手”为例给你一个可参考的接入流程。第一步读取技能定义文件里面通常会包含输入参数说明、输出样例、所需工具列表、允许调用的外部接口。先别急着写代码把输入样例逐条读懂看它支持哪些文件格式、有哪些必填参数。第二步注册依赖工具。多表查询类技能通常需要文件解析器和SQL执行器。文件解析器负责把Excel、CSV转成可查询的结构SQL执行器负责在临时表或数据库上执行生成的SQL。第三步初始化参数。这里比较关键的是数据源连接配置、查询超时时间、最大返回行数、字段映射表。字段映射表建议先用小样本手工维护一版不要指望技能第一次就能认全你所有的业务名词。第四步跑边界测试。准备三个用例一个最简单的单表查询一个涉及多表关联的复杂查询一个故意写错的查询比如不存在的字段名看技能能不能给出合理的报错或澄清。边界测试跑完再放到线上。下面给一个极简版代码示例展示怎么把“多表查询助手”的核心流程串起来实际项目里你可以在它的基础上扩展import json import sqlite3 import pandas as pd from openai import OpenAI client OpenAI(base_urlyour-model-endpoint, api_keyyour-api-key) SKILL_SCHEMA { name: multi_table_query_assistant, description: 根据用户自然语言查询解析数据源并生成可执行SQL, parameters: { type: object, properties: { query: {type: string, description: 用户的查询意图描述}, tables: {type: array, items: {type: string}, description: 参与查询的表名列表} }, required: [query] } } def run_skill(query: str, tables: list[str], table_info: dict) - str: # 1. 生成表结构字典只保留关键字段信息 table_dict [] for table in tables: cols table_info.get(table, {}).get(fields, []) table_dict.append({table: table, fields: cols}) # 2. 让模型基于结构字典生成查询计划 plan_prompt ( 你是一个数据分析助手。根据表结构字典生成查询计划。\n f用户问题{query}\n表结构{json.dumps(table_dict, ensure_asciiFalse)}\n 输出JSON格式的计划包含涉及表、字段、聚合方式、过滤条件。 ) plan_resp client.chat.completions.create( modelyour-model-name, messages[{role: user, content: plan_prompt}], temperature0.1, ) plan json.loads(plan_resp.choices[0].message.content) # 3. 根据计划生成SQL sql_prompt ( 根据以下查询计划生成标准SQL不要做计划之外的推断。\n f计划{json.dumps(plan, ensure_asciiFalse)} ) sql_resp client.chat.completions.create( modelyour-model-name, messages[{role: user, content: sql_prompt}], temperature0, ) sql sql_resp.choices[0].message.content.strip() # 4. 执行SQL并返回结果 conn sqlite3.connect(:memory:) for table in tables: df pd.DataFrame(table_info[table][data]) df.to_sql(table, conn, indexFalse) result pd.read_sql_query(sql, conn) conn.close() return result.to_json(orientrecords, force_asciiFalse) # 使用方法 # print(run_skill(上个月华东区销售额, [sales], table_info))4.3 参数调整与性能取舍实际接入时有两个参数是最值得调的。第一个是temperature生成SQL和查询计划这类确定性任务直接设为0或者0.1不要给模型随意发挥的空间。第二个是上下文裁剪比例技能在执行前应该自动过滤掉明显无关的字段或重复内容我一般建议保留的信息量不超过窗口的40%给后续输出留足余量。另外要注意是否启用并行调用。像“多表查询助手”这种技能内部有多个独立的模型调用动作如果用的是支持并行调用的Agent框架可以把计划生成和字段映射并行跑能明显缩短整体响应时间。但并行也有代价就是出问题的时候排查更麻烦建议先串行验证通再改并行。还有一点很多人容易忽略给技能的每条模型调用都设置独立的超时时间。如果一个技能内部有四次模型调用你只在技能层设了一个30秒超时一旦某次调用卡住整个技能就白白浪费掉时间。每层调用都设超时宁可让它提前失败也不要让用户等一个注定等不来的结果。5. 我筛周榜的三个习惯别只盯着“第几名”每周榜单出来很多人只看排名就结束了。但实际上排行本身的价值有限排名变化和背后信息才是真正值得花时间研究的。我分享三个自己固定会做的动作。5.1 看增量不看存量我注重的不是谁长期霸榜而是这周“新上榜”和“名次跳升”的条目。因为一个技能如果已经连续好几周排在前面说明它基本成熟了你能从中学到的设计思路可能是上个版本的东西。反而那新上榜的很多是在解决新冒出来的痛点用的也是最近才成熟的实现方案。比如这周“多语言本地化翻译”新上榜我会去看它新在哪它不是一个简单的翻译技能而是包含术语表管理、目标语言文化适配、译后质量评分三层结构这些都是针对出海业务场景新出现的问题打磨的。这些增量信息才是榜单里最值钱的部分。5.2 动手翻作者仓库和发布记录榜单页面上能看到的是技能名、评分、安装量但这些数字很容易被刷出来。我会额外去翻作者的仓库重点看三样东西最近一个月有没有提交记录、Issues里面有没有被反复反馈的未解决问题、README里有没有写清楚的适用边界。我踩过一次坑接了一个评分挺高的技能进了内部系统结果作者三个月没更新底层模型一升级输出格式就开始飘。后来去翻仓库才发现Issues里面已经有人反馈了作者一直没回应。所以现在我接任何技能之前都会顺手看一眼“最后维护时间”这个数据比评分诚实得多。5.3 用小流量先验证不要全量接入你从榜单上相中一个技能别直接挂到生产环境先找一个不太重要的场景做小流量验证。我的经验是先限定一个具体的输入类型比如只处理CSV格式的表格跑上一周把成功率、报错率、异常输出率记下来。确认稳定后再逐步放开其他文件格式和场景。这个习惯虽然看起来保守但能帮你避开很多坑。技能本身有bug、技能和你的数据不匹配、技能和底层模型版本冲突这些问题在小流量阶段都能暴露出来等你要处理的量级变大再去擦屁股代价会翻好几倍。6. 榜单背后接入热门SKILLS时容易踩的几个坑最后这部分我整理了最近一段时间实际踩坑和帮朋友排查问题的记录。照着这个速查表能省不少排查时间。问题现象可能原因排查与解决建议技能不识别输入文件报格式错误技能对文件格式的判断写得太死查看技能定义里允许的格式白名单先转成它支持的格式再传入输出内容突然不稳定格式时好时坏技能依赖的底层模型版本被更新行为发生变化锁定模型版本或在技能层增加输出格式校验和后处理报上下文超限错误任务无法继续采集阶段没做数据裁剪全量信息直接塞给模型增加预过滤阶段先提取关键字段和摘要再交给模型处理提示权限错误技能无法读取文件技能要求的目录权限比预期更大检查Agent运行环境的权限配置确认是否允许访问目标目录技能输出结果看起来对但数据口径不对字段映射表没覆盖你特有的业务名词手工补充映射表业务名词优先用规则映射不要全依赖模型调用速度慢单个技能要等十几秒内部多个模型调用串行执行确认是否为并行调用把相互独立的步骤并行执行技能升级后原先的输入参数不能用了作者改了技能定义没有做向后兼容接入时锁定技能版本号升级前做回归测试结合这些坑我再说两条个人觉得最管用的经验。首先是“版本锁死”要刻进习惯里技能的发布频率现在越来越快作者可能这周加了一个参数下周又改了输出格式如果不锁版本某天线上突然挂了你都不知道是哪个环节变的。其次是不要让技能承担它定义之外的责任榜单上的技能描述怎么写你就怎么用你想让它多做一点最好的方式不是去改它的提示词而是写一个新的技能把它作为内部的一个环节去调用。这样职责边界清晰出问题也好排查。最后再分享一个我做Agent以来最真实的体会技能榜单看着是排名其实是需求的晴雨表。它不直接告诉你哪个模型最强而是告诉你大家正在用AI解决什么问题、哪些问题还没有被解决干净。每周花十分钟刷一遍榜不是为了追新而是为了在别人已经趟平的路上少走弯路然后腾出精力去解决那些榜单上还不存在的需求。