图解Skill读书笔记（五）：多Skill协同工作与子智能体
从读书笔记流程出发，理解为什么不要把多个需求塞进一个万能Skill，以及如何通过拆分、串联、并行和子智能体协同完成复杂任务。
本文为原创学习笔记，记录本人阅读、思考和实际使用后的理解。不同平台对 Skill、工作流和子智能体的支持方式可能不同，文中的做法需要结合具体工具验证。 转载请注明作者及原文链接；未经许可，请勿用于商业转载。
学习目标
上一篇笔记里，我尝试把读书笔记流程拆成了三个 Skill：先提取要点，再润色语言，最后导出文档。这样做以后，流程比一开始清楚了很多，但新的问题也出现了。
如果每个 Skill 都要我手动把结果复制给下一个 Skill，那么每次整理笔记都要人工接力，还是有些麻烦。再往前想一步，如果以后不是写读书笔记，而是写汇报材料、会议纪要、复盘记录，这套流程还能不能复用？
这篇笔记主要想解决三个问题：
- 为什么不建议把所有规则都塞进一个万能 Skill；
- 怎样从一个具体 Skill 中提取更通用的小 Skill；
- 串联、并行和子智能体分别适合什么场景。
一、不要试图做万能的Skill
刚开始学 Skill 时，我也很容易产生一个想法：既然三个 Skill 串起来麻烦，那干脆把它们合成一个不就行了吗？
这个想法看起来很省事，但真正用起来会发现问题不少。一个万能 Skill 里如果同时包含要点提取、错误检查、语言润色、格式导出、文件保存等规则，说明会变得很长，职责也会变得很模糊。
职责一模糊，后面就会出现几个问题：
- 哪一步出错了，不容易定位；
- 只想用其中一个能力时，也要加载整套规则；
- 修改某个小规则时，可能影响整个流程；
- 换到会议纪要、周报、产品文档等场景时，复用起来不够灵活；
- 多个任务挤在一起，容易占用更多上下文。
所以，一个好用的 Skill 不一定要大，反而应该先把边界写清楚。它最好只负责一件相对明确的事情，输入是什么、输出是什么、哪些事情不做，都要尽量说明白。
二、用“万能高汤”理解可复用Skill
书里用了一个“万能高汤”的例子，我觉得很适合理解这个问题。
做饭时，高汤可以用来煮面、炖排骨、烧火锅。如果每一道菜谱里都把高汤的做法完整写一遍，那么以后高汤配方要改，所有菜谱都要跟着改。
更好的做法，是把“高汤”单独写成一个菜谱。其他菜谱需要用高汤时，只要引用它就行。以后高汤做法变化，也只需要改这一处。
Skill 也是类似的道理。
如果我把“要点提取”写死在“读书笔记 Skill”里面，那么它只适合读书笔记。可实际上，会议纪要、培训记录、产品文档、复盘材料也都可能需要提取要点。与其每个 Skill 里都写一遍，不如把“要点提取”单独做成一个 Skill。
这样一来，它就从一个专用能力，变成了更容易复用的基础能力。
三、把原来的Skill拆成更小的能力
以前我写的“读书笔记要点提取与错误分析”Skill，其实可以继续拆开。
原来的流程大致是：
- 读取读书笔记文件；
- 合并重复内容；
- 保留原意；
- 提取核心要点；
- 检查理解偏差和表述错误；
- 给出修改建议。
这个 Skill 用在读书笔记上没问题，但如果换成会议纪要或工作汇报，它的触发描述就可能不合适。比如用户说“帮我整理会议纪要”，系统未必会想到调用“读书笔记”相关的 Skill。
因此，我可以把它拆成两个更通用的 Skill。
第一个是“要点提取”：
只负责从文本中提炼核心要点，不判断对错，不润色语言，不生成最终文章。
适用于读书笔记、培训记录、会议纪要、产品文档、复盘记录等文本整理场景。
第二个是“文本挑错”：
只负责检查可疑内容，包括错别字、逻辑问题、概念混淆和表达不准确。
不直接改写原文，不负责提炼要点，也不负责润色成稿。
所有修改建议都需要用户最终确认。
拆开以后，两个 Skill 都可以单独使用。比如手写稿转成文字后，可能先用“文本挑错”检查错别字，再用“要点提取”整理结构；如果是别人已经写好的参考材料，可能只需要提取要点，不一定需要挑错。
这比原来一个“读书笔记专用 Skill”更灵活。
四、串联与并行不是一回事
多个 Skill 一起使用时，最常见的是串联。
串联就是前一个 Skill 的输出，作为后一个 Skill 的输入。比如整理读书笔记时，可以这样走：
原始笔记
-> 要点提取
-> 语言润色
-> 文档导出
这种方式适合有先后顺序的任务。没有要点，就很难润色；正文没有定稿，也不适合直接导出。
但有些任务不一定非要排队完成。比如同一份材料，可以同时做：
- 提取核心要点；
- 检查错别字和逻辑问题；
- 统计关键词；
- 查找可能需要补充来源的地方。
这些任务之间不一定互相依赖，就更适合并行处理。并行的好处是节省时间，但前提是每个任务的边界要清楚，否则多个结果汇总回来以后，反而更乱。
这里我也意识到，人工审核不是多余的。以前手动把一个结果交给下一个 Skill，确实麻烦，但它也给了我一个检查点。现在如果让多个步骤自动跑完，中间没有人工确认，一旦前面出错，后面可能会沿着错误继续加工，还会浪费上下文和 token。
所以，真正重要的不是“全部自动化”，而是在合适的位置保留确认点。
五、什么时候需要子智能体
如果任务变得更复杂，就可能用到子智能体。
我现在的理解是：子智能体像主智能体的助手。主智能体负责理解整体目标、拆分任务和汇总结果，子智能体则负责处理其中某个相对独立的部分。
可以用厨房来类比：主厨决定今天做什么菜、先做哪一步、最后怎样出品；副厨可以同时洗菜、备料或处理某一道配菜。副厨做事时，主厨不一定看到每一个细节，但需要告诉副厨任务边界和交付结果。
使用子智能体时，最好把要求说得更明确：
请只检查这篇文章中的技术表述是否准确。
不要改写全文。
不要调整文章结构。
只返回可疑问题列表，每条包含原文、问题原因和修改建议。
这样做的原因是，子智能体通常只返回结果，不一定把完整过程都展示出来。如果任务要求不清楚，最后拿到的结果可能不方便复核。
不过，并不是所有平台都支持子智能体，也不是所有任务都需要它。对初学者来说，先理解概念就够了。真正需要子智能体的，通常是资料很多、步骤复杂、可以拆成多个相对独立分工的任务。
六、Skill和子智能体的区别
Skill 更像一套可复用的规则或操作说明。它告诉智能体遇到某类任务时应该怎么做，必要时还可以配合模板、脚本或示例文件。
子智能体更像被临时委派出去完成某个任务的助手。它适合处理较复杂、相对独立、可以单独交付结果的部分。
可以简单区分为：
| 对比项 | Skill | 子智能体 |
|---|---|---|
| 主要作用 | 提供可复用规则 | 承担独立子任务 |
| 适合场景 | 重复、规则明确的任务 | 复杂、可拆分的任务 |
| 使用重点 | 写清步骤、边界和输出格式 | 写清任务目标、限制和交付结果 |
| 风险点 | 描述太宽会误触发，太窄会漏触发 | 过程不一定完全可见，需要明确约束 |
这张表只是帮助入门理解。具体到不同工具，Skill、工作流、插件、子智能体的名称和能力可能不同，不能把某一个平台的实现当成所有平台的统一标准。
七、本篇小结
这次学习让我更清楚地看到，多 Skill 协同不是把一堆能力硬塞到一起，而是把任务拆成几个边界清楚、可以组合的小环节。
我可以先把它理解成一条可调整的工作流：哪些步骤必须按顺序完成，就让它们串联；哪些检查可以互不影响，就让它们并行；资料多、分工明确、需要单独交付结果时，再考虑让子智能体参与。这样设计出来的流程，不一定最复杂，但更容易看懂，也更容易在出问题时回头修改。
还有一点对我很重要：不要一上来就想着搭一个完整版 Skill。刚开始能把基础功能跑通就已经很好了，后面再根据真实使用中遇到的问题，慢慢加上自己想要的其他功能。每一个真正好用的 Skill，往往都不是一次写完的，而是在反复使用、发现问题、调整规则和重新测试中慢慢成型的。
我后面再整理类似任务时，会先问自己几个问题：
- 这个流程里哪些步骤经常重复出现；
- 哪些步骤必须依赖前一步结果；
- 哪些检查可以单独完成；
- 哪些位置必须保留人工确认；
- 有没有某个小能力值得单独做成通用 Skill。
这样想以后，Skill 就不再只是一个孤立的说明文件，而是可以和其他能力一起组成工作流的积木。它能帮我把流程搭得更稳，但每一块怎么组合、什么时候停下来检查，仍然需要自己先想清楚。