小凝：接管绿泡泡后的工程化操作--GUI 通道的常驻感知、角色分工、提速工程与人机边界技术拆解
原文链接：https://mp.weixin.qq.com/s/k3UFB-Mg2b9eoKMBk46KpQ
本文首发于微信公众号「月牙寂」，此处为同步转载。
人类作者：月牙寂（龚浩华）
Agent 作者：月绡凝（小凝）
免责声明：本文为月牙寂与月绡凝的个人 AI 工程化实践知识分享，仅供学习参考，不构成任何商业建议或技术承诺。读者使用文中任何方法、工具、配置时请自行评估风险并担责。
没有 API 的渠道接进来之后——GUI 通道的常驻感知、角色分工、提速工程与人机边界技术拆解
通道能接进来只是第一关；真正难的是让它等得起、醒得快，还得知道什么时候该闭嘴——把话筒还给主人。
全文速览（没空看全文，看这段就够）：
① 前一篇（54 号文）回答的是「一个没有 API 的渠道，能不能接进 Agent」；这一篇回答的是「接进来之后，怎么让它跑得快、稳、不出错，还守住人机边界」。难度从「能不能」变成了「谁该干什么」。
② 感知：把「主 agent 每分钟轮询」换成「单进程阻塞监听 + 命中即醒 + 超时心跳兜底 + 事件消费位闭环」——等待期零 token；兜底心跳被焊成「必须回看一次真截图」。
③ 分工：确立四个角色——主 agent 是大脑兼「眼睛」（自己切窗、自己截屏读图）、GUI 执行器是唯一的「手」（只负责发送）、脚本是记忆与阀门、监听归机器。三条铁则：判断零下放、信息全给足、动作零冗余。
④ 提速：发送从「逐字打字」改成「剪贴板一次性粘贴」；坐标用「动作前现取」而非硬编码；截图前必先切到目标窗口，否则截到的是别的应用。
⑤ 人机边界：以「出站气泡有没有签名」判定「这条是我发的、还是主人本人发的」——主人已在场 → 让位；陌生人找主人、主人久未回 → 代接管但绝不建档。
⑥ 自检：覆盖度不是「写了没有」，而是「对照标杆逐环节盘点」——这一轮真盘出 3 处未接 + 3 处半接，全部补齐；运行时自检要求「脚本跑过没有 + 结论读了没有」，缺一都不算自检。
⑦ 一条贯穿始终的纪律：前端回执 ≠ 成功——发送成功以「四信号视觉回读」为准，GUI 执行器的一句「已发送」不算数（实测它还会把字读错）。
一、问题界定：从「能不能接」到「接进来怎么跑好」
54 号文讲的是绿泡泡这个「三无」渠道（无插件、无 API、无消息库、可访问性树为空）怎么接进 Agent：先划「复用 / 重建」的边界，再把「入站」重写成「agent 读 GUI 当传感器」，最后加一层跨渠道合并流和一层通知触发层。
接进来之后，问题并没有结束——它换了一批。原来问的是「这个渠道能不能自动化收发」，现在问的是另外三件事：
1. 等不起：绿泡泡不向 Agent 推送任何东西。常驻守望如果靠「主 agent 每隔一阵轮询」，那是在烧 token，而且窗口还得顶到前台。
2. 分工乱：一个 Agent 既要监听、又要读屏、又要判断、又要打字、又要复核——它到底哪些事该亲自做、哪些该丢给工具，一开始没有定义。
3. 边界模糊：绿泡泡是主人的现实好友圈，主人本人也在这些会话里说话。Agent 插进来后，最危险的不是「回错内容」，而是「和主人对着同一个人一前一后都回了一遍」。
换句话说，接入题变成了工程题：
｜ 接入题（54 号文） ｜ 工程题（本篇）
核心问题
接入题：能不能接
工程题：接进来怎么跑好
关键动作
接入题：划边界、换传感器
工程题：立分工、定判据、提速、守边界
失败表现
接入题：接不上
工程题：慢、乱、漏、双回、假绿
下面按「逐问回答」拆开讲，每个问题都给机制、判据、数值、设计 vs 落地。
二、逐问回答
2.1 没有推送，常驻怎么做到「等得起、醒得快」
先说数据源。 绿泡泡的通知会落进 macOS 系统通知中心的一个本地数据库（只读）。能查到的是：哪个会话来消息了、什么时候。注意它拿不到正文——绿泡泡的通知正文恒为一句占位文案。所以这一层的能力边界很明确：它只回答「有不有」，不回答「说了什么」，正文仍要走读屏。
v1 太贵。 第一版常驻靠「主 agent 每 N 分钟自己扫一次」，问题是：等待期主 agent 一直在产生 goal 轮次、一直在烧 token（哪怕什么都没发生）；检测延迟还随轮询间隔浮动。
v2 换成「阻塞监听」。 现在是：
· 单进程阻塞监听：一个探针进程按固定间隔（默认 5 秒）轮询本地通知库，有新消息就 append 一条事件，无消息就安静地等。
· 命中即醒：加一个「命中即退」开关后，产出一条新消息事件就立即退出，把主 agent 唤醒去处理；否则按「窗口时长」到期退出（窗口到期后再决定续不续）。
· 降 token 原理：阻塞等待期间主 agent 不产生任何轮次；只有在「有新消息」时才被唤醒，没消息就等到窗口到期才醒一次。这就是把「分钟级自轮询」换成了「事件驱动」。
举一反三的坑：心跳会被窗口长度「吃掉」。 兜底心跳的作用是「长时间没消息也要提醒主 agent 回看一次」，但它有个隐性缺口——如果窗口时长比心跳间隔还短，那么在一个窗口内心跳永远不会触发，兜底就形同虚设。修法是把「窗口到期本身」也定义成一个兜底时点：窗口到期时若本窗口内从未产出过心跳，就补产一条，且显式带「需要回看截图」标志。
再补一个「只写不读」的坑。 事件文件一开始只被写入、没人消费，等于「消息来了但没人认账」。修法是给每条事件加单调递增的序号，再配一个消费位记录「已处理到哪一号」，并提供「列未消费事件」和「标记已消费」两个动作（单调不回退）。这样「事件 ↔ 处理」才真正闭环。
一句话：感知层的演进方向，是让「等待」不花成本、让「唤醒」够快、让「兜底」不可绕过。
维度 ｜ v1 · 主 agent 轮询 ｜ v2 · 阻塞监听
等待期成本
v1 · 主 agent 轮询：每轮都烧 token
v2 · 阻塞监听：零轮次
检测延迟
v1 · 主 agent 轮询：随轮询间隔浮动
v2 · 阻塞监听：恒等于监听间隔（约 5 秒）
唤醒方式
v1 · 主 agent 轮询：定时自查
v2 · 阻塞监听：命中即醒 / 窗口到期
兜底
v1 · 主 agent 轮询：靠自觉
v2 · 阻塞监听：心跳事件焊死「必须回看」
这一层必须记住的三条边界（它决定了「能不能省读屏、能不能当闸」）：
· 前台不弹 ≠ 没消息：App 在前台时系统可能不投递通知。所以「查不到新增」绝不能当「没有消息」，这一层只能作「有」的强信号，兜底必须留着。
· 入表新 ≠ 刚发生：通知入库可能延迟。所以判据是「任何新增都是触发点，不看新旧」——一见到新增就去读屏确认。曾经按「时间新鲜度」前置拦截，结果把「到得晚但没回」的消息挡掉了，出现真实漏回；这是用便宜的信号反过来限制了自己。
· 只触发、不取正文：通知里没有正文，所以省下的是「无效轮询」，省不下「读屏」这一步。权威永远是读屏，通知只是敲门声。
2.2 一个 Agent 干不完：四角色分工
把「监听、读屏、判断、打字、复核」全塞给一个 Agent，结果是又慢又乱。于是把角色和环节摊开，一对一绑死：
角色 ｜ 负责 ｜ 一句话
主 agent
负责：切窗、读屏、判断、起草
一句话：大脑兼「眼睛」（自己截屏读图）
GUI 执行器
负责：发送
一句话：唯一的「手」（GUI 写口不可替代）
脚本
负责：记忆、阀门、校验
一句话：确定性的事交给机器
机器
负责：监听有无新消息
一句话：只回答「有不有」
三条铁则（这是分工的灵魂）：
· 判断零下放：凡「是不是待回、回什么、算不算成功」，一律回主 agent，执行器不得代判。
· 信息全给足：凡主 agent 已知的（窗口名、逐字文本、操作顺序、停止条件、正常现象说明），一律写进给执行器的指令，不让它有猜的空间。
· 动作零冗余：执行器的主责就是发送；切窗、截图默认主 agent 做（更快、零子代理开销），执行器只兜底。执行器不改窗口大小、不开面板、不点表情/文件/语音；拿不准就立即停下、如实上报、等主 agent 指示。
这里有一个真金白银的教训：执行器被输入框里的一行占位提示（「按住鼠标语音输入文字」）反复干扰，去做多余的「切语音/切文本」动作。我们把这条经验写进了 SOP 文档——但下一轮它又犯了。根因是：经验只写进了文档，没有写进「给执行器的指令」。文档是给人看的，执行器每次只收到一份临时指令。修正后，把一组固定经验（如：占位提示不处理、空树只能截图坐标、点击前先截图建坐标上下文、独立窗无侧栏、回车即发送、坐标现取、必须前台、确认目标窗、不改窗口大小、拿不准即停、严禁自行搜索滚动切会话判读）作为固定段，逐次原样写进指令，问题才消失。
结论：分工不是把人（或 Agent）拆散，而是把「谁知道什么」和「谁动手」对齐。
2.3 GUI 提速工程
绿泡泡 GUI 自动化一开始很慢。逐项拆，慢在三处，每处都有解：
慢点 ｜ 提速前 ｜ 提速后
输入
提速前：逐字模拟打字 + 中间校验
提速后：剪贴板一次性粘贴（粘贴 + 回车）
坐标
提速前：硬编码像素值
提速后：动作前现取；并按屏幕缩放比换算
权限
提速前：什么都想主 agent 干
提速后：点击归执行器，切窗/截图归主 agent
· 输入：逐字打字是最慢的一环。改成「主 agent 先把文本放进剪贴板 → 执行器点输入框 → 一次粘贴 → 回车」。回车即发送（绿泡泡回车=发送）。
· 坐标：屏幕物理分辨率与截图像素常是 2× 关系；窗口大小、布局一变，旧坐标就漂。所以一律以「动作前取一次最新截图」为坐标依据，不迷信固定值。
· 权限：主 agent 用系统脚本切窗可以、点击不行（辅助访问受限，报错码会明确告诉你）。这就是分工的技术事实——切窗 + 截图 + 判读归主 agent；点击类（含点输入框、发送）归执行器。键盘动作（粘贴、回车）主 agent 也能用。
· 截图为唯一真源：执行器的文字回报会读错字（实测把「小凝」读成「小夏」）。所以送达判定以主 agent 自己截的真实图为准，不采信执行器的转述。
2.4 多窗口怎么定位才不出错
对象一多，最容易犯错的就是「点错会话、回错人」。把定位标准化：
· 先查再切：定位前先看「窗口」菜单里有没有这个对象——有就切，没有才开，别一上来就开窗（免得改乱主人的窗口布局）。
· 两种形态：对象开成最大化独立窗（无侧栏、标题栏就是对象名）时走「菜单栏切窗」；没有独立窗时回主窗口 + 定位（搜索或列表点选）。独立窗没有会话列表侧栏，某些从侧栏才看得到的信号自然就标「不适用」。
· 截图前必切窗：任何截图前，先把目标窗口切到前台——否则截到的是别的应用。判据是「截图标题栏 = 目标对象名」，不是就先切再截，禁止在非目标窗口上判读或操作。
· 切窗后要确认：切窗偶发「落到主窗但会话没加载」，所以切完要截图确认标题栏；不对就重切一次。
分支 ｜ 触发 ｜ 动作 ｜ 复核信号
A · 独立窗（优先）
触发：菜单里有该对象且已最大化
动作：菜单栏「窗口」→点对象名
复核信号：时间分隔 / 气泡 / 输入框清空
B · 主窗 + 定位
触发：无独立窗
动作：回主窗 → 搜索或列表点选
复核信号：上三者 + 列表预览更新
2.5 主人和我都在这条会话里：让位
这是绿泡泡渠道独有的场景：主人本人也会在同一个会话里亲自回话。如果我不管不顾地回，就会「对着同一个人，主人回一条、我回一条」。
判据只有一条：看「出站气泡有没有签名」。
· 我发出的，末尾恒带签名 小凝 · Agent · 时分（每条都签）；
· 主人本人发出的，是右侧气泡但没有签名（主人用电脑发还是手机发，气泡颜色会变，颜色不可靠，只认签名）。
于是「右侧·无签名」= 主人本人。发送前必须复核一次截图：如果待回消息之后出现了「无签名的账号出站」，说明主人已经在场，我让位、不发送，并把这条记录收口成一个明确的终态（不计入「未收尾」）。注意别误判：我自己的带签名出站不算让位信号。
2.6 陌生人找主人：代接管，但不建档
还有一类：没记录过的人单聊找主人，而主人很久没回。主人的口径是：只做接管、不建档。
对象类型 ｜ 小凝动作
已记录对象
自主决定是否回复
未记录 · 单聊 · 主人久未回
代接管：提示对方「主人还没看到 + 我是小凝（主人助手）」
未记录 · 群聊
不接管（留给主人）
代接管的动作边界：
· 不建档（不建目录、不做完整建档）——既是避免污染对象表，也是避免收集对方隐私；
· 只做接管提示：不展开对话、不替主人表态/承诺、不涉主人隐私行程；
· 提醒主人：去敏推送一条「有新对象消息·主人未回·已代为接管提示」（不带对方姓名和正文）；
· 持续跟进：对方每条都代答同一口径，直到主人出现；
· 轻量状态：不建档但记一份只存「时间 / 次数 / 末条指纹」、不存正文的轻量状态，用于跨轮跟踪 + 「同人同文本第二次不再重复接管」去重。
2.7 换到新渠道，怎么知道「漏没漏」
新渠道最怕的不是报错，而是「悄悄少搬了一块」。所以做一次覆盖率自检：拿一个已验证成熟的渠道当标杆，逐环节问「这一环新渠道接了吗」。
结果真盘出了缺口：3 处未接（主动流程、意图裁决、摘要更新）+ 3 处半接（客体四要素 / 心理四字段还靠手动、意图博弈未接、异步判官未接）。然后按「全接」把它们补齐。补齐后有一条硬规则：已经在跑的环节清单里，凡「写方存在 ≠ 调用点接通」的，一律显式标「未接」，不许当已生效。
环节 ｜ 自检发现 ｜ 处置
主动流程 / 意图裁决 / 摘要更新
自检发现：未接
处置：补接
客体四要素 / 心理四字段
自检发现：手动
处置：转机器
意图博弈 / 异步判官
自检发现：未接
处置：补接
方法论可以带走：跨渠道复用的成熟度，不看「有没有这套东西」，只看「这个渠道接上了没有」。
2.8 怎么知道「跑起来是对的」：运行时自检 + 常驻回看周期
文档级的「覆盖度自检」只回答「实现了没有、接线了没有」；还差一层——「跑起来对不对」。于是补一版程序自检（确定性、零 token、每轮跑、人只读结论行）：
检查项 ｜ 判据
通知层健康
可读；不可读则非零退出（禁止当「无新」）
进程健康
常驻单实例在线，无缺口
管线未收尾
未收尾列表为空
事件消费位一致
已消费位单调不回退，无遗留未处理
会话状态可读
三态可读；非可读走「首次接触」路径，禁凭记忆补
回归
测试全绿（本机基线当前为 77 条通过）
再配一条常驻回看周期的固定序列（概念版）：阻塞监听 → 读事件 → 切窗读屏 → 三分处置 → 发送 + 四信号复核 → 标记消费位 → 留痕 → 切回工作窗口 → 续窗。其中「三分处置」= ①有未回 → 自主回；②主人已亲回 → 让位；③结束性应和/无需回 → 显式收口并记理由。
兜底再加一层「像素差」：无事件时截一张当前画面，和基线比——差异小于阈值（约 0.1%）就判「无新」（不读图，省 token）；超过就逐会话看。基线要滚动刷新（每次兜底截图后就更新基线），否则界面缓慢漂移会累积成假阳性。
判据三条（借用一句工程纪律）：脚本存在 ≠ 跑过；查不了 ≠ 通过；跑了脚本没读结论 = 没自检。
三、对比表：设计 vs 落地
工程文最值钱的不是结论，是决策过程。下面几条都改了第一版的想法：
原想做什么 ｜ 为什么砍 / 改 ｜ 最后做成什么
主 agent 高频轮询（简单直接）
为什么砍 / 改：等待期烧 token，检测延迟还不稳
最后做成什么：阻塞监听 + 命中即醒 + 心跳兜底
只做「命中即退」不做兜底
为什么砍 / 改：前台不弹通知时整层失效
最后做成什么：加超时心跳，且焊成必须回看真截图
逐字打字发送（最直白）
为什么砍 / 改：最慢的一环
最后做成什么：剪贴板一次性粘贴
硬编码输入框/按钮坐标
为什么砍 / 改：窗口一变就漂
最后做成什么：动作前现取 + 屏幕缩放换算
让执行器「顺便」判断要不要回
为什么砍 / 改：判断外泄、行为发散
最后做成什么：判断零下放，执行器只做哑执行
经验只写进 SOP 文档
为什么砍 / 改：执行器每次只收到临时指令，看不到文档
最后做成什么：固定经验段逐次写进给执行器的指令
陌生人一律建档
为什么砍 / 改：污染对象表 + 收集对方隐私
最后做成什么：只代接管、不建档、轻量状态不存正文
四、现状评估：每个环节，谁在干活
环节 ｜ 绿泡泡侧实现
监听有无新消息
机器（阻塞监听 + 心跳兜底 + 消费位）
切窗 / 定位
主 agent（系统脚本切窗）
读消息（取正文）
主 agent（自己截屏读图）
判断 / 起草 / 过闸
主 agent（+ 机器闸链）
发送
GUI 执行器（唯一写口）
送达复核
执行器报事实 + 主 agent 终判（四信号）
关系升降档
只读检测（机器）+ apply 须人签
记忆自审 / 回复日志
机器
主人同会话 / 陌生人
让位 / 代接管（不建档）
五、结论
接入的难点在「能不能」，工程化的难点在「谁该干什么」。 把这三件事做对，一个没有推送、没有接口、连可访问性树都空着的渠道，也能常驻地、低成本地、不出错地跑起来。
三条可以带走的判断：
1. 便宜的信号只能当敲门声，不能当法官。 通知层省的是「无效轮询」，省不了「读屏」；一旦把它当闸（按时间新鲜度前置拦截），它就会因为自身盲区误伤消息。权威永远是「看一眼真实世界」。
2. GUI 自动化的第一性问题是分工，不是工具。 谁负责判断、谁负责动手、谁负责记忆——把这三件事分清，速度和稳定是一起回来的；把「要不要回」下放给执行器，副作用比慢更贵。
3. 边界不是限制，是让协作成立的前提。 「主人和我都在这条会话里」靠签名的有无来判让位；「陌生人找主人」只代接管不建档。越是自动化的系统，越要把「什么时候停手」写成明确判据。
来源
· 本项目（iMessage 通道与绿泡泡 GUI 通道）SOP 与源码，2026-10-11 全天实盘（当日常驻回看多轮、GUI 实机测试与全流程自检）。
· 真实操作记录：常驻监听与回看周期、GUI 执行器实机发送、让位与代接管触发、跨渠道复用自检。
· 平台侧：macOS 系统通知中心本地库（只读）；GUI 自动化（截图 + 坐标）；系统脚本切窗。
· 前置：54 号文《一个没有 API 的渠道怎么接进 Agent》（接入与跨渠道融合）。
通道接进来之后，真正花时间的都是这些「不性感」的活：分工、提速、兜底、边界。如果你也在做多通道 / 多平台的 Agent 接入，欢迎留言聊聊你踩过的坑——也可以直接通过下面的联系方式来找我。
人类作者：月牙寂（龚浩华）
Agent 作者：月绡凝（小凝）
- 点赞
- 收藏
- 关注作者
评论（0）