状态说明（核验于 2026 年 7 月 31 日）： 本文最初是一篇 2023 年的 Auto-GPT 本地安装教程。那些命令已经过时。官方现在明确说明：AutoGPT Classic 已停止支持，依赖不会再更新，并且存在已知安全问题。它适合研究历史，不适合生产使用。新项目应从仍在维护的 AutoGPT Platform，或其他活跃的工作流系统开始。
2023 年第一次运行 Auto-GPT 时，我盯着终端里不断出现的计划、批评和行动，感觉软件正在跨过一道门：过去我们告诉程序每一步怎么做，现在似乎只要告诉它想去哪里。
那一刻很真实，但我从中得到的第一个结论并不准确。
当时我以为，自治就是让模型把循环跑得更久。三年后再看，自治真正困难的部分，恰恰是决定这个循环可以在哪里运行：它能调用哪些工具，能接触哪些凭据，最多花多少钱，何时必须停下，哪一步一定要有人签字。
所以这次更新不再教你复活一个 2023 年的命令行演示。我们要回答三个更有价值的问题：
- AutoGPT Classic 留下了什么？
- 2026 年的 AutoGPT Platform 到底变成了什么？
- 如何把旧设想迁移成一条可观察、可停止、可负责的工作流？
先说结论：不要再照旧教程安装
如果一篇教程仍要求你准备 Python 3.8、执行 pip install -r requirements.txt、把 .env.template 改成 .env、配置 Pinecone，再用 python3 -m autogpt 启动，它描述的是 2023 年某个时间点的 Auto-GPT，而不是今天稳定的使用入口。
现在 AutoGPT 这个名字背后至少有两件不同的东西：
| 维度 | AutoGPT Classic | AutoGPT Platform |
|---|---|---|
| 定位 | 早期自主 Agent 实验 | 构建和运行 Agent 工作流的平台 |
| 官方状态 | 已停止支持，依赖不再更新 | 持续开发，官方仓库仍发布 beta 版本 |
| 核心抽象 | 单个 Agent 反复规划与行动 | block、工作流、触发器、部署与运行监控 |
| 合适用途 | 阅读源码、研究、隔离环境实验 | 新的自动化与持续运行任务 |
| 许可证 | Classic 及 autogpt_platform 之外部分使用 MIT | autogpt_platform 内代码与内容使用 Polyform Shield |
“AutoGPT 是一个开源 Agent”已经不是完整说法。它保留了开源实验的谱系，但当前 Platform 与 Classic 存在清楚的许可证边界。
2023 年的实验，真正留下了什么
Auto-GPT 出现得很早，早到当时我们甚至还没有稳定的语言去描述 Agent。它用一个粗糙但直观的循环，把几件后来成为常识的事摆到了桌面上：
- 模型要完成工作，只有提示词不够，还需要工具；
- 一个模糊目标必须拆成可以执行的动作；
- 上一步的结果需要回到下一轮决策；
- 浏览器、文件、记忆和代码执行一旦接入，系统就有了状态；
- 有状态就有风险，能行动的模型也必须知道如何停止。
这些问题一直存在。消失的是当时那套实现。
旧文曾经列举内容创作、翻译、数据分析、报告生成和编码，仿佛把目标写进去，结果就会自然发生。技术上，模型确实可以尝试这些任务；工程上，“可以尝试”与“值得信任”之间隔着证据、权限、预算和验收。
早期界面让用户给 AI 起名字、定义角色、写下五个目标，然后一次次按 y 批准行动。它让自治看起来很具体，却没有让结果因此可靠。计划可以很流畅，依据仍可能是错的；工具调用可以成功，方向仍可能偏离；循环每多跑一次，进展和误差都会一起累积。
Classic 最有价值的地方，是在同一块终端里同时展示了可能性与失败方式。
Platform 改变的不是界面，而是责任边界
官方对当前 AutoGPT Platform 的描述包括 Agent Builder、工作流管理、部署控制、现成 Agent、运行交互与监控；服务端负责执行已部署的工作流，并支持持续运行和外部触发。
表面看，这是从命令行走向可视化画布。更深一层的变化，是从隐式行为走向显式结构。
在工作流中，一个 block 只负责一个相对清楚的动作：接收触发、读取数据、调用模型、验证结果、写入系统或发送通知。连接线说明数据如何移动，凭据只交给需要它的组件，失败也能落在一个具体节点，而不是淹没在长长的思考日志里。
这不会自动让 Agent 变正确，却让我们有机会知道它错在了哪里。
例子：每天生成一份 Agent 领域简报
旧式目标通常写成：
每天早上找到最重要的 Agent 新闻，总结后发给我。
这句话把“重要”“找到”“总结”“发送”全部交给一个模型临场理解。更稳健的实现会把它拆开：
- 定时器创建一次运行；
- 搜索连接器只从允许的来源收集候选项；
- 确定性代码过滤日期并去重；
- 模型提取每条消息的核心主张、发布日期和证据链接；
- 校验步骤拒绝没有证据或日期不明的条目；
- 模型根据结构化记录生成简报；
- 对外发布前进入人工审批；
- 发送组件只处理已经批准的成品；
- 系统留下成本、来源和失败记录。
它看起来没有“让 Agent 自己想办法”那么浪漫，却更接近真正可用的软件。每一处不确定性都有一个可以被看见的位置。
如何把旧 Auto-GPT 设想迁移到今天
不要迁移命令，要迁移的是任务意图、约束与证据。
第一步：找回真正要完成的工作
早期 Auto-GPT 提示经常把目标与全能幻想混在一起：
调研市场，开发产品，扩大规模，创造五千万美元收入。
这不是一个可以验收的任务。可以把它缩成：
每周一读取十个官方来源的产品更新，生成一份带引用的差异报告，并保存为待审草稿。
开始搭建之前，先写清：
- 什么事件触发运行；
- 必须提供哪些输入；
- 最后应该留下什么可检查的产物；
- 可以访问哪些来源与系统；
- 单次运行的时间和成本上限；
- 哪些决定必须由人作出。
如果成功条件无法被描述，接入 Agent 只会把模糊放大。
第二步：把能力拆成窄而清楚的 block
将检索、转换、模型推理、副作用和交付分开。一个只读取文档的组件，比一个同时能够浏览网页、修改文件、发送邮件和执行代码的 Agent 更容易测试。
确定性的工作尽量交给确定性代码：日期用代码解析，数据结构用 schema 校验，标识符用代码去重。只有语言理解和模糊判断真正需要模型。
模型应该站在系统的不确定边缘，而不是替代整个系统。
第三步：先设计权限，再写提示词
列出所有凭据和可能产生副作用的动作。每个集成只获得完成当前步骤所需的最小权限；读取与写入使用不同的凭据；生产密钥不能进入提示词，也不能提交到仓库。
不可逆动作之前需要审批门，例如：
- 对外发布内容；
- 给客户发送消息；
- 修改生产数据；
- 购买付费服务；
- 在沙箱之外执行生成的代码。
提示词里的“请不要”不是安全边界，权限才是。
第四步：给循环预算和停止条件
一条 Agent 工作流至少要明确：
- 最大模型调用次数与工具调用次数；
- 最长运行时间与单次成本上限；
- 每个失败步骤最多重试几次；
- 找不到证据时如何结束；
- 权限被拒绝时如何结束。
“直到完成目标为止”不是停止条件，它只是允许系统把失败解释成继续消耗资源的理由。
第五步：测试接口处，而不是欣赏过程
为正常输入、空输入、格式错误、凭据过期、限流和局部服务中断准备测试样例。验收最终产物，不要因为中间文字像是在认真思考，就误以为任务已经成功。
对于研究简报，可以检查：
- 每条事实是否都有来源链接；
- 来源日期是否处于允许窗口；
- 同一事件是否只出现一次；
- 输出是否符合约定 schema；
- 没有审批时是否绝不会发送。
先在低预算下运行，再逐步提高频率与影响范围。
第六步：一圈一圈扩大部署范围
先手动运行，只给读取权限；稳定后再加定时触发；然后增加一个可撤销的写操作。只有当运行记录已经无聊到没有惊喜，才让工作流接触更大的受众或更重要的系统。
目标不是第一次运行多么惊艳，而是一百次平静运行，以及某一次失败能够停在正确的位置。
2026 年如何自托管 Platform
安装入口应以官方仓库链接的文档为准。核验本文时，官方将 Platform 自托管描述为一项需要一定技术基础的工作，并为 macOS/Linux 与 Windows 提供安装程序；文档列出的环境包括 Docker Engine、Docker Compose、Git、Node.js、npm 以及合适的编辑器，硬件和网络要求另有说明。
请从 AutoGPT 官方仓库 进入其最新的自托管文档 ，不要复制一篇旧博客里的“一行命令”。执行安装脚本前先读脚本，固定准备使用的版本，升级前查看 release notes。云端开放状态、beta 阶段、系统要求与价格都可能比文章更新得更快。
安装后建议按这个顺序开始：
- 在本地打开 Platform；
- 新建或导入一条很小的工作流；
- 只配置对应 block 真正需要的凭据；
- 使用可丢弃的数据测试；
- 检查运行结果和成本；
- 手动路径稳定后，再增加触发器与外部副作用。
这里刻意不复制官方的一键安装命令。命令很容易复制，也很容易过期；不断变化的入口应该回到维护者自己的文档。
如果仍想研究 Classic
Classic 仍然值得阅读。当前官方 README 记录了原始实验、Forge、benchmark、Agent Protocol 服务、workspace 与分层权限系统，也给出了基于 Python 3.12+ 和 Poetry 的研究环境：
git clone https://github.com/Significant-Gravitas/AutoGPT.git
cd AutoGPT/classic
poetry install
cp .env.example .env
poetry run autogpt
这些命令只用于阅读仓库和隔离实验，不是生产建议。同一份 README 已经明确警告：Classic 不受支持，依赖存在已知漏洞，也不会继续更新。
如果一定要运行：
- 使用可以随时删除的 workspace；
- 创建低额度、实验专用的凭据；
- 禁止访问个人文件和生产服务；
- 让生成代码始终留在沙箱；
- 在模型提供商侧设置消费上限；
- 假设网页内容可能包含恶意指令；
- 实验结束后销毁凭据。
旧教程与当前历史仓库的差异如下：
| 2023 年旧指令 | 当前 Classic 仓库中的对应方式 |
|---|---|
| Python 3.8 或更高 | Python 3.12+ |
pip install -r requirements.txt | 在 classic/ 内执行 poetry install |
重命名 .env.template | 复制 .env.example |
| Pinecone 密钥是必需项 | 当前 Classic README 的基础必需变量中没有 Pinecone |
python3 -m autogpt | poetry run autogpt |
| 安装 Classic 插件目录 | 在 Platform 中使用集成 block，或编写边界清楚的 block |
这张表以后也会过时。仓库与教程冲突时，以仓库为准。
不要忽略许可证边界
AutoGPT 官方仓库同时包含两种许可证：
autogpt_platform目录内的代码与内容使用 Polyform Shield；- 其他部分，包括原始 stand-alone Agent、Forge、benchmark 与 Classic GUI，使用 MIT。
如果计划二次分发、嵌入产品或提供商业服务，应直接阅读仓库 LICENSE 。这里是在指出边界，不是法律建议。
这件事也提醒我：一个名字可以延续项目的故事，却不代表架构、维护状态和使用条款没有改变。看到熟悉的名字时，仍要重新检查脚下的地面。
如果今天重新开始，我会怎么做
我不会先做一个通用自主 Agent。我会先选一件反复出现的痛苦：它有一个明确产物，也有一个真正关心结果是否正确的人。
然后问四个问题：
- 哪一部分真的模糊到需要模型？
- 结果离开系统之前，哪些事实可以先验证？
- 哪个动作一旦执行两次就会造成伤害？
- 当真实世界与提示词不一致时，谁有权让它停下？
这没有 2023 年终端演示那么戏剧化，却是 Agent 从表演走向基础设施的起点。
Auto-GPT 最持久的贡献，不是证明模型可以无限循环，而是让我们第一次认真面对：当语言拥有工具之后，会发生什么。热闹散去，答案仍然是工程里最朴素的几件事——划清边界、观察状态、让失败足够便宜。
读者回响