1. 内容整体设计与思路拆解1.1 为什么Agent需要一套独立的“技能层”做过大模型应用的开发者基本都会撞到同一堵墙模型本身很强但一到具体任务就“有脑子没手”。让模型直接写代码、查库存、发邮件它要么编出根本不存在的接口要么把参数格式猜得七扭八歪——问题不在于模型笨而在于你缺了一层把“意图”翻译成“动作”的中间件。这套中间件就是agent-skills所指向的东西一套给智能体预备的、可复用、可组合、可观测的外部能力集。我最早意识到这个问题的场景特别朴素。当时我接了一个内部知识库问答项目模型能答得头头是道但一让它去查最新项目排期它就开始胡编“部门周报显示”之类根本不存在的数据。后来我在模型前面加了一层技能调度把“查询数据库”“读取周报文件”“调用日历API”这些动作全部封装成独立技能模型只需要选择技能、填好参数剩下的脏活累活全交给技能层去执行。效果立竿见影幻觉率肉眼可见地下降因为模型不再需要“记住”数据它只需要知道“去哪里拿数据”。这里有一个关键认知所谓agent-skills本质上是在模型和外部世界之间架一座桥。模型负责“想”技能层负责“做”。这座桥设计得好不好直接决定了智能体是可靠的生产工具还是只能陪聊的玩具。国内团队做AI应用最容易踩的坑是把技能层和大模型逻辑强行耦合在一起改一个接口要重写一半Agent逻辑维护成本高到怀疑人生。所以设计的第一原则就是把技能与决策彻底解耦。1.2 技能集设计的四条底层原则结合我实际做过和拆解过的项目一套能长期进化的agent-skills体系基本都遵循下面四条原则。第一单一职责。一个技能最好只做一件事。“查询天气”和“发送天气提醒邮件”不要做成同一个技能因为前者的输出可能是后者的输入拆开之后你就可以在“查询天气”后面再接一个“生成日报”技能组合出无限玩法。而耦合在一起想复用就束手束脚。第二输入输出契约化。每个技能必须有清晰、严格的入参和出参定义最好用JSON Schema这样的结构来描述。模型不需要理解这个技能的代码实现它只需要知道给我什么字段我能得到什么结果。就好比你去餐厅吃饭不需要知道后厨怎么炒菜只看菜单——技能就是那道菜菜单就是Schema。第三可观测性优先。每个技能的执行都应该记录日志、耗时、成功与否。这一步很多团队会省略但在真实生产环境里技能层往往是排查问题的第一现场。模型回复错了先查技能层日志是不是参数传错是不是工具本身报错有了观测数据排障速度能快出好几倍。第四可灰度、可回滚。技能层更新时不要一次性替换所有版本。按用户比例灰度出问题能立刻回退。我见过不止一个团队把技能层当成普通代码库直接全量上线结果某个技能接口的返回格式微调后模型立刻开始“发挥想象力”解读新格式各种诡异问题冒出来。技能层面向的是模型模型对变化的敏感度比人类用户要高得多——人类看到页面样式变了还能自适应模型看到输出格式变了可能直接把任务搞崩。2. 核心细节解析与实操要点2.1 技能注册与描述编写决定Agent“眼光”的关键一环在agent-skills体系里技能的注册信息就是模型的“视野”直接决定模型能不能在关键时刻想起还藏着这么个工具。描述信息太笼统模型该调用时不会调用描述信息太冗长模型会被无关细节带偏。我给自己的项目定了一套描述模板每条技能描述包含四个部分。第一是功能概要一句话说明这个技能做什么。第二是适用场景给一两个典型的调用场景示例帮模型建立“何时用它”的直觉。第三是重要约束比如“此技能只能查询已授权企业数据”或“输出结果按降序排列”避免模型对结果做出错误假设。第四是参数说明逐一解释每个字段的含义和格式要求。这四个部分用纯文本组织别用复杂的嵌套JSON——模型对长文本的理解能力很强但对结构极端复杂的文本反而容易丢失关键信息。我在一次测试中发现同样一个技能描述从JSON改成自然语言段落式之后模型在端到端任务中的工具选择准确率提升了将近12个百分点。还有个细节容易被忽略技能名称别怕长怕的是含义模糊。“get_weather”和“get_weather_by_city_and_date”在语义清晰度上差着一大截。即便后者写起来长一些模型一眼就能明确它的能力和边界。2.2 参数解析与类型校验给模型装上“安全带”模型填充参数时的自由度是一把双刃剑给够了自由度模型在面对复杂情况时能灵活适配完全不加约束模型就会在生产环境里自创枚举值。你定义一个状态参数只允许“open”“closed”“pending”三种取值模型可能平白无故填一个“in_progress”进去。接口收到无法识别的参数直接报错任务链断裂。解决方案是在技能层的入口做严格校验不要信任模型传来的任何参数。校验在工程上不算事很多语言都有现成的Schema验证库。但这里的关键不在校验本身而在校验失败之后的处理策略——不是退回错误让模型重新填一遍而是把错误信息加工成“纠正提示”告诉模型哪个字段错了、合法取值有哪些然后允许模型在同一轮对话内重新发起调用。这种纠错机制的效果非常显著。我做过一个自然语言转SQL的技能初期不加纠错逻辑模型填错参数后强制整轮重来成功率一直在75%左右反复横跳。后来改成错误提示加重新调用机制成功率稳定在90%以上。原因很好理解大模型对话本身就是多轮过程给它一次“试错-反馈-修正”的机会远比让它一条路走到黑更符合模型的工作习惯。再补充一点日期、时间、枚举值这类参数尽量把格式写到描述里并在校验层主动做归一化。例如描述里写明“date字段使用YYYY-MM-DD格式”校验层看到“2024年3月5日”也能兼容性地解析后再喂给下游工具模型端不报错底层还稳当。2.3 技能编排从“选工具”到“走流程”单技能只能解决孤立问题真实业务基本都是链路。一个客服智能体收到用户投诉先要调用情绪识别技能判断严重程度再调知识库检索技能找解决方案最后调工单创建技能把问题派发出去。这条链路谁来编排业界目前有两条路线。路线一让模型端到端编排。也就是把可选技能全部暴露给模型让它自己决定怎么串。这种方式灵活度高能应对很多长尾场景但代价是不可控——模型可能上一步还在查物流状态下一步就毫无逻辑地跳到退换货流程任务链路越深跑偏的概率越大。路线二预先定义流程模板。把常见任务路径固化成模板模板里标注好每一步应该用什么技能、技能之间怎么传参。模型只需要在入口处做一次意图识别选中某个模板后按图索骥执行自由度大幅下降稳定性和可靠性则同步提升。我实践下来比较稳妥的是混合策略把高频场景固化成模板作为硬规则把低频长尾场景留给模型自由编排作为兜底。这就好比一个成熟的团队“标准作业流程”是写在手册里的遇到手册之外的事咋办请有经验的人临场判断。Agent团队里那个“有经验的人”就是模型。3. 实操过程与核心环节实现3.1 从零搭建一个技能包骨架讲理论总是轻巧的直接上手做一遍才知道沟沟坎坎在哪里。我以一个典型的“企业信息查询助手”为例演示如何给Agent设计一套技能包。目标功能是两个能回答“某某公司是做什么的”这类百科类问题也能回答“我们和某某公司的合同什么时候到期”这类企业内部数据问题。第一步是拆技能明确颗粒度边界。我最终拆出四个核心技能get_company_profile通过公开接口获取公司工商信息、主营业务、规模等search_internal_contracts检索内部合同数据库按公司名和日期过滤get_contract_detail通过合同ID获取合同全文的指定段落check_permission提前校验当前用户对某个公司/合同的访问权限。这样拆的考量是每个技能都只有一个明确的数据来源和产出形态未来无论怎么换数据源、怎么加新功能都不需要牵连其他技能。第二步是写技能描述。我给每个技能都按前面说的四段式模板来写。比如get_company_profile的描述先写“根据公司全称或简称查询企业基础工商信息”再写适用场景“当用户询问某公司的业务范围、规模、注册地、法定代表人等公开信息时使用”再补约束“本技能仅返回公开注册资料不含内部评价或合作记录”最后列出参数格式。这段描述写完我会拿给同事看问一个最简单的问题如果你是一个完全不认识这个代码的对话机器人看到这段描述你能在正确的时机调用它吗这个测试标准比任何评审都高效。第三步是定义输入输出结构。输出我统一封装成标准信封格式包含三块status成功/失败、data业务数据列表、message给模型看的状态说明。这种统一格式的好处天上地下——技能多了以后模型处理不同技能的返回时不需要“重新学习”大大降低理解成本。3.2 技能调度与执行的完整链路技能写好了怎么让模型真正跑起来这里我给出一套可以直接套用的执行链路。先做意图识别拿到用户问题后第一步任务不是去检索答案而是先过一遍分类器这个问题是查公开信息还是查内部合同还是两个都要分类可以采用传统的意图分类模型也可以直接用大模型做综合成本考虑我一般用大模型加一个极简的Prompt实现给定技能列表描述让模型输出需要调用的技能ID列表和入参。这一步的作用是把问题翻译成结构化的技能调用计划。接下来进入参数抽取阶段。模型需要从用户原始表述里提取关键字段比如“张三的公司”就要解析出公司名“张三的公司”再去看内部合同数据库里有没有这家公司的记录。提取结果送进技能层的校验器校验器返回一个结构化调用请求。如果校验不通过走前面设计的纠错流程把错误信息和合法取值范围一并回传模型。技能执行完成之后数据不能直接当作最终回答。你要设计一个“结果摘要”环节把技能返回的结构化数据重新生成一段自然语言回答。这个环节的目的不是为了让回答更漂亮而是为了让模型在拼接多技能结果时不会互相矛盾和遗漏关键信息。我在实践中发现凡是跳过摘要这一步的Agent回答经常是“数据在眼前但说不出重点”。如果链路跑通了最终你会得到下面这样的运行表现用户问题“我们和星辰科技的合作合同到没到期”运行过程意图识别 - 判定涉及内部合同 - 调用search_internal_contracts参数公司名星辰科技 - 返回合同列表找到一份合同ID - 调用check_permission校验当前用户对该合同的访问权限 - 返回有权限 - 调用get_contract_detail读取合同到期日 - 结果摘要 - 生成回答。整个过程四次技能调用完全透明每一步都能从日志里看到参数和返回结果问题定位成本极低。4. 常见问题与排查技巧实录4.1 模型“视而不见”不调用该调用的技能这是所有Agent项目里的头号高频问题技能明明在那里描述也写得清清楚楚模型就是死活不调用非要自己硬答。我排查这个问题一向按照固定的顺序来从可能性最高的查起。第一顺位检查描述与意图的匹配精度。模型不调用技能大概率是因为它没有意识到当前问题需要技能介入。比如你的“库存查询”技能描述里写的是“根据产品ID查询实时库存”用户问的是“还有没有货”模型可能根本联想到不上去。把描述改成“用于回答产品是否有现货、剩余数量等问题”立即见效。第二顺位检查上下文长度。如果系统提示词塞了太多背景说明技能列表被挤到上下文尾部模型的注意力分布会让技能描述“泡在最不起眼的位置”。适当精简提示词把技能列表的位置前移能非常有效地提高工具召回率。第三顺位检查示例缺失。给模型注入一两个“用户问什么就调用什么技能”的few-shot示例比在描述里反复强调一百遍都管用。模型是通过模式匹配来工作的你给它一个完美匹配的样本它就知道该怎么做了。4.2 工具真的崩了技能调用失败后的排查路径技能调用失败的排查其实是一个层层收敛的过程。我在新的Agent项目里都会准备一个技能自检清单按下面的顺序排查。先看调用参数是否合法。这个最常见前面已经说过。重点是要看是模型传参问题还是校验器配置问题。区分方法很简单把同一个参数用调试工具手动传给技能看能不能通。能通就是模型侧问题不能通就是校验器或技能本身有问题。再看凭据和权限。Agent技能经常要访问第三方服务Token过期、IP白名单变动、权限不足这些故障是长期潜伏的暗坑。我在日志系统里专门加了一条规则凡是技能报错涉及“401”“403”“auth”“permission”的直接亮红灯转人工。因为这些问题无法靠模型自身修正重试一百次也是白搭。最后看依赖服务的运行状态。技能本身没问题不代表技能背后的服务没问题。数据库慢查询、第三方API限流、对端服务宕机都会导致技能超时。给技能调用设计合理的超时时间和重试策略是第一道防线在超时后根据错误类型决定是重试、降级还是直接返回错误提示这是第二道防线。4.3 稳定的代价技能编排过度的隐忧技能化虽然好用但千万别把Agent变成“只会按流程走”的机器人。我遇到过最极端的情况一个面向C端用户的问答助手团队把99%的对话都固化成流程模板结果用户问一句“我昨天问你的那个问题还记得吗”Agent直接当机——因为这句话不在任何模板里。技能编排的目标应该是“覆盖多数容忍少数”而不是“覆盖所有拒绝少数”。平常用模板保证稳定遇到模板覆盖不到的场景允许模型自由发挥这也回到了前面说过的混合策略。模型的能力在进步技能层的设计目标不是束缚模型而是让模型在跑得更快的前提下不摔跤。我做项目时很喜欢套用一句话技能层是缰绳不是牢笼。缰绳能让马跑得更稳牢笼却会让马直接废掉。设计技能集的过程其实就是在找这个平衡点。5. 扩展方向与进阶心得5.1 从单Agent到多Agent技能如何跨智能体复用单Agent的技能包跑顺之后下一步的诱惑自然就是多Agent协作。这时候技能怎么共享就变成一个绕不开的架构问题。我的建议是技能层保持单体架构做成一个独立的中台服务所有Agent共享同一套技能注册中心。这样做的原因有两个。第一技能本身是无状态的它不需要知道调用自己的是“销售助手”还是“客服助手”只需要正确地接收参数、返回结果。这跟微服务的理念天然合拍。第二技能复用的价值不仅仅是省代码更是省成本——一个已被验证过的技能新Agent接入时不需要重新测试排障直接在注册中心点亮即可。多Agent场景下有一个新问题需要额外关注技能权限的按Agent隔离。销售助手和客服助手虽然共享同一套技能池但可调用范围和可见数据范围应当不同。我一般会在技能注册信息里加一个“allowed_agents”字段由网关在调度时强制校验防止越权调用。5.2 技能自动进化从手动编写到基于反馈的迭代现在这个阶段的技能绝大多数还是靠开发者一点点手写调试。但有一个趋势已经起来了——根据模型的实际调用记录和失败反馈自动生成和迭代技能描述。思路也不复杂。把用户问题和模型当时的思考链路存下来分析哪些场景下模型选了错误技能、选了技能却填错参数、技能执行后用户满意度低等等然后把这些反例喂给大模型让它给出技能描述的修正建议。我试验过一个小范围版本让大模型针对某个技能的失败样本输出“描述缺失信息”“参数约束不清晰”“适用场景边界模糊”等诊断结论再自动改写描述文本。运行两轮之后工具选择的准确率有可观察到的提升。不过要提醒一句这个方向还在很早期的探索阶段。自动改写的描述有可能引入歧义所以必须保留人工审批这个兜底环节。技能层是生产系统不是试验田任何自动化改动都必须有审计和回滚机制。5.3 非技术的最后一课技能集也是产品跑了很多项目之后我有一个很深的体会agent-skills这一个抽象概念落到产品层面它不只是开发者工具更是产品体验的一部分。技能覆盖度决定了Agent能不能解决用户的问题技能执行速度决定了Agent回应用户的体验技能失败时的反馈话术则决定了用户对Agent的信心。我见过很多团队在模型提示词上死磕却从不看一眼自己的技能层是不是已经老化。模型层花一周做优化可能只提升2%的效果技能层补充一两个高价值能力效果立刻提升一个档次。为什么因为模型的能力上限已经由它的参数规模定死了你对再多次话它也变不出新能力。但技能层是可以无限扩展的——每次给Agent装一个新“器官”它能做的事就实实在在多一圈。在这个意义上技能设计者的工作很像游戏里给角色配技能栏选什么技能、怎么排序、如何取舍最终决定了这个Agent在上手玩家手里是普通角色还是神装角色。所以把精力多分一些给技能层吧投入产出比一定比你想象的更高。
Agent技能层设计与实践：从意图到动作的中间件
1. 内容整体设计与思路拆解1.1 为什么Agent需要一套独立的“技能层”做过大模型应用的开发者基本都会撞到同一堵墙模型本身很强但一到具体任务就“有脑子没手”。让模型直接写代码、查库存、发邮件它要么编出根本不存在的接口要么把参数格式猜得七扭八歪——问题不在于模型笨而在于你缺了一层把“意图”翻译成“动作”的中间件。这套中间件就是agent-skills所指向的东西一套给智能体预备的、可复用、可组合、可观测的外部能力集。我最早意识到这个问题的场景特别朴素。当时我接了一个内部知识库问答项目模型能答得头头是道但一让它去查最新项目排期它就开始胡编“部门周报显示”之类根本不存在的数据。后来我在模型前面加了一层技能调度把“查询数据库”“读取周报文件”“调用日历API”这些动作全部封装成独立技能模型只需要选择技能、填好参数剩下的脏活累活全交给技能层去执行。效果立竿见影幻觉率肉眼可见地下降因为模型不再需要“记住”数据它只需要知道“去哪里拿数据”。这里有一个关键认知所谓agent-skills本质上是在模型和外部世界之间架一座桥。模型负责“想”技能层负责“做”。这座桥设计得好不好直接决定了智能体是可靠的生产工具还是只能陪聊的玩具。国内团队做AI应用最容易踩的坑是把技能层和大模型逻辑强行耦合在一起改一个接口要重写一半Agent逻辑维护成本高到怀疑人生。所以设计的第一原则就是把技能与决策彻底解耦。1.2 技能集设计的四条底层原则结合我实际做过和拆解过的项目一套能长期进化的agent-skills体系基本都遵循下面四条原则。第一单一职责。一个技能最好只做一件事。“查询天气”和“发送天气提醒邮件”不要做成同一个技能因为前者的输出可能是后者的输入拆开之后你就可以在“查询天气”后面再接一个“生成日报”技能组合出无限玩法。而耦合在一起想复用就束手束脚。第二输入输出契约化。每个技能必须有清晰、严格的入参和出参定义最好用JSON Schema这样的结构来描述。模型不需要理解这个技能的代码实现它只需要知道给我什么字段我能得到什么结果。就好比你去餐厅吃饭不需要知道后厨怎么炒菜只看菜单——技能就是那道菜菜单就是Schema。第三可观测性优先。每个技能的执行都应该记录日志、耗时、成功与否。这一步很多团队会省略但在真实生产环境里技能层往往是排查问题的第一现场。模型回复错了先查技能层日志是不是参数传错是不是工具本身报错有了观测数据排障速度能快出好几倍。第四可灰度、可回滚。技能层更新时不要一次性替换所有版本。按用户比例灰度出问题能立刻回退。我见过不止一个团队把技能层当成普通代码库直接全量上线结果某个技能接口的返回格式微调后模型立刻开始“发挥想象力”解读新格式各种诡异问题冒出来。技能层面向的是模型模型对变化的敏感度比人类用户要高得多——人类看到页面样式变了还能自适应模型看到输出格式变了可能直接把任务搞崩。2. 核心细节解析与实操要点2.1 技能注册与描述编写决定Agent“眼光”的关键一环在agent-skills体系里技能的注册信息就是模型的“视野”直接决定模型能不能在关键时刻想起还藏着这么个工具。描述信息太笼统模型该调用时不会调用描述信息太冗长模型会被无关细节带偏。我给自己的项目定了一套描述模板每条技能描述包含四个部分。第一是功能概要一句话说明这个技能做什么。第二是适用场景给一两个典型的调用场景示例帮模型建立“何时用它”的直觉。第三是重要约束比如“此技能只能查询已授权企业数据”或“输出结果按降序排列”避免模型对结果做出错误假设。第四是参数说明逐一解释每个字段的含义和格式要求。这四个部分用纯文本组织别用复杂的嵌套JSON——模型对长文本的理解能力很强但对结构极端复杂的文本反而容易丢失关键信息。我在一次测试中发现同样一个技能描述从JSON改成自然语言段落式之后模型在端到端任务中的工具选择准确率提升了将近12个百分点。还有个细节容易被忽略技能名称别怕长怕的是含义模糊。“get_weather”和“get_weather_by_city_and_date”在语义清晰度上差着一大截。即便后者写起来长一些模型一眼就能明确它的能力和边界。2.2 参数解析与类型校验给模型装上“安全带”模型填充参数时的自由度是一把双刃剑给够了自由度模型在面对复杂情况时能灵活适配完全不加约束模型就会在生产环境里自创枚举值。你定义一个状态参数只允许“open”“closed”“pending”三种取值模型可能平白无故填一个“in_progress”进去。接口收到无法识别的参数直接报错任务链断裂。解决方案是在技能层的入口做严格校验不要信任模型传来的任何参数。校验在工程上不算事很多语言都有现成的Schema验证库。但这里的关键不在校验本身而在校验失败之后的处理策略——不是退回错误让模型重新填一遍而是把错误信息加工成“纠正提示”告诉模型哪个字段错了、合法取值有哪些然后允许模型在同一轮对话内重新发起调用。这种纠错机制的效果非常显著。我做过一个自然语言转SQL的技能初期不加纠错逻辑模型填错参数后强制整轮重来成功率一直在75%左右反复横跳。后来改成错误提示加重新调用机制成功率稳定在90%以上。原因很好理解大模型对话本身就是多轮过程给它一次“试错-反馈-修正”的机会远比让它一条路走到黑更符合模型的工作习惯。再补充一点日期、时间、枚举值这类参数尽量把格式写到描述里并在校验层主动做归一化。例如描述里写明“date字段使用YYYY-MM-DD格式”校验层看到“2024年3月5日”也能兼容性地解析后再喂给下游工具模型端不报错底层还稳当。2.3 技能编排从“选工具”到“走流程”单技能只能解决孤立问题真实业务基本都是链路。一个客服智能体收到用户投诉先要调用情绪识别技能判断严重程度再调知识库检索技能找解决方案最后调工单创建技能把问题派发出去。这条链路谁来编排业界目前有两条路线。路线一让模型端到端编排。也就是把可选技能全部暴露给模型让它自己决定怎么串。这种方式灵活度高能应对很多长尾场景但代价是不可控——模型可能上一步还在查物流状态下一步就毫无逻辑地跳到退换货流程任务链路越深跑偏的概率越大。路线二预先定义流程模板。把常见任务路径固化成模板模板里标注好每一步应该用什么技能、技能之间怎么传参。模型只需要在入口处做一次意图识别选中某个模板后按图索骥执行自由度大幅下降稳定性和可靠性则同步提升。我实践下来比较稳妥的是混合策略把高频场景固化成模板作为硬规则把低频长尾场景留给模型自由编排作为兜底。这就好比一个成熟的团队“标准作业流程”是写在手册里的遇到手册之外的事咋办请有经验的人临场判断。Agent团队里那个“有经验的人”就是模型。3. 实操过程与核心环节实现3.1 从零搭建一个技能包骨架讲理论总是轻巧的直接上手做一遍才知道沟沟坎坎在哪里。我以一个典型的“企业信息查询助手”为例演示如何给Agent设计一套技能包。目标功能是两个能回答“某某公司是做什么的”这类百科类问题也能回答“我们和某某公司的合同什么时候到期”这类企业内部数据问题。第一步是拆技能明确颗粒度边界。我最终拆出四个核心技能get_company_profile通过公开接口获取公司工商信息、主营业务、规模等search_internal_contracts检索内部合同数据库按公司名和日期过滤get_contract_detail通过合同ID获取合同全文的指定段落check_permission提前校验当前用户对某个公司/合同的访问权限。这样拆的考量是每个技能都只有一个明确的数据来源和产出形态未来无论怎么换数据源、怎么加新功能都不需要牵连其他技能。第二步是写技能描述。我给每个技能都按前面说的四段式模板来写。比如get_company_profile的描述先写“根据公司全称或简称查询企业基础工商信息”再写适用场景“当用户询问某公司的业务范围、规模、注册地、法定代表人等公开信息时使用”再补约束“本技能仅返回公开注册资料不含内部评价或合作记录”最后列出参数格式。这段描述写完我会拿给同事看问一个最简单的问题如果你是一个完全不认识这个代码的对话机器人看到这段描述你能在正确的时机调用它吗这个测试标准比任何评审都高效。第三步是定义输入输出结构。输出我统一封装成标准信封格式包含三块status成功/失败、data业务数据列表、message给模型看的状态说明。这种统一格式的好处天上地下——技能多了以后模型处理不同技能的返回时不需要“重新学习”大大降低理解成本。3.2 技能调度与执行的完整链路技能写好了怎么让模型真正跑起来这里我给出一套可以直接套用的执行链路。先做意图识别拿到用户问题后第一步任务不是去检索答案而是先过一遍分类器这个问题是查公开信息还是查内部合同还是两个都要分类可以采用传统的意图分类模型也可以直接用大模型做综合成本考虑我一般用大模型加一个极简的Prompt实现给定技能列表描述让模型输出需要调用的技能ID列表和入参。这一步的作用是把问题翻译成结构化的技能调用计划。接下来进入参数抽取阶段。模型需要从用户原始表述里提取关键字段比如“张三的公司”就要解析出公司名“张三的公司”再去看内部合同数据库里有没有这家公司的记录。提取结果送进技能层的校验器校验器返回一个结构化调用请求。如果校验不通过走前面设计的纠错流程把错误信息和合法取值范围一并回传模型。技能执行完成之后数据不能直接当作最终回答。你要设计一个“结果摘要”环节把技能返回的结构化数据重新生成一段自然语言回答。这个环节的目的不是为了让回答更漂亮而是为了让模型在拼接多技能结果时不会互相矛盾和遗漏关键信息。我在实践中发现凡是跳过摘要这一步的Agent回答经常是“数据在眼前但说不出重点”。如果链路跑通了最终你会得到下面这样的运行表现用户问题“我们和星辰科技的合作合同到没到期”运行过程意图识别 - 判定涉及内部合同 - 调用search_internal_contracts参数公司名星辰科技 - 返回合同列表找到一份合同ID - 调用check_permission校验当前用户对该合同的访问权限 - 返回有权限 - 调用get_contract_detail读取合同到期日 - 结果摘要 - 生成回答。整个过程四次技能调用完全透明每一步都能从日志里看到参数和返回结果问题定位成本极低。4. 常见问题与排查技巧实录4.1 模型“视而不见”不调用该调用的技能这是所有Agent项目里的头号高频问题技能明明在那里描述也写得清清楚楚模型就是死活不调用非要自己硬答。我排查这个问题一向按照固定的顺序来从可能性最高的查起。第一顺位检查描述与意图的匹配精度。模型不调用技能大概率是因为它没有意识到当前问题需要技能介入。比如你的“库存查询”技能描述里写的是“根据产品ID查询实时库存”用户问的是“还有没有货”模型可能根本联想到不上去。把描述改成“用于回答产品是否有现货、剩余数量等问题”立即见效。第二顺位检查上下文长度。如果系统提示词塞了太多背景说明技能列表被挤到上下文尾部模型的注意力分布会让技能描述“泡在最不起眼的位置”。适当精简提示词把技能列表的位置前移能非常有效地提高工具召回率。第三顺位检查示例缺失。给模型注入一两个“用户问什么就调用什么技能”的few-shot示例比在描述里反复强调一百遍都管用。模型是通过模式匹配来工作的你给它一个完美匹配的样本它就知道该怎么做了。4.2 工具真的崩了技能调用失败后的排查路径技能调用失败的排查其实是一个层层收敛的过程。我在新的Agent项目里都会准备一个技能自检清单按下面的顺序排查。先看调用参数是否合法。这个最常见前面已经说过。重点是要看是模型传参问题还是校验器配置问题。区分方法很简单把同一个参数用调试工具手动传给技能看能不能通。能通就是模型侧问题不能通就是校验器或技能本身有问题。再看凭据和权限。Agent技能经常要访问第三方服务Token过期、IP白名单变动、权限不足这些故障是长期潜伏的暗坑。我在日志系统里专门加了一条规则凡是技能报错涉及“401”“403”“auth”“permission”的直接亮红灯转人工。因为这些问题无法靠模型自身修正重试一百次也是白搭。最后看依赖服务的运行状态。技能本身没问题不代表技能背后的服务没问题。数据库慢查询、第三方API限流、对端服务宕机都会导致技能超时。给技能调用设计合理的超时时间和重试策略是第一道防线在超时后根据错误类型决定是重试、降级还是直接返回错误提示这是第二道防线。4.3 稳定的代价技能编排过度的隐忧技能化虽然好用但千万别把Agent变成“只会按流程走”的机器人。我遇到过最极端的情况一个面向C端用户的问答助手团队把99%的对话都固化成流程模板结果用户问一句“我昨天问你的那个问题还记得吗”Agent直接当机——因为这句话不在任何模板里。技能编排的目标应该是“覆盖多数容忍少数”而不是“覆盖所有拒绝少数”。平常用模板保证稳定遇到模板覆盖不到的场景允许模型自由发挥这也回到了前面说过的混合策略。模型的能力在进步技能层的设计目标不是束缚模型而是让模型在跑得更快的前提下不摔跤。我做项目时很喜欢套用一句话技能层是缰绳不是牢笼。缰绳能让马跑得更稳牢笼却会让马直接废掉。设计技能集的过程其实就是在找这个平衡点。5. 扩展方向与进阶心得5.1 从单Agent到多Agent技能如何跨智能体复用单Agent的技能包跑顺之后下一步的诱惑自然就是多Agent协作。这时候技能怎么共享就变成一个绕不开的架构问题。我的建议是技能层保持单体架构做成一个独立的中台服务所有Agent共享同一套技能注册中心。这样做的原因有两个。第一技能本身是无状态的它不需要知道调用自己的是“销售助手”还是“客服助手”只需要正确地接收参数、返回结果。这跟微服务的理念天然合拍。第二技能复用的价值不仅仅是省代码更是省成本——一个已被验证过的技能新Agent接入时不需要重新测试排障直接在注册中心点亮即可。多Agent场景下有一个新问题需要额外关注技能权限的按Agent隔离。销售助手和客服助手虽然共享同一套技能池但可调用范围和可见数据范围应当不同。我一般会在技能注册信息里加一个“allowed_agents”字段由网关在调度时强制校验防止越权调用。5.2 技能自动进化从手动编写到基于反馈的迭代现在这个阶段的技能绝大多数还是靠开发者一点点手写调试。但有一个趋势已经起来了——根据模型的实际调用记录和失败反馈自动生成和迭代技能描述。思路也不复杂。把用户问题和模型当时的思考链路存下来分析哪些场景下模型选了错误技能、选了技能却填错参数、技能执行后用户满意度低等等然后把这些反例喂给大模型让它给出技能描述的修正建议。我试验过一个小范围版本让大模型针对某个技能的失败样本输出“描述缺失信息”“参数约束不清晰”“适用场景边界模糊”等诊断结论再自动改写描述文本。运行两轮之后工具选择的准确率有可观察到的提升。不过要提醒一句这个方向还在很早期的探索阶段。自动改写的描述有可能引入歧义所以必须保留人工审批这个兜底环节。技能层是生产系统不是试验田任何自动化改动都必须有审计和回滚机制。5.3 非技术的最后一课技能集也是产品跑了很多项目之后我有一个很深的体会agent-skills这一个抽象概念落到产品层面它不只是开发者工具更是产品体验的一部分。技能覆盖度决定了Agent能不能解决用户的问题技能执行速度决定了Agent回应用户的体验技能失败时的反馈话术则决定了用户对Agent的信心。我见过很多团队在模型提示词上死磕却从不看一眼自己的技能层是不是已经老化。模型层花一周做优化可能只提升2%的效果技能层补充一两个高价值能力效果立刻提升一个档次。为什么因为模型的能力上限已经由它的参数规模定死了你对再多次话它也变不出新能力。但技能层是可以无限扩展的——每次给Agent装一个新“器官”它能做的事就实实在在多一圈。在这个意义上技能设计者的工作很像游戏里给角色配技能栏选什么技能、怎么排序、如何取舍最终决定了这个Agent在上手玩家手里是普通角色还是神装角色。所以把精力多分一些给技能层吧投入产出比一定比你想象的更高。
