Network Repair Plan Skill
概述
是网络修复计划生成器,作为网络问题的统一入口,大模型根据问题描述先通过知识库分析对问题进行初步预判,然后通过该 skill 与大模型共同完成网络问题的定位和解决。
工作流程 (重要:必须按此顺序执行)
第一步:大模型遍历知识库
- 使用 Glob 工具查找
skills/network-repair-plan/knowledge/*.md文件 - 使用 Read 工具读取所有知识库条目
- 理解每个条目:
- 故障类型(fault-type)
- 根因类别(root-cause)
- 故障现象和症状
- 诊断步骤
- 修复方法
- 是否有solution-skill字段
第二步:大模型进行语义匹配用户问题
- 理解用户问题的语义(非关键词匹配)
- 分析用户描述的症状、错误信息、组件
- 与知识库条目进行语义相似度匹配
- 提取匹配条目的
solution-skill字段(如有) - 检查用户是否指定远程环境(如"在 demo 环境上"、"demo 环境的存储")
第三步:大模型进行决策处理路径
┌─────────────────────────────────────────┐
│ 匹配结果判断 │
├─────────────────────────────────────────┤
│ │
│ A. 匹配到条目且有 solution-skill │
│ → 读取 skills/network-repair-plan/modules/<solution-skill>/MODULE.md│
│ → 调用该 skill │
│ → 整合 skill 输出 + 知识库建议 │
│ → 需要知识闭环(更新/合并知识库) │
│ │
│ B. 匹配到条目但无 solution-skill │
│ → 根据知识库条目的诊断步骤执行 │
│ → 按照修复方法执行命令 │
│ → 无需调用其他 skill │
│ → 不需要知识闭环(已有知识库) │
│ │
│ C. 无匹配条目 │
│ → 根据用户描述推断问题类型 │
│ → 调用通用诊断 skill(如 network-diag)│
│ → 需要知识闭环(新增知识库条目) │
└─────────────────────────────────────────┘
第四步:执行诊断
远程环境检测:
- 如果用户指定了远程环境(如"demo 环境")
- 路径 A/C:使用 network-repair-plan 脚本的
--remote <env>参数 - 路径 B:必须使用 ssh-manager 执行远程命令
- 动态获取 ssh-manager 路径(重要!):
1. 使用 Glob 查找**/ssh-manager/scripts/main.py获取绝对路径
2. 使用找到的绝对路径执行命令,避免路径不一致问题 - 调用方式:
python <found_path> exec <environment> "<command>"
- 动态获取 ssh-manager 路径(重要!):
执行诊断(根据第三步的决策路径):
| 路径 | 场景 | 执行方式 |
|---|---|---|
| 路径 A | 匹配到条目且有 solution-skill | 通过 network-repair-plan 调用该 skill |
| 路径 B | 匹配到条目但无 solution-skill | 按照知识库条目的"诊断步骤"执行命令 |
| 路径 C | 无匹配条目(知识库为空或不匹配) | 通过 network-repair-plan 调用 network-diag |
路径 A 和 C:通过 network-repair-plan 调用 skill
- 读取
skills/network-repair-plan/modules/<problem-type>/MODULE.md理解 skill 功能(路径 A 从 solution-skill 获取,路径 C 调用 network-diag) - 通过 network-repair-plan 调用该 skill:
- 使用 Glob 工具查找**/network-repair-plan/scripts/network_repair_plan.py获取绝对路径
- 调用方式:python <found_path> --problem-type <type> [--service <name>] [--ingress <name>] [--remote <env>] [--json-output] [--verbose]
- 参数说明:--problem-type <type>: 问题类型(如 svc, dns, calico, route 等)--service <name>: Service 名称(用于 svc 类型,只检测指定服务,如--service inc)--ingress <name>: Ingress 名称(用于 traefik 类型,只检测指定 ingress)--remote <env>: 远程环境名称(如 demo)--mode: 操作模式,可选值:diagnose(默认):执行诊断,生成 network-diag-<type>.jsonverify: 验证模式,追加修复步骤并执行验证,更新 verification 字段--cmd: 修复命令(配合--mode verify使用,记录已执行的修复步骤)--merge: 合并所有 network-diag-*.json 文件成统一的 network-diag.json--json-output: 输出 JSON 格式--verbose: 详细输出模式- 远程环境支持:
- 脚本内置远程环境管理功能
- 使用
--remote <env>参数指定远程环境 - 远程初始化包括:环境检查、Python 环境修复、技能上传等
文件生成说明:
- 单个 skill 检测:生成
network-diag-<type>.json(如 network-diag-route.json) - 合并多个结果:使用
--merge将所有 network-diag-*.json 合并成network-diag.json - 验证模式:
--mode verify --cmd "命令"会追加修复步骤到现有 network-diag-*.json
路径 B:按知识库条目执行诊断
- 按照知识库条目的"诊断步骤"执行命令
- 本地环境:直接使用 Bash 工具执行
- 远程环境:- 路径 B 不使用 network-repair-plan 脚本,需要通过 ssh-manager 执行远程命令
- 使用 Glob 查找
**/ssh-manager/scripts/main.py获取绝对路径 - 使用绝对路径执行命令:
python <found_path> exec <env> "<command>"
路径 A 和 C 分析诊断结果:
- 查看诊断结果:
- 读取 skill 生成的network-diag-<type>.json文件
- 结合知识库条目的修复建议
- 确定是否需要执行修复
执行修复与验证(循环过程)(如果检测到问题):
> 重要:修复过程可能需要多次迭代,直到问题完全解决或用户放弃。
修复循环流程:
执行修复 → 验证 → 检测是否还有问题
↓ ↓
否 是
↓ ↓
完成 询问用户:是否继续修复?
↓ ↓
确认 放弃
↓ ↓
执行修复 记录当前状态
↓ ↓
验证 ←────────┘
↓
(循环继续)
执行步骤:
- 询问用户是否执行修复(首次):
- 向用户说明检测到的问题
- 展示建议的修复命令
- 询问用户是否确认执行修复
- 用户确认修复:
- 执行修复命令
-
路径 A/C:使用 verify 模式记录修复步骤:
```bash
# 使用 Glob 查找 network-repair-plan 脚本
Glob: "**/network-repair-plan/scripts/network_repair_plan.py"# 使用 verify 模式记录修复步骤并执行验证
python3 <found_path> --problem-type <type> --mode verify --cmd "<执行的修复命令>"
``` -
路径 B:直接执行修复命令,无需 verify 模式
- 验证修复结果:
- 路径 A/C:verify 模式会自动重新调用技能进行验证
- 路径 B:手动检查修复结果
- 检查是否还有问题
- 如果无问题 → 完成(路径 A/C 进入第五步知识闭环)
- 如果仍有问题 → 继续下一步
- 仍有问题时再次询问用户:
- 向用户说明当前状态
- 询问用户是否继续修复
- 如果用户确认 → 返回步骤 2(执行新的修复)
- 如果用户放弃 → 完成(路径 A/C 进入第五步知识闭环)
- 记录所有修复步骤(仅路径 A/C):
- 每次修复通过--mode verify --cmd自动记录到repair_steps数组
- 包括成功和失败的步骤
- 用于后续生成 repair.json
第五步:完成知识闭环(仅路径 A/C)
知识闭环包括以下步骤(按顺序执行):
- 生成 network-diag-<type>.json:已在第四步完成
- 执行修复(如果检测到问题):
- 根据用户确认情况执行修复
- 可能需要多次循环(修复 → 验证 → 再修复)
- 用户可选择放弃修复,此时只记录已执行的步骤 - repair.json 自动生成:记录修复过程和结果
- 调用 network-knowledge-extract(完成知识闭环):提取知识并更新知识库
知识闭环执行范围:
- 路径 A/C:三种场景都必须执行知识闭环
- 场景一:问题已修复 — 修复完成并验证通过后,生成知识库文档
- 场景二:用户放弃修复 — 用户放弃后立即生成知识库文档(记录已执行的诊断和修复步骤)
- 场景三:无问题的健康检查(HEALTH_CHECK) — 检查完成后立即生成知识库文档
- 路径 B:不需要知识闭环(已有知识库条目,直接执行诊断步骤即可)
知识闭环执行时机:
> 重要:路径 A/C 的三种场景都必须执行知识闭环,但执行时机不同:
| 场景 | 触发条件 | 知识闭环执行时机 |
|---|---|---|
| 问题已修复 | 修复验证通过,确认问题已解决 | 修复完成后生成知识库文档 |
| 用户放弃修复 | 用户主动放弃继续修复 | 放弃操作后立即生成知识库文档 |
| 无问题的健康检查 | 诊断结果显示系统正常(HEALTH_CHECK) | 检查完成后立即生成知识库文档 |
如果诊断结果为"无问题"或"系统正常":
repair.json中的repair_status填写 "success"(表示检查完成)repair_steps_executed记录诊断步骤- 必须调用 network-knowledge-extract 生成知识库文档(记录健康检查结果和环境信息)
5.1 记录修复结果
repair.json 由脚本自动生成,大模型不需要手动创建:
5.2 调用知识提取
使用 Glob 工具查找 network-knowledge-extract 脚本:
Glob: "**/network-knowledge-extract/scripts/network_knowledge_extract.py"
调用知识提取命令:
# 示例:calico 问题
python3 <找到的路径> \
--repair-plan <network-repair-plan所在目录>/scripts/report/network-diag-calico.json \
--repair-result <network-repair-plan所在目录>/scripts/report/repair-calico.json
# 示例:dns 问题
python3 <找到的路径> \
--repair-plan <network-repair-plan所在目录>/scripts/report/network-diag-dns.json \
--repair-result <network-repair-plan所在目录>/scripts/report/repair-dns.json
> 重要:上例中的 <network-repair-plan所在目录> 应替换为实际绝对路径。可通过以下方式获取:
>
> 1. 使用 Glob: "**/network-repair-plan/scripts/network_repair_plan.py" 找到脚本路径
> 2. 脚本所在目录的父目录即为 skill 根目录,例如:若脚本路径为 /path/to/skills/network-repair-plan/scripts/network_repair_plan.py,则 skill 根目录为 /path/to/skills/network-repair-plan/
> 3. JSON 文件的绝对路径为 <skill根目录>/scripts/report/network-diag-<type>.json
文件路径说明:
- 相对路径基准:以下路径均相对于 skills 目录(即存放所有 skill 的父目录)
- JSON 文件位于:
<skill根目录>/scripts/report/目录(例如network-repair-plan/scripts/report/) - 文件命名:
network-diag-<type>.json和repair-<type>.json - 常见类型:
calico,dns,svc,route,bond,kube-vip,traefik等 - 脚本自动生成路径:network-repair-plan 脚本内部通过
get_report_dir()自动计算绝对路径,无需手动拼接
执行方式:
- 本地环境:使用 Bash 工具执行
- 远程环境:知识提取总是在本地执行(报告已从远程获取)
5.3 验证知识库更新(如果执行了知识提取)
检查知识提取输出:
- 如果输出包含 "✓" 或 "成功" 标记,说明知识提取成功
- 如果输出包含 "合并"、"新建" 或 "引用",说明知识库已更新
向用户报告知识闭环结果:
✓ 知识已提取并更新到知识库
操作类型: [合并/新建/引用]
知识库条目: [条目文件名]
可调用的诊断技能(solution-skill)
| 问题类型 | 调用技能 | 说明 |
|---|---|---|
| Calico 问题 | calico | BGP、IPAM、跨节点通信问题 |
| DNS 问题 | dns | 域名解析失败 |
| Service 问题 | svc + dns | Service 无法访问 |
| 路由问题 | route | 路由表异常 |
| Bond 问题 | bond | 网卡聚合问题 |
| 网卡光模块问题 | nic | 网卡光模块问题 |
| VIP 问题 | kube-vip | 负载均衡问题 |
| InfiniBand 问题 | ib | IB 网络问题 |
| RoCE 问题 | roce | RoCE 网络问题 |
| RDMA 问题 | rdma | RDMA 通用问题 |
| AI 任务问题 | ai | AI 任务调度和执行问题 |
| GPU 问题 | gpu | GPU 资源和 P2P 问题 |
| RoCE 交换机问题 | switch | RoCE 交换机连接和配置问题 |
| IB 交换机问题 | switch | IB 交换机接口和状态检查 |
| Blitzwing 网络 | blitzwing-network | Blitzwing 网络组件问题 |
| Ingress 问题 | traefik | Traefik Ingress 问题 |
| 前端问题 | traefik | Traefik Ingress 问题 |
| Potal 问题 | traefik | Traefik Ingress 问题 |
| 通用网络问题 | network-diag | 集群网络全面诊断,大概耗时 15 分钟 |
| 网络 | network-diag | 集群网络全面诊断,大概耗时 15 分钟 |
> 注意:知识库条目格式由 network-knowledge-extract skill 管理,详见该 skill 的 SKILL.md
示例执行流程
示例 1:用户问存储问题
用户输入:"检测一下集群的存储"
大模型执行:
- 遍历
skills/network-repair-plan/knowledge/*.md,发现csi-storage-backend-down.md - 理解该条目:fault-type=CrashLoopBackOff, root-cause=存储后端异常
- 检查元数据:无 solution-skill 字段
- 决策:走路径 B(无 solution-skill)
- 执行知识库中的诊断步骤:
bash
kubectl get pods -n cybertron-infra | grep csi
df -h /storage/main/
- 向用户输出诊断结果
示例 2:用户问远程环境的存储问题
用户输入:"查询一下 demo 环境的存储状态"
大模型执行:
- 遍历知识库,匹配到
csi-storage-backend-down.md - 提取元数据:无 solution-skill 字段
- 检测到远程环境:用户指定了"demo 环境"
- 决策:走路径 B(无 solution-skill)+ 远程执行
- 动态获取 ssh-manager 路径:
bash # 使用 Glob 查找 ssh-manager 的绝对路径 Glob: "**/ssh-manager/scripts/main.py" # 假设找到: /root/.openclaw/workspace/skills/network-repair-plan/ssh-manager/scripts/main.py - 使用找到的绝对路径执行诊断命令:
bash python3 /root/.openclaw/workspace/skills/network-repair-plan/ssh-manager/scripts/main.py exec demo "ls -la /storage/main/" python3 /root/.openclaw/workspace/skills/network-repair-plan/ssh-manager/scripts/main.py exec demo "df -h /storage/main/" - 向用户输出远程环境的诊断结果
示例 3:用户问网络问题
用户输入:"跨节点 Pod 无法通信"
大模型执行:
- 遍历知识库,匹配到
calico-bgp-peer-not-established.md - 提取元数据:solution-skill=calico
- 决策:走路径 A(有 solution-skill)
- 读取
skills/network-repair-plan/modules/calico/MODULE.md - 通过 network-repair-plan 调用 calico skill:
```bash
# 使用 Glob 查找 network-repair-plan 脚本
Glob: "**/network-repair-plan/scripts/network_repair_plan.py"
# 假设找到: /path/to/network-repair-plan/scripts/network_repair_plan.py
# 通过 network-repair-plan 调用 calico skill
python /path/to/network-repair-plan/scripts/network_repair_plan.py --problem-type calico
```
- network-repair-plan 会输出诊断结果和修复建议
- 整合 skill 输出 + 知识库建议,生成修复计划
示例 4:完整的知识闭环流程
用户输入:"检查一下 Calico BGP 状态,有问题就修复"
大模型执行:
阶段 1:诊断与修复计划
- 遍历知识库,匹配到
calico-bgp-peer-not-established.md - 提取元数据:solution-skill=calico
- 通过 network-repair-plan 调用 calico skill 执行诊断:
```bash
# 使用 Glob 查找 network-repair-plan 脚本
Glob: "**/network-repair-plan/scripts/network_repair_plan.py"
# 假设找到: /path/to/network-repair-plan/scripts/network_repair_plan.py
# 通过 network-repair-plan 调用 calico skill
python3 /path/to/network-repair-plan/scripts/network_repair_plan.py --problem-type calico
```
- network-repair-plan 会输出诊断结果和修复建议(包括 network-diag-<type>.json)
- 诊断结果:BGP peer 未建立,需要修复配置
阶段 2:执行修复
- 执行修复命令并使用 verify 模式记录:
```bash
# 使用 Glob 查找 network-repair-plan 脚本
Glob: "**/network-repair-plan/scripts/network_repair_plan.py"
# 修复命令 1:更新配置
kubectl edit configmap blitzwing-config -n cybertron-network
# 记录修复步骤 1 并验证
python3 <found_path> --problem-type calico --mode verify --cmd "kubectl edit configmap blitzwing-config -n cybertron-network"
# 修复命令 2:重启 Pod
kubectl delete pod -n cybertron-network -l k8s-app=calico-node
# 记录修复步骤 2 并验证
python3 <found_path> --problem-type calico --mode verify --cmd "kubectl delete pod -n cybertron-network -l k8s-app=calico-node"
```
- verify 模式会自动执行验证并更新 network-diag-calico.json 中的 verification 字段
- repair_steps 已在 verify 模式中自动记录到 network-diag-calico.json
- 验证通过后,脚本会自动生成
repair-calico.json
阶段 4:知识闭环
知识提取步骤:
-
使用 Glob 查找 knowledge-extract 脚本:
Glob: "**/network-knowledge-extract/scripts/network_knowledge_extract.py" -
调用知识提取命令:
```bash
# 先用 Glob 获取 network-repair-plan 的 skill 根目录
Glob: "**/network-repair-plan/scripts/network_repair_plan.py"
# 假设找到: /path/to/skills/network-repair-plan/scripts/network_repair_plan.py
# 则 skill 根目录为: /path/to/skills/network-repair-plan
python3 /path/to/network_knowledge_extract.py \
--repair-plan /path/to/skills/network-repair-plan/scripts/report/network-diag-calico.json \
--repair-result /path/to/skills/network-repair-plan/scripts/report/repair-calico.json
```
- 查看输出:
阶段 5:报告结果
-
向用户报告完整结果:
✓ Calico BGP 问题已修复 ✓ 已生成修复报告: repair-calico.json -
如果执行了知识提取,补充报告:
✓ 知识已提取并更新到知识库 操作类型: 合并 知识库条目: calico-bgp-peer-not-established.md 匹配分数: 85分
示例 5:修复循环流程(需要多次修复)
用户输入:"检查一下 Service 状态,有问题就修复"
大模型执行:
阶段 1:诊断
- 遍历知识库,匹配到 Service 相关条目(如 service-selector-mismatch.md)
- 检查元数据:无 solution-skill 字段
- 决策:走路径 B(无 solution-skill)
- 按照知识库条目的诊断步骤执行命令
- 诊断结果:Service 选择器不匹配,Endpoints 为 0
- 向用户报告问题并询问是否修复
阶段 2:首次修复(循环开始)
- 用户确认修复
- 执行修复命令:
kubectl patch svc ... - 验证修复结果:检查 Endpoints 是否关联
- 仍有问题:Pod CrashLoopBackOff
- 向用户说明当前状态并询问是否继续修复
阶段 3:第二次修复(循环继续)
- 用户确认继续修复
- 查看 Pod 日志,发现配置错误
- 执行修复命令:
kubectl edit configmap ... - 重启 Pod:
kubectl delete pod ... - 验证修复结果:Pod 正常运行,Service 可访问
- 问题已解决,退出循环
阶段 4:完成(路径 B 不需要知识闭环)
> 重要说明:本示例走路径 B(知识库条目无 solution-skill),不需要执行知识闭环。
- 向用户报告完成
关键点:
- 路径 B 直接执行知识库条目中的诊断和修复步骤
- 每次修复后都要验证
- 仍有问题时需要再次询问用户
- 循环直到问题解决或用户放弃
- 路径 B 不需要知识闭环
注意事项
- 大模型必须主动遍历知识库:不要等待用户明确要求
- 语义理解优先:不要仅依赖关键词匹配
- 检查 solution-skill 字段:决定走哪条处理路径
- 知识库条目可能自带解决方案:无 solution-skill 时直接执行其中的命令
- 远程环境执行方式:
- 检测用户是否指定远程环境(如"demo 环境"、"在 l20 上")
- 路径 A/C:使用 network-repair-plan 脚本的
--remote <env>参数 -
路径 B:必须使用 ssh-manager 执行远程命令
- 必须动态获取 ssh-manager 路径(不同智能体环境路径可能不同):
1. 使用Glob: "**/ssh-manager/scripts/main.py"获取绝对路径
2. 使用绝对路径执行:python <found_path> exec <env> "<command>" - 示例流程:
```bash
# 步骤1: 使用 Glob 找到 ssh-manager
Glob: "**/ssh-manager/scripts/main.py"
# 结果: /root/.openclaw/workspace/skills/network-repair-plan/ssh-manager/scripts/main.py# 步骤2: 使用绝对路径执行命令
python3 /root/.openclaw/workspace/skills/network-repair-plan/ssh-manager/scripts/main.py exec l20-node-5 "ls -la"
```- 不要直接使用 ssh 命令,也不要假设固定路径
- 必须动态获取 ssh-manager 路径(不同智能体环境路径可能不同):
- 知识闭环执行范围:
- 路径 A/C:三种场景都必须执行知识闭环
- 问题已修复:修复完成并验证通过后,生成知识库文档
- 用户放弃修复:放弃操作后立即生成知识库文档
- 无问题的健康检查(HEALTH_CHECK):检查完成后立即生成知识库文档
- 路径 B:不需要知识闭环(已有知识库条目,直接执行诊断步骤即可)
- 执行知识闭环时:
- repair.json 已自动生成(记录修复结果)
- 使用 Glob 查找 network-knowledge-extract 脚本
- 使用 Glob 查找 network-repair-plan 脚本获取 skill 根目录(如
/path/to/skills/network-repair-plan) - 调用
python3 <knowledge-extract路径> --repair-plan <skill根目录>/scripts/report/network-diag-<type>.json --repair-result <skill根目录>/scripts/report/repair-<type>.json - 向用户确认知识库已更新
- 动态路径查找:
- 使用 Glob 工具动态查找脚本路径,不要假设固定路径
- network-repair-plan:
Glob: "**/network-repair-plan/scripts/network_repair_plan.py" - network-knowledge-extract:
Glob: "**/network-knowledge-extract/scripts/network_knowledge_extract.py" - ssh-manager:
Glob: "**/ssh-manager/scripts/main.py"
- 知识提取成功标志:
- 输出包含 "✓" 或 "成功" 表示提取成功
- 输出包含 "合并"、"新建" 或 "引用" 表示知识库已更新
- 如果出现错误信息,需要向用户报告
- JSON 文件生成:
- network-diag-*.json:由各个 skill 自动生成,保存在
<skill根目录>/scripts/report/目录 - network-diag.json:使用
--merge合并生成,保存在<skill根目录>/scripts/report/目录 - repair-<type>.json:由脚本自动生成(验证通过或无问题时),保存在
<skill根目录>/scripts/report/目录 - 格式错误会导致知识提取失败,建议使用辅助脚本确保格式正确
-
使用 verify 模式记录修复步骤(仅路径 A/C):
- 执行修复后,应使用
--mode verify --cmd "命令"记录修复步骤 - verify 模式会自动调用技能进行验证
- 修复步骤会自动追加到 network-diag-*.json 的 repair_steps 数组
- verification 字段会根据验证结果自动更新
- 路径 B 不使用 verify 模式,直接执行诊断步骤即可
- 执行修复后,应使用
-
文件命名规则:
- 文件位置:所有 JSON 文件保存在
<skill根目录>/scripts/report/目录(skill根目录即network-repair-plan/的绝对路径) - 单个 skill 检测:生成
network-diag-<type>.json(如 network-diag-route.json) - 合并多个结果:使用
--merge将所有 network-diag-*.json 合并成network-diag.json - 最终修复文件:
repair-<type>.json(由脚本自动生成,无需手动创建) - 大模型需要根据文件名区分不同阶段的输出
- 文件位置:所有 JSON 文件保存在
附录:Python 脚本使用
基本诊断命令
# 自动诊断(默认 diagnose 模式)
python3 scripts/network_repair_plan.py
# 指定问题类型(diagnose 模式,生成 network-diag-<type>.json)
python3 scripts/network_repair_plan.py --problem-type calico
# 指定问题类型并只检测特定服务
python3 scripts/network_repair_plan.py --problem-type svc --service inc
# 指定问题类型并只检测特定 ingress
python3 scripts/network_repair_plan.py --problem-type traefik --ingress my-ingress
# 查看 IB 交换机状态(诊断 IB 接口和交换机连接)
python3 scripts/network_repair_plan.py --problem-type switch --type ib
# 查看远程为 ruijie 的 RoCE 交换机
python3 scripts/network_repair_plan.py --problem-type switch --type roce --remote ruijie
# 远程环境诊断
python3 scripts/network_repair_plan.py --remote demo --problem-type dns
# 远程环境诊断特定服务
python3 scripts/network_repair_plan.py --remote demo --problem-type svc --service my-service
# 合并所有 network-diag-*.json 成统一的 network-diag.json
python3 scripts/network_repair_plan.py --merge
# 验证模式:记录修复步骤并执行验证
python3 scripts/network_repair_plan.py --problem-type route --mode verify --cmd "ip route add default via 192.168.1.1"
# 远程环境验证模式
python3 scripts/network_repair_plan.py --remote demo --problem-type dns --mode verify --cmd "kubectl edit configmap coredns -n kube-system"