DeerFlow Smoke Test Report【免费下载链接】deer-flowAn open-source long-horizon SuperAgent harness that researches, codes, and creates. With the help of sandboxes, memories, tools, skill, subagents and message gateway, it handles different levels of tasks that could take minutes to hours.项目地址: https://gitcode.com/GitHub_Trending/de/deer-flowTest Date: {{test_date}}Test Environment: {{test_environment}}Deployment Mode: LocalTest Version: {{git_commit}}注意 Deployment Mode 在本地模板中硬编码为 Local——这是与 [Docker 版模板](https://link.gitcode.com/i/eac0d62141852a2610097f4c51865136) 的第一个区分点两者按部署模式二选一使用不能混用。 执行摘要表Execution Summary要求给出阶段级统计 markdown | Metric | Status | |------|------| | Total Test Phases | 6 | | Passed Phases | {{passed_stages}} | | Failed Phases | {{failed_stages}} | | Overall Conclusion | **{{overall_status}}** |其下的「Key Test Cases」表把 6 个阶段压缩为 6 行用例级结论每行都要求同时给出Result与Details两列即不能只写 Pass/Fail 而不写原因Case对应占位变量含义Code update check{{case_code_update}}/{{case_code_update_details}}代码是否成功更新到最新Environment check{{case_env_check}}/{{case_env_check_details}}本地依赖与端口检查Configuration preparation{{case_config_prep}}/{{case_config_prep_details}}config.yaml 与 .env 准备Deployment{{case_deploy}}/{{case_deploy_details}}make check/install/启动Health check{{case_health_check}}/{{case_health_check_details}}进程、端点、LangGraph APIFrontend routes{{case_frontend_routes_overall}}/{{case_frontend_routes_details}}/workspace/*路由冒烟六个阶段的结构与检查项模板的「Detailed Test Results」部分按阶段展开每个阶段用固定 checklist 条目 一个Phase Status结论。以下按模板顺序完整梳理各阶段条目、对应变量以及这些条目在脚本/Makefile 中的真实落点。Phase 1代码更新检查模板固定 4 个条目- [x] Confirm current directory - {{status_dir_check}} - [x] Check Git status - {{status_git_status}} - [x] Pull latest code - {{status_git_pull}} - [x] Confirm code update - {{status_git_verify}}对应 SOP.md Phase 1 的操作细节先用pwd确认当前目录是项目根目录应包含Makefile、backend/、frontend/、config.example.yaml再git status检查未提交变更然后git fetch origin maingit pull origin main最后git log -1 --oneline记录最新 commit 哈希与提交信息——这两项记录会填入模板 Environment Information 中的{{git_branch}}、{{git_commit}}、{{git_commit_message}}。Phase 2本地环境检查本地模板的 Phase 2 固定 5 个条目Docker 模板则为 Docker version/daemon/Compose 三项与 check_local_env.sh 的检查逻辑一一对应- [x] Node.js version - {{status_node_version}} - [x] pnpm - {{status_pnpm}} - [x] uv - {{status_uv}} - [x] nginx - {{status_nginx}} - [x] Port check - {{status_port_check}}脚本中的判定标准即这些变量的取值依据Node.jsnode --version主版本号必须 22脚本会打印version: x.x.x并要求 22pnpmpnpm --version能返回版本信息未安装时提示npm install -g pnpmuvuv --version能返回版本信息nginxnginx -v能返回版本信息macOS 建议brew install nginxLinux 用系统包管理器端口脚本要求lsof存在并对2026主端口、3000前端、8001Gateway三个端口逐一检查任一被占用即标记失败。这三个端口的分工与 health_check.sh 中check_listen_port的本地模式检查完全一致Nginx 监听 2026、Frontend 监听 3000、Gateway 监听 8001。Phase 3配置准备- [x] config.yaml - {{status_config_yaml}} - [x] .env file - {{status_env_file}} - [x] Model configuration - {{status_model_config}}SOP 对这一步的规定config.yaml不存在时执行make config生成已存在时考虑make config-upgrade合并新字段.env不存在时从.env.example复制模型配置要验证至少配置了一个模型、且模型引用了正确的环境变量如OPENAI_API_KEY。仓库根目录的 config.example.yaml 提供了配置样例Makefile 中确实存在config:与config-upgrade:目标第 79、82 行起。Phase 4本地部署本地模板的 Phase 4 有 4 个条目对应 deploy_local.sh 的执行顺序- [x] make check - {{status_make_check}} - [x] make install - {{status_make_install}} - [x] make dev-daemon / make dev - {{status_local_start}} - [x] Service startup wait - {{status_wait_startup}}deploy_local.sh的实际行为可以作为报告证据先确认config.yaml不存在则make config并提示配置模型与 API key 后重跑再确认.env不存在则从.env.example复制随后依次执行make check校验 Node.js 22、pnpm、uv、nginx、make install安装前后端依赖、make dev-daemon后台启动 Gateway 内嵌运行时、Frontend、Nginx最后提示等待 90–120 秒并给出三个日志路径logs/gateway.log、logs/frontend.log、logs/nginx.log。仓库 Makefile 中check、install、dev、dev-daemon、stop、clean、setup-sandbox、docker-init、up等目标均可在文件中检索到说明模板引用的每条命令都是真实可执行的 Make 目标。需要说明的差异模板条目写的是make dev-daemon / make dev而 SOP 建议本地部署用make dev-daemon后台make dev为前台运行、CtrlC 即停两者二选一记录在{{status_local_start}}中即可。Phase 5服务健康检查- [x] Process status - {{status_processes}} - [x] Frontend service - {{status_frontend}} - [x] API Gateway - {{status_api_gateway}} - [x] LangGraph-compatible Gateway API - {{status_langgraph}}对照 health_check.sh这些条目的判定方式进程/端口状态本地模式下脚本用lsof -nP -iTCP:port -sTCP:LISTEN检查 2026/3000/8001 三个端口是否处于 LISTENSOP 也给出进程级检查命令ps aux | grep -E (uvicorn|next|nginx) | grep -v grep期望存在 Gatewayuvicorn app.gateway.app:app、Frontendnext dev/next start、Nginx 三类进程前端服务curl -I http://localhost:2026期望 200脚本允许200|301|302|307|308API Gatewaycurl http://localhost:2026/health需返回非空的健康状态 JSONLangGraph 兼容 API访问http://localhost:2026/api/langgraph/assistants/lead_agent脚本接受200|401——当认证已启用且未带会话 cookie 时401属于可接受结果见下文「已知的可接受告警」。脚本还内置了模式自动探测SMOKE_TEST_MODE未显式指定时若docker ps中存在名字含deer-flow的容器则按 docker 模式检查容器状态否则按本地端口模式检查——这保证了同一健康检查脚本在两种部署模式下都能复用。前端路由冒烟结果表Frontend Routes Smoke Results这是本地模板中最具「报告显式性」要求的一块模板要求逐路由列出结果| Route | Status | Details | |-------|--------|---------| | Landing / | {{landing_status}} | {{landing_details}} | | Workspace redirect /workspace | {{workspace_redirect_status}} | target {{workspace_redirect_target}} | | New chat /workspace/chats/new | {{new_chat_status}} | {{new_chat_details}} | | Chats list /workspace/chats | {{chats_list_status}} | {{chats_list_details}} | | Agents gallery /workspace/agents | {{agents_gallery_status}} | {{agents_gallery_details}} | | Docs {{docs_path}} | {{docs_status}} | {{docs_details}} | **Summary**: {{frontend_routes_summary}}这张表的数据来源是 frontend_check.sh脚本的探测逻辑与表格行一一对应Landing /期望 200Workspace redirect /workspace期望 200 或 301/302/307/308 之一且跟随重定向后最终 URL 必须落在/workspace/chats/check_final_url用curl -w %{url_effective} -L实现/workspace/chats/new、/workspace/chats、/workspace/agents期望 200且最终 URL 保持在/workspace/前缀下即没有被重定向到登录页Docs 路由路径由DOC_PATH环境变量控制默认/en/docs期望 200 或 404文档路由属可选项所有检查可用BASE_URL覆盖默认http://localhost:2026。脚本还有一个与模板强相关的认证处理细节当 Gateway 启用认证DEER_FLOW_AUTH_DISABLED ! 1时/api/models返回 401脚本会先用smoke-testdeerflow.dev默认密码SmokeTest123!可用SMOKE_TEST_EMAIL/SMOKE_TEST_PASSWORD覆盖注册或登录一个冒烟测试用户把 session cookie 传给后续所有 curl 调用从而验证的是真实的/workspace/*页面而不是登录重定向具体分支为——/api/v1/auth/setup-status显示needs_setup: true时先走/api/v1/auth/initialize初始化管理员否则尝试/api/v1/auth/register201 即注册成功并自动登录注册失败用户已存在则清 cookie 后走/api/v1/auth/login/local最后用/api/v1/auth/me返回 200 验证会话有效性。这也解释了 SKILL.md 中「已知可接受告警」里为什么会出现来自 auth provider 的注册日志——那是预期行为不阻塞测试通过。脚本退出码即冒烟结论全部通过时打印✅ Frontend smoke checks passed!并exit 0任一失败则exit 1。报告中的{{frontend_routes_summary}}就应概括该结论。Phase 6测试报告生成- [x] Result summary - {{status_summary}} - [x] Issue log - {{status_issues}} - [x] Report generation - {{status_report}}对应 SOP Phase 6 的四步汇总各阶段执行状态 → 记录失败项的错误详情 → 用模板生成完整报告 → 给出后续建议。模板剩余区块问题日志、环境信息与服务状态模板尾部还有四个区块是报告「可追溯性」的来源Issue Log无问题时可注明无### Issue 1 **Description**: {{issue1_description}} **Severity**: {{issue1_severity}} **Solution**: {{issue1_solution}}Environment Information本地依赖版本原文、Git 信息、配置摘要Node.js: {{node_version_output}} pnpm: {{pnpm_version_output}} uv: {{uv_version_output}} nginx: {{nginx_version_output}} Repository: {{git_repo}} Branch: {{git_branch}} Commit: {{git_commit}} Commit Message: {{git_commit_message}}- config.yaml exists: {{config_exists}} - .env file exists: {{env_exists}} - Number of configured models: {{model_count}}Local Service Status这是本地模板与 Docker 模板的第二个结构差异本地版记录 Nginx/Frontend/Gateway 及其端点Docker 版记录deer-flow-nginx/deer-flow-frontend/deer-flow-gateway三个容器的运行状态与 Uptime| Service | Status | Endpoint | |---------|--------|----------| | Nginx | {{nginx_status}} | {{nginx_endpoint}} | | Frontend | {{frontend_status}} | {{frontend_endpoint}} | | Gateway | {{gateway_status}} | {{gateway_endpoint}} | | Gateway LangGraph API | {{langgraph_status}} | {{langgraph_endpoint}} |【免费下载链接】deer-flowAn open-source long-horizon SuperAgent harness that researches, codes, and creates. With the help of sandboxes, memories, tools, skill, subagents and message gateway, it handles different levels of tasks that could take minutes to hours.项目地址: https://gitcode.com/GitHub_Trending/de/deer-flow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考