见过太多多Agent系统的通病：Agent本身够聪明，但连接它们的代码没人愿意维护。HTTP调用散落在各处，重试逻辑东一块西一块，错误处理不过是console.log的豪华版。我建的VORTEX系统完全用n8n实现——没有胶水代码，没有自定义编排层，没有消息队列。Agent之间的连接只是工作流图里声明的webhook调用，故障处理是白送的。
为什么选n8n做Agent编排
另一个选择是用代码写编排层——Node.js服务接收webhook事件，调用Groq，写入Firestore，触发下游Agent。我做过原型，400行代码，立刻变成谁都不想碰的东西。
问题清单：
• Groq API调用的重试逻辑得手写
• 加个下游步骤要改编排器重新部署
• 流水线到底在干嘛，没有可视化呈现
• 调试失败得读日志，而不是看图
n8n全解决了。每个Agent是一个工作流，每个工作流是一张节点图。加步骤就是拖个节点到画布上连起来。重试是HTTP节点上的一个勾选框。整个流程不用打开文件就能看见。
Agent的结构
7个Agent遵循同一套模式：
• 触发节点——Webhook节点（Agent 1、2、3、7）或Schedule节点（Agent 4、5、6）
• 处理节点——Code节点做数据转换，HTTP Request节点调外部API
• 输出节点——Firestore写入、Respond to Webhook节点，或两者都有
Agent 1（Behavioral Scout）最简单也最重要，所有数据都经过它：
Webhook Trigger
Normalize Activity Atom（Code节点）
Write to Firestore（HTTP Request → Firestore REST API）
Respond to Webhook（200 OK + atom_id）
Code节点做归一化：提取user_id、event_type、feature、session_mins等字段，补默认值，生成ISO时间戳。归一化后，Agent 1同步触发Agent 7的webhook并等待响应，然后才返回。Agent 7负责所有下游路由。
Agent 7——路由中枢
Agent 7是系统里最复杂的工作流，也是唯一会调用其他Agent的。
Webhook Trigger（来自Agent 1）
Decision Logic（Code节点）
├─ HOT_LEAD ──→ Call Agent 2（HTTP Request）
（原文截断，后续内容未提供）
热门跟贴