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를 직접 export해도 도움이 되지 않습니다. 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 릴리스로 업그레이드하십시오. 수동 해결 방법으로는 `FileTime` 구조체, 그 `ctypes.POINTER` 타입들, 그리고 kernel32 `WinDLL` 바인딩이 매 호출 시 생성되는 대신 모듈 수준에서 한 번만 생성되도록 `process_runtime.py`를 패치하십시오(예: `_windows_kernel32()` 헬퍼에 `@lru_cache(maxsize=1)` 적용).

Q: Windows에서 Telegram 'Conflict' 오류 없이 여러 nanobot 인스턴스를 실행하는 방법은?

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 ``` 그러면 각 인스턴스가 해당 디렉터리 아래에서 자체 config와 workspace를 사용합니다. 참고: `NANOBOT_HOME` 지원은 `--home`을 채택하는 방향으로 거부되었으며, 명시적 config/workspace 설정이 여전히 우선 적용됩니다.

Q: DuckDuckGo web_search가 연속 검색 시 "No results found" 오류로 실패하는 이유는 무엇이며, 어떻게 해결할 수 있나요?

`DuckDuckGo search failed (No results found.)` 오류는 모호합니다 — 이는 일치하는 결과가 0건임을 확인해 주지 않습니다. `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 실패를 확인된 0건 일치로 표시하는 대신 "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를 직접 export해도 도움이 되지 않습니다. 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 릴리스로 업그레이드하십시오. 수동 해결 방법으로는 `FileTime` 구조체, 그 `ctypes.POINTER` 타입들, 그리고 kernel32 `WinDLL` 바인딩이 매 호출 시 생성되는 대신 모듈 수준에서 한 번만 생성되도록 `process_runtime.py`를 패치하십시오(예: `_windows_kernel32()` 헬퍼에 `@lru_cache(maxsize=1)` 적용).

Question 3

Windows에서 Telegram 'Conflict' 오류 없이 여러 nanobot 인스턴스를 실행하는 방법은?

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 ``` 그러면 각 인스턴스가 해당 디렉터리 아래에서 자체 config와 workspace를 사용합니다. 참고: `NANOBOT_HOME` 지원은 `--home`을 채택하는 방향으로 거부되었으며, 명시적 config/workspace 설정이 여전히 우선 적용됩니다.

Question 4

DuckDuckGo web_search가 연속 검색 시 "No results found" 오류로 실패하는 이유는 무엇이며, 어떻게 해결할 수 있나요?

Accepted Answer

`DuckDuckGo search failed (No results found.)` 오류는 모호합니다 — 이는 일치하는 결과가 0건임을 확인해 주지 않습니다. `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 실패를 확인된 0건 일치로 표시하는 대신 "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개 기준 틱당 약 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회로 줄어듭니다. 장기적인 수정에는 업스트림 변경이 필요합니다: 비용이 더 이상 전체 세션 파일 수에 비례하지 않도록 제한된(bounded) 유휴 스캔 또는 인덱스/캐시된 메타데이터 계층이 필요합니다.

nanobot

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트