AutoGPT AI 智能体平台实战指南：托管版与自托管部署、Docker 架构与许可模型全解析

AutoGPT 是一个用于构建、部署和运行 AI 智能体（AI Agent）的开源平台：你可以用自然语言描述想要达成的结果，也可以在可视化画布上逐步编排每一个执行环节，然后按需、按计划或触发器驱动地运行智能体。本文基于当前仓库的 README.md 展开，并结合 autogpt_platform 的部署文档、Docker Compose 编排文件与安装脚本，系统讲清楚 AutoGPT 的四大产品入口、托管版与自托管两条路线的差异、自托管的完整操作路径与底层服务架构，读完后你可以独立完成一套 AutoGPT Platform 的本地部署与日常运维。

一、一个平台，四个产品入口

README 将 AutoGPT 定位为“让你构建、部署并运行能够完成完整工作流的 AI 智能体”的开源平台。整个产品由四个协同的表面（surfaces）组成，覆盖了从“一句话出智能体”到“逐步精确控制”的完整光谱：

入口	定位	典型用法
AutoPilot	对话式智能体生成	用自然语言描述任务，把对话直接转成一个可运行的智能体
Agents	智能体运行总览	在统一视图中查看所有智能体、运行记录、成本与需要你处理的操作
Marketplace	智能体市场	从经过验证的现成智能体出发，加入自己的库并针对业务做定制
Build	可视化构建画布	拖拽、连接、分支、检查各个 Block，对每个步骤做精确控制

这四张入口图在仓库中的真实截图分别保存在 AutoPilot 界面、Agents 仪表盘、Marketplace 界面 和 Build 画布。

从仓库结构可以印证这四个入口并非纸面概念：

• 前端界面位于 autogpt_platform/frontend，基于 Next.js 构建；
• 智能体执行逻辑由后端 autogpt_platform/backend/executor 等模块承载；
• 仓库还内置了可导入的示例工作流，如 Discord Bot Chat To LLM_v5.json、Medium Blogger_v28.json 等模板文件；
• 后端 blocks 目录 下有三百多个 Block 实现文件，对应 Build 画布中可拖拽的功能单元。

二、两条路线：托管平台 vs 自托管

README 明确区分了使用 AutoGPT 的两条路径，并给出了一张完整的对比表：

	AutoGPT Platform（托管）	Self-hosted（自托管）
获取方式	公开注册即可使用	克隆仓库并自行安装
成本	付费套餐 + 按智能体用量计费	无许可费；基础设施与模型服务商费用由自己承担
部署	官方托管运维	需要 Docker 与环境配置
模型接入	内置，无需准备 API Key	自带模型 API Key
更新与运维	官方负责	自己负责
核心构建器与智能体运行时	包含	包含
数据与基础设施控制	托管在官方基础设施	运行在自己的基础设施上
支持	取决于套餐	社区支持

README 强调：两条路径共用同一个仓库。托管版的付费逻辑在于——每一次智能体运行都消耗真实的模型调用量、算力、存储、密钥管理与运营支持，托管服务覆盖这些基础设施成本，同时反哺开源项目的持续开发；自托管则永远保持无许可费，适合希望自主掌控基础设施的个人和团队。

三、自托管快速开始

3.1 一键安装脚本

官方安装脚本位于 installer 目录：setup-autogpt.sh（macOS / Linux）与 setup-autogpt.bat（Windows）。脚本会自动检查前置依赖、克隆仓库并拉起全部服务。

从 setup-autogpt.sh 头部注释可以看到它支持三个可选参数：

• --with-ollama：额外安装 Ollama，拉取一个默认聊天模型，并写入 backend/.env 使 AutoPilot 在无云端 API Key 的情况下运行（CHAT_USE_LOCAL=true）；
• --ollama-model=NAME：指定要拉取的模型（默认 hf.co/unsloth/Qwen3.5-4B-GGUF:Q4_K_M）；
• --ollama-host=URL：复用已有的 Ollama 服务，跳过本地安装但仍写入本地模型相关的 .env 配置。

3.2 手动 Docker Compose 部署

autogpt_platform/README.md 给出了手动部署的标准流程，前置要求仅为 Docker 与 Docker Compose V2（Docker Desktop 自带，也可单独安装）：

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

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

2. 复制环境变量模板：

   cp .env.default .env
   

   该模板文件确实存在于 autogpt_platform/.env.default，你可以在此追加自己的环境变量（如模型 API Key）。

3. 启动全部服务：

   docker compose up -d
   

   这会以分离模式启动 docker-compose.yml 中定义的所有后端服务。

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

3.3 Makefile 常用命令

autogpt_platform/Makefile 封装了日常开发运维命令，完整目标列表可通过 make help 查看：

make help             # 查看全部目标说明
make init-env         # 为平台、backend、frontend 复制 .env.default 到 .env
make start-core       # 仅启动核心服务（Postgres、Redis、RabbitMQ），后台运行
make stop-core        # 停止核心服务
make logs-core        # 跟踪核心服务日志
make migrate          # 执行 backend 数据库迁移
make format           # 格式化并检查后端（Python）与前端（TypeScript）代码
make run-backend      # 本地运行 FastAPI 后端
make run-frontend     # 本地运行 Next.js 前端开发服务器
make reset-db         # 删除数据库数据卷并重新应用迁移
make test-data        # 运行测试数据生成器

其中 start-core 实际执行 docker compose up -d deps——deps 是 Compose 文件中定义的一个“依赖聚合”服务，详见下一节的架构解析。

3.4 单容器实验性发行版

如果只想要最简单的自托管方式，仓库还提供了 single-container 发行版：单个容器内打包了 Web 应用、各 API 服务、工作进程、PostgreSQL、RabbitMQ、三节点缓存集群以及基于 FalkorDB 的记忆存储，运行数据持久化在 /data 卷中。官方明确标注该形态为实验性，面向本地与小规模自托管场景，不用于高可用部署。其快速启动命令为：

docker run -d \
  --name autogpt \
  --restart unless-stopped \
  --shm-size 2g \
  --ulimit nofile=65536:65536 \
  -p 127.0.0.1:3000:3000 \
  -e AUTOGPT_PUBLIC_URL=http://localhost:3000 \
  -v autogpt-data:/data \
  significantgravitas/autogpt:latest

需要注意的运维要点（均来自 single-container/README.md）：

• 首次启动可能需要数分钟，等容器变为 healthy 后再访问；
• 注册默认开放，上面的回环端口绑定只保证本机可达——若把应用暴露到网络，在你关闭注册前任何人都能注册账号；
• 创建账号后用 docker exec autogpt autogpt-admin promote [e-mail] 将其提升为管理员；
• 之后以 AUTH_ALLOW_NEW_ACCOUNTS=false 重建容器以关闭注册，并保留同一数据卷以持久化账号、智能体与记忆；
• AUTOGPT_PUBLIC_URL 必须与浏览器实际访问的 URL 完全一致；
• 测试环境的启动与稳态健康检查约占用 5–6 GiB 内存（实际取决于启用的服务与负载）。

四、自托管架构深潜：Docker Compose 服务编排

autogpt_platform/docker-compose.yml 采用“薄包装”模式：它只声明网络（app-network、shared-network）与数据卷，各服务通过 extends 继承自 docker-compose.platform.yml 中的真实定义。这套编排可以拆成四类组件：

1. 数据与中间件层

服务	说明
db	PostgreSQL，镜像固定为 pgvector/pgvector:pg15（内置 pgvector 向量扩展），映射主机 5432 端口；启动时挂载 db/init/00-init.sql 创建平台 schema
redis-0/1/2	三节点 Redis 7 集群，端口分别为 17000/17001/17002，本地开发仅作缓存用途，每次 up 均全新构建
redis-init	一次性 sidecar，执行 redis-cli --cluster create 组建集群，且具备幂等短路（集群已 ok 则跳过）
rabbitmq	消息队列（镜像 rabbitmq:4.1.4），映射 5672 端口
falkordb	图数据库，承载记忆功能（Graphiti），映射 6380（数据）与 3001（Web UI）端口
clamav	防病毒扫描服务，映射 3310 端口

2. API 与执行层（均从 backend Dockerfile 构建，命令入口对应 pyproject.toml 中的脚本）

服务	命令	端口
rest_server	rest	8006
executor	executor	8002
copilot_executor	python -m backend.copilot.executor	8008
websocket_server	ws	8001
database_manager	db	8005
scheduler_server	scheduler	8003
notification_server	notification	8007
platform_linking_manager	platform-linking-manager（仅在 bot profile 下启动）	8009
frontend	Next.js 生产构建	3000

3. 启动顺序编排：Compose 文件中有大量 depends_on ... condition: service_healthy / service_completed_successfully 约束。migrate 服务等待 db 健康后执行 prisma generate && prisma migrate deploy，而 rest_server、executor 等业务服务全部依赖 migrate: service_completed_successfully，确保数据库迁移完成前业务进程不会启动。db 本身还等待 rabbitmq 健康——docker-compose.yml 中的注释解释了原因：E2B 环境中并发创建容器会与 RabbitMQ 的 .erlang.cookie 写入竞争，只给 db 加门槛就能级联保护整个启动序列。

4. 依赖聚合服务：deps 与 deps_backend 两个 busybox 空服务（command: /bin/true）仅在 local profile 下生效，分别把“中间件依赖”和“后端服务依赖”聚合成一个可 docker compose up -d deps 的目标——这正是 make start-core 的工作机制。

autogpt_platform/README.md 还给出了六个常用 Compose 运维场景，值得保留在运维手册里：

# 1) 重建并重启单个服务，不影响其他服务
docker compose build api_srv && docker compose up -d --no-deps api_srv

# 2) 同时跟踪多个服务日志
docker compose logs -f api_srv ws_srv

# 3) 横向扩容 executor 应对负载
docker compose up -d --scale executor=3

# 4) 停机维护完整流程：停止 → 移除 → 拉新镜像 → 重启
docker compose stop && docker compose rm -f && docker compose pull && docker compose up -d

# 5) 代码热更新开发
docker compose watch

# 6) 查看全部服务状态
docker compose ps

此外该文档建议通过为 PostgreSQL 与 Redis 添加命名卷（postgres_data、redis_data）实现数据持久化，并提供了 OpenAPI 客户端生成流程：pnpm fetch:openapi（需后端运行在 8006 端口）、pnpm generate:api-client（用 Orval 生成 TypeScript 客户端）与组合命令 pnpm generate:api。

五、配置体系：环境变量的五层加载顺序

autogpt_platform/docker-compose.platform.yml 文件头部用注释显式定义了后端环境变量（首个到末位，后者覆盖前者）：

1. backend/.env.default —— 全部配置项的默认值；
2. backend/.env —— 用户自定义配置（可选）；
3. Compose 的 environment 键 —— Docker 专属覆盖（如容器内服务名）；
4. Shell 环境 —— 运行 docker compose 前导出的变量；
5. CLI 参数 —— docker compose run -e VAR=value。

其中 x-backend-env 锚点把容器网络内的服务名统一注入所有后端服务，例如 DB_HOST=db、REDIS_HOST=redis-0、RABBITMQ_HOST=rabbitmq、JWT_JWKS_URL=http://frontend:3000/api/auth/jwks，并内嵌了 DATABASE_URL 连接串（指向 db:5432/postgres 的 platform schema）。前端容器则反向注入 AGPT_SERVER_URL: http://rest_server:8006/api 与 AGPT_WS_SERVER_URL: ws://websocket_server:8001/ws。这套“默认文件 + 用户覆盖 + 容器网络名”的机制是自托管部署中调试连接问题的核心依据。

六、可以自动化的场景与集成生态

README 给出了六类典型自动化方向，可作为搭建智能体时的选题参考：

领域	示例
高管运营	从内外部信号准备每日简报
销售	会前自动调研每一个客户账号
市场	把发布简报转成跨渠道的活动草稿
工程	事故分诊并给出可能的原因起点
客户支持	起草回复、收集上下文、标记需升级的事项
研究	持续监测信息源，变化时输出结构化报告

集成方面，README 声明 AutoGPT 可连接 45+ 平台（包括 Gmail、Google Calendar、Google Docs、Google Sheets、GitHub、Slack、Discord、Notion、HubSpot、Linear、Airtable、Jira、Salesforce、Stripe、Webflow）以及数百个 AI 模型。在仓库中可以直接核实的证据有：

• docs/integrations/block-integrations 下按集成方组织了 67 个文档目录（如 github/、notion/、slack/、telegram/、discord/ 等），每个目录收录对应 Block 的详细说明；
• 另有 llm-providers 指南 与 语音服务商指南 说明模型与语音侧的接入方式；
• 平台文档 docs/platform 提供了从 getting-started、block-sdk-guide 到 OAuth 集成流程 的完整开发者指南；
• analytics/queries 中的 SQL 查询（如 platform_cost_log.sql）则反映了平台内置的用量与成本统计能力，对应 Agents 入口中的成本视图。

七、许可模型：Polyform Shield 与 MIT 的双轨制

README 的许可条款表是部署决策前必须确认的部分：

组件	许可证	含义
autogpt_platform/	Polyform Shield 1.0.0	个人与内部商业使用免费；不得将其作为竞争性托管服务出售
classic/ 及仓库其余部分	MIT	宽松的开源使用

平台自身的许可文本保存在 autogpt_platform/LICENSE.md。这意味着：自托管用于个人或公司内部流程完全免费合规，但若计划基于 Platform 构建对外售卖的竞争性托管服务，则需另行评估 Polyform Shield 的限制条款。

八、AutoGPT Classic：实验阶段的完整存档

README 指明原始独立智能体仍保留在 classic/ 目录下，遵循 MIT 许可。classic/README.md 给出了该部分的关键事实：

项目状态：Classic 是一个已被宣布结题的实验项目——它证明了 GPT-4 的自主任务拆解与链式执行，但不受支持、依赖不再更新，且 classic/SECURITY.md 与文档都提示其存在已知漏洞，建议仅作教育研究目的使用。

目录结构：

classic/
├── pyproject.toml          # 单一 Poetry 项目
├── poetry.lock
├── forge/                  # 核心自主智能体框架
├── original_autogpt/       # 原始实现
├── direct_benchmark/       # 基准测试框架
└── benchmark/              # 挑战定义（数据）

运行方式（Python 3.12+ 与 Poetry）：

cd classic
poetry install
cp .env.example .env

# 三个入口
poetry run python -m forge      # Forge 智能体
poetry run serve --debug        # 原始 AutoGPT Web 服务（默认 http://localhost:8000）
poetry run autogpt              # CLI 入口

# 基准测试
poetry run direct-benchmark run

关键环境变量包括必需的 OPENAI_API_KEY，可选的 SMART_LLM（复杂推理模型）/FAST_LLM（简单任务模型）、TAVILY_API_KEY、SERPER_API_KEY、LOG_LEVEL、PORT 与 FILE_STORAGE_BACKEND（local/s3/gcs）。

工作区与权限系统：Classic 采用分层权限——工作区级 .autogpt/autogpt.yaml 与智能体级 .autogpt/agents/{id}/permissions.yaml，支持 allow/deny 通配模式（如 read_file(**.env)、execute_shell(sudo:*)），检查顺序为“智能体 deny → 工作区 deny → 智能体 allow → 工作区 allow → 交互询问”，未命中时用户可选择单次允许、按智能体允许、按工作区允许或拒绝；.env、.key、.pem 等敏感文件与 rm -rf、sudo 等破坏性命令默认被拒。智能体文件访问被沙箱在其 workspace/ 子目录内，状态经 state.json 跨会话持久化。

九、社区、贡献与文档资源

README 的社区支持表指向：Discord 社区（链接见原文档徽章）、官方文档站点、GitHub Issues（Bug 报告）、GitHub Discussions（功能请求）以及本仓库的贡献规范 CONTRIBUTING.md。仓库内另有两份与开发直接相关的文档值得引用：

• CONTRIBUTING.md 与 SECURITY.md：贡献流程与安全漏洞披露渠道；
• codecov.yml：覆盖率集成配置，说明项目以持续集成方式维护测试覆盖率。

如果你想从使用转向开发，最短路径是：先按 docs/platform/contributing 阅读测试规范，再运行 make run-backend / make run-frontend 建立本地全栈开发环境。

十、小结：如何做出部署决策

基于仓库证据，决策路径可以收敛为三步：

1. 零运维诉求 → 使用托管 AutoGPT Platform，四条产品线（AutoPilot / Agents / Marketplace / Build）开箱即用，代价是付费套餐与按量计费；
2. 需要数据与控制权、但想要最少步骤 → 用 setup-autogpt.sh 一键安装，或 single-container 镜像 单容器起步，并尽快完成“提升管理员 + 关闭注册”两步；
3. 需要深度定制与多服务扩展 → 走 docker-compose.yml 全量编排，掌握 deps 聚合服务、migrate 健康门控、五层环境变量加载顺序与 make 命令集，即可支撑扩容（--scale executor=3）、灰度重建单个服务与数据持久化等生产级操作。

无论哪条路径，都请留意 autogpt_platform/ 的 Polyform Shield 许可边界，并确认模型 API Key 的配额与成本预算——因为每一次智能体运行，消耗的都是真实的模型与计算资源。