摘要 据 DeepSeek 介绍，内部 Super-agent 实例在用户群里没人 @ 时，也会自己复现 bug、提交修复 PR，前提是团队配置了一条规则。这次公开的是这套架构的设计文章和一个开源研究原型。
DeepSeek 的内部用户群里，有人抱怨 macOS 桌面端的一个 bug：点一下没聚焦的窗口，会话会被误识别成双击进入重命名，每天要误触几十次。没人 @ 群里的 agent，它却在后台复现了问题、查了代码，最后在群里回复：已修复并提交 PR，附前后对比图，根因是 Electron 默认吞掉激活窗口的那次点击。
标题里那一幕：没人 @ 它，它修好了 bug
这一幕不是 agent 自己突然决定去做的。DeepSeek 在公司内部的 DeepSeek Harness 用户群里，专门配置了一条“静默复现并修复”策略：有人在群里反馈问题或讨论改动方案时，agent 先在后台尝试复现、找修法，只有确认了问题、找到了简单的修法，才把结果交给人，否则全程不说话。同一套规则下还有另一个例子：群里还在讨论波浪号被渲染成删除线该怎么改，它已经在后台提交了修复 PR。
这两个例子出自 DeepSeek Harness 团队（DeepSeek Harness 是 DeepSeek 做的 agent 运行框架）10 月 31 日晚在官方公众号发的《Super-agent 设计探索：迈向更自主的 Agent 系统》，团队同时在 GitHub 开源了 MIT 协议的研究原型 dsh-superagent-prototype。文章开头就说明，这是架构思路的探讨，并非对 DeepSeek Harness 现有产品功能的介绍；README 也写明原型不是 DeepSeek 的官方产品，和内部版本不完全一样，文中有些设计只是未来方向。
它想解决的问题：人的注意力成了上限
过去一年，编码 agent 已经证明，模型能用工具解决复杂问题，越来越不需要人一步步盯着。但现在的 agent 大多以单个会话（session）为单位，会话之间互相独立：同时推进几件事，人就得在几个窗口之间切换，记住每个窗口聊到哪了。DeepSeek 的观察是，一个人通常只能同时跟进 3 到 5 个活跃会话。用他们的话说，单任务的上限取决于模型能力，多任务的上限取决于人的注意力。
文章也提到，只在本地单会话 agent 上接一些外部工具，它虽然也能收到群消息，但仍会遇到会话同步阻塞、多个任务的上下文混在一起、本地设备离线就停的问题。他们的答案是让 agent 不再绑定在一次次手动会话上，变成一个常驻、连续的实体，并给它定了四个特征：持续、高效、主动、持久。
“持续”最好理解：用户先在群里提了需求，后来在 GitHub 的 PR 评论里改了做法，它能接上，用户感觉始终在跟同一个 agent 打交道。
贯穿全文的原则，是尽量少占人的注意力。原型仓库的设计理念文档说得更直接：每条消息、每个通知、每个提问都要花掉别人的注意力，带来的价值必须比这更多。落到细节上，他们验证过的一条硬规定是：在群聊这类即时通讯渠道里，单次回复不超过 100 词。
怎么做到的：拿报 bug 这件事走一遍
还拿群里报 bug 这件事来说。群里每天有大量闲聊，CI（代码提交后自动跑的构建和测试）结果也在不停推送，绝大多数不需要 agent 管。所以消息进来先过两道筛：第一道是写死的程序规则，比如看是哪个群、谁发的，直接放行或丢掉；过了关的才交给模型，按团队用提示词写的策略判断要不要管。
判断要管，就交给 Router 层（路由层）。它是常驻的总调度，记得各个任务的来龙去脉，但自己不动手，而是开一个 Worker：一个上下文单独隔离的会话，专心复现、修这一个 bug。Worker 修完向 Router 汇报，由 Router 在群里统一回复。这样各个任务不会挤在一个会话里互相干扰，也不会因为各开各的会话丢掉全局上下文。
报 bug 的人如果接着补充细节、改了要求，这条消息不用再让 Router 判断一遍：Worker 接手时就“订阅”了这条讨论，后续消息由程序直接送到它那里，文章叫“订阅直通”。如果人在 agent 干活中途插话，文章设计的异步机制能让它在当前这一步推理结束后就处理新消息，不用等后台任务跑完；这个机制已在 DeepSeek Harness 里实现，但默认没开。
长期在线还得能自己恢复。agent 的运行放在云端、会话状态存进数据库，再连回用户自己的电脑干活（文章叫 BYOM，自带机器），不再跟着某一台电脑开关机。外面另有一个 Watchdog（看门狗）定时巡查，不光看服务有没有挂，也让模型判断各个 Worker 有没有实质进展、有没有跑偏，发现问题就介入修复。文章提到，这和 Anthropic 提出的“脑手分离”思路一致，区别在于 DeepSeek 首先要接的是用户日常在用、可能时不时离线的个人电脑。
数据和风险：官方自己说只能当初步参考
文章做了一组初步实验：约 300 条群聊和 CI 消息里，约 20 条是真正的工作请求，其余是闲聊、跟进、叫停；写代码的部分用一个只耗时间的假工具代替，所以测的是调度和协作能力，不是写代码的能力。结果是 Super-agent 一半的任务在 12.4 分钟内完成，95% 的任务在 15.7 分钟内完成；对照方案是一个会话加 subagent（主会话可以把活分出去的子 agent），在不特意催它分活的提示词下，95% 的任务要 29.5 分钟。
代价是 token。维持多个会话，读缓存 token（模型每次调用时重新读入的、已缓存的上下文）比单会话更多。前面说的订阅直通能省下一部分：去掉它，完成时间基本不变，但 Router 要做的判断多了约 30%，读缓存 token 从 2323 万涨到 3177 万，约多 37%。文章明说实验基于合成负载和简化环境，结果只供初步参考。
风险部分，文章自己也没回避。云端的 agent 一直接着外部的群聊和代码平台，而接入的个人电脑上有私有代码、敏感数据和本地凭据；一旦云端被入侵或遭到提示词注入，所有接入的设备都有被控制的风险。即使云端没出事，只要凭据能进入模型的上下文，正常运行中也可能泄露。
想自己试试，先知道开源版默认是什么样
如果你想动手，先把预期调对：开源原型默认不会像标题那样没人叫也干活。
按 README 和设计理念文档，开源原型是一个盯着单个 GitHub 仓库（可选再接飞书）的编码 agent，打包成 DeepSeek Harness 的一个组件。它只在被允许的人直接请求、或者团队写好的规则允许时才行动；没人请求的主动工作必须有团队写的规则，而且一开始只记录它本来会做什么，不真的动手。干活时它保持安静，只在出了结果、需要人决定或做不完的时候说话。
具体的路子按官方文档来：先读仓库里的 docs/000-philosophy.md，理解它的原则；再按 README 的建议，让你常用的编码 agent 读 SETUP.md，带你把它接到一个测试仓库上。考虑到前面说的安全风险，别接存着敏感代码和凭据的环境，权限给到最小。设计理念文档给运营者的建议也值得照做：允许的人员名单短一点，主动工作先只记录，看它判断得对了再放开；它太吵，就把提示词改短改严，或者先暂停。