一个人只能盯 3 个 AI 会话，dsh-superagent 凭什么破这个天花板？
dsh-superagent 把「人给 AI 派活」这件事从你身上拿走了，代价是你得重新学怎么当一个只负责验收的人。
这事得从上周说起。我在三个窗口之间来回切：一个修 bug，一个补测试，还有一个帮我看 PR。
没一会儿测试挂了，我得把报错复制出来，找到修 bug 那个窗口贴进去。需求变了，我得回想当时是在哪个窗口说的。另一个卡住了，我还得问它到底缺什么。
AI 在写代码，我在跟进 AI。
然后我看到了 DeepSeek 团队那句观察，一句话把我钉在椅子上：一个人通常只能同时跟进 3 到 5 个活跃 Session。
所以单任务的上限看模型能力，多任务的上限看人的注意力。你买了再强的模型，天花板还是你的脑子。
10 月 31 日，DeepSeek Harness 团队开源了 dsh-superagent-prototype，配一篇万字设计长文。我把它和仓库的九篇文档从头翻了一遍，下面说说到底动了哪块地基，以及你现在能不能用上。
· · ·
先澄清一个误会：它换的不是模型
看到「新范式」三个字，很多人的第一反应是——是不是又出了个更强的模型？
不是。模型还是那些模型。
它换的是组织方式。
你现在用 AI 是这么个流程：你当项目经理，AI 当外包。你拆需求、派活、催进度、转述反馈、验收。五个环节，你全程在场，一个都不能走神。
dsh-superagent 想干的，是把「项目经理」这个角色也交出去，你只留验收。
拆开来是五件事：会话不归你管、反馈不用你搬、命令跑着能插话、不 @ 也能干活、关机了还活着。
一条一条说。
第一刀：Session 这玩意儿，本来就不该让你看见
先看它要解决的两个死结。
所有事塞进一个会话，串行排队，上下文互相污染。接口报错、文档要求、测试输出，全糊在一份记忆里。
每件事开一个新会话，倒是并行了，但它们互不通气。你在 A 窗口定的方案，B 窗口一无所知。
官方那句话我觉得最狠：
让用户手动管理 Session，很大程度上是从底层 LLM API 延续下来的设计惯性。Session 应当是系统的实现细节，而不应是用户的认知负担。
翻译成人话：Session 是给写代码的人看的，不是给用的人用的。你打开 AI 工具先看到「会话 1、会话 2、会话 3」，就像用微信还得自己决定走哪个数据库连接。
它的解法是拆两层。
Router（调度台）：常驻，接所有人从所有入口进来的话，管全局，管分派。关键设计是它不下场干活——连 Bash 工具都不给它配。它只处理「任务之间」的关系，不碰「任务内部」的拆解。
Worker（工位）：一个活一个工位，上下文完全隔离，全套工具，最强的模型，闷头干一件事。
举个具体的。你在飞书群里说「正文、代码、终端的字体要能分别配」，它开个 Worker 去做。你转头去 GitHub 的 PR 评论里说「设置项太多了，收进折叠区」——这条评论会直接进同一个 Worker 的上下文。
你面对的始终是一个东西，不是三个窗口。
还有个细节：Worker 不直接跟你说话。它跟 Router 汇报，Router 统一对外。所以十个 Worker 在干活，不会十个窗口一起刷你屏。
这跟常见的 Agent Team 不太一样。Agent Team 是「一个大活拆成几个子任务」，主控得深度理解细节、高频协调，推理负载很重。这里 Router 只管分派，所以官方说轻量模型就够用。
第二刀：反馈不用你搬
这条我觉得最实在。
平时怎么干？AI 提了 PR，CI 挂了，你复制报错，贴回去，说「继续修」。Review 说漏了个边界情况，你再复制一遍，再贴一遍。
它干了什么：Worker 接手某个 PR 之后，会订阅这个 PR。同一个 Thread 下的后续事件——评论、CI 结果——由程序直接送到那个 Worker，不经过 Router。
打个比方：快递直接送到工位，不用每件都先过前台登记。
效果有数字。把这个「直通」关掉，Router 需要做的决定多约 30%，读缓存 token 从 2323 万涨到 3177 万，增幅约 37%。任务完成速度基本没变，纯属白烧。
这里还有个我很喜欢的克制：「顺便把用户模块也重构一下」这种话，它是会挡的。原文明说，后续消息可以补充上下文，但不会自动扩大原来的授权范围。
程序员都懂，「顺便」后面往往没什么小事。
第三刀：测试跑着，你还能改主意
这个痛点特别真实。集成测试刚开始跑，你突然想起来还有个旧客户端要兼容。消息发过去，AI 卡在那儿等命令返回，半天没动静。等它跑完，实现又得改。
原理不复杂。经典 ReAct Loop 是同步的：模型调 run()，整个循环停住，等结果回来。它把耗时的工具换成了 start() 和 stop()——start() 立刻返回「已启动」，后台跑完，结果作为一条新消息投回会话。
这样前台回话和后台干活就解耦了。你插一句新要求，它在当前这步推理结束后就能处理，不用干等。
但这里有个坑得提前说：这项能力在 DeepSeek Harness 里实现了，默认没开。别看着文章就去试，试不出来是正常的。
第四刀：不 @ 它也干活，但它先学会了闭嘴
这条最容易被吹过头，也最容易翻车。
机制叫「投机执行」。像 CPU 的分支预测：群里有人随口说「这接口升级后好像偶尔会超时」，它先在后院试着复现。修好了拿出来，修不好默默扔掉，一个字不说。
但官方在这件事上很清醒：后台尝试烧算力。要是它每试一步都往群里发消息，再丢几个猜测让大家判断，人反而更忙了。
所以默认模式是 observe——评估它推断出来的活儿，留下记录，但不实际接单。
我的建议很直接：新接入先跑一周 observe，去翻它记了哪些「准备接的活」。要是连「中午去食堂还是点外卖」都判成开发需求，说明规则得调。等判断准了，再切 auto。
一个容易踩的坑：observe 不是全局只读开关。符合授权条件的明确请求，这个模式下照样执行。上线前就弄明白，别到时候以为它什么都没干。
顺带说事件过滤，因为这块很多人会低估。真实群里是「高噪音、低触发率」，每条消息都调大模型判断，钱和延迟都顶不住。所以它做了两级：
Fast Path（代码规则）：来源、群范围、机器人白名单，先筛一刀，不花钱。
Slow Path（大模型）：过了第一关的，才让模型判断语义。
就像小区门口的保安先看工牌，可疑的才叫经理出来聊。
第五刀：关机和跑偏
两个问题，第二个比第一个值钱。
先说关机。现在你的 agent 绑在你这台机器上，合盖就歇菜。它把计算、状态、环境拆成三份：计算放云端无状态容器，状态（Session）进数据库，环境留原地不动——你的代码、你的凭据、你的内网，不搬。
端上只装一个极轻的 daemon，不存状态，只负责执行命令。官方叫 BYOM，Bring Your Own Machine。
人话：大脑在云上，手在你电脑上。
再说跑偏，这个更值钱。
Agent 挂掉，大多数时候不是进程死了。是模型陷入死循环，或者方向跑歪了。你去监控进程，进程活得好好的，token 在烧。
所以它单独配了个 Watchdog Session，定时唤醒，站在主系统外面看三件事：基础设施活不活、每个 Worker 有没有实质进展、方向对不对。
更妙的是 Watchdog 自己也是个完整 agent。维护者可以直接问它「刚才那个 worker 为啥卡住了」，也能让它在线改主系统的提示词和触发规则。
能拿自然语言运维一个跑着的 Agent 系统，这个体验想想还挺新鲜。
数据，以及数据不能证明什么
先摆结果。测试条件是约 300 条模拟消息，其中 20 个是真工作请求，其余是闲聊、跟进、叫停和 CI 消息，每种方案跑 5 次。
| 方案 | P50 | P95 |
|---|---|---|
| Super-agent | 12.4 分钟 | 15.7 分钟 |
| 单 Session + Subagent（中性提示） | — | 29.5 分钟 |
单 Session 那组有个特别扎心的细节：5 次运行，一次都没调用过 Subagent。所有活都堆在主会话里，被新消息一遍遍打断。
换一组提示词，明确要求「优先委派」，5 次里 4 次委派了，剩 1 次它觉得「这活很小」自己干了，形成一条长尾。
这说明什么？单 Session 方案的性能靠提示词、靠模型临场判断，不稳。双层架构是把这件事挪到了系统层面。
然后是必须说清楚的部分：
一、这组实验里，编码工作是用一个「只消耗时间的工具」替代的。它测的是调度和协作能力，不是代码质量。
二、换到真实项目，还得看修复正确率、审核时间、返工次数。PR 提得快、审核更费劲，这笔账未必划算。
三、消息间隔和工作时长按 1/4 缩放过。
所以「快了一倍」这话，先别说。
它现在还不能干什么
这节比上面所有夸奖都重要。
它是研究原型，不是产品。README 第一句就是这个，还自己承认可能有 bug、代码风格和工程实践不一致。官方设计文章里讨论的一些能力，仓库里并没有实现。
它不是沙箱。Worker 以运行者的操作系统用户身份执行命令，权限是 danger-full-access。独立目录和命令包装器不构成隔离，Worker 能按路径执行程序、能读你的 home 目录。真要隔离，得用专用的系统账号。
提示词注入是真风险。官方在开放问题里自己写了：云端 Agent Loop 一旦被攻破，所有连着的端侧设备都面临被控制的风险。就算没被攻破，凭据进了模型上下文也有泄露风险。
只支持单个 github.com 仓库，GitHub Enterprise 不行。
自动合并默认关着。官方建议先让人来合，等它的 PR 长期靠谱了再考虑打开。
说白了：能持续执行任务，和能放心交付，中间还隔着一堆工程活。
想试的话，照这个来
先对一下前置条件，缺一个都跑不起来：
Node.js 22.19+ 或 24+、pnpm、git 2.32+、tmux、Python 3.8+、GitHub CLI 2.48+，还有一个已经给 DeepSeek Harness 配好的模型供应商。
第一步，准备一个专用的机器人 GitHub 账号。
这条别省。它写的所有东西都挂在这个账号名下。用你自己的号，等于让它冒充你说话。
mkdir -p ~/.local/bin
cat > ~/.local/bin/gh-agent <<'EOF'
#!/bin/sh
GH_CONFIG_DIR="$HOME/.config/gh-agent" exec gh "$@"
EOF
chmod +x ~/.local/bin/gh-agent
gh-agent auth login
gh-agent api user --jq .login第二步，装。最省事的方式是让 AI 帮你装。
把仓库拉下来，然后跟你的 coding agent 说一句话就行：
Read SETUP.md in this repository and set up dsh-superagent with me.
它会一次问一个问题，收集完给你一份完整计划，你点头它才动手。问到需要你亲手做的事（建账号、登录 CLI、填密钥），它会单独发一条消息，把命令列给你，绝不在对话里问你要密码。
想手动来，命令是这些：
npm install -g @deepseek-ai/dsh@0.2.1-rc.3
git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git dsh-superagent
cd dsh-superagent
pnpm install && pnpm build
dsh superagent --from-default-profile web --dump-config > /dev/null
dsh plugin --profile superagent add "link:$PWD"
cp examples/profile.cordis.patch.yml ~/.dsh/profiles/superagent/cordis.patch.yml
scripts/dsh-superagent start提醒一句：dsh superagent --from-default-profile 只能用于全新安装。profile 已经存在时它会覆盖掉，连配置一起删。升级时千万别跑这条。
第三步，打开面板，先别改模式。
地址 http://127.0.0.1:3082，侧边栏找 Superagent。默认就是 observe，让它跑一周，翻翻它记了什么。
第四步，试一次。
用一个在允许名单里的账号，去仓库的 issue 里发一条：
@你的机器人账号
修复 /users 接口空参数导致的 panic。
补充回归测试，保持现有接口兼容。
完成后提交 PR，交给我审核。这个写法值得学：修什么、怎么验收、交付到哪，三件事一次说清。含糊的需求，它也只能给你含糊的结果。
踩坑提醒：编辑已有 issue 的正文加上 @ 是不会被发现的，必须发新评论。
日常维护就三条命令：
scripts/dsh-superagent status
scripts/dsh-superagent stop
scripts/dsh-superagent restart升级前先备份 <stateDir>/orchestrator.sqlite。它的数据库只能向前迁移，新版本打开过的库，旧版本打不开，回滚只能靠这份备份。
那到底颠覆了什么
我不太喜欢「范式」这个词，它被用烂了。但这次确实有一样东西被换了位置。
以前是：AI 的能力上限看模型，多任务的上限看你能同时盯几个窗口。
现在它试着把「盯窗口」这件事从人身上拿掉。
你的角色往后撤一层。从前是「派活 + 转述 + 催进度 + 验收」，现在只剩「定目标 + 验收」。
但账不能这么算完。
它省下的是跟进成本，多出来的可能是审核成本。PR 一天提二十个，你审得过来吗？审不过来，那就是把瓶颈从「派活」挪到了「验收」，总量一点没少。
所以我现在的判断是：这东西真正值得看的地方，不是它一天能提多少 PR，而是它有没有把「协作这件事本身」做成系统能力。
至于省不省钱、省不省人，得拿真实项目跑一个月，把修复正确率、审核时间、返工次数一起算。
算不出来，那它就只是个更聪明的多开器。
· · ·
参考资料
1. 陈煎鱼，《新出的 Dsh-superagent 是什么，新 AI 研发范式？》，脑子进煎鱼了，2026-11-02
2. DeepSeek Harness Team，《Super-agent 设计探索：迈向更自主的 Agent 系统》，2026-10-31
3. 仓库与文档：github.com/deepseek-ai/dsh-superagent-prototype（MIT License）
发表评论: