DeepSeek 的 Super-agent，为什么叫Super？
DeepSeek 产品部成员崔添翼在知乎举了个例子，英文里的上标叫 superscript，下标叫 subscript。
套到 Agent 上，Sub-agent 是在主 Agent 下面加一层，Super-agent 则是在原本干活的 Agent 上面加一层。
团队在文章里放了一个内部案例：开发者在群里让 Agent 按方案 A 改代码，等它提了 PR，又在 GitHub 评论里说：还是用方案 B 吧。
人一看就知道，这句话在改刚才的决定，系统得先把群里的要求和眼前的 PR 对上，再把新方案交给正在改代码的 Agent。
要是两条消息各进了一个会话，开发者就得自己把前情补一遍。
把所有消息放进一个会话，Agent 看得到方案是怎么定的、后来又怎么改。
可几件事同时进来，代码日志、用户指令和执行结果都挤在一起，任务也得排队。
给每项任务单开会话，活倒是能分头干了。可只要两个任务牵涉同一个决定，或者用户换个地方补一句，还是得有人把消息送到对的会话里。
很多时候，这个人就是开了好几个窗口的开发者。
这就是崔添翼说的取舍：会话拆开，任务能并行。可拆得越开，原来的上下文就越难接上。
DeepSeek 把交互和执行分成了两层。
上层 Router 接消息、分派任务，也负责跨任务协调；下层 Worker 各自在独立会话里干活。
用户照旧在群里提需求、在 GitHub 上补意见，系统在后台找到负责这件事的 Worker。
如果每条 PR 评论都要 Router 看一遍再转发，Worker 分头干活省下来的时间，又可能花在等消息上。
所以，团队把同一条 PR 或同一个群聊话题里的消息组织成线程。
第一条消息由 Router 分派，Worker 接手并订阅线程后，这条 PR 下的新评论就可以直接送到它手上。
Router 主要处理新任务，以及需要在几项工作之间协调的事。
不过，在同一条 PR 里补一句，毕竟还有 PR 可以认。
要是 PR 已经合了，隔了一周，你在新会话里说按上次定的方案来，系统就得知道你说的是哪个项目、哪次讨论，以及当时最后选了哪个方案。
崔添翼说，业界对长程记忆怎么做还没有形成共识，这也是团队采用双层架构的动机之一。
Router 可以维护任务之间的关系，Worker 各自保留执行需要的上下文。
至于会话结束后，哪些决定值得留、下次什么时候该找回来，仍是跨会话长程记忆要解决的问题。
DeepSeek Harness 还没有内置的跨会话长程记忆，但可能快有了。
授权用户提出需求后，系统会建立工作项，在独立会话和目录里执行，再回到原对话交付结果，比如提交一个 PR。
对于这套双层架构，崔添翼说，团队并没有提出全新的理论。
文章发出后，他们收到了不少英雄所见略同的反馈，和同行聊过才发现，已有几个团队在数月前试过类似设计。
在他看来，Agent 时代，写代码把各种方案试一遍并不难，难的是试完之后，能不能看清哪个方向长期更合适，并坚持做下去。
DeepSeek 的 Super-agent 还处在原型探索阶段。内部版本目前只在公司内较小规模的受信环境中跑通。
文章里提到的计算与状态、运行环境解耦，要在 Harness 里实现，还有不少工程工作。
与此同时，Harness 的会话内协作已经有了新进展。
10 月底，实验性工具 subagent_oar 可以把独立任务交给本机的 Codex 或 Claude CodeDeepSeek Harness更新，直接调用Codex、Claude Code做任务！。
11 月 11 日发布的 v0.2.2-rc.2 预览版又支持按会话开启 AgentTeam，团队成员和任务可以在同一块面板里查看，子 Agent 也能起名字、分层协作。
现在，开着同一个会话，开发者已经能看清哪个 Agent 在做哪件事。
下次关掉窗口、重新开一个，只说一句上次定的那个方案，接着做吧。
Harness 能不能把前情找回来？崔添翼在知乎给出的消息是：可能快有了。
