深度研究：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。短期看前者更快，但'测试不可行·调试不可行·复用不可行'的三重债务同时累积。"

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

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 #深度研究