过去我们把 AI 当成一个更聪明的输入框。Multica 换了一个视角如果 AI 已经能接任务、改代码、跑测试、提 PR为什么不干脆把它放进团队的工作流里有一个挺有意思的变化可能很多人已经感受到了。以前用 AI 写代码我们的动作很像“找人帮忙”打开一个终端把需求粘进去等它跑完再把结果搬到另一个地方。任务一多终端标签页也跟着变多。Claude Code 在做重构Codex 在补测试另一个 Agent 在查线上问题。每个工具都很能干但你得亲自盯着它们记住谁在做什么手动补上下文失败了还要自己发现。到最后AI 节省了执行时间却把人变成了一个忙碌的调度器。Multica 想处理的恰好就是这一层问题。它不是另一个代码模型也不试图替代 Claude Code、Codex 或 OpenCode。它更像一个面向“人类成员 AI 成员”的协作控制台需求仍然以 Issue 的形式出现项目仍然有看板和状态流转只是任务的负责人除了人也可以是一个 Agent。官方把它称为面向 human agent teams 的开源工作空间任务、执行过程、决策记录和代码差异都会围绕同一个 Issue 串起来。这件事表面上像“给 Jira 加了 AI”但如果只这么理解就低估它了。真正稀缺的不再是生成能力而是协调能力今天的代码 Agent 已经不太缺“手脚”了。它们能读仓库、改文件、调用工具、执行测试甚至能完成一段相对完整的研发任务。问题在于这些能力通常散落在各自的会话和终端里。一个 Agent 的上下文结束了经验也跟着结束另一个 Agent 接手时你要重新解释项目背景任务执行到一半卡住如果没有人主动去看可能几个小时后才发现同一个问题被解决过一次下次仍然要从头提示。Multica 的价值是把这些“一次性的智能”放进一个可管理的系统里。你可以创建不同职责的 Agent为它们配置指令、运行环境和 Skills可以把 Agent 编进小队由一个负责人按照规则分派工作也可以用自动化定时触发巡检、周报、翻译或内容同步。官方目前列出了 20 种可接入的 Agent CLI包括 Claude Code、Codex、Cursor、Copilot、Kimi 与 OpenCode 等。这里有一个很关键的分界单个 Agent 解决的是“这件事怎么做”Multica 解决的是“谁来做、在哪里做、做到哪一步、失败后怎么办、结果由谁验收”。前者是执行能力后者是组织能力。当 AI 能力越来越接近标准化资源之后后者反而会成为更大的瓶颈。一张卡片如何变成一次完整的 Agent 执行想象一个最普通的需求给 App 首页的图标增加动态效果。在传统的 AI 编程流程里你会打开终端切到仓库目录组织一段提示词告诉 Agent 应该改哪里。它完成之后你再查看 diff、运行 App、决定是否提交。如果同时有五个项目这套动作要重复五遍。在 Multica 里入口变成了一张 Issue 卡片。你用自然语言描述需求把负责人设置成某个 Agent。系统把任务放进队列绑定相应项目和代码仓库再把任务交给指定的 Runtime。Agent 在 Runtime 所在的机器上拉起 CLI读取上下文、修改代码、运行命令并持续把状态、评论、阻塞原因和执行日志写回卡片。完成后卡片进入 Review而不是直接把代码推进主分支。这套流程最有价值的地方不是少填了几项表单而是把意图、执行和验收连成了一个闭环。人不必一直守着终端但也没有退出决策链。你仍然负责定义问题、补充约束、检查结果和决定是否合并。AI 获得了更大的行动空间同时每一步都有可以追踪的上下文。Multica 的任务生命周期会记录入队、领取、开始、完成或失败等状态并通过实时通道同步进度遇到阻塞时Agent 可以主动上报而不是安静地停在那里。这更接近真实团队的协作方式不是“我问一句你答一句”而是“我把工作交给你你持续汇报最后把可评审的结果交回来”。它的技术结构为什么值得看一眼Multica 的架构没有把所有执行都塞进中心服务而是把“管理平面”和“执行平面”拆开。管理平面负责项目、Issue、Agent、权限、状态和事件。官方仓库给出的实现是 Next.js 16 前端、Go 后端Chi 路由 sqlc gorilla/websocket以及带 pgvector 扩展的 PostgreSQL 17前后端之间承载常规业务交互任务状态通过 WebSocket 实时推送。Web、桌面端和移动端看到的是同一个工作空间。执行平面则是运行在本地电脑或自有云主机上的 Agent daemon。它靠近代码仓库也靠近已经安装并登录的各种 Agent CLI。中心服务把任务发给 daemondaemon 再启动 Claude Code、Codex、Cursor Agent 或其他 CLI 完成工作。换句话说Multica 自己不提供大模型它调度的是你已经拥有的工具和算力。用一张图把整体关系说清楚Multica 三层整体架构上面这张图里用户端、管理平面、执行平面是三个明确分开的角色。前端通过 REST 提交业务请求通过 WebSocket 订阅实时事件daemon 则以大约 3 秒一次的频率主动向后端拉取属于自己的任务跑完后再把状态和 token 用量回写。整个通信是“事件驱动 拉取执行”的组合好处是执行环境不必对公网开放也不需要中心服务持有你的代码和凭据。这个拆分很务实。首先代码执行不必集中到平台服务器其次团队可以把不同机器注册为 Runtime根据项目、权限或负载分配任务再次Agent 后端并没有被锁死今天用 Codex明天换成另一个兼容的 CLI管理流程仍然可以保持不变。官方说明中也强调Agent 实际执行发生在本机 daemon 或用户自己的云基础设施上平台主要协调任务状态并广播事件。如果把它类比成我们熟悉的工程系统Multica 有点像“项目管理系统 Agent 调度器 可观测控制台”。看板负责表达工作daemon 负责执行Skills 负责沉淀能力日志与 Review Gate 则负责让结果可追溯、可干预。一条任务在系统里的完整旅程一张卡片被分派给 Agent 之后背后其实经过了一整条状态流水线。后端有一个叫TaskService的服务负责把外部触发分派、评论、提及、Chat 消息落成agent_task_queue里的一条待办记录daemon 用SELECT … FOR UPDATE SKIP LOCKED的方式并发领任务保证同一条 Issue 不会被多个 daemon 同时抢到。领到之后daemon 会在本机开一个隔离的 workdir注入 Skills、MCP 配置和环境变量再拉起对应的 CLI 执行。流式过程中的每一次“思考”、每一次工具调用、每一段 diff都会顺着 daemon → 后端 → WebSocket 实时推到你正在看的那个页面。最后跑完了无论成功还是失败都会带上 token 用量、成本、失败分类一起落库然后进入 Review Gate 由人来拍板是否合并。Multica 任务生命周期有几个细节值得单独拿出来说一是任务合并。用户在 Agent 还没开始跑之前连发几条评论系统会把这些评论合并成一次运行的上下文避免让 Agent 一句一句反复重跑二是失败分类。上下文超限、模型鉴权失败、网络抖动会被打上不同标签其中“上下文溢出”“达到迭代上限”这类情况还会被标记为 poisoned下一轮直接开新会话而不是傻乎乎地在坏状态里 resume三是取消策略。当你手动 cancel 或超时命中看门狗默认 30 分钟无输出daemon 会走SIGTERM → SIGKILL的进程组信号把 CLI 顺带拉起的 MCP server 一起干掉避免留下僵尸进程。一个统一接口兼容 20 多种 Agent CLIMultica 之所以能在同一个看板上并行调度 Claude Code、Codex、Cursor、Copilot、Kimi、OpenCode 这类风格差异极大的工具靠的是server/pkg/agent里的一层 provider 抽象。所有具体 CLI 都要实现同一个Backend接口Run / Cancel / StreamMultica 再按协议把它们分成三类实现NDJSON 流以 Claude Code、OpenClaw 为代表用--output-format stream-json把思考、工具调用、结果按行拆成 JSON 事件JSON-RPC 2.0Codex 走自己的一套 schema通过 stdin/stdout 做请求-响应Agent Communication ProtocolACPHermes、Kiro、Kimi、QwenPaw 等使用这套跨厂商的 Agent 通信协议。Multica 的 Provider 抽象层这个设计带来的最大好处是“可替换性”。今天团队用 Claude Code 走主力开发明天想让某些任务改交给 Codex 或 Kimi看板、Issue、Skills、Review 流程都不需要改动只要在 Runtime 一侧切换对应的 provider 即可。对企业和团队来说这基本消除了“选错模型就要重来一遍工作流”的迁移成本。再往下一层daemon 还负责一些容易被忽略但相当重要的运行时事务token 输入输出与缓存命中统计、以 1e-10 美元为精度的成本计量、每个 Runtime 的活跃度热力图以及在 CLI 无响应时的看门狗兜底。这些数据都会顺着心跳回传到管理平面变成 Runtime 详情页上那些图表和排行的原始素材。看到这里其实可以理解Multica 的技术“重心”并不在模型侧而在“如何把一堆异构 Agent CLI 变成可以被组织、被观测、被审计的团队成员”这件事上。这也是它跟单纯的 code Agent 工具最本质的区别。Skills 才是这套系统会不会越用越强的关键只让 Agent 多跑几个任务并不会自然形成团队能力。真正能复利的是把一次成功的方法固化下来。比如第一次做数据库迁移时你需要告诉 Agent 去哪里查看现有 schema如何生成 up/down migration应该运行哪些检查失败时看哪些日志。如果这些经验只存在于一段对话里它们很快就会丢失。把它写成 Skill 后它就从“某次提示词”变成了可复用的工作手册。下一次不管任务交给哪个 Agent都能沿用同一套步骤。部署、代码审查、UI 检查、发版、周报甚至内容同步都可以用类似方式沉淀。Multica 将 Skill 作为团队级能力来管理让解决过的问题逐渐变成可重复调用的流程。这也解释了为什么 Multica 不是装好就自动起飞的魔法。平台只是把模型、CLI、工具调用、Skills、代码仓库和工作流组合到一起。真正决定效果的仍然是你有没有清晰的任务边界、可靠的验收标准以及足够好的能力配置。AI 团队和人类团队在这件事上其实很像招聘几个聪明人不等于自动得到一个高效组织。私有化部署时难点通常不在“跑起来”Multica 是开源且可自托管的官方提供 Docker Compose 和 Helm 等部署方式也提供云端与桌面端入口。对熟悉 Docker、Git 和 Node.js 工具链的开发者来说把服务拉起来不算特别神秘。真正容易踩坑的是运行环境的一致性。Server 能打开不代表 Agent 就能工作。Runtime 机器上必须先安装并认证至少一种受支持的 Agent CLIdaemon 需要能识别这些 CLI也需要访问正确的仓库、环境变量和凭据。若在 daemon 启动之后才新增 CLI通常还要让运行时重新扫描。容器环境变量发生变化时也不能想当然地把它当作热更新配置而要确认是否需要重建或重启服务。如果要从公网访问还要补上域名、HTTPS、反向代理与访问控制。如果用于团队项目则更要认真考虑仓库权限、模型密钥、Agent 可执行命令的范围以及最终合并前的人工 Review。平台能提供审计和权限边界但边界怎么划仍然是部署者的责任。还有一个容易忽略的点开源不等于没有授权条件。Multica 仓库使用的是带附加条件的 Multica License涉及托管服务、商业嵌入和品牌使用时应直接阅读 LICENSE而不是只凭“代码公开”四个字做判断。它最适合谁又不适合谁我觉得 Multica 最适合两类人。一类是同时维护多个项目的独立开发者。你可能有一个 App、一个网站、一个自动化脚本再加上博客和内容分发。过去这些项目都挤在脑子里现在可以把它们放进统一看板让不同 Agent 在不同 Runtime 上推进。人在路上时创建一条需求回到电脑前直接评审结果这种工作方式会明显改变个人项目的吞吐量。另一类是已经大规模使用代码 Agent 的研发团队。当终端里的 Agent 越来越多团队迟早需要统一的任务入口、权限、日志、成本视图和验收流程。与其让每个人建立一套私有提示词和脚本不如把有效的方法沉淀成团队共享的 Skill。但如果你只是偶尔让 AI 补一个函数或者项目本身没有清晰的 Issue、代码审查和自动测试流程Multica 可能显得过重。它放大的不仅是生产力也会放大流程本身的质量。需求模糊Agent 就会高效地跑偏没有测试自动生成的 PR 也很难快速验收权限没有隔离并发越高风险越大。所以在接入更多 Agent 之前最好先问三个问题任务能否被清楚描述结果能否被自动或半自动验证失败时是否有人能及时接管。最后聊一个我更在意的变化Multica 最让我感兴趣的不是“一个人能同时指挥十个 AI 员工”这种充满未来感的说法。真正的变化是软件研发的基本单位可能正在改变。以前我们优化的是一个人的编码速度后来优化的是人和 AI 的对话效率。再往后优化对象会变成一整个由人类和 Agent 组成的系统任务如何切分上下文如何传递能力如何复用运行时如何调度错误如何暴露最后由谁承担决策责任。当执行成本持续下降人的价值不会消失只是会向更上游移动。写出第一版代码不再是最难的事定义正确的问题、设计边界、建立验收标准和做出取舍会变得更重要。从这个角度看Multica 不是一个“让 AI 多写点代码”的工具。它更像是在提前回答另一个问题当 Agent 真的成为团队成员之后我们该用什么方式组织它们而这可能比模型又快了百分之多少更值得开发者认真看一眼。
