别再复制日志给AI了！我让Codex自己去观测云查报错 - 努力的小雨
内容提要
本文实测通过观测云 OWL MCP 让 Codex 查询日志，排查知识库 PDF 导入失败问题。Codex 按文档编号、批次、来源和时间查询，定位到文档 1042 在解析阶段报错，PDFBox 提示 trailer 缺少根对象定义。作者回控制台核对，确认六条记录与返回一致，并注意到 partial=true、coverage=unknown 的限制。全程约 94 秒，人工复核约 10 分钟。
延伸解读
MCP 让 AI 直接查日志，但权限与范围需明确
文章展示了 Codex 通过观测云 OWL MCP 直接查询日志，省去人工复制粘贴。但配置中 API Key 权限随账号生效，本次只读操作不代表 Key 只能查询。作者特意限定来源、批次和时间，并声明“先查原因，别改数据”，说明给 AI 开放数据访问时，必须用任务范围约束其行为，避免误操作。
查询结果带 partial 标记，结论需留边界
Codex 返回的记录包含 partial=true 和 coverage=unknown，意味着查询结果可能不完整。作者据此只确认已查到的解析异常，不推断后续阶段是否执行。读者在使用类似工具时，应关注返回中的完整性标记，避免把“没查到”当成“没发生”，尤其在排查多阶段流程时。
人工复核路径：从 6 条到 1 条
作者回控制台按来源和批次筛出 6 条记录，加文档编号后剩 2 条，再展开失败记录核对事件编号和异常原文。这条路径说明 AI 给出的结论仍需人工沿相同条件验证，尤其要确认引用的记录是否唯一对应目标文档，防止相似编号或正文提及造成混淆。
效率对比：94 秒查询 vs 10 分钟复核
Codex 从启动到给出回答约 94 秒，其中仅两次业务查询；人工复核约 10 分钟。时间差异体现 AI 在检索和整理上的优势，但复核仍不可省略。文章也指出，坏 PDF 如何处理仍需根据文件决定，本次未让 AI 自动修改或重跑，说明工具适合定位问题，而非替代修复决策。
Q&A
如何让 Codex 直接查询观测云日志来排查 PDF 导入失败？
通过观测云官方提供的 OWL MCP 接入 Codex。在 Codex CLI 配置中指定 MCP 服务器地址（如 CN3 站点）和 API Key 环境变量，然后给 Codex 提供文档编号、批次号、来源和时间范围，Codex 会调用 owl.data.simple_query 工具查询日志并分析报错。
Codex 查日志时怎么避免把文档 1042 和 10420 搞混？
在查询条件中使用 document_id = '1042' 进行精确字段匹配，而不是直接搜索正文中的数字“1042”。这样能避免匹配到编号 10420 或其他文档消息里顺带提到的 1042。
PDFBox 报错 Missing root object specification in trailer 是什么意思？
这是 PDFBox 在解析 PDF 时抛出的异常，表示 PDF 文件的 trailer（尾部）中缺少根对象定义，导致解析器无法正常读取文件结构。该错误发生在解析阶段（stage=parse），属于不可重试错误（retryable=false）。
Codex 查询日志返回 partial=true 和 coverage=unknown 代表什么？
这两个标记表示查询结果可能不完整，覆盖范围未知。因此可以依据已查到的异常下判断，但不能因为没看到后续阶段就断言后续一定没执行。Codex 的回答也保留了这一限制。
这次用 Codex 查日志排查问题总共花了多长时间？
从启动 Codex 到拿到最终回答用时约 93.6 秒（约 1 分 34 秒），期间共 8 次工具调用，其中 2 次是业务日志查询。之后人工回平台复核约花了 10 分钟。
如何人工复核 Codex 从观测云查到的日志结果？
在观测云日志查看器中选定相同时间范围，按来源和批次筛选得到 6 条记录，再加上 document_id='1042' 筛选剩下 2 条，最后展开失败记录，核对事件编号（末尾 business-04）和异常字段内容是否与 Codex 引用的一致。
