DeepSeek开源Super Agent：为何仍点不了你的APP？

DeepSeek开源了一套叫Super Agent（超级智能体）的新架构，思路很直接：既然一个人管不过来，那就给AI配一个团队。一个当调度员，负责判断该干什么；另外几个专门干活。这两个角色分别叫Router和Worker。

听起来是个好办法，但问题在于：调度员派出去的那些活，到底是什么活？

调度员的设计：为什么Router不能自己动手

Super Agent最值得琢磨的设计，是Router被刻意设计成不能自己干活。原因不复杂：如果调度员能上手，它就会忍不住自己干，一干，所有任务都得排队等它。

这个约束其实在解决多Agent系统里常见的「调度者瓶颈」——调度层一旦陷入具体执行，整个系统的并行能力就退化成单线程。DeepSeek^广告选择用架构限制来规避这个问题，思路是清晰的。

但架构层面的优雅，不能替代对任务类型的审视。接下来才是关键。

「调度者瓶颈」是多Agent系统中的一个典型反模式：当负责任务分发的节点同时也具备执行能力时，它会倾向于亲自处理部分任务，导致其他Worker闲置，系统整体退化为串行执行。在传统分布式系统中，类似的思路体现为「调度器与执行器分离」——例如Kubernetes的调度器只负责将Pod绑定到节点，而不参与容器实际运行。Super Agent通过架构约束剥夺Router的执行能力，本质上是用「能力隔离」换取「调度专注」，这与操作系统将中断处理与用户态任务分离的设计哲学一脉相承。

派出去的活：Router到底能调动什么

据B站UP主的拆解，Super Agent演示的例子集中在群聊、GitHub、邮件、CI这些场景。它们的共同点是：都是程序能直接调用的，发个请求，就有回应。

这条边界划得很清楚。有API的，AI叫得动；没API的，AI叫不动。而你一天真正要办的事——微信、银行、挂号——恰恰属于后者。它们不接程序请求，只提供一个给人看的界面。

所以Super Agent的能力半径，本质上取决于目标系统有没有开放接口。这不是模型能力的问题，是系统生态的问题。

这里的「API」泛指系统对外暴露的程序化调用接口，包括RESTful API、GraphQL、gRPC、命令行工具、SDK以及Webhook等。一个系统是否「叫得动」，取决于它是否提供机器可读的调用约定和结构化返回。手机APP通常只提供面向人类视觉的GUI，其界面元素没有语义化的程序接口，因此Agent无法通过请求-响应模式操作。这正是「有API」与「没API」的分水岭：前者是系统生态问题，后者需要屏幕理解与模拟交互技术来弥补。

Worker的三类形态，以及被忽略的那一类

按照上述分析，Worker其实可以分为三类：

• 第一类：另一个程序。 靠命令行和接口干活，这是目前绝大多数Agent项目在做的事，生态也最热闹。
• 第二类：一个手机APP。 只有界面、没有接口，几乎没人碰。
• 第三类：另一台设备。 通过设备间协作完成任务。

第一类和第三类都有成熟路径，唯独第二类——也就是绝大多数普通人手机里的APP——是被跳过的。而这恰恰是用户感知最强的场景。

Andy的解法：把界面读成清单，而不是算坐标

UP主提到的Andy，做的就是第二类Worker。它的思路是：不依赖接口，直接看屏幕。

具体做法是：把屏幕读成一份清单，每个能点的元素编个号；不算坐标，而是在截图上叠一层网格，报第几格。这跟传统的坐标点击有本质区别——坐标点击依赖精确的像素定位，界面一变就容易失效；网格加编号的方式，容错性更高，也更接近人类「看到按钮就点」的行为逻辑。

还有一条安全规矩：同一个地方戳到第三次，就停下来。因为反复戳同一个位置，说明它其实是在猜。与其乱点一气，不如先问用户一句。这个「三次即停」的机制，是对自动化系统常见的「盲目重试」问题的一个务实回应。

传统坐标点击依赖屏幕分辨率、窗口位置和像素级定位，一旦界面布局变化、弹窗出现或设备分辨率不同，坐标就会失效。网格加编号的方式将屏幕划分为规则单元，每个可点击元素映射到单元编号，模型只需输出编号而非精确坐标，从而降低了对像素级精度的依赖，提升了跨设备、跨分辨率的鲁棒性。这种思路接近于「空间离散化」——用有限的格子代替连续的坐标空间，使决策空间从无限像素缩小为有限编号，既降低了模型输出难度，也提高了容错性。

密码处理：模型永远拿不到的字段

另一个值得说的设计是密码。模型永远拿不到密码，只能请求设备去输入。模型只知道填了12个字符，但不知道那12个字符是什么。

这个设计把敏感信息的处理从模型层剥离到了设备层，从架构上切断了模型接触明文凭证的可能。对于要让AI操作真实账户的场景来说，这是必要的隔离。

「模型永远拿不到密码」的设计遵循了最小权限原则（Principle of Least Privilege）：模型只被授予完成任务所必需的信息，而非全部信息。具体实现上，密码输入由设备侧的受控组件完成，模型只能发起「请求输入」的动作并获知输入长度等元信息，无法读取明文内容。这种隔离将敏感凭证的处理限制在可信执行环境内，即使模型被提示注入攻击或出现幻觉，也无法泄露密码。这与支付系统中「令牌化」（tokenization）的思路类似——用代理凭证替代真实凭证，从架构上切断敏感数据的暴露路径。

叫得动与叫不动：Agent能力的真实边界

回到标题的问题。DeepSeek的Super Agent架构解决的是「怎么组织多个Agent协作」，但没解决「目标系统愿不愿意被调用」。

有的东西叫得动——有API、有命令行、有开放协议的系统。有的东西叫不动——你手机里那些只有界面的APP，基本都属于这一类。AI想替你办事，就得学会自己去看、自己去点。这就是Andy这类方案要解决的问题。

多Agent协作的架构设计，和真实世界界面的操作能力，是两条独立的战线。前者已经有相对成熟的范式，后者还处在早期探索阶段。Super Agent的Router/Worker分工给出了一个可扩展的骨架，但骨架之下，第二类Worker的缺失意味着它对普通用户的日常工作，目前仍然够不着。

真正的门槛不在调度逻辑，而在那些不接请求的界面。