# DeepSeek Harness team proposes a super-agent design for more autonomous agent systems

> Original title: DeepSeek Harness 团队 Super-agent 设计探索：迈向更自主的 Agent 系统

- Source: meng shao
- Published: 2026-10-31T14:41:48.000Z
- Bad Influence: https://badinfluence.news/items/c7e640qrxlsd969vzpp9jjo7b
- Original: https://x.com/shao__meng/status/2116541149443698968

## Summary

A DeepSeek Harness team engineering discussion, shared by meng shao, argues that single-task agents are already strong and the bottleneck is how many sessions a person can track at once. The proposed super-agent uses a two-layer Router and Worker design, event-driven triggers, asynchronous ReAct, and cloud loops with a local daemon. A synthetic test reported p50 and p95 completion times of about 12.4 and 15.7 minutes for the super-agent, versus about 29.5 minutes for a single-session setup at p95.

## Post

DeepSeek Harness 团队 Super-agent 设计探索：迈向更自主的 Agent 系统

DeepSeek Harness 团队的工程架构探讨分享，团队认为，单任务 Agent 已经够强，瓶颈变成「人同时盯得住几个 Session」。Super-agent 要把 Agent 做成跨信道连续、能并行多任务、事件驱动主动干活、云端持久在线的实体；做法不再堆一个聊天窗口，转而用经典计算机系统思路（双层 Router/Worker、事件过滤与直通、异步 ReAct、存算分离加端侧 daemon、外部 Watchdog）把 Session 变成实现细节，人只做高层决策与验收。

问题从哪来
Coding Agent 证明模型能少盯着干活；个人助手又把消息、日程、邮件接进来，变成持续在线、事件驱动。但主流设计仍以单一 Session 为基本单位：并行几件事就要人手动切 Session、自己记上下文，一个人通常只能跟住大约 3–5 个活跃 Session。于是单任务上限看模型，多任务上限看人的注意力。只在本地单会话上挂 CLI/MCP，仍躲不开同步阻塞、上下文搅在一起、设备离线就停。

# 四个基础特征

连续（IM、GitHub 评论像同一个 Agent，不问「Session X 里有没有 Y」）、高效（可并行多任务，不必等上一条做完才能说下一条）、主动（持续观察环境，该出手才出手）、持久（始终在线，异常能自愈）。文中举例：同一开发任务在 IM 与 GitHub 之间连续推进；公共群无人 @ 也能主动定位根因并提修复 PR。

单个 ReAct Loop 撑不住这四点，于是拆成五个模块。

1. 双层架构：连续性 vs 吞吐
· 全进一个 Session：上下文最连，但串行慢、细节互相污染。
· 每条事件新开 Session：吞吐高，缺全局上下文，对用户也乱。

解法：Router 层常驻，承接人类交互与全局协调，当序点、协调点、记忆；不亲自执行具体任务（甚至可不挂 Bash）。Worker 层上下文隔离、挂满工具，专做单任务，用最强模型；对外不直接说话，状态汇报给 Router，由 Router 统一回复。

文中刻意区分：常见 Agent Team 是一个复杂任务内部拆角色，Lead 推理很重；这里的 Router 只管任务之间的高层分派。实践里 Router 往往用更轻模型就够。事件积压时 Router 会把多条 Trigger 批进一次长输入短输出的调用；积压适度时，单个决定摊到的推理时间反而下降（7.2 节有压测）。规模再大再谈 Router 内多层过滤或水平切分——切得越细吞吐越高、全局连续性越差，在全局记忆未解前这权衡一直在。

Worker 内部仍可再开 Subagent 或自己就是 Team，对 Router 透明。个人助手前端一个聊天框，底层也可按话题分 Worker。

2. 事件驱动：Trigger，不是等人逐条打字
驱动主输入改成群聊、邮件、日程、Code Review、CI 等半结构化 Trigger。
· 两级过滤（Fast/Slow Path）：程序层按来源、群组、白名单等确定性规则先砍噪音；过线的再交给 LLM 做语义判断（提示词可随时改策略）。
· 订阅与直通：同一 PR / IM 话题 / 邮件串 = Thread。Router 冷启动建 Worker 并订阅后，同 Thread 后续事件程序直通 Worker，不再每次经 Router 转发；Router 仍可观测全局，但只管未订阅的新事件。Thread↔Worker 多对多：多人改同一环境时共享事件、自行发现冲突，结论仍经 Router 对用户说。
· Inline & Spill + 链式召回：把上下文窗口当 Cache，近期高概率信息 Inline，长内容 Spill 成摘要/续读入口。对象带唯一 ID，注入时内联下一跳关联 ID，形成引用图，需要时多跳按需展开（消息→Thread→Worker→另一评审 Thread）。
· 投机执行：会议邀约可先对日程、备资料、起草回复；群里讨论 bug 时可后台静默复现，确认简单可修才交结果，否则保持安静。

3. 面向人的交互
· 异步 ReAct：耗时工具从同步 run() 改为 start()/stop()，立刻返回 Started，结果事后当事件投回；前台可继续收指令。文称 DeepSeek Harness 已实现但尚未默认开启。
· 按信道改输出带宽：IM 低打扰、单次回复不超过约 100 词；GitHub/邮件写结构化背景、改动说明与验证。

4. 计算、状态与环境分离
本地 Agent 常把 Loop 计算、会话状态、仓库与工具链绑在一台机器上，休眠即停。两步拆开：
· Loop 放云端无状态弹性容器，Session 状态进数据库 → 云端持久在线。
· 重状态执行环境留在原地，端侧只跑无会话状态的轻量 daemon 执行命令、回结果（BYOM：日常开发机也可接入）。文中对齐 Anthropic「脑手分离」，但场景更强调个人机上未提交改动与本地凭据，而不仅是托管沙箱/VPC。

5. Watchdog（外部 Control Loop）
独立 Watchdog Session，定时消息驱动：既看接口/状态等基础设施，也用模型看 Worker 有没有实质进展、是否跑偏。维护者可用自然语言问它、让它改提示词或触发规则。

实验（合成负载，初步参考）
约 300 条消息、约 20 条工作请求，编码用耗时占位工具。Super-agent 任务完成时间 p50/p95 约 12.4 / 15.7 分钟，好于「单 Session + Subagent」：中性提示下模型 5 次都不委派、被新消息打断，p95 约 29.5 分钟；强调委派后仍整体更慢且偶发长尾。代价是多会话带来更高读缓存 token。去掉直通后完成时间差不多，但 Router 决定数约 +30%、读缓存 token 约 +37%；直通主要省 Router 开销，不直接加快完成。Router 压测：Trigger 从约 1 条/分到约 40 条/分，平均 batch 1.0→2.8，单次请求 2.5s→3.9s，单个决定分摊推理时间 6.4s→1.6s。

未解问题（第 8 节）
Router 何时切分、Worker 何时要直连通信；跨月长程记忆；Session 对用户隐藏后，产品侧任务呈现与中途介入怎么做；组织级上下文边界与 A2A；云端 Loop + 端侧 daemon 的入侵面与「用不接触凭据本身」的凭据使用。文末强调：若安全隐私无解，Super-agent 只能缩在很小的可信范围里。

GitHub dsh-superagent-prototype 主笔 Yujia Qiao
https://github.com/deepseek-ai/dsh-superagent-prototype
公众号文章地址
https://mp.weixin.qq.com/s/zoS7GlReWPhfCjENGxXCdg

![](https://badinfluence.news/api/img-proxy?u=https%3A%2F%2Fpbs.twimg.com%2Fmedia%2FHV9241iXIAAmYGf.jpg&mode=thumb&exp=1793664000&sig=6239f7d22770b812)