关键要点
- 仓库数据：187,081 星标，531 个未关闭 issue，未归档——截至本次评测仍在积极提交
- AutoGPT Platform（autogpt_platform/，agpt.co）：托管、付费的可视化智能体构建工具——Polyform Shield License（源码可见，限制竞争性商业使用）
- 经典版 AutoGPT（classic/original_autogpt/）：原始的自主命令行智能体——MIT 许可证，仍接收安全和维护提交
- 本地模型：经典版通过 OPENAI_API_BASE_URL 支持任何兼容 OpenAI API 的服务器（包括 Ollama），还通过 LLAMAFILE_API_BASE 原生支持 Llamafile
- Platform 自身的环境配置没有 Ollama 或本地模型设置——它是围绕托管模型提供商构建的
- 本站及任何地方均不存在 AutoGPT 的联盟返佣计划；以下每个链接都是明示的普通链接
📍 简单一句话
AutoGPT 现已成为两个产品：一个付费的托管版 AutoGPT Platform（Polyform Shield 许可证），是当前积极开发的重心；以及一个遗留的 MIT 许可经典 CLI 智能体，仍可通过通用 OpenAI 兼容端点在本地对接 Ollama 运行，但只接收维护更新，不再获得新功能。
💬 简单来说
大多数人记忆中的"AutoGPT"——一个你可以指向自己模型的命令行智能体——依然存在，也依然免费（MIT），但背后的公司现在把精力放在了另一个带可视化构建工具的付费产品上。在决定评估哪一个版本之前，先看清许可证和文件夹名称。
📌Note: 如果搜索结果、教程或旧博客文章提到"AutoGPT"却没有区分经典版和 Platform，通常指的是 2026 年之前的 CLI 智能体——也就是经典版，它是该项目中唯一 MIT 许可、可免费自托管的部分。
2026 年的 AutoGPT 是什么？
AutoGPT（github.com/Significant-Gravitas/AutoGPT）是 2023 年让"自主智能体"这一理念走红的项目：给 LLM 一个目标，让它在无需人工逐步批准的情况下自行规划、行动并自我批判。到了 2026 年，同一个 GitHub 组织推出了一个结构上截然不同的产品——一个名为 AutoGPT Platform 的商业化托管产品，而原始的自主循环智能体则作为次要的 MIT 许可组件保留下来。
- AutoGPT Platform（agpt.co / platform.agpt.co）：当前的旗舰产品，一个托管、付费的可视化智能体构建工具
- AutoPilot：一个对话生成智能体的界面——用自然语言描述任务，Platform 会为其组装出一个智能体
- Agents 仪表盘：管理、监控并重新运行你或 Marketplace 构建的智能体
- Marketplace：浏览并安装其他用户构建的预制智能体模板
- Build 画布：拖拽式、基于节点的可视化智能体构建编辑器，在理念上类似 Langflow 或 Dify 的工作流构建工具
- 自托管 Platform 在技术上是可行的（仓库中存在 docker-compose.platform.yml、installer/ 脚本和 single-container/ 选项），但 README 的主要行动号召是注册托管产品，而不是自托管
- classic/original_autogpt/：原始的 CLI 驱动自主智能体，如今被定位为遗留组件，与 classic/forge（智能体构建框架）、classic/benchmark 和 classic/frontend 并列
MIT / Polyform 许可证拆分详解
AutoGPT 的许可情况并非单一答案，如果你打算在其代码基础上进行商业开发，弄错这一点会有实际影响。该仓库对代码库的两个不同部分使用了两种不同的许可证。
经典版 AutoGPT 还有人维护吗？
在安全性和稳定性这个意义上是的，但在新功能这个意义上不是。classic/ 文件夹持续收到核心团队的提交——近期的例子包括依赖漏洞清理、针对出站请求处理的 SSRF 加固修复，以及在经典智能体所依赖的某个依赖包出现被入侵版本后设置的版本上限。这些正是你希望在打算运行的代码上看到的提交类型：它们是防御性的，而不是装饰性的。
classic 得不到的是新功能开发。新增能力的提交——新的智能体构建原语、市场功能、新的 AutoPilot 行为——都落在 autogpt_platform/ 里。该项目自己的 README、issue 标签和文件夹结构都把 classic 视为一个保持可用和安全、但不再积极扩展的遗留次要分支。这与"被抛弃"是有实质区别的：提交仍在让 classic 保持运行和安全，只是团队的产品重心已经转移到别处。
仓库状态
- What it shows:
- 未归档；本次评测当天仍有提交；531 个未关闭 issue
classic/ 提交模式
- What it shows:
- 安全修复和依赖上限定期出现；没有重大新功能提交
新功能落地位置
- What it shows:
- autogpt_platform/——AutoPilot、Marketplace 和 Build 画布获得积极开发
项目定位
- What it shows:
- README 和主要行动号召推广托管版 Platform；classic 被定位为遗留 CLI 分支
📌Note: 本次评测没有对经典版 AutoGPT 运行自己的测试套件——下面的结论基于 classic/ 子文件夹具体的已记录提交历史和 issue 活动，而非我们自己生成的基准测试数据。在投入大量时间之前，请对照仓库核实当前状态。
如何用 Ollama 本地运行经典版 AutoGPT
经典版 AutoGPT 并没有一个专门命名的一流"Ollama 集成"。它有一个通用的、兼容 OpenAI API 的客户端，通过 classic/original_autogpt/.env.template 配置，而 Ollama 恰好暴露了一个兼容 OpenAI 的端点——所以把两者对接起来是一个配置步骤，而不是内置功能。
- 1克隆 github.com/Significant-Gravitas/AutoGPT，打开 classic/original_autogpt/ 文件夹——这是 MIT 许可的 CLI 智能体，不是 autogpt_platform/ 文件夹。
- 2单独安装 Ollama，并拉取一个能够遵循多步骤工具调用指令的模型；本站自己关于本地编程模型和工具调用能力的对比文章是选型的合理起点。
- 3将 classic/original_autogpt/ 内的 .env.template 复制为 .env。
- 4在 .env 中将 OPENAI_API_BASE_URL 设置为你 Ollama 服务器的 OpenAI 兼容端点（Ollama 在其默认端口的 /v1 路径暴露此端点）。Ollama 不会检查 API key 的具体值，但客户端仍要求 OPENAI_API_KEY 字段被设置为一个非空的占位字符串。
- 5另外，如果你运行的是 Llamafile 而不是 Ollama，则改为设置 LLAMAFILE_API_BASE——这是一条独立的原生本地推理路径，不经过通用的 OpenAI 兼容设置。
- 6按照 classic/original_autogpt/README.md 中的说明安装经典版的 Python 依赖，并从该文件夹（而非仓库根目录）运行智能体。
- 7预计在最初几次运行中需要密切监督。由于这是通用的 OpenAI 兼容机制，而非经过维护和测试的 Ollama 集成，模型特有的问题（工具调用格式、上下文长度限制）需要你自行调试。
经典版 AutoGPT 需要特定的 Ollama 版本吗？
该项目没有为经典版记录一个固定、经过测试的 Ollama 版本——因为这是通用的 OPENAI_API_BASE_URL 机制，兼容性取决于你的 Ollama 版本是否暴露稳定的兼容 OpenAI 的 /v1 端点，而近期的 Ollama 版本都能做到。请查阅 Ollama 自己的发布说明来确认 API 兼容性，而不是 AutoGPT 的说明。
经典版 AutoGPT 能完全离线运行吗？
可以，一旦 OPENAI_API_BASE_URL 指向本地的 Ollama 或 Llamafile 端点，经典版 AutoGPT 就不需要向云端提供商发起出站 API 调用。但作为智能体任务的一部分（例如浏览类工具），它仍可能发起出站网络请求，除非你禁用该能力。
对规划循环的合理预期
经典版 AutoGPT 的核心机制——LLM 在循环中自行规划下一步、决定任务何时完成、无需人工逐步批准——正是让它成名的架构，也是在面对本地、通常规模更小的开放权重模型时老化得最明显的架构。
- 自主、无范围限制的规划循环对底层模型的要求，高于范围受限、工具受限的智能体：模型必须追踪长跨度状态、决定何时停止，并在没有人工及早发现偏差的情况下自我纠正
- 较小的本地模型（大多数人通过 Ollama 在消费级硬件上舒适运行的那类）比大型托管模型更容易在长时间自主运行中偏离主题，原因很简单：跨多步骤的规划与自我纠正是一项比单轮工具调用更难的能力
- 这是一个比较性的架构观点，而不是针对任何具体模型或版本的断言：对本地模型而言，维持一个无范围限制的规划循环，比维持一个每步都有人工批准的范围受限执行框架要难得多
- 范围受限的替代方案——Cline + Ollama、Continue.dev 的 Agent 模式，以及 LangGraph 这类基于图的编排工具——把智能体限制在一个编辑器、一组文件，或每个动作一个明确的批准关卡内，从而减少单次规划失误在被人工发现前能偏离多远
谁该用经典版 AutoGPT，谁该用 Platform？
正确的选择取决于你想要的是一个免费、自托管、动手实验的方案,还是一个付费、托管的产品。
AutoGPT 与替代方案对比
AutoGPT 的两个部分对标不同的工具：经典版 AutoGPT 对标其他本地、范围受限的智能体执行框架；Platform 对标其他托管或可自托管的可视化智能体构建工具。
| Tool | Model | License | Best For | Maintenance |
|---|---|---|---|---|
| AutoGPT（经典版） | 本地通过 Ollama（OpenAI 兼容 URL） | MIT | 自主循环实验 | 仅安全修复 |
| AutoGPT Platform | 托管提供商 | Polyform Shield | 可视化构建 + Marketplace | 积极维护 |
| Cline + Ollama | 本地 | Apache 2.0 | 受监督编程智能体 | 积极维护 |
| Continue.dev Agent | 本地或云端 | Apache 2.0 | IDE 内范围受限智能体 | 积极维护 |
| LangGraph | 本地或云端 | MIT | 自定义基于图的智能体 | 积极维护 |
评估 AutoGPT 时的常见误区
2026 年围绕 AutoGPT 的大多数困惑，都来自不清楚某个说法指的是项目的哪一半。
常见问题
AutoGPT 是 MIT 许可的吗？
部分是。classic/ 文件夹（original_autogpt、forge、benchmark、frontend）采用 MIT 许可证。autogpt_platform/ 文件夹——当前的旗舰托管产品 AutoGPT Platform——则采用 Polyform Shield 许可，这是一种源码可见许可证，而非宽松的开源许可证。
AutoGPT 还有人维护吗？
有。该仓库未被归档，本次评测当天仍有提交，有 531 个未关闭的 issue。活跃的功能开发集中在 autogpt_platform/；classic/ 文件夹仍会收到安全和维护提交，但不再获得新功能。
AutoGPT 能配合 Ollama 使用吗？
经典版 CLI 智能体可以，通过其通用的兼容 OpenAI API 的客户端——将 OPENAI_API_BASE_URL 设置为你 Ollama 服务器的 /v1 端点即可。这不是一个专门命名、专门构建的"Ollama 集成"，当前的 AutoGPT Platform 也不支持它，因为其配置中没有本地模型设置。
AutoGPT Platform 是什么？
AutoGPT Platform（agpt.co）是该项目当前的商业产品：一个托管、付费的可视化智能体构建工具，带有对话生成智能体的 AutoPilot、Agents 仪表盘、预制智能体的 Marketplace，以及基于节点的 Build 画布。技术上可以自托管，但该项目主要推广的路径是托管注册。
AutoGPT 是免费的吗？
经典版 AutoGPT（MIT）可以免费自托管。AutoGPT Platform 是一个付费的托管产品；在 Polyform Shield 许可下可以自托管它，该许可允许个人或内部使用，但限制在其基础上构建具有竞争性质的商业产品。
AutoGPT 和 AutoGPT Platform 有什么区别？
AutoGPT（经典版）是 2023 年那一代原始的自主 CLI 智能体——MIT 许可，本地运行，接收维护提交。AutoGPT Platform 是同一组织推出的一个独立、更新的商业产品——一个采用源码可见许可证的托管可视化智能体构建工具，也是目前积极开发的重心。
我还能免费用 AutoGPT 做本地实验吗？
可以，通过 classic/original_autogpt/，它依然采用 MIT 许可证，并通过 OPENAI_API_BASE_URL 设置对接本地 Ollama 服务器运行。但要预期这是一个处于维护模式的代码库，而不是功能仍在积极开发的代码库。
AutoGPT 为什么会拆分成两种许可证？
该项目的商业重心转移到了托管版 AutoGPT Platform。Polyform Shield 让公司能够保持该代码源码可见——可供个人使用阅读和自托管——同时防止竞争对手拿走代码重新打包转售，而 MIT 这样的宽松许可证无法防止这种情况。
在本地智能体工作上，经典版 AutoGPT 比 Cline 或 Continue.dev 更好吗？
对于无人值守的本地自动化任务而言不是。经典版 AutoGPT 无范围限制的自主规划循环对底层模型的要求，高于 Cline + Ollama 或 Continue.dev 的 Agent 模式这类范围受限、单编辑器的执行框架，后者通过逐步批准来限制规划失误的影响范围。经典版 AutoGPT 更适合用来体验规划循环架构本身，而不适合用于生产环境的编程工作。