从 n8n 到 AutoGPT：自动化工具的两次进化，和还没解决的问题 2023 年之前，自动化 = 「如果 A 就 B」的规则流；2023 年之后，自动化 = 「给个目标，自己想办法」。这两代工具在 GitHub 上同时繁荣，本文拆解它们的架构差异、演进路径，以及「自主性」这道至今没满分的题。 先讲个对比场景。需求：「每天早上把昨天的客户投诉整理成摘要发到 Slack。」 用 n8n 做：拖出定时触发器 → Gmail 节点拉邮件 → 过滤节点筛投诉 → LLM 节点生成摘要 → Slack 节点发送。每一步是什么、失败了走哪条边，画布上一目了然。 用 AutoGPT 做：告诉 Agent「每天整理客户投诉摘要发 Slack」，它自己决定怎么连 Gmail、怎么判断什么是投诉、怎么调 LLM。 两种做法都能完成任务，但信任模型完全不同——前者你信任的是自己画的流程，后者你信任的是模型的判断。这就是两代自动化工具的分水岭。 第一代：n8n——「可视化优先，代码兜底」 n8n（197K Star）从传统工作流自动化起家，现在是「AI 原生自动化平台」的标杆。它的架构是教科书级的分层： 节点（Node）为基本单元的 DAG 引擎：前端可视化画布，后端 Node.js 执行引擎处理触发器、分支、工具调用； AI 层集成 LangChain：Agent 编排、模型切换、工具使用都是现成节点； 数据持久化：SQLite（单机起步）到 PostgreSQL（生产）。 最值得学的是它的两条设计原则： **1. 可视化优先，代码兜底。**画布覆盖 80% 场景，剩下 20% 用 Code 节点写 JS/Python，甚至引 npm 包。这个比例拿捏是关键——纯低代码平台必然在复杂场景碰壁（「做到 90% 就上不去了」），留一个代码逃生舱，天花板就没了。 2. 1500+ 集成节点 + 9000+ 模板市场。节点有标准化开发模式，社区贡献机制成熟；模板市场让用户从「别人的成品」起步而不是从零拖起。平台类项目的增长飞轮，本质是让贡献者和使用者都占到便宜。 ...

我把信息摄入、追踪、研究拼成了一条流水线：五个 GitHub 项目的组合拳 单个 AI 工具解决单点问题，但信息工作的真实形态是一条链：格式转换 → 聚合 → 追踪 → 研究 → 沉淀。本文拆解五个各管一段的开源项目，以及它们怎么拼成一条个人信息流水线。 先描述一个典型的信息工作日：早上要看行业新闻，盘中要盯持仓股票的异动，临时要调研一家公司近况，周末还要整理读书笔记。如果每件事都靠「打开 N 个网站 + 手动复制粘贴」，一天下来真正思考的时间所剩无几。 我在 GitHub 上找到的解法不是一个全能工具，而是五个各管一段的项目。它们串起来的逻辑是：数据先变成 LLM 能吃的格式，再被聚合和追踪，最后由 AI 加工成结论。 graph LR A[原始文档<br/>PDF/Office/网页] -->|markitdown| B[Markdown] B --> C[open-notebook<br/>沉淀与问答] D[各平台热榜] -->|newsnow| E[聚合看板/MCP] F[社交平台噪音] -->|last30days-skill| G[社交相关性简报] E --> H[AI Agent 消费] G --> H C --> H 入口段：markitdown——一切格式转 Markdown 微软的 MarkItDown 解决的是流水线最脏最累的第一环：把任意文档变成 LLM 友好的文本。 PDF、Word、Excel、PPT、图片、音频、HTML、CSV，甚至 zip 包和网页 URL，一行命令转成结构清晰的 Markdown。它和普通文本提取工具的关键区别：保留标题层级、表格结构和列表语义，而不是把文档拍平成一坨纯文本——下游模型能不能理解文档结构，差距就在这。 架构是「转换器注册表」：核心类维护 MIME 类型到 Converter 的映射，每种格式一个转换器（pdfminer 管 PDF、python-docx/pptx/openpyxl 管 Office 三件套），可选挂 OCR、Whisper 转写、LLM 图片描述。已经有 AutoGen 和 LangChain 的官方集成。 ...

自托管到底在折腾什么？从 awesome-selfhosted 到 go2rtc 的四层答案 「为什么你要自己架服务，直接用现成的不好吗？」——本文用四个 GitHub 项目回答这个问题。自托管不是一种技术偏好，是一套关于数据主权的价值观，而它的工程形态远比想象中精致。 每次跟人聊起家里那台跑着十几个容器的小服务器，总会被问：「云上不香吗？免费额度不够吗？」 香。但研究完 awesome-selfhosted（307K Star）这个索引库和它圈子里的几个代表项目后，我想给自托管一个更准确的定义：**它不是「自己部署软件」，而是「把数据、服务、规则的控制权收回到自己手里」。**这个定义能解释为什么这个圈子既极客又固执。 第一层：一张地图——awesome-selfhosted 先看规模。awesome-selfhosted 收录了数百个可自托管应用，覆盖： 类别 代表项目 替代的商业服务 通信 Matrix、Jitsi、Discourse Slack、Zoom、Reddit 内容 Ghost、BookStack、Strapi Medium、Notion、Airtable 文件同步 Nextcloud、MinIO、Syncthing Google Drive、Dropbox 媒体 Jellyfin、Immich、Navidrome Netflix 相册、Google Photos、Spotify DevOps Gitea、Drone、Uptime Kuma GitHub、Jenkins、StatusPage AI Ollama、LocalAI OpenAI API（本地化） 注意几个细节，能看出这个社区的「价值观洁癖」： 只收符合开源定义（OSD）的软件，非自由软件单独关进 non-free.md 小黑屋。数据主权的前提是软件本身可审计，逻辑是自洽的。 GitHub Actions 自动巡检死链和弃坑项目——索引库最大的天敌是腐烂，他们用自动化对抗它。 元数据独立仓库（YAML/JSON）管理，README 自动生成——数据与展示分离，这个工程实践本身就值得抄。 它诚实列出了缺点：技术门槛、安全更新责任、硬件带宽成本。自托管不是免费的，只是把「订阅费」换成了「运维投入」。想清楚这笔账，再看要不要入坑。 第二层：协议翻译官——go2rtc 如果说 awesome-selfhosted 是地图，go2rtc（AlexxIT，Go 语言）就是自托管精神的极致样本。它解决的问题特别具体：家里摄像头品牌太杂，协议互不相通。 海康用私有协议、小米用自家的、Ring 又是一套；你想看画面，要么装五个 App，要么各厂商的云服务各看各的（还得交月费）。go2rtc 的做法是做一个「通用协议转换网关」： graph LR A[RTSP/ONVIF/海康/小米<br/>Ring/Wyze/GoPro...] --> G[go2rtc<br/>协议转换网关] G --> B[WebRTC 零延迟播放] G --> C[HLS / MP4 / RTMP] G --> D[HomeKit / Home Assistant] 输入端支持 RTSP/RTMP/WebRTC/ONVIF/HLS 加一堆私有协议，输出端支持 WebRTC（零延迟）、HLS、MP4、HomeKit，还能双向音频、推流到 YouTube/Telegram。 ...

AI 编程的下一个战场不是模型，是「技能层」 Agent 时代的真实痛点：模型能力够了，但它「不懂你团队的规矩」。本文梳理 GitHub 上正在成型的 Agent Skills 生态——从标准到方法论再到宿主，一层一层看这套新基础设施是怎么长出来的。 用 AI 写代码半年以上的人，大概都有过这种体验：模型的智商不是瓶颈，对齐才是。你说「重构这个模块」，它哗啦一下把接口签名、调用方、测试全改了；你说「先别动」，它说好的，然后顺手格式化了半个仓库。 2026 年的 GitHub 上，一批高星项目正在集体回答同一个问题：**怎么让 AI 编码代理像一个守规矩的工程师，而不是一个热心但莽撞的实习生？**答案收敛到了一个词：Skills（技能）。 一个标准的诞生：SKILL.md 故事的起点是 Anthropic 的 Agent Skills 规范（anthropics/skills，163K Star）。它的设计简单到惊人： 每个技能就是一个文件夹； 里面一个 SKILL.md，带 YAML frontmatter，必填字段只有两个：name 和 description； 代理启动时扫描技能目录，根据 description 判断当前任务该激活哪个技能。 就这么点东西，但它解决了一个关键问题：**方法论从此可以像代码一样分发。**以前「怎么做代码审查」「怎么写好需求」这些经验锁在人脑里，现在它变成了可版本化、可安装、可共享的文件。仓库里 docx/pdf/pptx/xlsx 四个文档技能是官方示范——注意它们是「源码可见」而非完全开源，且明确声明仅供演示、生产需自测，这个边界划得很诚实。 标准立住之后，生态开始分层。我把它分成三层来看： graph TD A[标准层<br/>SKILL.md 规范] --> B[方法论层<br/>superpowers / agent-skills / mattpocock] B --> C[宿主层<br/>Claude Code / opencode / deer-flow / hermes] D[配置层 cc-switch] --> C 方法论层：三种「驯服 Agent」的思路 这一层是生态里最有意思的部分。三个头部项目，代表三种完全不同的思路。 思路一：流程化——obra/superpowers（260K Star） 它的哲学是「流程化而非随意发挥」，把软件开发拆成一套自动触发的工作流技能：brainstorming（苏格拉底式追问需求）、writing-plans（拆成 2-5 分钟的小任务）、subagent-driven-development（派子代理干活 + 两阶段评审）、test-driven-development（强制红绿重构）、requesting-code-review…… ...

同一个「存数据」的需求，为什么长出了三种完全不同的数据库？ PostgreSQL、Redis、DuckDB——三者都管自己叫「数据库」，但架构几乎没有一处相同。本文从一个问题出发：为什么「存数据」这一件事，需要三种截然不同的答案？ 先说个真实感受：新人问我「该用什么数据库」时，我最怕听到的是「就……存点数据」。因为「存数据」这个需求背后，至少藏着三个互相矛盾的目标：要快（延迟）、要对（一致性）、要能算（分析吞吐）。这三个目标在物理层面就是打架的，所以业界长出了三种完全不同形态的数据库，各自押注一个目标。 这篇拿 PostgreSQL（75K+ Star 里的常青树）、Redis（75K Star）、DuckDB（40K Star）当样本——它们恰好是三条路线的教科书级代表。 三种数据库，三种「世界观」 PostgreSQL Redis DuckDB 一句话定位 数据的基础设施 远程数据结构接口 SQLite for Analytics 押注的目标 正确性 > 性能 延迟 > 一切 分析吞吐 + 零部署 数据在哪 磁盘（缓冲进内存） 内存 就在文件里（CSV/Parquet/S3） 并发模型 多进程、MVCC 多版本 单线程事件循环 单写者、Morsel 并行读 典型场景 金融、ERP、订单 缓存、会话、排行榜、限流 数据科学家本地跑 SQL 分析 注意：这三行的每一列差异都不是「实现细节」，全是世界观分歧。往下看。 PostgreSQL：把「正确」放在所有选项的前面 PostgreSQL 从 1986 年 Berkeley 的学术项目走到今天，38 年没死，靠的不是快——它从来不追求最快。它的护城河是正确性和可信度的复利。 几个能看出价值观的设计： 1. Process-per-connection：每个连接一个独立进程。 MySQL（InnoDB）用线程池，PG 用进程。进程更重、启动更慢，但一个连接崩了不会带走别人——内存隔离是操作系统保证的，不是代码纪律保证的。这是「可靠性高于便利」的字面体现。 2. MVCC 的代价是 VACUUM。 读写互不阻塞的代价是旧版本数据堆在表里，得靠 VACUUM 回收。很多人骂 VACUUM 烦，但这笔交易是明码标价的：读永远不阻塞写、写永远不阻塞读，换来的运维成本。对比 MySQL undo log 的回收方式，各有取舍，但 PG 把旧版本直接放主表的设计，让「时间旅行」「闪回查询」这类能力成为可能。 ...

跑一个大模型到底有几种跑法？从 llama.cpp、Ollama 到 vLLM 的三条路 本文回答一个看似简单的问题：「我想在本地跑个大模型」——然后呢？这三个 GitHub 上最火的推理项目，其实回答的是三个完全不同的问题。 周末折腾本地大模型的人，大概率经历过这个场景：搜「本地跑 LLM」，GitHub 推荐给你 llama.cpp、Ollama、vLLM 三个项目，Star 数加起来四十多万。打开 README 都是「高性能推理」，看起来互为竞品。 但我研究完这三个项目的架构后，结论是：**它们根本不是竞品，是三条不同的路，解决三个不同的问题。**选错工具不是性能差一点的问题，是方向错了。 三个项目，三个问题 先把结论摆出来： 项目 回答的问题 服务对象 优化目标 llama.cpp 「我的笔记本/手机能跑吗？」 单个极客 单请求延迟、硬件可及性 Ollama 「我只想跑，不想折腾」 所有人 上手门槛（降到一条命令） vLLM 「一块 GPU 怎么服务上千用户？」 生产 API 服务 多请求吞吐 注意看第三列——llama.cpp 和 vLLM 的优化目标甚至是对立的。一个恨不得为单个请求榨干每一毫秒延迟，一个恨不得把一千个请求塞进一个 batch 里摊薄成本。这两个目标天然冲突，所以它们不可能是同一个工具的两种实现。 llama.cpp：把 LLM 从数据中心拽到你的笔记本 llama.cpp 的故事从一个意外开始：2023 年初 LLaMA 权重泄露，作者 Georgi Gergashev 四天内拿出了原型。这个「时机比技术重要」的案例后来被反复引用，但真正让这个项目活下来的是架构决策。 它做了一个关键分层：底层是 ggml 张量库（算子、内存管理、多后端抽象），上层是 llama 推理引擎（模型定义、KV Cache、采样、API）。最大的亮点是多后端抽象——同一套 ggml API，底下可以是 CPU（AVX2/AVX512/NEON）、CUDA、Metal、Vulkan、SYCL、HIP，还支持 CPU+GPU 混合推理（-ngl 指定丢给 GPU 的层数）。你 MacBook 上跑 Metal、Linux 服务器上跑 CUDA、安卓手机上跑 NEON，代码是同一套。 ...

一台 2017 年的 MacBook Pro，当年卖一万多，如今打开浏览器都喘。问题不在硬件——而在它身上的软件每年都在为更新的机器写作。给它换个轻量系统，等于把被系统吃掉的 3GB 内存还给自己。 开场：越更新越卡的"官方支持" 上周帮朋友收拾一台 2017 款 MacBook Pro：13 寸，8GB 内存，512GB SSD。当年这也是台主力开发机，现在开个 Chrome 加十几个标签页，风扇就开始起飞，切换窗口能感觉到明显的迟滞。 系统一路从 Sierra 升到了 Ventura——苹果对这台机器的官方支持到 macOS 13 为止，再往上（Sonoma、Sequoia、Tahoe）全都把它踢出了名单。也就是说，这台机器已经站在了 macOS 世界的尽头： 安全更新快断供：Ventura 的支持周期临近结束，之后就是裸奔 资源越吃越多：空闲状态下 macOS Ventura 自己就占掉 3.5–4.5GB 内存，留给应用的只剩不到一半 软件只往前看：新版应用默认你有 16GB 内存和新 CPU，没人再为 8GB 老机器优化 换掉它的理由很充分。但换什么？答案可能出乎意料地朴素：Xubuntu 24.04 LTS。 为什么是 Xubuntu：一张对比表说清楚 Xubuntu 是 Ubuntu 官方 flavors 之一，把桌面从 GNOME 换成了轻量的 XFCE。内核、软件仓库、apt、LTS 支持周期全都和 Ubuntu 一样，只是桌面开销大幅降低。 在同一台 2017 MBP（8GB / 512GB SSD）上实测对比： 项目 Xubuntu 24.04 macOS Ventura 这意味着什么 空闲内存占用 ~0.8 GB ~4.0 GB ✅ 多出 3GB+ 给浏览器和 IDE 安装体积 ~9 GB ~30 GB ✅ 磁盘压力小 开机到桌面 ~18 s ~35 s ✅ 日常感知明显 空闲 CPU <1% 1–3% ⚠️ Spotlight/iCloud 后台常驻 安全支持 到 2029（ESM 到 2034） 即将停更 ✅ 决定性差距 动画精致度 朴素但流畅 丝滑 ⚠️ 唯一让步 8GB 内存是这台机器的瓶颈。macOS 的内存管理很聪明（压缩 + swap），但巧妇难为无米之炊；Xubuntu 的思路简单粗暴——系统自己少用点，把内存还给应用。 ...

摘要：2026 年了，为什么还有人用 Electron 写 SSH 客户端？PixShell 的作者给出了另一种答案：同一个 monorepo，macOS 端用 Swift + AppKit + SwiftTerm + SwiftNIO 手写 SFTP v3 协议，Windows 端用 C# WPF + WebView2 + SSH.NET，双端原生、零 Electron。功能上它几乎照着 FinalShell 抄了一遍作业（同屏目录同步、chmod、打包传输、一键迁移），又加上了 2026 年的新东西：MCP、Agent Bridge、AI 工具一键接管 SSH。更有意思的是——这个项目几乎是一个人带着几个 AI 编码代理写出来的。本文拆解它的功能定位、架构取舍、协议实现细节和那些藏在注释里的踩坑记录。 一个 SSH 客户端的"去 Electron 化"实验 打开 FinalShell、Termius、Tabby 的进程列表，你大概率会看到一堆 --type=renderer 的 Chromium 子进程。一个用来连服务器的工具，自己先吃掉 800MB 内存，这件事大家似乎已经习惯了。 PixShell（github.com/lyu0805/pixshell）的作者显然没习惯。这个项目的前身就是一个 Electron 应用——仓库里的蓝图文档还留着旧账：renderer 约 1.6 万行 + main 约 5700 行 JS。从 v0.1.1 开始，他做了一个相当激进的决定：推倒重来，双端全原生，同一个 monorepo 维护。 平台 UI 终端渲染 SSH/SFTP 栈 🍎 macOS Swift / AppKit SwiftTerm（原生渲染） SwiftNIO + 自研 SFTP v3 🪟 Windows C# / WPF WebView2 + xterm.js SSH.NET 注意这张表里最反直觉的一点：macOS 端没有用 xterm.js。Mac 的终端是 SwiftTerm 原生渲染的，只有 Windows 端因为 WPF 生态里没有像样的终端控件，才走了 WebView2 内嵌 xterm.js 这条路。作者在 README 里专门加了个警告框强调这件事——大概是被问烦了。 ...

摘要：还在手动暂停视频截字幕？还在边看直播边手打笔记？本文介绍的 screen_ocr.py 脚本，利用 macOS 原生 screencapture 与 Vision API，结合 Python 的 imagehash 库，实现了一个“框选即监控、变化即记录”的实时 OCR 笔记神器。特别适合视频字幕提取、在线会议记录及动态网页监控。 1. 工具简介：你的屏幕“速记员” 在日常开发与学习中，我们经常面临以下场景： 看网课/直播：老师讲得太快，来不及记笔记。 提取视频字幕：视频没有提供字幕文件，只能盯着画面看。 监控动态界面：某个网页或软件界面不断刷新数据，需要手动记录。 screen_ocr.py 专为解决这些痛点而生。它运行后，你只需在屏幕上框选出感兴趣的文字区域，它就会在后台“盯着”这块区域。一旦检测到画面内容变化（如字幕变了、数据刷新了），它会立即调用 macOS 原生的 OCR 引擎识别文字，并按时间顺序写入 Markdown 文件。 2. 核心功能解析 2.1 原生框选：screencapture -i 传统 Python 截图工具（如 pyautogui）通常无法精确框选区域，或者依赖庞大的 GUI 库（如 tkinter、PyQt）。screen_ocr.py 直接调用了 macOS 内置的 screencapture -i 命令。 体验：按下运行键，鼠标变成十字准星，跟平时用 Cmd+Shift+4 一模一样。 优势：零依赖、原生体验、支持 Retina 屏幕高清截图。 2.2 智能去抖：感知哈希 (pHash) 比对 如果每秒钟都调用 OCR，不仅浪费资源，还会产生大量重复文本（比如画面没变，但识别结果可能因为噪点略有不同）。 脚本引入了 imagehash 库，计算图片的 pHash (感知哈希)。 原理：将图片缩放、灰度化、DCT 变换后生成一个 64 位的指纹。 判定：只有当新旧两帧图片的汉明距离（Hamming Distance）大于 5 时，才认为画面发生了实质变化。 效果：完美过滤静止画面，仅在文字更新时触发识别。 2.3 极速识别：macOS Native Vision API 通过 ocrmac 库封装，直接调用 macOS 系统级的 VNRecognizeTextRequest。 ...

摘要：在处理视频关键帧文本/字幕提取时，我们常常面临“多帧重复”与“识别效率低”两大痛点。本文记录了从传统 PaddleOCR 方案切到 macOS Native Vision API 的全过程，并通过 Python 实现了内存级模糊去重与灵活的批量导出。在 M4 Pro 芯片加持下，识别速度直升至每秒 10+ 张！ 1. 背景与痛点 在视频内容分析、字幕提取或文档视频化等场景中，我们通常需要将视频按帧导出为图片并识别其中的文本。然而，这一过程有两个核心痛点： 画面重复率极高：相邻的关键帧往往包含完全相同或极其相似的文本，直接输出会导致结果大量冗余。 传统 OCR 引擎偏重：像 PaddleOCR 这类业界顶级的开源方案，在 NVIDIA 显卡或 x86 CPU 上表现优异，但在 Apple Silicon（如 M4 Pro）上运行时，由于需要经过 Python 运行时与跨平台计算图调度，单图识别耗时较长（100~300ms/帧），处理大批量图片时风扇直吹、资源占用较高。 2. 方案对比：PaddleOCR vs macOS Native Vision 为了在 Mac 上获得最佳效率，我们对比了两种技术路线： 维度 PaddleOCR (Python) macOS Native Vision API (ocrmac) 底层硬件支持 主走 CPU 多线程推理 / MPS 支持有限 深度适配 Apple Neural Engine (NPU) + Metal 单图识别速度 ~100 - 300 ms / 帧 ~50 - 100 ms / 帧（每秒 10+ 张） 资源与内存占用 需加载完整神经网络权重与 Python 运行库 直接调系统驻留服务，占用微乎其微 初始化开销 首次运行需下载 100MB+ 模型模型并做连通性检测 零下载、零模型开销，开箱即用 最佳适用场景 复杂工业票据、表格结构化解析、跨平台部署 macOS 平台下的视频关键帧、截图、常规文本快速提取 结论：在 macOS 环境下处理视频字幕与常规截图，原生 Vision API 凭借对 NPU 的极致调度，性能堪称“降维打击”。 ...