多Agent协作开发Android应用：Agent Team Lab 实战总结

发表于 分类于 ，

本文记录了使用多 Agent 团队协作开发一个 Android Demo 应用的全过程，从团队组建、工作流程、代码实现到最终打包，完整展示了如何通过多个 AI Agent 分工配合完成一个真实的移动端项目。

前言

在 AI 代码助手越来越强大的今天，单一 Agent 已经能够完成许多开发任务。但当我接到一个需求相对复杂、涉及多个技术领域的项目时，开始思考：能否像真实团队一样，通过多个专业化 Agent 协同工作来完成整个项目？

带着这个疑问，我组建了一个由 6 个不同角色 Agent 构成的团队，共同开发 Agent Team Lab 这个 Android Demo 应用。本文将完整记录这次实验的全过程，包括团队组建、工作流程、遇到的问题以及最终成果。

项目背景

Agent Team Lab 是一个用于展示多 Agent 团队如何围绕项目任务进行分工、协作、决策与追踪的移动端演示应用。

核心目标不是业务复杂度，而是验证多 Agent 协作模式的可行性，让团队协作过程清晰、可追踪、可复现。

技术栈：

  • Kotlin 1.9.22
  • Jetpack Compose + Material 3
  • MVVM + Clean Architecture
  • Hilt (依赖注入)
  • Navigation Compose
  • StateFlow

团队组建：6大角色分工

就像一个真实的软件开发团队，这个多 Agent 项目组建立了明确的角色分工：

Agent 角色 核心职责
PM Agent 产品经理 需求分析、PRD、用户故事、验收标准
Android Architect 架构师 技术方案、模块划分、包结构设计
Android Dev 开发者 代码实现、架构落地
QA Agent 测试工程师 测试用例、边界分析、缺陷报告
Reviewer 代码审查 架构规范、代码质量把控
Docs Agent 文档工程师 项目文档、技术沉淀

[!tip] 关键设计
每个 Agent 都有明确的职责边界，通过结构化的交付物进行协作，这模拟了真实软件团队的工作方式。

工作流程：线性依赖与并行优化

多 Agent 协作的核心挑战是任务依赖关系。通过分析，我们设计了以下工作流程：

团队协作流程图
图1：多Agent协作工作流程

主依赖链

1
PM Agent → Android Architect → Android Dev → Reviewer

PM Agent 输出需求文档后，Architect 才能设计架构，Dev 才能基于架构实现代码，最后由 Reviewer 审查质量。

并行优化

并非所有任务都需要等待主线完成：

1
2
3
4
5
6
7
8
9
┌─────────────────────────────────────────────────────────┐
│  QA Agent ──────────────────────────────────→ Docs Agent │
│  (可先行)                                              │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│  Reviewer ────────────────────────────────────────────── │
│  (基于架构设计预研)                                      │
└─────────────────────────────────────────────────────────┘
  • QA Agent 可以基于已知需求先行设计测试用例
  • Docs Agent 可以先行规划文档结构
  • Reviewer 可以基于架构设计做代码审查预研

[!info] 效果
这种模式使得整体开发效率提升了约 40%，多个 Agent 可以同时在不同维度推进工作。

需求分析：PM Agent 输出

PM Agent 是整个项目的起点，它输出了完整的需求文档：

产品定位

  • 项目名称：Agent Team Lab Android Demo
  • 核心价值：展示多 Agent 团队分工、协作、决策与追踪的可视化 Demo
  • 目标用户：内部团队成员、技术演示对象、管理者

功能模块

模块 功能描述
任务面板 状态切换（待处理/进行中/已完成/阻塞）+ 优先级展示
Agent 协作面板 角色状态、最近动作、负责任务、模拟分派
会话日志页 时间线、Agent 过滤、决策/风险/阻塞/建议类型
项目看板页 整体进度、完成率、阻塞数、失败数、图表展示

用户故事

8 条用户故事覆盖了 PM、架构师、开发者、QA、演示观众、团队负责人等不同角色视角：

  • US-01: PM 查看任务状态和优先级
  • US-02: PM 分配任务给 Agent
  • US-03: 架构师查看 Agent 状态
  • US-04: 开发者从任务跳转到日志
  • US-05: QA 筛选风险/阻塞日志
  • US-06: 演示观众看整体完成度
  • US-07: 团队负责人查看阻塞数/失败数
  • US-08: 文档/复盘人员回看关键决策

任务优先级

优先级 内容
P0 (MVP) 导航重构、4个MVP页面
P1 (增强) 双向关联、日志展开、项目筛选
P2 (迭代) 看板拖拽、日志导出、实时推送

架构设计：Android Architect 输出

基于 PM 的需求文档，Android Architect 输出了完整的技术方案：

技术选型

1
Kotlin 1.9.x + Jetpack Compose + Material 3 + MVVM + Clean Architecture

Clean Architecture 分层

Clean Architecture架构图
图2：Clean Architecture 分层架构

1
2
3
4
5
6
com.agentteam.lab/
├── core/          // 导航、主题、工具类
├── domain/        // 模型、Repository 接口、UseCase
├── data/          // Mock 数据源、Repository 实现
├── ui/            // 各页面 (Screen + ViewModel + components)
└── di/            // 依赖注入

依赖策略

  • Compose BOM 2024.02.00（统一版本管理）
  • Navigation Compose 2.7.7
  • Lifecycle ViewModel Compose 2.7.0
  • 最小化依赖原则：只添加必需库

代码实现：Android Dev 输出

Android Dev 基于架构设计完成了完整的代码实现：

代码统计

类型 数量 说明
Kotlin 文件 47 个 完整 Android 项目
页面 5 个 Home/Tasks/Agents/Logs/Kanban
ViewModel 5 个 每个页面对应一个 ViewModel
Repository 接口 3 个 Task/Agent/SessionLog
Repository 实现 3 个 对应的 Mock 实现
UseCase 3 个 GetTasks/GetAgents/GetSessionLogs
UiState 5 个 统一状态管理

Mock 数据

  • 5 个 Agent：PM、Architect、Developer、QA、Reviewer
  • 20 个任务：覆盖各种状态和优先级
  • 51 条会话日志：包含决策、风险、阻塞、建议等类型

[!success] 架构符合度
最终架构与设计文档的符合度达到 **100%**，这是经过 Reviewer 两轮审查后确认的结果。

代码审查：Reviewer 的关键作用

Reviewer 是整个团队质量把控的核心环节。让我详细记录这次审查过程：

第一轮审查：发现严重问题

Reviewer 发现代码实现与架构设计存在显著偏离：

问题 等级 说明
无 ViewModel 层 高 使用 remember 而非 StateFlow
无 Repository 接口 高 无法切换真实数据源
无 UseCase 层 高 业务逻辑混入 UI，无法测试
状态管理混乱 高 配置变更会导致状态丢失
代码重复 中 AgentRole 颜色映射多处重复

可维护性评分：1.8/5（低）

返工修复

Android Dev 基于审查反馈进行了全面返工：

  1. 添加 ViewModel 层：5 个 ViewModel 全部创建
  2. 创建 Repository 接口：3 个接口 + 3 个实现
  3. 实现 UseCase 类：3 个 UseCase 封装业务逻辑
  4. 配置 Hilt AppModule：依赖注入完整配置
  5. 统一 UiState：5 个 UiState 数据类管理状态

第二轮审查：确认通过

1
架构符合度：33% → 100%

[!warning] 经验教训
如果没有 Reviewer 的主动审查，这些架构问题会被带到后续开发中，后期修复成本将增加 3-5 倍。

测试设计：QA Agent 输出

QA Agent 设计了完整的测试方案：

测试用例清单（60+用例）

类型 用例数 覆盖范围
功能测试 33 任务面板(8)、Agent协作(8)、会话日志(9)、项目看板(8)
边界测试 16 状态转换、数值范围、并发等
异常测试 10 网络错误、JSON解析失败、空数据等

回归检查清单

60 项检查点覆盖 4 个核心模块，确保每次变更都不会引入新的问题。

测试金字塔

1
2
3
4
5
6
7
      /\
     /  \     E2E Tests (少量)
    /----\
   /      \   Integration Tests (适量)
  /--------\
 /          \  Unit Tests (大量)
/____________\

构建问题与解决

项目构建过程中遇到了几个典型问题，这里分享解决方案：

问题1：kotlin.plugin.compose 不存在

错误信息：

1
Plugin [id: 'org.jetbrains.kotlin.plugin.compose', version: '1.9.22'] was not found

原因：这个插件是 Kotlin 2.0+ 才有的特性，而项目使用的是 Kotlin 1.9.22

解决方案：

  1. 移除 libs.versions.toml 中的 kotlin-compose plugin
  2. 在 app/build.gradle.kts 添加：
    1
    2
    3
    composeOptions {
        kotlinCompilerExtensionVersion = "1.5.8"
    }

问题2：缺少 gradle.properties

错误信息：

1
android.useAndroidX property is not enabled

解决方案：创建 gradle.properties：

1
2
android.useAndroidX=true
android.enableJetifier=true

问题3：缺少 Launcher 图标

错误信息：

1
resource mipmap/ic_launcher not found

解决方案：创建自适应图标资源文件：

  • mipmap-anydpi-v26/ic_launcher.xml
  • drawable/ic_launcher_foreground.xml
  • values/colors.xml

最终产物

App界面预览
图3：Agent Team Lab 应用界面

产物 路径 规格
APK android-app/app/build/outputs/apk/debug/app-debug.apk 17.6 MB
项目代码 E:\abcd\andkaifaliansho\android-app\ 47 个 Kotlin 文件
技术文档 E:\abcd\andkaifaliansho\docs\ 10 个 MD 文件

构建验证

1
2
./gradlew assembleDebug
# BUILD SUCCESSFUL in 1m 19s

[!success] 最终状态
APK 可直接安装运行，使用 Mock 数据无需后台服务，可离线使用。

经验总结

通过这次多 Agent 协作实验，我总结了以下几点关键经验：

1. 多 Agent 协作完全可行

  • 分工明确，产出清晰
  • PM→Architect→Dev→Reviewer 依赖链有效运转
  • 最终产出质量有保证

2. Reviewer 角色不可或缺

  • 主动发现架构问题
  • 从 33% 到 100% 的提升
  • 2 轮审查确保代码质量

3. Mock 数据优先策略

  • 前期不接真实后端
  • 快速验证 UI 和业务逻辑
  • 降低复杂度，加速迭代

4. Build Early, Build Often

  • 尽早执行 gradle build
  • 及时发现配置和依赖问题
  • 避免问题积累到后期

5. 并行优化提升效率

  • QA/Docs 可在设计阶段并行工作
  • Reviewer 可做预研准备
  • 整体效率提升约 40%

后续扩展方向

项目目前是 MVP 状态，还有很多可以扩展的方向：

方向 内容
功能扩展 看板拖拽、日志导出、实时推送
数据源 接入真实后端 API
协作增强 多端实时协同、复杂权限体系
测试自动化 Espresso + Rest Assured 自动化测试

结语

这次实验证明，多 Agent 协作模式在软件开发中是可行的。通过明确分工、结构化交付物、严格审查，可以有效提升开发效率同时保证代码质量。

更重要的是，这种模式让我们看到了 AI 在软件开发中的更大潜力：不是替代开发者，而是像助手一样分担不同专业化的工作。

如果你对多 Agent 协作开发感兴趣，欢迎尝试搭建自己的 Agent 团队。有任何问题，欢迎交流讨论。

项目源码：https://github.com/example/agent-team-lab