Super Agent主动工作原型开源

DeepSeek Harness团队在10月31日晚上发布了一篇文章，标题为《Super-agent设计探索：迈向更自主的 Agent 系统》，文章里提出了这样一个概念：Super Agent。 同时他们也在GitHub上开源了Super Agent的原型dsh-superagent-prototype，以供开发者参考。 所谓Super Agent，它就相当于一个记忆力超群、24小时在线、永远不摸鱼偷懒的同事。 你之前交代过什么，即使到下一个任务里，它依然能够记得。

还能在各种聊天软件、邮件和GitHub等不同的地方，执行同一项工作。 “主动”是Super Agent的核心关键词，有些事情不一定非得等到你开口命令它，它才会去干活。 比如看到群里有人报Bug，哪怕没人艾特Super Agent，它也能先去看看问题出在哪，能修就直接动手。 Anthropic此前推出的Claude Duet，虽然还处于预览版，但是它也会主动看邮件和日历，早上给你一份简报，平时发现重要事情再来找你。 Agent不该一直等你开口，Super Agent和Duet的共同点都是如此。

但“主动”并不意味着刷存在感。 一个真正好用的Super Agent，不仅要知道什么时候该主动找你，更要知道哪些事可以自己处理，什么情况才允许打扰你，什么时候应该保持安静。 它知道该干什么，也知道什么时候别烦你。 Super Agent和普通Agent有啥区别？ Super Agent和普通Agent的区别就在于，前者像是正式员工，后者更像是一个临时工。 你交代给普通Agent一件事，它会开始查资料、写代码、给结果。 当你下次有别的事，即使你叫来的还是它，它又要从查资料开始干起。

就算普通Agent把所有事情都经历一遍，可是到了最后，还是只有你自己知道所有任务的全貌。 因为每个任务都是一个独立的会话，Session之间互不相通。 普通Agent在A Session里得出的结论，B Session里的他根本不知道。 只有你自己才知道整个任务的全貌。 可DSH团队观察到，一个人的精力有限，通常只能同时跟进3到5个这样的活跃Session。 所以问题不只是Agent够不够聪明，你能同时盯住几个Agent也是提升模型工作效率的重点。 那如果让一个员工同时做所有事呢？ DSH认为这样也不现实。

普通Agent一边修Bug，一边写报告，还要不断回消息，输出速度必然会变慢，更可怕的是几件任务的细节也容易混在一起，导致最后的结果驴唇不对马嘴。 Super Agent要解决的第一件事，就是分配两种角色。 一种叫Router，可以理解为项目主管。 他负责听需求、记背景、看全局，再决定任务交给谁，但不亲自去做具体执行。 另一种叫Worker，就是真正干活的员工。 每个Worker只领一项任务，在自己的独立空间里完成，修Bug的专心修Bug，写报告的专心写报告，几个人可以同时开工。

有句话听起来挺扯的，可事实就是这些分工不同的Worker，它们的“人格”也是不同的。 有些好沟通，有些极难沟通。 所以在Super Agent这里，你只需要跟最好沟通的项目主管打交道，不必挨个跟每个Worker沟通。 看到这里，你可能会问：这不就是主Agent带着几个子agent吗？ 前几天Anthropic刚刚发文章，标题叫《构建Agent》，核心就是说弄一堆子Agent不如单个Agent效率高。 事实上两者截然不同。

负责统领子Agent的主Agent，它的任务非常繁重，包括深入理解任务细节、规划子任务、高频协调，所以它的推理负担很重。 同时子Agent每一步都需要耦合，所以就需要主Agent频繁协调。 Router根本不考虑那些，它只管“这活我应该推给谁”，Worker之间上下文隔离、彼此独立，靠订阅同一个Thread感知冲突。 所以从产品逻辑上来说，Super Agent跟子Agent完全是两码事。 Super Agent的“主动”从何而来？ Super Agent干的第二件事是，没人专门下命令时，它怎么主动去干活？

DeepSeek的做法让它留意工作环境里的动静。 任何动静都可能成为一个“触发器”，Super Agent一旦察觉有动静了，就会立刻进入工作状态。 任务派出去之后，后续沟通也不必一直经过主管。 比如Worker已经开始修某个Bug，那么这个话题下面的新评论，就会直达Worker。 就像维修师傅接单以后，你会直接把问题报给维修师傅，不用再让客服转述一遍。 DSH的文章中有个案例，开头也提到了，群里有人说：“这个项目有BUG。

”没人艾特Agent，但这句话进入系统后，先经过规则过滤，再由模型判断它符合团队提前写好的“静默复现并修复”策略。 项目主管把任务交给一个Worker，Worker在自己的独立空间里复现问题、查找原因、尝试修复。 没复现出来，或者发现修复很复杂，它就保持安静。 如果确认问题并找到简单方案，就提交一份PR，最后交给人验收结果。 后续有人在GitHub评论里要求换个修法，Worker也能从原来在聊天软件的场景里换到GitHub上面接着做。

DeepSeek文章里展示的内部实例，就是这样在群聊和GitHub之间连续推进任务，甚至在无人艾特的情况下主动提交修复代码的申请。 除了看聊天软件里的消息以外，Super Agent还会观察所有能看到的信息，比如收到一封新邮件、日程有变化、代码自动检查没通过。 但是群聊里大部分消息都是闲聊，绝大多数跟Super Agent没关系。 如果每条都让模型读一遍，又慢又贵。 所以DeepSeek给Super Agent加了两道筛网。 第一道是提前定好的规则：哪些群能看、哪些人或机器人的消息算数、哪些来源直接忽略。

第二道交给模型判断：剩下的候选消息，这句话是随口吐槽，还是真有一个需要处理的问题？ 这类需要理解语义的判断，规则没办法写出来。 好在的是，第二道筛网是用自然语言写的，想改策略，改一句提示词就行。 只有两道都通过了，项目主管才会派任务。 Super Agent另一大特点是把工作放到后台，先告诉你“已经开始做了”，做完再把结果送回来。 这期间，你仍然可以补充要求、叫停，或者安排下一件事。 DeepSeek称，这一异步任务机制已经在DSH中实现，但尚未默认开启。

你去餐厅点菜，点完之后服务员也不可能站在灶台前等菜炒完，他会回来继续招呼其他客人，等菜做好了他才去端上来给你。 还有一个事，DeepSeek认为Agent是要持续干活的，所以Super Agent更是要一直在线、持续工作。 可是干活久了，上下文就会太长，Agent很容易出错。 因此DeepSeek把Agent的“大脑”、任务记录和实际操作的电脑分开。 大脑可以在云端工作，任务记录单独保存，代码和文件仍留在原来的电脑上。 这样，某台云端机器重启了，记录还在。 需要操作你的电脑时，再远程连接过去。

同时，DeepSeek还给Super Agent安排了一个Watchdog。 普通的监控只能看Agent有没有宕机，Watchdog还要看任务有没有进展、方向有没有跑偏。 就像店长巡店，不只是看灶台的灯亮没亮，还要看厨师放了几克盐、煮了多长时间。 不过，GitHub上的dsh-superagent-prototype还不能被当成Super Agent的“完全体”。 DeepSeek表示，它只是研究原型，不是正式产品。 目前主要面向一个GitHub仓库，也可以选择接入飞书，文章里的一些设计还没有实现。

Super Agent最强的能力是“闭嘴” GitHub原型的说明文档里，有这么一句话：尽可能少占用人的注意力，尽可能多地提供价值。 DeepSeek把每一条消息、每一次通知、每一个问题、每一个设置项，都看成一种注意力成本。 不能提供足够价值，就应该删掉。 原型还明确规定，Agent工作时保持安静，只有结果可用、需要人做决定，或者任务无法完成时，才再次开口。 这跟过去互联网产品的逻辑几乎是反着来的。 以前做产品，往往希望你多打开。 Super Agent要做的是帮你把事情处理掉，让你少打开。

一个真正好用的Agent，不应该把20条群消息总结成另外20条通知，再让你逐个确认。 它应该先把大部分事情做完，你只需要做那个非你不可的决定。 所以，Super Agent主动性的核心不是“多说话”，是它知道什么时候不该打扰你。 DeepSeek文章里有个“静默复现并修复”的例子。 Agent可以先在后台复现Bug、寻找修复方案，但只有确认问题并找到简单方案后才交付结果，否则全程保持安静。 换成一个普通Agent，可能刚看到消息就先回一句“收到，我正在分析”，十分钟后发来一段过程，半小时后再告诉你没复现。

是，这个普通Agent很忙，我看着都累，可你也确实被它折腾了半天。 可Agent产生的信息，其实不等于Agent提供的价值。 Super Agent就是在重新定义人跟AI之间的关系，人不应该给AI当秘书。 DeepSeek反复强调一个概念，Session该由系统在背后管理，用户不应该为它操心。 文章提到“从这个角度看，让用户手动管理Session，在很大程度上是从底层LLM API延续下来的设计惯性”。 这句话的意思是，会话并不是正确的产品形态，它只是早期大模型API留下的习惯。

既然用户真正想管理的是任务，那就应该让系统自己去管会话，人只需要看事情有没有办完。 有了Super Agent，你就不用每天特意打开某个AI应用，它只要在群里、代码仓库和邮件里，就能自己工作。 当然，Agent越主动，它的边界感也就越重要。 DeepSeek的Super Agent有这样一条规则：Super Agent