Posts

[!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 桥接。 ...

[!NOTE] 初心：为了帮儿子在学习时更好地进入状态，我用纯 HTML 手搓了一个极其轻量的“专注力工具箱”。它没有复杂的后台，只有三个最原始、最直接的模块。 在这篇文章中，我将分享这个工具的设计逻辑。你可以直接在导航栏点击 专注力工具 体验。 1. 为什么是“手搓”？ 市面上有很多专注力 App，但它们往往： 功能太重：容易引起孩子在 App 内部的二次分心。 缺乏针对性：我需要的是一个能够配合学习节奏（15-20 分钟一节）的纯净环境。 于是我写了这个不到 400 行代码的 HTML 页面。 2. 三个核心模块 A. 视觉热身 (Visual Warmup) 在进入正式学习前，大脑需要一个“启动仪式”。 原理：盯着屏幕中央的圆点持续 30 秒，尽量不眨眼。这能锻炼眼部肌肉，强迫神经系统从发散状态收束到一点。 色彩选择：默认使用 Tiffany Blue (蒂芙尼蓝)，这种颜色能给人带来宁静、克制的视觉心理暗示。 B. 极致专注计时 (Focus Timer) 我们不崇尚长时间苦学，而是强调高效的“短周期推演”。 15/20 分钟闭环：配合孩子的专注时长，设置了扇形和网格两种视觉反馈。 视觉化流逝：看着红色扇面一点点缩减，比抽象的数字更能让孩子感知时间的宝贵。 C. 状态反馈 (Brain Check-in) 学习不只是输入，还需要“元认知”监控。 状态卡片：在计时结束或开始前，让孩子选择自己是“充电状态”还是“棉花大脑”。 自省回路：这种简单的交互能帮孩子建立起“我现在状态如何？”的自我觉察，这是长期专注的基础。 总结 这个工具是 VisAgent/Claw 哲学的一个分支：工具不一定要复杂，但一定要顺手。 如果你也面临孩子学习坐不住的问题，欢迎点击上方导航栏体验。 手搓快乐！🦾

[!TIP] 目标：实现“零侵入”的架构文档同步与 AI 自驱动的系统修复闭环。 1. 零侵入代谢 (Metabolic Governance) 在手搓 Agent 的过程中，维护 ARCHITECTURE.md 和路由表通常是开发者的噩梦。我们的方案是 Metadata-Free 的“新陈代谢”机制： 感知变更：挂载于 Git 钩子，通过 Git Diff 捕获代码变动。 语义推演：AI 自动分析代码意图，更新机器可读的 .anti_bot_map.md (RAG 路由表) 和人类可读的 ARCHITECTURE.md (架构心法)。 强一致性：彻底消除人工维护文档的成本，文档即代码，代码即地图。 2. 系统的脉搏：Heartbeat 引擎 为了保证 Agent 在无人值守下的稳定性，我们配置了独立的 Heartbeat 进程。它不仅仅是监控资源，更是一个“自我意识”探测器： def probe_heartbeat_checklist(): """让 AI 定期审计自己的运行状态""" with open(HEARTBEAT_FILE, "r") as f: content = f.read() if "[ ]" in content: # 发现待办或异常 engine = RoleEngine("heartbeat") # 触发 AI 进行自我诊断并更新状态 result = engine.invoke(f"Audit this checklist:\n{content}") 3. 自愈闭环：Self-Repair Agent 当 Heartbeat 探测到网关假死或日志中出现 Traceback 时，会瞬间唤醒 Self-Repair Agent： ...

[!TIP] 目标：通过 CLI 传参实现多模态（视觉/文件）感知，并构建动态加载的插件式技能系统。 1. 让 CLI “看见”世界 多模态能力不一定非要复杂的 SDK。在 VISAGENT 中，我们利用 gemini CLI 对文件路径的天然支持（@path），在 RoleEngine 层实现了感知接入： def _do_raw_invoke(self, message, files=None): # 构造多模态后缀 mm_suffix = "" if files: mm_suffix = "\n" + "\n".join([f"@{f}" for f in files]) # 拼接到最终 Prompt full_input = f"{message}{mm_suffix}" # ... 执行 subprocess 实战经验：为了处理复杂的视觉任务，我们专门封装了 vision_expert 技能，通过 DEEP 模式引导 AI 进行 Chain-of-Thought 推演，从而实现对截图、UI 组件的精确识别。 2. 动态技能树：SkillHandler 手搓系统的灵活性在于 插件化。我们设计了 SkillHandler 模块，它能自动发现 skills/ 目录下的所有能力： 自动化发现：启动时扫描目录。 Manifest 规范：每个技能自带 manifest.json，定义其功能描述与 权限主权 (Sovereignty)。 Sovereignty-Aware：在 Prompt 注入时，系统会明确告知 AI 它被授权访问的 FS 路径和网络域，实现安全约束。 3. 灵活的 Hooks 机制 为了在 AI 调用前后插入逻辑，我们实现了一组 Python Hooks： ...

[!TIP] 目标：从单步对话进化为“计划-模拟-执行”的闭环，并引入基于 YAML 的 DAG 异步编排。 1. 从“聊天”到“执行”：AX (Architect-Executive) 范式 Agent 与普通 Chatbot 的分水岭在于：它是否能将模糊的目标拆解为可操作的步骤。在 VISAGENT 中，我们实现了一套 AX Planner 逻辑： Architect (架构师)：接收需求，输出 TODO.json。此时严禁执行，只准规划。 Simulation (心理演操)：在执行前，让另一个“安全专家”角色对计划进行风险评估。 Executive (执行官)：逐一调用 execute_step 完成任务。 这种“先想后做”的机制，通过简单的 Prompt 约束即可在任意 CLI 上实现： # AX_PLANNING_MODE 核心指令 plan_prompt = ( "You are a specialized Task Architect. Output ONLY valid JSON.\n" "Schema: { 'goal': '...', 'steps': [ {'id': 1, 'desc': '...', 'type': 'EXECUTION'} ] }" ) 2. 线性落后：为什么需要 DAG？ 早期的 AX Planner 是线性的。但现实中，复杂的工程任务往往是拓扑结构：有的步骤可以并行，有的则必须等待前序结果。这就是我们引入 Flow Architect 的原因。 ...

[!TIP] 目标：不依赖框架，通过封装 CLI (如 gemini CLI) 构建具备状态管理与隔离能力的 Agent 引擎。 1. 为什么选择 CLI 而非框架？ VISAGENT 的核心设计哲学是 CLI-Native。相比于黑盒框架，直接封装 CLI (如 gemini CLI) 具有更高的可控性和透明度： 原子性：单次调用即单次推演。 状态透明：Session 的恢复与挂起完全由路径和 Resume 标志控制。 环境隔离：利用系统级工具即可实现权限沙箱。 2. 底层封装：RoleEngineBase 核心逻辑通过 subprocess 触发。为了处理长 Prompt 导致的 Shell 参数溢出，我们坚持使用 stdin 传输： def _do_raw_invoke(self, message: str, context: str = "", files: List[str] = None) -> dict: cmd = [AI_BIN, "--resume", "latest"] if self._get_turns() > 0 else [AI_BIN] # 应对超长 Prompt 使用 stdin use_stdin = len(message + context) > 2000 if use_stdin: cmd += ["-p", "-"] result = subprocess.run( cmd, input=f"{message}\n\n{context}" if use_stdin else None, capture_output=True, text=True, encoding='utf-8' ) if result.returncode == 0: self._inc_turns() return {"ok": True, "output": result.stdout} 3. 隔离与会话管理 凭证沙箱 (Symlink) 为了实现多角色、多项目并发而不产生凭证污染，我们利用 软链接 (Symlink) 动态注入 .gemini 配置： ...

[!IMPORTANT] 核心痛点：在快速迭代的项目中，由于人工更新文档的成本极高，导致代码与架构文档（README, ARCHITECTURE.md）总是处于“失真”状态。 解决之道：将“文档维护”从人类开发者的心智负担中剔除，移交给具备语义推演能力的 AI Agent，实现架构图谱的“新陈代谢”。 在跟 AI 进行多轮关于文档治理的对话后，我沉淀出了一个关于“AI 原生新陈代谢治理（AI-Native Metabolic Governance）”的 Skill 构思。这不仅仅是一个自动化脚本，更是一种让代码架构“活起来”的治理逻辑。 Skill: AI-Native Metabolic Governance V3.0 (新陈代谢地图治理) 🎯 核心目标 (Objective) 通过“无侵入”感知和 AI 自主驱动，彻底消除文档维护的心智负担。本 Skill 指导 Agent 在代码发生变更时，自主分析物理结构与逻辑意图的变化，自动更新机器可读的寻址地图（Map: .anti_bot_map.md）和人类可读的架构心法（Lore: ARCHITECTURE.md）。 ⚙️ 触发时机 (Trigger Conditions) 主动触发: 接收到指令 执行新陈代谢、Run metabolism 或 更新架构图。 被动拦截: 挂载于 git pre-commit 或部署脚本（如 scripts/remote_deploy.py）执行前。 🔄 执行工作流 (AI-Native Workflow) 当触发本 Skill 时，Agent 必须严格执行以下三步： Step 1: 零侵入发现 (Zero-Intrusion Discovery) 摒弃人工标签: 严禁要求人类开发者书写任何 @identity 类的冗余注释。 AST 物理扫描: 扫描目标域的 src/ 目录，提取所有导出的类名 (Exported Classes)、核心接口 (Interfaces) 和顶层函数 (Top-level Functions)，将其作为天然的 Identity。 Step 2: 语义推演与计算 (Semantic Metabolism) 提取上下文: 获取当前的 Git Diff、最新的 AST 结构，以及旧版的 .anti_bot_map.md。 意图识别: 判断代码变更的性质。 是新增模块？ -> 自动为其总结 Role。 是文件拆分？ -> 追踪旧逻辑流向了哪个新文件。 是废弃删除？ -> 标记为已移除。 计算健康度 (Health Score)：满分 10.0。若存在大量未被文档化的复杂大类，或模块职责严重耦合，酌情扣分。 Step 3: Map 与 Lore 的双向重绘 (Dual-Update) 根据推演结果，覆写以下两个核心文件： ...

[!TIP] 受众：希望能从底层逻辑优化刷宝效率的 D2R 玩家。 核心目标：梳理 /players X 命令与实际掉率之间的数学关系。 问题-方案映射： 误区：认为只需简单开启 8 人难度就能达到最高掉率。 方案：详解 X（总玩家数）与 Y（同图组队玩家数）对 NoDrop 的共同影响。 暗黑 2 重制版进入第 13 赛季，不少老友依然在讨论如何更科学地“出货”。在刷宝的过程中，单凭感觉往往容易产生偏差，理解游戏背后的 NoDrop（空手率）机制，能让我们在选择刷宝难度和效率之间找到更好的平衡点。 所谓的掉落，其实是一场与概率的博弈。 1. 怪物强度与 X 因子 在 D2R 中，玩家数（X）影响怪物的基本属性。这些属性在怪物生成的瞬间即被固定，即使玩家随后离开游戏，数值也不会改变。 以下是玩家数对怪物生命值的影响参考： X (总玩家) 生命周期 (HP) 倍率 示例 (基础 500 HP) P1 100% 500 P2 150% 750 P3 200% 1,000 P4 250% 1,250 P5 300% 1,500 P6 350% 1,750 P7 400% 2,000 P8 450% 2,250 [!NOTE] 在噩梦与地狱难度下，额外的玩家还会提升怪物的伤害与准确率（AR），每位额外玩家约增加 6.25%。 2. NoDrop 机制：X 与 Y 的协同作用 很多时候，大家会发现单机开启 /players 8 的体感掉落并没有想象中那么夸张。这是因为掉落判定是在怪物死亡瞬间计算的，且受到 Y 因子（同地图组队玩家数）的影响。 ...

深度总结 D2R Multi Rust 从 Tauri v1.x 迁移至 v2.0 的“致幻”过程，涵盖 ACL 权限机制变更、Minisign 签名机制更新以及 Github Action 自动化发布的深坑。