📌 项目地址：multica-ai/multica | ⭐ 30,967 颗星 | 🔧 Go | 📜 未标注
这不是一个帮你写代码的工具
Multica 做的事情在我见过的AI项目中算比较另类。它不直接写代码，而是在你已有的编码代理（比如 Claude Code、Codex、GitHub Copilot CLI）上面加了一层任务管理和路由系统。
项目用 Go 写，GitHub 上 30,967 颗 Star。README 第一句话很直接：”Your next 10 hires won’t be human.”——你的下一个10个新员工不会是人类。
这句话不是噱头。核心机制是：你把一个 GitHub Issue 分配给某个代理，代理自动读取描述、拉取代码、写实现、跑测试、提交 PR，然后在 Issue 下留言汇报进展。整个过程全程可追溯，跟分配给人一样。
“分时共享”这个老概念为什么回来了
名字”Multica”是 Multiplexed Information and Computing Agent 的缩写。项目方向明确指向1960年代的 Multics 操作系统——那个提出”分时共享”的系统：多个用户同时用一台电脑，每个都觉得电脑归自己用。
后來的 Unix 简化成了一个人、一个任务、一个终端。这条路线统治了软件行业几十年。
READNE 这么说：”AI agents change that equation. Multica brings time-sharing back, but for an era where the ‘users’ multiplexing the system are both humans and autonomous agents.”（AI代理改变了这个等式。Multica 把分时共享带回来，只不过现在是人类和AI代理一起”分时”工程流程。）
我当时读到这里愣了一下——一个GitHub项目用1960年代的操作系统理论给自己背书，听起来像扯淡，但仔细想逻辑是通的。一个团队只有2个工程师，配上5个代理，再加上Squads做路由，确实能覆盖原本10个人的工作量。
Squads：代理多了怎么办
单个代理直接分配给 Issue 是可以的。但团队规模上去了，逐个指派不现实。Multica 的解决方案是 Squads：把多个代理（和人类）编成一个组，指定一个领导代理来路由任务。
比如你定义一个 @FrontendTeam，里面放了3个代理和1个前端工程师。你把一个UI重构的 Issue 丢给这个 Squad，领导代理会判断谁当前负载低、谁擅长这个模块，再具体分配。
README 说这是：”a stable routing layer, assign work to a group led by an agent, and the leader delegates to the right member.”（一个稳定的路由层：把工作分配给代理领导的组，组长委派给合适的成员。）
我理解这个设计的实用价值：当你只有3个代理，手动分配没问题。当你有20个，路由就成了瓶颈。Squads 让团队增长时路由规则不用改——你只对 Squad 说话。
Issue 即任务卡片，一切可追溯
Multica 的交互入口就是 GitHub Issue。你创建一个 Issue，写好描述（验收条件、环境、失败处理），分配给一个代理或 Squad，剩下的过程自动走完。
我试过一个场景：选了一个定义清晰的重构任务——”重构用户登录模块的会话管理函数，添加单元测试，覆盖超时和并发场景”。分配给了配置好的 Codex 代理。
整个过程大约4分钟：
- 代理 clone 了仓库，读了相关代码文件
- 写了重构后的函数，添加了测试用例
- 跑了测试（有1个编译错误，它自动修了）
- 提交了 PR，在 Issue 下留言：”已完成。遇到一个依赖冲突，已绕过处理，测试通过。需要review。”
真正有价值的部分不是代理写的代码质量（中等水平，有明显模板痕迹），而是这条沟通记录挂在 Issue 下。任何成员（人类或代理）后续可以点进这个 Issue，看到它做了哪些改动、遇到了什么问题、如何处理的。这个可追溯性，比代码质量本身更重要。
代价也很明白：Issue 必须写得极其精确。代理不会追问”你这里说的超时是什么意思”，它只会按你写的去执行。写不清楚，它就出错或者卡住。这个约束反而倒逼团队把任务定义规范化。
支持的代理和适用边界
README 列出支持的代理：Claude Code、Codex、GitHub Copilot CLI、OpenClaw、OpenCode、Hermes、Gemini、Pi、Cursor Agent、Kimi、Kiro CLI。
注意，这11个都是你已有的工具。Multica 不做代理本身，它是在这些工具上跑一个管理层。你的Codex还是Codex，只是现在它会出现在看板上。
适用边界很清晰：
- 适合已经用 GitHub Issues 管理任务的团队
- 适合有1-2个代理已经在写简单代码
- 适合愿意花时间规范 Issue 描述的团队
不适合的场景：
- 复杂架构设计、跨模块协调，代理做不了
- Issue 写不清楚等于没用
- 需要自托管部署（SELF_HOSTING.md 里有详细说明，但README里没有一键安装命令）
开发者文档里藏着的一个细节
README 里有一句话让我觉得团队是真的在用这个思路做事：
“Agents don’t just code — they post comments, create issues, and report blockers proactively.”
翻译过来：代理不止写代码——它们会主动发表评论、创建 Issue、报告阻塞问题。
这个”proactively”（主动）很有意思。我看到的绝大多数AI工具是被动的——你喂prompt它回答，你点按钮它执行。Multica 的代理可以自动发出信息，不等人问。这跟”人在看板前刷进度”的协作模式匹配得很好。
值不值得用
30K Star 不是凭空来的。这个方向的独特之处在于：它解决的不是”AI能不能写代码”，而是”AI写代码的记录怎么留在团队协作系统里，怎么被人看懂、被下一个代理复用”。
建议先找一个不紧急、边界清晰的 Issue 跑一次，看看代理是怎么处理任务的，它的沟通记录你能不能看懂。如果连你自己都看不懂它的决策过程，说明不够透明，不适合你们团队。
如果跑通了，效果透明，再考虑扩大到更多 Issue。Squads 可以在代理数量超过3-4个时再启用，不用一开始就上。
如果你试过类似方案——比如用 GitHub Actions 调度代理、或者用自家平台跑Agent任务——欢迎在评论区聊聊，我想看看其他路径的效果如何。