CodeXLoop · 架构专题 Connector / Runtime / Daemon

Connector / Runtime / Daemon
把扫码、接线、执行三层拆开看

当我们说 “CodeXLoop 最终也要做到扫码绑定微信”，真正要补的不是一个按钮，而是三层协作： Connector 负责平台协议和扫码登录， Runtime 负责对外 API 与状态调度， Daemon 负责长期循环与核心任务推进。

为什么要把这三层单独讲清楚

因为很多系统在做 “聊天平台接入” 时，最容易混淆的一件事就是：

扫码登录

这只是 connector 的认证动作，不等于 loop 已经会处理消息。

API 服务

Runtime 负责接收 webhook、暴露状态、转发工单，但不应该吞掉核心业务逻辑。

后台循环

Daemon 负责长期推进 plan / evolution / task，不应该直接变成所有平台协议的堆放层。

所以这页的目标很简单：把“扫码”“接线”“执行”拆成三层，避免以后把 thread、connector、daemon 混成一个大黑箱。

三层角色：谁负责什么

层 更像什么 职责 不该承担什么
Connector 电话线路 / 渠道网关 扫码登录、平台协议适配、收发消息、会话身份管理 不应该直接推进长期任务或自己维护完整 loop
Runtime 前台 / API 调度台 对外提供 API、接 webhook、做状态查询、路由到 thread / task / workspace 不应该承载所有平台协议细节，也不应该自己变成循环引擎
Daemon 后台执行引擎 定时唤醒、读 plan、推任务、写 evolution、维持 loop 节奏 不应该直接承担扫码认证交互，也不应该直接等同于 connector runtime

从消息进来到任务推进，中间到底经过了什么

1. Connector 收到外部事件

例如微信、飞书、Telegram 的入站消息，或者扫码确认后的登录状态变更。

2. Runtime 接住并归一化

把平台侧会话转成内部会话身份，再决定是查状态、投递工单，还是绑定到某个 thread / workspace。

3. Daemon 继续长期任务

真正的计划推进、任务续跑、演化记录、GitHub / Pages / 发布闭环仍由 daemon 驱动。

[插图提示词]

用途：画 CodeXLoop 的 Connector / Runtime / Daemon 三层协作图。

形式：三层消息流图；Mermaid 很合适。

提示词：左侧放外部平台（WeChat, Feishu, Telegram），第一层是 Connector（QR auth, session identity, inbound/outbound adapter），第二层是 Runtime（API router, webhook intake, task/thread/workspace router），第三层是 Daemon（loop scheduler, plan reader, evolution writer, publish actions），箭头从左到右贯穿，并在底部补一条 workspace shell UI 控制面。

Mermaid 更适合：是。

微信扫码接入到底属于哪一层

微信扫码绑定不是 daemon 在“直接接微信”，而是 connector 在完成一个认证与会话建立流程。

Connector 侧

负责 start qr、wait qr、persist token/account id、长轮询更新。

Runtime 侧

负责暴露二维码登录 API、把登录结果写入本地状态，并让 UI 能展示绑定状态。

Daemon 侧

仍然专注在长期任务推进；它最多消费“这个 connector 现在绑定到了哪个 thread / task”。

所以对 CodeXLoop 来说，真正要做的不是“把微信绑到 daemon”，而是：先建 connector shell，再做 QR auth contract，再定义会话与 thread 的桥接关系。

对 CodeXLoop 的直接要求

第一步：先把 connector shell 做稳

Workspace 里先有状态、绑定、目标会话和 mock QR contract，再谈真实微信 runtime。

第二步：再做 QR auth flow

把 start qr / wait qr 收成 relay API，而不是直接在前端里写死一条微信逻辑。

第三步：最后才做 conversation bridge

真正决定一条微信会话如何映射到 thread / task / workspace，并处理和 daemon 的互斥。