最新分支启动时未指定langgraph service

[coderw184]

如题

[willem-bd]

回答：最新分支不再需要单独的 LangGraph 服务

这是正常的设计变更，不是问题。在当前的架构中，DeerFlow 已经将 LangGraph agent 运行时嵌入到了 Gateway 进程中，不再运行独立的 LangGraph Server。

架构变化

组件	说明
Gateway (端口 8001)	同时提供 REST API 和 LangGraph 兼容的 agent 运行时
Frontend (端口 3000)	Next.js 前端
Nginx (端口 2026)	统一反向代理入口

关键证据

1. Gateway 内嵌运行时：app/gateway/app.py 在 lifespan 中通过 langgraph_runtime(app, startup_config) 启动 agent 运行时，无需独立进程。

2. Nginx 路由重写：nginx 配置中有专门的 location /api/langgraph/ 块，将 /api/langgraph/* 重写为 /api/* 后代理到 Gateway。/api/langgraph 前缀保留是为了向前端 LangGraph SDK 客户端提供向后兼容，但实际都由同一个 Gateway 进程提供服务。

3. 前端默认走代理路径：frontend/next.config.js 仅在 NEXT_PUBLIC_LANGGRAPH_BASE_URL 未设置时才配置 /api/langgraph 的 rewrites。在 make dev 模式下，前端通过 nginx（或直接通过 Gateway）访问，.env 文件中 NEXT_PUBLIC_LANGGRAPH_BASE_URL 默认被注释掉。

4. Docker Compose 没有 LangGraph 服务：docker-compose-dev.yaml 只定义了 nginx、frontend、gateway 和可选的 provisioner，没有独立的 LangGraph 服务。

5. make dev 只启动 3 个服务：Gateway (8001) + Frontend (3000) + Nginx (2026)。Gateway 同时处理自己的 REST API 和 LangGraph 兼容的 agent 运行时。

总结

你观察到的"未指定 langgraph service"是正确的行为——DeerFlow 将原本独立的 LangGraph Server 合并到了 Gateway 进程中，简化了部署架构。

如果你之前有单独配置 LangGraph Server 的旧配置，可以直接忽略，当前版本不需要它。