IB-Robot系列 | 面向AI编程时代：openEuler Embedded 的 Agent 开发与维护实践

过去评价一个研发团队，可能看“代码写得好不好”；而在 AI 编程时代，代码生成本身已经不再是稀缺能力。真正稀缺的，是把“开发、构建、验证、迭代、协作、提交”这一整条工程链路自动闭环起来的能力。

openEuler Embedded 在这一点上面临的挑战尤为突出。它同时横跨 PC、开发板、云构建平台与git协作平台，本身就是一个高度复杂的工程对象：

在传统模式下，一个问题要走完“人工排查 → 手敲命令 → 多轮验证 → 手写描述 → 推送 PR”的完整路径；而在 Agent 模式下，这条路径需要被重塑为“问题识别 → 路由 skill → 自动执行 → 自动验证 → 人工确认关键决策 → 自动闭环 PR 推送”。

在 openEuler Embedded 的日常研发与维护中，有三类问题最具代表性，也最能体现 Agent 化的必要性。

以近期快速演进的具身智能框架 IB_Robot 为例，它有严格的架构设计契约，同时其训练服务、数据服务、推理服务、动作分发、databus 等等模块正在持续演进。团队多人并行开发时，极易出现这样一种场景：

这里的根本矛盾是：人工检视不可扩展。架构负责人逐个检视 PR 和代码，往往已经在大块功能写完之后才发现架构性问题。IB_Robot 现阶段最需要的，不仅是能写代码的 Agent，更是能持续检查架构约束、在早期拦住错误方向、出现问题时能够自闭环的 Agent。

openEuler Embedded 的一个典型调试场景是当新南向平台/新RTOS对接进混合部署框架 MICA，开发者发现通信失败的问题。这样一个“通信失败”的黑盒现象，背后可能的根因却分布在不同领域：

一个问题可能同时涉及Yocto、MICA、UniProton、kernel、厂商驱动等多个领域，人工定位极其耗时。即使有 AI 辅助，如果缺少统一的入口和问题导流，跨模块理解依然不清晰，常见问题的分析链路会很长。

openEuler 生态涉及海量软件包，以 ROS 包为例，逐包人工升级几乎不可持续：包数量大、依赖关系复杂、升级影响外溢（一个包的版本变更可能反向影响其他包的构建和测试稳定性），新版本还可能引入 openEuler 社区暂未提供的新软件包。

一个真实的连锁场景：

ROS 等软件包升级最大的难点，不是“传个新 tar 包再改下 spec”，而是处理海量包之间的依赖连锁、openEuler 定制化适配、跨阶段问题归因。

面对这些痛点，openEuler Embedded 的核心思路是用 Agent + Skill 体系，把零散的工程经验沉淀为“可调用、可验证、可传承”的能力模块，串起一条完整的研发维护闭环。

整体体系覆盖以下环节：

Skill 的本质，是把零散经验变成“可调用、可验证、可传承”的工程能力模块。

这条闭环的关键在于：每一个环节都不是孤立的脚本，而是可以被 Agent 按需调用、组合、并在失败时自闭环重试的能力单元。下面以三个典型实践展开。

IB_Robot 的 skills 体系面向两类视角：

目标是让开发者只在关键分歧点做判断，其余工程动作由 Agent 串起来完成。

IB_Robot 已经具备从“理解系统”到“提交协作结果”的基础骨架：

这套骨架覆盖了从架构理解、环境构建、运行验证到提交规范、issue/PR 管理、代码评审、评论闭环的全链路。它的价值不在于单点能力有多强，而在于把这些原本散落在资深工程师脑子里的经验，固化成了可被 Agent 调用、可被新人复用的标准动作。至此，开发者不再需要手工串起全部流程。

IB_Robot 开发流程介绍视频

MICA 是 openEuler Embedded 的混合部署框架，特性天然跨 Linux、RTOS、openAMP、底座等多个领域。针对这种跨域特性，设计的核心是把“任务入口”统一化，再由 workflow 做意图分流。

MICA 的 skills 体系以一个总入口 mica-overview 起步，识别用户意图后进入对应 workflow，每个 workflow 给出可执行的步骤、命令、状态确认与失败下一跳：

在技术领域上进一步细分：master、client、openAMP、弹性底座，以及平台协作接口。

MICA 场景的难点不在某一处，而在于“问题可能出现在任何一个领域”。传统做法是工程师凭经验猜根因，逐个领域排查；而 workflow 分流的价值在于：

软件包升级是 openEuler Embedded 维护工作中体量很大的一类，尤其最近的具身技术研发更依赖ROS2 humble包的升级。理想的升级流程是一句话即可触发完整的工程链：“帮我升级下 XXX ROS 包” → “没问题，提完 PR 跟你汇报”。

于是团队设计了总控 Agent openeuler-ros-upgrader 来统一管理 workspace、阶段状态、报告与失败重试路径，下挂数个 skills 串联起完整能力：

这条原则是整套流水线能“自治”的关键。ROS 升级里真正的难点恰恰不在常规环节，而在于那些上游变更、补丁冲突、依赖缺失等需要逐个分析的异常场景。如果还像传统脚本工程，遇到失败就跳过或留给人工，那当升级规模上升，人工兜底的瓶颈立刻会重现。我们的做法是让 Agent 在每一个失败点上都先尝试分析根因、生成修复方案、重试闭环，只有在确实需要策略决策时才上交给工程师。

ROS包升级流程介绍视频

当前进展（openEuler Embedded 3.30 版本）：基于 openEuler 24.03 LTS (aarch64) 新增 / 升级了 139 个 ROS Humble 软件包，功能范围主要涵盖：

后续计划（openEuler Embedded 未来版本）：根据 ROS 社区官方软件包列表，目标覆盖全量 ROS2 humble 软件包。策略上，分析全量 ROS2 humble 包的依赖关系做拓扑分层构建，及时识别升级阻塞包、需人工介入的软件包和环节，对 Agent 升级 ROS 包的能力做全面验证，沉淀更多经验到 openeuler-ros-upgrader skills。

设想未来一天的工作：

让人从“流程执行者”转变为“关键节点决策者”，让 Agent 成为 openEuler Embedded 的自治执行层。

把这条演进路径拉到更长的尺度看，Skill 体系的价值在于把重复性协作流程沉淀为自动化能力——工具自动化 → 能力 skill 化 → 使用者可复用 → 生态自驱建设。自动化成熟后，生态参与门槛降低，维护者从包揽执行转向规则制定与质量把关，使用者也能从生态消费者变为建设者，openEuler 生态可能从“维护者主导”走向“使用者自驱建设”的新阶段。

面向 AI 编程时代，openEuler Embedded 的实践给出的不仅是“用 AI 写更多代码”，而是把研发、构建、验证、协作、提交整条工程链路沉淀成可调用、可验证、可传承的 Skill 体系。这套思路已在 IB_Robot 架构守护、MICA 跨域协作、ROS 包自动化升级三个场景落地验证。下一步，将让这套能力从单仓走向全域，从开发者工具走向面向使用者的能力载体。