先说结论：DeepSeek 团队 10 月 31 日晚的《Super-agent 设计探索》最值钱的地方，不是「AI 指挥 AI」，而是把 Agent 的瓶颈从模型能力挪到了人的注意力。
判断成立；但把它当成下一代 Agent 已落地，就过了。
一个人同时开三四个 Agent 窗口，很快记不清哪个在跑测试、哪个在等权限。DeepSeek 观察到，人通常只能同时跟进 3 到 5 个活跃会话。DeepSeek
所以它提出 Super-agent：跨会话保持上下文、同时推进多件事、互不干扰，让用户始终面对同一个 Agent。
它还说，Session 本不该让用户管理。这句像口号，其实是全文的架构前提。DeepSeek
架构不新，拼装得完整
做法是两层：常驻 Router 接消息、维护全局上下文、负责分派；每个任务一个 Worker，上下文隔离、工具齐全、用最强模型。
再往下是事件驱动、订阅直通、上下文当缓存、异步 ReAct、存算分离和 Watchdog。知乎
大多是操作系统和分布式系统的老思路。DeepSeek 也承认，文章没有新理论；价值在拼装，不在发明。DeepSeek
把「要不要分工」从提示词挪到系统层，比多开几个 Agent 窗口难得多。
实验能证明调度，不能证明写代码
官方做了两组初步实验，都是自测、合成负载。
端到端实验每次约 300 条消息，约 20 条是工作请求；编码用假工具，每种方案跑 5 次。
结果 Super-agent 的 p50/p95 是 12.4/15.7 分钟。知乎
对照组更能说明问题：单 Session 在中性提示下，5 次运行一次都没调用 Subagent，p95 拖到 29.5 分钟。分工交给模型临场判断太不稳，放到系统层才稳。DeepSeek
取消订阅直通后，Router 决策次数增加约 30%，读缓存 token 从 2323 万涨到 3177 万，增幅约 37%。知乎
但这些数字测的是调度与协作，不是代码质量；样本只有 5 次，只能算方向性证据。
开源的落差
GitHub 上的 dsh-superagent-prototype 同日开源，MIT，我查时已过 3000 星。
但它不是文章那套完整系统的开源版。README 写得很直白：研究原型，不是正式产品。GitHub
它能做的是单仓库加飞书群的常驻助手：有人提需求就开工单，在自己的会话里做，回原对话交差。
仓库能对上 Router/Worker、订阅直通、两级过滤和「观察→自动」授权；对不上 Watchdog、投机执行、云端分离。
代码默认最多跑 3 个工单，接单默认 observe，只记录「本来会接」；watchdog 和 speculative 检索为 0。
所以它是能跑的切片，不是能直接上手的完整系统。
最值得抄的是治理，不是架构图
比起双层架构，三条治理约束更有普适价值。
第一，模型只做判断，权限由代码把关：模型说该接，没匹配到启用的规则，程序照样驳回。
第二，先记账后动手：默认观察档，把主动行为记成「本来会做什么」，攒一阵让人看，再决定放不放开。
第三，把少打扰当指标：只在需要决策或验收时说话。这三条比多开几个 Agent 更难抄。
还没解决的三件事
文章自己列了开放问题，最要命的是安全。
云端 Agent 接进个人设备后，提示词注入、凭据泄露、跨设备权限就不是理论问题。安全不解决，它只能在很小且可信的范围工作。DeepSeek
第二是成本：常驻监听和投机执行都在用算力换注意力，废片率高时账单很难看。
第三是长程记忆：跨月后，旧的正确决策可能变成今天的错误引导。Router 扩展、A2A 也仍待探索。
怎么评
对普通开发者，现在能用的只是 GitHub 仓库助手，别当通用 Super-agent；值得学的是「会话是实现细节」和「权限先于自主」。
对团队，值得小范围试点观察档：先攒审计记录，再放开自动接单。
对行业，信号意义大于产品意义：竞争正从模型能力转向 harness 和系统调度，但「自主」的边界仍是权限、安全与成本。
DeepSeek 把设计图摊开了，也把难题一起摊开了。方向值得跟，产品还早。
