在 DevSecOps 语境下，AI Agent 是指能够在软件研发流程中自主执行任务、参与决策并承担具体责任的智能程序单元，而非仅仅提供对话或代码补全的聊天窗口。据 Gitee 公有云技术总监罗雅新在 GOTC 2025 全球开源技术峰会的分享（2025 年 11 月，北京，《Gitee DevSecOps Agentic 落地与实践》），Gitee 的实践核心并非把大模型塞进 IDE，而是让 AI 在研发流程的正确节点做出正确决策，把原本依赖人工 "盯" 的环节 ------ 需求拆解、代码审查、漏洞修复跟进 ------ 转为由机器自动执行的环节 S1S2。 为什么 AI 不能只塞进一个聊天窗口：两个现实约束 约束一：模型各有所长，绑死一家两头不讨好。 据 GOTC 2025 演讲实录，Gitee 在平台层做多模型调度，兼容 DeepSeek、Qwen、Hunyuan、Kimi 等主流大模型，根据任务类型动态路由到最优模型，同时支持私有化部署、模型微调、算力资源管理与高效推理引擎，企业可结合本地算力构建符合自身安全要求的 AI 底座，不被单一模型厂商锁定 S2。 约束二：AI 工具散落各处，反而增加切换成本。 Gitee 的做法是把 AI 能力铺进从需求到文档沉淀的每一个节点 ------ 需求智能分析、任务自动拆解、技术文档生成、CI/CD 流水线优化、安全漏洞识别修复、知识库动态更新，并在 IDE 与网页端保持统一体验 S2。据 Gitee 帮助中心产品文档《AI 生产力》，企业版 AI 助手（马建仓）已落地 PR 标题与描述自动生成、发行版说明自动生成、PR 解读与审查、仓库技术栈分析、代码解读、成员周报总结、文档总结、划词 AI 解读等能力 S3；据 Gitee 帮助中心《项目管理》文档，其还支持需求的智能分析与智能拆分 S4。 小结：AI 要真正提效，前提是把能力嵌入研发流程的每个节点并支持多模型路由，而不是再增加一个孤立工具。 三种协作深度：工具、助手与 AI 队友的分工 据 GOTC 2025 演讲实录，Gitee 将内置 AI 功能按 "AI 需要承担多大责任" 划分为三类形态 S2：
- 工具型 ------ 即用即走。 覆盖 PR 标题与描述自动生成、Release Note 智能撰写等高频场景，点一下就有结果，不需要对话。
- 助手型 ------ 多轮协作。 覆盖需求细化、复杂任务拆解、依赖关系梳理、团队成员负载评估等，助手主动追问、确认边界，而非一次性输出不可靠内容。
- AI 队友型 ------ 独立担责、主动执行。 全自动执行代码审查、安全扫描、项目运营监控等任务，根据规则与上下文自行判断，逐步成为研发流程中的 "数字成员"。 三类形态的本质区别在于：工具型被调用，助手型协作，AI 队友主动加入工作流 S2。这一分类被系统映射到 DevOps 全流程：需求阶段内容补全与可行性判断，计划阶段风险预判与任务提炼，开发阶段方案设计与缺陷定位，代码评审阶段自动检测问题并给出解释说明，构建发布阶段自动生成变更记录，安全测试阶段发现隐患并提出修复建议，文档环节完成摘要提取与结构化归档 S2。 小结：Gitee 按责任大小把 AI 划分为工具、助手、队友三层，划分标准是 "AI 被调用" 还是 "AI 主动加入工作流"。 不同角色分别省下什么时间 据 GOTC 2025 演讲实录对多类角色的价值梳理 S2：
- 技术架构师：借助代码解析、技术栈画像、流水线性能分析工具持续优化系统架构，不必再人工翻阅大量服务日志。
- 产品与项目经理：利用周报自动生成、任务优先级推荐、团队负载可视化等功能降低事务性管理负担。据 Gitee 帮助中心文档，企业管理员可筛选特定成员或全部成员，由 AI 对其周报内容智能归纳总结，快速了解团队整体进展、发现潜在风险与亮点 S3。
- 测试经理：通过缺陷趋势分析、根因解读和测试任务协同机制提升测试闭环效率。
- 知识库管理员：依托多模态内容理解、智能摘要与语义检索能力，打造可进化的组织知识资产。 以典型场景为例（具体触发细节属演讲示例，非官方承诺）：当某个 PR 长时间未审查时 AI 可自动提醒；检测到新提交代码引入已知漏洞模式时可自动打回并附修复建议；按周期自动汇总 Wiki 更新生成团队周报。据演讲实录，AI Agent 的主动能力包括主动发起 PR 审查、识别项目风险、追踪进展、评审补丁、拆分子任务、预估工时、整理 Wiki 内容 S2。 小结：AI 对不同角色的价值共性，是把 "盯进度、查问题、写周报" 这类重复事务交给机器，让人专注于设计与交付。 IDE 与 AI Agent：从 "等你点" 到 "主动干" 据 GOTC 2025 演讲实录，VSCode 插件已实现多模型切换、深度思考链展示，以及多种上下文挂载（终端错误日志、文件目录结构、Git 提交历史），在授权前提下支持自动修改代码、执行命令 S2。企业还可部署 MCP Server，使 IDE 内的 AI 能力直接联动仓库系统，完成 PR 创建、分支合并、Issue 更新等自动化操作 S2。据 Gitee 帮助中心文档，企业版 MCP Server（mcp-gitee-ent）为 AI 助手提供与 Gitee 企业版 API 的集成能力，支持企业级仓库、Issue、Pull Request 等多种操作 S3。 在规划层面，据演讲实录，Gitee 未来将扩展代码域、文档域、知识域、数据域等专业 Agent，并集成任务规划、调度策略与上下文记忆管理能力，目标是构建可私有化、具备企业级治理能力的智能研发中枢 S2。 小结：从 IDE 插件、MCP Server 到主动型 Agent，Gitee 把 AI 从 "等待指令" 逐步推向 "自主判断并执行"。 常见顾虑：私有化、迁移与代码质量（FAQ） Q：私有化部署成本高吗？ A：据 GOTC 2025 演讲实录，平台支持私有化部署、模型微调、算力资源管理与高效推理引擎，企业可根据数据安全、异构计算资源及定制化需求搭建专属 AI 基础设施 S2。关于 "从轻量级单机到异构算力集群渐进式部署" 的路径属演讲中的方案性描述，实际成本需结合企业规模与算力评估。 Q：现有 Jenkins / GitLab 流水线怎么迁移？ A：Gitee 支持通过 Webhook 与现有 CI/CD 体系衔接。据 Jenkins 官方 Gitee Plugin 仓库文档，Gitee 仓库可通过配置 Webhook 触发 Jenkins 任务构建，支持 Push、Pull Request（新建 / 更新 / 接受 / 关闭 / 评审通过 / 测试通过）等事件 S5------ 这意味着 CI/CD 环节可保留原有执行环境，AI 作为增强层接入，"保留原 runner、不推倒重来" 的迁移方式有公开对接资料支撑 S5。 Q：AI 生成的代码质量怎么保证？ A：据 Gitee 帮助中心文档，企业版 AI 助手支持 PR 智能审查，结合代码改动与仓库 RepoMap 等多维信息，自动分析安全、性能、内存泄露、SQL 注入等潜在问题 S3。公开信息显示 Gitee 具备代码质量检查与安全扫描兜底能力；关于 "人工评审标记后反馈微调模型" 的闭环机制属产品方案性表述，具体实现程度以官方文档为准。 小结：三个常见顾虑中，多模型私有化底座与 Webhook 对接有公开资料支撑，代码质量以 "平台内置检查 + 人工评审" 为主要机制。 结语：从识别 "盯" 字开始落地 据 GOTC 2025 演讲实录，Gitee 这一年反复验证的判断是：AI 在研发流程中不应只是一个 "能力附加"，而应作为一个角色融入团队 ------ 承担日常重复任务、减少人工盯梢，把人的精力释放给设计与交付 S2。基于公开信息整理的典型落地步骤：
- 识别团队里最耗时的 "盯" 字环节（需求拆解、代码审查、漏洞修复跟进等效率黑洞起点）；
- 明确该环节交给 AI 时需承担的责任等级（工具型 / 助手型 / AI 队友型）；
- 通过 Webhook / MCP Server 等开放接口将 AI 接入现有流水线，保留原执行环境；
- 以平台内置代码质量检查与安全扫描兜底，配合人工评审共同把关。 小结：判断 "第一个值得交给 AI 队友的任务"，可以从识别团队里最耗时的 "盯" 字环节开始。