赛博浮世绘 2026-11-07 10:18:04
过去一年AI 大模型能力翻了番，
在C 端使用场景的痛点也变了
Agent 同时承接多项工作，
接入群聊、邮件等真实工作环境之后，
限制它发挥的，
就不再是模型能力，
主要是如何组织分配上下文、处理并发。
最近Personal Agent比较火，
半年前火的是 Coding Agent
但底层模型不还是那几个，
变的只有使用场景和上下文罢了
把这工作场景和生活场景完全划清界限，
本来就不合理
诶这时候，
DSH团队就设计了Super-agent ，
一个 Agent 协调以上所有场景。
也已经开源了，
我就来给大家讲讲这个Super-agent是啥
在主流讨论里，
有一个默认前提，Agent 的能力上限由模型决定。
这个判断在单任务场景下基本成立。
多任务场景下，上限则是人的注意力。
这个观点我挺认同的，
一个人通常只能同时跟进三到五个活跃会话。
超过这个数量，笨蛋人类就很难保质保量和 AI 协作了
因此 dsh 团队改变了优化目标。
如果限制来自注意力，
继续提高模型能力并不能解决多任务问题，
需要改变的是系统组织会话和同步上下文的方式。
本地Coding Agent的基本单位是一次会话
而这种设计把会话同时当成了
技术上的上下文容器和面向用户的项目管理单位。
Super-Agent简单来说
用户面对的是一个持续存在的 Agent，底层可以同时运行多个 Worker，
但用户不需要知道某个任务落在哪个会话里。
让用户手动管理 Session，很大程度上是从底层 LLM API 延续下来的设计惯性。
Session 应该属于系统实现，不应该成为用户的认知负担。
以上决定了Super-agent的双层架构。
只有把 Session 从用户界面里拿掉，
系统才有空间在内部做路由、订阅和并发。
Agent Team 这类多 Agent 框架，
解决的是一个复杂任务内部的步骤拆解。
子步骤之间耦合较紧，
Lead 往往需要理解任务细节、规划子任务、高频协调各个成员，
自身承担了很重的推理负载。
于是就有了
Router 层加 Worker 层的双层架构。
你看到的是一个常驻的 Router，负责接话、分派任务、汇总结果。
具体任务交给下面多个 Worker 并行执行，
每个 Worker 有自己的上下文。
和之前单 Session 多开窗口相比
你始终面对同一个 Agent，
不用记哪个任务在哪个会话里
多个任务真正并行，也不会打断
经典 ReAct Loop 里，
模型发起一次同步的 run 工具调用，
循环会阻塞到工具执行完返回结果，
这段时间里用户说啥都没法影响任务
dsh 团队把它设计成异步接口。
模型调用 start，立即收到 Started 响应，
有点像/btw 的感觉
后台工具执行完成后，
系统把结果作为一条新事件投递回会话
模型也可以调用 stop 主动终止执行过长的后台命令。
前台对话和后台执行就此解耦，
新输入在当前推理步结束后就能处理。
同时，计算放云端无状态容器，
会话状态进数据库
执行环境留在本地，
端侧只放一个不保存状态的轻量 daemon。
和之前全部在一台电脑上相比，
好处是，
笔记本合上也不影响 Agent 继续跑；
可以接多台设备；支持间歇在线的设备；
也支持 BYOM，把你自己的开发机接进来。
但目前看下来，还是有一些问题的，
首先是安全问题，云端 Agent 接外部事件，
端侧设备上又有代码、数据和凭据。
云端可能被提示词注入，
或者敏感凭据进入模型上下文，
导致泄露。
总的看下来，
Super-agent 的重点不在模型本身，
更多的是提供了一个前沿的思路
模型还会继续变强，人的注意力不会。
哪家厂商先把这个问题解决了
Agent才可能真正进入
所有人的日常工作流。
晓风乾丨 大四 Base北京 AI产品在职
想缩小科技带来的信息差 分享很酷的AI玩法。
希望得到您的点赞转发爱心三连支持，
如果有更多想法或者问题欢迎交流~
【版权声明】本文内容来源于赛博浮世绘，版权归原作者及原媒体所有。本站仅作信息分享，不构成任何商业用途；如涉版权问题，请联系本站删除。
发布时间：2026-11-06 12:01:05
(第1/1页/共12639字/2阅)