AutoGPT 实战技巧：5个提效方法
从一次失败的自动爬取说起
去年年底，我接了个活：帮一个做跨境贸易的朋友监控 40 多个竞品网站的价格变动。听起来简单，但网站结构五花八门，有的要登录，有的反爬，还有一个居然是纯 Flash 时代的老古董。我最初的方案很朴素：每个网站写一个脚本。写到第 7 个的时候我崩溃了——这种重复劳动真的不该由人来做。
于是我打开了 AutoGPT，想着“让 AI 自己写爬虫”。结果第一次跑就给我上了一课：它给自己设定的任务是“完成价格监控系统的开发”，然后开始无限循环地“分析需求 → 写代码 → 发现不完整 → 重新分析需求”，烧了我大概 $4 的 API 费用，产出了零个能用的文件。
那次踩坑之后，我花了几个周末认真研究 AutoGPT 的运行机制，逐渐摸索出一套能真正让它干活的方法。下面这 5 个技巧，每一个都是用真金白银换来的。
技巧一：把大目标拆成小任务，别让 AI 自己规划全局
AutoGPT 最容易翻车的地方就是自主规划。你给它一个宏大目标，它会生成一个模糊的计划，然后执行到一半就迷失方向。
我后来的做法是：目标写成一句可以直接验证是否完成的动作。
对比一下：
❌ 差的目标：
"开发一个价格监控系统"
✅ 好的目标：
"写一个 Python 脚本，用 requests 和 BeautifulSoup 抓取
https://example.com/products 页面上 class 为 price 的元素，
输出为 CSV 文件 prices.csv"
第二种写法，AutoGPT 通常两三轮就能交付。因为判断标准清晰，它不需要反复纠结“我是不是完成了”。我的经验法则是：如果一个任务的验收标准你自己都说不清楚，先别交给 AutoGPT。
技巧二：用好 continuous_mode 的边界，控制预算
AutoGPT 默认每完成一轮就停下来问你“是否继续”，这在长任务里烦得要命。启动时加上：
./run.sh --continuous 5
表示连续执行 5 轮才暂停。但我要提醒你：千万别开 --continuous 0（无限模式）然后去睡觉。我有一次让它跑一晚上，早上起来发现它陷入了一个“安装依赖失败 → 重试 → 失败”的死循环，烧掉了 12 美元。
我的替代方案是用 --max-step-limit 配合较短的连续轮数，比如 --continuous 3，每 3 轮检查一次输出文件。多花点人工确认的时间，但止损效果显著。
技巧三：给 memory 喂上下文，而不是指望它自己查
AutoGPT 的长期记忆默认用的是本地存储，检索质量一般。我发现一个土办法特别有效：在 workspace 目录下手动放一个 context.md，里面写清楚：
- 项目的文件结构
- 已经完成的部分
- 已知的技术约束（比如“目标网站需要 User-Agent 头，否则返回 403”）
- 禁止事项（比如“不要修改 config.yaml”）
AutoGPT 每次读取文件时会看到这个文件，相当于给了一个“项目备忘录”。加了 context.md 之后，我那些跨多轮会话的任务失败率肉眼可见地下降了。它不再重复踩我已经踩过的坑——比如第三次尝试给网站发请求时才想起来加 headers 这种事。
技巧四：把“执行”和“审查”分成两次运行
这是我效果提升最大的一个技巧。让 AutoGPT 一口气写完并自我审查，质量很一般——它审查自己的代码就像学生检查自己的考卷，看不出问题。
我的流程改成：
- 第一次运行：只让它写代码，目标是“实现 X 功能，输出到 /workspace/src/”
- 人工快速扫一眼（30 秒，看结构对不对）
- 第二次运行：目标改成“审查 /workspace/src/ 下的代码，找出 bug 和边界情况遗漏，输出 review.md”
- 根据审查结果做第三次运行修复
分成三次跑，总 token 消耗差不多，但产出质量高出一截。因为它带着“找茬”的指令去读代码时，注意力完全不同。我用这个流程让它写那批爬虫，40 个站点里它独立搞定了 31 个，剩下的 9 个反爬太狠的我自己上的 Playwright。
技巧五：模型选择要分层，别一个 GPT-4 打天下
AutoGPT 允许你配置不同环节用不同模型。早期我用 GPT-4 跑所有环节，账单很疼。后来改成：
- 思考/规划/写代码：GPT-4（现在可以用更新更便宜的模型）
- 文件读写、简单格式转换、执行命令：GPT-3.5 级别的模型足够
在 .env 里配置 SMART_LLM 和 FAST_LLM 两个变量即可。这一改，我单任务成本直接砍掉一半以上。说实话，让 GPT-4 去决定“把文件从 A 文件夹复制到 B 文件夹”这种事，纯属浪费。
诚实说说它的局限
用了几个月，我的结论是：AutoGPT 适合“清晰定义的、可验证的、中等复杂度的”任务。它擅长批量处理结构化工作（写爬虫、整理文档、格式转换、写测试用例），但对需要真正设计决策的开放性问题，它依然会跑偏。
另外它的日志输出非常啰嗦，建议配合 --debug 关闭调试信息，并且养成每次运行前 git commit workspace 的习惯——我有过被它“好心”重写整个项目文件的经历。
如果你把它当成一个“需要明确指令的初级程序员”，而不是“全自动员工”，它是个不错的生产力工具。期望值放对了，这东西真能帮你省时间；期望值错了，它只帮你烧 API 费。