一个 Data Agent 同时会做指标设计、异动诊断、质量检查、Notebook、图表、看板和报告，听起来很强。但能力越多，越容易出现一种隐蔽失败：每个工具都调用了，真正的问题却没有被负责。
Data Analytics Skills 的 Index 值得看，不是因为它列出了 15 个 Skill，而是因为它承担了四件更接近控制面的工作：判断任务是否属于数据分析、选择谁负主责、处理来源冲突，以及定义什么叫完成。
第一道门：这真的是数据分析任务吗
“做一份报告”“研究一下市场”“验证这个观点”都不自动等于数据分析。判断标准应该是：结论是否依赖结构化记录、数值指标或可计算证据；用户是否需要据此做产品、运营或资源决策。
这道资格门很重要。普通写作被误路由到分析链，会制造不必要的查询和伪精确；真正的量化问题被当作写作任务，又会跳过数据验证。
主 Skill 只能有一个
复杂任务可以调用多个 Skill，但最好只有一个对最终问题负责。
| 请求 | 主 Skill | 支持 Skill | 完成标志 |
|---|---|---|---|
| “周活为什么跌了？” | metric-diagnostics | 业务背景、报告 | 原因链有证据，报告已检查 |
| “这张表能用于月报吗？” | analyze-data-quality | 数据验证 | 风险、缺口和使用条件明确 |
| “建立持续经营看板” | build-dashboard | 指标设计、可视化 | 口径、交互和刷新均可验证 |
主 Skill 决定问题如何收敛；支持 Skill 负责补背景、验证、表达或发布。若每个 Skill 都只是“帮一点忙”，就没人对遗漏负责。
工具可见，不等于获得授权
路由器还需要区分三件事：运行环境提供了什么能力、用户有权使用什么能力、当前任务允许执行到哪一步。看到数据库连接器，不能推断可以查询所有表；能够生成网站，也不代表这次任务允许发布。
因此，能力路由与交付路由应分开：前者决定用什么方法解决问题，后者决定成果能否写入文件、站点或外部系统。
冲突来源不能被悄悄合并
数仓、BI、指标文档、语义层、会议纪要和旧报告可能同时出现一个指标，但权威性、新鲜度和粒度不同。路由前至少要回答：哪个来源控制定义？哪个来源控制当前数值？冲突是否会改变结论？
如果无法裁决，正确动作是保留冲突并指出需要谁确认，而不是挑一个更顺手的数字。
完成门比“已经算完”更严格
分析结束至少要经过四项检查：主 Skill 确实执行；关键结论能够追到来源；方法、数字和图表经过验证；约定的制品真实存在、可打开并适合接收者使用。
这正是 Index 最实用的设计：入口有资格门，中间有责任路由，出口有完成门。数据 Agent 的可靠性，不只取决于模型会不会算，也取决于系统能否拒绝错误任务、选择最小责任链，并在证据不足时不假装完成。
设计自己的路由器时
不要从“有哪些工具”开始列菜单。先为高频请求定义主责任、必要上下文、允许动作、验证条件和失败去向。工具可以替换，责任契约不应该随提示词漂移。