核心用法
knowledge-base-collector 是一款面向个人知识管理的采集型 Skill，设计目标为"先入库不丢，再迭代优化"。其核心工作流程围绕三类输入展开：
网页与社媒链接采集：支持普通网页、X/Twitter 推文、微信公众号文章三类 URL。调用 ingest_url.py 脚本后，自动识别来源类型，优先通过 r.jina.ai 服务提取正文内容，生成 content.md 与 meta.json 双文件存储。系统内置 URL 去重机制，避免重复入库。
截图与图片入库：通过 ingest_image.py 处理本地图片，支持 OCR 文本关联落盘。用户可预先使用 tesseract 或多模态 LLM 提取文字，通过 --text-file 参数注入，实现"图+文"双重索引。
标签化组织与检索：采用"标签优先"分类策略，支持层级标签（如 #coding-agent/#claude-code）与多维度标记（来源、主题、状态）。配套提供 search_kb.py 关键词/标签/时间窗口检索、weekly_digest.py 周报生成、wechat_backlog.py 待补抓队列管理，形成完整的内容消费闭环。
WeChat 特殊处理：针对公众号抓取的风控问题，设计了"云端优先+节点回退+占位兜底"的三级策略。当云端触发验证时，若存在已连接的 macOS 节点（如 Reed-Mac），可尝试节点侧抓取；否则创建 status=blocked_verification 占位条目，保证信息不丢失，后续手动补全。
显著优点
架构设计务实：文件系统+JSONL 索引的轻量级方案，无需数据库依赖，天然支持版本控制与同步。20_Inbox 的收件箱模式符合 GTD 理念，降低认知负荷。
来源覆盖全面：同时处理开放网页（Web/X）与半封闭生态（微信公众号），并通过节点代理机制解决特定平台的风控瓶颈，在同类工具中具备差异化能力。
扩展性良好：标签体系开放，支持用户自定义语义标签；脚本化设计便于二次开发（如接入 Notion/Logseq 等外部系统）。
安全基线达标：无危险函数执行、无硬编码密钥、数据纯本地存储，通过静态代码分析与动态行为审计。
潜在缺点与局限性
外部服务单点依赖：核心内容提取功能完全依赖 r.jina.ai，该服务不可用将导致网页采集失效。虽有 WeChat 占位机制，但通用网页暂无本地备用方案。
WeChat 采集成功率波动：即使引入节点代理，仍受微信反爬策略、节点在线状态、网络环境三重变量影响，无法承诺 100% 成功率，需用户接受"部分占位"的工作模式。
无内置敏感信息脱敏：截图 OCR 可能捕获 API Key、Token 等敏感数据，目前仅依赖 SKILL.md 文档提醒，缺乏代码层自动检测与强制脱敏机制。
检索能力基础：当前检索基于简单的字符串匹配与标签过滤，未实现语义搜索或向量检索，大规模知识库下的查找效率可能受限。
生态封闭性：依赖特定目录结构（/home/ubuntu/.openclaw/kb）与 Telegram 工作流，跨平台迁移或与其他 PKM 工具集成需额外开发成本。
适合的目标群体
researchers & 技术写作者：需要系统归档公众号技术文章、Twitter 线程、GitHub Discussion 等分散信息源，构建主题知识库。
效率工具爱好者：已使用 Telegram 作为信息入口，希望将"收藏即遗忘"转变为"收藏即可检索"的主动管理范式。
小型团队知识管理员：需在本地服务器维护共享资料库，对数据主权敏感，拒绝 SaaS 订阅模式。
macOS+Linux 混合环境用户：拥有常驻 macOS 设备可作为 WeChat 采集节点，补充云端能力缺口。
使用风险说明
性能风险：r.jina.ai 为免费/低费率服务，高频批量采集可能触发速率限制；大规模图片 OCR 若依赖云端多模态模型，将产生 Token 消耗。
依赖项风险：Python 环境需自行维护，requests 版本未锁定可能引发兼容性问题；tesseract 中文识别需额外安装 chi_sim 语言包。
数据持久化风险：本地文件存储无自动备份机制，KB 目录损坏或误删将导致知识库丢失，需用户自行配置 rsync/云同步策略。
隐私合规风险：URL 发送至第三方服务虽为功能必需，但涉及用户浏览行为数据外泄，敏感行业（金融、医疗）用户需评估合规影响。
维护可持续性风险：T3 来源可信度表明作者为个人开发者，长期更新与漏洞响应存在不确定性，建议关键使用前审查代码并考虑 fork 自维护。