过去我们把 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。中心服务把任务发给 daemon，daemon 再启动 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 CLI

Multica 之所以能在同一个看板上并行调度 Claude Code、Codex、Cursor、Copilot、Kimi、OpenCode 这类风格差异极大的工具，靠的是 server/pkg/agent 里的一层 provider 抽象。所有具体 CLI 都要实现同一个 Backend 接口（Run / Cancel / Stream），Multica 再按协议把它们分成三类实现：

• NDJSON 流：以 Claude Code、OpenClaw 为代表，用 --output-format stream-json 把思考、工具调用、结果按行拆成 JSON 事件；

• JSON-RPC 2.0：Codex 走自己的一套 schema，通过 stdin/stdout 做请求-响应；

• Agent Communication Protocol（ACP）：Hermes、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 CLI；daemon 需要能识别这些 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 真的成为团队成员之后，我们该用什么方式组织它们？

而这，可能比模型又快了百分之多少，更值得开发者认真看一眼。