n8n+Hermes建筑日报自动化踩坑实录:从零到跑通的彻夜复盘

凌晨3点,Telegram 推送了第一条自动生成的建筑趋势日报。从一个念头到成功运转,其间踩过的坑有多少?付出的时间值不值?这篇复盘将给你一份不加滤镜的真实答案。
源头:看似简单的推送需求
需求听起来并不复杂:每天清晨自动搜集与建筑、AI 设计及参数化相关的行业资讯,通过智能过滤和摘要后,推送到 Telegram。
这样一觉醒来就能读到精华,不必再亲自刷遍各个信息平台。
实现路径也很清晰——用 n8n 负责数据采集与调度,Hermes Agent 承担智能处理,最后通过 Telegram 完成推送。网上有现成的方案文档,看上去一两个小时就能跑通。
可真正动手之后,我从开始到成功推送几乎折腾了整夜。
这篇文章并非教程,而是一次深度复盘:记录每一个坑、每一个判断、每一次绕路,下次再碰到相似的挑战,就能少走无数弯路。
先分清角色:n8n 与 Hermes 功能定位
在进入那些坑之前,有必要先把两个工具的底层职责讲清楚。
n8n 是一个开源的工作流自动化平台,类似于 Zapier 或 Make,但能完全自托管。它的核心价值在于连接——把各类数据源、API、服务串联成自动化管道。RSS 抓取、HTTP 请求、数据库操作、定时触发,这些都是 n8n 的拿手好戏。但它不负责“思考”,只做搬运与编排。
Hermes Agent 则是一个本地运行的 AI Agent 框架,支持工具调用(网络搜索、文件操作、代码执行等),具备持久化记忆,并且可以接入 Telegram、Discord 等多个平台。它真正擅长的是“思考”与“判断”——理解上下文、筛选信息、生成结构化输出。
因此,两者的分工非常明确:n8n 是数据管道,Hermes 是大脑。
坑一:方案文档的理想与现实
网上流传的方案文档,架构看起来相当完备:定时触发 → RSS 采集 → Hermes 处理 → Telegram 推送。
但在一个关键步骤上,被一句话轻松带过——“请确保你已经部署好 Hermes Agent”。
问题就出在这。
Hermes Agent 有两种运行模式:
- •
hermes:交互式 CLI,打开终端直接对话,也是大多数人的日常使用方式 - •
hermes gateway:消息网关模式,用来连接 Telegram、Discord 等平台,同时内置了一个 OpenAI 兼容的 HTTP API,监听在 8642 端口
n8n 想调用 Hermes,必须依赖第二种模式所暴露的 HTTP API。如果只运行了 hermes,API 根本不存在,n8n 无论如何配置都连不上。
更细致的问题是:即使启动了 hermes gateway,API Server 默认也是关闭的。你必须进入 ~/.hermes/.env,同时设置以下两个变量:
API_SERVER_ENABLED=true
API_SERVER_KEY=你生成的密钥
其中 API_SERVER_KEY 是强制的,哪怕只是本地调用也绝不能省略,否则 gateway 会直接报错并拒绝开启 API。
教训:所有“请先确保你已经……”的步骤,都要逐行展开细查,绝不能假定对方的环境和你的一模一样。
坑二:已废弃的 Function 节点
方案提供的工作流 JSON 里,使用了 n8n-nodes-base.function 这个节点类型。
然而在当下的 n8n(v0.198.0 之后),Function 节点已经被 Code 节点彻底取代。
导入旧的 JSON 时,节点要么无法加载成功,要么静默失效——看似在工作流画布上完好无损,实际执行起来完全没有任何输出。
这个坑极其隐蔽,因为工作流看起来逻辑完整,错误提示又不够直接。
最终,我把所有 JavaScript 处理逻辑全部迁移到 Code 节点,并指定为 Run Once for All Items 模式,问题才算真正解决。
坑三:JSON Body 动态嵌入陷阱
在调用 Hermes API 时,需要将 RSS 文章内容拼接成一段 prompt,再放入 HTTP 请求的 Body 中。
最直观的做法是在 n8n 的 HTTP Request 节点里,通过表达式直接引用上游节点数据,并嵌入到 JSON 结构里,比如:
{
"content": "={{ $json.prompt }}"
}
但这根本行不通。prompt 里含有大量的中文文本、换行符和特殊字符,直接嵌入会彻底破坏 JSON 的合法性,n8n 在解析阶段就会报错。
解决思路是预先序列化:在 Code 节点里,用 JSON.stringify() 把整个请求 Body 打包成一个字符串,当成一个字段传给下游。HTTP Request 节点拿到的就是一个合法的 JSON 字符串,可以直接使用,从而绕开了动态拼接带来的语法隐患。
代价是多了一步处理,但换来了稳定的执行。
坑四:RSS 源网络可访问性
经测试,ArchDaily 的主 RSS 源在国内直接访问会返回 502,而参数化建筑网站的 SSL 证书有问题,会触发 TLS 握手错误。
最终保留了两个稳定可用的信息源:ArchDaily(通过备用地址接入)和 Dezeen。
建议:在正式部署前,务必用 curl 逐一验证每个 RSS URL 的可达性,绝不要想当然地认为国外网站都能无障碍访问。
坑五:本地 n8n 进程持久化
通过 npm 安装 n8n 后,直接运行 n8n start,进程是绑定在当前终端里的。一旦关闭终端,n8n 就立刻停止。
尝试用 nohup 让它后台常驻,但在我的 M1 Mac 上非常不稳定,进程经常会神秘消失。
最终依靠 tmux 解决了问题——新建一个专用的 tmux session 来跑 n8n,即使终端关闭,session 也不会结束:
tmux new-session -d -s n8n 'n8n的完整启动命令'
同样的策略也必须应用到 hermes gateway 上,以保证它持续在线。
这是本地自托管方案的通病:没有进程守护,也不具备自动重启能力,电脑重启后一切都得手动恢复。 如果追求真正的稳定运行,需要配置 macOS 的 launchd 服务,或者干脆迁移到 VPS 上。
成果:每日自动推送的质量
管线跑通后,每天早上 08:00,Telegram 会准时收到这样一条推送:
📅 建筑趋势日报 2026/06/09
🔥 今日精选:
Ecologies of Repair: Reconciling Our Relationship with Water
一句话亮点:苏丹裔建筑师 Ola Hassanain 提出“修复生态学”,以建筑实践重建人与水的关系
链接:archdaily.com/…When Façades Become Habitats
一句话亮点:立面从“内外分隔”转向“多物种栖息地”,建筑为生态让渡空间
链接:archdaily.com/…💡 今日趋势洞察:建筑正从服务人类的功能主义转向修复性实践——修复水、修复物种共存、修复多危机叙事。
质量远超我的预期。在这种应用场景下,Hermes 的筛选与总结能力表现得相当出色。
对比:n8n+Hermes 与单独 Hermes 的差异
这是一个值得认真辨析的问题。
Hermes 本身就提供了 hermes cron 功能,可以配置定时任务,让 Agent 自主搜索、整理并推送信息。单从结果来看,两种方案都能实现“每天自动推送建筑资讯”。
本质区别在于数据来源的控制权。
| 维度 | 单独 Hermes cron | n8n + Hermes |
|---|---|---|
| 数据来源 | Hermes 使用 web search 自行寻找 | n8n 主动抓取指定的 RSS 源 |
| 数据稳定性 | 依赖搜索引擎,结果随机性强 | 固定来源,质量可预期 |
| 可扩展性 | 靠 prompt 描述,边界模糊 | 增加工作流节点即可扩展数据源 |
| 接入非网络数据 | 做不到 | 可以连接数据库、API、本地文件 |
| 实施复杂度 | 低,一条命令即可 | 较高,需要调试数据管道 |
对于纯粹的信息聚合与推送,Hermes cron 更直接,不必引入 n8n。
n8n 的真正价值在于需要对接非公开数据或结构化数据源的场景,那才是这套架构大显身手的地方。
管道解锁:对建筑师的实际意义与场景
这是整个事件中最值得展开的部分。
今晚所做的,表面上是“建筑资讯自动推送”,但本质上,我们打通了一条从任意数据源到 AI 处理,再到任意输出端的柔性管道。
这条管道一旦建立,能接入的数据和能实现的自动化,就远不止于资讯推送。
场景一:项目文件监控
监测项目共享文件夹,一旦有新的图纸或文档上传,自动触发 Hermes 分析变更内容,提取关键信息,实时推送给相关人员。从此再也不用人工盯着文件夹,也不用干等别人通知。
场景二:规范库自动更新提醒
定时抓取住建部、各省厅官网的规范发布页面,新规范或修订版一旦上线,自动提取核心变更点,推送到你的 Telegram 或邮箱。建筑师最怕的就是用了旧版规范,而这条管道可以把这类风险压到最低。
场景三:甲方需求自动归档
接入邮件或企业微信 API,对甲方发来的需求描述进行自动归类、关键信息提取,并写入项目管理系统。不仅大幅减少手动整理的时间,也有效降低了遗漏的可能。
场景四:IFC 模型变更日报
结合 BIM 工作流,每日自动对比 IFC 模型的变化,由 Hermes 生成变更摘要,推送至项目负责人。在多人协作的大型项目中,信息同步的成本极高,自动化日报能显著降低沟通摩擦。
场景五:竞赛信息聚合
抓取多个竞赛信息平台,根据设定条件(类型、奖金、截止时间)进行筛选,每周定时推送。再也不必手动刷站,更不会因为错过报名截止日期而后悔。
更大的图景:AI 不再是孤立的对话框
当前大多数人使用 AI 的方式仍是:打开对话框,输入问题,得到回答,然后关闭。AI 是孤立的,与工作流程深度割裂。
而 n8n + Hermes 这套架构所做的,正是把 AI 嵌入到工作流之中——让 AI 在正确的时间、基于正确的数据、自动完成正确的任务,而不需要人工去触发。
对建筑师而言,这个转变意味着从“我去问 AI”变成了“AI 主动告诉我”。
从被动查询到主动推送,从单次对话到持续运行,从人工触发到事件驱动——这才是 AI 真正融入工作流程的第一步。
今夜那些踩过的坑,全都值得。
技术栈总结
- • n8n:工作流自动化引擎,本地 npm 安装,通过 tmux 维持进程
- • Hermes Agent:AI Agent,以
hermes gateway模式运行,暴露 8642 端口的 OpenAI 兼容 API - • RSS 源:ArchDaily、Dezeen(使用前务必验证可访问性)
- • 推送端:Telegram Bot(独立创建,与 Hermes 自身的 Bot 分离)
- • 运行环境:macOS M1,本地运行
已知局限:电脑重启后需要手动拉起两个进程。要实现生产级的稳定运行,仍须迁移到 VPS 或配置 launchd 实现自动启动。