AI调度范式实战：从「小马拉大车」到三联机制

从「小马拉大车」到「三联机制」——AI Skill 调度范式的实战思考

一、问题的起点：1000 个 Skill 的尴尬

在深度使用 AI 智能体 WorkBuddy 的过程中，一个令人头疼的问题逐渐浮现。

Skill 的生态确实太丰富了——你可以安装几千个，覆盖写作、编程、设计、数据分析、变&现策略……但实际情况是，绝大多数 Skill 装了就装在在那，从未被真正触发。

更诡异的是另一个极端：明明优质的 Skill 就装在本地，AI 却「想不起来」用它。比如装了 prompt-optimizer（提示词优化器），你连续写三遍提示词，它都没有被触发。

这里有两个典型问题，可以形象地概括为：

• 「小马拉大车」：AI 的调度判断力是有限的「小马」，却要拉动几百上千个 Skill 的「大车」——调度压力全压在 Agent 瞬时判断上。
• 「大马拉小车」：某些 Skill 能力足够强（大马），但因为触发条件描述不充分，实际上只处理非常窄的任务（小车）。

二、根因分析：Skill 到底怎么被触发的？

来分析一下 WorkBuddy 的 Skill 调度机制，精简来说就是：

• Skill 安装后默认进入休眠状态，只有 name 和 description 这两个字段始终在上下文中。
• Agent 根据当前对话内容，判断是否匹配某个 Skill 的 description。
• 只有 Agent 主动调用 use_skill 时，Skill 的完整指令才会被加载。

这意味着什么？

Skill 的触发与否，完全取决于 Agent 在那一瞬间「想没想起来」。没有记忆机制，没有主动告知的接口，更没有边界告警功能。

这就像你请了 100 个专家坐在隔壁房间，但他们不会主动敲门告诉你「我能帮上忙」——你得靠自己的直觉判断，什么时候该叫谁。这才是调度问题的核心。

三、三联机制：让 AI 从「被动等待」到「主动服务」

经过几轮深度讨论，这里设计了三层协作机制：

第一层：需求雷达（Intent Radar）

做什么：每次对话开始时，自动扫描用户意图方向。

不等待用户明确指出「我要用 XX Skill」，而是从输入中提取意图大类：

设计原则：不猜具体细节，只判大类方向。大类对了，后面的能力匹配就不会偏。

第二层：能力快照（Capability Snapshot）

做什么：意图判定后，主动告知用户「现在有哪些专家在支持你」。

例如：

为什么重要：用户往往不知道某个 Skill 存在，甚至不知道它能做什么。主动告知，相当于让「隔壁的专家敲门进来报到」。

第三层：边界哨兵（Boundary Sentinel）

做什么：当用户需求触及当前 Skill 的能力天花板时，主动告警。

例如：用 html-ppt 生成了一份演示文稿，用户说「帮我部署到线上」。此时边界哨兵会主动触发告警机制。

为什么重要：避免「勉强出活」——当前 Skill 硬着头皮做不擅长的事，质量会下降，用户也会感到困惑。

四、共享知识池：不让信息断链

三联机制还有一个隐藏层：共享知识池（Shared Knowledge Pool）。

每次 Skill 执行完毕后，产出物不是孤立的。下一阶段 Skill 会自动继承：

• 文件路径（上一阶段生成的文档/代码的绝对路径）
• 关键结论（核心分析结果，不超过 3 条）
• 进度摘要（一句话概括当前进展）

这解决了跨 Skill 协作中最常见的问题：「换人」就丢上下文。

五、Intent Router：一个「元 Skill」的诞生

三联机制不是一个抽象概念。它已经被实现为一个真实的 Skill 文件——Intent Router（意图路由引擎）。

它不替代任何具体 Skill，而是做三件事：看方向、亮底牌、守边界。

它被设计为「元 Skill」——所有对话默认优先加载，每次对话开始和意图变化时自动激活。

你可以在 WorkBuddy 中安装使用。

六、一个产品建议：对话列表需要管理功能

在实现三联机制的过程中，操作中暴露了一个「朴实但致命」的产品痛点：

对话列表只能显示首次对话内容的简写作为名称，不支持：

• ✗ 右键重命名
• ✗ 归档/封存
• ✗ 删除
• ✗ 收归到文件夹

时间一长，几十条对话全是模糊的截断文本，完全分不清哪个是哪个工作流。

这个反馈已经通过 AI 整理提交给后台团队。如果你也有同样的困扰，请一起反馈。

七、写在最后

三联机制的核心思想其实很简单：

从「装了很多 Skill 却不会用」，到意识到调度问题，再到设计出三联机制——整个过程让人深刻体会到：AI 工具的好坏，不在于它能做什么，而在于它知不知道自己能做什么、该什么时候做。

希望这篇分享能帮到同样在「Skill 大海」里迷茫的你。