agent-skills 这个词最近在 AI 应用开发圈子里出现的频率越来越高。如果你关注过 AutoGPT、BabyAGI 这类项目或者研究过 Function Calling、Tool Use 相关的技术方案大概率已经接触过这个概念。但很多人对它的理解还停留在“给 Agent 加几个工具函数”这个层面实际上 agent-skills 要解决的是更底层的智能体能力构建问题怎么让一个通用模型在特定场景下像熟手一样干活而不是每次从零开始摸索。这篇文章我会从一个实际开发者的视角完整拆解 agent-skills 的核心逻辑、实现路径和踩坑记录。内容主要面向两类读者一类是刚接触 Agent 开发、想搞清楚技能系统和普通工具调用有什么本质区别的初学者另一类是已经做过几个 Demo、想在稳定性、可扩展性和效果上更进一步的中级开发者。无论你属于哪一类这篇文章都会给你一些可以直接落地的参考。1. 技能系统与工具调用的本质差异很多人第一次接触 agent-skills会误以为它就是把 API 封装成函数列表交给模型。这个理解不算错但远远不够。传统的工具调用Tool Use解决的是“模型能不能调用外部能力”的问题而技能系统Skills解决的是“模型能不能像熟练工一样完成复杂任务”的问题。这两者的复杂度完全不在一个量级。举个直观的例子。假设你要让 Agent 帮你整理一份周报。用传统工具调用的思路你需要提供“读取聊天记录”“提取关键事项”“生成文本”这三个函数然后靠提示词告诉模型先调用哪个、再调用哪个。这种方式在任务路径固定、步骤较少时确实有效可一旦任务变成“每周自动整理周报还要根据团队成员的不同岗位生成不同详略程度的版本再把上周遗留事项自动合并到本周计划”传统工具调用的短板就暴露了模型每次都要重新理解任务、重新规划步骤既不稳定也容易遗漏上下文。技能系统的思路完全不同。它会把“整理周报”这件事本身封装成一个完整的技能模块这个模块里不仅包含工具函数还包含任务拆解逻辑、步骤顺序、经验规则、常见异常处理方案甚至是针对特定场景的提示词模板。当 Agent 识别到当前任务可以匹配到已有技能时它会直接加载整套方案而不是临时思考怎么做。我用一个类比来帮助理解工具调用像是给一个新员工一份电话簿他需要什么资源就查什么号码技能系统则像是给这位员工一本完整的操作手册不仅告诉他找谁还告诉他每一步怎么做、遇到问题怎么处理、哪些细节容易出错。这就是为什么 agent-skills 在处理重复性、专业性任务时效果和稳定性都显著优于单纯的工具调用。1.1 技能的层级结构与组织形式实际构建技能系统时第一个要解决的问题是技能的组织形式。我见过不少项目把技能做成了扁平结构也就是一堆 JSON 文件平铺在目录里每个 JSON 描述一个技能。这种方式在小规模场景下勉强能用一旦技能数量超过 20 个管理成本和检索成本就会急剧上升。更合理的做法是分层组织。顶层是技能域Skill Domain对应业务场景的大类比如“数据分析”“文档处理”“日常办公”中间层是具体技能Skill对应可复用的任务单元比如“Excel 透视表生成”“PDF 信息抽取”底层是原子操作Atomic Operation对应不可再拆分的工具函数。这个分层结构带来的直接好处是模型在规划任务时不需要在大几十个工具之间逐一比选而是先定位技能域再在域内筛选合适的技能最后落到具体的原子操作上。检索路径缩短了错误率自然降低。我在实际项目中还发现一个规律技能的描述信息Skill Description质量对调用准确率的影响远大于结构本身。很多开发者会用一句话概括技能功能这在技能少的时候够用但技能多起来之后一句话描述会导致大量误匹配。我现在的做法是给每个技能写三段式描述第一段讲功能边界明确“这个技能做什么、不做什么”第二段讲适用场景列举典型任务类型第三段讲依赖关系说明需要哪些前置条件。这样模型在向量检索或关键词匹配时能拿到更充分的决策依据。1.2 确定性逻辑与模型推理的协同分工一个容易被忽略的设计原则是技能系统内部既包含确定性的代码逻辑也包含模型推理的部分两者的协同关系需要刻意设计。不要指望模型处理所有事情也不要把所有逻辑都写死到代码里。以我做过的一个数据清洗技能为例。这个技能的任务是从用户上传的 CSV 文件中完成异常值识别、缺失值处理、格式统一然后输出清洗报告。我在实现时做了明确分工缺失值统计、格式检测这类规则明确的步骤用确定性代码完成不走模型异常值判断策略、清洗方案选择这类需要语义理解的步骤才交给模型推理。这样做有三个原因。第一是成本确定性代码执行一次只要几毫秒且不消耗 Token第二是稳定规则明确的步骤交给代码执行结果永远可预期第三是质量模型资源被集中到真正需要“智能”的环节推理效果反而提升。这套分工逻辑是 agent-skills 与“全链路模型推理”方案的核心差异。2. 技能定义与注册全流程拆解明确了技能系统的设计理念之后落地实现就会顺畅很多。这部分我们进入实操阶段详细拆解一个技能从定义到注册上线的完整流程。我先说明整体步骤再逐一解释每个环节的要点和原因。整体流程包括需求梳理、技能配置编写、原子操作实现、技能注册与测试、性能评估与迭代。2.1 需求梳理从业务诉求到技能定义很多开发者一上来就写代码这是大忌。技能开发的第一步是需求梳理而且这个环节比大多数人想象的更重要。我习惯先回答四个问题这个技能要解决什么高频重复任务任务的输入输出边界在哪里哪些环节需要模型智能、哪些环节可以确定性代码完成这个技能的考核指标是什么还是拿周报技能举例。某团队反馈“每周写周报太耗时”如果直接做一个“周报生成”技能大概率满足不了需求因为“耗时”的根源可能是素材分散、格式不统一、复盘深度不够而不是“生成”这个动作本身。经过梳理后发现核心瓶颈是素材收集环节团队成员需要从聊天记录、项目管理系统、邮件三个渠道手动整理信息这个过程占了 70% 的时间。于是技能设计的重心就倾向了多源信息汇聚与自动摘要而非单纯的文本生成。需求梳理完成后输出物是一份技能需求说明主要包含任务描述、输入字段定义、输出字段定义、处理流程草案、异常场景清单。这份说明会作为后续配置编写的基础。在实际项目中需求梳理环节至少要占据整个开发周期的三分之一时间省掉这个环节后期返工的成本会成倍增加。2.2 技能配置的结构设计与字段详解技能配置是整个 agent-skills 的核心文件可以类比为技能系统的“大脑”。当前主流方案中配置文件通常采用 YAML 或 JSON 格式。我推荐 YAML因为可读性更好且天然支持注释方便团队协作时记录设计意图。一个标准的技能配置文件至少应该包含以下区块元信息、触发条件、输入输出 Schema、执行流程、依赖工具表、错误处理策略。下面我逐块说明。元信息是技能的基本档案包括技能名、版本号、所属技能域、作者和维护人。这里的版本号建议遵循语义化版本规范主版本号在技能行为发生重大变化时递增次版本号在新增能力时递增修订号用于细节修正。触发条件定义了“什么时候激活这个技能”。这里有两种模式显式触发和隐式触发。显式触发是指用户在任务描述中明确提到技能关键词比如“帮我分析这份销售数据”隐式触发是指模型根据任务上下文自动判断是否需要激活技能比如用户说“最近业绩波动有点大”模型判断可能需要数据分析和归因。隐式触发对描述质量要求更高也是技能误激活的重灾区后面我会专门讲这个问题。输入输出 Schema 定义了技能的数据契约。这里必须做到字段名、类型、必填性、约束条件完全明确。我见过很多技能上线后出现诡异 bug最后排查发现是日期字段格式不一致导致的——输入侧接收的是“2025-03-15”但内部逻辑处理的是“2025/3/15”格式。解决方案是Schema 中显式声明 format并在入口统一做数据清洗与类型转换。执行流程是技能配置中最复杂的部分它决定了技能被激活后内部逻辑如何一步一步执行。我会在下一小节单独展开。依赖工具表声明了技能运行所依赖的外部工具和内部原子操作这个表主要用于依赖管理和运行时校验。错误处理策略则是预设技能失败后的降级、重试或人工介入方案。2.3 执行流程编排DAG 与状态机执行流程编排是技能配置的灵魂。当前主流实现有两种范式基于 DAG有向无环图的编排和基于有限状态机的编排。这两种范式各有适用场景我分别说明。DAG 范式适合流程相对固定、步骤之间是并行或串联关系的技能。我在实现中通常用节点表示原子操作或模型调用用边表示数据依赖。DAG 的核心优势是天然支持并行执行——只要节点之间没有数据依赖就可以并发运行显著提升技能执行速度。数据清洗技能就利用了这点缺失值检测、格式合规检查、重复记录识别三个检测节点之间无依赖关系并行执行后总耗时从原来的 25 秒降到了 9 秒。状态机范式适合流程分支多、需要人工介入或回退操作的技能典型场景是审批流和客服工单处理。状态机的核心是定义状态和转移条件每个状态表达技能的当前阶段转移条件决定何时进入下一阶段。某团队的订单处理技能就采用了状态机设计状态包括“待审核”“审核中”“待补充信息”“已通过”“已驳回”每个状态都有明确的超时处理和升级机制。两种范式并非互斥复杂技能完全可以混用。我的经验是外层用状态机管控大阶段内层用 DAG 编排具体步骤。这样大阶段之间保持清晰的分界大阶段内部又获得足够的并行执行能力。在配置执行流程时还需要额外关注步骤之间的数据传递。建议在流程定义中显式声明每个节点的输入输出映射关系千万别依赖隐式全局变量——这个坑我踩得很深一旦技能逻辑变复杂隐式数据传递会导致排查问题极其痛苦。2.4 原子操作的实现规范原子操作是技能系统能力的基本单元对应实际执行的代码。原子操作的实现质量直接决定了技能系统的整体上限。我在实践中遵循几个原则。第一单一职责原则每个原子操作只做一件事。宁可拆细不要做大而全的功能函数。第二标准输入输出约定。所有原子操作通过统一的 context 对象接收参数通过统一的 result 对象返回结果。这个约定的意义在于后续技能编排才不需要针对不同函数写适配层。第三完备的超时和失败处理。每个原子操作必须显式声明超时时间和失败时的返回策略避免外部服务卡住导致整个技能流程挂起。以 PDF 信息抽取原子操作为例实现要点有三个。一是文件解析前先做文件类型校验——很多人只检查扩展名实际上扩展名是 .pdf 但内容可能是损坏文件或伪装的二进制文件必须读取文件头做二次校验。二是抽取过程遵循渐进策略先尝试快速文本提取文本质量不达标时切换 OCR 方案OCR 仍失败再报错转人工。三是输出结构化字段时保持字段名风格统一不要一套代码输出 snake_case、另一套输出 camelCase。原子操作的测试也很关键建议每个原子操作建立独立测试用例集覆盖正常输入、边界输入、异常输入三种情况。这一步投入的精力会在后续技能联调时数倍回报。2.5 技能注册与激活策略技能配置和原子操作实现完成后下一步就是技能注册。注册的本质是把技能纳入技能库Skill Library让系统在后续任务中能够检索到它、加载它、执行它。技能注册有两个核心问题索引方式和激活策略。索引方式决定“模型怎么找到这个技能”激活策略决定“模型什么时候调用这个技能”。索引方面现代技能系统通常采用混合索引维护关键词索引做精确匹配同时把技能描述做向量化处理配合向量数据库做语义检索。混合索引方案的优势很直接关键词索引保证高频技能能被快速命中向量检索保证未包含关键词但语义相近的描述也能召回正确技能。技能进入技能库前建议做一次描述质量检查主要看描述中是否包含足够的触发特征词、边界描述是否清晰、是否存在和其他技能描述语义重叠度高的情况。激活策略方面当前实现方案有三种规则激活、模型决策激活、混合激活。规则激活最可控——加载配置后用规则引擎判断用户请求是否匹配技能触发条件词适合高频、边界清晰的技能模型决策激活最灵活——让模型在对话上下文中自行判断是否需要使用技能适合低频、任务复杂、边界模糊的技能混合激活是折中方案——先跑规则快速筛选候选集再把候选集交给模型做最终决策。实战下来混合激活是稳定性与灵活性最均衡的方案。单纯依赖规则会出现“换一种说法就识别不了”的尴尬单纯依赖模型则会出现“不该调用的场景瞎调用”的问题还会导致 Token 消耗不可控。3. 一个完整技能的实现实录从配置到上线理论讲了不少接下来我们完整走一遍一个实际技能的上线过程。这个技能需求来自某电商运营团队的日常痛点每周需要从客服对话记录中提炼高频问题、情绪趋势和优化建议。项目的原生诉求是减少人工整理客服周报的时间。3.1 技能定版与配置文件编写需求梳理阶段我们聚焦核心场景为“客服对话周报生成”。输入是某客服平台导出的周对话记录输出是一份包含高频话题 Top 5、情绪趋势分析、问题分类统计和优化建议的 Markdown 报告。技能配置采用 YAML 格式核心结构如下skill_name: cs_weekly_report version: 1.2.0 domain: business_analysis trigger_keywords: - 客服周报 - 对话分析 - 客诉统计 input_schema: conversation_file: type: file required: true description: 客服对话导出文件支持 CSV 或 JSON 格式 time_range: type: string required: false default: last_week description: 统计时间范围 granularity: type: enum values: [day, week] default: week output_schema: report: type: markdown description: 分析报告全文 stats: type: object description: 结构化统计结果 workflow: - node: validate_input type: atomic operation: verify_file_format - node: parse_records type: atomic operation: parse_conversation_csv - node: detect_batch type: dag parallel: - node: topic_extraction type: model prompt_template: templates/topic_extraction.md - node: sentiment_analysis type: model prompt_template: templates/sentiment_analysis.md - node: category_classification type: model prompt_template: templates/classification.md - node: merge_results type: atomic operation: merge_detection_results - node: gen_report type: model prompt_template: templates/report_generation.md error_handling: - error: FILE_FORMAT_INVALID action: return_user_message message: 文件格式不支持请上传 CSV 或 JSON 文件 - error: ANALYSIS_FAILED action: retry_once_then_fallback fallback: rule_based_analysis注意 workflow 中的 detect_batch 节点使用了 DAG 并行编排topic_extraction、sentiment_analysis、category_classification 三个模型节点互不依赖可并发执行。这一步在效果上缩短了整体响应时间也为我后续做并发改造提供了示例基础。3.2 prompt_template 的分类设计技能配置文件里引用的三个 prompt_template是技能智能水平的直接决定因素。我最初的版本把三个任务合并在一个大 prompt 里结果话题情绪分类混在一起输出质量波动很大。后来拆成三个独立模板每个模板专注一个子任务效果立刻改善。以情绪分析模板为例核心设计理念是“给模型一个分析框架而不是让它自由发挥”。模板结构包含四块任务定义、输入格式、输出格式、分析原则。分析原则部分会显式约束模型的判断标准比如“负面情绪判定需结合具体表述而非仅看关键词”“每条对话至少给出一个情绪标签情绪不明确时标注为中性”。这种约束显著提升了标签一致性。模板中还会预设 few-shot 示例。实操发现示例数量控制在 3 到 5 个效果最好太少模型抓不住模式太多不仅增加 Token 消耗还可能让模型“过度模仿”示例中的边缘情况。每个示例都刻意选择典型场景覆盖正常、异常和边界三类情况。3.3 技能运行上下文与状态管理技能启动后运行时上下文Runtime Context贯穿整个执行过程。我在设计中定义了一个上下文对象包含输入数据、中间结果、配置信息、日志句柄四类内容。每个节点执行时从上下文读取输入处理后再写入上下文节点之间不直接通信只依赖这个共享状态。这种设计的优势在排查问题时体现得非常明显只要在每个节点执行完毕后 dump 关键状态实战中遇到的大部分问题都能快速定位到具体环节。上下文还需要管理 Token 使用量和累计耗时两个监控指标便于及时返回阶段性结果。状态管理的另一个关键环节是“可中断可恢复”支持。长任务技能运行中可能遇到外部依赖超时或用户主动中断如果没有状态持久化设计技能就要从头执行。我的方案是为技能运行打上快照节点执行完成后将当前状态序列化存储一旦中断可以在最近完成的节点处续跑。这个能力初期可以不做但做长耗时项目的团队建议尽早纳入架构。3.4 上线前的评测集构建与指标评估技能上线前必须经过系统评测否则就是拿生产环境当测试场。评测这块我强烈建议构建固定评测集。具体做法是收集 30 到 50 条真实历史任务作为基准样本每条任务记录标准答案。这份评测集要长期维护每次代码变更都跑一遍才能确认技能行为“没变差”。评测指标分为客观指标和主观指标。客观指标包含任务完成率、平均响应时间、Token 消耗量、配置加载失败率、模型调用失败率。主观指标包含输出准确度、步骤合理性、异常处理质量。主观指标无法全自动判断我在实践中的做法是设计打分卡由人在评测集上按 1 到 5 分打分定期取平均分跟踪走势。这个技能从初版到稳定版经历了多轮评测迭代。首轮评测中任务完成率只有 68%主要失败场景有两个日期范围识别错误——用户传入“上周”时模型偶发理解成“本周”文件编码识别错误——部分 CSV 文件不是 UTF-8 编码导致解析失败。针对这两个问题我在输入解析环节增加了日期归一化和编码自动检测能力两个月后任务完成率稳定在 94% 左右。4. 实测过程中最常见的 7 类问题与排查手册技能系统上线后真正的挑战才开始。生产环境的复杂程度远超开发环境各种意料之外的情况层出不穷。这里我把实战中高频出现的 7 类问题整理成排查手册每类都给出典型症状、排查路径和解决方案供大家直接参考。4.1 技能误激活与漏激活症状用户没说相关需求但技能被激活执行了或者用户明确表达了需求技能却没被触发。排查路径先检查触发关键词的覆盖情况再看技能描述与其他技能的语义重叠度。误激活通常是描述边界不清晰所致。漏激活则往往是因为触发词和实际表达差异过大。解决方案核心思路是收敛和扩展。收敛是指明确技能的边界条件在描述中显式加上“非…场景不需要使用本技能”扩展是指丰富触发特征词尤其补充行业术语和口语化表达。4.2 执行流程状态卡死症状技能在某个节点长时间无响应既不报错也不继续执行最终整体超时。排查路径优先查看日志中该节点是否返回了结果查看外部依赖服务是否超时再检查该节点的错误处理策略是否配置了 fallback。解决方案给每个节点配置独立的超时时间同时实现全局兜底超时。单个节点超时后按预设策略选择重试、跳过或整体失败。我最后常被调用到的方案是前序遍历式超时检查——每 5 秒扫描一次所有在跑节点的执行时长最早恢复秩序的方法反而是最简单的方法。4.3 输出格式不稳定症状同一个技能在不同批次任务中输出结果时而是 Markdown 表格时而是列表时而是纯文本段落。排查路径检查 prompt 模板中输出格式约束是否足够刚性检查解析层是否存在容错逻辑。解决方案在 prompt 模板中增加格式化约束段明确“输出必须符合以下结构不得增删改字段”。同时增加结构校验层用代码对模型输出做二次检查不合规时触发自动修正逻辑比如让模型重新生成一次或做规则化清洗。4.4 Token 消耗失控症状技能执行一次消耗的 Token 远超预期成本直线上升。排查路径定位耗时最多、消耗最大的节点。常见原因有三个上下文过多重复传递、模型输入包含大量无效历史信息、某个步骤的输出被后续步骤全量复用。解决方案优化上下文管理每步只传必要字段适时截断历史信息只保留关键摘要为各节点设置 Token 护栏和熔断预算预算耗尽时自动停止提问或降级到低成本模型。4.5 技能间能力重叠导致冲突症状多个技能可以处理同一类任务模型挑选了不合适的那个导致结果偏差。排查路径在评测集中分析误匹配案例检查这些技能的描述是否高度相似或重叠。解决方案做技能能力边界收敛包括调整描述使各自边界更清晰、在优先级高的技能描述中强调“优先选用”、或干脆合并技能降低重叠度。我维护技能库时有一条经验法则两个技能若在超过 30% 的任务场景下可互换那么就值得考虑是否该合并成一个技能。4.6 外部依赖变动导致技能失效症状技能原本运行正常某天突然大面积报错且错误信息指向外部接口或第三方库。排查路径检查外部接口的版本变更或响应结构变化检查第三方库是否被升级到不兼容版本。解决方案建立依赖版本锁机制。外部接口调用层统一封装做好结构校验和字段兼容映射第三方库锁定精确版本升级前在评测集上完整回归。这个习惯救过我多次也建议团队尽早建立依赖变更通知机制。4.7 新技能影响已有技能症状新技能上线后某个原本稳定的旧技能开始出现异常或调用频次下降。排查路径这是一个非常隐蔽的问题根源大概率是检索阶段结果被新技能干扰——新技能的高相关度描述把本该属于旧技能的请求截走了。解决方案新技能上线前在评测集上对全量技能库做一次回归评估不只测新技能本身还要关注“确认新技能的加入不改变旧技能的行为”。此外给核心技能增加调用约束条件比如必须是特定技能域下的请求才可触发可以抑制部分干扰。5. 技能系统架构演进的三个经验视角走到这里一个可用、稳定的技能系统已经搭建完成。但真实工程场景中技术选型从来不是一次定终身而是随着业务复杂度上升不断演进。这一节分享几个架构层面的经验视角属于更高维度的“为什么这么设计”。5.1 从单技能到技能库再到技能市场初建技能系统时一般都是一两个技能打天下。这时候重点是怎么把单个技能做深做透。技能数量到两位数之后重心就要转向技能库的治理新增复用、去重、版本管理、依赖关系可视化。再往后团队内部或社区之间会产生技能交换的需求这时候就会自然走向“技能市场”形态本质是技能分发的结构化通道包括技能包封装、校验、发布、订阅、评价机制。如果你所在团队规划阶段建议从一开始就定义清晰的技能包格式和版本规范否则后续批量迁移成本极高。5.2 模型选型动态化技能系统与模型的耦合程度是另一个重要决策点。我见过两种极端方案一种是一个模型打到底所有技能内的模型调用都用同一个模型另一种是为每个技能绑定一个专用模型追求极致效果。这两种方案各有取舍。统一模型的优势是成本可控、管理简单劣势是效果上限受限专用模型的优势是效果可定制劣势是成本高、维护负担重。演进过程中的平衡做法是建立模型路由层对每个技能根据任务复杂度或输入信息量动态选择模型。简单任务用轻量模型复杂任务切到更强模型整体性价比最高。5.3 自评价与持续学习机制技能上线初期效果未必最优这个阶段不能急着优化 prompt 或调整参数先跑一段时间积累真实调用数据和失败案例。基于真实反馈做迭代远好于闭门造车式的猜测。具体操作上可以给技能建立自评价机制每个任务执行完毕后记录结果评价分数定期汇总失败模式将有共性的问题反馈到技能配置和原子操作层面。这样技能会像滚雪球一样越用越熟练——这个“持续学习”的能力是 agent-skills 区别于静态工具链的根本所在。我在一次踩坑中体会尤其明显我精心设计了一版包含 16 个分支条件的流程配置以为能全面覆盖各类情况上线后失败率却居高不下。后来通过失败案例分析发现真正的问题场景只有 3 大类而 16 个分支里大部分几乎没被走到。后来我砍掉了冗余分支聚焦真实问题的处理逻辑稳定性反而大幅提升。数据驱动迭代永远是效果优化的第一性原则。6. 最后分享几个核心建议agent-skills 的概念本身不复杂核心是“结构化沉淀、系统化复用、持续迭代演进”这三件事。如果你正准备在自己的项目里引入技能系统这几条建议希望你记住。第一别为了技能系统而技能系统。技能系统是解决重复性、专业性任务效率与质量问题的工具如果你的项目只有一次性任务收益可能不明显。先把高频场景列出来再决定哪些适合技能化。第二先跑通最小的闭环再扩展技能数量。哪怕只是一个技能的完整流程从需求到上线跑通也比十个半成品技能更有价值。技能系统的工程复杂度是线性增长的而稳定性挑战往往是指数增长的小步快跑最稳。第三持续维护评测集和失败案例库。这两份资产决定了技能系统的迭代速度和质量上限。没有评测集你无法量化“改动到底变好还是变坏”没有失败案例库你的优化都是盲人摸象。第四保持对新技术方案的敏感但不要盲目追新。agent-skills 相关的方法论仍在高速演进今天的最优实践明天可能就过时。成熟团队的做法通常是核心逻辑保守稳妥外围能力持续小规模验证新技术。技能系统的打磨没有终点它更像一个跟着业务一起成长的生命体。我现在维护的技能库已经运行了大半年每一轮迭代都建立在真实数据和失败反馈之上效果也确实在使用中越变越好。希望这篇总结能帮你避开早期阶段那些不必要的坑在 agent-skills 这条路上走得更顺畅。