AutoGPT Classic开启调试日志并通过 E2B 分享日志帮助定位 Agent 异常行为【免费下载链接】AutoGPTAutoGPT is the vision of accessible AI for everyone, to use and to build on. Our mission is to provide the tools, so that you can focus on what matters.项目地址: https://gitcode.com/GitHub_Trending/au/AutoGPT当你在使用 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_flagTrue, helpImplies --log-levelDEBUG --log-formatdebug )即它等价于同时指定--log-levelDEBUG与--log-formatdebug。serve子命令Agent Protocol 服务端也有同样的参数定义见 cli.py#L185-L187。调用链是cli.run()解析参数后调用run_auto_gpt(...)后者在 main.py#L198-L205 中把这些参数交给日志配置函数configure_logging( debugdebug, levellog_level, log_formatlog_format, log_file_formatlog_file_format, configconfig.logging, tts_configconfig.tts_config, )真正的落地逻辑在 config.py 的configure_logging()中几个关键点debug与level互斥同时传入两者会直接抛出ValueError(Only one of either debug and level arguments may be set)config.py#L91-L92。因此命令行上不要同时写--debug --log-level...debug 的聚合效果当debugTrue时config.level被置为logging.DEBUGconfig.log_format被置为LogFormatName.DEBUGconfig.py#L114-L118DEBUG 格式的日志行debug格式使用DEBUG_LOG_FORMAT %(levelname)s %(filename)s:%(lineno)d %(title)s%(message)sconfig.py#L28-L29即每条日志都带源文件名和行号。这正是排障时最有价值的信息——你可以直接根据日志里的file:lineno跳回源码定位这也是为什么报 bug 时要用 debug 格式重新跑一遍。用--log-level、--log-format、--log-file-format精细控制除了--debugcli.py 还暴露了三个更细粒度的参数参数取值作用--log-levelPython logging 标准级别CRITICAL、ERROR、WARNING、INFO、DEBUG等来自标准库logging._nameToLevel的键控制日志输出阈值默认INFO--log-formatsimple/debug/structured_google_cloudLogFormatName枚举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_FORMATconfig.py#L171-L177所以即使是日常非 debug 运行出错时的行号信息也不会丢失。通过环境变量等价配置从源码结构看LoggingConfig 定义了环境变量来源命令行参数未指定时会读取这些变量环境变量默认值说明LOG_LEVELINFO日志级别logging.getLevelName解析LOG_FORMATsimple控制台日志格式LOG_FILE_FORMAT未设置时回退LOG_FORMAT否则simple文件日志格式PLAIN_OUTPUTFalse控制台是否纯文本输出也就是说在 Docker 或 CI 场景中你也可以不改启动命令、只注入LOG_LEVELDEBUG LOG_FORMATdebug达到与--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 格式。控制台侧则是双路输出stdouthandler 输出 WARNING 以下的内容经BelowLevelFilterstderr专门收 WARNING 及以上config.py#L145-L153。分享排障材料时把整个生成的 debug 日志目录打包上传即可不必挑文件。提示上传日志前建议先自行检查其中是否包含 API key、令牌等敏感信息日志中可能记录 LLM 调用与工具参数这是分享前的好习惯。通过 E2B 查看与分享日志日志生成后官方推荐的查看与分享通道是 E2B 上的 AutoGPT 日志实例。操作步骤继承自原文档打开autogpt.e2b.dev以纯文本形式给出避免外链并登录。登录后可以看到 AutoGPT 团队成员上传的日志可以直接查看别人跑出来的现场这对理解同类问题很有帮助上传自己的日志点击“Upload log folder”按钮选择你用--debug生成出来的 debug 日志目录等待 1~2 秒后页面自动刷新分享日志直接把浏览器地址栏中的 URL 发给协作者即可对方打开就能逐文件浏览日志内容对应下图中的日志 URL。这种方式相比在 issue 里直接贴日志片段的优势日志目录可能包含多个文件与大量行数E2B 提供了按文件夹浏览、逐行检索的体验链接也天然带版本上传即定格。给日志打标签Tags如果你和团队成员共用这个通道可以给日志打上自定义标签例如标注“该 Agent 在挑战challenges场景下出现问题”。标签名字可以任意取E2B 提供三种严重度severitySuccessWarningError添加标签的步骤点击日志文件夹名称左侧的 “plus”加号按钮输入新标签的名字选择严重度。给标签选严重度时建议与日志本身的性质对齐Agent 正常跑完的参考运行选 Success可疑但可运行的现象选 Warning明确失败、需要团队介入的现场选 Error这样团队成员扫一眼仪表盘就能按严重度分拣。小结与注意事项--debug--log-levelDEBUG --log-formatdebug二者不能与--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子命令均支持--debugPlatform 部分autogpt_platform的日志体系不在本文讨论范围内。【免费下载链接】AutoGPTAutoGPT is the vision of accessible AI for everyone, to use and to build on. Our mission is to provide the tools, so that you can focus on what matters.项目地址: https://gitcode.com/GitHub_Trending/au/AutoGPT创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考