架构

[!TIP] 受众：对自托管工具感兴趣、经常与各种“限制”博弈的开发者。 核心目标：构建一个完全受控的 YouTube 媒体采集系统，解决 n challenge 签名挑战。 问题-方案映射： 登录墙/Cookie $\rightarrow$ Manifest v3 浏览器插件同步 动态签名 (n-sig) $\rightarrow$ Docker 内置 External JS Solver (node) 实时观测 $\rightarrow$ Socket.io 流式转发 stdout 最近在折腾自己的“数字主权”基础设施，其中一个刚需就是 YouTube 下载。市面上的工具很多，但随着 YouTube 对 n-sig（一种通过混淆 JS 动态生成的签名）的限制加码，很多开源项目开始在大音轨下载上“翻车”。 作为一个写了 20 年代码的老兵，我最受不了的就是“工具不可控”。于是，我把这套老伙计重新打磨了一下，做了一个“主权级”的架构。 1. 架构：为什么非要搞这么复杂？ 很多人觉得 yt-dlp 一行命令能解决的事，为什么要搞插件、Docker 和后端？ 答案是：骨感现实。 Cookie 维护：手动导 cookies.txt 太脏。我写了一个 Manifest v3 插件，点一下直接同步到云端。 环境隔离：我的开发机是 Windows，但下载器必须部署在 Linux Docker 里，且需要精准控制 ffmpeg 和 yt-dlp 的版本。 这就是我们的“三足鼎立”： 插件 (Bridge)：负责打通浏览器会话。 后端 (Engine)：Node.js + Socket.io，负责进程管理和实时日志。 容器 (Infra)：解决一切环境依赖。 2. 泥地打滚：解决 n-sig 的深层逻辑 前阵子，我的下载器突然报错：n challenge solving failed。这是 YouTube 升级了混淆逻辑，yt-dlp 默认的 Python 模拟器解不动了。 ...

继我们之前讨论过的 RoleEngine 核心 之后，是时候填补原生 CLI “大脑”与现实世界通信平台——微信之间的鸿沟了。 在 VisAgent 中，我们不迷信臃肿的重量级框架。相反，我们采用 CLI 原生桥接 (CLI-Native Bridge) 模式。本文将探讨我们如何将 “Clawbot”（我们的微信接口）连接到手搓的 Gemini CLI 内核。 请求流：从聊天到 CLI 该架构是一系列专用工具组成的链条，每个工具只做一件事并做到极致。以下是消息如何从手机传递到 AI 的过程： sequenceDiagram participant User as 📱 微信用户 participant Daemon as ⚙️ WeClaw (Go) participant Bridge as 🌉 visagent_invoke.py participant Engine as 🧠 RoleEngine (Python) participant CLI as 🐚 Gemini CLI (Binary) User->>Daemon: 发送消息 Daemon->>Bridge: 生成进程 (JSON) Bridge->>Engine: 初始化角色 Engine->>CLI: subprocess.run(stdin=prompt) CLI-->>Engine: 原始 AI 输出 Engine->>Engine: 过滤 Agent 噪音 Engine-->>Bridge: OK + 清净输出 Bridge-->>Daemon: JSON 事件 Daemon-->>User: 回复微信 1. 桥梁：visagent_invoke.py 由于我们的微信守护进程 (WeClaw) 是用 Go 编写的，而我们的 Agent 逻辑是用 Python 编写的，我们需要一个轻量化、高性能的桥梁。我们没有采用复杂的 RPC 系统，而是使用了 CLI 桥接。 ...