Tutti VM：多智能体协作的环境隔离与实战指南

多智能体是今年绕不开的技术热词，但很多人一开始尝试多智能体项目，就被环境问题卡住了：多个 Agent 之间怎么隔离依赖、怎么管理不同版本的 Python 和模型配置、多个智能体同时跑的时候怎么避免互相干扰。这些问题的答案，往往不在 Agent 框架本身，而在底层运行环境。Tutti VM 这个方向，正是把“虚拟机”和“多智能体协作”放在一起，解决多智能体项目真正落地时的环境隔离和编排问题。

这篇文章会从实际体验出发，讲清楚三件事：第一，为什么多智能体项目需要 VM 这类隔离底座，它解决了哪些裸机和容器解决不好的问题；第二，怎么从零搭建一个可以跑多智能体协作的实验环境，包括虚拟机安装、网络配置、Python 环境和依赖管理；第三，用一个“正反博弈 + 裁判”的多智能体代码示例，跑通完整的协作流程，并给出常见的排查思路和工程建议。

文章不会只堆概念，每个章节尽量有操作路径、有代码、有排错方法。如果你正准备开始做多智能体项目，或者已经被虚拟机环境、Agent 通信、依赖冲突这些问题折磨过，这篇文章应该对你有用。

1. 多智能体协作真正难在哪里

很多人以为多智能体开发最难的是 Prompt 设计或者模型调用，实际从项目落地角度看，真正的门槛在两头：一头是单个 Agent 能力的构建，另一头是多个 Agent 的运行环境。

单个 Agent 跑起来相对简单，无非是调用大模型 API、写工具函数、维护上下文。但多智能体协作不是多个单 Agent 的简单叠加。它意味着多个 Agent 要同时运行、互相通信、共享一部分状态，同时又要在逻辑上彼此隔离。这里会出现几个非常实际的问题。

第一个问题是依赖冲突。Agent A 可能依赖 Python 3.10 和某个库的 2.x 版本，Agent B 可能依赖 Python 3.8 和同一个库的 1.x 版本。如果直接在宿主机上跑，光是解决依赖冲突就消耗大量精力。用虚拟环境可以在一定程度上解决，但虚拟环境仍然共享操作系统内核和系统级配置，遇到底层库不一致时依然会出问题。

第二个问题是资源隔离。多个 Agent 同时运行，任何一个 Agent 的失控循环或内存泄漏都可能拖垮整个宿主进程。比如一个 Agent 在处理长上下文时报错，导致 CPU 被打满，其他 Agent 的响应也跟着变慢。这种情况下，如果每个 Agent 有独立的资源配额，影响范围就能被限制住。

第三个问题是运行环境的差异。生产环境和开发环境的操作系统版本、CUDA 版本、系统依赖库不一样，代码在本地能跑，部署到服务器上却报缺库，这类问题在多智能体项目里会被放大，因为涉及的可执行组件更多了。

VM 的价值恰恰体现在这里。虚拟机的隔离粒度比进程级隔离更彻底，每个虚拟机有独立的操作系统、独立的内核、独立的网络栈和独立的文件系统。多个智能体如果运行在不同的虚拟机里，依赖冲突从根源上被避免了，资源配额可以精确限制，环境一致性也更容易保证。这是进程、容器和虚拟环境无法完全替代的。

从体验角度看，把多智能体项目跑在 VM 里，最明显的感觉是“心里踏实”。系统环境出了问题，直接回滚快照，不用反复折腾宿主机。对于需要长期迭代的多智能体项目，这种兜底能力非常关键。

2. 理解 Tutti VM 与多智能体协作的关系

先说结论：从现有的材料看，Tutti VM 本质上是一个把“VM 虚拟机环境”与“多智能体协作”结合起来的技术方向。它的核心不是某一个具体的大模型，也不是某一个 Agent 框架，而是“运行底座”这个层面。

这里需要先厘清几个概念。

多智能体系统（Multi-Agent System）是指由多个自主 Agent 组成的系统，Agent 之间通过消息传递、任务分工或博弈机制完成单个 Agent 难以独立完成的任务。常见的设计模式包括：多个 Agent 分别扮演不同角色、一个主 Agent 调度多个子 Agent、多个 Agent 进行正反辩论再由裁判 Agent 做出裁决。这些模式中，Agent 之间既需要协作，也需要保持各自的独立状态。

VM（Virtual Machine）则是虚拟机，通过 Hypervisor 在物理硬件之上模拟出多个完整的计算机系统。每个虚拟机都包含自己的操作系统、虚拟 CPU、虚拟内存、虚拟磁盘和虚拟网卡。VM 的主要优势是隔离性强、环境可复制、快照便于回滚。热词里大量出现的“vm 创建虚拟机教程”“vm 虚拟机安装教程”“vm 怎么设置中文”等搜索词，反映出虚拟机本身有很高的使用门槛，环境配置对普通开发者来说并不轻松。

“Tutti VM”的含义，更稳妥的理解是：以虚拟机作为多智能体运行环境的载体，用多台虚拟机分别承载一个或多个 Agent，再通过网络通信把这些 Agent 组合成一个协作系统。这样做的直接收益是，每个 Agent 的环境互不干扰，且整套系统可以标准化复现。

用一张表格来看虚拟机、容器、裸机进程三种方案在多智能体场景下的差异：

从多智能体协作的角度看，VM 的最大优势不是运行速度，而是隔离性和可回滚性。多智能体系统在调试阶段不确定性很高，一个 Agent 的行为可能会污染整个环境，快照回滚能让你迅速回到一个已知正常的状态。这在容器和裸机环境下操作起来都更麻烦。

所以，Tutti VM 解决的核心问题，可以概括为一句话：多智能体系统的环境隔离与可复现运行。它适合对稳定性和调试效率有要求的场景，比如多智能体应用的开发调试、模型对比评测、自动化测试等。它的成本是资源开销更大、启动更慢，不适合对延迟和资源占用极敏感的轻量场景。

3. 多智能体协作的系统架构与运行模型

在开始搭建环境之前，先把多智能体协作的架构和运行模型讲清楚。多智能体系统的架构设计，直接影响 VM 的划分方式。

常见的一种架构是“角色分工模式”。系统里同时存在多个 Agent，每个 Agent 扮演一个角色，比如代码生成 Agent、代码审查 Agent、测试编写 Agent。用户输入需求后，主控模块把任务拆解，分发给不同 Agent，Agent 执行完后再由聚合模块汇总结果。

另一种常见的架构是“正反博弈 + 裁判模式”。两个或多个 Agent 分别持不同立场，针对同一个问题给出各自的方案，互相质疑和反驳，最后由一个独立的裁判 Agent 综合双方论据得出最终结论。这种模式近年来讨论得很多，因为它在某些决策类任务上能减少单 Agent 的偏见，让输出结果更经得起推敲。

第三种是“主从调度模式”。一个主 Agent 负责任务分解和结果汇总，多个子 Agent 分别执行具体子任务。这种模式适合任务路径清晰、子任务可并行处理的场景。

在这个架构里，VM 的划分策略通常有两种思路：

第一种是一台 VM 跑一个 Agent。隔离性最好，资源控制最清晰，但资源开销大，虚拟机数量多，管理成本高。适合对稳定性和安全边界要求高的场景。

第二种是一台 VM 跑多个 Agent，但通过进程隔离或虚拟环境隔离。资源利用率高，但隔离性弱一些。适合实验阶段，比如在一台 Ubuntu 虚拟机上同时跑两个 Agent 进程。

从工程实践来看，可以优先采用第二种思路做原型验证，等到项目成熟后，再按 Agent 的重要程度决定是否拆分到独立 VM。用一个简洁的文字架构描述如下：

宿主机（VMware / VirtualBox / KVM） ├── VM-Agent-A（Ubuntu + Python 3.10 + Agent A 代码） ├── VM-Agent-B（Ubuntu + Python 3.10 + Agent B 代码） └── VM-Judge（Ubuntu + Python 3.11 + Judge 裁判 Agent） ↓ 内部虚拟网络（NAT / Host-Only / Bridge） ↓ 多 Agent 通过 HTTP / Socket 通信协作

VM 之间的通信推荐走虚拟网络。桥接模式让 VM 在局域网里拥有独立 IP，可以互相访问；NAT 模式下 VM 共享宿主机 IP，VM 之间也能通信，但外部访问 VM 会受限。Host-Only 则适合完全隔离的内部实验网络。

理解了这个架构，后面搭环境时你就知道每一步在做什么：虚拟机是给 Agent 住的房间，虚拟网络是房间之间的走廊，Python 环境和依赖是每个 Agent 的工具箱，通信接口是 Agent 之间递纸条的窗口。

4. 环境准备：从零搭建多智能体实验环境

搭建环境是整个过程的第一个坎。从热搜词来看，大量开发者被虚拟机安装、网络配置、系统安装这些问题卡住过。这里以 VMware Workstation 为例，梳理一套稳妥的搭建路径。

4.1 安装虚拟机软件

VMware Workstation 是常见的桌面级虚拟机软件，也可以选择 VirtualBox 或 KVM，核心思路一致。安装过程不再赘述，需要注意两点：安装完成后，进入“编辑 - 虚拟机网络编辑器”，检查虚拟网络配置是否正常；如果准备让多个 VM 互相通信，建议单独规划一个 VMnet 网段，不要和宿主机主网段混在一起。

4.2 创建第一台 Ubuntu 虚拟机

多智能体开发通常选择 Ubuntu 作为 VM 操作系统，因为 Python 生态和大多数 Agent 框架对 Linux 支持最好。在 VMware 中新建虚拟机时，选择“稍后安装操作系统”，在系统类型里选 Ubuntu 64 位。磁盘大小建议设置在 40GB 以上，内存根据宿主机配置来，最低建议 4GB，如果同时要跑多个 VM 则要预留更多。

虚拟机系统的安装镜像，建议到 Ubuntu 官网下载 LTS 版本，不要随便下载第三方修改版。安装过程可以参考你的 VM 虚拟机安装教程操作，这里真正有坑的地方在登录进入系统之后。

4.3 配置虚拟机网络，解决桥接和网络激活问题

安装完成进入 Ubuntu 后，第一件事是配置网络。很多人在“vm 中桥接模式 centos 网络激活失败”“vm 虚拟机网速特别慢”“vm 中桥接模式网络激活失败”这些搜索词背后，其实都是网络配置不当。

用 VMware 装完 Ubuntu 后，默认网卡模式往往不能直接上网，需要检查网络配置文件。在 Ubuntu 22.04 及以后版本中，网络配置通常在/etc/netplan/目录下的.yaml文件。以桥接模式为例，可以编辑配置文件：

# 文件路径：/etc/netplan/01-network-manager-all.yaml network: version: 2 renderer: NetworkManager ethernets: ens33: dhcp4: true dhcp6: false

修改完成后执行：

sudo netplan apply ip addr show ens33

如果ip addr show没有获取到 IP，先检查 VMware 的虚拟机网络设置里网卡是否选择了“桥接模式”，并勾选“复制物理网络连接状态”。对于虚拟机网速特别慢的问题，常见原因是桥接网卡选择错误，可以在虚拟机设置里把网卡类型改为 e1000e 或 vmxnet3 试试，不同平台支持情况不同。

4.4 安装 Python 和基础依赖

在 VM 内部安装 Python 和 Agent 框架依赖。多智能体项目建议使用虚拟环境管理 Python 版本，避免污染系统 Python。示例操作：

sudo apt update sudo apt install -y python3-pip python3-venv git curl mkdir -p ~/multi-agent && cd ~/multi-agent python3 -m venv venv source venv/bin/activate pip install --upgrade pip

如果涉及多个 VM，建议在每个 VM 中都采用同样的流程，并把依赖写入requirements.txt，这样整套环境可以通过脚本批量拉起。对多智能体开发来说，依赖可复现比什么都重要。

4.5 验证 VM 之间网络互通

假设你已经创建了两台 Ubuntu 虚拟机 VM-Agent-A 和 VM-Agent-B，且都处于桥接模式或 Host-Only 网络，用 ping 命令验证互通：

# 在 VM-Agent-A 中执行 ping -c 4 <VM-Agent-B 的 IP>

如果 ping 不通，优先检查两个 VM 是否在同一网段，防火墙是否拦截，以及 VMware 虚拟网络编辑器中的 DHCP 设置是否正确。这一步没有打通，后面 Agent 之间的通信就无从谈起。

到这里，你的多智能体实验环境已经具备雏形：一台或多台 Ubuntu 虚拟机，每台都有独立的系统环境，虚拟机之间可以通信。下一步就可以写多智能体协作代码了。

5. 多智能体协作示例：正反博弈 + 裁判的 Python 实现

有了 VM 环境，接下来写一个最小可运行的多智能体协作示例。这里采用“正反博弈 + 裁判”模式：两个 Agent 分别扮演“正方”和“反方”，针对同一个问题分别给出观点并互相反驳，最后由裁判 Agent 综合双方观点给出最终结论。

这是一个非常经典的多智能体协作模式，代码量不大，但能完整展示多个 Agent 之间如何分工、如何通信、如何汇聚结果。考虑到大多数读者还没有接大模型 API，示例先不做真实模型调用，而是用模拟函数代替，方便你直接跑通流程。接入真实模型的改造方法在后面说明。

5.1 项目文件结构

multi-agent-demo/ ├── main.py # 主控程序，编排整个协作流程 ├── agents/ │ ├── __init__.py │ ├── debater.py # 正反方 Agent │ └── judge.py # 裁判 Agent ├── requirements.txt # 依赖清单 └── README.md # 使用说明

5.2 正反方 Agent 实现

debater.py定义了一个DebaterAgent类，它接受name和stance两个参数。name区分不同的 Agent 实例，stance表示立场，取pro（正方）或con（反方）。

# 文件路径：multi-agent-demo/agents/debater.py class DebaterAgent: """正反方 Agent，负责生成观点和反驳对方观点。""" def __init__(self, name: str, stance: str): self.name = name self.stance = stance def generate_opening(self, topic: str) -> str: """生成开场观点。 这里用规则函数模拟真实模型的输出， 接入大模型 API 时只需替换方法内部实现。 """ if self.stance == "pro": return f"[{self.name}] 支持“{topic}”。理由：它能提升效率、降低人工成本。" return f"[{self.name}] 反对“{topic}”。理由：它存在风险，需要审慎评估。" def rebuttal(self, topic: str, opponent_opening: str) -> str: """反驳对方观点。""" if self.stance == "pro": return ( f"[{self.name}] 反驳：对方说“{opponent_opening}”，" "但风险可以通过规范化管理来控制。" ) return ( f"[{self.name}] 反驳：对方说“{opponent_opening}”，" "但效率提升不能掩盖潜在副作用。" )

5.3 裁判 Agent 实现

judge.py定义了一个JudgeAgent，它接收正方和反方的观点列表，然后给出最终结论。同样的，这里用规则函数模拟裁判行为。

# 文件路径：multi-agent-demo/agents/judge.py class JudgeAgent: """裁判 Agent，综合正反双方观点给出最终结论。""" def __init__(self, name: str = "judge"): self.name = name def decide(self, topic: str, pro_arguments: list, con_arguments: list) -> str: """综合正反方观点，生成最终结论。""" pro_count = len(pro_arguments) con_count = len(con_arguments) total = pro_count + con_count if total == 0: return f"[{self.name}] 没有收到有效观点，无法裁决。" return ( f"[{self.name}] 结合“{topic}”的正反双方观点，" f"正方提出 {pro_count} 条论据，反方提出 {con_count} 条论据。" "最终倾向：在控制风险的前提下，可以尝试推进，但需持续评估。" )

5.4 主控程序实现

main.py负责创建 Agent 实例，编排对话流程。它模拟了多智能体协作的完整闭环：先让正方和反方各自生成开场观点，再让双方互相反驳一轮，最后收集所有观点交给裁判 Agent 裁决。

# 文件路径：multi-agent-demo/main.py from agents.debater import DebaterAgent from agents.judge import JudgeAgent def run_debate(topic: str): """调度正反方与裁判的协作流程。""" pro = DebaterAgent(name="agent-pro", stance="pro") con = DebaterAgent(name="agent-con", stance="con") judge = JudgeAgent(name="judge") print("==== 多智能体协作开始 ====") print(f"辩题：{topic}") print() # 第一步：双方生成开场观点 pro_opening = pro.generate_opening(topic) con_opening = con.generate_opening(topic) print(pro_opening) print(con_opening) print() # 第二步：双方互相反驳一轮 pro_rebuttal = pro.rebuttal(topic, con_opening) con_rebuttal = con.rebuttal(topic, pro_opening) print(pro_rebuttal) print(con_rebuttal) print() # 第三步：裁判综合所有观点给出结论 final_decision = judge.decide( topic, pro_arguments=[pro_opening, pro_rebuttal], con_arguments=[con_opening, con_rebuttal], ) print(final_decision) print("==== 多智能体协作结束 ====") if __name__ == "__main__": run_debate("是否应该在企业中推行 AI 自动化流程")

5.5 依赖清单

requirements.txt中当前只需要很少的依赖，保留它是为了方便以后接入真实模型扩展：

# 文件路径：multi-agent-demo/requirements.txt # 当前版本为最小示例，暂无第三方强依赖 # 后续接入 openai / requests 时在此追加

5.6 API 接入思路

上面的示例用固定字符串模拟了模型输出。在实际项目中，把generate_opening和rebuttal方法内部改成调用大模型 API 即可。以 OpenAI 接口为例，改造后的generate_opening大致如下：

import os from openai import OpenAI client = OpenAI(api_key=os.getenv("OPENAI_API_KEY")) def generate_opening_with_llm(self, topic: str) -> str: if self.stance == "pro": prompt = f"你支持“{topic}”，请给出三条有说服力的理由。" else: prompt = f"你反对“{topic}”，请给出三条有说服力的理由。" resp = client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}], temperature=0.7, ) return f"[{self.name}] {resp.choices[0].message.content.strip()}"

如果你使用的是其他模型服务，把client的初始化参数换成对应的服务地址和 API Key 即可。需要提醒的是，API Key 必须通过环境变量或密钥管理服务加载，不要硬编码在代码里。

5.7 运行代码

在 VM 中进入项目目录，激活虚拟环境，执行：

cd ~/multi-agent-demo source ../venv/bin/activate # 如果 venv 在上一级目录 python main.py

运行后预期输出类似：

==== 多智能体协作开始 ==== 辩题：是否应该在企业中推行 AI 自动化流程 [agent-pro] 支持“是否应该在企业中推行 AI 自动化流程”。理由：它能提升效率、降低人工成本。 [agent-con] 反对“是否应该在企业中推行 AI 自动化流程”。理由：它存在风险，需要审慎评估。 [agent-pro] 反驳：对方说“[agent-con] 反对“是否应该在企业中推行 AI 自动化流程”。理由：它存在风险，需要审慎评估。”，但风险可以通过规范化管理来控制。 [agent-con] 反驳：对方说“[agent-pro] 支持“是否应该在企业中推行 AI 自动化流程”。理由：它能提升效率、降低人工成本。”，但效率提升不能掩盖潜在副作用。 [judge] 结合“是否应该在企业中推行 AI 自动化流程”的正反双方观点，正方提出 2 条论据，反方提出 2 条论据。最终倾向：在控制风险的前提下，可以尝试推进，但需持续评估。 ==== 多智能体协作结束 ====

如果看到这个输出，说明最小多智能体协作流程已经跑通。

6. VM 环境下的资源隔离、快照与多 Agent 管理

多智能体示例跑通之后，下一步要思考的是：怎么在多 VM 环境中管理多个 Agent。这直接对应到 VM 的核心能力：快照、克隆和资源限制。

6.1 快照：多智能体调试的后悔药

VM 快照是虚拟机在某个时间点的完整状态保存。多智能体系统调试时，Agent 的代码可能会修改系统文件、安装各种依赖，甚至把环境改坏。有了快照，出问题后可以一键恢复到之前可用的状态。

操作路径很简单：

1. 在 Agent 代码跑通后，立即创建一个快照，命名为“baseline-v1”。
2. 每次进行大版本改动前，再创建一个快照。
3. 环境出问题时，直接恢复到最近可用的快照。

这种做法能显著降低实验成本。容器环境虽然也有镜像分层，但 VM 快照的“整机回滚”能力在系统级环境修复上更直接。

6.2 克隆：快速拉起多个 Agent 环境

如果要在一个四虚拟机架构里跑四个不同角色的 Agent，不需要一台一台安装系统。以一台配置好的 Ubuntu VM 为模板，使用“克隆 - 完整克隆”功能，几分钟内就能复制出多台环境。克隆完成后，需要修改的内容包括：主机名、IP 地址、SSH 密钥、Agent 实例的name参数。这样一台模板 VM 可以演化出多个角色不同的 Agent 运行环境。

6.3 资源限制：避免一个 Agent 拖垮整个集群

VM 的 CPU 和内存可以在 VMware 设置中单独分配。推荐的做法是：给承担实时交互的 Agent 分配更多内存，给离线运行的 Agent 分配较少内存。比如：

这个表格只是参考，具体要根据宿主机资源调整。资源配额的好处是：假如某个 Agent 内存溢出或 CPU 被打满，其他 VM 不会受影响。

6.4 多 Agent 通信的安全边界

当多个 Agent 分布在不同的 VM 上，它们之间的通信就变成了网络通信。这意味着要开始考虑认证和防火墙。最简单的方案是：VM 之间通过内部虚拟网络通信，不暴露到宿主机外部网络；通信接口使用随机 Token 做简单认证；不要让开发调试用的 Agent 端口对外网开放。

这里要特别强调一个安全底线：如果你准备把多智能体系统接入真实生产环境，涉及任何权限操作、数据删除、外部资源访问，都必须先在测试环境验证，遵循最小权限原则，并准备好回滚方案。多智能体系统的自主性越强，越需要在设计上加入人和护栏。

7. 常见问题与排查思路

整理几个高频问题，都是 VM 多智能体环境中容易踩的坑。

排查顺序建议从底层到上层：先看网络通不通，再看依赖环境对不对，最后看 Agent 代码逻辑。网络问题占了 VM 多智能体环境排障的大头，值得优先掌握。

8. 多智能体 VM 协作的最佳实践与工程建议

多智能体项目从 demo 走到工程化，需要建立一套自己的规范。整理几条实践建议：

依赖环境必须版本化。每一台 VM 的 Python 版本、关键依赖、环境变量都要写进文档或配置脚本。至少保证：新人拿到你的脚本，能在半天内还原一套可运行的多智能体环境。

VM 命名规范要统一。推荐格式：vm-角色-用途，例如vm-agent-debater、vm-judge-api。命名混乱在多 VM 场景下会很快失控。

Agent 之间的通信接口要事先定义好。消息格式使用 JSON 统一，字段包括agent_name、message_type、payload、timestamp。接口先定下来，再写内部逻辑，避免后面联调时反复改协议。

日志必须标准化。每个 Agent 的日志要能区分是哪个 VM、哪个 Agent、哪一轮调用。建议格式：时间 | VM 名称 | Agent 名称 | 事件类型 | 详情。

注意安全边界。多智能体系统一旦接入了真实业务系统和外部工具，它的行为会对真实环境产生作用。必须为 Agent 设置权限边界，使用只读账号、测试环境、沙箱、人工审批等方式控制风险。任何涉及删除、写入、支付、生产配置变更的操作，都要有最小权限和回滚方案。

定时备份 VM 状态。除了手动快照，还可以设置定时任务定期创建快照，或者用脚本备份关键配置文件。重要数据不要只留在 VM 里，单独同步到宿主机或远端存储。

9. 总结与接下来可以怎么深入

这篇文章从多智能体协作的环境痛点切入，解释了为什么 VM 是多智能体项目值得考虑的底座方案，然后完整走了一遍环境搭建流程，包含 Ubuntu 虚拟机安装、网络配置、Python 环境准备、多智能体通信验证，最后用“正反博弈 + 裁判”的 Python 示例跑通了最小协作闭环。

几点核心收获可以再强调一遍：

第一，多智能体项目的难点不在单个 Agent，而在多个 Agent 的隔离、通信和可复现。VM 是处理这类问题的有效底座之一。

第二，环境问题要多从虚拟机网络和依赖管理两个方向排查，这两类问题占了多智能体环境踩坑的大多数。

第三，正反博弈 + 裁判是一种简单有效的多智能体协作设计，代码框架清楚后，替换成真实模型调用和多轮对话并不复杂。

下一步可以考虑的方向：给示例接入真实大模型 API，增加多轮辩论而不是一轮反驳；把 Agent 通信从函数调用改成 HTTP 或消息队列，模拟真实分布式场景；尝试在多个 VM 上分别部署不同 Agent，用网络通信替代同一个进程内的直接调用。

如果你正打算开始多智能体项目，建议先按这篇文章的最小示例跑通一遍，再决定要不要上多 VM 架构。从单机原型到多 VM 分布式，是一步一步演进的过程。希望这篇分享能帮你少踩一些环境配置的坑。