老牌但能打：Huginn 自托管自动化代理，RSS 聚合+网页监控实战

2026-08-16 · DevCraft Studio

在 1GB 小机用 Docker Compose 部署 Huginn（Postgres+Redis），手把手搭一条 WebsiteAgent→EmailDigestAgent 的每日资讯摘要流。对比 n8n 说明它在 scraping/监控场景更省节点，让你跑起一套数据完全自有的私有 IFTTT。

如果你玩过 IFTTT、Zapier，或者最近在折腾 n8n，大概率会有一个别扭的点：你的自动化规则、抓取到的数据、甚至触发条件，全都捏在别人手里。要么按月订阅，要么免费档随时砍功能。Huginn 就是来解决这个问题的一剂老药——它 2013 年就开源了，到 2026 年仍然有 44k+ 的 GitHub stars，MIT 许可，完全自托管、没有任何调用次数或节点数量限制。它不像 n8n 那样强调"可视化节点画布"，而是用代理（Agent）这个更贴近"智能体"的概念来组织自动化：每个 Agent 干一件小事，再把输出喂给下一个 Agent，串成一条流水线。2026 年它仍保持活跃维护，社区里每天都有新的 Agent 玩法被分享出来，这也是我愿意把它推荐给自托管新手的原因。

延伸阅读

更多相关攻略推荐：【知识库自托管 02】2026 实测：VPS 自托管 Anythin、抢补货/盯降价不求人：changedetection.io 自托管监、【知识库自托管 03】2026 实测：搬瓦工/RackNerd 上自、不写代码也能跑 AI：Flowise 自托管 + Ollama 搭建、为什么你的 VPS 账号会被突然封禁？避开 TOS 违规陷阱与退款坑。

一、为什么 2026 年还值得折腾 Huginn？

先说结论：如果你的需求是定时抓取网页、监控页面变化、聚合 RSS、再发一份每日摘要邮件，Huginn 比 n8n 更轻、更省节点。n8n 一个抓取流程往往要拖出 HTTP Request、HTML Extract、Function、IF、Email 好几个节点，而 Huginn 里一个 WebsiteAgent 就内置了"定时拉取 + CSS/XPath 抽取 + 变化检测"三件事，输出直接丢给 EmailDigestAgent 汇总。换句话说，同样一条"每天把几个技术博客的新文章聚成一封邮件"的需求，n8n 可能要 6 个节点，Huginn 只要 2 个 Agent。

它和 IFTTT/Zapier 的本质区别有三点。第一，有状态：WebsiteAgent 会记住上一次看到了什么，只把"新增/变化"的部分往后传，不会每天把整页重发一遍。第二，抓取能力强：原生支持 CSS 选择器、XPath、正则、甚至内嵌 JavaScript 做二次清洗，这是那些"只接官方 API"的 SaaS 做不到的。第三，数据自持：所有配置和抓取结果都存在你自己的数据库里，不依赖任何第三方账号。便宜 VPS 用户常问"Ruby 写的东西，1GB 小机跑得动吗？"——实测 50 个 Agent 空闲也就吃 300MB 左右内存，完全没问题。

顺带一提，Huginn 内置大约 60 种 Agent 类型。除了上面提到的 WebsiteAgent 和 EmailDigestAgent，常用的还有 RSSAgent（专门吃 RSS 源）、PeakDetectorAgent（检测数值波动，比如股价或气温）、DeDuplicationAgent（去重）、TriggerAgent（条件触发）、WebRequestAgent（调用任意 API）等。你几乎不需要写代码，纯靠界面里选类型、填 JSON 的 options 就能拼出相当复杂的链路。这也是它相比"还得写 Function 节点"的 n8n，在监控与抓取场景下更顺手的根本原因。

二、一台 1GB 小机够不够？VPS 怎么选

Huginn 官方给出的下限是 512MB 内存（仅测试），推荐 1GB 起步。我们这次要跑 Huginn + Postgres + Redis 三个容器，1GB 是舒适线，2GB 更从容。磁盘给 10GB 以上即可，镜像本身不大，主要增长来自抓回来的数据。CPU 几乎不挑，单核都行。

拿来练手的便宜机器我优先推荐这几家，都是年付十几二十美元的档次，跑 Huginn 绰绰有余：RackNerd 的 1GB 年付机型性价比极高，适合长期挂着；CloudCone 的按量计费小机适合先试水；BandwagonHost（搬瓦工）的 CN2 线路对国内访问更友好，如果你要在国内收邮件摘要会很舒服；Vultr 按小时计费、随时删机，适合先花几毛钱把整篇教程跑通再决定要不要留。

  • 1GB / 1 vCPU / 20GB SSD：个人自用、Agent 不超过 50 个的甜点配置。
  • 512MB 内存：能跑，但 Postgres 和 Redis 会抢内存，建议把 Postgres 的 shared_buffers 调到 128MB 以下，否则容易 OOM。
  • 2GB 及以上：可以放心加大量 WebsiteAgent 做全网监控，不必精打细算。

系统选 Ubuntu 22.04 / 24.04 都行，先装好 Docker 和 Docker Compose：curl -fsSL https://get.docker.com | sh 然后 sudo usermod -aG docker $USER 重新登录即可。别忘了开防火墙只放行 3000 端口（或干脆用反代后只放 80/443）。备份也很简单：定期 docker compose stop 后打包 ./pgdata 目录，或用 pg_dump 导出 SQL，就能完整保留所有 Agent 配置和抓取历史。配合 RackNerd、Vultr 这类商家自带的快照功能，更是双保险。

三、用 Docker Compose 一键拉起（Postgres + Redis）

很多老教程还在用 Huginn 镜像自带的 SQLite 或内嵌 MySQL，那是给演示用的。生产环境请务必把数据库拆出来，并且用 PostgreSQL 而不是 SQLite——SQLite 在 Sidekiq 并发写的时候会频繁报 "database is locked"。下面这份 compose 是我压过 1GB 机器的生产级写法，Huginn + Postgres 16 + Redis 7 三件套。

version: "3.8" services: postgres: image: postgres:16-alpine restart: unless-stopped environment: POSTGRES_DB: huginn POSTGRES_USER: huginn POSTGRES_PASSWORD: ${POSTGRES_PASSWORD} volumes: - ./pgdata:/var/lib/postgresql/data healthcheck: test: ["CMD-SHELL", "pg_isready -U huginn -d huginn"] interval: 10s timeout: 5s retries: 5 redis: image: redis:7-alpine restart: unless-stopped volumes: - ./redisdata:/data huginn: image: huginn/huginn:latest restart: unless-stopped depends_on: postgres: condition: service_healthy redis: condition: service_started ports: - "3000:3000" environment: APP_SECRET_TOKEN: ${APP_SECRET_TOKEN} DATABASE_ADAPTER: postgresql DATABASE_HOST: postgres DATABASE_PORT: 5432 DATABASE_NAME: huginn DATABASE_USERNAME: huginn DATABASE_PASSWORD: ${POSTGRES_PASSWORD} REDIS_URL: redis://redis:6379/0 RAILS_ENV: production DOMAIN: huginn.example.com INVITATION_CODE: ${INVITATION_CODE} SMTP_SERVER: ${SMTP_SERVER} SMTP_PORT: 587 SMTP_DOMAIN: ${SMTP_DOMAIN} SMTP_USER_NAME: ${SMTP_USER} SMTP_PASSWORD: ${SMTP_PASSWORD} EMAIL_FROM_ADDRESS: huginn@example.com volumes: - ./logs:/app/log

注意镜像标签：Huginn 官方不发语义化版本号，Docker Hub 上的 huginn/huginn 只有 latest 和具体的 commit hash。新手用 latest 最省心；如果你想锁定版本避免某天拉到破坏性更新，去 Docker Hub 抄一个 commit hash 钉死即可。

同目录放一个 .env 文件，别把密码写进 compose：

POSTGRES_PASSWORD=换一个强密码 APP_SECRET_TOKEN=`openssl rand -hex 64` 生成的随机串 INVITATION_CODE= SMTP_SERVER=smtp.example.com SMTP_DOMAIN=example.com SMTP_USER=huginn@example.com SMTP_PASSWORD=你的发信密码

APP_SECRET_TOKEN 一定要稳定、够长，用 openssl rand -hex 64 生成。它一旦在重启后发生变化，所有登录会话立刻失效，所以务必写进 .env 持久化，别每次都重新生成。然后 docker compose up -d，首次启动要等数据库初始化和建表，大概 30 秒到 1 分钟，看 docker compose logs -f huginn 出现监听 3000 端口就成功了。

四、实战：搭一条 WebsiteAgent → EmailDigestAgent 的每日资讯流

光部署没意思，我们来跑通 brief 里的核心场景：每天把几个 RSS/网页源的新内容聚成一封邮件摘要。这条流水线只需要两个 Agent，完美体现 Huginn "省节点" 的优势。先在浏览器打开 http://你的IP:3000，用种子账号登录（默认 admin / 你 .env 里设的密码，老镜像有时是 password，登进去第一件事就是改密码）。

第一个 Agent 是 WebsiteAgent，负责抓一个 RSS 源并抽取条目。新建 Agent 选 WebsiteAgent，配置如下（options 是 JSON）：

{ "type": "WebsiteAgent", "name": "抓 Hacker News RSS", "options": { "url": "https://news.ycombinator.com/rss", "type": "xml", "mode": "on_change", "expected_update_period_in_days": 1, "extract": { "title": { "xpath": "//item/title", "value": "string(.)" }, "link": { "xpath": "//item/link", "value": "string(.)" } } }, "schedule": "every_1h" }

这里 mode: on_change 是灵魂：Agent 会记住上一次抽到的条目，只把"新出现"的往外发，避免重复刷屏。schedule: every_1h 表示每小时轮询一次。你可以复制这个 Agent，把 url 换成任何 RSS（比如几个技术博客的 feed），做出 3~5 个抓取源。

第二个 Agent 是 EmailDigestAgent，把上游所有 WebsiteAgent 的输出汇总成一封漂亮的每日邮件。新建 Agent 选 EmailDigestAgent，receivers 里勾选刚才那几个 WebsiteAgent：

{ "type": "EmailDigestAgent", "name": "每日资讯摘要", "receivers": ["抓 Hacker News RSS", "抓某博客 RSS"], "options": { "expected_receive_period_in_days": 2, "subject": "你的每日资讯摘要 - ${time}", "content": "今日共收到 ${events.length} 条更新：\n\n${events.map(e => '- ' + e.title + ' ' + e.link).join('\n')}", "send_every": "1d", "send_at": "08:00" }, "schedule": "every_1h" }

send_every: 1d 加 send_at: 08:00 意味着每天早 8 点把累积的更新打包发出。SMTP 我们在 compose 里已经配好，收件人默认是触发这个 Agent 的账号邮箱，你也可以加 recipients 字段指定其他地址。保存后点 Agent 上的 "Run" 手动触发一次验证能收到邮件，整条流水线就通了。这就是一套完全私有、不依赖任何 SaaS 的 IFTTT。

想再进阶一点，你可以把多个 WebsiteAgent 的输出先过一个 DeDuplicationAgent 去重，再进 EmailDigestAgent；或者把 WebsiteAgent 的 mode 从 on_change 改成 all，配合 TriggerAgent 做"价格低于某阈值才发信"的条件告警。这种"Agent 拼 Agent"的玩法，正是 Huginn 被称作私有 IFTTT 的底气。它不追求花哨的画布，而是把"Agent 即积木"这件事做到了极致，越用越上头。

五、中文圈教程常漏的 8 个坑

  • 坑 1：用 SQLite 当生产库。镜像默认可能走 SQLite，并发一高就 "database is locked"。拆出 Postgres 或 MySQL，本教程已用 Postgres 规避。
  • 坑 2：APP_SECRET_TOKEN 重启后变了。没写进持久化配置，容器重建后所有会话报废。务必用 .env 固定。
  • 坑 3：忘了 REDIS_URL。不配 Redis，后台任务（Sidekiq）会退化或报错，邮件发不出去。三件套里 Redis 不能省。
  • 坑 4：直接公网裸奔 3000 端口。Huginn 自带账号密码只是地板，公网暴露建议套一层 Caddy + 基础认证或 Authelia/Authentik 前置认证，别只靠内置登录。
  • 坑 5：INVITATION_CODE 没设导致被陌生人注册。留空等于开放注册，单机自用请设一个随机码或留空但务必关掉公网。
  • 坑 6：抓取被目标站限流 / 封 IP。WebsiteAgent 默认不设 User-Agent，频繁轮询易被拦。在 options 里加 headers 伪装浏览器 UA，并把 schedule 调慢。
  • 坑 7：XPath 和 CSS 选择器混用。XML/RSS 源用 XPath，HTML 页面用 CSS。选错模式抽不到东西，新手常卡在这。
  • 坑 8：1GB 机器 OOM。Postgres 默认 shared_buffers 很能吃内存。1GB 机型在 postgres 环境里加 POSTGRES_SHARED_BUFFERS=128MB 类调优，或干脆升到 2GB 更稳。

只要避开这 8 个坑，Huginn 在便宜小机上能安安静静跑上好几年。它不像那些花哨的新玩具，胜在稳、轻、完全可控——这正是自托管玩家最在乎的东西。