1. 先从使唤人办事说起技能机制到底解决什么问题1.1 为什么单纯聊天不够用前阵子我帮朋友调试一个AI助手需求特别朴素用户说帮我看看明天杭州适合穿什么衣服助手要能查到明天的天气再结合温度给出穿衣建议。一开始我们走的是最常规路线——把所有天气数据一股脑塞进提示词里让模型自己理解。结果效果惨不忍睹要么模型把最高温32度理解成建议穿羽绒服要么数据更新不及时明明明天下雨它还一本正经地说适合户外运动。问题出在哪聊天式交互的边界太模糊了。大模型本质上是一个文本生成器它擅长的是理解和生成语言而不是执行确定性的动作。当你让它查天气的时候它并不会真的去调用气象接口它只是在基于训练数据猜一个答案。这种猜测在知识类问题里勉强够用但在需要实时数据、需要操作外部系统、需要执行确定性流程的场景里就是灾难。1.2 技能机制的本质把大模型变成调度中枢后来我把方案改成了技能机制效果立刻不一样了。所谓技能机制通俗点说就是你预先定义好一系列可以被调用的能力模块每个模块负责一件具体的事大模型本身不直接干活它只负责理解用户意图、决定调哪个模块、然后把模块返回的结果组织成自然语言回复给用户。打个比方。你雇了一个特别聪明的秘书大模型但这位秘书不会自己做饭、不会自己开车、也不会自己修电脑。你给秘书配了一个工具箱里面有微波炉操作手册、地图导航App、维修工的联系方式。用户说我饿了秘书不会自己去炒菜而是翻开微波炉手册、按照步骤热一份饭端上来。技能机制里的技能就是这个工具箱里的一件件工具。这个转变很关键大模型从什么都要自己会变成只需要知道谁会。它的定位从执行者变成了调度者。而每一项技能就是把大模型的语言理解能力和外部世界的确定性操作焊接起来的那根焊条。这也是为什么现在几乎所有AI Agent框架都把技能或工具调用作为最核心的抽象概念——没有技能的Agent只是个聊天机器人有了技能的Agent才具备干活的资格。2. 技能机制的四层骨架注册、调度、执行、反馈2.1 技能注册让Agent知道你会什么技能机制的第一步是注册也就是把你定义好的能力以结构化的方式告诉大模型。这一步相当于给每个技能办一张身份证上面写清楚三件事这个技能叫什么、它是干什么的、调用它需要提供哪些参数。我见过不少初学者在这一步偷懒觉得反正模型聪明我口语化描述一下就行了。这是大忌。技能描述写得好不好直接决定模型在意图判断时的准确率。比如你写根据城市名获取当前天气信息返回温度、湿度、风力等数据模型基本一眼就能判断该不该调这个技能。但你要是写成天气这个功能可以给我搞来天气数据参数就是城市模型的判断就会开始飘。更讲究的是参数说明。每个参数不光要有名字和类型还要把取值范围、格式约束、默认行为写清楚。比如city这个参数你要说明它接受的是中文城市名还是城市ID是否需要加市后缀。这些细节不写清楚模型填充参数的时候就容易填出各种奇怪的值。2.2 意图调度让Agent知道该用哪个注册完成之后真正决定技能机制智商的是意图调度这一层。当用户说明天上海下雨的话我就坐地铁上班模型需要做的事情是识别出这句话里有条件判断下雨、有城市上海、有日期明天然后决定需要调用天气查询技能再根据返回结果决定是否调用地铁路线规划技能。这个过程在实现上通常是函数调用机制完成的。大模型会在生成回复之前先输出一个结构化的调用请求里面包含技能名称和参数。你的系统拦截到这个请求执行对应的技能再把结果回传给模型。如果你用过市面上主流的Agent开发框架你会发现它们的核心循环基本就是这个理解意图 - 决定调哪个技能 - 执行 - 看结果 - 决定下一步。这里有个细节很多人会忽略意图调度不是只做一次。复杂任务往往需要多轮调用。比如用户说帮我订一间明天能带宠物入住的酒店Agent可能需要先调用查询宠物友好酒店技能拿到结果后还要调用比价技能最后调用下单技能。每一轮调用都是一次看结果再决策的过程。2.3 参数填充与执行让Agent知道怎么调调度决策做完之后就是参数填充和实际执行。参数填充这一环特别有意思它考验的是大模型对上下文的信息抽取能力。用户不会规规矩矩把参数列给你他可能说的是帮我看看那边天气怎么样——那边到底是哪儿模型得结合对话历史里的位置信息去推断。实际执行环节则需要你在技能内部处理好所有脏活。比如查询天气这项技能内部要拼装HTTP请求、处理超时、解析JSON、处理异常状态码、把原始数据整理成模型容易理解的结构化文本。一个合格技能的逻辑应该是输入简单干净的参数输出同样简单干净的中间结果所有复杂性都封装在技能黑盒内部。我还想特别强调一下执行结果的投喂格式。很多开发者直接把API返回的原始JSON丢给模型这会导致两个问题一是字段太多太杂模型在生成回复时容易抓错重点二是字段含义不直观模型可能误解。我自己的习惯是在技能内部就把数据整理成一段精炼的摘要文本比如杭州明日多云最高32度最低25度西南风3级紫外线较强再交还给大模型。这样模型只需要把这段摘要翻译成用户友好的回答几乎不会出错。2.4 结果反馈让Agent知道干得怎么样最后一层是结果反馈它决定了Agent能不能从错误中恢复。现实世界的API调用不可能永远成功可能是网络超时、可能是参数校验不通过、可能是上游服务返回了意料之外的数据。没有反馈机制的Agent一旦遇到错误就会陷入死循环或者直接摆烂。正确做法是在技能内部做一次完整的风险分级然后把处理过的状态返回给模型。比如成功返回正常数据。可重试的错误比如临时超时返回服务暂时不可用可稍后重试。不可重试的错误比如参数格式错误返回参数xxx缺失或格式不正确请引导用户补充信息。模型拿到分级反馈后行为会截然不同遇到可重试的错误它会换一种表述再尝试一次遇到参数问题它会主动向用户追问澄清。这一层做得好不好直接决定了用户感知到的智能感。3. 手写一个天气查询技能从需求到联调的完整链路3.1 需求定义与边界划定光讲概念有点虚我拿一个真实的练手项目来拆一遍。假设我们要做一个穿衣建议助手第一个技能就是天气查询。动手之前先把需求问清楚这个技能到底要解决什么问题答案是获取指定城市未来一段时间的天气供上层语义分析使用。注意不是生成穿衣建议——穿衣建议是后续由大模型根据天气数据再做的加工不是技能本身的事。输入是什么城市名、日期。要不要支持模糊日期比如后天我建议日期参数由模型去把自然语言转换成标准格式技能只接受2025-01-15这种明确的ISO格式这样技能内部的逻辑最干净。输出是什么我不建议技能直接输出给用户看。它应该输出一份结构化的天气简报给模型再由模型组织措辞。所以技能返回的字段要覆盖日期、天气现象、最高最低温度、风力风向、降水概率、紫外线强度、穿衣提醒的原始素材比如温度体感描述。3.2 技能描述与参数Schema编写接下来定义技能的身份证。这里我习惯直接用JSON Schema来定义参数结构大部分Agent框架都支持这种格式{ name: get_weather, description: 查询指定城市在指定日期的天气情况返回天气现象、温度范围、风力、降水概率、紫外线强度等信息。当用户询问出行、穿衣、户外活动相关问题时可调用此技能获取实时天气数据。, parameters: { type: object, properties: { city: { type: string, description: 目标城市的中文名称如杭州、北京。不带市后缀。如果用户说的地名不明确或为本地这里等指代词需结合对话上下文推断无法推断时询问用户。 }, date: { type: string, description: 需要查询的日期格式为YYYY-MM-DD只能是今天或未来7天内的日期。如果用户说明天后天等相对日期请先换算成绝对日期。 } }, required: [city, date] } }写这段描述时有两个心得。第一description里要写明什么时候该调用这会大幅提升意图调度的准确率。我特意写了当用户询问出行、穿衣、户外活动相关问题时模型就会在类似场景下优先考虑这个技能。第二参数说明里要明确写出什么不该做比如不带市后缀就是为了避免模型老老实实把杭州市填进去而你的执行端又得做字符串清洗。3.3 执行端的封装细节技能的执行端我通常封装成一个函数。这里的关键不在业务逻辑而在容错处理import requests import json def get_weather(city: str, date: str) - dict: 执行天气查询技能。 返回给大模型的统一结构status message data try: resp requests.get( https://example-weather-api.com/query, params{city: city, date: date}, timeout5 ) if resp.status_code ! 200: return { status: retriable_error, message: f天气服务暂时不可用HTTP {resp.status_code}请稍后重试, data: None } raw resp.json() today_data raw.get(data, {}) # 这里把原始字段整理成模型易于理解的结构化简报 summary ( f{city}在{date}的天气{today_data[condition]} f最高{today_data[temp_max]}度最低{today_data[temp_min]}度 f{today_data[wind]}风降水概率{today_data[precip_prob]}% f紫外线{today_data[uv_index]} ) return { status: success, message: summary, data: today_data } except requests.Timeout: return { status: retriable_error, message: 天气服务响应超时可稍后重试, data: None } except Exception as exc: return { status: fatal_error, message: f天气查询失败{str(exc)}请向用户说明并建议稍后再试, data: None }这段代码看似简单但里面藏着一个很重要的设计原则技能永远不要抛异常永远返回结构化的状态。因为调用你技能的不是Python代码而是一个大模型——它不能try-except它只能根据你返回的文本内容来判断下一步怎么走。你返回的状态字段和message就是它做判断的唯一依据。3.4 联调与效果验证技能跑通之后联调阶段是最能暴露问题的。我当时的验证方法是准备一批刁钻测试用例明天出门要不要带伞——考察是否能识别出需要调天气技能且能把明天换算成日期。上海呢——结合上文城市追问考察上下文参数补全。帮我看看大后天三亚的太阳大不大。——考察口语表达到参数映射。天气这功能怎么老出错——考察会不会在该调用的时候不调用。做完这轮联调你会发现真正影响体验的往往不是执行端的逻辑而是模型对技能描述的理解。某个参数描述改一个词意图命中率可能提升十几个百分点。所以别怕反复调试description这是技能机制里投入产出比最高的一步。4. 技能机制和提示词堆砌差在哪实测对比4.1 提示词方案的三个死穴可能有人会想我不搞什么技能直接在提示词里写你是一个天气助手你能获取天气再给几个示例效果不也一样吗实测下来差别很大。提示词堆砌方案有三个绕不开的死穴。死穴一模型会幻觉执行结果。没有真正的外部调用模型在回答天气时本质上是在编。它可能基于训练数据里的气候常识给你一个看起来合理的答案但这个答案和真实天气没有关系。技能机制强制让模型先生成一个调用请求拿到真实数据后再组织语言从机制上杜绝了编造实时数据的可能。死穴二复杂流程无法控制。提示词里可以写一百条规则教模型先查天气再查路况再查酒店但模型输出的随机性决定了它随时可能跳步。技能机制则不同每一步都是一次确定的函数调用流程控制权在你手里。死穴三可维护性差。每加一个新能力都要去改那坨巨大的提示词改完还可能影响其他能力。技能机制下每个技能独立封装、独立测试加一个新能力和加一个独立的Python模块一样简单。4.2 技能机制的四个核心优势用表格对比会更直观对比维度纯提示词方案技能机制方案数据实时性依赖模型训练数据无法保证每次真实调用外部接口流程稳定性高随机性容易跳步确定性强每步可控扩展成本改提示词牵一发动全身新增独立技能互不影响错误恢复模型硬编错误信息结构化状态 分级重试策略实际上这两个方案可以组合使用。大模型的角色设定、语气风格、回复格式这些软能力走提示词和外部世界交互的硬能力走技能机制。软硬分离既保留了模型的灵活表达又保证了操作的确定性。我记得第一次把天气技能接入整体系统时用户反馈特别有意思。之前问杭州明天穿什么模型给的答案虽然也是短袖但会附带一句根据历史气候数据推测。接入技能之后同样的问法模型会直接说明天杭州多云转阴最高30度体感闷热建议穿短袖或薄棉麻衬衫如果早晚出门最好带件薄外套。用户能明显感觉到AI靠谱了——因为它不再靠猜而是真的看到了明天的天气。5. 真实项目里踩过的技能设计坑5.1 参数描述太文学化模型反复追问第一个坑来自一个记事的Agent。我给它写了个添加待办事项技能参数描述用的是需要被记住的代办事项的详尽内容要包含用户所有想表达的要点。结果模型每次执行这个技能都会把用户一句话里夹带的情绪、背景、未来计划全塞进一个参数字段然后返回给用户时又啰嗦地复述一遍。后来我把描述改成简洁的待办内容5到15个字例如周四下午三点和客户开会效果立竿见影。技能参数描述的目标不是让模型发挥创造力而是让模型填出符合预期的、干净的值。越是简单直接的描述模型执行得越准。5.2 技能执行时间过长整个对话被卡死第二个坑是同步阻塞问题。我一开始图省事所有技能都用同步方式调用。结果遇到一个技能要查询三个不同渠道的价格再汇总整个请求耗时接近15秒。用户在聊天界面等着体验极差——而且模型在长时间等待中如果超时会直接放弃整个对话流程就断了。后来改成异步模式技能先返回一个已提交处理中的状态Agent可以先回复用户正在查询请稍等处理完成后通过回调把结果推进会话。如果你的Agent涉及外部系统耗时操作一定要提前规划异步回调机制不要等到上线被用户催了才改。5.3 技能之间的边界模糊互相抢活第三个坑出现在技能数量变多以后。当我的Agent里有查天气推荐穿衣规划行程三个技能时用户说明天去北京穿什么模型有概率去调规划行程而不是查天气。因为三个技能的description在某些场景下是重叠的。解决办法有两个方向。一是给技能划分明确的责任边界在description里直接写本技能不负责XX请调用Y技能。二是设定技能优先级让框架在意图判断得分相近时默认选择更具体、更底层的技能而不是大而全的复合技能。经验是技能尽量做到单职责一个技能只干一件逻辑上不可再分的事。看似多合一很方便实际会大幅提高模型的决策难度。6. 多技能协同编排从单兵作战到工具箱联动6.1 三种编排模式单个技能解决单个问题但真实用户需求往往是多个问题的组合。在技能数量多起来之后你会面临编排问题。我实际用过且验证有效的三种模式顺序模式一个技能的输出是另一个技能执行的依据。比如查天气得出了明天有雨然后触发规划地铁通勤路线。这是最常用的模式实现方式是设置技能之间的依赖关系让模型在拿到前一个结果后再决策是否调用下一个。并行模式多个技能之间没有依赖关系可以同时调用。比如用户问明天下班后适合去哪个商圈逛街Agent可以同时调用查询天气预报和获取商圈优惠信息两个结果一起返回后再组织答案。并行模式能显著缩短复杂任务的响应时间。条件分支模式根据技能执行结果走不同路径。典型的例子是如果明天下雨就推荐室内活动否则推荐户外活动。这种模式需要框架支持结果判断逻辑我习惯把判断逻辑写成一个小工具函数让模型根据工具返回的布尔值来决定下一步调用哪个技能。6.2 技能粒度怎么定编排之前必须先解决粒度问题。技能粒度过粗一个技能包罗万象模型很难匹配粒度过细一个简单的用户需求要编排五六个技能调用链长、失败概率高。我总结出一个比较实用的标准一个技能应该对应一个用户在达成目标过程中可感知的最小完整动作。查询天气是一个完整动作查询天气并推荐穿衣并规划路线就不是一个动作而是一个流程。流程应该由Agent在上层去编排而不是揉进一个技能里。按照这个标准去拆分你的技能库会有几十个原子技能加上几个流程编排规则整体结构会非常清晰。最后分享一个我个人的习惯每加一个新技能都会在测试环境跑一轮边界问答专门用那些意图不明确的、带指代词、带省略的句子去砸它。技能机制不怕模型笨怕的是技能描述写得不到位。很多时候改一句description的收益比优化一整天代码都大。这套机制跑顺之后Agent的扩展方式就从改代码变成了加技能我自己的开发效率提升了不止一倍。