[DSH/多智能体/CodingAgent] dsh-superagent-prototype: 基于 DeepSeek Harness 的主动式、Coding 多智能体研究原型

0 序

  • Super-agent 是 DeepSeek Harness 团队 2026 年 10 月 31 日公开的一套自主 Agent 架构，配套原型 dsh-superagent 同日以 MIT 协议开源。

它是一个常驻在线的 Coding Agent，盯住一个 GitHub 仓库，也可以接入飞书群。有人 @ 它提需求，它就开工单，在独立会话和目录里干活，最后回到原对话交付，比如提一个 Pull Request。
架构上，一个常驻的 Router 负责收消息和分派，多个上下文隔离的 Worker 并行执行。再配合事件订阅直通、异步 ReAct Loop、存算分离和外部 Watchdog，Agent 可以"不切会话并行推进多项任务"。
团队的初步实验约 300 条消息、20 项工作请求：Super-agent 任务完成时间 p50 为 12.4 分钟、p95 为 15.7 分钟；带 Subagent 工具的单会话方案在中性提示下 p95 是 29.5 分钟。
官方强调这只是研究原型，不是 DeepSeek 正式产品。截至 11 月 4 日 02:00 ，Github 社区仓库约 16.3K Star（关注着）。

  • 为此，笔者进行了初步的调研。

  • 调研时间： 2026-11-04 / 调研策略： 人工 + AI

  • 产品定位：DeepSeek Harness 团队开源的「Super-agent」研究原型——一个面向单个 GitHub 仓库、可选接入飞书的主动式编码智能体；它以「Router 管任务之间、Worker 管任务之内」的双层架构为核心，把跨会话多任务的调度权从人手里收回到系统层。它是研究代码，不是官方产品。

1 概述

产品介绍

image

  • 产品定位：一个针对单个 GitHub 仓库的主动式编码智能体（proactive coding agent），以 DeepSeek Harness（DSH）的一个 bundle / 插件包形式分发。它持续监听 GitHub（可选飞书），当被允许的人提出请求时，它会打开一个工单（Ticket），在自己的 Agent Session 和独立目录中完成工作，并在原始对话里回复（例如提交 Pull Request）。一个 Web 面板展示「哪些事需要人处理」。

  • 诞生的背景与原因：

    • 以 Coding Agent 为代表的单任务 Agent 已证明模型能自主调用工具解决复杂问题，人的角色正从「逐步指挥」上移到「决策与验收」。

    • 但主流 Agent 的工作单位仍是相互隔离的单次 Session，一个人通常只能同时跟进 3～5 个活跃 Session。

    • DeepSeek 的判断是：单任务的上限取决于模型能力，多任务的上限取决于人的注意力。

    • 若仅给本地 Agent 加 CLI/MCP/连接器去收 IM 消息，会撞上三个顽疾——同步阻塞（跑长任务时无法响应新消息）、上下文混乱（多任务细节挤在一个窗口互相污染）、离线即停（合盖即停止）。

    • 要突破，就必须打破 Agent 与单次手动会话的绑定。

  • 解决的核心问题：把「维护会话、同步上下文、分派任务」这些原本压在用户身上的活搬到系统层，让一个 Agent 能跨会话、跨平台（IM / GitHub / 邮件）连续推进多个并行任务且互不干扰。

  • URLs：

  • 《Super-agent 设计探索：迈向更自主的 Agent 系统》

这篇是 DeepSeek Harness 团队 2026 年 10 月 31 日在官方公众号发表的架构技术长文，官方开源原型仓库与此对应：

资源 链接
官方开源原型仓库
（对应这篇设计，README 即 Towards a More Autonomous Agent System）		 https://github.com/deepseek-ai/dsh-superagent-prototype
DeepSeek Harness 主仓库（开源源码） https://github.com/deepseek-ai/deepseek-harness
DeepSeek Harness 官网（产品与架构介绍） https://www.deepseek.com/harness/

说明

  • 官方公众号原文是《Super-agent 设计探索：迈向更自主的 Agent 系统》，由 DeepSeek Harness 团队发布（2026-10-31 晚），但没有可直接粘贴的公开 URL 链接（公众号文章需要在其 App/网页内查看）。
  • 想读原文正文的话，GitHub 的 dsh-superagent-prototype 仓库就是与这篇文章对应的开源实现与文档，可在其中看到完整设计；也可先看几篇高质量解读（IT之家、36氪、腾讯云）作为导读。

重要免责声明（来自 README 原文）：这是仅供参考的研究原型，不是 DeepSeek 官方产品，更接近研究代码而非生产级软件，可能仍有 bug，编码风格与工程实践并不统一；它针对公开发布做过适配，与团队内部版本、与官方文章里描述的实现都不完全一致，文章里部分设计只是未来方向，未在原型中实现。

发展历程

时间 事件
2026-10-31 DeepSeek 产品部与 DeepSeek Harness 团队发布官方文章《Super-agent 设计探索：迈向更自主的 Agent 系统》，首次提出 Super-agent 概念（四特征 + 五模块）；同日在 GitHub 开源研究原型 dsh-superagent-prototype（MIT 协议）。
2026-11-01 起 被国内技术社区（阿里云开发者社区、51CTO、36氪等）广泛解读，定位为「会主动干活、更懂何时闭嘴」的 Agent 系统架构，并与 Anthropic 的 Claude Code / Claude Duet 作对比。
发布至今 项目处于早期研究阶段，社区生态尚未成形；官方明确其定位是「给开发者参考的架构蓝图与参考实现」。

注：由于仓库发布仅数日且 GitHub 访问受 robots.txt 限制，Star / Fork 数量等社区量化指标暂无法核实，以下「发展趋势」仅作定性评估（详见该节）。

主要功能

  1. 主动事件驱动：以环境事件（群聊消息、PR/Issue 评论、CI 结果、邮件/日程）作为主要输入（Trigger），替代用户逐条敲提示词；无需被 @ 也能主动定位根因并提交修复 PR。
  2. 双层架构调度：常驻 Router（只做判断与分派，不执行具体任务，甚至可不配 Bash 工具、用轻量模型）与隔离并发的 Worker（一事一 Worker，挂载完整工具、用最强模型，不直接对外说话，结果汇报 Router 统一回复）。
  3. 两级过滤 + 订阅直通：程序层（来源/群组/白名单等确定性条件）快速准入 → 语义层（模型按提示词策略研判）；已有人负责的 Thread 后续事件由程序直通给对应 Worker，不再经过 Router（多对多订阅）。
  4. 全双工异步交互：前台对话与后台执行解耦（异步 start()/stop() 取代阻塞 run()）；IM 信道单次回复不超过 100 词，按信道说话（IM 低打扰、GitHub 高信息密度）。
  5. 上下文管理（Inline & Spill + 链式召回）：把上下文窗口当 Cache 管，近期信息内联、超预算信息外置留引用；给 Trigger/Thread/Worker Session 编号形成引用图，支持跨长程运行回捞旧任务。
  6. 投机执行：后台先复现/尝试，结果有价值才交付，否则全程安静（官方内部配置了「静默复现并修复」策略）。
  7. 授权与治理：授权写在代码里而非提示词里（Gate）；主动工作默认 observe（只看不做），三档 off / observe / auto；Mandate 不可变、范围扩大须新建工单；单一写入者 Engine + 「先存后做」副作用队列，重启不丢事、不重做。
  8. Web 面板：以「是否有事需要我」优先排序展示工单、系统健康与历史，可检索 Trigger / Thread / Ticket。

核心优势

  • 把人从「消息总线」中解放出来：
    • 一个人不必在多个 Agent 窗口/多套上下文之间当调度员，由系统统一承接跨信道交互。
  • 架构层面的分工保证：
    • 不同于「用提示词劝模型分工」（不稳定），双层架构在系统层面强制 Router 不干活、Worker 只收自己订阅的消息。
    • 官方实验：去掉直通后 Router 决定数 +约 30%，读缓存 token 由 2323 万增至 3177 万（+约 37%），而完成时间几乎不变——说明直通大幅节省中心节点开销。
  • 主动但不打扰：「能用代码判断的、就不交给模型」，两级过滤控制算力与延迟；「会闭嘴」被当作核心产品能力（主动性的关键是知道何时不该打扰人）。
  • 存算分离 + BYOM：计算（云端无状态容器）与状态（数据库）、计算与执行环境（端侧轻量 daemon）解耦，支持把日常开发机（可能间歇在线）接入云端 Agent。
  • 对抗提示词注入的结构性设计：外部文本永远是最低优先级的数据，权限与范围由代码 Gate 与不可变 Mandate 决定。

主要短板

  • 不是生产级软件：官方明示为研究代码，可能有 bug、风格不一致，使用前需自行审查与适配。
  • 平台覆盖窄：只支持 github.com 与飞书，不支持 GitHub Enterprise Server；内网 GitLab、企业微信、钉钉等需自写事件源（Source）。
  • 设计不完整：官方文章中的部分设计（如端侧 daemon、跨设备持久、异步 start/stop 默认开启）尚未在原型中实现；原型 Agent Loop 仍在本地、状态存本地 SQLite，离「云端 24 小时在线」有差距。
  • 安全边界薄弱：Worker 仍以运维者的操作系统用户运行；命令垫片/目录只是默认值而非安全边界，需额外用专用 OS 账号、每工单容器、凭据代理来加固。
  • 成本更高：多 Session + 持续观察会带来更多 token 消耗（官方数据：读缓存 token 高于单 Session），本质是用更多 token 换更短更稳的完成时间。

局限性

  • 范围：面向单个仓库的编码场景；团队需要人工看面板、调规则（运营不可省）。
  • 依赖：需要 DSH（DeepSeek Harness）作为运行时，需 Node.js 22.19+/24+、pnpm、git 2.32+、tmux、Python 3.8+、GitHub CLI 2.48+。
  • 实验结论仅供参考：官方实验基于合成负载与简化环境（约 300 条消息、重复 5 次），仅作初步参考。
  • 未解决的问题（官方文末自列）：双层架构如何扩展（Router 何时水平切分、长程记忆）、脱离 Session 后如何与 Agent 协作、上下文边界与实例间协作（A2A）、云端 Agent Loop 被入侵时对端侧设备的风险与凭据泄露风险。

适用场景

  • 研发团队 / 开源仓库维护：让一个 Agent 在 GitHub + IM 之间连续推进 issue 修复、PR 评审、特性开发，且无需人逐条 @ 指挥。
  • 需要「持续在线、事件驱动」的自主协作者：个人助手（Personal Agent）形态，直接接入消息、日程、邮件与工作平台。
  • 希望学习 Agent 系统架构设计：双层 Router/Worker、事件过滤、订阅直通、存算分离、Watchdog 等可作为企业自研 Agent 系统的参考蓝本（「学原型、借概念、换底座」）。

同类竞品

竞品/参照 形态 与 dsh-superagent 的差异
Anthropic Claude Code / Claude Duet 商业产品 Duet 也会主动看邮件/日历、早间简报、发现重要事项再找用户；Super-agent 与 Duet 的共性在于「Agent 不该一直等你开口」。Claude 还有「脑手分离」（brain-hand split）思想，与 Super-agent 存算分离一致，但 Super-agent 强调先接用户日常、可能间歇在线的个人机器。
Anthropic《构建 Agent》 官方工程文章 观点看似相反（「一堆子 Agent 不如单个 Agent」），但 DeepSeek 强调二者截然不同：Agent Team 的 Team Lead 要深入单任务内部高频协调、推理负担重；Super-agent 的 Router 只处理任务之间的高层关联与分派，轻量模型即可。
主 Agent + Subagent（普通模式） 常见多 Agent 依赖提示词劝模型委派，不稳定（实验：中性提示下 5 次运行 0 次委派）；Super-agent 用【架构】实现【强制分工】。
企业自研 Agent 编排（Agent Team / 群聊 Agent） 各类 多数缺少「Router/Worker 双层 + 订阅直通 + 存算分离 + Watchdog」的系统级设计，仍是 Session 中心制。

发展趋势

  • 开源社区活跃趋势：项目发布于 2026-10-31，上线仅数日，尚处早期研究阶段；社区热度主要体现为技术媒体的密集解读与架构讨论，而非大规模生产使用。Star / Fork 等量化指标因仓库发布过短且 GitHub 访问受限，暂无法核实（待补充）。
  • 总结：作为 Super-agent 架构的公开参考实现，它短期内不是可投产产品，但其「把人注意力当稀缺资源调度」的系统设计思想具有更长周期的参考价值，可能为个人助手与研发型自主 Agent 的后续形态定调。

DSH 与 SuperAgent 的关联关系与本质区别

本节补充澄清 DSH（DeepSeek Harness） 与 SuperAgent（Super-agent） 的关系——这是理解整个项目时最容易混淆的一对概念。

二者分别指什么

概念 全称 指代
DSH DeepSeek Harness DeepSeek 的 Agent 运行时/执行环境（类似桌面/终端 Agent 平台，提供 Session、工具调用、Web 面板、插件管理器、模型 Provider 接入、Cordis 配置等）。它是通用基础设施层。
SuperAgent Super-agent（架构） / dsh-superagent（原型） 两层含义：① 官方文章提出的一种 Agent 系统架构设计范式（四特征：连续·高效·主动·持久；五模块：双层·事件驱动·交互·存算分离·Watchdog）；② 以该设计为蓝本的开源参考实现 dsh-superagent-prototype。

关联关系

  1. 载体与实现：dsh-superagent 是 打包为 DSH 的一个 bundle（插件包） 运行的，DSH 提供它所需的 Session、工具、面板与模型接入等底层能力；领域模型中的 Main Session（orchestrator，即 Router） 与 Executor Session（worker） 都跑在 DSH Session 上。
  2. 底层能力支撑：官方明确「异步 start()/stop() 机制已在 DSH 中实现（但未默认开启）」——说明 Super-agent 设计所需的异步执行、持续在线等能力，很大程度由 DSH 运行时承载，二者相互支撑。
  3. 概念落地的分层：Super-agent 是一种可复用的架构蓝图，DSH 是其首个落地载体；但该蓝图本身与具体平台无关，官方域模型（Source/Trigger/Thread/Ticket/Mandate/Subscription 等）可被其他运行时复用。
  4. 从仓库看：dsh-superagent 代码中的 orchestrator（主 Session）与 worker（执行器 Session）直接映射到 Super-agent 的 Router/Worker 概念，DSH 的 Session 管理被 Super-agent 吸收进系统层。

本质区别（对比）

维度 DSH（DeepSeek Harness） SuperAgent（Super-agent）
抽象层次 通用 Agent 运行时/平台（操作系统层） Agent 系统架构 / 应用形态（应用层）+ 参考实现
关注点 单个 Session 的执行、工具、模型接入、面板 跨会话、跨平台的多任务调度与连续性（Router/Worker 分层）
核心抽象 Session、工具、插件、Provider、Cordis 配置 Router、Worker、Trigger、Thread、Ticket、Policy、Mandate、Subscription
状态管理 Session 会话状态 领域化持久状态：Ticket/Thread/工单存库（原型为 SQLite），并主张存算分离
主动性 被动作答执行 事件驱动主动工作（观察环境、两级过滤、投机执行）
对 Session 的态度 以 Session 为基本工作单位 批判「用户手动管理 Session」是 LLM API 遗留的设计惯性，主张 Session 应由系统管理，用户只管任务
边界/开放性 是 DSH 生态的平台底座 概念可落地到 DSH 以外的平台，原型仅覆盖 github.com + 飞书
成熟度 相对成熟的运行时 研究原型（MIT，非官方产品）

一句话概括：DSH 是「操作系统」，SuperAgent 是跑在（但不限于）这套操作系统上的一种「自主协作应用」的架构设计与参考实现；SuperAgent 把「跨会话多任务调度、会话管理、持久在线」这些原本压在用户身上的负担，从 DSH 的 Session 语义之上进一步上收进了系统层。

2 工作原理与架构

概念术语

以下为 dsh-superagent 领域模型中的核心概念（引自 docs/001-domain.md，含中文对照）。

术语 中文 含义
Source 来源 一个事件流（如 GitHub、飞书）；kind 是可复用实现，instance 是一次具体配置。持有读取位置与自身 bot 身份。
Trigger 触发 一条带 Source 元数据、不可变的事件；同一条 Trigger 被接受两次只产生一个工单（幂等）。
Thread 线程 按时间排序的 Trigger 序列（如同一 PR / 同一 IM 话题 / 同一邮件串）；一个 Thread 上同一时间至多一个 Eval。
Correlation 关联 Thread 之间的关系；只补充上下文，不做路由。
Channel 渠道 Thread 的写入侧（GitHub 评论、飞书话题回复等）。
Policy 策略 版本化的受理规则 + 各 Source 的准入名单/同步/bot 列表/准入表；变更影响存量工单时会通知。
Eval 评估 对一批 Trigger 的研判，分两层：gate（准入，确定性第一层） 与 assessment（研判，模型判断）；输出 Decision。
Mandate 授权 一次 accept 授予的权限：策略版本、范围、强度、匹配规则、发送者身份、接收方式；不可变，范围扩大须新建工单。
Ticket 工单 一个授权工作单元，仅由 Eval 创建；自身定义状态（open→ended→open），不跟随执行器。
Assignment 派工 Ticket 与一个 Executor 实例的绑定；pending→running→ended。
Subscription 订阅 Ticket 与 Thread 之间的多对多关系；匹配的 Trigger 扇出给所有在订阅中的 Ticket。
Executor 执行器 执行 Assignment 的端口：每个 Ticket 一个 Executor Session + 一个目录。
Decision 决定 Eval 的结果：accept（接单）/ stop（停止）/ ignore（忽略）/ unavailable（未完成）。
Strength 强度 Mandate / Eval 依据的强度：explicit（明确）/ inferred（推断）。

核心流程：Trigger → Thread → Eval（gate + assessment）→ Ticket（含 Mandate）→ Assignment → Executor → Channel（对外回复）。人的消息到达已存在工单的 Thread 时走订阅扇出直达该 Ticket，不再经过 Eval。

flowchart LR S[Source 来源] -->|Trigger 触发| T[Thread 线程] T -->|批量| E[Eval 评估] T -->|订阅扇出| K[Ticket 工单] E -->|accept + Mandate / stop| K E -->|ignore / unavailable| X[recorded 记录] P[Policy 变更] -->|通知| K K -->|Assignment 派工| W[Executor 执行器] K -->|Channel 渠道| S

架构与运行原理

总体设计（五大模块）：双层架构、事件驱动、面向人的交互、存算分离、Watchdog。其核心运行原理可用下图概括：

flowchart TB ENV[环境信道: IM群聊 / 邮件日程 / GitHub / CI结果] --> EF1[① 事件过滤: 程序层 gate] EF1 --> EF2[语义层模型研判] EF2 -->|值得介入| R[Router 层 常驻<br>全局序点·协调点·记忆<br>批处理·链式召回·轻量模型] EF2 -->|不值得| QUIET[保持安静] R -->|分派| W[Worker 层 隔离并发<br>一事一Worker·最强模型] T[订阅直通 Thread多对多] --> W W -->|汇报| R R -->|统一回复| UI[面向人的交互<br>全双工异步 Loop·IM≤100词] W --> PS[持久化状态 Session·工单存库] PS --> EX[执行环境 端侧daemon] WD[Watchdog 外部控制回路<br>查卡死与跑偏] --> EX

分层职责：Router 管「事与事之间」，Worker 管「一件事之内」；能用代码判断的不交给模型。

关键工程机制

  1. 双层架构：Router 常驻承接所有人类交互、维护全局上下文，刻意不执行具体任务（甚至可不配 Bash 工具，用较轻量模型保证速度与效果）；Worker 上下文隔离、挂载完整工具，直接决定交付质量（用最强模型），推理过程与工具调用不刷屏，结论汇报 Router 统一对外。Router 上事件越拥挤，批处理（Prefill 并行）下有效吞吐反而越高——官方压测：需要决定的 Trigger 从约 1 条/分升到约 40 条/分，平均批大小 1.0→2.8，单次请求耗时仅 2.5s→3.9s，单个决定分摊推理时间从 6.4s 降到 1.6s。
  2. 事件驱动 + 两级过滤：程序层按来源/群组/白名单确定性准入（Fast Path）→ 语义层由模型按提示词策略判断（Slow Path）。语义层是纯自然语言扩展点，改一句提示词即可开关策略。
  3. 订阅直通（fan-out）：Router 为某 Thread 创建 Worker 后，该 Thread 后续事件由程序直接发给对应 Worker，不再经 Router；多对多（两个 Worker 撞同一 PR 时彼此可见、自行解决冲突，无需点对点通信）。
  4. Inline & Spill + 链式召回：把上下文窗口当 Cache 管（最少信息起步→局部性内联→超限外置留引用）；Trigger/Thread/Worker Session 编号形成引用图，模型可沿 ID 一跳一跳回捞旧任务，缓解 Router 长程遗忘。
  5. 投机执行：CPU 分支预测的 Agent 版——后台先干，结果有价值才交付，否则丢弃。
  6. 全双工异步：异步 start()/stop() 取代阻塞 run()；noWait 守卫（sleep 拒绝、Shell 超时>30s 拒绝、任务等待>5s 拒绝）；Worker 前台 Shell 命令超 5 秒自动转后台。注意：start()/stop() 工具原型未实现，原型用「超时转后台」的朴素办法达成全双工。
  7. 存算分离：计算（云端无状态容器）↔ 状态（数据库）分离，容器可水平扩展/重启/替换，连续性由存储保障；计算 ↔ 执行环境分离，环境留在原地，端侧只部署不存会话状态的轻量 daemon（BYOM）。原型未实现端侧 daemon。
  8. Watchdog：独立于主系统外的外部控制回路（定时消息驱动），既处理基础设施故障，也由模型判断各 Worker 是否有实质进展、方向是否跑偏；它自身也是一个完整 Agent，可用自然语言问故障原因、在线增删提示词。原型用每小时巡检任务 + 状态脚本实现。
  9. 授权与一致性：授权写在代码里（Gate，bot 永远不能产生明确请求）；受理模式三档 off/observe/auto，默认 observe；Mandate 不可变；领域层 Engine 是唯一写入者（不做 I/O），所有对外动作先写入副作用队列（Effects），提交后再执行、失败退避重试；所有 ID 由输入确定性派生，保证幂等。
  10. 存储与状态：单一 SQLite 数据库（Store），启动时加目录锁防止并发迁移/写入；重启可恢复（原型 Agent Loop 仍在本地）。

代码结构索引（节选）

模块 文件 职责
Runtime src/app/runtime.ts 组合根，启动/关闭，加状态目录锁
Engine src/core/engine.ts Trigger/Thread/Decision/Ticket/Assignment 唯一写入者；EnginePart 分 Intake/Evals/Tickets/Assignments/Replies 五部分
Store src/app/store.ts SQLite 存储，领域仓库 + 读查询 + Outbox 回执
Effects src/app/effects.ts 持久副作用队列（assessment/launch/delivery/relay/notice/reply），指数退避重试
Sources src/sources/ SourceKind 实现：Feishu、GitHub（notifications/PR/Issue/CI）
DshExecutor src/executor/dsh.ts 每个 Ticket 一个 Session + 目录；WorkerSlots 控制并发槽位
MasterAssessor src/app/assessment.ts 主 Session 研判主动候选
Prompts src/app/prompts.ts 版本化提示词配置，可在线编辑

3 使用指南

安装部署

官方设计是「让 Agent 替你完成安装」：对安装者说 Read SETUP.md in this repository and set up dsh-superagent with me.，安装 Agent 一次只问一个简短问题、给出完整计划后再执行。

前置依赖：Node.js 22.19+ 或 24+、pnpm、git 2.32+、tmux、Python 3.8+、GitHub CLI 2.48+、以及 DSH（DeepSeek Harness）运行时（含模型 Provider 配置）。

构建（Windows / Linux 通用）：

git clone https://github.com/deepseek-ai/dsh-superagent-prototype
cd dsh-superagent-prototype
pnpm install && pnpm build        # 类型检查 + 测试 + 构建
pnpm check                        # 开发期：typecheck + test + build

配置要点（SETUP.md 交互式问题）：

  • Source：仅 GitHub，还是同时接飞书？（默认仅 GitHub）
  • 仓库：owner/name；Agent 账号：建议专用 GitHub 账号（绝不用运维者本人账号），agent 一切输出都出现在该账号名下。
  • 受理名单（Policy）：GitHub 上允许哪些 login 请求工作（默认仅运维者本人）；飞书则为首个群的全部成员。
  • 执行（Executor）：checkout 目录（默认 ~/src/<name> 新克隆）、提交身份（建议用 agent 账号）、是否启用 auto-merge（默认否）。
  • 默认值（不必问）：profile 名 superagent（复制 DSH Web profile 以隔离）、端口 3082、状态目录 <home>/.dsh/state/superagent、分支前缀 agent/、受理模式 observe、每小时巡检任务。

启动与接入：安装后按 docs/006-deployment.md 的 Install / Machine configuration / Start and stop 章节执行；通过 Management API 依次保存 github Source、policy 允许名单、executor 配置与提示词；用 scripts/dsh-superagent status 校验（exit 0 且无 setup problem 即为就绪）。

关键操作

  • 发起工作：从允许名单内的账号，在仓库的某个 issue 下评论 @<agent 登录名> <请求>，约一分钟内 Overview 上会出现一个 Ticket。
  • 监督面板：在 DeepSeek Harness Web 侧边栏打开 Superagent；面板按「是否有事需要我 → 系统是否健康 → 单件工作历史」三个问题组织，Tab 为 Overview / Source / Trigger / Eval / Execution / Settings。
  • 人机协作：Worker 需要决策或验收时才会发问（一次只问一个具体问题）；可在 Ticket 上查看 Mandate、Policy 版本、Inputs、Subscriptions 与 Assignments，支持 Retry、Evaluate again、Stop 等操作。
  • 运维纪律（官方 Responsibility 三原则）：start narrow（先短名单 + observe 记录）、tune for less noise（Agent 太吵就改短改严提示词或暂停，不要用更多消息解释噪音）、own what it says（审阅 agent 以你名义发布的内容）。

安全提醒：原型的命令垫片/目录只是默认值，不是安全边界；Worker 以运维者的操作系统用户运行，生产使用至少应配专用 OS 账号，敏感场景建议每工单一个容器 + 凭据代理。

F 附件 & 扩展

F.1 AI博主(数字生命卡兹克)的专项解读 （必读）

关于《Super-agent设计探索：迈向更自主的Agent系统》的解读 + 笔者的体验
“一个人通常只能同时跟进3到5个活跃的会话，在这种设计下，单任务的上限取决于模型能力，多任务的上限取决于人的注意力。”

该博主的核心观点：

1. 核心思想：把【任务的"起点"】从注意力/精力有限的【人】身上拿掉

  • 引 DeepSeek《Super-agent设计探索》开篇："【单任务】上限取决于【模型能力】，【多任务】上限取决于【人的注意力】。"

  • 【人的注意力】是Agent系统中【最宝贵的资产】、【最大的瓶颈】。普通用法（打开窗口→下命令→看它干→检查）的弊端是：所有事都以你为起点，不开窗口就什么都不发生，你永远只能并行推进盯得过来的3~5个会话。

  • 解法：用"领导力思维"改造系统——像明朝皇帝批奏折（票拟+批红），Agent能自己处理的就自己干，只把需要你拍板的事推到你面前，你只做点击确认（"批奏折"）。

2. 四层架构（事件 → 执行 → CI → 决策）

  • ① 自动化中台：所有事件（定时任务、Webhook、消息/邮件/告警）先汇聚到统一格式的短消息，按 rules.json 里的规则决定叫醒哪个Agent、用什么模型、并行度、是否需要人决策。带来的收益：接新事件/换Agent只需改一行规则、统一去重、消息只走"小卡"一个出口、全量数据沉淀、流水线可视化。
  • ② Agent执行：模型按特长分工——Claude Opus 5.5 主力开发、GPT-6.1 Sol 管运维查修BUG、GPT-6.1 Terra 干浏览器/电脑操控。关键判断：做决策/管理的模型必须是最强最主动的，"不能用笨的指挥聪明的"。全部跑在本地两台Mac上（不上云，因为登录态/权限/隐私都在本地）。
  • ③ CI中台：Agent只写到"提交合并请求"为止，不能自行上线。后面五步全自动：审查（Codex只读审查，最多3轮）→ 检查（类型/测试/构建，每任务开全新虚拟机跑完即删）→ 合并（写死进GitHub规则）→ 发布 → 核实（确认线上版本真的包含改动）。实测298个合并请求、333条问题306条被合并前修掉。中位数两三分种上线，全程无需人管。
  • ④ 飞书批奏折：Agent把"票拟"（建议处理意见）做成飞书卡片推给你，你只点击同意，Agent继续往下干。

3. 几个实用原则/细节

  • 推到你面前的事件只限几类：删数据、停服、花钱、对外发消息、改产品方向、新建/轮换密钥、改权限。其余Agent全权完成（这是踩坑后总结的，否则一天几十条会摧毁注意力）。
  • "定了的事不问第二遍"：仓库里有《卡兹克定的事》（亲口决定+原话+日期）和《定了不做的事》（拒绝过的事直接照答），防止重复打扰。
  • 唯一不交给Agent的：用户反馈。每条有价值反馈都亲自看、亲自发给Agent执行、解决后回真诚的邮件——保留最后的"仪式感"。
  • 配套细节：每个自动化任务配一个专属Skill（本质是沉淀的SOP，方便解耦管理）；本地Mac每台挂一个"接单程序"轮询中台（解决内网无法被公网推入的问题）；成本约 200刀 Claude会员+100刀 GPT会员。

4. 作者画像（背景可参考）

  • 一年前是完全不懂开发的设计师，一年后靠这套系统做出百万月活、9000 star的开源公益产品（AIHOT），还给公司搭了【AI化中台】。

总结：Agent自动化的终极意义不是"更强的模型"，而是通过事件驱动 + 规则调度 + 只做关键决策，把人的注意力从"事必躬亲"中解放出来——本质上是用做皇帝/带团队的方式，让人退到"批奏折"的位置，只保留最高价值的判断和少数有意义的仪式感（如用户反馈）。

Z FAQ for dsh-superagent

Q: dsh-superagent 是 DeepSeek 的正式产品吗？

不是。README 明确其为仅供参考的研究原型，非官方产品、非生产级软件，可能含 bug，与内部版本和官方文章描述不完全一致；文章里部分设计（如端侧 daemon、异步 start/stop 默认开启）未在原型中实现。

Q: Super-agent 和「主 Agent + 子 Agent」有什么区别？

本质不同。Agent Team 的 Team Lead 要深入单个复杂任务内部做拆解与高频协调、推理负担重；Super-agent 的 Router 只管任务之间的高层关联与分派，不碰任务内部拆解，用轻量模型即可；Worker 间上下文隔离、靠订阅同一 Thread 感知冲突。官方实验显示「用提示词劝模型委派」不稳定（中性提示下 5 次运行 0 次委派）。

Q: 它怎么做到「没人 @ 也能主动干活」？

靠两层策略叠加：程序层按来源/群组/白名单确定性粗筛，语义层由模型按提示词里团队写好的策略（如「静默复现并修复」）判断。语义层是自然语言扩展点，加规矩改提示词即可，不用动代码。

Q: 会不会很烧 token？

会。Super-agent 本质是用更多 token 换人的时间与注意力。官方数据：去掉直通后读缓存 token 从 2323 万增至 3177 万（+约 37%）；多 Session + 持续观察都会增加消耗，企业需算清这笔账。

Q: 能接入 GitHub Enterprise 或国内 Git 平台吗？

原型只支持 github.com 与飞书，不支持 GitHub Enterprise Server；内网 GitLab、企业微信、钉钉需自写事件源（Source）。官方建议「学原型、借概念、换底座」：领域概念与授权模型照搬，事件源与执行器重写。

Q: 安全上要注意什么？

授权写在代码而非提示词（bot 永不产生明确请求）；主动工作默认 observe。但 Worker 仍以运维者 OS 用户运行，命令垫片/目录不是安全边界；云端 Agent Loop 一旦被入侵或提示词注入攻破，其连接的端侧设备都有风险。生产至少用专用 OS 账号，敏感场景每工单一个容器 + 凭据代理。

Q: 一个 Router 不会成为瓶颈吗？

官方结论是相反——事件越拥挤，Router 有效吞吐反而越高。因为上轮推理期间到达的 Trigger 会积压、下轮一并注入形成批处理（Prefill 并行），单次请求耗时增长远慢于批大小。在他们当前团队规模下，一个常驻 Router 就够用，不必过早水平切分（切越细，全局上下文连续性越差）。

Q: 状态存在哪里？重启会丢吗？

状态存本地 SQLite（单一数据库，启动加目录锁），重启可恢复；所有 ID 由输入确定性派生 + 「先存后做」副作用队列，同一条消息读多少次只生成一个工单，重启不丢事、不重做。但原型 Agent Loop 仍在本地，端侧 daemon / 云端容器化未实现。

Q: superagent 可以理解为是一种多 agent 架构吗？是的，但区别于传统多智能体的协作模式（必读）

  • 可以这么理解，但要分两层看——它内部确实是多 Agent 架构，但对外是「单一 Super-agent 实体」，这恰恰是它区别于【传统多 Agent 协作】的本质。

从内部实现看：是「多 Agent + 分层调度」

系统里有多个独立运行的 Agent 会话/单元：

单元 角色 自主性
Router（常驻） 全局协调点，接所有入口、分派任务、统一对外说话 有全局决策权
Worker A/B/C…（隔离并发） 一事一个 Worker，各挂完整工具干自己的活 只对分配给自己的 Ticket 负责，不对外说话、不做跨任务决策
Watchdog（外部回路） 巡检主系统，查卡死/跑偏 独立控制回路，本身也是个完整 Agent

所以从「有几个 agent 进程/会话在同时运行」看，它是典型的多 Agent 架构，甚至 Worker 内部还能再开 Subagent。

但它的形态是「一个 Agent」，而非「多个平级 Agent 协作」

关键区别在于协调点只有一个，且 Worker 不是自主对等体：

  • 传统多 Agent（如 Agent Team、多智能体协商）：多个 agent 平级，各自对外、互相协商，靠「主 Agent 深入任务内部拆解 + 高频协调」。
  • Super-agent：Router 是唯一的全局序点和对外身份，Worker 只是被调度、被隔离的执行单元，彼此靠「订阅同一个 Thread」感知存在，不做点对点通信，也不向用户说话。

一句话：对外是「一个记性好、24 小时在线、会主动干活的同事」；对内是一个 Router 管着多个 Worker 的「分层调度系统」。

更准确的说法

Super-agent 不是「多 Agent 架构」的简单子集，而是一种面向持续在线、事件驱动场景的 Agent 系统架构：它用「双层」回答了【传统多 Agent】 一直没解决的两个问题——多任务并行（多 Worker） 和 统一连续的交互体验（单 Router）。所以：

它是「多执行体 + 单协调面」的架构：执行维度是多 Agent，交互维度是单 Agent。这也是官方反复强调它和 Agent Team「截然不同」的原因。

如果你把「多 Agent 架构」理解为「内部有多个【执行单元】并行干活」，那它就是；如果你把它理解为「多个平级 Agent 互相协作对外」，那它不是。

Y 推荐文献

  • dsh-superagent-prototype

关于《Super-agent设计探索：迈向更自主的Agent系统》的解读 + 笔者的体验
“一个人通常只能同时跟进3到5个活跃的会话，在这种设计下，单任务的上限取决于模型能力，多任务的上限取决于人的注意力。”
在整个Agent系统里，人的注意力是最宝贵的资产，同时也是最大的瓶颈。

X 参考文献

posted @ 2026-11-04 01:57  数据知音  阅读(20)  评论(0)    收藏  举报