能干的活越来越多，能盯的窗口还是五个

2026-11-01 · 人工智能

10 月 31 日晚上八点半，DeepSeek Harness 团队在自家公众号挂了一篇技术文章，标题很长：《Super-agent 设计探索：迈向更自主的 Agent 系统》。

差不多同时，他们把配套的原型代码开源了，仓库叫 dsh-superagent-prototype，MIT 许可，只有一个 commit。

我打开仓库先看开头，看完就笑了。第一段不是介绍功能，是免责声明：仅供研究参考，不是 DeepSeek 官方产品；代码长自团队的日常开发，其中大量工程是 coding agent 自己做的；可能有 bug，代码风格和工程实践可能不统一，用之前请自己审一遍。

一个团队忙活半天做了套系统，第一件事是告诉你：代码可能是 AI 写的，写得可能不怎么样。

起点是一个数：五个

文章真正的开头不是技术，是个观察。他们发现，一个人通常只能同时跟进 3 到 5 个活跃会话。

他们的说法是 Session，我说窗口，一个意思。

现在你用 AI 干活是这样：一个窗口修 bug，一个窗口写新功能，一个窗口看别人的 PR。三个窗口同时开着，你就在中间来回跳，跳到第三个的时候，第一个干到哪儿了已经忘了。窗口再开第四个，你的记忆就先崩了。

所以文章里有句话我抄了下来：单任务的上限取决于模型能力，多任务的上限取决于人的注意力。

这句话听着平淡，其实是在说一件挺丧的事——模型这一年涨了多少能力，跟你一天能干几件事，关系不大了。卡住你的不是它，是你自己脑子里那块缓存。

所以让管事的不管活

他们的解法是把调度这件事从人手里拿回来，交给系统。核心是个两层结构：Router 负责派活，Worker 负责干活。

Router 那一段有个细节，是全文我最喜欢的：原文提出，Router 可以不配备 Bash 工具。

也就是说，这个坐在调度位上的东西，手上不给它命令行。它能看、能判断、能分派，但它不能自己动手。因为它一旦开始埋头写代码，新来的消息就没人接了。

管事的不管活，这道理听着像常识。可我们多少公司里，最忙的那个人恰恰是既管又干的。

顺带一个选型：Router 用小一点、快一点的模型，Worker 用强的。不是所有岗位都要招最贵的人。

权限不交给模型

Agent 要「主动」，就得能自己判断一条消息值不值得处理。这里的坑很明显：真实工作环境里绝大多数消息都不需要 AI 管，全丢给模型，钱和时间都白烧。

他们分两层过滤。第一层是普通程序规则，快、便宜、不用推理，而且它同时承担授权准入——谁能触发、能触发什么，在这一层定死。第二层才让模型判断语义：这条消息是不是个活。

分工的意思很直白：能不能干，程序说了算；该不该干，模型说。授权边界不交给模型自由发挥。

这话写在技术文档里像句废话，但这一年出的事，一半都是因为把「能不能」和「该不该」交给了同一个东西去判断。

三个省事的细节

接手过的活，别再问路。 一个 Worker 接了某个 PR，后面这个 PR 来五条评论、CI 跑挂了，按老办法每条都要过一遍 Router，重新判断「这归谁」。他们的做法是 Worker 接手时就订阅这个 Thread，之后的消息系统直接送到它手上，Router 只在开新任务、跨任务协调时出面。订阅是多对多的，一个 Worker 能订多个 Thread，一个 Thread 也能被多个 Worker 订。

把上下文窗口当缓存用。 一个跑了三个月的 Agent，历史日志、Issue、PR 全塞回去，token 烧光不说，注意力还被稀释。他们的分法叫 Inline & Spill：大概率要用的（当前事件、近期消息、任务摘要、相关对象 ID）放窗口里，体积大又低频的（完整日志、长文档、旧任务）留在外面，只留个读取入口。

先干活，再汇报。 群里有人说「这版本好像又内存泄漏了」，Agent 不必先回一句「我帮你看看」，它可以直接在后台复现、找根因、备好补丁，有靠谱结果了再交给人，没结果就安静地结束。他们管这叫投机执行。

但这条有三道闸：活本身的价值得能验证；后台烧的算力要有预算上限；对外有影响的动作必须先拿到授权。少一道，你仓库里就会多出一堆没人要的 PR。

省下来的时间是拿 token 换的

实验部分我没跳。合成环境：约 300 条消息、20 项工作请求，每种配置重复跑 5 次。

结果是：一半的任务 12.4 分钟内做完，95% 在 15.7 分钟内做完。对照组是「单会话 + Subagent」，中性提示下 95% 要 29.5 分钟。

但账不是白捡的。他们把「订阅直通」这个优化拿掉之后，Router 的决策数多了约 30%，读缓存的 token 从 2323 万涨到 3177 万。反过来，Router 做批处理，单个决定分摊的推理时间能从 6.4 秒压到 1.6 秒。

一句话：它不是更省的方案，是拿 token 换你的等待。对个人来说这笔账不一定划算，对团队可能划算——毕竟被省下来的那几个小时，是要发工资的。

一个自己会反转的设计

最后一层是 Watchdog，看门狗。名字朴实，功能是盯着别的 Agent。

普通监控只查进程活没活、网络通不通。可一个 Agent 完全可能进程好端端的，却在原地打转：同一条命令连着跑失败、同一段代码反复改、方向早就偏了。这些老办法都发现不了。

他们的办法是单独开一个 Watchdog 会话，定期检查，在约束内自己恢复或者叫人。有意思的是，这个监督者本身也是个有工具的 Agent，它不光能判断任务出没出问题，还能顺手改提示词、调触发策略、修系统本身。

原文自己承认了风险：得给 Watchdog 比普通 Worker 更严的约束，否则会出现主 Agent 和 Watchdog 互相修改、反复重启的场面。

我看这段的时候在纸上画了个圈：一个 AI 管着另一个 AI，被管的那个也在改系统，管人的那个也在改系统。这画面有点熟，像两个人互相给对方改简历。

写在后面的两句话

文章自己说得很清楚：整套设计没有提出新理论，是把操作系统里的老东西——调度、缓存、进程隔离、看门狗——搬进了 Agent。

仓库那边说得更直白：文章里讲的一些设计只是方向，这个原型里还没实现。

这就是我觉得这次发布有意思的地方。它不是又发了个能聊天的东西，是一群人把「人到底卡在哪」这个问题的答案摊开给你看，然后说：我们照这个答案搭了个架子，代码在这儿，写得不怎么样，你自己看着办。

我省下注意力了没有，不好说。

昨天晚上我在便利店排队，前面那人一边付钱一边对着手机说「等一下，我回个消息」，后面排了四个人。收银员抬头看了他一眼，又把头低回去扫码。五秒钟之后，那人还在打字。

我们大概都需要一个 Router。问题是，轮到它决定哪条消息该打断你的时候，你放心把那个权限交出去吗。