做Agent到一定阶段的人应该都有这种感觉单个工具调用早就不是瓶颈了真正决定一个智能体是“玩具”还是“生产力工具”的是你给它组织的技能体系。我在多个Agent项目里反复调整prompt、拆分工具、重构流程之后发现最终能稳定提效的是agent-skills这套思路——它不是某个具体框架的功能而是一种把Agent能力封装成“可复用技能”的工程化方法。这篇文章把我这段时间踩过的坑、总结出的结构、以及验证过有效的实操经验一次讲清楚适合正在做Agent落地、或者准备从零搭技能库的人参考。1. 从Tools到SkillsAgent能力组织的范式转变1.1 Tools为什么不够用了早期我们做Agent能力扩展最直接的做法是给模型提供一批Tools查天气、算数学、读文件、调API。每个Tool本质上是“一个函数一段描述”模型根据用户的意图决定调用哪个。这个模式在Demo阶段很好用但一旦场景复杂起来问题马上暴露第一个问题是上下文膨胀。一个真实业务Agent往往需要几十个工具每个工具的描述、参数说明、调用约束加起来光工具定义就能占掉上万token。模型不是每一次都需要全部工具但全量挂载就意味着每一次对话都在为用不到的细节买单推理速度和准确率一起下降。第二个问题是工具本身没有“防御力”。Tool就是一个输入到输出的映射参数传错了会报错返回结果不合理也没有自检机制。模型对这些一无所知它以为调用成功了但拿到的是一个垃圾结果后面的步骤全部建立在错误基础上。第三个问题是难以复用。一个工具拆得越细越容易被不同场景调用但也越难保证“多步操作”的一致性。比如“下订单”这个动作只暴露一个下单API远远不够它可能需要先查库存、再锁优惠、最后提交订单还要处理中途失败的回滚。这种“复合能力”用单纯Tools来表达逻辑会分散在Agent的prompt里改一处牵一发动全身。1.2 Skills的定义能力封装而不是接口暴露Skills和Tools的核心区别在于思考的单位不一样。Tool是接口视角它回答的是“我能调什么”Skill是能力视角它回答的是“我能完成什么目标”。一个Skill可以内部调用多个Tool可以把领域规则写死在执行逻辑里可以在返回结果之前自己做一遍合理性校验甚至可以在失败时尝试替代方案。对于上层的Agent来说它只需要知道“什么时候该用这个技能”“跳过这个技能会损失什么”“这个技能要求什么输入”至于技能内部多复杂不归它管。用生活化的类比Tool像你工具箱里的一把螺丝刀Skill则是“换一个轮胎”这件事你不仅需要螺丝刀还要千斤顶、扭力扳手还要知道拆装顺序和拧螺丝的力矩标准。螺丝刀只是一个零件换轮胎是一项技能。这个视角的切换直接影响Agent的稳定性和可维护性。我后来把项目里所有工具按“业务目标”重新组织成技能库prompt大幅瘦身模型的行为可预测性明显提升这就是agent-skills方法论带来的直接改变。1.3 Skills适用的典型场景不是所有项目都需要上技能库。我的判断标准很简单如果Agent只需要五六个工具且每个工具之间没有强依赖直接用Tools也够用。但出现下面这些信号时就该切换到Skills了同一组工具经常被“组合调用”且组合顺序固定工具使用过程中需要业务规则校验比如金额边界、库存判断、权限检查一次任务可能失败失败后需要降级或重试多个项目或多个Agent需要共享同一套能力工具数量超过20个模型开始频繁选错其中一个“频繁选错”最为致命。模型选错工具往往不是因为模型笨而是因为工具描述之间语义重叠、边界模糊。Skills可以通过严格的意图声明和触发条件来解决这一点后面第3部分会细说。2. 一个完整Skill的四层结构缺一层都容易翻车如果只给Skill写一个函数和一个描述那本质上还是Tool。一个真正能扛住生产环境的Skill我会要求它具备四层结构意图声明、输入契约、执行逻辑、质量护栏。这四层各管一段合起来才能让技能既“调得准”又“跑得稳”。2.1 意图声明说清楚“什么时候用”和“什么时候不用”意图声明就是技能的说明书但很多人把它写成了“功能简介”。比如错误写法查询商品库存正确写法当用户询问某个商品是否有货、库存数量、能否购买时使用本技能。如果是需要购买或下单请使用下单技能不要调用本技能。差别在于正确写法包含了两个关键部分正例触发信号和排除边界。只写功能名的后果是模型遇到语义接近的需求时不知道边界在哪里。例如用户问“这个商品还能买吗”它可能会选择库存查询但实际应该判断成下单前的库存确认由下单技能内部处理。我在意图声明里固定使用如下模板效果很好技能名称简洁不堆叠技术词汇一句话说明这个技能做什么输出什么触发条件哪些关键词、哪些语义场景下应该调用不适用场景明显不该调用的情况写2-3个典型反例依赖说明依赖哪些其他技能或数据源这段声明会被输入给模型做意图匹配也会被嵌入方案做语义检索所以宁可多花点时间写清楚也不要含糊其辞。2.2 输入契约用Schema约束模型的想象力模型在决定调用技能时需要根据用户的原始输入来“填参数”。如果没有一个强约束的Schema模型经常脑补参数或漏传关键字段。我一般建议输入契约使用JSON Schema描述包含每个参数的名称、类型、是否必填可枚举值的范围比如订单状态只允许几个合法值参数之间的约束关系比如end_time必须晚于start_time默认值策略不传时是报错还是使用默认值一个下单技能的输入契约示例{ type: object, required: [product_id, quantity, shipping_address], properties: { product_id: { type: string, description: 商品ID必须是从商品查询结果中取得的ID }, quantity: { type: integer, minimum: 1, maximum: 99, description: 购买数量 }, coupon_code: { type: string, description: 优惠券码可选 } } }这里有一个细节product_id不能是模型自由生成的字符串必须来自上游查询结果。这个约束写在字段描述里比写在代码里更容易让模型遵守因为模型在执行时是“先读Schema再生成参数”的。参数校验失败时不要只返回一个“参数错误”要把具体哪个字段不合法、合法范围是什么都说清楚这样模型才有机会进行二次修正而不会放弃调用或反复撞同一个错误。2.3 执行逻辑把领域规则沉淀在代码里执行逻辑是技能的核心主体它可以是直接调用一个函数也可以编排多个工具。我强烈建议把可确定的业务规则写死在代码里而不是写到prompt里让模型临场发挥。举个例子“拆红包”这个技能里有一个规则单个用户每天只能领三次。这个规则如果放在prompt里模型可能在某次对话里忘记或者被用户的话术误导。但如果放在技能执行逻辑里每次领取时都检查领取次数超限就返回“今日已领取三次”这条规则就是绝对可靠的。执行逻辑还需要注意幂等性。同一个技能参数相同多次执行应该产生相同的结果或明确的可重入语义——尤其是涉及扣款、发消息这类有副作用的操作。否则Agent在重试时会重复扣款、重复发通知这在生产环境是不可接受的。我给每个技能的执行函数都增加了request_id参数同一请求重复提交时只生效一次。这个习惯帮我挡掉了好几个线上事故。2.4 质量护栏别让错误答案流出技能质量护栏是Skills和Tools最大的一点不同。它不仅保证“调用不崩溃”还要保证“输出可被信任”。我通常会在执行逻辑之后接一个自检步骤规则大致如下def validate_result(result, request_params): if result is None: raise SkillExecutionError(返回结果为空) if result.get(status) failed: return RollbackAction(reasonresult.get(error_message)) if result.get(total_amount, 0) 0: raise SkillExecutionError(订单金额异常需要人工确认) return result这段代码解决的是“模型感知不到结果是否合理”的问题。如果没有自检环节技能返回了一个空列表模型可能以为“查无数据”并如实告诉用户如果加上自检空结果会被标记为异常触发重试或切换到人工流程。质量护栏还包括降级方案。比如一个技能依赖外部搜索服务搜索服务超时后是直接报错还是尝试用本地缓存兜底我的习惯是优先本地缓存其次返回部分结果并在返回信息里明确标注“数据可能不是最新”至少不要让用户面对一个完整的失败。这样一个四层结构的Skill把模型以外的东西全部固化了Agent需要做的思考只剩下“是否调用、传什么参数”判断路径短了自然稳定得多。3. 让Agent学会在正确时机调用技能触发与选择实践技能定义得再好触发不对也白搭。一个技能库可能有几十个技能想让模型每次都能选到最合适的那一个不能只靠大模型的“临场发挥”需要有意识地设计选择机制。3.1 为什么不能完全依赖模型自由选择模型在上下文里看到所有技能描述时看起来“什么都会”但实际选择质量受三个因素影响描述文字的相似度会干扰判断、模型会受用户话术的意图迁移影响、技能太多时注意力会被稀释。最典型的问题是语义相似技能互相干扰。我做过一个客服Agent同时有“订单查询”和“物流查询”两个技能它们的描述高度相似一个说的是查订单状态一个说的是查快递位置。用户问“我的东西到哪了”模型一会儿选订单查询一会儿选物流查询完全看心情。这类问题是模型能力无法靠提示词解决的必须引入更结构化的选择机制。3.2 两阶段选择Embedding预筛 模型精排方案我采用的方案是两阶段选择先粗筛再精排每一阶段的花销都不大。第一阶段用用户最近的输入做Embedding和每个技能的描述做向量相似度计算召回Top K个候选技能。这样做的目的是把选择范围从50个缩小到5个左右避免模型面对过大的候选集。此时描述的写法很关键包含触发场景关键词的技能描述向量检索的效果会好很多。第二阶段把Top K候选技能的名称、描述、适用条件、边界条件连同用户的完整对话历史一起放进模型prompt让模型做一个精排决策。此时模型不需要在一堆噪音里找答案只需要在几个高相关技能里挑一个准确率明显提高。两阶段方案实现起来不复杂核心代码如下candidates await retrieve_candidate_skills( user_inputlatest_message, top_k5, skill_indexskill_embedding_index ) selected_skill await select_skill_with_llm( candidatescandidates, conversation_historyhistory, )这个方案上线后技能触发的准确率从84%提升到94%而且调用成本几乎没有增加。因为第一阶段用的是便宜快速的Embedding模型第二阶段只把5个技能塞进精排prompt比全部技能塞入的token开销小得多。注意预筛的Embedding模型不要用太弱的至少要保证领域词汇有基本区分能力。我遇到过用通用小模型做Embedding时“订单”“库存”“发货”这几个词向量距离太近预筛直接把正确技能排掉了导致精排阶段根本没有机会。3.3 技能描述怎么写检索才更容易命中既然要做向量检索技能描述就不能只“给人看”还得“给向量看”。几个提高命中的技巧描述中自然嵌入高频用户口语词。例如“查库存”可以写成“当用户说‘有货吗’‘库存够吗’‘还剩多少件’时触发”这些口语表达恰恰是用户输入的高频形式。每个技能写2-4个典型query样例并把这些样例加入技能索引的Embedding内容里。这相当于给技能打了“语义锚点”。避免在描述中堆叠同义词反而会稀释向量特征。选3个最有代表性的触发场景写清楚即可。以“订单改地址”技能为例我会写出这样的触发样例“我要改一下收货地址”“把东西寄到另一个地址”“订单地址写错了能换吗”这三个句子涵盖了不同的表达习惯当用户输入形式接近其中任何一个时Embedding相关性都足够高。3.4 冲突仲裁当多个技能都适合时怎么办两阶段选择只能解决“选出几个候选”但真实场景中候选技能之间可能存在硬冲突。例如“取消订单”和“修改订单”两个技能用户问“我不要了”两个技能的描述都能匹配上这时候模型很可能随机选一个。我的做法是在精排prompt中显式加入优先级规则让模型在处理语义重叠时有一个决策依据。优先级规则一般在技能定义的元数据里声明比如如果订单已发货取消操作需要先走“拦截物流”逻辑此时优先调用“拦截物流”技能只有未发货订单才能使用“取消订单”技能当用户表达的意图是“不想买”但订单已发货时选择“售后申请”而不是“取消订单”精排prompt里加上这样几条硬性判断规则模型就很少再选错了。对于特别容易混淆的技能对我还会在双方的意图声明里互相添加排除描述例如取消订单技能里写“本技能仅处理未发货订单已发货订单请交给售后申请技能处理”。这种“互斥声明”的效果比单一优先级提示词更稳定。3.5 Few-shot样例的作用和写法想让精排模型更稳定还可以在技能选择阶段塞一两个Few-shot示例。注意这里不是给执行阶段补充知识而是给“选择行为”建立模仿模板。我一般给精排prompt准备3个few-shot对每个对包含一段用户消息、几个候选技能、正确的选择结果和一句简短的“为什么选它”。重点提示模型选择时优先看用户当前意图而不是历史话题如果候选技能中没有完全匹配的选择一个可以做最小近似执行的技能并明确向用户说明偏差。加了这个之后最直观的变化是“模棱两可”场景下的行为一致性变好了。以前同一个query在不同会话里可能选出不同技能加了few-shot后基本固定下来这对后续日志分析和优化非常重要。4. 技能的复用与组合从单点能力到执行链路4.1 三种基础组合模式覆盖大多数业务流单一技能解决不了复杂任务组合是必然的。我总结出三种最常用的技能组合模式顺序链模式A技能的输出作为B技能的输入一步一步往下走。典型场景是“查商品→加购物车→结算→下单”每一步的输出都能自然衔接下一步。顺序链的关键是每一步的返回结果要包含下一步所需的结构化字段最好直接返回JSON而不是渲染好的文本。条件分支模式根据中间结果决定走哪条分支。比如付款环节如果订单金额为零走“免费领取技能”否则走“在线支付技能”。这种模式要求前面的技能返回一个可判断的状态字段例如order.amount和order.status。并行扇出模式一个任务拆成多个子任务并发执行最后汇总结果。比如“对比三款手机配置”可以并行调用三次“商品详情查询”技能再让模型综合对比。这个模式能显著降低整体时延但要注意技能是否有副作用只有只读技能才能安全并行。4.2 上下文传递数据共享的三个原则技能组合最让我头疼的不是调用顺序而是“数据怎么传”。早期我图省事在全局上下文里塞各种临时字段技能之间互相读取结果上下文变成一个所有人都在涂改的黑板改一处崩一片。后来我定下三条原则技能之间显式传参A技能需要B技能的结果时用参数传递不靠“隐式环境变量”。隐式依赖一旦多起来排查链路时的成本极高。只读共享全局数据用户画像、系统配置这类跨技能通用的数据放在全局上下文但任何技能都不允许修改它们只能读取。有需要针对用户做状态变更时通过显式参数传到技能内部处理。会话级状态写入专门存储临时状态写入会话级存储比如conversation_state.set(payment_step, 2)由编排层统一管理技能不直接操作。这三条原则让技能之间的耦合度降到最低也让技能能够独立复用和测试不至于“离开那个环境就跑不起来”。4.3 依赖声明让编排层知道谁在等谁当一个技能链越来越长时调度层面的可观测性就变得重要。我在每个技能定义中增加一个可选字段depends_on声明该技能依赖的前置技能或外部数据这样编排层在执行前可以先做一个依赖解析。例如{ name: 结算下单, depends_on: [查询商品库存, 计算优惠价格] }当用户要求“把购物车里的东西结算掉”时编排层会读取购物车中现有商品的元数据自动补齐“查询商品库存”的调用完成后才进入“结算下单”技能。这个过程用户是无感知的但对Agent来说相当于执行前多了一个编译期检查。依赖声明还能帮我做自动化测试。我写了一个回归脚本遍历所有技能的依赖图检查是否存在循环依赖、缺少依赖、或者依赖输出格式不匹配的问题。上线前跑一遍能避免很多“运行到一半突然发现上游没数据”的尴尬。4.4 组合技能降级策略组合链路越长失败点越多。我给每个组合流程都定义了降级策略不能说最后一环失败了整个链路就没了。比如“下单链路”中支付超时降级为生成支付链接发给用户继续支付如果配送地址无法解析降级为让用户手动填写地址并保留购物车内容。一个简单的降级配置结构{ steps: [ { skill: 查询商品库存, fallback: 使用缓存库存数据并标注可能过期 }, { skill: 计算优惠价格, fallback: 不应用优惠券提示用户优惠信息暂不可用 }, { skill: 结算下单, fallback: 返回部分下单结果并标记需要人工确认 } ] }这个策略的核心思想是每一步失败都尽量不中断整个用户目标哪怕结果是降级的也要让用户能在一部分可用能力下继续推进。比起一句“系统繁忙请稍后再试”这种处理方式在真实业务中的体验差距是非常明显的。5. Skill设计踩坑实录五个让我熬夜排查的问题这部分是我最想分享的因为全是实打实的生产事故换来的经验。5.1 “万能技能”陷阱一个技能塞了太多职责我最早设计技能时为了图省事把“订单相关”的能力都塞进了一个大技能里包括查订单、改订单、取消订单、催发货。描述写得密密麻麻让模型“根据用户意图自行处理”。结果模型频繁出现两种行为用户问“我的订单到哪里了”它调用大技能内部走的是“查订单详情”分支返回却渲染成“物流轨迹”用户想改地址它又把订单状态和物流状态搅在一起。最要命的是因为技能描述太长精排阶段模型经常只看到前半段描述以为这个技能只负责查询完全没触发。排查链路的起点是日志——我发现几乎所有“误触发”最后都指向同一个技能但触发理由五花八门。后来我把这个万能技能按业务目标拆成五个独立技能查订单、改地址、取消订单、查物流、催发货每个都重新写意图声明问题才真正解决。教训就是技能粒度要按“用户可感知的目标”划分不按“业务模块”划分。一个技能只做一件事并把这件事描述到极致。5.2 描述里的技术黑话模型根本看不懂还有一个隐藏很深的坑技能描述是我以工程师视角写的充满“创建工单”“关联主数据”“刷新物化视图”这类词。模型可能认识这些词但用户不会这么说话模型的“意图匹配”也就找不到对应关系。用户说“帮我问一下物流”技能描述写的是“查询运单节点信息”Embedding相似度很低模型即使精排也get不到。后来我把所有技能描述都改成“用户口语业务含义”的写法比如“查物流”技能描述里直接写“当用户问包裹到哪了、东西送没送到、快递进度时触发”。改完之后误触发和漏触发都下降了。我现在要求团队所有技能描述必须经过“口语化改写”核心标准是一个完全不懂技术的用户用最自然的话提问这个描述能不能让模型想起这个技能。5.3 输入校验形同虚设技能裸奔有一次线上频繁出现脏数据排查到最后发现是我的校验逻辑写得太过宽松一个quantity字段模型传了“2件”这样的字符串Schema校验写的是type: integer按理说应该报错但加载的JSON Schema库默认关闭了严格模式字符串“2件”被当作校验通过后面计算全乱了。还有一次更隐蔽技能接收一个日期范围参数模型传了结束日期早于开始日期校验只检查“格式合法”没检查“逻辑合理”结果统计数据直接显示成负数。这让我彻底明白输入校验是技能的第一道防线必须写成“宁可错杀不可放过”。合法的才放行任何可疑输入都要返回结构化错误信息并且把错误原因直接传给模型让它有机会修正参数。后来我写了一个通用校验函数把类型、范围、关联关系全部统一跑一遍这套校验函数还被复用到了其他所有技能里。5.4 失败不被感知Agent一本正经地胡说八道这个坑最隐蔽也最危险。某个技能在调用外部ERP接口时如果接口返回HTTP 200但业务码是500我的代码没有检查业务码直接把响应里的一个空列表返回给了Agent。Agent拿到空列表以为“没有数据”非常自信地告诉用户“您目前没有未发货的订单”。但真实情况是接口数据库刚好短暂不可用只是错误信息没有被透传。这个问题的根因是执行逻辑缺少结果语义校验。修复方案就是我在第2部分说的质量护栏调用外部接口后必须做状态码和业务码双重检查同时设定异常返回的兜底文案不让技能返回“空结果”冒充“正常空数据”。我还新增了一条规则当技能出现非预期异常时返回结果里必须带一个error_context字段说明“发生了什么、已尝试过什么、下一步可以怎么做”。这样即使失败Agent也能基于上下文给用户一个合理的解释而不是把异常吞掉。5.5 技能版本混乱测试结果反复横跳技能库进入维护期后我遇到过接口行为忽好忽坏的阶段同一个query上周回归通过这周就选错技能。查到最后发现技能描述在两天内被改了七次大家都在“顺手”微调但没有任何人记录版本。从那以后我要求所有技能定义进入Git管理每次修改走MR评审描述变更必须有对应的测试用例更新。技能库的每一次改动都会触发回归测试集跑一遍全部技能触发场景和执行场景确保改动只影响了预期范围。技能版本和代码版本同步管理还有一个好处Agent线上使用旧版本但新版本可以在隔离环境里跑灰度对照不会干扰线上数据。现在我再也不担心“谁动过那个技能”了Git日志会告诉我一切。6. 把技能库当成产品来运营评估、迭代与沉淀6.1 建立技能测试集先测后改防止回归技能库的工程质量需要一个可持续的评估机制。我每个技能都维护了对应的测试集包含触发测试、执行测试、边界测试三类测试类型覆盖内容用例数量建议触发测试用户不同说法下是否能正确触发目标技能20-40条执行测试正确参数下执行结果是否符合预期5-10条边界测试参数缺失、非法值、异常接口响应等场景5-10条触发测试是最有价值的它能直接反映技能描述和选择机制的质量。我经常在一个新技能写完后跑一遍触发测试如果准确率不到90%就说明描述或边界条件写得有问题需要继续调优绝不能让一个“半成品技能”进库。回归测试是整个技能库的“体检仪”每次有技能增删改我都会全量跑一遍重点看修改是否影响了其他技能的触发率。有很多次都是“改了一个技能结果另一个技能的触发测试挂了”这种跨技能影响在手工测试里几乎不可能发现。6.2 可观测性每个调用都要回答“为什么选它”技能跑得对不对光靠用户反馈太慢了。我要求所有技能调用都必须打日志并且记录以下字段调用时间、用户原始输入、被召回的候选技能列表、被选中的技能及置信度、输入参数、执行结果、耗时。有了这些日志我能复盘任何一次“错误触发”。比如用户明明在问物流为什么模型选了下单技能打开日志一看精排阶段候选技能列表里根本没有物流查询技能说明物流查询技能在第一阶段的Embedding召回里就被过滤掉了。于是我知道是描述问题还是阈值问题而不是对着模型干瞪眼。我还给每个技能加了trigger_reason字段模型精排选择后必须生成一句简短说明“因为用户提到‘包裹到哪了’所以选择物流查询技能”。这句话看起来不起眼但在复盘误触发、优化few-shot的时候价值极大。6.3 从日志中挖掘两类问题误触发与漏触发日志分析的终极目标是找到两种错误行为并给出针对性修正。误触发用户意图是A场景模型选成了B技能。这类问题通常是技能描述之间有语义重叠或者优先级规则没写清楚。修正手段在A和B的描述中互相加排除边界或者增加一条优先级规则让模型在语义接近时按业务规则决策。漏触发用户意图明显是A场景但模型没选任何技能直接走自定义回复。这类问题通常是描述没有覆盖到用户的高频表达或者候选技能Top K里A技能没有被召回。修正手段把日志中漏触发的用户query加入技能描述的触发样例里用真实用户的说话方式补充语义锚点。我养成了一个习惯每周固定花一小时翻一遍技能调用日志把误触发和漏触发的典型案例记录下来更新到对应的技能描述或测试集里。坚持一个月后技能库的触发准确率会有肉眼可见的提升。6.4 技能库的自然淘汰与版本迭代技能越多管理成本越高“没用的技能”会成为模型选择的噪音。我规定每个技能必须有自己的触发率统计三个月内触发率低于某个阈值比如每月少于20次的技能进入“待淘汰”状态再观察一个月确实没有低频价值后下架归档。下架不是删除而是把技能定义和测试用例完整归档到代码库的历史版本里。说实话所有下架技能里有一半后来被重新启用了——场景变化、话术变化、新需求出现旧技能改改描述就能上这时候归档的好处就体现了。版本迭代方面我推荐用语义化版本主版本号对应意图声明或交互行为的大改次版本号对应执行逻辑优化补丁号对应小修小补。每次发版都走测试集回归确保质量这个习惯帮我省了很多线上返工的时间。6.5 控制技能库的“肥胖率”少而精是长期原则技能库会越做越大但增量不一定代表更好。技能多了之后选择链路的噪音也随之增加即使有预筛机制如果技能之间语义高度相似召回时也容易互相污染。我的原则是能合并的合并能删除的删除宁可少一个技能也不留一个鸡肋技能。判断一个技能是否该存在的标准很简单它是否能独立、高频、清晰地服务一个用户可感知的目标。如果三个技能总是一起出现、面向相似场景我会考虑合并成一个大技能如果一个技能在当前产品语境下几乎没有存在感那就毫不犹豫地让它下架。一个成熟的技能库就像一套好用的工具箱不一定有很多工具但每一个工具都清楚自己能干什么、不能干什么、适合在什么场景用。每次新加技能之前先问问自己真的需要吗有没有已有的技能能覆盖想清楚这两个问题再动手写代码比埋头造轮子高效得多。