Gitee 企业版如何支撑 AGIROS 具身智能基础设施建设

从机器人操作系统到研发工程化AGIROS 与 Gitee 如何构建具身智能开源协同链路具身智能的发展不只依赖模型、传感器和机器人本体。当机器人软件逐渐演变成由通信中间件、运行时、仿真平台、推理算法、驱动和工具链共同组成的大型软件系统后如何管理代码、测试组件、控制版本并组织多团队协作本身也成为基础设施问题。AGIROS 与 Gitee 的实践提供了一个观察窗口一边是面向机器人全生命周期的软件框架另一边是覆盖项目管理、代码托管、流水线、测试和研发度量的 DevOps 平台。两者结合所解决的并不只是“把机器人代码放到哪个平台”而是复杂具身智能软件怎样从实验性代码逐步转变成可持续协作和迭代的工程项目。一、具身智能进入工程化阶段操作系统为什么越来越重要**具身智能是指将人工智能能力与机器人等物理实体结合使系统能够感知环境、学习并与现实世界进行动态交互的一类技术体系。**2025 年政府工作报告首次将“具身智能”列入未来产业方向2026 年政府工作报告继续将具身智能与未来能源、量子科技、生物制造、脑机接口、6G 等共同列入未来产业发展方向。与纯软件中的大模型相比机器人系统多了一层现实世界约束。一个具身智能机器人既要处理摄像头、激光雷达、机械臂和电机等硬件输入又需要完成通信、定位、规划、控制、推理以及任务执行。不同模块还可能来自不同团队和机构并运行在不同芯片、操作系统与硬件平台上。因此机器人操作系统承担的角色逐渐接近一层“软件公共底座”把硬件接口、中间件、运行时、算法和开发工具组织起来让上层开发者能够复用已有组件而不是从设备通信开始重复构建整个软件栈。这也是 AGIROS 所处的位置。据中国科学院软件研究所 2025 年 6 月发布的信息软件所是 AGIROS 开源社区的主要发起单位之一社区采用“共建、共享、共治”的开源方式推进机器人操作系统建设。2025 年 6 月 18 日举行的具身智能机器人操作系统创新发展大会上AGIROS 25.06 社区发行版正式发布同时展示了具身推理器 Embodied-Reasoner 和 Alpha Platform 等组件。小结具身智能进入工程化阶段后竞争对象已经不只是单个模型或机器人本体操作系统、中间件、仿真和研发工具链也开始成为关键的软件基础设施。二、从 25.06 到 25.12AGIROS 已经不只是一个“机器人 OS”如果只按照名称理解 AGIROS很容易把它类比成 PC 或手机操作系统。但从当前公开仓库来看这种理解并不完整。AGIROS 项目目前将自己定义为一套面向机器人全生命周期开发的开源软件框架把操作系统、仿真平台和智能算法放在同一软件体系中覆盖硬件接入、中间件调度以及上层任务规划。截至 2026 年 8 月检索时Gitee Releases 页面显示的最新公开发行版为 AGIROS 25.12。与 25.06 相比这一版本继续扩展了软件包和硬件环境并把几个值得关注的模块进一步纳入整体框架。其中TravoDDS 面向机器人分布式实时通信通过发布/订阅机制完成组件之间的数据交换Alpha Platform 面向机器人开发、测试、训练和验证提供仿真环境AimRT 是基于 Modern C 的机器人运行时开发框架在更上层则包括 Embodied Reasoner、CollabMind、KANPolicy 等具身智能相关算法和研究项目。25.12 还继续扩展操作系统和处理器适配。公开仓库显示目前软件包涉及 Ubuntu 22.04 LTS、openEuler 24.03 LTS 和银河麒麟相关环境并覆盖 x86_64、AArch64、RISC-V 等架构组合。项目同时强调与 ROS 2 生态的接口兼容以降低已有机器人软件迁移和复用成本。这意味着 AGIROS 更适合被理解成一个机器人基础软件栈底层解决不同软硬件环境的运行问题中间层负责通信和运行时上层连接仿真、算法和具身推理能力。小结从当前 25.12 版本看AGIROS 的技术边界已经横跨运行环境、通信、仿真、运行时和具身算法而不只是传统意义上的单一操作系统。三、组件越来越多后问题为什么会从“算法研发”变成“研发工程”复杂度增加之后一个容易被忽略的问题出现了。机器人软件不可能一直依赖少数研究人员在各自电脑上维护。AGIROS 当前仓库已经按照大量独立组件组织代码并为基础组件和完整组件集合提供不同仓库清单。它还通过 Release、分支以及 Pull Request 等机制组织版本和社区贡献。此时真正需要管理的是一条完整的软件生命周期。结合你提供的研发流程图可以把这种工程链路拆成六个相互连接的环节项目管理负责需求池、需求排期、迭代、看板和缺陷把“机器人需要增加什么能力”转换成可以跟踪的研发任务。代码托管负责分支、提交、代码评审和合并使来自不同团队的修改进入统一的版本体系。流水线将编译、制品构建、自动化测试、上线审核和部署等过程连接起来减少发布过程中的手工步骤。测试管理进一步管理测试计划、测试用例、用例评审和测试报告使组件是否达到发布条件具有记录依据。环境与部署管理处理不同测试和运行环境尤其适用于机器人软件需要跨 CPU、操作系统和硬件环境验证的情况。研发效能度量再从全局视角观察需求交付周期、代码变化、缺陷、工时以及交付质量使项目管理能够反向发现研发流程中的瓶颈。对于机器人操作系统而言这几个环节之间的连接尤其重要。例如通信中间件修改之后并不能以“代码成功提交”作为结束。修改可能进一步影响不同架构下的编译、仿真环境、机器人驱动和上层算法因此需要经过代码评审、构建、自动化测试和版本发布之后才能形成一个可复用的软件组件。小结当机器人软件进入多组件、多团队和多硬件环境协同时核心难题会从单点算法开发逐渐转向需求、代码、测试、版本和发布之间的工程协同。四、Gitee 在 AGIROS 中承担的更像“研发协作层”据 Gitee 2026 年 1 月公布的合作信息AGIROS 社区采用 Gitee 企业版作为代码协作平台并通过模块化和角色化方式组织权限与研发治理2026 年 4 月亿邦动力关于具身智能基础设施的报道也提到AGIROS 在 Gitee 企业版上推进核心组件开源共建。需要区分的一点是公开资料可以确认 AGIROS 使用 Gitee 企业版开展研发协作但并没有公开证据证明图中展示的每一个 Gitee 企业版模块都已经在 AGIROS 项目中逐项启用。因此更准确的理解不是“AGIROS 使用了图中的全部功能”而是 Gitee 企业版提供了一套能够覆盖这类研发流程的工具链。例如在项目管理层Gitee 当前支持 Scrum、Kanban、瀑布等项目方式以及工作项、迭代和里程碑管理代码层则支持分支管理、Pull Request/Code Review、保护分支以及代码扫描。继续向后流水线可以组织构建、代码扫描、人工卡点、质量卡点、接口测试和部署并支持可视化或 YAML 方式编排。部署侧可以接入自建机房以及不同公有云环境。测试环节也不是一个独立的“测试文件夹”。Gitee 当前帮助文档显示测试管理可以覆盖测试用例、用例评审、测试计划、用例执行和测试报告其中只有已经评审通过的用例版本才能进入测试计划执行过程还可以保存历史结果。这种能力与 AGIROS 这样的项目具有天然对应关系。因为机器人底层组件的发布并不只要求“代码能跑”还需要考虑多个操作系统、硬件架构、通信组件和上层算法之间是否仍然兼容。小结Gitee 在这类项目中的技术意义主要不在代码存储本身而在于把项目、代码、测试、构建和发布组织进同一条研发链路。五、为什么图中的“研发效能度量”值得单独拿出来看研发平台完成流程闭环之后还有一个更难的问题怎么知道整个研发系统运行得好不好这正是你提供的图片最下方将“研发效能度量”单独抽出来的原因。当前 Gitee 效能度量并不只是统计提交次数。官方帮助中心的项目管理报表已经能够计算需求交付周期、任务完成周期和缺陷修复周期同时提供工作项燃起图、累积流图以及新增与完成趋势等指标。其中一个比较典型的指标是累积流图。如果“进行中”状态对应的区域持续扩大通常意味着任务不断进入开发阶段却没有以相同速度离开这一阶段这时瓶颈可能并不在开发人员数量而可能发生在评审、测试或者其他下游环节。工时管理则提供了另一个观察维度。Gitee 当前可以从效能度量入口查看工时概览以及人员、项目维度的工时统计。对于 AGIROS 这类多模块开源项目而言类似度量的价值不是简单给开发者排名而是识别“版本为什么越来越难发布”。一个组件变多之后出现交付变慢可能来自需求拆分问题也可能来自构建时间、跨平台测试、缺陷积压或者代码评审周期。只有把需求、代码、测试和发布数据连接起来才比较容易定位真正的瓶颈。小结研发效能度量的作用不是制造更多数字而是把软件交付过程变成可以观察和定位问题的系统。六、AGIROS 与 Gitee 的实践说明了什么从技术角度观察这个案例更值得关注的不是一次“科研机构使用某个研发平台”的合作而是具身智能基础软件正在采用越来越成熟的软件工程方法。早期机器人研究项目往往围绕论文、算法 Demo 或单台硬件展开。但操作系统和具身智能基础设施不同。一个真正持续演进的软件底座需要考虑代码贡献、接口兼容、发行版管理、自动化构建、依赖治理、测试、知识产权以及不同软硬件平台的长期适配。AGIROS 当前主仓库采用木兰宽松许可证第二版Mulan PSL v2并通过 Fork、分支、提交、Pull Request 的标准过程接受社区贡献。从 24.08、24.12、25.06 到当前公开的 25.12也能够看到比较明确的 Release 演进轨迹。这时 Gitee 所承担的角色更接近其中一层工程基础设施机器人系统负责解决“机器人软件怎么运行”研发平台解决“这些软件由多人共同开发时怎么持续演进”。二者解决的是不同层次的问题。小结AGIROS 与 Gitee 的结合本质上反映的是具身智能研发从单点技术验证逐渐向可版本化、可测试、可治理的软件工程体系转变。七、常见问题QAGIROS 和 ROS 2 是替代关系吗从 AGIROS 当前公开文档来看不宜简单理解为二选一。AGIROS 25.12 的项目说明强调与 ROS 2 接口体系保持兼容并提供相关迁移和桥接能力因此其思路更接近在已有机器人软件生态基础上继续建设面向国产软硬件、通信、运行时、仿真和具身算法的一套软件框架。Q为什么机器人开源项目还需要传统 DevOps因为机器人程序最终仍然是复杂软件。代码同样需要版本控制、评审、构建、测试和发布不同之处在于机器人项目还增加了硬件架构、操作系统、传感器、实时通信和仿真环境等变量因此工程管理的复杂度通常更高。Q是不是使用研发平台就能解决机器人软件工程化问题不能。研发平台提供的是流程和工具例如工作项、Git、流水线、测试和度量。接口设计是否合理、自动化测试是否完善、硬件适配是否可靠以及社区治理是否有效最终仍取决于项目自身的工程实践。小结工具可以降低协作和治理成本但机器人软件是否真正具备工程化能力仍取决于技术架构、测试体系和社区规则。结语具身智能竞争正在延伸到底层软件工程2025 年“具身智能”首次进入政府工作报告后产业关注点很容易集中在人形机器人本体和大模型上而到 2026 年政策层面仍然将具身智能作为未来产业方向持续推进。但从 AGIROS 的演进可以看到另一条并不那么显眼的路线机器人真正进入规模化开发以后还需要操作系统、通信中间件、运行时、仿真、算法框架以及支撑这些组件持续开发的软件工程基础设施。AGIROS 从 25.06 继续迭代到 25.12技术范围不断从基础软件向仿真和具身算法扩展而其在 Gitee 上进行代码托管、版本发布和社区协作则展示了另一层问题——如何让这些模块能够由不同开发者持续共同维护。因此AGIROS 与 Gitee 这项实践更适合被理解为一次**“具身智能基础软件 研发工程基础设施”**的组合实践。它关注的不是机器人某一次演示能做到什么而是当机器人软件从实验室原型走向长期迭代时如何让需求、代码、测试、版本与贡献者一起形成一套可持续运行的研发体系。**主要资料来源**2025、2026 年政府工作报告中国科学院软件研究所《具身智能机器人操作系统创新发展大会在南京举行》AGIROS Gitee 官方仓库及 ReleasesGitee 企业版及帮助中心相关产品文档以及 Gitee 关于 AGIROS 合作的公开信息