基于 openUBMC 构建 Agent 驱动的 BMC 研发工作流

01 应用背景

智能 Agent 正从单纯的代码生成工具，逐步演进为工程任务协同载体。但在 BMC 固件研发场景下，真正的瓶颈并非 Agent 能否生成代码或调用工具，而是难以打通需求分析、源码实现、测试构建、固件部署与功能验证等研发环节——任务目标、阶段进度、验证证据和交付结果散落在会话日志、终端输出与本地文件中，缺少统一管理与持续追溯机制。

传统 BMC 研发中，工程师需要在源码、构建环境和目标设备之间反复切换，手动核对结果并衔接后续步骤。引入 Agent 后，分析、编码和工具调用可以连续推进，但任务跨越多个阶段或会话中断时，仍需要重新梳理已完成的工作、确认当前进度，增加了重复检查和人工衔接的开销。

同时，BMC 调试与问题定位还存在极强的跨层分析壁垒：——同一个报错，可能横跨硬件拓扑、驱动、框架、基础服务、产品配置、北向接口等多个维度。要得出可靠结论，不仅依赖源码静态分析，还需要结合真实硬件设备的状态做交叉验证。

针对这种复杂的跨层工程协同分析的诉求，如果仅依靠 Agent 零散调用工具，会面临以下几个挑战：

• 状态不持久： 长流程任务缺少统一状态管理，工程上下文无法持续保留；
• 证据易失效： 设备状态动态变化，难以客观判定任务是否完成；
• 写操作结果不明确： 固件刷写、热补丁等操作易超时，无法确认设备侧真实结果，盲目重试会叠加变更，进一步扩大故障影响范围。

因此，BMC 研发工程师需要的不只是 Agent 调用单点工具能力增强，而是一套完整工程工作流：任务状态可保存、中断可续跑、写操作可对账，最终以 BMC 设备实际运行状态作为任务验收标准。

02 基于 openUBMC 构建 Agent 驱动的 BMC 研发工作流

针对上述痛点，软通华方依托 openUBMC 的资源模型、组件化开发和设备管理能力，构建了 openUBMC Agent Workflow。该工作流面向BMC全研发场景，工程师定义任务目标、执行范围与验收条件后，宿主 Agent 结合领域技能（Skill）与 Target Runtime，自主推进分析、修复、构建、升级和实机验证全流程。

1. 总体架构与执行分工

图1：openUBMC Agent Workflow 全链路执行与职责分工

宿主 Agent 负责规划、分析和工程判断，按领域 Skill 调用开发构建工具与设备能力。Target Runtime 基于MCP协议统一管控任务进度、目标连接、资源调度、变更记录与验收结果。开发和构建的结果以阶段回执进入任务，作为后续交付与验证的依据。

2. 核心能力

2.1 依托 openUBMC 工程体系，衔接源码开发与设备验证

openUBMC 的 MDS 模型定义、MDB/D-Bus 资源对象和北向接口映射，为需求分析、异常定位和功能验证提供统一参照。结合组件源码、依赖关系与构建工具链，Agent 可以确定代码修改范围、选择测试与构建方式，并核对待部署的固件制品。

领域 Skill 将沉淀的工程经验封装成标准化的诊断、开发、构建、升级和验证流程。Agent 既能从故障描述启动任务，也能承接已有修改或构建制品；依据实时状态动态选择后续动作，保证源码改动、交付固件制品与设备侧业务结果三者可追溯、可对应。

2.2 长流程断点续跑，支持多任务智能并发推进

面对固件编译、设备重启这类耗时环节，工作流支持后台持续运行，完整留存运行日志、任务状态与输出制品，发生中断后可接续执行。设备断连重启恢复后，系统自动完成重连、版本校验与业务复核，无需工程师全程盯守。

方案具备两层并发能力：同一任务内部，源码解析、日志检索、日志分析这类无依赖动作可以并行执行；多任务场景下，故障修复、代码开发、设备验收可错峰开展。系统结合任务依赖关系与硬件资源做统一调度，同一设备上的变更操作串行执行，多设备任务高效并发，有效提升整体效率。

2.3 可信执行闭环，完善任务恢复与验收保障体系

通过任务档案、变更日志、证据账本一套机制，构建可信执行底座，实现异常可恢复、变更可追溯、验收有依据。

任务档案（Case）保存目标、阶段结果和核验证据，执行现场（TargetRun）管理当前目标的连接与能力。会话或连接中断后，Agent 读取历史任务进度、核验设备当前状态，在满足条件时恢复任务执行。

变更日志（Mutation Journal）记录已发起操作及其核验结果。针对固件升级、文件替换等高风险动作，优先采集设备真实状态，再判定继续执行、调整方案或是发起重试，规避将超时简单等同于失败所引发的误操作。

证据账本（Evidence Ledger）记录设备变更前后的状态；任务验收（Closeout）关联固件制品标识、验收指标与业务运行结果。构建完成、升级指令下发仅属于阶段节点；只有设备实测结果达到预设标准，任务才算真正闭环，保障每一次研发交付可信可控。

3. 典型场景 RAID 控制器信息缺失的修复交付

以某项目现场故障为例：BMC 可识别服务器 RAID 卡，但管理界面无法展示控制器信息。日志显示libsml_lsi.so加载失败，控制器注册返回错误码 4357；经核验定位为适配库缺失，核对固件基线后锁定修复范围。

图2：人工组织与 Workflow 自主推进对比

传统人工模式下，分析、构建、升级、验证、交付全流程都需要工程师介入确认，反复切换各类工具，碎片化操作带来大量重复工作量。借助 openUBMC Agent Workflow，整个修复流程实现自动化闭环：系统自动完成依赖与打包配置修正、测试构建、固件升级及设备恢复，并自动校验适配库加载、控制器注册、资源对象与北向接口状态。常规流程交由 Agent 自主流转，工程师仅聚焦关键决策与复杂异常；同时可以利用构建、设备重启的等待时段并行处理其他工作，削减人工盯守、工具切换带来的无效开销，提升故障修复交付效率。

03 客户价值

openUBMC Agent Workflow 重构 BMC 研发任务执行模式：实现分析工作前置、工程阶段自动衔接，降低研发人员在工具切换、上下文重建、流程盯守上的人力消耗。

高效跨层研判，精准收敛故障范围

工作流以统一任务目标串联全部分析材料，聚合领域知识、源码、接口与设备侧证据，把原本串行开展的分析环节改为并行协同。依托多源信息交叉校验，快速收拢问题边界、定位根因，减少反复检索取证，提升复杂跨层故障的研判效率与准确度。

释放人力成本，聚焦高价值研发

构建打包、固件升级、设备重连、循环核验等重复性工程动作实现自动化。工程师仅需定义任务目标，把控交付结果与异常风险，不必持续值守流程；人力从机械操作中释放，更多投入部件适配、资源调优、业务迭代等高价值工作。

多任务并行调度，提升交付效率

通过智能任务调度，充分利用编译、重启等长耗时环节的空闲窗口，并行推进其他研发任务。在硬件资源约束下最大化利用研发时间，改善人工串行作业、流程空等问题，提高单位时间可交付的任务总量。

沉淀工程资产，实现能力迭代复用

把场景化排查逻辑、标准化构建流程、验收规范等固化为可复用的领域 Skill，打破工程师个人经验壁垒。同类研发任务可以直接复用成熟执行路径；团队还可以基于任务运行数据做量化复盘，持续打磨优化研发流程，实现工程能力体系化迭代。

欢迎关注openUBMC

• 社区官网：https://www.openubmc.cn
• 代码仓地址：https://atomgit.com/openUBMC