[BUG]: Backend helper process crashes during agent sessions; ~830 MB leaked per agent exchange

问题场景

用户在 AnythingLLM Desktop 1.16.0 的 Agent 模式下工作，配置 Local AI（OpenAI 兼容）提供 LLM 服务，启用了文件系统访问、文档创建和网页浏览技能，并挂载了一个 MCP 服务器。工作区附带一个约 50 KB 文本的小型 PDF。当用户发送一个要求分析文档并生成 PDF 的请求时，第一次交互成功（生成 PDF 并显示下载卡片），但在同一线程中发送第二条消息时，会话瞬间结束并显示 “Agent session complete.”，且没有任何输出——实际是后端辅助进程已经崩溃。此崩溃在两天内出现 15 次，每次都以 macOS 的 EXC_BREAKPOINT（SIGTRAP）终止信号报告。

报错原文

[BUG]: Backend helper process crashes during agent sessions; ~830 MB leaked per agent exchange

exception    EXC_BREAKPOINT (SIGTRAP)
termination  SIGNAL code=5, byProc: "exc handler", byPid: <the backend pid>
frames       Electron Framework … libsystem_malloc.dylib _malloc_zone_memalign

[AgentHandler] Injecting N parsed file(s) into user message

Maximum tool call limit (10) reached. After this tool I will generate a final response.

原因分析

根据 Issue 的证据，最可能的原因如下：

后端进程在每次 Agent 交互中泄漏约 830 MB 内存，且从不释放，最终进程因内存耗尽而崩溃。但崩溃报告中未出现 “JavaScript heap out of memory” 字符串，因此不能确认是典型的 V8 堆耗尽，更可能是原生层（libsystem_malloc）的内存分配失败导致进程主动中止（SIGTRAP / EXC_BREAKPOINT）。

触发崩溃的关键路径似乎与 Document Creation 技能相关：create-pdf-file 工具将整个文档正文作为字符串参数传递给模型，在一次会话中模型可能多次调用该工具，每次都携带近 5，000 字的载荷并保留在对话记录中。当用户发送下一条消息时，后端需要组装之前的分析、工具调用记录中完整的两份文档副本以及重新注入的解析文件——整个组装过程正好是崩溃点。

有意思的是，Chat 模式（非 Agent）在相同文档和模型下完全稳定，只有 Agent 模式会崩溃，这与最后一条日志行落在 AgentHandler 上的现象一致。LLM 提供方本身没有问题：直接 curl 本地 OpenAI 兼容服务器时响应时间 0.868 秒，且设置面板不经过 LLM 也会挂起，因此可排除模型提供方的原因。

环境排查

• 确认 AnythingLLM Desktop 版本是否为 1.16.0（1.14.0 未启用 Document Creation 时无崩溃记录）。
• 确认操作系统版本为 macOS 26.6.1（原始报告中的 15.7.7 是笔误）。
• 确认 LLM 提供方为 Local AI（OpenAI 兼容端点，例如 mlx_lm.server）——更换模型（如 gemma-4-26b-a4b-it-MLX-8bit）仍可复现，说明与具体模型无关。
• 确认是否启用了 Document Creation 技能——这是最可疑的触发点。
• 确认工作区附加文件的类型和大小：PDF（约 50 KB 文本）为实际限制，一个 PDF 对应一次启动。
• 通过 lsof -nP -tiTCP:3001 -sTCP:LISTEN 查看后端 PID，再用 ps -o rss= -p <pid> 监控每次 Agent 交互后的内存变化，确认是否每次增加约 830 MB。
• 检查 storage/logs/backend-YYYY-MM-DD.log 中崩溃会话的最后一行是否为 [AgentHandler] Injecting N parsed file(s) into user message，且其后无任何错误行。

解决步骤

1. 禁用 Document Creation 技能（可优先尝试）：在 Agent 模式的工作区中关闭 Document Creation 技能，保持其他技能不变，然后在相同工作区中重复相同的操作流程，观察是否还能触发崩溃。
2. 避免在同一线程中连续发送消息：如果 Document Creation 技能必须保留，则每次 Agent 交互后开新线程，不要在同一线程中发送第二条消息，以规避崩溃触发路径。
3. 监控后端进程的内存增长：使用 lsof -nP -tiTCP:3001 -sTCP:LISTEN 找到后端 PID，配合 ps -o rss= -p <pid> 每两分钟采样一次，确认每次 Agent 交互后内存是否增加约 830 MB 并持续持有不释放。
4. 检查 workspace_agent_invocations 中的未关闭会话：在崩溃前 3–249 秒内是否存在 closed = 0 的 Agent 会话——每次崩溃都伴随一个未关闭会话，一一对应。
5. 更换为 Chat 模式验证：相同文档和模型下使用 Chat 模式（而非 Agent 模式）发送多轮消息，确认不会崩溃，以验证问题仅限于 Agent 模式的后端路径。
6. 确认工具调用上限未强制执行：当模型无法找到生成的文件并循环调用 filesystem-list-directory 和 filesystem-search-files 时，后端会输出 “Maximum tool call limit (10) reached” 但不会真正停止——注意此提示后仍会继续调用工具，最终不会生成最终响应。此问题与崩溃可能独立，但建议同时记录并报告。
7. 在 GitHub Issue 中反馈复现结果：将禁用 Document Creation 后的测试结果、内存采样数据和未关闭会话的记录补充到原始 Issue 中，帮助开发者定位根因。

验证方法

禁用 Document Creation 技能后，在同一工作区、同一文档、同一模型下连续进行多轮 Agent 交互，观察是否不再出现会话立即结束、后端进程是否保持稳定。每两分钟采样后端进程的 RSS 内存，确认每次交互不再增加约 830 MB。检查 macOS 崩溃报告目录中是否不再有新的 EXC_BREAKPOINT（SIGTRAP）报告，并确认 workspace_agent_invocations 表中不再出现 closed = 0 的未关闭会话。如果禁用了 Document Creation 后连续 3–5 次重启并重复完整操作流程均未崩溃，即可确认该技能是崩溃触发点。

参考来源

Mintplex-Labs/anything-llm #6145

AI 工具推荐

想把多个 AI 模型放在一个入口？

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。