大数跨境
0
0

AI Agent 编码助手实战:面向 KMP 原生跨端实现研发提效

AI Agent 编码助手实战:面向 KMP 原生跨端实现研发提效 支付宝体验科技
2025-11-18
11
导读:近年来,以 GPT 和 Cursor 等为代表的大模型及其相关 IDE 呈现出蓬勃发展的态势。

近年来,以 GPT 和 Cursor 等为代表的大模型及其相关 IDE 呈现出蓬勃发展的态势。这股浪潮显著推动了 AI Agent 驱动的编码辅助工具快速涌现,开发者可借助图生码、意图生码、智能改写、外部工具链编排调用等创新性能力,从而显著提升软件开发效率、优化编码流程,并加速高质量代码交付。

本文基于支付宝技术部马静在 QCon 的演讲《AI Agent 编码助手实战:面向 KMP 原生跨端实现研发提效》整理而来,文章将围绕支付宝 KMP 原生跨端框架,分享 KMP AI Agent 编码助手相关实战经验,以及如何帮助 KMP 开发者进行研发提效。

马静 支付宝技术部
支付宝技术

支付宝 KMP 原生跨端背景介绍

术语解释

术语名称
术语介绍
KMP(KotlinMultiplatform)
Jetbrains 基于 Kotlin 推出的一套跨端框架,允许开发者使用 Kotlin 语言编写一次业务逻辑代码,然后将其编译成适用于多个平台的原生应用、Web 应用或服务端应用。
CMP(ComposeMultiplatform)
JetBrains 提供的一套基于 Compose 基础库的声明式 UI 跨端框架,支持在 Android、iOS、桌面和 Web 开发共享 UI。
支付宝 KMP 原生跨端
在 “ Kotlin + Compose Multiplatform” 的基础上,为支付宝终端开发者提供一整套完善的跨端框架能力。
AntUI 组件库
基于 Compose 编写的支付宝 UI 组件库,包含丰富且风格统一的 UI 组件。
OHOS、Harmony
OHOS 是鸿蒙项目的开源操作系统基底,而 HarmonyOS 是基于 OHOS 打造的商用智能终端操作系统。

支付宝 KMP 原生跨端架构

总的来说,原生跨端的优势,在于极大地减少为不同平台开发应用程序的工作量,同时保留各自平台的最佳体验。去年 8 月份,我们开始研发 KMP 原生跨端框架,做了不少能力延展和优化工作。通过下面这张架构图,向大家介绍一下具体工作内容。

跨端基座

  • C++ 实现的底层基础库能力,以 KMP 接口形式透出。
  • 增强对接鸿蒙平台的系统能力,例如 eventcenter、pipeline、资源读取、线程派发等。
  • Tecla API 基础库 :Tecla 是一种跨端、跨技术栈的统一 API 调用机制,KMP 开发者编写一套 Kotlin 的业务代码,调用 Tecla API,等于实现在三端调用支付宝中间件能力。

MYKMP

  • 突破性支持鸿蒙,实现编写一次代码,可在安卓/iOS/鸿蒙三个平台运行。
  • 基于原生平台 Runtime 进行性能优化,包含启动速度、内存占用等。
  • 使用自研 LLVM,进行一些编译插桩工作。
  • 鸿蒙平台通信简化通道,实现 kt - ets 双向互调。
  • 编译优化,缩减包大小体积。
  • 常用原生平台系统级 API 导出,可编写 Kotlin 调用 。

MYCMP

  • 在 iOS 和鸿蒙上提供两种渲染管线,一种是基于 KMP 现有的 skiiko  渲染引擎,另外一种是基于自研 Canvas 渲染引擎,在内存、帧率、用户体验上有更好的提升。
  • Compose AntUI 组件,基于 Compose 基础库封装的支付宝 UI 组件库,提供更加丰富,风格统一的高阶 UI 组件。
  • 耗时检测,利用工具检测 Compose UI 的排列重组耗时。
  • 运行时体验监控,线上卡顿、无限重组、掉帧等问题监控、基础性能数据统计。
  • 嵌入原生组件,支持嵌入动态下发的原生渲染卡片。
  • 抹平生命周期差异,支持 Composable 内部感知外部原生层级的生命周期,支持 App/Activity/Page 三种层面的接入方式。

工程体系

围绕 KMP 进行一整套工程体系上的支持和适配,方便开发者在支付宝应用架构下,快速开发 KMP 应用。

业务应用

目前已经覆盖多个业务,在支付宝应用上,目前已接入的业务有:首页我的、消息、视频、理财这几个 TAB,以及出行对话智能体,视频通话等。独立应用已接入的有:健康管家 App,理财 App等。整体覆盖量已经达到亿级 PV ,目前已作为原生跨端主要技术栈,帮助业务提效迭代。

支付宝技术

KMP 跨端研发现状痛点

介绍完背景,再来看下当前 KMP 应用开发过程中,有哪些研发痛点?如图所示,开发者在每个研发阶段,分别遇到一些研发难题。

这让我们开始思考,这些问题是否可以通过 AI Agent 来辅助解决,已知 AI 编码工具是否适用原生跨端?我们着手对目前几款热门编码工具进行调研,调研结果如图:

前面两款是内部编码助手,Agent 能力丰富,同时整合支付宝的工程研发体系,但是只能面向前端技术栈,无法适用于 KMP 技术栈。第三款和第四款是外部热门的 Cursor 及 Cline,这两款 Agent 能力较强,支持 KMP 技术栈,但无法融合内部工程研发体系,以及不具备支付宝终端相关的中间件知识。

通过挖掘研发痛点,调研业界现状,目前缺少一款能与客户端基础框架技术深度结合、支持原生跨端开发、适应支付宝端研发工程体系的 AI Agent 编码工具。我们希望有一款具有跨端特色的 AI 编程搭子,解决实际问题,帮助开发者进行研发提效。

支付宝技术

KMP 编码助手方案与实践

接下来进入第三部分,KMP 编码助手方案与实践。这是一个产品功能演示,让大家先有使用体感。视频中会在 Android Studio IDE 上,打开编码助手,Agent 会自动学习当前目录结构以及打开的文件,询问是否需要优化,以及询问支付宝中间件能力,和设计稿生码等,接下来我将介绍编码助手如何从构思到方案落地,以及这些核心能力的技术实现细节。

开发 KMP 应用有哪些具体工作

调研时期,我们整理了开发 KMP 应用都有有哪些具体工作。例如开发者需要在界面开发阶段学习 Compose 知识并上手实作,在逻辑开发阶段需要快速上手 KMP,以及在鸿蒙平台的一些特定用法。在线上运维阶段需要本地堆栈反解工具,以及闪退堆栈分析。

运用 AI 对 KMP 开发二次加速

如果说 KMP 跨端开发是对客户端应用开发的一次提速,而在 AI 驱动下,我们可以借助 Agent、MCP、RAG 检索等技术,对 KMP 开发工作进行二次加速。具体能力包括图生码、设计稿生码、本地工具调用、内部文档检索等。

KMP 编码助手整体架构

整体架构分为三个层次:客户端、Agent 框架、基础服务。其中客户端主要负责用户交互、上下文管理、代码管理等职能,Agent 框架负责智能决策和任务执行,包含代码生成、任务分解、工作流编排、意图分析等。基础服务则提供必要的底层 AI 能力和数据支持。我们作为客户端开发人员,核心工作是运用好这些基础服务,在 Agent 框架层面进行一系列能力扩展,最终给到用户流畅的开发体验。

接下来将重点剖析几个核心能力的实现细节,讲我们是如何借助 Agent、MCP、RAG 检索这些技术,来帮助开发者解决实际开发过程中遇到的问题。先来看在界面开发阶段,如何帮助开发者快速上手 Compose。

如何帮助开发者快速上手 Compose

界面开发阶段,开发者需要破除的困局包括但不限于:

  • Compose UI 编写经验有限,内部大部分开发者其实对 CMP 并不熟悉。
  • Compose Multiplatform 的社区经验支持有限。
  • 面对复杂的 UI 设计,需要切换思路,从传统命令式 UI 切换到声明式 UI 重新编排布局。

为了让开发者对 Compose 有更加直接的体感,提升界面开发效率,我们提供了两种 AI 生码方式,一种是设计稿生码。一种是图生码。

设计稿生码

这里怎么有两张一模一样的图呢,是不是放错了,其实不是,左边这张图是 Sketch 设计软件选中的图层,右边这张是利用我们的设计稿生码技术,转换成 Compose UI 代码并最终预览出来的效果。下面是设计稿生码的演示视频。

具体这块能力是怎么做到的呢,先来看下整体实现链路。在设计稿生码功能启动的时候,我们会把 Node、WebView、idea 插件以及 Sketch 应用建联,实现消息互通。在选中组件后,Node 服务会按照一定规则将设计稿转换成 IR,包括类型转换、参数转换、样式转换以及视图层级转换。再由 IR 转换成 Compose 源码,加以人工规则补全,最后由大模型统一按要求优化代码。

我们来具体看下设计稿转换 IR 的规则细节。首先进行类型转换,对不同的区块,可以转换成 div、image、box、button 等。其次是入参转换,也就是右边的 props,比如 Image 就需要指定 src 入参。最后是样式转换,类似于前端 CSS 样式的一套定义规则。

然后再把这样一套 IR 规则转换成 Compose UI 布局代码。比如 div 对应 Box,src 对应 PainterResource,Style对应 Modifier 或者 Textstyle。

当然这套规则说起来简单,实际上做还是踩了很多坑的,坑的部分总结如下:

这样转换出来的 Compose UI 代码虽然可以还原布局,但看起来还是比较呆,里面会有硬编码以及重复的组件平铺,难以用于生产。这时候就需要大模型进行二次优化,将界面布局进行组件化以及数据驱动的封装,比如一个平铺列表,最终优化成 ServiceItem 组件,对应传参 ServiceData,最终代码就可以直接用于生产。

再来整体对比下,从原始设计稿,到原始 Compose UI,再到模型二次优化的界面效果。这里能感受到模型二次优化后,基本上能够还原设计稿组件,但是代码更加直接可用。

设计稿生码的优点是,转换后还原精度高,缺点是不支持基于支付宝 AntUI 组件库还原,以及设计稿不够规范影响还原效果。我们自然而然的会想有更加简便,且支持高阶 UI 组件库的方案,就是图生码。

图生码

方案 1:图 -> 代码,模型直出

这是最初的方案,将高阶 UI 组价库的知识按照统一格式,输入给 MLLM 学习后,直接将图片转换成 Compose 代码。

用此方案的图生码效果如图,存在的问题也非常明显。首先是细节精度欠佳;其次输入的 UI 组件库,上下文长度非常有限,只能覆盖一小部分核心组件;此外不同基模表现差异较大,内部闭源模型效果一般。因此我们开始考虑后训练方案。

方案 2:图 -> IR -> 代码

第二种方案是一种后训练方案,过程是将图片先转换成 IR 表示,再由 IR 表示通过转换器生成目标代码。其中由图片转换成 IR 这个环节,我们有一套自研图生码算法,直接识别并转换成包含 AntUI 高阶组件的 IR。里面借助经过专门后训练的多模态大模型(MLLM),将 UI 页面图片转化为结构化的 IR 信息。再由设计稿生码中提到的转换规则,将 IR 转换成代码。我们来详细看下具体的图生码算法流程。

整体流程分三个阶段:数据构造,模型训练,后处理增强。在数据构造阶段,需要准备训练数据集,每条数据都由一张图,以及图对应的结构化 IR 组成。在模型训练阶段,输入训练数据和指令,进行监督式微调(SFT),以及强化学习。在后处理增强,对模型输出的 IR 进行多维度的校准。

  • 数据构造

这个阶段的核心挑战是如何构造大量的「图 -> IR」数据对用于训练和测试,采用人工标注,会有效率低和精度差的问题。我们的解决方案是构建自动化的数据生产流程,先由大模型按照规则随机生成 Compose 代码,再基于无障碍导出视图树结构,以及渲染截图,产出图片与 IR 一一对应的数值对。

  • 模型训练

在模型训练阶段,这个阶段的核心挑战是如何通过模型将图片转换成 IR信息。本身由于 UI 界面复杂,又受限于基模能力,对于基础组件识别都有困难,更别说高阶 UI 组件了。这里我们的解决方案是,训练增强多模态大模型的UI 页面解析能力。将图片转为 IR 信息。

这个环节,我们的核心是采用当下比较热门的 LoRA 适配器,LoRA 适配器的作用是高效地引入任务特定的知识,而无需大规模修改或训练整个 MLLM,大大降低了训练成本和资源需求,使得 UI 解析任务的微调变得更加可行和高效。利用 LoRA 这种参数高效的微调技术,在给定“页面图片”和“解析页面指令”的情况下,通过监督式学习(使用“具体的 IR 信息”作为真值并进行梯度回传)来训练这个多模态大模型(MLLM)的 UI 页面解析能力。

  • 后处理增强

经过多模态大模型转换后的 IR 基本上可以还原出布局和用到的 UI 组件,但还是由于幻觉问题,对于位置、样式、布局等细节可能存在不准确的情况,所以我们又进行后处理增强。这里遇到的核心挑战是如何增强视觉还原度,解决方案是利用传统图像算法,对位置、样式、布局等信息进行后处理校准。

后训练图生码还原的效果示例:

从还原效果来看,相比第一种方案模型直出的形式,后训练方案在位置、样式、布局等细节处理更加精准;并且可以扩展到高阶 UI 组件的识别;由图到 IR ,IR 还可以扩展转换到更多原生技术栈(安卓 / iOS / 鸿蒙)。

目前内部开放的图生码能力采用的是第二种方案,可基于 Compose UI 基础组件库进行还原,对于高阶 AntUI 组件识别正在训练中,预计年底可以开放。

前面讲完界面开发阶段,我们提供了设计稿生码和图生码两种能力帮助开发者上手 UI,接下来是逻辑开发阶段,这个阶段要考虑的是如何帮助开发者快速上手 KMP。

如何帮助开发者快速上手 KMP

作为基础框架团队,日常经常接到各类问题咨询。整体答疑现状可概括为三点:

  • 接入业务不断增多,日常咨询量与日俱增;
  • 内部文档质量参差不齐,内容多且繁杂,较难查找阅读;
  • 由于文档质量不高,导致机器人答疑质量不高。

KMP 开发者最容易提出的问题,举例如下:

  • Kotlin 跨端能力库中是否包含某项能力?
  • 这个 API 能力调用代码该怎么写?
  • AntUI 组件库是否支持包含某个组件?

为了帮助开发者快速获取知识,我们提供了基于 RAG 检索的智能问答能力。

RAG 检索问答基本流程

RAG 检索在实践中遇到哪些问题?

问题点
问题描述
解法
源数据较为复杂
以内部 Kotlin 跨端 API 库为例,JSON 源数据 1.3MB,内部包含近千个 API 原始信息记录,不具备可读性,模型无法一次性处理
自建 Markdown 生成助手 Agent,利用 Agent 分批处理 JSON 源数据,按 API 维度产出格式化文档
切片效果不理想
智能切片、人工切片,在处理 API 接口文档时,由于知识条数较多、分片的字符长度有限,部分知识被切断,导致召回的内容不准确
用 FAQ 形式替换切片形式,借助大模型理解 md 文档后,输出可能会提问的 FAQ,再人工辅助补充
体系性问题无法回答
提问某个 API 的问题,模型可以回答。但提问某一类 API 的问题,由于知识库缺少体系性知识,Agent 无法召回相关知识并回答
将知识图谱中的实体、关系和属性直接作为 RAG 系统的检索语料,例如让模型理解 “模块 – 能力 – 具体接口” 的层级关系,并给出可能的提问
FAQ 不容易命中
例如提问“红点有哪些相关能力”,模型可以回答,但是换个方式提问,例如“红点有哪些功能”、“红点能力都有哪些”,Agent 无法回答
FAQ 增强,“举一反三”,让Agent 针对某个 FAQ 产出多种问法

解决开发者具体遇到的困难

我们再来看看,如何帮助 KMP 开发者解决一些核心问题。背景是,开发者通常具备单端开发经验,难以应对其他端平台问题;其次,KMP 框架在鸿蒙平台的突破性支持,仅限内部流通经验,无法获取社区支持。基于这样的背景,开发者主要面临的困难有三种:

  • KMP 模块在三端平台构建失败,无法定位原因
  • 安卓 / iOS / 鸿蒙,三端闪退如何排查
  • KMP 应用框架需要在三端各自接入,平均需要 3 人日

KMP 模块在三端平台构建失败,无法定位原因

KMP 核心产物需要同时三端构建,一旦出现构建失败问题,传统排查方式效率比较低下,花费的时间从几分钟到一小时不等。

这里我们通过 Agent 工作流的方式,帮助开发者主动触发构建,利用 KMP 日志分析脚本,提取关键日志,再结合现有构建知识库进行召回,最终由模型整理组织答案。从而加快构建失败问题的排查速度。

安卓/ iOS /鸿蒙,三端闪退如何排查

开发者可以直接将闪退日志输入给 Agent ,Agent 会触发闪退分析的工作流,先用 KMP 堆栈反解工具提取关键内容并解析,再将解析结果返回给 Agent,由 Agent 结合当前的项目代码上下文,给出原因和解决方案。

KMP 应用框架需要在三端各自接入,平均需要 3 人日

为了抹平不同平台 Application 及 Activity 生命周期差异,我们提供一套应用框架给开发者接入。这样开发者只需要关注 kotlin 共享代码层的生命周期处理,而无需关注三端的生命周期差异。但是接入的成本脚本,一般需要 3 个人日,这里我们提供工具,帮助开发者自动生成 KMP 模版应用来实现快速接入。

使用 MCP 路由 KMP 相关工具

前面提到的各类 Agent 工具使用,种类比较复杂,如何让 Agent 根据用户提示词,主动路由到对应的工具上,这里就用到 MCP 技术。

MCP 概念

简单来讲,Model Context Protocol (MCP) 是一个开源标准,如同 AI 应用的 USB-C 接口,使其能标准化地连接到外部数据源、工具和工作流,从而获取关键信息并执行任务。

MCP 示例 – KMP 闪退堆栈分析

假设我们要定义一个 MCP 工具,这个工具内置了一套 KMP 闪退堆栈分析的工作流,如果想让 Agent 路由到这个工具,可以像下图右边这样定义,内容包括工具名称、提示词描述、入参说明等。

MCP 示例 - KMP 闪退堆栈分析演示

编码助手整体 MCP 架构

KMP 编码助手不止具备本地 MCP 工具的路由能力,同时也支持远程 MCP 市场应用。这里分享一下 MCP 相关结构图,详细可关注后续分享。

支付宝技术

未来展望

编码助手持续优化与创新路径

下一步我们将重点在四个方向上进行深入研究,一是图生码/设计稿生码持续算法优化和能力建设;二是生成式 UI,模型能够根据数据理解,自动选择合适的 UI 组件排列布局,并且实现动态渲染;三是将 KMP 扩展到更多原生技术栈;四是内部开放 Agent 和 MCP 市场,让更多小伙伴可以参与进来学习共建,丰富研发生态。

AI Agent 面向软件开发全周期的应用趋势

AI Agent 在软件开发的整个生命周期中,正在以非常快的速度彻底改变我们的工作方式。这些 Agent 正成为软件开发中不可或缺的智能伙伴,驱动着从构思到交付再到维护的每一个环节的创新。


【声明】内容源于网络
0
0
支付宝体验科技
1234
内容 241
粉丝 0
支付宝体验科技 1234
总阅读165
粉丝0
内容241