高德汽车工程 AI Native 演进实录｜AutoSDK AI Coding 可观测与自进化闭环的构建

汽车产业正从“软件定义”驶向“AI 定义”的深水区。在百万级代码、企业级 SDK 交付的工程场景下，我们面对的已不只是“AI 能不能写代码”的疑问，而是“AI 能否像工程师一样稳定交付”的工程命题。

过去数月，高德汽车业务中心进行了一场系统性实践。我们将这段旅程总结为四篇文章：

架构篇：高德汽车工程AI Native演进实录｜AutoSDK全链路AI Native开发

知识篇：高德汽车工程AI Native演进实录｜基于Qoder的业务知识工程建设实践

质量篇：高德汽车工程AI Native演进实录｜用Harness构建可控AI交付

进化篇：以可观测驱动、持续自进化的 Loop Engineering，让研发体系持续迭代。

我们始终坚持一个判断——能力交给模型，秩序交给系统。对 ToB 复杂工程而言，AI 交付不能只依赖单点生成能力，还需要把流程、知识、质量和反馈机制一起纳入工程体系，让 AI 交付从“偶尔成功”走向“稳定可复现”，再进一步具备持续改进的能力。

希望这四篇分享，能为大家理解 AI Native 时代下的汽车软件工程实践提供一些参考。

为什么“单次跑好”远远不够

前三篇回答了链路如何贯通、AI 如何理解业务、如何守护质量。至此，AI Coding 链路已经具备可控、可信、可靠的单次交付能力。数字说明了阶段成效：缺陷漏出下降约 73%，代码采纳率 84%，API 规范遵守率 80%。

但企业级交付对链路的要求，从来不止“单次跑好”，还要“越跑越好”：

•流程中上一次质检打回的问题，下一次任务能否自动避开？

•历史总结出的经验，能否固化为下一次的默认约束？

•流程低效的环节，能否被度量、被定位、被优化？

人类研发组织有记忆，上一次踩过的坑会变成团队免疫力；而 AI 系统默认没有记忆，如果没有机制把教训沉淀下来，同一个坑就会反复掉。防线守的是这一次，进化补的是下一次。

所以，构建自进化闭环是 AI Coding 进入企业级生产后必须补上的一环。这也是进化篇要回答的问题：系统如何从一次次运行中持续改进。

可观测先行：进化需要证据，不是直觉

如架构篇所述，AutoSDK搭建的多阶段流水线，并非单 Agent 的顺序处理，而是多 Agent 与多工具的动态协作，执行过程是一个复杂状态机。这意味着输出偏离预期时，如果没有清晰的链路追踪，执行过程不可见，问题排查只能靠猜，进化更是无从谈起。凭感觉调 prompt、拍脑袋加规则，改完效果可能更好，也可能更差，没有数据的进化，是玄学。因此，在回答“如何进化”之前，先解决系统可观测问题，它是进化的地基。

行业里不是没有可观测方案，但AutoSDK 的场景有几个现实约束：

•AI Coding 运行在 IDE，无法直接接入第三方可观测SDK；

•企业级数据安全要求观测基础设施必须自建自控；

•AutoSDK 不止观测单次会话内的调用链，还包括跨会话、跨 Agent 的“工程过程”：编排是否存在断点、上下文是否准确；

这些需求叠加在一起，意味着现成方案搬不动，观测必须原生地长在链路里。

落地分两步：先采集，再组织。

采集：三源融合，互为补充。

•Hook 埋点：在关键生命周期节点触发——任务开始、启动子 Agent、Tool 调用前后、LLM 调用前后、任务结束、异常发生，捕获执行过程中的关键事件与字段。Hook 提供实时事件；

•本地会话转录文件：记录执行过程的完整上下文——用户输入、Agent 思考过程、计划变更、Tool 入参与返回、LLM Prompt、最终输出，解析后成为结构化的执行数据。转录文件提供完整决策过程；

•本地数据库：通过 IDE 内置的 SQLite 数据库，获取任务元数据与跨 Agent 的关联关系，让分属不同会话的执行重新归拢到同一个任务上。本地数据库提供任务级关联。

三源融合，完整的执行过程才能被还原。

组织：从观测目标到三支柱实现。

观测要覆盖三个层面的问题：

•任务层：这次任务成没成——看结果；

•能力层：Agent 与模型的行为表现是否在劣化——看趋势；

•机制层：质检机制拦没拦住——看过程；

结果告诉你“发生了什么”，趋势告诉你“正在往哪里去”，过程告诉你“为什么发生”。三层都可见，进化才有入口。

为了实现这三层观测目标，我们沿用 Metrics、Trace、Logs 三支柱框架，但在 AI Coding 场景下扩展了各自的语义：

•Metrics 层：可度量，看效果和趋势。 请求量、错误率、延迟这类传统指标，只回答“快不快、错没错”，回答不了“值不值”——Token 消耗在哪里，哪一步在绕弯路。因此 Metrics 的语义必须扩展：效率、质量、效果各有自己的答案——过程稳不稳定、到底有没有真提效、成本有没有花在关键阶段。有了这些，闭环中每一次改进，才有前后对比的依据。

•Trace 层：可见，看清过程。 传统 Trace 记录服务间的调用——谁调用了谁。但 Agent 的编排问题几乎不发生在单次调用里：最终产出的偏差，根因可能在好几个阶段之前——探索产出不完整，传导进设计，设计再传导进编码。调用链回答不了“问题是怎么传导的”。因此 Trace 必须从调用链扩展为因果链：每个阶段的决策与交接都是执行树上的节点，最终产出出现偏差时，可以沿树一路回溯到根。

•Logs 层：可归因，用证据说话。 归因不能停在“看起来哪里不对”，要能落到具体：哪个 Agent 在哪个阶段调用哪个工具失败、当时的上下文是什么。因此 Logs 必须从文本扩展为结构化、有语义的行为记录——能按阶段、Agent、工具检索，与 Trace、Metrics 互为印证。每一个结论，都应该能落到一条可查证的记录上。

三支柱就位后，排查问题的动作变成一套固定节奏：Metrics 先暴露异常——哪个环节的指标劣化了；Trace 再定位链路——问题是从哪个上游、怎么传导过来的；Logs 最后拿出证据——具体是哪个 Agent、哪一次调用出了错。

链路黑盒变透明之后，第一批暴露的问题很有意思——往往不是模型能力问题，而是流程编排问题：

1上下文膨胀：部分任务在调研阶段消耗了大量上下文和 Token，但关键约束并没有稳定传递到设计阶段。

2阶段交接不完整：上游产物没有明确接口兼容性或跨仓依赖，下游编码只能基于不完整输入继续执行。

3角色边界越权：部分任务中，主 Agent 越过子 Agent 直接执行具体工作项，专职 Agent 的设计、编码、验证职责被绕开。

三类问题有一个共同点：它们不是简单的“模型答错”，而是链路中的流程、上下文或角色边界没有被正确组织。 如果没有可观测，靠人回翻对话几乎不可能系统性发现，这正印证了可观测的价值——不只是记录过程，而是让每一个判断都能回到可查证的执行记录上。

自进化闭环：让流程长出记忆

可观测让问题被看见，但看见不等于进化，真正的进化还需要回答下一步：看见的问题能否进入系统，让流程长出记忆。

AutoSDK 基于Loop Engineering建立了一层面向系统改进的自进化闭环——观测、归因、干预、验证，四个环节形成闭合。其中，可观测能力正是这个闭环的输入源：Metrics 提供异常信号，Trace 提供因果链路，Logs 提供归因证据——三支柱的数据汇入观测和归因环节，让每一轮改进都建立在结构化的执行事实上，而非人工印象。

四个环节里，验证是闭环的关键，也是最容易被省略的一环。

原因很现实：质量门禁有明确的过/不过，代码能编译、用例能跑，天然就是裁判；而“进化”没有天然的裁判——改了一条规则，怎么知道是变好了，还是把一个显性问题换成了一个隐性问题？不受验证的进化，和没有测试的代码一样危险。 质量篇的验证哲学在这里完全适用：每一次进化都要被验证，就像每一行代码都要过自测。

AutoSDK 的验证设计包含三个维度：

•跟谁比：优化前 N 天 vs 优化后 N 天；

•看什么：该类问题的发生率、一次通过率、阶段耗时、Skill 召回率等；

•怎么看：不仅看目标指标是否下降，还要看是否引入新的问题类型或误报。

第三个维度值得单独强调：进化的目标是收敛问题，不是堆砌控制。一条新规则拦住了目标问题，却制造出一批新误报，这在数据上会原形毕露——这正是验证层存在的意义。可观测平台持续跟踪同类指标，验证层的价值不是给优化贴标签，而是让每次进化都建立在可验证的事实上。

至此，自进化闭环的核心可以一句话收拢：让每一次改进都经过识别、回灌和验证。 只有这样，观测到的问题才不会停留在单次任务中，而会逐步转化为后续交付能力。

案例：一次质检打回如何变成默认约束

抽象的概念不如一个具体的案例。在 AutoSDK AI Coding链路中，质检 Agent 会持续检查意图理解、领域设计、开发实现和验证结果，并对不符合要求的产出进行打回。过去，这些打回记录虽然已经存在于观测系统中，但如果缺少持续分析机制，就很难自然转化为系统改进。以下是一次真实的闭环过程：

观测：基于可观测的Metrics 层，发现近期质检通过率未达预期，系统从指标异常中识别出本轮要进化的目标。

归因：AI 在这些离散打回中识别重复模式，聚类后定位根因：问题集中在“设计→编码”阶段，设计文档缺少接口兼容性检查项。

干预：系统基于归因结果生成优化建议，人工评审建议的合理性和改动面，确认后落地；如果拒绝则记录理由，避免系统重复建议。

验证：后续观察期内，通过可观测对比该类打回率和一次通过率，确认问题是否真的减少且未引入新异常。数据稳定改善后，这轮自进化闭环完成闭合。

阶段效果

运行至今，闭环开始把问题转化为具体的流程约束和工程资产。典型成效包括：

•效率优化：针对调研 Agent 未并行执行、缺乏调研策略的问题，调整编排方式，支持调研 Agent 多实例并行，并引入更合适的工具与执行路径。优化后，调研阶段平均耗时降低约 50%。整体流程耗时从原来的1.5h缩短为现在的1h以内。

•上下文治理：针对主 Agent 上下文占用一度达到 70% 的问题，调整编排策略，减少子 Agent 返回内容量级。优化后，主 Agent 平均上下文占用从70% 降至 50%。

•角色边界收敛：针对主 Agent 越过子 Agent 直接执行工作项、未完成任务即提前结束流程等问题，新增硬约束，明确主 Agent 与设计、编码、验证等子 Agent 的职责边界。

•质检数据稳定沉淀：当前四大质检门禁已经持续产生可消费的通过与打回数据，通过率提升50%。这些数据不再只是单次任务的评审结果，而是进入闭环，成为后续规则、Skill 和流程优化的输入。

这个实例证明：自进化不是抽象概念，而是可以用现有数据跑起来的日常机制。每一次打回、每一次处置、每一次验证，都在帮助链路把经验沉淀为下一次默认携带的约束。

回看这个闭环，有一处细节值得留意：每一次干预的“裁判”都偏软——规则该不该改、效果是否真的好，仍依赖人工评审与设计好的对比。那么，如果效果评价本身就是可量化的呢？

性能优化：从人工试错到数据验证的闭环

性能优化正是这类效果可量化的需求，它的目标天然明确、可衡量：常驻内存、启动耗时、CPU 占用，数字本身就是裁判。当验证信号足够硬，闭环就有条件再往前一步：从“系统出建议、人来拍板”，走向“系统自主迭代、人做最终决策”。我们选择性能优化作为检验 Loop Engineering 上限的试验场。先看传统模式的瓶颈在哪。

传统模式：人全程参与，一个候选耗时半天

性能优化是一个高试错成本的工程活动。一个优化候选从选点到验证完成通常需要半天，而大多数候选最终是无效的。问题不在于工程师判断力不够，而在于验证代价太高，导致能试的候选数量受限，优化空间无法被充分探索。

我们的思路，就是把这个过程反过来：不是人全程参与每一轮试错，而是系统自主迭代，把“猜测”变成“有数据支撑的结论”。为此，我们基于 Loop Engineering 构建了性能优化闭环——一个驱动 AI Agent 自主完成性能分析、筛选、代码修改和验证的全流程系统。

性能优化闭环：从筛选到验证

这条闭环的输入是一个 APK 和一个优化目标（如“native 常驻内存降至 X MB 以下”），输出是经过实测验证的优化结论。这也是目前链条最长的一条闭环——向内覆盖 AI Coding 全链路，向外纳入自动性能测试、数据采集、编译出包与集成验证。整条流水线分为前置阶段（执行一次）和循环体（每个候选重复）：

图中的关键机制：

AI 与确定性脚本的分工：编译、采集、符号化、聚类由确定性脚本完成，结果可重复可追溯；判断可行性、探索代码结构、设计优化方案、实施改码由 AI 子会话完成，需要理解和推理能力。关键决策点——“这个候选到底能不能优化”——由 AI 产出判断字段后，Python 代码做硬逻辑拍板，不依赖 AI 的自我评估。改码与验证由两个互相看不到对方过程的独立 agent 分别完成，避免自我确认偏差。

代码管理：每个候选改码前对源码所有子仓打快照。验证通过则 commit 保留改动进入下一轮，验证无效或出现回归则回滚到快照状态。代码始终干净，改动可追溯，每一轮的 delta 都可归因到单一优化点。

安全兜底：设备掉线、连续多轮无效果、达到轮次上限，任一条件触发自动停止，不会无限空转。任何步骤中断后重跑，已完成的步骤自动跳过，长流水线不怕中间断点。

自进化：每一轮循环的结果都会反哺系统——深判不通过的原因回灌为浅判规则，下次同类方向直接跳过；验证有效的候选沉淀为优化模式知识，让后续浅判推荐更精准；验证阶段发现的用例盲区反馈回测试场景，减少漏验。系统越跑越准，而非每次从零开始。

阶段效果

下图是某版本 native 内存场景的一次真实运行记录：

这一轮运行中，浅判淘汰了三分之二的无效方向，进入循环体的 11 个候选里，2 个经实测验证有效——这些方向在人工模式下大多根本不会被尝试。

系统交付的不是“AI 认为可以优化”，而是“改了、跑了、实测数据说话”的验证结论。但边界也很明确：它不自动合入生产代码，不替代工程师的架构设计决策。它的角色是穷举和验证，证明“这条路走得通、收益是真的”；生产级实现由工程师基于验证结论重新设计，确保代码质量和长期可维护性。

结语

可观测性和自进化闭环改变了两件事：问题定位不再依赖人工回翻对话和中间产物，而是可以沿 Metrics、Trace、Logs 回到具体执行节点；改进不再依赖临时复盘——分散在质检打回、人工评审中的问题，开始转化为规则、Skill 和流程上的具体改进。自进化不是一次性的大改造，而是围绕真实执行数据持续推进的小步迭代。

作为系列的最后一篇，把四篇文章放回一条主线来看：

篇目	回答的问题	交付的能力
架构篇	链路能否贯通	从需求到交付的多 Agent 全链路流水线
知识篇	能否做对	体系化沉淀的业务知识
质量篇	能否稳定交付	Harness 三道防线，守住单次交付的底线
进化篇	能否持续改进	可观测 + 自进化闭环，让系统越跑越好