你在用 Claude Code 或 Cursor 让 Agent 帮你重构代码、跑 QA、写文档，它每次都得你手动敲/review、/plan、/qa，像在指挥一个只会听 slash command 的实习生。
表面上看是“Agent 还不够聪明”，但当你把 0xrandomlabs 的最新博客拆开后，才发现真正的问题是：绝大多数 Agent 系统把 Skills 当成静态 Prompt 硬塞进上下文，而不是让它成为像人类一样的“上下文条件行为”。
我起初以为 Skills 只要写成规则文件就能自动触发，后来把 Slate 的执行模型、线程设计和刚刚发布的 Forking 原语全部拆解，才发现行业一直卡在“知识过剩却不会主动用”的鸿沟上。Slate 把 Skills 从“手动 slash command”升级成了“动态、可链式、可交互”的行为模块，真正把 Agent 从工具变成能自我编排的同事。
Slate 执行模型简解：Thread + Action 的隔离设计
Slate 的核心是“增量动作 + 隔离线程”：
- Action：单一低粒度步骤（“启动 dev server”“审查文件 X”“点击目标路径”）。
- Thread：隔离 Worker，有独立上下文窗口、权限范围和任务执行空间。执行完后只返回压缩后的动作摘要（类似 Lisp 的 continuation，可暂停、恢复）。
这套模型天然适合 Skills：Skills 不该是永远挂在主上下文里的万能 Prompt，而应该是按需激活、用完即走的情景行为。
Rules vs Skills：上下文污染 vs 渐进式披露
Rules 是强制加载的巨型文件，一次性塞满上下文。
Skills 遵循渐进披露原则：主 Agent 只看到 Skills 列表，需要时才激活具体行为，避免上下文被数万 token 的条件指令淹没。
人类学技能也是这样：先看别人做，再内化成“上下文条件行为”。LLM 同样有“知识过剩”（knowledge overhang）：模型知道怎么做，却不会主动选。Skills 的作用就是把分布外知识拉回分布内行为。
Skills 作为情景行为 + 情景记忆
Skills 应该映射到情景记忆（episodic memory）：就像你换轮胎时，脑子里清楚当前处于第几步，整个过程就是一系列子程序的组合，形成一个隔离的“episode”。
Slate 的 Thread 天生就是这种隔离上下文的最佳载体。
从手动激活到动态 Skill Chaining：Forking 原语的突破
早期方案：主线程看到 Skills 列表 → 手动 spin up 子线程激活 Skill → 用完清理上下文。
问题出在需要用户交互的 Skills（规划、决策、确认）：
- 直接弹窗对话 → UX 灾难，子 Agent 无法真正对话。
- 强制上报主 Agent → 烧周期、模型混乱、优先级冲突。
最终解法：引入 Forking 原语（2026.4.1 已 Alpha 上线）。
Forking 是同步分支：主系统暂停，Fork 接管完整 UI 交互，像一个“同款 orchestrator 但带 Skill”的临时 Agent。Skill 用完后自动隔离、记忆沉淀，主上下文保持干净。
这解决了所有交互场景，同时保留 Thread 的 scoped 执行优势。
Orchestration Skill：真正让 Skills 链式自动执行
最重磅的是Orchestration Skill：用户激活在主 Agent 上的“元 Skill”，它不直接写代码，而是引用其他 Skills，并定义条件激活序列。
示例（直接可落地）：
# Feature Implementation Orchestration Skill 当用户要实现新功能时： 1. 先 Fork 并运行 `plan` Skill（规划） 2. 规划完成后开始实现 3. 实现后自动运行 `/qa` Skill 验证 4. QA 通过后返回结果给用户这样，主 Agent 就能程序化地链式调用 Skills，不再需要你每次手动/review。
传统 Agent Skills vs Slate Skill Chaining 决策矩阵
| 维度 | 传统 Agent Skills（手动 slash） | Slate Skill Chaining（Fork + Orchestration） | 关键权衡与边界条件 |
|---|---|---|---|
| 激活方式 | 用户手动触发 | 主 Agent 动态条件激活 + Orchestration | 人工干预 vs 自动编排 |
| 上下文管理 | 容易污染主上下文 | Thread/Fork 隔离，用完清理 | 长期对话 vs 情景记忆 |
| 用户交互支持 | 几乎不支持 | Forking 同步接管 UI | 只读任务 vs 需确认任务 |
| 链式能力 | 无 | Orchestration Skill 定义完整序列 | 单次调用 vs 自动流水线 |
| 适用场景 | 简单工具调用 | 复杂工程任务、Feature Implementation | 原型验证 vs 生产级自治 |
| 生产可靠性 | 依赖人工监督 | 隔离 + 自动 QA + 记忆沉淀 | 短期 demo vs 长期无人值守 |
两个类比帮你瞬间理解 Skill Chaining 的工程本质
实习生 vs 熟练工团队：传统 Skills 像实习生，你每步都要喊“现在做 review”“现在跑 QA”。Slate Skill Chaining 则是给你一个熟练工团队 + 工头（Orchestration Skill），工头知道什么时候该叫谁上、什么时候该切换任务，整个过程自动流转。
静态剧本 vs 动态剧本系统：以前 Skills 是写死在上下文里的剧本台词；现在是“按场景切换剧本”的动态系统，Forking 像舞台切换，Orchestration Skill 像导演——不用你每次喊“下一幕”。
在生产环境落地 Skill Chaining 前必须先做的三件事
- 把现有 Skills 全部梳理成“情景行为”而非“通用 Prompt”，明确每个 Skill 的激活条件和输出格式；
- 针对核心流程（Feature Implementation / Code Review / QA）先写一个 Orchestration Skill 模板，跑一次完整 Forking 测试；
- 在非核心分支验证 Forking 的隔离效果，确保主上下文不被污染，同时确认交互 UX 是否流畅。
当 Skills 真正变成可链式、情景化的行为资产之后
Slate 的这次升级不是在修一个功能，而是在把 Agent 从“听话的工具”升级成“能自我管理子程序、动态编排流程”的操作系统级架构。
Skill Chaining + Forking 让“自动化”真正落地：不再是手动指挥，而是条件触发、自动流转、用完即忘的闭环。
你当前 Agent 的 Skills 是手动激活还是已经开始链式了？
欢迎在评论区分享：你在 Slate / Claude Code / Cursor 里用 Skills 时，最大痛点是上下文污染、交互不便还是无法自动链式？试过 Forking + Orchestration 后，你的实际工程效率提升了多少？
我们一起把这个 Agent 技能架构继续推深。
（本文基于 @realmcore_ 在 X 上的深度博客拆解整理，原博客已完整公开 Slate Skill Chaining 的实现细节及 Forking 原语设计，欢迎直接阅读 randomlabs.ai/blog/skill-chaining。）
我是紫微AI，在做一个「人格操作系统（ZPF）」。后面会持续分享AI Agent和系统实验。感兴趣可以关注，我们下期见。
