10月31日晚，DeepSeek Harness 团队在官方公众号发布了技术长文《Super-agent 设计探索：迈向更自主的 Agent 系统》，同日在 GitHub 以 MIT 协议开源了配套原型仓库 dsh-superagent-prototype。但要先说清这次发布的是什么：它不是一款新产品，原文开篇自我定位是面向工程实践的架构思路探讨，配套插件只是为验证技术路线提供的原型。DeepSeek 这次交出来的，是一张“路线图”加一个“能跑起来的切片”。微博知乎微信公众号
多任务的天花板，是人的注意力
这套设计想解决的问题，来自每个用过 Coding Agent 的人都碰到过的瓶颈：主流 Agent 以单个会话为基本单位，会话彼此独立，想同时推进几件事，就得自己切换、记住各会话的上下文。文章的判断很直白：单任务的上限取决于模型，多任务的上限取决于人的注意力。据团队观察，一个人通常只能同时跟进 3 到 5 个活跃 Session，再往上，谁在干什么就记不住了。知乎微信公众号
团队想要的形态，是一个跨会话保持上下文、能同时推进多项复杂任务且互不干扰的“连续实体”，他们称之为 Super-agent。四个基础特征是连续、高效、主动、持久：始终接入 IM 和 GitHub 等真实工作环境，从环境事件里主动识别值得处理的事，长期运行遇到异常能自动恢复。知乎微信公众号
解法：一个管调度的，一群干活的
架构核心是把“维护全局连续性”和“高并发执行”拆成两层：Router 层常驻，统一承接人类交互与全局协调，用较轻量的模型往往就够；Worker 层上下文隔离、并发执行，配置最强模型决定交付质量。用户面对的始终是同一个 AI，Session 退居为实现细节。更直观的验证场景是他们在内部用户群配置的“静默复现并修复”：群里有人反馈问题、没人 @ 它时，Agent 先在后台复现、找修复方案，确认问题并找到简单修法才交出结果，否则全程不出声。传播里“AI 没人 @ 就自己发现 Bug、提交修复 PR”的说法，出自这里。微信公众号知乎
其余模块都围绕同一个目标：环境事件先经程序、再经模型两级过滤；上下文窗口当作 Cache 来管理；耗时工具改为异步调用，后台干活不卡前台对话——这套异步机制已经在 DeepSeek Harness 中实现，但尚未默认开启。执行环境也留在用户自己的机器上，云端只跑循环、端侧装轻量 daemon，再配一个独立的 Watchdog 会话定时检查各任务有没有实质进展。微信公众号
实验数字：用更多 token 换稳定的时间
端到端消融实验里，每次约 300 条消息、约 20 条工作请求、每种方案重复 5 次，Super-agent 完成任务的 p50 是 12.4 分钟、p95 是 15.7 分钟；对照组带 Subagent 工具的单 Session 方案受提示词影响极大，中性提示下 5 次运行一次都没有委派，p95 到 29.5 分钟。去掉订阅直通后，任务完成时间基本不变，但 Router 决定数增加约 30%、总读缓存 token 从 2323 万涨到 3177 万，增幅约 37%——直通省的是调度开销，不是时间。需要留意的是，这两组实验全部出自 DeepSeek 自测，基于合成负载，编码环节用只耗时的假工具代替。知乎微信公众号知乎
离大规模可用，还差一道安全题
文章把最难的问题留在明处：云端 Agent Loop 一旦遭遇服务端入侵或提示词注入，其连接的全部端侧设备都面临被控制的风险。对此原文没有回避：如果没有办法很好的解决安全与隐私问题，那么 Super-agent 只有在一个很小且可信的范围才能工作。 对普通用户，这相当于一条红线：别急着把整套工作环境交给一个常驻 AI。对打算上手的人，还有一处落差要心里有数：开源的是一个缩水的切片，最难的云端常驻和跨设备部分没在里面。微信公众号知乎
目前把这套思路跑在日常环境里的还是 DeepSeek 自己：内部 Super-agent 实例已在持续运行，参与问题复现与修复、代码审查响应与 DeepSeek Harness 的迭代。外界盯着的 DeepSeek 下一代产品会不会用上这套架构，目前没有官方说法。值得盯的信号有两个：安全与隐私机制是否补进仓库，异步任务等模块是否随 Harness 正式产品默认放开。微信公众号知乎
