晚上十点，你开着四个 AI 窗口：一个改合同，一个查竞品，一个等报错，还有一个跑到一半，你已经忘了它要干什么。切回去，先花两分钟读它说到哪，再把背景重讲一遍。
DeepSeek Harness 团队 10 月 31 日晚发布的《Super-agent 设计探索》，开头就盯住了这个场景。他们观察，一个人通常只能同时跟进 3 到 5 个活跃 Session；单任务的上限看模型，多任务的上限看人的注意力。这话由做 Agent 的团队写进架构文章，意思很明确：卡住生产力的不是模型不会做，是人管不过来。DeepSeek Harness 团队
文章想解决的，不是“AI 更会干活”，而是“AI 替你当调度员”。方案叫 Super-agent：你面前只有一个助手，底层像前台加后台——常驻的 Router 接住对话和任务，多个隔离的 Worker 在后台并行做。Router 不干具体活，Worker 只把结果交回它。文章里有一句关键的话：Session 应当是系统的实现细节，而不应是用户的认知负担。你不需要记住哪个窗口在跑什么，系统应该替你记。DeepSeek Harness 团队
这套架构最日常的想象不是写代码。文章举例，收到会议邀约，Agent 可以先在后台核对日程冲突、搜集资料、备好回复草稿，你过目后直接发出。省下的是查日程、翻资料、起草这几步的来回。DeepSeek Harness 团队
内部实例走得更远：公共群聊里有人反馈问题，没人 @ 它，它自己定位根因、提交修复 PR。这证明的是流程能跑通，不是模型写代码变强了。DeepSeek Harness 团队
那到底能省多少？实验用的是合成负载：约 300 条消息、20 个工作请求，编码工作用一个只消耗时间的工具代替。它测的是调度和协作，不是写代码的能力。DeepSeek Harness 团队
在这个前提下，Super-agent 的任务完成时间 p50 是 12.4 分钟、p95 是 15.7 分钟。DeepSeek Harness 团队
作为对照，单 Session 方案在中性提示下 p95 是 29.5 分钟；换成“优先委派”的提示能好一些，但 5 次里仍有 1 次模型觉得活小、自己干了。最慢的那批任务，完成时间从半小时压到了十五分钟。DeepSeek Harness 团队
代价是 token。文章说，Super-agent 的读缓存 token 高于单 Session，是用更多 token 换更短、更稳的完成时间。去掉“订阅直通”后，Router 的决策量增加约 30%，总读缓存 token 从 2323 万涨到 3177 万，增幅约 37%。DeepSeek Harness 团队
对普通人来说，更关键的是：现在根本用不上。文末写明，这个原型插件只是验证技术路线的原型，并非 DeepSeek 的正式产品。这篇文章是一篇架构思路探讨，不是产品功能介绍。DeepSeek Harness 团队
GitHub 上的原型也印证了这一点：只服务一个 GitHub 仓库，README 写着这是研究代码，不是生产就绪的软件。GitHub
要跑起来，还得装 Node、pnpm、tmux、GitHub CLI 和 DSH 等，单独开一个 agent 账号，再配置谁可以派活。这更像工程团队的研究样机，不是普通人的“一键省事”。
所以，“普通人用 AI 干活能省多少事”，今天最诚实的答案是：省不了多少。你仍然要自己开窗口、讲背景、验收。Super-agent 现在省的是 DeepSeek 团队自己调度多个 Agent 的注意力；它把“一个人盯 3 到 5 个会话”这个隐性成本，写成了一个架构问题。
但这篇文章仍值得读，因为它把一笔平时算不清的账摊开了：你用 AI 省下的时间，有多少又还给了切换窗口、重讲上下文和等结果。少开两个窗口，把任务和验收标准一次写清，可能比等一个更聪明的 Agent 更早见效。
也有人不买账。知乎上有人担心，这种持续在线的协作者在实际工程里很容易因为任务失控，变成消耗算力和精力的负担。一位小红书博主说得更直接：这套架构在小团队里可能很神，进了大企业就会撞上部门扯皮和数据壁垒。这不是技术问题，是权限和利益问题。知乎小红书
团队写得直白：一旦云端的 Agent Loop 被服务端入侵或提示词注入攻破，它连接的所有端侧设备都可能被控制。这道坎不解决，Super-agent 就只能在小范围、可信的人之间用。DeepSeek Harness 团队
回到开头那个晚上。Super-agent 想替你省掉的，不是写合同那十分钟，而是你在四个窗口之间来回找“它刚才说到哪”的那几十次。这个愿景成立的前提，是你愿意把电脑、账号和群聊都交给同一个助手。在那之前，普通人能做的，是先把注意力从窗口里赎回来一点。
