第二章：系统环境与依赖管理
说实话，很多做量化交易的朋友，最后代码跑不起来，不是策略有问题，而是环境崩了。我见过太多人，在本地跑得好好的，一上服务器就各种报错。嗯，这章我们就来解决这个问题。
2.1 Python虚拟环境搭建
Python的依赖管理，说白了就是「隔离」两个字。你想想看，一个项目用TensorFlow 1.x，另一个用2.x，装在一起肯定打架。虚拟环境就是给每个项目一个独立的小房间。
我个人习惯用 venv，因为它是Python自带的，不需要额外装东西。但如果你团队里有人用Windows，有人用Mac，那我建议你直接用 conda，跨平台兼容性好很多。
核心原则：每个交易策略项目，都应该有自己的虚拟环境。别偷懒共用。
创建虚拟环境其实就一行命令：
# 用 venv
python -m venv trading_env
# 激活（Linux/Mac）
source trading_env/bin/activate
# 激活（Windows）
trading_env\Scripts\activate激活后，你的终端前面会出现 (trading_env) 字样。看到这个，就说明环境隔离成功了。
小技巧：我习惯在项目根目录下建一个 .venv 文件夹，然后用 .gitignore 把它忽略掉。这样既不影响版本控制，又能保证每个人拉代码后自己重建环境。
2.2 依赖包管理：Poetry vs Conda
这里我踩过不少坑。早期我用 pip freeze > requirements.txt，结果发现这玩意儿会把所有依赖的依赖都列出来，版本还锁得死死的。换台机器，经常装不上。
后来我转向了 Poetry。它解决了两个核心问题：
- 依赖解析：自动帮你算好哪些版本能共存
- 锁定文件：
poetry.lock保证所有人装的一模一样
安装Poetry也很简单：
curl -sSL https://install.python-poetry.org | python3 -初始化项目：
poetry new multi_agent_trading
cd multi_agent_trading
poetry add pandas numpy ta-lib
poetry add --dev pytest black看到没？--dev 参数把测试和格式化工具单独放，生产环境不装这些。这个设计很聪明。
但如果你团队里有人用 Conda，那也别硬推Poetry。Conda的优势在于：
- 能管理非Python依赖（比如C++库）
- 对Windows用户更友好
- 环境切换速度更快
我个人建议：纯Python项目用Poetry，涉及C扩展或跨语言依赖用Conda。
注意：千万不要混用pip和conda装同一个包。我曾经这么干过，结果两个版本冲突，调试了整整一天。选一个工具，用到底。
2.3 Docker基础与镜像构建
虚拟环境解决了「同一台机器」的问题。但多智能体系统往往要部署在多台服务器上，这时候Docker就派上用场了。
Docker的核心思想就一句话：把环境和代码打包成一个镜像，到处运行。
我给你们看一个典型的 Dockerfile：
FROM python:3.10-slim
WORKDIR /app
# 先装依赖（利用Docker缓存层）
COPY pyproject.toml poetry.lock ./
RUN pip install poetry && \
poetry config virtualenvs.create false && \
poetry install --no-dev
# 再拷代码
COPY . .
CMD ["python", "main.py"]这里有个细节：先拷依赖文件，再装依赖，最后拷代码。为什么？因为依赖不常变，代码经常改。这样每次构建时，依赖层可以复用缓存，速度能快好几倍。
构建和运行：
docker build -t trading-agent:latest .
docker run -d --name agent1 trading-agent:latest避坑指南：我曾经把整个项目文件夹拷进去再装依赖，结果每次改一行代码都要重装所有包，构建一次20分钟。后来改成上面那种分层构建，时间缩短到30秒。
对于多智能体系统，我一般会建多个Docker镜像：
| 智能体类型 | 基础镜像 | 额外依赖 |
|---|---|---|
| 数据采集智能体 | python:3.10-slim | requests, websocket-client |
| 策略决策智能体 | python:3.10-slim | numpy, pandas, scikit-learn |
| 执行交易智能体 | python:3.10-slim | ccxt, pycryptodome |
每个智能体独立构建、独立部署。这样如果某个智能体挂了，不影响其他模块。
2.4 版本控制（Git）策略
Git这东西，很多人只会 add、commit、push 三板斧。但在多智能体系统里，这远远不够。
我推荐用 Git Flow 策略，但做了简化：
- main 分支：只放生产可用的代码
- develop 分支：日常开发的主战场
- feature/* 分支：每个新功能一个分支
- hotfix/* 分支：线上出问题紧急修复
举个例子，你要开发一个「风险控制智能体」：
git checkout -b feature/risk_agent
# 开发、测试...
git add .
git commit -m "feat: 新增风险控制智能体，支持止损和仓位管理"
git checkout develop
git merge feature/risk_agent这里有个关键点：提交信息要规范。我团队用的是 conventional commits 规范：
| 类型 | 说明 | 示例 |
|---|---|---|
| feat | 新功能 | feat: 新增数据缓存模块 |
| fix | 修复bug | fix: 修复时间戳溢出问题 |
| chore | 杂项 | chore: 更新依赖版本 |
| docs | 文档 | docs: 更新API说明 |
为什么要这么严格？因为多智能体系统涉及多个模块，如果提交信息乱七八糟，回滚的时候根本不知道哪个提交对应哪个功能。
我的习惯：每次提交前，我会先跑一遍测试。如果测试没过，绝对不提交。这个习惯帮我避免了很多次「代码推上去才发现跑不了」的尴尬。
2.5 本章知识体系
下面这张图，是我梳理的本章核心逻辑。你看一眼，就能明白这些工具是怎么配合的：
你看，整个链路很清晰：先在本地用虚拟环境隔离开发，用Poetry或Conda管理依赖，然后通过Docker打包成镜像，最后用Git控制所有代码变更。每一步都环环相扣。
最后提醒一句：别想着「先写代码，环境后面再配」。我见过太多项目，代码写完了，部署的时候发现依赖装不上，最后重写。环境管理，一定要从第一天就开始做。
公众号:蓝海资料掘金营，微信deep3321