★ FEATURED ARTICLE 最近在组里复盘智能体项目进度发现大家最头疼的问题出奇一致模型能聊但不会干活。Agent Skills这个词最近在圈子里讨论得很多核心就一句话——把大模型从“聊天窗口”里解放出来给它装上手脚再给它攒一本经验库。这里的“手脚”指模型真正调用外部工具、操作业务系统的能力“经验库”则是一边跑任务一边沉淀下来的方法论和避坑记录。这篇文章就把我自己搭智能体时怎么设计技能、怎么建设经验库、怎么让这两件事协同工作的整套思路拆开讲清楚适合正在做智能体应用但又觉得“只会对话、干不了实事”的开发者参考。1. 先拆清楚Agent Skills到底是什么1.1 为什么大模型必须要有“手脚”很多人第一次接触智能体时以为把业务逻辑写进提示词就能让模型干活实测下来完全不是那么回事。大模型本质上是一个语言模型它的强项是理解、生成、推理但你要它真正去查一个订单、改一条数据库记录、调用一个外部接口它做不到——它连一次真实的网络请求都发不出去。这个限制决定了智能体想要从“玩具”变成“工具”必须在模型之外接一套可以执行动作的组件这个组件就是技能Skill。我习惯用一个类比来解释技能的作用模型是大脑技能是手。大脑负责想清楚“该做什么”手负责把想法落地成动作。你想让智能体帮你订会议室大脑能理解“帮我订明天下午三点的会议室”这句话但它不知道会议室系统长什么样、接口怎么调、参数怎么传。这时候就需要一个“订会议室”技能把接口地址、入参格式、出参格式全部封装好模型只要按约定的格式调用它就行。这个过程在工程上叫函数调用Function Calling而Agent Skills就是在函数调用之上再做一层更完整的封装。其实很多刚开始做智能体的人连函数调用都不太熟练直接上手Agent Skills确实有点跳跃。但换个角度想函数调用是“让模型能调一个函数”Agent Skills是“让模型知道什么场景该调哪个函数、调的时候应该传什么参数、调用结果该怎么解读、失败时该怎么补救”这是完整的行为闭环。没有这层封装你就得在每次对话里重写一堆工具定义和调用规则项目一复杂立刻失控。1.2 技能的“静态能力”和经验库的“动态积累”要分清再把概念往细了拆。技能和能力是两个层面的东西。技能回答的是“智能体能做什么”它是一个静态清单比如“查库存”“下订单”“生成报表”每个技能对应一套可执行的逻辑。经验库回答的是“智能体怎么做更好”它是一个动态沉淀比如“用户问库存时要先问清哪个仓库”“库存不足时要顺带推荐替代品”这些是模型跑完任务之后总结出来的行为模式。我见过不少项目上来就一股脑堆技能结果模型根本不知道该选哪个或者选了但用得很别扭。核心原因就是缺了经验库这层“决策依据”。举个例子某客服智能体有“查订单”和“查物流”两个技能两个技能本质上都调同一个订单系统。如果没有经验库告诉模型“用户问‘到哪了’优先走物流查询‘买了什么’优先走订单查询”模型可能两个技能都试一遍浪费调用次数不说用户体感还差。经验库的另一个价值是“把一次成功变成永久能力”。同样一个售后工单第一次处理时可能需要人工介入把处理步骤、判断依据、注意事项记下来形成一条经验。以后再出现相似工单智能体检索到这条经验就能直接复用处理思路效率完全不一样。这也是为什么我始终认为技能是智能体的“当下能力”经验库是智能体的“长期复利”。2. 技能层怎么设计才不容易翻车2.1 一个合格技能必备的三个核心要素先说结论一个技能能不能被模型正确使用90%取决于你在定义阶段有没有把下面三件事写清楚。第一是触发条件。技能不是任何时候都该被调用的你得告诉模型“什么情况用我”。触发条件可以基于意图识别、关键词匹配、规则判断也可以综合几种方式。比如“查天气”技能触发条件就是“用户提到天气、气温、降水、穿衣建议等与气象相关的诉求”。但光有这个还不够最好写明“不要随便触发”的负向条件。比如用户说“今天心情不好”虽然提到了“今天”但完全和天气无关如果没有负向兜底模型可能真的去查天气很尴尬。第二是执行体。这是技能真正的逻辑部分可以是调用一个HTTP接口也可以是一段本地代码甚至可以是一个需要人工确认的半自动流程。执行体要把模型的“意图”翻译成业务系统能理解的“动作”。以订会议室为例模型输出的是“明天下午三点、容纳10人、需要投影”执行体要把它拼成会议室系统的API请求处理鉴权、参数校验、返回结果解析。第三是输入输出Schema。这一步是我自己踩坑最多的。大模型天生有“幻觉参数”的毛病你要它传时间它可能会编一个不存在的日期。所以技能定义里的参数一定要写明类型、取值范围、是否必填、枚举可选值。比如“时间”字段要用标准ISO格式“会议室ID”必须来自前置查询步骤的返回结果。输出Schema同样重要你得约定好执行结果用什么结构返回给模型包括是否成功、错误码、业务数据字段。这样模型才知道下一步该怎么处理。2.2 主流技能接入方式与选型对比现在业界接入技能的方式主要有三种原生函数调用、统一协议接入、工作流引擎编排。三种方式我都跑过一遍简单说下区别。函数调用是目前最常见的做法思维链路短、接入成本低。你在模型接口里直接声明一批函数模型在输出的合适位置引用函数名和参数你的代码去执行并回传结果。这种方式适合技能数量不多几十个量级、调用逻辑简单的场景。我做过的一个知识库问答系统就只用了十几个函数调用维护起来很轻松。统一协议接入则以MCP为代表。它的思路是让技能变成一个标准的“可挂载服务”通过统一的协议来描述工具、连接方式、调用约定。好处是技能可以跨平台复用团队A做的技能团队B拿来就能用不用重新适配。缺点是标准还在快速演进周边生态没那么成熟如果你只想内部快速交付引入这套协议反而增加了学习成本。工作流引擎编排适合复杂场景。比如“退换货”这个动作要依次调用“查订单”“查库存”“生成退货单”“通知仓库”等多个能力而且步骤之间有先后、有分支、有回退。这种场景下让模型自由调用所有技能容易失控不如引擎写死一套流程模型只在关键节点做决策。代价是灵活性降低流程一变就要改代码。我在选型时通常看三个维度技能数量、场景复杂度、团队维护成本。技能少就函数调用系统多就统一协议流程繁琐就工作流编排。没有银弹适合就是最好。2.3 技能描述写给模型看的产品说明书这点单独拿出来讲因为在真实项目中翻车率最高。技能描述是写给模型看的“产品说明书”不是文档给人类看的。你需要用模型容易理解的语言把技能的用途、使用限制、参数语义写清楚。举个例子。一开始我写了一个“查询订单”技能描述是“查询订单信息返回订单详情”。看起来很简洁对吧实际上模型根本不知道该在什么时候用它。后来我改成这样技能用途是“查询用户订单详情适用于用户询问订单状态、下单时间、订单金额、商品清单等场景”使用限制是“仅查询本会话内已绑定的用户订单跨用户查询请先调用用户鉴权技能”参数说明里写明“order_id为必填来自上一轮订单列表查询的返回结果不能用户提供任意值”。改完之后模型的选择准确率明显提升。还有个容易被忽略的地方技能描述也要写清楚“不要做什么”。负向约束比正向描述更重要。比如“查天气”技能里加一句“本技能仅用于获取天气信息不提供穿衣建议穿衣建议由推荐技能完成”模型就不会顺着天气话题自己发挥。我在多个项目里验证过加负向约束之后误调用次数能下降五六成。不要小看这个步骤。技能描述写得好不好直接决定了模型的工具选择准确率而工具选择一旦错了后面所有步骤都是白费。与其之后反复调prompt不如在技能定义阶段多花半小时把描述写透。3. 经验库把一次任务变成永久能力的关键3.1 经验条目到底应该记什么经验库的存储结构决定了后续能不能被高效检索和复用。我的实践是每条经验至少包含五个部分目标、步骤、前提条件、反面教训、效果反馈。这五部分各司其职组合起来才是一条可用的经验。目标描述这条经验适用什么场景。写的时候尽量具体比如“处理非工作时间提交的加急工单”而不是笼统的“客户服务”。步骤记录实际做这件事的完整流程每一步都要有可执行性。前提条件很重要比如“仅适用于VIP客户”“仅在库存充足时可用”这是避免经验被错误复用的关键。反面教训是踩坑记录比如“该操作会弹确认框必须在自动化脚本里先处理弹窗”。效果反馈是这条经验被使用后的效果评分用来决定它是否继续有效。存储载体上我建议用向量数据库配合元数据标签。向量用于语义检索标签用于过滤。比如每条经验打上“售后”“电商”“高优先级”这样的标签查询时先缩小范围再做语义匹配准确率和响应速度都更理想。这里有个常见的误解经验库不等于知识库。知识库存的是静态资料经验库存的是动态做法。一个说“该产品支持7天无理由退货”是知识一个说“退款操作需要先取消发货单否则系统会报库存异常”是经验。智能体真正需要的是后者因为知识可以直接丢给模型理解经验则需要被“执行”。3.2 经验回流从自动记录到检索注入经验库建好之后更关键的是怎么让它持续产生价值。我的做法分三步沉淀、清洗、注入。沉淀就是让每一次成功的任务执行都被记录下来。最简单的方式是写一个日志Hook任务执行结束时自动把目标、步骤、结果整理成经验草稿。这里我会刻意保留原始执行轨迹因为模型中间经历了哪些分支、调用过哪些技能这些过程信息比结果本身更有参考价值。清洗则是从草稿到正式经验的过滤过程。不是每条日志都值得沉淀。那些依赖随机因素的、只适用于单次场景的记录应该直接过滤掉。我一般会在清洗环节加一个人工确认门槛每周定期看一遍生成的草稿挑出真正可复用的部分入库。如果你觉得人工审核太重也可以用规则过滤加定期抽查的方式。注入是经验真正发挥作用的一步。我通常在每次任务开始前先把用户问题做一次向量检索从经验库里找出最相关的Top-K条经验拼进系统提示词里作为上下文。这个做法业内叫RAG检索增强生成。检索注入的核心是控制数量和质量注入太多提示词膨胀模型注意力被稀释注入太少参考意义不大。我实测下来Top-K在3到5之间效果最好具体取决于任务复杂度可以先用这个区间做基线再慢慢调。经验库生效后智能体会产生一个很微妙的变化它不再每次从零开始“想”怎么做而是变成“回忆”之前做过的成功路径再结合当前情况进行微调。这就像老员工处理问题比新员工快不是因为他智商高而是因为他见过足够多的场景形成了肌肉记忆。经验库就是给智能体做肌肉记忆训练。3.3 经验污染最隐蔽但必须防的大坑经验库最大的风险不是没有经验而是被“错误经验”污染。一旦坏经验进了库智能体会反复用它指导后续任务越用越“信”形成恶性循环。我在一个项目中就吃过亏某条经验把“用户说不要了”错误理解为“取消订单”导致一系列误操作排查了大半天才定位到源头。防污染机制我有几个方案。第一是经验得分机制每条经验被使用后用任务的成功率给它打分连续得分偏低就直接降权或移除。第二是新经验“试用期”新入库的经验先标记为“灰度”状态只有使用效果稳定的才转正。第三是定期人工审计尤其在高风险业务场景绝对不能全自动跑人工看一遍流程即使效率低也值得。另外经验库要保留版本和状态信息。版本记录的是这条经验的迭代历史状态则是草稿、生效、废弃三态流转。这样即使一条经验被改坏了也能快速回滚到之前的版本。我见过一些团队把经验库搞成了“纯追加”的日志只进不出跑了几个月后噪声比信号还多检索效果全线下降。经验库需要做减法跟数据库要做索引优化一个道理。4. 完整实操从零搭一个带技能与经验库的客服助手4.1 定义需求与技能清单这次我用一个虚构的客服助手项目来完整走一遍流程方便你直接照着复现。场景是某电商平台的售后咨询智能体需要完成三类工作识别用户问题类型、查询订单信息、给出处理建议。技能清单我先定为三个。技能一是“问题分类”负责把用户的问题归为“订单查询”“退换货”“发票”“投诉”等几个类别这个技能本身不用调外部接口靠规则和模型判断就能完成。技能二是“订单信息查询”调用订单系统的接口根据用户ID和关键词返回订单状态、商品、金额等数据。技能三是“处理建议生成”根据问题类型和订单数据从经验库检索最合适的处理路径并生成答复建议。这三个技能的分工很有意思问题分类决定“走哪个处理分支”订单查询提供“决策所需的数据”处理建议生成则结合数据和经验完成“最终输出”。三个阶段每一环都依赖前一级的结果如果第一级就分错类后面的流程基本全错。4.2 技能定义与基础代码技能定义我推荐用JSON Schema的方式描述它既能被模型接口原生支持也便于维护和版本管理。下面给出“订单信息查询”技能的完整定义。{ name: order_info_query, description: 查询用户订单信息。适用场景用户询问订单状态、商品明细、订单金额、物流信息等。仅可查询当前会话已授权用户的订单禁止跨用户查询。, parameters: { type: object, properties: { user_id: { type: string, description: 当前会话授权用户的唯一标识来自会话上下文禁止由用户直接提供 }, keyword: { type: string, description: 查询关键词可选例如商品名、订单号前缀等 }, limit: { type: integer, description: 返回订单数量上限默认5 } }, required: [user_id] } }描述里特别强调了“仅可查询当前会话已授权用户的订单”“user_id来自会话上下文”这两句话能在很大程度上防止越权和参数幻觉。我把这些约束写成技能注册代码的注释强制走审查流程确保后续迭代的人不会随手删掉。再来看技能的执行体部分。这里我用一个简单的Python函数来模拟。真正的项目里这一层要做的核心工作是参数校验、鉴权、调用下游接口、结果结构化和异常分类。def execute_order_query(params): # 强制参数校验使用实际鉴权信息绝不接受用户直接传入的user_id current_user get_session_user() if params.get(user_id) ! current_user: raise PermissionError(user_id越权访问) # 调用订单系统接口模拟 result order_system_api.query( user_idparams[user_id], keywordparams.get(keyword, ), limitparams.get(limit, 5) ) # 结果按约定结构返回成功标志、数据、错误码 return { success: True, data: result, error_code: None }注意返回结构里我永远带回success与error_code这两个字段决定了模型如何处理后续逻辑。如果success是False模型应该尝试换个方式查询或者明确告诉用户系统暂时不可用而不是硬编一个结果出来。这个约定最开始没有结果模型在接口失败时反而“脑补”了一个假订单数据差点出了生产事故。技能三“处理建议生成”稍微特殊一点它不直接调接口而是先做一次经验库检索再把检索结果作为上下文交给模型组合答复。我把这部分代码也贴出来。def generate_suggestion(problem_type, order_data): # 组装检索条件问题类型订单状态是最主要过滤项 filter_tags [problem_type] if order_data: filter_tags.append(order_data.get(status, )) related_experiences experience_store.search( queryf{problem_type} 处理建议, filter_tagsfilter_tags, top_k3 ) # 注入经验正文同时给出引用来源方便模型在答复中注明依据 context_text \n.join([exp.content for exp in related_experiences]) return compose_response(context_text, order_data)4.3 组装Agent主循环技能定义好了经验库也接上了现在把它们组装成一个完整的Agent主循环。我的做法是接收用户消息先做意图判断再执行相关技能中间不断把结果回填给模型最后生成用户答复。这是一个标准的Agent多步骤执行流程。def agent_loop(user_session, user_message): # 第一步用“问题分类”技能确定处理分支 classify_result call_skill(classify, {message: user_message}) problem_type classify_result[data][category] # 第二步根据分类结果决定是否查询订单数据 order_data None if problem_type in (order_query, after_sale, invoice): order_data call_skill( order_info_query, {user_id: user_session.user_id} ).get(data) # 第三步检索经验库并生成答复 suggestion call_skill( handle_advice, {problem_type: problem_type, order_data: order_data} ) # 第四步执行完成后异步记录经验草稿 record_experience_draft( session_iduser_session.id, steps[problem_type, order_data, suggestion], resultsuccess ) return suggestion这版代码里最关键的一行是最后的record_experience_draft它每执行一次任务就自动生成一条经验草稿。跑了几天之后经验库里就会积累出各种问题类型的处理轨迹。我再定期清洗转正智能体的能力就会随着使用时长越来越强。这就是前面说的“复利效应”。4.4 上线后的效果与调优要点这套客服助手跑了几周之后最大的变化不是分类准确率而是“一次解决率”。一开始智能体经常给用户一个标准话术就完事用户再追问两句又得换通道转人工。经验库积累到一定量级后它开始知道“退款超时用户需要补一句进度查询入口”“发票开具失败要先确认抬头信息”这些细节都是普通对话模型不会主动说出来的而它们恰恰是用户满意度提升的关键。需要提醒的是第四步“异步记录经验草稿”一定要做异步处理不要让用户等待。我在最初版本里是在同步链路里写日志结果一次高频查询窗口期日志队列阻塞了主流程用户响应时间直接从1秒变成10秒属于典型的低级坑。异步落库加上重试机制才是稳妥做法。5. 高频故障与排查思路实录5.1 技能误触发和参数幻觉的处理先说说技能误触发。模型把不相关的用户问题关联到某个技能上最常见的补救是强化技能描述里的负向约束。比如某次用户问“订单为什么没发货”模型触发了“补开发票”技能原因是技能描述里只写了“处理订单相关事务”。我把所有技能描述统一加上了“仅当用户明确提到XX时才触发用户未主动要求时禁止触发”误触发率立刻降了下来。参数幻觉又是另一码事。模型编造不存在的参数值根源在于Schema不够严格。我有一个专门对付这个问题的习惯凡是能从上下文推导的参数一律不在技能定义的参数清单里开放给模型而是由执行体在代码里自动注入。比如user_id模型根本不需要传它在执行体里从会话上下文自己取。这样能直接砍掉一大半参数幻觉场景。如果参数必须由模型从用户语句中提取那就一定要给枚举值。比如“订单状态”参数只允许传pending、shipped、completed、cancelled这四个枚举值模型就没法自己发挥创造新状态。配合后端的二次校验拦截参数层面的可靠性基本能保证在99%以上。5.2 经验库检索不准确和注入膨胀经验库的检索质量直接影响智能体回答质量。我遇到过的典型问题是检索返回的经验语义上相似但场景根本不适用。例子是“退款”类经验有的适用于“七天无理由”有的适用于“质量问题”两者处理路径差很远。光靠向量相似度区分不了这么细的差别得靠过滤标签兜底。我的做法是强制每个技能在查询经验库时都必须带上业务标签过滤条件比如问题类型、订单状态、用户等级。标签过滤把候选集缩小到几十条再做向量排序准确率就高很多。另一个问题是注入膨胀。经验库刚起步时只有几十条我习惯把所有匹配的都注入结果提示词超长模型反而抓不住重点。后来固定注入条数并且在经验正文前加“经验要点”摘要让模型优先读取摘要需要细节再展开看原文。经验库还可以做轻量的时效性衰减。某些经验只适用于特定促销季过了那个时间就逐渐失效。我设置了一个衰减因子经验超过设置的天数后自动降权新经验优先被检索到。这个机制很粗糙但在大多数场景下比纯静态检索要靠谱。5.3 排障工具箱与兜底建议做Agent排障时我习惯用一个“输入-输出-执行轨迹”三段式分析。先看模型的输入里到底注入了什么上下文有没有经验库内容有没有技能描述再看模型的输出是准备调哪个技能最后看执行体有没有真正执行成功。大多数问题其实能在执行轨迹里找到答案模型只是一层“翻译官”真正的问题往往是技能定义或数据链路出的错。还有一个很重要的兜底建议任何技能都建议配套一个“人工接管”出口。技能执行失败、经验库检索不到可用经验或者模型连续两次给出相同错误答复时应该主动把会话转给人工。智能体不是用来完全替代人的它是用来处理那80%重复场景的剩下20%复杂场景交接给人去处理体验反而更好。5.4 我最后想说的一点Agent Skills这套东西本质上解决的是智能体“会做”和“做得对”之间的鸿沟。模型负责会理解技能负责会执行经验库负责做得对。三者缺一不可也没有任何一环节可以一劳永逸——技能要随业务迭代经验库要持续清洗模型选择也要跟着场景调整。我自己最大的体会是千万别把经验库当成锦上添花的东西。它才是智能体项目真正产生积累的地方。技能是搭好的骨架经验是长出来的肌肉跑得越久你的智能体和其他人用同一套模型搭出来的智能体差距会拉得越开。趁早把经验回流的闭环建起来后面越用越顺手这就是这个领域里最值得花时间的复利投资。
阅读完成 · 觉得有帮助？
