DeepSeek想给AI配个COO:帮你指挥一群AI助手干活,让我们都学会当管理者

你有没有过这种体验：让一个AI查资料，另一个写代码，再开一个对照数据。任务确实分出去了，但你还得在几个窗口之间来回切，记住每个做到哪一步、要补什么信息。

AI好像在帮忙，自己却多了一份“管理AI”的工作。

近日，DeepSeek Harness团队发布了一篇技术长文，讨论怎么解决这个问题。他们把设想中的系统叫作Super-agent，超级智能体：它能在后台接收任务、安排多个执行单元，并把需要人处理的事情送回来。

这篇是架构设计文章，不是新模型发布，也不是一款人人现在都能直接使用的AI助理。团队说，内部已有相关系统在运行；公开的代码只是研究原型，文章里的部分设计还没有在原型中实现。

但它提出的问题，我觉得很真实：AI越来越能干之后，人不一定缺一个更聪明的聊天框，可能更缺一个不需要时时盯着的工作流程。

DeepSeek团队在文章中提到，按他们自己的经验，一个人通常只能同时跟进三到五个活跃会话。这是团队经验，不是一项证明所有人都如此的测量。

现在常见的做法，是给AI开三个任务，完成一个再点开另一个。AI中途要是问问题，你还得想：它说的是哪件事？我刚才给过它什么资料？

DeepSeek设想的方式更像一位负责接活的协调员。你把事情告诉它，它在后台分别交给处理链接、处理图片、查数据的执行单元。后续有人补充信息，系统尝试把消息送回负责那件事的单元；需要你拍板时，再来找你。

这里有两个英文词，可以顺便记一下：

Router，可以理解成“协调员”：负责接收消息、判断要不要处理、把任务分出去。

Worker，可以理解成“干具体活的助手”：每个Worker处理自己的任务，尽量不让几件事的上下文混在一起。

文章还讨论了Watchdog，也就是在外部检查任务是否卡住的“看护程序”。例如，一个任务反复执行却没有进展，系统可以尝试发现并处理异常。

这些都是团队提出的设计思路，不能理解为你今天下载原型，就能把它们完整用起来。

网上传播时，有个数字很容易让人误会：有人说任务从29.5分钟缩短到了12.4分钟。

这两个数字都出现在原文里，但不能这样直接比较。

29.5分钟是单会话方案里较慢任务的P95，也就是95%的任务完成时间不超过这个数；12.4分钟是Super-agent方案的P50，也就是中位数。一个看慢任务，一个看中间水平，口径不同。

按相同口径看，在团队自己的实验中：

不过，这不是“AI写代码普遍快了多少”的测试。实验每组只跑了5轮，每轮约300条模拟消息，其中约20条是工作请求；“写代码”用一个消耗时间的工具代替，并没有检验真实代码质量。实验图注还说明，消息间隔和模拟工作时长缩短为原来的四分之一，模型调用时间没有缩短。

换句话说，它测到的主要是这套系统如何安排任务，不是证明它编程更厉害。

快也有代价。实验中，Super-agent每轮读取的缓存Token约2320万，普通提示词的单会话方案约610万。Token可以理解为模型处理文字时使用的计量单位；这里比较的是缓存读取量，不能直接换算成总费用，但至少说明：多开执行单元，并不是完全免费的。

看到这里，可能有人会说：让AI后台干活、同时处理任务，这些不是已经有了吗？

是的。DeepSeek并不是第一个想到这些功能的。如果只看“多个助手一起工作”，其他公司也早已在做；区别在于产品入口、适用场景，以及完成到了哪一步。

OpenAI的Codex已经支持把工作交给多个子Agent并行处理，再把结果汇总回来。它更偏向软件开发，也可以通过不同工具处理研究和其他任务；多开助手同样会消耗更多Token。

Anthropic的Claude Tag则更像进入团队聊天群的同事。企业团队授权后，可以在Slack里@Claude，让它调用接入的工具和资料完成任务，再回到对话里答复。它有产品入口，但适用范围和权限取决于账号、配置与开放情况。

谷歌的Gemini Live与Spark则把语音作为入口。按照谷歌介绍，用户可以口头交代任务，让Spark在后台跨Google文档、表格、云端硬盘等工具处理；谷歌表示Spark需要Google AI Pro或更高订阅，能否使用还要看地区和账号条件。

Manus 2.0把重点放在跨应用完成工作。按照官方介绍，连接服务后，新邮件、日历事件或Slack消息等可以触发自动任务；如果需要持续运行，还可以购买Cloud Computer云端环境。

国内也有可对照的开源项目。字节跳动的DeerFlow同样是面向开发者的SuperAgent框架，支持子Agent、工具和隔离执行环境等能力，需要自己部署或集成。

把它们排在一起，最容易忽略的一点是：现成产品、开发者框架和研究原型不是同一种东西。不能因为DeepSeek的设计写得完整，就说它已经比现有产品更强；也不能因为其他公司有类似功能，就说这篇文章没有价值。

DeepSeek的价值，在于把团队实际遇到的组织问题摊开来讲：任务从哪里来、谁接、后续消息怎么找回原来的执行者，什么时候才值得打扰人。

DeepSeek公开的dsh-superagent-prototype原型，目前主要围绕单个GitHub代码仓库工作，也可以选择接入飞书。获得授权的人提出请求后，系统可以建立工作项，在独立会话中处理，再把结果回复到原来的对话。

它主要面向开发者，需要自己配置。仓库明确写着：这是供参考的研究代码，不是官方成熟产品，也不建议未经检查就直接用于生产环境。

至于文章里提到的更广泛的跨设备、长期在线和自动恢复，不能直接等同于公开原型已经全部具备。

还有一个点比速度更重要：权限。

一个能读取群聊、代码和文件的助手，确实可能帮团队省事；可如果它被恶意内容误导，或者接触到不该看到的密钥，也可能把问题带进更多系统。DeepSeek团队自己在文中列出了提示词注入、凭据泄露和跨设备权限等风险，也承认长期记忆和人工中途接管仍需要继续解决。

对我们来说，现阶段不用急着追求一个能读取所有资料的“全能助理”。先选一件低风险、重复发生的事，比如整理公开资料、汇总待办；把任务边界和交付格式说清楚，最后自己检查结果。涉及付款、公开发布、删除文件或客户隐私时，保留人工确认。

如果AI后台忙了半天，最后仍要你逐条翻记录、纠错、收拾权限，那省下来的时间未必比想象中多。一个真正好用的助理，除了能干活，还得让人知道：它做了什么，哪里需要我负责。