三个窗口，一个修 bug，一个写新功能，一个等代码审查。AI 每个都干得不慢，慢的是你——在三个窗口之间来回横跳，还要记住每个窗口里它已经知道了什么。
10 月 31 日晚上，DeepSeek Harness 团队发了一篇万字长文《Super-agent 设计探索：迈向更自主的 Agent 系统》，同一天把配套原型挂上了 GitHub，MIT 许可。文章开头那句判断，比后面所有架构图都值钱：一个人通常只能同时跟进三到五个活跃会话。单任务的上限取决于模型能力，多任务的上限取决于人的注意力。
这句话戳中的是当下所有智能体产品的共同尴尬。模型那条线还在往上冲，人这条线早就见顶了。
它不是一个更强的智能体，是一套「别让你管会话」的底座
先把定位说清楚：这不是一个新模型，也不是一个能装的应用。仓库自称是研究原型，不是 DeepSeek 的正式产品，部分设计只停留在文章里，代码里没有。
它想改的是工作单位。现在的智能体把「会话」当成基本单位，于是并行的代价全落在人身上：开一个窗口，就得记住这个窗口的上下文。DeepSeek 的方案是把会话降级成系统内部的实现细节，用户始终面对同一个助手，背后有多少个会话在跑，与你无关。
配套的四件套是：连续、高效、主动、持久。翻译成人话就是——不切断上下文、不互相堵、不用你点名、关机也还在跑。
Router 只派活，Worker 只干活，这条分工不能反
双层架构是整套设计的地基。
常驻的 Router 承接所有人类入口：群聊、代码评审、邮件、日程。它只做三件事，判断这条消息要不要处理、该派给谁、以及统一对外回话。文章里有个细节很关键：Router 刻意不执行具体任务，甚至可以不给它配命令行工具。理由很直白——Router 一旦埋头写代码，整个系统的响应就塌了。
所以 Router 用轻量模型就够，最强的那一档留给 Worker。
Worker 是隔离的会话，一个任务一个，挂满执行工具。它有个硬规矩：绝不直接对人说话，只向 Router 汇报，由 Router 统一回复。这条规矩解决的是一个很具体的问题——三个智能体同时回你消息，界面直接乱套。
这套分工在站内不是第一次出现。十月底那篇讲 AWS 开源 Infinity 的文章里，并发运行时解决的是「等工具跑完」的账单；Vercel 的 durable-harness解决的是「跑到一半崩了怎么续」。DeepSeek 这套往前挪了一格：它管的是「多个任务同时活着的时候，谁来决定顺序」。三者可以叠着用，不冲突。
触发器、两级过滤、Thread 直通：把群聊噪音挡在模型外面
驱动这套系统的不是提示词，是环境事件。DeepSeek 管它叫 Trigger：群消息、邮件日程、代码评审评论、持续集成的结果，都算。
问题在于真实群聊噪音极大，绝大多数消息不需要 AI 插手。每条都叫一次大模型，延迟和成本立刻顶不住。
解法借的是操作系统里的快慢路径。程序规则先筛一遍：来源对不对、在不在白名单、是不是机器人自己发的，直接丢掉；剩下的候选才交给模型做语义判断。这层的妙处在于，语义判断的策略写在提示词里，等于给了个随时开关的行为旋钮。
第二条设计更省事：一条代码评审、一个群话题、一封邮件链，连续的几条事件构成一条 Thread。Router 从第一条事件开了 Worker 之后，这个 Worker 就订阅了这条 Thread，后面的消息直接投给它，不再过 Router。
别小看这条直通。文章给的消融数据是：关掉它，Router 要做的决定多了约三成，读缓存从两千三百二十三万 token 涨到三千一百七十七万。
上下文按缓存管：内联、溢出、顺着编号往回翻
上下文窗口是稀缺资源，DeepSeek 用编译优化的思路处理：大概率马上要用的直接内联进窗口，比如当前消息的前五十字和相邻几条；超长的部分溢出到窗口外，只留摘要和关联对象的编号。
真要翻旧账时，模型顺着编号之间的引用关系一跳一跳按需取回。这套做法的前提是每条事件、每条 Thread、每个 Worker 都有唯一编号，否则链条断在第一步。
投机执行：先偷偷修，修好了才说话
这是整套设计里最像人的一段。
群里有人报 bug，不等谁点名，智能体先在后台消耗一点算力尝试复现。修好了，直接开一个合并请求，附前后对比；修不好，全程闭嘴，不留一句「我正在努力」。
文章里举的例子很具体：有人在群里说，macOS 桌面端窗口没聚焦时点一下会话，会被识别成双击、进了重命名，一天误触发几十次。没人 @ 它，它自己认出了这是缺陷，在后台复现、定位，最后提交了修复和截图。根因是 Electron 默认吞掉了激活窗口的那次点击，下一次点击带着双击标记，于是被判成双击。
同一套思路还铺到了交互上：把同步的工具调用改成异步的启动和停止，后台跑编译时前台照样能接新指令；群聊里单条回复不超过一百词，代码评审里给结构化报告。说白了就是按信道定制话术密度。
实测数字要分三档看
论文式的表格很容易被当成战力榜，这里得拆开。
能核实的部分：约三百条消息驱动四种方案，其中约二十条是工作请求，其余是闲聊、跟进、叫停和持续集成消息，每种方案跑五次。Super-agent 的完成时间是 p50 十二点四分钟、p95 十五点七分钟；单会话加子智能体工具、中性提示下是二十点四和二十九点五。改成提示里优先委派之后，p50 降到十三点八，p95 还是二十九点零。
只有厂商说法的部分：编码环节用一个只消耗时间的假工具代替，所以测的是调度和协作，不是单个任务干得好不好。负载是合成的，环境是简化的。作者自己把结论写成「仅作初步参考」。
表格的另一半是账单：Super-agent 单次实验读缓存两千三百二十三万 token，单会话只有六百零五万。拿四倍上下文换更短更稳的完成时间，这笔账值不值，取决于你的 token 便宜还是你的时间便宜。
还有一组压测更值得看：把需要判断的事件从每分钟一条拉到四十条，批处理大小从一点零涨到二点八，单次请求从二点五秒涨到三点九秒——涨得比批量慢，于是每个决定的摊销推理时间从六点四秒掉到一点六秒。这解释了为什么他们说团队规模下一个 Router 会话就够。
开源原型里有什么，没什么
仓库是 TypeScript 写的，打包成 DeepSeek Harness 的一个 bundle。核心是一个引擎类，挂五个部件：收事件、做判断、管工单、派活、回话，所有状态变更走同一个事务入口。编排层是一个两秒一轮的定时器，每轮推一下待发出的副作用，再推进到期的评估。
权限那层写得很克制。每个来源一张准入表，把消息判成显式请求、推断候选或者直接忽略。通过判断要同时满足三个条件：方向已确定、命中的规则至少一条是启用的、给出意图证据。哪怕都满足，只要这条是推断出来的、而当前模式不是自动，也只能记成「本可以接受」，先记录不执行。
模式三档，关闭、观察、自动，默认是观察。
没实现的部分也写在 README 里：看门狗、端侧轻量守护进程、异步的工具调用循环。文章里那套「云端跑循环、本地跑环境」的脑手分离，在原型里还只是方向。所以现在克隆下来能跑的，是一个盯着单个 GitHub 仓库、等白名单里的人派活、干完开合并请求的代码智能体。
想在自己项目里照抄，从这三步开始
不用整套搬。按投入产出排，最值得抄的是三件小事。
第一件，把触发分成代码层和模型层两道。这一步不写代码也能落地：先列出哪些来源根本不该叫模型，剩下的才交语义判断。省下的钱当天就能看见。
第二件，一条话题只开一个执行会话，后续消息直接投给它，别再回到调度层。这条改动的收益最确定——三成决策量、两成多缓存。
第三件，前台命令超过五秒就转后台。原型的参数是：超过五秒转后台任务，每轮结束后后台最多再跑三十分钟，到点杀掉并把工单报成等待中，空出来的位置立刻还给下一个人。没有这个超时，一个卡住的会话会吃掉整个池子。
如果你现在还在手工开窗口调度智能体，老达AI实践专题里那几篇讲工作流的可以一起看。真要上手，AI 智能体与自动化专题里的方案对比更省时间。
前面提过的 AWS 那套「给后台智能体配收件箱、要动手先审批」的思路，这篇可以当对照组：一个把审批放在动作前，一个把审批压缩成一条规则加三档模式。至于入口侧怎么开放，Cursor 那套把智能体打成 SDK 的做法是另一条路。
三处必须先想清楚的风险
第一处，权限。原型的执行文档写得很直白：Worker 会话以操作者的系统用户身份跑命令，不额外审批。也就是说，一个能自己找 bug 的智能体，同样能自己删掉你半个目录。
第二处，提示注入。文章自己把这条列为未解问题：云端智能体能按需调用本地设备，本地凭据和未提交的代码都在射程内。沙箱那道门该怎么设，Perplexity 开源的那套笼子是目前站内讲过最细的一份。
第三处，用量。文章结尾那句提醒值得抄在墙上：别拿它刷产量。批量合并请求、群发消息、凑数的活，付出的注意力比拿到的东西多。
老达点评
这篇东西最值钱的地方不是架构图，是那句把注意力当唯一计价单位的话。一旦你把「打扰人」当成成本，系统会自动去挑那些真值得开口的事做，这比任何提示词技巧都更接近少说多做。
但它同样是把双刃剑。一个能替整个团队干活的智能体，也能把整个团队的注意力一起浪费掉——它越快，你被通知的频率越高。所以我更愿意把它理解成一份「注意力预算表」，而不是一套要立刻上线的系统。
给普通人的建议：短期内别指望靠这个省事。真要试，按他们自己写的路子来——先开观察模式跑一周，只记录不执行，看它本来会干些什么，再决定放不放权。这一步花的时间，比事后收拾烂摊子便宜得多。
