Agent 的下一个瓶颈，是你只有一双眼睛
DeepSeek 在文章里写了一个数字，很不起眼，但扎心：
一个人通常只能同时跟进 3 到 5 个活跃 Session。
这就是今天所有 Agent 产品的隐形天花板。你买了十个 Agent，最后还是要排队——因为你不是在等模型，你是在等自己看完。
10 月 31 日晚，DeepSeek Harness 团队发了一篇技术文章《Super-agent 设计探索：迈向更自主的 Agent 系统》。不是发模型，是发架构。
他们的判断很直接：单任务的上限取决于模型能力，多任务的上限取决于人的注意力。而现在，前者已经不是瓶颈了。
他们想要的 Agent，有四个特征
- 连续：你在 IM 里说"用方案 A"，转头在 GitHub 评论里改成"用方案 B"，它知道你说的是同一件事，不用你解释"Session X 里有没有 Y"
- 高效：上一个任务还在跑，你可以直接下一条指令，不用等
- 主动：群里有人反馈 bug，没人 @ 它，它自己去复现、找根因、提 PR
- 持久：你的电脑关机了，它还在云上活着；你重新上线，它接着干
这四件事，一个 ReAct Loop 一件都做不到。所以 DeepSeek 拆出了五个模块。
一、Router 不干活，Worker 不说话
这是整套设计里最反直觉的一条。
传统做法是"一个会话干所有事"：上下文最连续，但串行、慢，而且多个任务的细节会互相污染。
另一种做法是"每个事件开一个新会话"：并发高，但没有全局上下文，而且十个会话同时跟你说话，你会疯。
DeepSeek 的方案是分两层：
- Router 层常驻，负责所有人类交互、全局协调、记忆。它不执行具体任务，甚至可以不配 Bash 工具
- Worker 层上下文隔离、工具挂满，专心干一件事，用最强的模型。它不直接跟人说话，只向 Router 汇报
这个设计有个很实在的好处：Router 不碰执行，就没有删除文件、改数据库的权限。群里混进一条提示词注入，最坏结果是"派错活"，不是"删库"。
DeepSeek 还特意区分了它和常见的 Agent Team：Team 是一个复杂任务内部拆角色，Lead 要深度理解任务、高频协调，推理负担很重；这里的 Router 只管任务之间的分派，用轻量模型就够了。
二、把 Agent 的输入，从"提示词"换成"事件"
这是"主动"的来源。
在 Super-agent 里，群聊消息、邮件、日程提醒、代码审查评论、CI 结果，都叫 Trigger。Agent 不再等你打字，而是持续看着这些事件流。
但真实群聊是"高噪音、低触发率"——绝大多数消息跟它无关。每条都调一次大模型判断，延迟和成本都受不了。
所以他们用了计算机系统里的 Fast Path / Slow Path：
- 程序层先按来源、群组、白名单做确定性过滤，挡掉大部分噪音
- 语义层再把候选事件交给模型，判断要不要动手
事件进了系统，还有一套"订阅直通"：Router 只负责新任务的冷启动，已经分配出去的 Thread（同一个 PR、同一个群话题、同一封邮件串），后续消息由程序直接发给对应的 Worker，不再经过 Router。
还有两个细节挺妙：
Inline & Spill。 把上下文窗口当 Cache 管：近期可能要用的信息直接内联，超长的、低频的留在窗口外，只放摘要和 ID，模型需要时再顺着 ID 去捞。他们管这个叫"链式召回"——从一条消息找到所在 Thread，从 Thread 找到 Worker，从 Worker 找到另一个代码评审 Thread。
投机执行。 群里还在讨论怎么修，它已经在后台把 PR 提了。确认有价值就交付，没价值就丢掉——用后台算力换人的等待时间。他们内部群里配了一条"静默复现并修复"策略：只有确认问题、并且找到简单修法时才出声，否则全程安静。
三、把"存算分离"搬进 Agent
本地 Agent 有个天生缺陷：计算、状态、执行环境绑在一台机器上。电脑一睡，Agent 就死。
DeepSeek 分两步拆：
- 计算与状态分离：Agent Loop 跑在云端无状态容器里，Session 状态存数据库。容器可以重启、扩容、替换，会话不丢。
- 计算与执行环境分离：执行环境留在原地，端侧只装一个不保存会话状态的轻量 daemon，负责执行命令、返回结果。
这就是他们说的 BYOM（Bring Your Own Machine）——把你自己的开发机接进云端 Agent，而不是把代码搬到云上重建环境。未提交的改动、本地凭据、内网依赖，都留在原地。
甚至支持间歇在线的设备：你的笔记本关机了，任务排队；等你开机，云端 Agent 自动触发，把需要在本机跑的那一步补上。
这套思路和 Anthropic 的"脑手分离"是一致的，区别在场景：Anthropic 讲的是托管沙箱和客户 VPC，DeepSeek 要先接的是你日常那台可能随时关机的个人电脑。
四、Watchdog：让一个 Agent 盯着另一群 Agent
长期在线的系统，不能只靠主系统自己保证可靠。而且 Agent 的故障往往不是进程崩了，是模型陷入无效循环，或者偏离目标——这种故障，进程监控根本发现不了。
所以他们在主系统之外放了一个独立的 Watchdog Session，用定时消息驱动，构成外部控制回路。
它做两件事：
- 处理接口报错、状态恢复失败这类基础设施故障
- 由模型判断每个 Worker"有没有实质进展""方向有没有偏"
更特别的是，Watchdog 本身也是一个有完整工具能力的 Agent Session。维护者可以用自然语言问它"昨晚为什么卡住了"，也可以让它在线改主系统的行为——加删提示词、调整触发规则。
用一个 Agent 运维另一群 Agent，这个画面有点赛博，但逻辑上很合理。
数据：快，但更费 token
他们做了一个消融实验：300 条消息（其中约 20 条是工作请求），同时驱动群聊和 GitHub CI，跑 5 次。
| 方案 | p50 | p95 |
|---|---|---|
| Super-agent | 12.4 分钟 | 15.7 分钟 |
| 单 Session + Subagent（中性提示） | — | 29.5 分钟 |
| 单 Session + Subagent（提示优先委派） | 略好 | 仍慢于 Super-agent，且有长尾 |
中性提示下，模型 5 次运行里一次都没调用 Subagent，所有活都在主会话里干，不断被新消息打断。改成"优先委派"的提示后，5 次里有 4 次委派了，但还是比双层架构慢——剩下那 1 次它觉得"活很小"，自己干了，形成了长尾。
代价也很清楚：维护多个独立会话，读缓存 token 更高。去掉"直通"机制后，完成时间几乎不变，但 Router 的决策次数增加约 30%，总读缓存 token 从 2,323 万涨到 3,177 万，多了 37%。
换句话说：它不是更省，是用更多 token 换更短、更稳的完成时间。
Router 本身也做了压测：Trigger 从每分钟 1 条加到 40 条，平均 batch 从 1.0 涨到 2.8，单次请求耗时只从 2.5 秒涨到 3.9 秒，单个决策分摊的推理时间反而从 6.4 秒降到 1.6 秒。批处理把拥堵变成了吞吐。
丑话：四个没解决的问题
DeepSeek 自己在第 8 节列了开放问题，而且写得挺诚实：
1. Router 什么时候该切分。 现在一个常驻 Session 够用，但团队规模再大呢？切得越细吞吐越高，全局记忆越碎。
2. 跨月记忆。 链式召回解决的是"近期任务"，跑几个月之后，长程记忆就是瓶颈。
3. Session 藏起来之后，人怎么协作。 底层有十个会话，界面上该给用户看什么？任务进行到一半，人想插手，怎么插？
4. 安全与隐私。 这条最要命。云端 Agent Loop 一旦被入侵或被提示词注入攻破，它连接的所有端侧设备都可能被控制；就算云端没被攻破，只要本地凭据进了模型上下文，正常执行也可能泄露。他们的原话是：如果安全隐私问题解决不了，Super-agent 只能在一个很小且可信的范围里工作。
另外两点得说清楚：实验基于合成负载和简化环境，官方自己说"部分设置还可以更严谨"；代码在 GitHub 上的 dsh-superagent-prototype 只是验证技术路线的插件原型，不是正式产品。
我的判断
这不是"又一个 Agent 框架"。
它是把操作系统那套东西——内核调度、进程隔离、看门狗、存算分离、投机执行——原样搬进了 Agent 系统。DeepSeek 自己说得很直白："我们并没有提出全新的理论。"
但恰恰是这种"不新"，说明方向开始收敛了。过去两年大家在卷模型，现在开始卷 harness：谁能把多个模型、多个会话、多个设备调度好，谁就能让同样的模型干出更多的活。
对普通用户，短期内没什么可用的——原型是个插件，得自己装、自己配。
对开发者，这套设计可以直接抄：Router/Worker 分层、事件过滤的 Fast/Slow Path、订阅直通、Inline & Spill、外部 Watchdog。每一条都不依赖 DeepSeek 的模型。
真正难的不是架构，是信任。你把开发机接进云端 Agent 的那一刻，交出去的不只是算力，还有你所有的本地凭据。
DeepSeek 把这个问题写进了"开放问题"，而不是"产品特性"。这个态度，比架构本身更值得注意。
相关链接：
- 官方文章（DeepSeek 知乎机构号）：https://zhuanlan.zhihu.com/p/2099987320443237060
- 原型代码（MIT）：https://github.com/deepseek-ai/dsh-superagent-prototype
- DeepSeek Harness 官网：https://www.deepseek.com/harness/
- DeepSeek Harness 源码：https://github.com/deepseek-ai/deepseek-harness
暂无评论。