DeepSeek Super-agent：架构设想、内部实践与开源原型

DeepSeek Harness 团队讨论的 Super-agent，最容易被误解的地方是它的完成度。

团队提出了一套架构，也描述了基于 DeepSeek Harness 持续运行的内部实例。内部实例可以在即时通信工具（IM）与 GitHub 之间推进开发任务；有过在群聊中看到问题反馈后，尝试复现、修复再交付的实践。公开仓库 dsh-superagent-prototype 则只实现了其中一部分，用于验证技术路线。它不是 DeepSeek 的正式产品，也不能代表 DeepSeek Harness 现有功能的全貌。

因此，“一个 Agent 帮你盯住所有工作”目前更适合作为设计方向来理解。它想改变的交互方式很明确：用户只与一个持续存在的 Agent 打交道，系统在背后建立、调度和保存多个任务会话。会话应该是系统的实现细节，而不是用户的心智负担。

为什么多开几个会话还不够

让 Coding Agent 写一份调研报告，再整理邮件、制作 PPT，或者同时改几个代码问题，单个会话很快会遇到阻塞：工具执行要等，长任务没有结束，新的请求已经来了。多开窗口能让任务并行，却把协调工作交还给人。哪个窗口正在等测试？哪个拿到的是旧需求？一处决定改了，是否要再贴到另外两个窗口？

DeepSeek Harness 团队的经验是，一个人通常只能同时跟进 3 到 5 个活跃会话。这是一项来自团队实践的观察，不是经过普遍验证的人类注意力上限。数字背后的麻烦很具体：人要反复切换窗口、回忆进度、搬运上下文，还得判断某个任务是否已经偏离要求。

给单个会话接上邮件、代码仓库等外部连接器，能扩大它看到的信息，却不会自动解决这些问题。长操作仍可能堵住当前交互，不同任务的上下文仍可能混在一起；如果执行依赖某台本地设备，设备离线也不会因为 Agent 能读邮件而消失。

团队希望 Super-agent 具备四种特征：跨渠道保持连续，同时处理任务且及时回应的高效，能按事件判断是否行动的主动，以及长期运行的持久。这些是架构目标，不能逐项算作公开原型已经交付的功能。

一个 Router，背后是多条任务线

架构上的取舍是：单会话容易保住上下文，但难并发；每来一件事就开一个互不相干的会话，虽然能并发，却很难协调。Super-agent 在两者之间放了一个 Router。

Router 面向用户和外部渠道，接收事件、分派任务、掌握全局进展，通常不亲自执行具体工作。Worker 则负责某项任务：使用工具，保留与该任务有关的上下文，再把结果报给 Router。不同 Worker 的上下文隔离，避免一个代码修复任务的日志挤进另一项工作的推理过程。

可以把它想成一个前台和几张正在办理的工单。用户仍找同一个前台；工单可以分别推进，前台要知道它们各自到了哪一步。区别在于，这里的“前台”也要判断新消息属于哪条任务线，以及什么时候需要把两条线的信息合在一起。用户不必因此再打开一排聊天窗口。

Router 会不会成为新的堵点？设计允许它把等待中的多个 Trigger 放到下一轮推理中合批处理，不必每条都单独唤起一次推理。实验里能看到批处理的收益，但容量受上下文长度和模型处理能力限制。任务规模继续扩大后，Router 何时需要拆分，团队尚无定论。

设计文章把整个框架归为五个模块：双层架构、事件驱动、全双工多信道交互、计算／状态／执行环境分离，以及 Watchdog。也有讲解为了方便理解将它概括为“四块”；这是讲法不同，不是两个相互冲突的架构版本。

看到一条消息，离动手还差几步

设想有人在群聊里说一个功能坏了，或者在 GitHub 评论中补充复现步骤。系统首先观察到外部事件，但“看见”不等于“立刻执行”。事件进入 Trigger 机制后，要先经过程序化准入，再由模型判断语义上是否值得处理。之后才谈得上启动任务或继续已有任务。

持续发生的事件会归入相应的 Thread。如果 Worker 已订阅某条 Thread，后续事件可以由程序直接送到它那里，省去 Router 再作一次分派决策；Router 仍能看到事件，维持对全局状态的追踪。这样安排针对的是高频更新：一条任务下面反复出现评论、测试结果和补充要求，没必要每次都从头判断归属。

事件多了，上下文也不能无限增长。Inline & Spill 的处理思路是，把近期可能用到的信息放在当前上下文里，长内容留在窗口外，需要时再取。对象 ID 还能支持 Chain of Recall：从当前评论或任务线索，找回相关的旧任务与信息。它解决的是“沿什么线索找”，不意味着运行数月后的记忆整理已经有了完整答案。

内部群聊案例中，Agent 看到反馈后可以静默尝试复现；确认问题并找到简单修法，才把结果交出来，否则保持安静。这比“监听群聊，自动修好所有问题”多了几道关键限制。会议邀约到来后查日程、起草回复，也是架构方向的示例，不能当成公开原型已经普遍具备的日历能力。

公开原型还有一道更直观的限制：其默认主动接受策略为 observe，即记录本来会采取什么行动，并不真正执行。事件驱动描述的是系统如何决定是否行动；实际是否被允许行动，还取决于策略和权限。

前台不断线，执行环境仍有现实边界

任务一旦交给 Worker，耗时工具调用不该让整个交互一直等待。设计中的异步方式是调用 start() 发起操作，完成后把结果作为新事件送回；运行太久的操作可以用 stop() 中止。设计文章指出，这套异步任务机制已经在 DeepSeek Harness 中实现，但尚未默认开启。这一状态不能直接等同于公开原型的默认行为。

多信道交互也要求不同的汇报方式。Worker 的推理过程和工具日志不应直接刷进群聊。Router 在 IM 里可以少打扰，只说需要人知道或决定的事；在 GitHub、邮件或文档这类异步渠道，则应留下足够的背景、改动和验证信息。假如你在 IM 里说采用方案 A，又在 PR 评论里改成方案 B，系统需要识别这两处信息属于同一项工作，并让负责的 Worker 得到新决定。

长期运行还牵涉设备。架构设计把无状态计算放在云端、会话状态放在数据库中，具体执行环境留在端点设备，由端点 daemon 按需执行命令。如此安排，是因为有些命令必须在拥有工作目录或本地环境的设备上运行。设备离线时，依赖它的工作仍得等它重新上线；“持续在线的 Agent”不等于所有执行资源永远可用。

Watchdog 则被设计为独立巡检机制：除了接口是否故障，还要看 Worker 有没有空转、跑偏。不过，公开原型的实测中没有找到完整的云端计算与本地 daemon 分离，也没有找到外部 Watchdog 的实现；测试中的原型运行在本地。这两项应放在架构设计和内部实践的范围里讨论，不能据此宣称开源仓库已经具备跨设备常驻与自愈能力。

实验里的“更快”，具体快在哪里

DeepSeek Harness 团队做过端到端调度实验：每次约 300 条消息、20 条工作请求，每种设计运行 5 次。其中编码工作由只消耗时间的假工具模拟。因此，实验测的是多项任务如何调度、协调和完成，不是模型写代码的质量，也不是实际开发项目的交付速度。

在这组对照中，单会话方案的 5 次运行均未调用 subagent。Super-agent 完成得更快，同时读取了更多缓存 token。若只说时间下降，不说 23.2M 对 6.1M 的成本差异，就会把调度收益讲得过于轻松。这个对照也不能外推成“写代码速度翻倍”：假工具根本没有检验代码能否运行。

Thread 订阅直通的作用，可以从另一组结果看得更清楚。去掉直通后，任务完成时间在该实验中基本不变，但 Router 决定数增加约 30%，缓存读 token 从 23.2M 增至 31.8M，约增 37%。直通主要省掉重复分派的决策和推理开销，并未在这组负载下显著缩短完成时间。

Router 的批处理压测也给出了一个范围有限的答案。当需要决策的 Trigger 到达速率从每分钟约 1 条升至 40 条，平均批大小从 1.0 增至 2.8；单个请求的耗时从 2.5 秒增至 3.9 秒，但每个决策摊销的推理时间从 6.4 秒降至 1.6 秒。合批提高了处理效率，也增加了单个请求的等待。结果来自特定压测负载，不能据此推断 Router 能无限扩展，或真实生产环境一定有相同表现。

原型可以接 GitHub 的活，验收仍要靠人

公开的 dsh-superagent-prototype 使用面比完整架构窄得多：它围绕 GitHub 仓库接收符合策略的请求，创建独立任务，交付代码供人检查。对愿意拿测试仓库研究事件驱动协作的小团队，它提供了可以动手观察的对象；对想直接接入邮件、日历和多台设备的普通用户，它还不是成熟产品。

一次公开视频实测里的番茄钟任务，正好说明“交付”和“可用”之间的距离。原型约 9 分钟交出初稿，但按钮实际不能正常工作；测试中的假时钟掩盖了问题。作者反馈后，又用约 7 分钟完成修复。另一个 BMI 计算器项目约 8 分钟完成，示例中 170 cm、65 kg 得到约 22.5 的结果。整段测试费用约 2.1 元。这些时间和费用只属于该作者的一次测试，不能当作官方性能基准或稳定价格。

部署门槛同样具体。该作者在 Windows 环境中需要额外配置，也遇到过模型凭据问题；这些经历不能推断所有环境都会如此。部署建议包括使用专用 GitHub 账号和独立系统账号隔离，先保持 observe 策略，暂缓自动合并。原型涉及较高执行权限，能不能运行和应不应该放权，是两次不同的判断。具体配置与兼容性还应以仓库当时的文档为准。

会话隐藏以后，人怎么接管

把会话从用户界面上移走，不等于任务状态可以不透明。用户仍需要知道有哪些 Worker 在工作、哪些结果经过验证、哪一步正在等待设备或人的决定。遇到影响代码合并、外部回复和本地命令执行的操作，还要有明确的介入位置。

规模问题也未解决：Router 何时分片，Worker 之间何时值得直接通信，运行数月后的旧信息该保留多少、怎样找回，团队都还没有确定答案。当前设计和实验展示了可行的调度方向，尚不足以证明它能长期管理任意规模的工作。

权限边界尤其不能靠“Agent 会自己判断”来代替。监听的群聊、评论和邮件越多，进入系统的不可信内容也越多，外部事件可能携带提示词注入。若云端 Agent 与本地端点互信过宽，服务端受侵害可能波及设备；本地凭据进入模型上下文，也带来泄漏风险。这些是广泛部署前需要解决的问题，并非公开原型已经提供了完整保障。

Super-agent 值得关注的设计变化，是试着让系统承担会话分派和上下文搬运，让人把时间用在决定优先级、处理例外和验收结果上。公开原型已经能展示其中一段工作流，但在更大权限、更长运行时间和更多外部渠道面前，仍需把每一步可见、可控和可验证做扎实。