2025年10月16日，在第27届中国国际软件博览会期间，开源中国郑州研发中心总经理常毅受邀出席“人工智能+软件”分论坛，并发表题为《智能 DevOps，企业级 DevOps 全域智能体系》的主题演讲。 第27届中国国际软件博览会于2025年10月15日至17日在郑州举行，以“开源构筑新生态，软件智造新未来”为主题，围绕AI重塑软件、工业软件创新发展和开源生态建设等议题展开交流。常毅在演讲中系统介绍了Gitee在企业智能研发领域的探索，展示了以“Gitee DevOps + Xtreme极智AI”为核心的智能研发体系。 DevOps为什么需要从“自动化”走向“智能化”？ 过去十余年，DevOps解决的核心问题，是如何打通开发与运维，通过代码托管、持续集成、自动化测试和持续交付，减少人工操作，提高软件交付效率。 但传统DevOps工具通常只能按照预先设定的规则执行任务。当需求描述不完整、代码结构复杂、测试失败原因不明确，或者项目风险需要结合多种信息判断时，系统仍然高度依赖人工分析。 大模型与智能体的出现，使DevOps开始从“流程自动化”迈向“任务智能化”。 常毅在演讲中提出，AI在研发领域的价值，并不只是为现有工具增加一个问答入口，而是要在工作效率、信息获取、代码质量和交付可靠性等关键环节形成实质性提升。其核心变化在于：AI不再只是等待开发者提问的辅助工具，而是逐步成为能够理解上下文、规划任务、调用工具并反馈结果的研发智能体。 什么是智能DevOps？ 智能DevOps可以理解为：在需求、设计、编码、测试、交付和度量等研发流程中，引入具备上下文理解、任务规划和工具调用能力的AI智能体，使部分重复性分析与执行工作能够自动完成，同时通过权限控制、审计记录和人工确认保证过程安全可控。 五大模块覆盖企业研发核心场景 围绕企业软件研发的完整流程，Gitee提出了由五类智能能力组成的全域智能体系。

1. 智能文档创作 研发文档经常面临更新不及时、格式不统一以及内容与代码脱节等问题。 智能文档能力可以辅助完成技术文档撰写、规范检查，以及流程图和架构图生成，减少重复整理工作。更重要的是，当文档生成能力能够与代码仓库、Issue和项目数据连接后，文档便有机会随着项目变化持续更新，而不再是长期无人维护的静态文件。
2. 智能协同管理 智能协同管理主要面向Pull Request、工作项、构建任务和团队协作过程，包括PR描述生成、代码变更解读、辅助审查、误报识别以及构建问题分析等能力。 它并不是取代项目经理或代码审查人员，而是先对大量上下文进行整理，把值得关注的问题、风险和变化呈现给相关人员，从而降低信息筛选成本。
3. 智能代码开发 在代码开发阶段，AI可以参与代码生成、单元测试生成、代码解释、缺陷定位、修复建议和评审建议等工作。 与只根据当前文件补全代码的传统编程助手相比，面向企业场景的Coding Agent需要理解整个项目的目录结构、技术栈、业务逻辑和开发规范，还需要能够调用Git、Shell、构建系统和测试工具，对生成结果进行验证。
4. 智能数据度量 企业研发平台中积累着工作项、提交记录、Pull Request、构建、测试、缺陷和制品等大量数据。 智能数据度量能力可以帮助团队生成图表、仪表盘和分析摘要，辅助管理者识别交付节奏、质量变化和潜在风险。不过，AI生成的结论仍需要建立在完整、准确和口径统一的研发数据之上。
5. 智能平台助手 智能平台助手承担连接模型、数据、工具和知识资产的作用。 企业可以通过统一平台管理不同大模型、知识库、研发工具和访问权限，并根据具体任务调用合适的模型与工具。它构成了不同智能体共同运行的基础，也是企业将零散AI功能升级为系统化智能研发能力的重要前提。 Gitee Scroll：让代码资产转化为可理解的知识资产 企业真正难以管理的往往不是代码文件本身，而是代码背后的业务逻辑、设计决策和演进过程。 随着项目规模不断扩大，文档可能落后于代码，模块之间的调用关系难以追溯，关键知识则分散在开发者个人经验、Issue、PR讨论和历史提交中。新成员需要花费大量时间理解项目，熟悉系统的老成员也会被反复询问相似问题。 针对这一问题，Gitee在演讲中介绍了代码智能分析工具Gitee Scroll。 根据Gitee公开资料，Gitee Scroll能够利用大模型提取项目架构、业务逻辑和代码知识，形成可阅读、可问答、可推理的项目理解视图。其价值并不仅是“解释某段代码”，而是帮助团队建立项目级知识入口，使代码结构、业务关系和研发知识更容易被检索与复用。 Xtreme Cli：从生成代码走向执行开发任务 在智能代码开发领域，Gitee还介绍了自研的核心智能体Xtreme Cli。 普通AI编程助手通常专注于代码补全、函数生成或问题问答，而Coding Agent需要面对更加完整的开发任务，例如理解需求、分析仓库、修改多个文件、执行测试、处理错误并提交代码。 Gitee公开资料显示，Xtreme Cli能够进行项目语义分析和架构模式识别，将复杂任务拆分为多个阶段，并调用构建测试工具、Shell命令和Git等工具执行操作。同时，其支持沙盒运行、后台模式、权限配置和多模型接入，以适应企业对数据安全、过程可控和模型部署方式的不同要求。 这里的关键变化是：AI输出的不再只是一段供开发者复制的代码，而是一个包含分析、修改、测试和反馈的任务过程。 但这并不意味着企业可以将复杂项目完全交由AI处理。对于核心业务、架构调整和高风险代码，仍然需要保留人工审查、测试验证和合并审批。 MCP：连接智能体与DevOps工具链的桥梁 智能体要真正参与企业研发，仅仅拥有语言理解能力还不够。 它还需要知道当前用户是谁、能够访问哪些仓库、可以读取哪些Issue、是否有权限修改代码，以及执行结果应当写入哪个系统。MCP所解决的，正是模型与外部数据、工具和业务系统之间的标准化连接问题。 在常毅介绍的体系中，Gitee通过MCP封装智能体需要的上下文、状态和调用接口，使智能体能够在权限边界内读取研发数据、调用工具、调度流程并写回结果。该体系既可以连接Gitee自身的研发工具，也可以扩展到第三方企业工具链。 此后，Gitee进一步发布了面向企业用户的MCP Server。通过企业版API，AI助手可以访问权限范围内的代码仓库、Issue、Pull Request、项目和迭代等数据。Gitee MCP随后还增加了远程访问方式，使部分场景无需在本地安装MCP Server即可连接AI助手。 因此，MCP更适合被理解为智能体进入企业研发环境的“标准接口层”，而不是一个能够单独完成全部研发工作的AI产品。 从演讲构想走向产品化：Gitee AI队友持续扩展 截至2026年7月，Gitee公开帮助文档中已经列出了Pull Request审查队友、安全扫描助手、代码研发助手和PMO助手等多类AI队友，并提供统一的AI队友工作台，用于查看任务产出、覆盖仓库和资源消耗等信息。 其中，PR审查队友可以从功能逻辑、安全性、性能和可维护性等维度分析代码变更，但其产品定位仍然是补充人工审查盲区、提示潜在问题，而不是代替Reviewer作出最终决策。安全扫描助手则结合软件成分分析能力，对依赖组件和CVE漏洞进行识别与风险提示。 代码研发助手进一步把智能体接入Issue到Pull Request的工作链路：分析需求描述、评估任务复杂度、创建分支、修改代码并自动提交PR。Gitee的使用指南也明确建议，将其与PR审查队友和人工决策结合，形成“AI实现、AI初审、人工确认”的协作闭环。 PMO助手则面向项目管理与Issue治理，可以按照每日、每周或每月周期生成进度报告和风险预警，并在Issue创建或更新时执行分类、优先级判断等任务。这意味着智能体的应用范围正在从编码与安全环节，逐步扩展到项目管理和研发治理。 这些后续产品进展表明，软博会演讲中提出的全域智能DevOps，并非单一的代码生成工具，而是在向覆盖需求、编码、审查、安全、项目管理和数据分析的智能体体系演进。 多智能体协作如何形成研发执行闭环？ 在传统研发模式中，需求分析、代码开发、测试、安全检查和项目管理通常由不同工具分别完成，数据和上下文也容易分散。 多智能体体系的思路，是让不同智能体负责不同类型的任务： 代码研发智能体根据Issue实现功能； 审查智能体分析代码变更与潜在缺陷； 安全智能体检查第三方依赖和漏洞风险； 文档智能体整理项目知识与变更说明； PMO智能体跟踪项目进度并生成风险报告。 这些智能体通过统一的权限、数据和工具接口共享必要上下文，再将处理结果写回Issue、Pull Request、报告或项目看板，形成“感知—分析—执行—反馈”的工作闭环。 在GOTC 2025相关分享中，Gitee也将AI队友描述为主动参与研发流程的协作角色：在需求阶段辅助补全用户故事与验收标准，在编码测试阶段生成代码、单元测试和安全报告，在交付阶段生成修复PR并辅助分析风险。 需要注意的是，多智能体协作仍然必须受到权限管理、任务审计、质量门禁和人工审批的约束。智能体越接近生产环境，企业越需要明确哪些操作可以自动执行，哪些操作必须经过人工确认。 企业落地智能DevOps，可以从哪几步开始？ 结合Gitee目前公开的产品能力，企业落地智能DevOps更适合循序渐进，而不是一开始就追求全流程无人化。 第一步，从高频、低风险任务开始。 优先选择PR摘要、代码解释、文档总结、测试用例生成和项目周报等容易验证结果的场景。 第二步，建立可信的研发上下文。 整理代码仓库、Issue规范、开发文档、代码规范和权限体系。没有完整上下文，智能体很难生成稳定可靠的结果。 第三步，通过MCP连接现有工具链。 按照最小权限原则开放仓库、项目和工作项数据，避免直接授予智能体过大的修改或发布权限。 第四步，保留人工质量门禁。 代码合并、生产发布、架构变更和高风险漏洞处理等关键操作，仍应由负责人审批。 第五步，用数据评估实际效果。 持续观察审查耗时、问题发现率、任务返工率和AI建议采纳率，根据实际结果调整智能体的规则、权限和使用范围。 常见问题 智能DevOps会取代程序员吗？ 目前更合理的定位是改变程序员的工作分工，而不是完全取代程序员。 AI更适合承担信息整理、初步分析、重复编码、测试生成和风险提示等任务。需求取舍、系统架构、复杂业务判断以及最终质量责任，仍然需要研发人员承担。 Coding Agent和普通AI代码补全有什么区别？ 代码补全工具主要根据当前文件和光标上下文生成代码。 Coding Agent则需要理解项目结构和任务目标，能够修改多个文件、调用Git与测试工具，并根据执行结果继续调整方案。两者的主要区别在于，前者侧重内容生成，后者侧重任务执行。 MCP是否等于企业内部的“AI操作系统”？ MCP本质上是一种连接模型、数据和工具的协议与接口机制。 它可以成为企业智能体平台的重要基础，但完整的企业级AI系统还需要身份认证、权限管理、模型管理、日志审计、安全隔离和质量评估等能力。 企业应该直接让AI自动修改和发布代码吗？ 不建议在缺少安全边界和验证机制的情况下直接开放生产权限。 更稳妥的方式是先让AI创建分支或Pull Request，再经过自动测试、AI辅助审查和人工审批后完成合并与发布。 结语：AI原生研发的重点不是“无人”，而是“协同” 从Gitee Scroll对代码知识的提取，到Xtreme Cli对开发任务的执行，再到MCP对工具、数据和权限的连接，以及AI队友在审查、安全、编码和项目管理场景中的持续扩展，Gitee正在尝试把分散的AI能力嵌入完整的DevOps流程。 这一路径所指向的，并不是简单地在代码托管平台上增加几个AI按钮，而是让AI从被动问答工具，逐步转变为能够参与研发流程的数字协作者。 常毅在软博会演讲中将Gitee定位为面向未来的企业智能研发操作系统。对于企业而言，这一愿景能否真正落地，最终仍取决于三项基础能力：高质量的研发数据、清晰可控的权限边界，以及人与智能体之间明确的责任分工。 未来的DevOps或许不会走向完全“无人化”，但很可能走向由开发者、平台工具与多个专业智能体共同参与的协同研发模式。 面对持续演进的软件工程范式，持续智能化的真正意义，不是盲目追求AI替代，而是让人从重复工作中释放出来，把更多精力投入到需求判断、系统设计和技术创新之中。