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。从仓库结构看它由backendPython/FastAPI 多进程后端、frontendNext.js 前端以及一组基础设施服务Postgres、Redis Cluster、RabbitMQ、FalkorDB、ClamAV组成整体通过 Docker Compose 编排。二、前置条件与一键启动2.1 前置条件DockerDocker Compose V2Docker Desktop 自带也可单独安装2.2 启动步骤克隆仓库并进入autogpt_platform目录git clone https://gitcode.com/GitHub_Trending/au/AutoGPT cd AutoGPT/autogpt_platform复制默认环境文件cp .env.default .env该命令把 .env.default 复制为.env之后可以在.env中修改自己的环境变量。当前仓库的autogpt_platform/.env.default记录的是 Postgres 连接信息# 警告上线生产环境前必须修改密码 POSTGRES_HOSTdb POSTGRES_DBpostgres POSTGRES_PORT5432 # 默认用户是 postgres POSTGRES_PASSWORDyour-super-secret-and-long-postgres-password文件内注释特别强调如果修改了 docker-compose.yml 中db服务的硬编码凭据必须同步更新docker-compose.platform.yml的DATABASE_URL/DIRECT_URL、backend/.env(.default)和frontend/.env(.default)多处凭据需要保持一致。启动全部服务docker compose up -d该命令以分离detached模式启动 docker-compose.yml 中定义的所有后端服务。等待所有服务进入 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服务容器内端口说明frontend3000Next.js 前端target: prod构建同时内嵌 Better Auth 服务直接连接 Postgreswebsocket_server8001WebSocket 服务入口backend.ws:mainexecutor8002图执行器入口backend.exec:mainscheduler_server8003定时调度服务database_manager8005数据库管理服务rest_server8006REST API 主服务OpenAPI 文档也由此导出notification_server8007通知服务copilot_executor8008Copilot 执行器platform_linking_manager8009平台关联管理器属于botprofile默认不启动db5432Postgrespgvector/pgvector:pg15rabbitmq5672消息队列rabbitmq:4.1.4redis-0/1/217000/17001/17002三主节点本地 Redis Clusterfalkordb6380宿主机→6379Graphiti 图数据库Web UI 在 3001clamav3310ClamAV 恶意文件扫描后端各服务的启动命令对应 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。dbPostgres依赖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 层加载顺序后者覆盖前者backend/.env.default—— 所有设置的默认值backend/.env—— 用户自定义配置可选required: falsecompose 中的environment键 —— Docker 专用覆盖把 localhost 换成容器内服务名如DB_HOST: db、REDIS_HOST: redis-0、REDIS_PORT: 17000Shell 环境变量docker compose run -e VARvalue命令行参数其中DATABASE_URL形如postgresql://postgres:...db:5432/postgres?connect_timeout60schemaplatform说明业务表落在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-coredocker compose up -d deps。deps是一个profile: local的 busybox 空容器唯一作用是depends_on拉起 db、redis-0/1/2、redis-init、rabbitmq、clamav、falkordb、migrate 这一串依赖logs-coredocker compose logs -f depsmigratecd backend poetry run prisma migrate deployprisma generategen-prisma-stub即 Prisma 迁移落地后重新生成类型与 stubrun-backendcd backend poetry run app对应backend.app:mainrun-frontendcd 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 给出的六个组合场景覆盖了绝大多数运维动作更新并重启单个服务例如重建api_srv且不影响其他服务docker compose build api_srv docker compose up -d --no-deps api_srv查看日志排障同时跟踪api_srv与ws_srvdocker compose logs -f api_srv ws_srv扩容服务应对负载把executor扩到 3 个实例docker compose up -d --scale executor3当前拓扑中executor依赖 Redis、RabbitMQ 与database_manager横向扩展实例数即可分散图执行压力。整系统停机维护后全新拉起docker compose stop docker compose rm -f docker compose pull docker compose up -d开发模式热更新docker compose watch每个后端服务在 compose 中都声明了develop.watch规则监听autogpt_platform/backend/migrate只监听migrations/变化并触发rebuild因此代码改动会自动反映到容器。检查服务状态docker compose ps六、数据持久化PostgreSQL 与 RedisREADME 给出为 PostgreSQL 和 Redis 添加命名卷的通用做法在docker-compose.yml中为对应服务追加volumesservices: postgres: # ... 其他配置 ... volumes: - postgres_data:/var/lib/postgresql/data redis: # ... 其他配置 ... volumes: - redis_data:/data volumes: postgres_data: redis_data:保存后执行docker compose up -d应用即可保证数据在容器重启后仍然保留。需要指出的是当前仓库的实际配置已经比 README 的示例更进一步Postgresdocker-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 OrvalREADME 描述了平台内置的 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-schemabackend.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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 AutoGPT Platform 本地部署与运维实战：docker compose 一键启动、核心服务拓扑与 Makefile 开发工作流
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。从仓库结构看它由backendPython/FastAPI 多进程后端、frontendNext.js 前端以及一组基础设施服务Postgres、Redis Cluster、RabbitMQ、FalkorDB、ClamAV组成整体通过 Docker Compose 编排。二、前置条件与一键启动2.1 前置条件DockerDocker Compose V2Docker Desktop 自带也可单独安装2.2 启动步骤克隆仓库并进入autogpt_platform目录git clone https://gitcode.com/GitHub_Trending/au/AutoGPT cd AutoGPT/autogpt_platform复制默认环境文件cp .env.default .env该命令把 .env.default 复制为.env之后可以在.env中修改自己的环境变量。当前仓库的autogpt_platform/.env.default记录的是 Postgres 连接信息# 警告上线生产环境前必须修改密码 POSTGRES_HOSTdb POSTGRES_DBpostgres POSTGRES_PORT5432 # 默认用户是 postgres POSTGRES_PASSWORDyour-super-secret-and-long-postgres-password文件内注释特别强调如果修改了 docker-compose.yml 中db服务的硬编码凭据必须同步更新docker-compose.platform.yml的DATABASE_URL/DIRECT_URL、backend/.env(.default)和frontend/.env(.default)多处凭据需要保持一致。启动全部服务docker compose up -d该命令以分离detached模式启动 docker-compose.yml 中定义的所有后端服务。等待所有服务进入 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服务容器内端口说明frontend3000Next.js 前端target: prod构建同时内嵌 Better Auth 服务直接连接 Postgreswebsocket_server8001WebSocket 服务入口backend.ws:mainexecutor8002图执行器入口backend.exec:mainscheduler_server8003定时调度服务database_manager8005数据库管理服务rest_server8006REST API 主服务OpenAPI 文档也由此导出notification_server8007通知服务copilot_executor8008Copilot 执行器platform_linking_manager8009平台关联管理器属于botprofile默认不启动db5432Postgrespgvector/pgvector:pg15rabbitmq5672消息队列rabbitmq:4.1.4redis-0/1/217000/17001/17002三主节点本地 Redis Clusterfalkordb6380宿主机→6379Graphiti 图数据库Web UI 在 3001clamav3310ClamAV 恶意文件扫描后端各服务的启动命令对应 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。dbPostgres依赖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 层加载顺序后者覆盖前者backend/.env.default—— 所有设置的默认值backend/.env—— 用户自定义配置可选required: falsecompose 中的environment键 —— Docker 专用覆盖把 localhost 换成容器内服务名如DB_HOST: db、REDIS_HOST: redis-0、REDIS_PORT: 17000Shell 环境变量docker compose run -e VARvalue命令行参数其中DATABASE_URL形如postgresql://postgres:...db:5432/postgres?connect_timeout60schemaplatform说明业务表落在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-coredocker compose up -d deps。deps是一个profile: local的 busybox 空容器唯一作用是depends_on拉起 db、redis-0/1/2、redis-init、rabbitmq、clamav、falkordb、migrate 这一串依赖logs-coredocker compose logs -f depsmigratecd backend poetry run prisma migrate deployprisma generategen-prisma-stub即 Prisma 迁移落地后重新生成类型与 stubrun-backendcd backend poetry run app对应backend.app:mainrun-frontendcd 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 给出的六个组合场景覆盖了绝大多数运维动作更新并重启单个服务例如重建api_srv且不影响其他服务docker compose build api_srv docker compose up -d --no-deps api_srv查看日志排障同时跟踪api_srv与ws_srvdocker compose logs -f api_srv ws_srv扩容服务应对负载把executor扩到 3 个实例docker compose up -d --scale executor3当前拓扑中executor依赖 Redis、RabbitMQ 与database_manager横向扩展实例数即可分散图执行压力。整系统停机维护后全新拉起docker compose stop docker compose rm -f docker compose pull docker compose up -d开发模式热更新docker compose watch每个后端服务在 compose 中都声明了develop.watch规则监听autogpt_platform/backend/migrate只监听migrations/变化并触发rebuild因此代码改动会自动反映到容器。检查服务状态docker compose ps六、数据持久化PostgreSQL 与 RedisREADME 给出为 PostgreSQL 和 Redis 添加命名卷的通用做法在docker-compose.yml中为对应服务追加volumesservices: postgres: # ... 其他配置 ... volumes: - postgres_data:/var/lib/postgresql/data redis: # ... 其他配置 ... volumes: - redis_data:/data volumes: postgres_data: redis_data:保存后执行docker compose up -d应用即可保证数据在容器重启后仍然保留。需要指出的是当前仓库的实际配置已经比 README 的示例更进一步Postgresdocker-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 OrvalREADME 描述了平台内置的 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-schemabackend.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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考