ECC
同样是把成熟工程流程装进 agent 的 harness 型项目,可比较两者对计划、验证与自审的强制程度。
ECC 面向单个开发者的跨仓库工作流;dsh 面向「一个仓库 + 团队授权 + 常驻监听」的组织场景。此前本方向已报道 ECC,故仅作参考。
DeepSeek 开源的仓库级常驻编码 agent 原型:只服务一个 GitHub 仓库,监听到被允许的人提出需求后自己开工作项,在独立会话与目录里干活,再回到原对话交付(通常是一个 PR),Web 面板标出仍需人处理的位置。它把「何时行动、何时打扰人」写成了显式授权模型。
dsh-superagent 是 DeepSeek 公开的一个研究原型,定位是「单仓库的主动型编码 agent」,以插件形式装进 DeepSeek Harness。它监听 GitHub,并可选监听飞书;当被授权的人提出需求时,它开一个工作项,在属于自己的 agent 会话与目录里完成工作,然后回到原始对话交付结果,通常是提交一个 PR;配套 Web 面板显示哪里还需要人介入。作者强调这是一种工作方式:尽量少占人的注意力,只在该行动时行动、只在有人必须决策或能直接用上结果时才发声,并把权限与授权单独成一章文档。仓库同时说明代码为研究用途、并非官方产品,也与论文描述的实现存在差异。
适合小团队把仓库级例行维护交给常驻 agent:issue 触发的小改动、PR 生成、重复性修复;也适合作为「按需唤醒 + 最小打扰」协作范式的参考。
TypeScript 实现(src、tests、prompts、skills、docs 等目录,pnpm 管理),以 DeepSeek Harness 插件形式交付;文档体系分哲学、领域模型、授权、执行、提示词、面板、部署、架构、Cookbook 八篇。README 自述大量工程由编码 agent 完成。本次只读 README 与目录,未运行。
它把权限与打扰当作一等设计:只在被请求或团队明文规则允许时行动,只在必须由人决策或能直接使用结果时才说话——这对 2B 场景里 agent 的越权与噪声控制很有借鉴价值。
README 明确标注仅供研究参考、非官方产品、可能含 bug、工程风格不一致,且与论文所述实现并不一致;仓库仅 1 次提交,star 增长快但成熟度低。
MIT
README 与仓库主页均标注 MIT:可商用、修改、分发,保留版权与许可声明即可。注意不要把它当成官方支持的 DeepSeek 产品;维护承诺与 SLA 不在许可范围内。
协议解读供选型参考,不构成法律意见。
作为仓库常驻 agent 的范式样本读文档(尤其授权与执行两篇),不建议直接进生产。
Star19700;观测时间:2026-11-06T05:31:20Z
暂无可比增长基线
开源代码
未找到可靠口碑
Hacker News 上围绕该仓库有多条链接帖(2026-10-31 至 11-02,3–11 分),但评论数均为 0,没有形成讨论;因此本轮未取得可核对的使用经验。
只检索了 Hacker News;GitHub Issues 与社区论坛未逐条阅读。无评论不等于无问题,也不代表项目被普遍认可。
模型知识参考,未在线核验;名称、维护状态和许可证需另行核实。
同样是把成熟工程流程装进 agent 的 harness 型项目,可比较两者对计划、验证与自审的强制程度。
ECC 面向单个开发者的跨仓库工作流;dsh 面向「一个仓库 + 团队授权 + 常驻监听」的组织场景。此前本方向已报道 ECC,故仅作参考。
dsh 官方安装路径里与记忆插件联动,可比较「会话内执行」与「跨会话记忆」的职责切分。
claude-mem 只做记忆层,不监听仓库也不执行任务。未核验两者集成细节。