周六北京场欢迎找我玩🤓👆
Deepseek 的 Super-Agent 架构中的 router 层或许可以采用快速判断模型（如 Jev）配合强逻辑判断模型（如 GPT）的形式来组合。
router 层要负责判断任务并路由给正确的 worker，如果router 模型能力较弱，则可能会导致判断出错从而影响整体工作效果；如果 router 采用能力较强的模型，在很多时候会出现模型能力和请求时间的浪费，增加整体流程的负担。
所以可以尝试用模型组的形式来优化一下架构，快速判断模型进行初判，这样在一些继续之前的工作的情景或者偶发简单任务的情景下，可以快速完成判断并继续路由到相应 worker 完成任务需求。当出现新的复杂场景下需求的时候，强逻辑大模型会具体分析需求重新分配任务。
当然这样的架构依然存在很多问题，比如 Jev 判断的结果真的可信吗，如果初次判断就出错了怎么办？所以很可能在完成快速初次判断 worker 执行任务的同时，还需要用能力更强的 router 模型并行进行一次分析，如果这时候检测到判断出了问题，则需要叫停重新规划。
所以这样的架构组合的作用可能就是节约了一些任务情景的启动速度，让日常小任务处理的更快，但是对于节省 token 没什么效果。
所以对于 Deepseek 的这套 Super-Agent 架构，我还是觉得并不是一个好的架构，这套系统笨重且并不能提高真实场景的任务完成效果，即便是想办法优化，也不过是给外面套上越来越多的 harness 层，越来越笨重。
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、甚至体验上超越它的东西。
如果你对生活助手有想要的功能，或者踩过哪些助手产品的坑，欢迎评论区分享讨论。
Deepseek 的Super-Agent 的这种产品形态我觉得还是有点卡在中间，一方面处理日常任务无需太重的 harness 设计，另一方面如果进行更大规模的长程任务开发，单开 session 显然更稳定可靠，外层的 router 等设计反而会增加算力负担和时间开销。
现阶段我认为并不是一个发现需求就应该做加法的时候，很多产品当前的困境就是harness 太重反而影响性能和使用体验，Super-Agent 更是有些过于理想化而会影响开发效果，并不是一个适用于项目开发的形态。
Super-Agent 的工作流设计很适合日常助手的定位，我觉得核心使用场景就是单会话、多主题、高频次访问，也就是把 Agent 当做手机上的助手，全天的任何时候随手拿起来就立即使用。这种情况下如果反复管理多个不同的对话，使用频率高了就会导致使用体验不佳，但是每次使用时的任务之间差距又很大，天然适合 Super-Agent 的多任务编排。这个生态位就很适合 Muse 这类的 AI 助手，而不是应用与开发。
我近期也在进行一个基于 deepseek 模型以及 dsh 扩展的生活助手项目开发，希望能锚定一个更贴近生活的，更易于使用的场景。项目相对完善之后我会进行开源，在 deepseek 这样速度快价格低的模型加持下，希望能给国内用户带来对标 muse 甚至超越的使用体验。如果大家对于一些功能和体验有什么好的想法也欢迎一起探讨！
我一直觉得 AI Native 是个 useless 的词汇，一个真正优秀的项目只需展示自己的成果，而无需一直标榜自己是所谓的 AI Native。刻意强调项目的 AI Native 只会让我觉得这个项目没有其他出彩之处，且代码架构可能也未经开发者更好的设计与优化。
已完全急哭，gpt 的防御性编程和非人语言系统让我开发的脑袋疼，现在模型能力和性价比都比不过 claude，如果不是 a/封号早就抛弃哈希仙人去隔壁享受似人 opus 了
接近技术应用的人，听一些远离技术的高管发言是一件痛苦的事情。他们有更好的信息源，视野更开阔更全面，这可能让他们在某些产业链或宏观方向上发表一些观点和分析。但是长久离开技术一线的，或者本身就不是做技术的人，他们对于 AI 的理解与真实应用效果的感受，远没有技术一线的人敏锐。听到这些长篇的无效发言漏洞百出，一想到在 AI 时代有话语权的这群人往往在传播的都是一些理解错位的信息，我还是觉得有些无奈。
现在绝大多数人和绝大多数场景，对于 AI 的使用是非常短视的，很多时候这也没什么，因为通常我们只要用 SOTA 模型的强大能力去降维打击一个小问题，做出来的东西只需要在当下解决问题而没有长期维护的需求。但是 AI 速成的惯性思维，让许多人在处理一个长期规划的时候，仍然采用这种短视的许愿式的方式构建项目。比较经典的就是很多人在网上说，自己用 AI构建了自己的知识库，将自己的资料都汇聚起来，形成知识复利。但是这些人大多只是一时兴起，做出来的所谓“知识库”究竟给他们带来什么收益了吗，恐怕没有。这正是因为他们用这种短视的速成的方式去构造了一个项目，而这个项目可维护性很差，且最终达成的效果也不理想。AI 本质是 garbage in, garbage out 的，大多数人根本没有什么真正有价值的自己的一些资料，一味的把自己的大量低质量冗余的电子资料做成数据库，只会导致垃圾知识污染 Agent 能力，大量的无用资料占据上下文只好一遍一遍压缩，真正有用处的部分反而呗遗忘的越来越少。AI 的压缩和上下文限制决定了它能记住的内容有限，不断压缩只会导致知识的价值也在不断损失，想要真正实现一个有价值的个人知识库，相当把大量的精力投入到数据库的架构设计 AI 对内容的学习和索引设计，以及高质量资料筛选中。总更好的数据库设计，更优化的 Agent 知识库索引交互，以及更高质量的数据，才能让这个个人知识库发挥出自己的作用。
为了让 AI 更可靠，我做了个给 Agent 用的网站
你的 AI Agent 配环境时，从哪里下载软件？
现实是：它要么相信搜索引擎的前排——而前排很可能是 SEO 优化过的钓鱼仿冒站；要么凭"记忆"编一个看似合理的域名——大模型编起官网来毫无心理负担。人类也一样，搜"XX 官网"，前排全是广告和李鬼。
于是我做了 Reliable Resources for Agent，一个开源的可信互联网资源库。
让 AI 可靠，让信息安全。
这里的所有资源全部为人工审核收录，但是资源是给 Agent 看的，让 Agent 可以避开钓鱼链接，直接找到官方页面，让 Agent 可以直接查到最新版的更新改动，配环境的时候更安全可靠。
它解决什么问题：
🔍 找官网不再碰运气：42 条收录，每条都经过人工审核，验证证据可查，拒绝"我编一个"
🛡️ 下载不再怕钓鱼：Go、npm、Docker、VS Code、GitHub 这些高仿冒风险产品单独做防伪收录
🧰 配环境更顺利：Agent 从库里拿官方地址，用版本管理器（pyenv / nvm / conda-forge）装对的版本，兼容性问题和版本错误更少
产品特点：
✅ 人工审核 + 官方渠道交叉验证 + CI 持续探活，每条收录证据可追溯
🤖 双受众：人类可浏览，Agent 通过 skill 直接调用
🔄 skill 每次使用自动拉取最新数据，无需重装；数据契约向后兼容
🌐 中英双语，开源免费（MIT）
安装 skills（一行命令，复制粘贴就行）：
npx skills add https://github.com/Fangwenky/reliable-resources-for-agent -g
装完重启 Agent，试一句："我想下载的那个工具，官网是哪个？"
🌐 在线浏览：https://fangwenky.github.io/reliable-resources-for-agent/
⭐ GitHub 求 star：https://github.com/Fangwenky/reliable-resources-for-agent
