凌晨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。
教训：任何"先确保你已经……"的步骤，都要展开细看，不能假设对方和你的环境一样。
第二个坑：n8n 的 Function 节点已经废弃
方案文档里的 n8n 工作流 JSON，用的是 n8n-nodes-base.function 这个节点类型。
现在的 n8n（v0.198.0 以后）已经用 Code 节点取代了 Function 节点。导入旧的 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 节点里，把整个请求 Body 用 JSON.stringify() 打包成一个字符串，作为一个字段传给下游节点。HTTP Request 节点拿到的是一个合法的 JSON 字符串，直接使用，绕过了动态拼接的问题。
这个方案的代价是多了一步处理，但换来了稳定性。
第四个坑：RSS 源的可访问性
ArchDaily 的主 RSS 源在国内直接访问会 502。参数化建筑网站的 SSL 证书有问题，会报 TLS 握手错误。
最终保留了两个稳定可用的源：ArchDaily（通过备用地址）和 Dezeen。
建议：在正式部署之前，先用 curl 逐一测试每个 RSS URL 的可访问性，不要假设国外网站都能用。
第五个坑：n8n 本地运行的持久化问题
n8n 通过 npm 安装后，直接运行 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。
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 自动启动。