1. 从“skills”这个词说起：为什么它突然成了智能体开发的关键词
如果你最近在关注智能体（Agent）相关的技术动态，大概率会频繁撞见“skills”这个词。它不像“prompt”“tool”“workflow”那样早就被讲烂了，反而带着一种“新瓶装旧酒但又确实不一样”的气质。我最初看到“Agent Skills”这个概念时，第一反应是：这不就是把工具调用包装了一下吗？但真正动手拆过几个案例、翻过一些公开的实现思路之后，我发现事情没那么简单。
“skills”在智能体语境下，指的是一套可复用、可组合、带明确边界的能力封装。它和传统的“函数调用”最大的区别在于：函数调用关注的是“输入什么参数、返回什么结果”，而skill关注的是“这个能力在什么场景下该被激活、激活后按什么流程执行、执行过程中如何与模型交互、失败后怎么兜底”。换句话说，skill更像是一个带说明书和操作手册的小型工作单元，而不是一个裸接口。
这个区别听起来有点抽象，但放到实际项目里就非常具体了。比如你要做一个“根据用户描述生成云资源部署方案”的智能体，如果只给模型一个“创建GKE集群”的函数，模型很可能在用户只是随口问“GKE和Cloud Run有什么区别”的时候就把函数调用了。但如果你把它封装成一个skill，里面写清楚触发条件、前置检查、参数收集步骤、异常处理逻辑，模型的行为就会稳定得多。
这篇文章适合谁看？如果你正在做智能体相关的开发，尤其是涉及Google Cloud、GKE、Genkit、Gemini这套技术栈的，或者你单纯对“Agent Skills”这个概念好奇、想知道它到底解决了什么问题，那接下来的内容应该能给你一些实在的参考。我不会只讲概念，而是会把skill的结构拆开、把设计时的取舍讲清楚、把实际落地时容易踩的坑摆出来。
2. Agent Skills到底解决了什么传统工具调用搞不定的问题
2.1 传统工具调用的三个典型失效场景
在没有skill这个概念之前，我们做智能体基本就是给模型挂一堆工具函数。简单场景下没问题，但一旦任务稍微复杂一点，就会遇到三类很典型的问题。
第一类是误触发。模型看到“集群”两个字就调用创建集群的工具，看到“账单”就调用查询费用的工具，完全不考虑用户当前是在咨询、在比较、还是在确认操作。我见过一个案例，用户问“GKE的计费模式是怎样的”，智能体直接调用了“创建GKE集群”的工具，因为它的工具描述里写着“用于GKE集群相关操作”。这种问题在工具数量少的时候还能靠反复调prompt缓解，工具一多就彻底失控。
第二类是流程断裂。很多任务不是一步能完成的，比如“帮我把这个服务部署到GKE上”，背后涉及检查项目配置、确认集群是否存在、构建镜像、推送镜像、应用部署清单、验证服务状态等一系列步骤。如果每个步骤都是一个独立工具，模型很容易在中间某一步跳过去，或者把顺序搞乱。更麻烦的是，有些步骤需要根据上一步的结果动态调整，比如集群不存在时应该先创建集群，但模型可能直接跳到部署环节然后报错。
第三类是上下文丢失。工具调用是无状态的，每次调用都是独立的。但实际任务中，很多信息需要在多个步骤之间传递，比如用户选定的区域、项目ID、服务名称。如果每个工具都要求模型重新提取这些参数，不仅浪费token，还容易出错。我遇到过模型在第三步把区域从“us-central1”写成“us-central”的情况，就因为它在重新生成参数时“记岔了”。
2.2 Skill的本质：把“能力”升级成“带上下文的工作流”
Agent Skill的核心思路，是把上面这些问题在封装层面就解决掉。一个skill不仅仅是一个函数，它至少包含这几个部分：触发描述（什么情况下该用这个skill）、输入契约（需要哪些参数、哪些是必填、哪些可以从上下文推断）、执行流程（内部可以包含多个步骤、条件分支、甚至对其他skill的调用）、输出规范（返回什么结构、如何向用户呈现）、异常处理（失败时是重试、降级还是向用户求助）。
这样设计的好处是，模型不需要在每次调用时重新理解“这个能力该怎么用”，因为skill本身已经把使用说明和执行逻辑都封装好了。模型要做的只是判断“当前场景是否匹配这个skill的触发描述”，匹配就激活，不匹配就不激活。这大大降低了模型在复杂场景下的决策负担。
举个例子，一个“部署服务到GKE”的skill，内部可能包含这样的流程：先检查用户是否指定了项目ID，没有的话从上下文或默认配置里取；然后检查目标集群是否存在，不存在则先走创建流程；接着构建并推送镜像；最后应用部署清单并等待就绪。整个过程对外只暴露一个skill入口，模型不需要关心中间有多少步骤。这就是skill和普通工具调用的本质区别——它把“怎么做”的知识从模型侧转移到了skill侧。
2.3 和Genkit、Gemini的配合关系
如果你用的是Genkit这套框架，skill的概念可以很自然地映射到它的工具定义和流程编排能力上。Genkit本身提供了定义工具、组合流程、管理状态的机制，而skill可以看作是在这些机制之上的一层“语义封装”。你可以在Genkit里定义一个skill，内部用多个tool和flow来实现具体逻辑，对外则暴露成一个带有自然语言描述的能力单元。
Gemini作为模型侧，负责的是“判断该不该激活某个skill”以及“从用户输入中提取skill需要的参数”。这里有个很关键的实践点：skill的触发描述要写得足够具体，不能太宽泛也不能太窄。太宽泛会导致误触发，太窄又会导致该用的时候用不上。我一般的做法是，在触发描述里同时写清楚“适用场景”和“不适用场景”，比如“当用户明确要求部署服务到GKE时使用；当用户只是在询问GKE概念或比较产品时不要使用”。这种正反两面的描述，对Gemini这类模型来说效果比只写正面描述好很多。
3. 拆开一个Skill看内部：结构、参数与执行逻辑
3.1 Skill的元数据设计：触发描述怎么写才靠谱
触发描述是skill的“门面”，模型主要靠它来判断是否激活。我见过很多skill的触发描述写得很随意，比如“用于处理GKE相关操作”，这种描述基本等于没写，因为“相关操作”太模糊了。好的触发描述应该包含三个要素：动作（这个skill具体做什么）、对象（操作的目标是什么）、条件（在什么前提下才应该使用）。
拿一个“查询GKE集群状态”的skill举例，触发描述可以这样写：“当用户询问某个GKE集群的当前状态、节点数量、版本信息或运行状况时使用。需要用户提供集群名称和区域，如果用户没有提供，应先询问而不是猜测。不适用于创建、删除或修改集群的操作。”这段描述里，动作是“查询状态”，对象是“GKE集群”，条件是“用户询问状态信息且能提供或愿意提供集群标识”。同时明确排除了创建、删除、修改场景，避免和别的skill冲突。
实际写的时候，我建议把触发描述当成给一个新同事看的操作说明来写。你要假设模型完全不知道你的系统里有哪些skill，它只能靠这段文字来判断。所以不要用内部术语，不要用缩写，尽量用自然语言把“什么时候该找我”说清楚。
3.2 输入参数的提取与校验：让模型少犯错
Skill的输入参数设计有个原则：能推断的不要问，能默认的不要填，必须问的一次问清楚。很多skill失败不是因为逻辑复杂，而是因为参数收集环节太啰嗦或者太模糊。
比如一个部署服务的skill，需要的参数可能包括项目ID、区域、集群名称、服务名称、镜像地址、副本数量。如果每个参数都让模型去问用户，用户体验会很差。我的做法是分层处理：项目ID和区域可以从当前上下文或默认配置里取，取不到再问；集群名称和服务名称如果用户没提，可以根据命名规范生成一个默认值并告知用户；镜像地址和副本数量如果用户没指定，就用项目里的默认镜像和默认副本数。只有那些真正无法推断且影响重大的参数，才必须让用户明确提供。
校验环节也很关键。模型提取的参数不一定可靠，比如用户说“部署到美国”，模型可能提取出“us”这样的区域代码，但GKE的区域格式是“us-central1”这种。所以skill内部要有参数规范化逻辑，把模型给的原始值转换成系统能接受的格式。如果转换失败，要给出明确的错误提示，而不是直接抛异常。我一般会在skill里加一个“参数预检”步骤，把所有参数过一遍，能修正的修正，不能修正的返回一个友好的询问信息。
3.3 执行流程中的状态管理：多步骤任务怎么不跑偏
多步骤任务是skill最能体现价值的地方，也是最容易出问题的地方。核心难点在于：每一步的执行结果如何影响下一步，以及中间状态如何保存。
我的经验是，在skill内部用一个显式的状态对象来贯穿整个流程。这个状态对象在skill开始时初始化，每一步执行后更新，后续步骤从状态对象里读数据而不是重新从模型输出里提取。这样做的好处是，即使模型在中间某一步的输出有轻微偏差，也不会影响后续步骤，因为后续步骤依赖的是状态对象里的确定值。
举个例子，一个“创建GKE集群并部署服务”的skill，状态对象可能包含：project_id、region、cluster_name、cluster_status、image_url、deployment_status。流程开始时，先从用户输入和上下文里填充project_id、region、cluster_name；然后检查集群是否存在，更新cluster_status；如果不存在则创建集群并等待就绪，再次更新cluster_status；接着构建推送镜像，更新image_url；最后应用部署清单，更新deployment_status。每一步都只依赖状态对象里的字段，不依赖模型的即时输出。这样即使模型在中间某步“说”错了什么，只要状态对象是对的，流程就能继续。
还有一个细节：skill执行过程中的中间输出要不要暴露给用户？我的建议是，对于耗时较长的步骤，给用户一个简短的进度提示，但不要把所有技术细节都倒出来。比如“正在检查集群状态……”“集群不存在，正在创建……”“正在部署服务……”，这种粒度就够了。太详细会让用户困惑，太简略又会让用户觉得卡住了。
4. 在Google Cloud与GKE场景下落地Skill的实操路径
4.1 环境准备：Genkit项目初始化与Gemini接入
要在Google Cloud技术栈下玩转Agent Skills，第一步是把Genkit项目搭起来。Genkit是Google推出的一个用于构建AI应用的框架，它提供了定义工具、编排流程、管理状态的基础设施，很适合用来实现skill模式。
初始化一个Genkit项目，基本流程是这样的：先确保本地有Node.js环境（建议18以上），然后创建一个新目录，执行npm init，接着安装Genkit相关的依赖。核心依赖包括genkit本身，以及如果你要用Gemini的话，还需要@genkit-ai/googleai这个包。安装完之后，在项目里创建一个Genkit配置文件，配置好Gemini的API访问方式。
这里有个容易忽略的点：Gemini的API访问需要正确的项目配置和权限。如果你在本地开发，建议通过环境变量来管理凭证，不要把敏感信息写死在代码里。另外，Genkit支持多种模型后端，Gemini只是其中之一，你可以根据实际需求选择。配置好之后，可以写一个最简单的flow来验证环境是否正常，比如一个接收用户输入并返回Gemini回复的flow。跑通这个最小闭环之后，再往上叠加skill逻辑。
4.2 把Skill映射到Genkit的Tool和Flow
在Genkit里，skill的实现可以拆成两层：底层用tool来封装具体的原子操作，上层用flow来编排skill的完整流程。比如“部署服务到GKE”这个skill，底层可能有“检查集群是否存在”的tool、“创建集群”的tool、“构建镜像”的tool、“应用部署清单”的tool，上层则是一个flow，按照预定顺序调用这些tool，并在中间处理状态和异常。
这样分层的好处是，tool可以被多个skill复用，而flow则专注于某个skill的特定逻辑。比如“检查集群是否存在”这个tool，既可以用在部署skill里，也可以用在查询skill里。而部署flow和查询flow则各自有自己的编排逻辑，互不干扰。
在Genkit里定义tool的时候，要特别注意输入输出的schema定义。Genkit支持用Zod来定义schema，这能帮你做参数校验和类型推断。我一般会把每个tool的输入输出schema写得尽量严格，这样在flow里调用的时候，TypeScript能帮你提前发现很多类型错误。另外，tool的描述也要认真写，因为Genkit会把tool描述暴露给模型，模型靠它来判断是否调用。
4.3 一个完整的Skill示例：从用户指令到GKE部署
假设我们要实现一个skill，用户说“帮我把这个服务部署到GKE上”，skill要能完成从参数收集到部署验证的全过程。我来拆一下这个skill的完整流程。
第一步是意图确认与参数收集。skill被激活后，先检查用户输入里是否包含了必要信息：服务名称、镜像地址、目标集群。如果缺少，skill会生成一个询问信息，让模型转达给用户。比如用户只说“部署这个服务”，skill会问“请提供要部署的服务名称和镜像地址，以及目标GKE集群的名称和区域”。
第二步是前置检查。拿到参数后，skill先检查目标集群是否存在。这一步通过调用GKE相关的API来完成。如果集群不存在，skill会询问用户是否要创建新集群，或者根据预设的默认配置自动创建。这里有个经验点：自动创建集群虽然方便，但成本较高，建议默认走询问流程，除非用户明确说了“没有就新建”。
第三步是镜像准备。如果用户提供的是代码仓库地址而不是现成的镜像地址，skill需要先触发构建流程。这一步可能涉及Cloud Build或其他构建服务。构建完成后，把镜像推送到Artifact Registry或Container Registry，并记录镜像地址。
第四步是部署执行。skill生成Kubernetes部署清单，包含服务名称、镜像地址、副本数、资源限制等配置，然后应用到目标集群。应用之后，skill会轮询部署状态，直到所有副本就绪或超时。
第五步是结果反馈。部署成功后，skill返回服务的外部访问地址（如果有的话）、副本状态、以及后续操作建议。如果部署失败，skill返回失败原因和可能的修复建议。
整个流程里，状态对象贯穿始终，每一步的输入都来自状态对象，输出也写回状态对象。模型只在第一步和最后一步参与——第一步理解用户意图，最后一步把结果转述给用户。中间的执行过程完全由skill内部控制，模型不介入。这就是skill模式的核心优势：把确定性逻辑交给代码，把不确定性判断留给模型。
5. 调试与优化：Skill开发中那些文档不会告诉你的坑
5.1 触发边界模糊导致的“抢活”与“漏活”
Skill开发中最常见的问题不是逻辑写错了，而是触发边界没划清楚。我遇到过两个skill互相“抢活”的情况：一个“查询集群信息”的skill和一个“诊断集群问题”的skill，触发描述都写了“GKE集群相关”，结果用户问“我的集群怎么了”，两个skill都觉得自己该上场，模型也懵了。
解决这个问题的办法是，在触发描述里明确写出“不适用场景”。比如查询skill写“不适用于诊断问题或提供修复建议”，诊断skill写“不适用于单纯查询状态信息”。另外，可以在skill的元数据里加一个优先级字段，当多个skill都匹配时，按优先级选择。但优先级只是兜底手段，根本解法还是把触发描述写清楚。
“漏活”的问题通常出现在触发描述写得太窄的时候。比如一个skill的触发描述写“当用户明确说‘部署到GKE’时使用”，但用户实际说的是“把这个服务放到GKE上跑”，模型可能就匹配不上了。我的经验是，触发描述里要包含多种可能的表达方式，用“例如”“包括但不限于”这样的词来扩展覆盖面。同时，在测试阶段要刻意用不同的说法去试探触发边界，发现漏触发就补充描述。
5.2 参数提取失败时的降级策略
模型提取参数不是百分百可靠的，尤其是当用户表达比较模糊的时候。比如用户说“部署到美东”，模型可能提取出“us-east”，但GKE的区域格式是“us-east1”或“us-east4”。如果skill直接拿“us-east”去调API，就会失败。
我的做法是在skill里加一层参数规范化逻辑。对于区域这类有固定格式的参数，维护一个映射表，把常见的模糊表达映射到标准值。映射不上的，不要直接报错，而是返回一个询问信息，让模型去和用户确认。比如“您说的‘美东’具体是指us-east1还是us-east4？这两个区域在服务和价格上略有差异。”
对于项目ID、集群名称这类没有固定格式但必须准确的参数，我的策略是：如果模型提取的值在系统里查不到，不要立即失败，而是先尝试模糊匹配。比如用户说的集群名称和实际集群名称只差一个连字符，可以提示用户“您是指xxx集群吗？”让用户确认。这样比直接报错友好得多。
5.3 长流程中的超时与重试处理
涉及GKE集群创建或镜像构建的skill，执行时间可能比较长，几分钟甚至十几分钟都很正常。这种长流程里，超时和重试是必须考虑的问题。
首先，每个步骤都要设置合理的超时时间。比如检查集群是否存在，超时可以设短一点，10秒左右；创建集群，超时要设长一点，可能15分钟。超时后不要直接失败，而是先检查实际状态——有可能操作已经成功了只是响应慢了。我一般会在超时后加一个“状态复核”步骤，确认实际状态后再决定是重试还是报错。
重试策略也要分情况。对于查询类的操作，重试通常没问题；对于创建类的操作，重试前一定要先确认上一次是否真的失败了，避免重复创建。我见过一个案例，创建集群的请求超时了，skill直接重试，结果创建了两个集群。后来我在skill里加了一个“幂等性检查”：每次创建前先按名称查一下，如果已存在就跳过创建，直接进入下一步。
还有一个细节是，长流程中要定期向用户反馈进度。如果skill要跑十分钟，中间一句话都不说，用户会以为卡死了。我通常会在每个主要步骤开始时给一个简短提示，比如“正在创建集群，这可能需要几分钟……”。这些提示不需要很详细，但要让用户知道系统还在工作。
6. 从单Skill到Skill组合：复杂任务的拆解思路
6.1 什么情况下该拆成多个Skill
一个skill不是越大越好。我见过有人把整个部署流程塞进一个skill里，结果这个skill的触发描述写了五百字，参数有二十多个，内部逻辑上千行。这种skill维护起来很痛苦，而且复用性很差。
判断该不该拆的标准，我一般看三点：触发场景是否独立、参数集合是否重叠、执行流程是否可分离。如果两个操作经常被用户在同一句话里提到，但触发条件不同，那就该拆。比如“创建集群”和“部署服务”经常连着做，但用户也可能只想创建集群不部署，或者部署到已有集群，这就是两个独立的触发场景，应该拆成两个skill。
如果两个操作的参数高度重叠，拆开会导致用户要重复提供信息，那可能不该拆，或者拆开后要用共享的上下文来传递参数。如果执行流程中间有明确的“断点”，比如需要用户确认才能继续，那这个断点就是天然的拆分点。
拆的好处是每个skill更专注、更容易测试、更容易复用。代价是skill之间的协调需要额外处理。我的经验是，宁可拆细一点，用组合的方式来编排，也不要做一个大而全的skill。细粒度的skill在调试时优势太明显了——出问题的时候你能快速定位是哪个环节，而不是在一个巨型skill里大海捞针。
6.2 Skill之间的上下文传递
拆成多个skill之后，上下文传递就成了关键问题。比如“创建集群”skill执行完后，“部署服务”skill需要知道新建集群的名称和区域。这些信息怎么传？
最直接的方式是通过一个共享的会话状态。在Genkit里，你可以用session或类似的机制来保存跨skill的上下文。每个skill执行完后，把关键输出写入会话状态；下一个skill执行前，从会话状态里读取需要的字段。这样skill之间不需要直接耦合，都通过会话状态来交换信息。
但这里有个坑：会话状态里的字段命名要统一。如果创建skill写的是clusterName，部署skill读的是cluster_name，那就对不上了。我的做法是维护一个共享的schema定义，所有skill都从这个schema里引用字段名。这样改字段名的时候一处改处处生效，不会出现不一致。
另一个坑是状态过期。如果用户创建集群后过了很久才来部署，会话状态可能已经失效了。这时候skill要能检测到状态缺失，并引导用户重新提供信息，而不是直接报错。我一般会在skill开头加一个“状态检查”步骤，确认需要的字段都存在且有效，缺什么就问什么。
6.3 组合编排中的错误传播与回滚
多个skill组合执行时，错误处理会更复杂。如果第一个skill成功了，第二个skill失败了，要不要回滚第一个skill的操作？这个问题没有标准答案，取决于具体场景。
对于创建集群这种重操作，回滚意味着删除集群，成本很高，而且可能不是用户想要的。我的做法是，默认不回滚，但把失败信息和当前状态清楚地告诉用户，让用户决定下一步。比如“集群已创建成功，但服务部署失败，失败原因是xxx。你可以选择重试部署，或者删除集群。”
对于轻量操作，比如修改配置，回滚可能更合适。但回滚本身也可能失败，所以回滚逻辑要设计得足够健壮。我一般会为每个可回滚的操作记录一个“回滚指令”，失败时按相反顺序执行回滚指令。如果回滚也失败了，就记录详细日志并通知用户手动处理。
还有一个实践点是，在组合编排中要区分“可恢复错误”和“不可恢复错误”。网络超时、临时限流这类属于可恢复错误，可以自动重试；参数错误、权限不足这类属于不可恢复错误，重试也没用，应该直接报错并给出修复建议。在skill里对错误分类处理，能大大提升组合流程的稳定性。
7. 测试Agent Skills时我常用的几个土办法
7.1 用“边界语句”试探触发逻辑
测试skill的触发逻辑，不能只用标准说法。我一般会准备一组“边界语句”，专门用来试探触发边界。比如对于“部署服务”skill，标准说法是“帮我把服务部署到GKE”，边界语句可能包括：“把这个服务放到GKE上跑”（换了个说法）、“我想在GKE上运行这个服务”（意图相同但表达不同）、“GKE上怎么部署服务”（这是询问而不是指令，不应该触发）、“帮我看看GKE上的服务状态”（这是查询，不应该触发部署skill）。
把这些边界语句跑一遍，看skill的触发情况是否符合预期。不符合的就调整触发描述，然后再跑一遍。这个过程可能要反复好几轮，但每轮都能让触发边界更清晰。我一般会把测试用的边界语句整理成一个列表，每次修改触发描述后都跑一遍回归，确保没有把之前修好的又改坏了。
7.2 模拟参数缺失和异常输入
参数提取的测试，重点是模拟各种“不完整”和“不规范”的输入。比如用户只说“部署服务”不说部署到哪里，或者用户说“部署到那个集群”但上下文里没有集群信息，或者用户提供的镜像地址格式不对。这些情况skill都应该能优雅处理，而不是直接崩溃。
我一般会构造一组测试用例，覆盖这些场景：参数完全缺失、参数部分缺失、参数格式错误、参数值不存在、参数值有歧义。每个用例都跑一遍，看skill的响应是否合理。合理的响应包括：友好地询问缺失信息、给出格式要求、提示可能的值、在歧义时请求确认。不合理的响应包括：直接报错、静默失败、用错误的默认值继续执行。
异常输入的测试也很重要。比如用户输入里包含特殊字符、超长文本、或者和任务无关的内容。skill应该能忽略无关内容，专注于提取有用信息。如果用户输入完全无法理解，skill应该礼貌地请用户重新表述，而不是胡乱猜测。
7.3 观察模型在skill执行中的“多余动作”
即使skill封装得很好，模型有时还是会在skill执行过程中插入一些“多余动作”。比如skill正在按流程执行，模型突然插一句“我觉得还可以这样……”，或者在不该询问的时候询问用户。这些多余动作会干扰skill的正常执行。
观察这些多余动作，能帮你发现skill设计中的问题。如果模型频繁在某个步骤插入询问，可能是那个步骤的进度反馈不够清晰，模型不确定当前状态。如果模型在skill执行中尝试调用其他工具，可能是skill的触发描述没有明确排除其他操作。如果模型在skill完成后还在继续生成内容，可能是skill的输出规范没有定义清楚“什么时候算结束”。
我的做法是，在skill的输出里明确标注“任务已完成”或“任务已失败”，并给出下一步建议。这样模型就知道该收尾了，不会继续自由发挥。另外，在skill执行过程中，尽量减少模型可以自由生成的环节，把能确定的内容都用模板或固定文案来输出，减少模型“加戏”的空间。
8. 关于Agent Skills，我目前的一些判断和保留意见
Agent Skills这个概念，我觉得它解决了一个真实存在的问题：智能体在复杂任务中的行为稳定性。通过把能力封装成带流程、带状态、带异常处理的单元，确实能让智能体在更多场景下可靠工作。尤其是在Google Cloud、GKE这种操作步骤多、参数要求严的场景下，skill模式比裸工具调用要稳得多。
但我也有一些保留意见。首先，skill的维护成本不低。每个skill都要写触发描述、定义参数、编排流程、处理异常，还要不断测试和调整。如果skill数量多了，管理这些skill本身就是一个工程问题。其次，skill的触发判断仍然依赖模型，而模型的行为不是完全可预测的。你可能写了很清楚的触发描述，但模型在某些情况下还是会误判。所以skill模式不是银弹，它只是把不确定性从“执行过程”转移到了“触发判断”，而触发判断的不确定性目前还没有特别好的解法。
另外，skill的粒度怎么把握，也是一个需要根据具体场景反复调试的问题。太粗了复用性差，太细了组合成本高。我目前的经验是，从最常用的场景开始，先做几个核心skill，跑一段时间看哪些地方需要拆、哪些地方需要合，再逐步调整。不要一开始就设计一个庞大的skill体系，那样很容易过度设计。
最后说一个实际体会：skill的文档和测试用例，比skill本身的代码更重要。因为skill的价值在于“可被正确使用”，而正确使用的前提是触发描述清晰、参数定义明确、异常处理合理。这些东西如果没写好，代码写得再漂亮也没用。我现在的习惯是，写skill之前先把触发描述和测试用例写好，确认边界清晰了再动手写实现。这个顺序看起来慢，但实际上省了很多返工的时间。
