一天一个开源项目

一天一个开源项目（第253篇）：dsh-superagent —— DeepSeek 开源的“主动式”编程智能体原型，核心原则是少占人的注意力

dsh-superagent 是 DeepSeek 团队开源的研究原型：一个守着单个 GitHub 仓库的主动式编程智能体，以插件形态运行在 DeepSeek Harness 里，监听 GitHub（可选飞书），被允许的人 @ 它时开一张工单，在独立的 Session 和目录里干活，再回到原对话里交付，比如一个 Pull Request。它的设计围绕一句话：用尽可能少的人类注意力，给出尽可能多的价值。MIT 协议，创建三天已有 1.5 万 Star。官方明确说明这是研究原型，不是 DeepSeek 的正式产品。

·约 26 分钟阅读·AI 工程
开源项目dsh-superagentDeepSeek HarnessAI Agent编程智能体GitHub飞书开源

引言

一个能替整个团队干活的智能体，也能浪费整个团队的注意力。

这是"一天一个开源项目"系列的第 253 篇文章。今天带你了解的项目是 dsh-superagent（deepseek-ai/dsh-superagent-prototype）。

先把 README 开头的声明放在前面，因为它很重要：这是一个仅供参考的研究原型，不是 DeepSeek 的官方产品。 代码来自团队的日常开发，其中大量工程工作由编程智能体完成；它不完全等同于内部版本，也不等同于论文《Exploring Super-agent Design: Towards a More Autonomous Agent System》里描述的实现，文中讨论的一些设计只是未来方向，原型里并没有实现。

那它值得读的地方在哪？不在代码成熟度，而在设计文档。仓库里九份按顺序阅读的文档，把"一个主动干活的智能体应该怎样克制"讲得非常具体：什么时候该出手，什么时候必须闭嘴，权限怎么授、怎么收，一张工单怎么开始、续上和结束。

你将学到什么

  • dsh-superagent 是什么，以及它和 DeepSeek Harness 的关系
  • 核心原则"少占注意力、多给价值"如何落到具体设计上
  • Source、Trigger、Thread、Eval、Mandate、Ticket 这套领域模型
  • 授权与准入：谁能让智能体开工，主动干活为什么默认只记录不执行
  • 一张工单的执行、交付与故障恢复
  • 局限与适用边界

前置知识

  • 用过 GitHub 的 Issue、Pull Request 和通知
  • 了解编程智能体（Claude Code、Codex、DeepSeek Harness 等）的基本概念
  • 对"怎样给自动化智能体设边界"感兴趣

项目背景

项目简介

dsh-superagent 是一个守着单个 GitHub 仓库的主动式编程智能体，以 bundle 的形式打包给 DeepSeek Harness（简称 DSH）。

README 的描述是：它监听 GitHub，也可以监听飞书。当一个被允许的人向它提出工作请求时，它会开一张工单，在自己的 Agent Session 和目录里干活，并在原来的对话里回复，比如一个 Pull Request。网页面板则只展示需要人处理的东西。

关于 DeepSeek Harness：官网的说法是，它是 DeepSeek 开源的 harness，建立在 Cordis "一切皆插件"的架构之上，可以作为桌面应用运行，也可以从代码启动 Web 界面，目前处于全球公开预览阶段。dsh-superagent 就是这个体系里的一个插件包。

作者与团队

  • 出品：DeepSeek（GitHub 组织 deepseek-ai）
  • 创建时间：2026-10-31，目前只有一次提交（"feat: add the dsh-superagent research prototype"）
  • 状态：研究原型，README 提示"可能仍有 bug，代码风格和工程实践可能不一致，使用前请审查和调整"

项目数据

数据取自 2026-11-03 的 GitHub，仅供参考：

  • ⭐ GitHub Stars: 约 15,500（创建仅三天）
  • 🍴 Forks: 约 1,660
  • 📄 License: MIT
  • 💻 语言构成: TypeScript 约 200 万字节，另有少量 CSS 和 Python
  • 📦 依赖运行环境: Node.js 22.19+ 或 24+，pnpm，git 2.32+，tmux，Python 3.8+，GitHub CLI 2.48+，以及符合 engines.dsh 范围的 DSH
  • 🌐 DSH 官网: deepseek.com/en/harness

主要功能

核心作用

它在做的是这样一条链路：

  1. 监听：GitHub 的通知、关注的 Issue 与 PR、CI 变化、PR 合并或关闭；飞书的实时事件和话题轮询
  2. 判断：一个被允许的人在这里明确 @ 它，才算一个请求；没人要求的事，需要团队写好的规则才能做
  3. 开工：为每个请求开一张工单，给它一个独立的 Executor Session 和一个独立目录
  4. 交付：把结果回到原对话里，通常是一个 Pull Request
  5. 看板：Web 面板只列出需要人处理的东西，健康状态不占地方

使用场景

  1. 团队仓库的日常小活

    • 在 Issue 里 @agent 请求，一分钟左右出现工单，随后看到确认回复和后续 PR

  2. 在飞书群里提需求

    • 配置好机器人后，允许的人在群里 @ 它

  3. PR 评审后的跟进

    • 评审意见、CI 结果通过"订阅"回到对应工单，智能体继续改

  4. 按团队规则做主动工作

    • 比如写规则让它处理某类依赖更新，先在 observe 模式下只记录"本来会接单"，确认靠谱再切到 auto

  5. 把智能体当同事来管理

    • 面板里看待办、审批、重试、暂停，而不是盯着一堆日志

快速开始

官方的做法本身就很有意思：安装步骤很多，所以让智能体陪你做。

对你的编程智能体说：

Read SETUP.md in this repository and set up dsh-superagent with me.

SETUP.md 是写给智能体看的安装流程，它规定了这个安装智能体自己也要遵守"少占注意力"：

  • 先只读 SETUP.md 和 docs/000-philosophy.md，跑一次探测命令，收集完答案之前什么都不读
  • 每条消息只问一个问题，每条不超过 300 字，每个问题都附一个"一个词就能接受"的推荐答案
  • 问的时候不执行，答案收齐后给出完整方案，等你确认再动手
  • 绝不在聊天里索要密钥，需要你亲手做的步骤（创建账号、登录 CLI、填应用密钥）汇总成一条消息，给出让你在自己终端里执行的命令

问题的顺序跟着领域模型走：先问请求从哪来（只用 GitHub 还是也用飞书、哪个仓库、用哪个 GitHub 账号），再问谁可以提需求，最后问智能体怎么处理工单（本地克隆在哪、提交署名、是否自动合并）。

默认值也很保守：

  • 单独的 profile superagent，端口 3082
  • 分支前缀 agent/
  • 接单模式 observe（只记录不执行）
  • 提交署名用智能体自己的账号
  • 自动合并默认关闭：在智能体的 PR 靠谱一段时间前，由人来合并

手动配置的示例 profile 很短：

- id: webserver
  config:
    host: 127.0.0.1
    port: 3082
- id: dsh-superagent
  config:
    stateDir: <绝对路径，例如 /home/me/.dsh/state/superagent>
# 飞书可选
# - id: dsh-superagent-feishu
#   disabled: false

开发者命令：pnpm check 会依次跑类型检查、测试和构建。

核心特性

  1. 只在被要求或被规则允许时行动

    • 请求必须直接点名智能体，并且来自被团队允许的人

  2. 只在有人必须行动或能用上结果时说话

    • 确认一次，干活时安静，出结果、需要决定或无法完成时才再发消息

  3. 一次只问一个具体问题

    • 用结构化字段问，让问题真正传到人手里，而不是埋在长报告里

  4. 按影响停手，而不是按工作量

    • 局部改动做到可评审的结果；需要设计决策的改动停下来问

  5. 诚实汇报

    • 草稿标成未完成，失败就报失败，遇到限制不绕过去，而是问

  6. 团队用文字塑造行为

    • 三个团队提示段（沟通、工单范围、交付要求），外加团队 Skill，覆盖大部分需求

项目优势

对比项dsh-superagent在终端里手动喊编程智能体常见的 GitHub 机器人
触发方式在 Issue / 群里 @ 即可，异步人守在终端前固定事件触发
权限边界白名单 + 授权记录 + 准入表，宿主强制执行取决于当前会话取决于脚本
主动性有，但默认只记录，规则要团队写无有，但逻辑写死
对人的打扰设计目标就是最小化无常常很吵
可审计面板能追溯 Trigger → Eval → Ticket看终端历史看日志

为什么值得读？

  • 它把"主动智能体"的克制写成了可执行的规则，而不是一句口号
  • 授权模型很细：谁能让它开工、开工后能走多远、规则改了怎么办，都有交代
  • 文档按编号顺序递进，每份只依赖前面的，可以当作一份设计文档范本

项目详细剖析

一句话哲学：注意力是成本

docs/000-philosophy.md 只有三千字节，但整个项目都从它展开：

Take as little human attention as possible, and give as much value as possible.

每个消息、通知、问题、设置、面板元素乃至一段文档，都要花某个人的注意力，每一项都必须给出比它花费更多的价值，否则就删掉。

这条原则推出对智能体的要求（前面"核心特性"已列），也推出对设计本身的要求：

  • 概念要少：设计里只有领域概念（如 Source）及其具体实现（如 GitHub、飞书），业务需求变成其中某个概念的属性或智能体遵循的提示词，而不是新增一个概念
  • 设置要少：当一个默认值适合几乎所有团队，就用默认值代替设置；团队能用文字描述的行为，是提示词文本，不是设置
  • 面板只展示需要人处理的：健康状态不占空间
  • 文档按顺序读：每份编号文档只依赖前面的

最后一节是"责任"，写得很直白：智能体用团队每天都能看到的账号评论、开 PR、发消息，它发的每一条都在消耗同事的注意力，责任在运营者。

  • 从窄开始：白名单短一点，主动工作先只记录；等"本来会做什么"看起来对了再放宽
  • 为减少噪音调优：吵的时候把提示词写得更短更严，或者暂停它，不要再加消息去解释噪音
  • 不要用它刷量：批量 PR、广播消息和忙活，花掉团队的比给的多
  • 对它说的话负责：读它以你的名义发的内容，错了就在提示词里纠正

最后一句话是："目标是在对的时间给对的帮助，其他时间什么都不做。"

领域模型：从 Trigger 到 Ticket

docs/001-domain.md 定义了整套概念。主线是：

工作从 Trigger 流向 Eval 再流向执行。Source 产生 Trigger；Trigger 作为上下文扇出给订阅了其 Thread 的 Ticket。通过这种方式到达某 Ticket 的人的消息，留在该 Ticket；其他所有 Trigger 进入 Eval，由它判断是否是新工作请求。Eval 接单时创建带 Mandate 的 Ticket。Assignment 把 Ticket 交给 Executor，结果经 Channel 回到 Source。

核心概念（括号里是文档给出的中文名）：

概念含义它保持的规则
Source（来源）事件流，如 GitHub 或飞书保存自己的读取位置和机器人身份；丢弃自己机器人的消息；重启不能重放事件
Trigger（触发）一个不可变的事件接受两次也只创建一张 Ticket，是审计和幂等的单位
Thread（线程）按时间排列的 Trigger同一时刻最多一个 Eval；可以有多张 Ticket
Channel（渠道）Thread 的写入端确认、回复、PR、已解决的评审都是写入
Policy（策略）带版本的评估规则，以及各 Source 的部分（谁能发起工作等）规则一变，运行中的 Eval 必须丢弃
Eval（评估）对一批 Trigger 的判断，分准入和研判两层无状态，输出一个 Decision
Mandate（授权）接单授予的东西：策略版本、范围、强度、匹配规则、发送者身份不可变；范围变宽要开新 Ticket；只有人的停止能撤回它
Ticket（工单）一个被授权的工作单元只有 Eval 能创建；有自己的状态，不跟随 Executor
Assignment（派工）Ticket 与一个 Executor 实例的绑定一张 Ticket 随时间可有多个
Subscription（订阅）Ticket 与 Thread 的多对多关系后续讨论不用再 @ 智能体就能到达执行者

有两个设计很值得停下来看。

第一，"人"不是领域概念。 Trigger 带着 Source 给出的发送者标识；白名单是某个 Source 在 Policy 里的一部分，用的是该 Source 自己的身份体系。同一个人在 GitHub 和飞书各有账号，这件事是智能体需要时读的提示词文本，而不是跨 Source 的身份映射表。

第二，文档专门有一节"被否决的概念"，记录了没有采用的方案和原因，例如：

被否决原因
把 Ticket 状态绑到 DSH Session 上Ticket 可以被交接、恢复，或由多个 Executor 运行，所以它定义自己的状态
Executor 声明"有人让我停"只有 Eval 决定终止的强度
策略变化时取消运行中的 Ticket取消会留下半成品；改为记录变化并送达
通过报告的自由文本推断"在等人"分类需要结构化事实；Executor 用结构化字段提问
每个 Thread 最多一张活跃 Ticket一个 Thread 里可能有几件互相独立的事

把"不做什么以及为什么"写下来，是很多项目缺少的。

授权与准入：谁能让它开工

docs/002-authorization.md 的开头一句话定下基调：

宿主强制执行白名单、规则和 Mandate。消息、评论和被引用的文档是决策的输入，不能改变这些权限。

Trigger 走两条路：

  • Eval 路径：判断是否开新工作。Source 会记录消息是否点名了智能体（mention 提及，或 direct 私信）。被允许的人点名它，是一个明确请求；其他人的消息走准入表；白名单上的机器人可以产生"推断候选"，但永远不是明确请求
  • 订阅路径：延续已有工作。订阅的 Thread 上的每条消息（包括机器人和 CI 的）都作为上下文到达订阅的 Ticket，绕过准入但不授予任何新权力，每张 Ticket 仍受自己 Mandate 的限制

强度分两档：

强度情形
explicit（明确）白名单里的人点名智能体，或在已有 Ticket 的 Thread 里跟进；准入表中设为明确请求的格子
inferred（推断）不在白名单的人在有 Ticket 的 Thread 里跟进；准入表中设为推断候选的格子；白名单机器人的消息
不准入其他机器人，准入表忽略的一切，以及接单模式为 off 时所有推断情形

接单模式是策略的一部分：

模式效果
off没有任何推断能成为候选
observe（默认）推断候选会被评估，通过的记录为"本来会接单"的忽略，不接单
auto推断候选评估通过就接单

明确请求在所有模式下都有效。先在 observe 下跑，复核记录下来的决定，再切到 auto。 每次评估对每条启用的规则都判断一次；主动接单至少要匹配一条规则。

规则变了怎么办也有交代：Policy 变化会丢弃运行中的 Eval 并重新排队，对受影响的活跃 Ticket 送一条"策略已变"的输入，说明是匹配的规则变了、请求者不再被允许，还是主动工作不再被接受。但它不会立刻撤销已有 Ticket 的 Mandate。 恢复一张已结束的 Ticket 之前，才会按当前策略重新校验：

  • 明确的跟进 Mandate 通过
  • 推断的 Mandate 需要 auto 模式且匹配的规则仍启用
  • 一个由准入表格子给出的 Mandate，仍需达到至少原来的强度；把发送者从白名单移除，会撤销通过"白名单发送者"格子得到的 Mandate
  • 机器人的 Mandate 需要该机器人仍在白名单

校验失败，Ticket 保持结束，其中等待的每条消息被当作"没到达任何 Ticket"处理，若无其他 Ticket 拥有它就送去 Eval。

还有两条细节：

  • 人在 Thread 里说"停"，只是一个普通 Trigger，由 Eval 决定停止。 Executor 不能自己声称"有人让我停"
  • 面板里点"停止"是命令，直接作用于 Ticket，记录为手动停止

订阅与"归属"：跟进消息归谁

这部分是最容易看晕、也最体现设计功力的地方。

一个人在某张 Ticket 自己的 Thread 里发消息，归这张 Ticket 的 Executor 决定，不再经过 Eval，也不产生 Decision。Executor 要么在 Ticket 范围内处理，要么交还（hand back）：当请求超出范围或属于另一张 Ticket 时。

只有当没有任何 Ticket 还拥有这条消息时，它才进入一次新的 Eval，候选里带着各 Executor 交还的理由。

Ticket 结束时，会释放它的 Executor 没读到或没有处理的跟进消息；没被确认、回答或交还的那些，各自去 Eval。

主动与被动也被区分：Executor 可以订阅相关 Thread（比如另一个 Issue 或 PR）当作仅上下文，那里的消息能到达 Ticket，但不授权，也不会唤醒已结束的 Ticket。

执行：一张工单怎么活着

docs/003-execution.md 把一张开着的 Ticket 分成互斥的几个阶段，从上到下取第一个匹配的：

阶段条件面板标签
person / delivery向 Executor 递送输入失败Input undelivered
person / answer有一个 Attention（等人回答的问题）Awaiting answer
person / review最近的报告是 readyAwaiting review
person / blocked, failed最近的报告是 blocked 或 failed，之后没人回复Blocked · Failed
working / queued没有 Assignment，或在等待Queued
idle报告是 waiting，或 Assignment 已结束Waiting for a Trigger
working其他Working

凡是 person 阶段，都表示"没人输入就走不下去"。一条新的人的消息会把 blocked 或 failed 的 Ticket 放回 Executor 手里。

Executor 是什么：每张 Ticket 得到一个名为 worker-<ticket id> 的 Executor Session 和一个以 Ticket 短名命名的目录。Session 以运营者的操作系统用户身份无需批准地运行命令。前台 shell 命令超过 5 秒会被转入后台任务，这样 worker 能在下一步收到新消息，而不是等一条长命令。

文档对"后台工作"的规定很细：

  • 一轮结束时若还有 shell 任务或子智能体在跑，Ticket 保留它的 worker 槽并保持 working，不会报告 waiting
  • 每轮之后，后台工作最多有 30 分钟完成；超时 shell 任务会被杀掉，Ticket 报告 waiting，并说明哪些任务被杀、哪些子智能体仍在
  • 交给人时立即释放槽位；子智能体停止，而像"给评审用的服务"这类 shell 任务可以继续到 Assignment 结束

并发：配置的并发上限作用于 worker 槽，另外多留一个槽给"人的消息或状态请求"。也就是说，新工作不会挤掉人继续已有 Ticket 的机会。

准备目录：第一个 Assignment 之前，如果 Ticket 目录不存在，会在执行根目录里用 sh 跑一次准备命令，限时十分钟，典型做法是用 git worktree 建一个检出。分支名的最后一段与 Ticket 短名匹配，该 PR 就归这张 Ticket。

执行变量：准备命令和 Executor 都能读到同样的变量，比如 DSH_SUPERAGENT_DIR、DSH_SUPERAGENT_TICKET、DSH_SUPERAGENT_GITHUB_REPOSITORY、DSH_SUPERAGENT_GITHUB_ACCOUNT，不含任何凭证。

合并：由提示词管，而不是宿主

自动合并由"交付要求"这一段提示词控制，宿主没有任何合并相关的决策逻辑。

默认情况下，Executor 绝不会以智能体账号启用自动合并，因为 GitHub 把合并归属于启用它的人。交付要求里必须指定另一个账号的 CLI 来合并，否则由人合并。

默认指令只允许在以下条件同时满足时自动合并：该 PR 是为这张 Ticket 开的、已就绪、所需批准覆盖了 head 提交、增删行数合计少于 200 行。再推新版本之前，Executor 先撤回自动合并。

文档的态度很清醒：这些说明约束的是智能体，不是 GitHub 的合并规则。 要强制批准，就在分支保护里要求，并让过期批准失效。

提示词：团队怎么塑造智能体

docs/004-prompts.md 讲清楚了团队能改什么：

段落内容
Communication（沟通）什么时候给人发消息、怎么写、每条 GitHub 消息开头那行（默认 This is by an automated agent, not a human）、怎么处理评审、哪些普通账号是评审机器人
Ticket scope（工单范围）Ticket 何时继续、何时带着草稿停下
Delivery requirements（交付要求）PR 中的证据、自动合并条件和行数阈值、提交作者
Team skills（团队技能）智能体需要时加载的知识，比如一个说明飞书用户对应哪个 GitHub 账号的 identities 技能

系统提示词按固定顺序组装：共享指令和角色，三个团队段，订阅与回复，调度或工作指令，准入，交接，环境，以及最后的 Policy 段。Policy 段在每次模型请求时重新生成，放在最后，这样策略变化不会改动前面的提示词文本（对缓存友好）。

优先级从强到弱：

  1. 工具和宿主强制的事实（身份、权限、参数检查、回复用途、长度限制），提示词改不了
  2. 内置和生成的段落（含团队覆盖）
  3. 主动 Ticket 匹配规则里的流程和沟通要求，仅对该 Ticket 的 Executor 有效
  4. 团队段和团队技能
  5. 外部文本：消息、评论、文档、引用。它是数据，永远不改变规则或授权

最后一条是提示词注入的防线：来自外面的文字再像命令，也只是数据。

内置文本的原则也值得一读，例如：

  • 角色分离：主 Session 只做路由，转发原始 Trigger 和路由事实，不做技术决定；一条路由备注最多 30 个词；Executor 阅读原始来源、判断范围、实现并验证
  • 主 Session 不等待：报告、跟进通知、候选和完成的后台任务自动作为消息到达；守卫会拒绝 sleep、超过 30 秒的 shell 超时和超过 5 秒的任务等待，因为一个被阻塞的步骤会拖慢新候选
  • 只在人必须行动或能用上结果时发消息，聊天消息默认一句话，硬上限 100 词
  • 只在明确引用时才挂接：消息必须指向某个 Ticket 的 PR、Issue、源消息或确认回复，主题相似不够
  • 诚实交付：开了 PR 不等于就绪；草稿要标未完成；没有真实"之前"截图的 UI 改动不算就绪
  • 让位给重复工作：当某人的分支或 PR 已经包含这张 Ticket 的改动，Executor 用一句话关闭自己的 PR 并指向对方的
  • 评审按结果处理：修好并验证的评论静默解决；拒绝的给一句理由；每个自动评审机器人在一个 PR 上最多三轮

故障与恢复

执行文档用大量篇幅讲"出问题怎么办"：

  • Executor 阻塞或失败：Ticket 不再接受自动输入；对暂时性的模型提供方或网络故障（HTTP 408、429、5xx，连接被拒绝、重置或超时）先自动重试三次带退避；失败后 CI 和机器人消息只记录，不递送，也不唤醒 Session；人的消息、之后一个非 blocked/failed 的报告或重试会解除阻塞
  • 重启：运行中的 Assignment 以"host restarted"结束，新的 Assignment 带一条恢复备注启动，要求 Executor 在重复任何外部动作之前先检查自己的目录、git 历史和 GitHub，按最老的 Ticket 优先
  • "先存后做"：dsh-superagent 在做出决定之后的动作（转发候选、启动 Assignment、递送输入）先落盘再执行，失败按 2 秒起、翻倍到一分钟重试；某类工作只有同一项连续失败三次后才会出现在总览的系统问题里
  • 渠道失败：发出的消息也按存储的工作处理，从 5 秒起翻倍到 300 秒退避；同一 Ticket 到同一对话的消息保持顺序，确认一定先于后面的回答；只有当 Source 不再监听该对话，或明确答复该对话永远收不到时才丢弃，丢弃的消息保留记录，所以"确认"读起来是"已丢弃"而不是"已发送"
  • 暂停处理：停止调度、新的 Eval、Eval 超时、输入递送和回复；Source 继续记录 Trigger，运行中的 Executor 轮次不被打断

面板：只回答三个问题

docs/005-panel.md 规定打开面板按顺序回答三个问题：有什么需要我现在处理吗？系统健康、在做对的事吗？一件工作从 Trigger 到 Eval 到 Ticket 的历史是什么？

标签页按工作流排列：Overview、Source、Trigger、Eval、Execution、Settings。Overview 先列需要处理的 Ticket，再是系统问题、24 小时活动计数和 Executor 负载。

代码结构

src 下的大致分层：

目录内容
src/core领域核心：engine.ts、evals.ts、tickets.ts、assignments.ts、intake.ts、replies.ts、ports.ts 等
src/sourcesGitHub 与飞书的 Source 实现：读取、触发、渠道、轮询、注册
src/executor与 DSH 的对接（dsh.ts）和后台任务管理（background.ts）
src/app运行时、HTTP 接口、设置、提示词装配、会话管理、迁移、工具
src/client面板前端（React / TSX）
src/infra命令、环境、健康检查、路径
prompts/、skills/默认提示词与 GitHub、飞书两个 Skill
tests/大量测试，最大的几个文件 runtime.spec.ts 约 142 KB、core-engine.spec.ts 约 107 KB

docs/007-architecture.md 约 70 KB，是架构文档；docs/008-cookbook.md 约 30 KB，讲如何新增一个 Source。我这次没有逐行读这两份。

适用范围与局限

  • 官方定位是研究原型：不是 DeepSeek 的正式产品，不建议直接当生产软件用；使用前要审查和调整
  • 与论文并不一致：原型与内部版本、与论文描述的实现都不完全相同，论文里的一些设计仍是未来方向
  • 依赖 DeepSeek Harness：它是 DSH 的插件包，需要符合版本范围的 DSH，以及一个已配置的模型提供方
  • Executor 的权限很大：Session 以运营者的 OS 用户身份、无需批准地执行命令。文档明说包装脚本和目录是默认值，不是安全边界，worker 仍可以用绝对路径运行程序。部署前请想清楚它能碰到什么
  • 前置依赖多：Node 22.19+、pnpm、git、tmux、Python、GitHub CLI、DSH，以及一个专门的智能体 GitHub 账号（文档建议不要用你自己的）
  • 只面向单个 GitHub 仓库，飞书为可选；其他代码托管平台需要自己写 Source（docs/008-cookbook.md 讲怎么加）
  • 默认要靠人把关：自动合并默认关闭，主动接单默认只记录
  • 非常年轻：创建三天，目前只有一次提交，没有发布版本，文档会演进
  • 文档为英文：另有少量中文界面文案（locale/zh.json）

项目地址与资源

官方资源

相关资源

  • 论文: Exploring Super-agent Design: Towards a More Autonomous Agent System（README 引用，我这次没有找到原文，未读）
  • Cordis 论文: DSH 官网列出了 Cordis paper

总结与展望

核心要点回顾

  1. 注意力是成本：每条消息、设置、面板元素都要证明自己值得占用人的注意力，否则删掉
  2. 主动，但克制：只在被要求或有团队规则时行动；主动接单默认只记录，不执行
  3. 授权可追溯、不可篡改：Mandate 不可变，只有接单、人的停止和重新校验失败能改变它；外部文本永远只是数据
  4. 谁拥有这条消息：订阅与"交还"机制保证每条跟进消息有且只有一个归属，不会被两边同时处理，也不会无人处理
  5. 文档本身就是产品：按顺序阅读、记录被否决的方案和原因，是一份很好的设计文档范本

适用人群

  • 想让编程智能体在团队仓库里异步、受控地干活的工程负责人
  • 正在设计"主动式智能体"的授权、准入、订阅和降噪机制的开发者
  • 在写 Skill、提示词体系或智能体文档的人，这个仓库的文档组织方式值得借鉴
  • 关注 DeepSeek Harness 生态的人

使用建议

不要先装。先按顺序读 docs/000-philosophy.md 到 docs/003-execution.md，四份加起来不长，再决定要不要在自己的仓库上跑。真的要试的话，用一个专门的 GitHub 账号，白名单只写你自己，接单模式留在 observe，让它先"想做"一段时间，再决定是否放宽。

探索 PrimeSkills —— 精选 AI agent 和技能工具，每一个都经过真实工作流验证。没有炒作，只有真正好用的工具。

访问我的个人主页，获取更多见解和有趣的产品。

← 返回博客列表