lxy/DevFlow
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
66c6553cdff6b59c578b05003a79f6616b0fb05e
DevFlow/docs/02-架构设计/专项设计/devflow集成u-claw-可行性研究-2026-09-28.md
T
lxy 3861e13b32 文档: 决策单拍板留痕并落 DRY 走查报告 
D2 黑名单放行拍板补留痕,relay token 不引具体值
DRY 技术债 Top12 清单落专项设计,高风险名单一项本轮收口
2026-10-01 08:28:08 +08:00

6.9 KiB
Raw Blame History

devflow → u-relay → u-claw 集成可行性研究

2026-09-28 · 状态:可行性已定,待 devflow/u-claw 两侧细勘察补全 需求原话:「考虑 devflow -> u-relay -> u-claw, 让 devflow 集成 u-claw 能力」

一、定性结论

不是从零集成,是复用已生产验证的通路,唯一工作面在 devflow 侧接入。 u-claw 通用 WS 渠道已于 2026-08-29 随 u-ppt 试点上线(dev-ops 容器,心跳正常),u-relay 零改动,协议有现成 TS 参考实现。

二、知识脉络时间线(防断档,按此追溯)

时间 事件 留痕
2026-08-29 01:50 swarm 试点拍板:u-claw 加通用 WS 渠道 + u-ppt Agent 面板经 u-relay 中继,点对点配对不实现 G1 decisions.jsonl 2026-08-29 01:50
2026-08-29 02:25 u-claw b401480 push + 发版:WS 渠道随 start 部署,cfg.WS==nil 跳过零行为变化;dev-ops 容器 20260829-0206 心跳正常 decisions.jsonl 02:25
2026-08-29 02:47 Node 探针模拟 miniapp 身份 E2E:hello_ack→agent_request→progress→agent_result 全通,2s 双端互证 decisions.jsonl 02:47;u-relay scripts/e2e-miniapp.mjs
2026-08-29 起 u-claw WS 渠道持续演进:368beba 初版(device 身份+独立 ws 子命令)→490280e 热重建僵尸连接→08e3f02 空闲超时分级判死 u-claw git log
2026-09-28 并行会话完成 u-family×devflow 四仓组合分析,落 KMS(基线与本文档一致) E:/wk-lab/docs/kms/u-family-devflow-组合分析.md
2026-09-28 用户提出 devflow 接入同一链路;本次三仓勘察(u-relay/devflow 已完,u-claw 收尾中) 本文档

三、链路事实(勘察确认,非推断)

链路拓扑

devflow(WS客户端,Miniapp角色) ──wss──> u-relay(9180,零改动) <──出站WS── u-claw WS渠道(Device角色,已上线)
wss://u-relay.1216.top/ws/miniapp              device_id 配对                /ws/device

协议(三层,均有实现背书)

  • 传输层(relay):Hello{kind,device_id,token} 10s 握手超时 → hello_ack;帧=BroadcastMessage{device_id,kind,source,from,payload,ts};方向路由 Event→Miniapp / Command→Device;帧上限 1MiB;miniapp ping relay 本地回 pong
  • 业务层(u-claw↔客户端,relay 纯透传):agent_request{request_id,prompt} 上行 → agent_progress{request_id,text} / agent_result{request_id,text} 下行
  • 心跳:ping/pong 保活;u-claw 侧有空闲超时分级判死 + 热重建防僵尸连接

现成参考实现(最大捷径)

  • u-ppt src/core/relay.ts(223 行,TS):RelayClient 类,握手看门狗/hello_ack/progress|result 分发/agent_request 帧,devflow 前端同为 TS 可直接移植
  • u-relay scripts/e2e-miniapp.mjs:探针脚本,协议逐字段参考
  • u-claw 368beba 起的 WS 渠道源码

部署拓扑(KMS 服务索引)

  • u-relay:suke-dev systemd u-relay.service,9180,nginx wss 终止,musl 单二进制 ~3.6MB
  • u-claw:多实例容器化(5+ bot),dev-ops 容器已含 WS 渠道版本;u-switch 模型路由公网口 switch.1216.top(devflow 若只要模型调用可直连,不必经 u-claw)

四、风险与决策点

  1. 鉴权债:relay 全局共享 token(默认值硬编码 lib.rs:219,值不在此引用;per-device token 留 Phase3 未做),持 token 者可冒充任意 device_id。自用可接受;devflow 与 miniapp 共用 relay 时建议补
  2. 能力边界(勘察中):u-claw WS 渠道背后是完整 agent(会话/技能/意志卡)还是简化执行,决定「集成 u-claw 能力」含金量 —— 待 u-claw 侧勘察
  3. 流式粒度:progress/result 块级聚合非逐 token,aichat 首版按块级渲染
  4. 多轮上下文:request_id 单次请求语义,跨轮会话锚点在 u-claw 侧如何维持 —— 待勘察
  5. 离线即丢:relay 无离线缓存,devflow 需自行处理 u-claw 掉线(重试/超时)

五、devflow 侧接入方案(devflow 勘察已回,2026-09-28)

关键认知:角色方向

devflow 现有 df-tunnel 是 Device 角色(连 /ws/device,服务 miniapp 反控通路)。接 u-claw 须另开一条 Miniapp 角色连接(连 /ws/miniapp,仿 u-ppt relay.ts),用独立 device_id 与 u-claw 配对(先例:u-ppt-dev-01),与现有 miniapp 通路隔离,两路并存互不干扰(relay 同 device_id 支持多连接,但建议配对独立)。

接入形态三选(按成本升序,可组合)

  1. AI 工具形态(推荐首发):u-claw 包装为 aichat 工具——declare_tool! 注册 ask_uclaw(prompt),devflow 的 AI 对话中可直接委托 u-claw 处理(用它侧的 agent/技能/Claude Code),progress 流式回流工具卡片。改动面:src-tauri/src/commands/ai/tools/ 加一个 register 文件 + tool_registry.rs:508 挂载。零侵入 agentic loop。
  2. 消息渠道形态:出站仿 tunnel-subscriber 再订阅 ai_event_bus(event_bus.rs:138),入站仿 remote_bridge 写 payload 路由器(remote_bridge.rs:145 加 cmd 臂)。适合「aichat 会话直接由 u-claw 代言」,改动大于形态 1。
  3. 反向 MCP:devflow 已内嵌 MCP HTTP server(df-mcp,20 工具,src-tauri/src/mcp.rs:45),u-claw 可反向消费 devflow 能力——与形态 1/2 互补,不冲突。

传输层与配置

  • WS 客户端:Rust 层新写轻量 client(TunnelClient trait 可并存新实现,df-tunnel/src/tunnel.rs:61)或前端 TS 移植 relay.ts;推荐 Rust 层(与工具形态同侧)
  • 配置落位:地址/独立 device_id → app_settings KV(照抄 relay_url 模式,lib.rs:194-217);token → OS keyring(照抄 provider api_key 模式);默认关,对齐 u-claw cfg.WS==nil 零行为变化模式
  • 注意:现有 token 硬编码在 lib.rs:219(值不在此引用),本项实施时顺带配置化

六、待补槽位(勘察代理回报后增量更新)

  • devflow 侧 ✅ 2026-09-28 已填(第五节;另有:build_provider/AiToolRegistry/EventBus/SettingsRepo/keyring 扩展点清单已勘察,见会话或按第七节基线 grep 复核)
  • u-claw 能力边界 ✅ KMS 组合分析已明:u-claw = 常驻 claude -p(stream-json)的多渠道 Agent 网关,WS 是继邮件/飞书后第三渠道(wsch.go),每渠道一条 chain=一个常驻 claude 子进程(prompt cache 热)——即 WS 渠道背后是完整 Claude Code 能力(技能/工具全量),「集成 u-claw 能力」含金量高
  • u-claw 侧收尾(勘察代理进行中):WS 渠道的多轮会话锚定细节(request_id↔chain 映射、会话持久化边界)

关联阅读

  • E:/wk-lab/docs/kms/u-family-devflow-组合分析.md(四仓画像+快照基线,本文档上游)
  • ~/.claude/kms/服务索引-全机器.md(部署拓扑)
  • ~/.u-claw/willcard/decisions.jsonl(8-29 试点留痕)

七、增量基线(下次免重探索,只补漂移)

基线 HEAD(2026-09-28):
  devflow 4840f7e   u-relay 9a2d376   u-claw d8dc003   u-ppt 4e68773
漂移检查命令(各仓):
  git -C <repo> log --oneline <基线HEAD>..HEAD
关键漂移点:u-claw WS 渠道演进(ws 相关提交)、u-relay 角色鉴权(per-device token 是否落地)、devflow df-tunnel 变更
Reference in New Issue View Git Blame Copy Permalink