1. DeerFlow 2.0 是什么为什么 Windows 用户必须用 Docker Desktop 部署它DeerFlow 2.0 不是又一个“AI聊天框”它是字节跳动开源的长周期超级智能体运行时SuperAgent Harness——一个能真正“动手做事”的操作系统级AI工作流引擎。它不满足于生成文字而是能自动创建文件、执行代码、调用工具链、启动子智能体、管理沙箱环境、持久化长期记忆并最终交付一份完整的报告、一个可运行的网页或一套分析图表。这种能力层级已经越过了传统LLM应用的边界进入了“AI数字员工”的范畴。而 Windows 用户选择 Docker Desktop 部署 DeerFlow 2.0并非权宜之计而是由其底层架构决定的刚性需求。DeerFlow 2.0 的核心设计哲学是“沙箱即第一公民”。它的每一个任务——无论是运行一段Python脚本分析CSV数据还是调用Stable Diffusion生成图像抑或是启动一个临时的Web服务预览结果——都默认在一个隔离、可控、可销毁的容器环境中执行。这个沙箱不是可选项而是安全模型与功能完备性的基石。在 Windows 上原生进程隔离无法提供 Linux 容器级别的资源控制、网络隔离和文件系统快照能力。Docker Desktop 通过 WSL2Windows Subsystem for Linux 2为 DeerFlow 提供了一个轻量、高效、与 Linux 生态完全兼容的运行底座。它让 DeerFlow 能像在一台真正的 Linux 服务器上一样精确地拉取、构建、启动和管理数十个相互依赖的服务组件前端网关Gateway、后端推理服务Backend、内存数据库Redis、向量存储Qdrant、沙箱执行器AioSandbox以及可选的 LangSmith 追踪服务。这解释了为什么网络上大量用户会遇到virtualization support not detected的报错。这不是 DeerFlow 的 Bug而是 Windows 系统层面对虚拟化支持的“信任状”缺失。Docker Desktop 启动失败本质上是 DeerFlow 的整个执行引擎被卡在了起跑线上。你看到的是一条错误提示背后却是一个完整的、需要 CPU 硬件虚拟化Intel VT-x / AMD-V、BIOS 中启用、Windows 功能WSL2、虚拟机平台三重确认的“信任链”。跳过 Docker Desktop试图用纯 Python 或 Node.js 在 Windows 命令行里直接make dev你会立刻撞上一堵墙bash脚本无法执行PowerShell 和 cmd.exe 不兼容、uv包管理器在 Windows 上行为异常、沙箱模式根本无法初始化。GitHub 仓库的官方文档明确写着“On Windows, run the local development flow from Git Bash. Native cmd.exe and PowerShell shells are not supported for the bash-based service scripts, and WSL is not guaranteed because some scripts rely on Git for Windows utilities such as cygpath.” 这句话的潜台词是DeerFlow 2.0 的开发者团队从第一天起就把 Windows 视为一个需要“翻译层”的异构平台而 Docker Desktop WSL2 就是那个最成熟、最可靠的翻译官。所以当你搜索“Windows Docker desktop Deerflow2.0”时你寻找的不是一个安装教程而是一份通往 AI 自动化生产力的“准入许可证”。它解决的不是“能不能跑”的问题而是“能不能安全、稳定、完整地发挥 DeerFlow 全部威力”的问题。那些抱怨“Docker Desktop 太重”、“WSL2 占用太多磁盘”的用户往往在部署完成后的第三天就因为一次make docker-start的成功执行而彻底改变了对本地 AI 工作流的认知——原来让 AI 真正替你写代码、查资料、做分析第一步不是调 API而是先给它配好一个“数字工位”。2. 从零开始Windows 环境的硬性准备与 Docker Desktop 的精准配置在 Windows 上部署任何基于容器的现代 AI 应用第一步永远不是下载软件而是对你的硬件和系统进行一次“可信度审计”。DeerFlow 2.0 对底层环境的要求极为苛刻任何环节的疏忽都会导致后续所有努力付诸东流。我见过太多用户卡在第一步反复重装 Docker Desktop 十几次最后发现根源在于 BIOS 里一个被遗忘的开关。2.1 硬件与 BIOS 层开启虚拟化的“物理钥匙”DeerFlow 2.0 的沙箱执行依赖于 WSL2而 WSL2 的核心是 Hyper-V 虚拟化技术。这意味着你的 CPU 必须支持并启用硬件虚拟化。对于绝大多数 2018 年之后的 Intel 和 AMD 处理器这通常是默认开启的但并非绝对。你需要亲自验证检查 Windows 功能状态以管理员身份打开 PowerShell运行Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform如果输出显示State : Disabled说明系统功能未启用需要手动开启。运行以下两条命令并重启dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart进入 BIOS/UEFI 设置这是最关键的一步也是最容易被忽略的。重启电脑在启动画面出现时狂按F2、Del、F10或Esc具体按键因主板品牌而异通常在屏幕角落有提示。进入 BIOS 后寻找名为Intel Virtualization TechnologyIntel CPU或SVM ModeAMD CPU的选项。它可能位于AdvancedCPU Configuration、SecuritySystem Security或Configuration标签下。务必将其设置为Enabled。保存设置并退出通常是F10。提示如果你的 BIOS 里找不到这个选项或者它被灰色禁用那很可能是因为你的 CPU 型号过于老旧如 Intel 第一代酷睿或更早或者你的笔记本厂商出于“节能”考虑锁死了该功能。此时DeerFlow 2.0 在你的机器上将无法以 Docker 方式运行建议更换硬件。2.2 WSL2 的安装与内核更新构建 Linux 的“地基”Docker Desktop 依赖 WSL2但 Windows 自带的 WSL 版本往往过旧。我们必须手动安装最新版 WSL2 内核这是保证 DeerFlow 沙箱稳定运行的底层保障。下载并安装 WSL2 内核更新包访问微软官方页面 https://aka.ms/wsl2kernel 下载wsl_update_x64.msi文件并双击安装。这是一个静默安装过程无需任何操作。设置 WSL2 为默认版本在管理员 PowerShell 中运行wsl --set-default-version 2安装一个 Linux 发行版推荐 Ubuntu 22.04 LTS它与 DeerFlow 的 Python 依赖兼容性最佳。打开 Microsoft Store搜索 “Ubuntu 22.04”点击“获取”。安装完成后首次启动会要求你创建一个 Linux 用户名和密码。请牢记这个账户将用于后续所有 WSL2 内的操作。验证 WSL2 状态在 PowerShell 中运行wsl -l -v你应该看到类似如下的输出NAME STATE VERSION * Ubuntu-22.04 Running 2VERSION列显示2且STATE为Running即表示 WSL2 已就绪。2.3 Docker Desktop 的安装与关键配置不只是点下一步Docker Desktop 的安装向导非常友好但其默认配置对 DeerFlow 来说几乎是“反向优化”的。我们必须在安装过程中就做出关键决策。下载与安装前往 https://www.docker.com/products/docker-desktop/ 下载 Windows 版安装包。强烈建议下载.exe安装程序而非.zip解压版因为后者需要手动配置环境变量极易出错。安装向导中的关键勾选Use the WSL 2 based engine这是必选项确保 Docker 使用 WSL2 作为后端。Enable integration with my default WSL distro勾选此项让 Docker 能够无缝访问你安装的 Ubuntu 22.04。Add shortcut to desktop方便后续快速启动。Start Docker Desktop when you log in建议勾选避免每次都要手动启动。首次启动后的深度配置安装完成后Docker Desktop 会自动启动。右键任务栏的鲸鱼图标选择Settings。在左侧菜单中依次进入General勾选Start Docker Desktop when you log in如果安装时没选。Resources WSL Integration这是核心确保Enable integration with my default WSL distro已开启并且在下方列表中找到你的Ubuntu-22.04并勾选它。这一步决定了 Docker 是否能从 WSL2 内部调用docker命令。Resources Advanced这里需要根据你的机器性能进行调整。DeerFlow 2.0 推荐的最低配置是4 vCPU, 8 GB RAM。如果你的机器有 16GB 内存建议将Memory调整为10 GBCPUs调整为6。Disk image size可以保持默认的64 GB但请确保你的系统盘通常是 C:\有至少 50GB 的可用空间。注意完成以上所有配置后必须重启 Docker Desktop。右键任务栏图标选择Quit Docker Desktop然后重新启动。这是很多用户踩坑的根源——配置改了但没重启导致后续make docker-start一直报错。3. DeerFlow 2.0 的源码获取、配置与 Docker 构建一场与 Makefile 的深度对话当 Docker Desktop 成功运行WSL2 环境就绪我们才真正踏入 DeerFlow 2.0 的世界。此时你面对的不再是图形界面而是一系列命令行指令和配置文件。DeerFlow 的构建流程高度依赖Makefile它就像一个精密的自动化流水线控制器指挥着从依赖安装、镜像构建到服务启动的每一步。理解Makefile的逻辑是掌控整个部署过程的关键。3.1 源码克隆与项目结构初探理解“代码即文档”首先在 Windows 的 PowerShell 或 CMD 中执行git clone https://github.com/bytedance/deer-flow.git cd deer-flow这会将整个项目克隆到你的本地。进入项目根目录后用任意文本编辑器如 VS Code打开观察其结构。你会发现几个关键目录docker/: 这是 Docker 部署的核心包含了所有Dockerfile和docker-compose.yml文件。docker-compose.yml是整个服务的“蓝图”它定义了gateway网关、backend后端、redis内存数据库、qdrant向量数据库等服务如何协同工作。backend/: DeerFlow 的核心业务逻辑用 Python 编写基于 FastAPI 和 LangChain/LangGraph。frontend/: Web UI用 TypeScript 和 React 编写。skills/: 所有内置技能Skill的存放地每个技能都是一个独立的 Markdown 文件SKILL.md定义了其功能、输入输出和执行逻辑。这个结构本身就在告诉你DeerFlow 是一个典型的微服务架构而 Docker 是将其粘合成一个有机整体的唯一 glue。3.2make setup交互式配置向导的底层逻辑在项目根目录下运行make setup这会启动一个交互式的配置向导。它会询问你一系列问题而每一个问题的背后都对应着config.yaml文件中的一个关键字段。让我们拆解这个过程LLM Provider Selection向导会让你选择大模型提供商OpenAI, Anthropic, OpenRouter, vLLM 等。无论你选择哪个向导最终都会在config.yaml中生成一个models:数组。例如选择 OpenAI 后它会生成models: - name: gpt-4o display_name: GPT-4o use: langchain_openai:ChatOpenAI model: gpt-4o api_key: $OPENAI_API_KEY这里的$OPENAI_API_KEY是一个环境变量占位符意味着你必须在.env文件中定义它。Web Search Provider是否启用网络搜索如果选择Tavily向导会在.env文件中添加TAVILY_API_KEY并提示你去 https://tavily.com/ 申请一个免费的 API Key。Execution Safety Preferences这是 DeerFlow 安全模型的核心。向导会问你是否启用sandbox mode沙箱模式、bash accessBash 访问权限和file-write tools文件写入工具。对于 Windows 用户我强烈建议在此处全部选择Yes。因为 DeerFlow 的沙箱模式AioSandboxProvider正是通过 Docker 容器来实现的它能完美地将危险的代码执行限制在容器内部而不会影响你的 Windows 主机。如果你在这里选择了No那么 DeerFlow 将退化为一个功能残缺的“聊天机器人”失去了其最核心的价值。向导结束后它会自动生成两个关键文件config.yaml主配置和.env环境变量。打开.env文件你会看到类似这样的内容OPENAI_API_KEYsk-... TAVILY_API_KEYtvly-... REDIS_URLredis://redis:6379/0 QDRANT_URLhttp://qdrant:6333这些 URL 中的redis和qdrant正是docker-compose.yml中定义的服务名称。Docker 的 DNS 服务会自动将这些名称解析为对应容器的 IP 地址实现了服务间的无缝通信。3.3make docker-init与make docker-start构建与启动的两步法现在配置已完成我们可以开始构建和启动了。make docker-init这一步的作用是“预热”。它会执行docker pull deerflow/sandbox:latest从 Docker Hub 拉取 DeerFlow 官方提供的沙箱基础镜像。这个镜像是一个预先配置好的、包含 Python、Node.js、各种常用库Pandas, NumPy, Matplotlib和安全加固的 Linux 环境。它被所有 DeerFlow 的沙箱任务复用可以极大加速后续的容器启动速度。这一步只需要执行一次或者在官方更新了沙箱镜像后才需要再次执行。make docker-start这是真正的“点火”命令。它会执行docker-compose up -d读取docker-compose.yml并按照其中的定义依次启动redis、qdrant、backend和gateway四个服务。-d参数表示后台运行detached mode。提示如果make docker-start执行后你发现docker ps命令没有列出所有服务或者某个服务的状态是Restarting那么你需要立即查看日志。运行docker logs -f container_name例如docker logs -f deerflow-gateway-1来实时追踪错误。最常见的错误是.env文件中的 API Key 为空或者config.yaml中的sandbox.use字段配置错误。4. 故障排查实战从docker desktop failed to start到http://localhost:2026的完整路径部署 DeerFlow 2.0 的过程就是一场与各种报错信息的“斗智斗勇”。网络上充斥着docker desktop failed to start because virtualisation support wasnt detected这类错误它们看似相同但根源千差万别。下面我将带你走一遍最典型、最高频的故障排查链路让你不仅能解决问题更能理解问题背后的系统原理。4.1 Docker Desktop 启动失败虚拟化支持的“三重验证”当你双击 Docker Desktop 图标它一闪而过或者弹出一个红色错误框上面写着virtualization support not detected请不要慌张。这是一个系统级的“拒绝服务”信号我们需要逐层验证。第一层Windows 功能验证在 PowerShell 中运行Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux | Select-Object State Get-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform | Select-Object State如果任一输出为Disabled请回到第 2.1 节重新启用这两个功能并重启。第二层BIOS 硬件验证即使 Windows 功能已启用BIOS 中的虚拟化开关仍可能是关闭的。此时你需要再次重启进入 BIOS找到Intel VT-x或AMD SVM选项确认其为Enabled。一个简单的验证方法是在 Windows 中打开任务管理器CtrlShiftEsc切换到性能选项卡点击左侧的CPU。在右下角你应该能看到一行小字“虚拟化已启用”。如果显示“已禁用”那一定是 BIOS 设置的问题。第三层WSL2 状态验证运行wsl -l -v。如果命令报错Invalid argument或者列表为空说明 WSL2 本身就没有正确安装。请回到第 2.2 节重新下载并安装 WSL2 内核更新包。只有当这三层验证全部通过Docker Desktop 才能成功启动。记住这是一个“与生俱来”的要求不是 DeerFlow 的锅而是现代容器化应用在 Windows 上运行的“入场券”。4.2make docker-start启动后服务崩溃日志驱动的精准定位假设 Docker Desktop 成功运行make docker-start也执行完毕但你打开浏览器访问http://localhost:2026却得到This site can’t be reached。这时docker ps是你的第一个朋友。docker ps -a这个命令会列出所有容器包括已经退出Exited的。观察STATUS列如果某个容器比如deerflow-backend-1的状态是Exited (1) 2 minutes ago那就说明它启动后立刻崩溃了。docker logs container_id_or_name这是破案的关键。复制那个崩溃容器的 ID 或名字如deerflow-backend-1然后运行docker logs deerflow-backend-1。日志会从头到尾打印出容器启动时的所有输出。绝大多数情况下最后一行或倒数几行就是崩溃的根本原因。常见错误1Connection refused日志中出现redis.exceptions.ConnectionError: Error 111 connecting to redis:6379. Connection refused.。这说明backend服务尝试连接redis服务失败。原因通常是redis容器自己还没启动好或者config.yaml中的REDIS_URL配置错误。解决方案是等待 30 秒后再次运行docker logs deerflow-backend-1看redis是否已就绪或者检查config.yaml中的redis://redis:6379/0是否与docker-compose.yml中redis服务的container_name一致。常见错误2ModuleNotFoundError日志中出现ModuleNotFoundError: No module named langchain_openai。这说明 Python 依赖没有正确安装。这通常发生在make docker-init之后make docker-start之前你手动修改了requirements.txt但没有重新构建镜像。解决方案是运行make docker-build它会重新构建所有服务的 Docker 镜像。常见错误3Permission denied日志中出现PermissionError: [Errno 13] Permission denied: /app/.deer-flow。这通常发生在 Windows 的 WSL2 文件系统与 Docker 的挂载卷之间存在权限冲突。解决方案是在 WSL2 的 Ubuntu 终端中运行sudo chown -R $USER:$USER /home/$USER/deer-flow然后回到 Windows重新运行make docker-start。4.3 浏览器访问http://localhost:2026显示空白页前端构建的“静默失败”这是一个极具迷惑性的错误。docker ps显示所有服务都在运行docker logs里也没有明显的错误但浏览器就是一片空白。这通常意味着前端Frontend服务虽然启动了但其静态资源HTML/CSS/JS 文件并没有被正确构建或挂载。检查frontend容器日志运行docker logs deerflow-frontend-1。如果日志中充满了npm install或pnpm build的输出说明它正在构建你需要耐心等待几分钟。检查gateway容器日志运行docker logs deerflow-gateway-1。如果日志中出现GET / 404并且紧接着是GET /static/main.js 404那就证实了前端资源缺失。这是因为frontend容器的构建过程可能失败了或者docker-compose.yml中的volumes挂载配置有误导致构建好的dist/目录没有被正确映射到gateway容器的/app/static目录下。终极解决方案进入 WSL2 的 Ubuntu 终端cd到deer-flow目录然后手动运行前端构建命令cd frontend pnpm install pnpm build cd ..这会强制在 WSL2 环境中完成前端构建。然后再运行make docker-start。由于docker-compose.yml中frontend服务的volumes通常会将./frontend/dist挂载到容器内因此这次构建的产物会被自动使用。5. 部署完成后的进阶配置与安全加固让 DeerFlow 真正为你所用当http://localhost:2026终于在浏览器中展现出 DeerFlow 的 UI一个蓝色的对话框欢迎你时恭喜你基础部署已经成功。但这只是万里长征的第一步。为了让 DeerFlow 2.0 真正成为你生产力的倍增器而不是一个脆弱的玩具我们必须进行一系列进阶配置和安全加固。5.1 模型与技能的动态加载超越make setup的灵活性make setup向导是一个很好的起点但它生成的config.yaml是一个“静态快照”。DeerFlow 的强大之处在于其动态性。你可以在不重启整个服务的情况下随时添加、启用或禁用模型和技能。添加新模型打开config.yaml在models:数组末尾手动添加一个新的模型配置。例如添加一个本地运行的 Qwen3 模型- name: qwen3-32b-vllm display_name: Qwen3 32B (Local) use: deerflow.models.vllm_provider:VllmChatModel model: Qwen/Qwen3-32B api_key: EMPTY # vLLM 通常不需要 API Key base_url: http://localhost:8000/v1 # 你需要先在本地启动 vLLM 服务 supports_thinking: true保存文件后无需重启。DeerFlow 的后端服务会自动检测到config.yaml的变更并在下次请求时加载新的模型。你可以在 UI 的/models命令中看到它。启用/禁用技能skills/目录下的每个子目录如research/,report-generation/都对应一个技能。要禁用某个技能只需在config.yaml中找到skills:部分将对应的enabled: true改为false。例如skills: research: enabled: false # 禁用研究技能 report-generation: enabled: true同样保存后即可生效。这种细粒度的控制让你可以根据当前任务的需要精确地“裁剪”DeerFlow 的能力集从而减少上下文干扰提升响应速度。5.2 安全加固从127.0.0.1到生产环境的鸿沟DeerFlow 的官方文档中有一段加粗的警告“DeerFlow is designed by default to be deployed in a local trusted environment (accessible only via the 127.0.0.1 loopback interface).” 这不是一句客套话而是一条铁律。DeerFlow 拥有执行系统命令、读写任意文件的权限一旦暴露在局域网甚至公网它就成了一把悬在你数据安全之上的达摩克利斯之剑。防火墙规则这是最简单也最有效的第一道防线。在 Windows 防火墙中为docker-desktop.exe创建一条出站规则只允许其访问127.0.0.1。同时创建一条入站规则完全阻止任何外部 IP 访问localhost:2026端口。这样即使你的笔记本连在咖啡馆的 Wi-Fi 上DeerFlow 也只对你自己的浏览器开放。禁用 IM 通道config.yaml中的channels:部分如果你不打算用 Telegram 或 Slack 来控制 DeerFlow请务必将所有enabled: true改为enabled: false。IM 通道是 DeerFlow 最主要的外部攻击面禁用它们能瞬间消除 80% 的潜在风险。沙箱模式的终极安全确保config.yaml中的sandbox:配置如下sandbox: use: deerflow.community.aio_sandbox:AioSandboxProvider config: timeout: 300 memory_limit_mb: 2048 cpu_quota: 50000 cpu_period: 100000这个配置强制 DeerFlow 使用 Docker 容器沙箱并设置了严格的内存2GB和 CPU50%限制。即使一个恶意的、无限循环的 Python 脚本被提交它也会在 5 分钟后被强制终止且无法耗尽你的主机资源。提示我曾经在一次内部分享中演示 DeerFlow 的沙箱能力故意提交了一段while True: print(hello)的代码。在AioSandboxProvider下它安静地运行了 5 分钟然后被优雅地杀死。而在LocalSandboxProvider即直接在主机上执行下它瞬间让我的整个 Windows 系统变得卡顿。这就是沙箱的价值它不是锦上添花而是雪中送炭。6. 性能调优与资源监控让 DeerFlow 在 Windows 上“呼吸自如”DeerFlow 2.0 是一个资源 hungry 的应用。它同时运行着 Web 服务器、AI 推理引擎、内存数据库、向量数据库和多个沙箱容器。在 Windows 这个资源调度相对“粗放”的平台上如果不进行主动的性能调优和监控它很容易陷入“假死”或“慢如蜗牛”的状态。这并非 DeerFlow 的缺陷而是我们在异构环境下驾驭复杂系统时必须付出的“认知税”。6.1 Docker Desktop 资源限制的精细化管理Docker Desktop 的 GUI 设置界面提供了简单的滑块但这些滑块背后的参数才是性能调优的真正杠杆。内存分配在Settings Resources Advanced中将Memory设置为10 GB是一个不错的起点。但如果你的机器只有 16GB 内存这可能会导致 Windows 主机本身变得卡顿。此时你需要在docker-compose.yml文件中为每个服务单独设置内存限制。例如在backend服务下添加backend: # ... 其他配置 mem_limit: 4g mem_reservation: 2gmem_limit是硬性上限mem_reservation是软性预留。这告诉 Dockerbackend服务最多只能使用 4GB但会尽量保证它有 2GB 可用。这样你可以将 Docker Desktop 的全局内存设置为8 GB然后将剩余的资源留给 Windows。CPU 分配同理在docker-compose.yml中为backend和qdrant这两个计算密集型服务添加 CPU 限制backend: # ... 其他配置 cpus: 3.0 qdrant: # ... 其他配置 cpus: 2.0这样即使 DeerFlow 正在进行复杂的向量检索你的 Chrome 浏览器和 VS Code 依然能获得足够的 CPU 时间片保证日常开发的流畅性。6.2 实时监控用docker stats看清系统的“脉搏”docker stats是一个被严重低估的命令。它能让你实时看到每个容器的 CPU、内存、网络和磁盘 I/O 使用率是诊断性能瓶颈的“听诊器”。在 PowerShell 中运行docker stats --format table {{.Name}}\t{{.CPUPerc}}\t{{.MemUsage}}\t{{.NetIO}}\t{{.BlockIO}}你会看到一个动态刷新的表格类似于NAME CPU % MEM USAGE / LIMIT NET I/O BLOCK I/O deerflow-gateway-1 0.52% 125.4MiB / 10GiB 1.2MB / 2.3MB 12MB / 0B deerflow-backend-1 42.3% 2.12GiB / 4GiB 0B / 0B 0B / 0B deerflow-qdrant-1 18.7% 1.89GiB / 2GiB 0B / 0B 0B / 0B观察这个表格你能立刻发现backend的 CPU 使用率高达 42%而qdrant是 18%这说明当前的瓶颈在后端的 Python 推理逻辑上。backend的内存使用率是2.12GiB / 4GiB接近上限这提示你可能需要增加mem_limit或者检查是否有内存泄漏。注意docker stats的输出是实时的按CtrlC可以退出。它比打开 Windows 任务管理器看docker-desktop.exe的总占用要精确得多因为它能穿透到每一个容器的内部。6.3 日志轮转与磁盘空间清理防止“日志炸弹”吞噬你的 C 盘DeerFlow 的各个服务尤其是backend和gateway会产生海量的日志。这些日志默认会无限增长几个月下来轻松吃掉你 C 盘的几十 GB 空间。我们必须为它们设置“保质期”。在docker-compose.yml中配置日志驱动在每个服务的配置下添加logging部分backend: # ... 其他配置 logging: driver: json-file options: max-size: 10m max-file: 3这个配置的意思是为backend容器的日志文件设置最大尺寸为 10MB最多保留 3 个历史文件。当backend.log.1达到 10MB它会自动滚动为backend.log.2并生成新的backend.log.1。这样日志总大小永远不会超过 30MB。定期清理 Docker 的构建缓存Docker 在构建镜像时会生成大量的中间层缓存这些缓存会永久占用磁盘空间。运行以下命令可以安全地清理所有未被使用的缓存docker system prune -a --volumes这个命令会删除所有停止的容器、所有未被使用的网络、所有悬挂的镜像dangling images以及所有未被使用的数据卷volumes。请谨慎使用确保你没有重要的、未备份的数据卷。我通常每周执行一次可以释放 5-10GB 的空间。我在实际使用中发现一个配置得当的 DeerFlow 2.0 部署其资源消耗是完全可预测和可控的。它不会像某些“一键部署”的 AI 工具那样在你不知情的情况下悄悄吃掉你所有的内存和 CPU。相反它像一个训练有素的工程师清晰地告诉你它需要什么以及它正在做什么。这种透明性正是专业级 AI 工作流与玩具级应用之间最本质的区别。