file_extract 默认关闭导致文件内容丢失，LLM 只看到 [File] 占位符

[sunlonglong-creator]

问题

通过 QQ 发送文件给机器人时，LLM 看不到文件内容，只收到 [File] 占位符或 <attachment>，文件 URL 完全丢掉了。

复现

1. 在 QQ 中向机器人发送一个文件（不附带文字，或附带文字如"帮我看下"）
2. LLM 回复中完全不知道文件内容，或一问三不知
3. 检查日志可以看到请求中 prompt 为空或仅有文字，文件 URL 未出现在上下文里

链路分析

QQ文件事件 → aiocqhttp_adapter
  → message_str = ""（File 不贡献文本）
  → File(url=..., name=...) 存入消息链 ✓

internal.py (InternalAgentSubStage.process):
  → has_media_content = True ✓（不会跳过请求）
  → file_extract_enabled = False（默认关闭）
  → _apply_file_extract 被跳过！

astr_main_agent.py (build_main_agent):
  → req.prompt 为空（如果无附带文字）
  → 无 image_urls、无 audio_urls
  → has_reply = False → return None  ← 整个请求被丢弃

如果带了文字一起发送，req.prompt 有内容不会 return None，但文件的 URL/路径仍然没有传给 LLM —— 它只知道有文件但不知道是什么、怎么读。

根因

core/utils/file_extract.py 的 Moonshot AI 文件提取功能默认 enable: False。关闭之后，AstrBot 没有任何备用机制将文件 URL 或本地路径透传给 LLM 或上下文。文件消息的 URL 被闷在 File 组件里，从未进入 ProviderRequest.contexts 或 req.prompt。

建议修复方向

1. 最低成本方案：不依赖 Moonshot AI，直接把文件 URL/名称追加到 req.prompt 或 req.contexts 中，类似 "[用户上传了文件: xxx.pdf，URL: https://...]"，让 LLM 知道有文件并可以调 astrbot_file_read_tool 来读。
2. 完整方案：对常见纯文本格式（.txt, .md, .py, .log 等）做本地读取后直接注入上下文，不经过 Moonshot API。
3. 配置层面：file_extract.enable 默认值改为 true 或增加一个 fallback 开关。

环境

• AstrBot: v4.25.6（uv tool 安装）
• 平台: aiocqhttp (QQ / Napcat)
• 模型: deepseek-v4-flash (Sensenova API)

[dosubot]

感谢详细的分析。经过代码确认，情况和你描述的有些出入——当前代码中 已经存在一个 fallback 机制，只是它传递的信息有限：

当 file_extract 关闭时，build_main_agent() 会将文件信息以文本注释形式注入 req.extra_user_content_parts [1]：

elif isinstance(comp, File):
    file_path = await comp.get_file()
    file_name = comp.name or os.path.basename(file_path)
    req.extra_user_content_parts.append(
        TextPart(text=f"[File Attachment: name {file_name}, path {file_path}]")
    )

这些 TextPart 最终会被组装进 LLM 的用户消息中 [2]，所以 LLM 理论上能看到文件名和本地路径，而非完全空白。

但问题在于：

• LLM 只能看到 [File Attachment: name xxx.pdf, path /tmp/xxx.pdf] 这样的占位信息，看不到实际内容
• 如果你没有附带文字且 req.prompt 为空，确实可能触发提前 return

你的建议方向是合理的。目前的 fallback 只给了元数据，没有给 URL（只给了本地 path），也没有自动触发 tool call 去读取文件。改进方向可以是：

1. 把文件 URL 也注入注释中（目前只注入了 file_path，没有 comp.url）
2. 对纯文本类文件做本地读取直接注入上下文
3. 在 system prompt 中提示 LLM 可以调用 astrbot_file_read_tool 来读取文件

建议开一个 PR 来改进这个 fallback 路径，核心改动在 astr_main_agent.py 的 File 处理分支中。

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[sunlonglong-creator]

感谢详细的分析。经过代码确认，情况和你描述的有些出入——当前代码中 已经存在一个 fallback 机制，只是它传递的信息有限：

当 file_extract 关闭时，build_main_agent() 会将文件信息以文本注释形式注入 req.extra_user_content_parts [1]：

elif isinstance(comp, File):
file_path = await comp.get_file()
file_name = comp.name or os.path.basename(file_path)
req.extra_user_content_parts.append(
TextPart(text=f"[File Attachment: name {file_name}, path {file_path}]")
)
这些 TextPart 最终会被组装进 LLM 的用户消息中 [2]，所以 LLM 理论上能看到文件名和本地路径，而非完全空白。

但问题在于：

• LLM 只能看到 [File Attachment: name xxx.pdf, path /tmp/xxx.pdf] 这样的占位信息，看不到实际内容
• 如果你没有附带文字且 req.prompt 为空，确实可能触发提前 return

你的建议方向是合理的。目前的 fallback 只给了元数据，没有给 URL（只给了本地 path），也没有自动触发 tool call 去读取文件。改进方向可以是：

1. 把文件 URL 也注入注释中（目前只注入了 file_path，没有 comp.url）
2. 对纯文本类文件做本地读取直接注入上下文
3. 在 system prompt 中提示 LLM 可以调用 astrbot_file_read_tool 来读取文件

建议开一个 PR 来改进这个 fallback 路径，核心改动在 astr_main_agent.py 的 File 处理分支中。

To reply, just mention @dosu.

Share context across your team and agents. Try Dosu.

但关键是，LLM没有真正收到这些，没有做出任何反应，哪怕想我一样干等30分钟也没用

[dosubot]

进一步确认了代码逻辑：当你只发文件（不带文字）时，build_main_agent() 的 early return 逻辑理论上不会丢弃请求。因为文件会先被加入 req.extra_user_content_parts，然后在判断是否 return None 时会检查它是否非空 [1]：

if not req.prompt and not req.image_urls and not req.audio_urls:
    if has_reply or req.extra_user_content_parts:
        req.prompt = "<attachment>"
    else:
        return None

所以如果 extra_user_content_parts 有内容，会设置 req.prompt = "<attachment>" 继续处理，而不是 return None。

你遇到的"LLM 完全没反应/干等 30 分钟"更可能是以下情况之一：

1. comp.get_file() 下载超时或失败 — 如果文件下载卡住，整个请求会阻塞
2. LLM API 调用超时 — DeepSeek/Sensenova 接口可能因为某些原因未正常返回
3. 文件组件在 adapter 层就没被正确解析 — 导致 extra_user_content_parts 实际上是空的，触发了 return None

建议排查：

• 检查日志中是否有 comp.get_file() 的下载错误或超时
• 确认日志中是否出现了 "<attachment>" 被设为 prompt 的记录
• 看看请求是否真的到达了 LLM API（搜索 API 调用日志）

如果能贴一下相关的调试日志，可以更精确定位卡在哪一步。

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[sunlonglong-creator]

进一步确认了代码逻辑：当你只发文件（不带文字）时，build_main_agent() 的 early return 逻辑理论上不会丢弃请求。因为文件会先被加入 req.extra_user_content_parts，然后在判断是否 return None 时会检查它是否非空 [1]：

if not req.prompt and not req.image_urls and not req.audio_urls:
if has_reply or req.extra_user_content_parts:
req.prompt = ""
else:
return None
所以如果 extra_user_content_parts 有内容，会设置 req.prompt = "<attachment>" 继续处理，而不是 return None。

你遇到的"LLM 完全没反应/干等 30 分钟"更可能是以下情况之一：

1. comp.get_file() 下载超时或失败 — 如果文件下载卡住，整个请求会阻塞
2. LLM API 调用超时 — DeepSeek/Sensenova 接口可能因为某些原因未正常返回
3. 文件组件在 adapter 层就没被正确解析 — 导致 extra_user_content_parts 实际上是空的，触发了 return None

建议排查：

• 检查日志中是否有 comp.get_file() 的下载错误或超时
• 确认日志中是否出现了 "<attachment>" 被设为 prompt 的记录
• 看看请求是否真的到达了 LLM API（搜索 API 调用日志）

如果能贴一下相关的调试日志，可以更精确定位卡在哪一步。

To reply, just mention @dosu.

Docs are dead. Just use Dosu.

查了LLM API后台，没到LLM API，日志里没有相关有用信息