AB
AB
AiBoss站

全部分类

教程

AutoGPT

教程

用 Docker 部署 AutoGPT 并让它自主拆解执行目标

AutoGPT 能在终端里接收一个目标，自行拆解任务、调用搜索与代码执行并逐步推进。本文用 Docker Compose 完成部署，讲清 .env 与 compose 配置、启动参数、交互确认（y / y-N）的用法，并用一个选品调研的完整示例走通流程，同时说明成本、死循环与中文支持等实际限制。

AutoGPT 是一个基于大语言模型的自主任务代理：你在终端里给它一个最终目标，它会自己把目标拆成任务，为每一步设定角色、目标、推理与行动计划，然后调用搜索、写文件、执行脚本等能力一步步推进，直到给出结果或卡住。它适合想了解自主代理工作方式、愿意为实验性任务付出调用成本的技术读者；如果你需要的是稳定可交付的生产流程，它目前并不合适。想先了解这类工具的定位，可以看站内的 AutoGPT 条目。

下面按「准备 → 部署 → 交互 → 完整示例 → 限制」的顺序讲。所有命令都在终端里执行，配置文件放在同一个项目目录中。

准备工作

开始之前需要确认三件事：

  • Docker 与 Docker Compose：本文采用容器方式运行，不直接在宿主机装 Python 依赖。确认 docker 与 docker-compose 命令可用。
  • OpenAI API Key：在 OpenAI 的密钥管理页面生成一个 key，后面写进 .env。注意这是按调用量计费的付费接口，不是免费聊天额度。
  • 一个专用项目目录：AutoGPT 需要读写配置文件、工作区文件和运行日志，建议单独建一个空目录，不要和别的项目混在一起。

另外要提前想清楚：AutoGPT 会连续发起大量模型调用，单次任务的费用取决于模型、步数和重试次数，可能远高于一次普通对话。开始前先确认账户余额与用量上限，具体价格与配额以 OpenAI 官网当前信息为准。

操作步骤

第一步：拉取镜像

先把 AutoGPT 的镜像拉到本地：

docker pull significantgravitas/auto-gpt

镜像体积不小，首次拉取需要等一会儿。拉取完成后可以用 docker images 确认镜像已经在本地列表中。

第二步：创建项目目录并加入 Docker 的文件共享范围

新建一个目录，例如 auto-gpt-demo，后续的 .env、docker-compose.yml、工作区与日志都放在这里。

如果使用 Docker Desktop，需要把这个目录加入 File sharing（文件共享）列表，否则容器挂载宿主机目录时会失败或看不到文件。命令行版 Docker 在 Linux 上一般不需要这一步，但要注意目录权限。

第三步：写 .env 配置文件

在项目目录里创建 .env，至少写入 API Key 与插件白名单/黑名单两个变量：

OPENAI_API_KEY=【写入你的 OpenAI key】
ALLOWLISTED_PLUGINS=
DENYLISTED_PLUGINS=

说明一下各行的作用：

  • OPENAI_API_KEY：必填，AutoGPT 所有推理与生成都走这个 key。
  • ALLOWLISTED_PLUGINS：允许加载的插件列表，留空表示不额外指定。
  • DENYLISTED_PLUGINS：禁止加载的插件列表，留空表示不禁用任何插件。

.env 里是明文密钥，不要提交到版本库，也不要放进会被同步到公共位置的目录。

第四步：写 docker-compose.yml

同一个目录下创建 docker-compose.yml，内容如下：

version: "3.9"
services:
  auto-gpt:
    image: significantgravitas/auto-gpt
    depends_on:
      - redis
    env_file:
      - .env
    environment:
      MEMORY_BACKEND: ${MEMORY_BACKEND:-redis}
      REDIS_HOST: ${REDIS_HOST:-redis}
    profiles: ["exclude-from-up"]
    volumes:
      - ./auto_gpt_workspace:/app/autogpt/auto_gpt_workspace
      - ./data:/app/data
      - ./logs:/app/logs

  redis:
    image: "redis/redis-stack-server:latest"

这份配置里几个关键点值得逐条对照：

  • 两个服务：auto-gpt 是主程序，redis 提供记忆后端，depends_on 保证 redis 先起来。
  • env_file：把上一步的 .env 注入容器，所以 API Key 不需要写进 compose 文件。
  • MEMORY_BACKEND 与 REDIS_HOST：默认值分别是 redis 和 redis，即用 redis 存记忆、连接名为 redis 的服务。想换后端时在 .env 里覆盖这两个变量即可，不用改 compose 文件。
  • profiles: ["exclude-from-up"]：给服务打上 profile 标记，避免直接 docker-compose up 时把整套服务一起拉起来；本文用 run 方式启动，正好配合这个设置。
  • 三个挂载卷：auto_gpt_workspace 是 AutoGPT 读写文件的沙箱工作区，data 存数据，logs 让日志落到宿主机磁盘，方便事后排查。

配置里还预留了 azure.yaml 与 ai_settings.yaml 的挂载注释。如果你要用 Azure 端点或预置的 AI 设置文件，把对应注释取消，并确保这两个文件与 docker-compose.yml 位于同一目录，否则容器启动时会因为找不到文件而报错。

第五步：启动 AutoGPT

用 run 方式启动主程序，并加上只使用 GPT-3 级别模型的参数：

docker-compose run --rm auto-gpt --gpt3only

参数含义：

  • run --rm：一次性运行指定服务，退出后自动删除容器，不留下停止状态的容器。
  • --gpt3only：只使用 GPT-3 级别模型，避免自动切到更贵的模型。想用更高阶模型时去掉这个参数，但费用会明显上升。

看到控制台开始输出启动信息与交互提示，就说明部署成功，可以输入目标了。

一个完整示例

下面用一个「童装选品调研」的目标，把从输入目标到观察执行的全过程走一遍。这个例子的价值不在于结果多准确，而在于让你看清 AutoGPT 每一步到底在做什么、什么时候该干预。

输入目标

启动后按提示输入目标，例如「帮我做童装选品调研，找出当前市场上值得关注的品类」。回车后 AutoGPT 开始规划。

读懂它的任务拆解

对每一个任务，AutoGPT 会输出一组固定字段，理解这些字段是使用它的前提：

  • Name：任务名称。
  • Role：给模型设定的角色，例如市场分析师。
  • Goals：这一步要达成的目标。
  • THOUGHTS：当前想法，例如「先分析市场流行趋势，有助于选品」。
  • REASONING：推理过程，说明为什么这么做。
  • PLAN：行动计划，通常是一串编号步骤，例如先用搜索引擎查趋势、再分析数据、最后把结果写入本地文件。
  • CRITICISM：自我批评，例如「需要保证数据正确，否则结论不可靠」。
  • NEXT ACTION：下一步要执行的具体动作，例如调用搜索工具查询童装市场趋势。

用 y 与 y-N 控制推进节奏

每一步执行前，AutoGPT 会等你确认：

  • 输入 y：只执行当前这一步，然后再次停下来等你确认。
  • 输入 y -N：连续执行 N 步不再逐步确认，例如 y -20 表示让它自己跑 20 步。

建议前几步一定用 y 逐步看，确认它的方向没跑偏、工具调用符合预期之后，再用 y -N 放它跑一段。这个习惯能省下不少冤枉钱。

观察执行结果

确认执行后，控制台会显示它调用了什么工具、拿到了什么返回。以搜索为例，它会拿到一批 JSON 格式的市场数据，然后进入下一轮：想法是「已有市场数据，需要先存起来再分析」，推理是「存下来便于后续回顾」，计划是「分析数据并存储」，下一步动作是把数据写入本地文件。

再输入 y，就能在宿主机的 auto_gpt_workspace 目录里看到它写出的文件。这一步很关键：工作区目录是你检查它产出的唯一可靠入口，不要只看控制台输出。

它开始写代码时会发生什么

继续推进，AutoGPT 往往会决定写一个 Python 脚本来做数据分析。这时常见的连锁反应是：

  1. 脚本要读取某个 CSV 文件，但该文件并不存在。
  2. 它转而写一个下载数据的脚本，去网上找数据。
  3. 下载脚本本身报错，它开始调试下载脚本。
  4. 依赖缺失，例如没有 pandas，它会去搜索如何安装，然后尝试安装。
  5. 依赖装好后继续执行，又回到「CSV 文件不存在」。

如果放任它自己跑，很容易在第 4、5 步之间反复循环：执行分析脚本 → 文件不存在 → 下载文件（实际没成功）→ 再执行分析脚本。这就是自主代理最典型的失败模式——它不会主动跳出循环重新审视目标，只会沿着当前计划不断重试。

遇到这种情况的正确做法是中断，而不是继续加步数。可以按提示退出，或者直接停掉容器，然后回到工作区检查它到底写出了哪些文件、缺的是哪一份数据，把缺失的输入手动补进工作区，再重新启动并给出更具体的目标。

注意事项

以下限制来自实际使用中暴露的问题，部署前值得逐条评估：

  • 非异步执行，周期长：任务是一步一步串行推进的，一个稍复杂的目标可能要跑很久，而且不保证能完整跑完。把它当成需要盯着看的实验，而不是后台批处理。
  • 每次从零开始，成本高：没有跨任务的积累，每次都要重新规划、重新搜索、重新试错。单次任务的费用可能达到数美元量级，用 GPT-3 级别模型尚且如此，换更强的模型只会更贵。具体单价与账户额度以 OpenAI 官网当前信息为准。
  • 重复动作多：同一份数据可能被反复搜索、反复写入，既拉长耗时也持续消耗额度，严重时形成死循环。
  • 中文支持有限：中文通常只体现在你输入的第一句目标上，后续的思考、计划与执行基本是英文，阅读时需要一定的英文能力。
  • 产出需要人工校验：它写出的脚本可能有明显错误（读取不存在的文件、缺少依赖），生成的结论也不能直接采信。工作区里的文件要逐个检查。
  • 密钥与目录安全：.env 中的 API Key 是明文，工作区目录里的文件由模型生成，不要把项目目录指向含有敏感资料的位置。

综合来看，AutoGPT 更适合用来观察自主代理如何拆解目标、如何调用工具、在什么条件下会失控，而不是直接承担生产任务。真正要落地时，把目标拆得更小、给足输入文件、用 y 逐步确认、随时准备中断，是控制成本和避免死循环最有效的几个手段。

返回