Multica协作看板：把AI编码Agent招进团队

当个人开发者还在为管理五个终端窗口里的Agent焦头烂额时，一个名为Multica的开源项目提出了另一种思路：让AI Agent像同事一样出现在项目管理看板上，有自己的名字，能认领任务，会在评论区汇报进展，做完后交回人类审查。这个项目在GitHub上已获得约5.2万Star，官方简介只有一句话——让人和AI Agent像一支队伍一样工作。

名字本身是个梗。Multica全称是Multiplex Information and Computing Agent，致敬1960年代开创分时操作系统的Multics。但真正值得关注的是它试图解决的问题：当Agent的单点编码能力不再是瓶颈，管理就成了新的瓶颈。

为什么需要人机混编看板

个人开发者面对多个Agent时，状态全靠肉眼扫终端窗口。团队场景更麻烦：人的任务在项目管理工具里，AI的任务散落在各自终端，两边进度对不上。周会汇报时没人说得清Agent这周到底产出了什么。还有一层隐性成本——任务的上下文散在聊天记录里，当时为什么这么做、结论落在哪个文件，过两周就没人记得。

Multica的答案是把所有工作收进同一种东西：Issue。人认领是人干，Agent认领是Agent干，看板上不分彼此。决策、讨论、产出链接全部留在Issue里，形成可追溯的工作记录。

四个核心对象撑起协作模型

支撑这套机制的是四个对象。Issue是工作单元，被指派给Agent后自动开工，在评论区汇报进展，完成后交回人类审查。每个Issue有编号，PR标题带上编号就能自动关联代码评审和任务。

Agent是命名实体，绑定模型供应商和运行机器，像任何同事一样出现在看板上，可以被指派、被订阅、被评论。Runtime是Agent实际执行代码的机器——你的笔记本或云主机都行，装一个守护进程通过WebSocket连服务端。这里有个关键设计：代码不出本机，服务端只负责调度，源码和文件始终留在自己的机器上。对代码敏感的场景，这一条决定了能不能用。

Squad则把人和若干Agent编成一组，由Leader负责路由任务。

WebSocket 是一种在单个 TCP 连接上提供全双工通信的协议。与传统的 HTTP 请求-响应模式不同，WebSocket 建立连接后，服务端和客户端可以随时主动向对方推送消息，无需客户端反复轮询。Multica 的 Runtime 守护进程正是通过 WebSocket 与服务端保持长连接，从而让服务端能够实时下发任务指派、接收 Agent 的进展汇报，同时避免频繁建立连接的开销。这种设计也使得任务状态在看板上能够近乎实时地更新。

流程编排与知识沉淀

派活只是第一步，Multica还管流程和沉淀。Stage做阶段编排，一个大任务拆成按1、2、3编号的子任务排队，比如调研是Stage 1、开发是Stage 2，只有Stage 1全部完成才会唤醒下一阶段负责人，多阶段流水线不用人盯。

Autopilot按Cron定时跑例行工作——每天早上的站会摘要、每周的依赖审计、固定日期的报表，定时任务交给Agent，早上打开看板直接收结果。Skill把解决过的问题沉淀成可复用技能，下次同类任务直接调用，思路和Agent社区流行的技能文件同一条路线。

ReviewGate是评审闸门：Agent的产出先进评审状态，人点头才算完成，不会直接改进主干分支。团队敢把活派给AI，靠的就是这类闸门。

技术栈与可观测性

技术选型都是眼熟的组合：后端Go配Chi路由和SQLC数据库访问，实时通信用Gorilla WebSocket，数据库是PostgreSQL 17加Crypto和pg_trgm扩展，后者负责全文搜索——搜索会同时命中标题、描述和评论正文，一个只存在于讨论里的结论后来照样搜得到。前端Next.js，同一套界面装进Electron做桌面端，用Expo和React Native做移动端。整个仓库是pnpm加Turbo的Monorepo，CLI用GoReleaser发布。

任务派下去卡住了怎么办？Multica把执行历史做成了可查对象。Issue runs列出任务跑过哪几轮、各自怎么结束，Run Messages展开某次运行的实际动作，Issue Usage汇总Token开销。看板说In Progress不代表真的在动，跑了什么、卡在哪步、花了多少钱，数据全在命令行里。

有两个破坏性动作需要特别注意：Rerun会把当前指派重新排队，Cancel Task会中断正在跑的Agent，正在写的东西就丢了。官方文档明确要求这两个动作必须先跟人确认，不能拿来清理自己没读过的状态。

pg_trgm 是 PostgreSQL 的一个扩展模块，它通过将文本拆分为连续的三字符序列（trigram）来支持模糊匹配和相似度搜索。与标准全文检索依赖分词和词干还原不同，pg_trgm 对中文等无空格分隔的语言也能提供较好的子串匹配效果，并且可以直接为 LIKE、ILIKE 以及相似度运算符（如 %）建立索引。Multica 用它来同时搜索 Issue 的标题、描述和评论正文，使得只出现在讨论中的结论也能被检索到。

兼容性与安全细节

Multica不自带模型，驱动你机器上已装好的命令行工具，官方列出26种支持的Agent CLI，包括Claude Code、Codex、Cursor、GitHub Copilot CLI、OpenCode等主流工具。版本控制接GitHub、GitLab、Gitea、Forgejo，消息接Slack、飞书、钉钉、企业微信和Telegram——后一面对国内团队特别实在，任务状态和评论能直接推到群里，手机上就能验收Agent的活。

CLI本机实测版本0.6.1，所有命令基本支持JSON输出。有两个细节体现对副作用的谨慎：NoStart参数让改状态或指派时只写状态不触发运行，官方算得很直白——多一次无谓的运行就是多一份模型账单；Mention的语义是评论里@一个Agent不是礼貌称呼，而是真的把活排进它的队列，所以技能文档禁止为致谢客套而@，回复时重复@还可能触发循环。评论正文必须从文件传入，不允许写在命令行参数里，因为Shell会改写反引号、变量和引号，Agent写的代码片段直接进参数十有八九会被破坏。

部署与许可

快速体验用官方安装脚本，跑Multica Setup认证后接托管云版本。想全自控就自托管，走Docker Compose或Helm Setup Self Host，把后端、数据库、前端整套起在自己的服务器上，家里的NAS或公司机房都行。隐私方面，默认每天发送一次匿名遥测快照，只有使用量统计，内容是环境变量，设DOT_NOT_TRACK即可关闭。

许可协议是Apache 2.0加附加条件，管托管服务、商用嵌入和品牌几块，官方叫Source Available。公司内部部署随便用，想拿它做托管生意或商用产品嵌入需要看附加条件。

Apache 2.0 是一种宽松的开源许可证，允许用户自由使用、修改和分发软件，包括用于商业目的，且不要求衍生作品开源。但 Multica 在此基础之上附加了额外条件，主要针对托管服务、商用嵌入和品牌使用。这种模式常被称为 Source Available（源码可见），意味着源代码公开可获取，但并非 OSI 定义的标准开源许可。对于公司内部部署，通常不受附加条件限制；而如果计划将 Multica 作为托管服务对外提供，或将其嵌入商业产品中销售，则需要仔细阅读并遵守附加条款。

和终端工具的分工

Multica和Hermes这类终端工具解决的是不同层面的问题。终端工具管的是这台机器的终端里Agent们怎么活着，是运行时；Multica管的是整个团队的任务怎么流转，Agent只是其中一种成员，是协作层。一个在机器这一侧，一个在任务那一侧，完全可以一起用——Multica派下来的活，Agent照样可以在终端工具里跑。

选不选Multica，判断标准就一条：如果你需要的只是多一个终端技巧，它用不上；如果你想让AI进团队的排期、验收和例行流程，让Agent的产出和人用同一套看板管理，这是目前这个方向上最成熟的开源选项。