deepseek-ai/dsh-superagent-prototype 给单个 GitHub 仓库配的「主动式编码 agent」，挂在 DeepSeek Harness 上：监听 GitHub（可选飞书），被授权的人提出请求后开工作项，在独立会话和目录里干活，最后回到原会话交付一个 PR；旁边还有一个 Web 面板，只显示「什么在等人处理」。
真正的价值不在它能写代码，而在它把「AI 什么时候能动、能走多远、谁批准」这件事，从一句口号变成了一串可以逐条审计的规则。下面拆开看。
基本盘：一份「研究原型」，为什么值得花十分钟
它到底是什么
dsh-superagent 是一个面向单个 GitHub 仓库的主动式编码 agent，打包成 DeepSeek Harness 的 bundle。它监听 GitHub（可选飞书），被授权的人提出请求后开一个工作项，在独立的 agent 会话和目录里干活，最后回到原会话交付 PR。一个 Web 面板展示「什么在等人」。
一句话讲清它关心什么
README 第一句就给全项目定了调：「Take as little human attention as possible, and give as much value as possible.」——尽可能少花人的注意力，尽可能多给人价值。
这个 star 数的含义
20,362 星、2,371 fork、0 open issue：0 个 issue 而 2 千多 fork，说明关注来自「收藏研究」而非「上报缺陷」，是方法论型项目的典型信号。
一个必须说明的边界
README 明确声明：这是研究原型，不是 DeepSeek 官方产品，代码大多由编码 agent 完成，「可能仍有 bug，代码风格与工程实践可能不一致」。所以下面讲的都是「思路可以抄，代码别直接搬」。
一句哲学：用「注意力成本」裁决每一个设计
裁决标准本身
每条消息、每次通知、每个问题、每项设置、每个面板元素、每段文档，都会花掉某个人的注意力；给不出超过成本的价值，就删掉。
只在被请求时行动
agent 只在被点名、或被团队写下的规则允许时才行动；没人请求的主动工作，默认先跑在「只记录本会做什么」的模式里。
只在人必须动手时开口
先确认一次并说明要做什么 → 干活期间保持安静 → 结果就绪、需要决策、或干不下去了再写。
一次只问一个具体问题
用结构化形式送达，而不是塞进一份长报告里。
按影响停下，不按投入停下
本地改动推到「可评审」就停；需要设计决策的改动，停下来提一个清楚的问题。
诚实报告
草稿就标未完成，失败就报失败，绝不为了少问一句而绕过限制。
为什么这是「推导」而不是「口号」
它把「少打扰」写成了推导出来的结论：每个功能都能拿「花了多少注意力、换回多少价值」这把尺子量一次，而不是靠自律。
领域模型：把「谁能开工」拆成可审计的几张牌
docs/001-domain.md 规定「只用这些术语，别的一律不用」，核心链路是 Trigger → Eval → 执行。
Trigger：不可变、幂等的单位
携带发起人元数据；同一个 Trigger 被接受两次，只会产生一个 Ticket。这是审计与幂等的根。
Policy：版本化的评估规则
谁能通过哪个 Source 发起工作、名单如何同步、哪些 bot 能产出候选，都写在里面。
Eval：两层判断、不持有状态
分 gate 门禁 + assessment 评估两层；输入 Trigger、Thread 快照、Thread 上全部 Ticket、当前 Policy，输出 Decision。
Mandate：不可变的授权
包含 Policy 版本、范围、强度、命中规则、发起人身份；范围变宽就开新 Ticket；只有人的停止才撤回它。
Ticket：只有 Eval 能创建
一份被授权的工作单元，状态自管，不跟随执行器。
Assignment：绑定执行器
一个 Ticket 生命周期内可有多个，但只有最终报告能在执行器侧结束 Ticket。
这条链子最值得记的一处
Trigger 重复接受只产生一个 Ticket——很多自动化系统靠加锁防重复，它却选择在领域层把「重复接受」收敛成同一个对象。
授权三档：explicit / inferred / not admitted
docs/002-authorization.md 的立场很硬：消息、评论、引用的文档都是决策输入，不能改变权限——宿主强制执行名单、规则与 Mandate。
Eval 路径：开启新工作
Source 记录消息有没有点名 agent；门禁检查发送者与 Policy。
订阅路径：延续既有工作
订阅 Thread 上的每条消息（含 bot 与 CI）都作为上下文送达订阅 Ticket，绕过门禁但不授予新权限。
所有权归属
某个执行器拥有某条消息期间，它不经过 Eval、也不产生 Decision。
三档强度一览
| 强度 | 场景 |
|---|---|
| explicit | 名单内的人点名 agent，或在已有 Ticket 的 Thread 上追问 |
| inferred | 名单外的人在已有 Ticket 的 Thread 上追问；bot 点名 agent；或到达「Source 收所有消息」的位置 |
| not admitted | 其他 bot 的消息、准入表忽略的一切、accept mode 为 off 时的全部 inferred |
bot 永远只是候选
一个关键细节：bot 永远只能产出 inferred candidate，绝不是 explicit request。这让「机器点名」和「人点名」在权限上天然分开。
执行节奏：5 秒后台化、slot 保留、30 分钟硬上限
docs/003-execution.md 用一张阶段表判断「在等什么」，从上往下读，第一个匹配的行获胜。
阶段表
| 阶段 | 条件 |
|---|---|
| person / delivery | 投递 Input 失败（2 秒重试，指数退避到 1 分钟） |
| person / answer | 有 Attention |
| person / review | 最新报告为 ready |
| person / blocked, failed | 最新报告为 blocked/failed，且此后无人消息到达 |
| working / queued | 无 Assignment，或有 pending |
| idle | 最新报告为 waiting，或 Assignment 已结束 |
| working | 其余全部 |
5 秒后台化
执行器预设 5 秒后把前台 shell 命令移为后台作业，让 worker 能在下一步收到新消息，不必等长命令跑完。
worker slot 保留
turn 结束时若仍有 shell 作业或子 agent 在跑，Ticket 保留 slot 并保持 working，不报 waiting；作业完成则在同一 slot 唤醒执行器。
30 分钟硬上限
后台工作最多 30 分钟，超限就杀掉 shell 作业、把 Ticket 报为 waiting，报告里保留执行器最后几句话、哪些作业被杀、哪些子 agent 仍在活跃。
「阶段由在等什么决定」的价值
这个思路比「按时间或按编号猜状态」可靠得多，可以直接套到任何多步骤自动化链路上。
工程组织：提示词是资产，渠道是插件
prompts 是工程资产
prompts/ 下 14 个文件独立管理：orchestrator / worker / dispatch / handoff / admission / subscriptions / replies / work / cli / shared 等，提示词被当成工程资产而非散落的字符串。
docs 编号强制阅读顺序
docs/ 用编号（000→008）强制阅读顺序，每篇只依赖它之前的篇，读者永远不需要尚未引入的概念。
渠道 = 加 skill，不改核心
skills/ 下两个渠道技能（github 与 feishu 各一个 SKILL.md）——扩展渠道是加 skill，不是改核心。
安装流程交给 agent
「读 SETUP.md 并和我一起装好它」，一次问一个问题，完整计划只展示一次。
测试与检查
测试 59 个文件（约占全仓 25%），pnpm check 跑类型检查 + 测试 + 构建。
你可以带走的六个做法
把「少打扰」从口号变成标尺
给每个通知、每个面板元素、每段文档加一道「注意力成本 vs 价值」的必答题。
用不可变 Trigger 做幂等
与其到处加锁，不如在领域层把「重复接受」收敛成同一个对象。
Mandate 不可变，范围变宽就开新单
一份授权就固定一份范围，想扩大只能另开一张，避免同一张单被悄悄扩权。
订阅路径只传上下文、不授新权限
「拿到了上下文」不等于「拿到了授权」。
阶段由「在等什么」决定
按卡在哪一层定状态，而不是按时间编号猜。
超时报告保留最后输出
杀掉后台作业时，把执行器最后几句话、哪些作业被杀、哪些子 agent 仍活跃一起写进报告，方便下次接着读。
同类项目里，它站在哪
瓶颈正在从「能不能跑」转向「能不能治理」
过去半年冒出的这类项目，有解决「怎么派」的、有解决「本地网关 / provider 路由」的、有解决「harness × 模型解耦」的。dsh-superagent 是治理面最完整的一个。
它补上的那块拼图
它把「派出去之后凭什么有权限做、能做多远、做到哪停」做成了 Policy + Mandate 两件套，成了可审计对象。