Skill自动调度路由器

问题：技能多了，Agent 也会犹豫

当你的技能库里有 2700+ 个技能时，Agent 面对一个任务的第一反应往往不是"马上动手"，而是"我该用哪个？"。这种犹豫不是懒惰——而是合理的不确定。选错了 Skill，意味着走错方向后还要回溯；选错了 Agent，可能让擅长代码的 agent 去做安全审计；选错了 Model，要么浪费算力，要么推理深度不够。

更隐蔽的成本是上下文污染。每次手动选择都在消耗宝贵的对话窗口，让 Agent 的注意力从"解决问题"转移到"判断该调谁"。

三问分类：5 秒定方向

Skill Router 的核心机制是在执行非平凡任务前，运行一个极轻量的三问分类，把任务映射到三类路径之一：

• BROKEN（故障修复）：当信号是错误、崩溃、测试失败、安全漏洞或生产事故时，路由到 systematic-debugging、security 等对应技能，并指定 Agent 和 Model 组合。例如遇到测试失败，会先跑 test-runner，再进入 systematic-debugging，由 test-runner Agent + Sonnet 模型执行，且不启用深度思考。

• BUILD（功能构建）：多文件改动或新功能开发。典型路径是先 brainstorming 再 writing-plans，最后进入领域技能。比如开发 UI 组件走 frontend-design，建数据库 Schema 走 db-expert。

• OPERATE（日常运维）：重构、加测试、性能优化、代码审查、部署。每个子任务都有对应的技能和 Agent 组合，比如性能优化走 perf + optimizer Agent。

输出格式是固定的契约行 [skill-router]，后面跟 ▶ 标记和 Skill + Agent + Model + Thinking 四元组。Thinking 深度从 none 到 ultrathink 分为四档，取决于任务复杂度。

边界与注意点

不是所有任务都需要路由。一行修复、读代码、回答事实性问题、单条命令执行、三步以内的操作——这些直接做就行，跳过路由。

静默规则很重要。当没有匹配到分类信号时，路由输出是静默的——这意味着对话可能是简单的、探索性的或微不足道的。不要把这种沉默解读成"应该走 OPERATE 重构"。同理，显式 slash 命令（如 /ship prod）也跳过路由，因为用户已经自己选了技能。

完成门是硬约束。任何"完成"声明之前，必须通过 verification-before-completion。这是防止 Agent 自欺欺人的最后一道防线。

输出格式不可改写。[skill-router] 行和 ▶ 标记是可被 grep 的契约，后续工具链可能依赖它来解析路由决策。改了格式等于破坏了集成协议。

为什么值得这 5 秒

很多工程师的直觉是"这很简单，直接做"。但 SKILL.md 里专门警告了这个陷阱：跳过路由看似省了 5 秒，实际上可能浪费数小时在错误的路径上回溯。而运行路由的成本是固定的 5 秒——判断错了，输出静默，没有任何副作用；判断对了，方向从一开始就是正确的。