飞书任务桥 · IM 远程调度 AI 任务产品系统Vibe Coding

AI 智能体已经在承担资料整理、文档生成、代码排查、数据核对这类长任务，一次执行动辄十几分钟到半小时。但执行发生在桌面电脑上，由此带出一个很实际的落差：任务一旦开跑，人就只能守着，离开工位等于把任务停在那里。执行中如果需要用户做选择，没有人应答，任务原地等待，白白消耗时间；更要紧的是结果没有回传渠道，回到工位之前完全不知道跑成什么样。

已有的替代方案都不顺手。远程桌面和 VNC 能在手机上看到画面，但屏幕小、操作别扭，还要把桌面长期暴露在网络上，安全上不好交代；SSH 只适合命令行任务，非技术同事根本用不了。还有一类方案是直接用现成的云端机器人助手，但这类工具够不到本地文件、内网系统和专用软件，真正要干活的场景它接不住。对多数团队来说，真正的诉求不是远程控制整台电脑，而是三件事：随时派活、随时看结果、随时追问。

这个项目的思路是把企业 IM 变成控制面。手机飞书发一句话就能把任务派给桌面端智能体，每一轮结束自动把结果推成卡片回手机，在卡片里直接回复就能接着追问，遇到需要选择的地方把选项同步成按钮卡片，手机上点一下或者打一行字就能应答。任务始终跑在装好环境和授权的电脑上，IM 只负责指挥和回传。

典型用法是出差途中、会议间隙、通勤路上，以及在家里临时要一份数据。对中小企业尤其合适：不用搭 VPN、不用买远程桌面授权、不用额外装客户端，团队本来就在用 IM，接入成本几乎为零。任务不再因为人离开电脑而中断，响应时间从"回去再处理"压缩到几分钟。

功能围绕一条主线设计：手机上也能把一个完整任务从派发盯到收尾。

一、消息驱动任务。飞书私聊或群里发一条消息即触发桌面端执行，同一会话支持多回合连续对话，前后文自动衔接；任务按项目目录隔离，不同项目的会话互不串线，避免上下文串味。桥可以限定只接受指定目录下的任务，防止误触发。

二、完成自动汇报。每一轮任务结束自动生成摘要卡片推送到 IM，卡片里带项目名、会话标识和结果摘要，手机上一眼能看完结论，不用回电脑翻日志。推送只对白名单目录里的会话生效，其他会话不打扰。

三、卡片回复续聊。长按推送卡片选择回复，消息会被定位并注入到原来那场会话继续执行，上下文不断，而不是新开一场问答从头再讲一遍。消息与会话的映射保存四十八小时，期间随时可以接着聊。

四、提问同步镜像。桌面端执行中需要用户做选择时，同一个问题会镜像成带按钮的卡片发到手机，按钮点选或者自由输入都可以；手机和电脑两边谁先回答谁生效，另一端自动作废，不会出现两边都答、任务执行两次的情况。

五、可靠性与一致性。消息与会话的映射原子写入路由表，配合过期清理和一次性认领，同一条回复只生效一次，从机制上避免重复注入；桥作为单一实例运行在宿主进程内，避免双实例抢事件、互相覆盖会话存档；IM 侧自己产生的会话不触发推送，杜绝消息自激刷屏；进程被杀后重建映射不丢，不会把旧回复重新注入。

六、部署与运维。桥随宿主程序启动，路径、会话标识、超时时间全部写在配置文件里，改配置即改行为；推送、镜像、认领、拒绝各个决策点都打结构化日志，出问题按日志定位而不是靠猜。

技术栈是 TypeScript 与 Node.js，通过飞书开放平台的长连接接收事件、以卡片消息回传结果，凭证走应用鉴权换取访问令牌。

实现上在开源 IM 通道插件的基础上做深度二次开发，新增推送与提问镜像两个子系统，并接入插件生命周期：入站消息按类型分流并认领对应的待办会话，独立监听会话事件，进程卸载时关闭资源。架构分三层：接入层负责长连接、事件订阅去重、卡片回调与文件收发；路由层维护消息标识到会话标识的映射；会话层负责会话注入、轮末摘要推送和白名单过滤。

核心难点是状态一致性。早期版本出现过两个实例同时写同一份会话存档、导致整轮内容丢失的问题，解法是确立单一写者原则：桥只作为插件运行在宿主进程内，不启独立实例，因为双连接会抢长连接事件并互相覆盖存档。第二个难点是重复注入，方案是把映射原子写入路由表，先写临时文件再重命名，带四十八小时过期与一次性认领语义，认领即删除，旧回复不可能被用第二次。第三个是配置健壮性，配置里的 Windows 路径必须用单引号，双引号里的单个反斜杠会让宿主启动直接崩掉，而且错误只进渲染进程日志，排查花了不少时间，最后固化成书写规范并在启动期校验。第四个是可观测性，插件日志必须走宿主日志通道而不是标准错误，否则验真时看不到任何输出。

验收在真机上逐项通过：手机发消息能收到单条回复；桌面会话每轮结束手机能收到推送卡片；长按卡片回复能把消息注入原会话继续执行且认领生效；IM 侧会话不触发推送，自环排除成立。