DeepSeek Harness团队提出“Super-agent”架构，试图解决多Agent系统中日益明显的问题：单个Agent的上限取决于模型能力，但同时管理许多任务时，上限往往取决于人能盯住多少会话。方案用长期运行的Router统一接收消息、保存全局状态和分配任务，再让相互隔离的Worker执行具体工作；同时加入事件触发、线程订阅、异步工具调用、跨设备执行环境及独立Watchdog。初步合成实验显示，它完成一组并行任务的中位时间为12.4分钟，明显短于单会话Agent的20.4分钟；但代价是更高的Token消耗，并带来提示注入、凭证暴露和终端接管等新风险。公开代码只是研究原型，并非正式DeepSeek产品，文章中的部分设计尚未实现。
文章作者、来源：DeepSeek
真正稀缺的资源开始变成人的注意力
随着编程Agent能够持续工作数小时，用户面临的新问题不再只是“模型会不会做”，而是“人能不能同时管理足够多的任务”。
DeepSeek Harness团队观察到，一个人通常只能认真跟进三至五个活跃会话。会话数量继续增加后，用户需要反复检查进度、回答问题、重新解释上下文，并判断哪个Agent已经偏离目标。理论上可以并行运行几十个Agent，实际生产力却受到人的监督能力限制。
因此，团队把Super-agent定义为一种长期在线、主动响应事件并可持续交付结果的系统，而不是一次回答一个问题的聊天机器人。其目标不是让人打开更多会话窗口，而是尽可能减少人必须介入的时刻。
Router负责理解全局，Worker只负责把事情做好
核心架构分为两层。
Router长期运行，接收来自即时通信、GitHub、邮件和其他系统的事件，保存团队级上下文，并决定任务应该交给哪个Worker。它原则上不亲自执行代码，也可以完全不配备Shell工具，因此能够使用速度更快、成本更低的模型。
Worker则对应具体任务，每个Worker拥有独立上下文、工作目录和完整工具权限，通常由能力更强的模型驱动。Worker不直接找人沟通，而是把进度和结果交给Router，由Router判断是否需要通知用户。
这与常见的“一个主管Agent拆解一个复杂任务”略有不同：Router主要协调彼此相对独立、随时出现的工作，并维护任务间关系；它不负责规划每项任务的内部执行过程。
不是每条群消息都值得唤醒一个大模型
始终监听群聊和代码仓库会产生大量噪声。DeepSeek为此设计了两级事件过滤。
Fast Path使用确定性规则，根据消息来源、群组、用户身份及机器人白名单快速丢弃无关事件。只有可能有价值的内容才进入Slow Path，由语言模型判断是否应该创建任务、交给已有Worker，或者仅保存为背景信息。
系统还把群聊话题、GitHub PR和邮件往来抽象为Thread。Thread中的第一个事件由Router处理；一旦某个Worker订阅该Thread，后续消息便可以直接传给Worker，不必每次重新调用Router做决定。Router仍能看到全局状态，但不再成为所有消息的同步中转站。
实验显示，关闭这种“直通”机制后，整体完成时间变化不大，但Router需要作出的决策增加约30%，缓存读取量由约2320万Token升至3180万Token，增加约37%。这说明事件路由未必直接提高Worker速度，却能显著减轻中央协调层的负担。
把上下文窗口当缓存，而不是永久记忆
长时间运行的Agent不可能把所有聊天、代码、工具输出和历史任务永远塞在上下文窗口里。
团队提出两种处理方式：可能很快用到的内容直接放入当前上下文；体积过大或使用频率较低的材料则保存在外部，只留下引用指针。Trigger、Thread和Worker拥有唯一标识，并组成一张可追溯的引用图。Agent需要背景时，可以沿着这条“召回链”逐步找回相关事件，而不必一次加载全部历史。
这种设计类似计算机的缓存层次：上下文窗口负责当前工作集，数据库和外部文件负责长期状态。它无法彻底解决数月运行后的记忆压缩问题，但比不断追加聊天记录更可扩展。
主动工作不等于不断打扰人
文章给出的一个例子是“静默复现并修复”。
Super-agent在公共群聊里看到疑似软件问题后，可以在后台创建Worker，复现错误并尝试简单修复。如果确认问题并形成可靠补丁，再向团队提交结果；如果无法复现或没有得到可信结论，就保持沉默。
这体现了系统对“主动性”的理解：不是看到每条消息都发表意见，而是先用机器时间换取证据，只在用户需要决策或确实能使用结果时打断用户。
公开原型目前被定位为面向单一GitHub仓库的主动编程Agent，可选接入飞书；收到获准用户的工作请求后，它会建立任务、在独立目录中执行，并在原始讨论中回复，例如提交Pull Request。其公开说明将原则概括为“尽可能少占用人的注意力，同时提供尽可能多的价值”。
Agent工作时，用户仍然可以继续说话
传统ReAct循环通常是同步的：模型发起工具调用后，必须等待工具返回才能继续推理，也很难在执行长任务期间接收新的指令。
DeepSeek Harness提出全双工异步工具机制。Agent可以用`start()`在后台启动测试、构建或长时间脚本，同时继续接收消息；需要停止时再调用`stop()`。这样，用户可以在工具尚未运行完时补充条件或纠正方向。
文章还主张根据渠道调整表达方式：即时通信群里的更新应尽量短，GitHub PR和邮件则可以保留结构化细节。Agent不仅要决定“说什么”，还要判断“在哪个渠道、以什么密度说”。
计算、状态和执行环境被拆成三部分
Agent Loop本身可以放在无状态云容器中弹性扩缩；会话、任务和引用关系保存在持久数据库；真正执行命令的环境则留在用户设备或专用机器上，由一个轻量守护进程连接。
这种设计允许团队自带机器，也能容忍设备暂时离线：设备重新连接后，等待中的任务可以继续执行。
但它同时扩大了安全边界。云端Agent Loop与终端守护进程之间存在隐含信任；一旦Agent受到提示注入、服务器被攻破，或者凭证意外进入模型上下文，攻击者可能从一个事件入口影响多个终端。文章明确承认，系统还需要解决“使用凭证但不让模型看见凭证”、设备权限隔离及长期记忆污染等问题。
独立Watchdog因此被放在Agent体系之外，用另一会话观察基础设施、Worker是否真正取得进展，以及任务是否发生漂移。它还可以在系统运行期间调整提示词和事件规则，避免让被监督的Agent自行评价全部行为。
实验结果有吸引力，但远不是生产级证明
团队构建了一组合成多任务实验，每轮大约包含300条消息和20项工作请求，共重复五次。为集中测试调度能力，实际编程工作由耗时工具模拟，因此结果不能证明代码质量。
Super-agent完成全部任务的中位时间为12.4分钟，95分位为15.7分钟。普通单会话Agent在中性提示下分别为20.4分钟和29.5分钟，而且五次实验中一次也没有主动调用子Agent。
当提示词明确要求优先委派任务时，单会话Agent的中位时间降至13.8分钟，但95分位仍为29分钟；五轮中有一轮，它判断任务很小而选择自己处理，形成明显长尾。
Super-agent的速度来自稳定的并行调度，但缓存读取量约为2320万Token，远高于普通单会话方案的610万Token。换句话说，它主要用更多推理和缓存成本换取更少的等待时间与人工协调。
压力测试中，Router面对的待判断事件从每分钟约1条提高到40条后，平均批次由1条增至2.8条；单次请求耗时由2.5秒增加到3.9秒，但摊到每个决策上的时间反而由6.4秒降至1.6秒。团队认为当前规模一个Router已经足够，更大部署是否需要分片仍是开放问题。
公开的是研究原型，不是已经完成的产品
DeepSeek同步公开了`dsh-superagent-prototype`，采用MIT许可证。官方README明确表示，它只是供参考的研究代码，不是正式DeepSeek产品；公开版本与内部系统及文章描述并不完全相同，部分构想仍属于未来方向。代码大量由编程Agent参与生成，可能存在缺陷和不一致，部署前需要自行审查和修改。
这一区分很重要。文章描述的是一套希望长期存在于团队工作流中的Agent操作系统，而仓库目前主要展示单仓库编程Agent。外界不能因为代码已经上传，就认定Router分片、完整Watchdog、跨设备安全和数月记忆已经达到生产水平。
不过，它的价值不只在某个功能，而在于重新定义Agent系统优化的目标：当模型已经能够独立完成越来越长的任务，下一阶段竞争的重点可能不再是“能同时启动多少Agent”，而是“这些Agent能否在尽量不占用人的注意力时，持续交付可信结果”。