一款旨在同时管理多项工作的编码智能体
DeepSeek的Harness团队于2026年10月31日发布了Super-agent设计，并同步推出一个采用MIT许可证的研究原型，可将针对GitHub代码库的请求拆分为独立的编码会话。其目标是让多项工作并行推进，同时减少开发者在不同对话间切换和检查进度所花的时间。
目录
团队的初步实验使用了约300条模拟消息，其中包含约20项工作请求。Super-agent在12.4分钟内完成了一半任务，15.7分钟内完成了95%的任务。作为对照，在中性指令下，一个可调用辅助智能体的单主会话系统，用时29.5分钟才达到95%的完成率。
DeepSeek的公开原型代码库名为dsh-superagent-prototype，提供了范围更窄、注重实用的版本：一个面向单个GitHub代码库的主动式编码智能体，以套件形式集成到DeepSeek Harness中。它会监听GitHub，也可选择监听飞书；经授权的人员提出工作请求后，它会创建工作项，并在原对话中回复，必要时还可能提交一份包含代码修改建议的拉取请求。
README也明确发出警告：已发布代码与内部系统及设计文章中的部分内容并不相同。一些拟议功能仍在计划中，DeepSeek将此版本称为研究代码，而非成熟产品。
维护该原型的DeepSeek Harness团队在README中说明了其状态：
仅供参考的研究原型，并非DeepSeek官方产品。
对开发者而言，此次发布提供了可供检查和改造的代码。其核心探索在于智能体如何组织工作、记住相关对话，以及判断何时需要人工介入。
DeepSeek为何希望隐藏会话管理
DeepSeek的设计始于团队在实际工作中的一个观察：一个人通常只能同时跟进三到五个活跃的智能体会话。每个会话都有各自的对话历史，因此开发者必须记住每项任务对应哪个会话，以及各个智能体收到了哪些指令。
Harness是围绕AI模型运行的软件，用于管理工具、文件、对话和执行过程。模型负责推理任务；Harness则决定任务如何交给模型，以及模型的操作如何执行。Super-agent将更多多任务协调工作交由这层外围软件处理。
团队列出了四个目标：跨对话保持连续性、高效并行执行、主动响应事件，以及持续运行并从故障中恢复。举例来说，开发者可能在聊天中选定一个方案，之后又在GitHub评论中修改方案。系统应能关联这两次交流，并相应调整同一项任务。
此次发布紧随DeepSeek于10月3日在Harness v0.2.1-alpha.1中开展的实验，该实验测试了与Claude Code扩展的兼容性。那次更新测试的是扩展桥接；Super-agent探索的则是Harness本身如何协调持续进行的工作。资料显示，系统由Yujia Qiao负责实现并撰写设计文章，另有15人参与评审和讨论。
一个Router负责协调，多个Worker负责执行
Super-agent将职责分配给常驻的Router和多个独立Worker。Router接收人与系统的交互，维护各项任务共享的信息，并分配工作。它不会亲自编写代码，从而能在其他会话繁忙时继续承担协调职责。
Worker负责具体任务。每个Worker都有独立的对话上下文和执行工具，因此调查缺陷、回复代码审查意见和修改功能可以同时进行。Worker将结果报告给Router，由Router与用户沟通，避免多个会话各自独立回复。
DeepSeek表示，路由工作通常可由较轻量的模型处理，而决定代码质量的工作则交由能力更强的模型。遇到复杂任务时，Worker也可以创建辅助智能体。Router负责管理不同任务之间的关系，而不是规划每项任务内部的每个步骤。
该原型为每项工作创建独立的会话和目录，并在设定的并发上限内同时启动任务。因此，运营人员可以控制同时启动多少项工作。独立的对话历史降低了某项任务的细节挤占另一项任务上下文的可能性，Router则保留全局视图。
消息如何变成任务，又不造成持续打扰
聊天消息、代码审查评论和自动化测试结果都可以成为触发操作的事件。更广泛的设计还考虑了电子邮件和日历提醒。持续集成（CI）是指在代码变更后自动构建或测试代码的检查流程，智能体可以根据检查结果采取行动。
DeepSeek分两个阶段筛选这些事件。首先，普通程序规则会检查事件来源、群组和授权用户等事项；随后，模型结合上下文和书面策略评估剩余候选事件。这样可以避免对无需处理的日常消息调用模型。
相关事件会归入同一个Thread，例如某个拉取请求下的评论，或某个聊天主题。Worker接手任务后，会订阅相应Thread。后续评论和测试结果可以直接发送给它，无须再让Router重新分配。
订阅可以重叠。多个Worker若同时处理同一个拉取请求，就能收到相同更新，从而发现影响各自工作的变化。Worker也可以关注多个相关Thread，或者在事件超出其任务范围时将其交回Router。
主动行动，但只在有用时发声
DeepSeek表示，内部的Super-agent已在持续运行，能够复现并修复问题、回应代码审查，并协助开发Harness本身。书面规则允许它调查群聊中提到的缺陷，即使没有人直接提及该智能体也可以这么做。
规则要求先安静地调查。智能体会尝试复现问题并寻找简单的修复方案，然后给出有用的结果。一个例子中，开发者正在讨论波浪号被显示为删除线的问题，而智能体已经提交了一份包含拟议修复方案的拉取请求。
Harness团队在README中这样概括其运行原则：
尽可能少占用人的注意力，同时尽可能多地创造价值。
该原型会在授权人员提出请求，或团队制定的规则允许时采取行动。其网页面板会列出需要人工关注的工作项。这样，界面便聚焦于待决事项和可用结果，而非每次工具调用或中间思路。
让旧上下文和新指令随时可用
DeepSeek的设计将模型上下文窗口，也就是模型一次能处理的信息量上限，视为一种缓存。经常需要的材料会留在手边；较长或相关性较低的历史则留在窗口之外，直到有需要时再调取。
设计文章将这两种操作称为Inline和Spill。Inline会把有用细节直接放入当前上下文，例如附近的聊天消息、标识符或简短预览。Spill则将较长内容留在别处，并提供引用，供模型进一步读取。
Chain of Recall会串联这些引用。事件、Thread和Worker会话都有唯一标识符，使智能体能够从当前消息追溯到相关讨论，再找到关联的Worker和另一条代码审查记录。目标是在不同渠道间找回旧任务，而不必反复加载其完整历史。
DeepSeek还处理了一个更直接的中断问题：长时间运行的命令可能会阻塞传统智能体，使其无法及时回复。其异步机制会在后台启动任务，并将结果作为新事件发回。用户可以继续下达指令，包括要求智能体改变方向或停止工作。
团队称，这一机制已在DeepSeek Harness中实现，但默认未启用。不同渠道的沟通规则也有所不同：设计规定，即时消息的单条回复不超过100词；而拉取请求和文档则会对修改内容及验证过程作出更有条理的说明。
云端协调，任务在本地电脑上执行
DeepSeek将运行智能体的计算资源、存储的会话历史，以及执行命令的机器分开。拟议方案是在云容器中运行智能体循环，将会话状态存入数据库，再由轻量级本地服务执行命令并返回结果。
这种安排支持自带设备（BYOM）。开发者可以连接已有电脑，直接使用其中的代码库、工具和未完成的修改，而不必将所有内容迁移到新的远程环境。即使电脑断开连接，云端协调仍可继续；需要这台设备执行的任务则会等待设备重新上线。
独立的Watchdog会话负责检查故障和停滞的工作。它不仅会检测错误信息，还会运用模型判断Worker是否取得实际进展，或是偏离目标，并在需要时尝试恢复。
DeepSeek将这些要素视为更广泛架构探索的一部分。README提醒，公开发布的套件与内部实现并不相同，因此开发者在依赖某项具体设计功能前，应先检查已发布的代码。
实验测量了什么
DeepSeek对每种实验配置重复测试了五次，将Super-agent与一个不支持直接传递事件的版本，以及两种配备辅助智能体的单会话配置进行比较。测试负载使用了合成消息和一个模拟长时间编码工作的工具。消息间隔和工作时长均缩短至原来的四分之一。
12.4分钟的中位数意味着一半任务在这个时间点前完成；15.7分钟的第95百分位数意味着95%的任务在此时间内完成。与中性条件下单会话系统的29.5分钟第95百分位数相比，Super-agent将这一指标缩短了13.8分钟，约为47%。
任务委派行为有助于解释这一结果。在中性指令下，单会话系统在五次测试中一次也没有调用辅助智能体。收到优先委派的提示后，它在四次测试中进行了委派，在第五次则自行处理。Super-agent则从架构上明确区分了协调与执行。
测试评估的是调度和协调能力，执行过程则由模拟完成。实际编码质量、独立性能测量和活跃用户数量均未公布，团队也将这些测量结果称为初步数据。DeepSeek尚未公布正式产品的发布日期。
更快的协调会使用更多缓存Token
Super-agent的并发能力伴随着更高的缓存输入用量。它读取了2323万缓存Token，而两种单会话配置分别读取605万和1082万。Token是模型处理文本时使用的基本单位；缓存读取则会复用此前请求中保留的输入。
移除直接事件传递后，缓存读取量从2323万升至3177万，增幅约37%；Router的决策次数则增加约30%。因此，在并行设计中，将后续事件直接发送给已接手任务的Worker，可以减少协调工作。
批处理有助于Router应对更高的消息流量。当事件到达速度从每分钟约1次升至40次时，平均批次大小从1.0增至2.8，请求耗时从2.5秒升至3.9秒。报告称，分配给每次Router决策的推理时间从6.4秒降至1.6秒。
实际取舍在于减少人员等待时间的同时，让模型在多个独立会话中处理更多内容。Token数据并未给出具体费用；考虑部署的团队还需结合模型价格、并发设置和实际工作负载进行评估。
本地权限使安全成为核心问题
该原型的执行文档指出，Worker命令会在操作人员的操作系统账户下运行，无须审批。前台Shell命令运行五秒后会转入后台执行，后台任务每轮最长可运行30分钟。这些设置意味着，操作人员账户所拥有的权限将直接影响部署安全。
已连接的机器可能存有凭据、私有代码和敏感文件。当传入消息或代码库内容可能影响这台机器上的命令时，提示注入问题就格外严重。提示注入是指恶意内容试图通过智能体读取的材料诱导其改变行为。
DeepSeek指出，安全与隐私、Router扩展能力、长期记忆，以及智能体实例之间的通信，都是尚待完善的领域。README要求用户审查并调整代码，并提醒其中可能仍有缺陷和不一致的工程实践。开发工作本身也有相当一部分由编码智能体完成。
该项目发布后迅速受到关注，其中包括Hugging Face研究负责人Leandro von Werra发布的帖子。以下时间线显示了原型传播之快：
- 2026年10月31日09:32 UTC：GitHub代码库创建。
- 10月31日：Harness团队发布设计文章；截至22:10 UTC，代码库已获得2046颗星和172次复刻。
- 11月1日04:20 UTC：代码库星标数达到3433。
对工程团队而言，当下要决定的是是否检查并改造这一实验性协调系统。它的吸引力在于有望以更少的打断处理更多工作；但要投入使用，团队还需要审查代码、设置权限，并决定哪些操作必须由人员处理。
要点
- DeepSeek发布了一款采用MIT许可证的研究原型，可处理单个GitHub代码库中的编码工作，并可选接入飞书。
- Router负责协调，多个独立Worker并行执行任务。
- 根据书面规则，内部系统可以调查已报告的缺陷，即使没有人直接提及它也能行动。
- 合成测试的任务完成时间中位数为12.4分钟，第95百分位数为15.7分钟；其缓存Token用量高于单会话方案。
- Worker在操作人员账户下执行命令，无须审批，因此权限和凭据管理是关键问题。
- 公开代码与内部系统并不相同，目前仍是研究原型，并非DeepSeek官方产品。
