| name | databrain-datalab-analyst |
| description | 经分Datalab 报表/知识库**兜底**分析 skill。**不是经分指标查询的首选**——一般经分（dashboard）问题必须先走 `databrain-dashboard-service`。仅在以下情况启用本 skill：(1) 用户**直接给了 Datalab 报表 URL / dashboard_id / `报表id@图表id`**；(2) `databrain-dashboard-service` 已尝试且返回 unsupported metric / 空数据 / MCP describe 找不到 cube 的明确失败。 非白名单游戏（不在 `dashboard_white_games`）**禁止**用本 skill 兜底。 |
| version | 3.11.0 |
| author | Datalab Team |
| permissions | 网络访问权限 |
0. Skill Scope（必读 · 与 dashboard-service / summarize 协作）
0.1 路由前置（硬约束，禁止越过）
- 本 skill 不是经分查询的入口。涉及白名单游戏（在
agent_context.dashboard_white_games 中）的指标查询，必须先调 databrain-dashboard-service，只有在 dashboard-service尝试过查数据，但明确返回 unsupported / 空数据 / 找不到 cube 后，才允许走本 skill 兜底。
- 非白名单游戏禁用本 skill。游戏不在
dashboard_white_games 中 → 走 databrain-intelligence，不要回退到 datalab。
- 直接命中场景（无需先试 dashboard-service）：用户把 Datalab 报表 URL / dashboard_id /
报表id@图表id 直接贴在问题里 → 直接 full_report；用户明确要求"看这个报表/图表"。
0.2 game_code 来源
直接从 agent_context.dashboard_game_code_and_filters[<game_name>].game_code 取值。仅当上下文缺失时，才用 search_game 兜底。
⚡ TL;DR
- 脚本入口:
python scripts/call_api.py <action> [参数]
- 常用 action:
dashboard_search, dashboard_overview, full_report, chart_data, knot_search
- 环境变量:
DATABRAIN_TOKEN(必填), DATABRAIN_HOST(必填), DATABRAIN_DISPLAY_HOST(必填)
- 最高频场景: 用户给了报表链接/ID → 直接
full_report（1 次调用搞定）
python scripts/call_api.py dashboard_search --game_code "gstm" --keyword "留存"
python scripts/call_api.py full_report --dashboard_id "<id>" --question "用户的问题"
python scripts/call_api.py full_report --dashboard_url "<url>" --question "用户的问题"
python scripts/call_api.py full_report --dashboard_id "<id>" --chart_ids '["chart_id_1","chart_id_2"]'
python scripts/call_api.py full_report --chart_refs '["dashboard_id_1@chart_id_1","dashboard_id_1@chart_id_2"]'
python scripts/call_api.py parse_refs --chart_refs '["dash1@chart1","dash1@chart2","dash2@chart3"]'
python scripts/call_api.py multi_report --chart_refs '["dash1@chart1","dash1@chart2","dash2@chart3"]'
python scripts/call_api.py dashboard_overview --dashboard_id "<id>"
python scripts/call_api.py chart_data --dashboard_id "<id>" --chart_id "<id>" --filters '[...]'
python scripts/call_api.py dashboard_data --dashboard_id "<id>" --chart_ids '["chart_id_1","chart_id_2"]'
python scripts/call_api.py dashboard_data --chart_refs '["dash1@chart1","dash1@chart2"]'
python scripts/call_api.py knot_search --game_code "gstm" --query "留存下降 归因分析"
- 禁止 Agent 自己写 curl/requests/subprocess 代码调 API
- 禁止 猜测 filter column 名或 value 值（必须从 dashboard_overview 的
available_filters 获取 column，从 available_values 匹配 value）
- 禁止 反向匹配：不得因为某筛选器
available_values 含有某值就自动加上该筛选器，只有用户明确提及的维度才加
🗺️ 完整决策树（唯一权威版）
⚠️ 决策树前置：先按 §0.1 路由前置判断本 skill 该不该被调用。被调用后才走下表。
本 skill 被路由进来后：
│
├── 用户给了报表 URL / dashboard_id / chart_refs（报表id@图表id）？
│ └── ✅ 是 →【路径 C】直接 full_report，不走 MCP 知识库；URL 自带授权，不再判白名单
│
├── 白名单游戏 + dashboard-service 已尝试且明确失败（unsupported / 空数据 / 找不到 cube）？
│ │
│ ├── game_code 以 "gst" 开头 → 【路径 A: Knot MCP 知识库前置 + 数据分析】
│ │ ├── ① knot_search（用用户问题作 query，获取相关报表/指标定义/方法论）
│ │ ├── ② 根据 MCP 返回 + dashboard_search 定位目标报表
│ │ ├── ③ dashboard_overview 获取报表结构
│ │ ├── ④ full_report 获取数据
│ │ └── ⑤ 输出"知识 + 数据"融合分析（格式交给 summarize 收尾）
│ │
│ └── 其他白名单游戏 → 【路径 B: 标准数据分析（无 MCP）】
│ ├── ① dashboard_search 搜索匹配报表
│ ├── ② dashboard_overview 获取报表结构
│ ├── ③ 自动选择最匹配报表 + full_report
│ └── ④ 数据分析 + 末尾提示其他候选报表
│
├── 用户问通用概念（无具体业务，无报表 ID）？
│ └── 查 references/ 本地文件直接回答
│
└── 上下文缺 game_code 且用户没给报表 URL/ID？
└── 兜底调一次 `search_game`，0 结果即放弃，不要循环试错
📋 前置条件
| 变量名 | 是否必填 | 说明 |
|---|
DATABRAIN_TOKEN | 必填 | 认证 token 原始值（不含 Bearer 前缀），由上层服务动态传入 |
DATABRAIN_HOST | 必填 | API 主机地址，由上层服务动态传入 |
DATABRAIN_DISPLAY_HOST | 必填 | 系统链接展示域名 |
MCP 知识库配置
| 配置项 | 值 | 说明 |
|---|
| 知识库检索方式 | 通过 Datalab 后端代理（/api/v1/datalab/skill/knot_search） | 后端根据 game_code 自动从七彩石获取对应 knot_uuid |
| 认证方式 | 复用 DATABRAIN_TOKEN（Bearer 认证透传） | 无需额外配置 Knot Token |
🎯 MCP 知识库接入游戏白名单
| game_code 前缀 | MCP 知识库 | 分析路径 |
|---|
gst | ✅ 已接入 | 知识库增强分析（MCP 检索 + 报表数据） |
| 其他 | 未接入 | 标准数据分析（仅报表数据，跳过 MCP） |
判断规则：从 agent_context.dashboard_game_code_and_filters[<name>].game_code 取值；gst* 走路径 A（MCP 前置），其他白名单游戏走路径 B（标准）。唯一例外：用户直接给了报表 URL/ID → 路径 C，不走 MCP。
Agent 行为准则
🔴 核心禁令（数据正确性硬约束）
调用方式：
- Agent 自己写
curl/requests.post/subprocess 代码调 API（必须通过 python scripts/call_api.py）
- 多轮逐个执行 chart_data（用 full_report 批量获取；如只需部分图表，传
--chart_ids 指定）
筛选器拼接（直接影响返回数据正确性，必须遵守）：
- 猜测 filter column 名（必须从
dashboard_overview.available_filters[].column 获取）
- 猜测 filter value 值（必须从
available_filters[].available_values 中匹配，不得自行编造值）
- 反向匹配：不得因为
available_values 中含某个值就自动添加该筛选器；筛选器使用必须由用户明确意图驱动
- 强行拼接报表不存在的筛选器：只使用
available_filters 中存在的 column；匹配不上就不加
- 循环试错：不得对同一个不存在的筛选器尝试多种 column 名变体（country → region → geo → ...），一次失败即放弃，先不带该条件查询，再从返回数据中筛选
数据真实性（零容忍）：
- 编造/捏造任何数值、指标、日期、趋势
- 输出未从
call_api.py 返回 JSON 中读到的数据；所有数字必须有原始出处
- 数据不完整时推断、补全或捏造数值
- 探索性代码（
print(data.keys())）/ 自行 groupBy 求和求平均（这会改变数据含义）
- 去掉负号：负数必须保留负号原样（如
-3.2%、-$1,200），不得 abs 或省略
- ✅ 查询返回 0 行 / 异常 → 必须如实说明"未查到数据"，不得虚构内容
- ✅
available_values 是参考值（截断 ≤100 个），不代表全量；用户明确指定的值即使不在列表里也可尝试
🚀 性能优化规则
- 所有 API 调用必须通过
python scripts/call_api.py <action> 完成
- 用
full_report 一次完成 report_log + overview + dashboard_data
- 不要重复调用同一个 API；错误不要重试超过 1 次
- 空值防御：API 返回数组中的元素可能为
None，遍历时 if item is not None
🎯 模糊查询自动选择规则
| 场景 | 行为 |
|---|
| 明确报表链接 URL / dashboard_id | 直接 full_report |
报表id@图表id 引用（chart_refs） | 直接 full_report --chart_refs（自动解析） |
| 报表名称（如"5_4 合抢玩法参与"） | 搜索确认后直接获取 |
| gst 游戏 + 指标/关键词 | 先查 MCP 知识库 → 用知识库推荐的报表 → full_report |
| 非 gst 白名单游戏 + 指标/关键词 | 自动选第一个匹配报表，末尾提示其他 |
| 模糊描述（如"看下用户数据"） | gst 走 MCP 前置；其他自动选第一个 |
选择优先级（gst 游戏）：MCP 知识库推荐 > 名称完全匹配 > 图表数量更多 > 搜索排序靠前
选择优先级（非 gst）：名称完全匹配 > 图表数量更多 > 搜索排序靠前
特殊情况：搜索 0 结果 → dashboard_list 翻页；用户说"换一个" → 选下一个；用户说"全部" → 逐个执行，超 3 个提示分批。
🔌 接口清单
| # | 接口 | 用途 |
|---|
| 0 | report_log | Agent 内部静默调用，不要向用户提及 |
| 1 | knot_search (Datalab 代理) | 知识库语义检索（需要 game_code） |
| 2 | search_game | 业务名称模糊搜索 → game_code |
| 3 | dashboard_list | 报表列表（分页） |
| 4 | dashboard_search | 关键词搜索报表 |
| 5 | dashboard_overview | 报表结构（图表列表 + 筛选器），获取数据前必须先调 |
| 6 | chart_data | 单图表数据（支持筛选 + 聚合） |
| 7 | dashboard_data | 报表图表数据（支持 chart_ids / chart_refs 指定图表，不传则全量） |
| 8 | parse_refs | 🆕 本地解析 报表id@图表id 引用列表（不调 API） |
| 9 | multi_report | 🆕 多报表批量查询：chart_refs 含多个 dashboard 时自动循环 |
所有 HTTP 接口：Authorization: Bearer $DATABRAIN_TOKEN，Base URL: ${DATABRAIN_HOST}
⏱️ 理想执行路径
game_code 默认来自 agent_context.dashboard_game_code_and_filters（§0.2）。
路径 A: gst 游戏 + 关键词（目标 ≤5 轮）— MCP 知识库前置
轮次 1: read_file SKILL.md（首次进入）
轮次 2: knot_search（用 agent_context 里的 game_code，用户问题作 query；获取报表信息 + 业务知识）
轮次 3: 根据 MCP 结果 + dashboard_search 定位报表 → dashboard_overview
轮次 4: full_report（获取数据）
轮次 5: 输出"知识 + 数据"融合的结构化结果（格式由 summarize 收尾）
路径 A 核心逻辑：MCP 知识库先行，用知识库返回的报表信息指导报表选择，而非盲目搜索后再补充知识。
路径 B: 白名单非 gst 游戏 + dashboard-service 兜底场景（目标 ≤4 轮）
轮次 1: read_file SKILL.md（首次进入）
轮次 2: dashboard_search（用 agent_context 里的 game_code）
轮次 3: dashboard_overview（最多并行 5 个）→ 自动选择 → full_report
轮次 4: 输出结构化数据分析结果
路径 C: 直接给报表 ID/URL（目标 ≤2 轮）
轮次 1: read_file SKILL.md（首次进入）
轮次 2: full_report（不走 MCP）
路径 D: 纯知识查询（目标 ≤3 轮）
轮次 1: read_file SKILL.md（首次进入）
轮次 2: gst → knot_search；非 gst → references/
轮次 3: 输出知识解答
📖 完整使用流程
🚀 最常用：用户给了报表链接/ID
python scripts/call_api.py full_report \
--dashboard_id "c1ef70ac094263d1e8cd06ade2876b31" \
--question "分析报表"
full_report 返回结构（stdout JSON）：
{
"steps": [
{
"step": "report_log"
},
{
"step": "dashboard_overview"
},
{
"step": "dashboard_data"
}
],
"overview": {
"dashboard": {},
"charts_summary": [],
"available_filters": []
},
"data": {
"dashboard": {},
"charts": []
},
"validation"
validation.all_charts_received: true → 直接生成报告；false → 降级逐图 chart_data
Step 1：game_code 获取
从 agent_context.dashboard_game_code_and_filters[<game_name>].game_code 直接取值。仅在 agent_context 缺失或业务名找不到时，兜底执行：python scripts/call_api.py search_game --game_name "<名称>" --top 3（不区分大小写，0 结果即放弃，不要改大小写重试）。
Step 2：知识库检索（仅 gst 游戏，前置执行）
⚠️ gst 游戏必须先查 MCP 知识库，用知识库返回的报表信息指导后续报表选择和数据分析。
通过 Datalab 后端代理调用 Knot MCP 知识库（后端自动根据 game_code 从七彩石获取对应 knot_uuid）：
python scripts/call_api.py knot_search --game_code "gstm" --query "留存下降 归因分析 原因" --top_k 5
MCP 检索结果中可能包含：
- 相关报表名称/ID → 直接用于 full_report
- 指标定义和计算口径 → 融入分析报告
- 归因方法论/最佳实践 → 指导分析方向
- 业务基准值 → 用于异常判断
🏷️ MCP 状态 Tag（自动化测试用，后期可移除）：knot_search 返回的 _mcp_status 字段标识 MCP 请求是否成功。脚本会在 JSON
输出前通过 stderr 打印状态行：
- 成功：
[MCP_OK] MCP 知识库请求成功
- 失败：
[MCP_FAIL] MCP 知识库请求失败原因
自动化测试脚本可捕获 stderr 第一行判断 MCP 连通性。
Step 3：报表发现 + 数据获取
python scripts/call_api.py dashboard_search --game_code "gstm" --keyword "留存"
python scripts/call_api.py dashboard_overview --dashboard_id "<id>"
python scripts/call_api.py full_report --dashboard_id "<id>" --question "用户的问题"
单图表查询（带筛选和聚合）
python scripts/call_api.py chart_data \
--dashboard_id "<dashboard_id>" \
--chart_id "<chart_id>" \
--filters '[{"column":"dtstatdate","operation":"between","value":["2026-03-11","2026-03-17"]}]' \
--aggregation '{"enabled":true,"group_by":["date"],"metrics_agg":"sum","top_n":50}'
🔑 Filters 参数格式详解
⚠️ 筛选器拼接原则（必须遵守）：
- 只拼用户明确提及的维度：先从用户问题中提取筛选意图（如"安卓"→系统、"东南亚服"→区服），再与
available_filters[].column + filter_name 做匹配，能匹配上的才加入 filters
- 禁止反向匹配：❌ 不得因为某个筛选器的
available_values 中恰好包含某个值（如数字"1"），就反向推断用户想筛选该维度。筛选器的使用必须由用户意图驱动，而非由可选值驱动
- 匹配不上就不加：如果用户提到的维度在
available_filters 中找不到对应 column，不要强行拼接，也不要反复尝试不同写法
- 利用
available_values 精准匹配值：确定要使用某个筛选器后，再从其 available_values 中选取与用户描述最匹配的值。注意：这一步是"确定用哪个筛选器"之后的值选择，不是用来决定"是否使用该筛选器"
- 从返回数据中筛选：匹配不到筛选器时，先不带该条件查询，再从返回的数据中查看是否有符合用户要求的数据行
- 禁止循环试错：不得对同一个不存在的筛选器尝试多种 column 名变体（如 country → region → geo → ...），一次匹配不上即放弃
💡 正确的筛选器决策流程：
用户问题 → 提取筛选意图关键词 → 与 filter_name/column 匹配 → 确定使用哪些筛选器 → 从 available_values 选值
错误的决策流程（禁止）：
遍历所有 available_values → 发现某个值像是和用户问题有关 → 自动添加该筛选器
available_filters 返回结构（dashboard_overview / full_report 返回）：
{
"filter_name": "国家",
"column": "country",
"column_type": "string",
"available_values": ["CN", "US", "JP", "KR", "TW"],
"current_value": ["所有国家"],
"date_type": "",
"description": "按国家筛选数据"
}
💡 available_values 使用指南：
- ⚠️
available_values 仅为参考值，非全量数据：由于数据量可能很大，返回的可选值列表经过截断（最多 100 个），不代表该字段的所有可能值
available_values 的用途是帮你了解该字段的值长什么样、格式是怎样的，而不是作为唯一可选范围- 只有当你已经确认用户意图涉及某个筛选维度时，才参考
available_values 来确定值的格式和写法
- date 类型筛选器没有
available_values，直接使用用户指定的日期范围
📐 匹配精度三级判断（按优先级从高到低）：
| 级别 | 条件 | 处理方式 | 示例 |
|---|
| ✅ 精准命中 | 用户描述与 available_values 中的值完全一致或一一对应 | 直接使用原始值 | 用户说"安卓" → available_values 含"安卓" → 用"安卓" |
| ⚠️ 模糊但可信 | 用户描述是某个值的同义词/别名/翻译，且该筛选器维度与用户意图完全吻合 | 使用匹配到的原始值 | 用户说"Android" → filter_name="系统"，available_values 含"安卓" → 用"安卓" |
| 似是而非 | 用户描述与某值语义相关但不等价，或用户描述的粒度/维度与筛选器不同 | 不使用该筛选器，改为从返回数据中分析 | 用户说"泰国" → filter_name="区服"，available_values 含"东南亚服" → 不等价，不加 |
💡 "似是而非"的判断标准：
- 用户的描述和可选值不在同一粒度（如"泰国"是国家粒度，"东南亚服"是区服粒度）→
- 用户的描述只是可选值的一个子集/部分含义（如"新手"只是"1-10级"的子集）→
- 用户的描述需要额外推理/假设才能对应到某个值 →
- 只有直接对等、无需推理的匹配才是合法匹配 ✅
🔄 匹配失败的降级策略：
- 匹配失败但用户明确指定了值 → 可以参考
available_values 的格式规律，用用户描述的值直接尝试（因为列表有截断，用户要的值可能存在但未返回）
- 匹配失败且无法推断格式 → 不添加该筛选条件，先不带该筛选查询数据，再从返回结果中人工筛选
⚠️ 反向匹配陷阱（必须避免）：
- 用户说"近一周角色升级" → 只需加日期筛选，不要因为"注册天数"筛选器有
available_values: ["1","2","3"...] 就自动加上 注册天数=1
- 用户说"哪个等级人数最多" → 这是对返回数据的分析需求，不是筛选条件
- 判断标准：用户是否明确指定了某个维度的具体值？如"安卓系统"（明确指定系统=安卓）✅ vs "升级情况"（没有指定注册天数）❌
请求结构体定义（每个 filter 对象）：
{
"column": "字段名",
"operation": "操作符",
"value": []
}
🚨 value 字段始终是数组 []，无论任何 operation，都不能传单个值（如 "value": "2026-03-11"）
💡 数字类型兼容：数值型 value 传数字 [100] 或字符串 ["100"] 均可，底层通过 AnyToString() 自动转换。推荐直接传数字字面量（无引号）。
各操作符对应的 value 格式：
| operation | 说明 | value 格式 | 示例 |
|---|
between | 区间（日期/数值） | [起始值, 结束值]（长度必须=2） | ["2026-03-11", "2026-03-17"] |
include | 包含（IN） | [值1, 值2, ...]（1~N 个） | ["CN", "US", "JP"] |
exclude | 排除（NOT IN） | [值1, 值2, ...]（1~N 个） | ["bot", "test"] |
greater | 大于 | [阈值]（长度=1） | [100] |
less | 小于 | [阈值]（长度=1） | [50] |
greaterOrEqual | 大于等于 | [阈值]（长度=1） | [0] |
lessOrEqual | 小于等于 | [阈值]（长度=1） | [1000] |
equal | 等于 | [值]（长度=1） | ["active"] |
notEqual | 不等于 | [值]（长度=1） | ["deleted"] |
notNull | 非空 | []（空数组） | [] |
null | 为空 | []（空数组） | [] |
日期筛选示例（最常见场景）：
[
{
"column": "dtstatdate",
"operation": "between",
"value": [
"2026-05-13",
"2026-05-19"
]
}
]
多条件筛选示例：
[
{
"column": "dtstatdate",
"operation": "between",
"value": [
"2026-05-13",
"2026-05-19"
]
},
{
"column": "country",
"operation": "include",
"value": [
"CN",
"US"
]
},
{
"column": "level",
"operation": "greaterOrEqual",
"value": [
10
]
}
]
聚合参数格式
{
"enabled": true,
"group_by": [
"date"
],
"metrics_agg": "sum",
"top_n": 50,
"sort_by": "字段名",
"sort_order": "desc"
}
错误处理
| 错误场景 | 处理方式 |
|---|
| 非白名单游戏 | 跳过 MCP，走标准数据分析 |
| knot_search 失败 | 提示知识库暂时不可用，继续走标准数据分析 |
| 知识库无结果 | references 兜底 + 报表数据 |
| HTTP 401/403 | 提示检查认证配置 |
| HTTP 500 | 提示稍后重试 |
| 超时（检索>15s/数据>90s） | 取消 + references 兜底 |
| game_code 搜索无结果 | 提示确认名称 |
| row_count=0 | 展示"暂无数据" |
📊 图表类型与数据结构映射
详细映射见 references/chart_data_mapping.md，以下是速查表。
| chart_type | 核心数据字段 | 取值方式 |
|---|
LineChart | line_chart.series_data[].data[] | X轴: x_axis_data[] |
Table | table_data[] | 每行: {列名: {value: "值"}} |
BarChart | bar_charts.series_data[].data[] | X轴: x_axis_data[] |
BigNumberChart | big_number_chart.value | 对比: time_comparisons[] |
StackBarChart | stack_bar_chart.series_data[] + table_data | |
PieChart | chart_sum_data[0].指标名[] | ⚠️ 必须 if item is not None |
EventLineChart | event_line_chart + event_list | |
HorizontalBarChart | horizontal_bar_charts[].series[].data[] | |
TrendChart | trend_metric(大数字) + line_chart(趋势) | |
MixedChart | mixed_chart.series_data[] | |
Map | map_charts[].map_chart_value[] | |
WordCloud | word_cloud.data[] | |
DimTrend | trend_metric + line_chart + dimension | |
PercentStackBarChart | percent_stack_bar_chart + table_data | |
完整字段结构、Series 通用格式、详细展示规范 → references/chart_data_mapping.md
📊 输出形态（仅数据正确性约束 · 格式由 summarize 收尾）
用户最终看到的 Markdown / 标题 / emoji / 章节骨架 / 字段简化引用块 / 报告开头格式 / 表格分块全部由 databrain-summarize 在 phase B 决定（参考 markdown_layout.md / simple.md / complete.md）。本 skill 在 phase A 只输出"数据正确"的中间产物，不强制格式模板。
数据正确性硬约束（违反即视为输出错误）
| # | 约束项 | 要求 |
|---|
| 1 | 数据来源 | 所有数值/日期/趋势必须能在 call_api.py 返回 JSON 中找到原始出处；找不到就说"未查到"，不得编造 |
| 2 | 零值/空数据 | 全 0 行可隐藏（避免噪声），空 row_count 必须如实说明"暂无数据"，不得静默删除整图 |
| 3 | 负号保留 | 负数原样展示（如 -3.2%、-$1,200），禁止取绝对值或省略 - |
| 4 | 不自行聚合 | 不得 groupBy / 求和求平均改变数据含义；如需聚合，通过 chart_data --aggregation 让后端做 |
| 5 | 不反向匹配筛选器 | 不因 available_values 中存在某值就自动加该筛选器；筛选器使用必须由用户明确意图驱动 |
| 6 | 不强拼不存在筛选器 | 用户提到的维度在 available_filters 中找不到 column → 不加该筛选；先不带条件查询，再从返回行中筛 |
| 7 | 数据完整性 | 数据不完整时不推断/补全；如某 chart 数据缺失，明确指出哪个图表缺失而非编造 |
| 8 | 内部细节不外泄 | 不主动向用户提"打点/上报/记录日志/report_log"；这些是 phase A 内部行为 |
完整图表字段结构与各图表类型字段映射仍可参考 references/chart_data_mapping.md（仅作字段映射参考，不再强制 emoji / 章节标题 / 字段简化引用块格式）。
📚 知识库参考
Agent 执行时可按需加载 references/ 下的文件（仅作字段/参数/术语参考，不再约束输出格式）：
| 文件 | 用途 |
|---|
chart_data_mapping.md | 图表类型完整字段映射（取数用，不约束格式） |
query_examples.md | 用户提问示例 & 参数拼接指南 |
metrics_dictionary.md | 英文字段名 → 中文翻译 |
chart_types.md | 图表类型说明（取数用） |
filter_operations.md | 筛选操作符详解 |
business_glossary.md | 业务术语解释 |
common_issues.md | 常见问题排查 |
⚠️ output_example.md 已不再作为输出强制模板（输出由 databrain-summarize 决定），保留仅供历史参考。
与其他 Skill 的协作：
- 首选经分查询 →
databrain-dashboard-service（本 skill 是 dashboard-service 的兜底，不是替代）
- 非白名单游戏指标 →
databrain-intelligence
