DeepSeek 的 Worker 调得动 GitHub，调不动微信：三类 Worker 的实现差别

先说结论，后面全是证据。

DeepSeek Harness 团队 10 月 31 日发了《Super-agent 设计探索》，Router 常驻协调、多个 Worker 并行，核心判断是一句话：单任务的上限取决于模型能力，多任务的上限取决于人的注意力（一个人同时只能跟进 3--5 个活跃会话）。

那篇讲的是怎么调度 。这篇想讲调度什么------因为它派出去的那些活，和一个人一天真正要干的活，可能不是同一批。

Andee 也是个 Router，位置一样（开源原型的 Router 和 Worker 都在本机跑，状态在本地 SQLite，面板开在 127.0.0.1）。差别在它够得着什么。这个差别决定了三类 Worker 里哪一类最难做。

一、能被程序调用的，只是 Worker 的一部分

DS 举的例子：群聊、GitHub、邮件、CI 结果。共同点是都能被程序直接访问------群聊有 API，GitHub 有 API，邮件有协议，代码仓库本身就是文件系统。

所以那套架构里，「派活给 Worker」约等于「发一个 HTTP 请求」。调度层判断派给谁、什么时候派、上下文怎么传。

但一个人一天要办的事，绝大多数没有 API：微信没有「帮我回消息」的接口，外卖 App 没有「查这个月花了多少」的接口，银行 App 没有「看看有没有重复扣费」的接口。挂号、政务、抢票都没有。

它们只有一个给人看的界面。

先说清楚：这不是说 DS 只支持一类。 它的框架对 Worker 是什么并不设限。但看它举的例子和开源原型------Worker 接的是 GitHub 仓库，跑的是 git 和 gh------它默认的那类 Worker 是另一个能被程序调用的东西。

Worker 是什么	怎么接触	现状
另一个 Agent / 命令行工具	协议、命令行	DS 的主场，很多人在做
一个 App（微信、银行、政务、挂号）	只有界面，没有接口	少
另一台设备（手机 ↔ Mac）	加密点对点通道	少

第二类最难，也最值钱------一个人真正高频、繁琐、想外包的事，几乎全在第二类里。

下面三节，就是这三类各自怎么实现。代码都在 kuafuai/andee，可以逐个核。

二、Worker 是一个只有界面的 App：怎么让它会点屏幕

它不要求 App 提供任何东西。屏幕被读成一份精简的元素提纲：每个元素一行、按层级缩进、带一个能直接点的编号。碰到 App 自己画像素的地方（小程序、WebView、游戏），退回看截图。

这里有个判断值得单拎出来：

通用大模型算坐标很差，读坐标很好。

所以它从不算坐标。每张截图上叠一层淡淡的 8×12 网格（GRID_COLS = 8、GRID_ROWS = 12；Android 在 ScreenController.kt:3643，Mac 在 MacScreen.kt:696），点按时报「第几格 + 格子里的哪一份」。目标太小时先放大，看到红色十字标出「会点在这儿」，确认了再动手。同一位置点到第四次会被拦下。

代价也在这里：慢，而且依赖那台设备醒着。

三、Worker 是已经装在机器上的 Agent：怎么知道有它、它能干什么

Mac 端有个 Gear 系统，回答的就是「这台机器上是不是已经有东西能干这个」。

用 mdls 一次扫描全部已安装 App，275 个大约 0.1 秒，拿到 id、名称、版本、上次使用时间、使用次数。这些是设备事实，模型不能猜也不能改。

然后分两层，故意隔开：

层	内容	谁能写
Facts	装了什么、版本、上次用、用了几次	设备读，模型不能改
Meaning	它干什么、能替我做什么、登没登录、有何限制	模型写，且只写一次

Meaning 那层是模型查不到的东西。装了 WorkBuddy 不等于知道它能做深度调研，装了 Claude Code 不等于知道它能改代码跑测试------这些要等第一次真正用它的时候记下来。

所以动手之前它会先问：这台机器上是不是已经有东西能干了？而不是上来就一个像素一个像素自己点。

四、Worker 是另一台设备：怎么派活过去

这一层 Mac 和 Android 跑同一份代码（派活逻辑是同一个类，不是各写一遍），两个身体之间是一条加密通道。

配对只做一次，且必须人参与：一台显示 6 位码，另一台输入；双方各出一个临时密钥、各算一遍 HMAC，码和它派生的东西都不上线。6 位数是一百万种可能，真正保安全的不是位数，是尝试次数上限------试错到次数就作废。之后每次连接不用人，双方用配对公钥互验，会话密钥来自临时 ECDH，设备被偷了也解不开之前录下的流量。

两端各自声明自己能干什么（PeerTasks.canFor）：

kotlin 复制代码

"mac"   -> "a Mac: browser, files, coding agents and a terminal, a big screen"
"phone" -> "an Android phone: its apps --- chat, shopping, food delivery, maps, ride-hailing"

派活接口叫 ask_friend，不等结果就返回。一个任务可能跑二十分钟，工具调用如果阻塞在那儿，会把发起方的对话当人质。所以一问完就回来，结果晚一点作为独立的一轮自己到达；链接断了就从发件箱重试。

五、有一个问题 DS 列进了待办，这边已经跑着

DS 文章第 8.4 节写得很直白：云端 Agent Loop 一旦被提示词注入攻破，连接的全部端侧设备都有风险；就算云端没破，只要凭据进了上下文，正常执行中也会泄露。所以「让 Agent 完全不接触凭据本身也能使用凭据」被列进了待办。

Andee 这边不是待办------它默认没有云端 loop，凭据也就没地方可泄露。

保险箱里一条账号记录分两半：能读的和只能用的。

能读：手机号、邮箱、用户名、持卡人，全是掩码（138****1111，够确认是这个账号，不够拿去输入）。卡号后四位是唯一不掩码的，理由很具体：两张卡长得一样时，模型必须能说出「我要用尾号 3702 那张」，而不是含糊地说「你的卡」。
只能用：模型永远拿不到。它只能请求设备去输入。

a secret never crosses the WebSocket. The brain asks the device to type it and gets back a length, not a value.

它知道「填进去了 12 个字符」，不知道那 12 个字符是什么。信用卡三个字段同理。

另外，五个私人笔记本工具（记什么、答应过什么）标了 localOnly，在 ToolSchemas.forHub() 里就被过滤掉------根本不上路，连发都不发出去。

六、老实对一下账

先说一个容易被忽略的事实：存算分离在开源原型里没有实现。

README 写得很直白：文章里讨论的部分设计属于「未来的方向」。装到机器上的那个 dsh-superagent，状态就是一个本地 SQLite 文件，面板开在 127.0.0.1，Worker 以你的系统用户身份跑命令。所以两边其实对称------我们那个 hub 后端也只到骨架。

项	DeepSeek	Andee
投机执行	有。内部在跑「静默复现并修复」	没做。动手前会问，不偷偷做
存算分离	文章写了方向，开源原型未实现	骨架在，未开放：hub 后端 + `BodyWsServer`/`BodyWsClient` 都写了，但链路无鉴权、明文 `ws://`
独立 Watchdog	有，独立 Session 定时巡检	无独立进程。只有调度器内部护栏：同位置第四次拦下、连续三次相同调用即停
多 Worker 并行	有，各自一个 Session 一个目录	弱。更接近「一次派一个」，不是调度队列
实验数据	有 P50/P95。官方自己注明是合成负载、编码用「只耗时的工具」模拟，测的是调度不是执行	没有。不编这种数
Worker 够得着什么	GitHub 仓库，可选接飞书	任意 App、任意设备

强项和短板是同一件事来的。 因为要动手点真实界面、因为 Worker 就在手边，它碰到的世界大一圈；也因为如此，它慢、它依赖设备醒着、云端那半还没敢开。

七、结构决定它能派给谁

DS 的实验数据里有一条值得看：中性提示下，单会话那组跑了五次，模型一次都没派活，全自己干了。换成「优先委派」的提示词，五次里四次派了活；剩下那一次判断「活太小」，又自己干了。

同一个模型、同一个场景，换个提示词行为就变了，组内还不稳。所以他们的结论是：靠提示词让模型学会分工不稳，得靠结构------Router 不准亲自干活，甚至不给它配 Bash。

这个判断是对的。我想接的是下一句：

结构决定它能派给谁。 DS 那套结构里 Worker 接的是 GitHub、是飞书，能覆盖的自主范围就是能被程序调用的那些东西。而一个人真实的、繁琐的、想外包出去的生活，大部分不在那里------在只给人眼看的界面上，在只装在手机里的 App 里。

所以我们要做的不是让 AI 调度 AI，是让 Router 长出手，去够那些永远不会为它开放接口的东西。

代码在 github.com/kuafuai/and...。文中每个机制、每条护栏、每处没修好的地方，都能在仓库里核对。