实践背景
一次支付链路异常中，多个服务同时出现报错，告警、调用链、指标、日志和前端反馈分别呈现出不同现象，但单一信号只能说明“哪里在报错”，无法直接回答“究竟是哪段代码导致了问题”。AI 工作台先通过内置可观测 Skill 逐层分析，确认异常服务、影响范围并排除基础设施和传播层干扰；随后通过接入的 GitHub 代码分析 Skill 继续下钻源码，将运行时错误与具体文件、函数和校验逻辑对应起来，最终把一次复杂的运行异常收敛为研发可以直接验证和修复的代码级结论。
用户的问题是：我的资源地图里出现了支付相关的告警，请从告警出发，逐层下钻找到真正的根因，并识别和排除不相关的干扰信号。
会话开始时有五条告警：
告警 | 状态 |
payment 错误率 > 10%（峰值 16.77%） | 活跃 |
frontend 错误数 > 50 | 活跃 |
frontend-proxy 错误数 > 50 | 活跃 |
flagd 错误率 > 10% | 已恢复 |
K8s Pod 内存 > 90% | 活跃 |
五条告警看起来像一场大面积故障，但没有一条直接告诉研发该改哪一行代码。
分析过程
内置 Skill 先把范围收窄
前五个阶段由平台内置能力完成：
阶段 | 调用能力 | 关键发现 | 对结论的作用 |
1 告警初判 | tcop-alarm | 错误集中在支付链路，主要维度是错误率 | 定下时间窗和嫌疑服务 |
2 调用链追踪 | tcop-apm | frontend → checkout → payment；payment 报 Invalid token，全部 span 耗时 < 13ms | 判断为业务逻辑拒绝，而非超时 |
3 指标验证 | tcop-prometheus | 网络丢包率为0，CPU 和内存未饱和 | 排除基础设施资源问题 |
4 日志确认 | tcop-cls | payment 与 frontend 错误在14:16:00同时出现，checkout 无自身错误 | 判断为同步触发，排除级联根因 |
5 前端影响 | tcop-rum | POST /api/checkout 错误率约100%，其他 API 正常，受影响用户104名 | 将影响面收敛到单个接口 |
五个 Skill 跑完，结论已经收敛到：payment 在业务逻辑层面拒绝请求，基础设施正常，影响集中在
/api/checkout。从错误信息落到代码行
研发接下来可追问：
Invalid token 是哪段校验逻辑判定的？为什么 app.loyalty.level=gold 被判无效？flagd 的告警是否与支付失败有关？这些问题需要代码证据。
github-repo-analyzer 接入后，前5个阶段的结论可以直接作为源码分析的输入：阶段 | 调用能力 | 关键发现 |
6 源码追溯 | github-repo-analyzer（通过上传官方安装包接入） | 定位到 payment/index.js:21 的 chargeServiceHandler：gold 未被校验逻辑接受；同时确认 flag 分支与网络 timeout 是两条不同路径 |
7 综合诊断 | tcop-alarm | 汇总证据，输出角色分离、证据链和修复优先级 |
阶段6带来两个前面无法得到的答案：
从错误信息落到代码行：研发知道该检查哪个文件、哪个函数和哪个判断。
区分同时发生的异常：代码确认 flagd 与 payment 校验问题是独立路径，不能把重启 flagd 当作 payment 故障的修复方案。
分析结果
结论不是“哪个服务挂了”，而是每个服务扮演什么角色：
角色 | 服务 | 判定依据 | 证据来源 |
主根因 | payment | index.js:21 将 app.loyalty.level=gold 判为无效 | 告警、Trace、日志、前端、源码 |
次根因 | flagd | flag 评估返回 reason=error，与 payment 无代码因果关系 | Trace、告警、源码 |
传播层 | checkout、frontend、frontend-proxy | 无自身错误，只向外传递上游失败 | Trace、日志 |
干扰信号 | Prometheus Pod 内存告警、otel-collector 写入报错 | 与业务链路无关 | 告警、日志 |
只有把源码证据补上，结论才从“高度疑似”变成可以写进故障报告的交叉验证结果。案例会话结果如下：
支付链路根因分析结果：
源码定位结果：
案例中，AI 通过
github-repo-analyzer 将支付失败下钻到 index.js:21 的 token 校验逻辑。配置指引
配置 Skill 到数字分身
扩展中心的广场提供可直接配置到数字分身的第三方 Skill，适用于扩展跨云、代码平台等特定场景的运维能力。
1. 在 AI 工作台 > 扩展中心 > Skill 技能 页面，选择广场，查看可用 Skill。
2. 查看预设的 github-repo-analyzer ，可分析 GitHub 仓库：浏览结构、搜索代码、审查提交/Issue/PR、诊断远程仓问题。
3. 进入 AI 工作台 > 扩展中心 页面，创建自定义 MCP，配置 GitHub MCP 信息，参考 官方网站。
4. 进入 AI 工作台 > 数字分身管理 页面，创建或编辑目标数字分身，在分身配置中添加 github-repo-analyzer Skill 和 GitHub MCP。
发起会话
1. 选择需要使用的 github-repo-analyzer Skill 和其他可观测 Skill。
2. 输入问题，建议包括明确的资源对象、范围和查询问题。
3. 查看分析过程的工具调用和会话结果。
