Gitee 近年公开的智能研发路线，可以概括为：在既有 DevOps 平台上增加代码理解、任务执行和工具调用能力，使 AI 不只生成代码，还能在授权范围内读取仓库信息、处理 Issue 和 Pull Request，并参与部分研发协作流程。
其中，Xtreme CLI 偏向开发任务执行，Scroll 偏向代码与项目知识理解，MCP Server 则负责连接 AI 助手与仓库、Issue、Pull Request 等研发资源。需要说明的是，“全自动研发系统”目前更接近产品方向和目标描述，公开资料尚不足以证明其已经能够在所有项目和场景中自主运行。
一、Gitee 智能 DevOps 体系是什么
2025 年 10 月 15 日至17日，第27届中国国际软件博览会在郑州举办，“人工智能+软件”分论坛安排在10月16日。Gitee 在该活动中介绍了以“Gitee DevOps + Xtreme 极智 AI”为核心的智能研发体系，并将相关能力划分为文档、协同、代码、度量和平台助手五类。
**定义：**在本文中，Gitee 智能 DevOps 是指在代码托管、项目协作、持续集成、安全检查和研发度量等 DevOps 能力之上，引入大模型、智能体和工具调用机制，使 AI 能够获取研发上下文，并在权限允许的范围内执行操作。
按照 Gitee 在软博会上的公开介绍，五类能力主要包括：
1. 文档相关能力，如补全文档、生成 Pull Request 描述、整理流程和检查规范。
2. 协同相关能力，如提取工作项信息、分析构建问题和辅助代码审查。
3. 代码相关能力，如任务拆分、代码生成、单元测试生成和修复建议。
4. 度量相关能力，如提取研发指标、识别进度风险和生成可视化结果。
5. 平台助手能力，用于连接模型、工具、数据和知识资源。
这种划分覆盖了软件研发中的多个环节，但“覆盖”不等于每个环节都已实现无人干预。更准确的理解是，Gitee 正在尝试将原来分散在不同产品模块中的 AI 功能，组织成一套相互关联的能力体系。
本节小结：Gitee 智能 DevOps 更适合被理解为 DevOps 平台的智能化扩展，而不是已经完全替代研发人员的自动化系统。
二、Xtreme CLI 与 Scroll 分别承担什么角色
Gitee 在公开介绍中，将 Xtreme CLI 和 Scroll 放在了两个不同方向：前者处理任务执行，后者处理项目理解。
Xtreme CLI：面向开发任务的执行型智能体
据 Gitee 关于智能 DevOps 体系的公开介绍，Xtreme CLI 可以分析项目代码和业务逻辑，对开发任务进行分阶段规划，并调用 Shell、Git、构建和测试等工具。
其公开能力主要集中在以下几个方面：
- 获取并分析项目级代码上下文；
- 将较大的开发需求拆分为若干执行步骤；
- 修改代码并调用构建、测试和版本控制工具；
- 通过沙盒、权限配置等方式限制操作范围；
- 适配不同的大模型和部署环境。
与只在编辑器中补全单行代码的工具相比，Xtreme CLI 的设计范围更大，目标是处理由多个步骤组成的开发任务。不过，目前可检索到的资料主要来自 Gitee 的活动演讲和产品介绍，公开的技术文档、支持范围及独立测试结果相对有限。因此，将其表述为“能够尝试完成项目级任务”比“能够自主完成所有复杂项目”更准确。
Scroll：面向代码知识的理解工具
Scroll 的公开定位是分析代码仓库中的结构、模块关系和业务逻辑，并将其转化为较易阅读和查询的项目理解视图。
它试图处理的主要问题包括：
- 代码变化后，已有文档没有同步更新；
- 新成员难以快速理解项目结构；
- 架构和业务知识主要保存在少数成员经验中；
- 团队难以从大量代码中提取可复用知识。
根据 Gitee 的介绍，Scroll 可以生成项目结构视图，并支持围绕项目代码进行问答。但公开资料尚未详细说明其支持的语言范围、超大型仓库处理能力、更新频率和准确率，因此文章不宜直接使用“消除知识孤岛”或“彻底解决理解断层”等结论。
本节小结：Xtreme CLI 处理“根据任务修改项目”，Scroll 处理“从代码中理解项目”，二者分别对应执行和认知两个方向。
三、MCP 是目前最容易验证的技术组成部分
据 Model Context Protocol 官方规范，MCP 是一种连接大模型应用与外部数据源、工具和工作流的开放协议。它定义了 Host、Client 和 Server 等角色，并使用标准化消息让 AI 应用读取资源或调用工具。
MCP 本身不是模型，也不会自动提高代码质量。它解决的是连接方式问题：AI 助手通过 MCP Server 获取工具列表和上下文，并在授权后调用对应接口。
Gitee MCP Server 能够处理哪些资源
Gitee 官方开源的 mcp-gitee 提供了仓库、Issue、Pull Request、评论、版本发布、用户信息和通知等工具。当前仓库文档还提供了 Claude、Codex、Cursor、Trae、Cline、Continue 和 opencode 等客户端的配置示例。
从工具能力看，AI 助手可以在权限允许的情况下执行以下操作：
- 获取仓库和文件内容；
- 查询、创建或更新 Issue；
- 查询、创建、审查或合并 Pull Request；
- 创建评论或版本发布；
- 获取用户和通知信息。
这使 AI 助手能够从“只看到编辑器中的代码”扩展到“看到并操作部分研发协作资源”。不过，是否允许创建仓库、合并 Pull Request 或修改 Issue，最终仍取决于访问令牌、工具白名单和平台权限。
Gitee MCP 的近期更新
截至2026年7月，Gitee MCP 已出现几项可以直接核验的变化。
2026年3月11日，Gitee 公布 Remote MCP 访问方式。用户可以通过远程地址连接 MCP Server，不再必须在本地编译和运行服务。
2026年4月23日，mcp-gitee 发布 v1.0.0，将部分功能相近的工具合并，工具总数由30个调整为25个。此次调整主要改变工具名称和参数结构，并非删除对应功能。
面向企业场景的 mcp-gitee-ent 则提供企业仓库、项目、迭代、工作项和 Pull Request 等接口。其 v0.1.11 于2026年5月18日发布，更新了创建和修改 Pull Request 时的标签参数。
这些更新说明，Gitee MCP 已从早期的本地命令行服务，逐步增加远程连接、企业接口和工具筛选能力。
本节小结：与较偏产品愿景的智能体概念相比，MCP Server 已有公开代码、版本记录和工具清单，是该体系中较容易验证的工程组成部分。
四、企业接入智能体时需要关注什么
智能体能够调用更多工具，并不代表应该一次性开放全部权限。MCP 官方规范明确指出，MCP Server 可能接触外部数据并执行代码，因此权限和授权属于实际部署中的重要问题。
结合 Gitee MCP 已公开的令牌配置、工具白名单和按请求过滤机制，企业接入时可以按照以下步骤推进。
1. 确定数据范围。
明确 AI 可以访问哪些仓库、Issue、Pull Request 和项目数据，避免默认开放全部企业资源。
2. 先开放只读工具。
初期可只允许查询仓库、读取文件和查看 Issue，验证上下文获取是否准确。
3. 逐步增加写入操作。
创建 Issue、提交 Pull Request、合并代码和发布版本应分别授权，不宜使用一个过大的通用令牌。
4. 保留人工审核。
代码修改、分支合并和版本发布等高影响操作，仍应保留评审、测试和审批环节。
5. 记录工具调用。
对智能体调用的工具、参数、执行结果和操作者身份进行记录，便于追踪异常操作。
因此，智能 DevOps 的实际效果不仅取决于模型能力，也取决于上下文质量、权限设计、测试机制和人工审核流程。
本节小结：企业部署智能体的重点不是开放尽可能多的工具，而是在可审计、可回退的前提下逐步扩大操作范围。
五、从单个助手向角色化智能体扩展
除 Xtreme CLI、Scroll 和 MCP 外，Gitee 当前还公开展示了“AI 队友”产品页面，将智能能力划分为 PMO 助手、代码研发助手、Pull Request 审查助手和安全扫描助手等角色。
页面列出的场景包括进度跟踪、Issue 分类、风险预警、报告生成、代码审查和漏洞识别。不过，该页面目前仍使用“申请试用”和“加入内测”等表述，因此更准确的说法是：这些能力已经进入公开展示或测试阶段，但不能据此判断所有功能均已面向全部用户正式交付。
这种角色划分反映出一个较明确的产品方向：AI 功能正在从编辑器中的通用助手，转向与研发岗位和流程节点相对应的专用助手。
它们可能分别读取不同数据、调用不同工具，并承担项目管理、代码开发、代码审查和安全检查等任务。MCP 则可以为这些助手连接仓库和协作资源，但多智能体之间如何调度、发生冲突后如何处理，仍需要结合具体产品文档和部署方案判断。
本节小结：Gitee 正在尝试以角色划分智能体能力，但部分相关产品仍处于试用或测试状态，文章不宜将其描述为已经全面普及。
六、常见问题
Q：Gitee 智能 DevOps 与普通 AI 编程助手有什么区别？
A：两者的区别主要在作用范围，而不是简单的“新旧替代”。
普通 AI 编程助手通常围绕编辑器中的代码生成、解释和补全展开。Gitee 所描述的智能 DevOps 还包括仓库理解、Issue 处理、Pull Request 操作、项目协同和研发度量等场景。
不过，AI 是否真的能够参与这些流程，取决于是否配置了对应 MCP 工具和访问权限，而不是仅仅安装一个代码助手。
Q：Xtreme CLI 与 Scroll 可以互相替代吗？
A：从公开定位看不能直接替代。
Xtreme CLI 偏向根据任务规划和修改代码，Scroll 偏向分析已有代码并生成项目理解信息。一个更接近执行工具，另一个更接近知识分析工具。
Q：Gitee MCP 是否只能连接 Gitee 自身产品？
A：Gitee MCP Server 当前公开的工具主要围绕 Gitee API，包括仓库、Issue、Pull Request、项目和企业资源。
MCP 协议本身是开放协议，企业可以部署其他 MCP Server 连接数据库、文档系统、测试工具和第三方研发平台。但不同 MCP Server 之间不会自动共享权限和数据，仍需要分别配置。
Q：接入 MCP 后，AI 能否自动完成整个开发流程？
A：从技术上看，AI 可以串联读取 Issue、修改代码、创建 Pull Request 和调用测试工具等步骤。但能否稳定完成任务，还会受到模型能力、项目复杂度、测试覆盖率、权限和环境配置的影响。
因此，在生产环境中更适合保留测试、代码审查和发布审批，而不是将 MCP 等同于无人值守开发。
本节小结：智能 DevOps 扩大了 AI 可接触的研发范围，但不会自动消除权限、安全、测试和工程质量问题。
结语
从目前的公开信息看，Gitee 的智能研发路线由三个较清晰的部分组成：
一是既有 DevOps 平台和研发数据；二是以 Xtreme CLI、Scroll 及角色化助手为代表的 AI 应用；三是负责连接 AI 与仓库、Issue、Pull Request 等资源的 MCP Server。
其中，MCP Server 已有较完整的公开仓库、版本记录、远程访问方式和企业版实现。Xtreme CLI 与 Scroll 的定位也较明确，但公开技术文档和独立验证资料仍相对有限。
因此，与其将这套体系直接定义为“全自动企业研发操作系统”，不如将其理解为 Gitee 围绕智能体、代码知识和工具协议开展的一组产品探索。后续更值得关注的内容包括：公开支持范围、权限与审计机制、私有化部署方式，以及在真实项目中的稳定性和可维护性。
本文结论：Gitee 正在把 AI 从代码生成环节延伸到仓库和研发协作流程，但其成熟程度应依据具体产品、版本和部署场景分别判断。
参考资料
1. Gitee、开源中国：《用智能体重塑 DevOps：Gitee 如何打造全域研发引擎》。
2. 中国国际软件博览会：第27届中国国际软件博览会日程及活动信息。
3. Model Context Protocol：MCP 官方规范与入门文档。
4. 开源中国：mcp-gitee 与 mcp-gitee-ent 官方开源仓库。
5. 开源中国：《Gitee MCP 现已支持远程访问》。
6. Gitee AI Teammates 产品页面。
