你的下一批 10 个新员工，不会是人类。
但说实话，现在大多数人用 AI 写代码的方式，跟管一个不打卡的远程实习生没什么区别。你手动把活扔给它，它干完干不完，全靠你一个人盯着。
你同时开着 Claude Code 和 Cursor，一边让 AI 改 bug，一边让它写新功能。但这两个 AI 之间没有任何协调机制。它们不知道彼此的存在，也不知道对方在干什么。
任务分配靠你脑子记，进度跟踪靠你手动刷新，出了问题靠你逐条排查。
Multica 想改变这件事。
这个开源项目把 AI 编程智能体变成了项目看板上的正式成员：你分配 Issue，它领取任务，写代码跑测试，实时汇报进度。人类和 AI 在同一块看板上协作，状态自动流转，不用再来回复制 prompt。
三层架构，服务器完全不碰你的代码
Multica 的设计有个反直觉的地方：服务器不执行任何智能体任务。
整个系统分三层。Multica 服务器（云端或自托管）管理工作区、Issue、任务队列，同时作为 WebSocket 枢纽推送实时更新。但它不碰你的代码，不碰你的 API 密钥，也不碰你本地的文件。
真正干活的是跑在你机器上的一个守护进程（Daemon），它是 Multica CLI 的一部分。这个进程做三件事：探测你本地装了哪些 AI 工具、向服务器注册自己、每隔 3 秒轮询一次看有没有新任务。
第三层就是你已经装好的 AI 编程工具。Multica 目前支持 14 款：Claude Code、Cursor、Codex、Windsurf、Aider 等等。它们是真正写代码的那一环。
一个典型的任务流程是这样的。你在 Web 端把一个 Issue 分配给 AI，服务器创建一条状态为 queued 的任务。3 秒之内，本地守护进程领取了它，状态变成 dispatched。
接着守护进程在本地创建隔离目录，调用 AI 工具开始执行，状态转为 running。AI 在你的机器上写代码、跑测试、提交结果。执行完毕后守护进程向服务器汇报，状态更新为 completed 或 failed。
举个具体场景：你在 Web 端创建了一个 Issue"重构用户认证模块"，分配给 Claude Code。3 秒后守护进程领了活，Claude Code 在你本地的隔离目录里开始分析现有代码、写新的认证逻辑、跑测试。整个过程执行日志通过 WebSocket 实时推到浏览器上，你能看到每一步进展。
完成后守护进程汇报结果，前端刷新，Issue 状态自动变成 completed。
API 密钥、代码目录、工具权限，全部留在本地。Multica 服务器只看到任务的"状态"，看不到任务的"内容"。
想更彻底的话，可以用 Docker Compose 或 Helm 在自有服务器上跑完整后端，连任务元数据都不经过第三方。调度层在云端，执行层在本地。这是 Multica 最核心的设计取舍。
四种让 AI 干活的方式
分配 Issue 是最常规的操作，把 AI 设为负责人，它自动接管。上下文来自 Issue 描述和你附加的 Skills。
评论 @ 提及是轻量级介入。不想改 Issue 状态，也不想换负责人，只是想让 AI 给个建议。比如一段代码你觉得有性能问题，但还不想正式发起重构，@一下让 AI 先看看。
直接聊天在隔离沙盒里进行，适合一对一地起草方案、调试思路、验证技术想法。想好了再转成正式 Issue。
最后是 Autopilots——通过 Cron 定时或 Webhook 触发的长期自动化指令。每周一早上 9 点跑一次安全扫描，或者每当有新 PR 合并时自动更新 API 文档。设好规则后就不用管了，AI 自己按节奏干活。
Runtime 是怎么回事
理解了任务流转，再来看 Multica 的一个关键概念：Runtime（运行时）。
一个 Runtime = 一个守护进程 × 一款 AI 工具。每款工具在每个工作区里都是独立的 Runtime。所以两款工具连上两个工作区，就是 2×2 = 4 个 Runtime，各自并行处理任务。
Multica 会自动检测你机器上装了什么工具，不用手动配。这个设计意味着你可以同时让 Claude Code 处理后端逻辑、Cursor 写前端组件，互不干扰。
14 款
目前支持的 AI 编程工具数量，还在持续增加。
小队和技能包
Multica 里有个"小队"（Squads）设定：一组 AI 智能体，由一个"队长"AI 领导。新 Issue 进来后，队长负责分析任务并分配给合适的成员。
比如一个涉及前后端的功能需求，队长可能把 UI 部分拆给一个擅长前端的 AI，API 设计分给另一个。这种层级结构在单个 AI 能力有限时特别有用，通过拆分和并行执行来提升复杂项目的吞吐。
另一个有意思的功能是 Skills（技能包）。它把代码、配置和上下文打包成可复用的"专业知识单元"。
举个例子：你团队里有人摸索出一套处理 OAuth 接入的最佳实践，让 AI 处理这类问题时又快又准。这个方案可以封装成一个 Skill，挂载给团队里所有 AI。下次再遇到 OAuth 相关需求，AI 不用从零摸索，直接调用这个 Skill。
Skills 让 AI 越用越聪明。团队的隐性知识变成了可复用的显性资产。底层用 PostgreSQL 17 + pgvector 扩展做了向量嵌入，让 Skills 的匹配是语义级的。即使描述用词不同，只要意思相近就能匹配到，不只是关键词硬搜。
技术栈和其他细节
前端用 Next.js 16，后端用 Go（高并发 WebSocket 正是 Go 擅长的场景），数据库是 PostgreSQL 17。平台支持与 GitHub、飞书、Slack 集成，PR 合并时自动关闭关联 Issue，在聊天工具里用斜杠命令直接创建任务。桌面端、CLI、iOS 移动端都能用。
和 Devin、Claude Managed Agents 有什么区别
Devin 走的是"全套虚拟员工"路线，有自己的云端开发环境和浏览器，端到端包办。Multica 不要求你换 IDE 或购买新工具，它调度你机器上已有的工具，成本和迁移门槛都更低。
Claude Managed Agents 与 Anthropic 生态集成最深，但只支持 Claude 模型，无法自部署。Multica 支持 14 款工具、可自托管、不锁定厂商。
💡
对于合规要求高的团队（金融、医疗、政府外包），开源 + 私有化部署 + 不碰代码的组合拳是 Multica 最大的差异化卖点。
过渡形态，但方向对了
说实话，Multica 目前更像是一个过渡形态，不是终局。
预设的状态工作流适配不了太复杂的场景（比如招投标或多轮审批），被动看板也没法主动预警超期和瓶颈。任务失败后只能手动介入，缺少自动重试或结构化反馈的机制。
但我觉得它的核心方向是对的：给 AI 一个正式的项目管理身份，让人类能"盯着"AI 的活，而不是放任它自由发挥。
如果你们团队已经在重度使用 AI 编程工具，但任务管理全靠脑子记、群里喊，Multica 可能正好填上这个空缺。开源、可自托管、不绑定厂商。
AI 越来越会写代码，但谁来保证它不跑偏？答案可能是：一个把 AI 当人管的项目管理工具。
