Super-agent 不是项目开发的未来，但可能是生活助手的底座 DeepSeek 发了 Super-agent 的设计文章，我读完的第一感觉是：思路很漂亮，但产品定位有点卡在中间，或许并不是 Agent 的最佳形态。 1. 它在解决什么问题 DeepSeek 的出发点很清楚：现有主流 Agent 仍以单个 Session 为基本单位，用户并行推进多项工作时，需要手动切换并维护各个 Session 的上下文，而一个人通常只能同时跟进 3 到 5 个活跃 Session。模型越强，瓶颈越不在模型，而在人的注意力。 于是他们把会话管理从人手上挪到系统层：Router 是持续运行的全局协调节点，负责接收多平台消息、分派任务并维护跨任务上下文，Worker 拥有独立上下文，负责具体执行。再配上事件驱动、存算分离和 Watchdog，Agent 就成了常驻、并行、会主动找活的系统。 2. 一个容易被忽略的点：它并没有取消单 session Worker 本质上就是一个隔离的单 session。真正的长程任务丢进 Worker，稳定性和单开 session 没有区别。外层的 Router 不碰任务细节，只管"谁来干、结果回给谁"。 所以问题不是"长程任务该不该用 Super-agent"，而是"外面套的这层调度值不值"。这取决于事件密度。 3. 数据怎么说 DeepSeek 的实验里，对比对象是单 Session 加 Subagent：Super-agent 任务完成时间 p95 为 15.7 分钟，中性提示词下的单 Session 方案则达到 29.5 分钟。差距主要来自调度，五次实验中，模型一次都没有主动调用 Subagent，所有任务都被新消息不断打断。 代价也写得很坦白：由于要维护多个独立会话，缓存读取 Token 高于单 Session，取消事件直通机制后，总缓存读取量增幅约 37%。另外要注意，实验用的是合成消息和模拟耗时工具，没有评估真实编码质量。 这组数据恰好印证了我的判断：它的收益来自"几百条消息里夹着二十个真实请求"这种高并发事件流。如果你一个人专注啃一个项目，事件流稀疏，Router 就是纯开销，而且是 token 和延迟两头的开销。 4. 为什么我觉得现在不该一味做加法 现在很多 Agent 产品的困境不是能力不够，而是 harness 太重：层层路由、层层编排，每一层都在消耗算力和响应时间。需求来了就加一层，是惯性，不是设计。DeepSeek 团队自己也说，没有提出新理论，只是把任务调度、缓存管理、事件驱动、存算分离这些经典系统思想搬了过来。经典思想有效，前提是负载特征匹配。 所以项目开发场景下，我更倾向于：任务够长、够重，就老老实实开独立 session，需要并行就显式 spawn。用户心里清楚自己在做什么，不需要一个 Router 替他猜。 5. 它真正的生态位：随身助手 换个场景就完全不同了。想象一个手机上的助手：全天随手拿起来就用，一会儿订餐，一会儿查日程，一会儿帮你回消息，主题跳跃、频次极高。这时候手动管理多个会话才是真正的体验灾难，而任务之间差异又大，天然适合"一个入口、多个 Worker"的编排。 DeepSeek 自己举的个人助手例子也是这个方向：收到会议邀请后，AI 可以提前核对日程、搜集背景资料，并准备邮件回复草稿，等待用户确认。这和 Muse 这类 AI 助手的定位高度重合，而不是 Coding Agent 的主战场。 这个场景还有一个红利：Router 主要负责信息理解和任务分派，相对轻量的模型也可能胜任。常驻、高频的那一层用便宜又快的模型，这恰好是 DeepSeek 这类模型的强项。 6. Super-Agent 所直面的使用困境依然没有完全解决 个人助手版的 Super-agent 有几道坎，DeepSeek 自己也没绕过去： 长期记忆：任务积累到数周甚至数月后，如何准确恢复历史上下文仍是难题 安全与隐私：持续接收外部消息，意味着提示词注入、凭据泄露的风险面更大。放到生活场景里，涉及的是你的聊天、日程和账号 主动性的边界："主动"和"打扰"只隔一步。静默复现再择优提交的思路值得借鉴，没价值的尝试就悄悄丢掉，不要让用户为 AI 的试错买单 7. 我在做什么 我最近在做一个基于 DeepSeek 模型和 dsh 扩展的生活助手项目，目标就是锚定上面说的那个场景：单会话、多主题、高频次，打开就能用。项目相对完善后会开源。希望借助 DeepSeek 速度快、价格低的优势，给国内用户做出对标 Muse、甚至体验上超越它的东西。 如果你对生活助手有想要的功能，或者踩过哪些助手产品的坑，欢迎评论区分享讨论。