在超级应用的研发体系中7x24 AI 生产线并不是一个单纯的 CI/CD 升级项目而是一套围绕 AI 深度托管人工关键兜底、Self-Healing、Agent 驱动流水线、质量效率双飞轮和 Benchmark 评测体系构建的自动化交付闭环。以下内容梳理自高德技术官方微信公众号发布的「超级应用的 AI 原生研发模式探索」系列技术分享。透过这些工程实践可以清晰看到这一体系如何在真实工程环境中运行。这一方向由杨夕凯及其带领的高德智能应用与基建平台团队持续推进。负责人杨夕凯现任职高德地图负责智能应用与基建平台先后参与动态数据、AI 导航、智能应用及基建平台等方向长期深耕地图数字孪生、空间智能、AR/数字人及 AI 导航算法模型等领域并参与建设支撑千亿级数据的端云一体化基础设施与工业级 AI 研发体系。一、问题起点AI 会写代码之后瓶颈为什么仍然在人在不少团队的实践中AI Coding 工具已经能明显提升编码速度但真正进入复杂工程后效率瓶颈往往并没有消失只是从「写代码慢」变成了「等人确认」。典型场景通常是这样的AI 生成一段代码后需要工程师确认是否符合预期构建失败后需要工程师查看日志、定位问题测试不通过后需要工程师判断是代码问题还是用例问题提交 CR 后仍然需要等待人工 Review 才能继续推进。这意味着AI 虽然参与了编码但整个研发流程仍然是「人在才动」。工程师从过去盯代码变成了盯 AI人不在线任务就停在原地。对于超级应用来说这种瓶颈会被进一步放大。超级应用通常具备以下特征用户规模大质量要求高模块数量多代码库复杂多团队协同变更频繁端云链路长构建、测试、发布流程复杂。如果 AI 只能单点辅助写代码而不能在规则边界内自主完成完整交付链路那么效率提升仍然停留在局部。在杨夕凯的推动下高德技术团队在 7x24 AI 生产线中要解决的正是这个问题让 AI 从「辅助编码」走向「可深度托管交付」。二、AI 全托管从人盯 AI到 AI 盯 AI7x24 AI 生产线的第一个关键变化是监控主体的切换。传统模式下工程师是 AI 的监督者。AI 每完成一步都需要人来判断下一步是否可以继续。而在深度托管模式下系统引入了自监控循环也就是 Self-Monitoring Loop。其基本结构可以理解为Coding Agent 执行任务 ↕ 监督 Agent 全程跟踪 ↓ 任务卡住自动恢复 缺少上下文自动补齐 任务完成输出 PR 测试报告 变更说明在这个循环中Coding Agent 负责编写代码监督 Agent 负责任务状态跟踪、异常恢复和上下文补齐。当任务无法继续时系统先尝试自动恢复当任务完成后系统输出的不只是代码片段而是可合并的 PR、测试报告和变更说明供工程师基于完整 PR 与测试报告进行最终审查。这种模式改变的不是某个环节而是整个生产组织方式。在工程师下班前提交需求描述后托管系统可以自动启动完整任务链理解需求、拆解任务、编码实现、测试验证、提交 CR。第二天早上工程师面对的是完整交付物和测试报告而不是停留在中间状态的半成品。从交付物形态看传统 AI Coding 的输出通常是代码片段工程师还需要完成集成、调试、补测试、整理提交等动作。而 AI 深度托管模式要求输出的是可进入工程系统的完整 PR。这意味着 AI 不仅要生成代码还要对代码进入工程系统后的可验证性负责。三、为什么全托管在 2026 年变得可行无人值守研发交付并不是一个新概念但过去很难真正落地。高德技术团队的实践材料提到深度托管模式在 2026 年变得可行主要因为三个条件同时成熟。3.1 模型长任务能力开始稳定早期大模型在处理复杂工程任务时容易出现上下文丢失、推理中断、循环试错等问题。对于简单函数生成或局部补全这些问题影响有限但对于完整功能开发、跨文件修改、测试验证和提交 PR 这类长序列任务任何一次中断都可能导致任务失败。随着模型能力增强AI 开始能够稳定完成覆盖完整功能开发的长任务。这是深度托管模式能够成立的前提。3.2 工具链开始支持 AI 自给自足如果 AI 只能生成代码却不能运行代码、观察结果、判断失败原因那么它仍然需要人充当「手和眼」。材料中提到以 Playwright MCP 等工具为代表AI 可以写代码、运行代码、观察执行结果并根据结果作出判断。工具链的成熟补全了自主执行的重要一环。3.3 平台基础不需要从零搭建高德团队并没有重新搭建一套独立云平台而是在已有 Coding Agent 平台基础上增加托管调度能力。这样系统从第一天起就可以处理真实需求而不需要漫长冷启动。在工程实现上杨夕凯团队提出了三个明确边界不造新 Agent直接复用现有成熟 Coding Agent 能力不搭独立云平台优先使用本地工具链不铺大而全聚焦在「能输出可合并 PR」这一核心交付闭环。这些约束降低了系统建设成本也让深度托管模式能够以较小粒度快速迭代验证。从效果指标看材料中给出的对比包括传统 AI Coding 通常带来 2 到 3 倍人效提升而 AI 深度托管模式的目标是指数级提升在标准化场景下据内部测算至少达到 10 倍以上AI 开工条件从「人在才动」变成「随时自动运行」并行任务数从单任务扩展到 10 个以上同时进行。需要明确的是从工程落地的客观规律来看对高度定制化、缺乏标准化的历史遗留复杂代码AI 重构成本依然较高「先治理基建、再释放 AI」是该方案生效的前提。四、Agent 驱动的 CI/CD 流水线从规则引擎到语义理解传统 CI/CD 流水线本质上是规则驱动的自动化系统。每一步触发条件、执行逻辑和失败处理都依赖人工预设的 if-else 规则。这种模式在人类工程师主导的研发流程中是可控的因为提交频率、变更范围和响应节奏都大致可预期。但当 Coding Agent 以 7x24 节奏持续提交代码时规则系统会暴露三个问题规则难以覆盖复杂组合人工响应速度成为瓶颈运维经验难以系统沉淀。高德团队的 AI-Native 流水线将这一架构升级为 Agent-aware 体系。其核心不是让 AI 模拟人点击原有 GUI而是让 AI 成为流水线执行者。代码推送后AI 自动触发构建、轮询状态、分析失败、生成修复补丁、重新提交直到构建成功。这一体系包含三个设计原则。4.1 声明式意图 自主决策人定义质量标准、安全底线和性能基线Agent 自主决定测试策略、构建路径和资源分配。工程师不再需要逐步在 GUI 中确认每一步而是把目标、边界和验收标准交给系统。Agent 根据当前变更内容决定该跑哪些测试、该做哪些检查、该进入哪个发布通道。4.2 上下文感知 动态适应同样的代码 diff在不同上下文下可能触发不同流水线行为。例如UI 文案修改可能只跑 UI 回归核心模型变更自动扩大测试范围并触发性能基准Bug 修复优先验证失败用例性能优化触发基准对比安全补丁启动全量扫描纯重构以行为等价性作为校验目标。这要求流水线不仅知道「代码变了」还要理解「为什么变」以及「变更可能影响什么」。4.3 闭环反馈 持续进化每次执行结果都会回流为经验数据用于优化后续决策。流水线不是一次性配置好的静态脚本而是随着运行数据不断调整策略的活系统。在研发平台层面该团队将构建触发、语义理解、跨平台交付等环节全面 Agent 化。AI 会对每次代码提交进行语义解析并结合依赖图谱计算影响范围。材料中还提到在内部核心场景评测中该模式可缩短约 50% 的构建到部署时间并降低约 40% 的流水线故障率。对于 Android、iOS、HarmonyOS 等多平台场景AI 可以协调并行构建处理条件编译与签名差异并在构建后执行多端一致性校验实现一次提交、多端交付。五、Self-Healing 自修复构建失败不再等待人工介入无人值守交付的最大风险之一是失败发生后没有人及时处理。如果 AI 只能报告错误而不能修复错误生产线仍然无法真正 7x24 运转。杨夕凯团队在生产线中引入 Self-Healing 自修复机制将构建与测试失败纳入自动诊断、修复、验证的闭环。自修复机制可以分为三层。5.1 静态诊断处理确定性问题系统分析构建日志和错误信息定位失败原因。对于编译错误、类型不匹配、依赖缺失等确定性问题Agent 直接生成修复补丁。这类问题的特点是错误信息明确、修复路径相对固定因此适合快速自动处理。5.2 动态推理处理需要上下文的问题对于运行时异常、测试断言失败等需要上下文理解的问题Agent 会回溯代码变更历史、分析调用链路、参考相关测试用例的期望行为推理出可能的修复方案。这类问题通常不能只靠错误日志解决需要理解变更意图、模块关系和业务预期。5.3 验证闭环修复后自动回归修复补丁提交后系统自动触发新一轮构建和测试。如果一次修复没有解决问题Agent 会基于新的错误信息进行二次诊断。自动修复尝试次数可配置超过限制后系统会上报人工团队并附带完整诊断报告和已尝试方案。这种机制的价值在于它把「失败」从流程终点变成了流程中间状态。构建失败不再意味着停工等人而是进入自动修复循环。材料提到学术界关于自愈 CI/CD 的研究表明AI Agent 能够自主解决约 60% 到 70% 的常见构建失败。高德团队在实践中通过持续训练 Agent 修复能力和优化 Harness使这一比例在内部标准化测试集中进一步提升。测试失败处理同样需要区分真实问题与不稳定测试。系统会识别 flaky test并将其与真实 Bug 区分避免无谓修复循环消耗资源。对于频繁失败的测试用例系统会进行聚类分析判断问题到底来自代码变更、测试环境还是测试用例本身的不可靠性。六、质量效率双飞轮用质量门禁对抗 AI 代码熵增AI 高速生成代码会带来效率也可能带来系统熵增。命名风格不一致、架构模式混用、隐式依赖蔓延、重复代码堆积都会在长期工程中形成技术债。如果只追求生成速度而不建立质量约束AI 越快系统越乱。因此7x24 生产线不能只解决「自动跑」的问题还要解决「自动跑得稳」的问题。杨夕凯及其团队将质量保障从事后检查前移到事中防控。每一个进入流水线的变更都要通过多层 AI 质量门禁。6.1 架构合规性检查架构合规性检查用于验证代码变更是否符合预定义架构规范包括模块边界是否被突破依赖方向是否正确接口契约是否兼容是否绕过既定扩展机制直接侵入核心逻辑。这一步直接对抗无约束生成带来的熵增问题因为 AI 往往倾向选择最短路径解决当前问题而忽视整体架构一致性。6.2 安全漏洞扫描安全漏洞扫描集成 SAST/DAST 工具链对新增代码进行实时安全扫描。Agent 不仅识别已知漏洞模式还会基于上下文分析潜在风险。例如一个看似正常的 API 调用是否可能被用于注入攻击一个数据处理函数是否存在越权访问可能新增配置是否引入敏感信息泄露风险。6.3 性能回归检测性能回归检测针对关键路径代码变更自动运行性能基准测试并对比变更前后的指标变化。性能劣化超过阈值的变更会被自动拦截同时附带性能分析报告和优化建议。对于超级应用来说性能问题往往不是单个接口慢一点而是在高并发、长链路、多端环境下被放大。因此性能门禁需要在变更进入生产环境前完成拦截。6.4 聚类分析与批量治理在门禁之外生产线还会持续收集构建、测试、部署过程中的数据形成多维质量数据集。AI Agent 对这些数据进行聚类分析识别反复出现的问题模式。例如频繁失败的测试用例可以被聚类为 flaky tests看似不同的构建失败可能被归类到共同根因如特定版本依赖不兼容或特定平台编译器行为差异代码复杂度、测试覆盖率、技术债务等指标的变化趋势可以被持续追踪。当一类问题被识别后Agent 不仅修复当前实例还会扫描代码库中的同类隐患并批量修复。同时修复模式会沉淀为新的质量规则纳入门禁检查。这样形成「一次修复、永久预防」的正向循环。这就是质量效率双飞轮的机制质量提升减少返工和故障处理时间从而提升效率效率提升又释放更多资源用于质量建设进一步提升质量。两个环节相互反馈推动研发系统持续螺旋上升。七、Benchmark 评测体系让无人值守交付可度量、可回归无人值守交付不能只靠感觉判断「AI 是否可靠」。高德团队在 AI-Native 生产线中引入 Benchmark 评测体系将规范体系从经验约束转化为可验证、可迭代、可优化的工程基础设施。评测目标不只是衡量 AI 是否完成任务更是检验规范是否提升交付质量、是否降低执行熵增、是否增强跨 Agent、跨模块、跨工作流场景下的一致性与可治理性。材料中提到AI benchmark 已从函数级代码生成演进到面向真实仓库、真实环境和长时程任务的系统评测。SWE-bench、Terminal-Bench、ProgramBench 等都表明仅看任务完成率或测试通过率已不足以评估 AI 在真实工程中的表现。评测还需要关注执行过程中的漂移、重复试错、工作流脆弱性和治理成本。基于这一背景该团队构建了面向执行过程的自定义 Benchmark并结合结果导向评测形成三类重点能力。7.1 典型场景全覆盖评测任务不只包括孤立代码题还覆盖真实工程中的典型任务类型任务类型评测重点CRUD 类开发任务生成稳定性、接口一致性、基础工程合规性复杂业务逻辑任务状态机、规则校验、事务处理等复杂逻辑下的规范遵循能力跨模块协作任务多模块、多层依赖、端云联动场景中的边界约束能力性能优化与重构任务非功能性需求下是否保持结构一致性避免局部补丁引入新技术债任务来源逐步纳入真实 Issue 修复、CI 失败修复、重构需求和规范升级任务以提高评测的生态效度。7.2 关键指标可量化评测不只看测试通过率还看多个维度的综合表现。常见结果指标包括测试结果通过率首次生成成功率。结构指标包括架构一致性得分代码规范符合率。过程质量指标包括上下文冗余重复调用无效步骤过长执行链。控制保持指标包括系统是否可解释是否可中断是否可纠正是否可回滚。通过「结果指标 结构指标 过程指标 控制指标」的组合评测不再只是给任务打一个完成分而是能够反映 AI 在真实工程环境中的综合交付质量。7.3 评测集持续扩展Benchmark 不是一次性静态测试集而是伴随规范演进持续扩展的动态评测系统。具体包括任务增量扩展持续从真实开发活动中引入新任务避免过拟合场景维度扩展逐步覆盖端云协同、多 Agent、跨团队协作和高风险改动指标体系扩展在结果指标稳定后逐步强化过程质量、控制保持和长期运维影响版本对比机制对不同规范版本、Skill 配置和 Agent 编排方式进行纵向比较。这套 Benchmark 与记忆机制、CI 门禁、任务模板和 Skill 体系共同构成反馈闭环。评测发现问题系统沉淀知识规范更新后再进入下一轮验证。最终目标不是建立排行榜而是持续积累证据回答哪些规范真正降低了返工与漂移哪些流程提升了协作效率哪些约束只是增加成本却没有改善质量。八、Agent 自进化让生产线越用越稳7x24 生产线如果只是自动执行任务仍然可能重复犯错。高德团队在 Agent 自进化机制中引入知识沉淀与反馈闭环使每次执行轨迹都能转化为结构化经验。成功的构建策略、有效的修复方案、高效的测试选择都会被自动沉淀为可执行知识而不是简单留存在日志中。Agent 的执行效果数据会持续回流到 Harness 优化循环用于优化工具链、提示词和记忆管理。材料中提到在组件级别优化中工具定义、中间件和长期记忆三个模块贡献了较大的性能增益。系统提示词也会对 Agent 行为产生显著影响但仅优化系统提示词而不优化其他组件反而可能造成 2.3 个百分点的性能回退。这说明 Harness 各组件之间存在协同效应必须整体优化。记忆管理同样需要平衡长期记忆用于跨任务经验积累短期记忆用于当前任务上下文管理长期记忆过多会引入噪声过少则无法复用经验短期记忆管理策略直接影响 Agent 在大型代码库中的导航效率。在错误处理上该团队强调通过工程化手段让 Agent 少犯重复错误。Agent 犯错后系统会分析错误类型并从架构规范、业务特性约束、提示词工程、上下文工程等方向进行工程化解决。每次迭代后Harness 变厚Agent 可犯的错误变少。这种机制使生产线不仅是在运行也是在学习。九、无人值守研发交付的关键工程条件从杨夕凯团队的实践来看7x24 AI 生产线并不是简单把 AI 接入 CI/CD而是需要一整套工程条件共同支撑。9.1 交付闭环必须明确该团队将核心目标收敛为「能输出可合并 PR」而不是追求所有环节一次性全自动化。这个边界让系统能够快速验证价值再逐步扩展能力。如果一开始就追求全链路无人化系统复杂度会迅速上升落地周期也会被拉长。聚焦核心交付闭环是工程上更稳健的选择。9.2 流水线必须具备语义理解能力如果 CI/CD 仍然依赖固定规则AI 的高频提交会放大规则系统的局限。只有理解 commit 意图、代码影响范围和风险等级流水线才能动态决定构建什么、验证什么、防控什么。语义理解能力让流水线从「被动执行脚本」变成「主动调度资源」。9.3 自修复能力必须分层确定性问题可以通过静态诊断快速修复复杂问题需要动态推理修复后还要自动验证。超过能力边界时系统必须上报完整诊断报告避免无限重试造成资源浪费。分层自修复既保证了自动化效率也保留了工程可控性。9.4 质量门禁和 Benchmark 必须长期运行无人值守不是降低质量要求而是把质量控制从人工审查转移到自动化门禁、评测和反馈闭环中。只有质量可度量、可回归7x24 才具备工程可信度。十、结语无人值守不是无人负责而是责任前移到规则和门禁7x24 AI 生产线的关键不是让 AI 无限制生成代码而是让 AI 在明确规则、标准组件、自动门禁和持续评测的约束下完成工业级交付。高德智能应用与基建平台团队的实践将 AI 深度托管、Self-Healing、Agent 驱动流水线、质量效率双飞轮和 Benchmark 评测体系组合成一条可运转的研发交付链路。在这一体系中杨夕凯所带领的团队并不是单纯追求 AI 写代码更快而是把重点放在如何让 AI 在真实超级应用中接得上、跑得稳、可验证、可持续演进。从更长周期看当生产线真正实现 7x24 深度托管软件研发的组织方式也会随之变化。工程师的工作重心会从写代码、调 Bug逐步转向定义规则、设计架构、把控方向AI 则成为持续运转的执行引擎。未来随着 Agent 能力和 Harness Engineering 继续成熟这条生产线还可能进一步支持自然语言需求直接端到端交付、跨项目经验自动迁移以及基于业务指标的自适应发布策略。