DeepSeek Super Agent 设计探索：多 Agent 协作 Multica/Raft 解决了吗？

10 月 31 日，DeepSeek Harness 团队发布了《Super-agent 设计探索：迈向更自主的 Agent 系统》。Harness 可以粗略理解为把模型、工具和任务执行接起来的运行框架。文章讨论的 AI，可以在群聊与代码协作平台 GitHub 之间接着做同一件事，并行处理多项任务，还能在没有人逐条下指令时，观察环境、推进工作。

朋友圈里刚好有一句评论：

multica/raft已经解决了绝大多数所谓super agent立的靶子。好用的，推荐。

这句话很值得追问。假如这些问题早已有产品处理，DeepSeek 这次到底贡献了什么？那些被称为 AI 同事的产品，又走到了哪一步？

先澄清：这里的 Multica 和 Raft 是两个产品。前者偏向人与 Agent 共同使用的任务管理平台，后者偏向人与 Agent 共享的团队协作空间。

作为产品推荐，这条评论很有依据；如果把它进一步理解为长期运行中的工程难题已被解决，现有证据还不够。 三者放在一起看，能看清一个变化：当 AI 能干活以后，越来越多的产品开始处理人要花多少精力管它。

这次对照基于公开产品资料、仓库及原型架构文档，未做三套系统在同一负载下的部署实测。

DeepSeek 这次发布到了哪一步

有一个边界需要先说清楚。

DeepSeek 文章讨论的是工程架构思路。配套的 dsh-superagent-prototype 仓库明确将自己定位为研究原型：它围绕一个 GitHub 仓库工作，可以接收 GitHub 及可选的飞书事件；公开代码经过整理，与内部版本及文章描述并不完全一致，部分设计尚未实现。

因此，读者需要分开看三个对象：文章中的整体构想、团队正在使用的内部实例、外部能够下载的原型。不能把三者的能力直接相加，理解成已经交付的正式产品。

它提出的职责划分很直观：Router（调度层）负责接收消息、协调和派活，Worker（执行层）在独立上下文中执行具体任务。对于已有归属的后续事件，系统可以直接送到相应 Worker，减少反复经过总调度的开销。原文还讨论了执行环境解耦，以及由独立的 Watchdog 巡检会话检查任务有没有实质进展。这些思路见团队文章的全文转载。

把它放进一个具体场景就好理解了。

你在群里提出一个故障，Agent 开始定位；你随后去 GitHub 补充新线索，工作仍归到同一件事；另一位同事同时提出一个新需求，系统另开执行上下文。你不用记住哪个终端窗口里装着哪段历史。

这段场景描述的是架构希望实现的协作体验，并不代表公开原型已完整具备所有能力。

人的工作对象开始从聊天会话，变成能够持续跟踪的任务。 模型每次能记住多少信息，仍然有限；系统需要负责把相关的信息送到正确的执行现场。

Multica 已经把不少事情做成了产品

看 Multica 的官方仓库，能明显感到它在处理同一类烦恼：几种编程 Agent 分散在不同终端，人不断派任务、找记录、转述上下文。

它把工作收进同一个任务空间。Agent 可以作为负责人接手任务单（issue），执行、汇报阻塞，再把结果交回复核；任务意图、执行记录和改动留在一起。Squads 用于组织人与 Agent，Autopilots 承担定时工作，Skills 用来复用经验。

这已经越过了同时打开几个聊天窗口的阶段。

对一个团队来说，最直观的变化是：人可以问某项工作进展如何，而不用先找到当时执行它的那次对话。Agent 换了执行轮次，任务仍然有负责人、有状态、有记录。

它也有一个有意思的定位：调度已有的编程工具。当前官方仓库列出的运行时里就包括 DeepSeek Harness。因此，Multica 与 DeepSeek Harness 之间可以存在上下层组合关系。

从官网的说明看，它还提供运行环境监控和并发配置，连接本地或其他机器上的执行环境。不过，界面能显示在线状态，并不意味着机器离线后，其上的工作还能继续。执行仍依赖相应环境和所接入的编程工具。

所以，朋友圈评论中针对任务管理、执行组织的那部分，确实有现成产品支撑。新名称出现时，已经在做这些事情的项目值得被看见。

Raft 更关心 Agent 怎么进入一个团队

Raft 的产品介绍强调的是另一种体验：每个 Agent 有自己的身份、工作空间和持续记忆，人与 Agent 在频道、话题、私聊和任务里协作。它们可以并行工作、交接任务，也能使用不同的编程运行时。

Multica 的入口更像把任务交给负责人，Raft 的入口更像进入一个已经有人和 Agent 在工作的团队。

这一区别影响了上下文放在哪里。

在纯终端工具里，一项决定可能只活在某次会话中。在共享协作空间里，决定可以留在任务和讨论里，后来加入的人或 Agent 有机会沿着工作历史找回它。这里的重点也包括谁知道哪件事、谁有权看到它、谁接着做。

Raft 的公开源码仓库包含服务端、网页客户端、命令行工具（CLI）、机器上的后台常驻程序（daemon）和开发工具包（SDK）；其中 daemon 负责运行 Agent，并代理其凭据使用。仓库同时说明，这是按版本导出的源码镜像。

这说明它已经在处理持续身份、团队协作和机器执行之间的连接。凭据代理也是具体的工程措施，不能把这类产品简单归为给大模型包一层界面。

不过，官网对持续记忆的介绍，并不能说明这项能力在各种任务中效果如何。它对过期决定的处理、权限变化后的检索行为、跨月任务的记忆准确率，都需要进一步验证。

信息被保存下来，与下一次工作时被正确使用，中间仍隔着一整套工程。

功能相似，为什么还不能说问题解决了

把公开资料中的重合点列出来，朋友圈那条评论就容易判断了。

讨论的问题	Multica 的产品入口	Raft 的产品入口
少切换会话	任务单与执行记录关联	共享频道、话题和任务
组织多个 Agent	任务派发与 Squads	并行工作与交接
保留协作上下文	项目资料、任务历史、Skills	持续身份、记忆与讨论历史
连接执行环境	本地 daemon 与运行时管理	机器 daemon 与多机器协作

这张表依据前述官方资料整理，只比较产品入口，不比较实测效果，也不表示它们采用了同一种底层架构。

重合已经很多。继续争论谁先说出超级 Agent，能带来的信息很少。更值得比较的是，功能在出错、冲突和长期运行时如何表现。

比如下面几件事：

• 群里决定用方案 A，代码评审里又改成方案 B，系统会执行哪个版本？
• 同一个事件被重复投递，会不会多开任务、重复提交改动？
• 进程重启后，是接着原来的工作，还是从头再做一次？
• 命令一直在运行，但半小时没有有效进展，谁会发现？
• Agent 被告知停止后，已经排队的后续事件还会不会把它重新唤醒？

这些是检验系统的情景，不代表某个产品已经出现了相应故障。

它们也解释了为什么系统设计值得单独讨论：展示任务状态很容易让人看懂，定义每一次状态变化何时有效、何时允许恢复、何时必须停下，才决定人能否放心离开。

在 DeepSeek 原型的架构文档里，可以看到一些具体处理：任务有明确的授权依据；只为补充上下文而订阅的话题，不会自动扩大执行权限；启动时恢复被中断的执行；评估、启动 Worker、投递消息等调度动作进入持久化队列，并安排重试。

这些设计提供了可检查的答案，但文档存在本身也不能替代运行验证。队列与重试也不等于每条业务操作都只会执行一次，例如发消息或提交改动，仍需分别处理重复执行。

这里有一个很容易被跳过的区别：任务恢复处理的是工作如何继续，授权处理的是它现在还该不该继续。 一个能重启的 Agent，如果恢复后继续执行已经撤回的要求，反而会给团队添麻烦。

DeepSeek 贡献了什么，也还没有证明什么

DeepSeek 在原文中承认，使用的是经典的计算机系统思想，没有提出全新理论。把它理解为宣称首次发明多 Agent，再用现成产品反驳，就偏离了文章自己的表述。

我的看法是，它的价值在于把几个经常混着讨论的问题拆开：对人保持交互连续，对任务保持执行隔离，对事件明确归属，对运行状态保留恢复机制。

这样的拆分让不同项目之间有了可比较的对象。我们可以问一个产品怎样维持任务连续性，而不必只听它介绍能接多少模型。

同时，原文实验的边界很重要：它用合成消息流测试调度，把编码工作替换为耗时工具。它能为特定条件下的调度设计提供参考，不能用来证明写代码更准确、生产故障更少，更没有直接证明优于 Multica 或 Raft。

因此，目前可以成立的判断有两层。

第一，Multica、Raft 已有的产品能力，足以说明这条路线早已被不同团队探索。

第二，公开资料还不足以给三者排出长期可靠性和人工负担的名次。产品官网、原型代码与调度实验，提供的是不同类型的证据。

谁先做出某个功能，和谁在真实工作中把它做得稳定，是两项需要分别回答的问题。

比 Agent 数量更有用的一个指标

讨论到这里，我更愿意用一个指标理解这些产品的价值：

每件验收通过的任务，消耗了多少人的注意力。

可以把它写成一个便于比较的口径：

单位交付人工负担 = 派活、补上下文、协调纠偏、故障接管和验收所花的总时间 ÷ 验收通过的任务数。

这是本文提出的观察框架，并非行业标准，也尚无对应的实测数据。比较时还需要限定相近的任务难度、质量要求和风险范围，并计入失败任务和返工消耗的人工时间。模型和机器成本则需要另计。

举个假设：

在同一统计时段内，一个系统同时启动十个 Agent，交付并通过验收十项任务，人花了两小时解释背景、解决冲突、检查结果。另一个系统完成并通过验收六项相同难度的任务，人花了二十分钟。

前者每项消耗十二分钟人工，后者约三点三分钟。

哪个更好，要看团队缺什么。如果缺的是人在固定时间内能组织多少工作，后者就可能更有价值；如果赶交付期限，前者较高的总吞吐也有意义。仅凭同时在线的 Agent 数量，看不出这种区别。

这个口径还会暴露一些表面热闹的改进：进度播报变得更密集，但人要频繁检查；后台任务跑得更久，但失败后仍要人重建现场；自动生成的改动更多，但验收和返工也一起增加。

看上去更自主，人的工作量可能没有下降。

反过来，一项不显眼的能力也可能很值钱：旧任务恢复时带回足够的背景，审批请求一次讲清原因，多个执行者遇到冲突时先自行协调，交付时附上能直接复核的证据。每少一次让人重新理解现场，才多一点可用的并行能力。

Agent 多了以后，稀缺的是什么

当然，这个框架也有适用边界。

对一次性的、小而明确的工作，直接打开一个编程助手通常就够了。额外搭建协作平台，可能带来账号、规则、机器和任务状态的维护负担。只有当工作开始长期并行、跨人交接、频繁恢复时，那层组织能力才更容易体现价值。

多 Agent 也未必持续放大产出。任务彼此耦合、验收标准含糊时，增加执行者可能先增加协调量。能把任务分出去，与能把成果收回来，是团队必须一起处理的两件事。

所以，我赞同那条评论提醒大家看见 Multica 和 Raft：它们已经把不少理念做成了可使用的产品。

我也认为，DeepSeek 把自己的架构选择和简化条件公开出来，有助于把讨论推进到更具体的地方。眼下最有价值的比较，应当落在相同工作负载下的交付质量、恢复行为、运行成本和人工投入上。

当 AI 开始批量承担执行，团队稀缺的资源就越来越集中在人如何分配注意力、作出决定和验收成果。 谁能稳定减少这些环节里可省掉的劳动，谁才更接近一个值得长期共事的 AI 同事。