FEATURED · 精选文章

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

发布时间 / 2026/9/7 3:11:19
来源 / 创域科博编辑部
栏目 / 资讯中心
AutoGPT AI 智能体平台实战指南:托管版与自托管部署、Docker 架构与许可模型全解析 AutoGPT AI 智能体平台实战指南托管版与自托管部署、Docker 架构与许可模型全解析【免费下载链接】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/AutoGPTAutoGPT 是一个用于构建、部署和运行 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.shmacOS / Linux与 setup-autogpt.batWindows。脚本会自动检查前置依赖、克隆仓库并拉起全部服务。从 setup-autogpt.sh 头部注释可以看到它支持三个可选参数--with-ollama额外安装 Ollama拉取一个默认聊天模型并写入backend/.env使 AutoPilot 在无云端 API Key 的情况下运行CHAT_USE_LOCALtrue--ollama-modelNAME指定要拉取的模型默认hf.co/unsloth/Qwen3.5-4B-GGUF:Q4_K_M--ollama-hostURL复用已有的 Ollama 服务跳过本地安装但仍写入本地模型相关的.env配置。3.2 手动 Docker Compose 部署autogpt_platform/README.md 给出了手动部署的标准流程前置要求仅为 Docker 与 Docker Compose V2Docker Desktop 自带也可单独安装克隆仓库并进入平台目录git clone https://gitcode.com/GitHub_Trending/au/AutoGPT cd AutoGPT/autogpt_platform复制环境变量模板cp .env.default .env该模板文件确实存在于 autogpt_platform/.env.default你可以在此追加自己的环境变量如模型 API Key。启动全部服务docker compose up -d这会以分离模式启动 docker-compose.yml 中定义的所有后端服务。待所有服务进入就绪状态后浏览器打开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 nofile65536:65536 \ -p 127.0.0.1:3000:3000 \ -e AUTOGPT_PUBLIC_URLhttp://localhost:3000 \ -v autogpt-data:/data \ significantgravitas/autogpt:latest需要注意的运维要点均来自 single-container/README.md首次启动可能需要数分钟等容器变为healthy后再访问注册默认开放上面的回环端口绑定只保证本机可达——若把应用暴露到网络在你关闭注册前任何人都能注册账号创建账号后用docker exec autogpt autogpt-admin promote youexample.com将其提升为管理员之后以AUTH_ALLOW_NEW_ACCOUNTSfalse重建容器以关闭注册并保留同一数据卷以持久化账号、智能体与记忆AUTOGPT_PUBLIC_URL必须与浏览器实际访问的 URL 完全一致测试环境的启动与稳态健康检查约占用 5–6 GiB 内存实际取决于启用的服务与负载。四、自托管架构深潜Docker Compose 服务编排autogpt_platform/docker-compose.yml 采用“薄包装”模式它只声明网络app-network、shared-network与数据卷各服务通过extends继承自 docker-compose.platform.yml 中的真实定义。这套编排可以拆成四类组件1. 数据与中间件层服务说明dbPostgreSQL镜像固定为pgvector/pgvector:pg15内置 pgvector 向量扩展映射主机 5432 端口启动时挂载 db/init/00-init.sql 创建平台 schemaredis-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数据与 3001Web UI端口clamav防病毒扫描服务映射 3310 端口2. API 与执行层均从 backend Dockerfile 构建命令入口对应pyproject.toml中的脚本服务命令端口rest_serverrest8006executorexecutor8002copilot_executorpython -m backend.copilot.executor8008websocket_serverws8001database_managerdb8005scheduler_serverscheduler8003notification_servernotification8007platform_linking_managerplatform-linking-manager仅在botprofile 下启动8009frontendNext.js 生产构建30003. 启动顺序编排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仅在localprofile 下生效分别把“中间件依赖”和“后端服务依赖”聚合成一个可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 executor3 # 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 文件头部用注释显式定义了后端环境变量首个到末位后者覆盖前者backend/.env.default—— 全部配置项的默认值backend/.env—— 用户自定义配置可选Compose 的environment键 —— Docker 专属覆盖如容器内服务名Shell 环境 —— 运行 docker compose 前导出的变量CLI 参数 ——docker compose run -e VARvalue。其中x-backend-env锚点把容器网络内的服务名统一注入所有后端服务例如DB_HOSTdb、REDIS_HOSTredis-0、RABBITMQ_HOSTrabbitmq、JWT_JWKS_URLhttp://frontend:3000/api/auth/jwks并内嵌了DATABASE_URL连接串指向db:5432/postgres的platformschema。前端容器则反向注入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 与 Poetrycd 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_BACKENDlocal/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 IssuesBug 报告、GitHub Discussions功能请求以及本仓库的贡献规范 CONTRIBUTING.md。仓库内另有两份与开发直接相关的文档值得引用CONTRIBUTING.md 与 SECURITY.md贡献流程与安全漏洞披露渠道codecov.yml覆盖率集成配置说明项目以持续集成方式维护测试覆盖率。如果你想从使用转向开发最短路径是先按 docs/platform/contributing 阅读测试规范再运行make run-backend/make run-frontend建立本地全栈开发环境。十、小结如何做出部署决策基于仓库证据决策路径可以收敛为三步零运维诉求→ 使用托管 AutoGPT Platform四条产品线AutoPilot / Agents / Marketplace / Build开箱即用代价是付费套餐与按量计费需要数据与控制权、但想要最少步骤→ 用 setup-autogpt.sh 一键安装或 single-container 镜像 单容器起步并尽快完成“提升管理员 关闭注册”两步需要深度定制与多服务扩展→ 走 docker-compose.yml 全量编排掌握deps聚合服务、migrate健康门控、五层环境变量加载顺序与make命令集即可支撑扩容--scale executor3、灰度重建单个服务与数据持久化等生产级操作。无论哪条路径都请留意autogpt_platform/的 Polyform Shield 许可边界并确认模型 API Key 的配额与成本预算——因为每一次智能体运行消耗的都是真实的模型与计算资源。【免费下载链接】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),仅供参考
RELATED — 相关阅读

相关资讯

LATEST — 最新资讯

最新发布

TODAY — 本日精选

新闻

WEEKLY — 本周精选

新闻

MONTHLY — 本月精选

新闻