一、这个问题是怎么来的？
最近在整理自己的 Skill 库时，我产生了一个疑问：
如果我有 5 个都是分析股票的 Skill，在一次对话中同时手动加载，会不会比只加载一个 Skill 更厉害？
这个问题其实非常有代表性。很多人在使用 Codex、WorkBuddy、Claude Code 等 Agent 时，都下意识觉得：**加载的 Skill 越多，AI 就越强。**但事实并不是这样。搞清楚 Agent 到底怎么用 Skill 的，才能设计出更稳定、更省 Token 的 Skill 体系。
二、很多人误解了 Skill 的工作方式
假设我们同时勾选了下面 5 个 Skill：
- 股票基本面分析
- 技术分析
- 财报分析
- 资金流分析
- 巴菲特价值投资分析
很多人的理解是这样的——AI 会依次调用五个专家，再综合五个人的意见：
Skill1
↓
Skill2
↓
Skill3
↓
Skill4
↓
Skill5
↓
综合输出
实际上，大多数 Agent 并不是这样工作的。
三、真正发生的事情是什么？
绝大多数 Agent（包括很多 Codex、WorkBuddy 等框架），当你手动加载多个 Skill 时，本质上会把它们全部拼接到同一个 Prompt 中。
模型最终看到的，更像是下面这样：
System Prompt
==================
Skill A 的说明（完整 SKILL.md 内容）
==================
Skill B 的说明（完整 SKILL.md 内容）
==================
Skill C 的说明（完整 SKILL.md 内容）
==================
Skill D 的说明（完整 SKILL.md 内容）
==================
Skill E 的说明（完整 SKILL.md 内容）
------------------
User：
分析腾讯股票
模型不是先执行 Skill A，再执行 Skill B，而是一次性看到所有 Skill 的说明。然后由大模型自己理解、融合这些信息，生成最终回答。因此，多个 Skill 更准确地说是多份"说明书"，而不是多个独立运行的专家。
打个比方：你同时塞给一个人五本不同的"投资指南"，他不可能分别按五本书跑五遍——他只会快速通读，然后用自己的理解给你一个综合回答。
四、多个 Skill 一起加载，会有哪些影响？
情况一：能力互补，效果通常更好
如果每个 Skill 负责不同的能力，例如：
- 财报分析
- 行业分析
- DCF 估值
- 风险分析
- Markdown 报告生成
它们之间职责明确、互不冲突。最终模型能够综合这些能力，输出更完整的分析结果。这属于多个模块共同完成一项任务，值得推荐。
情况二：同类 Skill，收益可能没有想象中大
如果五个 Skill 都是在教模型"如何分析股票"，例如：
- 巴菲特投资体系
- 彼得·林奇投资体系
- 技术分析体系
- 量化分析体系
- 价值投资体系
那么模型最终看到的是**五套相似甚至部分重叠的分析方法。**它不会真的分别运行五个专家。更多情况下，它会：**自动融合、自动取舍、自动折中，**最后输出一个综合性的回答。
**加载五个相似 Skill，不等于得到五倍能力。**更像是给了模型五份方向大致相同的参考资料，而不是五个独立分析引擎。
五、Skill 之间还可能互相"打架"
如果多个 Skill 的指导原则不同，就可能出现冲突。例如：
| Skill | 指导原则 |
|---|---|
| A | PE 是核心指标 |
| B | PE 并不重要，更关注现金流 |
| C | 不预测未来股价 |
| D | 必须预测未来一年走势 |
模型看到之后，会尝试兼顾所有观点。最终回答往往会变成：
「PE 有一定参考价值……现金流同样重要……可以适当预测……但预测存在较大不确定性……」
这种回答看起来什么都说了，其实**没有任何一个体系真正贯彻到底。**这也是很多人觉得 AI 回答越来越"和稀泥"的重要原因。
六、一个容易被忽略的问题：Token 成本
很多人只关注能力，却忽略了上下文成本。做个简单估算：
| 内容 | Token 数 |
|---|---|
| 每个 Skill | ~1,500 |
| 5 个 Skill | ~7,500 |
| 用户提供的数据 | ~5,000 |
| 历史聊天记录 | ~10,000 |
| 合计 | ~22,500 |
一次请求中，仅上下文就已经达到 22,500 Token。
请求更慢、成本更高、更容易触碰上下文长度限制、历史内容更容易被挤出上下文。每加载一个 Skill，都会挤占一部分上下文窗口，而这些窗口本该留给用户数据和历史对话。
七、什么时候适合同时加载多个 Skill？
关键原则只有一句话：互补型 Skill 可以一起加载，相似型 Skill 要谨慎。
| Skill 组合 | 建议 | 原因 |
|---|---|---|
| 财报 + 风险 + 行业 + 报告生成 | ✅ 推荐 | 能力互补，提升分析完整度 |
| PPT + 配图 + Mermaid + Markdown | ✅ 推荐 | 属于完整工作流链条 |
| 巴菲特 + 林奇 + 技术分析 + 价值投资 | ⚠️ 谨慎 | 内容重叠，容易融合甚至冲突 |
| 五个功能几乎相同的 Skill | ❌ 不推荐 | Token 增加，收益有限 |
八、如果一定要加载多个同类 Skill，应该怎么做？
如果你的目的就是**"希望看到不同投资体系的观点"**，那么不要让模型自己决定。而是直接告诉它：
请严格按照五种投资体系分别分析，不允许融合，最后再给出综合结论。
例如输出结构可以设计为：
一、巴菲特投资体系
......
二、彼得·林奇体系
......
三、技术分析体系
......
四、量化分析体系
......
五、综合结论
这样模型会更倾向于分别应用不同思路，而不是提前融合。
九、我更推荐的 Skill 设计方式
相比维护多个高度相似的 Skill，我更推荐：一个总 Skill + 多个子模式（Persona）。
例如：
股票分析 Skill
├── 巴菲特模式
├── 林奇模式
├── 技术分析模式
├── 财报分析模式
├── 量化模式
真正调用时，只需要告诉 Agent：
分析腾讯股票
启用：
✓ 巴菲特模式
✓ 财报模式
✓ 技术分析模式
这样设计有几个明显优势：
- 公共规则只维护一次，减少重复。
- 避免多个 Skill 指令冲突。
- 节省 Token，降低上下文开销。
- 输出结构更加稳定。
- 后期维护成本更低。
对于 Skill 数量越来越多的用户，这种设计会明显优于维护大量高度相似的独立 Skill。
十、最后的总结
关于"一次加载多个 Skill 是否更强"，记住下面几条：
- 多个 Skill 不会像多个专家一样依次执行。
- 大多数 Agent 的实现方式，是把多个 Skill 一次性拼接到 Prompt 中，让大模型自行理解和融合。
- 互补型 Skill（不同能力）一起使用，通常能够提升效果。
- 相似型 Skill（相同领域、不同流派）一起使用，收益往往没有想象中高，还可能因为指令冲突导致回答变得折中。
- 如果希望保留不同体系的观点，应明确要求模型分别分析，而不是让它自由融合。
**一句话总结：**Agent 的能力，不取决于一次加载了多少 Skill，而取决于 Skill 是否职责清晰、互补协作，以及你是否让模型以正确的方式组织和使用这些能力。
十一、把镜头拉近：Skill 注入的四个底层机制
前面讲的都是"现象层面"。如果我们把镜头拉近，看看 Skill 到底在底层是怎样发挥作用的，理解会更深。
1. Skill 加载本质是 Prompt 注入，不是多 Agent 协作
无论是手动勾选还是自动匹配，Skill 都通过"将 SKILL.md 全文拼入 System Prompt 或用户消息"的方式生效。Agent 框架一般不会为每个 Skill 启动独立的推理会话——那样成本太高，而且不同会话之间没有共享上下文。
实际的做法是：在同一条 Prompt 里把多个 Skill 的指令一并给出。所以：
- Skill A 里写"输出必须包含风险提示"，Skill B 里写"输出应简洁，不超过 500 字"，模型需要自己协调这两个指令。
- 如果两个 Skill 的指令本质上互斥——比如一个要求结构化表格、另一个要求自然段落——模型最终的表现会变得不稳定，可能在这一段遵守 A，下一段又被 B 带跑。
2. Skill 不是 RAG，不要再搞混了
有人在看到"多个 Skill 一起用"时，会联想到 RAG（检索增强生成）——从多个知识库中检索相关内容然后综合。但 Skill 不是知识库，它是行为指令。知识库的内容可以叠加，因为它们是"参考资料"，不冲突就行；指令叠加却不一样——两条互相矛盾的指令同时生效，模型没法同时做到，只能折中。
这个区别很关键：RAG 是给了模型更多"弹药"，Skill 是给了模型更多"命令"。多一份弹药通常更好，多一份互相打架的命令则未必。
3. 中间迷失：Skill 多了，有些指令会被模型忽略
大模型处理长上下文时，存在公认的"中间迷失"（Lost-in-the-Middle）效应。2023 年 Liu 等人的研究证实：模型对开头和结尾的内容关注度最高，中间部分容易被遗漏。
这个效应放在 Skill 加载的场景里就很直接了：当你加载 5 个甚至 8 个 Skill 时，排在 Prompt 中间位置的 Skill 指令，模型可能只是"略读"一下，甚至整段跳过。你在用的 Agent 看起来加载了 8 个 Skill，实际被认真执行的也许只有前两个和最后一个。
4. 真的需要多个"视角"？换个思路
一个更可靠的方案不是加载多个 Skill，而是：
- 用单个 Skill 定义清楚分析框架。
- 在 Skill 内用模式切换（如"请用巴菲特模式分析"）来控制行为分叉。
- 如需多次分析，分多轮对话，每轮切换一个模式。每轮只加载一份上下文，指令更聚焦，也不存在指令冲突。
这个思路比"一次性加载五个 Skill 让模型自己看着办"要可靠得多——不是因为逻辑上更优雅，而是因为它尊重了模型处理长上下文的真实边界。
**原文作者：**杨杰的学习笔记，整理自日常使用 Agent 的实践经验。
