一周1.2w Star，热门赛道杀出一匹黑马！对谈Multica张佳圆：如何重写“人A协作”规则？

“多人+多 Agent”新主场。

张佳圆带着他的新产品 Multica 一周斩获 GitHub 1.2w Star回来了。

这一次，他想探索的是：

当 AI Agent 已经足够好，一个团队要怎么和多个 Agent 丝滑地协作？

Multica 致敬的是 1964 年的操作系统 Multics——那个最终失败、但启发了 Unix 世界半个世纪的“多人、多任务”先驱。今天，它正在创造新的历史。新产品上线不到 3 周，便迅速交出了一份炸裂的成绩单：

连续登上 GitHub Trending 榜单，一周涨 1.2w Star，平台上“平均每 10 秒，就有一个 Agent 任务被触发执行”。而支撑这一切的团队，只有 4 个真人 + 十几个 AI Agent。

在用户量和Agent任务暴涨的近两周里，他们团队处于怎样的一个高强度工作状态？在“多人+多 Agent”的明牌赛道，Multica 的壁垒是什么？张佳圆所解释的“不可复制性”，真的能成立吗？

以下是十字路口和Multica 创始人张佳圆的对话实录。

快问快答

🚥 十字路口

年龄？  

👦🏻 张佳圆

30

🚥 十字路口

MBTI 和星座？

👦🏻 张佳圆

INTJ + 处女座

🚥 十字路口

一句话介绍你的编程启蒙？  

👦🏻 张佳圆

初中开始自学编程（大概 15 年前），最初是为了给某学习机编写游戏，接触的第一门编程语言是 BBK Basic。

🚥 十字路口

一句话介绍你现在的公司和产品？  

👦🏻 张佳圆

Multica 是一个让人和 AI Agent 在同一个工作空间里协同工作的平台——Where humans and AI agents work as one team.

🚥 十字路口

融资情况？  

👦🏻 张佳圆

已完成两轮融资，老股东是头部美元基金，即将开启新一轮融资。

🚥 十字路口

商业化情况？

👦🏻 张佳圆

产品还没商业化。计划今年 5 月尝试商业化。

🚥 十字路口

团队规模？ 

👦🏻 张佳圆

4 个真人 + 十几个不同的 Agent 一起工作。

🚥 十字路口

一句话介绍创业前在做什么？

👦🏻 张佳圆

创业之前在 TikTok，上一个产品是 DevvAI（AI 搜索引擎 + AI Coding），近百万级的开发者使用过。

带着一点浪漫的命名

🚥 十字路口

Multica 项目是什么时候正式启动的？

👦🏻 张佳圆

其实只有不到4个月。Multica 诞生的时间线，大致是这样的：

2026 年 1 月：想法第一次出现在 journal 里。当时我们还在想“做一个更好的本地 Coding Agent”。

2026 年 2 月：我们开始做第一版原型，延续本地 Agent 的思路。

2026 年 2 月下旬 - 3 月：团队内部自己先使用起来，但是却撞到了两个痛点——Context 孤岛 + 多 Agent 管理问题。于是，我们做了一次小的方向调整，从“单人本地 Agent”转向“多人多 Agent 的协作平台”。

2026 年 4 月 1 日：新产品在个人账号上小范围上线，到现在差不多 2.5 周。

2026 年 4 月底：我们计划做一次正式的全球发布。

🚥 十字路口

“多人多 Agent 协作”这个idea，是怎么诞生的？

👦🏻 张佳圆

有一周，我们同时在推进三个相对独立的功能。按以前的模式，我会打开本地的 Claude Code，开 3-5 个 session 轮流跟 Agent 对话，写完一个 review 一个。

但问题是，当某个功能需要另一位同事的产品判断时，整个协作链条就断了，我必须把 Agent 的对话记录截图发到飞书，同事看完回我，然后我再把反馈粘贴回本地 terminal，Agent 再继续……

一个很小的协作动作，能打断我 20 分钟。

当时我们就想：为什么 Agent 的协作空间是孤立的本地终端，而人的协作空间是飞书或 Linear？有没有可能，把它们统一到同一个空间里？

于是，顺着这个思路，我们做了 Multica 的第一版原型——一个像 Linear 那样的看板，但参与者同时包括人和 Agent。

我们团队用了一周后，意识到这不只是“把两个协作空间合并”的效率优化，实际上，它彻底改变了任务分派的形态：

从“人驱动 Agent”变成了“批量创建 Issue → Agent 自主执行 → 完成后人 review 决策”。

下面这张图很直观，是我们内部开发 Multica 的任务看板。

Agent 在同时处理 20+ 任务，另外还有 60+ 任务已经处理完毕、等待下一步 review 或决策：

🚥 十字路口

你当时怎么确定那是一个合适的Timing？你看到了什么别人没看到的机会？

👦🏻 张佳圆

在启动 Multica 之前，我们已经在 AI 编程工具领域做了3年多：从最早的 DevvAI，到后来的 Devv Code，一路迭代过来，我们对这个领域的演进有比较强的“手感”。

让我觉得“是对的timing”的判断，来自这两件事的交汇：

第一，模型能力到了拐点。

Coding 相关的 benchmark 持续被拉高，本地 Coding Agent 已经能做到让工程师不用关心代码细节、只 review 最终结果的程度。

这意味着，“Human in the Loop”可以被进一步压缩，从“多轮对话”走向“直接分派任务”。

第二，我们在自己的实践中撞到了很多具体的痛点。

当团队每个人都在用本地 Coding Agent 之后，瓶颈已经明确从“单人效率”变成了“团队协作”。 我们判断，下一个阶段真正的主场已经来了——从本地 Agent 到“多人 + 多 Agent”。

🚥 十字路口

为什么取名 Multica？

👦🏻 张佳圆

我们的命名和产品定位是同步想清楚的。

Multica 的名字，藏着我们产品的一点小小的浪漫，它来源于操作系统的演进史：

Multics（1964）——全称 Multiplexed Information and Computing Service（多路复用的信息和计算服务），由 MIT、贝尔实验室等联合开发，是最早的分时操作系统之一，但最终项目没做成。

Unix（1969）——Multics 团队的 Ken Thompson 和 Dennis Ritchie 从中吸取经验，做出了一个更精简的版本。Unix 这个名字本身就是对 Multics 的双关戏谑——把“Multi”换成了“Uni”。Unix 之后几乎成了所有主流操作系统的鼻祖：Linux、FreeBSD、macOS、iOS、Android 皆源于此。

Multica（2026）——我们把 Multics 中的 Service 换成 Agent，寓意从“多路复用的计算服务”进化为“多路复用的智能体协作”。

大部分人知道 Linux，但不一定知道 Multics。如果你了解操作系统的完整历史，你就理解这个名字背后的致敬。

“4个真人+ 十几个Agent”，他们的一天

🚥 十字路口

满足“多人多 Agent”的产品形态具体是怎么设计的？

👦🏻 张佳圆

Multica 的产品形态是看板式界面，类似 Linear 或 Jira，但参与者同时包含人和 Agent。

它的运行核心包含四个概念：

Agent Runtime（运行时）——把本地的 Agent 运行环境注册到平台。

我们不单独做另一个 Agent，而是接入用户现有的 Agent。目前，已支持 Claude Code、Codex、OpenClaw、Cursor、Hermes Agent 等。

你现在用什么 Agent，就可以在 Multica 里继续用它。我们团队注册了多台机器（个人电脑、Mac mini 等），每台机器上的 Agent 都作为 Runtime 被调用。

Agent Profile（角色）——基于 Runtime 创建的具体角色。

每个 Agent 相当于一个 AI 员工，有自己的记忆、Skills，能自我迭代，可以定义角色和 Instructions。

现在，我们内部还在探索更细分的分工，比如专门做开发的 vs. 专门做 GTM 的。

Issue（任务单元）——创建 Issue → 分配给 Agent 或人 → 执行 → 完成后通知相关方 review。

而且，Issue 内可以 @ 其他团队成员（人或 Agent）实现多方协作。

Inbox（收件箱）——聚合所有需要个人关注的事项。

我们每天只需看 Inbox，点进去就能看到完整上下文，不用在多个工具之间切换。

通常，一个 5-10 人团队的典型流程会是：周会确定本周目标 → Agent 批量创建 Issue → 部分直接 assign 给 Agent、部分分配给人 → Agent 自动执行 → 完成后 @ 相关人 review → 人在同一个 Issue 里直接给反馈 → Agent 根据反馈迭代。

整个过程，所有 context 都在一个地方，不需要在飞书、本地终端、项目管理工具之间来回切换。

🚥 十字路口

你们团队内部，一天之中，Agent 是如何工作的？

👦🏻 张佳圆

Multica 已经渗透到每一个时间点上，比较典型的一天通常是这样的：

早晨：Research Agent 准时发送一篇 AI / Agent 行业日报，梳理并分析过去 24 小时内值得关注的内容。同时数据分析 Agent 产出昨天的数据分析报告——如果发现某个核心指标异常（比如某个功能上线后激活率下降），它会自动创建一个修复 Issue 并 assign 给对应的决策人。

白天：GitHub Agent 持续 review 所有新收到的外部 Issue 和 PR——bug 类自动分析根因，feature 类对齐内部 roadmap 判断是否接受，并把确认要做的事情转化为 workspace 里的内部 Issue。每位同事各自的 Coding Agent 按计划推进任务，中间可能在 Issue 里展开讨论、@ 其他同事或 Agent 一起拍板。

代码产出后：Code Review Agent 对每一段代码先做初审，再交给人做最终确认。

傍晚 6 点：Deploy Agent 定时触发——自动测试当天所有提交的代码、打包 web 和 desktop 版本、发布到线上，最后更新 changelog 并同步上线。

🚥 十字路口

人在做什么？

👦🏻 张佳圆

最终决策。比如：

•参与并指导 Agent 该怎么做事（或者让 Agent 自己去发现应该怎么做）

•对需要拍板的事情排优先级

•对最终产出质量把关

•日常主要盯着 Multica Inbox——它相当于每个人的“邮件收件箱”，所有需要我关注的东西都会聚合在这里。

要强调的一点是，每一个 Agent 都在给人提供决策材料，所有材料的沉淀和讨论，都会在同一个 Issue 里留痕。当一个月后，如果要回顾“当时为什么做这个决定”，直接打开这个 Issue 就能看到完整上下文。

🚥 十字路口

这种“多人多 Agent 协作”，使用下来，你最大的一个感受是什么？

👦🏻 张佳圆

我最核心的感受一个是：我们更像是在“经营一支团队”，而不是在“使用一个工具”。

Agent 变成了主动发起工作的角色，而不是被动等待指令的工具。

以前用本地 Coding Agent，我打开终端它才开始干活；现在打开 Multica Inbox，通常已经有一堆 Agent 做完的事情在等我 review。

我想分享一个让 Agent 值夜班的小故事。

前两周，有一天凌晨两点，我躺在床上突然想改一个产品交互的细节。放在以前，这种灵感要么第二天早上起来忘掉，要么得爬起来开电脑亲自动手。

这次，我直接在 Multica 里建了一个 Issue、assign 给 Agent，然后就睡觉了。早上起来打开 Inbox，PR 已经建好、跑完了测试等我 review——确认没问题合并上线就完事了。

这种“让 Agent 值夜班”的体验，是本地 Agent 模式给不了的。因为本地 Agent 需要人一直守着终端。

🚥 十字路口

很多团队最自然的做法，其实是先把 Agent 接进 Slack 里。但你们为什么觉得这还不够？已经在 Slack 里和 Agent 协作的团队，切到 Multica 之后，最先感受到的变化会是什么？

👦🏻 张佳圆

Slack 接 Agent 确实是当下最自然的切入点，但这不是我们想做的形态。

可以设想一下 6 个月、一年、甚至更远之后的协作形态：

一个团队里，可能是几个人 + 几十、几百，乃至上千个 Agent；同一时刻并行推进的任务，可能有数百个。

在这个数量级下，IM 这种范式会很快崩掉。

一方面，人的带宽和注意力完全不够，消息流是天然抢占注意力的设计，无法承载这种规模的并行；另一方面，当一个频道里同时跑着几百条任务的上下文，频道本身就会变成噪音，Context 会彻底混乱——

Agent 之间的协作、人与 Agent 的协作、人与人的讨论，全部挤在同一条时间线里，根本无法分辨。

这也是我们没有第一时间选择 IM 形态的原因。

我认为Slack / 飞书接 Agent 会是一种中间过渡形态——它能让更多人以最低门槛先跑起来，但它并不是终局。

长期来看，一定会回归到以任务为中心的分派模式。

不是因为看板比 IM"更好"，而是因为只有这种形态，才能真正承载大规模人与 Agent 的并行协作。这是 Multica 想提前押注的位置。

人，是 AI 团队里最慢的那个节点

🚥 十字路口

最近一周用户量暴涨，分享一下真实的使用情况？

👦🏻 张佳圆

先上一组数据，让体感有个坐标系。

对比最近两周的周环比（WoW）：

最近这周，我们团队全部都在高强度执行。

做产品迭代。每天保持几十项产品更新、bug fix 和优化，具体可以看 multica.ai/changelog。

做开源社区建设。过去两周， GitHub 上增长非常快，本周（4.13-4.18）我们占了 GitHub Trending 第 4 名；顺便提一句，排在 Trending 第 1 的也是我们的项目。

做用户沟通。我们持续和早期用户一对一聊，收集反馈并快速转化为产品改动。

我想强调的一点是，GTM——目前完全是自然增长，没有投流，靠产品本身 + 开源社区

🚥 十字路口

这个成绩单验证了什么？你从中发现了什么新的信号？

👦🏻 张佳圆

这里最关键的信号，其实不是“涨了多少”，而是一个分层：用户数是线性增长，但 Issue 和 Agent 任务数是指数级增长。

这说明，每个用户在使用过程中，对 Agent 的依赖在快速加深，使用场景从“试试看”变成了“日常工作流”。

而且，从平台上跑的 Agent provider 来看，Codex、Claude、Hermes、Gemini、OpenCode、OpenClaw、Copilot 等，也都有真实的负载占比。

这也印证了，我们“不做 Agent、做 Agent 协作层”的定位。用户带什么模型进来都能跑，我们不和任何一家 Agent 厂商正面竞争，他们能力越强，我们的价值就越大。

🚥 十字路口

你们还有什么新的发现？

👦🏻 张佳圆

主要有三个。

第一，信任 Agent 是有过程的。刚从“个人 Agent”模式切换到“Multica Agent Team”模式的时候，我们自己也会不放心，担心 AI 产出的质量不够好，不敢真的把任务完全放手。

但当我们把周边的基础设施一件件补齐之后，让 Agent 自动 code review、让它跑集成测试、给每个 task 配隔离环境，我们发现， Agent 其实能很好地完成任务。

另外，真正决定 Agent 能力上限的，不是模型本身，而是你围绕它建起来的那套 harness。

第二，一个可能会刺痛很多人、也是我们过去两周最深的一个体感：人，是 AI 团队里最慢的那个节点。换句话说，人的注意力依然是整个系统的瓶颈。

现在我们团队里的 Agent 其实很多时候处于 Idle（待机）状态。因为每个任务的最终决策权，还在人手里，Agent 完成任务后必须等人来 review、给反馈，才能进入下一个循环。

Multica 正在把这个瓶颈逐渐降低，通过批量分派、异步 review、Inbox 聚合等机制，让一个人能同时管理更多 Agent。

我有一个比较强烈的预感：未来衡量一个 AI Native 组织效率的核心指标，可能会是 “Agent Idle 率”。Idle 率越低，说明这个组织把 Agent 的产能利用得越充分，也意味着它越“AI Native”。

第三，真的不需要那么多人。

在 AI Native 的组织形态里，人力不再是扩张的必需品。相反，每多一个人都会增加沟通成本、摊薄 Agent 的执行效率。

这是我们过去两周最直接、也最强烈的体感。

真人的不可替代性，是什么？

🚥 十字路口

这种重度依赖 AI 的研发模式，你会担心思维能力被“外包”吗？

👦🏻 张佳圆

这是一个我们内部非常认真讨论过的问题，我分两个层面谈谈。

首先，工程师的“工作重心”，正在迁移。

在 AI Native 的团队里，工程师花在“写代码”上的时间在快速下降，取而代之的是花更多时间在这三件事上：

第一，定义问题。把模糊需求拆解成 Agent 能独立执行的 Issue， 是一门新手艺。好的 Issue 描述，决定了一半的产出质量。

第二，Review 和判断。Agent 能快速产出 5 个方案，但哪个方案在架构上更可持续、哪个方案对未来的演进更友好，仍然需要人的判断。

第三，架构和品味。代码细节可以交给 Agent，但整体架构、API 设计、产品手感这些“high level taste”也在变得更重要，它们是 Agent 自主执行的“地基”。

所以，关于“思维外包”，低层次的重复思考——比如“这段代码应该怎么写”、“这个 API 的参数怎么排”——这些外包给 Agent， 非但不会让人变笨，反而能把精力释放出来。

而另一层高层次的判断与品味，比如“这个产品应该服务谁”、“这个架构 3 年后会怎么样”，这些并不能外包，而且反而因为 Agent 的存在，变得更加稀缺和关键。

总结来说，在一个什么都可以被 Agent 做掉的时代，人的品味和判断，反而是价值的最终锚点。这也是我们Multica“最不可被复制的东西”。

🚥 十字路口

Multica 现在有多少人？

👦🏻 张佳圆

我们目前是 4 个真人 + 十几个 Agent 的团队。

我们内部习惯把 Agent 也算作“同事”。所以，从人 + Agent 的视角，也可以说是一个 20 人的团队。

这也是我们对 AI Native 组织形态的一种实验。

代码可复刻，但这三样不能

🚥 十字路口

哪些产品会被你列入竞争对手？Multica 和它们的区别是什么？

👦🏻 张佳圆

这个赛道的玩家，现在大致有几类：

首先，Devin / Factory 这类“云端 Agent 平台”。他们走的是“自己做最强的 Agent、端到端云端执行”的路线。

其次，Cursor / Claude Code 这类“本地 Agent + 轻协作”平台，他们未来很可能在现有基础上扩展出团队协作能力。

第三类，传统项目管理工具（Linear / Jira）+ AI 插件。他们可能从另一端切入，给既有工作流加上 Agent。

Multica 和它们的本质区别，我认为在两个层面：

第一，Agent 策略上。

我们不做另一个 Agent，而是做“Agent 的协作层”，我们不与模型厂商 / Agent 厂商正面竞争。

你现在用的是 Claude Code 还是 Codex 并不重要，Multica 是让它们能够在一个团队工作空间里被调度、协作、留痕的平台。

第二，协作单元上。

我们从Day 1 就是为“多人 + 多 Agent”设计的。本地 Agent 工具天然以单人为中心，要“扩展出”多人协作会面临很多根本性的重构；而我们从看板、Issue、Inbox 的架构出发，天然就是团队视角。

🚥 十字路口

Cursor、Claude Code 大概率会推出类似功能。在这样的明牌赛道创业，Multica 最不可被复制的部分是什么？

👦🏻 张佳圆

我此前写过一篇文章专门讨论这个问题。

在 AI 时代，代码本身不再是护城河，任何一个 feature 都可能被 Agent 在一天内复刻出来。

每天，我们在团队里问自己的核心问题是：在你的产品中，什么东西是不可被短时间复刻的？

我们的答案是这三个壁垒：

1. 品味（Taste）与判断（Judgment）

品味是时间复利的积累。它由你过去看到的、读到的、认知和审美全部组合而成；判断，是基于认知做出的选择。这两者，都无法被一个 PR 复刻。

举一个 Multica 自身的例子：我们的产品设计语言用的是 Issue / Inbox / Profile，而不是行业里 AI Coding 工具更常用的 Chat / Code。

这个选择背后是一个判断——我们认为未来的 AI 产品形态应该向“团队协作工具”收敛，而不是向“IDE”收敛。

判断不一定对，但它是由“我们相信什么”决定的。

2. 数据（Data）

Workspace 会随团队使用不断积累 context：沟通记录、决策过程、项目知识、Agent 的记忆和 Skills，这些 context 会产生使用惯性（switching cost），迁移成本极高。

随时间积累，数据壁垒会增强，先发优势也会更明显。

3. 分发与入口（Distribution）

我们的目标是，让 Multica 成为 AI Native 小团队的原生 Agent 平台。

其中，开源是关键策略。我们的代码完全开源，想复刻的团队可以直接 fork。但产品本身不是壁垒，分发才是。

🚥 十字路口

你们考虑过哪些商业化路径？

👦🏻 张佳圆

计划 2026 年 5 月开始初步尝试商业化。核心逻辑是：平台免费 + 云端算力收费。

用一个更直观的比喻：这有点像“自带食材免费用厨房，想用餐厅的预制菜另付费”——

•你可以把自己已经在付费订阅的 Claude Code、Codex、Cursor 等 Agent 接入 Multica，在平台上统一管理团队任务、协作留痕（这部分完全免费）。

•如果某些任务你希望直接用 Multica 自己托管的云端 Agent 来执行（不用占本地机器、不用配置环境、可以 7x24 运行），这部分会按 Token 消耗计费。

我们只在你真正使用云端算力时收费，不在协作平台本身收费。这也是我们“做协作层而不是做 Agent”的基本定位。

🚥 十字路口

目前的融资进度？

👦🏻 张佳圆

此前已完成两轮融资，老股东是头部美元基金。

我们预计新一轮融资，将在 5 月初开启。主要用于扩大云端 Agent 的算力基建，以及开源社区的建设。

🚥 十字路口

你如何判断 AI 编程工具市场的空间和机遇？

👦🏻 张佳圆

我把 Coding 工具的演进分成四个阶段，核心变量是人类介入程度（Human in the Loop）的逐步降低，当前正处于阶段三到阶段四的过渡期。

阶段一：代码补全（GitHub Copilot）。AI 辅助补全片段，大部分代码仍由工程师手写，人工介入极高

阶段二：AI 编辑器（Cursor）。通过 sidebar 交互，AI 可以写大段代码，但人需要持续引导

阶段三：本地 Coding Agent（Claude Code / Codex）。根据需求自主完成复杂任务，人只需 review 结果，人工介入中低

阶段四：任务分派器（Multica 聚焦）。直接分派任务给 Agent，Agent 完全自主执行，无需多轮 chat，人工介入极低。

趋势是清楚的：人工介入会持续降低，最终的工作形态就是“分派任务、等结果”。接下来，真正的瓶颈会从“Agent 能不能完成任务”转移到“团队怎么高效地组织多个 Agent 一起工作”。

这也正是 Multica 切入的时机。

我们站在历史的节点上

🚥 十字路口

最后，你希望 Multica 能给这个世界留下的最持久的印记是什么？

👦🏻 张佳圆

我们没那么在乎结果。

回到 Multica 这个名字本身——我们致敬的是 Multics，一个最终失败但启发了整个 Unix 世界的操作系统。从 Multics 到 Unix，人类用了 5 年时间找到了“多人、多任务”计算的正确形态，之后的半个世纪，几乎所有软件都运行在这个范式之上。

我相信，今天我们正站在一个类似的节点上：AI Agent 会重塑团队协作的基本形态，未来的软件团队一定不是“几个人用工具”，而是“人和 Agent 作为平等的协作者共同完成工作”。

Multica 想做的事情，就是为这个未来形态提供第一版答案。

即使最终， Multica 没能成为那个被记住的名字，也没关系——

只要 50 年后有人回头看这段历史，能把 Multica 和 Multics 并列地提起一次——说，嗯，那个时代有过一些早期的尝试……我们就已经做到了想做的事。

文章来自于微信公众号 "十字路口Crossing"，作者 "十字路口Crossing"