团队可能花数月争论“Hermes 还是 n8n？”，仿佛必须由一个产品包办所有自动化。两者解决的是不同工作。n8n 是具有丰富集成和确定性控制流的工作流引擎。Hermes Agent 是带记忆、技能与工具的智能体运行时，适合需要解释与判断的任务。真正有用的问题是：这一步需要可靠管道，还是需要判断？
如果你对其中一方还不熟悉，请先阅读《在 n8n 中构建第一个 AI 智能体：端到端的线索分诊工作流》和 Hermes Agent 是什么。如果是在 Zapier、Make 和 n8n 之间选择平台，可参考 n8n、Zapier 与 Make 对比。设计交接方式时，请查阅官方的 Hermes API 服务器文档、Hermes Webhook 文档和 n8n HTTP 请求节点文档。Nous Research 并未提供与旧版第三方集成页面相对应的现成 Hermes 到 n8n 工作流。
不同的工作模式
确定性工作具有已知的流程图：验证 → 通过 API 补充数据 → 写入 CRM → 通知。重试、持久的业务幂等性以及字段映射比文本质量更重要。n8n 或其他工作流引擎正是为此而设计的。
判断工作的中间步骤没有固定答案：阅读杂乱的客户备注、判断严重程度、按团队既定语气起草回复、选择应引用哪份文档。此时记忆与技能很重要，Hermes 正是为这类工作设计的。
混合工作是一种候选模式，适用于同一流程的前后环节是确定性的，而中间又需要范围受限的智能体判断。它在生产环境中的价值必须经过测量，不能想当然。
事件 → n8n 验证 + 持久化幂等性
→ Hermes API 服务器 :8642 + Bearer 认证
→ n8n 验证返回的 schema
→ 经过人工把关后写入
此图只是说明性应用组合，不是经过供应商测试的现成集成。如果所需契约是接收事件，并把结果发送到已配置的日志、GitHub 评论或消息适配器，请使用默认端口 8644 上独立的 Hermes Webhook 适配器，并按事件来源文档采用相应的身份验证方式。
决策框架
根据五个维度对每个候选工作流进行评分。这只是用于规划的启发式方法，不是经过验证的产品选择模型。当左侧特征占主导时，使用 n8n-only；当右侧特征占主导时，使用 Hermes-only；当同一流程同时出现两侧特征时，再评估混合模式。
| 维度 | 偏向 n8n 的特性 | 偏向 Hermes 的特性 |
|---|---|---|
| 路径稳定性 | 每次运行固定步骤 | 分支取决于内容 |
| 集成 | 多个 SaaS 连接器、重试、队列 | 连接器较少；需要 shell/浏览器/技能 |
| 状态 | 每次运行无状态，或由你拥有数据库字段 | 跨会话记忆和流程 |
| 输出 | 结构化 JSON/字段 | 文本、分诊理由、多源综合分析 |
| 误操作的代价 | 高；倾向于显式节点 + 审批 | 发送/写入时同样很高；仍需门控；Hermes 只负责起草 |
快速规则
- 如果流程图里不需要写“取决于文本内容”，就用 n8n。
- 如果关键步骤是阅读杂乱的自然语言并生成一份慎重的草稿，请使用 Hermes（通常在 n8n 验证之后）。
- 如果你需要同时具备 SaaS 管道功能和判断能力，请测试混合方案；不要强迫一种工具去模仿另一种工具。
- 如果你只需要一个由人工复制粘贴的聊天机器人答案，就不要使用工作流平台；直接使用聊天功能。 详见 Hermes Agent 是什么。
应围绕真正的瓶颈购买或自托管合适的工具。为了搬运 CSV 字段而部署智能体运行时是浪费；搭建五十个脆弱的 n8n AI 节点来模拟记忆与技能，同样是浪费。
n8n 应负责什么
以下职责应留在 n8n 中（相关模式可参见《在 n8n 中构建你的第一个 AI 智能体：端到端的线索分诊工作流》）：
- Webhook 接收和 schema 验证
- 幂等性和去重
- 访问 CRM、帮助台、表格和 Slack 时的身份验证
- 速率限制、重试、错误分支
- 在枚举值和评分上进行显式的 if/switch 路由
- 保留的工作流执行记录，以及显式的写入确认和关联 ID
- 紧急停用开关和环境标志
n8n 可以通过 AI Agent 节点处理轻量判断；当工具受控、JSON 契约清晰时，这种方式仍然有效。如果需要持久记忆、技能库、消息网关体验，或 n8n 节点图之外更复杂的工具使用，再评估 Hermes。
Hermes 可能适合承担什么
Hermes 的候选职责包括：
- 以技能形式编码的流程（可重复的运维、支持和发布检查清单）
- 通过记忆保存团队偏好和持久项目事实，并采用《Hermes Agent 第一周：记忆管理、技能与工具审批》中说明的管理规范和写入控制
- 模糊分类和起草，结合工具辅助的查找
- 直接在现有渠道中操作的体验（根据你的配置使用 CLI、Telegram、Discord 或 Slack 网关）
- 通过已配置交付目标的命名 Webhook 路由开展事件驱动调查（《Hermes Webhook：无需巨型万能提示的事件驱动智能体》）
当智能体需要执行产生确定性副作用的操作时，Hermes 可以通过显式配置的工具、技能或 MCP 服务器调用经过身份验证的 n8n webhook。这是自定义应用行为，必须拥有自己的身份验证、schema、超时和幂等性契约；它不是原生 Hermes Webhook 的交付目标。优先使用专用工具，不要把 Hermes 当作集成总线。
可测试的一种混合模式
当 n8n 必须在同一工作流中取得智能体结果时，已核实的自定义端点路径是由 HTTP 请求节点调用使用 Bearer 认证的 Hermes API 服务器。使用 /v1/responses 进行面向响应的调用；使用 /v1/runs 进行异步运行时，n8n 再轮询或观察结果。API 接受 Idempotency-Key，但响应缓存只保留五分钟，因此 n8n 或业务系统仍需负责持久幂等性。Webhook 适配器另会缓存交付 ID 一小时；有效的重试去重需要稳定的 X-GitHub-Delivery 或 X-Request-ID，这个有界缓存同样不能替代持久的业务幂等性。
参考流程：私有支持分诊
- 工单/表单 webhook → n8n
- n8n 验证电子邮件、长度、来源枚举；过滤垃圾邮件；附加
ticket_id - n8n HTTP 请求 → 在
:8642上的 Hermes API 服务器，使用Authorization: Bearer <API_SERVER_KEY>和一个应用级关联 ID - Hermes 技能：分类严重性，起草回复，列出缺失信息；工具仅对已批准的来源进行只读操作
- n8n 接收或轮询结果，验证版本化的响应 schema，并将格式错误或超时的输出路由到人工审核
- 人工批准后，n8n 负责写入帮助台或 CRM，并发送客户回复
在初始版本中，不要从 Hermes 自动发送客户电子邮件。最终发送应由 n8n 在审批后执行，遵循与线索分诊文章相同的防护规则。
只要条件允许，就先在 n8n 中删减负载，再交给 Hermes。智能体只能看到分诊所必需的最少字段。客户机密信息和支付信息绝不能进入智能体记忆。
方向选择
| 方向 | 使用场景 | 机制 |
|---|---|---|
| n8n → Hermes API | n8n 需要取回智能体结果 | 向 :8642 发送 HTTP 请求，使用 Bearer 认证，/v1/responses 或 /v1/runs |
| 源 → Hermes 事件 | 运行结果应交付到另一个目标 | 在 :8644 上使用命名路由、与来源相匹配的认证方式和已配置的交付目标 |
| Hermes → n8n | 智能体需要确定性的 n8n 操作 | 带有 schema 和幂等性的自定义认证 n8n webhook/工具 |
| Hermes MCP ↔ n8n | 智能体必须检查或操作 n8n 工作流 | 经 Nous 审核的目录条目，通过最小工具集显式安装 |
你不需要同时使用 MCP 和 Webhook。官方的 Hermes MCP 文档列出了用于检查和管理 n8n 工作流的 hermes mcp install n8n。安装前该功能处于禁用状态；安装会执行目录清单和服务器代码，因此只应暴露你已审查的工具。MCP 管理、API 请求/响应和 Webhook 事件入站是三种不同的契约。
对比表（操作者视角）
| 关心点 | n8n | Hermes Agent |
|---|---|---|
| 主要职责 | 工作流自动化 | 智能体运行时 |
| 优势 | 连接器、重试、可视化流程和调试记录 | 记忆、技能、工具、网关用户界面 |
| 典型触发器 | Webhooks、计划任务、应用事件 | 聊天、定时任务、webhooks |
| 最佳输出 | 可靠的副作用 | 经分析的草稿和调查结果 |
| 滥用的主要风险 | 大规模写错而不易察觉 | 工具范围过广 + 提示注入 |
| 候选私有拓扑 | 通过 LAN/VPN 工作流调用私有 HTTP API | 将 Hermes 指向一个经过测试的私有 OpenAI 兼容 URL |
两列都不是“更 AI”。它们是不同层。
反模式
- 把 Hermes 当作 Zapier： 解析每个 SaaS 事件，并通过临时工具调用写入每个字段。这只是在低质量地重新发明重试机制。
- 把 n8n 当作长期记忆： 把个性和流程塞进 AI 节点的巨型系统提示。应使用 Hermes 技能与记忆，或通过外部文档存储进行有计划的检索。
- 双写： 两个系统在没有所有权规则时共同更新 CRM。请选择一个写入者。
- 单一共享万能路由： 让一个 webhook 同时处理计费、HR 和 GitHub。请拆分路由。
- 未经审查的社区技能加上生产环境n8n凭证： 在双方都应用最小权限原则。
用 JSON 定义版本化的请求和响应契约，例如
ticket_id、text、severity_hint和correlation_id，并在两端验证。只有自定义工具或应用实现了callback_url，该字段才有意义；Hermes Webhook 适配器不会解释它。在 n8n 执行数据和应用日志中保留关联 ID，并在把这些记录称为审计记录之前验证其覆盖范围。
练习：为四个真实工作流选所有者
选取本季度想实现的四项自动化。对每项填写：
- 触发来源
- 确定性步骤（列表）
- 判断步骤（列表）
- 所有者：n8n / Hermes / 混合
- 人工审批在哪里
- “完成”用一句话是什么意思
示例行： 「收到合作伙伴线索」→ 确定性步骤：校验、去重、在 CRM 中创建记录 → 判断步骤：说明匹配度、起草介绍文字 → 混合 → 发邮件前审批 → 当 CRM 记录已经存在且草稿进入审核时，即算完成。
如果四项全是混合模式，先端到端构建一个最小纵向闭环，再添加渠道和 MCP。如果四项全是 n8n 专用，请推迟 Hermes。如果四项全是 Hermes 专用且没有集成，你可能是在构建个人操作助手；这可以是合理选择，但不要称其为自动化平台的替代品。
建议的测试顺序
- 使用存根（不使用LLM）稳定n8n的验证和日志路径。
- 添加一个通过 Bearer 认证的 Hermes API 调用，包含仅限起草的技能、超时处理、持久工作流幂等性以及响应 schema 验证。
- 将 Hermes 生成的草稿与人工基准比较，并针对固定样本测试。二十个不同类型的工单可作为实用的冒烟测试，或许能暴露明显故障，但不足以确定生产环境错误率。
- 通过n8n审批控制写入操作。
- 只有完成前述步骤后，才增加更丰富的 Hermes 记忆、更多技能和消息网关。
延伸阅读
- 在 n8n 中构建你的第一个 AI 智能体：端到端的线索分诊工作流
- n8n、Zapier 与 Make 对比
- Hermes Agent 是什么
- Hermes Agent 第一周：记忆管理、技能与工具审批
- Hermes Webhook：无需巨型万能提示的事件驱动智能体
- 人在回路中的设计模式
- Hermes API 服务器
- Hermes Webhook 适配器
- Hermes MCP
- n8n HTTP 请求节点
- n8n 文档
根据眼前的具体任务选择工具，然后测试实际的集成契约。管道和判断都可能必要，但 API 请求/响应、Webhook 事件交付和 MCP 工作流管理不可互换。
