network-repair-plan

SKILL运维和基础设施
运维和基础设施 未标注权限 许可证不明确
安装这个技能

网络问题统一入口:知识库预判 + 故障定位修复。触发场景:节点不通、连接超时、路由异常、DNS 解析、Calico/CNI、网络诊断、Ingress/LoadBalancer 排查等

一句话选型结论

按资料字段整理

network-repair-plan是运维和基础设施类的 Agent Skill,安装方式未标注,权限级别未标注,许可证不明确,有可直接复制的安装命令。技能本质是给模型读的说明书,效果取决于模型与客户端;装完先用一个小任务验证,再放进正式流程。

分类运维和基础设施 安装方式未标注 权限级别未标注权限 许可证许可证不明确
累计安装 未标注 本周 未标注
GitHub 星标 未标注 仓库 未标注
下载量 未标注 技能市场下载数
权限级别 未标注权限 安装前请确认风险范围
许可证 许可证不明确 未说明

安装

未标注
在支持 Skills 的客户端里执行,装完问一句「你有哪些技能」验证
skillhub install user_a63d34c2/network-repair-plan
  1. 1
    确认客户端支持

    确认你的客户端支持 Skills(Claude、Codex、Cursor 等),并升级到较新的版本。

  2. 2
    拿到技能文件

    执行上面的命令安装;也可以把仓库里的 SKILL.md 手动放进客户端的 skills 目录。

  3. 3
    刷新技能列表

    重新打开客户端,或刷新技能列表,让新放进来的技能被加载。

  4. 4
    验证是否生效

    问一句「你有哪些技能」,确认列表里出现它,再拿一个小任务试跑。

技能档案

运维和基础设施
字段来自技能仓库与公开索引,中文说明由本站标注
作者 / 维护方user_a63d34c2仓库 未标注 · 版本 未标注
宿主客户端未标注技能可被这些客户端加载
安装方式未标注安装包 community
权限级别未标注权限安装前请确认风险范围
许可证未说明许可证不明确,商用前请自行确认条款
仓库可用性available技能仓库当前是否可访问
最近核验未标注上游最后核验时间 · 数据更新 1791625344
正文体量27.6 KBSKILL.md 原文大小,越大说明说明书写得越细

典型使用场景

3 类
按分类整理的常见用法,具体以 SKILL.md 为准
查服务与日志

按现象定位服务状态与日志线索。

写部署与巡检脚本

把重复的部署、巡检写成脚本。

故障排查

按步骤排查网络、依赖与配置。

选择建议

装之前先看这几条
按条目字段给出的判断,不替你决定用不用

值得选的地方

  • 有可直接复制的安装命令,不用自己翻文档找入口。

先想清楚的地方

  • 没有标注权限级别,实际能做什么要装好后确认。
  • 许可证不明确,商用或二次分发前先到仓库确认条款。
  • 没有做站内核验,内容以作者仓库为准。
  • 技能只是说明书,实际效果取决于模型与客户端,装完先用小任务试一遍。

更适合

  • 需要在运维和基础设施场景里给模型补一套做法的人。
  • 愿意先读一遍 SKILL.md、确认它会让模型做什么的人。

不太适合

  • 对许可证要求很严、必须明确可商用的人。
  • 只想装完就自动变强、不打算看说明书的人。

同类对比

6 个同类
同分类里挑最接近的几条,字段以各自详情页为准
技能权限级别安装方式累计安装宿主客户端安装命令
network-repair-plan当前 未标注权限 未标注 未标注 未标注 有
Azure 部署 调用外部服务 GitHub 仓库 664.2 万 Codex、Claude、Cursor 有
Azure diagnostics 问题管理 调用外部服务 GitHub 仓库 657.6 万 Codex、Claude、Cursor 有
Azure aigateway 部署 调用外部服务 GitHub 仓库 655.3 万 Codex、Claude、Cursor 有
Azure AI 搜索 调用外部服务 GitHub 仓库 651.4 万 Codex、Claude、Cursor 有
Azure Cloud migrate 部署 调用外部服务 GitHub 仓库 650.7 万 Codex、Claude、Cursor 有

SKILL.md 全文

27.6 KB
模型实际读到的说明书原文,来自技能仓库

Network Repair Plan Skill

概述

是网络修复计划生成器,作为网络问题的统一入口,大模型根据问题描述先通过知识库分析对问题进行初步预判,然后通过该 skill 与大模型共同完成网络问题的定位和解决。

工作流程 (重要:必须按此顺序执行)

第一步:大模型遍历知识库

  1. 使用 Glob 工具查找 skills/network-repair-plan/knowledge/*.md 文件
  2. 使用 Read 工具读取所有知识库条目
  3. 理解每个条目:
    - 故障类型(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>"

执行诊断(根据第三步的决策路径):

路径 场景 执行方式
路径 A 匹配到条目且有 solution-skill 通过 network-repair-plan 调用该 skill
路径 B 匹配到条目但无 solution-skill 按照知识库条目的"诊断步骤"执行命令
路径 C 无匹配条目(知识库为空或不匹配) 通过 network-repair-plan 调用 network-diag

路径 A 和 C:通过 network-repair-plan 调用 skill

  1. 读取 skills/network-repair-plan/modules/<problem-type>/MODULE.md 理解 skill 功能(路径 A 从 solution-skill 获取,路径 C 调用 network-diag)
  2. 通过 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>.json
    • verify: 验证模式,追加修复步骤并执行验证,更新 verification 字段
    • --cmd: 修复命令(配合 --mode verify 使用,记录已执行的修复步骤)
    • --merge: 合并所有 network-diag-*.json 文件成统一的 network-diag.json
    • --json-output: 输出 JSON 格式
    • --verbose: 详细输出模式
    • 远程环境支持:
    • 脚本内置远程环境管理功能
    • 使用 --remote &lt;env&gt; 参数指定远程环境
    • 远程初始化包括:环境检查、Python 环境修复、技能上传等

文件生成说明:

  • 单个 skill 检测:生成 network-diag-&lt;type&gt;.json(如 network-diag-route.json)
  • 合并多个结果:使用 --merge 将所有 network-diag-*.json 合并成 network-diag.json
  • 验证模式:--mode verify --cmd &quot;命令&quot; 会追加修复步骤到现有 network-diag-*.json

路径 B:按知识库条目执行诊断

  1. 按照知识库条目的"诊断步骤"执行命令
    - 本地环境:直接使用 Bash 工具执行
    - 远程环境:
    • 路径 B 不使用 network-repair-plan 脚本,需要通过 ssh-manager 执行远程命令
    • 使用 Glob 查找 **/ssh-manager/scripts/main.py 获取绝对路径
    • 使用绝对路径执行命令:python &lt;found_path&gt; exec &lt;env&gt; &quot;&lt;command&gt;&quot;

路径 A 和 C 分析诊断结果:

  1. 查看诊断结果:
    - 读取 skill 生成的 network-diag-&lt;type&gt;.json 文件
    - 结合知识库条目的修复建议
    - 确定是否需要执行修复

执行修复与验证(循环过程)(如果检测到问题):

> 重要:修复过程可能需要多次迭代,直到问题完全解决或用户放弃。

修复循环流程:

执行修复 → 验证 → 检测是否还有问题
    ↓                    ↓
   否                   是
    ↓                    ↓
  完成            询问用户:是否继续修复?
                        ↓           ↓
                      确认        放弃
                       ↓           ↓
                  执行修复      记录当前状态
                       ↓           ↓
                     验证 ←────────┘
                       ↓
                  (循环继续)

执行步骤:

  1. 询问用户是否执行修复(首次):
  • 向用户说明检测到的问题
  • 展示建议的修复命令
  • 询问用户是否确认执行修复
  1. 用户确认修复:
  • 执行修复命令
  • 路径 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 模式

  1. 验证修复结果:
  • 路径 A/C:verify 模式会自动重新调用技能进行验证
  • 路径 B:手动检查修复结果
  • 检查是否还有问题
  • 如果无问题 → 完成(路径 A/C 进入第五步知识闭环)
  • 如果仍有问题 → 继续下一步
  1. 仍有问题时再次询问用户:
  • 向用户说明当前状态
  • 询问用户是否继续修复
  • 如果用户确认 → 返回步骤 2(执行新的修复)
  • 如果用户放弃 → 完成(路径 A/C 进入第五步知识闭环)
  1. 记录所有修复步骤(仅路径 A/C):
    - 每次修复通过 --mode verify --cmd 自动记录到 repair_steps 数组
    - 包括成功和失败的步骤
    - 用于后续生成 repair.json

第五步:完成知识闭环(仅路径 A/C)

知识闭环包括以下步骤(按顺序执行):

  1. 生成 network-diag-<type>.json:已在第四步完成
  2. 执行修复(如果检测到问题):
    - 根据用户确认情况执行修复
    - 可能需要多次循环(修复 → 验证 → 再修复)
    - 用户可选择放弃修复,此时只记录已执行的步骤
  3. repair.json 自动生成:记录修复过程和结果
  4. 调用 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: &quot;**/network-knowledge-extract/scripts/network_knowledge_extract.py&quot;

调用知识提取命令:

# 示例:calico 问题
python3 &lt;找到的路径&gt; \
  --repair-plan &lt;network-repair-plan所在目录&gt;/scripts/report/network-diag-calico.json \
  --repair-result &lt;network-repair-plan所在目录&gt;/scripts/report/repair-calico.json

# 示例:dns 问题
python3 &lt;找到的路径&gt; \
  --repair-plan &lt;network-repair-plan所在目录&gt;/scripts/report/network-diag-dns.json \
  --repair-result &lt;network-repair-plan所在目录&gt;/scripts/report/repair-dns.json

> 重要:上例中的 &lt;network-repair-plan所在目录&gt; 应替换为实际绝对路径。可通过以下方式获取:
>
> 1. 使用 Glob: &quot;**/network-repair-plan/scripts/network_repair_plan.py&quot; 找到脚本路径
> 2. 脚本所在目录的父目录即为 skill 根目录,例如:若脚本路径为 /path/to/skills/network-repair-plan/scripts/network_repair_plan.py,则 skill 根目录为 /path/to/skills/network-repair-plan/
> 3. JSON 文件的绝对路径为 &lt;skill根目录&gt;/scripts/report/network-diag-&lt;type&gt;.json

文件路径说明:

  • 相对路径基准:以下路径均相对于 skills 目录(即存放所有 skill 的父目录)
  • JSON 文件位于:&lt;skill根目录&gt;/scripts/report/ 目录(例如 network-repair-plan/scripts/report/)
  • 文件命名:network-diag-&lt;type&gt;.json 和 repair-&lt;type&gt;.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:用户问存储问题

用户输入:"检测一下集群的存储"

大模型执行:

  1. 遍历 skills/network-repair-plan/knowledge/*.md,发现 csi-storage-backend-down.md
  2. 理解该条目:fault-type=CrashLoopBackOff, root-cause=存储后端异常
  3. 检查元数据:无 solution-skill 字段
  4. 决策:走路径 B(无 solution-skill)
  5. 执行知识库中的诊断步骤:

bash kubectl get pods -n cybertron-infra | grep csi df -h /storage/main/

  1. 向用户输出诊断结果

示例 2:用户问远程环境的存储问题

用户输入:"查询一下 demo 环境的存储状态"

大模型执行:

  1. 遍历知识库,匹配到 csi-storage-backend-down.md
  2. 提取元数据:无 solution-skill 字段
  3. 检测到远程环境:用户指定了"demo 环境"
  4. 决策:走路径 B(无 solution-skill)+ 远程执行
  5. 动态获取 ssh-manager 路径:
    bash # 使用 Glob 查找 ssh-manager 的绝对路径 Glob: &quot;**/ssh-manager/scripts/main.py&quot; # 假设找到: /root/.openclaw/workspace/skills/network-repair-plan/ssh-manager/scripts/main.py
  6. 使用找到的绝对路径执行诊断命令:
    bash python3 /root/.openclaw/workspace/skills/network-repair-plan/ssh-manager/scripts/main.py exec demo &quot;ls -la /storage/main/&quot; python3 /root/.openclaw/workspace/skills/network-repair-plan/ssh-manager/scripts/main.py exec demo &quot;df -h /storage/main/&quot;
  7. 向用户输出远程环境的诊断结果

示例 3:用户问网络问题

用户输入:"跨节点 Pod 无法通信"

大模型执行:

  1. 遍历知识库,匹配到 calico-bgp-peer-not-established.md
  2. 提取元数据:solution-skill=calico
  3. 决策:走路径 A(有 solution-skill)
  4. 读取 skills/network-repair-plan/modules/calico/MODULE.md
  5. 通过 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
```

  1. network-repair-plan 会输出诊断结果和修复建议
  2. 整合 skill 输出 + 知识库建议,生成修复计划

示例 4:完整的知识闭环流程

用户输入:"检查一下 Calico BGP 状态,有问题就修复"

大模型执行:

阶段 1:诊断与修复计划

  1. 遍历知识库,匹配到 calico-bgp-peer-not-established.md
  2. 提取元数据:solution-skill=calico
  3. 通过 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
```

  1. network-repair-plan 会输出诊断结果和修复建议(包括 network-diag-<type>.json)
  2. 诊断结果:BGP peer 未建立,需要修复配置

阶段 2:执行修复

  1. 执行修复命令并使用 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"
```

  1. verify 模式会自动执行验证并更新 network-diag-calico.json 中的 verification 字段
  2. repair_steps 已在 verify 模式中自动记录到 network-diag-calico.json
  3. 验证通过后,脚本会自动生成 repair-calico.json

阶段 4:知识闭环

知识提取步骤:

  1. 使用 Glob 查找 knowledge-extract 脚本:
    Glob: &quot;**/network-knowledge-extract/scripts/network_knowledge_extract.py&quot;

  2. 调用知识提取命令:

```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
```

  1. 查看输出:

阶段 5:报告结果

  1. 向用户报告完整结果:

    ✓ Calico BGP 问题已修复 ✓ 已生成修复报告: repair-calico.json

  2. 如果执行了知识提取,补充报告:
    ✓ 知识已提取并更新到知识库 操作类型: 合并 知识库条目: calico-bgp-peer-not-established.md 匹配分数: 85分

示例 5:修复循环流程(需要多次修复)

用户输入:"检查一下 Service 状态,有问题就修复"
大模型执行:
阶段 1:诊断

  1. 遍历知识库,匹配到 Service 相关条目(如 service-selector-mismatch.md)
  2. 检查元数据:无 solution-skill 字段
  3. 决策:走路径 B(无 solution-skill)
  4. 按照知识库条目的诊断步骤执行命令
  5. 诊断结果:Service 选择器不匹配,Endpoints 为 0
  6. 向用户报告问题并询问是否修复

阶段 2:首次修复(循环开始)

  1. 用户确认修复
  2. 执行修复命令:kubectl patch svc ...
  3. 验证修复结果:检查 Endpoints 是否关联
  4. 仍有问题:Pod CrashLoopBackOff
  5. 向用户说明当前状态并询问是否继续修复

阶段 3:第二次修复(循环继续)

  1. 用户确认继续修复
  2. 查看 Pod 日志,发现配置错误
  3. 执行修复命令:kubectl edit configmap ...
  4. 重启 Pod:kubectl delete pod ...
  5. 验证修复结果:Pod 正常运行,Service 可访问
  6. 问题已解决,退出循环

阶段 4:完成(路径 B 不需要知识闭环)

> 重要说明:本示例走路径 B(知识库条目无 solution-skill),不需要执行知识闭环。

  1. 向用户报告完成

关键点:

  • 路径 B 直接执行知识库条目中的诊断和修复步骤
  • 每次修复后都要验证
  • 仍有问题时需要再次询问用户
  • 循环直到问题解决或用户放弃
  • 路径 B 不需要知识闭环

注意事项

  1. 大模型必须主动遍历知识库:不要等待用户明确要求
  2. 语义理解优先:不要仅依赖关键词匹配
  3. 检查 solution-skill 字段:决定走哪条处理路径
  4. 知识库条目可能自带解决方案:无 solution-skill 时直接执行其中的命令
  5. 远程环境执行方式:
  • 检测用户是否指定远程环境(如"demo 环境"、"在 l20 上")
  • 路径 A/C:使用 network-repair-plan 脚本的 --remote &lt;env&gt; 参数
  • 路径 B:必须使用 ssh-manager 执行远程命令

    • 必须动态获取 ssh-manager 路径(不同智能体环境路径可能不同):
      1. 使用 Glob: &quot;**/ssh-manager/scripts/main.py&quot; 获取绝对路径
      2. 使用绝对路径执行:python &lt;found_path&gt; exec &lt;env&gt; &quot;&lt;command&gt;&quot;
    • 示例流程:

    ```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 命令,也不要假设固定路径
  1. 知识闭环执行范围:
  • 路径 A/C:三种场景都必须执行知识闭环
    • 问题已修复:修复完成并验证通过后,生成知识库文档
    • 用户放弃修复:放弃操作后立即生成知识库文档
    • 无问题的健康检查(HEALTH_CHECK):检查完成后立即生成知识库文档
  • 路径 B:不需要知识闭环(已有知识库条目,直接执行诊断步骤即可)
  • 执行知识闭环时:
    • repair.json 已自动生成(记录修复结果)
    • 使用 Glob 查找 network-knowledge-extract 脚本
    • 使用 Glob 查找 network-repair-plan 脚本获取 skill 根目录(如 /path/to/skills/network-repair-plan)
    • 调用 python3 &lt;knowledge-extract路径&gt; --repair-plan &lt;skill根目录&gt;/scripts/report/network-diag-&lt;type&gt;.json --repair-result &lt;skill根目录&gt;/scripts/report/repair-&lt;type&gt;.json
    • 向用户确认知识库已更新
  1. 动态路径查找:
  • 使用 Glob 工具动态查找脚本路径,不要假设固定路径
  • network-repair-plan: Glob: &quot;**/network-repair-plan/scripts/network_repair_plan.py&quot;
  • network-knowledge-extract: Glob: &quot;**/network-knowledge-extract/scripts/network_knowledge_extract.py&quot;
  • ssh-manager: Glob: &quot;**/ssh-manager/scripts/main.py&quot;
  1. 知识提取成功标志:
  • 输出包含 "✓" 或 "成功" 表示提取成功
  • 输出包含 "合并"、"新建" 或 "引用" 表示知识库已更新
  • 如果出现错误信息,需要向用户报告
  1. JSON 文件生成:
  • network-diag-*.json:由各个 skill 自动生成,保存在 &lt;skill根目录&gt;/scripts/report/ 目录
  • network-diag.json:使用 --merge 合并生成,保存在 &lt;skill根目录&gt;/scripts/report/ 目录
  • repair-<type>.json:由脚本自动生成(验证通过或无问题时),保存在 &lt;skill根目录&gt;/scripts/report/ 目录
  • 格式错误会导致知识提取失败,建议使用辅助脚本确保格式正确
  1. 使用 verify 模式记录修复步骤(仅路径 A/C):

    • 执行修复后,应使用 --mode verify --cmd &quot;命令&quot; 记录修复步骤
    • verify 模式会自动调用技能进行验证
    • 修复步骤会自动追加到 network-diag-*.json 的 repair_steps 数组
    • verification 字段会根据验证结果自动更新
    • 路径 B 不使用 verify 模式,直接执行诊断步骤即可
  2. 文件命名规则:

    • 文件位置:所有 JSON 文件保存在 &lt;skill根目录&gt;/scripts/report/ 目录(skill根目录 即 network-repair-plan/ 的绝对路径)
    • 单个 skill 检测:生成 network-diag-&lt;type&gt;.json(如 network-diag-route.json)
    • 合并多个结果:使用 --merge 将所有 network-diag-*.json 合并成 network-diag.json
    • 最终修复文件:repair-&lt;type&gt;.json(由脚本自动生成,无需手动创建)
    • 大模型需要根据文件名区分不同阶段的输出

附录:Python 脚本使用

基本诊断命令

# 自动诊断(默认 diagnose 模式)
python3 scripts/network_repair_plan.py

# 指定问题类型(diagnose 模式,生成 network-diag-&lt;type&gt;.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 &quot;ip route add default via 192.168.1.1&quot;

# 远程环境验证模式
python3 scripts/network_repair_plan.py --remote demo --problem-type dns --mode verify --cmd &quot;kubectl edit configmap coredns -n kube-system&quot;

常见问题

5 问
答案由本站依据条目字段整理
network-repair-plan怎么安装?

在支持 Skills 的客户端里执行:skillhub install user_a63d34c2/network-repair-plan。安装方式为未标注。装完刷新技能列表或重开客户端。

network-repair-plan支持哪些客户端?

资料没有标注宿主客户端,但只要客户端支持 Skills(Claude、Codex、Cursor 等),一般都能加载。

network-repair-plan权限高吗,安全吗?

权限级别为未标注权限。安装前先看它会读取或写入哪些内容。

network-repair-plan收费吗?

本站不代收费用,也没有标注具体价格。是否收费取决于技能本身和所用的模型或客户端,正式使用前按作者说明确认。

network-repair-plan用什么许可证?

许可证标注为 未说明(许可证不明确)。商用或二次分发前请到仓库确认条款原文。

热门专题

按场景挑技能
全部专题 →

技能内容以作者仓库为准;分类、权限级别与许可证状态的中文说明为中文整理,最近核验 未标注。