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 Server，AI 客户端可以在授权范围内访问仓库文件、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 完全替代开发者，而是重新划分人与工具之间的工作边界：让智能体承担信息整理、重复执行和辅助分析，让开发者继续负责架构设计、业务判断、质量把关和最终决策。