企业官网建设流程全解析

AutoGPT Platform 本地部署与运维实战：docker compose 一键启动、核心服务拓扑与 Makefile 开发工作流

【免费下载链接】AutoGPTAutoGPT is the vision of accessible AI for everyone, to use and to build on. Our mission is to provide the tools, so that you can focus on what matters.项目地址: https://gitcode.com/GitHub_Trending/au/AutoGPT

本文基于 AutoGPT 仓库中的autogpt_platform/README.md展开，系统讲解 AutoGPT Platform 的本地运行方法：Docker Compose 一键启动、Makefile提供的核心服务工作流、常用 compose 运维场景（重建单服务、扩缩容、日志排障等）、PostgreSQL/Redis 数据持久化方案，以及前端 API 客户端的生成流程。读完并结合仓库内docker-compose.yml、docker-compose.platform.yml、Makefile的源码级剖析，你可以独立完成 Platform 的部署、日常运维和前后端联调。

一、AutoGPT Platform 是什么

AutoGPT Platform 是一个用于创建和运行 AI Agent 的系统，帮助使用者通过人工智能自动化任务、分析数据并为组织产出洞察（autogpt_platform/README.md）。从仓库结构看，它由backend（Python/FastAPI 多进程后端）、frontend（Next.js 前端）以及一组基础设施服务（Postgres、Redis Cluster、RabbitMQ、FalkorDB、ClamAV）组成，整体通过 Docker Compose 编排。

二、前置条件与一键启动

2.1 前置条件

• Docker
• Docker Compose V2（Docker Desktop 自带，也可单独安装）

2.2 启动步骤

1. 克隆仓库并进入autogpt_platform目录：

   git clone https://gitcode.com/GitHub_Trending/au/AutoGPT cd AutoGPT/autogpt_platform

2. 复制默认环境文件：

   cp .env.default .env

   该命令把 .env.default 复制为.env，之后可以在.env中修改自己的环境变量。当前仓库的autogpt_platform/.env.default记录的是 Postgres 连接信息：

   # 警告：上线生产环境前必须修改密码 POSTGRES_HOST=db POSTGRES_DB=postgres POSTGRES_PORT=5432 # 默认用户是 postgres POSTGRES_PASSWORD=your-super-secret-and-long-postgres-password

   文件内注释特别强调：如果修改了 docker-compose.yml 中db服务的硬编码凭据，必须同步更新docker-compose.platform.yml的DATABASE_URL/DIRECT_URL、backend/.env(.default)和frontend/.env(.default)，多处凭据需要保持一致。

3. 启动全部服务：

   docker compose up -d

   该命令以分离（detached）模式启动 docker-compose.yml 中定义的所有后端服务。

4. 等待所有服务进入 ready 状态后，浏览器访问http://localhost:3000即可打开 AutoGPT Platform 前端。

三、docker-compose 背后的真实服务拓扑

docker-compose.yml本身是一个“组合文件”：它声明了app-network/shared-network两张网络与clamav-data、workspace-data、falkordb_data三个命名卷，其余服务均通过extends继承自 docker-compose.platform.yml。理解这套组合方式，是排障与二次部署的关键。

3.1 服务清单与端口

从两份 compose 文件可以整理出如下服务/端口对应关系（均定义在 docker-compose.platform.yml）：

后端各服务的启动命令对应 backend/pyproject.toml 中[tool.poetry.scripts]注册的入口：rest = "backend.rest:main"、ws = "backend.ws:main"、executor = "backend.exec:main"、db = "backend.db:main"、scheduler = "backend.scheduler:main"、notification = "backend.notification:main"等，与 backend/rest.py、backend/ws.py 等源码一一对应。

3.2 启动顺序：healthcheck 与 depends_on 级联

这套编排的核心是“健康检查门控”：

• migrate一次性容器执行prisma generate && python3 scripts/gen_prisma_types_stub.py && prisma migrate deploy，只有当prisma migrate status输出 “No pending migrations” 才算健康；所有后端服务都依赖migrate: service_completed_successfully。
• db（Postgres）依赖rabbitmq: service_healthy。compose 文件中的注释解释了原因：在 E2B 的 Docker 环境中，容器并发创建会与 RabbitMQ 的.erlang.cookie写入产生竞态，导致 broker 启动eacces错误；由于其余服务全部间接依赖db，只门控db一个点即可级联到整个堆栈。
• rest_server、executor等还依赖redis-0: service_healthy（检查cluster info中cluster_state:ok）。

从源码结构看，Redis 被刻意做成cache-only 的三主集群：redis-0/1/2各自挂载--cluster-announce-hostname暴露自己的 compose 主机名，redis-init一次性 sidecar 执行redis-cli --cluster create建集群（幂等：若集群已ok则直接跳过）。compose 注释明确指出不给 Redis 挂卷——只持久化 seed 节点是陷阱，因为其余分片重启后节点 ID 变化，seed 的nodes.conf会钉住过期 peer 而无法自愈。

3.3 环境变量加载顺序

docker-compose.platform.yml 顶部用注释写明了 5 层加载顺序（后者覆盖前者）：

1. backend/.env.default—— 所有设置的默认值
2. backend/.env—— 用户自定义配置（可选，required: false）
3. compose 中的environment键 —— Docker 专用覆盖（把 localhost 换成容器内服务名，如DB_HOST: db、REDIS_HOST: redis-0、REDIS_PORT: "17000"）
4. Shell 环境变量
5. docker compose run -e VAR=value命令行参数

其中DATABASE_URL形如postgresql://postgres:...@db:5432/postgres?connect_timeout=60&schema=platform，说明业务表落在platformschema；前端服务则被注入AGPT_SERVER_URL: http://rest_server:8006/api与AGPT_WS_SERVER_URL: ws://websocket_server:8001/ws，用于容器内访问后端。

四、只启动核心服务：Makefile 工作流

当只需要 Postgres + Redis + RabbitMQ 这类基础组件（例如本地跑后端/前端做开发联调）时，可以借助 Makefile：

# 查看全部目标 make help # 只启动 Postgres + Redis + RabbitMQ make start-core # 停止核心服务 make stop-core # 查看核心服务日志 make logs-core # 对后端和前端做格式化与 lint make format # 运行后端数据库迁移 make migrate # 运行后端服务器 make run-backend # 运行前端开发服务器 make run-frontend

结合 Makefile 源码，这些目标的实际实现是：

• start-core=docker compose up -d deps。deps是一个profile: local的 busybox 空容器，唯一作用是depends_on拉起 db、redis-0/1/2、redis-init、rabbitmq、clamav、falkordb、migrate 这一串依赖；
• logs-core=docker compose logs -f deps；
• migrate=cd backend && poetry run prisma migrate deploy+prisma generate+gen-prisma-stub，即 Prisma 迁移落地后重新生成类型与 stub；
• run-backend=cd backend && poetry run app（对应backend.app:main）；
• run-frontend=cd frontend && pnpm dev。注意当前 frontend/package.json 中dev脚本定义为pnpm run generate:api:force && next dev --turbo，即每次启动前端开发服务器都会先强制刷新 API 客户端再启动 Next.js；
• 另有 README 未列出的实用目标：reset-db（停 db、删除data/db/data、重新执行迁移与 Prisma 生成）、init-env（幂等地复制三个目录的.env.default）、test-data、load-store-agents。

五、Docker Compose 常用命令与典型运维场景

日常可用的 compose 命令：

• docker compose up -d：分离模式启动服务
• docker compose stop：停止服务但保留容器
• docker compose rm：删除已停止的容器
• docker compose build：构建或重建服务
• docker compose down：停止并删除容器、网络与卷
• docker compose watch：监听代码变更并自动更新服务

下面是 README 给出的六个组合场景，覆盖了绝大多数运维动作：

1. 更新并重启单个服务（例如重建api_srv且不影响其他服务）：

   docker compose build api_srv docker compose up -d --no-deps api_srv

2. 查看日志排障（同时跟踪api_srv与ws_srv）：

   docker compose logs -f api_srv ws_srv

3. 扩容服务应对负载（把executor扩到 3 个实例）：

   docker compose up -d --scale executor=3

   当前拓扑中executor依赖 Redis、RabbitMQ 与database_manager，横向扩展实例数即可分散图执行压力。

4. 整系统停机维护后全新拉起：

   docker compose stop docker compose rm -f docker compose pull docker compose up -d

5. 开发模式热更新：

   docker compose watch

   每个后端服务在 compose 中都声明了develop.watch规则：监听autogpt_platform/backend/（migrate只监听migrations/）变化并触发rebuild，因此代码改动会自动反映到容器。

6. 检查服务状态：

   docker compose ps

六、数据持久化：PostgreSQL 与 Redis

README 给出为 PostgreSQL 和 Redis 添加命名卷的通用做法：在docker-compose.yml中为对应服务追加volumes：

services: postgres: # ... 其他配置 ... volumes: - postgres_data:/var/lib/postgresql/data redis: # ... 其他配置 ... volumes: - redis_data:/data volumes: postgres_data: redis_data:

保存后执行docker compose up -d应用，即可保证数据在容器重启后仍然保留。

需要指出的是，当前仓库的实际配置已经比 README 的示例更进一步：

• Postgres：docker-compose.yml 的db服务已把数据目录挂载到宿主机的./data/db/data:/var/lib/postgresql/data，并在首次初始化（新卷）时自动执行 db/init/00-init.sql，创建platformschema 及兼容历史 Prisma 迁移的 legacyauth.users结构；
• FalkorDB：已挂载falkordb_data:/data命名卷；
• ClamAV：挂载clamav-data:/var/lib/clamav保存病毒特征库；
• 工作区文件：rest_server与copilot_executor共享workspace-data:/app/autogpt_platform/backend/workspaces卷；
• Redis：如上所述，按 cache-only 设计刻意不挂卷，每次up都是全新集群。

因此在本仓库上直接make reset-db或rm掉data/db/data即可彻底重置数据库（这正是 Makefile 中reset-db目标的做法）。

七、前端 API 客户端生成（OpenAPI + Orval）

README 描述了平台内置的 API 客户端生成脚本：

• pnpm fetch:openapi：从后端服务拉取 OpenAPI 规范（要求后端运行在 8006 端口）
• pnpm generate:api-client：用 Orval 从 OpenAPI 规范生成 TypeScript API 客户端
• pnpm generate:api：顺序执行上述两步

对应的实操流程：修改后端 API 后，确保服务在运行（docker compose up -d），然后重新生成客户端即可获得最新的 TypeScript 类型与请求封装。

以当前仓库代码为准的补充：在当前的 frontend/package.json 中，这些步骤已整合为两个脚本：

"generate:api": "npx --yes tsx ./scripts/generate-api-queries.ts && orval --config ./orval.config.ts", "generate:api:force": "npx --yes tsx ./scripts/generate-api-queries.ts --force && orval --config ./orval.config.ts"

其中 frontend/scripts/generate-api-queries.ts 负责从后端${baseUrl}/openapi.json（即rest_server的 8006 端口）拉取规范并写入本地./src/app/api/openapi.json；本地已有规范时默认复用，加--force才会强制重新拉取。随后 orval.config.ts 以该openapi.json为input.target生成客户端代码。后端侧则通过 backend/pyproject.toml 中的export-api-schema（backend.cli.generate_openapi_json:main）导出完整 OpenAPI 文档。开发工作流中pnpm dev默认走generate:api:force，等价于 README 中“修改后端后执行一次完整再生成”的操作。

八、小结

AutoGPT Platform 的本地运行路径非常清晰：cp .env.default .env→docker compose up -d→ 访问http://localhost:3000；开发侧则用make start-core起基础组件、make migrate落地迁移、make run-backend/make run-frontend本地联调。深入 docker-compose.platform.yml 可以看到一套以migrate一次性容器和 healthcheck 门控为核心的启动编排、cache-only Redis Cluster 的取舍，以及 5 层环境变量覆盖机制；而 Makefile 与前端generate:api:force脚本则把“迁移 → 生成 → 联调”的日常循环压缩成了单条命令。掌握了这些配置与命令的底层依据，即可在只读仓库之上完成部署、扩容、排障和 API 客户端的再生成。

【免费下载链接】AutoGPTAutoGPT is the vision of accessible AI for everyone, to use and to build on. Our mission is to provide the tools, so that you can focus on what matters.项目地址: https://gitcode.com/GitHub_Trending/au/AutoGPT