DeepSeek的Super-agent一夜冲上GitHub第一：AI开始替你“派活”了，但我发现它的Token账单涨了3.8倍，还能读你的整个家目录

10月31日晚，DeepSeek Harness团队丢出了一个叫Super-agent的东西。第二天，dsh-superagent-prototype 仓库单日涨星3705，从第22名直接冲到GitHub第一，知乎热榜第二，1500万热度。

它做的事情一句话就能说清：以前是你一个人管三五个Agent会话，现在是一个常驻的Router替你管一群Worker，你只跟Router说话。

p50 12.4分钟、p95 15.7分钟，对比单会话+Subagent方案的p95 29.5分钟。速度确实上去了。

但我翻完仓库的部署文档和几篇实测之后，发现两件事在热度里被轻轻带过了：读缓存Token从605万涨到2323万，大约3.8倍；Router和Worker以你的操作系统账户跑，能读你的home目录。

它和Claude Code的Subagent到底差在哪：一个“同步等”，一个“异步派”

很多人第一眼会觉得Super-agent就是“Claude Code的Agent Teams换个名字”。不是。

Claude Code的Subagent模式，本质是在一个会话里嵌套。主Agent拆出一个子任务，派给Subagent，等它回来，再继续往下走。Lead要拆解单个复杂任务，Subagent在同一个工作流的上下文里干活。这是同步、命令行式的协作。

Super-agent拆的是两层不同的东西。Router是一个长期活着的会话，只跟人打交道、维护全局上下文、派活，它本身不执行具体任务，甚至可以不配Bash工具。Worker是一个任务一个独立会话，上下文彼此隔离，挂完整工具，用能力最强的模型，只向Router汇报，不直接跟人说话。

这个区别在实际使用里的体感是：你不用等上一个任务跑完，就能接下一个指令。Router派完活就去接新事件，Worker在自己的隔离会话里干活，完事了自己回来汇报。p95从29.5压到15.7，靠的不是模型推理变快了，是不用排队等前一个任务跑完。

速度的代价：Token涨了3.8倍，取消“直通”后再涨37%

这是文章最需要说清楚的部分。

DeepSeek团队的实验口径是约300条消息、20项真实工作请求，每种方案重复五次。Super-agent的读缓存Token是2323万，单会话基线是605万，大约3.84倍。

团队自己的说法是“用更多Token换更短、更稳的完成时间”。这句话本身没错，但它只说了半句。另外半句藏在实验的另一个对照组里：取消“订阅直通”机制之后，Router的决策次数增加了约30%，读缓存Token从2323万涨到3177万，再增加37%。

订阅直通的意思是，一个Worker接手某个PR之后，后续这条Thread上的评论直接由程序发给它，不再绕Router。这个机制不是可选的优化项，是控制成本的关键结构。一旦取消，Router要重新处理每一条后续事件，Token就往上走。

还有一个数字容易被忽略：Router批处理把单个决策分摊的推理时间从6.4秒压到了1.6秒。这个优化降低的是延迟，不是Token。速度收益和成本代价，是两个账本。

“工作区隔离”不等于“安全隔离”：它能读你的home目录

这是我在翻文档时最在意的一段。

Super-agent的Worker有独立的会话和独立的工作目录。文件层面，一个Worker改的东西和另一个Worker改的东西是分开的。但这只是“文件去哪儿”的隔离，不是“进程能碰什么”的隔离。

dev.to上的一篇分析把这件事说得很直接：发布的预设以danger-full-access在操作员的OS账户下运行。账户包装器选择默认身份，并不能阻止Worker读取操作员的home目录或按路径执行程序。文档因此建议使用专用OS账户做隔离

这句话拆开看是三层。第一，Worker继承的是你的系统权限，不是某个受限沙箱的权限。第二，它能按路径调用你机器上的程序。第三，它能读你home目录下的文件。独立工作目录解决的是“Agent之间不打架”，不解决“Agent能碰到什么”。

官方推荐的一个动作是给Agent单独开一个GitHub账户。这个建议的出发点是对的：Agent提的PR、留的评论，用独立身份，不和你的个人账户混在一起。但要注意，GitHub账户只切了“对外身份”，没有切“执行进程的操作系统权限”。Worker跑起来的时候，用的还是你的OS账户。

专用OS账户才是那道真正的门。官方的部署文档也把它列为最低安全措施。如果你只是在自己的开发机上试试，问题不大；如果你把它部署在一台有生产凭证、有共享目录、有其他项目代码的机器上，这道门不开，等于把整个账户交出去。

部署比想象中简单，但“研究原型”四个字要当真

安装路径不复杂。先装DeepSeek Harness的CLI：npm install -g @deepseek-ai/dsh@0.2.1-rc.3 ，然后克隆仓库，把 SETUP.md 直接丢给你的Coding Agent读。这份文档被写成了一个向导，Agent每次只问你一个简短问题，把全量计划展示一次，然后自动安装和配置

它需要Node.js 22.19以上、GitHub CLI 2.48以上，以及一个在Harness里配好的模型provider。Router用较轻量的模型就够，Worker用能力最强的模型，因为代码质量由Worker决定。

但README第一段就写得很清楚：“Research prototype for reference only, not an official DeepSeek product. Treat it as research code, not production-ready software. It may still contain bugs.”

这是一个架构探索，不是正式产品。实验用的是合成消息流和模拟工具，只验证调度与协作，没有评估真实编码质量。你能从它身上学到的是“多任务并发该怎么组织”，不能直接拿来当生产系统用。

Watchdog和“先观察”模式：它知道Agent可能不吭声

做Agent落地最难的地方在于，它不吭声。任务派下去，进度条卡在40%，日志最后一行是半小时前的，你分不清它还在想，还是已经死了。

Super-agent的架构里有一个专门管这件事的模块：Watchdog。它什么都不干，只做巡检。每隔一小会儿扫一遍所有Worker的心跳时间戳，谁超时就把谁按下去。社区已经有现成的Watchdog插件，比如 dsh-watchdog 的默认配置是5秒一次心跳，30秒没有新心跳判定为冻结，恢复时杀掉孤儿Worker。另一个插件 dsh-stall-guard 做得更细：不杀正在执行的任务，只对真正的“沉默”动手，先诊断、再修复

还有一个设计细节值得单独说：Super-agent默认从“观察模式”开始，先看不。团队的原则写在 docs/000-philosophy.md 第一行：“尽可能少占用人的注意力，尽可能多给出价值”。所以它只在被请求、或者团队写好的规则允许时才行动，只在有人需要决策或能用上结果时才说话。

这个“克制”不是道德姿态，是成本控制。一个能替整个团队行动的Agent，也能浪费整个团队的注意力；一个能主动找活的Agent，也能主动烧掉你的Token。先观察，再放开，是让它在你的环境里校准“什么值得动”的最便宜的方式。

它适合谁，以及我现在的用法

值得认真试的人：已经在用DeepSeek Harness、并且有多个任务需要并行的开发者或小团队。它的Router/Worker拆分解决了一个真实的问题：你的注意力是瓶颈，Agent不该让你在三个终端窗口之间来回切。如果你有GitHub仓库需要持续盯issue和PR，它的“主动找活”模式能省掉一部分“人肉巡检”。

需要先算账再碰的人：对Token成本敏感的个人用户。3.84倍的读缓存Token不是小数字，如果你的任务本身不高价值、或者你的预算卡得很紧，单会话方案在成本上仍然更划算。速度的收益，只在“并行确实能省下你的时间”的场景里才成立。

必须先把安全门关好的人：任何打算把它跑在有生产凭证、共享目录或其他项目代码的机器上的人。专用OS账户、独立GitHub账户、窄白名单、从观察模式开始，这四件事不做完，别让它碰你的真实环境。

我现在的用法是：在一台专门跑Agent的机器上开一个独立OS账户，Router配轻量模型、Worker配能力最强的模型，从观察模式开始跑一周，只让它看issue和PR评论、不主动提交。先看它“想做什么”，再决定它“能做什么”。

Super-agent把“一个Agent管多个Agent”从概念变成了能跑的原型。但原型的意思是：它证明这条路能走，不证明这条路已经铺好了。那3.84倍的Token和那扇没关的OS权限门，就是你还得自己铺的那两段路。