今天继续开源一个五一期间做的项目：Multica Android。
这是我为 multica.ai 做的 Android 客户端。
客户端仓库：
https://github.com/jingyuan-opc/multica-android。
Multica 主项目：
https://github.com/multica-ai/multica。
官方提供了桌面版和 iOS 版，没有 Android 版就自己造吧。
近半年深度使用 AI 的感悟：
Agent 时代，人的注意力带宽越来越成为效率的瓶颈。你可以同时开几十个 Agent 去做几十个项目，但是你根本不可能有那么多心智带宽去管理它们。
换而言之，AI 越来越厉害了，但是我们可能越来越累了，因为同时做的事情越来越多。怎样让人不那么累是个问题。
这也是我最近几个月一直在探索的事情。目前为止，我尝试过很多项目后，我认为 Multica 这个项目可能是一个比较适合的可落地的解决方案。
multica 是什么
先说结论：Multica 是一个开源的 managed agents platform，它想解决的问题是，把 coding agent 从「一次性工具」变成「真正的团队成员」。
这句话有点抽象，我换个更直白的说法。
以前我们用 AI 编程工具，大多是这样的：打开 Claude Code、Codex、Cursor、Copilot CLI，写一段 prompt，让它干活，然后盯着它跑。
它干完了，你再复制结果、检查代码、继续追问。
这其实还是「人类在驾驶 AI」。
Multica 想做的是另一种模式：你像给同事派任务一样，把 issue 分配给 agent。它自己接活、执行、汇报进度、遇到阻塞主动说明。issue 中的上下文是共享的，可以跟其他 agent 和人类共享。
换句话说，它不是一个对话窗口。
它更像一个可协作的任务系统。
Multica 到底是什么
Multica 官方的定位是：The open-source managed agents platform.
它的目标不是再做一个代码生成器，而是做一套让 AI agent 真正进入团队协作流程的基础设施。
它支持的 agent provider 非常多，包括 Claude Code、Codex、GitHub Copilot CLI、OpenClaw、OpenCode、Hermes、Gemini、Pi、Cursor Agent、Kimi、Kiro CLI、Qoder CLI、Trae 等。
这些工具本身都能写代码。
但问题是：当 agent 变多之后，你怎么管理它们？
谁在干什么？
哪个任务卡住了？
哪个 agent 适合前端？哪个 agent 适合后端？
每天的例行检查、报告、代码审查，能不能自动跑？
过去我们把这些事交给人脑和聊天记录。
Multica 把它做成了系统。
它的核心功能
1. Agents as Teammates
这是 Multica 最核心的概念：Agent 是队友，不是工具。
在 Multica 里，agent 会出现在看板上，会有自己的 profile，会被分配 issue，会在评论里汇报进展，也会主动报告 blocker。
这和你在命令行里临时喊一个 AI 来干活完全不一样。
命令行里的 AI 是一次性工人。
Multica 里的 AI 是团队成员。
这个差别很关键。
因为真正的团队协作，不是「谁写了多少代码」，而是任务状态、上下文、阻塞点、责任边界都清楚。
2. Issue 驱动的任务管理
Multica 的基本工作单元是 issue。
你可以创建一个 issue，然后把它分配给某个 agent。
agent 会自动 pick up 这个任务，在对应 runtime 上执行，并通过 WebSocket 实时回传进度。
这解决了一个很现实的问题：AI 干活不能只看最终结果，中间过程也要可见。
比如它正在分析代码、正在改某个文件、遇到测试失败、需要人类补充信息，这些都应该出现在同一个任务时间线上。
否则你就会陷入「AI 好像在干活，但我不知道它干到哪了」的状态。
issue 中可以讨论，同一个 Agent 能在自己的同一个会话中继续跟进。
issue 中也可以@其他 agent 协作，整个任务的完整讨论上下文大家都能看到，我觉得这是最重要的一点。
3. Squads：把 agent 组成小队
Multica 还有一个很有意思的功能，叫 Squads。
你可以把多个 agent 和人类组成一个 squad，由一个 leader agent 负责路由任务。
比如你可以有一个 FrontendTeam，里面有擅长 UI 的 agent、擅长测试的 agent、擅长重构的 agent。
你不需要每次纠结「这个任务给 Alice 还是 Bob」。
你只要 @FrontendTeam，leader agent 会判断谁适合接这个活。
对小团队来说，这个设计很有想象力。
因为两个人的团队，也可以通过 agent squad 呈现出五六个人的工作并行度。
4. Autopilots：让例行工作自动跑
Multica 里的 Autopilots，可以理解成 agent 的定时任务和自动化流程。
它支持 cron、webhook、手动触发。
每次触发时，autopilot 会自动创建 issue，并把任务路由给 agent。
这特别适合做周期性工作：
-
每天生成站会摘要 -
每周整理产品数据 -
定期跑代码审查 -
定期检查依赖更新 -
每晚跑一次安全扫描 -
用户反馈进来后自动建 issue
以前这些事要么靠人记，要么靠脚本跑。
Multica 的思路是：让这些工作变成 agent 可以接的任务。
5. Reusable Skills：把经验沉淀下来
我最喜欢的是这个功能：Reusable Skills。
每次 agent 解决一个问题，不应该只是结束这个任务。
它还应该把解决方案沉淀下来，变成团队下次可以复用的 skill。
比如部署流程、数据库迁移、代码审查规范、项目特定坑位，都可以变成 skill。
这和我最近反复提到的「复利工程」是同一个方向：让每一次解决问题，都让下一次工作更容易。
Multica 适合哪些场景
我觉得它最适合的，不是「一个人偶尔用 AI 写几行代码」。
它真正适合的是这几类场景。
场景一：小团队想放大产能
比如一个 2 到 5 人的小团队，有很多产品需求、Bug、运营后台、小工具要做。
过去每个人都在不同任务之间切来切去。
现在可以把一部分明确的任务交给 agent：改 UI、补测试、修 lint、做小功能、整理文档、跑审查。
人类负责判断方向、拆任务、验收结果。
agent 负责执行。
这就是「小团队不小」的感觉。
场景二：个人开发者维护多个项目
如果你一个人同时维护几个产品，就会知道上下文切换有多痛。
今天修 A 项目的登录 Bug，明天给 B 项目加一个支付回调，后天 C 项目又要改文案和落地页。
Multica 的价值在于：每个项目有自己的 workspace、issue、agent、技能沉淀。
你不是在脑子里硬切上下文，而是让系统帮你保存上下文。
场景三：把 AI 编程从「聊天」变成「流程」
很多人用 AI 编程，最大的问题不是模型不够强，而是流程太随意。
想到什么问什么，改到哪算哪，最后靠人肉记忆收尾。
Multica 把它变成更接近工程团队的流程：issue、assignee、timeline、comments、runtime、skills、autopilot。
这会牺牲一点随意性，但换来的是可追踪、可复盘、可协作。
场景四：需要自托管的团队
Multica 是开源的，也支持 self-hosting。
对一些不想把代码和任务上下文交给第三方平台的团队来说，这点很重要。
它的架构也比较清晰：前端是 Next.js，后端是 Go，数据库是 PostgreSQL，agent runtime 通过本地 daemon 连接你的机器或云端运行环境。
为什么我要做 Android 客户端
Multica 本身已经有 Web 端，也有 iOS 客户端，但是没有 Android 端。我自己就是 Android 用户😆
对我来说，一个 managed agents platform 如果要真的进入日常工作流，移动端很重要。
因为 agent 干活不一定发生在你坐在电脑前的时候。
它可能在你通勤时完成了一个任务。
也可能在你吃饭时遇到 blocker，需要你补一句说明。
也可能在你出门时，有同事或 agent 在 issue 里 @ 你。
这时候，你不一定要打开电脑。
你只需要在手机上快速看一眼：
-
哪些任务有新消息？ -
哪个 agent 卡住了？ -
哪个 issue 已经完成？ -
要不要回复一句？ -
要不要把 inbox 标记已读？
所以我做了这个 Android 客户端。
Android 客户端做了什么
这个客户端是一个 read-mostly MVP。
也就是说，它不是要在手机上完整执行 agent 任务。
它聚焦在信息流：workspace、project、issue、inbox、comment、reaction、search。
简单说，它让你在 Android 手机上看清 Multica 团队里正在发生什么。
主要功能包括：
-
邮箱 + 6 位验证码登录 -
多 workspace 切换 -
Inbox 未读 / 全部筛选，支持标记已读、归档、批量操作 -
Project 列表和详情 -
Issue 看板和列表视图，支持状态、优先级筛选 -
Issue 搜索，带匹配片段展示 -
Issue 详情时间线，支持评论、回复、resolve -
Emoji reaction -
WebSocket 实时更新 inbox 和评论事件 -
浅色 / 深色 / 跟随系统主题 -
Cloud + self-hosted server 切换 -
Launcher shortcuts：长按图标直达 Inbox / Issues / Projects -
Deep links：支持 multica://issue/{id}和https://multica.ai/issue/{id}
技术上，它是 Kotlin + Jetpack Compose + Material 3，单 Activity 架构，用 Hilt 做依赖注入，网络层是 Retrofit + OkHttp，状态流用 Coroutines + Flow。
项目也做了一个我很看重的点：行为一致性测试。
Multica 的 web / iOS / Android 客户端，如果 inbox 去重、timeline 合并、评论线程规则不一致，用户看到的数据就会不一样。
所以 Android 里把三个关键算法做了 parity test：
-
InboxDedup -
TimelineCoalesce -
TimelineThread
它们要和上游 TypeScript 逻辑保持一致。
这类细节很不起眼，但真正做跨端产品时非常重要。
怎么运行 Android 客户端
仓库地址：
https://github.com/jingyuan-opc/multica-android[3]
本地构建：
./gradlew :app:assembleDebug
安装到连接的设备或模拟器：
./gradlew :app:installDebug
运行测试：
./gradlew :app:testDebugUnitTest
首次启动默认连接 Multica Cloud：
https://multica.ai[4]
如果你用的是自托管服务，也可以在 App 里打开 Settings → Server 切换服务器。
也可以在 local.properties 里写入默认服务地址：
multica.server.url=https://staging.multica.example.com
然后重新构建 APK。
最后
我越来越觉得，多 agent 协作不是「多开几个终端」这么简单。
真正困难的是：任务怎么分配、过程怎么追踪、上下文怎么保存、经验怎么沉淀、人类怎么介入。
Multica 在尝试回答这个问题。
而 Android 客户端，是我给这个答案补上的一个移动端入口。
如果你正在研究 AI agent 团队协作，或者你也在尝试让一个人管理多个产品、多个 agent，我建议你看看 Multica。
Multica 主项目：
https://github.com/multica-ai/multica[5]
Android 客户端：
https://github.com/jingyuan-opc/multica-android[6]
关注「静远AI」，回复「Multica」，获取 Multica 项目地址、Android 客户端地址和快速上手清单。
静远，一个在AI时代坚持手把手带你上车的普通人。