1. 从“技能”这个词说起为什么我们需要重新理解Agent的能力边界“agent-skills”这个标题乍一看像是某个开源仓库的名字或者某个技术团队内部对智能体能力模块的统称。但如果你最近在关注AI应用层的动态会发现这个词背后其实藏着一个正在发生的范式转移我们讨论智能体Agent的方式正在从“它能调用什么工具”转向“它具备哪些可复用、可组合、可评估的技能”。过去一年里我参与过几个智能体相关的项目从客服自动化到代码辅助再到多步骤任务编排。踩过的坑不少最大的一个体会是大多数智能体项目失败不是因为模型不够强而是因为“技能”没有被当作一等公民来设计。大家习惯性地把提示词写得很长把工具列表堆得很全然后指望模型自己“悟”出正确的调用顺序。结果就是演示时惊艳上线后崩溃。“agent-skills”这个标题如果让我来拆解它至少包含三层含义。第一层是能力封装把某个具体任务的处理逻辑从散落的提示词和工具调用中抽离出来变成一个独立的、有明确输入输出的技能单元。第二层是技能编排多个技能如何组合、如何路由、如何回退这比单个技能的实现更考验架构设计。第三层是技能评估与迭代你怎么知道一个技能是“好”的怎么量化它的成功率、延迟、成本怎么在版本迭代中不破坏已有能力这篇文章我想围绕这三层含义把“agent-skills”这个主题拆开来讲。适合谁看如果你正在做智能体应用开发或者你是一个技术负责人正在评估要不要把现有的提示词工程升级成技能化架构那这篇内容应该能帮你省下不少试错时间。如果你只是对智能体感兴趣想了解这个领域在工程上到底怎么落地我也会尽量用生活化的类比把关键概念讲清楚。先给一个最直观的类比。你可以把智能体想象成一个刚入职的实习生模型本身是他的“智商”和“常识”工具是他能接触到的“办公设备”而“技能”就是他经过培训后掌握的“标准作业流程”。一个实习生如果只会说“我试试看”你是不敢把重要任务交给他的。但如果他掌握了“查订单”“改地址”“发退款”这三个标准技能并且知道什么情况下用哪个那他就变得可靠了。agent-skills要解决的就是让智能体从“我试试看”变成“我知道怎么做”。2. 技能化架构的核心设计思路为什么不是简单的函数调用2.1 从“工具调用”到“技能封装”的认知升级很多人第一次接触智能体开发都是从工具调用开始的。定义一个函数写一段描述让模型在需要的时候调用它。这很直观也很容易上手。但当你把工具数量增加到十几个、任务步骤增加到五六步的时候问题就来了。我遇到过最典型的情况是模型在第一步调用了正确的工具但传参格式错了或者在第三步应该调用工具B的时候它又回头调用了工具A。你去看日志发现模型“理解”了任务但“执行”的时候总是差那么一点。这时候你可能会想是不是提示词写得不够清楚于是你把描述改得更详细把示例加得更多。短期内好像好了但过几天换个任务同样的问题又出现了。根本原因在于工具调用只定义了“能做什么”没有定义“怎么做才对”。一个工具函数比如search_order(order_id)它只告诉模型“给我一个订单号我还你订单信息”。但模型不知道订单号格式是什么如果查不到应该怎么办查到多个结果怎么处理这些“隐性知识”如果每次都靠提示词去补那提示词会膨胀到不可维护。技能封装要做的就是把这些隐性知识显性化。一个“查询订单”技能应该包含输入参数的校验规则、调用前的预处理、调用后的结果解析、异常情况的处理分支、以及成功/失败的标准输出格式。这些东西写在哪里不是写在提示词里而是写在技能的定义里。模型只需要知道“有一个查询订单的技能输入是订单号输出是标准化的订单状态”至于内部怎么处理那是技能实现的事。这就像你去餐厅点菜。你不需要知道厨房怎么切菜、怎么控火、怎么摆盘。你只需要看菜单点一个“宫保鸡丁”然后等结果。菜单上会写这道菜辣不辣、有没有花生、大概多久能上。这就是技能封装的价值把复杂性留在厨房把简单性留给前台。2.2 技能的生命周期定义、注册、发现、调用、评估一个完整的技能化架构不是写几个函数就完事了。它需要一套完整的生命周期管理。我把它拆成五个阶段每个阶段都有容易踩的坑。定义阶段你要决定一个技能的边界。太粗一个技能干太多事复用性差太细技能数量爆炸编排复杂度飙升。我的经验是一个技能对应一个“原子业务动作”。什么叫原子业务动作就是在一个业务流程里不能再拆分的、有明确业务含义的步骤。比如“验证用户身份”是一个原子动作“查询订单”是另一个“发起退款”是第三个。不要把“验证身份并查询订单”合成一个技能也不要把“查询订单”拆成“连接数据库”和“执行SQL”。注册阶段技能需要被系统识别和索引。这里的关键是元数据设计。一个技能除了实现代码还需要有名称、描述、输入schema、输出schema、适用场景、依赖条件、版本号。描述要写给模型看所以要用自然语言但又要足够精确。我见过很多项目在这里偷懒描述写得模棱两可结果模型根本不知道什么时候该用这个技能。发现阶段当智能体面对一个任务时它需要从技能库中找到相关的技能。这可以是基于描述的语义检索也可以是基于规则的硬路由。对于技能数量少于20个的场景我建议直接把所有技能描述塞进上下文让模型自己选。超过20个就需要做分层路由或者向量检索了。但要注意检索的召回率比精确率更重要宁可多召回几个让模型筛也不要漏掉关键技能。调用阶段这是最工程化的部分。技能被选中后需要处理参数绑定、执行、超时控制、重试、结果格式化。这里有一个容易被忽视的点技能的执行结果应该是结构化的而不是一段自然语言。因为下游可能还有别的技能要消费这个结果。如果每个技能都返回一段话那编排层就得写一堆解析逻辑非常脆弱。评估阶段这是大多数项目缺失的一环。你怎么知道“查询订单”这个技能是好的你需要有测试用例有成功率统计有延迟分布有成本核算。更重要的是你需要有回归测试。当你优化了技能A的实现怎么保证它不会破坏依赖它的技能B和技能C这需要一套技能级别的单元测试和集成测试。2.3 技能与提示词、工具、工作流的关系辨析这里有必要澄清几个容易混淆的概念。技能不是提示词提示词是给模型的指令技能是封装好的能力单元。技能不是工具工具是底层的API或函数技能是工具的上层抽象。技能也不是工作流工作流是技能的编排方式技能是工作流的组成元素。用一个更具体的例子来说明。假设你要做一个“处理退款申请”的智能体。底层的工具可能是数据库查询函数、支付网关的退款接口、消息队列的发送函数。提示词可能是“你是一个客服助手请根据用户请求处理退款。”工作流可能是先验证身份再查订单再判断是否符合退款条件最后执行退款。而技能是verify_user、query_order、check_refund_eligibility、execute_refund。每个技能内部封装了对应的工具调用、参数校验、异常处理。这样分层的好处是当业务规则变化时你只需要修改对应的技能不需要动提示词也不需要重写工作流。比如退款条件从“7天内”改成“15天内”你只需要改check_refund_eligibility这个技能其他部分完全不受影响。这就是关注点分离带来的可维护性。3. 核心细节解析一个技能应该长什么样3.1 技能定义的元数据规范一个技能的定义我通常会用类似下面的结构来描述。这不是某个特定框架的语法而是一种通用的元数据设计思路。skill_id: query_order name: 查询订单 description: 根据订单号查询订单的当前状态、金额和商品信息。适用于用户询问订单进度、订单详情等场景。 version: 1.2.0 input_schema: type: object properties: order_id: type: string description: 订单号通常为10-20位数字或字母组合 pattern: ^[A-Za-z0-9]{10,20}$ user_id: type: string description: 用户ID用于权限校验 required: - order_id - user_id output_schema: type: object properties: status: type: string enum: [pending, paid, shipped, delivered, cancelled, refunded] amount: type: number items: type: array items: type: object properties: name: { type: string } quantity: { type: number } error: type: string description: 错误信息仅在查询失败时返回 preconditions: - 用户已通过身份验证 postconditions: - 返回的订单信息与用户ID匹配 timeout_ms: 3000 retry_policy: max_retries: 2 backoff_ms: 500这份元数据里有几个字段是容易被忽略但极其重要的。preconditions和postconditions是给编排层看的用来判断技能是否可以被调用以及调用后是否满足预期。timeout_ms和retry_policy是给执行器看的避免一个技能卡死整个流程。input_schema里的pattern和required是给参数校验用的能在调用前就拦截掉明显错误的输入。我特别想强调description的写法。很多开发者把它写成“查询订单”这太简略了。模型看到这个描述不知道什么时候该用也不知道用了之后能得到什么。好的描述应该包含做什么、什么时候用、输入是什么、输出是什么。比如上面写的“根据订单号查询订单的当前状态、金额和商品信息。适用于用户询问订单进度、订单详情等场景。”这样模型在规划步骤时就能准确判断这个技能是否相关。3.2 技能内部的实现模式前置校验、核心逻辑、后置处理一个技能的内部实现我习惯分成三段式前置校验、核心逻辑、后置处理。这个结构不是强制的但能帮你把错误处理想清楚。前置校验要做的事情包括参数格式校验、权限校验、依赖状态检查。比如查询订单之前要确认订单号格式正确要确认当前用户有权限查这个订单要确认数据库连接是正常的。这些检查如果放在核心逻辑里会让代码变得很乱。单独抽出来不仅清晰而且可以在校验失败时快速返回标准化的错误。核心逻辑就是真正干活的代码。调用数据库、调用外部API、做计算、做转换。这部分要尽量保持纯粹不要掺杂太多的条件分支。如果核心逻辑里出现了大量的if-else那说明这个技能的边界可能没划好应该拆成多个技能。后置处理负责把核心逻辑的输出转换成标准化的技能输出。比如数据库返回的是一个原始的行对象后置处理要把它映射成output_schema定义的格式。如果核心逻辑抛出了异常后置处理要把它转换成结构化的错误信息而不是让异常直接冒泡。这里有一个实操心得后置处理里一定要做输出校验。我见过太多案例技能返回的数据结构跟schema对不上导致下游技能解析失败。在技能内部加一层校验虽然多写几行代码但能省下大量的调试时间。3.3 技能之间的依赖管理与版本控制当技能数量多起来之后依赖管理就成了一个头疼的问题。技能A可能依赖技能B的输出格式技能B升级了技能A就挂了。这跟微服务架构里的服务依赖问题一模一样。我的做法是技能之间的依赖只通过schema契约不通过实现细节。技能A需要技能B的输出那就把技能B的output_schema作为A的输入契约。只要B的schema不变B的内部实现怎么改A都不受影响。如果B的schema必须变那就升大版本号并且提供迁移期。版本控制方面我建议采用语义化版本。主版本号变更表示不兼容的schema修改次版本号变更表示向后兼容的功能新增修订号变更表示bug修复。编排层在引用技能时可以指定版本范围比如query_order^1.2.0表示接受1.x.x的所有版本但不接受2.0.0。还有一个容易被忽视的点技能的废弃策略。当一个技能不再需要时不要直接删除而是标记为deprecated并在描述里说明替代方案。因为可能还有旧的流程在引用它。直接删除会导致线上事故。4. 实操过程从零搭建一个技能化智能体4.1 环境准备与基础框架选型假设我们要从零开始搭建一个技能化的智能体系统。第一步是选型。这里我不推荐具体的框架名称因为不同团队的技术栈差异很大。但我可以给出选型的几个关键考量维度。模型能力你的技能编排需要模型具备多步推理和函数调用的能力。如果模型本身不支持结构化输出那技能调用的参数绑定就会很痛苦。所以第一步是确认你用的模型是否支持JSON mode或者function calling。执行环境技能的执行是在本地进程里还是在沙箱里还是在远程服务里这决定了你的技能实现语言和部署方式。如果技能需要访问内部数据库那可能得放在内网环境执行。如果技能是纯计算那可以放在无服务器函数里。编排引擎你是自己写编排逻辑还是用现成的编排框架自己写的好处是灵活坏处是要处理很多边界情况。用框架的好处是省事坏处是可能被框架的限制绑住。我的建议是如果技能数量少于10个自己写一个简单的编排器就够了。超过10个再考虑引入框架。可观测性这个最容易被忽视但最重要。你需要能追踪每一次技能调用的输入、输出、耗时、成功与否。没有这个你根本不知道系统哪里出了问题。我通常会在技能执行器的入口和出口打点把日志结构化后送到日志系统。4.2 定义第一个技能从需求到可执行单元我们拿一个具体的需求来走一遍流程。假设我们要做一个“会议安排助手”用户说“帮我约张三明天下午三点开个会”。这个需求可以拆成几个技能我的拆法是parse_meeting_request解析会议请求、check_availability检查参会人时间、create_calendar_event创建日历事件、send_invitation发送邀请。四个技能每个都有明确的输入输出。先看parse_meeting_request。输入是一段自然语言输出是结构化的会议信息参会人、时间、主题、时长。这个技能内部其实是一次模型调用但封装成技能后编排层就不需要关心解析的细节了。这个技能的难点在于自然语言里的时间表达非常多样“明天下午三点”“下周三上午”“后天中午”都要能解析。我的做法是在技能内部先用规则做一轮预处理把相对时间转换成绝对时间再用模型做兜底解析。再看check_availability。输入是参会人列表和时间段输出是每个人的空闲状态。这个技能需要调用日历系统的API。难点在于不同日历系统的API格式不一样有的返回的是忙碌时间段有的返回的是空闲时间段。技能内部要做归一化统一输出成“可用/不可用”的布尔值。create_calendar_event和send_invitation相对直接但要注意幂等性。如果编排层重试了不能创建出两个相同的会议。我的做法是在技能内部加一个去重键比如用“参会人时间主题”的哈希值作为幂等键。4.3 技能编排让智能体学会“先做什么再做什么”技能定义好了接下来是编排。编排的核心问题是给定一个用户请求如何选择合适的技能序列最简单的方式是让模型自己规划。把用户请求和所有技能的描述一起塞给模型让模型输出一个技能调用序列。这种方式灵活但不可控。模型可能会漏掉关键步骤也可能会调用不存在的技能。更可控的方式是预定义工作流。对于常见的请求类型硬编码技能序列。比如“安排会议”就固定走parse - check - create - send这个流程。这种方式稳定但不够灵活。如果用户说“帮我改一下明天下午的会议”预定义的工作流就处理不了了。我的实践经验是混合模式对于高频、固定的场景用预定义工作流对于长尾、多变的场景用模型规划。但模型规划的输出要经过一层校验确保调用的技能存在、参数格式正确、依赖关系满足。校验不通过就回退到预定义工作流或者直接报错。编排层还有一个重要职责是状态管理。技能A的输出要传给技能B这个传递过程需要有一个上下文对象来承载。我通常会把上下文设计成一个键值对结构每个技能可以从上下文里读数据也可以往上下文里写数据。这样技能之间就不需要直接耦合都通过上下文来通信。4.4 技能执行器的实现要点技能执行器是真正调用技能的地方。它的实现质量直接决定了系统的稳定性。我总结几个关键要点。超时控制每个技能都必须有超时时间。没有超时控制的技能调用就像没有刹车的汽车。超时时间怎么定根据技能的历史P99延迟来定通常设为P99的1.5倍。超时后要能中断执行而不是让线程一直挂着。重试策略不是所有技能都适合重试。查询类的技能可以重试因为它是幂等的。写入类的技能要谨慎除非有幂等键。重试要有退避不能立即重试否则可能加剧下游压力。熔断机制如果一个技能连续失败多次应该暂时熔断不再调用它。这可以防止一个故障技能拖垮整个系统。熔断后要有恢复策略比如半开状态试探。结果缓存对于查询类的技能如果同样的输入在短时间内被多次调用可以考虑缓存结果。但要注意缓存的失效策略避免返回过期的数据。错误分类技能执行失败的原因有很多种参数错误、权限不足、下游超时、内部异常。这些错误应该被分类因为不同的错误需要不同的处理方式。参数错误应该直接返回给用户下游超时应该重试内部异常应该告警。5. 常见问题与排查技巧实录5.1 技能选择错误模型总是选错技能怎么办这是最常见的问题。用户说“查一下我的订单”模型却调用了“查询物流”的技能。排查思路如下。首先看技能描述是否足够区分。如果“查询订单”和“查询物流”的描述都是“查询相关信息”那模型选错很正常。描述里要明确写出适用场景和输入输出的差异。比如“查询订单”的描述里写“输入订单号返回订单状态和金额”而“查询物流”的描述里写“输入物流单号返回配送进度和当前位置”。其次看技能数量是否过多。如果一次性给模型几十个技能它的选择准确率会下降。可以考虑分层路由先让模型选择技能类别再在类别内选择具体技能。最后看是否有few-shot示例。在提示词里给几个“用户请求 - 正确技能”的示例能显著提升选择准确率。示例要覆盖容易混淆的场景。5.2 参数绑定失败模型传的参数格式不对模型传参格式错误通常是因为input_schema不够明确。比如order_id只写了type: string模型可能传“我的订单号是12345”而不是纯数字。解决办法是在schema里加pattern约束并在描述里给出示例。另一个原因是模型没有从上下文中正确提取参数。比如用户说“查一下我昨天买的那个”模型需要从对话历史里找到订单号。这时候需要在编排层做参数补全把上下文里的信息注入到技能调用参数里。还有一个坑是可选参数的处理。如果某个参数是可选的模型可能传一个空字符串或者null。技能内部要能处理这种情况不能直接报错。5.3 技能执行超时下游服务慢导致整个流程卡住超时问题要从两个层面解决。技能层面设置合理的超时时间和重试策略。编排层面要有整体的超时预算。比如整个任务必须在10秒内完成那分配给每个技能的时间就要按比例分配。如果某个技能经常超时要考虑优化它的实现。比如把同步调用改成异步或者加缓存。如果下游服务本身就不稳定那要考虑降级方案。比如查询订单超时了可以返回“订单信息暂时无法获取请稍后重试”而不是让整个流程失败。5.4 技能版本升级导致的不兼容这个问题在技能数量多起来之后几乎必然出现。预防措施是严格的schema版本管理。任何对input_schema或output_schema的修改都要评估是否向后兼容。不兼容的修改必须升主版本号并且提供迁移期。迁移期内新旧版本并存。编排层可以逐步切换先让少量流量走新版本观察没问题后再全量。同时要有回滚方案一旦新版本出问题能快速切回旧版本。5.5 常见问题速查表问题现象可能原因排查方向解决建议模型选错技能描述不清晰或技能过多检查技能描述区分度统计技能数量优化描述增加示例分层路由参数格式错误schema约束不足检查input_schema的pattern和required补充约束增加参数校验技能执行超时下游慢或超时设置过长查看技能耗时分布检查下游服务优化实现加缓存调整超时版本升级后报错schema不兼容对比新旧schema差异升主版本号提供迁移期技能重复执行重试策略不当检查重试次数和幂等性加幂等键调整重试策略上下文丢失状态管理有问题检查上下文传递链路统一上下文对象加日志追踪5.6 几个我踩过的坑和对应的技巧第一个坑是技能描述里用了太多专业术语。模型不是领域专家它不理解“SKU”“GMV”这些缩写。描述要用大白话把术语展开。比如“查询商品库存”比“查询SKU库存”更好。第二个坑是技能输出里包含了敏感信息。比如查询用户信息时把手机号、身份证号都返回了。这些信息如果进入上下文可能会被后续的技能或者模型泄露。我的做法是在技能的后置处理里做脱敏只返回必要的信息。第三个坑是技能之间的循环依赖。技能A调用技能B技能B又调用技能A导致死循环。预防措施是在编排层做依赖检测发现循环就报错。同时技能设计时要遵循单向依赖原则上层技能可以调用下层技能反之不行。第四个坑是忽略了技能的冷启动问题。有些技能第一次调用时需要加载模型或者建立连接耗时很长。如果编排层没有预留时间就会超时。解决办法是加预热机制在系统启动时预先调用一次。6. 技能评估与持续迭代怎么知道你的技能在变好6.1 定义技能级别的评估指标技能评估不能只看“成功/失败”。我通常会用一组指标来衡量一个技能的健康度。成功率调用成功次数除以总调用次数。但要注意成功率的定义要明确。参数校验失败算不算失败下游超时算不算失败我的做法是分开统计业务成功率业务逻辑正确执行和技术成功率没有技术异常。延迟分布P50、P95、P99延迟。平均值会掩盖长尾问题所以要看分位数。如果P99延迟很高说明有少量请求体验很差需要优化。调用频次这个技能被调用了多少次。频次突然下降可能意味着上游编排逻辑变了或者模型不再选择这个技能了。错误分布各种错误类型的占比。如果参数错误占比很高说明schema设计有问题。如果下游超时占比高说明依赖服务不稳定。成本每次调用的token消耗或者API费用。对于调用大模型的技能这个指标很重要。6.2 构建技能回归测试集每次修改技能实现或者升级模型都要跑一遍回归测试。测试集怎么构建从生产日志里采样。把真实的用户请求和对应的技能调用记录下来人工标注哪些是正确的哪些是错误的。正确的作为正例错误的作为负例。测试集要覆盖各种边界情况空输入、超长输入、特殊字符、多语言混合。测试的执行可以自动化。每次代码提交后自动跑一遍测试集对比成功率和延迟。如果指标下降超过阈值就阻止合并。6.3 基于反馈的技能迭代闭环技能不是一次性的需要持续迭代。迭代的驱动力来自哪里来自用户反馈和线上监控。用户反馈可以是显式的点赞/点踩也可以是隐式的用户重新提问、用户放弃任务。把这些反馈关联到具体的技能调用上就能知道哪个技能需要优化。线上监控发现异常时要能快速定位到是哪个技能的问题。这需要全链路的追踪能力。每次技能调用都有一个唯一的trace_id通过这个id可以把编排层的日志、技能执行器的日志、下游服务的日志串联起来。迭代的节奏建议是小步快跑。每次只改一个技能的一个点改完就跑回归测试没问题就灰度发布。不要一次性改多个技能否则出了问题很难定位。6.4 技能库的治理避免技能膨胀和重复建设当团队规模变大之后技能库很容易变得混乱。不同的人可能定义了功能相似的技能或者同一个技能有多个版本在跑。治理措施包括建立技能注册中心所有技能必须注册才能被编排层发现。注册时要做查重发现相似技能时提醒开发者。定期做技能盘点把长期无人调用的技能标记为废弃。建立技能评审机制新技能上线前要经过评审确保命名规范、描述清晰、schema合理。还有一个实践是技能分层。把技能分为基础技能和业务技能。基础技能是通用的比如“发送邮件”“查询数据库”。业务技能是特定领域的比如“处理退款”“安排会议”。业务技能可以依赖基础技能但基础技能不能依赖业务技能。这样能保证基础技能的复用性。7. 技能化架构的边界与适用场景7.1 什么情况下适合技能化技能化不是银弹。它适合的场景是任务步骤多、技能可复用、需要评估和迭代。如果你的智能体只是做一个简单的问答那直接写提示词就够了没必要上技能化架构。具体来说以下几种情况适合技能化。第一业务流程有明确的步骤划分每个步骤可以独立测试。第二多个流程之间有共享的步骤比如“验证身份”在退款、改地址、查订单里都要用。第三需要对每个步骤做精细化的监控和优化。第四团队多人协作需要清晰的接口边界。7.2 什么情况下不适合技能化反过来以下几种情况不适合技能化。第一任务非常开放没有固定的步骤。比如“帮我写一篇文章”这种任务很难拆成原子技能。第二技能数量很少只有两三个那直接写在提示词里更简单。第三对延迟极其敏感技能化带来的额外编排开销不可接受。第四团队规模很小一个人就能维护所有逻辑技能化反而增加了复杂度。7.3 技能化与端到端模型的权衡最近有一种观点认为随着模型能力增强端到端模型可以直接完成任务不需要技能化。这个观点有一定道理但忽略了一个关键问题可靠性和可解释性。端到端模型在演示时可能表现很好但在生产环境里你需要知道它为什么成功、为什么失败。技能化架构提供了天然的观测点。每个技能的输入输出都是可追踪的出了问题能快速定位。而且技能可以独立测试和迭代不需要每次都重新训练或微调整个模型。我的看法是技能化和端到端模型不是对立的而是互补的。对于高频、固定的任务用技能化保证稳定性和可维护性。对于长尾、开放的任务用端到端模型提供灵活性。两者结合才能既稳又活。8. 一个完整的技能调用示例从用户输入到最终响应8.1 场景描述与技能序列规划用户输入“帮我查一下订单12345的退款进度如果还没退就催一下。”这个请求涉及两个技能query_refund_status查询退款状态和urge_refund催退款。编排层需要先调用查询技能根据查询结果决定是否调用催退款技能。技能序列规划的逻辑是先解析用户意图识别出“查询”和“条件催办”两个动作。然后检查技能库找到对应的技能。接着规划执行顺序先查询再根据查询结果做条件判断。最后生成执行计划。8.2 技能调用的参数绑定与执行query_refund_status的输入参数是order_id和user_id。order_id从用户输入里提取user_id从会话上下文里获取。参数绑定完成后执行器调用技能。技能内部先做参数校验确认订单号格式正确、用户有权限。然后调用退款系统的API获取退款状态。最后把结果格式化成标准输出{status: processing, estimated_days: 3}。编排层拿到这个结果后判断status不是completed所以需要调用urge_refund。urge_refund的输入是order_id和reason。执行后返回{success: true, message: 已催办}。8.3 结果整合与用户响应生成两个技能都执行完后编排层把结果整合成一段自然语言回复“您的订单12345退款正在处理中预计3天内到账。我已经帮您催办会加快处理速度。”这里要注意最终回复的生成也可以是一个技能。我通常会把“生成用户回复”也封装成一个技能输入是各个技能的执行结果输出是自然语言。这样回复的风格可以统一管理也方便做多语言适配。8.4 异常情况的处理与回退如果query_refund_status执行超时了怎么办编排层应该捕获超时异常然后决定是重试还是回退。如果重试两次还是超时就返回“退款状态暂时无法查询请稍后重试”。同时记录日志触发告警。如果urge_refund执行失败了怎么办查询已经成功了用户知道了退款进度。催办失败不应该影响主流程。编排层可以返回“退款正在处理中催办请求已提交但暂时未成功建议您稍后手动联系客服”。这样用户至少得到了部分信息不会觉得整个请求都失败了。这种部分成功的处理能力是技能化架构的一个重要优势。端到端模型如果中间某一步失败往往整个响应都不可用。而技能化架构可以做到“能返回多少返回多少”用户体验更好。9. 技能化架构的演进方向9.1 技能自动发现与组合目前技能的组合方式主要是人工预定义或者模型规划。未来一个方向是让系统自动发现技能之间的组合模式。比如通过分析大量的执行日志发现“查询订单”之后经常跟着“查询物流”那就可以把这两个技能打包成一个复合技能。这样既能减少编排开销又能提升响应速度。9.2 技能的自适应优化每个技能都有一些可调参数比如超时时间、重试次数、缓存策略。这些参数目前是人工设定的。未来可以根据运行时的统计数据自动调整。比如发现某个技能的P99延迟在上升就自动增加超时时间。发现某个技能的调用频率很高就自动开启缓存。9.3 跨智能体的技能共享在一个组织内不同的智能体可能都需要“验证身份”“发送通知”这些通用技能。如果每个智能体都自己实现一套就是重复建设。未来的方向是建立一个组织级的技能市场技能提供者发布技能技能消费者按需订阅。这需要一套技能描述标准、版本管理机制和计费体系。9.4 技能的安全与权限控制技能可以访问内部系统所以权限控制至关重要。每个技能应该有自己的权限边界只能访问它被授权访问的资源。编排层在调用技能时要传递调用者的身份信息技能内部做权限校验。同时要有审计日志记录谁在什么时候调用了什么技能输入输出是什么。10. 一些个人体会和实用建议做智能体技能化这件事我最大的体会是不要一开始就追求大而全的架构。很多团队一上来就想设计一个完美的技能框架结果花了几个月时间还没跑通一个完整的流程。我的建议是从一个具体的场景开始先手动定义两三个技能把编排跑通然后再逐步抽象和扩展。另一个体会是技能的粒度比数量更重要。一个粒度合适的技能应该是“一个业务动作一个明确的输入输出一个可独立测试的单元”。不要为了追求技能数量而过度拆分也不要为了省事而把多个动作塞进一个技能。还有一点评估体系要尽早建立。不要等到技能数量多了才想起来做监控和测试。从第一个技能开始就要有日志、有指标、有测试用例。这样后面扩展的时候才能保证质量不滑坡。最后分享一个实用技巧给每个技能写一个“使用说明”。这个说明不是给模型看的是给其他开发者看的。说明里写清楚这个技能解决什么问题、什么场景下用、有什么限制、依赖哪些外部服务。这样当别人需要复用或者修改这个技能时能快速上手。我见过太多项目技能代码写得不错但没有任何文档换个人就维护不下去了。技能化架构不是目的而是手段。它的目的是让智能体从“能演示”变成“能上线”从“靠运气”变成“靠工程”。这条路不容易走但走通了之后你会发现智能体的可靠性和可维护性会有质的提升。