路由层选型与事件驱动设计从 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 脚本改逻辑要改代码没有可视化界面状态管理靠内存重启丢失功能单一往复杂走要加很多端点第一站n8ngit 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_claudefn_send_to_window模板化launch_agent.jsonsend_to_window.json全链路验证通过commit → webhook → Code 节点 → inject → agent 窗口收到遇到的问题Windows 上的 ExecuteCommand 节点阻塞子进程 — 改用 Code 节点 execSyncn8n 在 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 注入层n8nWindows 路由层 ↓ Webhook 接收 commit 事件 ↓ Code 节点解析 payload ↓ 条件分支路由 ↓ wsl tmux send-keys 注入三层分离层位置职责技术选型路由层n8n事件接收、解析、决策、注入n8n Webhook Code会话层WSLAgent 持久化、命令注入tmux协议层文件系统共享状态、行为规范STATUS.md SKILL.md事件链路总图Agent写完 ↓ 追加 STATUS.md ↓ git add git commit -m [CC-WSxxx] ... ↓ post-commit hook ↓ notify-agent.shcurl POST n8n webhookhttp://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 同级经验别用框架解决路由问题— 路由就是一个条件分支 injectn8n 够用了三层分离才能解耦— 路由层、会话层、协议层各自可独立替换可视化不是必须的但 debug 时很香— n8n 的执行日志比 Python print 强多了