القائمة
当监控平台、日志平台、值班对话或变更后异常暴露出某个资源、域名、IP 或业务现象时，围绕告警目标自动展开上下游拓扑，检查同一拓扑内的关联异常并归并根告警、派生告警和噪声告警，输出根因候选、影响范围和结构化诊断摘要。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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 时，最终回答必须遵守以下约束：