Q: コマンドが中国語/日本語/韓国語のテキストで終わる場合に、nanobot CLI が macOS で UnicodeDecodeError によりクラッシュするのはなぜですか?

原因: nanobot <=0.3.5 は setproctitle をインポートする前に `SPT_NOENV=1` を無条件に設定します。macOS ではこれによりプロセスタイトル用のバッファが argv 領域に限定され、setproctitle <=1.3.8 ではそこで最終バイトが欠落します（上流のバグ dvarrazzo/py-setproctitle#167）。コマンドラインがマルチバイト UTF-8 文字（CJK/絵文字）で終わっている場合、途中で切り詰められたバイト列が原因で、setproctitle の macOS 固有のインポート時に実行される `getproctitle()` が `UnicodeDecodeError: 'utf-8' codec can't decode bytes` を発生させ、モデル呼び出しが行われる前に CLI が終了してしまいます。 修正（`nanobot/cli/process_identity.py` 内）: SPT_NOENV は、実際に意味を持つ Linux でのみ設定します: ```python import sys if sys.platform == "linux": os.environ.setdefault("SPT_NOENV", "1") ``` 必要に応じて、setproctitle のインポート/呼び出しを try/except で囲み、装飾的なプロセス命名によって CLI がクラッシュすることが決してないようにしてください。 修正済みリリースがインストールされるまでの回避策: (1) argv がマルチバイト文字で終わらないように、CJK テキストの後ろに ASCII 文字（例: 末尾のスペース）を追加する。(2) uv ツール環境にインストールされている `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でTelegramの「Conflict」エラーを回避して複数のnanobotインスタンスを実行する方法

Windowsでは、nanobotは`NANOBOT_HOME`環境変数を無視し、常に`C:\Users\ \.nanobot`をデフォルトとして使用します。そのため、2つのインスタンスが同じ`config.json`と同じTelegram Bot Tokenを読み込み、`telegram.error.Conflict`ループが発生します。**回避策:** 2つ目のプロセスを起動する前に`USERPROFILE`を上書きしてください: CMD: ``` set "USERPROFILE=C:\Path\To\Alternative\Home" nanobot gateway ``` **恒久的な修正（近日提供予定）:** PR #6128では、サブコマンドの前に指定する明示的な`--home` CLIオプションが追加されます: ``` nanobot --home onboard nanobot --home gateway ``` これにより、各インスタンスはそのディレクトリ配下で独自のconfigとworkspaceを使用するようになります。注意: `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) # 間隔なし -> すべてのクエリが DDGSException: No results found で失敗 # クエリ間に3秒の間隔 -> すべて結果を返す ``` **恒久修正 (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 ではそこで最終バイトが欠落します（上流のバグ dvarrazzo/py-setproctitle#167）。コマンドラインがマルチバイト UTF-8 文字（CJK/絵文字）で終わっている場合、途中で切り詰められたバイト列が原因で、setproctitle の macOS 固有のインポート時に実行される `getproctitle()` が `UnicodeDecodeError: 'utf-8' codec can't decode bytes` を発生させ、モデル呼び出しが行われる前に CLI が終了してしまいます。

修正（`nanobot/cli/process_identity.py` 内）: SPT_NOENV は、実際に意味を持つ Linux でのみ設定します:
```python
import sys
if sys.platform == "linux":
    os.environ.setdefault("SPT_NOENV", "1")
```
必要に応じて、setproctitle のインポート/呼び出しを try/except で囲み、装飾的なプロセス命名によって CLI がクラッシュすることが決してないようにしてください。

修正済みリリースがインストールされるまでの回避策: (1) argv がマルチバイト文字で終わらないように、CJK テキストの後ろに ASCII 文字（例: 末尾のスペース）を追加する。(2) uv ツール環境にインストールされている `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でTelegramの「Conflict」エラーを回避して複数のnanobotインスタンスを実行する方法

Accepted Answer

Windowsでは、nanobotは`NANOBOT_HOME`環境変数を無視し、常に`C:\Users\\.nanobot`をデフォルトとして使用します。そのため、2つのインスタンスが同じ`config.json`と同じTelegram Bot Tokenを読み込み、`telegram.error.Conflict`ループが発生します。**回避策:** 2つ目のプロセスを起動する前に`USERPROFILE`を上書きしてください: CMD: ``` set "USERPROFILE=C:\Path\To\Alternative\Home" nanobot gateway ``` **恒久的な修正（近日提供予定）:** PR #6128では、サブコマンドの前に指定する明示的な`--home` CLIオプションが追加されます: ``` nanobot --home onboard nanobot --home gateway ``` これにより、各インスタンスはそのディレクトリ配下で独自のconfigとworkspaceを使用するようになります。注意: `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)
# 間隔なし -> すべてのクエリが DDGSException: No results found で失敗
# クエリ間に3秒の間隔 -> すべて結果を返す
```

**恒久修正 (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` が 1 秒ごとの `bus.consume_inbound()` タイムアウトのたびに `auto_compact.check_expired(...)` を呼び出します（`nanobot/agent/loop.py`、約 1032 行目）。各呼び出しで `SessionManager.list_sessions()` が実行され、すべての `sessions/*.jsonl` ファイルを開いて解析し、さらに `_has_compactable_idle_tail` を介して期限切れの各セッションを完全にロードします。セッションファイルが数千件ある場合、ディレクトリ全体が約 1 秒ごとに再読み込みされ、パスのたびにセッションの LRU キャッシュが追い出され、アクティブなターンがゼロでも CPU が圧迫されます（2,000 ファイル時に 1 ティックあたり約 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)
```

その後、エージェントループを構築する際にデフォルトの `AutoCompact` の代わりに `ThrottledAutoCompact` を注入し、`_no_compact_cache` に記録済みのセッションは新しいターンを受け取るまでスキップします。これにより、アイドル時のスキャンコストが 1 秒ごとから 1 分ごとに削減されます。長期的な修正にはアップストリームでの変更が必要です。つまり、上限のあるアイドルスキャン、またはインデックス/キャッシュ済みメタデータ層を導入し、コストがセッションファイル総数に比例して増大しないようにする必要があります。

nanobot

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト