AI 深度技能之-解读Multica（一）- 让Agent 变成真·队友

"Your next 10 hires won't be human." ------ Multica 官网首页标语

如果你用过 Claude Code、Codex 或 Cursor Agent，大概经历过这样的场景：终端里开了一堆窗口，手动复制 prompt，盯着执行进度，跑完了还得自己把结果贴回 Issue。Agent 很强，但用起来像外包------你得时刻盯着，沟通全靠复制粘贴。

Multica 想解决的就是这个问题。它不造新的 Agent，而是给已有的 Coding Agent 套了一层项目管理壳，让它们变成看板上可分配、可追踪、可协作的"队友"。

项目地址：github.com/multica-ai/... 官网文档：multica.ai/docs/zh

一、它到底解决什么问题

先把痛点摆出来，再看 Multica 怎么接的招。

1. Agent 是个黑盒，跑完才知道结果

平时用 Agent CLI，你敲一个命令进去，它闷头跑，跑完输出一堆文字。中间出了什么问题、卡在哪一步、有没有改错文件，你只能等它跑完才知道。

Multica 的做法：把 Agent 执行过程拆成 Task 生命周期（排队 → 认领 → 执行 → 完成/失败），通过 WebSocket 实时推送进度。你在看板上能看见每个 Agent 当前在干什么，跟看同事的 Jira 状态一样。

2. 多 Agent 协作全靠人工转达

前端 Agent 跑完了要交给后端 Agent，你得手动把前者的输出整理成后者的 prompt。Agent 一多，人工路由的负担直线上升。

Multica 的做法 ：Squad 机制。把多个 Agent 编成一个小队，指定一个 Leader Agent。任务分给 Squad，Leader 自己判断该转给谁。你不用操心路由细节，@前端组 比 @小张或小李或小王 省事得多。

3. 技能没法复用，每次从头来

Agent 帮你做了一次数据库迁移，下次做同样的迁移，你得把上次的 prompt 再贴一遍。经验没法积累。

Multica 的做法：Skills（技能）。每次成功的执行可以沉淀成一份 Markdown 技能文档，后续任务自动注入到 Agent 上下文里。做过的迁移、部署流程、代码审查清单，都变成可复用的团队资产。

4. 定时任务没人盯就停

每天要跑的日报、定期的代码巡检，没人在场就没人触发 Agent。

Multica 的做法：Autopilots。Cron / Webhook / 手动三种触发方式，到点自动创建 Issue 并分配给 Agent 或 Squad，不需要人干预。

5. Agent 只能在本机跑，团队没法共享

你电脑上装了 Claude Code，同事电脑上装了 Codex。两个人没法互相用对方的 Agent，更没法在一个看板上统一管理。

Multica 的做法：Daemon + Runtime 架构。Daemon 跑在你自己的机器上，自动检测本地装了哪些 Agent CLI 并注册为 Runtime。服务器只做协调，不跑 Agent 代码。团队共享一个 Multica 工作区，但各自用各自的 Runtime。

二、业务流程：一个任务从创建到交付

下面用一个具体的场景走一遍完整流程。假设你要让 Agent 帮你修复一个 GitHub Issue。

完整流程图

逐步拆解

步骤 1：创建 Issue

在看板上创建一个 Issue，写清楚要做什么。跟你在 Jira / GitHub Issue 上创建任务一模一样。

步骤 2：分配

把 Issue 分配给某个 Agent 或某个 Squad。分配的一瞬间，Multica 做几件事：

创建一条 Task 记录，状态为 dispatched
准入检查：Agent 的 Runtime 在不在线？在线才入队
去重检查：同一个 Issue + 同一个 Agent 有没有 pending 的 Task？有就跳过

如果分配给 Squad，Leader Agent 会收到一份 Briefing（简报），包含：

操作协议：你是 Leader，要判断任务该谁干
成员名册：每个成员的名字、类型（agent/human）、角色、技能列表
组级指令：如果 Squad 有特殊规则（比如"所有 PR 必须先跑 lint"），会写在这里

步骤 3：Leader 路由决策

Leader 拿到任务后，根据 Briefing 做判断：

自己能干 → 自己处理
某个成员更合适 → 委托，生成一段 Handoff Note（交接说明），把任务上下文压缩成 200 字以内的摘要传给对方
任务太大 → 拆成子任务，分别分配

步骤 4：Agent 执行

被分配的 Agent 通过 Daemon 在本地机器上执行。Daemon 是一个后台进程，它的工作很简单：

arduino 复制代码

监听 Multica 服务器的 Task 队列
  → 收到 Task → 调用对应的 Agent CLI（claude / codex / copilot...）
  → 把执行进度通过 WebSocket 回传服务器
  → 执行完毕，结果写回 Issue

Agent 不在 Multica 服务器上跑，始终在你自己的机器上跑。Multica 服务器只做协调。

步骤 5：协作（如果需要）

执行过程中，Agent 如果需要其他 Agent 的帮助，可以在 Issue 下评论并 @mention 对方。被 @ 的 Agent 会收到一个 Task，跟人类在 GitHub Issue 里 @ 同事是一样的体验。

bash 复制代码

# Agent A 在 Issue 下的评论
@agent-b 这个 API 的认证方式用的是什么？我这边需要对接。

# Agent B 收到 Task，查自己的记忆，回复
用的是 OAuth 2.0，client_id 在 .env 里，callback 地址是 /auth/callback。

步骤 6：完成与技能沉淀

Task 完成后，结果自动写回 Issue 评论。如果这次解决方案有通用价值，可以沉淀成一份 Skill------就是一个 Markdown 文件，描述"遇到什么问题、怎么解决的、注意事项是什么"。下次类似任务，Skill 会自动注入到 Agent 上下文里。

三、Squad 路由：Multica 最有意思的设计

Squad 是 Multica 区别于其他 Agent 管理工具的核心机制。详细聊聊它为什么有意思。

Squad 是什么

Squad = 一组 Agent（可以混编人类）+ 一个 Leader Agent。任务分配给 Squad，Leader 决定具体谁干。

为什么不直接分配给具体 Agent

团队小的时候，直接 @小张 没问题。但当 Agent 数量到十几个、几十个的时候：

你记不住每个 Agent 擅长什么
新人不知道该找谁
Agent 增减时，所有路由逻辑要重新调整

Squad 把路由逻辑下沉到 Leader Agent。你只管 @前端组，Leader 根据成员的能力摘要做判断。团队扩容时，往 Squad 里加人就行，路由方式不变。

Leader 怎么做决策

Leader 收到任务时，上下文里被注入了 Briefing。Leader 的决策逻辑：

关键点：Leader 不读成员的记忆。Leader 只知道成员的名字、角色、技能列表（来自 Briefing 的 Roster）。这就像部门经理分配工作，不需要知道工程师脑子里记着什么，只需要知道"小王擅长 React、小李擅长 CSS"。

跨 Agent 协作通过 Issue 评论

Agent A 需要 Agent B 的信息，不是直接读 B 的记忆库，而是在 Issue 里 @B 提问。B 被触发后检索自己的上下文回答。A 拿到的是 B 的回答，不是 B 的原始记忆。

这个设计的好处：

审计友好：所有跨 Agent 交互都在 Issue 评论里，可追溯
解耦：Agent 之间不需要共享内部状态
人类可介入：人随时可以在评论里补充信息或修正方向

四、Autopilot：让 Agent 自己跑起来

Autopilot 解决的是"没人触发就停"的问题。

三种触发方式

触发方式	适用场景
Cron	每天早上的日报、每周的代码巡检、每月的依赖检查
Webhook	GitHub Push 后自动跑 lint、PR 创建后自动 Code Review
手动	临时起意跑一次，比如"现在检查一下所有服务的健康状态"

两种执行模式

create_issue 模式：创建可见的 Issue，有审计追踪。适合需要记录的工作。
run_only 模式：直接执行，不创建 Issue。适合静默监控类任务。

准入检查

Autopilot 触发时不是无脑执行，会先做准入检查：

Agent 的 Runtime 在不在线？不在线 → 跳过本次，不堆积死任务
Squad 是否已归档？归档了 → 跳过
Leader Agent 是否还在？不在了 → 跳过

这些检查避免了"定时任务堆积成山但全是失败"的问题。

五、技术架构

整体架构

技术栈

层	技术选型	为什么这么选
前端	Next.js 16 (App Router)	生态成熟，SSR + 客户端交互兼顾
桌面	Electron	复用 Web 前端，跨平台桌面覆盖
移动	iOS 原生 (Swift)	移动端查看进度、审批任务
后端	Go (Chi router, sqlc, gorilla/websocket)	编译型语言，高并发，适合任务调度
数据库	PostgreSQL 17 + pgvector	关系型 + 向量检索，一个库搞定
Agent 运行时	本地 Daemon	Agent 跑在用户机器上，不跑在服务器上

代码结构

bash 复制代码

multica/
├── server/                 # Go 后端
│   ├── internal/
│   │   ├── handler/        # HTTP/WS handler
│   │   ├── service/        # 业务逻辑
│   │   │   └── builtin_skills/  # 内置技能（Squads、Autopilots、Mentioning 等）
│   │   ├── events/         # 事件系统
│   │   └── analytics/      # 埋点分析
│   ├── migrations/         # 数据库迁移（125+ 个迁移文件）
│   └── pkg/db/generated/   # sqlc 生成的类型安全查询代码
├── apps/
│   ├── web/                # Next.js 前端
│   ├── desktop/            # Electron 桌面
│   └── mobile/             # iOS 移动端
├── packages/
│   ├── core/               # 无头业务逻辑（Zustand + React Query）
│   ├── ui/                 # 原子组件（shadcn/Base UI）
│   └── views/              # 页面视图（平台无关）
├── Dockerfile
└── docker-compose.selfhost.yml

几个值得注意的技术决策

1. sqlc 而非 ORM

Go 后端用 sqlc（写 SQL → 生成类型安全的 Go 代码），不用 GORM 之类的 ORM。迁移文件有 125+ 个，每个都是纯 SQL。好处是 SQL 层完全透明，性能可预期。

2. pgvector 做语义检索

PostgreSQL 装了 pgvector 扩展。Agent 的 Skill 检索、Issue 的语义搜索都走 pgvector，不用额外引一个向量数据库。

3. WebSocket 实时进度推送

Agent 执行进度通过 gorilla/websocket 实时推送到前端。Task 状态变更、Issue 评论更新、Agent 上线下线，都是 WS 事件。

4. 前端包边界硬隔离

bash 复制代码

packages/core/    --- 无 react-dom，无 localStorage，无 process.env
packages/ui/      --- 不依赖 @multica/core
packages/views/   --- 不依赖 next/* 或 react-router-dom
apps/web/platform/ --- 唯一允许用 Next.js API 的地方

这套边界让前端逻辑可以跨平台复用------Web、Desktop（Electron）、未来的 TUI 都用同一套 core 和 views。

六、Agent 运行时机制

这块是 Multica 设计中最容易被忽略但实际很关键的部分。

Daemon 与 Runtime 的关系

Daemon 和 Runtime 的关系图见上方架构图，核心要点：

Daemon 是跑在你机器上的后台进程
启动时扫描 PATH，检测装了哪些 Agent CLI
每个 CLI 注册为一个 Runtime
长轮询 Multica 服务器的 Task 队列
收到 Task → 调用对应 CLI → 执行 → 进度回传

Agent 永远跑在你自己的机器上，不在 Multica 服务器上跑。 服务器只做协调和存储。

Task 生命周期

arduino 复制代码

dispatched → claimed → running → completed
                                → failed
                                → cancelled

状态	含义
dispatched	已入队，等 Daemon 认领
claimed	Daemon 已认领，准备执行
running	Agent CLI 正在执行
completed	执行成功，结果已写回 Issue
failed	执行失败，可配置自动重试
cancelled	被取消（比如 Issue 被关闭）

Handoff Note ------ 委托时的上下文传递

当一个 Agent 把任务委托给另一个 Agent 时，会生成一段 Handoff Note。作用是让接收方快速了解任务背景，不用从头摸索。

Handoff Note 的内容通常包括：

任务是什么
为什么委托给你
相关的上下文信息（从委托方的工作记忆中提取）
预期的交付物

这段内容存在 Task 表的一个字段里，Agent 认领 Task 时注入到上下文中。

七、Skill 系统：让 Agent 越用越强

Skill 是什么

Skill 是一份 Markdown 文件，描述"遇到什么问题、怎么解决、注意什么"。它会在任务执行时自动注入到 Agent 的上下文里。

bash 复制代码

skills/
├── deploy-to-staging.md      # 部署到预发环境的步骤
├── db-migration-checklist.md # 数据库迁移检查清单
├── code-review-guidelines.md # 代码审查规范
└── api-auth-setup.md         # API 认证配置方法

Skill 的来源

Multica 内置了一组 Skill（放在 server/internal/service/builtin_skills/ 下），覆盖了平台自身的核心功能：

内置 Skill	作用
multica-squads	教 Leader Agent 怎么做路由决策
multica-autopilots	教 Agent 怎么处理定时任务
multica-mentioning	教 Agent 怎么处理 @mention
multica-creating-agents	教 Agent 怎么创建新 Issue
multica-working-on-issues	教 Agent 怎么处理被分配的 Issue
multica-skill-importing	教 Agent 怎么创建新 Skill
multica-projects-and-resources	项目和资源管理
multica-runtimes-and-repos	运行时和仓库管理

用户也可以自己写 Skill，放在本地目录或上传到工作区。

Skill 的注入时机

不是所有 Skill 都注入。Multica 会根据任务内容做相关性匹配，只注入跟当前任务相关的 Skill。这避免了上下文被无关 Skill 撑爆。

八、它解决的痛点与没解决的

解决了

痛点	方案
Agent 是黑盒	Task 生命周期 + WebSocket 实时进度
多 Agent 协作靠人工	Squad Leader 自动路由
经验没法复用	Skill 沉淀 + 自动注入
定时任务没人触发	Autopilot（Cron / Webhook / 手动）
Agent 只能本机用	Daemon + Runtime 架构，团队共享看板
多工具混用	统一接口适配 14 种 Agent CLI

没解决（或者说不是它要解决的）

问题	说明
Agent 自身的记忆管理	Multica 不碰这块，完全交给底层 Agent CLI
Agent 的模型路由	用什么模型、怎么省钱，由 Agent CLI 自己决定
跨工作区记忆共享	工作区之间完全隔离，不共享 Agent 也不共享记忆
非编码场景的 Agent	设计上面向编码场景，其他场景需要自己适配

这种"不做"其实是一种设计哲学------Multica 不替 Agent 思考，帮 Agent 协作。 它把记忆、推理、模型选择都留给底层 Agent CLI，自己只做任务编排和团队协作。

九、适合谁用

适合

团队里已经在用 Claude Code / Codex 等 Coding Agent，觉得管理多个 Agent 很痛苦
想让多个 Agent 协作完成大任务，但人工路由太累
需要定时触发 Agent 跑周期性工作（日报、巡检、Code Review）
团队成员用不同的 Agent CLI，想统一管理
想把 Agent 的工作沉淀成可复用的团队技能

不太适合

只用单个 Agent 做单次任务，没有协作需求
需要 Agent 在服务器上跑（Multica 的 Agent 跑在用户本地）
非 Coding 场景（虽然理论上可以适配，但内置 Skill 都是面向编码的）
对 Agent 记忆有复杂管理需求的（Multica 刻意不碰这块）

十、技术亮点总结

1. Daemon 架构------Agent 不上云

Agent CLI 跑在用户自己的机器上，Multica 服务器只做协调。这意味着：

代码不离开你的机器
不用给 Multica 服务器配 API Key
Agent 访问本地文件系统、数据库、内网服务都不需要额外配置

对于有数据安全要求的团队，这个设计很友好。

2. Briefing 机制------Leader 路由的上下文注入

Leader Agent 做路由决策时，不需要读成员的记忆。Multica 通过 Briefing 把成员的能力摘要注入 Leader 的上下文。这个设计让路由决策的成本很低------Leader 只需要做一次 LLM 调用就能决定任务该谁干，不需要复杂的记忆检索。

3. Issue 评论作为 Agent 间通信协议

跨 Agent 协作不靠共享记忆库，靠 Issue 评论 + @mention。这个设计有三个好处：

审计友好（所有交互都在 Issue 里）
解耦（Agent 之间不需要知道对方的内部状态）
人类可介入（人随时可以在评论里补充信息）

4. Skill 的自动注入

Skill 不是简单的文档库，它会根据任务内容自动注入到 Agent 上下文。这意味着 Agent 的能力会随着团队使用越来越强------做过的迁移、踩过的坑，都变成 Skill，下次自动带上。

5. 准入检查------防止死任务堆积

Autopilot 和 Task 入队前都做准入检查：Runtime 在线吗？Leader 还在吗？Squad 归档了吗？不满足条件就跳过，不堆积死任务。这个细节在实际使用中很关键，否则定时任务跑几天就把队列塞满了。

十一、协议与自部署

Multica 使用修改版的 Apache 2.0 协议。核心限制两条：

不能直接拿 Multica 做 SaaS 卖给别人------内部使用没问题，但对外提供托管服务需要商业授权
不能去掉前端 LOGO 和版权信息------除非你不用 Multica 的前端

自部署一条命令：

arduino 复制代码

curl -fsSL https://raw.githubusercontent.com/multica-ai/multica/main/scripts/install.sh | bash -s -- --with-server
multica setup self-host

需要 Docker。完整的自部署指南在 SELF_HOSTING.md。

写在最后

Multica 的定位很清晰：不造 Agent，管 Agent。 它不跟 Claude Code / Codex 竞争，而是做它们的上层管理平台。

它最值得借鉴的不是什么复杂技术，而是两个设计思路：

Squad 路由替代记忆共享------跨 Agent 协作不靠共享记忆库，靠任务路由和 Issue 评论。复杂度直接降一个数量级。
Daemon 架构保证代码安全------Agent 跑在本地，服务器只协调。对于有数据安全顾虑的团队，这是刚需。

如果你在找一种方式把多个 Coding Agent 组织起来协作，或者想让 Agent 定时跑起来而不用人盯着，Multica 值得一试。

相关链接

GitHub：github.com/multica-ai/...
官网：multica.ai
中文文档：multica.ai/docs/zh
Discord：discord.gg/W8gYBn226t
自部署指南：SELF_HOSTING.md