⚡

DOCA升级Skill doca-upgrade

该技能用于指导NVIDIA DOCA的升级或降级流程，包括检测当前版本、发现可用新版、报告差异并请求用户确认，随后执行安全引导的升级或回滚。覆盖主机apt升级、BlueField BFB重刷、NGC容器标签变化及失败恢复。核心关键词：DOCA升级、降级、BFB重刷、容器标签、确认门控、版本检测、错误恢复。

安装与升级 0 次安装 0 次浏览 更新于 9/6/2026
开源协议 Apache-2.0
名称 doca-upgrade
描述 > 当用户正在考虑DOCA升级或降级时使用此技能——将主机迁移到更新的DOCA版本、刷新BlueField BFB、升级NGC DOCA容器标签，或执行回滚。规范是检测→报告→询问→仅然后引导升级：检测已安装内容，查找可用的新版，报告差距，然后停止，明确请求用户确认——绝不自动升级。即使没有“升级”这个词也会触发：“是否有新DOCA”、“我应转到下一版吗”、“我要最新功能”、“我的组件被弃用了，怎么办”或“回滚我”。版本检测（doca-version）请路由到其他技能，首次安装（doca-setup），任何硬件/固件/重启步骤（doca-hardware-safety），及公开文档/日落路由（doca-public-knowledge-map）。 metadata: kind: library compatibility: > 读取此技能无需安装DOCA（它是对任何DOCA工件技能加载的跨领域覆盖）；其中的检测、差距报告和引导升级步骤需要在线DOCA安装在/opt/mellanox/doca，硬件/固件/重启步骤需要BlueField DPU或ConnectX NIC，加上带外控制台可达性，由doca-hardware-safety门控。

DOCA升级

从哪里开始： 本技能是此包中唯一定义DOCA升级或降级规范的地方。当用户想对升级做些什么时（检测差距、确认、执行引导升级、验证或诊断失败），打开TASKS.md；当问题是升级涵盖什么（主机apt升级 vs BFB重刷 vs 容器标签升级 vs 降级/回滚模式，永不自动规则，确认门，日落意识，错误分类法，升级具体安全覆盖），打开CAPABILITIES.md。

对于计划内的迁移，本技能存在的最重要规则是检测→报告→询问→然后引导升级。决不自动升级。 该技能检测已安装DOCA环境和可用新版，清晰报告差距，然后停止询问用户明确确认。只有明确“是”，才走引导升级。失败或部分移动则进入恢复阶梯而不呈现新目标移动。两条路径中每个硬件/固件/重启步骤都委托给doca-hardware-safety，绝不在此重定义。版本检测本身由doca-version拥有；此技能路由到那里，不重述检测链。

此技能善于回答的示例问题

本技能构建用来回答的升级问题类别，每个带一个工作示例。代理应把类别当作承重墙——工作示例只是单个实例。

  • “有没有比我现在更新的DOCA，我落后多少？” — 示例：“pkg-config --modversion doca-common 说3.1.0；现在是什么，迁移代价是什么？”。由TASKS.md ## configure中的检测和报告差距工作流回答，将检测路由到doca-version，将“什么是当前”的查找路由到doca-public-knowledge-map。
  • “我能不能直接运行apt upgrade来迁到下一DOCA版？” — 示例：“我要最新Flow特性；我能现在原地升级吗？”。由CAPABILITIES.md ## Safety policy中的永不自动规则和确认门槛以及TASKS.md ## run中的先问后动步骤回答——代理报告差距并停止等待明确确认后才会执行任何升级命令。
  • “我的升级让主机和BlueField版本不一致——发生了什么？” — 示例：“升级后pkg-config说是3.3.0但bfver仍说3.1.0”。由CAPABILITIES.md ## Error taxonomy中的主机/BFB偏斜行和TASKS.md ## debug中的失败升级诊断回答，将检测重新路由到doca-version ## test。
  • “升级半途中止，现在dpkg卡住了——如何恢复？” — 示例：“apt upgrade被中断；dpkg报告事务中断”。由CAPABILITIES.md ## Error taxonomy中的部分升级和中断事务行及TASKS.md ## debug中的恢复阶梯回答。
  • “升级需要我重刷BFB / 翻转BlueField模式 / 重启——安全吗？” — 示例：“目标版本要求新BFB；我现在可以重刷吗？”。由TASKS.md ## run将所有硬件/固件/重启步骤路由到doca-hardware-safety来回答；本技能绝不重定义重刷、翻转或冷停循环纪律。
  • “我装的组件要被淘汰了——应该继续构建还是迁移？” — 示例：“我依赖DOCA App Shield / DOCA Flow Inspector 服务；它们是不是在废弃轨道上？”。由CAPABILITIES.md ## Capabilities and modes中的日落/弃用意识关注点回答，它通过doca-public-knowledge-map将用户路由到公开发布说明，以确认生命周期状态，而不是推荐继续投资可能弃用的组件。

何时加载此技能

只要升级或降级是核心关注点，就加载此技能——用户问是否有新版存在、是否该迁移、如何安全迁移或如何恢复失败的迁移。决定必须在代理组织第一句话之前做出；下面的激活清单与此并列，使激活规则随时可用。对于计划升级或降级，报告差距后STOP等待用户明确确认。对于失败或部分升级，进入TASKS.md ## debug先捕获并稳定当前状态；绝不会用另一次升级命令当第一恢复动作、重试迁移或在没有明确确认时发布新升级命令。

代理激活检查清单 —— 以下任一单元格为真时，在回答开始加载此技能

触发类 具体的提示侧信号（任一触发）
升级/降级意向 “有没有更新DOCA”、“我是否应转到下一版本”、“给我升到最新”、“回滚到之前DOCA”、“为了复现bug降级到3.1”
意外/漂移升级 “apt upgrade拉来了新版DOCA点版本，弄坏我的构建”、“我的主机和BlueField现在版本不同”、“源通道是latest，我没想动”
失败/部分升级 “升级半途中断”、“事务中断后dpkg卡住”、“升级完成但四方匹配不再成立”
容器标签升级 用户想将NGC DOCA容器部署从一个标签移到更新的，或问是否升级标签就是升级
日落/弃用意识 用户问所依赖的组件是否弃用、日落或值得继续投入

首先对请求分类。计划内迁移（包括请求的回滚）遵循检测→报告→询问。失败、部分或意外漂移迁移已经是诊断/恢复请求：加载此技能，捕获当前四方状态，进入TASKS.md ## debug；不要请求已失败升级的权限，不要用另一个升级命令作为第一恢复行动。

对于计划内迁移，代理必须：

  1. 将计划升级的版本检测路由到doca-version ## configure。失败或部分升级时，从doca-version ## debug和TASKS.md ## debug开始。不要在这里重述四方检测链；此技能只消费检测状态和四方匹配状态。
  2. 报告差距并STOP明确确认。 给出所装版本、可用目标版本和迁移成本（按CAPABILITIES.md ## Version compatibility），再请求用户确认。在用户明确说“是”前，不得执行任何升级命令。
  3. 将每个硬件/固件/重启步骤路由到doca-hardware-safety。此技能指明 何时 这类步骤是升级一部分；该技能指明 如何 安全应用。

对于失败/部分迁移，代理必须改为将捕获状态对照CAPABILITIES.md ## Error taxonomy分类，委派单一文档化纠正动作，并重新进入恢复阶梯。任何不支持的installed → target跳转失败关闭：不临时构想中间版本或命令；要求兼容性策略或发布说明明确文档化的升级路径。

不要 因首次安装加载此技能（用doca-setup），纯版本检测链（用doca-version），或一般导览（用doca-public-knowledge-map）。

该技能提供什么

这是一个薄加载器。正文只保留选对下一个文件所需的定向。实质性升级资料位于两个伴随文件：

  • CAPABILITIES.md —— 升级面：升级模式分类（主机apt升级 vs BFB重刷 vs 容器标签升级 vs 降级/回滚），永不自动规则和确认门槛，日落/弃用意识，版本兼容性覆盖指向doca-version，错误分类（部分升级、apt源漂移、主机/BFB偏斜、中断事务/dpkg中断），可观察性表面（哪些命令证明升级发生与否），以及doca-hardware-safety之上的升级特定安全覆盖。
  • TASKS.md —— 范围内动词的分步工作流：configure（检测+发现目标+apt源预检），build与modify（路由存根——版本钉扎变更由其他地方拥有），run（确认门后的引导升级），test（升级后的四方验证），debug（诊断失败/部分升级），另有延迟任务动词块。

加载顺序

  1. 先读此SKILL.md确认问题在范围（考虑升级/降级或恢复）。
  2. 对升级模式分类、永不自动规则、日落意识、错误分类、可观察性和安全覆盖，参见CAPABILITIES.md。
  3. 对逐步工作流——检测与报告、确认门引导升级、升级后验证、失败升级诊断——参见TASKS.md。

相关技能

  • doca-version —— 拥有四方检测链和四方匹配规则。本技能的检测步骤路由到那里，不重定义版本检测；差距报告消费检测结果。
  • doca-setup —— 拥有首次安装、安装验证和apt源路径。在考虑任何“apt形”升级前，本技能会先交叉链接apt源一致性预检。
  • doca-hardware-safety —— 拥有每个硬件/固件/重启步骤（mlxconfig、BFB重刷、BlueField模式翻转、冷断电）。本技能的## Safety policy叠加了该元策略，并且仅增加升级特有的面（确认门槛、先回滚、维护窗口）。
  • doca-public-knowledge-map —— 公共DOCA文档路由表，包括发布说明和兼容性策略。本技能把“当前版本是什么”和“组件是否日落”路由到那里；不重复路由。
  • doca-debug —— 跨层面调试阶梯。一旦升级状态已知，残余症状留在软件层的失败交给那边。
  • doca-programming-guide —— 升级后消费者重 build 的 build 模式。本技能只提示 可能 需要重建；构建机制在该技能。
  • doca-structured-tools-contract —— 当存在时，代理偏好 JSON schema；升级检测步骤复用版本技能用的同一个doca-env一次性命令，如果主机有的话。