16｜Skills、工具与模型路由：专业能力如何真正进入任务
目标：能区分技能发现、内容加载、工具权限、模型选择和实际能力应用；以少而准确的机制提升质量，而不默认建设多层路由系统。
本章目录
沿着对象与状态理解本章
Prompt、Skill、工具、模型各在不同层起作用；先确认失败点，再改变路由。
下方图解的固定输入在“输入与适用条件”中声明。它用于解释本章机制，不与本章其他独立例子的数值暗中接续。
Skill存在，为什么仍可能完全没用？
从“安装了技能”到“写出了更好的代码”，中间经过什么？
技能像可按需展开的工作说明，不是新训练的一层神经网络。只有它被发现、匹配、读取，并真正影响行动，才可能改善结果。把“加载成功”当作能力已经应用，会把中间几道故障都遮住。
输入与适用条件：通用Skill运行示意，不假定Codex、Claude Code和Copilot的实现细节完全相同。
1 / 6 · 磁盘上有Skill
窄屏可左右滑动图形，或点击“放大图形”。文字解释紧随图后。
文件没在搜索路径里，下一步就可能看不到。
本步状态由图形与说明共同给出。默认静止。用“下一步”看完解释再继续；播放到最后一步自动停止。键盘聚焦播放器后，可用左右键逐步查看、空格播放/暂停。图中颜色辅助区分，含义同时用文字注明。
为什么需要
在需要时提供专业步骤，避免所有规则常驻上下文。
怎样实现
按发现→匹配→加载→执行→验证逐段诊断。
可能的代价与误解
过度加载引入冲突和成本；漏加载导致关键专业要求缺失。
如何判断是否做对
用该加载与不该加载的真实任务双向测路由，再测最终工程质量。
1. 四种路由不是同一个问题
技能路由选择程序性知识；工具路由选择可执行能力；模型路由选择成本/能力配置；任务委派决定控制权与上下文分工。它们可以组合，但不能把一个“相关性分数”同时用于全部决策。
例如一个存储系统任务需要事务专业知识，不一定需要新的子Agent；主Agent可按需读取该Skill。它需要数据库工具，也不代表允许写生产库。它需要深入推理，不一定要先调用一个模型判别器再决定模型。每增加一层都应说明解决哪个实际失败。
Agent Skills规范描述元数据、主体和资源组织；宿主如何发现、加载和执行资源仍需查具体实现。遵循文件格式，只能说明可被识别的条件之一，不等于所有CLI行为完全一致。[N27][N20][N22]
2. 描述应该帮助区分，而不是扩大存在感
一个差描述：“处理所有高级软件工程问题，保证最佳质量。”它几乎匹配任何任务，无法判断边界。更好的描述明确任务信号和专业范围，例如涉及事务隔离、写入一致性、数据迁移时使用，同时说明纯样式修改不需要。
但描述也不能过窄到必须出现准确关键词才加载。用户说“两个请求同时更新后丢了一次修改”，可能需要并发与一致性知识，即使未提“lost update”。回归样本应包含关键词、同义表达、隐含专业需求、容易误判的邻近任务和不相关任务。
路由目标是恰当，不是加载越多越好。漏掉必要技能与多加载无关技能代价不同，需结合任务质量与成本。让所有技能同时加载可以让召回看起来很高，却失去路由意义。
3. 一份专业Skill应该包含什么
专业内容应能改变工程动作。以持久化为例：本地事务不能覆盖远程副作用，超时需要unknown状态，重试前要幂等/对账，版本检查防止陈旧写入，测试应包含崩溃窗口。这样的内容比“考虑安全、性能、可维护性”更有实际价值。
建议核心保持目标、适用条件、关键风险与执行路径，细节资源按需读取。示例应标明约束而不是强迫所有项目采用某框架。对简单修复，不要要求输出完整架构报告；对复杂分布式问题，也不能只给通用检查清单。
代码资源与模板应可运行、可验证；内容中的版本依赖需标注。工具命令不得默认带有不必要权限。一个下载来的Skill也属于需要审查的输入，不能因为它被放进技能目录就获得信任。
4. “已激活”与“有效应用”之间的证据链
至少分成发现、选择、读取、进入上下文、形成动作、结果满足专业要求六步。日志显示选择了Skill，只证明前面部分；模型回答“已遵循”也不是后面部分的证据。
评价应在结果中找专业差异。例如事务Skill是否让实现处理超时未知、避免重复写入、补充对应故障测试；而不是是否在回答中重复“幂等性”三个字。反过来，未显式加载Skill但模型已正确完成，也说明该任务未必需要额外技能成本。
静态测试能检查描述格式、路径、路由边界样本和资源存在；它不能证明真实宿主将其加载并提高代码质量。应把静态合同测试与实际任务A/B分开报告，不用前者替代后者。
5. 模型路由：先知道候选，再谈最优
不同CLI、账号和配置可用模型不同。扩展层不应凭记忆硬编码一组“肯定可用”的模型名称；优先使用宿主可见候选和用户配置。模型能力也依赖工具支持、上下文与输出格式，不能只按单次Token价排序。
一个简洁策略是使用可靠默认模型，只有已知任务约束或明确证据需要时才切换。引入级联时，计算第一次失败的成本、重试成本、上下文交接和错误发现率。如果小模型做错却验证器没发现，升级路径根本不会触发。
推理强度与模型路由应避免双重过度控制。先用真实任务测试默认配置，再讨论某类低风险任务是否可降级。不要创建一个额外分析Agent仅为估计是否需要分析，形成递归成本。
6. 冲突与单一权威
多个Skill同时定义“必须先分析”“立即实现”“一定独立Review”，可能产生冲突。应以用户目标、宿主权限和项目明确约束为准，专业Skill提供条件性建议，避免互相争夺顶层流程控制。
工程简报或任务状态若存在，应作为当前目标的集中入口，其他文件引用它而不复制多份版本。不是所有项目都需要正式Brief；但一旦信息分散导致冲突，应通过减少权威副本解决，而不是再加一个协调层。
技能召回变高但误加载也变高，算不算优化
输入与条件。10个需要并发技能的任务中旧系统命中8，新系统命中10；另90个不需要的任务中旧误触发2，新误触发30。
| 步骤与对象 | 内部动作 | 中间结果 / 新状态 |
|---|---|---|
| 1必要召回 | 旧80%，新100% | 确有改善。 |
| 2触发精确率 | 旧8/(8+2)=80%；新10/(10+30)=25% | 大量无关任务被增加流程。 |
| 3成本观察 | 30个误触发任务多读资料和审查 | 可能拖慢多数普通工作。 |
| 4分错因 | 看漏掉的2个正例为何不匹配 | 尝试定向边界修复而非泛化“所有开发”。 |
| 5选方案 | 同时比较任务成功与效率 | 不能用一个召回指标宣布全面更好。 |
把过程连起来。技能路由要兼顾该用时用与不该用时不用，指标需要同时约束。
边界与反例。数据是教学混淆矩阵，非任何真实rd-skills测评结果。
依据与适用范围：[EVALS]。示例输入和场景由本书明确设定。
7. 验收实验
选择一组真实任务，比较无技能、旧技能、新技能，在相同宿主/模型/工具下测专业缺陷、功能成功、额外阅读与总耗时。保留明确误加载与漏加载样本；对新方案做移除消融，证明收益来自哪部分内容。
验收题：新版路由准确率提高，但生成代码质量下降，是否合并？不能仅按路由指标合并。可能选对技能但技能内容过时，或加载成本挤占了源码证据。最终目标是工程任务，不是路由分类器本身。