AutoGPT Classic：开启调试日志并通过 E2B 分享日志，帮助定位 Agent 异常行为

当你在使用 AutoGPT Classic 遇到 Agent 行为异常、想记录一个有意思的用例，或者要提交一个 bug 报告时，最有说服力的材料就是完整的运行日志。本文基于仓库中的官方指引 share-your-logs.md，讲解如何开启 debug 日志、日志文件实际写在哪个目录、日志由哪些文件组成，以及如何在 E2B 平台上查看、上传、打标和分享这些日志。读完后你能够独立完成“生成调试日志 → 上传 E2B → 生成可分享链接 → 为日志打上严重度标签”的完整排障与协作流程，并且能从源码层面理解 --debug 参数到底改变了什么。

什么场景下需要分享日志

原文档给出的三种典型场景：

• Agent 出现怪异行为：比如输出偏离任务、反复执行同一动作、工具调用失败等，仅凭终端上的简短提示很难定位原因；
• 有趣的用例：你想把自己的玩法和配置分享给社区，讨论其可行性；
• 提交 bug 报告：在向 AutoGPT 团队反馈问题时，附带日志可以大幅提高沟通效率，减少“请提供更多信息”的来回。

这三个场景的共同点是：问题发生时，Agent 内部的 LLM 请求、工具调用、组件状态等细节已经过去了，只有落盘的日志（尤其是 DEBUG 级别）保留了完整现场。

开启调试日志

Activity、Error 和 Debug 日志都位于 ./logs 目录下。原文档给出的三种开启方式，按运行环境区分：

./autogpt.sh --debug      # Linux / macOS

.\autogpt.bat --debug     # Windows

docker compose run --rm auto-gpt --debug    # Docker 环境

其中 docker compose run --rm auto-gpt --debug 适用于以容器方式运行 Classic 的场景：--rm 表示容器退出后自动清理，auto-gpt 是服务名，--debug 透传给容器内的启动脚本。

--debug 参数在源码中的真实含义

--debug 不是一个独立的“调试开关”，而是一个语法糖。在 CLI 入口 cli.py 中，run 子命令对它的定义是：

@click.option(
    "--debug", is_flag=True, help="Implies --log-level=DEBUG --log-format=debug"
)

即它等价于同时指定 --log-level=DEBUG 与 --log-format=debug。serve 子命令（Agent Protocol 服务端）也有同样的参数定义，见 cli.py#L185-L187。

调用链是：cli.run() 解析参数后调用 run_auto_gpt(...)，后者在 main.py#L198-L205 中把这些参数交给日志配置函数：

configure_logging(
    debug=debug,
    level=log_level,
    log_format=log_format,
    log_file_format=log_file_format,
    config=config.logging,
    tts_config=config.tts_config,
)

真正的落地逻辑在 config.py 的 configure_logging() 中，几个关键点：

1. debug 与 level 互斥：同时传入两者会直接抛出 ValueError("Only one of either 'debug' and 'level' arguments may be set")（config.py#L91-L92）。因此命令行上不要同时写 --debug --log-level=...；
2. debug 的聚合效果：当 debug=True 时，config.level 被置为 logging.DEBUG，config.log_format 被置为 LogFormatName.DEBUG（config.py#L114-L118）；
3. DEBUG 格式的日志行：debug 格式使用 DEBUG_LOG_FORMAT = "%(levelname)s %(filename)s:%(lineno)d %(title)s%(message)s"（config.py#L28-L29），即每条日志都带源文件名和行号。这正是排障时最有价值的信息——你可以直接根据日志里的 file:lineno 跳回源码定位，这也是为什么报 bug 时要用 debug 格式重新跑一遍。

用 --log-level、--log-format、--log-file-format 精细控制

除了 --debug，cli.py 还暴露了三个更细粒度的参数：

参数	取值	作用
--log-level	Python logging 标准级别（CRITICAL、ERROR、WARNING、INFO、DEBUG 等，来自标准库 logging._nameToLevel 的键）	控制日志输出阈值，默认 INFO
--log-format	simple / debug / structured_google_cloud（LogFormatName 枚举，config.py#L35-L38）	控制台日志格式；默认 simple，未显式指定时会同步作为文件日志格式
--log-file-format	同上	单独覆盖“文件输出”的格式；未指定时回退到全局 --log-format

两个值得注意的行为（均可在 config.py#L126-L131 中确认）：

• structured_google_cloud 格式会禁用日志文件输出（config.log_file_format = None）。这种结构化 JSON 格式面向云环境的集中式日志采集，本地跑 Classic 时选它就不会在磁盘上留下日志文件；
• error.log 恒用 debug 格式写：ERROR 文件 handler 固定使用带文件名与行号的 DEBUG_LOG_FORMAT（config.py#L171-L177），所以即使是日常非 debug 运行，出错时的行号信息也不会丢失。

通过环境变量等价配置

从源码结构看，LoggingConfig 定义了环境变量来源，命令行参数未指定时会读取这些变量：

环境变量	默认值	说明
LOG_LEVEL	INFO	日志级别（logging.getLevelName 解析）
LOG_FORMAT	simple	控制台日志格式
LOG_FILE_FORMAT	未设置时回退 LOG_FORMAT，否则 simple	文件日志格式
PLAIN_OUTPUT	False	控制台是否纯文本输出

也就是说，在 Docker 或 CI 场景中，你也可以不改启动命令、只注入 LOG_LEVEL=DEBUG LOG_FORMAT=debug 达到与 --debug 相同的效果（参数优先于环境变量，见 config.py#L113-L124 的聚合顺序）。

日志文件的位置与组成

config.py#L23-L26 定义了日志常量：

LOG_DIR = Path(__file__).parent.parent.parent / "logs"
LOG_FILE = "activity.log"
DEBUG_LOG_FILE = "debug.log"
ERROR_LOG_FILE = "error.log"

由此可以推断日志目录的相对位置：LOG_DIR 以 forge/logging/config.py 为基准向上三级，即落在 classic/forge/logs 下（对应文档中提示的 ./logs）。实际由 configure_logging() 创建的 handler 有两个文件输出：

• activity.log：记录 config.level 及以上的日志；仅在日志级别低于 ERROR 时挂载（config.py#L157-L169），即常规运行和 debug 运行都会写它，按 LOG_FILE_FORMAT 格式化，UTF-8、追加模式；
• error.log：只记录 ERROR 及以上的日志（config.py#L171-L177），恒定使用带 file:lineno 的 debug 格式。

控制台侧则是双路输出：stdout handler 输出 WARNING 以下的内容（经 BelowLevelFilter），stderr 专门收 WARNING 及以上（config.py#L145-L153）。分享排障材料时，把整个生成的 debug 日志目录打包上传即可，不必挑文件。

提示：上传日志前建议先自行检查其中是否包含 API key、令牌等敏感信息（日志中可能记录 LLM 调用与工具参数），这是分享前的好习惯。

通过 E2B 查看与分享日志

日志生成后，官方推荐的查看与分享通道是 E2B 上的 AutoGPT 日志实例。操作步骤（继承自原文档）：

1. 打开 autogpt.e2b.dev（以纯文本形式给出，避免外链）并登录。登录后可以看到 AutoGPT 团队成员上传的日志，可以直接查看别人跑出来的现场，这对理解同类问题很有帮助；
2. 上传自己的日志：点击 “Upload log folder” 按钮，选择你用 --debug 生成出来的 debug 日志目录，等待 1~2 秒后页面自动刷新；
3. 分享日志：直接把浏览器地址栏中的 URL 发给协作者即可，对方打开就能逐文件浏览日志内容（对应下图中的日志 URL）。

这种方式相比在 issue 里直接贴日志片段的优势：日志目录可能包含多个文件与大量行数，E2B 提供了按文件夹浏览、逐行检索的体验，链接也天然带版本（上传即定格）。

给日志打标签（Tags）

如果你和团队成员共用这个通道，可以给日志打上自定义标签，例如标注“该 Agent 在挑战（challenges）场景下出现问题”。标签名字可以任意取，E2B 提供三种严重度（severity）：

• Success
• Warning
• Error

添加标签的步骤：

1. 点击日志文件夹名称左侧的 “plus”（加号）按钮；
2. 输入新标签的名字；
3. 选择严重度。

给标签选严重度时，建议与日志本身的性质对齐：Agent 正常跑完的参考运行选 Success；可疑但可运行的现象选 Warning；明确失败、需要团队介入的现场选 Error，这样团队成员扫一眼仪表盘就能按严重度分拣。

小结与注意事项

• --debug = --log-level=DEBUG --log-format=debug，二者不能与 --log-level 同时指定，否则启动即报错；
• 日志落在 logs/ 目录（源码中为 classic/forge/logs，对应文档中的 ./logs），核心文件是 activity.log（全部活动）与 error.log（仅错误，恒带文件名和行号）；
• structured_google_cloud 格式会禁用文件输出，本地排障不要选它；
• 分享路径：autogpt.e2b.dev 上传日志目录 → 刷新后获得 URL → 附在 issue 或讨论中 → 用自定义标签 + 严重度帮助团队定位；
• 适用前提：以上命令均针对仓库中 classic/original_autogpt 这套 Classic 实现（run 默认启动方式、serve 子命令均支持 --debug），Platform 部分（autogpt_platform）的日志体系不在本文讨论范围内。