1. 先泼盆冷水Skill 数量与 Agent 智商不成正比1.1 我见过最离谱的“技能全家桶”先讲一个真实的场景。某团队在内部系统里接入 Agent 时产品经理兴冲冲地列出了二十多个“必备技能”查工时的、查 OKR 的、查会议室状态的、生成周报的、翻译邮件摘要的、自动给客户打标签的……理由也很充分每个业务部门都觉得自己那点操作如果不变成技能Agent 就“不完整”。结果跑了两周问题全冒出来了。最典型的是 Agent 会花十几秒“思考”然后不确定该调哪个技能有时候明明只是问一句“这周会议室紧张吗”它能连环触发三个技能最后给你返回一个风马牛不相及的排期表。后来我们做了一次埋点统计二十多个技能里真正在一周内被成功触发超过 10 次的只有 4 个剩下十几个要么从未触发要么每次触发都是误判。这不是个别现象。我自己也踩过类似的坑总想把 Agent 的能力边界撑大一点于是不断往里塞技能包。装的时候有多爽用的时候就有多痛。核心原因其实不难理解Agent 的决策通道是有限的每一个技能都在跟“直接回答”这条路抢资源。技能太多模型每走一步都要做一次“要不要调用工具”的判断题误判率自然就上去了。1.2 模型的基础推理能力被“技能噪音”掩盖很多人忽略了一件事大模型本身已经内置了大量常识性能力。你问它“今天适合穿什么”它不需要一个“天气穿衣建议技能”才能回答你让它把一段话改得更委婉它也不需要“邮件润色技能”。这些技能本质上是把模型已经会做的事情封装了一层不但没有新增能力反而增加了决策负担。我习惯用“噪音”这个词来形容这种状态。一次对话中系统把可用技能的名称、功能说明、参数格式、示例用法全部塞进上下文模型相当于一边开车一边看十几块广告牌。它必须“无视”大部分广告牌才能专心开车但这是有认知成本的。实测中技能描述总长度超过一定阈值之后模型对基础问题的回答质量会明显下降尤其是那些需要多步推理的任务。更隐蔽的问题是技能的存在会改变模型的回答倾向。明明用户问的是一个开放性问题模型因为检测到“这个技能的关键词沾边”就会优先走工具调用路线而不是直接组织语言回答。绕了一大圈最后给出的结果反而更机械、更模板化。结论很扎心技能不是越多越好有时候少到极致Agent 反而更聪明。2. 一份 Agent Skill 失效的三种典型病理2.1 描述性失语模型根本不知道什么时候该用它我复盘过大量“永远不被触发”的技能发现它们有一个共同点描述写得像招聘 JD而不是使用说明书。举个例子。某团队给 Agent 配了一个“项目风险预警技能”技能的 description 写的是“用于识别项目中可能存在的风险因素并提供风险管理建议。”看起来没毛病但模型面对用户真实提问时根本不知道触发它。因为用户不会说“请进行风险管理”用户会说“这个需求下周做不完怎么办”。如果技能描述里没有出现“延期”“做不完”“没时间”这类自然表达模型在意图匹配阶段就把它跳过了。我后来把这条描述改成“当用户提到项目可能延期、资源不足、需求变更、团队抱怨时间不够等情况时使用本技能分析风险并给出应对建议。不要用于解释概念或写科普说明。”触发率立刻翻了接近三倍。说明问题不在技能本身而在描述是否完成了“从用户口语到工具调用”的翻译。描述性失语是大多数技能无效的第一大原因也是最容易被修复的原因。2.2 成本黑洞技能文档先吃掉一半上下文第二个病理更现实上下文预算被技能说明蚕食。现在的 Agent 应用通常把技能描述、参数 Schema、示例片段全部注入系统提示词里。单个技能消耗几百 token 听起来不多但十个技能就是几千甚至上万 token。如果 Agent 还需要读取用户数据、历史记录那留给真正推理的空间就被严重压缩。我做过一个对比同一个 Agent在技能包里只保留 2 个核心技能时处理一段 3000 字中文材料并输出摘要整体响应质量稳定当技能包膨胀到 15 个之后同样的问题出现了明显的“记忆衰减”——它开始遗忘材料前半部分的内容。这当然不是模型真的失忆而是上下文窗口被无关技能描述占满有效信息被挤出了注意力范围。更坑的是很多技能描述里还塞了大量“防御性提示”比如“不要把这个技能用于 X 场景”“如果用户没有明确要求请不要调用”。这些内容看似严谨其实是双重负担一方面占 token另一方面会增加模型的理解歧义。最好的技能说明是让模型在 1 秒内看懂触发条件而不是让它读完一篇小论文再决定动不动手。2.3 相互打架多个技能同时触发导致死循环多个技能之间互相干扰是我见过最让人血压升高的场景。一个 Agent 同时挂着“日历管理技能”和“任务调度技能”用户说“帮我安排下周五的评审会议”。结果模型先调用日历技能创建了日程又调用任务调度技能生成了一堆待办最后还试图用“邮件通知技能”给参会人发邀请。三个技能各做了一部分但没有一个把整件事闭环。更离谱的是技能之间的循环调用。有的 Agent 支持技能内部再调用其他技能一旦 A 技能的输出格式触发了 B 技能的入口B 又依赖 A 的返回值就会在同一个任务里来回切换四五次。每次切换都要消耗 token还可能因为参数格式不匹配直接报错。用户看到的结果就是Agent 思考了很久然后说“抱歉我遇到了一些问题”。这类问题很难从单个技能的代码里看出来必须从“技能组合”的层面做排演。我后来定了一条规矩新增任何技能之前先画一张技能触发关系表标注哪些技能可以串行、哪些技能绝不能同时出现。宁可个别场景多一步人工操作也不要让 Agent 在多个技能之间反复横跳。3. 我是怎么给已有技能做“健康检查”的3.1 从触发率报表里找“僵尸技能”给技能做体检第一步不是看代码而是看报表。如果 Agent 平台支持日志分析我会重点拉三个指标触发次数、调用成功次数、调用结果使用率。触发次数表示模型判断“该用技能”的次数调用成功表示工具本身没报错结果使用率表示最终回答里是否真的采纳了技能返回的数据。三者的差距很能说明问题。一个技能如果触发次数很高但结果使用率很低说明模型评估错了场景如果触发次数极低说明描述和用户的真实表达不匹配如果调用经常失败那就要检查工具接口是否稳定或者参数映射是否合理。连续观察两周基本能把“僵尸技能”找出来——它们占着上下文却从未贡献过价值。我还有一个个人习惯每个技能都要设置独立的日志标记。这样不仅能看整体触发率还能定位到具体是哪一类用户问题触发的。标签维度包括触发前缀、用户问题长度、调用耗时等等。没有这些数据后面所有的优化都只能靠拍脑袋。3.2 用 1 个问题判断是否值得重构面对一个表现不佳的技能我建议只问一个问题去掉它用户会明显觉得缺了某样东西吗如果答案是不确定那就先别急着删而是做一个“隐藏测试”把技能从配置文件里注释掉跑一周。很多团队不敢用这种“减法测试”怕用户投诉。但我做过几次之后发现真正被用户感知的功能缺失非常少。因为大多数技能只是锦上添花而用户最常用的核心路径往往只有一两条。隐藏测试结束后把有技能和无技能两段时间的用户反馈对比一下。如果没有任何人提到某个功能“消失了”这个技能就可以彻底移除了。如果确实有反馈再把技能加回来同时按照更严谨的触发条件重新设计。这套方法周期长但比拍脑袋决策可靠得多。3.3 技能评估打分表为了方便判断一个技能是去是留我整理了一张打分表。每次评估技能都会从以下几个维度打分单项 1~5 分总分低于 15 分的技能直接列入淘汰候选评估维度打分逻辑权重说明触发准确率触发后是不是总能匹配用户意图核心指标误触发越少越好结果使用率返回数据是否真的被写进最终回答防止模型“用了等于没用”上下文成本技能描述Schema 实际占用 token 数成本越高要求越严苛接口稳定性外部服务超时、报错频率不稳定接口等于给 Agent 埋雷可维护性参数变更是否需要频繁改代码频繁改动会导致描述失真这张表看起来简单但比“感觉这个技能有用”要客观得多。尤其是“可维护性”这项很容易被忽略。很多技能的接口只改了一个字段名原本的文档就全废了。与其维护一堆脆弱连接不如让 Agent 用最朴素的方式解决问题。4. 实操把拖后腿的技能改成真正有用的技能4.1 裁剪前的准备工作确定要保留哪些技能之后不要直接动手改先把准备工作做完否则很容易改出一堆新问题。第一步是梳理用户最常问的 20 类问题。可以从客服工单、群聊记录、搜索日志里拉目标不是列全用户需求而是找出覆盖度最高的几类。接着对这 20 类问题做一次“无技能基线测试”让 Agent 在完全没有技能的情况下回答看哪些问题能答好哪些问题答得不行。答得不好的那一类才是真正值得用技能去补的缺口。我见过最普遍的错误是反向操作先写了技能再去找什么问题配它。这样相当于“有了锤子看什么都像钉子”技能的触发范围会被强行扩大最终表现反而更差。正确的顺序一定是“缺口在前技能在后”。准备工作的最后一步是给每个候选技能写一句“任务声明”比如“本技能只解决会议室预订确认不做日程建议。”这句话会直接变成技能描述的第一句。4.2 重新设计技能说明的三段式写法我以为稳妥的技能说明应该分成三部分触发条件、执行边界、输出要求。缺一不可但顺序可以按平台习惯调整。触发条件部分要写用户可能怎么说而不是写技术概念。比如“当用户提到‘订个会议室’‘哪个房间有空’‘下午开会有地方吗’等表达时使用本技能”。用自然口语覆盖高频说法模型在意图匹配时命中率会明显提高。执行边界部分要写明“不做什么”比如“不要主动推荐会议室之外的地点不要修改已有日程”。这不是防御性废话而是给模型划定清晰的决策边界防止工具自由发挥。输出要求部分最关键但最容易被写坏。不要写“请输出友好且专业的回复”这没有任何约束力。要写“只返回会议室编号、时间段和预订状态一句话说明是否成功勿包含思考过程”。明确的结构化要求能让 Agent 的回答更稳定也更容易被后续程序解析。三段式写完之后建议把说明压缩到 300 token 以内超过这个长度大概率是因为混入了无关内容。4.3 用显式开关避免误触发有些技能本身很稳定但就是容易在错误的场景里被误触发。比如数据分析技能用户只不过说了一句“我感觉这数据不太对”模型就可能直接调用技能去跑 SQL结果因为权限不够报错。这种情况不能怪模型只能怪技能的触发条件太宽松。我会给这类技能加一个“显式开关”要求的触发语句更严格必须包含明确指令比如“请用数据分析技能查看数据”“帮我统计一下”“跑一遍分析”。如果用户只是表达情绪模型就应该用普通对话能力回应而不是动用工具。这个改动会让技能的触发率下降但成功率会显著上升。另外一个有效手段是把高成本技能的优先级调低。如果模型需要在“调用数据分析技能”和“直接回答”之间选择我宁愿它先尝试直接回答只有当回答需要精确数字或者跨表查询时才选择调用工具。调整优先级不会让技能失效而是让它从“天天抢戏”变成“关键先生”。5. 一组对比实验结果同一任务开技能与不开技能5.1 测试任务设计光说不练没有说服力。我挑了一个内部测试集来对比“满技能版 Agent”和“极简版 Agent”的差异。测试集包含 12 类常见任务每类任务准备 10 条真实用户问题一共 120 条。问题覆盖日常问答、数据查询、流程安排、文案改写、多步信息整合等场景。实验分成三组第一组挂 12 个技能包括日程、天气、订单查询、邮件起草、风险预警等第二组只挂 3 个被验证为“高触发、高使用率”的技能第三组不挂任何技能纯靠模型基础能力。三组使用同一个模型版本、同一份系统提示词和完全相同的输入顺序尽可能排除变量干扰。评估标准也提前定好回答准确率、任务完成度、平均响应时长、上下文 token 开销。坦白讲一开始我预想的结论是“极简版大于满技能版”但我没想到差距会那么大。尤其在多步信息整合任务里满技能版经常因为中途调用一次无关工具导致后续步骤断掉。极简版反而能一路走到底。5.2 典型结果简单汇总几个关键数据虚构测试数据仅作讨论指标满技能版12 个技能精简版3 个技能无技能版总体成功率64%83%78%数据查询类准确率88%91%52%开放问答类准确率61%80%86%平均回答耗时8.2 秒5.4 秒4.1 秒平均 token 单次540033002100数据查询类任务里无技能版输得很彻底因为模型记不住某个内部系统的状态必须有工具做支撑。开放问答类任务里满技能版明显被拖累本来能直接生成的回答非要先思考一遍工具切换再输出准确率反而最低。最让我意外的是精简版它在两类任务里都拿了不错的分数尤其在整体成功率上最高达到了 83%。结论并不复杂技能要解决的是“模型靠内部知识无法单独完成”的问题而不是代替模型做它本来就擅长的事。数据查询离不开技能开放问答则应该让模型自由发挥。把所有技能无差别塞给 Agent只会让它在不该调用工具的地方消耗时间和注意力。5.3 对结果的理解有人可能会问既然无技能版在开放问答里得分最高是不是干脆把所有技能都删了我认为不是。因为真实业务里有很多必需操作比如“查询订单状态”“提交工单”“触达外部系统”没有技能模型根本完成不了。所以那个 52% 的数据查询准确率就是代价。实验最值得关注的是满技能版和精简版的差距——两者拥有的工具能力几乎一致满技能版只是多了 9 个“低频技能”。这些低频技能没有在任何一次测试里帮上忙却稳定地拖慢了响应速度。也就是说技能包的边际收益下降得比想象中快得多。前面 1 个技能带来的能力提升非常明显到第 5 个技能时基本持平第 10 个往后就开始负优化。这给我一个很实际的操作指引如果团队时间有限与其优化每一个技能的实现细节不如先砍掉一半低频技能。一次减法带来的效果可能比重写十个技能描述还明显。6. 我最后留下哪些技能以及避坑清单6.1 目前仍保留的几类技能经过几轮清理我现在给内部 Agent 保留的技能大致只分三类。第一类是“数据访问型”。系统内的订单、库存、项目状态等数据模型不可能靠训练知道必须通过工具读取。这一类技能是刚需需要保证接口稳定并且描述要写得特别具体细化到参数名和返回字段。第二类是“外部动作型”例如提交审批、创建日程、发送通知。它们必须被执行但触发门槛要高最好加上用户二次确认环节防止误操作。第三类是“格式转换型”例如把一段文本转成特定结构、从非结构化内容里抽取字段。这类技能适合场景固定、输出标准化的任务。其余那些“知识科普型”“写作润色型”“脑暴建议型”技能我基本都不挂了。不是它们没用而是模型的基础能力已经足够好挂上去只会增加噪音。我现在的原则是如果一次对话中用户最直接的感受就是“对话变顺畅了”那技能配置就做对了。6.2 避坑清单最后分享一份避坑清单都是我实际踩过之后整理出来的。希望你在给 Agent 配技能时能少走几步弯路。不要为了“完整”而配技能。先把用户高频问题和能力缺口对齐再决定加什么。不要用抽象描述写技能说明。触发条件要写用户原话执行边界要写“不做什么”。不要放过低频技能。连续两周触发率低于 10 次的技能优先隐藏并观察。不要只盯触发率。结果使用率才是最终价值的体现触发率高但结果不用等于一场空。不要让技能互相嵌套。除非有充分测试否则 A 技能调 B 技能很容易变成死循环。不要把完整工具文档塞进技能描述。精简到只保留调用所需的最小信息量。我给 Agent 配置技能的经验说白了就是“少即是多”。早期我也迷恋那种动辄几十个技能的能力清单好像技能数量代表了 Agent 的战斗力。但现在我更看重每一次调用的确定性这个技能可能很慢可能很笨但只要它被触发就一定要给出对用户有用的结果。这一件事做到了技能就算没白配做不到删掉反而是最优解。