标题：豆包手机第三方黑盒测试技术报告

【叠甲】

利益无关，纯个人技术兴趣驱动。本人不认识豆包的同学，本人也不做GUI-Agent（2025年了还在做Reasoning），唯一可能的粘连是用CK-Pro的Web Agent里面用了Playwright。

本文所有结论均基于对自有设备的 Black-box Stress Testing 与一部分Arxiv Paper的逻辑推演，不代表官方实际实现，所以里面可能有胡言乱语的幻觉，见谅。

【前言】

上手测了几天 Cases。一方面，看到了巨大的工程量，另一方面，社媒上出现了极多的安全争论，按下不表，我们是技术报告。

简单来说，这不仅仅是一个 App，字节是在 Android Framework 层做了一套 OS 级的影子系统。

下面开始碎碎念，主要观察如下：

1. 两套模式：System 1 (Intuition) vs. System 2 (Reasoning)

最有意思的设计是它把 Agent 拆成了两套 Stack：标准模式和 Pro 模式。这不仅仅是模型大小的区别，而是完全不同的两套 Pipeline。

【Testbed / 任务设定】

• 环境：系统相册 (Gallery App)。
• 物料：一张京东首页的全屏截图。
• 指令：“帮我点击搜索按钮”。

两个模式，Fast 和 Pro。

• Standard Mode (Fast)：走的是 Naive Simulation。
  • 观察：主要依赖浅层视觉（VLM），响应极快（体感 Latency < 500ms）。
  • 推测：走的Doubao-1.5-UI-TARS的（蒸馏）模型，prompt小，通过压低IO token获得更快效果。
  • 缺陷：在遇到“相册里的截图”这种 Visual Trap 时，会傻乎乎地去点击图片里的按钮。这是典型的 System 1 直觉反应（也可能是上下文没传当前系统状态等detail信息）。
• Pro Mode (Slow & Robust)：走的是 Deep Reasoning + Tool Use。
  • 现象：在同样的“截图陷阱”测试中，Pro 模式明显有一个 Pause & Think 的过程，然后拒绝点击并 Suggest 切换浏览器。
  • 推测：走的Doubao-1.5-UI-TARS路线，但是优化了很多，可能用的是thinking模式下的agent，亦或是做了更多post-train的升级版，框架上做了上下文工程，类似鹅的CK-Pro。
  • 推测：这说明其 Planner 介入了，且具备了 Self-Reflection 能力。而且只有在 Pro 模式下，才能观察到复杂的 Multi-hop Search 和 System API 的直接调用。

【备注：仍有可能被欺骗，可能并没有传入当前界面的xml，在此情景下仍可能是纯vision方案】

2. 感知层的混合路由 (Hybrid Perception Router)