Multica：把多个 Agent CLI 放进同一块 Issue 看板的工作空间
同时开五个终端 Tab，一个跑 Claude Code 写文档，一个跑 Codex 重构代码，一个跑 Cursor 改 Bug，一个跑 Kimi 做调研，一个跑 Copilot 补全。每个 Agent 都活在自己的 session 里，切个 Tab 就要重新解释上下文，Agent 挂了就得从头再来。想让 Claude Code 写完的文档直接交给 Codex 去实现，两个 CLI 之间根本不认识，只能手动复制粘贴上下文、手动协调进度、手动检查结果。
AI Agent 已经不缺了，缺的是管理它们的方式。Multica 不是又一个 Agent，而是一个工作空间：把 Agent 和真人队友放在同一块看板上，像分配任务给同事一样分配 Issue。Agent 自己领取、报告进度、提出阻塞、交回审核。
项目信息
- GitHub：
- 自托管安装脚本：
- Helm chart：
oci://ghcr.io/multica-ai/charts/multica - 源码 clone 地址：
1. 为什么 Agent 需要工作空间
手里已经有 Claude Code、Codex、Cursor，为什么还要加一层工作空间？
上下文割裂：每个 Agent 在自己的终端里，session 一结束上下文就丢。技术栈是什么、模块的业务逻辑是什么，每天都要重复解释一遍。
协调成本高：想让 Agent A 写完代码、Agent B 做 review，两者互不认识。复制粘贴、手动触发、手动检查，全靠人串起来。
没有审计追踪：Agent 做了什么决策、跑了什么命令、花了多少 Token，最终只知道「它写完了」，不知道「它怎么写的」。出问题排查像大海捞针。
扩展性差：今天用 Claude Code，明天想试 Codex，后天想换成 Kimi。每个 Agent 有自己的配置方式和命令格式，切换成本越来越高。
这些问题单个 Agent 解决不了，需要一个协调层，把 Agent 和团队放在同一个上下文里、用同一套规则协作。GitHub CLI 解决的是命令行与 GitHub 的交互，Multica 解决的是另一件事：多个 Agent 怎么像团队一样协作。
2. Issue 驱动，Agent 即队友
Multica 的核心设计是把 Agent 完全当作队友：出现在看板上，可以被分配 Issue，可以评论进度，可以提出阻塞，可以交回审核。
它要解决的核心矛盾是：怎么让 Agent 的意图、执行、决策、产出连在一起。传统模式是给一个 Prompt、拿一个结果，中间的决策过程、执行日志、Token 消耗全丢了。Multica 的做法是一切围绕 Issue。
Issue 是唯一的真相来源
一个 Issue 不只是任务描述，而是整个协作的真相来源：
- 意图：Issue 的标题和描述，说明要做什么
- 执行：Agent 的每次工具调用、每条命令，记录在 Issue 的 Execution Log 里
- 决策：Agent 的评论、提出的阻塞、做出的选择，都留在 Issue 里
- 产出：最终的 PR、代码变更，关联到这个 Issue
打开任何一个 Issue，能看到完整链路：谁提的、谁做的、怎么做的、做了什么、花了多少 Token。
# 查看 Issue 详情
multica issue view 123
# 输出包含完整信息：
# - 标题、描述、指派人
# - Agent 的执行日志（每次工具调用、每条命令）
# - Token 消耗统计
# - 关联的 PR 和代码变更
这样设计带来的直接结果是：
- 上下文不丢失：Agent 每次执行基于 Issue 的完整历史，不用重新解释
- 可审计：谁做了什么、怎么做的，一目了然
- 可追溯：出问题打开 Issue 就能看到完整执行链路
- 可复现：同一个 Issue 换个 Agent 再跑一次，结果可对比
Agent 是队友，不是工具
Agent 不被动等你喂 Prompt，而是主动参与协作：
- 你分配 Issue 给 Agent：像分配给同事一样，选择 Agent 作为 assignee
- Agent 自己领取任务：检查自己的队列，主动开始工作
- Agent 报告进度：在 Issue 里评论「我正在做 X」「我遇到了 Y」
- Agent 提出阻塞：卡住了就标记 Issue 为 blocked 并说明原因
- Agent 交回审核：做完把 Issue 移到 review 状态等你确认
# 创建一个 Issue，分配给 Agent
multica issue create \
--title "重构用户认证模块" \
--body "把 JWT 换成 OAuth 2.0，保持 API 兼容" \
--assignee claude-code
# Agent 会自动领取任务，开始工作
# 你可以在 Issue 里看到它的进度：
# - "正在分析现有代码结构..."
# - "发现 3 个依赖 JWT 的地方，需要确认是否保留兼容"
# - "已完成重构，提交了 PR #456，请 review"
- 不需要盯着 Agent，它自己干活，有问题才来找你
- 可以并行处理：同时分配 5 个 Issue 给 5 个 Agent，各自独立工作
- 最终决策权在你：Agent 做完，review 通过才算完成
一个内部工具团队的例子
假设一个内部工具团队：3 个后端、2 个前端、1 个运维，引入 AI Agent 提效：
- 后端 Agent：用 Claude Code，负责写 API、重构代码、修 Bug
- 前端 Agent：用 Cursor，负责写 UI、改样式、做交互
- 文档 Agent：用 Codex，负责写文档、更新 README、生成 changelog
- 测试 Agent：用 Kimi，负责写测试、跑测试、生成测试报告
在 Multica 里，这些 Agent 和真人队友一样出现在看板上。分配一个后端 Issue 给 Claude Code，它会自动领取、开始工作、报告进度、交回审核。
这些 Agent 之间也能协作：Claude Code 写完 API 后，Cursor 自动领取前端 Issue，基于新 API 写 UI；Codex 自动生成 API 文档；Kimi 自动跑测试。中间的协调和上下文传递由工作空间完成，不需要手动复制粘贴。
3. Runtime 抽象：23 种 Agent CLI，一套接口
第二个核心设计是 Runtime 抽象层，解决「不同 Agent CLI 怎么在同一平台里无缝切换」。
传统模式下每个 Agent 有自己的配置方式、命令格式、API，用 Claude Code 学一套、用 Codex 学另一套、用 Cursor 再学一套，切换成本越来越高。
Runtime 是什么
Runtime 是 Agent 运行的「桌面」——可以是你的笔记本、云服务器，或任何装了 Agent CLI 的机器。
Multica 不绑定特定的 Agent CLI，支持 23 种：Claude Code、Codex、Cursor、Copilot、Kimi、OpenCode、Qwen Code、DeepSeek Harness 等，基本覆盖主流 AI 编程助手。
# 查看所有支持的 Agent CLI
multica runtime list
# 输出：
# claude Claude Code
# codex OpenAI Codex
# cursor Cursor Agent
# copilot GitHub Copilot CLI
# kimi Kimi
# qwen Qwen Code
# ... (共 23 种)
切换 Provider 是下拉选择，不是迁移
因为有了 Runtime 抽象层，切换 Agent Provider 变得很简单：
# 创建一个 Agent，使用 Claude Code
multica agent create \
--name "code-reviewer" \
--runtime my-laptop \
--provider claude
# 创建一个 Agent，使用 Codex
multica agent create \
--name "doc-writer" \
--runtime my-laptop \
--provider codex
# 创建一个 Agent，使用 Kimi
multica agent create \
--name "test-runner" \
--runtime my-laptop \
--provider kimi
不用改配置、不用学新命令、不用重新部署，切换 Provider 就是下拉选择一下。
- 无锁定：今天用 Claude Code，明天想试 Codex，随时切换
- 统一接口：不管底层是什么 Agent，Multica 用同一套 API 驱动
- 代码不离开你的机器：Agent 在 Runtime 上运行，代码不上传到第三方
如果团队后端用 Claude Code、前端用 Cursor、文档用 Codex、测试用 Kimi，这些 Agent 都通过统一的 Runtime 抽象层接入，不需要为每个 Agent 单独搭环境、学不同命令格式。某个 Agent 升级后性能提升，也可以一键把对应角色切过去，迁移成本接近零。
4. Squads：让 Agent 和人组队
第三个核心设计是 Squads，解决「Agent 和人怎么高效协作」。
传统做法是各干各的，靠 Slack、飞书、钉钉这类 IM 工具协调。但 IM 里的信息是碎片化的，Agent 的进度、决策、产出散落在聊天记录里，很难追踪。
Squad 是一个包含 Agent 和人的团队，由一个 leader 负责分配工作。
# 创建一个 Squad
multica squad create \
--name "backend-team" \
--leader alice \
--members bob,claude-code,codex
# 在 Squad 里分配工作
multica issue create \
--squad backend-team \
--title "重构用户认证模块" \
--assignee claude-code
Squad 的 leader 可以是人，也可以是 Agent。人做 leader 时手动分配工作；Agent 做 leader 时会自动分析任务，分配给最合适的成员。
- 协作更高效：Agent 和人在一起，上下文共享，沟通成本低
- 责任更清晰：谁负责什么一目了然
- 进度更透明：Squad 看板显示所有成员（包括 Agent）的工作状态
一个典型场景是新功能开发：产品经理提需求、设计师出设计稿、后端写 API、前端写 UI、测试写用例。在 Multica 里创建一个 Squad，包含产品经理（人）、设计师（人）、后端 Agent（Claude Code）、前端 Agent（Cursor）、测试 Agent（Kimi）。Leader 可以是产品经理，负责分配工作。后端 Agent 写完 API 后，前端 Agent 自动领取 UI 任务，测试 Agent 自动编写测试用例。整个过程在看板上清晰可见。
5. Autopilots：自动化重复工作
第四个核心设计是 Autopilots，解决「怎么让 Agent 主动做重复性工作，而不是每次都等人分配」。
传统做法是写 cron job 定时触发脚本，但 cron job 不知道任务状态、不知道 Agent 进度、出了问题也不知道怎么处理。
Autopilot 是一个定时任务，可以自动触发 Agent 工作。
# 创建一个 Autopilot，每天早上 9 点生成日报
multica autopilot create \
--name "daily-standup" \
--schedule "0 9 * * *" \
--agent codex \
--action "生成昨日工作日报，包括：完成的 Issue、进行中的 Issue、阻塞的 Issue"
# 创建一个 Autopilot，每周五下午 5 点生成周报
multica autopilot create \
--name "weekly-report" \
--schedule "0 17 * * 5" \
--agent claude-code \
--action "生成本周工作周报，包括：完成的 PR、合并的代码、待处理的技术债"
# 创建一个 Autopilot，每小时检查一次代码质量
multica autopilot create \
--name "code-quality-check" \
--schedule "0 * * * *" \
--agent kimi \
--action "运行代码质量检查，如果发现问题，创建 Issue 并分配给相关 Agent"
- 自动化重复工作：日报、周报、代码检查、测试运行交给 Agent
- 智能触发：除了定时，还能基于事件触发，比如 PR 合并后自动运行测试
- 可追踪：每次 Autopilot 的执行记录在 Issue 里，可以审计
适合放进 Autopilot 的重复性工作：每日站会日报（昨天做了什么、今天做什么、遇到什么问题）、每个 PR 的代码质量/安全性/性能检查、自动跑测试并生成报告、检测代码变更后更新对应文档。这些工作不需要手动触发，也不需要写复杂脚本。
6. 自托管：数据完全在你手里
第五个核心设计是完全自托管，解决「使用 AI Agent 的同时怎么保证代码和数据安全」。
云端 AI 服务需要把代码和数据上传到第三方，对很多公司来说不可接受——代码是核心资产。
Multica 支持多种部署方式：
# 方式 1：Docker Compose（最简单）
curl -fsSL https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.sh | bash -s -- --with-server
multica setup self-host
# 方式 2：Helm（Kubernetes 环境）
helm install multica oci://ghcr.io/multica-ai/charts/multica
# 方式 3：从源码构建
git clone https://github.com/multica-ai/multica.git
cd multica
make selfhost-build
自托管后所有数据都在自己的基础设施里：
- 代码不离开你的机器：Agent 在 Runtime 上运行，代码不上传到第三方
- 数据库在你手里：PostgreSQL 部署在你自己的服务器上
- Git 仓库在你手里：支持 GitHub、GitLab、Gitea、Forgejo，甚至自托管 Git 服务
带来的好处是数据安全、满足企业合规要求、可以按需改代码。
以一个金融公司为例：整个平台自托管在公司内部的 Kubernetes 集群，Git 服务用 Gitea 或 Forgejo 放在内部，Runtime 在内网服务器上运行使代码不离开内网，PostgreSQL 启用透明数据加密（TDE）。代码和数据全程在自己手里。
7. 实战清单：AI Agent 工作空间怎么搭
架构设计
- Issue 驱动：一切围绕 Issue，意图、执行、决策、产出连在一起
- Agent 即队友：Agent 出现在看板上，可以被分配、报告进度、交回审核
- Runtime 抽象：支持多种 Agent CLI，切换 Provider 是下拉选择，不是迁移
协作
- Squads：Agent 和人组队，leader 负责分配工作
- Autopilots：自动化重复工作（日报、周报、代码检查、测试运行）
- 通知集成：Slack、飞书、钉钉、企业微信、Telegram，在常用的 IM 里触发和跟踪
安全
- 自托管：数据完全在你手里，代码不离开你的机器
- 审计追踪：每次执行记录在 Issue 里，可审计、可追溯
- 权限控制：owner、admin、member 三种角色，精细控制 Agent 的访问权限
扩展性
- CLI 和 API：所有功能都可以通过 CLI 和 API 调用，支持脚本化
- Skills：把已解决的问题变成 playbook，所有 Agent 复用
- 多客户端：Web、桌面端（macOS/Windows/Linux）、移动端（iOS），同一套工作空间
8. 总结
AI Agent 看起来是技术问题，实际是协作问题。Multica 的设计思路可以拆成六点：
- Issue 驱动解决上下文割裂
- Agent 即队友解决协调成本高
- Runtime 抽象解决 Agent 锁定
- Squads解决 Agent 和人协作
- Autopilots解决重复性工作自动化
- 完全自托管解决数据安全
给自己的团队搭 AI Agent 工作空间，不必一上来就做到 Multica 的规模，但架构思路可以先定好：Issue 驱动、Agent 即队友、Runtime 抽象、安全优先。功能可以慢慢加，架构一开始就要对——改架构比加功能痛苦得多。