Q: 为什么 nanobot CLI 在 macOS 上运行时,当命令以中文/日文/韩文文本结尾时会崩溃并抛出 UnicodeDecodeError?

原因：nanobot <=0.3.5 在导入 setproctitle 之前无条件地设置 `SPT_NOENV=1`。在 macOS 上，这会将进程标题缓冲区限制在 argv 区域内，而 setproctitle <=1.3.8 在此处会丢弃最后一个字节（上游 bug dvarrazzo/py-setproctitle#167）。如果命令行以多字节 UTF-8 字符（CJK/emoji）结尾，被截断的字节序列会导致 setproctitle 在 macOS 上导入时执行的 `getproctitle()` 抛出 `UnicodeDecodeError: 'utf-8' codec can't decode bytes`，使 CLI 在进行任何模型调用之前就直接崩溃。 修复方法（在 `nanobot/cli/process_identity.py` 中）：仅在 Linux 上设置 SPT_NOENV，因为只有在该平台上它才有实际意义： ```python import sys if sys.platform == "linux": os.environ.setdefault("SPT_NOENV", "1") ``` 可选做法：将 setproctitle 的导入/调用包裹在 try/except 中，使这个仅起装饰作用的进程命名永远不会导致 CLI 崩溃。 在安装修复版本之前的临时解决办法：(1) 在 CJK 文本之后追加一个 ASCII 字符（例如一个末尾空格），使 argv 不以多字节字符结尾；(2) 使用上述补丁修改你的 uv tool 环境中已安装的 `process_identity.py`。注意：自行导出 SPT_NOENV 环境变量并无帮助，因为 setproctitle 只检查该变量是否存在，而不检查其值。Linux 不受影响（在该平台上字节丢失仅是外观问题，不会导致崩溃）。

Q: 如何修复 Windows 11 上 nanobot webui 内存泄漏（RAM 占用过高）的问题？

内存泄漏位于 `nanobot/process_runtime.py::_windows_process_identity()`，该函数在每次调用时都会重新定义一个 `ctypes.Structure` 子类和一个新的 `ctypes.WinDLL("kernel32")`。`ctypes._pointer_type_cache` 会永久保留这些类型对象（约 6.5 KB/次调用），由于 WebUI 启动器每 0.5 秒轮询一次 `runtime.status()`，且网关每 1 秒轮询一次客户端状态，因此即使在空闲状态下，内存也会以约 2.6 MB/分钟（约 3.7 GB/天）的速度增长。修复方法：升级到包含 PR #6507 的 nanobot 版本。作为手动临时解决方案，可以修改 `process_runtime.py`，使 `FileTime` 结构体、其 `ctypes.POINTER` 类型以及 kernel32 `WinDLL` 绑定仅在模块级别创建一次（例如，通过在 `_windows_kernel32()` 辅助函数上使用 `@lru_cache(maxsize=1)`），而不是在每次调用时都创建。

Q: 如何在 Windows 上运行多个 nanobot 实例而不出现 Telegram 'Conflict' 错误?

在 Windows 上,nanobot 会忽略 `NANOBOT_HOME` 环境变量,始终默认使用 `C:\Users\ \.nanobot`,因此两个实例会加载同一个 `config.json` 和同一个 Telegram Bot Token,从而引发 `telegram.error.Conflict` 循环。 **临时解决方法:** 在启动第二个进程之前,为其覆盖 `USERPROFILE`: CMD: ``` set "USERPROFILE=C:\Path\To\Alternative\Home" nanobot gateway ``` **永久修复(即将推出):** PR #6128 新增了一个显式的 `--home` CLI 选项,需放在子命令之前: ``` nanobot --home onboard nanobot --home gateway ``` 这样,每个实例都会使用该目录下各自的配置和工作区。注意:`NANOBOT_HOME` 的支持方案已被否决,改为采用 `--home`;显式的 config/workspace 设置仍具有更高优先级。

Q: 为什么 DuckDuckGo web_search 在连续搜索时出现 "No results found" 错误，以及如何修复？

`DuckDuckGo search failed (No results found.)` 错误是模糊的——它并不能确认零匹配。`ddgs` 库将上游拒绝（例如 Mojeek HTTP 403 封锁）、解析失败和聚合错误都隐藏在这个通用异常背后。连续不停地发起多个不同的查询会触发这些失败；而同样的查询在间隔开来后则能成功。 **解决方法——控制搜索节奏：** 在 web_search 调用之间添加约 3 秒的暂停。已验证的复现：8 个不同的查询无暂停 → 0/8 结果（全部为 `DDGSException: No results found`）；同样的 8 个查询间隔 3 秒 → 8/8 结果。 ```python from ddgs import DDGS d = DDGS(timeout=15) # no pause -> all queries fail with DDGSException: No results found # 3s pause between queries -> all return results ``` **永久修复（PR #6409）：** 该工具现在将模糊的 ddgs 失败如实报告为"no usable search result obtained, cause unknown"，而不是将其呈现为已确认的零匹配。它还区分了工具自身的等待截止时间与 ddgs 报告的超时，同时保留了结果格式、网络路由、取消机制和诊断隐私。 **超出范围：** 移除上游速率限制/反自动化封锁，以及添加自动重试/退避/节奏控制配置。不要假设每个 `No results found` 错误都是速率限制所致。上游错误保留问题在 https://github.com/deedy5/ddgs/issues/478 单独跟踪。

Question 1

为什么 nanobot CLI 在 macOS 上运行时,当命令以中文/日文/韩文文本结尾时会崩溃并抛出 UnicodeDecodeError?

Accepted Answer

原因：nanobot <=0.3.5 在导入 setproctitle 之前无条件地设置 `SPT_NOENV=1`。在 macOS 上，这会将进程标题缓冲区限制在 argv 区域内，而 setproctitle <=1.3.8 在此处会丢弃最后一个字节（上游 bug dvarrazzo/py-setproctitle#167）。如果命令行以多字节 UTF-8 字符（CJK/emoji）结尾，被截断的字节序列会导致 setproctitle 在 macOS 上导入时执行的 `getproctitle()` 抛出 `UnicodeDecodeError: 'utf-8' codec can't decode bytes`，使 CLI 在进行任何模型调用之前就直接崩溃。

修复方法（在 `nanobot/cli/process_identity.py` 中）：仅在 Linux 上设置 SPT_NOENV，因为只有在该平台上它才有实际意义：
```python
import sys
if sys.platform == "linux":
    os.environ.setdefault("SPT_NOENV", "1")
```
可选做法：将 setproctitle 的导入/调用包裹在 try/except 中，使这个仅起装饰作用的进程命名永远不会导致 CLI 崩溃。

在安装修复版本之前的临时解决办法：(1) 在 CJK 文本之后追加一个 ASCII 字符（例如一个末尾空格），使 argv 不以多字节字符结尾；(2) 使用上述补丁修改你的 uv tool 环境中已安装的 `process_identity.py`。注意：自行导出 SPT_NOENV 环境变量并无帮助，因为 setproctitle 只检查该变量是否存在，而不检查其值。Linux 不受影响（在该平台上字节丢失仅是外观问题，不会导致崩溃）。

Question 2

如何修复 Windows 11 上 nanobot webui 内存泄漏（RAM 占用过高）的问题？

Accepted Answer

内存泄漏位于 `nanobot/process_runtime.py::_windows_process_identity()`，该函数在每次调用时都会重新定义一个 `ctypes.Structure` 子类和一个新的 `ctypes.WinDLL("kernel32")`。`ctypes._pointer_type_cache` 会永久保留这些类型对象（约 6.5 KB/次调用），由于 WebUI 启动器每 0.5 秒轮询一次 `runtime.status()`，且网关每 1 秒轮询一次客户端状态，因此即使在空闲状态下，内存也会以约 2.6 MB/分钟（约 3.7 GB/天）的速度增长。修复方法：升级到包含 PR #6507 的 nanobot 版本。作为手动临时解决方案，可以修改 `process_runtime.py`，使 `FileTime` 结构体、其 `ctypes.POINTER` 类型以及 kernel32 `WinDLL` 绑定仅在模块级别创建一次（例如，通过在 `_windows_kernel32()` 辅助函数上使用 `@lru_cache(maxsize=1)`），而不是在每次调用时都创建。

Question 3

如何在 Windows 上运行多个 nanobot 实例而不出现 Telegram 'Conflict' 错误?

Accepted Answer

在 Windows 上,nanobot 会忽略 `NANOBOT_HOME` 环境变量,始终默认使用 `C:\Users\\.nanobot`,因此两个实例会加载同一个 `config.json` 和同一个 Telegram Bot Token,从而引发 `telegram.error.Conflict` 循环。 **临时解决方法:** 在启动第二个进程之前,为其覆盖 `USERPROFILE`: CMD: ``` set "USERPROFILE=C:\Path\To\Alternative\Home" nanobot gateway ``` **永久修复(即将推出):** PR #6128 新增了一个显式的 `--home` CLI 选项,需放在子命令之前: ``` nanobot --home onboard nanobot --home gateway ``` 这样,每个实例都会使用该目录下各自的配置和工作区。注意:`NANOBOT_HOME` 的支持方案已被否决,改为采用 `--home`;显式的 config/workspace 设置仍具有更高优先级。

Question 4

为什么 DuckDuckGo web_search 在连续搜索时出现 "No results found" 错误，以及如何修复？

Accepted Answer

`DuckDuckGo search failed (No results found.)` 错误是模糊的——它并不能确认零匹配。`ddgs` 库将上游拒绝（例如 Mojeek HTTP 403 封锁）、解析失败和聚合错误都隐藏在这个通用异常背后。连续不停地发起多个不同的查询会触发这些失败；而同样的查询在间隔开来后则能成功。

**解决方法——控制搜索节奏：** 在 web_search 调用之间添加约 3 秒的暂停。已验证的复现：8 个不同的查询无暂停 → 0/8 结果（全部为 `DDGSException: No results found`）；同样的 8 个查询间隔 3 秒 → 8/8 结果。

```python
from ddgs import DDGS
d = DDGS(timeout=15)
# no pause -> all queries fail with DDGSException: No results found
# 3s pause between queries -> all return results
```

**永久修复（PR #6409）：** 该工具现在将模糊的 ddgs 失败如实报告为"no usable search result obtained, cause unknown"，而不是将其呈现为已确认的零匹配。它还区分了工具自身的等待截止时间与 ddgs 报告的超时，同时保留了结果格式、网络路由、取消机制和诊断隐私。

**超出范围：** 移除上游速率限制/反自动化封锁，以及添加自动重试/退避/节奏控制配置。不要假设每个 `No results found` 错误都是速率限制所致。上游错误保留问题在 https://github.com/deedy5/ddgs/issues/478 单独跟踪。

Question 5

为什么 nanobot-ai 在空闲时每秒都消耗大量 CPU，该如何解决？

Accepted Answer

原因：在 nanobot-ai 0.3.0 中，`AgentLoop.run` 会在每次 `bus.consume_inbound()` 的 1 秒超时触发时调用 `auto_compact.check_expired(...)`（`nanobot/agent/loop.py`，约第 1032 行）。每次调用都会执行 `SessionManager.list_sessions()`，该方法会打开并解析每一个 `sessions/*.jsonl` 文件，然后通过 `_has_compactable_idle_tail` 完整加载每个已过期的会话。当会话文件达到数千个时，整个目录大约每秒被重新读取一次，每一轮都会逐出会话 LRU 缓存，即使在活跃轮次为零的情况下也会持续占用 CPU（在 2,000 个文件时实测每个 tick 约 0.14 秒）。

变通方案：继承 `AutoCompact` 并重写 `check_expired`，以对扫描进行节流并缓存结果，例如：

```python
import time
from nanobot.agent.compact import AutoCompact

class ThrottledAutoCompact(AutoCompact):
    def __init__(self, *args, scan_interval: float = 60.0, **kwargs):
        super().__init__(*args, **kwargs)
        self._scan_interval = scan_interval
        self._last_scan = 0.0
        self._no_compact_cache = set()  # session ids verified to have nothing to compact

def check_expired(self, *args, **kwargs):
        now = time.monotonic()
        if now - self._last_scan < self._scan_interval:
            return None  # skip scan between intervals
        self._last_scan = now
        return super().check_expired(*args, **kwargs)
```

然后在构建 agent loop 时，注入 `ThrottledAutoCompact` 以替代默认的 `AutoCompact`，并跳过已记录在 `_no_compact_cache` 中的会话，直到它们收到新的轮次。这将空闲扫描的开销从每秒一次降低到每分钟一次。长期修复需要上游进行更改：采用有上限的空闲扫描，或引入索引/缓存元数据层，使开销不再随会话文件总数增长。

nanobot

核心功能

避坑指南

适用场景

标签

快速上手

相似推荐