1. 为什么"技能"成了 Agent 的命门
1.1 从对话助手到行动体
我最早接触 Agent 开发时，大家讨论的都是"怎么让模型把话说对"，后来慢慢发现，真正让一个 Agent 从"能用"变成"好用"的，根本不是它多会聊天，而是它能不能干净利落地把事情办成。这个转变的关键，就是今天标题里这两个字——技能。
技能在 Agent 语境里，不是简历上写的"会 Python、懂项目管理"那种宽泛能力，而是一个可以被触发、被参数化、被反复执行的最小行动单元。打个比方，对话模型像一个人脑，技能就是它手边那套放得整整齐齐的工具箱：锤子负责敲钉子，螺丝刀负责拧螺丝，你不会拿钳子去敲墙，也不会拿扳手去剪电线。一个没有技能库的 Agent，就像只有脑袋没有手，什么问题都只能"跟你说说";一旦把技能挂上去，它立刻从一个侃侃而谈的顾问，变成一个抡起袖子干活的执行者。
我见过不少团队在早期疯狂堆模型提示词，试图让 Agent 在一条超长的系统提示里"领悟"所有任务。结果就是提示词越来越长、成本越来越高、行为却越来越飘。后来我们把任务拆成技能，每个技能管一个窄范围，模型需要做的判断少了，执行的确定性立刻上来了。这件事给我的触动很大：Agent 的能力上限，往往不是模型决定的，而是你给它设计的技能边界决定的。
1.2 技能与工具、插件的区别
提到技能，很多人会把它和工具（Tool）或插件（Plugin）混在一起。从我自己的开发经验看，它们确实有重叠，但侧重点不同。工具的粒度更细，通常指一个具体的函数或 API，比如"发送 HTTP 请求""读取某个文件";而技能是一个更高层的封装，它至少包含触发条件、输入解析、执行步骤、结果反馈四部分，可能内部会调用好几个工具。插件则更多是一种分发和安装的形态，技能可以用插件的形式打包，但插件往往还包含模型配置、界面入口之类的东西。
区别不是咬文嚼字，而是直接影响研发方式。如果你把技能当成一个简单的函数注册给模型，你很快会发现模型根本不知道什么场景该用、参数填错了怎么办、执行到一半失败了怎么收场。只有把技能当作一个完整的决策与执行闭环来设计，Agent 的行为才能从"碰运气"变成"有套路"。
2. 拆解一个 Agent 技能必备的四个组成
2.1 触发条件：什么时候该出手
一个技能必须明确自己的"使用场景约束"。不是模型高兴就能调。我习惯用一个白名单思维：在技能描述里写清楚"仅在满足以下条件时使用：用户请求中包含 XX 实体、目标明确指向 XX 操作、且具备 XX 前置数据"。描述越具体，模型误调用的概率越低。
举个真实踩过的例子。我们早期做了一个"天气查询"技能，描述写得特别开放："查询任意地点天气情况。"结果用户说"帮我安排明天出差行程"，Agent 居然先调了天气技能，因为它觉得"出差"和"天气"有关。后来改成"仅在用户直接询问当前或未来某时间点的气温、降水、风况等天气数据时使用；如果用户只是提及天气相关词汇但核心目的是安排行程，不得调用"，误调用率立刻降了下来。触发条件不是给模型看的免责声明，而是给模型画的行动边界。
2.2 输入解析与参数抽取
模型从自然语言里抽参数，经常会抽错。这里我的经验是：不要指望模型一次抽对，要给它明确的参数 schema 和示例。每个技能定义一个 JSON Schema，字段名用模型容易理解的英文或拼音都行，但要配上简称和别名。比如日期字段叫target_date，描述里写"支持'今天''明天''下周三'等自然语言，输出统一为 yyyy-MM-dd"。
更关键的是参数校验。技能执行前必须先过校验关卡：必填项有没有、枚举值在不在范围内、数字是否在合理区间。校验失败时不要直接报错，而是生成一条"我还需要确认什么"的消息返回给模型，让模型去追问用户。这一步能避免海量因参数异常引发的执行失败。
2.3 执行逻辑：确定性优先
技能内部的执行逻辑，能写死的部分就不要让模型自由发挥。我通常把执行逻辑分成三层。第一层是规则层，处理所有有明确公式或规则的步骤，比如文件改名、数据格式转换;第二层是模型层，只负责那些真正需要理解语义的步骤，比如从一段文本里提取关键观点;第三层是兜底层，当规则层和模型层都搞不定时，返回一个可解释的失败信息，而不是抛出一堆堆栈。
记住一个原则：技能是为了提高确定性而存在的。如果某个技能的执行结果每次都不同，那它就不是技能，只是一个带提示词的模型调用。所以我在设计执行逻辑时，优先选择脚本、API、SQL 这些有固定输出的方式，模型调用只作为补充。
2.4 反馈与容错
技能跑完之后，反馈信息要比"成功了"或"出错了"丰富得多。我个人实践中，反馈至少包含三块：执行结果摘要、关键数据快照、失败原因与建议。执行结果摘要是给模型看的，让它能接着往下对话;关键数据快照是给用户看的，方便确认;失败原因与建议则是给调试者看的。
容错这块，最常见的坑就是不设超时和重试。一个技能去请求第三方接口，网络一抖就是几十秒，Agent 干等着，对话体验直接垮掉。我的习惯是给每个技能预设一个超时上限（具体视任务而定，一般网络请求 5—15 秒），连续失败两次就用兜底方案——要么降级返回缓存数据，要么明确告知用户"当前服务不稳定，请稍后再试"。
3. 实操：从需求到落地的技能设计流程
3.1 先画边界，再谈实现
很多开发者一上来就写代码，结果技能越写越臃肿。我推荐先做一次"需求边界梳理"，把你要支持的任务列表出来，然后逐个问三个问题：这个任务能不能用几条规则直接搞定？如果不能，是不是因为有太多开放式的语义理解？如果理解模型都搞不定，是不是应该把任务拆得更小？
以我们做过的一个"会议纪要整理"技能为例。最初需求是"听完录音直接输出格式整齐的纪要"，听起来简单，做起来发现里面混着转写、发言区分、议题归纳、待办提取四个差异很大的子任务。强行塞进一个技能，提示词会互相打架。于是我们拆成四个独立技能：转写用现成语音接口，发言区分靠声纹特征，议题归纳交给模型，待办提取则是规则加模型的双重校验。边界画完之后，每个技能的压力都小了一大半。
3.2 把技能写成一个可测试的单元
技能在设计上应该像软件工程里的函数一样，输入输出尽量纯净。我实操时会做一份"技能测试卡"，每个技能配套 10—20 条典型输入，覆盖正常情况、边界情况、恶意输入三类。正常情况验证主流程，边界情况验证参数校验和兜底逻辑，恶意输入验证会不会被执行逻辑里的漏洞绕过。
为了让测试可重复，我在本地搭了一个模拟环境，不连真实外部服务，用 mock 数据代替。这样每次改完技能描述或执行逻辑，跑一遍测试卡就能看出行为是否漂移。这一步看着麻烦，实际上能省掉无数线上返工时间。Agent 技能的回归测试，重要性不亚于传统工程的单元测试。
3.3 结果验证与效果评估
技能上线之后，要有一套效果指标。我常用的有三个：调用成功率（技能有没有正常跑完）、任务达成率（用户最初的需求有没有被真正满足）、无效调用率（技能被调用了,但实际上是多余的）。前两个好理解,最后一个很关键,也是最容易被忽视的。一个技能如果频繁被无效调用,说明它的触发条件写得不够严格,或者模型对它的理解有偏差。
收集指标的方式,我建议从日志里单独捞一份"技能调用明细",记录请求原文、模型抽取的参数、执行结果、用户后续反馈。每周过一遍,你就能看到哪些技能的触发描述需要微调,哪些技能的参数 schema 需要加别名。没有数据支撑的技能优化,基本都是在凭感觉猜。
4. 踩坑记录：我在技能打磨中的典型问题
4.1 提示工程过度依赖
我刚开始做技能时,特别喜欢在技能的描述里写一堆"你要注意""你最好""你应当",觉得这样模型就能表现得很聪明。结果恰恰相反,描述越像在"教"模型做事,模型越容易理解偏差。后来我把技能描述精简成三段式:功能一句话、触发条件、输入输出说明。多余的修饰词全部删掉。实测下来,描述长度缩短四成,误调用率反而降了一大截。
原因是模型在处理工具描述时,真正抓取的是结构化的关键信息,而不是散文式的劝告。你写"请务必在查询前确认用户授权",效果远不如在参数 schema 里加一个"是否已取得授权"的布尔字段,并在校验逻辑里做拦截。提示词是软约束,校验逻辑才是硬约束。
4.2 状态管理混乱
Agent 在执行多步任务时,往往需要记住中间状态,比如"刚才已经查询过库存了,现在要算总价".如果技能内部不做状态保存,每次调用都是无记忆的,那就只能靠对话上下文来回传数据。这里的坑在于:对话上下文有长度限制,而且模型可能漏传、错传。
我的解法是引入一个轻量状态存储。技能执行过程中,把有用的中间结果写入一个临时缓存,并返回给模型一个极简的"状态令牌"(如{"step": 2, "result_id": "abc123"}),后续技能通过这个令牌读取具体数据。这样既不用把一个很大的对象反复塞进对话,又能保证状态在技能链里是可知、可控的。需要注意,状态令牌要设置有效期,避免长期堆积占用存储。
4.3 并发与超时
当一个 Agent 同时挂了十几个技能,肯定会出现并发调用的情况。我这边的教训是:技能之间必须做隔离,尤其是外部接口调用。曾经因为两个技能共用一个全局变量,导致 A 技能查到的结果被 B 技能覆盖,排查了很久才发现是变量命名冲突。后来规定所有技能内部变量都带技能名前缀,全局只允许通过统一的上下文接口读写数据。
另外,超时要分场景设定。内部计算可以短一点,比如 5 秒;外部网络请求要放宽到 15 秒左右;涉及大文件处理的,可以到 30 秒以上。不设超时的话,某一个技能卡住,整个 Agent 就像被冻结了一样,用户连取消都做不到。我通常会再加一个"取消令牌"机制,用户如果失去耐心,可以直接中断当前技能链。
5. 多技能编排：打造一个真正的"熟手" Agent
5.1 技能路由：让模型只做选择题
当技能库超过五个以后,一定要考虑路由问题。我的做法是让模型先做一次"意图分类",只输出一个意图标签,再由一个规则引擎把意图映射到对应的技能组合。这一步把"该用哪个技能"从模型的自由发挥,变成了一个受控的映射表。
举一个例子。用户说"帮我查一下这个电脑能不能装那款设计软件",意图分类结果可能是"软硬件兼容性评估",路由表就会把它映射为"读取电脑配置 + 查询软件要求 + 执行兼容性判断 + 生成建议报告"四个技能依次调用。模型不需要自己想流程,它只需要做好选择题,剩下的都由编排层决定。这样即使模型偶尔选错,我们也知道错误发生在哪个环节,而不是一锅粥。
5.2 上下文传递的两种方式
多技能编排时,上下文传递是成败关键。我试过两种主流方式,各有适用场景。
第一种是链式传递,前一个技能的输出直接作为后一个技能的输入。适合步骤强依赖、顺序固定的流程,比如先查库存再算价格。这种方式优点是好理解,缺点是链条一旦断掉就没法继续。
第二种是共享黑板,所有技能都往一个公共上下文空间里读写数据,技能之间通过键值配对引用。适合多分支并行、没有严格顺序的任务,比如市场调研,要同时抓舆情、查竞品、看价格,最后汇总。这种方式灵活,但对上下文空间的数据结构要求很高,需要提前约定好。
我在实际项目里,一般会给流程强依赖的任务用链式,给松散并行的任务用黑板。如果一个任务两种特性都有,就把它拆成两个阶段,阶段内用链式,阶段间用黑板。
5.3 一个简单的编排示例
我用一个"竞品情报简报"的场景,示意一下多技能怎么协作。整个流程包括四个技能:搜集新闻页面、提取关键信息、生成对比表格、输出简报文本。搜集新闻页面是规则型技能,负责抓取指定几家竞品的公开新闻;提取关键信息是模型型技能,需要理解每篇新闻里提到了哪些产品特性;生成对比表格是规则型技能,把提取出来的特性按固定模板排列;输出简报文本又回到模型型技能,把表格转成自然语言的优劣势点评。
这四个技能放在一个技能库之外,还配了一个流程编排表,写明技能顺序、超时时间、输入输出映射。模型在整个过程中只被调用两次,一次是提取信息时做语义理解,一次是生成点评时组织语言。其余步骤全是确定性的规则执行。这样一个流程跑下来,单次任务成功率能维持在较高水平,即使某篇新闻解析失败,也只是记一个警告,不至于让整个简报流程停摆。
6. 最后再聊一点实战体会
技能设计这件事,做得越久越觉得它像"驯模型"而不是"教模型"。你给技能定边界、定参数、定容错方式,本质上是在替模型处理它最不擅长的确定性问题,让它把有限的注意力集中到真正需要理解的任务上。我在多个项目里试过,单纯堆模型能力不如把技能拆到位,后者带来的稳定性提升往往是立竿见影的。
如果你正准备开始做自己的 Agent 技能库,我建议从一个小到不能再小的场景入手,比如"导出当前网页里的表格数据"或者"把一段录音转成简洁的待办列表"。先把一个技能做得细节扎实,测试卡跑顺了,再考虑把它扩展成技能组。别一上来就想着做一个全能助手,那种项目背后的编排复杂度和调试成本,不是个人开发者或者小团队能轻松扛住的。
另外,每一个技能上线前,都要问自己一句:如果把技能的说明文字删掉,这个行为还能被稳定触发吗?如果答案是不能,那就说明你的实现里还有太多地方依赖模型"猜"。一个成熟的技能的标志,就是即使模型换了一个版本,它依然能按预期的边界执行。这也是我判断一个 Agent 工程是否扎实的核心标准之一。
