AREX Feed Article
DeepSeek 开源 dsh-superagent 研究原型：面向单一 GitHub 仓库的主动式编码 agent
10 月 31 日，DeepSeek 在 GitHub 的 deepseek-ai 组织下创建了仓库 ，仓库描述为《Towards a More Autonomous Agent System》，MIT 许可、以 TypeScript 编写。截至 11 月 1 日发稿，该仓库已有 3,854 个 star、362 次 fork（）。其中的 是一个面向单一 GitHub 仓库的主动式（proactive）编码 agent，打包为 的 bundle（插件包）：它监听 GitHub、可选接入飞书（Feishu），获允许的请求者提出工作请求时，它会开启一个工作项（work item），在自己的 agent 会话与目录中完成工作，再回到原来的对话里回复——例如附上一条 pull request。
README 开头第一段就把性质说清楚：这是仅供研究参考的原型（research prototype for reference only），不是 DeepSeek 官方产品；代码源自团队日常开发，相当一部分工程由编码 agent 完成。与开源同日，DeepSeek Harness 团队在微信公众号发布设计文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，文末写明「Yujia Qiao 完成了系统实现和本文写作」，把原型背后的架构与实验数据完整摊开（）。
图：《Super-agent 设计探索》一文给出的 Super-agent 整体系统架构，标号 [2] 至 [6] 对应文章第 2 至第 6 节的五个模块（图源：微信公众号原文）。
监听、准入、开工、回话：一张工作单的生命周期
以下流程按仓库文档自述整理。README 与 描述的接入单位叫 Source（来源）：GitHub 仓库必配，飞书可选。GitHub 侧的监听范围覆盖新 issue、新 pull request、评论和默认分支的 CI 结果；飞书侧按配置的群与私聊接收消息，配置卡片上保留着「其他群」「仅 @」「全部消息」这样的中文开关。
不是每条消息都能让它动起来。消息先经 Source 的准入表判定：名单上的成员直接对 agent 说话，构成显式请求；文档也允许把某个接收范围配置成「任何人 @ agent 都算显式请求」，举的用途是专门的客服群。机器人永远不能提出显式请求，也不能叫停工作。请求通过判断后，系统开出一张 Ticket（工作单），交给 Executor（执行会话）在隔离上下文与独立目录里干活：干活期间保持安静，结束才把结果写回原来的对话线程。
「主动」的部分由规则管住。文档定义了三种 accept mode（接受模式）：off、observe（默认）与 auto。默认的 observe 模式下，推断出的候选请求只做评估、记为忽略并标注 would accept（本会接受），并不真正开工；团队翻看这些记录、确认规则写得对，再切到 auto。每张工作单都携带 Mandate（授权凭证），记录触发它的规则与当时的 Policy 版本；把人移出允许名单，可能让经该名单接受的工作单在恢复前的复验中被吊销。
人工介入集中在面板。README 只写了一句「web 面板显示需要人的事项」， 则写明：面板就开在 DeepSeek Harness Web 侧边栏里，名叫 Superagent，打开先回答三个问题——有没有事需要我现在处理、系统是否健康、某件工作从 Trigger（触发事件）到 Eval（准入判断）再到 Ticket 的来龙去脉。健康状态不占版面；需要人处理的条目会直接给出操作入口。
连安装都交给 agent：README 建议对自己的编码 agent 说「读这个仓库的 SETUP.md，和我一起把 dsh-superagent 装起来」，它会一次问一个短问题、先展示完整计划，再执行安装与配置（）。
行为守则：尽可能少占用人的注意力
把核心原则写成一句话：「尽可能少占用人的注意力，尽可能多地给出价值。」README 里还有一句更直白的推论：「一个能为整个团队干活的 agent，也能浪费整个团队的注意力。」项目里的每条消息、每个通知、每个问题、每个设置、面板上的每个元素、每段文档，都要挣回自己消耗的注意力，否则删掉。
文档给 agent 定的行为守则包括：只在被请求、或团队写下规则允许时行动；说话只在有人必须行动、或有人能用上结果的时候，干活期间不出声；一次只问一个具体问题；按影响收尾而不是按工作量，需要设计决策就停下来提问；如实汇报，草稿标注未完成，失败就报失败，不绕过限制来省去提问。
守则之外还有一节「责任」：agent 用团队天天可见的账号发评论、开 PR、私信同事，操作者要对它说的话负责。文档给出的做法是从很短的允许名单起步、主动工作先只记录不执行，看着对了再放宽；agent 变吵就改提示词、收紧规则，而不是加消息解释噪音；不要拿它冲产量——批量 PR、广播消息和琐碎杂活消耗的注意力比给出去的多。
设计文章拆解 Super-agent：五个模块与「初步参考」的实验数据
微信文章把「一个人通常只能同时跟进 3 到 5 个活跃 Session」当作出发点，并给出一句判断：「单任务的上限取决于模型能力，多任务的上限取决于人的注意力。」它把跨会话（Session）保持上下文、并行推进多项任务、持续在线的 agent 形态称为 Super-agent，归纳出连续、高效、主动、持久四个特征，并给出五块支撑模块：Router/Worker 双层架构；事件驱动，即 Trigger、两级过滤、订阅直通、Inline & Spill（内联与溢出）上下文管理与链式召回、投机执行；面向人的多信道交互；计算、状态与环境的分离；以及主系统之外的 Watchdog（看门狗会话）。
图：文章配图展示的「静默监听—后台复现—提交修复 PR」流程。注意这是文章描述的 DeepSeek 内部 Super-agent 实例，而非已开源的原型（图源：微信公众号原文）。
文章称，基于这套思路与 DeepSeek Harness 构建的内部 Super-agent 实例已在持续运行，日常参与问题复现与修复、代码审查响应和 DeepSeek Harness 自身的迭代。配图给出的样例是：产品用户群里有人抱怨 macOS 桌面端窗口未聚焦时点击会话被识别为双击、每天误触发几十次；无人 @ 的情况下，实例在后台复现排查，随后在群里回复「已修复并提交 Pull Request，附前后对比截图」，根因指向「Electron 默认吞掉激活窗口的那次点击」。
实验部分，文章自称基于合成负载与简化环境，「以下结果仅作为初步参考」：每次实验约 300 条消息、其中约 20 条是工作请求，编码工作用只消耗时间的工具代替，每种方案跑 5 次。结果是 Super-agent 完成任务的 p50（中位数）为 12.4 分钟、p95 为 15.7 分钟；带 Subagent 工具的单 Session 在中性提示下 5 次运行一次都没有委派，p95 达 29.5 分钟；改成「优先委派」的提示词后，5 次里 4 次委派，整体仍更慢。单独压测 Router 层时，把需要决策的 Trigger 到达速率从每分钟约 1 条提到约 40 条，平均 batch 大小（一次合并处理的 Trigger 条数）从 1.0 升到 2.8，单次请求耗时只从 2.5 秒涨到 3.9 秒，单个决定分摊的推理时间从 6.4 秒降到 1.6 秒；去掉 Worker 的直通机制，任务完成时间基本不变，但 Router 的决定量增加约 30%，读缓存 token 从 2,323 万涨到 3,177 万，增幅约 37%。
底座：一切皆插件的 DeepSeek Harness
dsh-superagent 不是独立应用，而是装在 DeepSeek Harness 上的 bundle。Harness（简称 dsh）是 DeepSeek 开源的 agent harness，采用「一切皆插件」（everything-is-a-plugin）架构，底层由 Cordis 框架驱动，Cordis 的设计另有一篇专门论文（）；Harness 官方 README 同时提醒项目处于 developer preview（开发者预览）、迭代很快，「将有破坏兼容性的变更」。原型仓库根目录里的 cordis.patch.yml、pnpm-lock.yaml 与 vitest 配置，显示出它是接在 Cordis 插件体系上的 TypeScript 工程；一条 pnpm check 即可跑完类型检查、测试和构建，docs/ 目录下 000 到 008 共九篇编号文档按序阅读，每篇只依赖前面的概念。
GitHub API 还显示，这个仓库关闭了 Issues 与 Pull Request 功能——它不在 GitHub 上收 bug 报告和外部代码，「仅供参考」在字面意义上成立。
两处「非官方」声明之后：早期反响与文章自列的开放问题
限定措辞在两处几乎一致。README 要求使用者把它当研究代码而非生产软件：可能仍有 bug，编码风格与工程实践可能不一致，用之前先审查、改造；发布版经过改编，与团队内部版本、也与设计文章描述的实现不完全相同，文章中的一些设计属于未来方向、并未在这个原型里实现。微信文章的结尾把同一层意思重复了一遍：「该插件只是一种为了验证技术路线而提供的原型，并非 DeepSeek 的正式产品。」
早期反响还停在初步数字上。Hacker News 有用户在 10 月 31 日以「DeepSeek open-sources dsh-superagent, a coding agent largely built by agents」为题提交了仓库链接（）；X 用户 teortaxesTex 发布了文章的英文翻译版，自注为机器翻译、未经人工校对，该帖获 101 次点赞、约 1.6 万次浏览（）。原型在实际环境中的能力与成熟度，目前没有独立验证。
文章在安全与隐私一节（8.4 节）把话说得很直接：事件驱动让 agent 接触更多不可信输入，「一旦云端的 Agent Loop 遭遇服务端入侵或提示词注入而被攻破，其连接的全部端侧设备都面临被控制的潜在风险」；凭据只要进入模型上下文，正常执行中也有泄露风险。文章的判断是，解决不了这两件事，「Super-agent 只有在一个很小且可信的范围才能工作」。这个开源原型此刻给出的答案是允许名单、默认只记录的 observe 模式，和一块只显示「需要人」的面板；至于这个「很小且可信的范围」能扩大多少，README 和文章都没有给出答案。