Lightbuild：为AI代理而生的声明式Android构建

从可执行脚本到静态数据：Android 构建的新思路

在 Android 开发者体验团队的产品经理 Juan Sebastián Oviedo 和开发者关系工程师 Scott Meyers 的共同演示下，Google 揭开了 Lightbuild 的面纱——一个实验性的 Android 构建体验。它试图回答一个根本问题：如果从零开始重新设计项目配置方式，会怎样？

当前，Gradle 和 AGP 构成了一个动态系统，支撑着数百万生产应用的构建配置。由于构建文件是用命令式、图灵完备的语言编写的，IDE 要理解项目配置，唯一的通用方式就是执行构建脚本。每次打开项目、切换分支或编辑构建文件，IDE 都需要经历配置阶段、执行插件逻辑、构建项目模型，然后才能提供代码补全和导航等功能。

正如 Juan 所说：“作为开发者，你最关心的是交付出色的应用，但管理构建脚本、保持 AGP 更新、让项目与 IDE 同步，却要花费大量时间和精力。”

声明式配置：让人和代理都能读懂

Lightbuild 的第一大支柱是声明式语法。对比屏幕左右两侧的文件：传统构建文件是命令式代码，可以包含局部变量、自定义辅助函数调用、条件语句和内联任务定义；而 Lightbuild 配置文件则是纯声明式数据——没有变量、没有函数调用、没有条件逻辑，只清晰陈述模块类型、SDK 目标和依赖关系。

“如果新工程师加入团队，打开这个文件，他们没有任何自定义构建习惯用法需要破译，每个 Lightbuild 模块都使用相同的、立即可读的语言。”Juan 解释道。

这种分离对人类可读性已是巨大提升，但对代理辅助工作流更具变革性。当开发者将 AI 代理纳入工作流，代理需要能够读取和修改构建配置，但它们无法预测配置更改的副作用——除非实际构建项目。在 Lightbuild 中，项目配置是一个确定性的静态数据图。代理可以检查这个图、理解模型拓扑，并使用已知模式修改它：查看模块列表、依赖及其版本，更新依赖，甚至添加全新的功能模块，只需读写结构化数据即可。

另一个关键细节是：Lightbuild 不是构建系统的插件，而是构建引擎的接口。当前预览版底层仍使用 Gradle 作为执行引擎，但架构上让 Android Studio 将项目视为 Lightbuild 项目。

图灵完备语言指的是具备分支、循环、变量赋值等能力，理论上可表达任意计算过程的编程语言。Gradle 使用的 Groovy 和 Kotlin DSL 都是图灵完备的，这意味着构建脚本可以包含任意逻辑，IDE 无法通过静态分析穷举其行为，只能实际执行才能获知最终配置结果。这正是传统 Android 项目同步缓慢且难以预测的根源。声明式配置则放弃图灵完备性，用受限的、结构化的数据格式（如 YAML）描述“是什么”而非“怎么做”，从而让静态分析、形式化验证和机器读取成为可能。

快速 IDE 同步：跳过脚本评估

第二大支柱是开发者生产力与心流。由于项目配置是确定性静态数据图，IDE 无需执行脚本评估阶段或插件代码就能理解项目。无论是打开项目、编辑构建文件还是切换分支，IDE 都能快速处理信息，让你直接进入工具。

Scott 在演示中展示了一个直观例子：在项目根目录的 project.lightbuild.yaml 中删除一个模块，保存瞬间该模块就从项目中消失；撤销更改并保存，它又立刻回来。“这就是 Lightbuild 带来的快速 IDE 同步，”Scott 说。

这种速度和可靠性得益于 Lightbuild 处理依赖的方式。通常，声明依赖后构建系统需要遍历传递依赖树来收集版本信息并解决冲突。而在 Lightbuild 中，每当依赖变化，工具会自动计算传递依赖信息，并写入每个模块目录下的 resolve.deps 文件。这样未来打开项目或重新构建时，IDE 和构建工具都无需重新计算。团队建议将这些文件签入源码控制，以便队友审查时看到传递依赖信息的变化，同时确保本地和 CI 流水线使用相同的依赖版本。

resolve.deps 还有锁定模式：通过 --locked-dependencies 参数，工具会对比文件内容与声明的依赖，如有差异则让构建失败。这使得这些文件可以像锁文件一样，在 CI/CD 生产构建中确保依赖不发生意外变化。

传递依赖是指项目直接声明的依赖所进一步依赖的库。例如声明依赖 A，而 A 又依赖 B 和 C，B 依赖 C 的某个版本，构建系统必须遍历整棵依赖树，收集所有版本约束并解决冲突（如选择最高版本），才能确定最终使用的库集合。这一过程在大型项目中可能涉及数百个节点，且每次配置变化都需重新计算，是 Gradle 同步耗时的主要来源之一。Lightbuild 将计算结果固化为 resolve.deps 文件，相当于把动态解析结果缓存为静态数据，从而跳过重复遍历。

为 AI 代理设计的 CLI

Lightbuild 以早期预览形式在 Android Studio Canary 和独立 CLI 工具中提供。Scott 通过 android create 命令配合 empty activity Lightbuild 模板创建了一个演示项目，并展示了 CLI 的关键命令：

• build、clean、test：常规构建操作
• resolve：生成 resolve.deps 文件
• query：查询项目结构，帮助开发者和代理理解项目布局

query 命令可以列出模块下的所有可构建目标（debug 和 release 的 APK 与 AAB），并支持 JSON 输出格式——“这对你的代理来说更容易消费，”Scott 表示。output 命令则显示构建中所有二进制文件的位置。同时，CLI 内置了完整的帮助系统，为代理提供所有参数和子命令的详细列表。

AI 代理（AI Agent） 指能够自主感知环境、调用工具并执行多步任务以达成目标的 AI 系统，例如可读取代码、修改文件并运行命令的编程助手。与单轮问答不同，代理需要可靠地理解操作对象的当前状态，并预测操作的后果。对于构建配置而言，命令式脚本的副作用难以预测，代理只能“试错”；而结构化数据图让代理可以通过查询接口读取拓扑、以模式化方式修改，并通过构建结果验证，显著降低了代理操作构建系统的风险与不确定性。

项目结构：应用模块是空壳

Lightbuild 项目结构有几个独特之处。根目录的 project.lightbuild.yaml 定义全局设置：项目名称、模块列表、外部仓库和全局版本。每个模块有自己的 lightbuild.yaml。

所有 Lightbuild 项目至少有两个模块：一个应用模块和一个库模块。应用模块不包含任何源代码——“因为应用模块不会经常变化，但构建需要时间。如果把所有应用代码放在库模块中，每次构建都会更快，因为不需要重新计算和重新打包应用模块中的所有内容，”Scott 解释。

这种设计也支持多应用变体。在演示的 Now in Android 项目中，原本通过 build flavors 区分 demo 和 prod 构建，Lightbuild 则通过创建多个应用模块（如 demo 应用、prod 应用）来实现，每个都是空壳，依赖不同的库组合。

构建变体（Build Variant） 是 Android 构建系统将构建类型（如 debug、release）与产品风味（product flavor，如 demo、prod）组合后生成的输出配置。传统上通过 buildFlavors 在单一应用模块内定义多个风味，再由 Gradle 组合出多个变体。Lightbuild 不支持这种在模块内部的条件切换，而是让每个变体对应一个独立的空壳应用模块，通过依赖不同的库模块组合来实现差异化。这一设计将“变体选择”从构建时的逻辑判断转变为项目结构上的静态声明，更符合其声明式、可静态分析的核心理念。

实战检验：32 模块的 Now in Android

Scott 使用 Gemini 代理将高度模块化的 Now in Android 项目（约 32 个模块）转换为 Lightbuild。项目打开和同步速度极快。不过他也坦诚了局限：Now in Android 依赖 Hilt 插件，而 Lightbuild 尚未支持此类插件，代理最终找到了变通方案。“你的当前项目中并非所有构建配置功能都会得到支持，这就是为什么 Lightbuild 仍处于预览阶段。”

展望与建议

Lightbuild 目前是实验性功能，缺少构建和维护生产应用所需的全部特性。Google 明确建议：生产应用继续使用 AGP 和 Gradle，在演示和实验项目中尝试 Lightbuild。开发者可通过官方文档页面获取入门步骤，包括安装 Android Studio Canary 版本和 Lightbuild CLI。Juan 和 Scott 及团队工程师也将在代理 AI 展台解答问题，并期待社区反馈来塑造产品的演进方向。

对于关注 AI 辅助开发工作流的团队而言，Lightbuild 代表了一种值得关注的范式转移：将构建配置从可执行代码转变为结构化数据，不仅让人更容易理解项目，更让 AI 代理有了可靠的操作界面。