路由层选型与事件驱动设计

从 route-agent.py 到 n8n 到 Dify 到 LangGraph 的技术路径 2026-05-28 ~ 2026-06-08

---

起点：route-agent.py

最早的路由层是一个自建 Python HTTP 服务：

route-agent.py（端口 8765）
  ├── /register — Agent 注册（HWND + session）
  ├── /event    — 接收 commit 事件 → 决策 → 注入
  └── /status   — 查询工作间状态

问题：

• Python 脚本，改逻辑要改代码
• 没有可视化界面
• 状态管理靠内存（重启丢失）
• 功能单一，往复杂走要加很多端点

---

第一站：n8n

git commit → post-commit hook
  → curl POST n8n webhook
    → n8n Code 节点解析 payload
      → 条件分支（REVIEW-PASS / REVIEW-FAIL）
        → Code 节点调 inject 脚本

n8n 的优势：

• Webhook 节点原生支持 HTTP 接收
• Code 节点内写 JavaScript / Python
• 条件分支可视化
• 自带日志和重试

实际 n8n 搭建成果：

• 两个原子节点工作流：fn_launch_claude + fn_send_to_window
• 模板化：launch_agent.json + send_to_window.json
• 全链路验证通过：commit → webhook → Code 节点 → inject → agent 窗口收到

遇到的问题：

• Windows 上的 ExecuteCommand 节点阻塞子进程 — 改用 Code 节点 + execSync
• n8n 在 Docker 里无法直接访问宿主机窗口 — 需要 host.docker.internal 桥接
• 汉化包版本必须精确匹配 n8n 版本（2.23.4）

---

第二站：Dify 评估

提出用 Dify 原因：

• 可视化编排（比 n8n 更直观）
• 内置 LLM 节点（不需要外挂 Hermes）
• 自带日志和状态追踪

否决原因：

• Dify 也在 Docker 里，同样面临跨网络问题
• 需要 host.docker.internal 桥接
• LLM 节点用不上（路由逻辑不是 LLM 决策）
• 多了一层 Docker，没有解决 n8n 解决不了的问题

---

第三站：LangGraph 评估

优势：

• 本地 Python 进程，不需要 Docker 网络
• 直接调文件 API、注入脚本
• graph_state 天然适合状态追踪
• 条件边 = 路由决策

否决原因：

• 纯代码，没有可视化界面
• 跟 route-agent.py 本质是同一类东西（Python 脚本）
• n8n 已经验证了 Webhook 链路可用
• 路由层不值得再用一个框架

---

最终形态：n8n

回到 n8n，但去掉 Windows 注入层：

n8n（Windows 路由层）
  ↓ Webhook 接收 commit 事件
  ↓ Code 节点解析 payload
  ↓ 条件分支路由
  ↓ wsl tmux send-keys 注入

三层分离

层	位置	职责	技术选型
路由层	n8n	事件接收、解析、决策、注入	n8n Webhook + Code
会话层	WSL	Agent 持久化、命令注入	tmux
协议层	文件系统	共享状态、行为规范	STATUS.md + SKILL.md

---

事件链路总图

Agent（写完）
  ↓ 追加 STATUS.md
  ↓ git add && git commit -m "[CC-WSxxx] ..."
  ↓ post-commit hook
  ↓ notify-agent.sh（curl POST）
n8n webhook（http://localhost:5679/webhook/agent-loop）
  ↓ Code 节点解析 payload 获取 author/message
  ↓ 条件分支：
    ├─ REVIEW-PASS → notify Hermes → 标记完成
    ├─ CC commit → tmux send-keys -t codex "/review-ws"
    └─ Codex REVIEW-FAIL → tmux send-keys -t cc "/fix-ws"
  ↓
Agent 窗口收到指令 → 读 STATUS.md → 继续循环

---

选型对比总结

方案	可视化	跨 Docker	注入能力	最终
route-agent.py	❌	✅ 原生	✅	❌ 被替代
n8n	✅	❌ 需要桥接	✅（Code 节点）	✅ 最终选型
Dify	✅	❌ 需要桥接	✅	❌ 多余层
LangGraph	❌	✅ 原生	✅	❌ 跟 route-agent 同级

---

经验

1. 别用框架解决路由问题 — 路由就是一个条件分支 + inject，n8n 够用了
2. 三层分离才能解耦 — 路由层、会话层、协议层各自可独立替换
3. 可视化不是必须的，但 debug 时很香 — n8n 的执行日志比 Python print 强多了