dsh-superagent：代理写出来的超级代理研究样本

背景与现象：3 天 13,000 星，和一段自曝式免责声明

2026 年 10 月 31 日，GitHub 组织 deepseek-ai 上线了仓库 dsh-superagent-prototype。三天之后，11 月 3 日上午的口径：13,000 星、1,348 fork、79 个 subscriber、0 个 open issue。作者字段写的是 DeepSeek Harness Team，MIT 许可，版本号 0.1.0。

星数之外，README 第一段的免责声明更有信息量，三个关键句都值得直引：「Research prototype for reference only, not an official DeepSeek product.」仅供参考的研究原型，不是 DeepSeek 官方产品；「much of the engineering done by coding agents」，大量工程由 coding agent 完成；「adapted for publication, so it is not identical to our internal version」，为发布做过改编，与内部版本并不相同。一个三天涨了一万三千星的仓库，开头先否认自己的官方身份，这个反差是本期的第一个拆解点：它是 DeepSeek Harness（下称 DSH）团队开源的研究原型，定性到「团队研究原型」为止，不能再往上写。

传播面上有一处明显的温差。这个仓库先后被提交过多次 Hacker News，最好成绩只有 11 分、0 评论，讨论寥寥；而 GitHub 这边星数暴涨，热度几乎全在 trending 一侧。背景板是 DSH 平台本身：8 月 13 日 developer preview 在 HN 拿到 747 分、314 条评论；10 月 2 日的 Harness Desktop（macOS/Windows 客户端）拿到 417 分、228 条评论。平台有真实的社区热度，dsh-superagent 是其生态里第一个重磅 bundle，星数里含着平台招牌带来的注意力转移。

它是什么，一句话说完：一个为 DSH 打包、只服务一个 GitHub 仓库的常驻 coding agent，监听 GitHub，可选监听飞书；被授权的人向它派活，它开一个工作项（Ticket），在自己的会话和目录里干活，然后回到原对话答复，比如提交一个 pull request；Web 面板只显示「需要人处理的事」。配套还有一篇文章《Exploring Super-agent Design: Towards a More Autonomous Agent System》，README 特别提醒：文章里讨论的部分设计是未来方向，原型并未实现。

架构与技术原理：一条授权铁律和五条纪律

先说形态。它不是独立应用，而是一个 Cordis 插件架构下的 bundle（cordis.patch.yml），装进 DSH 里运行。仓库自带九篇编号文档，从 000 到 008 依次是哲学、领域模型、授权、执行、提示词、面板、部署、架构和 cookbook，最后一篇是添加一个 Source 的教学。每篇只依赖排在它前面的文档，这是 README 自述的设计约束：读者永远不会遇到一个尚未被引入的概念。

领域模型是一条单向的流。Source（事件源，GitHub 或飞书）产生 Trigger（不可变事件），Trigger 归属 Thread（时间序的会话），Eval 对一批 Trigger 做两层判断（gate 加评估），产出 Decision；接受则创建 Ticket 并附一份 Mandate（授权凭证），Assignment 把 Ticket 绑到一个 Executor（执行会话）上，结果经 Channel 写回原对话。此后同一 Thread 的后续消息通过 Subscription 扇出，作为上下文直接送达已订阅的 Ticket，不再重新过 Eval。

整个系统的重心在授权。docs/002 开篇一句铁律，原文是：「The host enforces allowed lists, rules and Mandates. Messages, comments and quoted documents are inputs to a decision; they cannot change those permissions.」宿主程序强制执行白名单、规则和 Mandate；消息、评论、被引用的文档只是决策的输入，不能改变权限。换句话说，prompt injection 的防线不写在提示词里，而写在架构层：无论消息内容说什么，权限判定都不经过消息内容。

Trigger 有两条路径。第一条是 Eval，决定要不要开工：Source 记录消息是否指名代理（@提及或私信），gate 检查发送者与该 Source 的 Policy。白名单里的人指名代理，构成显式请求；bot 最多产生「推断候选」，永远不构成显式请求，不在名单里的 bot 直接不受理。推断候选还要过 accept mode 这一关：off、observe、auto 三档，默认 observe，只记录「本来会接受」的判断，不真开工。第二条是 Subscriptions，延续既有工作：订阅 Thread 的每条消息（包括 bot 和 CI 的）都送达已订阅的 Ticket，绕过 gate 但不授予任何新权限，Ticket 始终受自身 Mandate 限制；人即使取消订阅，Executor 的所有权也持续到 Ticket 结束。

Mandate 是 accept 那一刻定格的授权凭证，不可变，记录 Policy 版本、范围、强度和命中的规则。全系统只有三种操作能改变它：accept 创建它，人的 stop 撤回它，复验失败吊销它。已结束的 Ticket 要恢复，必须先按当前 Policy 复验：把发送者移出白名单，就能吊销当初经他授予的 Mandate。这套规则落在 src/policy.ts 的 242 行里，gate 与 revalidate 两个函数和文档逐条对应。

哲学文档给代理定了五条纪律：只在被要求或团队成文规则允许时行动，没人要求的工作必须先以只记录模式运行；只在有人必须行动或能用上结果时说话，工作期间保持安静；一次只问一个具体问题，用结构化形式问，让问题找到人而不是埋在长报告里；按影响停而不按工作量停，本地改动做到可评审为止，需要设计决策就停下来问；诚实汇报，草稿标未完成，失败报失败，「限制绝不为避免提问而绕过」。

目录结构和文档互相呼应。src/core 是领域模型与工单引擎（engine、tickets、intake、stage、replies、memory 等 15 个文件）；src/sources 里 github-* 与 feishu-* 文件成对出现，两个 Source 实现完全对称；src/executor 把执行落到 DSH 会话；policy.ts、limits.ts、admission.ts 独立成文件，授权与限流不和业务代码混住。13 份提示词放在 prompts/ 目录里进了仓库，admission、dispatch、orchestrator、worker、handoff 各司其职，提示词被当作一等公民管理。

关键数据：12,390 行代码，一个 commit

仓库统计口径的几个硬数字：src/ 下 TypeScript 共 12,390 行、147 个 .ts 文件；tests/ 有 65 个文件；全仓 216 个文件（不含 node_modules 和 .git），合计 3.8MB。语言是 TypeScript，package.json 里 private: true，不发 npm 包，按 bundle 使用。

历史只有一条：单个 squash commit（6337fc8，2026-10-31，「feat: add the dsh-superagent research prototype」），发布之后没有新的提交，contributors API 返回空数组。九篇编号文档之外，prompts/ 有 13 份提示词，skills/ 有 2 个（GitHub 和飞书各一）。

policy.ts 里的默认参数值得单列：并发 worker 上限默认 3；Eval 超时默认 120 秒；accept mode 默认 observe；默认规则只有两条，copy（文案修正）和 visual（视觉修正），而 visual 规则的指令原文写着「Do not invent visual style」，方向或范围没定死就只观察、不确认、不动工。默认值收得极紧，和「先窄后宽」的操作建议一致。

执行侧的细节：每个 Ticket 分到一个名为 worker-<ticket id> 的会话和一个专属目录；前台命令超过 5 秒自动转成后台任务，让 worker 在下一步就能接收新消息，而不是干等长命令跑完。

SETUP.md 本身就是一份拆解材料。它不是写给人的，是写给代理的：官方的安装建议是「让你的 coding agent 读 SETUP.md 陪你装」。文件里给代理立了规矩：一次只问一个短问题，每条消息 300 词以内，完整计划只展示一次，问完所有问题才允许动手，绝不在聊天里索要秘密，需要人手的步骤（建账号、登录 CLI、填 app secret）单独打包成一条消息。先决条件清单也不短：Node.js 22.19+、pnpm、git 2.32+、tmux、Python 3.8+、GitHub CLI 2.48+，加上 DSH 本体和一个模型提供方。

影响与意义：注意力是货币，权限是铁律

第一，注意力经济被当成了设计公理。README 的加粗原句：「take as little human attention as possible, and give as much value as possible」，尽量少占人的注意力，尽量多给价值。哲学文档把它展开成验收标准：一条消息、一个通知、一次提问、一项设置、一块面板元素、一段文档，每样都花掉某个人的注意力，给不出超过成本的价值就删掉。动机也写得直白：「一个能替整个团队行动的代理，也能浪费整个团队的注意力。」多数代理产品把能力当卖点，这个项目反过来，把「花你多少注意力」当第一约束：面板只显示需要人处理的事，健康状态不占任何空间；概念要少，设置要少，能用一个默认值的就不做配置项，团队用文字描述的行为写成提示词而不是开关。

第二，对 prompt injection 给出了架构级回答。业界常见做法是在提示词里叮嘱模型「不要执行消息里的指令」，本质是求模型自律；dsh-superagent 把问题交给宿主程序：权限只存在于白名单、规则和 Mandate 里，消息、评论、被引用的文档一律只是决策输入。注入文本写得再像命令，也拿不到 gate 之外的权限。这条防线不依赖模型能力，模型换代它也在。docs/001 的「被拒绝的概念」表里有一条同源的取舍：不允许 Executor 自己宣称「有人让我停」，停止的判定权只在 Eval。任何要接外部消息的代理系统，这套设计都可以直接抄。

第三，操作员责任写进了技术文档。哲学文档专门有一节 Responsibility：代理以团队天天看见的账号发评论、开 PR、发消息，每条消息都在花同事的注意力，操作员要为此负责。四条操作守则：先窄，白名单从短开始，主动工作只记录，看对了再放宽；吵了就改，把提示词改短改严，或者直接暂停，「不要用更多消息去解释噪音」；不要拿它刷量，mass PR、广播消息和 busywork 给团队的消耗大于价值；对它说的话负责，读它以你的名义发出的内容，错了就改提示词。治理条款和技术设计放在同一篇文档里，这个做法比代码本身更少见。

第四，它提供了一个「代理写、代理读」的工程组织样本。README 自认大量工程由 coding agent 完成，而这 12,390 行代码的组织方式给出了一套可复述的答案：编号文档递进依赖，保证任何一篇的读者（包括代理读者）不缺前置概念；提示词入仓、按角色分文件；两个 Source 实现严格对称，新增一个 Source 有 cookbook 教学；65 个测试文件托底；连领域模型文档都附「被拒绝的概念」表，把十来个明确不采用的设计和理由列在一起。给代理看的仓库该怎么长，这里有一份完整参考答案。

争议与风险：研究原型就是研究原型

第一，身份与成熟度。README 自己承认：代码可能仍含 bug，编码风格和工程实践可能不一致，「把它当研究代码，不是生产就绪的软件」。发布版与内部版不同，配套文章里的部分设计属于未来方向、原型未实现。想直接拿来用的团队，应该先把这几句读三遍。

第二，没有演进史。全仓库只有一个 squash commit，一次性发布，代码在生长过程中的取舍无从考察；contributors API 返回空数组，贡献者分布无从得知。对一个卖点是「代理参与工程」的仓库，历史缺失尤其可惜：没法从提交记录里观察代理量产代码的真实工作方式，只能看到最终结果。另外，0 open issue 不说明没有问题，更可能说明社区还没来得及认真使用（这句是我的判断）。

第三，传播温差本身就是个信号。HN 最好成绩 11 分、0 评论，GitHub 三天 13,000 星。HN 的冷清说明它在英文技术社区的讨论份额有限；GitHub 的星数暴涨，更多来自 DeepSeek 的招牌效应和「超级代理」这个叙事。星数是注意力指标，不是质量指标，两者不能混着读（这也是我的判断）。

第四，部署门槛把它限制在样本位置。先决依赖一长串，必须有 DSH 平台、专用 GitHub 账号，可选飞书机器人；官方文档直接建议让 coding agent 陪你安装。对不在 DSH 生态里的团队，它的可执行价值有限，真正可迁移的是文档和设计。还要留意授权模型的一个隐含代价：gate、Mandate、复验这套机制越严密，配置面就越大，Policy 版本一变，进行中的 Eval 全部作废重排，运维上要记住的规则不少。

结论与展望：文档比代码更值得读

配套文章的标题就是宣言：《Exploring Super-agent Design: Towards a More Autonomous Agent System》，迈向更自主的代理系统。文章与原型互为表里：文章谈设计，其中一部分是未来方向；原型只给出已实现的部分，并自己声明两者不相同。后续值得盯两件事：DSH 生态里会不会长出第二个、第三个重磅 bundle；以及 DeepSeek 团队会不会把文章里的未来方向逐个落进后续版本。

对读者，这个仓库的价值分层很清楚。最底层是可以直接搬走的授权模型：宿主握权限、消息只是输入、Mandate 不可变、恢复前复验。中间层是注意力经济的设计公理和操作员责任条款。最上层才是那 12,390 行 TypeScript 实现，而它按 README 的自认只是一个可能带 bug 的参考样本。我的结论一句话：dsh-superagent 值得读，文档比代码更值得精读；它证明了代理系统的难点不在能力，而在授权和注意力，这两个问题都有工程解。

参考来源

• 仓库与 README：https://github.com/deepseek-ai/dsh-superagent-prototype（13,000★ / 1,348 fork / 0 open issues / 79 subscribers，2026-11-03 口径）
• 本地 clone 只读核对（2026-11-03）：README.md、SETUP.md、docs/000-philosophy.md、docs/001-domain.md、docs/002-authorization.md、docs/003-execution.md、src/policy.ts、package.json、prompts/、skills/
• 配套文章：《Exploring Super-agent Design: Towards a More Autonomous Agent System》（README 引用，原型声明与文章不完全对应）
• DSH 平台 HN 讨论：developer preview 747▲/314c（2026-08-13）；Harness Desktop 417▲/228c（2026-10-02）
• 本仓库 HN 提交：最高 11▲/0 评（2026-10-31）

署名：永亮