PostgreSQL码农集散地

聊聊 DeepSeek SuperAgent

大家好,我是 digoal德哥,这几天被 DeepSeek SuperAgent 刷屏了,今天跟大家聊聊我对这个 dsh superagent 的看法。

能触动我神经的应该是它能解决卷王的痛点。大家有没有注意,不管是你周边的卷王还是互联网上的卷王,只要看他们露脸的那种视频,你会发现他们个个都成了熊猫眼,就比如我经常看罗胖的视频日记,眼睛跟肿了似的。

为什么?这个问题我之前其实说过,就是这个人啊,在 AI 效率越来越高的情况下,自己成了瓶颈,所以我打造了 AI 屠龙刀周六的会议我爆出了 AI “屠龙刀” 的秘密,有兴趣的朋友可以回去翻看我的公众号文章。

不要被 super 这个词骗了,DeepSeek SuperAgent 根本不是“Agent 又能多干活了”,那个叙事已经过时了。它真正瞄准的问题是 —— 人成了瓶颈,特别是卷王。说白了它在找边际收益更大的需求,再提 Agent 又更牛了不是没意义,是边际收益递减了。你想想是不是这个理儿,模型单任务能力早就溢出了,Terminal-Bench 也好 DeepSWE 也好,刷分刷到麻了,可你一个人能同时盯几个窗口?三个?五个?再多就精神分裂了。限制产出的不再是模型,是人的注意力带宽。那既然瓶颈在人这儿,你继续卷模型参数有个屁用啊,得换赛道,把“协调”这件事从人脑子里掏出来塞给系统。这就是 superagent 的逻辑起点,它不是在做一个更强的 Agent,它是在做一个替人管 Agent 的 Agent。

那怎么管呢?它拆成 Router 和 Worker 两层,Router 只分派不干活,Worker 闷头干不对外说话。这个设计乍一看平平无奇,但它其实是在复刻操作系统里那个最老掉牙的分层调度思路。Router 用轻量模型就够了,因为它只判断“这事儿该不该接、派给谁”;Worker 才需要最强模型去啃硬骨头。你把最贵的算力全怼在执行上,别浪费在分拣上。而且 Router 不配 Bash 工具,它连动手的能力都没有,这就从架构上杜绝了“调度者自己下场干活然后上下文炸掉”的经典死法,我经常在使用 Claude 时遇到 subagent 卡死然后主会话上去就把自己玩死的情况。你想想多少 Agent 框架死在主会话越长越蠢上,superagent 相当聪明,把“想”和“做”在物理层面隔离开了。

再往下,怎么保证 Agent 干活时不打扰人?我发现这块真像我自己写的 SOUL.md,我就特烦 Agent 动不动问我。所以个人认为这是真正见功力的地方。现在市面上那些主动型 Agent,十个里有九个半是“积极废人”,屁大点事弹个通知,你还没法骂它,因为它是“为你好”。superagent 在这块搞了个双层过滤,程序层先拿确定性规则筛掉噪音,剩下的才交给模型做语义判断。默认是 observe 模式,意思是对于推断出来的“你可能会需要这个”的任务,它只记录“我本来会接这个活”,但不开工,除非你明确授权或者团队规则允许。这个克制太重要了。一个能替你干活的 Agent 如果管不住自己的主动性,它浪费的就不只是它自己的时间,还包括你整个团队的注意力。superagent 理念文件第一行写“尽可能少占用人的注意力”,这不是口号,是架构约束。

不过我前面说的全是理念。这东西目前还是个研究原型,代码是团队拿 Agent 自己写的,README 里自己都承认工程风格可能不一致、可能有 bug。它绑一个 GitHub 仓库加飞书,场景窄得很。而且那个“订阅直通”的机制虽然聪明 —— Worker 接手 PR 后后续评论直接走程序通道不绕 Router,省了 Router 大概三成的决策量和近千万 token —— 但这套东西的复杂度摆在那儿,部署门槛不低。你让一个普通开发者自己配 worktree 准备命令、调 Router 的模型、写授权规则,光想想就头大。所以它现在的价值不在“拿来就能用”,在于它把一个问题给结构化了:过去我们说 Agent 要自主,说的是单个 Agent 的能力边界;superagent 说的是多个任务之间的协调成本该由谁承担。它给的答案是系统承担,人只负责决策和验收。

不管方法是什么,核心都是在解决人类瓶颈。另外我再预测一下下次再看到有什么新东西一定是边际收益更大的需求。