先说明一下背景。过去大半年我一直在折腾各种Agent项目，从早期的纯提示词工程，到接各种工具调用，再到最近半年开始认真研究并落地了一套自建的agent-skills体系。中间踩过的坑、推翻重来的次数，比过去三年写业务代码加起来还多。今天不聊那些花里胡哨的概念包装，就纯粹把我在实际项目里怎么设计、怎么搭建、怎么踩坑又怎么修复的过程完完整整拆给你看。
如果你手头也有一个或多个AI Agent项目，正被"提示词越写越长但效果越来越不稳""换个输入形式就翻车""同一个操作逻辑换个场景全部重写"这类问题困扰，这篇文章应该能给你一套可以直接上手的解法。
1. 先搞清楚：Agent缺的从来不是"聪明"，而是"可复用的手艺"
1.1 提示词堆砌的终点：一个真实的失控现场
三个月前我接了一个内部工具项目：做一个能自动整理项目周报的Agent。需求听起来很简单——把团队群里零散的周报信息收集起来，按照固定模板输出一份Markdown周报。
我早期做法和大多数人一样，把要求全写在系统提示词里：你要提取每个人的任务、你要判断任务状态、你要分类优先级、你要总结风险点、你输出的格式必须是……前前后后写了三千多字。测试当天效果惊人，样例数据全过。
然后就翻车了。同事把周报从"微信聊天记录"换成"飞书文档截图"，Agent直接懵了，提取逻辑全乱套。再换成"语音转文字稿"，输出格式又变了。我花了大量时间在提示词里补充各种输入形态的可能性，每加一种场景，提示词就变厚一层，而每变厚一层，其他场景的准确率就掉一截。到最后，那个Agent变成了一坨碰不得的代码——改一行，崩三处。
这段经历让我彻底明白了一个道理：你把"怎么做"写进提示词，Agent只是在"背诵"；你把"怎么做"封装成技能，Agent才开始"掌握"。
1.2 技能的本质：把"方法"从"指令"里剥离出来
后来我重新设计这个周报Agent，不再往提示词里堆细节，而是换了一种组织方式：把"整理周报"这件事拆成几个独立的技能，每个技能负责一个环节——信息抽取、任务去重、优先级判断、Markdown格式化。每个技能内部有自己完整的操作方法、参考样例、处理规则，Agent碰到对应场景时再把这套"手艺"调用出来。
打个比方你就明白了。普通提示词式Agent，像你给实习生交代任务："你去把这份文件处理一下，注意格式要好看，数据要准确，别漏了重点……"——他听得懂，但遇到具体细节全靠临场发挥。技能式Agent，像你给实习生一本工作手册："处理文件之前，先看第一章的格式规范，再翻第二章的数据校验清单，最后按第三章的模板输出。"——他不光听懂了任务，还知道该调哪套标准动作。
所以我对技能的定义就一句话：技能是围绕某一类具体任务，预先组织和验证过的：输入识别方式、执行步骤、输出范式，以及用到的工具与参考样例的完整封装。
它和工具调用（Function Calling）的区别在于：工具是"手"，技能是"手 + 方法 + 经验"。Agent调用一个天气API，那是工具；Agent拿到一段会议录音后知道该先分段、再转写、再按发言人归并、最后生成摘要，那是一整套技能。
1.3 什么任务才值得做技能？先用这四个标准卡一遍
不是所有任务都值得做成技能。我踩过不少"盲目技能化"的坑，最后总结出一个判断标准，基本上四条全中的任务才值得做：
- 高频：这活儿Agent每周、每天都可能碰到。一辈子碰不到一次的任务，写成技能是纯浪费。
- 可复现：同样的输入，预期的产出相对稳定，不是那种"这次这么写、下次那么写都行"的开放式任务。
- 有明确产出物：最后的结果是一份文档、一段代码、一张表格这类能检验的东西。纯闲聊没资格做技能。
- 有判断基准：你能说清楚什么算好、什么算差，否则后面评测迭代无从谈起。
我那周的"输入形态多变导致崩溃"的周报整理任务，完美命中这四条：每周都做、产出物固定为Markdown周报、格式好坏一眼可判。唯一难的是"可复现"——输入来源太杂。但实际情况是，输入形态杂不等于方法不能统一：只要把"是否属于周报内容"和"怎么提取"分开来处理，底层方法是可以稳定的。
2. 技能库的模块设计：让Agent看得懂、用得对、学得会
2.1 一个技能 = 一个目录 + 一份SKILL.md + 若干资源文件
先上一份我现在在用的标准技能目录结构。整套基于文件系统来组织，因为文件比数据库更透明，Git可以做版本管理，随时能diff谁改了什么。
agent-skills/ ├── README.md # 技能库总览与设计约定 ├── _shared/ # 跨技能复用的共享资源 │ ├── templates/ # 输出模板 │ └── tools/ # 公共脚本或工具封装 └── skills/ ├── weekly-report/ # 技能根目录，名字就是技能ID │ ├── SKILL.md # 技能的元信息与执行说明（核心文件） │ ├── scripts/ # 可选的辅助脚本 │ │ ├── parse_input.py │ │ └── validate_output.py │ ├── examples/ # 参考样例（Few-shot） │ │ ├── success_case_1.md │ │ └── failure_case_1.md │ └── assets/ # 模板、字典等静态资源 └── meeting-minutes/ ├── SKILL.md ├── scripts/ └── examples/1.2 SKILL.md的灵魂：description就是Agent的"记忆索引"
SKILL.md是每个技能的核心，里面记录了这个技能的元信息、适用条件、操作步骤、资源文件和注意事项。整个文件最关键的其实是开头的YAML front matter，尤其是description字段。
为什么这么说？因为Agent面对一个任务时，不会把所有技能的SKILL.md都读一遍——那是巨大的上下文浪费。它在主对话里会先根据当前场景，去检索技能库的描述索引，决定该调用哪个技能。description写得像没写，Agent就想不起这个技能；description写得有偏差，Agent就会在错误的场景调错技能。
我见过写得很差的description，长这样：
name: weekly-report description: 整理周报。这种描述等于没有。Agent面对"同事发来一段语音转写稿要我整理"时，根本不会把"整理周报"和"语音转写稿"关联起来。
我现在的写法是：
name: weekly-report description: >- 当用户需要把零散的团队工作信息整理成结构化周报时使用。适用输入包括： 聊天记录（微信群/钉钉/飞书）、会议纪要文本、语音转文字稿、项目看板条目。 不适用于：生成新周报（无素材时）、为单个人写个人总结报告。 输出为固定Markdown模板，包含任务列表、风险项、下周计划三个区块。前后的差别在于：后者不仅告诉Agent这个技能"是什么"，还告诉了它"什么时候该想起这个技能""什么时候不该用"。**触发条件的正例和反例都写清楚，召回准确率会显著提升。**这个字段是技能库设计里性价比最高的投入，我基本会花整个SKILL.md三分之一的时间来打磨description。
2.3 SKILL.md内的三段式结构：输入识别、执行流程、输出约束
SKILL.md的内文我建议固定成三段结构，不要自由发挥——标准化是为了让Agent稳定理解，也是为了让你自己维护时不用每次重新猜结构。
--- name: weekly-report description: >- ... version: 1.2.0 tags: [report, weekly, team] --- # 周报整理技能 ## 1. 输入识别 - 允许的输入形态：聊天记录原文、会议纪要、语音转写文本、看板导出 - 关键字段标记：任务描述、负责人、截止时间、状态 - 禁止输入：纯闲聊内容、与团队工作无关的信息 ## 2. 执行流程 1. 用 scripts/parse_input.py 将输入文本切分为"有效工作信息"和"噪音" 2. 对有效信息逐条抽取：任务描述、负责人、截止时间、状态（进行中/已完成/阻塞） 3. 对任务进行去重：相同任务以最新一条状态为准 4. 识别阻塞项和高风险项，填入风险区块 5. 调用 assets/template.md，生成最终周报 ## 3. 输出约束 - 必须使用 assets/template.md 的格式，不得自创模板 - 输出语言：中文 - 长度范围：200-500字 - 不做推测：素材中未提到的信息不得自行补充这样一份SKILL.md，Agent拿到之后可以按图索骥地执行，不会"觉得自己做完了"而实际上漏了校验步骤。顺便说一句，"输出约束"这一节很多人会漏掉，但它恰恰是决定产出稳定性的关键。Agent默认倾向自由发挥，你不在文件里写明"必须用模板""不许推测"，它就会给你加点它自己脑补的内容，看着没问题，实际上已经偏离了预期。
3. 手把手搭第一个真实技能：把"周报整理"变成Agent的肌肉记忆
3.1 选场景：为什么拿周报开刀最合适
纸上谈兵没意思，下面我带你完整走一遍第一个技能的搭建流程。就以我前面反复提到的周报整理为例。
选它当第一个技能的原因很简单：它高频、有明确产出物、结果可校验、而且失败模式清晰。对于第一次搭技能库的人来说，这几点决定了你后面迭代时有抓手，不会陷入"也不知道写好没写好"的混沌状态。
另外周报是一个复合型技能，它内部包含了信息抽取、分类、去重、格式化等多个子环节，把这个技能打磨透，你对技能设计的大部分要点就都过了一遍。
3.2 从零写一个可用的SKILL.md：逐段拆解
下面是我为"周报整理"技能写的SKILL.md实际内容，我逐段说明为什么这么写。
--- name: weekly-report description: >- 当用户需要把零散的团队工作信息整理成结构化周报时使用。适用输入包括： 聊天记录（微信群/钉钉/飞书）、会议纪要文本、语音转文字稿、项目看板条目。 不适用于：生成新周报（无素材时）、为单个人写个人总结报告。 输出为固定Markdown模板，包含任务列表、风险项、下周计划三个区块。 version: 1.2.0 tags: [report, weekly, team] --- # 周报整理技能 ## 1. 输入识别 接受以下输入形态： - 多人聊天记录的纯文本导出，格式不限，但需要包含发言人标识或上下文可推断归属 - 会议纪要文本，包含讨论事项、负责人、结论 - 语音助手转写后的文本稿（可能含重复、语气词、口语化表达） - 项目看板导出（任务卡片列表） 每个输入的第一处理步骤统一执行：`python scripts/parse_input.py < input.txt`，脚本会做三件事： 1. 按行切分并过滤噪音行（表情、纯语气词、广告） 2. 识别潜在的任务描述行，输出候选句列表 3. 统计输入中的负责人出现次数，用于归属推断 ## 2. 执行流程 1. 运行 parse_input.py，获得候选句与负责人列表 2. 对每条候选句，判断是否为有效工作信息（判断准则：包含动作动词 / 包含具体交付物 / 包含时间节点；三者至少满足两者） 3. 抽取字段： - task: 任务描述（保留不超过30字） - owner: 负责人（聊天记录中出现的人名或代词对应的角色） - deadline: 截止时间（如有；没有则标注"未明确"） - status: 进行中 / 已完成 / 阻塞（依据上下文判断；语气词如"搞定""完了"映射为已完成） 4. 任务去重：合并描述相似度超过0.85的任务对，保留后出现且信息更完整的一条 5. 风险识别：status=阻塞 或 距截止只剩2天且状态仍为进行中 的任务，列入风险区块 6. 渲染模板 assets/template.md，填充三个区块 ## 3. 输出约束 - 严格使用 assets/template.md 中规定的Markdown结构 - 不得添加素材中不存在的负责人和任务 - 若输入为空或没有有效工作信息，直接输出"本周无有效工作信息可整理" - 不输出分析过程，只输出最终周报你可能注意到了，我在输入识别环节放了一个真实脚本的调用入口。**当规则比较机械（行切分、候选句识别）时，与其让LLM凭感觉做，不如交给一个确定性脚本把候选集压缩到一个很小的范围内，再由LLM做语义判断。**LLM擅长的是模糊匹配和语义理解，不擅长的是逐行翻几千行文本不遗漏——明确分工才能扬长避短。
执行流程里我特别写了第2步的"判断准则"和第4步的"相似度阈值"——这些量化标准看着不起眼，但它们是Agent执行稳定性的锚点。没有量化准则，Agent的判断就会有较大的随机性，今天觉得这句是任务，明天觉得不是，输出就上下飘忽。
3.3 喂参考样例：不是越多越好，而是"成功 + 失败"成对喂
很多人在技能里堆一大堆成功案例，以为Few-shot越多越准。我的实测结论是：成功案例3个以内足够了，更重要的是每个成功案例配1个失败案例。
失败案例的价值在于"圈定边界"。比如我给周报技能放了一个失败样例：输入是"今天天气真不错，大家周末愉快"，期望输出是"本周无有效工作信息可整理"。Agent看了这个样例之后，面对闲聊输入时就不会强行提炼出"工作信息"。
成功案例的选取也有讲究。不要全放理想化的整齐输入，至少留一个案例输入是带口语化、带错别字、带重复内容的语音转写稿，让Agent学会"真实世界的输入长什么样"。
目录结构就像这样：
examples/ ├── success_case_1.md # 标准聊天记录输入 + 标准周报输出 ├── success_case_2.md # 语音转写稿（含语气词、重复句） + 标准周报输出 ├── failure_case_1.md # 纯闲聊输入 + "无有效信息"输出 └── failure_case_2.md # 单条不完整信息 + "信息不足需补充"输出3.4 接入主Agent：声明加载、触发调用、拿到结果
技能文件写好之后，还需要让它能被主Agent加载和调用。目前主流做法是在主Agent的配置里声明技能库地址，加载器会读取所有SKILL.md的描述索引，形成一个技能清单。当主对话产生新消息时，系统根据消息内容与技能描述做向量检索或关键词匹配，选出可能相关的Top-N技能，把它们的完整SKILL.md内容注入上下文，Agent读完SKILL.md后决定是否采用。
这个过程有一个必须注意的性能点：不要每次对话都把所有技能的完整SKILL.md注入上下文。几十个技能文件全部塞进去，几千上万tokens的上下文就没了，主Agent反而"消化不良"。正确做法是两步走：先只注入技能描述列表（轻量索引，几十个技能也就几百tokens），命中之后再注入对应技能全文。
我当时接入后的主Agent配置大概是这样的：
agent: skill_library_path: ./agent-skills/skills skill_index_enabled: true skill_selection_mode: auto # 可选：manual / auto / hybrid max_skills_to_load: 3 skill_injection_threshold: 0.6 # 相关度阈值，低于则不注入max_skills_to_load: 3是我调出来的合理值。一次加载超过3个技能，主Agent的处理质量反而下降——它会在多个技能之间摇摆，不知道该按哪个来。如果你发现某些任务确实需要多个技能配合，那是"上层任务编排"的问题，不应该靠"一次性全量加载技能"来解决，而是应该再设计一个更高层的编排技能来依次调用子技能。
4. 技能评测与迭代：像给同事做代码评审那样打磨技能
4.1 不能靠"感觉好用"，必须建回归测试集
技能写出来只是起点，真正让它从"能用"变成"可靠"，靠的是评测和迭代。而评测的第一前提，是有一套稳定的回归测试集。
我给周报技能建的回归测试集大概长这样：
| 用例编号 | 输入类型 | 输入特征 | 期望输出 | 评判要点 |
|---|---|---|---|---|
| WR-001 | 聊天记录 | 5人对话，3条有效任务，1条闲聊 | 3条任务，无闲聊混入 | 精确率：不产出多余任务 |
| WR-002 | 语音转写 | 含语气词、重复、结巴 | 转写内容被正常处理 | 召回率：不遗漏真实任务 |
| WR-003 | 混合输入 | 聊天 + 看板导出混合 | 去重后输出 | 综合去重效果 |
| WR-004 | 纯闲聊 | 无任何工作信息 | "无有效信息" | 拒绝率：不强行编造 |
| WR-005 | 含有阻塞项 | 任务卡在阻塞状态 | 风险区包含该任务 | 风险识别准确率 |
这套测试集里的用例，部分是当初让我翻车的真实输入，部分是构造的边界情况。建议把历史翻车输入全部整理进回归集，这是最有价值的资产。
评测方式我建议分两层：第一层是机器可判的客观指标（有没有用模板、有没有产出预期区块、有没有包含"无有效信息"字样），这些可以写成脚本自动跑；第二层是需要人工看的语义指标（任务抽取是否准确、风险判断是否合理），这些我每次迭代后会自己过一遍前十来个用例。两层都过了，再放出去跑真实数据。
4.2 最常见的三个失败模式：偏、漏、编
迭代的过程中会遇到各种失败，总结下来大多数跑不出这三个模式：
失败模式一：偏（检索到了但理解偏了）。症状是Agent加载了技能，但没有按技能执行流程走，自由发挥。排查方向：SKILL.md的执行步骤写得不够"命令化"，建议把每一步都写成祈使句，像"必须执行""不得跳过"这种强制性措辞比"建议执行"要管用得多。
失败模式二：漏（执行到一半"觉得自己做完了"）。症状是跳过中间步骤直接输出结果。这是LLM的常见毛病，尤其跳过的往往是有脚本校验的那一步。修复方法：在输出约束里明确写"未经脚本checksum校验禁止输出最终结果"，同时把校验失败时的兜底输出也写出来。
失败模式三：编（输出了素材中不存在的内容）。症状是Agent补全了没有提到的任务或负责人。这类问题靠提示几乎无解，最稳定的是在脚本层把守住：让脚本先跑一遍识别出素材中的实体清单，LLM的抽取值必须在这个清单内，不在清单内则丢弃。用确定性的代码给Agent的幻觉上锁。
4.3 迭代节奏：一次只改一个变量
迭代技能最忌讳的是"一次改五处，效果好了也不知道是哪处的功劳，效果差了也不知道哪处帮了倒忙"。
我自己执行的原则是：一次只改一个变量，小步快跑。比如这轮测试完WR-003去重效果不好，那这轮只调整去重的相似度阈值（从0.85调到0.8），其他一律不动，跑完回归集看结果。确定这次改动有效，再进入下一轮的修改。
另外要给技能文件标注正确的版本号，并在SKILL.md里更新改动日志。这里不多说，细节放到后面踩坑章节统一讲。
5. 实战中踩过的坑：五个反直觉的教训
5.1 技能不是越多越好：数量超过某个阈值后，召回质量会崩
早期我有一股"万物皆可技能"的热情，把代码审查、文档润色、周报总结、会议纪要、邮件回复、SQL生成……一股脑全建了技能。两个多月攒了五十几个，然后发现主Agent的选择开始飘了。
原因在于：技能选择本质上是在"技能描述索引"里做匹配。技能多了，description之间会有概念重叠和语义竞争。比如"会议纪要"和"周报整理"在description里都提到了"会议""任务""负责人"这些词，Agent面对一段会议记录时，就可能在两个技能之间犹豫，甚至把两个技能都加载进来，互相干扰。
踩过这个坑之后，我给技能库立了两条规矩：
- 新技能入库前，先检索现有技能库，如果已有技能能从它的description覆盖场景，就不新建，而是扩展现有技能。
- 每个技能description里必须写明"不适用于哪些场景"，人为切分边界，减少语义竞争。
如果你发现技能数量已经超过四十个而且召回的准确率开始下降，建议不要急着精简具体技能，先检查是不是一批技能的description写得边界模糊——把边界写清楚，通常就能解决大部分问题。
5.2 技能里的"默认值"会悄悄污染上下文
有段时间我的技能SKILL.md里写了不少默认设置，比如"输出格式使用默认模板""超时时间默认5分钟"。一点小改动，但对Agent来说，"默认"这个词是个大坑——Agent不知道你说的默认是指"看assets里的模板文件"还是"它脑子里那个默认"。
实测中，写着"默认模板"的技能，Agent有较大概率直接按它对Markdown的通用理解输出，完全不去读template.md文件。修复方式很简单：删掉一切"默认"措辞，改成具体的指向——"输出格式必须使用 assets/template.md 中定义的模板，不得使用其他格式"。含糊的表述是Agent自由发挥的入口，给它的输入越具体，它的发散空间越小。
5.3 模型升级后技能突然"退化"，先查的不是逻辑而是措辞
一次比较大的模型版本升级后，我的好几个技能效果同时变差了。当时的第一个念头是技能逻辑过时了，准备大改。后来冷静下来，把回归测试集跑了一遍，发现一个规律：纯粹依赖语义判断的环节出错变多，而依赖脚本和明确模板的环节一切正常。
原因后来想明白了：模型升级后对措辞的敏感度会变化。原来对"判断是否为有效工作信息"这个指令执行良好的表述，新版模型的理解产生了偏移。**解决方法不是在逻辑层面推翻重写，而是把原本纯语义判断的环节，改成"脚本预筛 + LLM复核"两步式。**先在脚本层用关键词规则缩小候选集，再用LLM对缩小后的集合做语义判断。这样即使模型对措辞的理解有漂移，由于候选集已经被卡得很小，最终结果也不会跑偏太多。
5.4 技能间的边界：谁负责"理解"，谁负责"执行"
一个常见的错误是把技能做成"大而全"。比如我刚开始做的周报技能，内部既做信息提取，又做格式排版，还想兼职判断风险等级。结果就是SPoE明显：一个环节出错，整个技能都不可用，且很难定位哪里错了。
后来我把周报场景拆成了一个技能组：信息抽取技能（只负责把素材变成结构化字段）、风险判断技能（接收结构化字段，输出风险标注）、周报渲染技能（接收结构化数据，渲染成Markdown）。各干各的，职责单一，哪个环节出问题就修哪个技能。
这样拆完一个看得见的好处是：技能可以组合复用。信息抽取技能不光服务周报，会议室纪要用它，甚至项目复盘也能用它。这就是技能库从"一堆一次性工具"走向"可组合模块"的关键一步。
5.5 版本管理与回滚：技能也会被"写坏"
你以为只有代码需要版本管理？技能同样需要。有一次我在优化"风险判断"技能的描述措辞时，顺手改了description里一个触发关键词，结果直接导致该技能在几乎所有场景下都不再被召回。还好技能库整个放在Git仓库里，一条git revert就把改动回滚了，前后损失不过半小时。
从那以后我养成几个习惯，你可以直接拿去用：
- 每个技能独立目录、独立版本号，SKILL.md里带
version字段和changelog小节 - 任何对SKILL.md的描述字段改动，必须跑一遍完整回归集再提交
- 技能目录整个纳入Git管理，每次改动一个commit，commit message写明"改了什么+为什么改"
- description字段的改动和正文字段的改动分开提交，因为前者影响召回，后者影响执行
这套习惯看起来繁琐，但在技能数量上来之后，它帮你节省的排查时间远超维护成本。
6. 从个人技能库到团队共享技能库，再往前一步
6.1 团队协作时的技能评审
搞定了个人使用的技能库之后，我自然想到让团队其他人也能用上这套东西。但共享之后发现，每个人的使用反馈，直接决定技能是否需要调整。同事在周报技能上反馈"某个任务状态总变成阻塞，但他觉得应该是进行中"——这其实是风险判断规则在特定业务语境下产生了偏差。
团队协作时我的做法是：每个技能目录里加一个FEEDBACK.md，使用方遇到问题直接把真实输入和期望输出贴进来。迭代者每个月集中处理一轮反馈，把高频问题沉淀进新测试用例，再针对性修改技能。技能不是"写一次用三年"的东西，它更像是活文档，需要持续喂养。
6.2 技能的可测试性，决定了这玩意儿能走多远
技能库发展到后来，最大的瓶颈一定不是模型的聪明程度，而是你的回归测试集覆盖度。一个没有测试集的技能库，改起来心都是虚的——你根本不知道一次改动是把准确率提高了3个点还是埋了一个大雷。
我有一次调整周报技能的"相似度去重阈值"从0.85降到0.8，初衷是希望更多重复任务被合并掉，结果回归测试集里WR-003的精确率立刻掉了。要不是有这套测试集，这个副作用放到真实使用中去，可能很久都不会被发现，等到发现时用户信任已经消耗得差不多了。
所以如果你问我做技能库最值得投入的事情是什么，我的回答是：不是花时间雕琢SKILL.md的措辞，而是花时间沉淀一套扎实的回归测试集。前者是术，后者是道。
6.3 个人体会：技能库是Agent工程从"个体户"走向"工业化"的分水岭
最后聊点实际的个人感受。
我看过很多Agent项目，从demo到落地之间隔着一道天堑。demo阶段靠提示词工程还能撑住，一旦进入真实场景，各种边界情况如潮水般涌来，这时候还在靠堆提示词，就像踢足球只靠一个前锋全场单干——前锋再强也要累死。技能库这套思路之所以值钱，本质上是因为它把"经验"从"对话上下文"里搬到了"可持久化、可版本化、可评测、可复用的独立模块"。
当前阶段我给这套体系定的目标是：每个技能在放入库之前，必须让它在回归测试集上的结果达到我能接受的基线——这条基线本身也在不断抬高：从"样例通过"到"回归集通过"再到"真实场景新用例连续两周稳定"。整个过程像滚雪球，测试集越厚，技能越稳，技能越稳，就越敢接入更复杂的场景。
如果你也准备开始搭自己的agent-skills，我的建议是：别一上来就规划一个大而全的技能库，先挑一个你手头每天都碰、且结果可校验的任务，按照这篇文章的流程把它做成第一个技能，建好它的回归集，然后跑两个月再说。等这个技能真的稳了，你自然就知道下一步该往哪个方向扩了。
