用 AI 写代码的人大多有过这种时刻：三个窗口同时跑，一个改接口，一个等测试，一个卡在权限报错。去倒杯水回来，先花两分钟回忆每个窗口聊到哪了。 任务没多复杂，人先成了调度器。知乎
DeepSeek Harness 团队把这层体验写成了架构问题。他们的观察很具体：一个人通常只能同时跟进 3 到 5 个活跃 Session。 所以单任务的上限看模型，多任务的上限看人的注意力。DeepSeek
它没有做一个更好的多窗口管理器，而是把 Session 收进系统内部，不让它成为用户要记的东西。上层是常驻的 Router，接住来自 IM、GitHub、邮件的事件，判断任务之间的关系再分派；下层是上下文隔离的 Worker，各自带着完整工具并行干活。用户看到的始终是一个 Agent，不必再记住「第 3 个窗口里那个 Session 说到哪了」。原文把这层意思说得很直白：Session 应当是系统的实现细节，而不应是用户的认知负担。DeepSeek
最先松开的是长任务对对话的阻塞。经典 ReAct Loop 里，模型发起一个同步工具调用后，整个循环要等结果返回；代码跑十几分钟，这十几分钟里它接不了新指令。Super-agent 把 run() 拆成 start() 和 stop()，后台任务先返回「已启动」，完成后再把结果作为新事件投递回来。前台可以继续聊，后台继续跑，这套异步机制已在 DeepSeek Harness 中实现，但尚未默认开启。
长任务不再堵住对话之后，另一处卡点才显出来：人一离开工位，任务还是停。本地 Agent 把计算、会话状态和执行环境绑在同一台机器上，电脑一休眠，循环就断了。按照 Super-agent 的设计，Agent Loop 放进云端无状态容器，会话状态存数据库，只在用户机器上留一个轻量 daemon，负责执行命令、返回结果。未提交的代码、私有凭据、内网服务都留在原地，Agent 却不必跟着某台电脑一起下线；设备重新上线后，云端还能触发需要在这台设备上完成的任务。
设备不再是边界之后，Agent 才有条件从「等人派活」变成「自己找活」。群聊消息、CI 结果、PR 评论都成了输入。系统先用确定性规则滤掉噪音，再把候选事件交给模型判断；同一个 PR 或话题的后续消息，可以直接订阅给负责的 Worker，不必每次都绕回 Router。原文举的例子是，内部实例会在无人 @ 的情况下，从公共群聊的反馈里定位根因并提交修复 PR。DeepSeek
但「不用手动切会话」只是表面。真正被接走的是调度、等待和来回同步；留下来的仍然是判断和验收。原文自己也把边界写得很清楚：这是一篇架构探讨，配套的 dsh-superagent-prototype 只是验证技术路线的原型，并非正式产品。 实验也基于合成负载：Super-agent 的 p95 完成时间是 15.7 分钟，单 Session 中性提示下是 29.5 分钟。数字差距明显，代价是更高的 token 消耗。DeepSeek小红书
更现实的阻力在别处。云端 Agent Loop 要持续接入外部事件，端侧又存着代码和凭据；一旦云端被提示词注入攻破，连接的所有设备都可能被控制。 原文把这列为尚未解决的问题，也没有给出完整答案。还有人从业务角度泼冷水：投机执行在后台同时跑几个备选方案，猜不中就丢掉，这种「主动」在真实公司里可能先变成算力账单。 技术能解决并发的物理极限，但解决不了权限、数据和利益分配。DeepSeek小红书
所以，Super-agent 值得关注的不是「又少点几次鼠标」。它把「谁来决定下一步做什么」从人手里分走了一部分，也把人的位置往验收端推了一截。对同时推进多个项目的人是实在的减负；对只想让 AI 替自己拍板的人，它暂时还接不住。
