DeepSeek dsh-superagent：少占注意力的仓库常驻 Agent
仓库常驻一个会写代码的 Agent，最怕的往往不是它不会干活，而是它太爱说话、太爱主动，把整队注意力拖垮。deepseek-ai/dsh-superagent-prototype（MIT）把「少占注意力、多给价值」写成可运行的研究原型：挂在单个 GitHub 仓库上，监听 GitHub（可选飞书），有人点名要活就开工单，在独立 Session 与目录里干活，再回到原对话答复——常见结果是开出 PR。下文按仓库 README 与 docs/000–007（查阅日 2026-11-01 北京时间）整理哲学、触发链路、面板与 Agent 引导安装。同日 GitHub API 星数约 4902★。
定位先说清：README 置顶写明——仅供参考的研究原型，非官方 DeepSeek 产品；代码来自团队日常开发，大量工程由编程 Agent 完成，可能仍有 bug、风格不一致，使用前请审阅与改造。对外发布版与内部版、与《Exploring Super-agent Design…》一文描述也不完全相同，文中部分方向尚未实现。
核心原则：少占注意力
docs/000-philosophy.md 的判词是：Take as little human attention as possible, and give as much value as possible. 消息、通知、提问、设置、面板元素、文档段落——凡是消耗注意力的，都要证明自己更值钱，否则删掉。
- 只在被要求、或团队写明的规则允许时行动。请求须直接点名 Agent，且来自允许名单上的人（或团队开放请求的对话）。无人要求的工作需要书面规则，并先以「只记录本会做什么」的模式启动。
- 只在人必须行动、或能用上结果时开口。确认请求一次并说明将做什么；干活时安静；有结果、要决策、或做不完时再说话。短消息，回到原对话。
- 一次只问一个具体问题，用结构化表单，别埋在长报告里。
- 按影响停，不按努力停：局部改动做到可评审结果；需要设计决策的改动停下来问清楚。
- 如实报告：草稿标未完成，失败就说失败，不为了少问人而绕过限制。
目标是在对的时间给对的帮助，其余时间什么都不说。
对操作者的责任也写进了哲学文档：名单从短开始、主动工作先只记录；一吵就收紧提示词或干脆暂停，别再加消息解释噪音；不要用它刷 PR 和广播；它以团队日常账号发声，你要为内容负责。
它实际在干什么
README 摘要：面向一个 GitHub 仓库的主动编程 Agent，打包成 DeepSeek Harness 的 bundle（公司级入口/权限/记忆分工可对照 公司 harness 五件套）。有人（在允许范围内）要活 → 开 work item → 独立 agent session 与目录里执行 → 在原对话答复（例如 PR）。Web 面板标出「需要人看」的事项。
001-domain.md 把概念压得很薄：Source（事件流，如 GitHub / 飞书）产生 Trigger；Thread 上串行跑 Eval；接受则带 Mandate 创建 Ticket；Assignment 交给 Executor；结果经 Channel 写回 Source。人不是领域实体——身份只是 Trigger 上的 Source 侧标识，允许名单是 Policy 的一部分。Rejected concepts 表刻意砍掉了「跨 Source 映射主体」「Eval 自己定时」「一 Thread 只能一个活 Ticket」等常见过度设计。
| 环节 | 做什么 |
|---|---|
| Source | GitHub 通知 / Issue·PR·评论·CI 等；可选飞书事件与话题轮询 |
| Eval | 先确定性 Gate（谁可发起、强度），再模型研判；输出 accept / stop / ignore / unavailable |
| Ticket | 授权工作单元；有自己的状态，不盲跟 Session |
| Executor | 每 Ticket 一个 worker Session + 目录（默认在执行根下）；可用 prepare 命令做 worktree（并行目录卫生见 git worktree 清理） |
| Channel | GitHub 评论 / 评审回复；飞书话题回复 |
执行与面板：需要人时才露脸
003-execution.md：每个 Ticket 有阶段标签——等输入送达、等人回答、等人审、阻塞/失败、排队、等 Trigger、Working。Executor 以操作者 OS 用户跑命令、无逐步审批（依赖部署与黑名单命令）；长命令约 5 秒后转后台，以便下一回合还能收消息。并发有槽位限制，人的跟进可占用额外槽，避免新活把旧活饿死。合并默认不由 Agent 账号自己开 auto-merge；需要时在 Delivery requirements 里点名另一账号的 CLI。
005-panel.md：在 DeepSeek Harness Web 侧栏打开 Superagent。面板按三个问题排序——现在有没有事要我？系统健康吗？某条活从 Trigger 到 Ticket 的历史？页签是 Overview / Source / Trigger / Eval / Execution / Settings。健康状态不占版面；待办直接给动作。设置按 Source、Eval、Execution、Prompts、Deployment 分组，各有保存历史。
怎么装：让 Agent 读 SETUP.md
步骤多，官方做法是让你的编程 Agent 读仓库里的 SETUP.md 带你装：一次只问一个短问题、全部答完后给一份完整计划、你确认后再执行；密钥从不在聊天里索取，需要人手的登录/建号步骤单独成消息。探针会检查 Node（22.19+ 或 24+）、pnpm、git、tmux、Python、gh、dsh 等。
问题顺序大致是：只要 GitHub 还是加飞书 → 哪个仓库 → Agent 用哪个专用 GitHub 账号（不要用操作者本人）→ 谁可下单 → 本地 clone / worktree 根 → 提交身份 → 是否允许 auto-merge（默认否）。默认还有 observe 受理模式（主动工作先只记录）、独立 profile、状态目录等——写在计划里，少开旋钮。
# 对你的编程 Agent 说：
Read SETUP.md in this repository and set up dsh-superagent with me.
验收入口：scripts/dsh-superagent status 退出码 0 且无 setup 问题；允许名单上的账号在 Issue 里 @Agent账号，约一分钟内 Overview 应出现 Ticket。
常见坑
- 当成正式产品直接上生产：官方明确说是研究原型，先审代码、先窄名单。
- 允许名单过宽 + 主动工作全开：违反「少注意力」原则，噪音会立刻起来。
- 用操作者本人 GitHub 当 Agent 身份：SETUP 建议专用账号，Agent 写的每条评论都会顶着这个名字。
- 指望文中所有 Super-agent 设想都已实现：README 写明部分方向未落地，以本仓库文档为准。
- 面板里到处找「健康数据」：健康状态故意不占空间；先看 Overview 里「需要人」的块。
完成标准
- 能说明「研究原型 / 非官方产品」边界，以及注意力原则的三条行为约束。
- 能口述 Source → Eval → Ticket → Executor → PR 的链路与面板三问。
- 知道用
SETUP.md让 Agent 引导安装，起步用短允许名单与 observe。
最后
dsh-superagent 想解决的不是「Agent 能不能写代码」，而是「常驻仓库的 Agent 怎样不把团队注意力吃光」。读完 000 再动手；装的时候跟 SETUP 走，先窄后宽。代码与编号文档见仓库；Harness 产品页见 DeepSeek Harness 站点。
