Windows 11 + WSL2 环境复现WAIC多智能体协作演示全流程指南-平芜编程栈

1. 项目概述：从零到一复现WAIC 6 Bot协作演示

最近在WAIC（世界人工智能大会）上，Avernet团队展示的那个多Bot协作演示，相信不少朋友都看到了。演示里几个Bot各司其职，有的负责分析需求，有的负责写代码，有的负责测试，配合得行云流水，把AI智能体（Agent）协作的潜力展现得淋漓尽致。作为一个常年混迹在Windows环境下的开发者，我当时的第一反应是：这玩意儿能在我的主力开发机上跑起来吗？毕竟很多前沿的AI项目，官方教程动不动就是“建议在Ubuntu 22.04+环境下运行”，对Windows用户不太友好。

经过一番折腾，我成功在Windows 11 + WSL2（Windows Subsystem for Linux 2）的环境下，完整复现了Avernet WAIC 6 Bot协作演示的核心流程。整个过程涉及环境搭建、依赖部署、模型配置和联调测试，虽然踩了不少坑，但最终跑通的那一刻，感觉Windows作为AI开发平台的边界又被拓宽了一点。这篇文章，我就把从零开始的完整步骤、核心配置、以及那些官方文档里不会写的“坑点”和解决方案，毫无保留地分享出来。无论你是想学习多智能体框架，还是单纯想在Windows上搭建一个可用的AI应用开发环境，这篇指南都能给你提供一条清晰的路径。

2. 环境准备：打造坚实的Windows+WSL2基础

复现任何复杂的AI项目，一个稳定、兼容的基础环境是成功的一半。对于这个演示，我们的战场是Windows 11 + WSL2 + Ubuntu 22.04 LTS。这个组合能让我们在享受Windows图形界面和日常软件便利的同时，获得一个近乎原生的Linux开发环境。

2.1 启用WSL2并安装Ubuntu

首先，确保你的Windows版本是Windows 10版本 2004 及更高版本（内部版本 19041 及更高版本）或 Windows 11。WSL2需要虚拟化支持，请在BIOS/UEFI设置中确保“虚拟化技术”（如Intel VT-x或AMD-V）已开启。

步骤一：以管理员身份启动PowerShell或Windows终端，执行以下命令启用WSL功能并安装WSL2内核更新：

# 启用适用于 Linux 的 Windows 子系统 dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux /all /norestart # 启用虚拟机平台功能 dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart

执行完成后，必须重启计算机。重启后，继续在PowerShell中安装WSL2 Linux内核更新包（可从微软官网下载，或直接使用wsl命令更新）。

步骤二：设置WSL2为默认版本并安装Ubuntu。

# 将WSL2设置为默认版本 wsl --set-default-version 2 # 从Microsoft Store安装Ubuntu 22.04 LTS # 也可以使用命令行安装，例如： wsl --install -d Ubuntu-22.04

安装过程中，系统会提示你创建Linux用户名和密码，请务必记住。

注意：如果你之前安装过WSL1的发行版，可以使用wsl --set-version <发行版名称> 2将其转换为WSL2。使用wsl -l -v可以查看所有已安装的发行版及其状态。

2.2 基础系统配置与网络优化

安装好Ubuntu后，通过开始菜单或wsl命令进入子系统。第一件事是更新软件源并升级系统。

sudo apt update && sudo apt upgrade -y

接下来是几个关键配置，直接影响后续服务的稳定运行：

配置WSL2与Windows的互通网络：WSL2采用虚拟网络，其IP地址会变化。为了在Windows中稳定访问WSL2内的服务（如Web界面），我们需要在Windows的hosts文件中添加映射。在WSL2中执行hostname -I获取其IP地址，然后在Windows的C:\Windows\System32\drivers\etc\hosts文件（需管理员权限编辑）末尾添加一行，如：172.28.123.45 ubuntu-wsl。这样在Windows浏览器中访问http://ubuntu-wsl:端口号就能连通。
解决WSL2内网络不可达问题：有时在WSL2内执行ping外网会失败，提示network is unreachable。这通常是因为WSL2的虚拟网卡没有正确获取DNS。编辑WSL2内的/etc/wsl.conf文件（没有则创建）：
```
[network] generateResolvConf = false
```
然后退出WSL2，在Windows PowerShell中执行wsl --shutdown彻底关闭，再重新进入。接着编辑/etc/resolv.conf，将nameserver设置为8.8.8.8或114.114.114.114。

安装必备的基础开发工具：

sudo apt install -y curl wget git build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev libffi-dev

2.3 开发环境核心组件安装

AI项目离不开Python、Docker和CUDA（如果你有NVIDIA GPU并打算本地运行大模型）。

Python环境管理（强烈推荐使用pyenv）：

# 安装pyenv依赖及pyenv本身 curl https://pyenv.run | bash # 将pyenv初始化命令添加到shell配置文件中（如 ~/.bashrc） echo 'export PATH="$HOME/.pyenv/bin:$PATH"' >> ~/.bashrc echo 'eval "$(pyenv init -)"' >> ~/.bashrc echo 'eval "$(pyenv virtualenv-init -)"' >> ~/.bashrc source ~/.bashrc # 安装特定版本的Python（例如3.10.12，这是许多AI框架兼容性较好的版本） pyenv install 3.10.12 pyenv global 3.10.12

Docker引擎安装：WSL2可以完美运行Docker。推荐使用Docker官方提供的安装脚本。

# 卸载旧版本（如有） sudo apt remove docker docker-engine docker.io containerd runc # 安装依赖 sudo apt update sudo apt install -y ca-certificates curl gnupg lsb-release # 添加Docker官方GPG密钥 sudo mkdir -p /etc/apt/keyrings curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg # 设置稳定版仓库 echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null # 安装Docker引擎 sudo apt update sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin # 将当前用户加入docker组，避免每次使用sudo sudo usermod -aG docker $USER # 退出WSL2再重新进入，使组权限生效

验证安装：docker --version和docker run hello-world。

CUDA Toolkit安装（可选，用于GPU加速）：如果你的Windows主机有NVIDIA GPU，并且想在WSL2内使用CUDA，需要：

在Windows上安装匹配的NVIDIA显卡驱动。
在WSL2的Ubuntu内安装CUDA Toolkit。访问NVIDIA官网，根据你的WSL2 Ubuntu版本选择“Linux -> x86_64 -> WSL-Ubuntu -> deb(local)”安装方式，按照官方指令操作。通常步骤是：
```
wget https://developer.download.nvidia.com/compute/cuda/repos/wsl-ubuntu/x86_64/cuda-keyring_1.1-1_all.deb sudo dpkg -i cuda-keyring_1.1-1_all.deb sudo apt update sudo apt install -y cuda-toolkit-12-4 # 版本号请根据实际情况调整
```
安装后，运行nvidia-smi应该能正确显示GPU信息。

3. 核心组件部署：构建Bot协作的基石

Avernet的演示核心在于多个Bot（智能体）的协同工作。要复现这一场景，我们需要部署几个关键的后端服务：一个用于编排和对话的AI应用框架（如Dify、LangChain服务），一个向量数据库用于存储和检索知识，以及一个缓存数据库来提升性能。这里我选择Dify作为应用框架，Redis作为缓存，Qdrant作为向量数据库。这种组合在开源社区中比较成熟，文档丰富，易于集成。

3.1 使用Docker Compose一键部署服务栈

最优雅的方式是使用docker-compose.yml文件来定义和运行所有服务。在WSL2的家目录下创建一个项目文件夹，例如waic_bot_demo，然后创建docker-compose.yml文件。

version: '3.8' services: # Dify - AI应用编排框架 dify-api: image: langgenius/dify-api:latest container_name: dify-api ports: - "5001:5001" environment: - MODE=api - CONSOLE_API_URL=http://localhost:5001 - CONSOLE_WEB_URL=http://localhost:3000 - SECRET_KEY=your-secret-key-change-this # 务必修改！ - DB_USERNAME=postgres - DB_PASSWORD=difyai123456 - DB_HOST=postgres.db - DB_PORT=5432 - DB_DATABASE=dify - REDIS_HOST=redis.cache - REDIS_PORT=6379 - REDIS_PASSWORD= - STORAGE_TYPE=local - FILES_URL=http://localhost:5001 volumes: - ./storage/data:/app/storage/data depends_on: - postgres.db - redis.cache networks: - dify-network dify-worker: image: langgenius/dify-worker:latest container_name: dify-worker environment: - MODE=worker - CONSOLE_API_URL=http://dify-api:5001 - CONSOLE_WEB_URL=http://localhost:3000 - SECRET_KEY=your-secret-key-change-this # 与api服务一致 - DB_USERNAME=postgres - DB_PASSWORD=difyai123456 - DB_HOST=postgres.db - DB_PORT=5432 - DB_DATABASE=dify - REDIS_HOST=redis.cache - REDIS_PORT=6379 - REDIS_PASSWORD= depends_on: - dify-api networks: - dify-network dify-web: image: langgenius/dify-web:latest container_name: dify-web ports: - "3000:3000" environment: - CONSOLE_API_URL=http://dify-api:5001 - APP_API_URL=http://localhost:5001 depends_on: - dify-api networks: - dify-network # PostgreSQL - 关系型数据库，Dify用于存储应用数据 postgres.db: image: postgres:15-alpine container_name: postgres-db restart: always environment: POSTGRES_PASSWORD: difyai123456 POSTGRES_DB: dify POSTGRES_USER: postgres volumes: - ./data/postgres:/var/lib/postgresql/data networks: - dify-network # Redis - 缓存和消息队列 redis.cache: image: redis:7-alpine container_name: redis-cache restart: always command: redis-server --appendonly yes volumes: - ./data/redis:/data networks: - dify-network # Qdrant - 向量数据库 qdrant.vector: image: qdrant/qdrant:latest container_name: qdrant-vector restart: always ports: - "6333:6333" - "6334:6334" volumes: - ./data/qdrant_storage:/qdrant/storage networks: - dify-network networks: dify-network: driver: bridge

关键配置解析与避坑指南：

端口映射：dify-web映射到3000端口（Web管理界面），dify-api映射到5001端口（后端API），qdrant映射到6333（HTTP）和6334（gRPC）端口。确保这些端口在Windows和WSL2中都没有被占用。
SECRET_KEY：这是一个关键的安全配置，用于加密会话等。务必将your-secret-key-change-this替换为一个你自己生成的、足够复杂的随机字符串。可以在Linux中运行openssl rand -hex 32来生成。
数据持久化：通过volumes配置，将容器内的数据（PostgreSQL数据、Redis数据、Qdrant向量数据、Dify上传的文件）映射到宿主机的./data和./storage目录下。这样即使删除容器，数据也不会丢失。
网络：所有服务在同一个自定义网络dify-network下，可以通过服务名（如postgres.db）直接相互访问，这是Docker Compose的特性。
依赖顺序：depends_on确保了服务启动顺序，例如dify-api会等待postgres.db和redis.cache就绪后才启动。

保存好docker-compose.yml文件后，在终端中进入该文件所在目录，执行：

docker-compose up -d

-d参数表示在后台运行。使用docker-compose logs -f可以查看实时日志，观察服务启动是否正常。当看到所有容器状态均为Up时，基础服务栈就部署完成了。

3.2 Dify初始化配置与模型接入

服务启动后，在Windows浏览器中访问http://localhost:3000（如果之前配置了hosts，也可以用http://ubuntu-wsl:3000）。首次访问会进入初始化页面，需要创建管理员账号。

登录后，进入Dify控制台。要让它能驱动Bot，最关键的一步是配置模型供应商。Avernet的演示很可能使用了多种模型，例如GPT-4用于复杂推理，Claude用于创意生成，或本地部署的模型。Dify支持 OpenAI API 格式的多种模型。

以配置OpenAI兼容的模型为例：

进入“设置” -> “模型供应商”。
点击“添加模型供应商”，选择“OpenAI”。
在配置页面：
- 模型类型：选择“文本生成”或“Embedding”，根据你要接入的模型功能。
- 模型名称：自定义一个名字，如 “My-GPT-4”。
- 模型ID：填写模型在API调用时的标识，例如gpt-4-turbo-preview。
- API密钥：填入你的OpenAI API Key。
- API基础地址：如果你使用的是第三方兼容OpenAI API的服务（如本地部署的Ollama、OpenRouter或国内大模型平台），这里需要修改为对应的地址，例如http://localhost:11434/v1（Ollama默认地址）。如果直接用OpenAI官方，则保持默认https://api.openai.com/v1。
点击“保存”，系统会测试连接。成功后，该模型就可以在创建工作流时被选用了。

实操心得：对于复现演示，如果演示中Bot功能各异，建议配置多个模型供应商，并给每个模型起一个清晰的别名（如“代码专家-GPT-4”、“文案助手-Claude-3”）。这样在后续设计工作流时，可以直观地为不同任务节点分配最合适的模型，模拟演示中Bot的“专长”特性。

3.3 连接Qdrant向量数据库

Dify本身支持多种向量数据库，我们需要将其连接到刚才部署的Qdrant实例。

进入“设置” -> “系统设置”。
找到“向量数据库”部分。
选择“Qdrant”作为供应商。
填写连接信息：
- 服务器地址：由于Dify运行在Docker容器内，且与Qdrant在同一个Docker网络dify-network中，这里应该填写服务名http://qdrant.vector:6333。这是关键！如果填localhost:6333会连接失败，因为localhost在容器内指向它自己。
- API密钥：如果Qdrant设置了认证则填写，我们默认部署没有，留空即可。
- 默认向量维度：根据你使用的Embedding模型确定，例如text-embedding-ada-002是1536维。
点击“连接测试”，成功后保存。

至此，我们的“舞台”已经搭建完毕——一个集成了AI模型能力、知识库存储（向量数据库）、应用编排和缓存的完整后端环境。接下来，就是设计并实现让多个Bot协作的“剧本”了。

4. 协作流程设计与实现：拆解多Bot工作流

Avernet演示的精髓在于多个Bot（智能体）的协同。在Dify中，这可以通过一个精心设计的“工作流（Workflow）”来实现。工作流由多个节点组成，节点间通过数据流连接，每个节点可以执行特定任务（如调用LLM、查询知识库、执行代码、条件判断等）。我们可以将每个Bot设计为工作流中的一个或多个功能节点。

4.1 模拟演示场景与Bot角色定义

为了复现，我们先定义一个简化的协作场景，它包含了演示中可能出现的几种典型Bot角色：

需求分析Bot：接收用户原始、模糊的需求，进行分析、澄清和结构化。
代码专家Bot：根据结构化的需求，生成可执行的代码片段或脚本。
代码审查/测试Bot：对生成的代码进行静态检查、模拟运行或单元测试，发现问题。
文档生成Bot：根据最终确认的代码和需求，生成技术文档或用户说明。
协调员Bot（可选）：负责在各个专业Bot之间传递信息、汇总结果、判断流程走向。

这个流程是线性的，但也可能存在分支和循环（例如，测试不通过则返回给代码专家修改）。

4.2 在Dify中构建多节点工作流

登录Dify，点击“创建工作流”。我们将构建一个名为“WAIC 6-Bot协作模拟”的工作流。

第一步：设置起始节点（用户输入）从左侧节点库拖入一个“开始”节点。这代表工作流的触发点。我们可以配置一个变量，比如user_request，来接收用户提出的原始需求。

第二步：添加“需求分析Bot”节点

拖入一个“LLM”节点，将其重命名为“需求分析Bot”。
连接“开始”节点的输出到该节点的输入。

在节点配置中：

选择模型：选择一个擅长理解和分析的模型，例如GPT-4。

编写提示词（Prompt）：这是赋予Bot“灵魂”的关键。例如：

你是一个资深产品需求分析师。请对用户的需求进行分析和澄清。 用户需求：{{user_request}} 请按以下结构化格式输出： 1. **核心目标**：用一句话总结用户想要实现什么。 2. **功能清单**：列出实现该目标所需的具体功能点。 3. **技术栈建议**：建议可能用到的编程语言、框架或工具。 4. **待澄清问题**：列出你需要向用户进一步确认的1-3个关键问题。

变量：{{user_request}}会自动绑定到“开始”节点传来的变量。
输出变量：将LLM的回复赋值给一个新变量，如analyzed_requirements。

第三步：添加“代码专家Bot”节点

再拖入一个“LLM”节点，重命名为“代码专家Bot”。
连接“需求分析Bot”节点的输出到其输入。

配置提示词，指示它根据结构化的需求生成代码。例如：

你是一个经验丰富的软件开发工程师。请根据以下需求分析，生成完整、可运行的代码。 需求分析： {{analyzed_requirements}} 请专注于[功能清单]部分，为[核心目标]编写代码。 要求： 1. 代码需包含必要的导入语句和主函数。 2. 添加清晰的注释。 3. 输出格式：首先用“```语言\n”包裹代码块，然后在代码块后简要说明代码逻辑和关键函数。

输出变量设为generated_code。

第四步：添加“代码审查Bot”节点这个节点可以更复杂。我们可以使用“代码”节点来实际执行一些检查，或者继续用“LLM”节点进行静态分析。

方案A（使用LLM进行审查）：添加一个LLM节点，提示词要求它扮演代码审查员，从代码风格、潜在bug、安全性、性能等方面审查generated_code，并输出审查报告code_review_report。
方案B（结合工具调用）：这是更高级的模拟。Dify支持“工具调用”节点。我们可以预设一个“代码静态分析工具”（这需要额外开发一个API端点，接收代码并返回分析结果，例如使用pylint、eslint的封装），然后在本节点调用该工具。结果可以传递给下一个节点做判断。

第五步：添加“判断”节点拖入一个“判断”节点。它可以根据上游节点的输出（如审查报告）来决定工作流走向。例如，配置判断条件：如果code_review_report中包含“严重错误”或“必须修改”等关键词，则走“不通过”分支，将流程引回“代码专家Bot”节点进行迭代修改；如果审查通过，则走“通过”分支，进入下一个节点。

第六步：添加“文档生成Bot”节点在“通过”分支后，添加一个LLM节点作为“文档生成Bot”。它的提示词可以设计为：根据最初的analyzed_requirements和最终通过的generated_code，生成一份Markdown格式的技术文档或用户使用指南，输出为final_documentation。

第七步：设置输出节点最后，拖入一个“回答”节点。可以配置它将final_documentation和generated_code一起输出给用户，作为最终成果。

至此，一个包含多个“Bot”（节点）的协作工作流就搭建完成了。每个节点都可以独立配置不同的模型、提示词和参数，模拟出不同特长的Bot。通过连接线和判断节点，我们实现了逻辑流转和条件协作。

4.3 工作流调试与优化技巧

搭建只是第一步，让工作流顺畅运行需要调试。

使用“调试”功能：Dify工作流编辑器右上角有“调试”按钮。点击后，可以在左侧面板输入测试用的user_request，然后逐步运行工作流。你可以观察每个节点的输入/输出，快速定位问题出在哪个环节。
提示词迭代：工作流的效果很大程度上取决于每个LLM节点的提示词。如果某个Bot的输出不符合预期，不要急于修改流程，先优化它的提示词。尝试更清晰的指令、更具体的格式要求、提供示例（Few-shot）等。
变量管理：确保变量名前后一致，在需要引用的地方正确使用{{variable_name}}语法。混乱的变量传递是工作流错误的常见原因。
处理长文本：代码和文档可能很长，超出模型的上下文限制。可以考虑在提示词中要求Bot分点输出，或者使用Dify的“文本分割”节点预处理输入。
模拟异步与并行：真正的多智能体可能是并行工作的。在Dify中，可以通过“并行”节点分支，让“代码专家Bot”和“文档草拟Bot”同时开始工作，最后再用一个“合并”节点汇总结果，这能更好地模拟演示中高效的协作场景。

5. 高级集成与性能调优

当基础工作流跑通后，我们可以进一步向Avernet演示的复杂度靠拢，涉及更真实的工具调用、知识库检索以及性能优化。

5.1 实现真实的工具调用与外部API集成

演示中的Bot可能不仅能“说”，还能“做”，比如调用搜索引擎API、执行Shell命令、操作数据库等。在Dify中，这可以通过“工具”功能实现。

创建自定义工具：

进入“工具”标签页，点击“创建工具”。
选择“自定义工具”，填写工具名称、描述。
最关键的是配置“API端点”。你需要一个对外提供服务的API。例如，创建一个可以执行Python代码片段的工具：
- URL：http://your-api-server:port/execute（这个服务需要你单独开发并部署，例如一个简单的Flask应用，接收代码，在安全沙箱中运行并返回结果）。
- 方法：POST。
- 请求头：根据需要添加，如Content-Type: application/json。
- 请求体参数：定义如{"code": "{{code}}"}，其中{{code}}是工作流中传来的变量。
- 参数映射：将API返回的JSON结果映射到新的工作流变量，如execution_result。
保存后，该工具就会出现在工作流编辑器的节点库中。

在工作流中，你可以添加一个“工具调用”节点，选择你创建的工具，并将上游节点生成的代码作为参数传入。工具执行后的结果，可以再交给LLM节点去分析。这就实现了“生成代码 -> 执行代码 -> 分析结果”的闭环，Bot的能力从“思考”扩展到了“行动”。

5.2 集成知识库实现上下文感知

演示中的Bot可能拥有专属知识库。在Dify中，可以轻松为工作流注入知识库上下文。

创建知识库：在Dify控制台创建知识库，上传相关文档（如产品手册、API文档、历史对话记录）。
在工作流中插入“知识库检索”节点：在需要查询知识的节点前，添加一个“知识库检索”节点。配置它连接到指定的知识库，并将用户问题或相关上下文作为查询内容。
组合提示词：在后续的LLM节点中，其提示词模板可以设计为：“请基于以下背景知识回答问题：\n{{knowledge_base_context}}\n\n用户问题：{{user_question}}”。这样，Bot的回复就能基于检索到的专业知识，回答更精准。

5.3 性能监控与优化策略

当工作流变得复杂，性能问题就会出现。以下是一些优化思路：

模型选择：不是所有任务都需要GPT-4。对于简单的文本格式化、信息提取，可以使用更小、更快的模型（如GPT-3.5-Turbo），以降低成本和提高响应速度。在Dify中可以为不同节点配置不同供应商的模型。
缓存策略：对于内容变化不频繁的节点（如某些固定的信息查询），可以考虑启用缓存。Dify本身与Redis集成，可以缓存一些中间结果。
超时与重试：在调用外部API或工具时，务必在节点配置中设置合理的超时时间，并配置重试机制，避免因单次失败导致整个工作流卡住。
WSL2资源分配：WSL2默认会动态分配内存和CPU。对于资源密集型的AI工作流，建议在Windows用户目录下的.wslconfig文件中进行限制，避免WSL2占用过多主机资源导致系统卡顿。
```
# 文件位置：C:\Users\<你的用户名>\.wslconfig [wsl2] memory=8GB # 限制最大内存，根据你的主机配置调整 processors=4 # 限制使用的CPU核心数 localhostForwarding=true
```
修改后，需要在PowerShell中执行wsl --shutdown关闭WSL2，再重新启动使之生效。

6. 常见问题与故障排查实录

在Windows + WSL2环境下复现此类项目，会遇到一些特有的问题。以下是我在实操中遇到的一些典型“坑”及其解决方案。

6.1 WSL2与Docker相关故障

问题1：Docker命令执行报错“Cannot connect to the Docker daemon”。

现象：在WSL2中执行docker ps等命令时提示连接失败。
原因：Docker服务没有启动，或者当前用户没有加入docker组。
解决：
1. 确保Docker服务已启动：sudo service docker start。
2. 将用户加入docker组后，需要完全退出WSL2终端再重新进入，或者执行newgrp docker刷新组信息。
3. 检查WSL2与Docker Desktop的集成：确保Windows上的Docker Desktop设置中，“Use the WSL 2 based engine”和“Enable integration with my default WSL distro”已勾选。

问题2：容器内服务无法通过localhost互访。

现象：在docker-compose.yml中，一个服务（如dify-api）配置了依赖另一个服务（如postgres.db），并使用localhost:5432作为数据库地址，导致连接失败。
原因：在Docker容器网络中，每个容器有独立的网络命名空间，localhost指向容器自身，而非宿主机或其他容器。
解决：必须使用Docker Compose定义的服务名作为主机名。如上文配置所示，应该使用postgres.db而不是localhost。这是容器间通信的标准方式。

问题3：WSL2磁盘空间占用过大。

现象：随着Docker镜像、容器和项目数据的增多，WSL2虚拟硬盘文件（通常位于%USERPROFILE%\AppData\Local\Packages\...）会不断膨胀，即使删除文件，空间也可能不释放。
解决：
1. 在WSL2中清理Docker：docker system prune -a（谨慎操作，会删除所有未使用的镜像、容器、网络和卷）。
2. 退出所有WSL2发行版，在PowerShell中执行wsl --shutdown。
3. 在PowerShell中执行diskpart，然后依次输入：
```
select vdisk file="C:\Users\<用户名>\AppData\Local\Packages\CanonicalGroupLimited...\ext4.vhdx" compact vdisk
```
  这会对虚拟硬盘进行压缩。请将文件路径替换为你的实际路径。

6.2 Dify应用与模型连接问题

问题1：Dify工作流中LLM节点调用失败，提示“模型服务不可用”或“超时”。

排查步骤：
1. 检查模型供应商配置：确认API密钥正确，API地址可访问（对于非OpenAI官方地址，在WSL2内用curl测试一下）。
2. 检查网络连通性：如果模型服务部署在WSL2外的本地主机（如Windows上运行的Ollama），需要确保Windows防火墙允许相关端口，并且在WSL2内能用Windows的IP地址（如172.x.x.x）访问到该服务，而不是localhost。
3. 检查上下文长度：如果提示词加上生成的内容过长，超过了模型的最大上下文限制，会导致失败。尝试精简提示词或拆分内容。
4. 查看Dify Worker日志：使用docker-compose logs -f dify-worker查看更详细的错误信息，可能包含模型返回的具体错误原因。

问题2：知识库检索效果不佳，返回无关内容。

原因：Embedding模型不匹配或文本分割策略不当。
解决：
1. 统一Embedding模型：确保创建知识库时选择的Embedding模型，与系统设置中Qdrant向量数据库配置的默认向量维度一致。如果不一致，检索时计算出的相似度会失准。
2. 优化文本分割：上传文档时，可以调整文本分割器（Splitter）的参数，如块大小（Chunk Size）和重叠区（Overlap）。对于技术文档，较小的块（如256 tokens）和一定的重叠（如50 tokens）通常效果更好。
3. 优化检索查询：在工作流的“知识库检索”节点中，尝试对查询文本进行改写或总结，使其更贴近知识库中片段的表述方式。

问题3：工作流运行缓慢。

分析：瓶颈可能出现在：1) LLM API调用延迟；2) 复杂工作流串行节点过多；3) WSL2资源不足。
优化：
1. 并行化：审查工作流，将没有依赖关系的节点改为并行执行。
2. 模型降级：对响应速度要求高、精度要求不高的节点，换用更快的模型。
3. 资源监控：在WSL2中运行htop或docker stats，观察CPU、内存和I/O使用情况。如果资源吃紧，考虑调整.wslconfig增加资源分配，或优化Docker容器资源限制。

整个复现过程，就像是在Windows这片熟悉的土地上，开辟出一块兼容Linux生态的“飞地”，并在这块飞地上精心搭建了一个多智能体协作的微型世界。从环境配置的琐碎，到服务联调的挑战，再到工作流设计的巧思，每一步都充满了探索的乐趣和解决问题的成就感。最终看到几个“Bot”按照你设计的剧本，有条不紊地对话、协作、产出结果时，那种感觉确实非常接近在WAIC上看到的演示效果。这不仅仅是一次技术复现，更是一次对AI应用开发模式的前沿实践。