DeepSeek 开源 dsh-superagent：会自己接活的编程 Agent

2026 年 10 月 31 日，DeepSeek 的 Harness 团队在 GitHub 上放出了 dsh-superagent。仓库简介只有一句「Towards a More Autonomous Agent System」，但 README 把定位说得很清楚：这是一个研究原型，不是 DeepSeek 的官方产品，代码来自团队日常开发，其中大量工程由 coding agent 完成。

它想解决的问题不是「让模型更会写代码」，而是「让 Agent 少占用人的注意力」。

它怎么工作

dsh-superagent 只服务一个 GitHub 仓库，以 bundle 的形式跑在 DeepSeek Harness 上。

• 它监听 GitHub，也可以选配飞书。
• 当被允许的人提出请求，或者团队写下的规则覆盖了某件事，它就开一个 work item。
• 每个任务有自己的 agent session 和工作目录，做完后回到原来的对话里回复，例如提交一个 pull request。
• 有一个 web 面板，显示哪些事情需要人来处理。

README 里把工作原则写得比功能更重：尽可能少占用人的注意力，尽可能多给价值。一个能替整个团队行动的 Agent，同样也能浪费整个团队的注意力，所以它只在被要求、或被团队规则允许时行动；只在有人必须行动、或者结果对人有用的时侯说话。

权限边界是重点

这套东西最容易出事的地方不是代码质量，而是「谁能让它干活」。

• 允许名单和规则由宿主执行，不靠模型自觉。一条消息、一条评论或一份被引用的文档，都不能扩大 Agent 的权限。
• 默认模式下，不明确的请求——比如没有点名 Agent 的消息、机器人发来的消息、不在名单里的人跟帖——会被评估并记录为「Agent 本来会接」的任务，但一个都不接。
• 明确请求在所有模式下都有效，例如名单内的人直接 @ 它。
• 官方建议先看一段时间这些「本来会接」的记录，确认判断标准没问题，再切到自动模式。

这个设计把「自主」拆成了两步：先学会判断哪些活该接，再决定要不要真的接。对团队来说，中间那段时间的日志比功能列表更有价值。

自动合并为什么不默认开

代码写完只是第一步，合不合进去是另一回事。README 说，自动合并由一条叫 Delivery requirements 的提示词控制，宿主本身不添加任何合并逻辑。

默认情况下，Agent 不会用自己的账号打开自动合并。原因很实际：GitHub 会把这次合并记在「启用自动合并的人」头上。除非提示词里明确指定了另一个账号，否则合并这件事留给人来做。

这算是一个很小但很清醒的默认值。它没有把「Agent 能合并」当成能力展示，而是先问「合并记录应该记在谁名下」。

怎么试

仓库给了两条路：

• 让 coding agent 读 SETUP.md，跟着它一步一步装。SETUP.md 一次只问一个短问题，先给出完整计划，再安装和配置。
• 自己按 docs 目录里的编号文档来：哲学、领域模型、授权、执行、提示词、面板、部署、架构、cookbook。

开发检查用 pnpm check，会跑类型检查、测试和构建。许可证是 MIT。

需要保留的地方

• 这是研究原型，README 明确说可能有 bug，代码风格和工程实践也可能不一致，不能直接当生产软件用。
• 它和团队内部版本、以及论文《Exploring Super-agent Design》里描述的实现并不完全相同；论文里有些设计只是未来方向，原型没有实现。
• 目前能核到的信息主要来自仓库 README 和两家独立报道，没有看到大规模部署或长期运行的公开数据。
• 「少占用注意力」是设计目标，不是已经验证的结论。实际效果取决于团队规则写得够不够细。

参考来源

本文基于以下公开报道整理：

• deepseek-ai/dsh-superagent-prototype — GitHub 仓库，2026-10-31
• DeepSeek open-sources Super-Agent, a coding agent that watches team chats for work — Help Net Security，2026-11-02
• DeepSeek team open-sources proactive coding agent research prototype — TechNode，2026-11-02

本文由 AI 辅助整理，事实与引文来自 GitHub 仓库 README、Help Net Security 与 TechNode 报道；未实际部署试用，配图后续补充。