你在用 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可暂停、恢复。这套模型天然适合 SkillsSkills 不该是永远挂在主上下文里的万能 Prompt而应该是按需激活、用完即走的情景行为。Rules vs Skills上下文污染 vs 渐进式披露Rules 是强制加载的巨型文件一次性塞满上下文。Skills 遵循渐进披露原则主 Agent 只看到 Skills 列表需要时才激活具体行为避免上下文被数万 token 的条件指令淹没。人类学技能也是这样先看别人做再内化成“上下文条件行为”。LLM 同样有“知识过剩”knowledge overhang模型知道怎么做却不会主动选。Skills 的作用就是把分布外知识拉回分布内行为。Skills 作为情景行为 情景记忆Skills 应该映射到情景记忆episodic memory就像你换轮胎时脑子里清楚当前处于第几步整个过程就是一系列子程序的组合形成一个隔离的“episode”。Slate 的 Thread 天生就是这种隔离上下文的最佳载体。从手动激活到动态 Skill ChainingForking 原语的突破早期方案主线程看到 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手动 slashSlate Skill ChainingFork 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和系统实验。感兴趣可以关注我们下期见。