10 月 31 日，DeepSeek 在 GitHub 丢了一个仓库：deepseek-ai/dsh-superagent-prototype。没发布会，没博客，README 第一行写着「研究原型，仅供参考，不是 DeepSeek 官方产品」。一周后它挂了两万颗星（20,178，11 月 7 日数据）。
翻完 docs 我的判断是：这不是又一个帮你写代码的 Agent，而是 DeepSeek 把「怎么管一个 Agent」的内部做法开了一份源。核心不是模型多强，是谁有资格派活、活怎么记账、人什么时候必须出现。
它到底是什么
一句话：一个只盯一个 GitHub 仓库的主动型编程 Agent，打包成 DeepSeek Harness 的 bundle。
它听两个地方：GitHub（通知、订阅的 Issue/PR、CI 变化，可开关「全仓库新 Issue/PR/评论」）和飞书（群里的 @、私聊）。白名单里的人找它要活，它就开一张工单，在自己的会话、自己的目录里干，干完回到原来那段对话交付——通常是一个 PR。侧边栏的面板只回答三个问题：现在有事要我做吗、系统健康吗、这件事从头到尾发生了什么。
README 里那句设计原则写得很实在：take as little human attention as possible, and give as much value as possible。能自己干就别叫人，要叫就只叫一次。
一套工单制，不是一个对话框
大多数 Agent 产品的心智模型是聊天框：你说一句它回一段。dsh-superagent 的心智模型是工单，中间每一步都有名字：
- Source：事件来源，记自己的读取位置，重启不重放；
- Trigger：一条不可变事件，同一条重复进来只会生成一张工单；
- Thread：按时间排的一串 Trigger，同一个 Thread 同时只跑一个 Eval；
- Eval：判定层，输出四种结论 accept / stop / ignore / unavailable，自己不存状态；
- Mandate：accept 时发的授权书，写清依据哪版 Policy、范围多大、谁在哪个平台说的，不可变；
- Ticket / Assignment：工单，和「派给哪个 Executor 实例」，状态各自独立。
最妙的一点是只有 Eval 能开工单。Executor 干完只能报告，不能自己宣布再干一票；人要停，只有人的 stop 能撤 Mandate。这比大部分「自主 Agent」的权限设计干净。
docs/001 里还附了一张「被否决的概念」表：为什么不建 Principal 实体、为什么 Eval 不自己排延迟任务、为什么 Policy 变更时不取消跑到一半的工单。肯把否决理由写出来的框架，功能列表之外还多一层可信。
授权是这项目的重点
三层：
- 每个 Source 一份白名单（同步群成员或 GitHub 登录名）；
- 一张准入表，按「在不在名单」「有没有 @ 机器人」两个维度，决定一条消息是明确请求、推断候选、还是直接忽略；
- 落到工单上的 Mandate，带 Policy 版本；Policy 变了只通知工单，不会把跑到一半的活掐掉。
默认 accept mode 是 observe：只记录它认为该干的活，不真干。这个默认值很聪明——先让团队看一周它想干什么，再决定放开多少。
一张工单跑起来什么样
拿到 Assignment 后，每张工单有独立会话 worker-<ticket id>，和一个以工单短名命名的目录，默认在 <stateDir>/work 下。目录不存在就先跑 prepare 命令（十分钟超时），典型写法是 git worktree 拉一份干净检出。
几个工程细节：
- Executor 以操作者系统用户身份、不经审批执行命令；
- 前台 shell 超过 5 秒自动转后台，下一步就能收新消息，不用干等编译；
- 一轮结束后后台任务最多再跑 30 分钟，超时 shell 被 kill、工单回到「等人」，子 Agent 可以继续；
- 并发有上限，但给人留一个额外槽位——满载时人插话不排队。
面板里的阶段也很实：排队、在干、干完等 Trigger、在问你、等你 review、卡住/失败、输入没送达（2 秒后重试，退避到 1 分钟）。
装它要什么
硬门槛：Node 22.19+ 或 24、pnpm、git 2.32+、tmux、Python 3.8+、GitHub CLI 2.48+，以及已经在跑的 DeepSeek Harness。
安装方式挺有意思：它让你叫自己的编码 Agent 去读 SETUP.md，那个 Agent 一次问一个问题，问完给一份完整计划，你确认一次它才动手；全程不让你在聊天里贴密钥，需要你亲手做的（建专用 GitHub 账号、飞书建机器人）单独列一条。默认值也写死了：profile superagent、端口 3082、状态目录 ~/.dsh/state/superagent、分支前缀 agent/、每小时自检拉起挂掉的进程。
说实话：现在还不能当基础设施
- 它是原型，不是产品。 README 自己承认很多工程是 coding agent 写的，可能有 bug、风格可能不一致；公开版和内部版、论文里的实现也不完全一样，论文有些设计只是方向、没落地。
- 它停在 11 月 3 日。 最后 push 是 11 月 3 日，没有 release 节奏，issue 区是关的。当参考读可以，当生产依赖不行。
- 权限是真危险。 Executor 以你的系统用户身份、免审批执行命令。官方有 blocked commands 兜底，但别拿它跑生产机，更别给 root。
- 成本是会话级的。 一张工单一个会话，还会起子 Agent、跑后台任务，长任务烧 token 不客气。先 observe 一周，看它一天想开几张工单。
- 对个人开发者，docs 比代码值钱。 001/002/003 三篇讲的是「Agent 替团队值班」绕不开的问题：幂等、授权边界、人机交接。要自己写多 Agent 系统，这三篇能省不少弯路。
一句话定位：它不帮你省写代码的时间，它给「一个 Agent 怎么替一个团队值班」写了一份能抄的作业。想先补 Agent 平台的整体地图，可以看十个平台第一次点「新建」；想看另一种「把 Agent 当员工管」的思路，Paperclip 那篇可以对照读。
