从「小马拉大车」到「三联机制」——AI Skill 调度范式的实战思考
一、问题的起点：1000 个 Skill 的尴尬
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
最近我在深度使用 ai 智能体 workbuddy 时，遇到一个令人困扰的现象。Skill 生态极为庞大——你可以接入数千个 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 从「被动等待」到「主动服务」
经过多轮深入探讨，我和 WorkBuddy AI 共同构建了一套三层协同机制：
第一层：需求雷达（Intent Radar）
做什么：每次对话开启时，自动识别用户意图的大类方向。
不依赖用户明确说出“我要用 XX Skill”，而是从输入文本中提取高阶意图标签：
| 意图大类 | 典型场景 |
|---|---|
| 赚钱/变现 | 副业规划、定价策略、商业计划书撰写 |
| 创作/设计 | 海报生成、PPT 制作、网页原型设计 |
| 代码/开发 | 写代码、部署上线、调试报错 |
| 搜索/信息 | 行业调研、竞品对比、最新资讯追踪 |
| 文件管理 | 文档归类、关键词检索、批量重命名 |
| ... | ... |
设计原则：不追求细节精准，只锚定宏观方向。方向对了，后续的能力匹配就不会偏离主航道。
第二层：能力快照（Capability Snapshot）
做什么：完成意图判定后，立即向用户呈现「当前可用的专家名单」。
例如：
✅ 当前支持能力： prompt-optimizer：可优化您的提示词结构与效果 html-ppt：将 HTML 内容一键转为可编辑 PPT code-reviewer：对 Python/JS 代码进行风格与安全审查
为什么重要：用户常常并不知晓某个 Skill 的存在，更不了解它的适用边界。主动亮出“底牌”，相当于让隔壁的专家主动推门进来、自我介绍。
第三层：边界哨兵（Boundary Sentinel）
做什么：当用户提出的需求超出当前 Skill 的能力范围时，即时发出提醒。
例如：用 html-ppt 生成完演示文稿后，用户说：“帮我把这份 PPT 部署到线上。” 此时边界哨兵立刻响应：
⚠️ 提示：
html-ppt仅支持格式转换，不具备服务器部署能力。建议切换至deploy-to-vercel或github-pages-deploy等部署类 Skill。
WorkBuddy Visio — Visio 兼容架构图生成器下载使用 draw.io（.drawio 格式）和 SVG 生成兼容 Microsoft Visio 的架构图。当用户需要以下任一场景时触发： - 用于 Visio 或技术文档的架构/系统/网络图 - 带连接标注的分层控制系统图 - 将 draw.io XML 转换为稳定、可嵌入的 SVG - 修复 Visio 或 draw.io 无法打开的故障排查类图表 - 任何需专业级布局且文本可编辑的图表
为什么重要：防止“硬撑式交付”——避免 Skill 强行处理不擅长的任务，导致输出质量下滑、用户信任受损。
四、共享知识池：不让信息断链
三联机制还嵌套了一个隐性支撑层：共享知识池（Shared Knowledge Pool）。
每次 Skill 执行完成后，其产出并非孤立存在，而是自动沉淀为下一环节可继承的关键上下文：
- 文件路径（上一阶段生成的文档/代码的绝对路径）
- 关键结论（核心分析结果，严格限制在 3 条以内）
- 进度摘要（一句话概括当前任务所处阶段）
这有效解决了跨 Skill 协作中最常见的痛点：“换人就丢上下文”。
五、Intent Router：一个「元 Skill」的诞生
三联机制不是纸上谈兵。我们已将其封装为一个真实可运行的 Skill 文件——Intent Router（意图路由引擎）。
它不替代任何具体功能型 Skill，而是专注三件事：
? 看方向（Intent Radar）
? 亮底牌（Capability Snapshot）
? 守边界（Boundary Sentinel）
我们将其定义为「元 Skill」——所有对话默认优先加载，且在每次对话启动及意图发生变更时自动激活。
你可在 WorkBuddy 中直接安装使用，完整 SKILL.md 内容详见本文末尾附件。
六、一个产品建议：对话列表需要管理功能
在落地三联机制的过程中，我发现了一个“看似简单却影响深远”的产品缺陷：
当前对话列表仅以首次输入的截断文本作为标题，完全不支持以下基础操作：
✗ 右键重命名对话名称
✗ 归档或封存已完成会话
✗ 批量删除无效记录
✗ 将相关对话收纳入自定义文件夹
时间一长，几十条对话全显示为模糊的省略号片段，根本无法区分哪条对应哪个工作流、哪个处于待跟进状态。
该问题已由 AI 整理形成结构化反馈，提交至后台产品团队。如果你也深受其扰，欢迎一同发声。
七、写在最后
三联机制的核心理念其实非常朴素：
这是我作为一名“非技术背景用户”的真实踩坑记录。从安装大量 Skill 却束手无策，到意识到调度逻辑才是瓶颈，再到与 WorkBuddy AI 协同设计出三联机制——整个过程让我深切体会到：
AI 工具的价值，不在于它能做什么，而在于它是否清楚自己能做什么、以及该在何时出手。
愿这篇思考，能为你穿越「Skill 海洋」时点亮一盏灯。
本文由 WorkBuddy AI（部分借助马维斯）协助整理与发布，三联机制由「马导 × 马维斯」联合设计。
Intent Router Skill 开源地址：见附件 SKILL.md
