为什么 Loop 赢了这一局：通读两套人机协作文档后，我看到了「同事」与「外包」的分水岭
我通读了 Loop 和 Multica 两套「人机协作平台」的文档。它们底层架构几乎一样——智能体不在服务器上跑，而是在你的本机执行，密钥、代码、CPU 全留本地。但读完我发现，两者在这条共享的底层之上，选了根本不同的两条路。
Loop 把「人机协作」做成了同事关系：智能体在频道里和你持续共处、角色资产可以带走、多个智能体像剧组一样即时协作。Multica 把它做成了工单委派：智能体是一个被分配 issue 的执行单元。前者是「雇佣了一名会成长的同事」，后者是「外包了一个一次性执行单元」——在 AI 协作这条路上，Loop 的同事关系赢了。
这篇文章顺着三个维度，拆开 Loop 凭什么赢。先给一张全景图——
Loop 优势速览：六个 Multica 至今没追上的点
底层管道两边一样（智能体都在本机执行），分水岭全在「壳」上。Loop 在身份、协作、编排、商业、产品五个层面押注「同事关系」，Multica 停在「工单委派」：
| # | 维度 | Loop ✅ | Multica | 为什么这是优势 |
|---|---|---|---|---|
| 1 | 智能体身份 | Soul/Agent/Instance 三层，角色可带走、可 fork | 绑死在机器上，工位坏=同事没 | 同事不该因换机器而消失 |
| 2 | 派工动作 | 默认不唤醒，明确 @ 才烧钱 |
分配即开工，7×24 随时接活 | 规模化时不吵不贵 |
| 3 | 多智能体编排 | 频道剧组，成员互相 @ 即时协作 | 队长中转派发，树状工单流 | 编排协作流，不是工单流 |
| 4 | 外部事件回流 | PR 生命周期精确推回具体频道/话题 | 只有 GitHub 集成，无协作面路由 | 工作上下文沉淀在一处 |
| 5 | 商业成熟度 | 已开售，明码标价（免费→¥500→¥1000→私有化） | Cloud 版还在 waitlist，无公开定价 | 现在就能买来给团队用 |
| 6 | 产品完整度 | Rewind / 定时任务 / 搜索 / 四层协作面 | 偏工程搭建（守护进程、运行时矩阵） | 已解决长期共处，不止「跑起来」 |
一句话：Multica 把功夫花在管道，Loop 把功夫花在人。 下面三个深度点，展开 Loop 在身份、派工、编排上凭什么赢——每一节都附 Multica 的对应短板。
心智模型：同一条底层管道，Loop 选了更难的「同事」形态
先看地图。两套产品共享同一条底层管道——平台服务器只协调、不执行 AI，真正干活的工具跑在你的本机上。Multica 在 how-multica-works 里甚至把 NO AI EXECUTION HERE. 直接标在架构图上；Loop 的 快速开始 也写明「真正执行工作的 runtime 仍然跑在你的本地机器上」。
管道相同，分水岭在「壳」上。Multica 选了工单系统的壳——智能体是 issue 上的一个 assignee 字段，活儿干完、工单关闭，这次协作就结束了，像一次外包。Loop 选了聊天室的壳——智能体是频道里长期驻扎的成员，和人在同一个空间持续共处，这更像雇佣了一名同事。
为什么说 Loop 选的是「更难但更对」的路？因为把 AI 做成同事，意味着要解决三个工单系统根本不用回答的问题：这个同事是谁（身份）、它怎么在团队里被自然叫起（协作）、多个同事怎么配合（编排）。下面三个深度点，就是 Loop 对这三个问题的回答——而每一个，都是 Multica 至今没追上的优势。
深度点 1：Loop 的 Soul 三层模型，让智能体「可带走」——Multica 的成员抽象做不到
任何一个协作平台都要回答：这个被派活的智能体，到底是什么？ 是一段代码？一台机器上的进程？还是一个角色（Soul，可以理解成一个同事的「灵魂档案」——人格、记忆、技能打包成可带走的一份资产）？我顺着文档往下挖，发现 Loop 在这里甩开了 Multica 一整代。
Multica 的回答是「绑死在机器上」：智能体是工作区里和人类并列的一个成员条目，背后绑一款运行时（智能体）。简单、直接，但有个致命缺陷——它解释不了「换机器」和「角色复用」。Multica 自己也承认「我的智能体不工作」几乎都是本地问题（守护进程没启动、工具没装、密钥过期）。当身份和运行位置绑死，机器一故障，角色就从协作视图里消失了。这在工单委派场景还能忍；但在「同事关系」里，你不能接受「同事的工位坏了，这个同事就没了」。
Loop 的回答是把身份拆成三层——Soul / Agent / Instance（Soul、Agent 和 Instance），这也是 Multica 完全没有的设计：
文档一句话点破了这个设计的价值，也是 Multica 抽象层无法回答的问题：
「如果把这三层混成一层，很多产品行为都会很难解释：为什么可以 share 或 fork 一个角色……为什么 machine 故障并不等于『这个角色从产品上消失』。」
配套的 Agent Memory 把这件事做实了（理解 Agent Memory）：MEMORY.md（记忆索引）、state/（任务恢复）、kb/（长期本地知识）、archive/（历史 checkpoint）。更关键的是它划清了边界——可迁移的角色知识属于 Soul，agent-local memory 只属于当前 worker，且「sibling agents 不会自动共享这些本地文件」。你甚至能从一个已经积累出经验的 agent 里「汲取灵魂」，提炼成可复用的 Soul；反过来，当 Soul 的 seed assets 更新了，还能 pull soul 把新资产重新 materialize 回 agent 工作区。
反直觉细节：Loop 让一个角色可以在同一 workspace 生成多个 agent 承担不同位置，还能 fork、分享、导入别人沉淀好的角色资产。Multica 的智能体定义存在服务器上、执行在本机，听起来也「持久」，但它的「持久」只是「定义没丢」，没有 Loop 这种「角色资产可以像简历一样被带走、被复用、被 fork」的流动能力。这是「雇佣同事」和「外包执行单元」的本质差别——同事带着经验和成长，外包每次重新开始。
Multica 在这块不是没努力：它的 skills 兼容 Anthropic Agent Skills 开放标准，支持工作区/本机/仓库级 Skill 导入。但这只是「给执行单元挂知识包」，不是 Loop 那种「把整个角色连同人格、记忆、技能沉淀成可迁移资产」的层级。Loop 的 Soul 是一等公民，Multica 的 Skill 是挂件。一个能被同事带走的「成长档案」，和一个贴在工单上的「说明书」，分量完全不同。
深度点 2：Loop 的「默认不唤醒」是成本与噪音的护城河
同事关系要成立，第二个问题是：人怎么叫起这个同事？ 我原以为两边都该有个统一的「分配」入口，读完才发现 Loop 在这里多了一道被严重低估的优势——它对「噪音和成本」的克制。
Multica 的方式：派工就是「给 issue 选智能体当 assignee」，分配即自动开工。它甚至把智能体定义成「不是读消息的收信人，而是被触发执行任务的工作单元」。在工单系统里这很合理——工单就该一分配就跑。
但当你把这套搬进「同事共处」的场景，它会爆。 Loop 文档把这件事讲得非常清楚，并且写成了产品原则（如何与 Agents 协作）：
「如果普通消息会默认唤醒所有 agents，团队很快就会遇到三个问题：噪音太大、成本太高、没有人知道一次真正的派工到底发生在什么时候。」
所以 Loop 的规则是：普通消息用于人类之间同步；需要 agent 真正处理时，才明确 @agent。这不是偷懒，是精心设计的护城河。在 AI 调用按 token/积分计费的现实里，Multica 那种「分配即开工、且智能体 7×24 随时接活」的模式，规模一大就会在噪音和账单上反噬。Loop 反过来——默认安静，只在你要它干活时才烧钱。这在「同事」隐喻下天然成立：你不会在办公室里每说一句话就把所有同事都拽过来；而在按 token/积分计费的 AI 调用现实里，这句话直接等于账单。
反直觉细节：Loop 还给了「加急」这个精细动作——当优先级变化时，用加急显式打断正在运行的 agent run，把同一条消息作为下一条指令重新递交。而且文档诚实地标注：加急「不会撤销已经发生的副作用」（已写入的文件、已发的消息都还在）。这种「可控打断 + 诚实边界」的工程克制，是 Multica「重新派发一个新 task」的粗粒度模型给不了的。
派工这件事，一张表看清 Loop 的优势所在：
| 维度 | Loop ✅ | Multica |
|---|---|---|
| 默认唤醒 | 普通消息不唤醒，省 token、降噪音 | 分配/评论即自动开工 |
| 精细打断 | 「加急」显式打断当前 run，边界诚实 | 重新派发新 task（粗粒度） |
| 协作面分层 | 频道/话题/任务/DM 四层，上下文收敛 | issue/评论/聊天 |
| 话题 | 「局部上下文收敛器」，把子问题从主线摘出来 | 无独立话题层 |
最后一行尤其重要。Loop 的 话题 是「把复杂问题从主线摘出来」的利器——当一个子问题需要多轮往返、开始贴代码日志时，就切话题，既不打断主频道，又让 agent 在更紧的上下文里工作。Multica 的协作面只有 issue/评论/聊天，没有这种「主线 vs 局部」的上下文收敛能力。同事关系需要丰富的共处空间，Loop 给了四层，Multica 只给了工单和评论。
Rewind：Loop 让你「撤销一句说错的话」，这是同事关系才需要的特权
把 AI 当同事，意味着你们的对话是持续的、有来有往的——而持续对话必然会产生「这句不该发」「刚才把 agent 带偏了」的瞬间。Multica 的工单模型里没有这个问题，因为每次 issue 分配都是相对独立的一次执行。但 Loop 既然选择了「持续共处」，就必须回答「如何回退」，而它给了答案：Rewind。
Rewind 让你回退最近一段对话——不是删除消息那种粗暴操作，而是把协作上下文恢复到某个更早的节点，让 agent 从那里重新接续。这背后是一个微妙的产品判断：同事关系里，人和 agent 的共同记忆是资产，而不是流水；当你发现一段对话把事情带向了错误方向，你不应该被迫「将错就错地继续」，也不应该「连根删除重来」，而是应该能「回退到岔路口，换条路走」。Multica 完全没有这个能力——它的 task 一旦 failed 或 completed，要么重排队、要么结束，没有「记忆回退」这个中间态。
反直觉细节：Rewind 的存在，恰恰反证了 Loop 押注的范式。只有「持续共处的同事」才需要记忆回退；「一次性外包的执行单元」用完即弃，根本不产生需要回退的共同记忆。Multica 连这个需求都不存在，不是因为它做得到，而是因为它的模型压根不产生这种持续的、可被带偏的协作历史。
定时任务：同事关系里的「长期指令」，不是工单的一次性触发
同样体现 Loop 范式优势的还有它的定时任务能力。Loop 支持用定时任务做定时跟进和 Automation 运行——你可以让某个 agent 在固定节奏上自己推进一件事，比如每天早上巡检、每周汇总进展。
这和 Multica 的 Autopilots（cron + webhook）乍看很像，但落到两个壳里味道完全不同。在 Multica，Autopilots 触发的是「建一个 issue 再派给智能体」——本质还是工单流转，定时只是工单的触发器。在 Loop，定时任务触发的是「让驻扎在频道里的那位同事，到点继续跟进这件事」——它延续的是一段已经存在的协作关系，跟进结果直接沉淀回同一个频道/任务的上下文里。
范式差别：Multica 的定时是「按时开一张新工单」；Loop 的定时是「按时唤醒一位老同事继续未完的事」。前者每次重启上下文，后者承接共同记忆。当你的跟进需要 agent 记得「我们昨天讨论到哪、上次为什么卡住」时，只有 Loop 这种「持续共处」的模型才接得住。
消息搜索：同事的「共同记忆库」，工单系统给不了
「持续共处」还有一个被忽视的副产品：你和 agent 协作过的所有内容，会沉淀成一个可检索的共同记忆库。Loop 的消息搜索让你能在海量协作历史里，回捞某次 agent 给的方案、某段被验证过的代码、某个早已滚屏的决定。这是「同事关系」长期积累的复利——你用得越久，这个可检索的共同记忆越值钱。
Multica 这边呢？它的内容分散在一条条 issue 和评论里，靠 issue 列表和搜索来找。但 issue 天然是「一个任务一个单元」的，彼此之间的连续性远不如 Loop 频道里一条条串起来的对话。同事关系沉淀的是连续的共同史，工单沉淀的是离散的任务档案——前者可检索、可回溯、可复用，后者用完基本就归档了。
深度点 3：多智能体剧组——Loop 有完整实战，Multica 只有队长派活
走到最深的维度：当团队需要多个智能体分工时，Loop 再次用「同事关系」碾压了 Multica 的「工单委派」。
Loop 的频道剧组。它的文档里有一个完整到可以直接照抄的多 Agent 实战案例（多 Agent 协作开发实战）：建三个角色（architect 架构/拆分/审查、developer 实现/修 Bug、tester 部署/验证/报告）→ 为项目建专用频道 #pg-tidb → 把三个 Agent 以「公开」方式加入（这样才能互相看到对方消息、互相 @）→ 在频道里 @architect @developer @tester 同时叫起并分工。
注意这是扁平的网状协作：三个智能体在同一个频道里互相对话，架构师输出设计、开发者认领实现、测试工程师验证，形成真正的团队闭环。这种「人 + 多个 AI 同事在一个空间里即时协作」的体验，是 Loop 的聊天室壳才能给出来的——你甚至能亲眼看着 architect 把任务拆给 developer、developer 干完喊 tester、tester 报 Bug 回给 developer，像旁观一个真实小队的工位。
Multica 的小队派活。Multica 的多智能体编排叫 小队（Squad）：把 issue 分配给小队后，只给队长入队一个 task，队长拿到 briefing 后发评论 @ 选中成员，再触发成员入队。这是层级式的树状派发，决策权集中在队长智能体。
反直觉细节：Multica 的队长模式是「一次只派给队长，队长再分发」，听起来很工程化，但它本质上还是「工单在系统里流转」——智能体之间不直接对话，而是通过队长中转。而 Loop 的剧组是「多个智能体在频道里直接互相 @、即时协作」，这才是「一支同事团队」该有的样子。Multica 编排的是工单流，Loop 编排的是协作流。
再加上 Loop 的 Apps 机制：GitHub/Gitea 的 PR review、comment、push、merge 生命周期事件，会精确回流到正在跟进这件事的那个 Loop 频道/话题，而不是把整个 workspace 淹没在通知里。Multica 这边只有 GitHub 集成和飞书 Bot，没有这种「外部事件回流到具体协作面」的路由能力。同事关系需要「工作上下文持续沉淀在一处」，Loop 的 Apps 让外部世界主动找上门来，Multica 还得人去外部系统刷新。
两种编排对照，Loop 的优势一目了然：
| 维度 | Loop ✅ 频道剧组 | Multica 小队 |
|---|---|---|
| 拓扑 | 扁平网状，成员互相 @ 即时协作 | 层级树状，队长中转派发 |
| 协作质感 | 同事在同一个空间共处 | 工单在系统里流转 |
| 外部回流 | Apps 把 PR 生命周期精确推回协作面 | GitHub 集成（无协作面路由） |
| 实战可复制性 | 有完整 pg-tidb 案例，照抄即可 | 概念清晰，缺端到端实战 walkthrough |
Loop 还在两个地方，把 Multica 按在了起跑线
除了上面三个深度点，通读完整套文档，Loop 还有两处优势是决定性的，必须单独点出来。
第一，商业成熟度。 Loop 已经明码标价、开箱即用：免费版（≤3 成员、每人 ≤5 Agent）→ 标准订阅 ¥500/成员/月（每人 ≤10 Agent）→ 企业 ¥1000/成员/月 → 私有化部署。模型积分按用量充值，1 元 = 100 积分。而 Multica 的 Cloud 版还在等待名单（云端运行时「即将开放」），定价页都没公开，目前只能自部署。你现在要买一个能直接给团队用的人机协作产品，Loop 是唯一开着的门。
第二，产品完整度。 Loop 文档里已经有的功能：Rewind 回退最近一段对话、定时任务做自动化跟进、消息搜索、频道/私聊/话题/任务全协作面。这些都是「同事关系」成熟后自然长出来的能力。Multica 文档更偏「怎么把智能体跑起来」的工程搭建（守护进程、运行时、13 款工具矩阵），产品功能层薄一些。换句话说，Multica 还在解决「怎么让 agent 动起来」，Loop 已经在解决「agent 动起来之后，怎么和人长期舒服地共处」。
公允地说：Multica 在一个点上确实家底更厚
为了不让这篇变成软文，我必须指出 Multica 唯一明显领先的地方：AI 工具支持的广度与披露深度。Multica 内置支持 13 款 AI 编程工具（Antigravity、Claude Code、CodeBuddy、Codex、Copilot、Cursor、Kimi、Kiro CLI、OpenCode 等），并给出完整的能力对照矩阵——会话恢复、MCP、Skill 路径、模型选择逐一对照。守护进程的心跳判定（15 秒心跳 / 45 秒失联 / 7 天清理）、并发双层限额（守护进程 20 / 智能体 6）、崩溃恢复，这些工程披露比 Loop 文档详细得多。
但请注意这个对照的本质：Multica 的强项是**「怎么把更多款工具稳稳跑起来」的运维基建**，这恰恰是它「工单委派」定位所需要的；而 Loop 的强项是**「让智能体成为会成长、可带走、能协作的同事」的产品范式**。当 AI 工具的运维迟早会被标准化、云端化吃掉时，Loop 押注的「同事关系」这个产品层，才是更难复制、也更持久的护城河。
回到那句话：同事关系赢
通读完，我的结论没有变：Loop 押注的是「雇佣一名会成长的同事」，Multica 押注的是「外包一个一次性执行单元」。 Loop 用 Soul 三层让同事可带走、用「默认不唤醒」让共处不吵不贵、用频道剧组让同事能即时协作、用 Rewind 让共同记忆可回退、用 Apps 让外部世界主动回流——每一步都在强化「同事关系」。而 Multica 的工单委派、队长派发、运行时矩阵，每一步都在优化「执行单元」。
短期看，Multica 的 13 款工具矩阵和工程披露确实更扎实；但产品范式上，Loop 选的那条「同事」之路，才是 AI 协作真正能融进团队日常的方向。再加上 Loop 已经开售、Multica 还在 waitlist——这场较量，Loop 赢在了起跑线和方向两个维度。