智能体进入 DevOps：Gitee 的全域智能研发体系如何落地

2025 年 10 月 16 日在第 27 届中国国际软件博览会“人工智能软件”分论坛上开源中国郑州研发中心总经理常毅以《智能 DevOps企业级 DevOps 全域智能体系》为主题介绍了 Gitee 将人工智能能力嵌入企业研发流程的整体思路。这套体系以 Gitee DevOps 平台为基础引入代码智能分析、编程智能体、模型服务和 MCP 等能力试图让 AI 从独立的代码生成工具逐步参与需求、文档、编码、测试、评审、交付和研发度量等环节。从其公开的产品路径来看Gitee 所关注的重点已经不只是“让 AI 帮助开发者写几段代码”而是如何把智能体接入原有工具链并在权限、数据和流程约束下执行研发任务。从辅助编程走向流程协作过去一段时间生成式 AI 在软件研发中的应用主要集中于代码补全、函数生成、错误解释和文档撰写。这些能力能够缩短部分操作时间但通常运行在研发流程之外AI 不一定了解项目历史也无法直接访问任务、代码评审、构建记录和发布状态。Agentic DevOps 所尝试解决的问题是让智能体获得更完整的项目上下文并能够调用实际研发工具。在这一模式下AI 的角色不再局限于回答问题而是可以根据任务要求读取仓库、分析代码、拆解步骤、调用构建或测试工具再将执行结果写回 Issue、Pull Request 或其他协作系统。Gitee 当前的企业研发平台已经覆盖代码管理、项目管理、文档协作、测试管理、持续集成和效能度量等模块。这些原有能力为智能体进入研发流程提供了数据和工具基础但智能体能否稳定发挥作用仍取决于上下文质量、权限配置、过程审计和结果验证机制。五类能力覆盖研发主要环节根据常毅在软件博览会上的介绍Gitee 将智能研发能力划分为五类。智能文档创作AI 可以辅助生成流程图、架构图和项目文档也可以检查文档结构和内容规范。这类能力的价值不仅在于减少文档编写时间还在于降低文档与代码长期脱节的概率。不过自动生成的文档仍需要与代码版本建立关联否则随着项目持续迭代文档仍可能再次失效。智能协同管理在项目协作环节AI 可以参与 Pull Request 描述生成、代码审查辅助、构建错误分析和问题分类。与单纯生成代码相比这类场景更依赖项目历史、团队规范和变更上下文。例如判断一次代码修改是否合理不能只分析当前文件还需要结合关联需求、历史提交、测试结果和项目约束。智能代码开发代码生成、单元测试生成、缺陷解释、修改建议和代码评审是目前智能研发中较成熟的一组应用。不过企业实际关注的不只是“代码能否生成”还包括生成内容是否符合现有架构、能否通过测试、是否引入新的安全风险以及开发者能否追踪 AI 修改了什么。智能数据度量研发平台积累了需求流转、提交、评审、构建、测试和交付等数据。AI 可以将这些数据转换为图表、摘要和异常提示辅助团队观察研发过程。但研发度量不能简单等同于人员考核。提交数量、代码行数和任务完成数量只能反映局部活动真正有价值的度量还需要结合交付周期、返工情况、缺陷率和业务结果。智能平台助手平台助手承担模型、工具、知识库和研发数据之间的连接工作。对于企业而言这一层的重要性往往高于单个 AI 功能。不同团队可能使用不同模型和开发工具数据也分布在代码仓库、项目管理、文档、流水线和制品系统中。只有完成统一接入和权限治理智能体才可能参与跨系统任务。Gitee Scroll将代码转化为可查询的项目知识大型软件项目通常存在一个长期问题代码持续更新但项目知识主要保存在少数核心成员的经验中。需求背景、架构决策、模块关系和历史问题可能分散在代码、提交记录、Issue、聊天记录和文档中。新成员加入后需要花费较长时间理解项目当核心成员离开时部分知识也可能随之流失。Gitee Scroll 的思路是通过大模型分析代码结构、模块依赖和业务逻辑生成可阅读、可检索和可问答的项目理解视图。其目标是把代码仓库中隐含的结构信息转化为更容易使用的知识资产。这种能力适合应用于项目交接、代码阅读、架构梳理和新人培训但自动生成的项目理解不能完全替代正式设计文档。对于关键架构决策、合规要求和业务规则仍需要由项目负责人确认。因此更合理的使用方式是将 Scroll 作为知识整理和检索工具而不是把模型输出直接视为项目事实。Xtreme CLI从生成代码到执行开发任务Gitee 展示的 Xtreme CLI 是面向命令行和项目环境的编程智能体。与传统代码补全工具相比它更强调对整个项目进行语义分析并根据任务制定执行步骤。智能体可以调用 Shell、Git、构建和测试工具在代码修改后继续验证结果。Gitee 还提出了沙盒运行、后台执行、权限配置和多模型接入等企业场景能力。这意味着编程智能体的工作范围正在从“生成一个函数”扩展到“处理一个开发任务”例如分析 Issue 和相关代码定位可能需要修改的模块生成修改方案调整代码并补充测试运行构建和测试命令整理变更摘要并发起 Pull Request。不过执行范围越大潜在风险也越高。错误的命令、过度修改、依赖误判或测试覆盖不足都可能影响项目稳定性。因此在企业环境中智能体是否支持最小权限、操作确认、沙盒隔离、日志记录和人工审批往往比单次生成代码的速度更加重要。MCP 将智能体接入真实研发工具智能体要参与研发工作需要一种标准化方式获取上下文和调用工具。MCP即模型上下文协议正被用于解决这一连接问题。通过 MCP ServerAI 客户端可以在授权范围内访问仓库文件、Issue、Pull Request、项目和用户信息并执行创建任务、补充评论或发起 PR 等操作。Gitee 后续发布的企业版 MCP Server进一步面向企业内部研发数据支持访问企业仓库、Issue、Pull Request、项目和迭代等信息。企业可以通过独立令牌为不同数据和操作配置权限。在此基础上Gitee 又增加了 Remote mcp-gitee。与需要在本地安装和运行 MCP Server 的方式不同远程版本由服务端托管支持通过兼容 MCP Streamable HTTP 协议的客户端接入。其公开能力包括读取仓库和文件、获取用户信息、处理 Issue 和 Pull Request 等。对于个人开发者和小型团队这种方式降低了部署门槛对于企业而言则需要进一步评估令牌管理、访问控制、日志审计和敏感代码传输等问题。MCP 的实际价值不在于增加一个新的接口而在于使智能体能够沿用已有研发系统中的数据和权限体系。它让“AI 理解项目”和“AI 执行操作”之间建立了连接。从单个智能体走向多智能体协作当智能体能够调用研发工具后下一步是将不同类型的任务交给不同智能体处理。例如需求智能体负责补充用户故事和验收标准代码智能体负责修改程序测试智能体负责生成和执行测试安全智能体负责分析风险文档智能体负责同步变更说明。Gitee 在 GOTC 2025 的公开分享中将其描述为覆盖需求、编码、测试、交付和运维的 Agentic DevOps 体系并提到通过 GiEngine 推理引擎和模力方舟平台提供模型部署、微调及治理方面的支持。多智能体协作并不意味着多个模型可以自动组成稳定的软件团队。不同智能体之间可能出现上下文不一致、任务重复、责任边界模糊和错误相互传递等问题。因此多智能体系统需要统一的任务编排、状态管理、权限控制和结果验收机制。MCP 可以解决部分工具连接问题但无法单独解决任务决策和质量责任问题。企业落地更需要关注可控性从公开信息看Gitee 的智能研发路线已经形成了较清晰的层次底层是原有 DevOps 平台以及代码、项目、测试和交付数据中间层是模型平台、知识分析和 MCP 工具接入上层则是代码、文档、测试、协同和度量智能体。这一结构体现了企业级 AI 研发与个人编程助手之间的差异。企业需要考虑的不只是模型能力还包括以下问题智能体能够访问哪些仓库和业务数据哪些操作可以自动执行哪些必须人工确认AI 生成的代码由谁审核和负责操作过程是否能够记录、回溯和审计模型更换后研发流程是否仍能稳定运行私有代码和业务数据是否满足安全及合规要求。如果这些问题没有解决智能体可能只是为原有工具链增加新的复杂度。反过来如果企业能够建立清晰的数据权限、任务边界和验收机制智能体则有机会减少信息查找、重复编码、文档整理和流程操作等低价值工作。从“增加 AI 功能”转向重构研发流程Gitee 对智能 DevOps 的探索反映了软件研发平台正在发生的一项变化AI 开始从编辑器插件进入项目管理、代码评审、测试、交付和知识管理系统。Gitee Scroll 试图解决代码知识难以沉淀的问题Xtreme CLI 将 AI 的能力扩展到项目级任务MCP 则为智能体连接代码仓库和协作数据提供接口。后续推出的远程 MCP 和企业版 MCP Server也说明这一体系正在从概念展示转向具体的工具接入和权限配置。但智能研发的成熟程度最终不能只通过生成速度或功能数量判断。更关键的指标是智能体是否理解项目约束执行过程是否透明输出结果是否可以验证出现问题后是否能够回滚以及企业是否仍然掌握数据和决策边界。从这个角度看所谓 AI 原生研发并不是让 AI 完全替代开发者而是重新划分人与工具之间的工作边界让智能体承担信息整理、重复执行和辅助分析让开发者继续负责架构设计、业务判断、质量把关和最终决策。