主权级下载器：在 YouTube 的 n-sig 迷雾中开工

Thu, 02 Apr 2026 21:15:00 +0800

[!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 模拟器解不动了。

手搓龙虾 (3): 将微信连接到 CLI 原生内核

Tue, 24 Mar 2026 12:45:00 +0800

继我们之前讨论过的 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 桥接。