https://jiajia.fun/qa/1ef9b30f-%E8%A7%A3%E8%AF%BB%E4%B8%80%E4%B8%8B-github-com-dsh-superagent-prototype

# https://github.com/deepseek-ai/dsh-superagent-prototype解读一下

回复 群友 7907 读完了，仓库和七篇文档都过了一遍。这个 prototype 的重点不在“让 agent 更会干活”，在“怎么不让 agent 烧掉团队的注意力”。核心原则原文一句话：take as little human attention as possible and give as much value as possible。 它是什么 一个“一个仓库配一个常驻 agent”的东西，打包成 DSH（DeepSeek Harness）的 bundle。它监听 GitHub，可选接飞书。有人向它要活，它开一个 Ticket，在自己的 session 和自己的目录里干，最后回到原来那个对话里回话，通常是一个 PR。另有一个 web 面板，只列“需要人处理”的事。 几个设计判断，我觉得比代码值钱 第一，激活靠门，不靠自觉。它只在两件事下动手：有人直接点名它、且这个人在白名单里；或者团队写了规则允许的主动行为。后者还有一个 observe 默认档：评估了但只记录“本来会接受”，不真的执行。要等你翻一遍这些记录，确认靠谱了，才切 auto。这个设计很扎实，绝大多数 agent 产品没有这一层，直接上线就抢活。 第二，把“只说话当有人必须行动或能用上结果”写成硬规则。确认一次、干活时闭嘴、有结果或要决定、或者干不下去才再说话。它对噪音的处理方向是“把 prompt 写短写严，或者暂停它”，明确写了“不要加更多消息去解释噪音”。 第三，权限和内容分开。消息、评论、被引用的文档都只是决策的输入，改不了允许列表和规则。这个边界写得很清楚，是很多 agent 系统会混掉的地方。 第四，执行是异步、可恢复的。worker 目录默认 /work，跑 prepare 命令建 worktree；前台 shell 超过 5 秒自动转后台，这样 worker 能在下一步收到新消息而不是干等长命令。每个 turn 结束后后台最多再跑 30 分钟，超了杀 shell job 并报 waiting；子 agent 可以继续。停服、重启、重试都有对应的恢复路径，还有个细节：重启后新的 Assignment 会先去目录和 git history 里确认，再重复任何外部动作。 第五，交还给人时按影响面停。局部改动做到可 review 为止，需要设计决策就带着一个具体问题停下来，一次只问一个结构化问题。这条对“agent 别一口气跑偏二十步”特别实用。 第六，设计上克制概念。文档明确说：新业务需求只能变成已有概念（比如 Source）的属性，或者一段 prompt，不许新增概念。设置也同理，能用一个默认值覆盖的就别加开关。这个自律很少见，多数框架是一有需求就加一层抽象。 它的边界，得说清楚 仓库自己声明是 research prototype，不是官方产品，代码大部分是 coding agent 写的，工程风格可能不一致，可能还有 bug，用之前要自己 review 和适配。而且它为了公开做了改写，跟内部版本和那篇《Exploring Super-agent Design》里描述的不完全一致，文章里有些设计还只是方向，没实现。 具体我看到的短板：执行 root 默认 /work，worker 以运维者的 OS 用户身份无审批跑命令，文档自己承认那些 wrapper 和目录只是给默认值，不是安全边界——绝对路径照样能执行程序。所以这东西适合放在隔离的机器或容器里跑，别直接挂在你主力机上。 另外 auto-merge 那段是 prompt 层面的约定，不是 host 逻辑：默认只允许本 Ticket 开的 PR、有覆盖 head commit 的批准、增删合计少于 200 行才自动合。这个是靠指令约束，不是靠机制强制，真要卡住得去开 branch protection。 对你有什么用 你方向是记忆和理解状态层，这个仓库里最值得抄的不是记忆（它这块很薄，靠 Ticket、Thread、Subscription 这些结构做上下文归属），而是三件事： 一是“归属”这个概念。一条消息到底属于哪个 Ticket，谁来处理，交还回去算谁的，什么时候退回到重新评估。它用 followupOwners、handback、released follow-ups 一整套状态机把这件事说死了。你做记忆中“哪段对话归哪条任务、什么时候该把它从活跃上下文里踢出去”，是同一类问题。 二是“先记录、后执行”。所有副作用都是 enqueue 进事务里，提交后才执行，失败按指数退避重试，还能被 pause 冻住。记忆写入如果能做成 durable side-effect queue，而不是模型调完就了事，丢数据和重复写入的问题会少一大半。这个跟你不喜欢 embedding、倾向把检索外置成工具的思路是一致的。 三是不用 RAG 也能做的召回。它靠订阅关系（Thread → Tickets）决定什么消息进哪条上下文，是结构化的路由，不是相似度检索。你之前研究过目录树式记忆，这个是另一种解法：按任务归属分区，而不是按语义分区。 要不要深读：我建议直接看 002 授权和 003 执行这两篇，其余的是实现映射。001 域模型那篇我两次抓取都失败，你本地读吧。