第 1 章 你同时只能跟三个窗口

周一早上的五个窗口

九点半，群里三条消息：支付回调偶发 502，运营说导出按钮点不动，还有人贴了一张 CI 红的截图。十点，一个 PR 等你 review。十点零五，产品问上周那个需求什么时候能上。

你打开第一个窗口查日志，第二个窗口让 AI 改导出按钮，第三个窗口读那个 PR。查到一半，产品的问题弹出来，你回去解释；解释完，第一个窗口的上下文已经凉了，日志翻到哪一页忘了。

一天结束，五件事推进了两件半。

这个场面不是模型不够聪明。你让它在任何一个窗口里干活，它都干得不错。卡住的是切换：每换一件事，你都要把"上次想到哪"重新装回脑子里。

DeepSeek 的 Harness 团队在 2026 年 10 月 31 日发了一篇文章，标题叫《Super-agent 设计探索：迈向更自主的 Agent 系统》。它没讲模型，讲的就是这件事：怎么让一套系统替你持有这些上下文。

文章里有一个观察，我把它当成这一章的起点："据我们观察，一个人通常只能同时跟进 3 到 5 个活跃 Session。"超过这个数，不是任务排队，是你开始丢东西。这是团队对自身工作方式的观察，不是测量，所以当量级看，别当容量上限。原文全文我存在 sources/ 里，后面引用的每一句都能在那边核。

断点不在模型，在你的切换

现在的 Agent，基本单位是一个会话（Session）。一个会话一件事，会话与会话之间互相不知道对方存在。

这套设计有两个隐含成本，平时看不见。

上下文在你身上。第三个窗口查到一半的证据，第四个窗口不知道。谁说过什么、哪条已经排除、哪条还没验证，全在你脑子里维护。

任务会等你。最后一个窗口里的活儿，只有你切回去才会往前动。系统不会因为五分钟没人看就自己推进。

再往下一层，是三个具体的断点，文章点了名。

单会话串行阻塞。一个窗口里跑一条很慢的命令，这个窗口就停在那儿。你想同时问点别的，只能再开一个。

多任务上下文混乱。五个窗口，五种语气，五套你当场编的缩写。切回去要先花一分钟回忆"这个窗口刚才在争什么"。

本地设备离线，任务停。Agent 跑在你的笔记本上，合盖就断。这个断点最容易被忽略，因为它不在软件里，在你的电源键上。

把一次切换算成钱

数字是我假设的，不是测量结果。你自己换成你的数。

一天八小时，五个任务，你平均每小时主动切换六次，也就是每十分钟一次。每次切回去要三分钟才能重新接上：翻记录、看上次改到哪、想起当时为什么这么改。

8 小时 × 6 次/小时 × 3 分钟 = 144 分钟
144 / 480 = 30%

将近三分之一的工作时间，花在把自己接回去，而不是干活。

这个算式有两个地方会骗你。三分钟可能偏乐观，长任务上五分钟很常见；也可能偏悲观，熟练的活儿接回去只要几十秒。它唯一的作用是让你承认这笔开销存在，并且能估出量级。

真正要看的不是 30%，是这 144 分钟属于谁。如果上下文存在系统里，其中一部分就不用你重建。注意是"一部分"。系统能记住它读过什么、改过什么，记不住你为什么决定先改导出按钮而不是先查 502。选择还在你这边。

读到这儿停一下。同样五件事：A 是你一个人开五个窗口来回切；B 是其中三件交给一个常驻系统，各自有上下文，你只在结果出来时看。差别在哪一个变量上？先写下你的答案，下一节回来对。

四个特征，一条一条对

文章给这种形态起了个名字，Super-agent，归纳出四条特征。名字不重要，四条特征可以当检查表用。

连续：你在群里说一句、在 PR 下面评一句，是同一个 Agent 在接。不需要你在两个地方各解释一遍背景。

高效：多件事同时推进，互不干扰。这里的"同时"是系统层面的并行，不是一边跟你聊天一边偷偷跑任务那种假并行。

主动：它看着环境里的动静，觉得值得动手就先动手，而不是等你 @。文章举的例子是群聊里有人报了个 bug，没人 @ AI，它在后台复现、找到修法，然后才提交一个 PR。

持久：一直在，出异常能自己爬起来。重启、断网、某次模型调用超时，任务不该归零。

四条里最容易误解的是"主动"。它不是"更爱说话"。原型仓库的文档把原则写得很直白：用尽量少的人类注意力换尽量多的价值；没人要求的工作，必须有一条团队写下的规则允许，而且先用只记录不动手的模式跑一段。

也就是说，主动的对立面不是被动，是噪音。

回到上一节那个判断。A 和 B 的差别不在任务数量，也不在模型强弱，在谁持有上下文。A 里上下文活在你脑子里，B 里活在系统里，你只在需要决策的时候被叫回来。

它不是产品，是一个还没定型的架构

这根事得说清楚，因为不少转述把它写成"DeepSeek 发布新品"。

我读了原型仓库。README 开头两句自己写着：研究原型，仅供参考，不是 DeepSeek 官方产品；代码为了公开做过适配，和内部版本、和文章里描述的实现在细节上并不一致，文章里有些设计是未来方向，原型里没实现。

仓库叫 dsh-superagent-prototype，MIT 协议，TypeScript。2026-11-01 我看的时候，GitHub 页面显示 3.5k star。它能做的事比文章小得多：盯一个 GitHub 仓库，有人要求干活就开一个工单，在自己的会话和目录里干，把结果以 PR 的形式回到原来的对话。

所以把它当成什么？一份可以读的设计草案，附带一个能跑的最小实现。你要学的是它怎么拆问题，不是它现在能不能替你上班。

什么时候这套说法不成立

三种情况，你对号入座。

任务本身需要你连续判断。改一段你不熟的代码，每一步都要你拍板，交给系统只会让你读更多份报告。这类活儿并行不了，拆开反而更慢。

任务之间强耦合。三件事其实是一件事的三个面，硬拆成三个工单，它们会互相踩。原型里的做法是同一个话题下允许挂多个工单，但评估时要靠工单列表去重，这就是在补这个洞。

团队没人愿意写规则。主动性的前提是有人把"什么情况下可以自己动手"写下来。写不出来，就只能一直停在"只记录不动手"的模式，那和普通 Agent 没区别，还多一层复杂度。

反过来，它最适合的场景有共同形状：事情多、彼此独立、单件不难、但需要有人一直盯着。值班、仓库维护、客服分流，都是这个形状。

经验：先数你在切换什么

看到"多智能体""自主协作"这类词，先别想架构。拿一张纸，写下你这周实际在并行的五件事，每件后面写两列：上下文现在存在哪（你脑子里、某个窗口里、还是某份文档里），以及它需要谁来推进（只有你能，还是谁都能）。

如果五件事里有一半以上的上下文存在你脑子里，那你缺的不是更强的模型，是一个替你持有上下文的地方。这时候再去看 Router、Worker、工单这些词，才知道它们各自在补哪个洞。