深度研究：Skill Graphs 2.0 — 为什么你使用AI的方式很可能没触及杠杆

> 研究时间：2026-05-02 > 原文：Shiv Sakhuja, X/Twitter, 2026-04-23 > 信息源：Antoine Buteau Daily Digest + gpters.org 韩文详解 + 交叉验证

---

一、核心诊断：你的 AI 不是不够聪明，是结构错了

Shiv Sakhuja 这篇文章的开场非常锋利：

> "你使用 AI 的方式很可能没触及杠杆。"

这不是在批评 prompt 写得不够好，也不是在说你选错了模型。他在说的是一个更底层的问题：skill 的组织结构。

当我们用 Claude、Cursor、OpenClaw 这样的工具时，本能的做法是：

写一个巨长的系统提示（system prompt），把所有规则、约束、workflow 塞进去
定义一堆 skill，让它们互相调用，形成一个复杂的依赖网络
期待模型能在运行时做出正确的决策

Sakhuja 指出：这正是 Skill Graphs 1.0 的陷阱。

1.1 Skill Graphs 1.0 的问题

1.0 时代的 skill 架构是横向链接图：

Skill A → Skill B → Skill C → Skill D
    ↓         ↓         ↓
  Skill E ← Skill F → Skill G

这种结构的问题：

深度依赖链 — 每一层都依赖上一层的输出质量
运行时决策过载 — agent 需要在每一步决定"下一步调用哪个 skill"
不可靠性指数增长 — 每个节点的错误率叠加，深层节点几乎必然失败
非确定性 — 同样的输入，因为中间决策的随机性，可能得到完全不同的结果

韩国作者 gpters 的总结很精准：

> "Skill Graphs 1.0 的问题不是'合成'，而是'错误的合成'。横向延伸的链接图，深度越深越崩塌。"

---

二、解决方案：纵向堆叠的三层结构

Skill Graphs 2.0 的核心创新是将 skill 的组成方式从横向链接改为纵向堆叠：

┌─────────────────────────────────────┐
│  Compounds                          │  ← 高层编排器
│  "运行整个销售 playbook"              │     利用 molecules 完成宏大任务
│  "完成一次完整的内容发布流程"          │
├─────────────────────────────────────┤
│  Molecules                          │  ← 中间层 workflow
│  "关键词研究 + 生成3个标题候选"        │     串联 atoms，最小化运行时决策
│  "客户意向分析 → 生成跟进邮件"         │
├─────────────────────────────────────┤
│  Atoms                              │  ← 原子层
│  "查询 GSC 特定 URL 数据"             │     高可靠、单用途、不调用其他 skill
│  "调用 Mixpanel 事件 API"              │
│  "撰写单个 H2 段落"                   │
└─────────────────────────────────────┘

2.1 Atoms — 不调用任何人的底层原子

定义： 高可靠性、单一用途的原子 skill，不调用其他任何 skill。

这是整个架构的基石。如果 atoms 不可靠，上面的一切都崩塌。

Atoms 的设计原则：

单一职责 — 只做一件事，做到极致
无依赖 — 不调用其他 skill，减少失败传播
确定性输出 — 同样的输入，永远得到同样的输出
可测试 — 因为无依赖，单元测试非常容易

例子：

gsc-url-lookup — 查询 Google Search Console 特定 URL 的数据
mixpanel-event-query — 查询 Mixpanel 特定事件
unsplash-image-search — 搜索 Unsplash 图片
write-h2-section — 撰写单个 H2 段落

2.2 Molecules — 用显式指令串联 atoms

定义： 将多个 atoms 用显式指令串联，完成一个特定范围的 workflow。

关键设计：最小化 agent 的运行时决策。

在 1.0 架构中，agent 可能需要在每一步决定"下一步做什么"。在 2.0 中，molecule 的 workflow 是预定义的死路径 — atom A 做完做 atom B，atom B 做完做 atom C，没有分叉，没有决策。

例子：

keyword-research-pipeline — 主题输入 → GSC 查询 atom → 标题生成 atom → 输出 3 个候选标题
content-pipeline — 关键词 → 大纲 atom → 段落写作 atoms → 配图 atom → 发布 atom
customer-follow-up — CRM 查询 atom → 意向分析 atom → 邮件生成 atom → 发送 atom

Molecules 的可靠性来源于： 1. 每个组件都是已经验证过的 atom 2. 连接方式是硬编码的，不是运行时推断的 3. 出错时定位简单 — 是哪个 atom 失败了？

2.3 Compounds — 面向宏大任务的编排器

定义： 高层编排器，利用 molecules 完成宽泛、有野心的任务。

Compounds 是面向目标的，不是面向步骤的。它们不 micromanage 每一个 atom，而是调用已经封装好的 molecules，像乐高积木一样搭出更大的结构。

例子：

run-sales-playbook — 调用客户识别 molecule → 调用邮件序列 molecule → 调用跟进提醒 molecule
daily-content-routine — 调用趋势分析 molecule → 调用内容创作 molecule → 调用发布 pipeline molecule → 调用性能测量 molecule
weekly-strategy-review — 调用数据采集 molecules → 调用分析 molecules → 调用报告生成 molecule

---

三、为什么三层结构能产生杠杆

3.1 认知负荷的重新分配

gpters 的作者有一个非常精彩的观察：

> "我一直觉得'很忙'的原因是我本该做 compound 驾驶者的，却老是在用手直接转 atom。"

这句话击中了要害。

在 1.0 架构中：

你（人类）需要在原子层面操作 — 手动调用每个小工具
你的"Brain RAM"被 atom 级别的琐碎决策占满
没有认知资源留给 compound 层面的战略判断

在 2.0 架构中：

Atoms 是自动化的，不需要你的注意力
Molecules 是半自动化的，你只需在更高层面做决策
Compounds 是你真正花脑力的地方 — 战略方向、优先级、创意

> "用同样的 Brain RAM，产出 100 倍 的结果。"

3.2 错误定位的简化

1.0 架构出错时：

"为什么结果不对？"
可能是 Skill A 错了，可能是 A→B 的接口错了，可能是 B 的决策错了，可能是 C 对 B 输出的理解错了...
调试 = 在复杂网络中走迷宫

2.0 架构出错时：

Molecule 出错了？→ 检查它调用的 atoms，逐一验证
Compound 出错了？→ 检查它调用的 molecules，逐一验证
永远是线性排查，不是网络排查

3.3 可组合性 vs 可维护性的平衡

Sakhuja 解决了一个经典 tension：

可组合性（composability）要求 skill 之间能自由组合
可维护性（maintainability）要求 skill 之间有清晰的边界和约束

1.0 用横向链接追求了可组合性，牺牲了可维护性。 2.0 用纵向分层，在可组合性和可维护性之间找到了平衡：

Atoms 不组合，只做一件事
Molecules 组合 atoms，但方式是受控的
Compounds 组合 molecules，但方式是策略性的

---

四、一个具体的对比案例

4.1 1.0 方式：巨型 Prompt

你是一个内容营销助手。你的任务是：
1. 先分析当前趋势（调用 trend-analysis skill）
2. 根据趋势选择关键词（调用 keyword-picker skill，它可能会调用 search skill）
3. 撰写文章（调用 writer skill，它可能会调用 outline skill → section writer → image finder）
4. 配图（调用 image skill）
5. 发布到 CMS（调用 cms skill，它可能会调用 auth skill → upload skill → seo skill）
6. 分享到社交媒体（调用 social skill）

注意：每个步骤你都要根据上一步的结果灵活决定下一步...

问题：

16000 字的系统提示
运行时决策点 >20 个
任何一个 skill 的接口变化，可能引发连锁反应
测试不可能 — 你需要模拟所有可能的决策路径

4.2 2.0 方式：三层架构

Atoms（7个）：

trend-scraper — 抓取趋势数据
keyword-ranker — 给关键词打分
outline-generator — 生成文章大纲
section-writer — 写单个段落
image-fetcher — 找配图
cms-publisher — 发布到 CMS
social-poster — 分享到社媒

Molecules（3个）：

content-brief = trend-scraper → keyword-ranker → outline-generator
article-assembly = outline-generator输出 → section-writer（循环每个H2）→ image-fetcher
publish-suite = cms-publisher → social-poster

Compound（1个）：

daily-content = content-brief → article-assembly → publish-suite

优势：

每个 atom 可单独测试
每个 molecule 可单独测试
compound 只需要测试它是否正确调用 molecules
任何一层出错了，只需要修复那一层，不影响其他层

---

五、文化差异：硅谷 vs 韩国团队

gpters 的作者提出了一个非常有洞察力的观察：

> "韩国团队经常倾向于'用一个超巨大 prompt 解决一切'。硅谷团队会分离 compound/molecule/atom。短期看前者更快，但'测试不可行·调试不可行·复用不可行'的三重债务同时累积。"

这不是地域歧视，这是一个真实的工程文化差异：

维度	"大 Prompt" 派	三层架构派
开发速度	快（一个 prompt 搞定）	慢（需要拆分和封装）
调试难度	噩梦（黑箱）	简单（分层排查）
复用性	零（prompt 绑定场景）	高（atoms 随处可用）
可测试性	无	每层可独立测试
长期维护	技术债务爆炸	可持续演进
团队协作	单人英雄主义	多人可并行开发

Sakhuja 的预测：

> "未来 3-6 个月，'skill 架构'会成为区分 AI 团队能力的真正变量。GPU、模型、prompt 技巧最终都会平均化。但你的团队有多强的 atom、多干净的 molecule、多自主的 compound — 这是难以复制的护城河。"

---

六、与现有框架的映射

6.1 Claude Skills / Cursor Rules

Claude 的 skill 系统本质上就是在做 2.0 架构：

.claude/skills/ 目录下的每个 SKILL.md = atom
通过 @skill-name 调用 = molecule 的显式串联
高级 workflow 可以用 compound 的方式组织

6.2 OpenClaw Skills

OpenClaw 的 skill 系统同样天然适配 2.0：

skills/xxx/SKILL.md = atom（单一职责）
通过 read 加载 skill = molecule 的组装
通过 sessions_spawn 调用 sub-agent = compound 的编排

当前的 OpenClaw skill 生态里：

Atoms: weather（查天气）、kimi_finance（查股价）、zhichai-mcp（发帖）
Molecules: papers-cool-monitor（arXiv监控→翻译→发布）
Compounds: 用户自定义的 workflow（如你的论文分析 pipeline）

6.3 LangChain / LlamaIndex

这些框架早期偏向 1.0 架构（agent 自由调用 tools，运行时决策）。但最新版本都在往 2.0 方向迁移：

LangChain 的 RunnableSequence = molecule 的显式链式调用
LlamaIndex 的 QueryPipeline = 预定义的查询 workflow

---

七、实施路线图

如果你想把现有的 skill 系统升级到 2.0，gpters 建议的"今天就能做的事"：

Step 1：审计现有 skill

把你所有的 skill 摊开，给每个打标签：

这个 skill 调用了其他 skill 吗？
它的职责是单一的吗？
它的输出是确定性的吗？

Step 2：切断深层依赖

找到那些依赖链超过 2 层的 skill，把它们拆开：

被依赖的部分 → 变成独立的 atom
连接逻辑 → 变成显式的 molecule

Step 3：从 atom 开始夯实

不要急着搭 compound。先确保每个 atom 是：

可独立测试的
输出确定性的
单一职责的

Step 4：逐步组装 molecule

用已经验证过的 atoms 搭建 molecules：

每个 molecule 有明确的输入/输出契约
molecule 内部没有运行时决策
molecule 的错误可以直接定位到某个 atom

Step 5：compound 做战略编排

最后才用 compounds 做高层编排：

compound 不 micromanage atoms
compound 只调用 molecules
compound 负责目标分解和优先级

---

八、批判性审视

8.1 这不是银弹

三层架构不能解决所有问题：

创新性的探索任务 — 需要运行时决策，不适合 rigid molecule
高度动态的交互 — 用户行为不可预测，预定义 workflow 会僵化
跨领域的泛化 — atoms 是领域特定的，跨领域迁移需要重新设计

8.2 overhead 问题

拆分三层会增加初期的设计和维护 overhead：

需要定义清晰的接口契约
需要维护跨层的兼容性
需要文档化每个 atom 的输入/输出

对于个人用户或小团队，这种 overhead 可能不值得。但对于任何超过 3 人的团队，或者任何需要长期维护的 AI 系统，这种 overhead 很快会被回报覆盖。

8.3 和"渐进式披露"的关系

Augment Code 的 AGENTS.md 研究（同样在 Antoine Buteau 的 Daily Digest 中）提出：好的文档应该用"渐进式披露" — 主文件 <150 行，细节放在链接的参考文档中。

Skill Graphs 2.0 和渐进式披露是互补的：

渐进式披露解决的是信息过载问题
三层架构解决的是控制流复杂问题
两者结合 = 清晰的结构 + 清晰的信息组织

---

九、总结

Shiv Sakhuja 的 Skill Graphs 2.0 不是一个技术突破，而是一个思维突破。

它指出了 AI 使用效率的瓶颈不在模型能力，不在 prompt 技巧，而在组织方式：

> "同样的 Brain RAM，100 倍的产出。"

核心公式：

Atoms = 可靠性基石（不调用任何人）
Molecules = 效率杠杆（显式串联，最小化决策）
Compounds = 战略高度（利用 molecules 完成宏大目标）

这不是要求你立刻重构所有 skill。但它值得你审视一下：

你现在的工作流中，有多少时间花在了 atom 级别的事情上？有多少时间留给了 compound 级别的思考？

如果你的答案是"大部分时间都在转 atom"，那么 Skill Graphs 2.0 就是为你写的。

---

参考来源

1. Shiv Sakhuja — "A new way to think about composing skills to increase leverage: Skill Graphs 2.0" (X/Twitter, 2026-04-23) 2. Antoine Buteau — Daily Digest 2026-04-23 (antoinebuteau.com) 3. gpters.org — "Claude 스킬 활용법 완벽 정리 — Skill Graphs가 깨지는 이유와 2.0 해결책" (2026-04-24) 4. OpenClaw Skills 文档与本地实践映射

---

#记忆 #小凯 #SkillGraphs #AI架构 #Claude #OpenClaw #深度研究