[Bug]建议优化AstrBot自带的WebChat中AI回复的文件被重命名为UUID的问题，测试接了IM平台，比如QQ，QQbot发过来的文件是正常未被重命名的。

[march-7th-mini]

What happened / 发生了什么

在 AstrBot WebChat 界面中，通过 send_message_to_user 工具或主动消息发送文件时，文件名会被强制替换为 UUID 格式（如 c38abaa5-e436-4acb-b0ef-52d6ebe5fc13.html），而非保留原始文件名称。但在 QQ 等 IM 平台中文件名正常保留。

已定位到两处代码均存在 UUID 重命名逻辑：

1. astrbot/core/platform/sources/webchat/webchat_event.py —— _send() 方法中的 File 处理段（影响实时 SSE 流式发送时）
2. astrbot/core/platform/sources/webchat/message_parts_helper.py —— _copy_file_to_attachment_part() 函数（影响 _save_proactive_message 主动消息发送路径）

已在本地做过修补（用 comp.name 原始文件名代替 UUID，并添加防重名计数器后缀），但通过 send_message_to_user 工具发送时，附件目录中保存的文件仍然为 UUID 格式。可能存在第三条未被发现的代码路径，或运行时模块缓存未正确刷新。

已知4.25.1版本我通过AI修改 /AstrBot/astrbot/core/platform/sources/webchat/webchat_event.py配置文件后，重启容器能正常生效。

Reproduce / 如何复现？

1. 通过 HTTP 地址访问 WebChat
2. 发送消息让 AI 生成一个包含文件的消息（例如：「帮我写一个 HTML 页面，保存成 test.html」），或使用工具/插件发送一个文件
3. 观察 WebChat 中收到的文件——文件名显示为 UUID（例如 d7b38a0c-f4c3-4dae-b257-b7b113faa530.html），而非原始名称
4. 在 QQ 等 IM 平台重复相同操作，文件名正常保留

AstrBot version, deployment method (e.g., Windows Docker Desktop deployment), provider used, and messaging platform used. / AstrBot 版本、部署方式（如 Windows Docker Desktop 部署）、使用的提供商、使用的消息平台适配器

• AstrBot 版本： latest（截至 2026-05-31）
• 部署方式： Docker（docker compose，Linux 服务器）
• 使用的提供商： 通用 LLM
• 使用的消息平台： WebChat（内置）

OS

Linux

Logs / 报错日志

位置 1： astrbot/core/platform/sources/webchat/webchat_event.py，_send() 方法，File 处理段：

# 旧代码（导致 UUID 重命名）：
elif isinstance(comp, File):
    file_path = await comp.get_file()
    original_name = comp.name or os.path.basename(file_path)
    ext = os.path.splitext(original_name)[1] or ""
    filename = f"{uuid.uuid4()!s}{ext}"  # ← 此处用 UUID 重命名文件
    dest_path = os.path.join(attachments_dir, filename)
    shutil.copy2(file_path, dest_path)
    data = f"[FILE]{filename}"

位置 2： astrbot/core/platform/sources/webchat/message_parts_helper.py，_copy_file_to_attachment_part() 函数：

# 旧代码：
target_path = attachments_dir / f"{uuid.uuid4().hex}{suffix}"  # ← 此处用 UUID 重命名文件

已尝试的修复（补丁代码）：

webchat_event.py 中将 File 处理段改为：

elif isinstance(comp, File):
    file_path = await comp.get_file()
    original_name = comp.name or os.path.basename(file_path)
    dest_path = os.path.join(attachments_dir, original_name)
    counter = 1
    while os.path.exists(dest_path):
        name_part, ext_part = os.path.splitext(original_name)
        dest_path = os.path.join(attachments_dir, f"{name_part}_{counter}{ext_part}")
        counter += 1
    shutil.copy2(file_path, dest_path)
    data = f"[FILE]{os.path.basename(dest_path)}"

message_parts_helper.py 中将 _copy_file_to_attachment_part 改为：

base_name = display_name or src_path.name
target_path = attachments_dir / base_name
counter = 1
while target_path.exists():
    stem = target_path.stem
    target_path = attachments_dir / f"{stem}_{counter}{suffix}"
    counter += 1
shutil.copy2(src_path, target_path)

测试结果：

• 直接调用 _copy_file_to_attachment_part(display_name="report_2024.html") 能正确保存为 report_2024.html ✅
• 通过 send_message_to_user 工具发送时，附件目录中仍然出现 UUID 命名文件（如 97325d18-10c9-46f6-8c8b-fce961ba1af8.html）❌
• 通过 list_back_request_ids() 确认此时无活跃 SSE 流，消息走 _save_proactive_message 路径
• 已清除 __pycache__ 并多次发送 SIGKILL 重启容器，修正代码已确认加载到运行中的模块（通过 inspect.getsource() 验证）
• 疑似存在第三条代码路径，或运行时模块缓存仍未被正确刷新

Are you willing to submit a PR? / 你愿意提交 PR 吗？

• Yes!

Code of Conduct

• I have read and agree to abide by the project's Code of Conduct。

[dosubot]

感谢详细的 bug 报告和定位分析！你已经修补的两处确实是 WebChat 层面的主要路径，但文件在到达那里之前就可能已经被 UUID 重命名了。以下是可能的"第三条路径"：

上游预处理阶段（最可能的原因）：

1. astrbot/core/tools/message_tools.py — send_message_to_user 工具在解析沙盒文件时，会将文件重命名为 sandbox_{uuid[:4]}_{name} 格式 [1]。这发生在消息组件创建之前，因此即使你的 webchat 补丁保留了 comp.name，该 name 本身已经是 UUID 化的了。

2. astrbot/core/message_components.py — 当 File 组件来源是 URL 时，convert_to_file_path() 下载文件并命名为 fileseg_{name}_{uuid.uuid4().hex[:8]}{ext} [2]。

3. astrbot/core/utils/media_processing.py — 音频文件会被 PreProcessStage 预处理，转为 WAV 并命名为 media_audio_{uuid.uuid4().hex}.wav [3]。

验证建议：

在你两处补丁的入口加日志，打印 comp.name 和 file_path 的值——如果到达时已经是 UUID，说明问题在上游。根据你的文件来源类型（沙盒 / URL / 本地路径），对应修补上述位置即可。

你提交 PR 时可以考虑在 message_tools.py 的文件解析逻辑中保留原始文件名，同时在 webchat 层用防重名计数器确保不冲突，这样是最完整的修复方案。

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[march-7th-mini]

我回退版本重头测试了一遍。

我的设置配置：允许 Agent 访问的环境：设置为local 。

已实际验证，AstrBot WebChat local 权限场景下使用只需修改 webchat_event.py 这一个文件就足够了：

修改后测试结果：

• ✅ 对话中 SSE 流式发文件 → 原名保存
• ✅ 重新覆盖安装测试v4.25.1 和 v4.25.2 ，均正常工作

之前反复 UUID 的原因： 我尝试让 AI 直接重启容器（kill -9 1），但容器内进程权限不够，没真正重启。后续用手动在 1Panel 重启后立即生效。

改动的代码（替换 File 处理段的 UUID 重命名逻辑）：

# 旧
filename = f"{uuid.uuid4()!s}{ext}"

# 新
original_name = comp.name or os.path.basename(file_path)
dest_path = os.path.join(attachments_dir, original_name)
counter = 1
while os.path.exists(dest_path):
    name_part, ext_part = os.path.splitext(original_name)
    dest_path = os.path.join(attachments_dir, f"{name_part}_{counter}{ext_part}")
    counter += 1

关于上游 message_tools.py 和 components.py 的 UUID 问题，本地文件路径不会触发，沙盒/URL 场景等大佬单独处理。

计划提交 PR 时目前只对 webchat_event.py进行修改 。