企业官网建设流程全解析

拆解OmniBot模块化架构：app、ui、baselib、assists等模块如何协作

【免费下载链接】OmniBotYour on-phone / mobile AI Agent / Claw, capable of operating terminals and performing a wide range of tasks in the Android world || 你的手机 AI 代理，她可以操作终端，也可以完成 Android 世界的广泛任务项目地址: https://gitcode.com/gh_mirrors/op/OmniBot

OmniBot 是一款运行在 Android 手机上的 AI Agent 应用，可以操作终端、完成 Android 世界的各种任务。它的源码采用典型的模块化架构：app做宿主编排、ui承载 Flutter 聊天界面、baselib提供数据库与网络等基础能力、assists管理任务生命周期。本文带你逐一看清这些模块的职责边界与协作方式，快速建立对 OmniBot 整体架构的认知。

一张图看懂：8 个核心模块各管一摊

OmniBot 是一个 Android 原生 Kotlin + Flutter 的混合应用。所有模块在 settings.gradle.kts 中统一注册，一眼就能看出架构全貌：

_{▲ OmniBot AI Agent 应用界面，聊天、工作区与终端能力整合在一个应用中}

可以看到，app是唯一的应用模块（application），其余全部是 library 模块，职责单一、相互按需依赖。

app 模块：宿主入口与 Agent 编排中枢

app是整个应用的“总装车间”。它的依赖清单基本就是架构的缩影，见 app/build.gradle.kts：

• :flutter（来自ui/模块）：加载 Flutter 界面
• :baselib、:assists、:uikit：三大核心库
• :core:main、:core:terminal-view、:core:terminal-emulator：内嵌终端运行时
• :omniflow-android：GUI 视觉操作能力
• MCP Server SDK、Ktor 本地服务器、Shizuku：支撑工具生态、本地 Web 服务与系统级特权操作

也就是说，Agent 的“理解 → 决策 → 执行 → 反馈”闭环，编排逻辑都发生在app层，它向下调度各模块能力，向上为 UI 提供统一接口。开发相关的构建与测试命令，可参考 AGENTS.md 与 README.zh-CN.md。

ui 模块：Flutter 打造的聊天与设置界面

用户日常看到的聊天窗口、场景模型配置、定时任务、记忆管理，都在ui/这个 Flutter 模块里。目录结构清晰：lib/features/放功能页面，lib/services/放服务层，lib/models/放数据模型。

ui模块并不是独立 App，而是以 Flutter Module 形式被 Gradle 引入：settings.gradle.kts 通过ui/.android/include_flutter.groovy脚本把它注册为:flutter项目，再由app以implementation(project(":flutter"))的方式嵌入原生壳中。Kotlin 与 Flutter 之间通过通信通道（Method Channel）+FlutterEngineGroup共享引擎实例实现高效协作（见 AGENTS.md 的架构说明）。

_{▲ 左侧抽屉进入设置：`ui` 模块承载 AI 能力配置、模型选择等界面}

baselib 模块：所有模块共享的地基

baselib是依赖链的最底层：数据库、文件存储、网络请求、模型配置、权限管理等横切能力都在这里。assists、androidgui、omniflow-android等模块都直接或间接依赖它（如 assists/build.gradle.kts）。

这样设计的收益很直接：

1. 单一事实来源——其他模块不重复造轮子；
2. 稳定边界——基础能力改动不影响上层业务；
3. 易于测试——baselib/src/test/下有大量单元测试保障地基质量。

assists 模块：任务状态机让 Agent 行为可控

OmniBot 的 Agent 任务（陪伴对话、学习、定时任务三类）由assists模块中的状态机统一管理，核心实现见 assists/ 下的StateMachine.kt。

_{▲ 配置页面由 ui 呈现，底层任务调度则交给 assists 状态机协调}

状态机负责三类任务的状态流转与生命周期协调，并在 UI、前台服务和后台协程之间传递消息。对新手来说，理解这个模块的关键是：界面（ui）只负责“展示”，执行编排交给 assists，系统能力下沉到 baselib——三层分离是 OmniBot 最核心的设计思想。

小而精的支撑模块：uikit、androidgui 与终端

• uikit：原生浮层组件，悬浮球、覆盖层面板、半屏界面等不经过 Flutter 的轻量 UI 都在这里，适合需要系统级悬浮的场景；
• androidgui+accessibility：封装 Android 系统操作与无障碍服务，是 Agent 能“操作手机”的底层通道，依赖关系见 androidgui/build.gradle.kts；
• ReTerminal/core：提供内嵌终端体验，terminal-emulator负责终端仿真内核，terminal-view负责渲染视图，让 Agent 可以直接在手机上操作 Alpine 等 Linux 环境。

模块如何被串起来：构建流水线视角

除了 Gradle 依赖，还有两条“隐性”装配链路值得注意：

1. WebUI 打包：webchat/ 是独立的 React + TypeScript 项目。app构建时会先用 pnpm 安装锁文件依赖、执行 Vite 生产构建，再把dist/产物拷入 APK assets（见 app/build.gradle.kts）；
2. 插件资源同步：plugins/catalog.v1.json 描述插件目录，构建时按main/investor两种 profile 选择性同步进 APK（app/build.gradle.kts）。

这意味着一次./gradlew installDevelopStandardDebug命令背后，Flutter 模块、React 构建、插件同步、原生模块编译是协同完成的。

总结：这套模块化架构好在哪？

• 职责清晰：入口编排在app、界面在ui、地基在baselib、调度在assists，新人按目录即可上手；
• 依赖方向严格向下：业务模块依赖baselib，但baselib不反向依赖任何业务模块；
• 扩展位预留充分：插件目录、MCP、Shizuku 特权通道都是独立模块接入，不侵入核心；
• 混合技术栈不打架：Flutter、React、原生 Kotlin 各有边界，通过构建脚本统一装配。

如果你想继续阅读，建议从 README.zh-CN.md 的「架构概览」和 AGENTS.md 入手，再按本文的模块顺序逐个打开对应目录，整个 OmniBot 的架构地图就完整了。🚀

【免费下载链接】OmniBotYour on-phone / mobile AI Agent / Claw, capable of operating terminals and performing a wide range of tasks in the Android world || 你的手机 AI 代理，她可以操作终端，也可以完成 Android 世界的广泛任务项目地址: https://gitcode.com/gh_mirrors/op/OmniBot