本文合并两篇公众号解读并做交叉核对：

  • 程序员鱼皮《DeepSeek 开源超级 Agent，牛逼！》（2026-11-03，原文）——概念与案例视角
  • 向明《7 张动图看懂 DeepSeek 的 Super-agent：合上电脑，Agent 还在跑》（2026-11-02，原文）——机制拆解与实测数字

两文数字能互相对上的地方已标注；配图见原文。另补了本机下载/评估开源原型的第一手记录。

一句话总结

DeepSeek Harness 团队提出 Super-agent 架构：把 Agent 从”单次会话”里解绑，让它像一个常驻的项目团队——跨渠道记上下文、同时推进多件事、被环境事件驱动、出问题能自恢复。

为什么需要 Super-agent

现在的 Agent（Claude Code / Codex / DeepSeek Harness）都以会话为单位跑 ReAct Loop：想一步、做一步、看结果。单任务没问题，多任务就崩：

  1. 会话之间互相隔离，跨任务信息全靠人肉搬运——人成了 AI 之间的传话筒。
  2. 一个人同时只能跟进 3–5 个活跃会话。单任务上限取决于模型，多任务上限取决于人的注意力。
  3. 给单会话接上飞书/GitHub 也不行，三个毛病：跑耗时命令时整个循环卡住；多需求堆一个会话上下文越来越乱；跑在本地电脑上，机器一休眠它就停。

作者的实测例子：让 Agent 跑 sleep 45 && echo 构建完成，期间问它”周会几点”，消息被排队 50 秒直到构建完成才回复。

四个特征，以及各自靠什么实现

特征 大白话 靠什么实现
连续 群里说的事，GitHub 评论里它还记着 双层架构（Router/Worker）
高效 上一件事没干完，也能接新指令 双层架构 + 全双工交互
主动 没人 @ 它，也盯着，该干就干 事件驱动 + 两级过滤
持久 合上电脑它还在跑，出错能自恢复 存算分离 + BYOM + Watchdog

和 Agent Team 的区别：Agent Team 解决”一个大任务怎么拆”，Team Lead 要亲自下场协调；Super-agent 解决”很多个任务怎么分”，领头的只管派活和关联判断。和 Personal Agent 的区别：后者是产品形态，Super-agent 是撑起它的底层架构。

怎么实现（五个模块 + 实测数字）

1. 双层架构：Router 管连续，Worker 管并发

  • Router 层（项目经理）：常驻在线，收所有渠道消息，记住全局、跟人沟通、给 Worker 派活。只派活不干活——甚至可以不给它终端工具，用轻量模型就够。
  • Worker 层（工程师）：每个任务一个，上下文互相隔离，干完只向 Router 汇报，不直接找你。Worker 才需要最强模型。

原文有句话点破了设计动机：“Session 应当是系统的实现细节，而不应是用户的认知负担。” 我们习惯”开新对话”，其实是被底层 API 的设计带着走的。

Router 会被消息挤爆吗？ 反直觉的答案：消息越多，摊到每条上越快。因为 Router 是批处理的——它上一轮在思考时，新消息先攒着，下一轮一起看。Router 每步”读得多、写得少”，多塞几条耗时涨得慢。

实测（向明文）：消息从约 1 条/分钟涨到约 40 条/分钟，每批平均从 1.0 条到 2.8 条，单次请求从 2.5s 涨到 3.9s；分摊到每个决定，从 6.4s 降到 1.6s。上限是上下文长度和单轮能准确处理的条数，所以团队规模内一个 Router 够用，不提前拆。

2. 事件驱动：Trigger + 两级过滤 + Thread 直通

  • 事件统一叫 Trigger：群消息、邮件、日程、PR 评论、CI 结果。Agent 的驱动源从”你打字”变成”环境发生的事”。
  • 门卫（快路径）：纯代码判断来源（监听的群？白名单的人？），大部分消息这一步就挡掉，不花钱。
  • 秘书（慢路径）：剩下的候选才交给大模型，按提示词里的策略判断要不要动手。规则想加想关，改提示词即可——“能用代码判断的，就别浪费模型的智能”。
  • Thread 直通：同一个 PR / 群话题 / 邮件串 = 一个 Thread（工单）。Worker 接手后订阅它，后续消息由程序直接送到 Worker，不再经过 Router。

实测（向明文）：去掉直通，任务完成时间基本不变，但 Router 决策多约 30%，读缓存 token 从 2323 万涨到 3177 万——正好对上鱼皮文的”+37%”（3177/2323≈1.37），两个来源互相印证。

订阅还是多对多的：两个 Worker 都在改同一个 PR，就都订阅这个 PR，不用互相通信也能看到对方动作，有机会自己发现并解决冲突。

3. 上下文：当缓存来管（Inline / Spill / 链式召回）

“浪费上下文窗口，就是浪费模型的智能。”

  • Inline：马上可能用到的，直接塞进窗口——消息 ID、摘要、前后几条相邻消息。
  • Spill：太长、不常用的留在窗口外，窗口里只放引用+摘要，需要时再读（DeepSeek Harness 终端输出超限转存临时文件就是同款思路）。
  • 链式召回（Chain of Recall）：每个对象都带”下一跳 ID”——从消息找到所属 Thread，从 Thread 找到负责的 Worker，从 Worker 找到关联的评审。模型顺着编号一跳一跳往下找，不用把历史全背下来。

4. 投机执行：没人叫它，它先干着

借 CPU 的 Speculative Execution：还不确定结果有没有用，先在后台试一试，有用就交，没用就扔。收到会议邀请，先后台核对日程、查资料、备好草稿，你确认即可发送。

DeepSeek 内部配了**”静默复现并修复”**规则：只有确认了问题、且找到了简单修复，才出声；否则全程不说话。经典案例：用户还在群里讨论”波浪号被渲染成删除线该改哪层”，修复 PR 已经交上来了。

安全边界：主动行为必须有团队预设规则，且默认先开观察模式（observe）——只记录”我打算做什么”，不真动手。

5. 交互与部署：全双工 + 存算分离 + BYOM + Watchdog

  • 全双工：ReAct 从”对讲机”变”电话”。耗时工具调用异步化：start() 立刻返回”已启动”，循环继续；后台跑完，结果作为一条新消息送回；跑太久还能 stop() 主动叫停。注意：这个异步机制 DeepSeek Harness 已实现，但还没默认开启。
  • 渠道分级话术：IM 群里只在需要拍板/验收时出声，单次回复**≤100 词**（他们验证过的硬规定）；GitHub/邮件/文档则相反——背景、改动、验证结果写完整。
  • 存算分离：计算放云端无状态容器，会话状态进数据库。容器挂了换一个，记录一条不丢。
  • BYOM（Bring Your Own Machine）：真实环境里有未提交的改动、私有凭据、内网服务，搬不动就不搬——云端做大脑，本地只装轻量 daemon 执行命令、回传结果。Agent 可以在几台机器间切换；某台电脑今天没开机，等它重新上线，云端自动把那台机器上的活补上。
  • Watchdog：主系统外单独放一个看门狗 Session 定时巡查。重点不是”进程在不在”，而是任务有没有实质进展、方向有没有跑偏（Agent 出事常见形态是原地打转，不是崩溃）。它本身也是个 Agent：你可以直接问它”刚才为什么挂了”，也可以让它在线修改主系统的提示词和触发规则。

这些设计借了哪些”老思想”

Agent 里的问题 借的思想
消息太多 Fast Path / Slow Path（快慢路径）
Router 扛不住 批处理（Batching）
上下文塞不下 缓存、Inline/Spill、局部性
不想干等 投机执行（Speculative Execution）
电脑一关就停 存算分离
跑着跑着出事 外部控制循环（Watchdog）

原文自己说：没有提出新理论，只是把计算机系统的经典思想搬到了 Agent 上。

实验数据

约 300 条消息/次、其中只有 ~20 条正经活，四种方案各跑 5 次：

方案 中位完成 95% 完成
Super-agent 12.4 min 15.7 min
单会话·普通提示 5 次实验 0 次派活给 Subagent 29.5 min
单会话·劝它派活 5 次里 4 次照做 ~29 min

结论：“靠制度管人，比靠自觉靠谱”——与其用提示词劝模型分工，不如架构上规定死。单会话方案的问题不是不会分工，是模型自己不愿意分工。
代价：多会话并存的读缓存 token 是单会话的 2–4 倍（绝对值见上，2323 万→3177 万）；实验基于合成负载与简化环境，只作初步参考。

怎么用起来

分两个层次：直接跑原型，或把架构思想搬进自己的 Agent 工作流。

A. 直接跑开源原型（真机评估结论）

这是给单个 GitHub 仓库用的常驻主动编码 Agent，作为 DeepSeek Harness 的 bundle 分发：白名单的人提需求 → 开工作项 → 独立会话干活 → 在原会话答复（通常交 PR）；Web 面板显示”需要人拍板”的事。

  • 环境：Linux 风格（启动脚本依赖 tmux）→ Windows 需 WSL；Node 22.19+/24+、pnpm、git 2.32+、gh 2.48+、@deepseek-ai/dsh@0.2.1-rc.3
  • 账号：一个专用 agent GitHub 小号（绝不能用自己的账号——它所有 commit/PR 都以该身份出现），对目标仓库有写权限；gh-agent wrapper 独立凭证
  • 安装：pnpm install && pnpm build → dsh superagent --from-default-profile web → dsh plugin --profile superagent add "link:$PWD"；然后让编码 Agent 读仓库里的 SETUP.md 带着你装（它一次问一个问题，收齐给计划）
  • 使用：面板默认 127.0.0.1:3082 侧栏 Superagent；配 Sources（仓库+gh-agent）→ Policy（白名单，列表为空时什么都不响应）→ Execution（每工单 worktree 命令）→ Prompts
  • 触发：白名单账号在 Issue/PR 评论 @agent小号 <需求>，约 1 分钟出 Ticket；注意编辑 Issue 正文不会触发，要发新评论
  • 安全：默认 observe 模式（只记录不执行）；它 danger-full-access 跑在 OS 用户下，官方建议配独立 OS 账户；先拿私有玩具仓库 + 白名单只填自己试
  • 成本：常驻轮询 + Worker 用强模型，token 消耗持续；本机评估结论是单机学生场景用不上（详见本机下载记录）

B. 借思想到自己工作流（轻量四件套，零基建）

不装原型也能拿到 80% 的收益，核心就四条：

  1. 一个入口 + 多个隔离 Worker：主会话只做派活/汇总，脏活丢给子 agent（ZCode 的 Agent + SendMessage；DSH 的 dsh headless --session-id）
  2. 批处理：攒一批消息/待办再统一处理，别一条一醒
  3. 订阅直通：同一任务线（一个 PR/一个话题）的后续消息直接进对应 Worker，不过主入口——文件版就是”每个任务一个专属文件/目录”，别全塞进一个总 WORKLOG
  4. Watchdog 定时检查：定时任务只问”有没有实质进展”，不只看”进程活没活”（ZCode 的 CronCreate / DSH 的每小时检查提示词）

官方留下的开放问题

  1. 规模再大、跑上几个月，一个 Router 还够吗？跨月长期记忆怎么办？
  2. 人不盯会话之后，用什么界面协作？聊天窗口可能只是路径依赖。
  3. 一个组织配几个 Super-agent，就是在决定哪些信息共享、哪些隔离；隔离实例之间怎么协作（A2A）？
  4. Agent 越主动，接触的不可信信息越多——提示词注入怎么防？云端一旦被攻破，连着的设备都有风险。

本机下载记录（2026-11-03 实测）

git clone 直连 github.com 被连接重置（Recv failure: Connection was reset），但 api.github.com 和 codeload.github.com 可达。走 codeload 拿 main 分支 tarball 快照解压到：

1
C:\Users\glj07\Desktop\琉璃幻彩的文件\23-AI与开发项目\dsh-superagent-prototype
  • 仓库元数据（API 实测，2026-11-03）：14,742 stars，size 775 KB，main 分支，MIT，简介 “Towards a More Autonomous Agent System”
  • 快照不含 .git 历史；热点/家里网络下可补全：git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git
  • 结构：TypeScript + pnpm，src/{core,app,client,executor,infra,sources}、prompts/team、skills/dsh-superagent-{feishu,github}、docs/000-008（philosophy → architecture/cookbook 编号递进）、tests
  • 最新评估（2026-11-04）：README 明确”研究原型，非官方产品”；部署体积约 3 MB，纯静态阅读价值 > 运行价值
  • 安全提醒：未审读的他人代码不要直接执行；跑之前先看 docs/002-authorization.md 与部署文档

最后

DeepSeek 自己说没提出新理论，只是把计算机系统的经典思想（批处理、快慢路径、投机执行、存算分离、看门狗）搬到了 Agent 上。两篇解读的落点一致：AI 不缺干活能力，缺的是组织能力。 以后的人机分工可能是：你带着一个 AI 团队，只负责拍板和验收。