Menu
当监控平台、日志平台、值班对话或变更后异常暴露出某个资源、域名、IP 或业务现象时，围绕告警目标自动展开上下游拓扑，检查同一拓扑内的关联异常并归并根告警、派生告警和噪声告警，输出根因候选、影响范围和结构化诊断摘要。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
ByteHouse 集群诊断，健康检查，慢查询分析和负载分析的工具
ByteHouse 数据质量检查工具。当用户提供集群连接信息、数据库名和表名，需要检查排序键、主键和分区键所使用的列的空值、零值情况，是否存在异常分布，以及排序键、主键的重复情况时，使用此技能。
通过本地 Python CLI 和 OpenAPI 客户端管理、排查火山云手机资源。适用于查询实例和资源、截图、执行命令、查看任务、检查应用、主机和机房容量、标签、DNS、路由，以及操作已授权的测试云手机实例。
简化版数据库工具，适用于火山引擎 RDS 实例以及自建数据库的元数据查询、SQL 执行、nl2sql 等场景。当用户需要查询火山引擎 RDS 实例以及自建数据库表结构、查看数据、执行 SQL 或将自然语言转换为 SQL 时使用此 skill。
火山云通信智能外呼 Skill. 当用户希望「让 AI 机器人帮忙打电话办事」(如订餐厅、催收、回访、问卷) 时调用. 内部依次走话术查询 → 任务创建 → 任务结果查询.
火山云通信话单 / 录音查询 Skill. 用户问「查一下 callId xxx 的话单」「下载 xxx 的录音」时调用. 注意TOP 接口仅支持按 CallId 精确查询, 不支持按 SingleOpenId/手机号/时间区间反查.
| name | byted-volcengine-rootcause-analyzer |
| description | 当监控平台、日志平台、值班对话或变更后异常暴露出某个资源、域名、IP 或业务现象时，围绕告警目标自动展开上下游拓扑，检查同一拓扑内的关联异常并归并根告警、派生告警和噪声告警，输出根因候选、影响范围和结构化诊断摘要。 |
这个 Skill 是一个面向故障场景的编排层。它不把告警当作一条孤立事件处理，而是把告警、资源拓扑、同时间窗异常和运行时证据拼成一个完整的故障上下文。
它的职责是：
这个 Skill 的目标不是“解释某一条告警”，而是把分散异常收敛成一条业务链路问题，尽快逼近真正的故障源头。
当前版本重点覆盖以下能力：
以下能力可以作为未来扩展输入，但当前不是必须步骤，也不能假设一定可用：
一句话区分：
byted-volcengine-rootcause-analyzer：负责把“告警 + 拓扑 + 异常归并 + 证据”串成诊断结论这个 Skill 依赖以下四个已有 Skill：
byted-volcengine-topology-builder职责：
topology.json、topology.md、图文件等基础拓扑数据边界：
适合什么时候调用：
byted-volcengine-topology-analyzer职责：
边界：
适合什么时候调用：
byted-volcengine-cloudmonitor职责：
边界：
适合什么时候调用：
byted-volcengine-api-assistant职责：
ServiceCode边界：
适合什么时候调用：
当出现以下场景时，应主动触发这个 Skill：
即使用户没有明确说“拓扑”或“告警归并”，只要问题本质是围绕一个故障现象收敛上下游异常并定位真正根因，就应该触发。
优先从告警文本、日志摘录或自由描述中提取以下字段：
如果文本里没有显式字段，也要继续识别：
如果缺少资源 ID，也允许从域名、IP 或现象描述反推候选资源，但最终回答必须显式标记不确定性。
先把原始输入整理为结构化对象，例如：
{
"account": "xx",
"policy_name": "xx",
"region_name": "华北2（北京）",
"region_id": "cn-beijing",
"severity": "严重",
"project": "mysite",
"alarm_time": "2026-05-09 17:26:11",
"time_window": "alarm_time +/- 15m",
"product": "clb",
"resource_id": "clb-xxx",
"instance_id": "",
"listener_id": "lsn-xxx",
"domain": "",
"ip": "",
"metric_name": "监听器/后端服务器异常个数",
"current_value": "AVG(xxx)[1m]:1Count",
"symptom": "",
"related_alerts": []
}
如果某些字段缺失，要显式标记为“缺失信息”，不要自行脑补。
先判断这次故障的主起点更接近哪一层：
domain、eip、clb、alb、listenerrule、server_groupecssecurity_group、subnet、vpc判断原则：
资源 ID、实例 ID、监听器 ID，要区分“告警对象”和“潜在根因对象”围绕主告警节点获取上下游拓扑。优先级如下：
byted-volcengine-topology-builderbyted-volcengine-topology-analyzer 展开目标节点的上下游、入口链路和受影响资源这一步的目标不是“画图展示”，而是为后续做告警归并建立一个可分析的故障上下文。
在已展开的拓扑范围内，检查同一时间窗内其他资源是否也有异常信号。
异常来源可以包括：
byted-volcengine-cloudmonitor 查询到的同步异常如果当前无法直接查询告警平台，则应退化为：
拿到同拓扑异常后，至少要分成三类：
root_alert：更接近链路收敛点，且能解释其他异常传播的告警derived_alert：由根问题向上游或下游传播形成的派生告警noise_alert：与当前主链路弱相关、证据不足或无法证明同源的告警归并原则：
当出现以下情况时，按需使用补充能力：
byted-volcengine-api-assistantbyted-volcengine-cloudmonitor使用原则：
综合以下证据后，再给出根因候选：
最终至少要回答：
最早触发的告警不一定最接近故障源头，可能只是更敏感的入口信号。
如果多条异常路径最终都汇聚到同一个资源、同一层组件或同一个资源组，应优先把它列为高置信候选根因。
例如：
至少满足以下一项，才能高置信归并：
建议按以下级别表达：
confirmed：有明确链路和运行时证据支撑high：拓扑与监控高度一致，但仍缺少少量细节medium：链路可达，但证据不够完整low：只能定位到某一层，无法确认唯一节点输出时优先使用以下结构：
结论：
- 当前最可能的根因候选是 ...
- 置信度是 ...
- 当前优先处理节点是 ...
告警归并结果：
- 主告警: ...
- 已归并的派生告警: ...
- 识别为噪声的告警: ...
拓扑与影响：
- 故障入口: ...
- 中间链路: ...
- 下游关键资源: ...
- 当前影响范围: ...
根因候选排序：
- 候选 1: ... | 证据: ...
- 候选 2: ... | 证据: ...
- 候选 3: ... | 证据: ...
事实 / 推断 / 待确认：
- 已确认事实: ...
- 高置信推断: ...
- 待确认项: ...
建议动作：
- 先处理 ...
- 再验证 ...
- 如需升级，交接摘要如下 ...
使用这个 Skill 时，最终输出应尽量覆盖以下内容：
如果用户需要快速升级或交接，至少应给出：
排查建议至少覆盖三类内容：
处理方式：
byted-volcengine-api-assistant 补产品与接口信息处理方式：
byted-volcengine-topology-builder 重新构建处理方式：
处理方式：
以下场景不要把这个 Skill 当成完整解决方案：
监控平台连续产生多条告警：
- 域名 5xx 升高
- CLB 监听器后端异常个数 > 0
- 单台 ECS 探活失败
值班人员在群里补充：
- mysite 首页访问报错
- 发生时间与告警时间一致
建议处理顺序：
使用这个 Skill 时，最终回答必须遵守以下约束：