Multica：当 Coding Agent 变多，你需要的不是更多终端
一个 Coding Agent 很好用。十个 Coding Agent 就开始像一场小型事故。
你把一个 issue 丢给 Claude Code，又让 Codex 修另一个 bug，Cursor Agent 在前端改样式，Gemini CLI 帮你查文档。每个工具都在动，但谁在做什么？哪个任务卡住了？哪个 agent 已经提交了 PR？哪段经验下次还能复用？
这就是 Multica 要解决的问题。
它不是又一个“会写代码的 AI”。它更像一个给 Human + Agent 团队用的项目管理层：人和 agent 出现在同一个看板里，任务可以分配给 agent，进度实时更新，经验沉淀成技能，算力和运行环境统一管理。
换句话说，Multica 不负责让单个 agent 更聪明。它负责让一群 agent 变得可管理。
Multica 是什么
Multica 是 multica-ai 开源的 Human + Agent 项目管理平台。项目地址是 https://github.com/multica-ai/multica，官网是 https://multica.ai。
官网的定位很直白：Your next 10 hires won’t be human。它把 coding agents 当成团队里的执行成员，而不是一次性的 prompt 工具。
你可以把任务分配给 agent，就像分配给同事。agent 会认领任务、更新状态、发表评论、报告阻塞、执行代码修改，并把结果回写到任务流里。
这听起来像项目管理软件，但关键区别在于：Multica 的看板不是只给人看的。agent 也能参与其中。
它支持 11 类 coding tools：
- Claude Code
- Codex
- Cursor Agent
- GitHub Copilot CLI
- Gemini CLI
- Hermes
- Kimi
- Kiro CLI
- OpenCode
- OpenClaw
- Pi
这些工具本来分散在不同终端里。Multica 把它们注册成 runtime 和 agent，让它们进入同一个工作系统。
核心功能一：Agent 像同事一样被分配任务
大多数 coding agent 的使用方式是“打开终端，粘贴任务，盯着输出”。这个模式适合个人短任务，但不适合团队。
Multica 的第一个核心功能，是把 agent 放进和人一样的项目协作界面。
在任务详情里，assignee 下拉框里既有人，也有 agent。你可以把“重构 API 错误处理中间件”分配给 Claude，也可以把“补单元测试”分配给 Codex。
被分配后，agent 不只是被动执行 prompt。它会：
- 把任务状态从 Todo 改成 In Progress
- 在 activity timeline 里留下操作记录
- 评论它发现的问题
- 报告当前进度
- 完成后提交结果或 PR
- 遇到阻塞时主动说明原因
这解决了一个很实际的问题：你不用再问“刚才那个 agent 跑到哪了”。任务流本身会告诉你。
人和 agent 的动作交织在同一个 timeline 里。谁分配了任务，agent 什么时候开始，改了哪些文件，什么时候说卡住，什么时候准备好 review，都在一处。
这就是 Multica 的第一个价值：让 agent 从黑盒终端变成可观察的团队成员。
核心功能二：完整任务生命周期，而不是一次性对话
普通 agent 会话是 prompt-response。你说一句，它做一轮。做完就结束。
真实工程任务不是这样。一个任务会经历排队、认领、执行、失败、重试、完成、审查。Multica 把这套生命周期显式管理起来。
官网描述的流程很清楚：
- enqueue：任务进入队列
- claim：agent 认领任务
- start：agent 开始执行
- complete 或 fail：任务完成或失败
每个状态变化都会被追踪和广播。没有“它可能还在跑吧”这种模糊状态。
更重要的是，agent 可以主动报告 blocker。
比如 agent 发现测试跑不起来，不应该静默卡住几个小时。它应该在任务里写清楚：
- 缺少环境变量
- 本地依赖安装失败
- 测试基线本来就是红的
- 权限不足，无法访问某个仓库
- 需求冲突，需要人来判断
这件事听起来简单，但对团队协作很关键。人类同事卡住会在 Slack 里说一声，agent 也应该这样。
Multica 还用 WebSocket 做实时进度流。你可以实时看 agent 正在读哪个文件、改哪个模块、跑什么测试；也可以不盯着，过一会儿回来直接看 timeline。
这就是第二个价值：把“我开了一个 agent 会话”变成“这个任务有明确状态和责任人”。
核心功能三：技能库让团队能力复利
Multica 官网有一句话很重要：Every solution becomes a reusable skill for the whole team。
这可能是它比普通 agent 看板更有意思的地方。
团队每天都会重复做很多工作：
- 写数据库 migration
- 部署到 staging
- 修复测试
- 做 PR review
- 按团队规范补日志
- 按项目约定生成 API handler
- 排查某类线上错误
如果每次都靠一个临时 prompt，团队没有积累。今天你教会 Claude 怎么写 migration，明天 Codex 还是不知道。下周新人来了，又要重新解释一遍。
Multica 把这些经验封装成 skill。一个 skill 可以包含：
- SKILL.md 指令
- 配置文件
- schema
- 模板
- 检查步骤
- 团队约定
比如“Write migration”这个 skill，可以规定：
- 先读取当前 migrations 目录
- 生成 up 和 down migration
- 检查 SQL 顺序
- 运行 sqlc compile
- 在干净数据库上跑测试
这不是把 prompt 存起来那么简单。它把“团队做事的方法”变成 agent 可执行的能力包。
所以 Multica 的技能库不是装饰功能。它解决的是 agent 团队最容易浪费的部分：经验无法复用。
Day 1，你教一个 agent 部署。Day 30，所有 agent 都会按同一套流程部署、写测试、审查 PR。团队能力开始复利。
核心功能四：统一管理本地和云端 Runtime
Multica 的另一个关键点是 runtime。
很多 agent 平台想把所有代码执行都拉到云端。Multica 的思路更现实：agent 可以运行在你的机器、本地 daemon、云端 runtime 或自部署基础设施上。平台负责协调，执行环境不必都交给平台。
本地 daemon 会扫描你机器上已经安装的 coding tools。官网说它会自动检测 11 种工具，包括 Claude Code、Codex、Cursor、Copilot、Gemini、Hermes、Kimi、Kiro CLI、OpenCode、OpenClaw 和 Pi。
检测到以后，Multica 会把它们注册成可用 runtime。
这带来三个好处。
第一，代码不用离开你的环境。
FAQ 里说得很清楚：agent execution 发生在你的机器或你自己的云基础设施上。代码不会经过 Multica servers。平台协调任务状态和事件广播。
对企业团队来说，这比“把仓库交给一个黑盒云 agent”更容易接受。
第二，算力状态可见。
统一 runtime 面板会显示本地 daemon、云 runtime、在线状态、离线状态、用量图和 activity heatmap。你知道哪些机器在跑，哪些 agent 空闲，哪些 runtime 掉线。
第三，不锁死 agent 后端。
Multica 是开源的，你可以带自己的 LLM provider、换 agent backend、扩展 API。它不是押注某一个模型或某一个 CLI，而是做上层管理。
这就是第四个价值：当 agent 数量变多，管理 compute 和执行环境本身就是系统工程。
核心功能五：Squads 让任务分配不用记人名
当团队只有一个 agent，你可以直接分配给它。
当团队有十个 agent，问题来了：这个 bug 应该给 Claude 还是 Codex？前端测试给谁？数据库 migration 给谁？如果某个 agent 忙着，谁来接替？
Multica 用 Squads 解决这类问题。
Squad 可以理解成 agent 小队。你不用每次指定具体 agent，而是把任务分给某个小队。小队里的 leader 或路由逻辑决定谁最适合接手。
比如：
- Frontend Squad：处理 UI、组件、样式、交互测试
- Backend Squad：处理 API、数据库、权限、队列
- Review Squad：专门做 PR review 和测试补充
- Maintenance Squad：处理依赖升级、lint、重复性修复
这很像人类团队。你不会每次都问“这个需求到底给小王还是小李”，你会先知道它属于前端、后端还是 QA。
Squads 的价值在规模化之后才明显。一个 agent 是工具，多个 agent 就需要组织结构。
Multica 和直接使用 Claude Code、Codex 有什么区别
直接使用 coding agent 没问题。个人任务、小修小补、一次性探索，终端会话最省事。
Multica 解决的是另一个层级的问题。
| 问题 | 直接用 Coding Agent | 用 Multica |
|---|---|---|
| 谁在做什么 | 靠人记 | 看板和 timeline 可见 |
| 任务状态 | 终端里看输出 | enqueue、claim、start、complete/fail |
| 多个 agent | 多个终端分散管理 | 统一 assignee、runtime、workspace |
| 卡住了怎么办 | 人回来才发现 | agent 主动报告 blocker |
| 经验复用 | prompt 散落在聊天里 | skill 进入团队库 |
| 执行环境 | 每个工具自己管 | 本地 daemon 和云 runtime 统一管理 |
| 团队协作 | 人工同步 | 人和 agent 共用 activity timeline |
所以它不是 Claude Code 的替代品，也不是 Codex 的替代品。
它更像 Linear、Jira、GitHub Issues 之上的 agent 执行层：任务仍然是任务，但 assignee 可以是 agent。
一个具体场景：让 Agent 修 API 错误处理
官网给了一个很好的例子：Refactor API error handling middleware。
这类任务很适合 Multica，因为它有明确目标，也可能涉及多个文件。
你可以把 issue 写成这样：
标题：统一 API 错误响应格式
背景：
当前多个 handler 的错误响应格式不一致，前端很难统一处理。
目标：
- 每个错误响应包含 code、message、request_id
- 保留现有 HTTP status code
- 不改变成功响应格式
验收标准：
- 修改所有相关 handler
- 增加或更新错误响应测试
- go test ./internal/handler 通过
- PR 中说明迁移范围然后把它分配给一个 backend agent。
Multica 里的理想执行过程是：
- agent 认领任务
- 读取 handler 目录
- 找到不一致的错误响应
- 修改第一个 handler
- 跑局部测试
- 继续迁移其他 handler
- 发现某个状态码不能改，主动评论说明
- 完成后提交 PR 或交付 diff
你不需要盯着每一行输出。你看 timeline 就能知道 agent 做了什么。
如果 agent 卡住，它应该报告 blocker。比如“comment handler 的错误格式和 issue handler 冲突，需要确认是否保留 409”。这时人类介入，给出判断，agent 继续执行。
这才是 Human + Agent 团队协作，而不是人在终端旁边陪跑。
什么时候应该用 Multica
满足下面任意两个条件，就值得试：
- 你已经同时使用多个 coding agent
- 任务经常超过 20 分钟
- 团队里不止一个人要看 agent 执行结果
- 你希望 agent 能异步跑任务
- 你需要知道 agent 是否卡住
- 你想把团队经验沉淀成 skills
- 你不想让代码离开自己的执行环境
- 你需要自部署或审计 agent 平台代码
最典型的团队是小型工程团队、开源项目维护者、AI-first startup、内部工具团队。
它们的共同点是：任务很多，边界相对清楚，人手不够，但又不能完全放弃 review 和测试。
什么时候别用
如果你只是偶尔让 agent 写一段脚本，不需要 Multica。
如果你的团队没有 issue 习惯，也不写验收标准，Multica 不会自动救你。平台可以管理任务生命周期，但不能把模糊任务变清楚。
如果你还没有测试和 review 流程，先补这些。agent 执行速度越快，错误扩散也越快。
如果你只有一个 agent，而且所有任务都在 5 分钟内完成，终端会话更直接。
Multica 是管理层。管理层只有在复杂度出现时才有价值。
常见误解
误解一：Multica 是新的 coding agent。
不是。它管理 Claude Code、Codex、Cursor Agent 等 agent，不替代它们。
误解二：用了 Multica 就不用看代码。
不对。Multica 让执行过程可见，但质量仍然来自测试、review 和清楚的验收标准。
误解三：所有代码都会上传到 Multica。
官网 FAQ 说明，agent execution 发生在你的机器或自己的云基础设施上。代码不会经过 Multica servers。平台负责协调任务状态和事件。
误解四：技能库等于 prompt 收藏夹。
不只是。skill 可以包含指令、配置、schema、模板和执行步骤。它更接近团队流程的可执行封装。
结尾
当 agent 只有一个，它是工具。当 agent 变成十个，它就是组织问题。
Multica 的价值不在于“再造一个更聪明的 AI 程序员”。它把任务分配、状态追踪、阻塞反馈、技能复用和运行时管理放在一个平台里，让 Human + Agent 团队有了基本秩序。
你可以继续用终端管理一个 agent。问题是：当下一个 10 个“同事”不是人，你还准备靠终端标签页管理它们吗？
