企业官网建设流程全解析

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-flow

Test 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 而不写原因：

六个阶段的结构与检查项

模板的「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 main+git 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.js：node --version主版本号必须>= 22，脚本会打印version: x.x.x并要求 22+；
• pnpm：pnpm --version能返回版本信息，未安装时提示npm install -g pnpm；
• uv：uv --version能返回版本信息；
• nginx：nginx -v能返回版本信息，macOS 建议brew install nginx，Linux 用系统包管理器；
• 端口：脚本要求lsof存在，并对2026（主端口）、3000（前端）、8001（Gateway）三个端口逐一检查，任一被占用即标记失败。

这三个端口的分工与 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为前台运行、Ctrl+C 即停；两者二选一记录在{{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，这些条目的判定方式：

1. 进程/端口状态：本地模式下脚本用lsof -nP -iTCP:<port> -sTCP:LISTEN检查 2026/3000/8001 三个端口是否处于 LISTEN；SOP 也给出进程级检查命令ps aux | grep -E "(uvicorn|next|nginx)" | grep -v grep，期望存在 Gateway（uvicorn app.gateway.app:app）、Frontend（next dev/next start）、Nginx 三类进程；
2. 前端服务：curl -I http://localhost:2026，期望 200（脚本允许200|301|302|307|308）；
3. API Gateway：curl http://localhost:2026/health需返回非空的健康状态 JSON；
4. LangGraph 兼容 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 /：期望 200；
• Workspace 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-test@deerflow.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/register（201 即注册成功并自动登录），注册失败（用户已存在）则清 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