chore: import upstream snapshot with attribution
This commit is contained in:
wehub-resource-sync
@@ -0,0 +1,29 @@
|
||||
# Design Constraints
|
||||
|
||||
These rules govern architectural decisions. When adding a feature or fixing a bug, prefer paths that respect these boundaries.
|
||||
|
||||
## Core stays small; extend at the edges
|
||||
|
||||
New capabilities should be added via `channels/`, `tools/`, skills, or MCP servers. The files `agent/loop.py` and `agent/runner.py` form the critical core path; changes there should be minimal and justified. If a feature can live in a channel adapter, a tool, or an external MCP server, it should not be inlined into the agent loop.
|
||||
|
||||
Runtime state fan-out follows the same boundary. `AgentLoop` may publish generic runtime events from `nanobot.bus.runtime_events` for turn/run/model/goal state changes, but WebUI/WebSocket wire details such as `_turn_end`, `_goal_status`, title refreshes, and goal-state sync belong in `nanobot.session.webui_turns.WebuiTurnCoordinator` or the relevant channel adapter.
|
||||
|
||||
## Less structure, more intelligence
|
||||
|
||||
Prefer simple, readable code over new framework layers and indirection. Add structure only when it removes real complexity, protects an important boundary, or matches an established local pattern. The best fix is often a smaller prompt, a tighter tool contract, a channel-local change, or one focused regression test.
|
||||
|
||||
## Prefer duplication over premature abstraction
|
||||
|
||||
Channels and providers are allowed to repeat similar logic (send retries, media handling, message splitting). Do not introduce complex base classes or shared helpers just to eliminate duplication across channel files. Each channel file should remain self-contained and readable on its own. The same applies to provider implementations.
|
||||
|
||||
## Minimal change that solves the real problem
|
||||
|
||||
Fix bugs by changing only what is necessary. Do not bundle unrelated refactors or clean-ups into a feature or bugfix PR. If a refactor is genuinely required, it should be a separate, clearly scoped PR.
|
||||
|
||||
## Keep PRs reviewable
|
||||
|
||||
A bugfix should make the protected invariant clear, change the smallest surface that enforces it, and add only the closest regression test. If a diff starts changing ownership boundaries or mixing behavior changes with clean-up, split it before it becomes hard to review.
|
||||
|
||||
## Explicit over magical
|
||||
|
||||
Configuration must be declared explicitly in `config/schema.py` Pydantic models. Error handling should raise clear exceptions rather than silently correcting bad input. Provider auto-detection exists, but every resolution path must be traceable from the factory to the concrete provider class.
|
||||
@@ -0,0 +1,40 @@
|
||||
# Common Gotchas
|
||||
|
||||
## Do not use `ruff format`
|
||||
|
||||
`CONTRIBUTING.md` mentions `ruff format`, but **do not run it** — it destroys git blame history. Only `ruff check` should be used.
|
||||
|
||||
## Config `${VAR}` References
|
||||
|
||||
`config/loader.py` resolves `${VAR}` patterns in `config.json` at load time. This is **not** a shell-like default-value syntax. If the environment variable is missing, `load_config` raises `ValueError` and the agent falls back to default configuration.
|
||||
|
||||
Example valid usage:
|
||||
```json
|
||||
{ "providers": { "openrouter": { "apiKey": "${OPENROUTER_KEY}" } } }
|
||||
```
|
||||
|
||||
## Windows Compatibility
|
||||
|
||||
nanobot explicitly supports Windows. Key differences to keep in mind:
|
||||
- `ExecTool` defaults to PowerShell on Windows (`pwsh` when available, otherwise Windows PowerShell); pass `shell="cmd"` for cmd.exe syntax or cmd built-ins (`shell.py`).
|
||||
- `cli/commands.py` forces `sys.stdout`/`stderr` to UTF-8 on startup to handle emoji and multilingual input.
|
||||
- MCP stdio server commands are normalized for Windows path separators (`mcp.py`).
|
||||
- Always use `pathlib.Path` for path manipulation; do not assume `/` separators.
|
||||
|
||||
## Prompt Templates
|
||||
|
||||
Agent system prompts and scenario-specific instructions live in `nanobot/templates/` as Jinja2 markdown files (`identity.md`, `platform_policy.md`, `HEARTBEAT.md`, `SOUL.md`, etc.). Changing these files alters agent behavior as directly as changing Python code. They are loaded by `utils/prompt_templates.py`.
|
||||
|
||||
Tool descriptions, skills, and replayed session history also shape model behavior. Treat changes to those surfaces like runtime code: keep them narrow, add a focused regression test when possible, and avoid teaching the model to repeat internal markers, local paths, or tool-call text.
|
||||
|
||||
## Context Pollution Persists
|
||||
|
||||
Anything written into memory, session history, or prompt inputs can be replayed into future LLM calls. Metadata such as timestamps, local media paths, tool-call echoes, and raw fallback dumps must be bounded and sanitized before they become examples for the model to imitate.
|
||||
|
||||
## Skills as Extension Point
|
||||
|
||||
Built-in skills live in `nanobot/skills/` (markdown + YAML frontmatter format). Agent capabilities that are "know-how" rather than code should be added as skills, not hardcoded into the agent loop. External skills can be published to and installed from ClawHub.
|
||||
|
||||
## Atomic Session Writes
|
||||
|
||||
`agent/memory.py` writes `history.jsonl` atomically (temp file + fsync + rename + directory fsync). This guarantees durability across crashes. Do not replace this with a plain `open(..., "w")` write.
|
||||
@@ -0,0 +1,29 @@
|
||||
# Security Boundaries
|
||||
|
||||
The agent operates with significant power (file system, shell, web). The following guards must not be bypassed when modifying related code.
|
||||
|
||||
## Workspace Restriction
|
||||
|
||||
Filesystem tools (`read_file`, `write_file`, `edit_file`, `list_dir`, `apply_patch`) resolve paths through the workspace path resolver (`agent/tools/filesystem.py` / `agent/tools/path_utils.py`), which enforces that the resolved path must lie under the active workspace when workspace restriction is enabled. The media upload directory is always an internal extra read root while restricted.
|
||||
|
||||
Additional filesystem roots must be capability-specific. `extra_allowed_dirs` is a legacy read-only alias. Use `extra_read_allowed_dirs` for read-only roots, `extra_write_allowed_dirs` only when a write-capable tool is intentionally allowed to modify an extra directory, and exact file allowlists when a tool may modify only specific files.
|
||||
|
||||
Shell execution (`ExecTool`, `agent/tools/shell.py`) also respects `restrict_to_workspace` as an application-level guard: if enabled and `working_dir` is outside the workspace, the command is rejected before execution, and command text is checked for obvious workspace escapes. This is not process-level isolation; use an exec sandbox backend for that.
|
||||
|
||||
**Rule**: Any new path-handling logic must go through the workspace path resolver or perform an equivalent containment check with explicit read/write capability semantics.
|
||||
|
||||
## SSRF Protection
|
||||
|
||||
All outbound HTTP requests from agent tools must pass through `validate_url_target` (`security/network.py`). By default it blocks loopback, RFC1918 private addresses, CGNAT ranges, link-local ranges, and cloud metadata endpoints (including `169.254.169.254`).
|
||||
|
||||
The only escape hatch is `configure_ssrf_whitelist(cidrs)`, which reads from `config.tools.ssrf_whitelist` at load time.
|
||||
|
||||
HTTP/SSE MCP transports are part of this boundary: validate configured MCP URLs before probing or constructing clients, and validate each outgoing HTTP request before redirects are followed. Local/private HTTP MCP endpoints are allowed only through the explicit SSRF whitelist. Stdio MCP servers are not part of the HTTP SSRF path.
|
||||
|
||||
**Rule**: Do not add direct `httpx.get` / `requests.get` calls in tools. Route through the existing web fetch utilities or replicate the `validate_url_target` check.
|
||||
|
||||
## Shell Sandbox
|
||||
|
||||
`tools/sandbox.py` provides optional command wrapping. The only backend currently shipped is `bwrap` (bubblewrap), intended for containerized deployments. On Windows and bare-metal Linux without `bwrap`, commands run in the native shell with workspace restriction as an application-level guard only.
|
||||
|
||||
**Rule**: If adding a new sandbox backend, implement `_wrap_<name>(command, workspace, cwd) -> str` and register it in `_BACKENDS`.
|
||||
@@ -0,0 +1,14 @@
|
||||
__pycache__
|
||||
*.pyc
|
||||
*.pyo
|
||||
*.pyd
|
||||
*.egg-info
|
||||
dist/
|
||||
build/
|
||||
nanobot/web/dist/
|
||||
.git
|
||||
.env
|
||||
.assets
|
||||
node_modules/
|
||||
bridge/dist/
|
||||
workspace/
|
||||
@@ -0,0 +1,2 @@
|
||||
# Ensure shell scripts always use LF line endings (Docker/Linux compat)
|
||||
*.sh text eol=lf
|
||||
@@ -0,0 +1,135 @@
|
||||
name: Bug Report
|
||||
description: Report a bug or unexpected behavior
|
||||
labels: ["bug"]
|
||||
body:
|
||||
- type: markdown
|
||||
attributes:
|
||||
value: |
|
||||
Thanks for reporting a bug! Please fill out the sections below to help us diagnose the issue.
|
||||
|
||||
- type: textarea
|
||||
id: description
|
||||
attributes:
|
||||
label: Bug Description
|
||||
description: A clear description of what went wrong.
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: steps
|
||||
attributes:
|
||||
label: Steps to Reproduce
|
||||
description: How can we reproduce this behavior?
|
||||
placeholder: |
|
||||
1. Configure nanobot with ...
|
||||
2. Send message ...
|
||||
3. See error ...
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: expected
|
||||
attributes:
|
||||
label: Expected Behavior
|
||||
description: What did you expect to happen?
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: logs
|
||||
attributes:
|
||||
label: Relevant Logs
|
||||
description: |
|
||||
Paste any relevant log output. You can run nanobot with `--log-level DEBUG` for more verbose logs.
|
||||
**Remember to redact any sensitive information (tokens, API keys, passwords, etc.)**
|
||||
render: shell
|
||||
|
||||
- type: input
|
||||
id: version
|
||||
attributes:
|
||||
label: nanobot Version
|
||||
description: Run `nanobot --version` or `pip show nanobot-ai`
|
||||
placeholder: e.g., 0.2.0
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: dropdown
|
||||
id: python_version
|
||||
attributes:
|
||||
label: Python Version
|
||||
description: What Python version are you using?
|
||||
options:
|
||||
- "3.11"
|
||||
- "3.12"
|
||||
- "3.13"
|
||||
- Other (specify below)
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: dropdown
|
||||
id: os
|
||||
attributes:
|
||||
label: Operating System
|
||||
options:
|
||||
- Windows
|
||||
- macOS
|
||||
- Linux
|
||||
- Docker
|
||||
- Other (specify below)
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: dropdown
|
||||
id: channel
|
||||
attributes:
|
||||
label: Channel / Platform
|
||||
description: Which messaging platform are you using?
|
||||
options:
|
||||
- Weixin (Personal WeChat)
|
||||
- WeCom (Enterprise WeChat)
|
||||
- Feishu (Lark)
|
||||
- DingTalk
|
||||
- Telegram
|
||||
- Discord
|
||||
- Slack
|
||||
- QQ
|
||||
- WhatsApp
|
||||
- Email
|
||||
- MS Teams
|
||||
- Matrix
|
||||
- WebSocket
|
||||
- API Server
|
||||
- Other (specify below)
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: dropdown
|
||||
id: llm_provider
|
||||
attributes:
|
||||
label: LLM Provider
|
||||
description: Which LLM provider are you using?
|
||||
options:
|
||||
- OpenAI
|
||||
- Anthropic (Claude)
|
||||
- DeepSeek
|
||||
- Google (Gemini)
|
||||
- Ollama (Local)
|
||||
- OpenRouter
|
||||
- Azure OpenAI
|
||||
- Other (specify below)
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: config
|
||||
attributes:
|
||||
label: Configuration (Optional)
|
||||
description: |
|
||||
Relevant parts of your nanobot configuration. **Remember to redact any sensitive information.**
|
||||
render: yaml
|
||||
|
||||
- type: textarea
|
||||
id: additional
|
||||
attributes:
|
||||
label: Additional Context
|
||||
description: Any other context, screenshots, or information that might help.
|
||||
@@ -0,0 +1,5 @@
|
||||
blank_issues_enabled: false
|
||||
contact_links:
|
||||
- name: Question / Support
|
||||
url: https://github.com/HKUDS/nanobot/discussions
|
||||
about: Ask questions and get help from the community in Discussions.
|
||||
@@ -0,0 +1,55 @@
|
||||
name: Feature Request
|
||||
description: Suggest a new feature or enhancement
|
||||
labels: ["enhancement"]
|
||||
body:
|
||||
- type: markdown
|
||||
attributes:
|
||||
value: |
|
||||
Thanks for suggesting a feature! Please describe your idea clearly.
|
||||
|
||||
- type: textarea
|
||||
id: problem
|
||||
attributes:
|
||||
label: Problem / Motivation
|
||||
description: What problem does this feature solve? What are you trying to accomplish?
|
||||
placeholder: I'm always frustrated when ...
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: solution
|
||||
attributes:
|
||||
label: Proposed Solution
|
||||
description: How would you like this to work?
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: alternatives
|
||||
attributes:
|
||||
label: Alternatives Considered
|
||||
description: What other approaches have you considered?
|
||||
|
||||
- type: dropdown
|
||||
id: component
|
||||
attributes:
|
||||
label: Related Component
|
||||
description: Which part of nanobot does this relate to?
|
||||
options:
|
||||
- Channel (WeChat, Feishu, Telegram, etc.)
|
||||
- LLM Provider
|
||||
- Agent / Prompts
|
||||
- Skills / Plugins
|
||||
- Configuration
|
||||
- CLI
|
||||
- API Server
|
||||
- Documentation
|
||||
- Other
|
||||
validations:
|
||||
required: true
|
||||
|
||||
- type: textarea
|
||||
id: additional
|
||||
attributes:
|
||||
label: Additional Context
|
||||
description: Any other context, examples from other projects, screenshots, etc.
|
||||
@@ -0,0 +1,81 @@
|
||||
name: Test Suite
|
||||
|
||||
on:
|
||||
push:
|
||||
branches: [main]
|
||||
paths-ignore:
|
||||
- docs/**
|
||||
pull_request:
|
||||
branches: [main]
|
||||
paths-ignore:
|
||||
- docs/**
|
||||
|
||||
concurrency:
|
||||
group: ${{ github.workflow }}-${{ github.ref }}
|
||||
cancel-in-progress: true
|
||||
|
||||
permissions:
|
||||
contents: read
|
||||
|
||||
jobs:
|
||||
test:
|
||||
runs-on: ${{ matrix.os }}
|
||||
timeout-minutes: 20
|
||||
strategy:
|
||||
fail-fast: false
|
||||
matrix:
|
||||
os: ${{ fromJSON('["ubuntu-latest","windows-latest"]') }}
|
||||
# CI concentrates on newer runtimes (3.11/3.12 still supported per pyproject requires-python).
|
||||
python-version: ${{ fromJSON('["3.13","3.14"]') }}
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
- name: Set up Python ${{ matrix.python-version }}
|
||||
uses: actions/setup-python@v5
|
||||
with:
|
||||
python-version: ${{ matrix.python-version }}
|
||||
|
||||
- name: Install uv
|
||||
uses: astral-sh/setup-uv@v4
|
||||
|
||||
- name: Install system dependencies (Linux)
|
||||
if: runner.os == 'Linux'
|
||||
run: sudo apt-get update && sudo apt-get install -y libolm-dev build-essential
|
||||
|
||||
- name: Install dependencies
|
||||
run: uv sync --all-extras --dev
|
||||
|
||||
- name: Lint with ruff
|
||||
run: uv run ruff check nanobot --select F
|
||||
|
||||
- name: Run tests
|
||||
run: uv run python -m pytest tests/ --cov=nanobot --cov-report=term-missing:skip-covered
|
||||
|
||||
webui:
|
||||
runs-on: ubuntu-latest
|
||||
timeout-minutes: 15
|
||||
|
||||
steps:
|
||||
- uses: actions/checkout@v4
|
||||
|
||||
- name: Set up Bun
|
||||
uses: oven-sh/setup-bun@v2
|
||||
with:
|
||||
bun-version: 1.3.6
|
||||
|
||||
- name: Install WebUI dependencies
|
||||
working-directory: webui
|
||||
run: bun install
|
||||
|
||||
- name: Lint WebUI
|
||||
working-directory: webui
|
||||
run: bun run lint
|
||||
|
||||
- name: Test WebUI
|
||||
working-directory: webui
|
||||
run: bun run test
|
||||
|
||||
- name: Build WebUI
|
||||
working-directory: webui
|
||||
run: bun run build
|
||||
+102
@@ -0,0 +1,102 @@
|
||||
# Project-specific
|
||||
.worktrees/
|
||||
.worktree/
|
||||
.assets
|
||||
.docs
|
||||
.env
|
||||
.web
|
||||
.orion
|
||||
|
||||
# Claude / AI assistant artifacts
|
||||
docs/superpowers/
|
||||
docs/plans/
|
||||
|
||||
# webui (monorepo frontend)
|
||||
webui/node_modules/
|
||||
webui/dist/
|
||||
webui/coverage/
|
||||
webui/.vite/
|
||||
*.tsbuildinfo
|
||||
|
||||
# Python bytecode & caches
|
||||
*.pyc
|
||||
*.pyo
|
||||
*.pyd
|
||||
*.pyw
|
||||
*.pyz
|
||||
__pycache__/
|
||||
*.egg-info/
|
||||
*.egg
|
||||
.venv/
|
||||
venv/
|
||||
.pytest_cache/
|
||||
.mypy_cache/
|
||||
.ruff_cache/
|
||||
.pytype/
|
||||
.dmypy.json
|
||||
dmypy.json
|
||||
.tox/
|
||||
.nox/
|
||||
.hypothesis/
|
||||
|
||||
# Build & packaging
|
||||
dist/
|
||||
build/
|
||||
*.manifest
|
||||
*.spec
|
||||
pip-wheel-metadata/
|
||||
share/python-wheels/
|
||||
|
||||
# Test & coverage
|
||||
.coverage
|
||||
.coverage.*
|
||||
htmlcov/
|
||||
coverage.xml
|
||||
*.cover
|
||||
|
||||
# Lock files (project policy)
|
||||
poetry.lock
|
||||
uv.lock
|
||||
|
||||
# Jupyter
|
||||
.ipynb_checkpoints/
|
||||
|
||||
# macOS
|
||||
.DS_Store
|
||||
.AppleDouble
|
||||
.LSOverride
|
||||
|
||||
# Windows
|
||||
Thumbs.db
|
||||
ehthumbs.db
|
||||
Desktop.ini
|
||||
|
||||
# Linux
|
||||
.directory
|
||||
|
||||
# Editors & IDEs (local workspace / user settings)
|
||||
.vscode/
|
||||
.cursor/
|
||||
.idea/
|
||||
.fleet/
|
||||
*.code-workspace
|
||||
*.sublime-project
|
||||
*.sublime-workspace
|
||||
*.swp
|
||||
*.swo
|
||||
*~
|
||||
nano.*.save
|
||||
|
||||
# Environment & secrets (keep examples tracked if needed)
|
||||
.env.*
|
||||
!.env.example
|
||||
|
||||
# Logs & temp
|
||||
*.log
|
||||
logs/
|
||||
tmp/
|
||||
temp/
|
||||
*.tmp
|
||||
exp/
|
||||
.playwright-mcp/
|
||||
bridge/node_modules/
|
||||
@@ -0,0 +1,81 @@
|
||||
This file provides guidance to AI coding agents working with this repository.
|
||||
|
||||
## Project Overview
|
||||
|
||||
nanobot is a lightweight, open-source AI agent framework written in Python with a React/TypeScript WebUI. It centers around a small agent loop that receives messages from chat channels, invokes an LLM provider, executes tools, and manages session memory.
|
||||
|
||||
## Development Commands
|
||||
|
||||
```bash
|
||||
# Python: run single test / lint
|
||||
pytest tests/test_openai_api.py::test_function -v
|
||||
ruff check nanobot/
|
||||
|
||||
# WebUI: dev server (proxies API/WS to gateway :8765), build, test
|
||||
# Build outputs to ../nanobot/web/dist (bundled into the Python wheel)
|
||||
cd webui && bun run dev # or NANOBOT_API_URL=... bun run dev
|
||||
cd webui && bun run build
|
||||
cd webui && bun run test
|
||||
|
||||
# Gateway
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
## High-Level Architecture
|
||||
|
||||
### Core Data Flow
|
||||
|
||||
Messages flow through an async `MessageBus` (`nanobot/bus/queue.py`) that decouples chat channels from the agent core:
|
||||
|
||||
1. **Channels** (`nanobot/channels/`) receive messages from external platforms and publish `InboundMessage` events to the bus.
|
||||
2. **`AgentLoop`** (`nanobot/agent/loop.py`) consumes inbound messages, builds context, and coordinates the turn.
|
||||
3. **`AgentRunner`** (`nanobot/agent/runner.py`) handles the actual LLM conversation loop: send messages to the provider, receive tool calls, execute tools, and stream responses.
|
||||
4. Responses are published as `OutboundMessage` events back to the appropriate channel.
|
||||
|
||||
### Key Subsystems
|
||||
|
||||
- **Agent Loop** (`nanobot/agent/loop.py`, `runner.py`): The core processing engine. `AgentLoop` manages session keys, hooks, and context building. `AgentRunner` executes the multi-turn LLM conversation with tool execution.
|
||||
- **LLM Providers** (`nanobot/providers/`): Provider implementations (Anthropic, OpenAI-compatible, OpenAI Responses API, Azure, Bedrock, GitHub Copilot, OpenAI Codex, etc.) built on a common base (`base.py`). Includes image generation (`image_generation.py`) and audio transcription (`transcription.py`). `factory.py` and `registry.py` handle instantiation and model discovery.
|
||||
- **Channels** (`nanobot/channels/`): Platform integrations (Telegram, Discord, Slack, Feishu, Matrix, WhatsApp, QQ, WeChat, WeCom, DingTalk, Email, MoChat, MS Teams, WebSocket, Mattermost). `manager.py` discovers and coordinates them. Channels are auto-discovered via `pkgutil` scan + entry-point plugins.
|
||||
- **Tools** (`nanobot/agent/tools/`): Agent capabilities exposed to the LLM: filesystem (read/write/edit/list), shell execution (with sandbox backends), web search/fetch, MCP servers, cron, notebook editing, subagent spawning, long-running tasks / sustained goals (`long_task.py`), image generation, and self-modification. Tools are auto-discovered via `pkgutil` scan + entry-point plugins.
|
||||
- **Memory** (`nanobot/agent/memory.py`): Session history persistence with Dream two-phase memory consolidation. Uses atomic writes with fsync for durability.
|
||||
- **Session Management** (`nanobot/session/`): Per-session history, context compaction, TTL-based auto-compaction (`manager.py`), and sustained goal state tracking (`goal_state.py`).
|
||||
- **Config** (`nanobot/config/schema.py`, `loader.py`): Pydantic-based configuration loaded from `~/.nanobot/config.json`. Supports camelCase aliases for JSON compatibility.
|
||||
- **WebUI** (`webui/`): Vite-based React SPA that talks to the gateway over a WebSocket multiplex protocol. The dev server proxies `/api`, `/webui`, `/auth`, and WebSocket traffic to the gateway.
|
||||
- **API Server** (`nanobot/api/server.py`): OpenAI-compatible HTTP API (`/v1/chat/completions`, `/v1/models`) for programmatic access.
|
||||
- **Command Router** (`nanobot/command/`): Slash command routing and built-in command handlers.
|
||||
- **Heartbeat** (`nanobot/templates/HEARTBEAT.md`): Periodic task list checked via `cron` jobs (legacy dedicated service removed).
|
||||
- **Pairing** (`nanobot/pairing/`): DM sender approval store with persistent pairing codes per channel.
|
||||
- **Skills** (`nanobot/skills/`): Built-in skill definitions (cron, github, image-generation, etc.) loaded into agent context.
|
||||
- **Security** (`nanobot/security/`): PTH file guard and other security measures activated at CLI entry.
|
||||
|
||||
### Entry Points
|
||||
|
||||
- **CLI**: `nanobot/cli/commands.py`
|
||||
- **Python SDK**: `nanobot/nanobot.py`
|
||||
|
||||
## Project-Specific Notes
|
||||
|
||||
- Architecture constraints: [`.agent/design.md`](.agent/design.md)
|
||||
- Security boundaries: [`.agent/security.md`](.agent/security.md)
|
||||
- Common gotchas: [`.agent/gotchas.md`](.agent/gotchas.md)
|
||||
|
||||
## Contribution Flow
|
||||
|
||||
See [`CONTRIBUTING.md`](./CONTRIBUTING.md) for contribution flow and PR guidelines.
|
||||
|
||||
## Code Style
|
||||
|
||||
- Python 3.11+, asyncio throughout.
|
||||
- Line length: 100.
|
||||
- Linting: `ruff` with rules E, F, I, N, W (E501 ignored).
|
||||
- pytest with `asyncio_mode = "auto"`.
|
||||
|
||||
## Common File Locations
|
||||
|
||||
- Config schema: `nanobot/config/schema.py`
|
||||
- Provider base / new provider template: `nanobot/providers/base.py`
|
||||
- Channel base / new channel template: `nanobot/channels/base.py`
|
||||
- Tool registry: `nanobot/agent/tools/registry.py`
|
||||
- WebUI dev proxy config: `webui/vite.config.ts`
|
||||
- Tests mirror the `nanobot/` package structure.
|
||||
@@ -0,0 +1,5 @@
|
||||
We provide QR codes for joining the HKUDS discussion groups on **WeChat** and **Feishu**.
|
||||
|
||||
You can join by scanning the QR codes below:
|
||||
|
||||
<img src="https://github.com/HKUDS/.github/blob/main/profile/QR.png" alt="WeChat QR Code" width="400"/>
|
||||
+135
@@ -0,0 +1,135 @@
|
||||
# Contributing to nanobot
|
||||
|
||||
Thank you for being here.
|
||||
|
||||
nanobot is built with a simple belief: good tools should feel calm, clear, and humane.
|
||||
We care deeply about useful features, but we also believe in achieving more with less:
|
||||
solutions should be powerful without becoming heavy, and ambitious without becoming
|
||||
needlessly complicated.
|
||||
|
||||
This guide is not only about how to open a PR. It is also about how we hope to build
|
||||
software together: with care, clarity, and respect for the next person reading the code.
|
||||
|
||||
## Maintainers
|
||||
|
||||
Maintainers are community stewards who help review, organize, and maintain the project. The list below describes each maintainer's current open-source project responsibilities.
|
||||
|
||||
| Maintainer | Role |
|
||||
|------------|------|
|
||||
| [@re-bin](https://github.com/re-bin) | Project lead; reviews community PRs and handles merges |
|
||||
| [@chengyongru](https://github.com/chengyongru) | Reviews community PRs and may approve them; merges are handled by the project lead |
|
||||
|
||||
## Contribution Flow
|
||||
|
||||
### What Should I Open a PR For?
|
||||
|
||||
PRs are welcome for:
|
||||
|
||||
- New features or functionality
|
||||
- Bug fixes with no behavior changes
|
||||
- Documentation improvements
|
||||
- Minor tweaks that don't affect functionality
|
||||
- Refactoring that is clearly scoped and easy to review
|
||||
- Changes to APIs or configuration, when the impact is documented
|
||||
|
||||
For riskier or larger changes, please open an issue or draft PR early so the
|
||||
shape of the work can be discussed before the implementation grows too large.
|
||||
|
||||
### Starting Work
|
||||
|
||||
Before making changes, sync your local checkout and create a topic branch.
|
||||
|
||||
```bash
|
||||
git fetch upstream
|
||||
git switch main
|
||||
git pull --ff-only upstream main
|
||||
git switch -c your-topic-branch
|
||||
```
|
||||
|
||||
Use your primary HKUDS/nanobot remote in place of `upstream` if your checkout
|
||||
uses a different remote name.
|
||||
|
||||
Keep unrelated local changes out of the topic branch. If your checkout already has
|
||||
work in progress, use a separate worktree or finish that work before starting a
|
||||
new branch.
|
||||
|
||||
## Development Setup
|
||||
|
||||
Keep setup boring and reliable. The goal is to get you into the code quickly:
|
||||
|
||||
```bash
|
||||
# Clone the repository
|
||||
git clone https://github.com/HKUDS/nanobot.git
|
||||
cd nanobot
|
||||
|
||||
# Install with dev dependencies
|
||||
pip install -e ".[dev]"
|
||||
|
||||
# Run tests
|
||||
pytest
|
||||
|
||||
# Lint code
|
||||
ruff check nanobot/
|
||||
|
||||
# Format code — optional. The existing tree predates `ruff format`,
|
||||
# so running it broadly produces large unrelated diffs.
|
||||
# Do not mix mechanical formatting churn into a functional PR.
|
||||
# Use formatting only for the exact code your change intentionally touches.
|
||||
ruff format <files-you-changed>
|
||||
```
|
||||
|
||||
## Contribution License
|
||||
|
||||
By submitting a contribution, you confirm that you have the right to submit it
|
||||
and agree that it will be licensed under the project's MIT License.
|
||||
|
||||
## Code Style
|
||||
|
||||
We care about more than passing lint. We want nanobot to stay small, calm, and readable.
|
||||
|
||||
When contributing, please aim for code that feels:
|
||||
|
||||
- Simple: prefer the smallest change that solves the real problem
|
||||
- Clear: optimize for the next reader, not for cleverness
|
||||
- Decoupled: keep boundaries clean and avoid unnecessary new abstractions
|
||||
- Honest: do not hide complexity, but do not create extra complexity either
|
||||
- Durable: choose solutions that are easy to maintain, test, and extend
|
||||
|
||||
In practice:
|
||||
|
||||
- Line length: 100 characters (`ruff`)
|
||||
- Target: Python 3.11+
|
||||
- Linting: `ruff` with rules E, F, I, N, W (E501 ignored)
|
||||
- Async: uses `asyncio` throughout; pytest with `asyncio_mode = "auto"`
|
||||
- Prefer readable code over magical code
|
||||
- Prefer focused patches over broad rewrites
|
||||
- Do not mix mechanical formatting, line wrapping, import sorting, or quote churn
|
||||
into a feature or bugfix PR. If formatting cleanup is needed, make it a
|
||||
separate formatting-only PR.
|
||||
- If a new abstraction is introduced, it should clearly reduce complexity rather than move it around
|
||||
|
||||
## Modifying CI Workflows
|
||||
|
||||
If your PR touches `.github/workflows/`, please keep the CI within
|
||||
GitHub Actions' free tier:
|
||||
|
||||
- Use only standard GitHub-hosted runners (`ubuntu-latest`, `windows-latest`)
|
||||
- Avoid macOS runners, larger runners (`*-cores`, `*-xlarge`, `*-gpu`),
|
||||
and self-hosted runners
|
||||
- Avoid uploading large artifacts or using long retention
|
||||
- Avoid paid Marketplace actions
|
||||
|
||||
If your change genuinely needs to step outside this, please call it out
|
||||
explicitly in the PR description so it can be discussed before merge.
|
||||
|
||||
## Questions?
|
||||
|
||||
If you have questions, ideas, or half-formed insights, you are warmly welcome here.
|
||||
|
||||
Please feel free to open an [issue](https://github.com/HKUDS/nanobot/issues), join the community, or simply reach out:
|
||||
|
||||
- [Discord](https://discord.gg/MnCvHqpUGB)
|
||||
- [Feishu/WeChat](./COMMUNICATION.md)
|
||||
- Email: Xubin Ren (@Re-bin) — <xubinrencs@gmail.com>
|
||||
|
||||
Thank you for spending your time and care on nanobot. We would love for more people to participate in this community, and we genuinely welcome contributions of all sizes.
|
||||
+46
@@ -0,0 +1,46 @@
|
||||
FROM node:24-bookworm-slim AS webui-builder
|
||||
|
||||
WORKDIR /app
|
||||
COPY webui/package.json webui/package-lock.json ./webui/
|
||||
WORKDIR /app/webui
|
||||
RUN npm ci
|
||||
COPY webui/ ./
|
||||
RUN mkdir -p /app/nanobot/web && npm run build
|
||||
|
||||
FROM ghcr.io/astral-sh/uv:python3.12-bookworm-slim
|
||||
|
||||
RUN apt-get update && \
|
||||
apt-get install -y --no-install-recommends ca-certificates git bubblewrap openssh-client libmagic1 && \
|
||||
rm -rf /var/lib/apt/lists/*
|
||||
|
||||
WORKDIR /app
|
||||
|
||||
# Install Python dependencies first (cached layer). Hatch reads the custom build
|
||||
# hook from hatch_build.py even for this metadata-only install.
|
||||
ARG NANOBOT_EXTRAS=whatsapp
|
||||
COPY pyproject.toml README.md LICENSE THIRD_PARTY_NOTICES.md hatch_build.py ./
|
||||
RUN mkdir -p nanobot && touch nanobot/__init__.py && \
|
||||
NANOBOT_SKIP_WEBUI_BUILD=1 uv pip install --system --no-cache ".[$NANOBOT_EXTRAS]" && \
|
||||
rm -rf nanobot
|
||||
|
||||
# Copy the full source and install
|
||||
COPY nanobot/ nanobot/
|
||||
COPY --from=webui-builder /app/nanobot/web/dist/ nanobot/web/dist/
|
||||
RUN NANOBOT_SKIP_WEBUI_BUILD=1 uv pip install --system --no-cache ".[$NANOBOT_EXTRAS]"
|
||||
|
||||
# Create non-root user and config directory
|
||||
RUN useradd -m -u 1000 -s /bin/bash nanobot && \
|
||||
mkdir -p /home/nanobot/.nanobot && \
|
||||
chown -R nanobot:nanobot /home/nanobot /app
|
||||
|
||||
COPY entrypoint.sh /usr/local/bin/entrypoint.sh
|
||||
RUN sed -i 's/\r$//' /usr/local/bin/entrypoint.sh && chmod +x /usr/local/bin/entrypoint.sh
|
||||
|
||||
USER nanobot
|
||||
ENV HOME=/home/nanobot
|
||||
|
||||
# Gateway health endpoint and optional WebUI/WebSocket channel ports
|
||||
EXPOSE 18790 8765
|
||||
|
||||
ENTRYPOINT ["entrypoint.sh"]
|
||||
CMD ["status"]
|
||||
@@ -0,0 +1,21 @@
|
||||
MIT License
|
||||
|
||||
Copyright (c) 2025-present Xubin Ren and the nanobot contributors
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
in the Software without restriction, including without limitation the rights
|
||||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||
copies of the Software, and to permit persons to whom the Software is
|
||||
furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
SOFTWARE.
|
||||
@@ -0,0 +1,393 @@
|
||||
<picture>
|
||||
<source media="(prefers-color-scheme: dark)" srcset="./images/readme-cover-dark.png">
|
||||
<img alt="nanobot README cover" src="./images/readme-cover-light.png">
|
||||
</picture>
|
||||
|
||||
<div align="center">
|
||||
<p>
|
||||
<a href="https://nanobot.wiki/docs/latest/getting-started/nanobot-overview">English</a> |
|
||||
<a href="https://nanobot.wiki/cn/docs/latest/getting-started/nanobot-overview">简体中文</a> |
|
||||
<a href="https://nanobot.wiki/zh-Hant/docs/latest/getting-started/nanobot-overview">繁體中文</a> |
|
||||
<a href="https://nanobot.wiki/es/docs/latest/getting-started/nanobot-overview">Español</a> |
|
||||
<a href="https://nanobot.wiki/fr/docs/latest/getting-started/nanobot-overview">Français</a> |
|
||||
<a href="https://nanobot.wiki/id/docs/latest/getting-started/nanobot-overview">Bahasa Indonesia</a> |
|
||||
<a href="https://nanobot.wiki/ja/docs/latest/getting-started/nanobot-overview">日本語</a> |
|
||||
<a href="https://nanobot.wiki/ko/docs/latest/getting-started/nanobot-overview">한국어</a> |
|
||||
<a href="https://nanobot.wiki/ru/docs/latest/getting-started/nanobot-overview">Русский</a> |
|
||||
<a href="https://nanobot.wiki/vi/docs/latest/getting-started/nanobot-overview">Tiếng Việt</a>
|
||||
</p>
|
||||
<p>
|
||||
<a href="https://pypi.org/project/nanobot-ai/"><img src="https://img.shields.io/pypi/v/nanobot-ai" alt="PyPI"></a>
|
||||
<a href="https://pepy.tech/project/nanobot-ai"><img src="https://static.pepy.tech/badge/nanobot-ai" alt="Downloads"></a>
|
||||
<img src="https://img.shields.io/badge/python-≥3.11-blue" alt="Python">
|
||||
<img src="https://img.shields.io/badge/license-MIT-green" alt="License">
|
||||
<a href="https://github.com/HKUDS/nanobot/graphs/commit-activity" target="_blank">
|
||||
<img alt="Commits last month" src="https://img.shields.io/github/commit-activity/m/HKUDS/nanobot?labelColor=%20%2332b583&color=%20%2312b76a"></a>
|
||||
<a href="https://github.com/HKUDS/nanobot/issues?q=is%3Aissue%20is%3Aclosed" target="_blank">
|
||||
<img alt="Issues closed" src="https://img.shields.io/github/issues-search?query=repo%3AHKUDS%2Fnanobot%20is%3Aissue%20is%3Aclosed&label=issues%20closed&labelColor=%20%237d89b0&color=%20%235d6b98"></a>
|
||||
<a href="https://twitter.com/intent/follow?screen_name=nanobot_project" target="_blank">
|
||||
<img src="https://img.shields.io/twitter/follow/nanobot_project?logo=X&color=%20%23f5f5f5" alt="follow on X(Twitter)"></a>
|
||||
<a href="https://nanobot.wiki/docs/latest/getting-started/nanobot-overview"><img src="https://img.shields.io/badge/Docs-nanobot.wiki-blue?style=flat&logo=readthedocs&logoColor=white" alt="Docs"></a>
|
||||
<a href="./COMMUNICATION.md"><img src="https://img.shields.io/badge/Feishu-Group-E9DBFC?style=flat&logo=feishu&logoColor=white" alt="Feishu"></a>
|
||||
<a href="./COMMUNICATION.md"><img src="https://img.shields.io/badge/WeChat-Group-C5EAB4?style=flat&logo=wechat&logoColor=white" alt="WeChat"></a>
|
||||
<a href="https://discord.gg/MnCvHqpUGB"><img src="https://img.shields.io/badge/Discord-Community-5865F2?style=flat&logo=discord&logoColor=white" alt="Discord"></a>
|
||||
</p>
|
||||
</div>
|
||||
|
||||
🐈 **nanobot** is an open-source, ultra-lightweight personal AI agent you can truly own. It keeps the agent core small and readable while giving you the practical pieces for real long-running work: WebUI, chat channels, tools, memory, MCP, model routing, automation, and deployment.
|
||||
|
||||
## Start Here
|
||||
|
||||
| You want to... | Go to |
|
||||
|---|---|
|
||||
| Install nanobot with no terminal/config background | [Start Without Technical Background](./docs/start-without-technical-background.md) |
|
||||
| Install quickly and get one CLI reply | [Install](#-install) and [Quick Start](#-quick-start) |
|
||||
| Open the bundled browser UI | [WebUI](#-webui) |
|
||||
| Connect Telegram, Discord, WeChat, Slack, Email, Mattermost, or another chat app | [Chat Apps](./docs/chat-apps.md) |
|
||||
| Configure providers, fallback models, Langfuse, MCP, web tools, or security | [Docs](./docs/README.md) and [Configuration](./docs/configuration.md) |
|
||||
| Understand or extend the internals | [Architecture](./docs/architecture.md) and [Development](./docs/development.md) |
|
||||
|
||||
## What can nanobot do?
|
||||
|
||||
nanobot is a self-hosted personal AI agent runtime. It can:
|
||||
|
||||
- run in a browser WebUI or terminal
|
||||
- connect to Telegram, Discord, Slack, WeChat, Email, Mattermost, and other chat apps
|
||||
- use tools such as files, shell, web search, web fetch, MCP, cron, image generation, and subagents
|
||||
- keep session history and long-term memory through Dream
|
||||
- run long-horizon goals and scheduled automations
|
||||
- expose a Python SDK and OpenAI-compatible API for integrations
|
||||
- deploy as a long-running local or server-side agent gateway
|
||||
|
||||
## Latest Release
|
||||
|
||||
**v0.2.2 - Durability Release**
|
||||
|
||||
Highlights:
|
||||
|
||||
- Segmented WebUI transcripts
|
||||
- Python SDK runtime controls
|
||||
- Automation management
|
||||
- Search/STT provider improvements
|
||||
- Gateway/session/provider reliability
|
||||
|
||||
[See full changelog](https://github.com/HKUDS/nanobot/releases/tag/v0.2.2)
|
||||
|
||||
## Open Source Partners
|
||||
|
||||
<p align="center">
|
||||
<a href="https://platform.kimi.com?aff=nanobot"><picture><source media="(prefers-color-scheme: dark)" srcset="https://kimi-file.moonshot.cn/prod-chat-kimi/kfs/4/1/2026-06-05/1d8h69mt3v89kkekg24gg"><img alt="Kimi Open Source Friends" height="44" src="https://kimi-file.moonshot.cn/prod-chat-kimi/kfs/4/1/2026-06-05/1d8h69fudcmosb3pipls0"></picture></a>
|
||||
<a href="https://platform.minimaxi.com/subscribe/token-plan?code=GILTJpMTqZ&source=link"><img alt="MiniMax" height="40" src="https://mintcdn.com/minimax-zh/1UjvBcdoC6r0UeyA/logo/light.svg?fit=max&auto=format&n=1UjvBcdoC6r0UeyA&q=85&s=672d724b639b2d88d0702fae329ea4f8"></a>
|
||||
</p>
|
||||
|
||||
## Recent Updates
|
||||
|
||||
- **2026-06-21** Python SDK runtime controls, optional Keenable key, cleaner run hooks.
|
||||
- **2026-06-20** Telegram rich messages, safer SDK concurrency, smoother Quick Start.
|
||||
- **2026-06-19** Firecrawl app, OpenAI image edits, safer session deletion.
|
||||
- **2026-06-18** Feishu recovery, Keenable search, Mistral polish, workspace-aware git.
|
||||
- **2026-06-17** Default idle auto-compact, clearer `/dream`, macOS installer fixes.
|
||||
|
||||
For older updates, see the [release archive](./docs/release-archive.md) or [GitHub releases](https://github.com/HKUDS/nanobot/releases).
|
||||
|
||||
## 💡 Why nanobot
|
||||
|
||||
- **Persistent workflows**: goals, memory, tools, and chat context survive long-running work.
|
||||
- **Chat-native reach**: WebUI, API, Telegram, Feishu, Slack, Discord, Teams, email, and Mattermost.
|
||||
- **Model freedom**: OpenAI-compatible APIs, local LLMs, image generation, search, and fallbacks.
|
||||
- **Small core**: readable internals with MCP, memory, deployment, and automation built in.
|
||||
- **Own your stack**: inspect, customize, self-host, and extend without a giant platform.
|
||||
|
||||
## 📦 Install
|
||||
|
||||
> [!IMPORTANT]
|
||||
> If you want the newest features and experiments, install from source.
|
||||
>
|
||||
> If you want the most stable day-to-day experience, install from PyPI or with `uv`.
|
||||
|
||||
Pick **one** install method:
|
||||
|
||||
Prerequisites: Python 3.11 or newer. Git is only needed for a source install; Node.js/Bun are only needed if you are developing the WebUI itself.
|
||||
|
||||
If terminals, API keys, or config files are new to you, use the guided zero-background walkthrough in [Start Without Technical Background](./docs/start-without-technical-background.md) instead of this compact README path.
|
||||
|
||||
**One-command setup**
|
||||
|
||||
macOS / Linux:
|
||||
|
||||
```bash
|
||||
curl -fsSL https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.sh | sh
|
||||
```
|
||||
|
||||
Windows PowerShell:
|
||||
|
||||
```powershell
|
||||
irm https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.ps1 | iex
|
||||
```
|
||||
|
||||
The default command installs or upgrades `nanobot-ai` from PyPI, then starts `nanobot onboard --wizard`. It avoids system-wide pip installs by using an active virtual environment, `uv`, `pipx`, or a managed venv under `~/.nanobot/venv`. If Quick Start finishes, skip the manual initialize/configure steps below and go straight to **Open the WebUI**.
|
||||
|
||||
To preview the plan without changing your environment, pass `--dry-run`; combine it with `--dev` when you want to preview the main-branch install.
|
||||
|
||||
```bash
|
||||
curl -fsSL https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.sh | sh -s -- --dry-run
|
||||
```
|
||||
|
||||
```powershell
|
||||
& ([scriptblock]::Create((irm https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.ps1))) --dry-run
|
||||
```
|
||||
|
||||
To install the current `main` branch instead, pass `--dev`:
|
||||
|
||||
```bash
|
||||
curl -fsSL https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.sh | sh -s -- --dev
|
||||
```
|
||||
|
||||
```powershell
|
||||
& ([scriptblock]::Create((irm https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.ps1))) --dev
|
||||
```
|
||||
|
||||
If you prefer to inspect the script first, open [`scripts/install.sh`](./scripts/install.sh) or [`scripts/install.ps1`](./scripts/install.ps1).
|
||||
|
||||
**Install with `uv`**
|
||||
|
||||
```bash
|
||||
uv tool install nanobot-ai
|
||||
```
|
||||
|
||||
**Install from PyPI with pip**
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
```
|
||||
|
||||
If pip reports `externally-managed-environment` on macOS or Linux, use the one-command installer, `uv tool install nanobot-ai`, `pipx install nanobot-ai`, or install inside a virtual environment.
|
||||
|
||||
**Install from source**
|
||||
|
||||
```bash
|
||||
git clone https://github.com/HKUDS/nanobot.git
|
||||
cd nanobot
|
||||
python -m pip install -e .
|
||||
```
|
||||
|
||||
Verify the install:
|
||||
|
||||
```bash
|
||||
nanobot --version
|
||||
```
|
||||
|
||||
## 🚀 Quick Start
|
||||
|
||||
**1. Initialize**
|
||||
|
||||
Skip this step if the one-command setup already started the wizard and Quick Start finished there.
|
||||
|
||||
```bash
|
||||
nanobot onboard
|
||||
```
|
||||
|
||||
Use `nanobot onboard --wizard` if you prefer an interactive setup.
|
||||
|
||||
**2. Configure** (`~/.nanobot/config.json`)
|
||||
|
||||
Skip this step if you already configured provider and model settings in the wizard.
|
||||
|
||||
`nanobot onboard` creates `~/.nanobot/config.json` and `~/.nanobot/workspace/`. Configure these **two parts** in the config file. Add or merge the following blocks into the existing file instead of replacing the whole file.
|
||||
|
||||
The example below uses a generic OpenAI-compatible `custom` provider so the compact path does not recommend one hosted service. Provider examples are recipes, not rankings or endorsements. For copyable provider-specific setup, see [Provider Cookbook](./docs/provider-cookbook.md).
|
||||
|
||||
*Set your API key*:
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"custom": {
|
||||
"apiKey": "your-api-key",
|
||||
"apiBase": "https://api.example.com/v1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
*Set a model preset and make it active*:
|
||||
|
||||
```json
|
||||
{
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"label": "Primary",
|
||||
"provider": "custom",
|
||||
"model": "model-id-from-your-provider",
|
||||
"maxTokens": 8192,
|
||||
"contextWindowTokens": 200000,
|
||||
"temperature": 0.1
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Direct `agents.defaults.provider` and `agents.defaults.model` still work for existing configs, but named presets are the recommended path because they also power `/model` switching and `fallbackModels`.
|
||||
|
||||
For another provider, the same config shape still applies:
|
||||
|
||||
| Replace | Where |
|
||||
|---|---|
|
||||
| Provider config key | `providers.<provider>` |
|
||||
| API key | `providers.<provider>.apiKey` |
|
||||
| Preset provider name | `modelPresets.primary.provider` |
|
||||
| Model ID | `modelPresets.primary.model` |
|
||||
| Endpoint URL, only when needed | `providers.<provider>.apiBase` |
|
||||
|
||||
**3. Open the WebUI**
|
||||
|
||||
Start the browser workbench:
|
||||
|
||||
```bash
|
||||
nanobot webui
|
||||
```
|
||||
|
||||
`nanobot webui` prepares the local WebSocket channel if needed, starts the gateway, and opens `http://127.0.0.1:8765`. It binds the first-run WebUI to `127.0.0.1` by default, so it is not exposed to your LAN. Prefer not to keep a terminal open? Use `nanobot webui --background`, then manage the gateway with `nanobot gateway status`, `logs`, `restart`, and `stop`.
|
||||
|
||||
For manual or terminal-only setup, test one CLI message:
|
||||
|
||||
```bash
|
||||
nanobot status
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
In `nanobot status`, it is normal for most providers to say `not set`. The active preset's provider should be configured, and `Config` plus `Workspace` should show check marks.
|
||||
|
||||
If that works, start an interactive chat:
|
||||
|
||||
```bash
|
||||
nanobot agent
|
||||
```
|
||||
|
||||
Need help with `PATH`, API keys, provider/model matching, or JSON errors? See the fuller [Install and Quick Start](./docs/quick-start.md) and [Troubleshooting](./docs/troubleshooting.md).
|
||||
|
||||
- Want a pasteable provider setup? See [Provider Cookbook](./docs/provider-cookbook.md)
|
||||
- Want to understand provider/model matching? See [Providers and Models](./docs/providers.md)
|
||||
- Want web search, MCP, security settings, or more config options? See [Configuration](./docs/configuration.md)
|
||||
- Want to run locally? See [Ollama](./docs/providers.md#ollama), [vLLM or another local OpenAI-compatible server](./docs/providers.md#vllm-or-other-local-openai-compatible-server), and the full [provider reference](./docs/configuration.md#providers).
|
||||
- Want to run nanobot in chat apps like Telegram, Discord, WeChat or Feishu? See [Chat Apps](./docs/chat-apps.md)
|
||||
- Want Docker or Linux service deployment? See [Deployment](./docs/deployment.md)
|
||||
|
||||
## 🌐 WebUI
|
||||
|
||||
The WebUI ships **inside the published wheel** — no extra build step. It is the browser workbench for chat sessions, workspace controls, Apps, Skills, Automations, and settings. For the full user guide, see [`docs/webui.md`](./docs/webui.md).
|
||||
|
||||
<p align="center">
|
||||
<img src="images/nanobot_webui.png" alt="nanobot webui preview" width="900">
|
||||
</p>
|
||||
|
||||
**Open it**
|
||||
|
||||
```bash
|
||||
nanobot webui
|
||||
```
|
||||
|
||||
The command enables the local WebSocket channel after confirmation, starts the gateway, and opens [`http://127.0.0.1:8765`](http://127.0.0.1:8765). To open it from another device on your LAN, see [WebUI docs -> LAN access](./docs/webui.md#lan-access).
|
||||
|
||||
The WebUI is served by the WebSocket channel on port `8765` by default. The gateway's `18790` port is for the health endpoint, not the browser UI.
|
||||
|
||||
> [!TIP]
|
||||
> Working on the WebUI itself? Check out [`webui/README.md`](./webui/README.md) for the source-tree, Vite dev server, build, and test workflow.
|
||||
|
||||
## 🏗️ Architecture
|
||||
|
||||
<p align="center">
|
||||
<img src="images/nanobot_arch.png" alt="nanobot architecture" width="800">
|
||||
</p>
|
||||
|
||||
🐈 nanobot stays lightweight by centering everything around a small agent loop: messages come in from chat apps, the LLM decides when tools are needed, and memory or skills are pulled in only as context instead of becoming a heavy orchestration layer. That keeps the core path readable and easy to extend, while still letting you add channels, tools, memory, and deployment options without turning the system into a monolith.
|
||||
|
||||
## ✨ Features
|
||||
|
||||
<table align="center">
|
||||
<tr align="center">
|
||||
<th><p align="center">📈 24/7 Real-Time Market Analysis</p></th>
|
||||
<th><p align="center">🚀 Full-Stack Software Engineer</p></th>
|
||||
<th><p align="center">📅 Smart Daily Routine Manager</p></th>
|
||||
<th><p align="center">📚 Personal Knowledge Assistant</p></th>
|
||||
</tr>
|
||||
<tr>
|
||||
<td align="center"><p align="center"><img src="case/search.gif" width="180" height="400"></p></td>
|
||||
<td align="center"><p align="center"><img src="case/code.gif" width="180" height="400"></p></td>
|
||||
<td align="center"><p align="center"><img src="case/schedule.gif" width="180" height="400"></p></td>
|
||||
<td align="center"><p align="center"><img src="case/memory.gif" width="180" height="400"></p></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td align="center">Discovery • Insights • Trends</td>
|
||||
<td align="center">Develop • Deploy • Scale</td>
|
||||
<td align="center">Schedule • Automate • Organize</td>
|
||||
<td align="center">Learn • Memory • Reasoning</td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
## 📚 Docs
|
||||
|
||||
Browse the [repo docs](./docs/README.md) for the latest features and GitHub development version, or visit [nanobot.wiki](https://nanobot.wiki/docs/latest/getting-started/nanobot-overview) for the stable release documentation.
|
||||
|
||||
- Use task-oriented guides: [Guides](./docs/guides/README.md)
|
||||
- Start with no technical background: [Start Without Technical Background](./docs/start-without-technical-background.md)
|
||||
- Start from zero with developer basics: [Install and Quick Start](./docs/quick-start.md)
|
||||
- Understand the runtime model: [Concepts](./docs/concepts.md)
|
||||
- Read the source-level map: [Architecture](./docs/architecture.md)
|
||||
- Choose a provider/model: [Providers and Models](./docs/providers.md)
|
||||
- Copy provider setup recipes: [Provider Cookbook](./docs/provider-cookbook.md)
|
||||
- Debug setup and runtime failures: [Troubleshooting](./docs/troubleshooting.md)
|
||||
- Talk to your nanobot with familiar chat apps: [Chat App AI Agent](./docs/guides/chat-app-ai-agent.md) · [Chat Apps](./docs/chat-apps.md)
|
||||
- Schedule or trigger agent work: [Automations](./docs/automations.md)
|
||||
- Configure providers, web search, MCP, and runtime behavior: [Configuration](./docs/configuration.md)
|
||||
- Integrate nanobot with local tools and automations: [OpenAI-Compatible API](./docs/openai-api.md) · [Python SDK](./docs/python-sdk.md)
|
||||
- Run nanobot with Docker or as a Linux service: [Deployment](./docs/deployment.md)
|
||||
|
||||
## 🤝 Contribute & Roadmap
|
||||
|
||||
PRs welcome! The codebase is intentionally small and readable. 🤗
|
||||
|
||||
### Contribution Flow
|
||||
|
||||
See [CONTRIBUTING.md](./CONTRIBUTING.md) for setup, review, and contribution guidelines.
|
||||
|
||||
**Roadmap** — Pick an item and [open a PR](https://github.com/HKUDS/nanobot/pulls)!
|
||||
|
||||
- **Multi-modal** — See and hear (images, voice, video)
|
||||
- **Long-term memory** — Never forget important context
|
||||
- **Better reasoning** — Multi-step planning and reflection
|
||||
- **More integrations** — Calendar and more
|
||||
- **Self-improvement** — Learn from feedback and mistakes
|
||||
|
||||
## Contact
|
||||
|
||||
This project was started by [Xubin Ren](https://github.com/re-bin) as a personal open-source project and continues to be maintained in an individual capacity using personal resources, with contributions from the open-source community. Feel free to contact [xubinrencs@gmail.com](mailto:xubinrencs@gmail.com) for questions, ideas, or collaboration.
|
||||
|
||||
### Contributors
|
||||
|
||||
<a href="https://github.com/HKUDS/nanobot/graphs/contributors">
|
||||
<img src="https://contrib.rocks/image?repo=HKUDS/nanobot&max=100&columns=12&updated=20260210" alt="Contributors" />
|
||||
</a>
|
||||
|
||||
|
||||
## ⭐ Star History
|
||||
|
||||
<div align="center">
|
||||
<a href="https://star-history.com/#HKUDS/nanobot&Date">
|
||||
<picture>
|
||||
<source media="(prefers-color-scheme: dark)" srcset="https://api.star-history.com/svg?repos=HKUDS/nanobot&type=Date&theme=dark" />
|
||||
<source media="(prefers-color-scheme: light)" srcset="https://api.star-history.com/svg?repos=HKUDS/nanobot&type=Date" />
|
||||
<img alt="Star History Chart" src="https://api.star-history.com/svg?repos=HKUDS/nanobot&type=Date" style="border-radius: 15px; box-shadow: 0 0 30px rgba(0, 217, 255, 0.3);" />
|
||||
</picture>
|
||||
</a>
|
||||
</div>
|
||||
|
||||
<p align="center">
|
||||
<em> Thanks for visiting ✨ nanobot!</em><br><br>
|
||||
<img src="https://visitor-badge.laobi.icu/badge?page_id=HKUDS.nanobot&style=for-the-badge&color=00d4ff" alt="Views">
|
||||
</p>
|
||||
@@ -0,0 +1,7 @@
|
||||
# WeHub 来源说明
|
||||
|
||||
- 原始项目：`HKUDS/nanobot`
|
||||
- 原始仓库：https://github.com/HKUDS/nanobot
|
||||
- 导入方式：上游默认分支的最新快照
|
||||
- 原作者、版权和许可证信息以原始仓库及本仓库 LICENSE 为准
|
||||
- 本文件仅用于记录来源，不代表 WeHub 是原项目作者
|
||||
+271
@@ -0,0 +1,271 @@
|
||||
# Security Policy
|
||||
|
||||
## Reporting a Vulnerability
|
||||
|
||||
If you discover a security vulnerability in nanobot, please report it by:
|
||||
|
||||
1. **DO NOT** open a public GitHub issue
|
||||
2. Create a private security advisory on GitHub or contact the repository maintainers (xubinrencs@gmail.com)
|
||||
3. Include:
|
||||
- Description of the vulnerability
|
||||
- Steps to reproduce
|
||||
- Potential impact
|
||||
- Suggested fix (if any)
|
||||
|
||||
We aim to respond to security reports within 48 hours.
|
||||
|
||||
## Security Best Practices
|
||||
|
||||
### 1. API Key Management
|
||||
|
||||
**CRITICAL**: Never commit API keys to version control.
|
||||
|
||||
```bash
|
||||
# ✅ Good: Store in config file with restricted permissions
|
||||
chmod 600 ~/.nanobot/config.json
|
||||
|
||||
# ❌ Bad: Hardcoding keys in code or committing them
|
||||
```
|
||||
|
||||
**Recommendations:**
|
||||
- Store API keys in `~/.nanobot/config.json` with file permissions set to `0600`
|
||||
- Consider using environment variables for sensitive keys
|
||||
- Use OS keyring/credential manager for production deployments
|
||||
- Rotate API keys regularly
|
||||
- Use separate API keys for development and production
|
||||
|
||||
### 2. Channel Access Control
|
||||
|
||||
**IMPORTANT**: Always configure `allowFrom` lists for production use.
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"telegram": {
|
||||
"enabled": true,
|
||||
"token": "YOUR_BOT_TOKEN",
|
||||
"allowFrom": ["123456789", "987654321"]
|
||||
},
|
||||
"whatsapp": {
|
||||
"enabled": true,
|
||||
"allowFrom": ["1234567890"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Security Notes:**
|
||||
- In `v0.1.4.post3` and earlier, an empty `allowFrom` allowed all users. Since `v0.1.4.post4`, empty `allowFrom` denies all access by default — set `["*"]` to explicitly allow everyone.
|
||||
- Get your Telegram user ID from `@userinfobot`
|
||||
- Use WhatsApp sender IDs as full phone numbers with country code and no leading `+`
|
||||
- Review access logs regularly for unauthorized access attempts
|
||||
|
||||
### 3. Shell Command Execution
|
||||
|
||||
The `exec` tool can execute shell commands. While dangerous command patterns are blocked, you should:
|
||||
|
||||
- ✅ **Enable the bwrap sandbox** (`"tools.exec.sandbox": "bwrap"`) for kernel-level isolation (Linux only)
|
||||
- ✅ Review all tool usage in agent logs
|
||||
- ✅ Understand what commands the agent is running
|
||||
- ✅ Use a dedicated user account with limited privileges
|
||||
- ✅ Never run nanobot as root
|
||||
- ❌ Don't disable security checks
|
||||
- ❌ Don't run on systems with sensitive data without careful review
|
||||
|
||||
**Exec sandbox (bwrap):**
|
||||
|
||||
On Linux, set `"tools.exec.sandbox": "bwrap"` to wrap every shell command in a [bubblewrap](https://github.com/containers/bubblewrap) sandbox. This uses Linux kernel namespaces to restrict what the process can see:
|
||||
|
||||
- Workspace directory → **read-write** (agent works normally)
|
||||
- Media directory → **read-only** (can read uploaded attachments)
|
||||
- System directories (`/usr`, `/bin`, `/lib`) → **read-only** (commands still work)
|
||||
- Config files and API keys (`~/.nanobot/config.json`) → **hidden** (masked by tmpfs)
|
||||
|
||||
Requires `bwrap` installed (`apt install bubblewrap`). Pre-installed in the official Docker image. **Not available on macOS or Windows** — bubblewrap depends on Linux kernel namespaces.
|
||||
|
||||
Enabling the sandbox also automatically activates `restrictToWorkspace` for file tools.
|
||||
|
||||
**Blocked patterns:**
|
||||
- `rm -rf /` - Root filesystem deletion
|
||||
- Fork bombs
|
||||
- Filesystem formatting (`mkfs.*`)
|
||||
- Raw disk writes
|
||||
- Other destructive operations
|
||||
|
||||
### 4. File System Access
|
||||
|
||||
File operations have path traversal protection, but:
|
||||
|
||||
- ✅ Enable `restrictToWorkspace` or the bwrap sandbox to confine file access
|
||||
- ✅ Run nanobot with a dedicated user account
|
||||
- ✅ Use filesystem permissions to protect sensitive directories
|
||||
- ✅ Regularly audit file operations in logs
|
||||
- ❌ Don't give unrestricted access to sensitive files
|
||||
|
||||
### 5. Network Security
|
||||
|
||||
**API Calls:**
|
||||
- All external API calls use HTTPS by default
|
||||
- Timeouts are configured to prevent hanging requests
|
||||
- The OpenAI-compatible API server must set `api.api_key` when binding to `0.0.0.0` or `::`; otherwise startup fails to prevent unauthenticated network access
|
||||
- Consider using a firewall to restrict outbound connections if needed
|
||||
|
||||
**WhatsApp:**
|
||||
- Keep the neonize session database under `~/.nanobot/whatsapp-auth` secure (mode 0700).
|
||||
- Use `nanobot channels login whatsapp --force` to remove and recreate the local session database when rotating linked devices.
|
||||
|
||||
### 6. Dependency Security
|
||||
|
||||
**Critical**: Keep dependencies updated!
|
||||
|
||||
```bash
|
||||
# Check for vulnerable dependencies
|
||||
pip install pip-audit
|
||||
pip-audit
|
||||
|
||||
# Update to latest secure versions
|
||||
pip install --upgrade nanobot-ai
|
||||
```
|
||||
|
||||
**Important Notes:**
|
||||
- Keep `litellm` updated to the latest version for security fixes
|
||||
- Run `pip-audit` regularly, including optional channel dependencies such as `nanobot-ai[whatsapp]`
|
||||
- Subscribe to security advisories for nanobot and its dependencies
|
||||
|
||||
### 7. Production Deployment
|
||||
|
||||
For production use:
|
||||
|
||||
1. **Isolate the Environment**
|
||||
```bash
|
||||
# Run in a container or VM
|
||||
docker run --rm -it python:3.11
|
||||
pip install nanobot-ai
|
||||
```
|
||||
|
||||
2. **Use a Dedicated User**
|
||||
```bash
|
||||
sudo useradd -m -s /bin/bash nanobot
|
||||
sudo -u nanobot nanobot gateway
|
||||
```
|
||||
|
||||
3. **Set Proper Permissions**
|
||||
```bash
|
||||
chmod 700 ~/.nanobot
|
||||
chmod 600 ~/.nanobot/config.json
|
||||
chmod 700 ~/.nanobot/whatsapp-auth
|
||||
```
|
||||
|
||||
4. **Enable Logging**
|
||||
```bash
|
||||
# Configure log monitoring
|
||||
tail -f ~/.nanobot/logs/nanobot.log
|
||||
```
|
||||
|
||||
5. **Use Rate Limiting**
|
||||
- Configure rate limits on your API providers
|
||||
- Monitor usage for anomalies
|
||||
- Set spending limits on LLM APIs
|
||||
|
||||
6. **Regular Updates**
|
||||
```bash
|
||||
# Check for updates weekly
|
||||
pip install --upgrade nanobot-ai
|
||||
```
|
||||
|
||||
### 8. Development vs Production
|
||||
|
||||
**Development:**
|
||||
- Use separate API keys
|
||||
- Test with non-sensitive data
|
||||
- Enable verbose logging
|
||||
- Use a test Telegram bot
|
||||
|
||||
**Production:**
|
||||
- Use dedicated API keys with spending limits
|
||||
- Restrict file system access
|
||||
- Enable audit logging
|
||||
- Regular security reviews
|
||||
- Monitor for unusual activity
|
||||
|
||||
### 9. Data Privacy
|
||||
|
||||
- **Logs may contain sensitive information** - secure log files appropriately
|
||||
- **LLM providers see your prompts** - review their privacy policies
|
||||
- **Chat history is stored locally** - protect the `~/.nanobot` directory
|
||||
- **API keys are in plain text** - use OS keyring for production
|
||||
|
||||
### 10. Incident Response
|
||||
|
||||
If you suspect a security breach:
|
||||
|
||||
1. **Immediately revoke compromised API keys**
|
||||
2. **Review logs for unauthorized access**
|
||||
```bash
|
||||
grep "Access denied" ~/.nanobot/logs/nanobot.log
|
||||
```
|
||||
3. **Check for unexpected file modifications**
|
||||
4. **Rotate all credentials**
|
||||
5. **Update to latest version**
|
||||
6. **Report the incident** to maintainers
|
||||
|
||||
## Security Features
|
||||
|
||||
### Built-in Security Controls
|
||||
|
||||
✅ **Input Validation**
|
||||
- Path traversal protection on file operations
|
||||
- Dangerous command pattern detection
|
||||
- Input length limits on HTTP requests
|
||||
|
||||
✅ **Authentication**
|
||||
- Allow-list based access control — in `v0.1.4.post3` and earlier empty `allowFrom` allowed all; since `v0.1.4.post4` it denies all (`["*"]` explicitly allows all)
|
||||
- Failed authentication attempt logging
|
||||
|
||||
✅ **Resource Protection**
|
||||
- Command execution timeouts (60s default)
|
||||
- Output truncation (10KB limit)
|
||||
- HTTP request timeouts (10-30s)
|
||||
|
||||
✅ **Secure Communication**
|
||||
- HTTPS for all external API calls
|
||||
- TLS for Telegram API
|
||||
- WhatsApp session secrets stay in the local session database
|
||||
|
||||
## Known Limitations
|
||||
|
||||
⚠️ **Current Security Limitations:**
|
||||
|
||||
1. **No Rate Limiting** - Users can send unlimited messages (add your own if needed)
|
||||
2. **Plain Text Config** - API keys stored in plain text (use keyring for production)
|
||||
3. **No Session Management** - No automatic session expiry
|
||||
4. **Limited Command Filtering** - Only blocks obvious dangerous patterns (enable the bwrap sandbox for kernel-level isolation on Linux)
|
||||
5. **No Audit Trail** - Limited security event logging (enhance as needed)
|
||||
|
||||
## Security Checklist
|
||||
|
||||
Before deploying nanobot:
|
||||
|
||||
- [ ] API keys stored securely (not in code)
|
||||
- [ ] Config file permissions set to 0600
|
||||
- [ ] `allowFrom` lists configured for all channels
|
||||
- [ ] Running as non-root user
|
||||
- [ ] Exec sandbox enabled (`"tools.exec.sandbox": "bwrap"`) on Linux deployments
|
||||
- [ ] File system permissions properly restricted
|
||||
- [ ] Dependencies updated to latest secure versions
|
||||
- [ ] Logs monitored for security events
|
||||
- [ ] Rate limits configured on API providers
|
||||
- [ ] Backup and disaster recovery plan in place
|
||||
- [ ] Security review of custom skills/tools
|
||||
|
||||
## Updates
|
||||
|
||||
**Last Updated**: 2026-04-05
|
||||
|
||||
For the latest security updates and announcements, check:
|
||||
- GitHub Security Advisories: https://github.com/HKUDS/nanobot/security/advisories
|
||||
- Release Notes: https://github.com/HKUDS/nanobot/releases
|
||||
|
||||
## License
|
||||
|
||||
See LICENSE file for details.
|
||||
@@ -0,0 +1,175 @@
|
||||
# Third-Party Notices
|
||||
|
||||
The following third-party components are redistributed as part of the packaged
|
||||
nanobot Python distribution (`pip install nanobot-ai`).
|
||||
|
||||
---
|
||||
|
||||
## Tabler Icons — interface icons (MIT)
|
||||
|
||||
- **Source**: https://github.com/tabler/tabler-icons
|
||||
- **Bundled**: `nanobot/web/dist/assets/index-*.js` (inline `arrow-fork` SVG)
|
||||
|
||||
```
|
||||
MIT License
|
||||
|
||||
Copyright (c) 2020-2026 Paweł Kuna
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
in the Software without restriction, including without limitation the rights
|
||||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||
copies of the Software, and to permit persons to whom the Software is
|
||||
furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
SOFTWARE.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## KaTeX — math rendering (MIT)
|
||||
|
||||
- **Source**: https://github.com/KaTeX/KaTeX
|
||||
- **Bundled**: `nanobot/web/dist/assets/index-*.{js,css}`
|
||||
|
||||
```
|
||||
The MIT License (MIT)
|
||||
|
||||
Copyright (c) 2013-2020 Khan Academy and other contributors
|
||||
|
||||
Permission is hereby granted, free of charge, to any person obtaining a copy
|
||||
of this software and associated documentation files (the "Software"), to deal
|
||||
in the Software without restriction, including without limitation the rights
|
||||
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
|
||||
copies of the Software, and to permit persons to whom the Software is
|
||||
furnished to do so, subject to the following conditions:
|
||||
|
||||
The above copyright notice and this permission notice shall be included in all
|
||||
copies or substantial portions of the Software.
|
||||
|
||||
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
||||
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
||||
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
|
||||
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
||||
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
|
||||
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
|
||||
SOFTWARE.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## KaTeX Fonts — math typography (SIL OFL 1.1)
|
||||
|
||||
- **Source**: https://github.com/KaTeX/KaTeX/tree/main/src/fonts
|
||||
- **Bundled**: `nanobot/web/dist/assets/KaTeX_*.{woff2,woff,ttf}`
|
||||
|
||||
The fonts are redistributed unmodified.
|
||||
|
||||
```
|
||||
Copyright (c) 2009-2010, Design Science, Inc. (<www.mathjax.org>)
|
||||
Copyright (c) 2014-2018 Khan Academy (<www.khanacademy.org>),
|
||||
with Reserved Font Names KaTeX_AMS, KaTeX_Caligraphic, KaTeX_Fraktur,
|
||||
KaTeX_Main, KaTeX_Math, KaTeX_SansSerif, KaTeX_Script, KaTeX_Size1,
|
||||
KaTeX_Size2, KaTeX_Size3, KaTeX_Size4, KaTeX_Typewriter.
|
||||
|
||||
This Font Software is licensed under the SIL Open Font License, Version 1.1.
|
||||
This license is copied below, and is also available with a FAQ at:
|
||||
http://scripts.sil.org/OFL
|
||||
|
||||
|
||||
-----------------------------------------------------------
|
||||
SIL OPEN FONT LICENSE Version 1.1 - 26 February 2007
|
||||
-----------------------------------------------------------
|
||||
|
||||
PREAMBLE
|
||||
The goals of the Open Font License (OFL) are to stimulate worldwide
|
||||
development of collaborative font projects, to support the font creation
|
||||
efforts of academic and linguistic communities, and to provide a free and
|
||||
open framework in which fonts may be shared and improved in partnership
|
||||
with others.
|
||||
|
||||
The OFL allows the licensed fonts to be used, studied, modified and
|
||||
redistributed freely as long as they are not sold by themselves. The
|
||||
fonts, including any derivative works, can be bundled, embedded,
|
||||
redistributed and/or sold with any software provided that any reserved
|
||||
names are not used by derivative works. The fonts and derivatives,
|
||||
however, cannot be released under any other type of license. The
|
||||
requirement for fonts to remain under this license does not apply
|
||||
to any document created using the fonts or their derivatives.
|
||||
|
||||
DEFINITIONS
|
||||
"Font Software" refers to the set of files released by the Copyright
|
||||
Holder(s) under this license and clearly marked as such. This may
|
||||
include source files, build scripts and documentation.
|
||||
|
||||
"Reserved Font Name" refers to any names specified as such after the
|
||||
copyright statement(s).
|
||||
|
||||
"Original Version" refers to the collection of Font Software components as
|
||||
distributed by the Copyright Holder(s).
|
||||
|
||||
"Modified Version" refers to any derivative made by adding to, deleting,
|
||||
or substituting -- in part or in whole -- any of the components of the
|
||||
Original Version, by changing formats or by porting the Font Software to a
|
||||
new environment.
|
||||
|
||||
"Author" refers to any designer, engineer, programmer, technical
|
||||
writer or other person who contributed to the Font Software.
|
||||
|
||||
PERMISSION & CONDITIONS
|
||||
Permission is hereby granted, free of charge, to any person obtaining
|
||||
a copy of the Font Software, to use, study, copy, merge, embed, modify,
|
||||
redistribute, and sell modified and unmodified copies of the Font
|
||||
Software, subject to the following conditions:
|
||||
|
||||
1) Neither the Font Software nor any of its individual components,
|
||||
in Original or Modified Versions, may be sold by itself.
|
||||
|
||||
2) Original or Modified Versions of the Font Software may be bundled,
|
||||
redistributed and/or sold with any software, provided that each copy
|
||||
contains the above copyright notice and this license. These can be
|
||||
included either as stand-alone text files, human-readable headers or
|
||||
in the appropriate machine-readable metadata fields within text or
|
||||
binary files as long as those fields can be easily viewed by the user.
|
||||
|
||||
3) No Modified Version of the Font Software may use the Reserved Font
|
||||
Name(s) unless explicit written permission is granted by the corresponding
|
||||
Copyright Holder. This restriction only applies to the primary font name as
|
||||
presented to the users.
|
||||
|
||||
4) The name(s) of the Copyright Holder(s) or the Author(s) of the Font
|
||||
Software shall not be used to promote, endorse or advertise any
|
||||
Modified Version, except to acknowledge the contribution(s) of the
|
||||
Copyright Holder(s) and the Author(s) or with their explicit written
|
||||
permission.
|
||||
|
||||
5) The Font Software, modified or unmodified, in part or in whole,
|
||||
must be distributed entirely under this license, and must not be
|
||||
distributed under any other license. The requirement for fonts to
|
||||
remain under this license does not apply to any document created
|
||||
using the Font Software.
|
||||
|
||||
TERMINATION
|
||||
This license becomes null and void if any of the above conditions are
|
||||
not met.
|
||||
|
||||
DISCLAIMER
|
||||
THE FONT SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
||||
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES OF
|
||||
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT
|
||||
OF COPYRIGHT, PATENT, TRADEMARK, OR OTHER RIGHT. IN NO EVENT SHALL THE
|
||||
COPYRIGHT HOLDER BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
|
||||
INCLUDING ANY GENERAL, SPECIAL, INDIRECT, INCIDENTAL, OR CONSEQUENTIAL
|
||||
DAMAGES, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
||||
FROM, OUT OF THE USE OR INABILITY TO USE THE FONT SOFTWARE OR FROM
|
||||
OTHER DEALINGS IN THE FONT SOFTWARE.
|
||||
```
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 12 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 5.6 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.8 MiB |
Binary file not shown.
|
After Width: | Height: | Size: 6.0 MiB |
Executable
+90
@@ -0,0 +1,90 @@
|
||||
#!/bin/bash
|
||||
set -euo pipefail
|
||||
|
||||
cd "$(dirname "$0")" || exit 1
|
||||
|
||||
count_top_level_py_lines() {
|
||||
local dir="$1"
|
||||
if [ ! -d "$dir" ]; then
|
||||
echo 0
|
||||
return
|
||||
fi
|
||||
find "$dir" -maxdepth 1 -type f -name "*.py" -print0 | xargs -0 cat 2>/dev/null | wc -l | tr -d ' '
|
||||
}
|
||||
|
||||
count_recursive_py_lines() {
|
||||
local dir="$1"
|
||||
if [ ! -d "$dir" ]; then
|
||||
echo 0
|
||||
return
|
||||
fi
|
||||
find "$dir" -type f -name "*.py" -print0 | xargs -0 cat 2>/dev/null | wc -l | tr -d ' '
|
||||
}
|
||||
|
||||
count_skill_lines() {
|
||||
local dir="$1"
|
||||
if [ ! -d "$dir" ]; then
|
||||
echo 0
|
||||
return
|
||||
fi
|
||||
find "$dir" -type f \( -name "*.md" -o -name "*.py" -o -name "*.sh" \) -print0 | xargs -0 cat 2>/dev/null | wc -l | tr -d ' '
|
||||
}
|
||||
|
||||
print_row() {
|
||||
local label="$1"
|
||||
local count="$2"
|
||||
printf " %-16s %6s lines\n" "$label" "$count"
|
||||
}
|
||||
|
||||
echo "nanobot line count"
|
||||
echo "=================="
|
||||
echo ""
|
||||
|
||||
echo "Core runtime"
|
||||
echo "------------"
|
||||
core_agent=$(count_top_level_py_lines "nanobot/agent")
|
||||
core_bus=$(count_top_level_py_lines "nanobot/bus")
|
||||
core_config=$(count_top_level_py_lines "nanobot/config")
|
||||
core_cron=$(count_top_level_py_lines "nanobot/cron")
|
||||
core_session=$(count_top_level_py_lines "nanobot/session")
|
||||
|
||||
print_row "agent/" "$core_agent"
|
||||
print_row "bus/" "$core_bus"
|
||||
print_row "config/" "$core_config"
|
||||
print_row "cron/" "$core_cron"
|
||||
print_row "session/" "$core_session"
|
||||
|
||||
core_total=$((core_agent + core_bus + core_config + core_cron + core_session))
|
||||
|
||||
echo ""
|
||||
echo "Separate buckets"
|
||||
echo "----------------"
|
||||
extra_tools=$(count_recursive_py_lines "nanobot/agent/tools")
|
||||
extra_skills=$(count_skill_lines "nanobot/skills")
|
||||
extra_api=$(count_recursive_py_lines "nanobot/api")
|
||||
extra_cli=$(count_recursive_py_lines "nanobot/cli")
|
||||
extra_channels=$(count_recursive_py_lines "nanobot/channels")
|
||||
extra_utils=$(count_recursive_py_lines "nanobot/utils")
|
||||
|
||||
print_row "tools/" "$extra_tools"
|
||||
print_row "skills/" "$extra_skills"
|
||||
print_row "api/" "$extra_api"
|
||||
print_row "cli/" "$extra_cli"
|
||||
print_row "channels/" "$extra_channels"
|
||||
print_row "utils/" "$extra_utils"
|
||||
|
||||
extra_total=$((extra_tools + extra_skills + extra_api + extra_cli + extra_channels + extra_utils))
|
||||
|
||||
echo ""
|
||||
echo "Totals"
|
||||
echo "------"
|
||||
print_row "core total" "$core_total"
|
||||
print_row "extra total" "$extra_total"
|
||||
|
||||
echo ""
|
||||
echo "Notes"
|
||||
echo "-----"
|
||||
echo " - agent/ only counts top-level Python files under nanobot/agent"
|
||||
echo " - tools/ is counted separately from nanobot/agent/tools"
|
||||
echo " - skills/ counts .md, .py, and .sh files"
|
||||
echo " - not included here: command/, providers/, security/, templates/, nanobot.py, root files"
|
||||
@@ -0,0 +1,56 @@
|
||||
x-common-config: &common-config
|
||||
build:
|
||||
context: .
|
||||
dockerfile: Dockerfile
|
||||
volumes:
|
||||
- ~/.nanobot:/home/nanobot/.nanobot
|
||||
cap_drop:
|
||||
- ALL
|
||||
cap_add:
|
||||
- SYS_ADMIN
|
||||
security_opt:
|
||||
- apparmor=unconfined
|
||||
- seccomp=unconfined
|
||||
|
||||
services:
|
||||
nanobot-gateway:
|
||||
container_name: nanobot-gateway
|
||||
<<: *common-config
|
||||
command: ["gateway"]
|
||||
restart: unless-stopped
|
||||
ports:
|
||||
- 18790:18790
|
||||
- 8765:8765
|
||||
deploy:
|
||||
resources:
|
||||
limits:
|
||||
cpus: "1"
|
||||
memory: 1G
|
||||
reservations:
|
||||
cpus: "0.25"
|
||||
memory: 256M
|
||||
|
||||
nanobot-api:
|
||||
container_name: nanobot-api
|
||||
<<: *common-config
|
||||
command:
|
||||
["serve", "--host", "0.0.0.0", "-w", "/home/nanobot/.nanobot/api-workspace"]
|
||||
restart: unless-stopped
|
||||
ports:
|
||||
- 127.0.0.1:8900:8900
|
||||
deploy:
|
||||
resources:
|
||||
limits:
|
||||
cpus: "1"
|
||||
memory: 1G
|
||||
reservations:
|
||||
cpus: "0.25"
|
||||
memory: 256M
|
||||
|
||||
nanobot-cli:
|
||||
<<: *common-config
|
||||
profiles:
|
||||
- cli
|
||||
command: ["status"]
|
||||
stdin_open: true
|
||||
tty: true
|
||||
+150
@@ -0,0 +1,150 @@
|
||||
# nanobot Docs
|
||||
|
||||
For published release documentation, visit [nanobot.wiki](https://nanobot.wiki/docs/latest/getting-started/nanobot-overview). The pages in this directory track the current repository and may describe features that have not reached the published site yet.
|
||||
|
||||
If you have never used a terminal or edited a config file before, start with [`start-without-technical-background.md`](./start-without-technical-background.md). Otherwise, start with [`quick-start.md`](./quick-start.md), open the browser workbench with `nanobot webui`, and use terminal checks when you need lower-level diagnosis.
|
||||
|
||||
Most JSON examples in these docs are snippets to merge into `~/.nanobot/config.json`, not full replacement files.
|
||||
|
||||
Provider examples are concrete walkthroughs, not rankings or endorsements. Use the provider whose key, endpoint, and model ID you actually control.
|
||||
|
||||
If you find a docs mistake, outdated command, or confusing step, please open an issue: <https://github.com/HKUDS/nanobot/issues>.
|
||||
|
||||
## Pick a Track
|
||||
|
||||
| You are | Start with | Then use |
|
||||
|---|---|---|
|
||||
| New to terminals and config files | [`start-without-technical-background.md`](./start-without-technical-background.md) | [`troubleshooting.md`](./troubleshooting.md) if the first reply fails |
|
||||
| Comfortable pasting commands and JSON | [`quick-start.md`](./quick-start.md) | [`provider-cookbook.md`](./provider-cookbook.md) for pasteable provider setups |
|
||||
| Operating a long-running bot | [`concepts.md`](./concepts.md) | [`chat-apps.md`](./chat-apps.md), [`webui.md`](./webui.md), and [`deployment.md`](./deployment.md) |
|
||||
| Integrating or extending nanobot | [`architecture.md`](./architecture.md) | [`configuration.md`](./configuration.md), [`openai-api.md`](./openai-api.md), [`python-sdk.md`](./python-sdk.md), [`development.md`](./development.md), and [`channel-plugin-guide.md`](./channel-plugin-guide.md) |
|
||||
|
||||
## Start Here
|
||||
|
||||
| Goal | Read | Outcome |
|
||||
|---|---|---|
|
||||
| Start with no technical background | [`start-without-technical-background.md`](./start-without-technical-background.md) | One-command setup, terminal basics, config, API keys, and the first reply |
|
||||
| Install and get the first reply | [`quick-start.md`](./quick-start.md) | A working CLI agent and a known-good config path |
|
||||
| Understand how the pieces fit | [`concepts.md`](./concepts.md) | Mental model for config, workspace, gateway, channels, tools, memory, and sessions |
|
||||
| Choose or change a model provider | [`providers.md`](./providers.md) | Correct provider/model pairing without reading the full config reference |
|
||||
| Copy a provider setup recipe | [`provider-cookbook.md`](./provider-cookbook.md) | Pasteable OpenRouter, OpenAI, Anthropic, local model, fallback, and Langfuse setups |
|
||||
| Fix a first-run or runtime problem | [`troubleshooting.md`](./troubleshooting.md) | A diagnosis order and targeted checks for common failures |
|
||||
|
||||
## Task Guides
|
||||
|
||||
Use these pages when you know the workflow you want and do not want to scan the
|
||||
full reference first.
|
||||
|
||||
| Goal | Guide |
|
||||
|---|---|
|
||||
| Build a personal AI agent | [`guides/build-a-personal-ai-agent.md`](./guides/build-a-personal-ai-agent.md) |
|
||||
| Run a self-hosted AI agent | [`guides/self-hosted-ai-agent.md`](./guides/self-hosted-ai-agent.md) |
|
||||
| Use a browser AI agent WebUI | [`guides/ai-agent-webui.md`](./guides/ai-agent-webui.md) |
|
||||
| Connect an AI agent to chat apps | [`guides/chat-app-ai-agent.md`](./guides/chat-app-ai-agent.md) |
|
||||
| Run long-running agent tasks | [`guides/long-running-ai-agent.md`](./guides/long-running-ai-agent.md) |
|
||||
| Schedule or trigger agent turns | [`automations.md`](./automations.md) |
|
||||
| Add long-term agent memory | [`guides/ai-agent-memory.md`](./guides/ai-agent-memory.md) |
|
||||
| Add MCP tools to an agent | [`guides/mcp-tools-for-ai-agents.md`](./guides/mcp-tools-for-ai-agents.md) |
|
||||
| Run an agent from Python | [`guides/python-ai-agent-sdk.md`](./guides/python-ai-agent-sdk.md) |
|
||||
| Expose an OpenAI-compatible agent API | [`guides/openai-compatible-agent-api.md`](./guides/openai-compatible-agent-api.md) |
|
||||
| Deploy a long-running agent gateway | [`guides/deploy-nanobot-gateway.md`](./guides/deploy-nanobot-gateway.md) |
|
||||
|
||||
Platform-specific chat guides:
|
||||
[`Telegram`](./guides/telegram-ai-agent.md),
|
||||
[`Discord`](./guides/discord-ai-agent.md),
|
||||
[`Slack`](./guides/slack-ai-agent.md),
|
||||
[`Feishu`](./guides/feishu-ai-agent.md),
|
||||
[`WhatsApp`](./guides/whatsapp-ai-agent.md),
|
||||
[`WeChat`](./guides/wechat-ai-agent.md),
|
||||
[`QQ`](./guides/qq-ai-agent.md),
|
||||
[`Email`](./guides/email-ai-agent.md), and
|
||||
[`Mattermost`](./guides/mattermost-ai-agent.md).
|
||||
|
||||
Configuration guides:
|
||||
[`MCP tools`](./guides/configure-mcp-tools.md),
|
||||
[`web search`](./guides/configure-web-search.md),
|
||||
[`model fallback`](./guides/configure-model-fallback.md),
|
||||
[`OpenAI-compatible providers`](./guides/configure-openai-compatible-provider.md),
|
||||
[`Langfuse`](./guides/configure-langfuse-observability.md),
|
||||
[`local security`](./guides/secure-local-ai-agent.md), and
|
||||
[`gateway deployment`](./guides/deploy-nanobot-gateway.md).
|
||||
|
||||
## After the First Reply Works
|
||||
|
||||
Do not configure everything at once. Pick one next surface:
|
||||
|
||||
If a local `nanobot agent` session can already answer normally, you can also ask nanobot to help configure itself: have it read the relevant docs, inspect your current config, make one specific next change, and tell you when to run `/restart`.
|
||||
|
||||
| Next goal | Read | First check |
|
||||
|---|---|---|
|
||||
| Use nanobot in a browser | [`webui.md`](./webui.md) | Run `nanobot webui` and open the local browser workbench |
|
||||
| Talk through a chat app | [`chat-apps.md`](./chat-apps.md) | Merge one channel snippet, run `nanobot channels status`, keep `nanobot gateway` running |
|
||||
| Change provider or add fallbacks | [`provider-cookbook.md`](./provider-cookbook.md) | Keep `modelPresets` named and set `agents.defaults.modelPreset` |
|
||||
| Call nanobot from Python | [`python-sdk.md`](./python-sdk.md) | Reuse the same config/workspace from code, then run or stream one agent turn |
|
||||
| Understand before operating long-term | [`concepts.md`](./concepts.md) | Know what config, workspace, gateway, sessions, memory, and tools mean |
|
||||
| Diagnose a new failure | [`troubleshooting.md`](./troubleshooting.md) | Start with `nanobot status`, then `nanobot agent -m "Hello!"` |
|
||||
|
||||
## Use nanobot
|
||||
|
||||
| Goal | Read | Outcome |
|
||||
|---|---|---|
|
||||
| Open the bundled browser UI | [`webui.md`](./webui.md) | `nanobot webui`, chat workspace, Apps, Skills, Automations, and settings |
|
||||
| Connect Telegram, Discord, WeChat, Slack, Email, Mattermost, or another chat app | [`chat-apps.md`](./chat-apps.md) | A gateway-backed chat channel with access control |
|
||||
| Use automations | [`automations.md`](./automations.md) | Scheduled automations, local triggers, heartbeat, WebUI management, and delivery behavior |
|
||||
| Use slash commands | [`chat-commands.md`](./chat-commands.md) | Pairing, model presets, local triggers, heartbeat tasks, and chat-side controls |
|
||||
| Generate images | [`image-generation.md`](./image-generation.md) | Image provider config, WebUI image mode, and artifact behavior |
|
||||
| Run several isolated bots | [`multiple-instances.md`](./multiple-instances.md) | Separate configs, workspaces, ports, and sessions |
|
||||
| Deploy outside a terminal | [`deployment.md`](./deployment.md) | Docker, systemd user services, and macOS LaunchAgent setup |
|
||||
| Join agent communities | [`agent-social-network.md`](./agent-social-network.md) | External agent-community setup |
|
||||
|
||||
## Reference
|
||||
|
||||
| Area | Read | Best for |
|
||||
|---|---|---|
|
||||
| Full configuration schema | [`configuration.md`](./configuration.md) | Exact fields, defaults, provider tables, web tools, MCP, security, and runtime options |
|
||||
| CLI commands | [`cli-reference.md`](./cli-reference.md) | Command names, common flags, and entrypoints |
|
||||
| Architecture | [`architecture.md`](./architecture.md) | Source-level runtime map for core flow, providers, channels, tools, WebUI, memory, security, and extension points |
|
||||
| Release archive | [`release-archive.md`](./release-archive.md) | Older release and daily update highlights moved out of the README |
|
||||
| Development | [`development.md`](./development.md) | Contributor notes for adding providers and transcription adapters |
|
||||
| Memory | [`memory.md`](./memory.md) | Session history, Dream consolidation, memory files, and versioning |
|
||||
| Observability | [`configuration.md#langfuse-observability`](./configuration.md#langfuse-observability) | Langfuse tracing setup and required environment variables |
|
||||
| WebSocket protocol | [`websocket.md`](./websocket.md) | Custom clients, token issuance, multiplexed chats, media, and protocol events |
|
||||
| OpenAI-compatible API | [`openai-api.md`](./openai-api.md) | `/v1/chat/completions`, `/v1/models`, file uploads, and SDK-compatible usage |
|
||||
| Python SDK | [`python-sdk.md`](./python-sdk.md) | SDK 101, sessions, streaming, model overrides, runtime helpers, and hooks |
|
||||
| Runtime self-inspection | [`my-tool.md`](./my-tool.md) | Inspecting and tuning the current agent run |
|
||||
|
||||
## Fast Lookup
|
||||
|
||||
| Need | Jump to |
|
||||
|---|---|
|
||||
| Provider/model resolution order | [`providers.md#provider-resolution`](./providers.md#provider-resolution) |
|
||||
| Model presets and fallback chains | [`providers.md#model-presets`](./providers.md#model-presets) and [`providers.md#fallback-models`](./providers.md#fallback-models) |
|
||||
| Langfuse environment variables | [`configuration.md#langfuse-observability`](./configuration.md#langfuse-observability) |
|
||||
| WebSocket/WebUI protocol details | [`websocket.md`](./websocket.md) |
|
||||
| OpenAI-compatible API usage | [`openai-api.md`](./openai-api.md) |
|
||||
| Python SDK usage | [`python-sdk.md`](./python-sdk.md) |
|
||||
| Scheduled automations and local triggers | [`automations.md`](./automations.md) |
|
||||
| Multiple configs, workspaces, and ports | [`multiple-instances.md`](./multiple-instances.md) |
|
||||
| Security, sandboxing, and SSRF controls | [`configuration.md#security`](./configuration.md#security) |
|
||||
| Channel plugin development | [`channel-plugin-guide.md`](./channel-plugin-guide.md) |
|
||||
|
||||
## Extend nanobot
|
||||
|
||||
| Goal | Read | Outcome |
|
||||
|---|---|---|
|
||||
| Add a provider or transcription adapter | [`development.md`](./development.md) | A registry/schema-aligned implementation path |
|
||||
| Add a chat channel plugin | [`channel-plugin-guide.md`](./channel-plugin-guide.md) | A packaged channel discovered through entry points |
|
||||
| Add custom MCP servers | [`configuration.md#mcp-model-context-protocol`](./configuration.md#mcp-model-context-protocol) | External tools exposed to the agent through MCP |
|
||||
| Tune tool safety | [`configuration.md#security`](./configuration.md#security) | Shell sandboxing, workspace restriction, and SSRF policy |
|
||||
|
||||
## Reading Strategy
|
||||
|
||||
Use the docs in this order when you are unsure where to go:
|
||||
|
||||
1. If terminal commands or config files are new to you, [`start-without-technical-background.md`](./start-without-technical-background.md) explains the setup words and uses one concrete provider example so there is only one decision at a time.
|
||||
2. [`quick-start.md`](./quick-start.md) proves installation, config loading, and provider access.
|
||||
3. [`concepts.md`](./concepts.md) explains the runtime model so later pages are easier to scan.
|
||||
4. [`provider-cookbook.md`](./provider-cookbook.md) gives pasteable provider, fallback, local model, and Langfuse recipes.
|
||||
5. A task guide, such as [`chat-apps.md`](./chat-apps.md), [`image-generation.md`](./image-generation.md), or [`deployment.md`](./deployment.md), gets one workflow working.
|
||||
6. [`configuration.md`](./configuration.md) is the source of truth when you need a specific field, default value, or advanced option.
|
||||
7. [`troubleshooting.md`](./troubleshooting.md) helps isolate whether a failure is install, config, provider, gateway, channel, or tool related.
|
||||
@@ -0,0 +1,99 @@
|
||||
# Agent Social Network
|
||||
|
||||
An agent social network lets a nanobot instance join an external agent community
|
||||
or chat network as a bot identity. After joining, nanobot can receive messages
|
||||
through that network, answer with its normal agent runtime, and use the same
|
||||
workspace, tools, memory, and channel access controls that apply elsewhere.
|
||||
|
||||
This page describes the current entry points and the safety model. Treat each
|
||||
network as an external integration: only join networks you trust, keep owner
|
||||
approval narrow, and review the skill instructions before asking nanobot to
|
||||
follow them.
|
||||
|
||||
## What is an agent social network?
|
||||
|
||||
In nanobot docs, an agent social network is an external community that publishes
|
||||
setup instructions for nanobot-compatible agents. The setup usually lives in a
|
||||
remote `skill.md` file. You send nanobot a message asking it to read that file
|
||||
and follow the network's registration flow.
|
||||
|
||||
The external network is not part of nanobot core. nanobot provides the runtime:
|
||||
model calls, tools, memory, sessions, and channel delivery.
|
||||
|
||||
> [!WARNING]
|
||||
> Remote `skill.md` files are external instructions. Review them before asking
|
||||
> nanobot to follow them, especially when file, shell, network, or chat-delivery
|
||||
> tools are enabled. Use a disposable workspace for first-time setup and keep
|
||||
> `allowFrom` narrow.
|
||||
|
||||
## What nanobot can do after joining
|
||||
|
||||
After setup, the exact behavior depends on the network, but the normal pattern
|
||||
is:
|
||||
|
||||
- receive direct messages or community messages addressed to the bot
|
||||
- reply through the configured network channel
|
||||
- use normal nanobot tools allowed by your configuration
|
||||
- keep session history for conversations that flow through the network
|
||||
- use Dream memory if memory is enabled for the workspace
|
||||
|
||||
## Supported networks
|
||||
|
||||
| Platform | Join message to send to your bot |
|
||||
|---|---|
|
||||
| [Moltbook](https://www.moltbook.com/) | `Read https://moltbook.com/skill.md and follow the instructions to join Moltbook` |
|
||||
| [ClawdChat](https://clawdchat.ai/) | `Read https://clawdchat.ai/skill.md and follow the instructions to join ClawdChat` |
|
||||
|
||||
Send the message from the CLI, WebUI, or an already configured chat channel.
|
||||
nanobot will read the public setup instructions and perform the requested setup
|
||||
using its available tools.
|
||||
|
||||
## Security model
|
||||
|
||||
- The remote setup instructions are external content. Read them yourself before
|
||||
running the join prompt if the bot has file, shell, or network tools enabled.
|
||||
- Keep `allowFrom` narrow on the channel you use for setup so only trusted users
|
||||
can issue registration commands.
|
||||
- Keep `tools.restrictToWorkspace` enabled unless the network setup explicitly
|
||||
needs another path.
|
||||
- Avoid `allowFrom: ["*"]` during setup unless the bot is isolated in a test
|
||||
workspace.
|
||||
- Store network tokens through environment variables when the integration
|
||||
supports secrets.
|
||||
|
||||
## Example workflow
|
||||
|
||||
1. Confirm the local agent works:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
2. Open the WebUI or a trusted chat channel.
|
||||
|
||||
3. Send the join message for the network you want.
|
||||
|
||||
4. Restart the gateway if the setup changes channel configuration:
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
5. Send a test message through the external network and confirm the session is
|
||||
routed to the expected workspace and model.
|
||||
|
||||
## Limitations
|
||||
|
||||
- Network features, identity, and moderation rules are controlled by the
|
||||
external network.
|
||||
- Availability depends on the remote setup instructions remaining reachable.
|
||||
- nanobot does not automatically audit remote skills for you.
|
||||
- Some networks may require public callbacks, tokens, or channel-specific
|
||||
account setup.
|
||||
|
||||
## Related docs
|
||||
|
||||
- [Chat Apps](./chat-apps.md)
|
||||
- [Security configuration](./configuration.md#security)
|
||||
- [Pairing](./configuration.md#pairing)
|
||||
- [Runtime self-inspection](./my-tool.md)
|
||||
@@ -0,0 +1,212 @@
|
||||
# Architecture
|
||||
|
||||
This page maps nanobot's runtime behavior to source files. Use it when you are debugging internals, reviewing a PR, adding a provider/channel/tool, or trying to understand where a user-visible behavior comes from.
|
||||
|
||||
For the product-level mental model, read [`concepts.md`](./concepts.md) first.
|
||||
|
||||
## Core Flow
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
Channel["Channel<br/>CLI, WebUI, chat apps"] --> Bus["MessageBus<br/>InboundMessage"]
|
||||
Bus --> Loop["AgentLoop<br/>session, workspace, context"]
|
||||
Loop --> Runner["AgentRunner<br/>provider/tool loop"]
|
||||
Runner --> Provider["Provider<br/>LLM backend"]
|
||||
Provider --> Runner
|
||||
Runner --> Tools["Tools<br/>files, shell, web, MCP, cron"]
|
||||
Tools --> Runner
|
||||
Runner --> Loop
|
||||
Loop --> Outbound["MessageBus<br/>OutboundMessage"]
|
||||
Outbound --> Channel
|
||||
|
||||
Loop -. reads/writes .-> State["Session, memory,<br/>hooks, skills, templates"]
|
||||
```
|
||||
|
||||
Main files:
|
||||
|
||||
| Area | Files |
|
||||
|---|---|
|
||||
| Message events and queue | `nanobot/bus/events.py`, `nanobot/bus/queue.py` |
|
||||
| Turn orchestration | `nanobot/agent/loop.py` |
|
||||
| Provider/tool conversation loop | `nanobot/agent/runner.py` |
|
||||
| Context construction | `nanobot/agent/context.py` |
|
||||
| Session storage and compaction | `nanobot/session/manager.py` |
|
||||
| Long-term memory and Dream | `nanobot/agent/memory.py` |
|
||||
|
||||
## Agent Loop vs Agent Runner
|
||||
|
||||
`AgentLoop` owns the channel-facing turn:
|
||||
|
||||
- receives inbound messages;
|
||||
- determines the effective session and workspace scope;
|
||||
- builds context;
|
||||
- wires hooks, progress, and channel metadata;
|
||||
- publishes outbound messages.
|
||||
|
||||
`AgentRunner` owns the model-facing loop:
|
||||
|
||||
- sends messages to the selected provider;
|
||||
- handles streaming deltas and reasoning blocks;
|
||||
- executes tool calls;
|
||||
- feeds tool results back into the model;
|
||||
- stops when a final answer is produced or runtime limits are hit.
|
||||
|
||||
Keep this split in mind when debugging. If a problem is about channel routing, session keys, workspace selection, or outbound delivery, start in `agent/loop.py`. If it is about provider calls, tool calls, streaming, or iteration limits, start in `agent/runner.py`.
|
||||
|
||||
## Providers
|
||||
|
||||
Provider metadata is centralized in `nanobot/providers/registry.py`. Configuration fields live in `nanobot/config/schema.py`.
|
||||
|
||||
Provider selection uses:
|
||||
|
||||
- explicit `agents.defaults.provider` or preset provider;
|
||||
- provider registry keywords;
|
||||
- API key prefixes and API base URL hints;
|
||||
- local provider fallback when `apiBase` is configured;
|
||||
- gateway fallback for providers that can route many model families.
|
||||
|
||||
Provider implementations live in `nanobot/providers/`. Most hosted providers use the OpenAI-compatible implementation, while Anthropic, Azure OpenAI, AWS Bedrock, OpenAI Codex, and GitHub Copilot have specialized paths.
|
||||
|
||||
Useful docs:
|
||||
|
||||
- [`providers.md`](./providers.md) for practical setup;
|
||||
- [`configuration.md#providers`](./configuration.md#providers) for exact provider reference.
|
||||
|
||||
## Channels
|
||||
|
||||
Channels translate external platforms into `InboundMessage` events and send `OutboundMessage` events back to the platform.
|
||||
|
||||
Main files:
|
||||
|
||||
| Area | Files |
|
||||
|---|---|
|
||||
| Base channel contract | `nanobot/channels/base.py` |
|
||||
| Built-in channels | `nanobot/channels/*.py` |
|
||||
| Discovery and lifecycle | `nanobot/channels/manager.py` |
|
||||
| WebSocket/WebUI channel | `nanobot/channels/websocket.py` |
|
||||
|
||||
Channels are discovered through built-in module scanning and plugin entry points. A custom channel should follow [`channel-plugin-guide.md`](./channel-plugin-guide.md).
|
||||
|
||||
## WebUI and Gateway
|
||||
|
||||
`nanobot gateway` starts:
|
||||
|
||||
- enabled chat channels;
|
||||
- the WebSocket channel when configured;
|
||||
- workspace-scoped cron service;
|
||||
- system jobs such as Dream and heartbeat;
|
||||
- the health endpoint on `gateway.port`.
|
||||
|
||||
The packaged WebUI is served by the WebSocket channel, not the health endpoint:
|
||||
|
||||
| Surface | Default |
|
||||
|---|---|
|
||||
| Health endpoint | `http://127.0.0.1:18790/health` |
|
||||
| WebUI/WebSocket | `http://127.0.0.1:8765` |
|
||||
|
||||
WebUI source lives in `webui/`. The production build is written to `nanobot/web/dist/` and bundled into the wheel.
|
||||
|
||||
Useful docs:
|
||||
|
||||
- [`webui.md`](./webui.md) for the WebUI user guide;
|
||||
- [`../webui/README.md`](../webui/README.md) for frontend source development;
|
||||
- [`websocket.md`](./websocket.md) for protocol details.
|
||||
|
||||
## Tools
|
||||
|
||||
Tools are discovered from `nanobot/agent/tools/` and plugin entry points.
|
||||
|
||||
Important files:
|
||||
|
||||
| Tool area | Files |
|
||||
|---|---|
|
||||
| Tool base and schema | `nanobot/agent/tools/base.py`, `nanobot/agent/tools/schema.py` |
|
||||
| Discovery | `nanobot/agent/tools/registry.py` |
|
||||
| Shell execution | `nanobot/agent/tools/shell.py` |
|
||||
| Filesystem tools | `nanobot/agent/tools/filesystem.py` |
|
||||
| Web search/fetch | `nanobot/agent/tools/web.py` |
|
||||
| MCP tools | `nanobot/agent/tools/mcp.py` |
|
||||
| Cron | `nanobot/agent/tools/cron.py`, `nanobot/cron/` |
|
||||
| Image generation | `nanobot/agent/tools/image_generation.py` |
|
||||
| Runtime self-inspection | `nanobot/agent/tools/self.py` |
|
||||
|
||||
Tool behavior is part of the model contract. Keep user-visible tool names, schemas, and error messages stable unless a change is intentional.
|
||||
|
||||
## Config and Paths
|
||||
|
||||
The config schema lives in `nanobot/config/schema.py`. Loading and saving live in `nanobot/config/loader.py`. Runtime path helpers live in `nanobot/config/paths.py`.
|
||||
|
||||
Defaults:
|
||||
|
||||
| Path | Default |
|
||||
|---|---|
|
||||
| Config | `~/.nanobot/config.json` |
|
||||
| Workspace | `~/.nanobot/workspace/` |
|
||||
| Sessions | `<workspace>/sessions/*.jsonl` |
|
||||
| Memory | `<workspace>/memory/` |
|
||||
| Cron store | `<workspace>/cron/jobs.json` |
|
||||
| WebUI/media/log runtime data | config directory subdirectories such as `webui/`, `media/`, and `logs/` |
|
||||
|
||||
The schema accepts both camelCase and snake_case keys, but saves config with camelCase aliases.
|
||||
|
||||
## Memory and Sessions
|
||||
|
||||
Session history is the near-term conversation replay. Memory is the longer-term workspace state.
|
||||
|
||||
| Store | File area |
|
||||
|---|---|
|
||||
| Session JSONL files | `<workspace>/sessions/` |
|
||||
| Long-term memory | `<workspace>/memory/MEMORY.md` |
|
||||
| Consolidation source history | `<workspace>/memory/history.jsonl` |
|
||||
| Bootstrap identity files | `<workspace>/SOUL.md`, `<workspace>/USER.md`, templates under `nanobot/templates/` |
|
||||
|
||||
Dream is implemented in `nanobot/agent/memory.py` and scheduled by the runtime when enabled.
|
||||
|
||||
## Security Boundaries
|
||||
|
||||
Security-sensitive code paths include:
|
||||
|
||||
| Boundary | Files |
|
||||
|---|---|
|
||||
| Workspace scope | `nanobot/security/workspace_access.py`, `nanobot/security/workspace_policy.py` |
|
||||
| Shell sandboxing | `nanobot/agent/tools/shell.py` |
|
||||
| SSRF/network checks | `nanobot/security/network.py`, `nanobot/agent/tools/web.py` |
|
||||
| PTH guard and CLI startup security | `nanobot/security/` and CLI entrypoints |
|
||||
| Channel access control | channel config in `nanobot/channels/*.py` |
|
||||
|
||||
When changing tools, channels, file access, WebUI workspace behavior, or network fetching, treat security as part of the functional behavior and update docs if the user-facing boundary changes.
|
||||
|
||||
## Extension Points
|
||||
|
||||
| Extension | How |
|
||||
|---|---|
|
||||
| Provider | Add `ProviderSpec` in `providers/registry.py`, add schema field in `config/schema.py`, implement provider only if the generic backend is not enough |
|
||||
| Channel | Implement `BaseChannel`, expose an entry point, follow [`channel-plugin-guide.md`](./channel-plugin-guide.md) |
|
||||
| Tool | Implement a tool under `agent/tools/` or expose a plugin entry point |
|
||||
| MCP | Add `tools.mcpServers` config |
|
||||
| Skill | Add workspace skill files under `<workspace>/skills/` or built-in skills under `nanobot/skills/` |
|
||||
|
||||
Prefer existing registry/discovery patterns over ad hoc wiring.
|
||||
|
||||
## Testing and Verification
|
||||
|
||||
Common checks:
|
||||
|
||||
```bash
|
||||
pytest tests/test_openai_api.py::test_function -v
|
||||
ruff check nanobot/
|
||||
cd webui && bun run test
|
||||
cd webui && bun run build
|
||||
```
|
||||
|
||||
Choose tests based on the changed surface:
|
||||
|
||||
| Change | Minimum useful verification |
|
||||
|---|---|
|
||||
| Provider behavior | Provider unit tests or a mocked API path; `nanobot agent -m "Hello!"` with safe config when possible |
|
||||
| Channel behavior | Channel tests plus `nanobot gateway` startup path |
|
||||
| WebUI behavior | WebUI tests/build and, for routing/settings/chat changes, browser-level verification through the gateway |
|
||||
| Tool behavior | Tool unit tests and an agent-run path when schema or model-facing behavior changes |
|
||||
| Docs | Link checks, command accuracy against CLI/schema, and `git diff --check` |
|
||||
|
||||
For user-facing flows, prefer at least one verification path through the public surface the user actually touches: CLI command, HTTP endpoint, WebSocket/WebUI, chat channel, or packaged import.
|
||||
@@ -0,0 +1,201 @@
|
||||
# Automations
|
||||
|
||||
<!-- Meta description: Create, run, and manage nanobot scheduled automations, local triggers, and heartbeat-backed background checks. -->
|
||||
|
||||
Automations are agent turns that run later in a linked chat/session. Use them
|
||||
when nanobot should do work without someone actively typing: reminders,
|
||||
recurring checks, nightly summaries, CI follow-ups, local script reports, or
|
||||
webhook-driven events.
|
||||
|
||||
Create automations from the chat, channel, or WebUI session where the result
|
||||
should appear. That lets nanobot keep the right session history, workspace, and
|
||||
reply target.
|
||||
|
||||
## Choose an Automation Type
|
||||
|
||||
| Type | Starts from | Best for | Created with |
|
||||
|---|---|---|---|
|
||||
| Scheduled automation | Time, interval, or cron expression | Recurring reminders, scheduled summaries, one-time future tasks | Ask nanobot in the target session to schedule it with the `cron` tool |
|
||||
| Local trigger | A local `nanobot trigger ...` command | CI jobs, webhooks, shell scripts, generated reports | `/trigger <name>` in the target session |
|
||||
| Heartbeat | Protected system schedule | Quiet recurring checks that should only report useful results | Edit `<workspace>/HEARTBEAT.md` |
|
||||
|
||||
The two user-created automation types are scheduled automations and local
|
||||
triggers. Heartbeat uses the same background service but is system-managed and
|
||||
protected from normal automation edits.
|
||||
|
||||
## Before You Create One
|
||||
|
||||
Keep `nanobot gateway` running. The gateway owns background delivery for chat
|
||||
apps, WebUI sessions, scheduled automations, local triggers, heartbeat, and
|
||||
Dream jobs.
|
||||
|
||||
Use the same workspace and config for the gateway and any process that sends
|
||||
local trigger messages. If you run multiple nanobot instances, pass the matching
|
||||
`--config` or `--workspace` option to `nanobot trigger`.
|
||||
|
||||
Create each automation from the target session. An automation without a linked
|
||||
chat/session cannot be enabled or run from the WebUI because nanobot would not
|
||||
know where to deliver the turn.
|
||||
|
||||
## Scheduled Automations
|
||||
|
||||
Scheduled automations are created by the agent's `cron` tool. In practice, ask
|
||||
nanobot from the target chat or WebUI session:
|
||||
|
||||
```text
|
||||
Every weekday at 9am, check open pull requests and summarize blockers here.
|
||||
```
|
||||
|
||||
or:
|
||||
|
||||
```text
|
||||
Tomorrow at 4pm, remind me to send the release notes.
|
||||
```
|
||||
|
||||
The cron tool supports interval schedules, cron expressions, and one-time
|
||||
scheduled tasks. Cron expressions can include an IANA timezone such as
|
||||
`America/Vancouver`; otherwise nanobot uses the runtime default timezone.
|
||||
|
||||
Scheduled automations normally deliver the result back to the session where they
|
||||
were created. Use them for work that should run on a predictable schedule and
|
||||
report each run.
|
||||
|
||||
For background checks that should stay quiet unless there is something useful to
|
||||
report, use heartbeat instead of a user-created scheduled automation.
|
||||
|
||||
## Local Triggers
|
||||
|
||||
Local triggers let a local script or external service send a message into a
|
||||
specific nanobot session later.
|
||||
|
||||
Create the trigger from the chat or WebUI session where future messages should
|
||||
arrive:
|
||||
|
||||
```text
|
||||
/trigger PR review
|
||||
```
|
||||
|
||||
nanobot replies with a trigger ID and a command shaped like:
|
||||
|
||||
```bash
|
||||
nanobot trigger trg_8K4P2Q9X "Review PR #4502"
|
||||
```
|
||||
|
||||
Replace the quoted text with the message nanobot should receive. For generated
|
||||
or longer content, pipe stdin:
|
||||
|
||||
```bash
|
||||
generate-report | nanobot trigger trg_8K4P2Q9X
|
||||
```
|
||||
|
||||
For multiple instances, use the same config or workspace selector as the
|
||||
gateway:
|
||||
|
||||
```bash
|
||||
nanobot trigger --config ./bot-a/config.json trg_8K4P2Q9X "Nightly report"
|
||||
nanobot trigger --workspace ./bot-a/workspace trg_8K4P2Q9X "Nightly report"
|
||||
```
|
||||
|
||||
nanobot does not provide a built-in public webhook receiver for local triggers.
|
||||
If GitHub, CI, or another external system should wake nanobot, run your own
|
||||
small webhook service and have it call `nanobot trigger` after it builds the
|
||||
final message.
|
||||
|
||||
## Heartbeat
|
||||
|
||||
Heartbeat is for recurring workspace checks that should usually stay quiet. It
|
||||
reads `<workspace>/HEARTBEAT.md`, executes active tasks, and sends only useful or
|
||||
actionable results to the most recently active chat target.
|
||||
|
||||
Use heartbeat for checks such as "watch this repo for important failures" or
|
||||
"periodically inspect this workspace and only tell me when action is needed." Use
|
||||
a scheduled automation instead when every run should produce a visible reminder
|
||||
or report.
|
||||
|
||||
Heartbeat is enabled by default when `nanobot gateway` starts. Configure it in
|
||||
[`configuration.md#gateway-heartbeat`](./configuration.md#gateway-heartbeat).
|
||||
|
||||
## Manage Automations
|
||||
|
||||
Use the WebUI Automations view to:
|
||||
|
||||
- filter by all, active, paused, needs-attention, or system jobs;
|
||||
- search by task name, message, trigger command, linked chat, schedule, or
|
||||
status;
|
||||
- sort by next run, last run, updated time, or name;
|
||||
- run scheduled automations now;
|
||||
- pause or resume, rename, or delete user-created automations;
|
||||
- copy the CLI command for local triggers;
|
||||
- inspect protected system automations without changing them.
|
||||
|
||||
Local triggers do not have a WebUI "Run now" action because each run needs a
|
||||
message. Copy the `nanobot trigger ...` command from the WebUI and replace
|
||||
`"message"` with the content that should be delivered.
|
||||
|
||||
## Delivery and Reliability
|
||||
|
||||
Automation delivery is workspace-local. Scheduled jobs and local trigger
|
||||
deliveries use the same workspace as the gateway.
|
||||
|
||||
Local trigger messages are written to a durable queue. If the gateway is not
|
||||
running yet, the message waits in that workspace. If the linked session is
|
||||
already running a turn, the trigger waits until the session becomes idle instead
|
||||
of being injected into the active turn.
|
||||
|
||||
The local trigger queue is at-least-once, not exactly-once. If the gateway exits
|
||||
after claiming a delivery but before the linked turn completes, the next gateway
|
||||
start requeues that delivery. External scripts should make repeated trigger
|
||||
messages safe. If the delivery reaches the agent and the turn fails, the
|
||||
delivery is marked failed instead of retrying forever.
|
||||
|
||||
Each local trigger delivery writes an audit record under
|
||||
`<workspace>/triggers/runs`. Run one gateway consumer per workspace; the local
|
||||
queue is not a distributed multi-consumer queue.
|
||||
|
||||
## Common Patterns
|
||||
|
||||
For a nightly report, ask from the target session:
|
||||
|
||||
```text
|
||||
Every night at 9pm, review today's workspace changes and summarize anything I should handle tomorrow.
|
||||
```
|
||||
|
||||
For a CI follow-up, create a trigger once:
|
||||
|
||||
```text
|
||||
/trigger CI follow-up
|
||||
```
|
||||
|
||||
Then have your CI or webhook adapter call:
|
||||
|
||||
```bash
|
||||
nanobot trigger <trigger-id> "Build failed on main. Inspect the logs and suggest the next fix."
|
||||
```
|
||||
|
||||
For a local report script:
|
||||
|
||||
```bash
|
||||
generate-report | nanobot trigger <trigger-id>
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If an automation does not run, check that `nanobot gateway` is running, the
|
||||
automation is enabled, and it was created from a linked chat/session.
|
||||
|
||||
If a local trigger waits forever, confirm the command uses the same workspace or
|
||||
config as the gateway.
|
||||
|
||||
If a trigger message appears twice after a restart, treat it as expected
|
||||
at-least-once delivery and make the external message idempotent.
|
||||
|
||||
If you need to edit, pause, resume, rename, delete, or inspect automations, use
|
||||
the WebUI Automations view.
|
||||
|
||||
## Related Docs
|
||||
|
||||
- [`webui.md#automations`](./webui.md#automations) for the browser management view
|
||||
- [`chat-commands.md#local-triggers`](./chat-commands.md#local-triggers) for `/trigger`
|
||||
- [`cli-reference.md#local-triggers`](./cli-reference.md#local-triggers) for `nanobot trigger`
|
||||
- [`configuration.md#gateway-heartbeat`](./configuration.md#gateway-heartbeat) for heartbeat settings
|
||||
- [`guides/long-running-ai-agent.md`](./guides/long-running-ai-agent.md) for long-running agent work
|
||||
@@ -0,0 +1,568 @@
|
||||
# Channel Plugin Guide
|
||||
|
||||
Build a custom nanobot channel in three steps: subclass, package, install.
|
||||
|
||||
> **Note:** We recommend developing channel plugins against a source checkout of nanobot (`python -m pip install -e .`) rather than a PyPI release, so you always have access to the latest base-channel features and APIs.
|
||||
|
||||
## How It Works
|
||||
|
||||
nanobot discovers channel plugins via Python [entry points](https://packaging.python.org/en/latest/specifications/entry-points/). When `nanobot gateway` starts, it scans:
|
||||
|
||||
1. Built-in channels in `nanobot/channels/`
|
||||
2. External packages registered under the `nanobot.channels` entry point group
|
||||
|
||||
If a matching config section has `"enabled": true`, the channel is instantiated and started.
|
||||
|
||||
## Quick Start
|
||||
|
||||
We'll build a minimal webhook channel that receives messages via HTTP POST and sends replies back.
|
||||
|
||||
### Project Structure
|
||||
|
||||
```text
|
||||
nanobot-channel-webhook/
|
||||
├── nanobot_channel_webhook/
|
||||
│ ├── __init__.py # re-export WebhookChannel
|
||||
│ └── channel.py # channel implementation
|
||||
└── pyproject.toml
|
||||
```
|
||||
|
||||
### 1. Create Your Channel
|
||||
|
||||
```python
|
||||
# nanobot_channel_webhook/__init__.py
|
||||
from nanobot_channel_webhook.channel import WebhookChannel
|
||||
|
||||
__all__ = ["WebhookChannel"]
|
||||
```
|
||||
|
||||
```python
|
||||
# nanobot_channel_webhook/channel.py
|
||||
import asyncio
|
||||
from typing import Any
|
||||
|
||||
from aiohttp import web
|
||||
from loguru import logger
|
||||
from pydantic import Field
|
||||
|
||||
from nanobot.channels.base import BaseChannel
|
||||
from nanobot.bus.events import OutboundMessage
|
||||
from nanobot.bus.queue import MessageBus
|
||||
from nanobot.config.schema import Base
|
||||
|
||||
|
||||
class WebhookConfig(Base):
|
||||
"""Webhook channel configuration."""
|
||||
enabled: bool = False
|
||||
port: int = 9000
|
||||
allow_from: list[str] = Field(default_factory=list)
|
||||
|
||||
|
||||
class WebhookChannel(BaseChannel):
|
||||
name = "webhook"
|
||||
display_name = "Webhook"
|
||||
|
||||
def __init__(self, config: Any, bus: MessageBus):
|
||||
if isinstance(config, dict):
|
||||
config = WebhookConfig(**config)
|
||||
super().__init__(config, bus)
|
||||
|
||||
@classmethod
|
||||
def default_config(cls) -> dict[str, Any]:
|
||||
return WebhookConfig().model_dump(by_alias=True)
|
||||
|
||||
async def start(self) -> None:
|
||||
"""Start an HTTP server that listens for incoming messages.
|
||||
|
||||
IMPORTANT: start() must block forever (or until stop() is called).
|
||||
If it returns, the channel is considered dead.
|
||||
"""
|
||||
self._running = True
|
||||
port = self.config.port
|
||||
|
||||
app = web.Application()
|
||||
app.router.add_post("/message", self._on_request)
|
||||
runner = web.AppRunner(app)
|
||||
await runner.setup()
|
||||
site = web.TCPSite(runner, "0.0.0.0", port)
|
||||
await site.start()
|
||||
logger.info("Webhook listening on :{}", port)
|
||||
|
||||
# Block until stopped
|
||||
while self._running:
|
||||
await asyncio.sleep(1)
|
||||
|
||||
await runner.cleanup()
|
||||
|
||||
async def stop(self) -> None:
|
||||
self._running = False
|
||||
|
||||
async def send(self, msg: OutboundMessage) -> None:
|
||||
"""Deliver an outbound message.
|
||||
|
||||
msg.content — markdown text (convert to platform format as needed)
|
||||
msg.media — list of local file paths to attach
|
||||
msg.chat_id — the recipient (same chat_id you passed to _handle_message)
|
||||
msg.metadata — channel routing context such as message/thread ids
|
||||
msg.event — typed runtime event for progress/status messages
|
||||
"""
|
||||
logger.info("[webhook] -> {}: {}", msg.chat_id, msg.content[:80])
|
||||
# In a real plugin: POST to a callback URL, send via SDK, etc.
|
||||
|
||||
async def _on_request(self, request: web.Request) -> web.Response:
|
||||
"""Handle an incoming HTTP POST."""
|
||||
body = await request.json()
|
||||
sender = body.get("sender", "unknown")
|
||||
chat_id = body.get("chat_id", sender)
|
||||
text = body.get("text", "")
|
||||
media = body.get("media", []) # list of URLs
|
||||
|
||||
# This is the key call: validates allowFrom, then puts the
|
||||
# message onto the bus for the agent to process.
|
||||
await self._handle_message(
|
||||
sender_id=sender,
|
||||
chat_id=chat_id,
|
||||
content=text,
|
||||
media=media,
|
||||
)
|
||||
|
||||
return web.json_response({"ok": True})
|
||||
```
|
||||
|
||||
### 2. Register the Entry Point
|
||||
|
||||
```toml
|
||||
# pyproject.toml
|
||||
[project]
|
||||
name = "nanobot-channel-webhook"
|
||||
version = "0.1.0"
|
||||
dependencies = ["nanobot-ai", "aiohttp"]
|
||||
|
||||
[project.entry-points."nanobot.channels"]
|
||||
webhook = "nanobot_channel_webhook:WebhookChannel"
|
||||
|
||||
[build-system]
|
||||
requires = ["hatchling"]
|
||||
build-backend = "hatchling.build"
|
||||
|
||||
[tool.hatch.build.targets.wheel]
|
||||
packages = ["nanobot_channel_webhook"]
|
||||
```
|
||||
|
||||
The key (`webhook`) becomes the config section name. The value points to your `BaseChannel` subclass.
|
||||
|
||||
### 3. Install & Configure
|
||||
|
||||
```bash
|
||||
python -m pip install -e .
|
||||
nanobot plugins list # verify the installed example plugin appears as "webhook"
|
||||
nanobot onboard # auto-adds default config for detected plugins
|
||||
```
|
||||
|
||||
Edit `~/.nanobot/config.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"webhook": {
|
||||
"enabled": true,
|
||||
"port": 9000,
|
||||
"allowFrom": ["*"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 4. Run & Test
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
In another terminal:
|
||||
|
||||
```bash
|
||||
curl -X POST http://localhost:9000/message \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{"sender": "user1", "chat_id": "user1", "text": "Hello!"}'
|
||||
```
|
||||
|
||||
The agent receives the message and processes it. Replies arrive in your `send()` method.
|
||||
|
||||
## BaseChannel API
|
||||
|
||||
### Required (abstract)
|
||||
|
||||
| Method | Description |
|
||||
|--------|-------------|
|
||||
| `async start()` | **Must block forever.** Connect to platform, listen for messages, call `_handle_message()` on each. If this returns, the channel is dead. |
|
||||
| `async stop()` | Set `self._running = False` and clean up. Called when gateway shuts down. |
|
||||
| `async send(msg: OutboundMessage)` | Deliver an outbound message to the platform. |
|
||||
|
||||
### Interactive Login
|
||||
|
||||
If your channel requires interactive authentication (e.g. QR code scan), override `login(force=False)`:
|
||||
|
||||
```python
|
||||
async def login(self, force: bool = False) -> bool:
|
||||
"""
|
||||
Perform channel-specific interactive login.
|
||||
|
||||
Args:
|
||||
force: If True, ignore existing credentials and re-authenticate.
|
||||
|
||||
Returns True if already authenticated or login succeeds.
|
||||
"""
|
||||
# For QR-code-based login:
|
||||
# 1. If force, clear saved credentials
|
||||
# 2. Check if already authenticated (load from disk/state)
|
||||
# 3. If not, show QR code and poll for confirmation
|
||||
# 4. Save token on success
|
||||
```
|
||||
|
||||
Channels that don't need interactive login (e.g. Telegram with bot token, Discord with bot token) inherit the default `login()` which just returns `True`.
|
||||
|
||||
Users trigger interactive login via:
|
||||
```bash
|
||||
nanobot channels login <channel_name>
|
||||
nanobot channels login <channel_name> --force # re-authenticate
|
||||
```
|
||||
|
||||
### Provided by Base
|
||||
|
||||
| Method / Property | Description |
|
||||
|-------------------|-------------|
|
||||
| `_handle_message(sender_id, chat_id, content, media?, metadata?, session_key?)` | **Call this when you receive a message.** Checks `is_allowed()`, then publishes to the bus. Automatically sets `_wants_stream` if `supports_streaming` is true. |
|
||||
| `is_allowed(sender_id)` | Checks against `config.allow_from`; `"*"` allows all, `[]` denies all. |
|
||||
| `default_config()` (classmethod) | Returns default config dict for `nanobot onboard`. Override to declare your fields. |
|
||||
| `transcribe_audio(file_path)` | Transcribes audio via the shared top-level `transcription` config (if configured). |
|
||||
| `supports_streaming` (property) | `True` when config has `"streaming": true` **and** subclass overrides `send_delta()`. |
|
||||
| `is_running` | Returns `self._running`. |
|
||||
| `login(force=False)` | Perform interactive login (e.g. QR code scan). Returns `True` if already authenticated or login succeeds. Override in subclasses that support interactive login. |
|
||||
| `send_reasoning_delta(chat_id, delta, metadata?, *, stream_id?)` | Optional hook for streamed model reasoning/thinking content. Default is no-op. |
|
||||
| `send_reasoning_end(chat_id, metadata?, *, stream_id?)` | Optional hook marking the end of a reasoning block. Default is no-op. |
|
||||
| `send_reasoning(msg)` | Optional one-shot reasoning fallback. Default translates to `send_reasoning_delta()` + `send_reasoning_end()`. |
|
||||
|
||||
### Optional (streaming)
|
||||
|
||||
| Method | Description |
|
||||
|--------|-------------|
|
||||
| `async send_delta(chat_id, delta, metadata?, *, stream_id?, stream_end=False, resuming=False)` | Override to receive streaming chunks. See [Streaming Support](#streaming-support) for details. |
|
||||
|
||||
### Message Types
|
||||
|
||||
```python
|
||||
@dataclass
|
||||
class OutboundMessage:
|
||||
channel: str # your channel name
|
||||
chat_id: str # recipient (same value you passed to _handle_message)
|
||||
content: str # markdown text — convert to platform format as needed
|
||||
media: list[str] # local file paths to attach (images, audio, docs)
|
||||
metadata: dict # channel routing context, e.g. "message_id" for threading
|
||||
event: object | None # typed runtime/UI event; usually inspect with isinstance()
|
||||
```
|
||||
|
||||
Runtime/UI semantics live on `msg.event`. Plugin-authored outbound messages should use typed events instead of legacy metadata flags such as `_progress`, `_stream_delta`, `_stream_end`, `_reasoning_delta`, `_turn_end`, or `_goal_status`. nanobot still accepts those old flags as a compatibility bridge for existing in-process extensions, but new plugin code should not add fresh dependencies on them.
|
||||
|
||||
## Streaming Support
|
||||
|
||||
Channels can opt into real-time streaming — the agent sends content token-by-token instead of one final message. This is entirely optional; channels work fine without it.
|
||||
|
||||
### How It Works
|
||||
|
||||
When **both** conditions are met, the agent streams content through your channel:
|
||||
|
||||
1. Config has `"streaming": true`
|
||||
2. Your subclass overrides `send_delta()`
|
||||
|
||||
If either is missing, the agent falls back to the normal one-shot `send()` path.
|
||||
|
||||
### Implementing `send_delta`
|
||||
|
||||
Override `send_delta` to handle two types of calls:
|
||||
|
||||
```python
|
||||
async def send_delta(
|
||||
self,
|
||||
chat_id: str,
|
||||
delta: str,
|
||||
metadata: dict[str, Any] | None = None,
|
||||
*,
|
||||
stream_id: str | None = None,
|
||||
stream_end: bool = False,
|
||||
resuming: bool = False,
|
||||
) -> None:
|
||||
buffer_key = stream_id or chat_id
|
||||
if stream_end:
|
||||
# Streaming finished — do final formatting, cleanup, etc.
|
||||
return
|
||||
|
||||
# Regular delta — append text, update the message on screen
|
||||
# delta contains a small chunk of text (a few tokens)
|
||||
```
|
||||
|
||||
Streaming state is passed through keyword-only arguments, not `_stream_delta` or `_stream_end` metadata flags. Use `stream_id` to key any per-stream buffers; fall back to `chat_id` when it is missing.
|
||||
|
||||
### Example: Webhook with Streaming
|
||||
|
||||
```python
|
||||
class WebhookChannel(BaseChannel):
|
||||
name = "webhook"
|
||||
display_name = "Webhook"
|
||||
|
||||
def __init__(self, config: Any, bus: MessageBus):
|
||||
if isinstance(config, dict):
|
||||
config = WebhookConfig(**config)
|
||||
super().__init__(config, bus)
|
||||
self._buffers: dict[str, str] = {}
|
||||
|
||||
async def send_delta(
|
||||
self,
|
||||
chat_id: str,
|
||||
delta: str,
|
||||
metadata: dict[str, Any] | None = None,
|
||||
*,
|
||||
stream_id: str | None = None,
|
||||
stream_end: bool = False,
|
||||
resuming: bool = False,
|
||||
) -> None:
|
||||
buffer_key = stream_id or chat_id
|
||||
if stream_end:
|
||||
text = self._buffers.pop(buffer_key, "")
|
||||
# Final delivery — format and send the complete message
|
||||
await self._deliver(chat_id, text, final=True)
|
||||
return
|
||||
|
||||
self._buffers.setdefault(buffer_key, "")
|
||||
self._buffers[buffer_key] += delta
|
||||
# Incremental update — push partial text to the client
|
||||
await self._deliver(chat_id, self._buffers[buffer_key], final=False)
|
||||
|
||||
async def send(self, msg: OutboundMessage) -> None:
|
||||
# Non-streaming path — unchanged
|
||||
await self._deliver(msg.chat_id, msg.content, final=True)
|
||||
```
|
||||
|
||||
### Config
|
||||
|
||||
Enable streaming per channel:
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"webhook": {
|
||||
"enabled": true,
|
||||
"streaming": true,
|
||||
"allowFrom": ["*"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
When `streaming` is `false` (default) or omitted, only `send()` is called — no streaming overhead.
|
||||
|
||||
### BaseChannel Streaming API
|
||||
|
||||
| Method / Property | Description |
|
||||
|-------------------|-------------|
|
||||
| `async send_delta(chat_id, delta, metadata?, *, stream_id?, stream_end=False, resuming=False)` | Override to handle streaming chunks. No-op by default. |
|
||||
| `supports_streaming` (property) | Returns `True` when config has `streaming: true` **and** subclass overrides `send_delta`. |
|
||||
|
||||
## Progress, Tool Hints, and Reasoning
|
||||
|
||||
Besides normal assistant text, nanobot can emit low-emphasis trace blocks. These are intended for UI affordances like status rows, collapsible "used tools" groups, or reasoning/thinking blocks. Platforms that do not have a good place for them can ignore them safely.
|
||||
|
||||
### Progress and Tool Hints
|
||||
|
||||
Progress and tool hints arrive through the normal `send(msg)` path. Check `msg.event` before rendering:
|
||||
|
||||
```python
|
||||
from nanobot.bus.outbound_events import ProgressEvent
|
||||
|
||||
async def send(self, msg: OutboundMessage) -> None:
|
||||
event = msg.event
|
||||
|
||||
if isinstance(event, ProgressEvent) and event.tool_hint:
|
||||
# A short tool breadcrumb, e.g. read_file("config.json")
|
||||
await self._send_trace(msg.chat_id, msg.content, kind="tool")
|
||||
return
|
||||
|
||||
if isinstance(event, ProgressEvent):
|
||||
# Generic non-final status, e.g. "Thinking..." or "Running command..."
|
||||
await self._send_trace(msg.chat_id, msg.content, kind="progress")
|
||||
return
|
||||
|
||||
await self._send_message(msg.chat_id, msg.content, media=msg.media)
|
||||
```
|
||||
|
||||
Tool hints are off by default for most channels. Users can enable them globally or per channel:
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"sendToolHints": true,
|
||||
"webhook": {
|
||||
"enabled": true,
|
||||
"sendToolHints": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Reasoning Blocks
|
||||
|
||||
Reasoning is delivered through dedicated optional hooks, not `send()`. Override `send_reasoning_delta()` and `send_reasoning_end()` if your platform can show model reasoning as a subdued/collapsible block. The default implementation is a no-op, so unsupported channels simply drop reasoning content.
|
||||
|
||||
```python
|
||||
class WebhookChannel(BaseChannel):
|
||||
name = "webhook"
|
||||
display_name = "Webhook"
|
||||
|
||||
def __init__(self, config: Any, bus: MessageBus):
|
||||
if isinstance(config, dict):
|
||||
config = WebhookConfig(**config)
|
||||
super().__init__(config, bus)
|
||||
self._reasoning_buffers: dict[str, str] = {}
|
||||
|
||||
async def send_reasoning_delta(
|
||||
self,
|
||||
chat_id: str,
|
||||
delta: str,
|
||||
metadata: dict[str, Any] | None = None,
|
||||
*,
|
||||
stream_id: str | None = None,
|
||||
) -> None:
|
||||
buffer_key = stream_id or chat_id
|
||||
self._reasoning_buffers[buffer_key] = self._reasoning_buffers.get(buffer_key, "") + delta
|
||||
await self._update_reasoning_block(chat_id, self._reasoning_buffers[buffer_key], final=False)
|
||||
|
||||
async def send_reasoning_end(
|
||||
self,
|
||||
chat_id: str,
|
||||
metadata: dict[str, Any] | None = None,
|
||||
*,
|
||||
stream_id: str | None = None,
|
||||
) -> None:
|
||||
buffer_key = stream_id or chat_id
|
||||
text = self._reasoning_buffers.pop(buffer_key, "")
|
||||
if text:
|
||||
await self._update_reasoning_block(chat_id, text, final=True)
|
||||
```
|
||||
|
||||
**Reasoning arguments:**
|
||||
|
||||
| Argument | Meaning |
|
||||
|------|---------|
|
||||
| `delta` | A reasoning/thinking chunk for `send_reasoning_delta()`. |
|
||||
| `stream_id` | Stable id for this assistant turn/segment. Use it to key buffers instead of only `chat_id`. |
|
||||
| `send_reasoning_end()` | The current reasoning block is complete. |
|
||||
|
||||
Reasoning visibility is controlled by `showReasoning` globally or per channel:
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"showReasoning": true,
|
||||
"webhook": {
|
||||
"enabled": true,
|
||||
"showReasoning": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Recommended rendering:
|
||||
|
||||
- Render tool hints and progress as trace/status UI, not as normal assistant replies.
|
||||
- Render reasoning with lower visual emphasis and collapse it after completion when the platform supports that.
|
||||
- Keep reasoning separate from final answer text. A final answer still arrives through `send()` or `send_delta()`.
|
||||
|
||||
## Config
|
||||
|
||||
### Why Pydantic model is required
|
||||
|
||||
`BaseChannel.is_allowed()` reads the permission list via `getattr(self.config, "allow_from", [])`. This works for Pydantic models where `allow_from` is a real Python attribute, but **fails silently for plain `dict`** — `dict` has no `allow_from` attribute, so `getattr` always returns the default `[]`, causing all messages to be denied.
|
||||
|
||||
Built-in channels use Pydantic config models (subclassing `Base` from `nanobot.config.schema`). Plugin channels **must do the same**.
|
||||
|
||||
### Pattern
|
||||
|
||||
1. Define a Pydantic model inheriting from `nanobot.config.schema.Base`:
|
||||
|
||||
```python
|
||||
from pydantic import Field
|
||||
from nanobot.config.schema import Base
|
||||
|
||||
class WebhookConfig(Base):
|
||||
"""Webhook channel configuration."""
|
||||
enabled: bool = False
|
||||
port: int = 9000
|
||||
allow_from: list[str] = Field(default_factory=list)
|
||||
```
|
||||
|
||||
`Base` is configured with `alias_generator=to_camel` and `populate_by_name=True`, so JSON keys like `"allowFrom"` and `"allow_from"` are both accepted.
|
||||
|
||||
2. Convert `dict` → model in `__init__`:
|
||||
|
||||
```python
|
||||
from typing import Any
|
||||
from nanobot.bus.queue import MessageBus
|
||||
|
||||
class WebhookChannel(BaseChannel):
|
||||
def __init__(self, config: Any, bus: MessageBus):
|
||||
if isinstance(config, dict):
|
||||
config = WebhookConfig(**config)
|
||||
super().__init__(config, bus)
|
||||
```
|
||||
|
||||
3. Access config as attributes (not `.get()`):
|
||||
|
||||
```python
|
||||
async def start(self) -> None:
|
||||
port = self.config.port
|
||||
token = self.config.token
|
||||
```
|
||||
|
||||
`allowFrom` is handled automatically by `_handle_message()` — you don't need to check it yourself.
|
||||
|
||||
Override `default_config()` so `nanobot onboard` auto-populates `config.json`:
|
||||
|
||||
```python
|
||||
@classmethod
|
||||
def default_config(cls) -> dict[str, Any]:
|
||||
return WebhookConfig().model_dump(by_alias=True)
|
||||
```
|
||||
|
||||
> **Note:** `default_config()` returns a plain `dict` (not a Pydantic model) because it's used to serialize into `config.json`. The recommended way is to instantiate your config model and call `model_dump(by_alias=True)` — this automatically uses camelCase keys (`allowFrom`) and keeps defaults in a single source of truth.
|
||||
|
||||
If not overridden, the base class returns `{"enabled": false}`.
|
||||
|
||||
## Naming Convention
|
||||
|
||||
| What | Format | Example |
|
||||
|------|--------|---------|
|
||||
| PyPI package | `nanobot-channel-{name}` | `nanobot-channel-webhook` |
|
||||
| Entry point key | `{name}` | `webhook` |
|
||||
| Config section | `channels.{name}` | `channels.webhook` |
|
||||
| Python package | `nanobot_channel_{name}` | `nanobot_channel_webhook` |
|
||||
|
||||
## Local Development
|
||||
|
||||
```bash
|
||||
git clone https://github.com/you/nanobot-channel-webhook
|
||||
cd nanobot-channel-webhook
|
||||
python -m pip install -e .
|
||||
nanobot plugins list # should show the installed example plugin as "webhook"
|
||||
nanobot gateway # test end-to-end
|
||||
```
|
||||
|
||||
## Verify
|
||||
|
||||
```bash
|
||||
$ nanobot plugins list
|
||||
|
||||
Name Type Enabled
|
||||
discord channel no
|
||||
telegram channel yes
|
||||
webhook channel yes
|
||||
```
|
||||
@@ -0,0 +1,978 @@
|
||||
# Chat Apps for Self-Hosted AI Agents
|
||||
|
||||
Connect nanobot to Telegram, Discord, Slack, WeChat, Email, Mattermost, and
|
||||
other chat platforms. This page is the full chat-channel reference. If you want
|
||||
a focused setup path for one platform, start with a guide:
|
||||
|
||||
| Platform | Guide |
|
||||
|---|---|
|
||||
| Telegram | [Build a Telegram AI Agent with nanobot](./guides/telegram-ai-agent.md) |
|
||||
| Discord | [Build a Discord AI Agent with nanobot](./guides/discord-ai-agent.md) |
|
||||
| Slack | [Build a Slack AI Agent with nanobot](./guides/slack-ai-agent.md) |
|
||||
| Feishu | [Build a Feishu AI Agent with nanobot](./guides/feishu-ai-agent.md) |
|
||||
| WhatsApp | [Build a WhatsApp AI Agent with nanobot](./guides/whatsapp-ai-agent.md) |
|
||||
| WeChat | [Build a WeChat AI Agent with nanobot](./guides/wechat-ai-agent.md) |
|
||||
| QQ | [Build a QQ AI Agent with nanobot](./guides/qq-ai-agent.md) |
|
||||
| Email | [Build an Email AI Agent with nanobot](./guides/email-ai-agent.md) |
|
||||
| Mattermost | [Build a Mattermost AI Agent with nanobot](./guides/mattermost-ai-agent.md) |
|
||||
|
||||
Want to build your own channel? See the [Channel Plugin Guide](./channel-plugin-guide.md).
|
||||
|
||||
Before configuring a chat app, make sure the local CLI path works:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
If that fails, fix installation, config, provider, or model setup first with [`quick-start.md`](./quick-start.md), [`providers.md`](./providers.md), and [`troubleshooting.md`](./troubleshooting.md). Chat apps require `nanobot gateway` to stay running after the channel is configured.
|
||||
|
||||
Most examples below are snippets to merge into `~/.nanobot/config.json`. When a
|
||||
snippet includes `allowFrom`, it is showing a static allowlist. For
|
||||
pairing-based access on supported channels, omit `allowFrom`; Slack and
|
||||
Mattermost also need `dm.policy` set to `"allowlist"` for DMs to issue pairing
|
||||
codes.
|
||||
|
||||
> [!NOTE]
|
||||
> If you are upgrading from a version where chat app SDKs were installed by default,
|
||||
> install the channel extra in the same Python environment before enabling or
|
||||
> restarting that channel:
|
||||
>
|
||||
> ```bash
|
||||
> nanobot plugins enable <channel>
|
||||
> ```
|
||||
>
|
||||
> Replace `<channel>` with names such as `telegram`, `slack`, `feishu`,
|
||||
> `dingtalk`, `matrix`, `qq`, `napcat`, `weixin`, `wecom`, or `msteams`.
|
||||
> To turn a channel off later, run `nanobot plugins disable <channel>`.
|
||||
> nanobot keeps the saved settings, but stops loading that channel after the
|
||||
> next restart.
|
||||
|
||||
## Common Setup Pattern
|
||||
|
||||
Every chat app uses the same shape:
|
||||
|
||||
1. Create or prepare the bot/account in the chat platform.
|
||||
2. Copy the token, secret, QR login state, webhook URL, or account ID that platform gives you.
|
||||
3. Merge that platform's JSON snippet into `~/.nanobot/config.json`.
|
||||
4. Prefer pairing for DM-capable channels: omit `allowFrom`, let the first DM receive a pairing code, then approve it with `/pairing approve <code>`.
|
||||
5. For channels without pairing, such as Email, keep access narrow with `allowFrom` or the platform-specific allow list.
|
||||
6. Check that nanobot can see the configured channel:
|
||||
|
||||
```bash
|
||||
nanobot channels status
|
||||
```
|
||||
|
||||
7. Start the gateway and leave that terminal running:
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
8. Send a test DM. If the bot returns a pairing code, approve it and send the message again. In group chats, follow that channel's `groupPolicy` behavior: many channels default to mention-only, while Matrix and WhatsApp default to open group replies.
|
||||
|
||||
If `nanobot channels status` does not show the channel as enabled, the config snippet is in the wrong place, the channel name is misspelled, or the config file you edited is not the one nanobot is reading. If the channel is enabled but messages do not arrive, run `nanobot gateway --verbose` and compare the platform-side credentials, event permissions, and allow lists.
|
||||
|
||||
> `allowFrom: ["*"]` bypasses pairing and allows anyone who can reach that channel to talk to the bot. Use it only when that is intentional, or temporarily while testing in a private sandbox.
|
||||
|
||||
| Channel | What you need |
|
||||
|---------|---------------|
|
||||
| **Telegram** | Bot token from @BotFather |
|
||||
| **Discord** | Bot token + Message Content intent |
|
||||
| **WhatsApp** | QR code scan (`nanobot channels login whatsapp`) |
|
||||
| **WeChat (Weixin)** | QR code scan (`nanobot channels login weixin`) |
|
||||
| **Feishu** | QR code scan (`nanobot channels login feishu`) or App ID + App Secret |
|
||||
| **DingTalk** | App Key + App Secret |
|
||||
| **Slack** | Bot token + App-Level token |
|
||||
| **Matrix** | Homeserver URL + Access token |
|
||||
| **Email** | IMAP/SMTP credentials |
|
||||
| **QQ** | App ID + App Secret |
|
||||
| **Napcat (QQ)** | Napcat Forward WebSocket URL + access token |
|
||||
| **Wecom** | Bot ID + Bot Secret |
|
||||
| **Microsoft Teams** | App ID + App Password + public HTTPS endpoint |
|
||||
| **Mochat** | Claw token (auto-setup available) |
|
||||
| **Signal** | signal-cli daemon + phone number |
|
||||
|
||||
<details>
|
||||
<summary><b>Telegram</b></summary>
|
||||
|
||||
**Install the optional channel dependency**
|
||||
|
||||
```bash
|
||||
nanobot plugins enable telegram
|
||||
```
|
||||
|
||||
**1. Create a bot**
|
||||
- Open Telegram, search `@BotFather`
|
||||
- Send `/newbot`, follow prompts
|
||||
- Copy the token
|
||||
|
||||
**2. Configure**
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"telegram": {
|
||||
"enabled": true,
|
||||
"token": "YOUR_BOT_TOKEN",
|
||||
"allowFrom": ["YOUR_USER_ID"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> You can find your **User ID** in Telegram settings. It is shown as `@yourUserId`. Copy this value **without the `@` symbol** and paste it into the config file.
|
||||
>
|
||||
> `richMessages` defaults to `false`. Set it to `true` only if your Telegram client supports Bot API 10.1 rich messages and you want richer markdown rendering; keep it disabled for Telegram Web, which may show unsupported-message errors for rich messages.
|
||||
|
||||
|
||||
**3. Run**
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
**Webhook mode (optional)**
|
||||
|
||||
Telegram uses long polling by default. To receive updates through a webhook, expose a public HTTPS URL that forwards to nanobot's local listener and set `mode` to `webhook`:
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"telegram": {
|
||||
"enabled": true,
|
||||
"token": "YOUR_BOT_TOKEN",
|
||||
"mode": "webhook",
|
||||
"webhookUrl": "https://example.com/telegram",
|
||||
"webhookListenHost": "127.0.0.1",
|
||||
"webhookListenPort": 8081,
|
||||
"webhookPath": "/telegram",
|
||||
"webhookSecretToken": "CHANGE_ME_RANDOM_SECRET",
|
||||
"webhookMaxConnections": 4,
|
||||
"allowFrom": ["YOUR_USER_ID"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> `webhookSecretToken` is required in webhook mode. Do not expose the local webhook listener directly to the public internet without a reverse proxy or tunnel in front of it. TLS/Host policy is handled by your proxy; nanobot only listens on `webhookListenHost:webhookListenPort` and validates Telegram's webhook secret token. `webhookMaxConnections` defaults to `4`; nanobot still serializes Telegram updates per conversation before forwarding them to the agent.
|
||||
>
|
||||
> `webhookUrl` is the public HTTPS URL registered with Telegram. `webhookPath` is the local path nanobot listens on. They often use the same path, but may differ when a reverse proxy or tunnel rewrites the request path.
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>Mochat (Claw IM)</b></summary>
|
||||
|
||||
Uses **Socket.IO WebSocket** by default, with HTTP polling fallback.
|
||||
|
||||
**Install the optional realtime dependency**
|
||||
|
||||
```bash
|
||||
nanobot plugins enable mochat
|
||||
```
|
||||
|
||||
Without this extra, Mochat still works through HTTP polling.
|
||||
|
||||
**1. Ask nanobot to set up Mochat for you**
|
||||
|
||||
Simply send this message to nanobot (replace `xxx@xxx` with your real email):
|
||||
|
||||
```
|
||||
Read https://raw.githubusercontent.com/HKUDS/MoChat/refs/heads/main/skills/nanobot/skill.md and register on MoChat. My Email account is xxx@xxx Bind me as your owner and DM me on MoChat.
|
||||
```
|
||||
|
||||
nanobot will automatically register, configure `~/.nanobot/config.json`, and connect to Mochat.
|
||||
|
||||
**2. Restart gateway**
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
That's it — nanobot handles the rest!
|
||||
|
||||
<br>
|
||||
|
||||
<details>
|
||||
<summary>Manual configuration (advanced)</summary>
|
||||
|
||||
If you prefer to configure manually, add the following to `~/.nanobot/config.json`:
|
||||
|
||||
> Keep `claw_token` private. It should only be sent in `X-Claw-Token` header to your Mochat API endpoint.
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"mochat": {
|
||||
"enabled": true,
|
||||
"base_url": "https://mochat.io",
|
||||
"socket_url": "https://mochat.io",
|
||||
"socket_path": "/socket.io",
|
||||
"claw_token": "claw_xxx",
|
||||
"agent_user_id": "6982abcdef",
|
||||
"sessions": ["*"],
|
||||
"panels": ["*"],
|
||||
"reply_delay_mode": "non-mention",
|
||||
"reply_delay_ms": 120000
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
|
||||
</details>
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>Discord</b></summary>
|
||||
|
||||
**1. Create a bot**
|
||||
- Go to https://discord.com/developers/applications
|
||||
- Create an application → Bot → Add Bot
|
||||
- Copy the bot token
|
||||
|
||||
**2. Enable intents**
|
||||
- In the Bot settings, enable **MESSAGE CONTENT INTENT**
|
||||
- (Optional) Enable **SERVER MEMBERS INTENT** if you plan to use allow lists based on member data
|
||||
|
||||
**3. Get your User ID**
|
||||
- Discord Settings → Advanced → enable **Developer Mode**
|
||||
- Right-click your avatar → **Copy User ID**
|
||||
|
||||
**4. Configure**
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"discord": {
|
||||
"enabled": true,
|
||||
"token": "YOUR_BOT_TOKEN",
|
||||
"allowFrom": ["YOUR_USER_ID"],
|
||||
"allowChannels": [],
|
||||
"groupPolicy": "mention",
|
||||
"streaming": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> `groupPolicy` controls how the bot responds in group channels:
|
||||
> - `"mention"` (default) — Only respond when @mentioned
|
||||
> - `"open"` — Respond to all messages
|
||||
> DMs always respond when the sender is in `allowFrom`.
|
||||
> - If you set group policy to open create new threads as private threads and then @ the bot into it. Otherwise the thread itself and the channel in which you spawned it will spawn a bot session.
|
||||
> `allowChannels` restricts the bot to specific Discord channel IDs. Empty (default) means respond in every channel the bot can see. Example: `["1234567890", "0987654321"]`. The filter applies after `allowFrom`, so both must pass. Discord threads under an allowed parent channel are also allowed; for Forum channels, allowing the parent Forum channel allows all threads/posts in that forum.
|
||||
> `streaming` defaults to `true`. Disable it only if you explicitly want non-streaming replies.
|
||||
|
||||
**5. Invite the bot**
|
||||
- OAuth2 → URL Generator
|
||||
- Scopes: `bot`
|
||||
- Bot Permissions: `Send Messages`, `Read Message History`
|
||||
- Open the generated invite URL and add the bot to your server
|
||||
|
||||
**6. Run**
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>Matrix (Element)</b></summary>
|
||||
|
||||
Enable Matrix support first:
|
||||
|
||||
```bash
|
||||
nanobot plugins enable matrix
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> Matrix encryption is disabled by default on Windows because `matrix-nio[e2e]` depends on `python-olm`, which has no pre-built Windows wheel. Use macOS, Linux, or WSL2 if you need Matrix E2EE.
|
||||
|
||||
**1. Create/choose a Matrix account**
|
||||
|
||||
- Create or reuse a Matrix account on your homeserver (for example `matrix.org`).
|
||||
- Confirm you can log in with Element.
|
||||
|
||||
**2. Get credentials**
|
||||
|
||||
- You need:
|
||||
- `userId` (example: `@nanobot:matrix.org`)
|
||||
- `password`
|
||||
|
||||
(Note: `accessToken` and `deviceId` are still supported for legacy reasons, but for reliable encryption, password login is recommended instead. If the `password` is provided, `accessToken` and `deviceId` will be ignored.)
|
||||
|
||||
**3. Configure**
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"matrix": {
|
||||
"enabled": true,
|
||||
"homeserver": "https://matrix.org",
|
||||
"userId": "@nanobot:matrix.org",
|
||||
"password": "mypasswordhere",
|
||||
"e2eeEnabled": true,
|
||||
"sasVerification": true,
|
||||
"allowFrom": ["@your_user:matrix.org"],
|
||||
"groupPolicy": "open",
|
||||
"groupAllowFrom": [],
|
||||
"allowRoomMentions": false,
|
||||
"maxMediaBytes": 20971520
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> Keep a persistent `matrix-store` — encrypted session state is lost if these change across restarts.
|
||||
|
||||
| Option | Description |
|
||||
|--------|-------------|
|
||||
| `allowFrom` | User IDs allowed to interact. Empty denies all; use `["*"]` to allow everyone. |
|
||||
| `groupPolicy` | `open` (default), `mention`, or `allowlist`. |
|
||||
| `groupAllowFrom` | Room allowlist (used when policy is `allowlist`). |
|
||||
| `allowRoomMentions` | Accept `@room` mentions in mention mode. |
|
||||
| `e2eeEnabled` | E2EE support (default `true`). Set `false` for plaintext-only. |
|
||||
| `sasVerification` | Auto-complete SAS device verification requests from allowed users (default `false`). Useful for Element X, which does not expose manual trust for third-party devices. |
|
||||
| `maxMediaBytes` | Max attachment size (default `20MB`). Set `0` to block all media. |
|
||||
|
||||
|
||||
|
||||
|
||||
**4. Run**
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>WhatsApp</b></summary>
|
||||
|
||||
Requires the WhatsApp optional dependencies:
|
||||
|
||||
```bash
|
||||
nanobot plugins enable whatsapp
|
||||
```
|
||||
|
||||
**1. Link device with QR**
|
||||
|
||||
```bash
|
||||
nanobot channels login whatsapp
|
||||
# Scan QR with WhatsApp → Settings → Linked Devices
|
||||
```
|
||||
|
||||
**2. Configure**
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"whatsapp": {
|
||||
"enabled": true,
|
||||
"allowFrom": ["1234567890"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Optional session database path:
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"whatsapp": {
|
||||
"databasePath": "~/.nanobot/whatsapp-auth/neonize.db"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Migrating from the old bridge**
|
||||
|
||||
- Remove `bridgeUrl` and `bridgeToken`; WhatsApp no longer runs a local Node.js bridge.
|
||||
- Re-run `nanobot channels login whatsapp`; old Baileys bridge auth data is not reused by neonize.
|
||||
- Update `allowFrom` entries to the WhatsApp sender ID without a leading `+`.
|
||||
|
||||
**3. Run**
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
**Optional: static LID mappings**
|
||||
|
||||
Modern WhatsApp can deliver a sender's LID instead of their phone number. nanobot
|
||||
learns LID to phone mappings at runtime when both identifiers are present, but you
|
||||
can also seed mappings up front so the phone number resolves from the
|
||||
very first message:
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"whatsapp": {
|
||||
"enabled": true,
|
||||
"allowFrom": ["1234567890"],
|
||||
"lidMappings": { "123456789012345": "1234567890" }
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>Feishu</b></summary>
|
||||
|
||||
Uses **WebSocket** long connection — no public IP required.
|
||||
|
||||
**Quick setup: QR login**
|
||||
|
||||
```bash
|
||||
nanobot plugins enable feishu
|
||||
nanobot channels login feishu
|
||||
# Use --force to create/sign in with a new bot
|
||||
```
|
||||
|
||||
Open the printed URL or scan the QR code with Feishu/Lark on your phone. If the optional `qrcode` package is installed, nanobot shows a terminal QR code; otherwise it prints the login URL. nanobot writes `appId`, `appSecret`, `domain`, and `enabled` under `channels.feishu` in the active config file. Use `--config <path>` to update a non-default config.
|
||||
|
||||
If QR login is unavailable for your account, use manual setup below.
|
||||
|
||||
**Manual setup**
|
||||
|
||||
**1. Create a Feishu bot**
|
||||
- Visit [Feishu Open Platform](https://open.feishu.cn/app)
|
||||
- Create a new app → Enable **Bot** capability
|
||||
- **Permissions**:
|
||||
- `im:message` (send messages) and `im:message.p2p_msg:readonly` (receive messages)
|
||||
- **Streaming replies** (default in nanobot): add **`cardkit:card:write`** (often labeled **Create and update cards** in the Feishu developer console). Required for CardKit entities and streamed assistant text. Older apps may not have it yet — open **Permission management**, enable the scope, then **publish** a new app version if the console requires it.
|
||||
- If you **cannot** add `cardkit:card:write`, set `"streaming": false` under `channels.feishu` (see below). The bot still works; replies use normal interactive cards without token-by-token streaming.
|
||||
- **Events**: Add `im.message.receive_v1` (receive messages)
|
||||
- Select **Long Connection** mode (requires running nanobot first to establish connection)
|
||||
- Get **App ID** and **App Secret** from "Credentials & Basic Info"
|
||||
- Publish the app
|
||||
|
||||
**2. Configure**
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"feishu": {
|
||||
"enabled": true,
|
||||
"appId": "cli_xxx",
|
||||
"appSecret": "xxx",
|
||||
"encryptKey": "",
|
||||
"verificationToken": "",
|
||||
"allowFrom": ["ou_YOUR_OPEN_ID"],
|
||||
"groupPolicy": "mention",
|
||||
"reactEmoji": "OnIt",
|
||||
"doneEmoji": "DONE",
|
||||
"toolHintPrefix": "🔧",
|
||||
"streaming": true,
|
||||
"domain": "feishu"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> `streaming` defaults to `true`. Use `false` if your app does not have **`cardkit:card:write`** (see permissions above).
|
||||
> `encryptKey` and `verificationToken` are optional for Long Connection mode.
|
||||
> `allowFrom`: Add your open_id (find it in nanobot logs when you message the bot). Use `["*"]` to allow all users.
|
||||
> `groupPolicy`: `"mention"` (default — respond only when @mentioned), `"open"` (respond to all group messages). Private chats always respond.
|
||||
> `reactEmoji`: Emoji for "processing" status (default: `OnIt`). See [available emojis](https://open.larkoffice.com/document/server-docs/im-v1/message-reaction/emojis-introduce).
|
||||
> `doneEmoji`: Optional emoji for "completed" status (e.g., `DONE`, `OK`, `HEART`). When set, bot adds this reaction after removing `reactEmoji`.
|
||||
> `toolHintPrefix`: Prefix for inline tool hints in streaming cards (default: `🔧`).
|
||||
> `domain`: `"feishu"` (default) for China (open.feishu.cn), `"lark"` for international Lark (open.larksuite.com).
|
||||
|
||||
**3. Run**
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
> [!TIP]
|
||||
> Feishu uses WebSocket to receive messages — no webhook or public IP needed!
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>QQ (QQ单聊)</b></summary>
|
||||
|
||||
Uses **botpy SDK** with WebSocket — no public IP required. Currently supports **private messages only**.
|
||||
|
||||
**Install the optional channel dependency**
|
||||
|
||||
```bash
|
||||
nanobot plugins enable qq
|
||||
```
|
||||
|
||||
**1. Register & create bot**
|
||||
- Visit [QQ Open Platform](https://q.qq.com) → Register as a developer (personal or enterprise)
|
||||
- Create a new bot application
|
||||
- Go to **开发设置 (Developer Settings)** → copy **AppID** and **AppSecret**
|
||||
|
||||
**2. Set up sandbox for testing**
|
||||
- In the bot management console, find **沙箱配置 (Sandbox Config)**
|
||||
- Under **在消息列表配置**, click **添加成员** and add your own QQ number
|
||||
- Once added, scan the bot's QR code with mobile QQ → open the bot profile → tap "发消息" to start chatting
|
||||
|
||||
**3. Configure**
|
||||
|
||||
> - `allowFrom`: Add your openid (find it in nanobot logs when you message the bot). Use `["*"]` for public access.
|
||||
> - `msgFormat`: Optional. Use `"plain"` (default) for maximum compatibility with legacy QQ clients, or `"markdown"` for richer formatting on newer clients.
|
||||
> - For production: submit a review in the bot console and publish. See [QQ Bot Docs](https://bot.q.qq.com/wiki/) for the full publishing flow.
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"qq": {
|
||||
"enabled": true,
|
||||
"appId": "YOUR_APP_ID",
|
||||
"secret": "YOUR_APP_SECRET",
|
||||
"allowFrom": ["YOUR_OPENID"],
|
||||
"msgFormat": "plain"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**4. Run**
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
Now send a message to the bot from QQ — it should respond!
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>Napcat (QQ via OneBot v11 支持群聊等功能)</b></summary>
|
||||
|
||||
Connects to a [Napcat](https://github.com/NapNeko/NapCatQQ) instance over its **forward WebSocket** (OneBot v11). Use this when you have your own QQ account running through Napcat and want full private + group chat support.
|
||||
|
||||
**1. Set up Napcat**
|
||||
|
||||
- Install and log into Napcat, then enable a **Forward WebSocket** server. See the [official Napcat Docker tutorial](https://github.com/NapNeko/NapCat-Docker).
|
||||
- In the webui, follow "网络配置" -> "新建" -> "Websocket 服务器" to create a forward websocket server. By default, the URL is `ws://127.0.0.1:3001`
|
||||
- Copy the forward websocket server's token
|
||||
- (Optional) In the webui, follow "系统配置" -> "登陆配置" -> "快速登录QQ" to automatically login after restarts
|
||||
|
||||
**Install the optional channel dependency**
|
||||
|
||||
```bash
|
||||
nanobot plugins enable napcat
|
||||
```
|
||||
|
||||
**2. Configure**
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"napcat": {
|
||||
"enabled": true,
|
||||
"wsUrl": "ws://127.0.0.1:3001",
|
||||
"accessToken": "YOUR_WEBSOCKET_TOKEN",
|
||||
"allowFrom": ["*"],
|
||||
"groupPolicy": "mention",
|
||||
"groupPolicyOverrides": {
|
||||
"123456789": "open",
|
||||
"987654321": 0.2
|
||||
},
|
||||
"welcomeNewMembers": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
| Option | What it does |
|
||||
|--------|--------------|
|
||||
| `wsUrl` | Napcat forward-WebSocket endpoint. Bearer auth via `accessToken` is sent in the `Authorization` header. |
|
||||
| `allowFrom` | QQ numbers permitted to talk to the bot. `["*"]` = anyone. Required `["*"]` (or include the joining user) for `welcomeNewMembers` to fire. |
|
||||
| `groupPolicy` | `"mention"` (default) — reply only when @-mentioned or replying to the bot's own message. `"open"` — reply to every group message. A float `p` in `[0.0, 1.0]` — @mentions and replies-to-bot always reply; every other group message replies with probability `p` (so `0.0` ≡ `"mention"`, `1.0` ≡ `"open"`). Private chats always reply. |
|
||||
| `groupPolicyOverrides` | Optional per-group overrides for `groupPolicy`, keyed by group id (as a string). Each value takes the same shape as `groupPolicy` (`"mention"`, `"open"`, or a float). Groups not listed fall back to `groupPolicy`. |
|
||||
| `welcomeNewMembers` | When true, `notice.group_increase` events are pushed to the bus as a synthetic message so the agent can greet new joiners. |
|
||||
| `maxImageBytes` | Hard cap (in bytes) for inbound image downloads. Defaults to 20 MB. Larger images are dropped with a warning. |
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>DingTalk (钉钉)</b></summary>
|
||||
|
||||
Uses **Stream Mode** — no public IP required.
|
||||
|
||||
**Install the optional channel dependency**
|
||||
|
||||
```bash
|
||||
nanobot plugins enable dingtalk
|
||||
```
|
||||
|
||||
**1. Create a DingTalk bot**
|
||||
- Visit [DingTalk Open Platform](https://open-dev.dingtalk.com/)
|
||||
- Create a new app -> Add **Robot** capability
|
||||
- **Configuration**:
|
||||
- Toggle **Stream Mode** ON
|
||||
- **Permissions**: Add necessary permissions for sending messages
|
||||
- Get **AppKey** (Client ID) and **AppSecret** (Client Secret) from "Credentials"
|
||||
- Publish the app
|
||||
|
||||
**2. Configure**
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"dingtalk": {
|
||||
"enabled": true,
|
||||
"clientId": "YOUR_APP_KEY",
|
||||
"clientSecret": "YOUR_APP_SECRET",
|
||||
"allowFrom": ["YOUR_STAFF_ID"],
|
||||
"groupUserIsolation": false
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> `allowFrom`: Add your staff ID. Use `["*"]` to allow all users.
|
||||
>
|
||||
> `groupUserIsolation`: Optional. Defaults to `false`, which keeps one shared session per group chat. Set it to `true` to give each sender in a DingTalk group chat a separate session while replies still go back to the same group.
|
||||
|
||||
**3. Run**
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>Slack</b></summary>
|
||||
|
||||
Uses **Socket Mode** — no public URL required.
|
||||
|
||||
**Install the optional channel dependency**
|
||||
|
||||
```bash
|
||||
nanobot plugins enable slack
|
||||
```
|
||||
|
||||
**1. Create a Slack app**
|
||||
- Go to [Slack API](https://api.slack.com/apps) → **Create New App** → "From scratch"
|
||||
- Pick a name and select your workspace
|
||||
|
||||
**2. Configure the app**
|
||||
- **Socket Mode**: Toggle ON → Generate an **App-Level Token** with `connections:write` scope → copy it (`xapp-...`)
|
||||
- **OAuth & Permissions**: Add bot scopes: `chat:write`, `reactions:write`, `app_mentions:read`, `files:read`, `files:write`, `channels:history`, `groups:history`, `im:history`, `mpim:history`
|
||||
- **Event Subscriptions**: Toggle ON → Subscribe to bot events: `message.im`, `message.channels`, `app_mention` → Save Changes
|
||||
- **App Home**: Scroll to **Show Tabs** → Enable **Messages Tab** → Check **"Allow users to send Slash commands and messages from the messages tab"**
|
||||
- **Install App**: Click **Install to Workspace** → Authorize → copy the **Bot Token** (`xoxb-...`)
|
||||
|
||||
> `files:read` is required to read files users send to nanobot. `files:write` is required for nanobot to send images, videos, and other file uploads. If you add either scope later, reinstall the Slack app to the workspace and restart nanobot so it uses the updated bot token.
|
||||
|
||||
**3. Configure nanobot**
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"slack": {
|
||||
"enabled": true,
|
||||
"botToken": "xoxb-...",
|
||||
"appToken": "xapp-...",
|
||||
"allowFrom": ["YOUR_SLACK_USER_ID"],
|
||||
"groupPolicy": "mention"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**4. Run**
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
DM the bot directly or @mention it in a channel — it should respond!
|
||||
|
||||
> [!TIP]
|
||||
> - `groupPolicy`: `"mention"` (default — respond only when @mentioned), `"open"` (respond to all channel messages), or `"allowlist"` (restrict to specific channels via `groupAllowFrom`).
|
||||
> - `groupAllowFrom`: channel IDs the bot may respond in when `groupPolicy` is `"allowlist"`.
|
||||
> - `groupRequireMention`: when `true` and `groupPolicy` is `"allowlist"`, the bot only replies to channels in `groupAllowFrom` **and** only when @mentioned (instead of every message). No effect for `"mention"`/`"open"`. Use this to scope the bot to approved channels while keeping mention-only behavior.
|
||||
> - DM policy defaults to open. Set `"dm": {"enabled": false}` to disable DMs.
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>Email</b></summary>
|
||||
|
||||
Give nanobot its own email account. It polls **IMAP** for incoming mail and replies via **SMTP** — like a personal email assistant.
|
||||
|
||||
**1. Get credentials (Gmail example)**
|
||||
- Create a dedicated Gmail account for your bot (e.g. `my-nanobot@gmail.com`)
|
||||
- Enable 2-Step Verification → Create an [App Password](https://myaccount.google.com/apppasswords)
|
||||
- Use this app password for both IMAP and SMTP
|
||||
|
||||
**2. Configure**
|
||||
|
||||
> - `consentGranted` must be `true` to allow mailbox access. This is a safety gate — set `false` to fully disable.
|
||||
> - `allowFrom`: Add your email address. Use `["*"]` to accept emails from anyone.
|
||||
> - `smtpUseTls` and `smtpUseSsl` default to `true` / `false` respectively, which is correct for Gmail (port 587 + STARTTLS). No need to set them explicitly.
|
||||
> - Set `"autoReplyEnabled": false` if you only want to read/analyze emails without sending automatic replies.
|
||||
> - `postAction`: Optional post-processing for processed emails: `"delete"` or `"move"` (default `null`).
|
||||
> This runs only after an accepted email is successfully delivered to the AI pipeline.
|
||||
> - `postActionMoveMailbox`: Destination mailbox used when `postAction` is `"move"` (for example `"Processed"` or `"[Gmail]/Trash"`).
|
||||
> - `postActionIgnoreSkipped`: If `true` (default), skipped emails are ignored for post-action and not moved/deleted.
|
||||
> - `postActionExpunge`: When `true`, the channel allows a full-mailbox `EXPUNGE` fallback if UID-scoped expunge is unavailable or fails (default `false`). Enable only on very old IMAP servers that lack modern UIDPLUS support. Note that this fallback will expunge **all** messages marked as deleted in the mailbox, including ones not handled by the agent. Leaving this off is safe for all modern IMAP servers.
|
||||
> - `allowedAttachmentTypes`: Save inbound attachments matching these MIME types — `["*"]` for all, e.g. `["application/pdf", "image/*"]` (default `[]` = disabled).
|
||||
> - `maxAttachmentSize`: Max size per attachment in bytes (default `2000000` / 2MB).
|
||||
> - `maxAttachmentsPerEmail`: Max attachments to save per email (default `5`).
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"email": {
|
||||
"enabled": true,
|
||||
"consentGranted": true,
|
||||
"imapHost": "imap.gmail.com",
|
||||
"imapPort": 993,
|
||||
"imapUsername": "my-nanobot@gmail.com",
|
||||
"imapPassword": "your-app-password",
|
||||
"smtpHost": "smtp.gmail.com",
|
||||
"smtpPort": 587,
|
||||
"smtpUsername": "my-nanobot@gmail.com",
|
||||
"smtpPassword": "your-app-password",
|
||||
"fromAddress": "my-nanobot@gmail.com",
|
||||
"allowFrom": ["your-real-email@gmail.com"],
|
||||
"postAction": "move",
|
||||
"postActionMoveMailbox": "[Gmail]/Trash",
|
||||
"postActionIgnoreSkipped": true,
|
||||
"postActionExpunge": false,
|
||||
"allowedAttachmentTypes": ["application/pdf", "image/*"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
|
||||
**3. Run**
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>WeChat (微信 / Weixin)</b></summary>
|
||||
|
||||
Uses **HTTP long-poll** with QR-code login via the ilinkai personal WeChat API. No local WeChat desktop client is required.
|
||||
|
||||
**1. Enable WeChat support**
|
||||
|
||||
```bash
|
||||
nanobot plugins enable weixin
|
||||
```
|
||||
|
||||
**2. Configure**
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"weixin": {
|
||||
"enabled": true,
|
||||
"allowFrom": ["YOUR_WECHAT_USER_ID"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> - `allowFrom`: Add the sender ID you see in nanobot logs for your WeChat account. Use `["*"]` to allow all users.
|
||||
> - `token`: Optional. If omitted, log in interactively and nanobot will save the token for you.
|
||||
> - `routeTag`: Optional. When your upstream Weixin deployment requires request routing, nanobot will send it as the `SKRouteTag` header.
|
||||
> - `stateDir`: Optional. Defaults to nanobot's runtime directory for Weixin state.
|
||||
> - `pollTimeout`: Optional long-poll timeout in seconds.
|
||||
|
||||
**3. Login**
|
||||
|
||||
```bash
|
||||
nanobot channels login weixin
|
||||
```
|
||||
|
||||
Use `--force` to re-authenticate and ignore any saved token:
|
||||
|
||||
```bash
|
||||
nanobot channels login weixin --force
|
||||
```
|
||||
|
||||
**4. Run**
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>Wecom (企业微信)</b></summary>
|
||||
|
||||
> Here we use [wecom-aibot-sdk-python](https://github.com/chengyongru/wecom_aibot_sdk) (community Python version of the official [@wecom/aibot-node-sdk](https://www.npmjs.com/package/@wecom/aibot-node-sdk)).
|
||||
>
|
||||
> Uses **WebSocket** long connection — no public IP required.
|
||||
|
||||
**1. Enable WeCom support**
|
||||
|
||||
```bash
|
||||
nanobot plugins enable wecom
|
||||
```
|
||||
|
||||
**2. Create a WeCom AI Bot**
|
||||
|
||||
Go to the WeCom admin console → Intelligent Robot → Create Robot → select **API mode** with **long connection**. Copy the Bot ID and Secret.
|
||||
|
||||
**3. Configure**
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"wecom": {
|
||||
"enabled": true,
|
||||
"botId": "your_bot_id",
|
||||
"secret": "your_bot_secret",
|
||||
"allowFrom": ["your_id"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**4. Run**
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>Microsoft Teams</b> (MVP — DM only)</summary>
|
||||
|
||||
> Direct-message text in/out, tenant-aware OAuth, conversation reference persistence.
|
||||
> Uses a public HTTPS webhook — no WebSocket; you need a tunnel or reverse proxy.
|
||||
|
||||
**1. Enable Microsoft Teams support**
|
||||
|
||||
```bash
|
||||
nanobot plugins enable msteams
|
||||
```
|
||||
|
||||
**2. Create a Teams / Azure bot app registration**
|
||||
|
||||
Create or reuse a Microsoft Teams / Azure bot app registration. Set the bot messaging endpoint to a public HTTPS URL ending in `/api/messages`.
|
||||
|
||||
**3. Configure**
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"msteams": {
|
||||
"enabled": true,
|
||||
"appId": "YOUR_APP_ID",
|
||||
"appPassword": "YOUR_APP_SECRET",
|
||||
"tenantId": "YOUR_TENANT_ID",
|
||||
"host": "0.0.0.0",
|
||||
"port": 3978,
|
||||
"path": "/api/messages",
|
||||
"allowFrom": ["*"],
|
||||
"replyInThread": true,
|
||||
"mentionOnlyResponse": "Hi — what can I help with?",
|
||||
"validateInboundAuth": true,
|
||||
"refTtlDays": 30,
|
||||
"pruneWebChatRefs": true,
|
||||
"pruneNonPersonalRefs": true,
|
||||
"refTouchIntervalS": 300
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> - `replyInThread: true` replies to the triggering Teams activity when a stored `activity_id` is available.
|
||||
> - `mentionOnlyResponse` controls what Nanobot receives when a user sends only a bot mention (`<at>Nanobot</at>`). Set to `""` to ignore mention-only messages.
|
||||
> - `validateInboundAuth: true` enables inbound Bot Framework bearer-token validation (signature, issuer, audience, lifetime, `serviceUrl`). This is the safe default for public deployments. Only set it to `false` for local development or tightly controlled testing.
|
||||
> - `refTtlDays` (default `30`) controls how old stored conversation refs can be before they are pruned.
|
||||
> - `pruneWebChatRefs` (default `true`) drops refs with `webchat.botframework.com` service URLs.
|
||||
> - `pruneNonPersonalRefs` (default `true`) drops refs whose `conversation_type` is not `personal`.
|
||||
> - `refTouchIntervalS` (default `300`) throttles how often successful sends refresh `updated_at` for active refs.
|
||||
|
||||
**4. Run**
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
<details>
|
||||
<summary><b>Signal</b></summary>
|
||||
|
||||
Uses **signal-cli** daemon in HTTP mode — receive messages via SSE, send via JSON-RPC.
|
||||
|
||||
**1. Install signal-cli**
|
||||
|
||||
Install [signal-cli](https://github.com/AsamK/signal-cli) and register a phone number:
|
||||
|
||||
```bash
|
||||
signal-cli -u +1234567890 register
|
||||
signal-cli -u +1234567890 verify <CODE>
|
||||
```
|
||||
|
||||
Start the daemon:
|
||||
|
||||
```bash
|
||||
signal-cli -a +1234567890 daemon --http localhost:8080
|
||||
```
|
||||
|
||||
**2. Configure**
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"signal": {
|
||||
"enabled": true,
|
||||
"phoneNumber": "+1234567890",
|
||||
"daemonHost": "localhost",
|
||||
"daemonPort": 8080,
|
||||
"dm": {
|
||||
"enabled": true,
|
||||
"policy": "open"
|
||||
},
|
||||
"group": {
|
||||
"enabled": true,
|
||||
"policy": "open",
|
||||
"requireMention": true
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> - `phoneNumber`: Your registered Signal phone number.
|
||||
> - `daemonHost` / `daemonPort`: Where signal-cli daemon is listening (default `localhost:8080`).
|
||||
> - `dm.policy`: `"open"` (anyone can DM) or `"allowlist"` (only listed numbers/UUIDs). When `"allowlist"`, unlisted DM senders receive a pairing code.
|
||||
> - `dm.allowFrom`: List of allowed phone numbers or UUIDs (used when policy is `"allowlist"`).
|
||||
> - `group.policy`: `"open"` (all groups) or `"allowlist"` (only listed group IDs).
|
||||
> - `group.requireMention`: When `true` (default), the bot only responds in groups when @mentioned.
|
||||
> - `group.allowFrom`: List of allowed group IDs (used when group policy is `"allowlist"`).
|
||||
> - `attachmentsDir`: Override the directory where signal-cli stores inbound attachments. Defaults to `~/.local/share/signal-cli/attachments` (the Linux default). Set this if signal-cli runs with a custom `XDG_DATA_HOME` or on macOS/Windows.
|
||||
> - `groupMessageBufferSize`: Number of recent group messages kept for context (default `20`, must be > 0).
|
||||
|
||||
**3. Run**
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
> [!TIP]
|
||||
> The channel automatically reconnects to the signal-cli daemon with exponential backoff if the connection drops.
|
||||
> Markdown in bot replies is automatically converted to Signal text styles (bold, italic, code, etc.).
|
||||
|
||||
</details>
|
||||
@@ -0,0 +1,156 @@
|
||||
# In-Chat Commands
|
||||
|
||||
These commands work inside chat channels and interactive agent sessions:
|
||||
|
||||
| Command | Description |
|
||||
|---------|-------------|
|
||||
| `/new` | Stop current task and start a new conversation |
|
||||
| `/stop` | Stop the current task |
|
||||
| `/restart` | Restart the bot |
|
||||
| `/status` | Show bot status |
|
||||
| `/model` | Show the current model and available model presets |
|
||||
| `/model <preset>` | Switch the runtime model preset for future turns |
|
||||
| `/dream` | Run Dream memory consolidation now |
|
||||
| `/dream-log` | Show the latest Dream memory change |
|
||||
| `/dream-log <sha>` | Show a specific Dream memory change |
|
||||
| `/dream-restore` | List recent Dream memory versions |
|
||||
| `/dream-restore <sha>` | Restore memory to the state before a specific change |
|
||||
| `/dream-prompt` | Show how Dream is being guided for memory |
|
||||
| `/dream-prompt init` | Create an editable Dream memory guide at `prompts/dream.md` |
|
||||
| `/skill` | List enabled skills and their descriptions |
|
||||
| `/trigger` | Show local trigger usage |
|
||||
| `/trigger <name>` | Create a named local trigger for the current chat/session |
|
||||
| `/pairing` | List pending pairing requests |
|
||||
| `/pairing approve <code>` | Approve a pairing code |
|
||||
| `/pairing deny <code>` | Deny a pending pairing request |
|
||||
| `/pairing revoke <user_id>` | Revoke a previously approved user on the current channel |
|
||||
| `/pairing revoke <channel> <user_id>` | Revoke a previously approved user on a specific channel |
|
||||
| `/help` | Show available in-chat commands |
|
||||
|
||||
## Pairing
|
||||
|
||||
When someone sends a DM to the bot and isn't on the allowlist — whether it's a new user or an existing user on a new channel — nanobot automatically replies with a **pairing code** (like `ABCD-EFGH`) that expires in 10 minutes. To grant them access:
|
||||
|
||||
```text
|
||||
/pairing approve ABCD-EFGH
|
||||
```
|
||||
|
||||
To see who's waiting, use `/pairing`. To remove someone later, use `/pairing revoke <user_id>` — you can find user IDs in the `/pairing list` output.
|
||||
|
||||
See [Configuration: Pairing](./configuration.md#pairing) for the full setup guide.
|
||||
|
||||
## Model Presets
|
||||
|
||||
Use `/model` to inspect the current runtime model:
|
||||
|
||||
```text
|
||||
/model
|
||||
```
|
||||
|
||||
The response shows the current model, the current preset, and the available preset names. Named presets come from the top-level `modelPresets` config and are the recommended way to configure model choices. `default` is always available and represents the model settings from direct `agents.defaults.*` fields.
|
||||
|
||||
To switch presets for future turns:
|
||||
|
||||
```text
|
||||
/model fast
|
||||
/model deep
|
||||
/model default
|
||||
```
|
||||
|
||||
Preset names come from the top-level `modelPresets` config. Switching is runtime-only: it does not rewrite `config.json`, and an in-progress turn keeps using the model it started with. See [Configuration: Model presets](./configuration.md#model-presets) for setup details.
|
||||
|
||||
## Local triggers
|
||||
|
||||
Use `/trigger <name>` when a local script or another service should be able to
|
||||
send a message into the current chat/session later. A name is required; plain
|
||||
`/trigger` only shows the usage hint.
|
||||
|
||||
Create the trigger from the chat where future messages should arrive:
|
||||
|
||||
```text
|
||||
/trigger PR review
|
||||
```
|
||||
|
||||
nanobot replies with a trigger ID and a command shaped like:
|
||||
|
||||
```bash
|
||||
nanobot trigger trg_8K4P2Q9X "Review PR #4502"
|
||||
```
|
||||
|
||||
Replace `"Review PR #4502"` with the message you want nanobot to receive. The
|
||||
trigger is bound to the session where it was created, so the message goes back
|
||||
to that same chat. Keep `nanobot gateway` running so trigger messages can be
|
||||
delivered. The trigger message starts an automation turn recorded in that
|
||||
session with the message you passed to the CLI; it is not treated as a normal
|
||||
user message. If that session is already running a turn, the trigger waits
|
||||
until the session is idle instead of being injected into the active turn.
|
||||
|
||||
Trigger deliveries are stored in the workspace until their linked agent turn
|
||||
finishes successfully. If the gateway exits after claiming a delivery but before
|
||||
the turn completes, the next gateway start requeues that delivery. This is an
|
||||
at-least-once local queue: a delivery may run more than once if the process
|
||||
exits at the wrong time, so external scripts should make repeated trigger
|
||||
messages safe. If the delivery reaches the agent and the agent turn fails, the
|
||||
delivery is marked failed in Automations instead of retrying forever.
|
||||
|
||||
For longer or generated content, omit the message argument and pipe stdin:
|
||||
|
||||
```bash
|
||||
printf '%s\n' "Review the latest failed CI job" | nanobot trigger trg_8K4P2Q9X
|
||||
```
|
||||
|
||||
If an external webhook should wake nanobot up, run your own small webhook
|
||||
service and have it call the trigger command after it builds the final message:
|
||||
|
||||
```bash
|
||||
nanobot trigger <trigger-id> "<message>"
|
||||
```
|
||||
|
||||
If you run multiple nanobot instances, pass the same config or workspace
|
||||
selector used by the gateway:
|
||||
|
||||
```bash
|
||||
nanobot trigger --config ./bot-a/config.json trg_8K4P2Q9X "Nightly report"
|
||||
nanobot trigger --workspace ./bot-a/workspace trg_8K4P2Q9X "Nightly report"
|
||||
```
|
||||
|
||||
Manage triggers from the WebUI Automations view. You can search, pause/resume,
|
||||
rename, delete, and copy the trigger command there. A session may have multiple
|
||||
triggers, just like it may have multiple scheduled automations.
|
||||
|
||||
See [Automations](./automations.md) for how local triggers fit with scheduled
|
||||
automations, heartbeat, and gateway delivery.
|
||||
|
||||
## Periodic Tasks
|
||||
|
||||
Periodic background checks are driven by `HEARTBEAT.md` in your workspace (`~/.nanobot/workspace/HEARTBEAT.md`). When `nanobot gateway` starts, it registers a protected heartbeat cron job by default. Every 30 minutes, that job checks the file; if it finds tasks under `## Active Tasks`, the agent executes them and delivers only results that pass the notification gate to your most recently active chat channel. If there are no active tasks, or the result is routine with nothing useful to report, the heartbeat is skipped silently.
|
||||
|
||||
Use heartbeat for recurring checks that should usually stay quiet. User-created cron jobs are different: they run as scheduled turns in the chat/session where they were created and normally deliver the result back to that channel.
|
||||
|
||||
**Setup:** edit `~/.nanobot/workspace/HEARTBEAT.md` (created automatically by `nanobot onboard`):
|
||||
|
||||
```markdown
|
||||
## Active Tasks
|
||||
|
||||
- Check weather forecast and notify me only if storms are expected
|
||||
- Scan inbox for urgent emails and notify me if any are found
|
||||
```
|
||||
|
||||
The agent can also manage this file itself - ask it to "add a periodic background check" or "check this periodically but only notify me if something changes" and it will update `HEARTBEAT.md` for you. Completed tasks should be deleted from the file, not moved to another section.
|
||||
|
||||
You can change the interval or disable the built-in heartbeat in `~/.nanobot/config.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"gateway": {
|
||||
"heartbeat": {
|
||||
"enabled": true,
|
||||
"intervalS": 1800
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The heartbeat job is visible in `cron(action="list")` as `heartbeat`, but it is system-managed and cannot be removed with the `cron` tool. To stop it, set `gateway.heartbeat.enabled` to `false` and restart the gateway.
|
||||
|
||||
> **Note:** The gateway must be running (`nanobot gateway`) and you must have chatted with the bot at least once so it knows which channel to deliver to.
|
||||
@@ -0,0 +1,287 @@
|
||||
# CLI Reference
|
||||
|
||||
Use this page when you know what you want to run and need the command shape. For a guided first run, start with [`quick-start.md`](./quick-start.md).
|
||||
|
||||
## Choose a Command
|
||||
|
||||
| Goal | Command | Notes |
|
||||
|---|---|---|
|
||||
| Check the install | `nanobot --version` | If this fails, try `python -m nanobot --version` |
|
||||
| Create or refresh config | `nanobot onboard` | Creates `~/.nanobot/config.json` and `~/.nanobot/workspace/` |
|
||||
| Refresh config non-interactively | `nanobot onboard --refresh` | Preserves existing values and adds missing default fields without prompting |
|
||||
| Use guided setup | `nanobot onboard --wizard` | Best when you prefer prompts over hand-editing JSON |
|
||||
| Open the browser workbench | `nanobot webui` | Prepares local WebUI settings, starts the gateway, and opens the browser |
|
||||
| Check config without calling a model | `nanobot status` | Summarizes the selected config, workspace, active model, and providers |
|
||||
| Send one test message | `nanobot agent -m "Hello!"` | First proof that install, config, provider, model, and workspace all work |
|
||||
| Chat in the terminal | `nanobot agent` | Interactive local chat; exit with `exit`, `/exit`, `:q`, or `Ctrl+D` |
|
||||
| Run the gateway directly | `nanobot gateway` | Service/ops command for WebUI, chat apps, cron, and heartbeat |
|
||||
| Deliver a local trigger | `nanobot trigger <id> "message"` | Created first with `/trigger <name>` in the target chat/session |
|
||||
| Serve an OpenAI-compatible API | `nanobot serve` | Starts `/v1/chat/completions`, `/v1/models`, and `/health` |
|
||||
| Check chat channel setup | `nanobot channels status` | Useful before starting `nanobot gateway` |
|
||||
| Manage optional features | `nanobot plugins list` | Shows channels and optional capabilities you can turn on |
|
||||
| Log in to QR/OAuth-style channels | `nanobot channels login <channel>` | Used by channels such as WhatsApp and WeChat |
|
||||
| Log in to OAuth model providers | `nanobot provider login <provider>` | Used by OAuth providers such as OpenAI Codex and GitHub Copilot |
|
||||
|
||||
## Global
|
||||
|
||||
```bash
|
||||
nanobot --help
|
||||
nanobot --version
|
||||
python -m nanobot --help
|
||||
python -m nanobot --version
|
||||
```
|
||||
|
||||
`python -m nanobot ...` is useful when the package is installed but the `nanobot` script is not on `PATH`.
|
||||
|
||||
## Common Patterns
|
||||
|
||||
Most day-to-day commands use the default config and workspace. Advanced or multi-instance runs usually pass both paths explicitly:
|
||||
|
||||
```bash
|
||||
nanobot agent --config ./bot-a/config.json --workspace ./bot-a/workspace -m "Hello"
|
||||
nanobot gateway --config ./bot-a/config.json --workspace ./bot-a/workspace
|
||||
nanobot serve --config ./bot-a/config.json --workspace ./bot-a/workspace
|
||||
```
|
||||
|
||||
Use `--verbose` on long-running processes when you need startup or runtime logs:
|
||||
|
||||
```bash
|
||||
nanobot gateway --verbose
|
||||
nanobot serve --verbose
|
||||
```
|
||||
|
||||
Long-running commands keep working until you stop them. Press `Ctrl+C` in that terminal
|
||||
to stop foreground `nanobot gateway` or `nanobot serve`. If you started the gateway
|
||||
with `--background`, use `nanobot gateway stop`.
|
||||
|
||||
## Setup
|
||||
|
||||
| Command | Description |
|
||||
|---|---|
|
||||
| `nanobot onboard` | Initialize or refresh the default config and workspace |
|
||||
| `nanobot onboard --refresh` | Refresh an existing config without prompting, preserving existing values |
|
||||
| `nanobot onboard --wizard` | Use the interactive setup wizard |
|
||||
| `nanobot onboard --config <path> --workspace <path>` | Initialize or refresh a specific instance |
|
||||
|
||||
Default paths:
|
||||
|
||||
| Path | Default |
|
||||
|---|---|
|
||||
| Config | `~/.nanobot/config.json` |
|
||||
| Workspace | `~/.nanobot/workspace/` |
|
||||
|
||||
## Agent CLI
|
||||
|
||||
| Command | Description |
|
||||
|---|---|
|
||||
| `nanobot agent -m "Hello!"` | Send one message and exit |
|
||||
| `nanobot agent` | Start interactive terminal chat |
|
||||
| `nanobot agent --session <id>` | Use a specific session key |
|
||||
| `nanobot agent --workspace <path>` | Override workspace |
|
||||
| `nanobot agent --config <path>` | Use a specific config file |
|
||||
| `nanobot agent --no-markdown` | Print plain text instead of Rich-rendered Markdown |
|
||||
| `nanobot agent --logs` | Show runtime logs while chatting |
|
||||
|
||||
In interactive mode, `Enter` sends the current message. Press `Alt+Enter` to add a newline before sending.
|
||||
|
||||
Interactive mode exits with `exit`, `quit`, `/exit`, `/quit`, `:q`, or `Ctrl+D`.
|
||||
|
||||
## WebUI
|
||||
|
||||
| Command | Description |
|
||||
|---|---|
|
||||
| `nanobot webui` | Create config/workspace if needed, enable the local WebUI channel after confirmation, start the gateway, and open `http://127.0.0.1:8765` |
|
||||
| `nanobot webui --background` | Start or reuse a background gateway, then open the WebUI |
|
||||
| `nanobot webui --no-open` | Prepare and start the WebUI without opening a browser |
|
||||
| `nanobot webui --port <port>` | Set the WebUI/WebSocket port |
|
||||
| `nanobot webui --gateway-port <port>` | Override the gateway health port |
|
||||
| `nanobot webui --yes` | Apply safe localhost WebUI defaults without confirmation; provider credentials still require interactive setup |
|
||||
|
||||
First-run WebUI setup binds to `127.0.0.1` by default. Use manual configuration and a WebUI password before exposing the WebSocket channel beyond localhost.
|
||||
|
||||
## Gateway
|
||||
|
||||
`nanobot gateway` starts enabled chat channels, WebUI/WebSocket when configured, cron-backed system jobs, Dream, heartbeat, and the health endpoint. Most local browser users should start with `nanobot webui`; use `gateway` directly for service management, chat app operation, and advanced deployment. By default it runs in the foreground, which keeps existing scripts and terminal workflows unchanged. Use `--background` when you want a local macOS, Linux, or Windows process that you can manage from the CLI.
|
||||
|
||||
| Command | Description |
|
||||
|---|---|
|
||||
| `nanobot gateway` | Start the gateway in the foreground with config defaults |
|
||||
| `nanobot gateway --verbose` | Show verbose runtime output |
|
||||
| `nanobot gateway --port <port>` | Override `gateway.port` for the health endpoint |
|
||||
| `nanobot gateway --workspace <path>` | Override workspace |
|
||||
| `nanobot gateway --config <path>` | Use a specific config file |
|
||||
| `nanobot gateway --background` | Start the gateway as a background process |
|
||||
| `nanobot gateway status` | Show the recorded background gateway PID, state file, and log file |
|
||||
| `nanobot gateway logs --no-follow` | Print recent background gateway logs and exit |
|
||||
| `nanobot gateway logs` | Follow background gateway logs |
|
||||
| `nanobot gateway restart` | Restart the recorded background gateway with the current config |
|
||||
| `nanobot gateway stop` | Stop the recorded background gateway |
|
||||
| `nanobot gateway install-service` | Install a systemd user service or macOS LaunchAgent |
|
||||
| `nanobot gateway install-service --dry-run` | Preview the generated service file and system commands |
|
||||
| `nanobot gateway uninstall-service` | Remove the installed system service |
|
||||
|
||||
For custom instances, pass the same selector flags to management commands:
|
||||
|
||||
```bash
|
||||
nanobot gateway --background --config ./bot-a/config.json --workspace ./bot-a/workspace
|
||||
nanobot gateway status --config ./bot-a/config.json --workspace ./bot-a/workspace
|
||||
nanobot gateway stop --config ./bot-a/config.json --workspace ./bot-a/workspace
|
||||
nanobot gateway install-service --config ./bot-a/config.json --workspace ./bot-a/workspace --name bot-a
|
||||
```
|
||||
|
||||
`--background` is a lightweight detached process. `install-service` is for
|
||||
login/startup integration: Linux uses a systemd user service; macOS uses a
|
||||
LaunchAgent plist. System services run the foreground gateway under the OS
|
||||
supervisor rather than nesting another background process.
|
||||
|
||||
Default health endpoint:
|
||||
|
||||
```text
|
||||
http://127.0.0.1:18790/health
|
||||
```
|
||||
|
||||
The bundled WebUI is served by the WebSocket channel, usually on port `8765`, not by the gateway health endpoint.
|
||||
|
||||
## Local Triggers
|
||||
|
||||
`nanobot trigger` delivers one local message to a trigger that was created from
|
||||
a chat/session with `/trigger <name>`.
|
||||
|
||||
```bash
|
||||
nanobot trigger trg_8K4P2Q9X "Review PR #4502"
|
||||
```
|
||||
|
||||
Keep `nanobot gateway` running so the message can be delivered to the linked
|
||||
chat/session. The message is recorded as an automation turn in that session,
|
||||
not as a normal chat message typed by the user.
|
||||
|
||||
The command writes to a workspace-local durable queue. If `nanobot gateway` is
|
||||
not running yet, the message waits in that workspace. If the target session is
|
||||
already running a turn, the trigger waits for that session to become idle. If the
|
||||
gateway exits after claiming a delivery but before the linked turn completes,
|
||||
the next gateway start requeues that delivery. The queue is at-least-once, not
|
||||
exactly-once, so the same message can be delivered again after an interrupted
|
||||
process. If the agent receives the delivery and the turn fails, the delivery is
|
||||
marked failed instead of retried indefinitely. Each delivery also writes an
|
||||
audit record under `<workspace>/triggers/runs`. Run one gateway consumer per
|
||||
workspace; this local queue is not a distributed multi-consumer queue.
|
||||
|
||||
Use stdin when another local process generates the message:
|
||||
|
||||
```bash
|
||||
generate-report | nanobot trigger trg_8K4P2Q9X
|
||||
```
|
||||
|
||||
Options:
|
||||
|
||||
| Command | Description |
|
||||
|---|---|
|
||||
| `nanobot trigger <id> "message"` | Deliver one message through a trigger |
|
||||
| `nanobot trigger <id>` | Read the message from stdin |
|
||||
| `nanobot trigger --config <path> <id> "message"` | Use the workspace from a specific config |
|
||||
| `nanobot trigger --workspace <path> <id> "message"` | Use a specific workspace |
|
||||
|
||||
Triggers are managed in the WebUI Automations view instead of through separate
|
||||
`list`, `revoke`, or `delete` CLI subcommands. From there you can pause/resume,
|
||||
rename, delete, search, and copy the command for each trigger.
|
||||
|
||||
For webhooks or other external systems, run your own small service and have it
|
||||
call this CLI after it decides what message nanobot should receive.
|
||||
|
||||
See [Automations](./automations.md) for the broader automation model, WebUI
|
||||
management, and delivery behavior.
|
||||
|
||||
## OpenAI-Compatible API
|
||||
|
||||
| Command | Description |
|
||||
|---|---|
|
||||
| `nanobot serve` | Start `/v1/chat/completions`, `/v1/models`, and `/health` |
|
||||
| `nanobot serve --host <host>` | Override API bind host |
|
||||
| `nanobot serve --port <port>` | Override API port |
|
||||
| `nanobot serve --timeout <seconds>` | Override per-request timeout |
|
||||
| `nanobot serve --verbose` | Show runtime logs |
|
||||
| `nanobot serve --workspace <path>` | Override workspace |
|
||||
| `nanobot serve --config <path>` | Use a specific config file |
|
||||
|
||||
Default API endpoint:
|
||||
|
||||
```text
|
||||
http://127.0.0.1:8900
|
||||
```
|
||||
|
||||
Public binds (`0.0.0.0` or `::`) require `api.apiKey`; send it as a Bearer token on API routes.
|
||||
|
||||
See [`openai-api.md`](./openai-api.md) for request examples.
|
||||
|
||||
## Status
|
||||
|
||||
```bash
|
||||
nanobot status
|
||||
```
|
||||
|
||||
Shows the config path, workspace path, active model, and provider summary without calling a model.
|
||||
|
||||
| Command | Description |
|
||||
|---|---|
|
||||
| `nanobot status` | Inspect the default instance |
|
||||
| `nanobot status --config <path>` | Inspect a specific config |
|
||||
| `nanobot status --config <path> --workspace <path>` | Inspect a specific config with a workspace override |
|
||||
|
||||
## Channels
|
||||
|
||||
| Command | Description |
|
||||
|---|---|
|
||||
| `nanobot channels status` | Show configured channel status |
|
||||
| `nanobot channels status --config <path>` | Show channel status for a specific config |
|
||||
| `nanobot channels login <channel>` | Run interactive login for supported channels |
|
||||
| `nanobot channels login <channel> --force` | Re-authenticate even if credentials already exist |
|
||||
| `nanobot channels login <channel> --config <path>` | Use a specific config file |
|
||||
| `nanobot plugins list --config <path>` | Show plugin/channel enabled state for a specific config |
|
||||
|
||||
Examples:
|
||||
|
||||
```bash
|
||||
nanobot channels login whatsapp
|
||||
nanobot channels login weixin
|
||||
nanobot channels status
|
||||
```
|
||||
|
||||
See [`chat-apps.md`](./chat-apps.md) for channel-specific setup.
|
||||
|
||||
## Optional Features
|
||||
|
||||
Use these commands when you want nanobot to add or remove a built-in capability
|
||||
without hand-editing JSON. Enabling may install the support package first.
|
||||
Disabling is for channels such as Telegram, Matrix, or Slack; it keeps your
|
||||
saved settings and turns the channel off.
|
||||
|
||||
| Command | Description |
|
||||
|---|---|
|
||||
| `nanobot plugins list` | Show available channels and optional capabilities |
|
||||
| `nanobot plugins enable <name>` | Install missing support and enable the feature or channel |
|
||||
| `nanobot plugins enable <name> --logs` | Show package install logs while enabling |
|
||||
| `nanobot plugins disable <channel>` | Turn off a channel without deleting its saved settings |
|
||||
| `nanobot plugins list --config <path>` | Read a specific config file |
|
||||
| `nanobot plugins enable <name> --config <path>` | Update a specific config file |
|
||||
| `nanobot plugins disable <channel> --config <path>` | Turn off a channel in a specific config file |
|
||||
|
||||
## Provider OAuth
|
||||
|
||||
| Command | Description |
|
||||
|---|---|
|
||||
| `nanobot provider login openai-codex` | Authenticate OpenAI Codex provider |
|
||||
| `nanobot provider login github-copilot` | Authenticate GitHub Copilot provider |
|
||||
| `nanobot provider logout openai-codex` | Remove OpenAI Codex OAuth state |
|
||||
| `nanobot provider logout github-copilot` | Remove GitHub Copilot OAuth state |
|
||||
|
||||
See [`providers.md`](./providers.md#oauth-providers) for when OAuth providers need explicit provider/model selection.
|
||||
|
||||
## Useful First Checks
|
||||
|
||||
```bash
|
||||
nanobot --version
|
||||
nanobot status
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
If these fail, use [`troubleshooting.md`](./troubleshooting.md) before debugging WebUI, chat apps, Docker, systemd, or SDK integrations.
|
||||
@@ -0,0 +1,166 @@
|
||||
# Concepts
|
||||
|
||||
Use this page when you want to understand nanobot before changing advanced settings. It explains the moving parts without requiring you to read the source first.
|
||||
|
||||
If you want source-file ownership and extension points, read [`architecture.md`](./architecture.md) after this page.
|
||||
|
||||
## Runtime Shape
|
||||
|
||||
nanobot has one small core loop and several ways to enter it:
|
||||
|
||||
| Part | What it does |
|
||||
|---|---|
|
||||
| Agent loop | Builds context, selects the session, calls the provider, runs tools, and publishes replies |
|
||||
| Providers | LLM backends such as OpenRouter, Anthropic, OpenAI, Bedrock, Ollama, vLLM, and other OpenAI-compatible APIs |
|
||||
| Channels | User-facing transports such as CLI, WebUI/WebSocket, Telegram, Discord, Slack, Feishu, WeChat, Email, Mattermost, and others |
|
||||
| Tools | Capabilities the model may call, including files, shell, web search/fetch, MCP, cron, image generation, and subagents |
|
||||
| Memory | Workspace files and session history that keep useful context across turns |
|
||||
| Gateway | Long-running process that connects enabled channels and serves the health endpoint |
|
||||
|
||||
The simplest path is `nanobot agent -m "Hello!"`: one inbound message goes through the agent loop and prints the reply in your terminal. The long-running path is `nanobot gateway`: channels receive messages from chat apps or the WebUI, publish them to the same agent loop, and send replies back to the originating channel.
|
||||
|
||||
## Config vs Workspace
|
||||
|
||||
The default instance lives under `~/.nanobot/`:
|
||||
|
||||
| Path | Meaning |
|
||||
|---|---|
|
||||
| `~/.nanobot/config.json` | Instance configuration: providers, model defaults, channels, tools, gateway, API, and runtime options |
|
||||
| `~/.nanobot/workspace/` | Agent workspace: memory, sessions, heartbeat tasks, cron jobs, skills, and generated artifacts |
|
||||
|
||||
You can override both with command flags:
|
||||
|
||||
```bash
|
||||
nanobot onboard --config ./bot-a/config.json --workspace ./bot-a/workspace
|
||||
nanobot agent --config ./bot-a/config.json --workspace ./bot-a/workspace -m "Hello"
|
||||
nanobot gateway --config ./bot-a/config.json --workspace ./bot-a/workspace
|
||||
```
|
||||
|
||||
The config file controls what nanobot may use. The workspace is where nanobot keeps state for that instance.
|
||||
|
||||
## Config Format
|
||||
|
||||
`config.json` accepts both camelCase and snake_case keys. The docs use camelCase because nanobot writes config back to disk with camelCase aliases, for example `apiKey`, `modelPresets`, `intervalS`, and `maxToolResultChars`.
|
||||
|
||||
Most examples are partial snippets. Merge them into the existing file created by `nanobot onboard`; do not replace the whole file unless you want to reset the instance.
|
||||
|
||||
## One Agent Turn
|
||||
|
||||
A normal turn follows this flow:
|
||||
|
||||
1. A channel receives a user message and publishes it to the message bus.
|
||||
2. The agent loop chooses a session key and builds context from the workspace, skills, memory, recent messages, channel metadata, and runtime settings.
|
||||
3. The provider receives the model request.
|
||||
4. If the model asks for tools, the runner executes them and feeds results back to the model.
|
||||
5. The final reply is saved to the session and sent back through the channel.
|
||||
|
||||
That flow is the same whether the message starts in the CLI, WebUI, Telegram, Discord, or another channel.
|
||||
|
||||
## CLI, Gateway, API, and WebUI
|
||||
|
||||
| Entry point | Command | Use it for |
|
||||
|---|---|---|
|
||||
| CLI one-shot | `nanobot agent -m "..."` | First-run checks, scripts, and quick local questions |
|
||||
| CLI interactive | `nanobot agent` | Terminal chat with persistent session history |
|
||||
| Gateway | `nanobot gateway` | Chat apps, WebUI, heartbeat, Dream, and long-running service mode |
|
||||
| OpenAI-compatible API | `nanobot serve` | Programmatic access through `/v1/chat/completions` |
|
||||
| WebUI | `nanobot gateway` plus WebSocket channel | Browser workbench served by the WebSocket channel on port `8765` |
|
||||
|
||||
The gateway health endpoint is on `gateway.port` (`18790` by default). The browser WebUI is served by the WebSocket channel (`8765` by default), not by the health endpoint.
|
||||
|
||||
## Provider and Model Selection
|
||||
|
||||
The active model should normally come from a named `modelPresets` entry selected by `agents.defaults.modelPreset`. Direct `agents.defaults.provider` and `agents.defaults.model` still form the implicit `default` preset for older or minimal configs. The active provider is resolved in this order:
|
||||
|
||||
1. If the active preset provider or implicit default provider is not `"auto"`, nanobot uses that provider.
|
||||
2. If provider is `"auto"`, nanobot tries to infer the provider from the model name, configured API keys, local provider base URLs, or gateway providers.
|
||||
3. OAuth providers such as OpenAI Codex and GitHub Copilot require explicit login and explicit provider/model selection inside the active preset.
|
||||
|
||||
Pin the provider inside the preset when setting up for the first time. It is easier to debug:
|
||||
|
||||
```json
|
||||
{
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"provider": "openrouter",
|
||||
"model": "anthropic/claude-opus-4.5"
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
See [`providers.md`](./providers.md) for practical examples and [`configuration.md#providers`](./configuration.md#providers) for the full provider reference.
|
||||
|
||||
## Channels and Sessions
|
||||
|
||||
Each channel maps inbound messages to a session key. That lets independent conversations keep separate history. The WebUI also supports multiple chats and workspace-scoped metadata for project workspaces.
|
||||
|
||||
`agents.defaults.unifiedSession` can intentionally share one session across channels for a single-user multi-device setup. Leave it off if you expect separate people, groups, channels, or projects to keep separate context.
|
||||
|
||||
## Memory, Sessions, and Dream
|
||||
|
||||
nanobot uses two related stores:
|
||||
|
||||
| Store | Location | Purpose |
|
||||
|---|---|---|
|
||||
| Sessions | `<workspace>/sessions/*.jsonl` | Recent conversation turns replayed into context |
|
||||
| Memory | `<workspace>/memory/MEMORY.md` and `<workspace>/memory/history.jsonl` | Long-term facts and consolidated history |
|
||||
|
||||
Dream is a periodic consolidation job. It reads accumulated history and updates workspace memory so useful context can survive beyond short session replay.
|
||||
|
||||
See [`memory.md`](./memory.md) for the detailed design.
|
||||
|
||||
## Tools and Safety
|
||||
|
||||
Tools are discovered automatically from built-in modules and plugin entry points. Common tool groups include:
|
||||
|
||||
- file read/write/edit and patching;
|
||||
- shell execution with configurable sandboxing;
|
||||
- web search and web fetch with SSRF checks;
|
||||
- MCP servers;
|
||||
- cron reminders, local triggers, and heartbeat tasks;
|
||||
- image generation;
|
||||
- subagents and runtime self-inspection.
|
||||
|
||||
Security-sensitive controls live in [`configuration.md#security`](./configuration.md#security). For production or shared chat apps, also configure channel access controls such as `allowFrom`, pairing, or WebSocket tokens.
|
||||
|
||||
## Background Jobs
|
||||
|
||||
When `nanobot gateway` starts, it runs workspace-scoped automations and
|
||||
registers system jobs:
|
||||
|
||||
- `dream`, when `agents.defaults.dream.enabled` is true;
|
||||
- `heartbeat`, when `gateway.heartbeat.enabled` is true.
|
||||
|
||||
Heartbeat reads `<workspace>/HEARTBEAT.md`. If the file has tasks under `## Active Tasks`, nanobot executes them and sends only useful/actionable results to the most recently active chat target. Routine "nothing changed" results are suppressed.
|
||||
|
||||
User-created reminders use the same cron service but are not the same as the
|
||||
protected heartbeat system job. They run as scheduled turns in their origin
|
||||
chat/session and normally deliver the result back to that channel.
|
||||
|
||||
Local triggers are also session-bound, but they do not have their own
|
||||
schedule. Create one from the target chat with `/trigger <name>`, then call
|
||||
`nanobot trigger <id> "<message>"` when a local script or external service wants
|
||||
nanobot to respond in that session. Webhook servers, third-party auth, and
|
||||
event-to-message formatting stay outside nanobot. Trigger deliveries are stored
|
||||
in the workspace until the linked agent turn finishes successfully. If the
|
||||
target session is busy, the trigger waits until that session is idle instead of
|
||||
being injected into the active turn. The message is recorded as an automation
|
||||
turn in that session. Delivery is at-least-once, so external systems should
|
||||
tolerate repeated trigger messages; a delivery that reaches the agent but fails
|
||||
is marked failed rather than retried forever.
|
||||
|
||||
## Where to Go Next
|
||||
|
||||
| Need | Read |
|
||||
|---|---|
|
||||
| First working install | [`quick-start.md`](./quick-start.md) |
|
||||
| Provider/model setup | [`providers.md`](./providers.md) |
|
||||
| Chat app setup | [`chat-apps.md`](./chat-apps.md) |
|
||||
| Complete config reference | [`configuration.md`](./configuration.md) |
|
||||
| Runtime debugging | [`troubleshooting.md`](./troubleshooting.md) |
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,188 @@
|
||||
# Deployment
|
||||
|
||||
Use this page after `nanobot agent -m "Hello!"` works locally. Deployment keeps long-running surfaces online: WebUI, chat apps, heartbeat, Dream, cron jobs, and channel connections.
|
||||
|
||||
## Before You Deploy
|
||||
|
||||
Check these once before Docker, systemd, or LaunchAgent:
|
||||
|
||||
| Check | Why it matters |
|
||||
|---|---|
|
||||
| `nanobot status` shows the expected config and workspace | Confirms the process will read the instance you meant to run |
|
||||
| `nanobot agent -m "Hello!"` works | Proves install, config, provider, model, and workspace writes before adding a service layer |
|
||||
| Secrets are in environment variables or protected config files | API keys, bot tokens, OAuth state, and chat credentials should not be world-readable |
|
||||
| `~/.nanobot/` or your custom config/workspace path is persistent | Sessions, memory, channel login state, generated artifacts, and cron jobs live there |
|
||||
| Channel access control is intentional | Use `allowFrom`, pairing, WebSocket `token`/`tokenIssueSecret`, or private test channels before exposing the bot |
|
||||
| Ports are planned | Gateway health defaults to `18790`; WebUI/WebSocket defaults to `8765`; `nanobot serve` defaults to `8900` |
|
||||
| Logs are easy to reach | Use `docker compose logs`, `journalctl`, LaunchAgent log files, or `nanobot gateway --verbose` while diagnosing startup |
|
||||
|
||||
Restart the deployed process after editing `config.json`. Long-running processes read config at startup.
|
||||
|
||||
## Choose a Runtime
|
||||
|
||||
| Runtime | Use it for | State location | Useful first command |
|
||||
|---|---|---|---|
|
||||
| Docker Compose | Repeatable container runs on Linux servers or workstations | Bind-mount `~/.nanobot` to `/home/nanobot/.nanobot` | `docker compose run --rm nanobot-cli agent -m "Hello!"` |
|
||||
| Docker CLI | Manual container testing or small one-off hosts | Bind-mount `~/.nanobot` to `/home/nanobot/.nanobot` | `docker run -v ~/.nanobot:/home/nanobot/.nanobot --rm nanobot status` |
|
||||
| systemd user service | Linux user-level gateway that restarts automatically | Host user's `~/.nanobot` unless you pass explicit paths | `systemctl --user status nanobot-gateway` |
|
||||
| macOS LaunchAgent | macOS gateway that starts after login | Host user's `~/.nanobot` unless the plist passes explicit paths | `launchctl list | grep ai.nanobot.gateway` |
|
||||
|
||||
## Docker
|
||||
|
||||
> [!TIP]
|
||||
> The `-v ~/.nanobot:/home/nanobot/.nanobot` flag mounts your local config directory into the container, so your config and workspace persist across container restarts.
|
||||
> The container runs as the non-root user `nanobot` (UID 1000) and reads config from `/home/nanobot/.nanobot`. Always mount your host config directory to `/home/nanobot/.nanobot`, not `/root/.nanobot`.
|
||||
> If you get **Permission denied**, fix ownership on the host first: `sudo chown -R 1000:1000 ~/.nanobot`, or pass `--user $(id -u):$(id -g)` to match your host UID. Podman users can use `--userns=keep-id` instead.
|
||||
>
|
||||
> [!IMPORTANT]
|
||||
> Official Docker usage currently means building from this repository with the included `Dockerfile`. Docker Hub images under third-party namespaces are not maintained or verified by HKUDS/nanobot; do not mount API keys or bot tokens into them unless you trust the publisher.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> The gateway and WebSocket channel default to `host: "127.0.0.1"` in `config.json` (set in `nanobot/config/schema.py`). Docker `-p` port forwarding cannot reach a container's loopback interface, so for the host or LAN to reach the exposed ports you must set both binds to `0.0.0.0` in `~/.nanobot/config.json` before starting the container. To serve the bundled WebUI from Docker, bind the WebSocket channel externally and protect bootstrap with a secret:
|
||||
>
|
||||
> ```json
|
||||
> {
|
||||
> "gateway": { "host": "0.0.0.0" },
|
||||
> "channels": {
|
||||
> "websocket": {
|
||||
> "host": "0.0.0.0",
|
||||
> "port": 8765,
|
||||
> "tokenIssueSecret": "your-secret-here"
|
||||
> }
|
||||
> }
|
||||
> }
|
||||
> ```
|
||||
>
|
||||
> When the WebSocket `host` is `0.0.0.0`, the channel refuses to start unless `token` or `tokenIssueSecret` is also configured. See [`webui.md#lan-access`](./webui.md#lan-access) for details.
|
||||
|
||||
### Docker Compose
|
||||
|
||||
```bash
|
||||
docker compose run --rm nanobot-cli onboard # first-time setup
|
||||
vim ~/.nanobot/config.json # add API keys
|
||||
docker compose up -d nanobot-gateway # start gateway
|
||||
```
|
||||
|
||||
```bash
|
||||
docker compose run --rm nanobot-cli agent -m "Hello!" # run CLI
|
||||
docker compose logs -f nanobot-gateway # view logs
|
||||
docker compose down # stop
|
||||
```
|
||||
|
||||
### Docker
|
||||
|
||||
```bash
|
||||
# Build the image
|
||||
docker build -t nanobot .
|
||||
|
||||
# Initialize config (first time only)
|
||||
docker run -v ~/.nanobot:/home/nanobot/.nanobot --rm nanobot onboard
|
||||
|
||||
# Edit config on host to add API keys
|
||||
vim ~/.nanobot/config.json
|
||||
|
||||
# Run gateway (connects to enabled channels, e.g. Telegram/Discord/Mochat).
|
||||
# Mirrors the security caps and port mappings declared in docker-compose.yml:
|
||||
# - `--cap-drop ALL --cap-add SYS_ADMIN` + unconfined apparmor/seccomp are required
|
||||
# when `tools.exec.sandbox: "bwrap"` is enabled (bwrap needs CAP_SYS_ADMIN for
|
||||
# user namespaces). Without them, `bwrap` exits with `clone3: Operation not permitted`.
|
||||
# - `-p 8765:8765` exposes the WebSocket channel / WebUI alongside the gateway health
|
||||
# endpoint on 18790.
|
||||
docker run \
|
||||
--cap-drop ALL --cap-add SYS_ADMIN \
|
||||
--security-opt apparmor=unconfined \
|
||||
--security-opt seccomp=unconfined \
|
||||
-v ~/.nanobot:/home/nanobot/.nanobot \
|
||||
-p 18790:18790 -p 8765:8765 \
|
||||
nanobot gateway
|
||||
|
||||
# Or run a single command
|
||||
docker run -v ~/.nanobot:/home/nanobot/.nanobot --rm nanobot agent -m "Hello!"
|
||||
docker run -v ~/.nanobot:/home/nanobot/.nanobot --rm nanobot status
|
||||
```
|
||||
|
||||
## Linux Service
|
||||
|
||||
Run the gateway as a systemd user service so it starts automatically and restarts on failure.
|
||||
|
||||
Preview the generated unit first:
|
||||
|
||||
```bash
|
||||
nanobot gateway install-service --manager systemd --dry-run
|
||||
```
|
||||
|
||||
Install, enable, and start it:
|
||||
|
||||
```bash
|
||||
nanobot gateway install-service --manager systemd
|
||||
```
|
||||
|
||||
For a custom instance, pass the same config/workspace selector you use to run the gateway:
|
||||
|
||||
```bash
|
||||
nanobot gateway install-service \
|
||||
--manager systemd \
|
||||
--name nanobot-telegram \
|
||||
--config ~/.nanobot-telegram/config.json \
|
||||
--workspace ~/.nanobot-telegram/workspace
|
||||
```
|
||||
|
||||
Common operations:
|
||||
|
||||
```bash
|
||||
systemctl --user status nanobot-gateway # check status
|
||||
systemctl --user restart nanobot-gateway # restart after config changes
|
||||
journalctl --user -u nanobot-gateway -f # follow logs
|
||||
nanobot gateway uninstall-service --manager systemd
|
||||
```
|
||||
|
||||
The installer writes `~/.config/systemd/user/nanobot-gateway.service`, runs
|
||||
`systemctl --user daemon-reload`, enables the unit, and restarts it. It uses the
|
||||
current Python executable with `python -m nanobot gateway --foreground`, so the
|
||||
service runs in the same environment you used to install nanobot.
|
||||
|
||||
> **Note:** User services only run while you are logged in. To keep the gateway running after logout, enable lingering:
|
||||
>
|
||||
> ```bash
|
||||
> loginctl enable-linger $USER
|
||||
> ```
|
||||
|
||||
## macOS LaunchAgent
|
||||
|
||||
Use a LaunchAgent when you want `nanobot gateway` to stay online after you log in, without keeping a terminal open.
|
||||
|
||||
Preview the generated plist first:
|
||||
|
||||
```bash
|
||||
nanobot gateway install-service --manager launchd --dry-run
|
||||
```
|
||||
|
||||
Install, load, enable, and start it:
|
||||
|
||||
```bash
|
||||
nanobot gateway install-service --manager launchd
|
||||
```
|
||||
|
||||
For a custom instance:
|
||||
|
||||
```bash
|
||||
nanobot gateway install-service \
|
||||
--manager launchd \
|
||||
--name nanobot-telegram \
|
||||
--config ~/.nanobot-telegram/config.json \
|
||||
--workspace ~/.nanobot-telegram/workspace
|
||||
```
|
||||
|
||||
Common operations:
|
||||
|
||||
```bash
|
||||
launchctl list | grep ai.nanobot.gateway
|
||||
launchctl kickstart -k gui/$(id -u)/ai.nanobot.gateway
|
||||
nanobot gateway uninstall-service --manager launchd
|
||||
```
|
||||
|
||||
The installer writes `~/Library/LaunchAgents/ai.nanobot.gateway.plist`, uses the
|
||||
current Python executable with `python -m nanobot gateway --foreground`, and
|
||||
writes LaunchAgent logs under `~/.nanobot/logs/`.
|
||||
|
||||
> **Note:** if startup fails with "address already in use", stop the manually started `nanobot gateway` process first.
|
||||
@@ -0,0 +1,121 @@
|
||||
# Development
|
||||
|
||||
This page collects contributor-facing notes for extending nanobot. User-facing setup and runtime options live in [`configuration.md`](./configuration.md).
|
||||
|
||||
## Adding an LLM Provider
|
||||
|
||||
nanobot uses the provider registry in `nanobot/providers/registry.py` as the source of truth for LLM provider metadata. Most OpenAI-compatible providers need only two changes.
|
||||
|
||||
1. Add a `ProviderSpec` entry to `PROVIDERS`:
|
||||
|
||||
```python
|
||||
ProviderSpec(
|
||||
name="myprovider",
|
||||
keywords=("myprovider", "mymodel"),
|
||||
env_key="MYPROVIDER_API_KEY",
|
||||
display_name="My Provider",
|
||||
default_api_base="https://api.myprovider.com/v1",
|
||||
)
|
||||
```
|
||||
|
||||
2. Add a field to `ProvidersConfig` in `nanobot/config/schema.py`:
|
||||
|
||||
```python
|
||||
class ProvidersConfig(BaseModel):
|
||||
...
|
||||
myprovider: ProviderConfig = Field(default_factory=ProviderConfig)
|
||||
```
|
||||
|
||||
Environment variables, config matching, provider status, and WebUI credential display derive from those two entries.
|
||||
|
||||
Useful `ProviderSpec` options:
|
||||
|
||||
| Field | Description |
|
||||
|---|---|
|
||||
| `default_api_base` | Default OpenAI-compatible base URL. |
|
||||
| `env_extras` | Additional environment variables derived from the provider config. |
|
||||
| `model_overrides` | Per-model request parameter overrides. |
|
||||
| `is_gateway` | Provider can route many model families, like OpenRouter. |
|
||||
| `detect_by_key_prefix` | Match configured gateways by API-key prefix. |
|
||||
| `detect_by_base_keyword` | Match configured gateways by API base URL. |
|
||||
| `strip_model_prefix` | Strip `provider/` before sending the model to the upstream API. |
|
||||
| `supports_max_completion_tokens` | Use `max_completion_tokens` instead of `max_tokens`. |
|
||||
| `is_transcription_only` | Provider has credentials but cannot serve chat completions. |
|
||||
|
||||
## Adding a Transcription Provider
|
||||
|
||||
Transcription is intentionally split into two layers:
|
||||
|
||||
- `nanobot/audio/transcription_registry.py` owns provider names, aliases, default models, and adapter loading.
|
||||
- `nanobot/providers/transcription.py` owns provider-specific HTTP behavior.
|
||||
|
||||
Credentials still live under `providers.<provider>` so chat channels and WebUI resolve API keys and API bases the same way.
|
||||
|
||||
1. Add provider credentials to `ProvidersConfig`.
|
||||
|
||||
```python
|
||||
class ProvidersConfig(BaseModel):
|
||||
...
|
||||
my_stt: ProviderConfig = Field(default_factory=ProviderConfig)
|
||||
```
|
||||
|
||||
2. Add a `ProviderSpec` in `nanobot/providers/registry.py`.
|
||||
|
||||
For transcription-only providers, set `is_transcription_only=True` so they show up in credential/settings surfaces but stay out of chat model selection.
|
||||
|
||||
```python
|
||||
ProviderSpec(
|
||||
name="my_stt",
|
||||
keywords=("my_stt",),
|
||||
env_key="MY_STT_API_KEY",
|
||||
display_name="My STT",
|
||||
default_api_base="https://api.example.com/v1",
|
||||
is_transcription_only=True,
|
||||
)
|
||||
```
|
||||
|
||||
3. Add an adapter class in `nanobot/providers/transcription.py`.
|
||||
|
||||
Adapters receive resolved credentials and settings. They return an empty string for provider errors so channel voice messages fail quietly instead of crashing the agent loop.
|
||||
|
||||
```python
|
||||
class MySTTTranscriptionProvider:
|
||||
def __init__(
|
||||
self,
|
||||
api_key: str | None = None,
|
||||
api_base: str | None = None,
|
||||
language: str | None = None,
|
||||
model: str | None = None,
|
||||
):
|
||||
self.api_key = api_key or os.environ.get("MY_STT_API_KEY")
|
||||
self.api_base = api_base or "https://api.example.com/v1"
|
||||
self.language = language or None
|
||||
self.model = model or "my-default-stt-model"
|
||||
|
||||
async def transcribe(self, file_path: str | Path) -> str:
|
||||
...
|
||||
```
|
||||
|
||||
4. Register the adapter in `nanobot/audio/transcription_registry.py`.
|
||||
|
||||
```python
|
||||
TranscriptionProviderSpec(
|
||||
name="my_stt",
|
||||
default_model="my-default-stt-model",
|
||||
adapter="nanobot.providers.transcription:MySTTTranscriptionProvider",
|
||||
aliases=("mystt",),
|
||||
)
|
||||
```
|
||||
|
||||
5. Add tests.
|
||||
|
||||
At minimum, cover:
|
||||
|
||||
- config resolution in `tests/providers/test_transcription.py`
|
||||
- adapter request/response behavior and retry/error handling
|
||||
- WebUI settings payload/update behavior in `tests/webui/test_settings_api.py`
|
||||
- provider brand mapping if the provider appears in Settings
|
||||
|
||||
6. Update user-facing docs.
|
||||
|
||||
Add the provider to [`configuration.md`](./configuration.md) where users choose `transcription.provider`, but keep implementation details in this development guide.
|
||||
@@ -0,0 +1,45 @@
|
||||
# nanobot Guides
|
||||
|
||||
These guides are short task entry points. Use them when you know what you want
|
||||
to build, then follow the linked reference docs for complete option tables and
|
||||
edge cases.
|
||||
|
||||
## Build and operate
|
||||
|
||||
| Goal | Guide |
|
||||
|---|---|
|
||||
| Build a personal AI agent | [Build a personal AI agent](./build-a-personal-ai-agent.md) |
|
||||
| Run a self-hosted AI agent | [Self-hosted AI agent](./self-hosted-ai-agent.md) |
|
||||
| Use the browser workbench | [AI agent WebUI](./ai-agent-webui.md) |
|
||||
| Run long-running tasks | [Long-running AI agent](./long-running-ai-agent.md) |
|
||||
| Add memory | [AI agent memory](./ai-agent-memory.md) |
|
||||
| Deploy a gateway | [Deploy a long-running nanobot AI agent gateway](./deploy-nanobot-gateway.md) |
|
||||
|
||||
## Connect and integrate
|
||||
|
||||
| Goal | Guide |
|
||||
|---|---|
|
||||
| Connect chat apps | [Chat app AI agent](./chat-app-ai-agent.md) |
|
||||
| Connect Telegram | [Telegram AI agent](./telegram-ai-agent.md) |
|
||||
| Connect Discord | [Discord AI agent](./discord-ai-agent.md) |
|
||||
| Connect Slack | [Slack AI agent](./slack-ai-agent.md) |
|
||||
| Connect Feishu | [Feishu AI agent](./feishu-ai-agent.md) |
|
||||
| Connect WhatsApp | [WhatsApp AI agent](./whatsapp-ai-agent.md) |
|
||||
| Connect WeChat | [WeChat AI agent](./wechat-ai-agent.md) |
|
||||
| Connect QQ | [QQ AI agent](./qq-ai-agent.md) |
|
||||
| Connect Email | [Email AI agent](./email-ai-agent.md) |
|
||||
| Connect Mattermost | [Mattermost AI agent](./mattermost-ai-agent.md) |
|
||||
| Run from Python | [Python AI agent SDK](./python-ai-agent-sdk.md) |
|
||||
| Expose `/v1/chat/completions` | [OpenAI-compatible agent API](./openai-compatible-agent-api.md) |
|
||||
|
||||
## Configure
|
||||
|
||||
| Goal | Guide |
|
||||
|---|---|
|
||||
| Add MCP tools | [Configure MCP tools](./configure-mcp-tools.md) |
|
||||
| Enable web search | [Configure web search](./configure-web-search.md) |
|
||||
| Add model fallback | [Configure model fallback](./configure-model-fallback.md) |
|
||||
| Add an OpenAI-compatible provider | [Configure an OpenAI-compatible provider](./configure-openai-compatible-provider.md) |
|
||||
| Add Langfuse tracing | [Configure Langfuse observability](./configure-langfuse-observability.md) |
|
||||
| Secure local tools | [Secure a local AI agent](./secure-local-ai-agent.md) |
|
||||
| Deploy the gateway | [Deploy nanobot gateway](./deploy-nanobot-gateway.md) |
|
||||
@@ -0,0 +1,72 @@
|
||||
# How AI Agent Memory Works in nanobot
|
||||
|
||||
This guide explains how to use nanobot's long-term AI agent memory: session
|
||||
history, compressed archives, durable memory files, Dream consolidation, and
|
||||
Git-backed memory changes.
|
||||
|
||||
## What you will build
|
||||
|
||||
- a workspace with persistent session history
|
||||
- compressed history archives for older turns
|
||||
- durable memory files such as `USER.md` and `MEMORY.md`
|
||||
- a Dream workflow for curating long-term memory
|
||||
|
||||
## When to use this
|
||||
|
||||
Use memory when an agent should remember stable preferences, project facts,
|
||||
decisions, and recurring context across sessions. Do not use memory as a dumping
|
||||
ground for every raw transcript; nanobot separates short-term messages from
|
||||
curated durable knowledge.
|
||||
|
||||
## Install
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
## Minimal working example
|
||||
|
||||
Ask the agent to remember a stable fact in a normal session, then run Dream:
|
||||
|
||||
```text
|
||||
/dream
|
||||
```
|
||||
|
||||
Inspect recent memory changes:
|
||||
|
||||
```text
|
||||
/dream-log
|
||||
```
|
||||
|
||||
The exact files live in the active workspace, usually under
|
||||
`~/.nanobot/workspace/`.
|
||||
|
||||
## Production notes
|
||||
|
||||
- Use one workspace per project or personal context.
|
||||
- Keep durable facts concise; old session details belong in `history.jsonl`.
|
||||
- Use `/dream-prompt init` when a workspace needs custom memory guidance.
|
||||
- Review Git-backed memory changes when memory affects important workflows.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Memory files may contain sensitive user or project facts.
|
||||
- Avoid sharing workspaces without reviewing `SOUL.md`, `USER.md`, and
|
||||
`memory/MEMORY.md`.
|
||||
- Use separate workspaces for personal and team contexts.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- If memory feels stale, run `/dream` and inspect `/dream-log`.
|
||||
- If memory changed incorrectly, use `/dream-restore` to inspect and restore
|
||||
previous versions.
|
||||
- If a new session lacks context, confirm it uses the same workspace.
|
||||
|
||||
## Related nanobot docs
|
||||
|
||||
- [AI Agent Memory in nanobot](../memory.md)
|
||||
- [Concepts](../concepts.md)
|
||||
- [Configuration](../configuration.md#auto-compact)
|
||||
- [Chat Commands](../chat-commands.md)
|
||||
@@ -0,0 +1,73 @@
|
||||
# How to Use an AI Agent WebUI with nanobot
|
||||
|
||||
nanobot includes a browser WebUI for persistent chat sessions, visible agent
|
||||
activity, workspace controls, Apps, MCP presets, Skills, settings, and
|
||||
Automations.
|
||||
|
||||
## What you will build
|
||||
|
||||
- a local browser workbench
|
||||
- one persistent chat session
|
||||
- a visible timeline of agent messages, tool calls, and file edit diffs
|
||||
- a gateway-backed WebSocket connection
|
||||
|
||||
## When to use this
|
||||
|
||||
Use the WebUI when you want a local AI agent interface that is easier to operate
|
||||
than a terminal, especially for project work, file attachments, model switching,
|
||||
workspace selection, Apps, Skills, and scheduled automations.
|
||||
|
||||
## Install
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
The published wheel already includes the WebUI bundle. You only need the
|
||||
`webui/` source directory when changing the frontend.
|
||||
|
||||
## Minimal working example
|
||||
|
||||
```bash
|
||||
nanobot webui
|
||||
```
|
||||
|
||||
The launcher checks setup, enables the local WebSocket channel after
|
||||
confirmation, starts the gateway, and opens the browser.
|
||||
|
||||
When nanobot edits a file, the WebUI activity timeline can show the changed
|
||||
line counts, a unified diff, and an **Open file** action for a read-only
|
||||
preview. File previews use the chat's current workspace access mode: restricted
|
||||
access stays inside the selected workspace, while Full Access can preview files
|
||||
outside the workspace when the gateway allows it.
|
||||
|
||||
## Production notes
|
||||
|
||||
- Use `nanobot webui --background` when you do not want to keep a terminal open.
|
||||
- Use `nanobot gateway status`, `logs`, `restart`, and `stop` to manage a
|
||||
background gateway.
|
||||
- If you expose the WebUI beyond localhost, set a token issue secret and review
|
||||
workspace/tool access.
|
||||
|
||||
## Security notes
|
||||
|
||||
- The first-run WebUI path binds to `127.0.0.1` by default.
|
||||
- Do not expose the WebUI on a LAN or public host without an intentional access
|
||||
model.
|
||||
- Keep file and shell tools scoped to the workspace before inviting other users.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- The WebUI is served by the WebSocket channel on port `8765` by default.
|
||||
- The gateway health endpoint is separate from the browser UI.
|
||||
- If the page opens but messages fail, check provider setup with
|
||||
`nanobot agent -m "Hello!"`.
|
||||
|
||||
## Related nanobot docs
|
||||
|
||||
- [Nanobot WebUI](../webui.md)
|
||||
- [Quick Start](../quick-start.md)
|
||||
- [WebSocket protocol](../websocket.md)
|
||||
- [Configuration](../configuration.md)
|
||||
@@ -0,0 +1,83 @@
|
||||
# How to Build a Personal AI Agent with nanobot
|
||||
|
||||
This guide builds a personal AI agent you can run locally, talk to from the
|
||||
terminal or browser, and later connect to chat apps, memory, tools, and
|
||||
automations.
|
||||
|
||||
## What you will build
|
||||
|
||||
- a configured nanobot install
|
||||
- one working model provider
|
||||
- one local agent reply
|
||||
- a browser WebUI session for ongoing work
|
||||
|
||||
## When to use this
|
||||
|
||||
Use this when you want a personal AI agent that you control rather than a hosted
|
||||
chat-only interface. nanobot is useful when the agent needs local workspace
|
||||
access, tool calls, session history, memory, scheduled work, or chat app
|
||||
delivery.
|
||||
|
||||
## Install
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
```
|
||||
|
||||
The wizard creates `~/.nanobot/config.json` and helps you choose a provider and
|
||||
model. If terminals and config files are new to you, use
|
||||
[Start Without Technical Background](../start-without-technical-background.md)
|
||||
instead.
|
||||
|
||||
## Minimal working example
|
||||
|
||||
First prove the runtime can answer:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
Then open the browser workbench:
|
||||
|
||||
```bash
|
||||
nanobot webui
|
||||
```
|
||||
|
||||
The WebUI starts the local gateway, opens a browser, and keeps persistent chat
|
||||
sessions for longer work.
|
||||
|
||||
## Production notes
|
||||
|
||||
- Keep one workspace per project or personal context.
|
||||
- Use `modelPresets` when you want stable names for fast, deep, local, or
|
||||
fallback models.
|
||||
- Keep `nanobot gateway` running for WebUI, chat apps, automations, and the
|
||||
WebSocket channel.
|
||||
- Use the Python SDK or OpenAI-compatible API when another program should call
|
||||
the agent.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Do not store API keys directly in shared files; use environment variables.
|
||||
- Prefer chat app pairing for first setup. Use `allowFrom` only for static
|
||||
allowlists, and keep those lists narrow.
|
||||
- Enable workspace restriction before exposing file or shell tools to other
|
||||
users.
|
||||
- Use a separate workspace for experiments that can modify files.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- `nanobot status` shows the config path, workspace path, and active model.
|
||||
- If `nanobot agent -m "Hello!"` fails, fix provider setup before opening the
|
||||
WebUI or chat apps.
|
||||
- If the WebUI opens but does not answer, check gateway logs and provider
|
||||
credentials.
|
||||
|
||||
## Related nanobot docs
|
||||
|
||||
- [Quick Start](../quick-start.md)
|
||||
- [Concepts](../concepts.md)
|
||||
- [WebUI](../webui.md)
|
||||
- [Configuration](../configuration.md)
|
||||
- [Troubleshooting](../troubleshooting.md)
|
||||
@@ -0,0 +1,94 @@
|
||||
# How to Connect an AI Agent to Chat Apps with nanobot
|
||||
|
||||
nanobot can run as a self-hosted chatbot or AI agent in Telegram, Discord,
|
||||
Slack, WeChat, Email, Mattermost, and other chat apps. The gateway receives chat
|
||||
messages, runs the agent, and sends replies back to the same channel.
|
||||
|
||||
## What you will build
|
||||
|
||||
- a working local agent
|
||||
- one enabled chat channel
|
||||
- a running gateway
|
||||
- a pairing-based approval flow or a narrow static allowlist
|
||||
|
||||
## When to use this
|
||||
|
||||
Use chat apps when the agent should live where users already communicate:
|
||||
private DMs, team channels, group chats, email threads, or bot workspaces.
|
||||
|
||||
## Install
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
Then choose one platform guide:
|
||||
|
||||
- [Telegram AI agent](./telegram-ai-agent.md)
|
||||
- [Discord AI agent](./discord-ai-agent.md)
|
||||
- [Slack AI agent](./slack-ai-agent.md)
|
||||
- [Feishu AI agent](./feishu-ai-agent.md)
|
||||
- [WhatsApp AI agent](./whatsapp-ai-agent.md)
|
||||
- [WeChat AI agent](./wechat-ai-agent.md)
|
||||
- [QQ AI agent](./qq-ai-agent.md)
|
||||
- [Email AI agent](./email-ai-agent.md)
|
||||
- [Mattermost AI agent](./mattermost-ai-agent.md)
|
||||
|
||||
## Minimal working example
|
||||
|
||||
Every channel follows the same pattern:
|
||||
|
||||
1. Get the platform token, login state, webhook, or mailbox credentials.
|
||||
2. Merge the channel snippet into `~/.nanobot/config.json`.
|
||||
3. Prefer pairing for DM-capable channels: omit `allowFrom`, then approve the
|
||||
first DM's pairing code.
|
||||
4. For channels without pairing, such as Email, keep access narrow with
|
||||
`allowFrom` or platform-specific allow lists.
|
||||
5. Check status:
|
||||
|
||||
```bash
|
||||
nanobot channels status
|
||||
```
|
||||
|
||||
6. Start the gateway:
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
7. Send a test DM, approve the pairing code when prompted, then send the test
|
||||
message again.
|
||||
|
||||
## Production notes
|
||||
|
||||
- Keep the gateway running as a service for always-on chat apps.
|
||||
- Use mention-only group policies before opening a bot to busy channels.
|
||||
- Use one channel at a time while debugging.
|
||||
- Prefer DMs for first tests; pairing only works in DMs, and group chats add
|
||||
permissions and routing behavior.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Prefer pairing or explicit allowlists; do not use `allowFrom: ["*"]` outside
|
||||
an intentional sandbox.
|
||||
- Rotate bot tokens if they are pasted into logs or shared files.
|
||||
- Review file, shell, and web tool access before inviting other users.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- If `nanobot channels status` does not show the channel, the config key or
|
||||
optional dependency is likely missing.
|
||||
- If the first DM returns a pairing code, approve it with
|
||||
`/pairing approve <code>` before expecting normal replies.
|
||||
- If messages do not arrive, run `nanobot gateway --verbose` and compare
|
||||
platform credentials, event permissions, and allow lists.
|
||||
- If group replies are unexpected, review that channel's group policy.
|
||||
|
||||
## Related nanobot docs
|
||||
|
||||
- [Chat Apps](../chat-apps.md)
|
||||
- [Configuration](../configuration.md#channel-settings)
|
||||
- [Pairing](../configuration.md#pairing)
|
||||
- [Deployment](../deployment.md)
|
||||
@@ -0,0 +1,79 @@
|
||||
# How to Configure Langfuse Observability for nanobot
|
||||
|
||||
nanobot can trace supported OpenAI-compatible provider calls through Langfuse's
|
||||
OpenAI SDK wrapper.
|
||||
|
||||
## What you will build
|
||||
|
||||
- Langfuse installed in the same Python environment as nanobot
|
||||
- Langfuse environment variables set before startup
|
||||
- one traced nanobot model call
|
||||
|
||||
## When to use this
|
||||
|
||||
Use Langfuse when you need observability for model requests, latency, errors,
|
||||
cost, or prompt behavior during development or production operation.
|
||||
|
||||
## Install
|
||||
|
||||
Install nanobot and prove the agent works:
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
Install Langfuse:
|
||||
|
||||
```bash
|
||||
python -m pip install langfuse
|
||||
```
|
||||
|
||||
## Minimal working example
|
||||
|
||||
Set credentials before starting nanobot:
|
||||
|
||||
```bash
|
||||
export LANGFUSE_SECRET_KEY="sk-lf-..."
|
||||
export LANGFUSE_PUBLIC_KEY="pk-lf-..."
|
||||
export LANGFUSE_BASE_URL="https://cloud.langfuse.com"
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
PowerShell:
|
||||
|
||||
```powershell
|
||||
$env:LANGFUSE_SECRET_KEY = "sk-lf-..."
|
||||
$env:LANGFUSE_PUBLIC_KEY = "pk-lf-..."
|
||||
$env:LANGFUSE_BASE_URL = "https://cloud.langfuse.com"
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
## Production notes
|
||||
|
||||
- Langfuse is configured with environment variables, not `config.json`.
|
||||
- Start services from an environment that exports the same variables.
|
||||
- Add tracing after the provider works; it should not be the first setup step.
|
||||
- Native providers that do not use the OpenAI-compatible client path may not
|
||||
produce Langfuse OpenAI-wrapper traces.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Treat Langfuse projects as observability stores for sensitive prompts and
|
||||
outputs.
|
||||
- Use separate projects for personal, staging, and production traffic.
|
||||
- Keep Langfuse keys out of committed service files.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- If no traces appear, confirm the service process sees the environment
|
||||
variables.
|
||||
- Confirm the provider path is OpenAI-compatible.
|
||||
- Run one local `nanobot agent -m "Hello!"` call before debugging service logs.
|
||||
|
||||
## Related nanobot docs
|
||||
|
||||
- [Configuration: Langfuse Observability](../configuration.md#langfuse-observability)
|
||||
- [Provider Cookbook: Langfuse Tracing](../provider-cookbook.md#recipe-langfuse-tracing)
|
||||
- [Deployment](../deployment.md)
|
||||
@@ -0,0 +1,74 @@
|
||||
# How to Configure MCP Tools in nanobot
|
||||
|
||||
This guide adds an MCP server to nanobot so the agent can use external tools
|
||||
through the Model Context Protocol.
|
||||
|
||||
## What you will build
|
||||
|
||||
- a working nanobot agent
|
||||
- one MCP server entry in `~/.nanobot/config.json`
|
||||
- a restricted set of MCP tools exposed to the model
|
||||
|
||||
## When to use this
|
||||
|
||||
Use MCP when the capability you need already exists as an MCP server, or when
|
||||
you want external tools to be managed outside nanobot core.
|
||||
|
||||
## Install
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
Install the MCP server runtime separately. Many examples use `npx`, `uvx`, or a
|
||||
remote HTTP endpoint.
|
||||
|
||||
## Minimal working example
|
||||
|
||||
Add this to `~/.nanobot/config.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"tools": {
|
||||
"mcpServers": {
|
||||
"filesystem": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"],
|
||||
"enabledTools": ["read_file"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Restart nanobot and ask a question that requires the MCP tool.
|
||||
|
||||
## Production notes
|
||||
|
||||
- Prefer `enabledTools` over exposing every tool by default.
|
||||
- Use `toolTimeout` for slow MCP operations.
|
||||
- Use HTTP MCP only for endpoints you trust.
|
||||
- Keep MCP server commands stable and versioned in deployment docs or scripts.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Stdio MCP starts a local process; review the command before enabling it.
|
||||
- HTTP/SSE MCP uses nanobot's SSRF guard.
|
||||
- Allow private HTTP MCP hosts only with narrow `tools.ssrfWhitelist` CIDRs.
|
||||
- Do not place secrets in command arguments when environment variables or
|
||||
headers can be used.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- Run the MCP command outside nanobot first.
|
||||
- Start `nanobot gateway --verbose` and inspect tool registration logs.
|
||||
- If an HTTP MCP URL is blocked, check whether it points to loopback or a
|
||||
private address that needs explicit allowlisting.
|
||||
|
||||
## Related nanobot docs
|
||||
|
||||
- [MCP tools for AI agents](./mcp-tools-for-ai-agents.md)
|
||||
- [Configuration: MCP](../configuration.md#mcp-model-context-protocol)
|
||||
- [Security](../configuration.md#security)
|
||||
@@ -0,0 +1,93 @@
|
||||
# How to Configure Model Fallback in nanobot
|
||||
|
||||
Model fallback lets nanobot try a primary model first, then fall back to one or
|
||||
more named presets when the primary provider fails or rate-limits.
|
||||
|
||||
## What you will build
|
||||
|
||||
- two or more `modelPresets`
|
||||
- a primary `agents.defaults.modelPreset`
|
||||
- an ordered `agents.defaults.fallbackModels` chain
|
||||
|
||||
## When to use this
|
||||
|
||||
Use fallback when you want better reliability across rate limits, provider
|
||||
outages, local model downtime, or cost-sensitive routing.
|
||||
|
||||
## Install
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
Verify each provider works before adding it as a fallback.
|
||||
|
||||
## Minimal working example
|
||||
|
||||
Merge this shape into `~/.nanobot/config.json` and replace provider/model names
|
||||
with ones you control:
|
||||
|
||||
```json
|
||||
{
|
||||
"modelPresets": {
|
||||
"fast": {
|
||||
"label": "Fast",
|
||||
"provider": "primary-provider",
|
||||
"model": "primary-model-id",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 65536,
|
||||
"temperature": 0.1
|
||||
},
|
||||
"deep": {
|
||||
"label": "Deep",
|
||||
"provider": "fallback-provider",
|
||||
"model": "fallback-model-id",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 200000,
|
||||
"temperature": 0.1
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "fast",
|
||||
"fallbackModels": ["deep"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
String entries in `fallbackModels` are preset names, not raw model IDs.
|
||||
Replace the placeholder model IDs with currently supported model IDs from your
|
||||
provider. The [Provider Cookbook](../provider-cookbook.md) has concrete recipes
|
||||
for common providers.
|
||||
|
||||
## Production notes
|
||||
|
||||
- Keep fallback context windows realistic; smaller fallback windows constrain
|
||||
how much context can fit.
|
||||
- Put cheaper or faster fallbacks before expensive ones when acceptable.
|
||||
- Use `/model <preset>` for runtime switching without editing config.
|
||||
- Keep labels human-readable for WebUI model lists.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Different providers may have different data handling policies.
|
||||
- Do not put provider keys directly in shared config files.
|
||||
- Confirm fallback models can safely receive the same prompts and files.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- If a fallback never triggers, confirm the primary error is treated as
|
||||
retryable/fallbackable.
|
||||
- If startup fails, check that each fallback string matches a key under
|
||||
`modelPresets`.
|
||||
- If output is truncated after fallback, review `maxTokens` and
|
||||
`contextWindowTokens`.
|
||||
|
||||
## Related nanobot docs
|
||||
|
||||
- [Providers and Models](../providers.md)
|
||||
- [Provider Cookbook: Fallback Presets](../provider-cookbook.md#recipe-fallback-presets)
|
||||
- [Configuration: Model Fallbacks](../configuration.md#model-fallbacks)
|
||||
@@ -0,0 +1,93 @@
|
||||
# How to Configure an OpenAI-Compatible Provider in nanobot
|
||||
|
||||
nanobot can call OpenAI-compatible model providers by configuring an `apiBase`,
|
||||
optional `apiKey`, and a model preset that references that provider name.
|
||||
|
||||
## What you will build
|
||||
|
||||
- a custom provider entry
|
||||
- a model preset pointing at that provider
|
||||
- one successful `nanobot agent` run
|
||||
|
||||
## When to use this
|
||||
|
||||
Use this for local or hosted services that expose OpenAI-compatible endpoints,
|
||||
including internal gateways, local model servers, and provider proxies that are
|
||||
not already named in nanobot.
|
||||
|
||||
## Install
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
```
|
||||
|
||||
Verify the endpoint responds before debugging nanobot:
|
||||
|
||||
```bash
|
||||
curl -sS https://api.example.com/v1/models
|
||||
```
|
||||
|
||||
## Minimal working example
|
||||
|
||||
Merge this into `~/.nanobot/config.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"custom": {
|
||||
"apiKey": "${CUSTOM_API_KEY}",
|
||||
"apiBase": "https://api.example.com/v1"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"label": "Custom",
|
||||
"provider": "custom",
|
||||
"model": "provider-model-name",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 65536,
|
||||
"temperature": 0.1
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Then run:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
## Production notes
|
||||
|
||||
- Include the version path in `apiBase` when the service expects `/v1`.
|
||||
- Use separate provider names for separate endpoints.
|
||||
- Use a placeholder key such as `EMPTY` only when the endpoint requires a
|
||||
non-empty key but does not validate it.
|
||||
- Leave `apiType` unset for OpenAI-compatible custom endpoints.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Keep provider keys in environment variables.
|
||||
- Treat internal model gateways as sensitive network services.
|
||||
- Do not point nanobot at untrusted proxy endpoints for private workspaces.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- If `curl /models` fails, fix the provider endpoint before changing nanobot.
|
||||
- If nanobot says the model is unknown, check the model ID expected by the
|
||||
provider.
|
||||
- If auth fails, confirm whether the provider wants Bearer auth and whether the
|
||||
key is present in the environment that starts nanobot.
|
||||
|
||||
## Related nanobot docs
|
||||
|
||||
- [Provider Cookbook: Custom OpenAI-Compatible Provider](../provider-cookbook.md#recipe-custom-openai-compatible-provider)
|
||||
- [Providers: Custom OpenAI-Compatible Endpoint](../providers.md#custom-openai-compatible-endpoint)
|
||||
- [OpenAI-Compatible Agent API](./openai-compatible-agent-api.md)
|
||||
@@ -0,0 +1,90 @@
|
||||
# How to Configure Web Search for a nanobot AI Agent
|
||||
|
||||
nanobot includes built-in web search and web fetch tools. Search uses
|
||||
DuckDuckGo by default and can be configured for API-backed or self-hosted
|
||||
providers.
|
||||
|
||||
## What you will build
|
||||
|
||||
- web tools enabled in nanobot
|
||||
- one search provider selected in `config.json`
|
||||
- optional web fetch settings for page reading
|
||||
|
||||
## When to use this
|
||||
|
||||
Configure web search when the agent needs current information, public web
|
||||
research, source discovery, or page fetching during a task.
|
||||
|
||||
## Install
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
Web tools are enabled by default. Configure them only when you want a specific
|
||||
provider, API key, proxy, fetch behavior, or SSRF allowlist.
|
||||
|
||||
## Minimal working example
|
||||
|
||||
Use the default search provider:
|
||||
|
||||
```json
|
||||
{
|
||||
"tools": {
|
||||
"web": {
|
||||
"enable": true,
|
||||
"search": {
|
||||
"provider": "duckduckgo"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Or use an API-backed provider:
|
||||
|
||||
```json
|
||||
{
|
||||
"tools": {
|
||||
"web": {
|
||||
"search": {
|
||||
"provider": "brave",
|
||||
"apiKey": "${BRAVE_API_KEY}"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Ask a question that requires current information and inspect the tool activity
|
||||
in the WebUI or logs.
|
||||
|
||||
## Production notes
|
||||
|
||||
- Keep API keys in environment variables.
|
||||
- Set `maxResults` when you need fewer or more search results per query.
|
||||
- Set `tools.web.proxy` only to a proxy you trust.
|
||||
- Use `fetch.useJinaReader: false` if you need local page conversion.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Web fetch and HTTP MCP share an SSRF guard.
|
||||
- Private, loopback, link-local, and cloud metadata addresses are blocked by
|
||||
default.
|
||||
- Add `tools.ssrfWhitelist` only for narrow trusted CIDRs.
|
||||
- Do not give public chat users unrestricted web and shell access without
|
||||
review.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- If search returns no results, switch provider or check the provider API key.
|
||||
- If fetch is blocked, inspect the target URL and SSRF whitelist.
|
||||
- If a proxy changes network behavior, verify `NO_PROXY` and proxy settings.
|
||||
|
||||
## Related nanobot docs
|
||||
|
||||
- [Configuration: Web Tools](../configuration.md#web-tools)
|
||||
- [Security](../configuration.md#security)
|
||||
- [WebUI](../webui.md)
|
||||
@@ -0,0 +1,76 @@
|
||||
# How to Deploy a Long-Running nanobot AI Agent Gateway
|
||||
|
||||
The nanobot gateway is the long-running self-hosted AI agent process that keeps
|
||||
WebUI sessions, chat apps, automations, local triggers, heartbeat jobs, Dream,
|
||||
and WebSocket delivery online.
|
||||
|
||||
## What you will build
|
||||
|
||||
- a verified nanobot config
|
||||
- a gateway process
|
||||
- a service or container deployment path with Docker, systemd, or macOS
|
||||
LaunchAgent
|
||||
|
||||
## When to use this
|
||||
|
||||
Use this when nanobot should keep running after a single CLI turn. Chat apps,
|
||||
browser sessions, background automations, local triggers, and server-side
|
||||
integrations all depend on a live gateway.
|
||||
|
||||
## Install
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
nanobot status
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
## Minimal working example
|
||||
|
||||
Run the gateway in the foreground:
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
For WebUI background usage:
|
||||
|
||||
```bash
|
||||
nanobot webui --background
|
||||
nanobot gateway status
|
||||
nanobot gateway logs
|
||||
```
|
||||
|
||||
## Production notes
|
||||
|
||||
- Docker Compose is the most repeatable Linux container path.
|
||||
- systemd user services are useful for Linux user-level gateway deployments.
|
||||
- macOS LaunchAgent keeps the gateway alive after login.
|
||||
- Persist config, workspace, sessions, memory files, channel login state, and
|
||||
generated artifacts.
|
||||
- Restart the gateway after editing `config.json`.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Plan ports before exposing services. Gateway health defaults to `18790`,
|
||||
WebUI/WebSocket defaults to `8765`, and `nanobot serve` defaults to `8900`.
|
||||
- Bind externally only when you have configured tokens or API keys.
|
||||
- Keep chat access control intentional before deploying.
|
||||
- Use Docker or Linux sandboxing when shell tools are enabled for unattended
|
||||
work.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- Use the same `--config` and `--workspace` flags for status checks and service
|
||||
startup.
|
||||
- Check logs with `docker compose logs`, `journalctl`, LaunchAgent logs, or
|
||||
`nanobot gateway --verbose`.
|
||||
- If Docker port publishing does not work, confirm the service is not bound only
|
||||
to container loopback.
|
||||
|
||||
## Related nanobot docs
|
||||
|
||||
- [Deployment](../deployment.md)
|
||||
- [Multiple Instances](../multiple-instances.md)
|
||||
- [Configuration](../configuration.md)
|
||||
@@ -0,0 +1,107 @@
|
||||
# Build a Discord AI Agent with nanobot
|
||||
|
||||
This guide connects nanobot to Discord so a Discord user or server channel can
|
||||
talk to your self-hosted AI agent through the nanobot gateway.
|
||||
|
||||
## What this guide builds
|
||||
|
||||
- a Discord bot application
|
||||
- Message Content intent enabled
|
||||
- the `discord` channel enabled in nanobot
|
||||
- one direct message or mention test
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- A working local nanobot reply:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
- Access to the Discord Developer Portal.
|
||||
- A Discord server where you can invite a bot.
|
||||
|
||||
## Install nanobot
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
```
|
||||
|
||||
## Enable the Discord channel
|
||||
|
||||
Install the optional channel dependency:
|
||||
|
||||
```bash
|
||||
nanobot plugins enable discord
|
||||
```
|
||||
|
||||
Create a Discord application, add a bot, copy the token, and enable
|
||||
`MESSAGE CONTENT INTENT` in the bot settings.
|
||||
|
||||
Merge this snippet into `~/.nanobot/config.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"discord": {
|
||||
"enabled": true,
|
||||
"token": "YOUR_BOT_TOKEN",
|
||||
"allowChannels": [],
|
||||
"groupPolicy": "mention",
|
||||
"streaming": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Omitting `allowFrom` enables pairing-only mode. A new user should DM the bot
|
||||
first, get a pairing code, and be approved before using the bot in servers.
|
||||
|
||||
Invite the bot with permissions to read history and send messages.
|
||||
|
||||
## Run nanobot gateway
|
||||
|
||||
```bash
|
||||
nanobot channels status
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
## Test a message
|
||||
|
||||
Send the bot a DM first. It should return a pairing code. Approve it from a
|
||||
trusted local surface:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "/pairing approve ABCD-EFGH"
|
||||
```
|
||||
|
||||
After approval, mention it in an allowed server channel:
|
||||
|
||||
```text
|
||||
@your-bot Hello from Discord
|
||||
```
|
||||
|
||||
## Security notes
|
||||
|
||||
- Keep `groupPolicy` as `mention` for first deployment.
|
||||
- Use `allowChannels` for server channels where the bot should operate.
|
||||
- Prefer pairing-only mode for user access; add `allowFrom` only when you want a
|
||||
static allowlist.
|
||||
- Avoid open group behavior in busy channels until session routing is clear.
|
||||
- Review tool access before inviting the bot into shared servers.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- If no messages arrive, confirm Message Content intent is enabled.
|
||||
- If a DM returns a pairing code, approve it before testing normal replies.
|
||||
- If server messages are ignored, check pairing approval, `allowChannels`, and
|
||||
whether the bot was mentioned.
|
||||
- If the bot cannot reply, confirm the invite permissions and channel overrides.
|
||||
|
||||
## Next: memory, automations, MCP tools
|
||||
|
||||
- [Chat Apps reference](../chat-apps.md)
|
||||
- [Pairing](../configuration.md#pairing)
|
||||
- [AI Agent Memory](./ai-agent-memory.md)
|
||||
- [Configure MCP tools](./configure-mcp-tools.md)
|
||||
@@ -0,0 +1,93 @@
|
||||
# Build an Email AI Agent with nanobot
|
||||
|
||||
This guide turns nanobot into an email AI agent that polls IMAP for accepted
|
||||
messages and replies through SMTP.
|
||||
|
||||
## What this guide builds
|
||||
|
||||
- a dedicated mailbox for nanobot
|
||||
- IMAP and SMTP credentials in `config.json`
|
||||
- an allowed sender list
|
||||
- a gateway process that polls and replies
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- A working local nanobot reply:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
- A mailbox for the bot.
|
||||
- IMAP and SMTP access. For Gmail, use an app password rather than your account
|
||||
password.
|
||||
|
||||
## Install nanobot
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
```
|
||||
|
||||
## Enable the Email channel
|
||||
|
||||
Merge this snippet into `~/.nanobot/config.json` and replace the addresses and
|
||||
passwords:
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"email": {
|
||||
"enabled": true,
|
||||
"consentGranted": true,
|
||||
"imapHost": "imap.gmail.com",
|
||||
"imapPort": 993,
|
||||
"imapUsername": "my-nanobot@gmail.com",
|
||||
"imapPassword": "your-app-password",
|
||||
"smtpHost": "smtp.gmail.com",
|
||||
"smtpPort": 587,
|
||||
"smtpUsername": "my-nanobot@gmail.com",
|
||||
"smtpPassword": "your-app-password",
|
||||
"fromAddress": "my-nanobot@gmail.com",
|
||||
"allowFrom": ["your-real-email@gmail.com"],
|
||||
"autoReplyEnabled": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Run nanobot gateway
|
||||
|
||||
```bash
|
||||
nanobot channels status
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
## Test a message
|
||||
|
||||
Send an email from an address in `allowFrom` to the bot mailbox. Keep the
|
||||
gateway running long enough for the polling interval to receive it.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Use a dedicated mailbox, not your primary personal inbox.
|
||||
- Set `consentGranted` to `false` to fully disable mailbox access.
|
||||
- Email does not use DM pairing. Keep `allowFrom` narrow; `["*"]` accepts mail
|
||||
from anyone.
|
||||
- Use environment variables for mailbox passwords.
|
||||
- Enable attachment types only when the agent needs them.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- If login fails, confirm IMAP/SMTP access and app-password setup.
|
||||
- If the bot reads but does not reply, check `autoReplyEnabled`, SMTP settings,
|
||||
and allowed sender addresses.
|
||||
- If attachments are missing, review `allowedAttachmentTypes`, size limits, and
|
||||
gateway logs.
|
||||
|
||||
## Next: memory, automations, MCP tools
|
||||
|
||||
- [Chat Apps reference](../chat-apps.md)
|
||||
- [Secure local AI agent](./secure-local-ai-agent.md)
|
||||
- [AI Agent Memory](./ai-agent-memory.md)
|
||||
- [OpenAI-compatible agent API](./openai-compatible-agent-api.md)
|
||||
@@ -0,0 +1,120 @@
|
||||
# Build a Feishu AI Agent with nanobot
|
||||
|
||||
This guide connects nanobot to Feishu or Lark through the `feishu` channel. The
|
||||
channel uses a WebSocket long connection, so the first setup does not require a
|
||||
public webhook URL.
|
||||
|
||||
## What this guide builds
|
||||
|
||||
- a Feishu/Lark bot app connected to nanobot
|
||||
- the `feishu` channel enabled in `config.json`
|
||||
- one pairing-approved Feishu or Lark user
|
||||
- mention-only group behavior for first deployment
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- A working local nanobot reply:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
- A Feishu or Lark account that can create or approve bot apps.
|
||||
- Permission to run `nanobot gateway` continuously.
|
||||
|
||||
## Install nanobot
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
```
|
||||
|
||||
## Enable the Feishu channel
|
||||
|
||||
Install the optional channel dependency:
|
||||
|
||||
```bash
|
||||
nanobot plugins enable feishu
|
||||
```
|
||||
|
||||
The easiest path is QR login:
|
||||
|
||||
```bash
|
||||
nanobot channels login feishu
|
||||
```
|
||||
|
||||
Open the printed URL or scan the QR code. nanobot writes the generated `appId`,
|
||||
`appSecret`, `domain`, and `enabled` fields into the active config.
|
||||
|
||||
If QR login is unavailable, create a Feishu/Lark app manually and merge this
|
||||
shape into `~/.nanobot/config.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"feishu": {
|
||||
"enabled": true,
|
||||
"appId": "cli_xxx",
|
||||
"appSecret": "xxx",
|
||||
"groupPolicy": "mention",
|
||||
"streaming": true,
|
||||
"domain": "feishu"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Omitting `allowFrom` enables pairing-only mode. A new user should DM the bot,
|
||||
get a pairing code, and be approved before using the bot normally.
|
||||
|
||||
For manual apps, enable the Bot capability, receive-message events, and Long
|
||||
Connection mode. If your app cannot get the `cardkit:card:write` permission,
|
||||
set `"streaming": false`.
|
||||
|
||||
## Run nanobot gateway
|
||||
|
||||
```bash
|
||||
nanobot channels status
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
## Test a message
|
||||
|
||||
DM the bot first. It should return a pairing code. Approve it from a trusted
|
||||
local surface:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "/pairing approve ABCD-EFGH"
|
||||
```
|
||||
|
||||
After approval, DM the bot again or mention it in a group chat:
|
||||
|
||||
```text
|
||||
@nanobot Hello from Feishu
|
||||
```
|
||||
|
||||
## Security notes
|
||||
|
||||
- Prefer pairing-only mode for first setup. Add `allowFrom` only when you want a
|
||||
static allowlist.
|
||||
- Keep `groupPolicy` as `"mention"` before inviting the bot into busy groups.
|
||||
- Store app secrets through environment variables for deployed services.
|
||||
- Review file, shell, and web tool access before adding more users.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- If QR login is unavailable, use manual app setup from the full chat-apps
|
||||
reference.
|
||||
- If streaming cards fail, confirm `cardkit:card:write` or set
|
||||
`"streaming": false`.
|
||||
- If no messages arrive, check Feishu/Lark event permissions, Long Connection
|
||||
mode, and `nanobot gateway --verbose`.
|
||||
- If a first DM returns a pairing code, approve it before testing normal
|
||||
replies.
|
||||
|
||||
## Next: memory, automations, MCP tools
|
||||
|
||||
- [Chat Apps reference](../chat-apps.md)
|
||||
- [Pairing](../configuration.md#pairing)
|
||||
- [AI Agent Memory](./ai-agent-memory.md)
|
||||
- [Configure MCP tools](./configure-mcp-tools.md)
|
||||
@@ -0,0 +1,73 @@
|
||||
# How to Run a Long-Running AI Agent with nanobot
|
||||
|
||||
nanobot can keep agent work alive across turns through sustained goals,
|
||||
persistent sessions, scheduled automations, local triggers, and a gateway
|
||||
process that stays running.
|
||||
|
||||
## What you will build
|
||||
|
||||
- a working local agent
|
||||
- a persistent chat session
|
||||
- a long-running goal or automation
|
||||
- a gateway process for background delivery
|
||||
|
||||
## When to use this
|
||||
|
||||
Use this when the task is not a one-shot answer: project work, recurring checks,
|
||||
scheduled summaries, file maintenance, multi-step research, or local triggers
|
||||
from scripts and build jobs.
|
||||
|
||||
## Install
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
## Minimal working example
|
||||
|
||||
Start a gateway:
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
From the WebUI or a chat session, start a sustained goal:
|
||||
|
||||
```text
|
||||
/goal Review this workspace, identify missing tests, and propose the smallest next fix.
|
||||
```
|
||||
|
||||
For scheduled or trigger-based runs, create the automation from the target chat
|
||||
so nanobot can link it to the correct session and workspace.
|
||||
|
||||
## Production notes
|
||||
|
||||
- Keep the gateway running for chat apps, WebUI sessions, automations, and local
|
||||
triggers.
|
||||
- Use stable session keys or chat sessions for work that should preserve context.
|
||||
- Keep goals bounded and explicit about done-ness.
|
||||
- Review Automations in the WebUI before relying on a schedule.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Treat long-running goals as delegated work with real tool access.
|
||||
- Restrict workspaces and shell execution before scheduling unattended tasks.
|
||||
- Keep chat access narrow so unknown users cannot create goals or automations.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- If a goal appears stuck, inspect the active session and gateway logs.
|
||||
- If an automation does not run, check that it is linked to a chat/session and
|
||||
that the gateway is still running.
|
||||
- If a local trigger fails, check the command copied from the WebUI Automations
|
||||
view.
|
||||
|
||||
## Related nanobot docs
|
||||
|
||||
- [Automations](../automations.md)
|
||||
- [WebUI Automations](../webui.md#automations)
|
||||
- [Chat Commands](../chat-commands.md)
|
||||
- [Memory](../memory.md)
|
||||
- [Deployment](../deployment.md)
|
||||
@@ -0,0 +1,104 @@
|
||||
# Build a Mattermost AI Agent with nanobot
|
||||
|
||||
This guide connects nanobot to Mattermost through the built-in Mattermost
|
||||
channel, using WebSocket events and the Mattermost REST API.
|
||||
|
||||
## What this guide builds
|
||||
|
||||
- a Mattermost bot account or token
|
||||
- the `mattermost` channel enabled in nanobot
|
||||
- mention-only group behavior for first deployment
|
||||
- one pairing-approved DM or mention test
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- A working local nanobot reply:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
- A Mattermost server URL.
|
||||
- A bot token or personal access token for the bot account.
|
||||
|
||||
## Install nanobot
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
```
|
||||
|
||||
## Enable the Mattermost channel
|
||||
|
||||
Merge this snippet into `~/.nanobot/config.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"mattermost": {
|
||||
"enabled": true,
|
||||
"serverUrl": "https://mattermost.example.com",
|
||||
"token": "YOUR_MATTERMOST_TOKEN",
|
||||
"teamId": "YOUR_TEAM_ID",
|
||||
"groupPolicy": "mention",
|
||||
"replyInThread": true,
|
||||
"dm": {
|
||||
"policy": "allowlist"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`teamId` scopes the channel to a Mattermost team. Keep `groupPolicy` as
|
||||
`mention` for the first test.
|
||||
|
||||
Mattermost DMs are open by default. Setting `dm.policy` to `"allowlist"` with no
|
||||
`dm.allowFrom` entries makes new DM senders receive a pairing code. Approve the
|
||||
code before using the bot normally.
|
||||
|
||||
## Run nanobot gateway
|
||||
|
||||
```bash
|
||||
nanobot channels status
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
## Test a message
|
||||
|
||||
DM the bot account. It should return a pairing code. Approve it from a trusted
|
||||
local surface:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "/pairing approve ABCD-EFGH"
|
||||
```
|
||||
|
||||
Then DM the bot again, or mention it in a channel where the bot has access:
|
||||
|
||||
```text
|
||||
@nanobot Hello from Mattermost
|
||||
```
|
||||
|
||||
## Security notes
|
||||
|
||||
- Store the Mattermost token in an environment variable for deployed services.
|
||||
- Keep `dm.policy` as `"allowlist"` when you want pairing-based approval.
|
||||
- Use mention-only group behavior before opening the bot to busy channels.
|
||||
- Review file and shell tools before inviting broad channel access.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- If startup logs say `serverUrl and token must be configured`, check the
|
||||
camelCase config keys.
|
||||
- If DMs are ignored, review the `dm` policy and pairing approval state.
|
||||
- If channel messages are ignored, confirm the bot is mentioned and belongs to
|
||||
the team/channel.
|
||||
- If thread replies are surprising, review `replyInThread` and
|
||||
`includeThreadContext`.
|
||||
|
||||
## Next: memory, automations, MCP tools
|
||||
|
||||
- [Chat Apps reference](../chat-apps.md)
|
||||
- [Pairing](../configuration.md#pairing)
|
||||
- [Long-running AI Agent](./long-running-ai-agent.md)
|
||||
- [Deployment](../deployment.md)
|
||||
@@ -0,0 +1,75 @@
|
||||
# How to Add MCP Tools to an AI Agent with nanobot
|
||||
|
||||
nanobot can connect MCP servers and expose their tools to the agent alongside
|
||||
built-in file, shell, web, cron, image generation, and subagent tools.
|
||||
|
||||
## What you will build
|
||||
|
||||
- a working nanobot agent
|
||||
- one MCP server configured in `config.json`
|
||||
- a restricted set of tools available to the model
|
||||
|
||||
## When to use this
|
||||
|
||||
Use MCP when a tool already exists as an MCP server, when another application
|
||||
publishes an MCP adapter, or when you want a clean boundary between nanobot and
|
||||
external tool logic.
|
||||
|
||||
## Install
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
Install the MCP server's own runtime separately. For example, many local MCP
|
||||
servers use `npx` or `uvx`.
|
||||
|
||||
## Minimal working example
|
||||
|
||||
Add a stdio MCP server to `~/.nanobot/config.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"tools": {
|
||||
"mcpServers": {
|
||||
"filesystem": {
|
||||
"command": "npx",
|
||||
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/dir"],
|
||||
"enabledTools": ["read_file"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Restart nanobot, then ask a question that needs the MCP tool.
|
||||
|
||||
## Production notes
|
||||
|
||||
- Use `enabledTools` to expose only the tools the agent actually needs.
|
||||
- Set `toolTimeout` for slow MCP servers.
|
||||
- Prefer stdio MCP for local tools and HTTP MCP for trusted remote services.
|
||||
- Keep MCP server install/update steps outside nanobot config when possible.
|
||||
|
||||
## Security notes
|
||||
|
||||
- HTTP/SSE MCP URLs use the same SSRF guard as web fetch.
|
||||
- Local/private HTTP endpoints require an explicit `tools.ssrfWhitelist` entry.
|
||||
- Stdio MCP servers run local processes; review their command and arguments.
|
||||
- Do not pass secrets in command-line args when environment variables or headers
|
||||
are available.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- Start `nanobot gateway --verbose` and check MCP startup logs.
|
||||
- Confirm the MCP command works by itself before debugging nanobot.
|
||||
- If an HTTP MCP server is blocked, review the SSRF whitelist and use a narrow
|
||||
host CIDR.
|
||||
|
||||
## Related nanobot docs
|
||||
|
||||
- [Configure MCP tools](./configure-mcp-tools.md)
|
||||
- [Configuration: MCP](../configuration.md#mcp-model-context-protocol)
|
||||
- [Security](../configuration.md#security)
|
||||
@@ -0,0 +1,74 @@
|
||||
# How to Run an OpenAI-Compatible Agent API with nanobot
|
||||
|
||||
nanobot can expose a local OpenAI-compatible endpoint behind
|
||||
`/v1/chat/completions`. This lets existing OpenAI-style clients talk to a
|
||||
tool-using nanobot agent instead of a raw model.
|
||||
|
||||
## What you will build
|
||||
|
||||
- a working nanobot agent
|
||||
- a local API server on `127.0.0.1:8900`
|
||||
- a `/v1/chat/completions` request
|
||||
- optional session isolation with `session_id`
|
||||
|
||||
## When to use this
|
||||
|
||||
Use this when an existing client, another language, or a separate process
|
||||
already knows how to call an OpenAI-compatible API. Use the Python SDK when you
|
||||
want in-process access to sessions, memory, runtime helpers, and hooks.
|
||||
|
||||
## Install
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot plugins enable api
|
||||
nanobot onboard --wizard
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
## Minimal working example
|
||||
|
||||
Start the API server:
|
||||
|
||||
```bash
|
||||
nanobot serve
|
||||
```
|
||||
|
||||
Call the chat endpoint:
|
||||
|
||||
```bash
|
||||
curl http://127.0.0.1:8900/v1/chat/completions \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"messages": [{"role": "user", "content": "hi"}],
|
||||
"session_id": "demo"
|
||||
}'
|
||||
```
|
||||
|
||||
## Production notes
|
||||
|
||||
- Pass `session_id` to isolate users, jobs, or workflows.
|
||||
- Streaming uses Server-Sent Events when `stream` is `true`.
|
||||
- `/v1/models` reports the fixed model surface expected by compatible clients.
|
||||
- File uploads are supported through JSON base64 or multipart form data.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Local `127.0.0.1` usage does not require an API key.
|
||||
- If `api.host` is `0.0.0.0` or `::`, configure `api.apiKey` before startup.
|
||||
- Treat the API as agent access, not just model access: tools and workspace
|
||||
permissions still matter.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- If `/v1/chat/completions` fails, test `nanobot agent -m "Hello!"` first.
|
||||
- If remote clients cannot connect, check `api.host`, `api.port`, firewall, and
|
||||
API key configuration.
|
||||
- If sessions mix together, pass unique `session_id` values.
|
||||
|
||||
## Related nanobot docs
|
||||
|
||||
- [Nanobot OpenAI-Compatible API](../openai-api.md)
|
||||
- [Python SDK](../python-sdk.md)
|
||||
- [Configuration](../configuration.md)
|
||||
- [Deployment](../deployment.md)
|
||||
@@ -0,0 +1,75 @@
|
||||
# Nanobot Python SDK: Run an AI Agent from Python
|
||||
|
||||
This guide shows when to use the Nanobot Python SDK instead of calling a model
|
||||
directly. The SDK runs the same agent runtime used by the CLI: model routing,
|
||||
tools, workspace access, session history, memory, streaming events, and runtime
|
||||
helpers.
|
||||
|
||||
## What you will build
|
||||
|
||||
- a Python script that creates a `Nanobot`
|
||||
- one agent run from code
|
||||
- an optional streamed run with tool visibility
|
||||
|
||||
## When to use this
|
||||
|
||||
Use the Python SDK for notebooks, evals, product backends, local scripts,
|
||||
workflow runners, and integrations that need direct access to agent sessions,
|
||||
memory, hooks, runtime state, or structured run results.
|
||||
|
||||
Use the OpenAI-compatible API instead when another language or process should
|
||||
call nanobot over HTTP.
|
||||
|
||||
## Install
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
## Minimal working example
|
||||
|
||||
```python
|
||||
import asyncio
|
||||
|
||||
from nanobot import Nanobot
|
||||
|
||||
|
||||
async def main() -> None:
|
||||
async with Nanobot.from_config() as bot:
|
||||
result = await bot.run("List the top-level files in this workspace.")
|
||||
print(result.content)
|
||||
|
||||
|
||||
asyncio.run(main())
|
||||
```
|
||||
|
||||
## Production notes
|
||||
|
||||
- Reuse one `Nanobot` instance for related work.
|
||||
- Pass `session_key` when a user, job, or eval case needs persistent history.
|
||||
- Use `bot.stream(...)` when the caller needs live text, tool, or failure
|
||||
events.
|
||||
- Use hooks for audit logs or custom observability.
|
||||
|
||||
## Security notes
|
||||
|
||||
- The SDK uses the same config, workspace, tools, and secrets as the CLI.
|
||||
- Do not run untrusted prompts with broad file or shell access.
|
||||
- Keep separate config/workspace paths for separate products or tenants.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- If SDK code fails, first run `nanobot agent -m "Hello!"` in the same
|
||||
environment.
|
||||
- Print `bot.runtime.workspace` and `bot.runtime.model` to confirm the expected
|
||||
config loaded.
|
||||
- Use explicit `config_path` and `workspace` when scripts run from services.
|
||||
|
||||
## Related nanobot docs
|
||||
|
||||
- [Nanobot Python SDK](../python-sdk.md)
|
||||
- [OpenAI-Compatible API](../openai-api.md)
|
||||
- [Configuration](../configuration.md)
|
||||
- [Concepts](../concepts.md)
|
||||
@@ -0,0 +1,102 @@
|
||||
# Build a QQ AI Agent with nanobot
|
||||
|
||||
This guide connects nanobot to QQ through the official `qq` channel. The
|
||||
official channel uses the botpy SDK and currently focuses on private messages.
|
||||
For QQ group chat and OneBot v11 workflows, use the Napcat section in the full
|
||||
chat-apps reference.
|
||||
|
||||
## What this guide builds
|
||||
|
||||
- a QQ bot application
|
||||
- the `qq` channel enabled in nanobot
|
||||
- one pairing-approved QQ private sender
|
||||
- a running nanobot gateway
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- A working local nanobot reply:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
- Access to the QQ Open Platform.
|
||||
- A QQ account added to the bot sandbox for testing.
|
||||
|
||||
## Install nanobot
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
```
|
||||
|
||||
## Enable the QQ channel
|
||||
|
||||
Install the optional channel dependency:
|
||||
|
||||
```bash
|
||||
nanobot plugins enable qq
|
||||
```
|
||||
|
||||
In the QQ Open Platform, create a bot application and copy the AppID and
|
||||
AppSecret. Add your QQ account to the sandbox test members, then merge this
|
||||
snippet into `~/.nanobot/config.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"qq": {
|
||||
"enabled": true,
|
||||
"appId": "YOUR_APP_ID",
|
||||
"secret": "YOUR_APP_SECRET",
|
||||
"msgFormat": "plain"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Omitting `allowFrom` enables pairing-only mode. A new private sender should get
|
||||
a pairing code before normal agent access.
|
||||
|
||||
## Run nanobot gateway
|
||||
|
||||
```bash
|
||||
nanobot channels status
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
## Test a message
|
||||
|
||||
Send the QQ bot a private message from a sandbox account. It should return a
|
||||
pairing code. Approve it from a trusted local surface:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "/pairing approve ABCD-EFGH"
|
||||
```
|
||||
|
||||
Send the message again after approval.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Prefer pairing-only mode for first setup. Add `allowFrom` only when you want a
|
||||
static allowlist.
|
||||
- Keep sandbox testing separate from production publishing.
|
||||
- Store QQ AppSecret through environment variables for deployed services.
|
||||
- Use Napcat only when you intentionally need a QQ account bridge and group chat
|
||||
features.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- If private messages do not arrive, confirm the sender is in the QQ bot sandbox
|
||||
and the gateway is running.
|
||||
- If output formatting is unreliable, keep `msgFormat` as `"plain"`.
|
||||
- If a first private message returns a pairing code, approve it before testing
|
||||
normal replies.
|
||||
- If you need QQ groups, see the Napcat section in the full chat-apps reference.
|
||||
|
||||
## Next: memory, automations, MCP tools
|
||||
|
||||
- [Chat Apps reference](../chat-apps.md)
|
||||
- [Pairing](../configuration.md#pairing)
|
||||
- [AI Agent Memory](./ai-agent-memory.md)
|
||||
- [Configure MCP tools](./configure-mcp-tools.md)
|
||||
@@ -0,0 +1,78 @@
|
||||
# How to Secure a Local AI Agent with nanobot
|
||||
|
||||
This guide covers the practical controls to review before letting a nanobot
|
||||
agent access files, shell commands, web fetch, chat apps, or remote users.
|
||||
|
||||
## What you will build
|
||||
|
||||
- a workspace-scoped agent setup
|
||||
- narrow channel access
|
||||
- safer secrets handling
|
||||
- optional shell sandboxing on Linux
|
||||
|
||||
## When to use this
|
||||
|
||||
Use this before exposing nanobot to teammates, chat apps, public networks, broad
|
||||
web access, or unattended automations.
|
||||
|
||||
## Install
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
## Minimal working example
|
||||
|
||||
Start with workspace restriction:
|
||||
|
||||
```json
|
||||
{
|
||||
"tools": {
|
||||
"restrictToWorkspace": true,
|
||||
"exec": {
|
||||
"enable": true,
|
||||
"sandbox": "bwrap"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`bwrap` is Linux-only and requires bubblewrap. On macOS or Windows, keep
|
||||
`restrictToWorkspace` enabled and review shell access carefully.
|
||||
|
||||
## Production notes
|
||||
|
||||
- Use environment variables for provider keys, bot tokens, and mailbox
|
||||
passwords.
|
||||
- Keep one workspace per trust boundary.
|
||||
- Prefer pairing for DM-capable chat apps, use narrow `allowFrom` lists only
|
||||
when static allowlists are intentional, and keep group policy mention-only at
|
||||
first.
|
||||
- Bind WebUI, WebSocket, and API services to localhost unless remote access is
|
||||
intentional.
|
||||
|
||||
## Security notes
|
||||
|
||||
- `restrictToWorkspace` is an application-level guard, not an OS sandbox.
|
||||
- `tools.exec.enable: false` removes shell execution entirely.
|
||||
- HTTP web fetch and HTTP MCP use SSRF protections by default.
|
||||
- Adding broad `tools.ssrfWhitelist` ranges increases exposure.
|
||||
- `allowFrom: ["*"]` bypasses pairing and means anyone who can reach that
|
||||
channel can talk to the bot.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- If a needed file cannot be read, confirm the active workspace path.
|
||||
- If a shell command fails under `bwrap`, check whether the command needs files
|
||||
outside the sandbox.
|
||||
- If local HTTP tools are blocked, review the SSRF whitelist and use a narrow
|
||||
CIDR.
|
||||
|
||||
## Related nanobot docs
|
||||
|
||||
- [Configuration: Security](../configuration.md#security)
|
||||
- [Pairing](../configuration.md#pairing)
|
||||
- [Deployment](../deployment.md)
|
||||
- [Chat Apps](../chat-apps.md)
|
||||
@@ -0,0 +1,83 @@
|
||||
# How to Run a Self-Hosted AI Agent with nanobot
|
||||
|
||||
This guide sets up nanobot as a self-hosted AI agent runtime on your own
|
||||
machine or server. The result is a gateway process that can serve the WebUI,
|
||||
chat apps, automations, and API integrations.
|
||||
|
||||
## What you will build
|
||||
|
||||
- a nanobot config and workspace under your control
|
||||
- a model provider connected through `config.json`
|
||||
- a long-running `nanobot gateway`
|
||||
- optional browser, chat app, and API access
|
||||
|
||||
## When to use this
|
||||
|
||||
Use this path when you want local or server-side ownership of the agent process,
|
||||
workspace files, memory files, and provider keys. It is also the right path when
|
||||
the agent must keep running after one terminal command finishes.
|
||||
|
||||
## Install
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
Complete the CLI check before deploying the gateway. A deployment problem is
|
||||
much easier to debug after the provider and model are known to work.
|
||||
|
||||
## Minimal working example
|
||||
|
||||
For chat apps, automations, and WebSocket delivery, start the gateway:
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
For the browser surface, use the WebUI launcher instead. It can start and manage
|
||||
the local gateway for you:
|
||||
|
||||
```bash
|
||||
nanobot webui
|
||||
```
|
||||
|
||||
Or connect a channel in `~/.nanobot/config.json`, then keep the same gateway
|
||||
process running for messages.
|
||||
|
||||
## Production notes
|
||||
|
||||
- Use Docker, systemd, or a macOS LaunchAgent when the process should survive
|
||||
terminal exits.
|
||||
- Give every deployed instance a distinct config path, workspace path, and port
|
||||
set.
|
||||
- Keep secrets in environment variables and start the service from the same
|
||||
environment.
|
||||
- Use health checks against the gateway or API process, not chat app delivery as
|
||||
the only signal.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Bind local-only services to `127.0.0.1` unless you intentionally expose them.
|
||||
- Set an API key before binding the OpenAI-compatible API to a public interface.
|
||||
- Prefer pairing for DM-capable chat apps, and keep any static `allowFrom`
|
||||
allowlists strict.
|
||||
- Enable `tools.restrictToWorkspace`; on Linux, use the bubblewrap sandbox for
|
||||
shell execution.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- Run `nanobot status` with the same `--config` and `--workspace` flags used by
|
||||
the service.
|
||||
- Run `nanobot gateway --verbose` while debugging channel startup.
|
||||
- Check port conflicts if the WebUI, WebSocket channel, or API endpoint fails to
|
||||
bind.
|
||||
|
||||
## Related nanobot docs
|
||||
|
||||
- [Deployment](../deployment.md)
|
||||
- [Multiple Instances](../multiple-instances.md)
|
||||
- [Configuration](../configuration.md)
|
||||
- [Chat Apps](../chat-apps.md)
|
||||
- [OpenAI-Compatible API](../openai-api.md)
|
||||
@@ -0,0 +1,109 @@
|
||||
# Build a Slack AI Agent with nanobot
|
||||
|
||||
This guide connects nanobot to Slack through Socket Mode. No public webhook URL
|
||||
is required for the first working setup.
|
||||
|
||||
## What this guide builds
|
||||
|
||||
- a Slack app with Socket Mode
|
||||
- a bot token and app-level token
|
||||
- the `slack` channel enabled in nanobot
|
||||
- a DM pairing flow and mention test from an approved Slack user
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- A working nanobot reply:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
- Permission to create a Slack app in a workspace.
|
||||
|
||||
## Install nanobot
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
```
|
||||
|
||||
## Enable the Slack channel
|
||||
|
||||
Install the optional channel dependency:
|
||||
|
||||
```bash
|
||||
nanobot plugins enable slack
|
||||
```
|
||||
|
||||
In Slack, create an app, enable Socket Mode, create an app-level token with
|
||||
`connections:write`, add bot scopes, subscribe to bot events, and install the
|
||||
app to your workspace.
|
||||
|
||||
Merge this snippet into `~/.nanobot/config.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"slack": {
|
||||
"enabled": true,
|
||||
"botToken": "xoxb-...",
|
||||
"appToken": "xapp-...",
|
||||
"groupPolicy": "mention",
|
||||
"dm": {
|
||||
"policy": "allowlist"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Slack DMs are open by default. Setting `dm.policy` to `"allowlist"` with no
|
||||
`dm.allowFrom` entries makes new DM senders receive a pairing code. Approve the
|
||||
code before using the bot normally.
|
||||
|
||||
## Run nanobot gateway
|
||||
|
||||
```bash
|
||||
nanobot channels status
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
## Test a message
|
||||
|
||||
DM the Slack bot directly. It should return a pairing code. Approve it from a
|
||||
trusted local surface:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "/pairing approve ABCD-EFGH"
|
||||
```
|
||||
|
||||
Then DM the bot again, or mention it in a channel:
|
||||
|
||||
```text
|
||||
@nanobot Hello from Slack
|
||||
```
|
||||
|
||||
## Security notes
|
||||
|
||||
- Keep `groupPolicy` as `mention` unless the bot is intentionally listening to
|
||||
every channel message.
|
||||
- Keep `dm.policy` as `"allowlist"` when you want pairing-based approval.
|
||||
- Use `groupAllowFrom` with allowlist mode for approved channels.
|
||||
- Reinstall the Slack app after changing scopes.
|
||||
- Keep bot and app tokens out of committed config files.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- If Socket Mode fails, confirm the app-level token starts with `xapp-`.
|
||||
- If the bot cannot send files, add `files:write`, reinstall the app, and
|
||||
restart nanobot.
|
||||
- If a DM responds normally without pairing, check that `dm.policy` is
|
||||
`"allowlist"`.
|
||||
- If channel messages are ignored, check event subscriptions and group policy.
|
||||
|
||||
## Next: memory, automations, MCP tools
|
||||
|
||||
- [Chat Apps reference](../chat-apps.md)
|
||||
- [Configure web search](./configure-web-search.md)
|
||||
- [Long-running AI Agent](./long-running-ai-agent.md)
|
||||
- [Deployment](../deployment.md)
|
||||
@@ -0,0 +1,109 @@
|
||||
# Build a Telegram AI Agent with nanobot
|
||||
|
||||
This guide connects nanobot to Telegram so a paired Telegram user can message a
|
||||
self-hosted AI agent backed by your normal nanobot config, tools, memory, and
|
||||
workspace.
|
||||
|
||||
## What this guide builds
|
||||
|
||||
- a Telegram bot created through BotFather
|
||||
- the `telegram` channel enabled in nanobot
|
||||
- a running nanobot gateway
|
||||
- one pairing-approved Telegram account
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- A working nanobot CLI reply:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
- A Telegram account.
|
||||
- A bot token from `@BotFather`.
|
||||
|
||||
## Install nanobot
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
```
|
||||
|
||||
## Enable the Telegram channel
|
||||
|
||||
Install the optional channel dependency:
|
||||
|
||||
```bash
|
||||
nanobot plugins enable telegram
|
||||
```
|
||||
|
||||
Merge this snippet into `~/.nanobot/config.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"telegram": {
|
||||
"enabled": true,
|
||||
"token": "YOUR_BOT_TOKEN"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Omitting `allowFrom` enables pairing-only mode. The first DM from a new user
|
||||
gets a pairing code instead of agent access.
|
||||
|
||||
Telegram uses long polling by default. Webhook mode is available for public
|
||||
HTTPS deployments; start with long polling for the first test.
|
||||
|
||||
## Run nanobot gateway
|
||||
|
||||
```bash
|
||||
nanobot channels status
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
Leave the gateway running while you test messages.
|
||||
|
||||
## Test a message
|
||||
|
||||
Open Telegram, DM the bot, and send:
|
||||
|
||||
```text
|
||||
Hello from Telegram
|
||||
```
|
||||
|
||||
The bot should reply with a pairing code. Approve it from an already trusted
|
||||
surface, such as the local CLI:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "/pairing approve ABCD-EFGH"
|
||||
```
|
||||
|
||||
Send the message again after approval. The reply should use the same model and
|
||||
workspace as your local CLI check.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Prefer pairing-only mode for first setup. Add `allowFrom` only when you want a
|
||||
static allowlist instead of code approval.
|
||||
- Do not use `allowFrom: ["*"]` unless the bot is isolated or intentionally public.
|
||||
- Rotate the BotFather token if it is pasted into logs or shared files.
|
||||
- Review tool access before adding group chats or more users.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- If the channel is not listed, run `nanobot plugins enable telegram` again in
|
||||
the same Python environment.
|
||||
- If messages do not arrive, run `nanobot gateway --verbose` and check the bot
|
||||
token.
|
||||
- If a first DM returns a pairing code, that is expected. Approve the code before
|
||||
testing normal agent replies.
|
||||
- If Telegram Web shows unsupported rich messages, keep `richMessages` disabled.
|
||||
|
||||
## Next: memory, automations, MCP tools
|
||||
|
||||
- [Chat Apps reference](../chat-apps.md)
|
||||
- [AI Agent Memory](./ai-agent-memory.md)
|
||||
- [Long-running AI Agent](./long-running-ai-agent.md)
|
||||
- [Configure MCP tools](./configure-mcp-tools.md)
|
||||
@@ -0,0 +1,103 @@
|
||||
# Build a WeChat AI Agent with nanobot
|
||||
|
||||
This guide connects nanobot to WeChat through the `weixin` channel. The channel
|
||||
uses HTTP long polling with QR-code login through the supported upstream API.
|
||||
|
||||
## What this guide builds
|
||||
|
||||
- the `weixin` channel enabled in nanobot
|
||||
- a QR-code login session
|
||||
- one pairing-approved WeChat sender
|
||||
- a running gateway for message delivery
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- A working local nanobot reply:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
- A WeChat account that can complete QR-code login.
|
||||
|
||||
## Install nanobot
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
```
|
||||
|
||||
## Enable the WeChat channel
|
||||
|
||||
Install the optional channel dependency:
|
||||
|
||||
```bash
|
||||
nanobot plugins enable weixin
|
||||
```
|
||||
|
||||
Merge this snippet into `~/.nanobot/config.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"weixin": {
|
||||
"enabled": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Omitting `allowFrom` enables pairing-only mode. The first private WeChat message
|
||||
from a new sender gets a pairing code instead of agent access.
|
||||
|
||||
Log in:
|
||||
|
||||
```bash
|
||||
nanobot channels login weixin
|
||||
```
|
||||
|
||||
Use `--force` if you need to discard saved login state and authenticate again.
|
||||
|
||||
## Run nanobot gateway
|
||||
|
||||
```bash
|
||||
nanobot channels status
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
## Test a message
|
||||
|
||||
Send a private WeChat message to the bot. It should reply with a pairing code.
|
||||
Approve it from a trusted local surface:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "/pairing approve ABCD-EFGH"
|
||||
```
|
||||
|
||||
Send the message again after approval and watch gateway logs for the sender ID
|
||||
and reply.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Prefer pairing-only mode for first setup. Add `allowFrom` only when you want a
|
||||
static allowlist.
|
||||
- Treat saved login state as sensitive account access.
|
||||
- Avoid connecting personal accounts to untrusted workspaces or broad tool
|
||||
permissions.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- If login fails, rerun `nanobot channels login weixin --force`.
|
||||
- If a first private message returns a pairing code, that is expected. Approve
|
||||
the code before testing normal agent replies.
|
||||
- If messages are denied without a pairing code, check gateway logs for whether
|
||||
WeChat provided the context token required for nanobot to reply.
|
||||
- If polling disconnects, restart the gateway and check network reachability to
|
||||
the upstream service.
|
||||
|
||||
## Next: memory, automations, MCP tools
|
||||
|
||||
- [Chat Apps reference](../chat-apps.md)
|
||||
- [AI Agent Memory](./ai-agent-memory.md)
|
||||
- [Secure local AI agent](./secure-local-ai-agent.md)
|
||||
- [Deployment](../deployment.md)
|
||||
@@ -0,0 +1,107 @@
|
||||
# Build a WhatsApp AI Agent with nanobot
|
||||
|
||||
This guide connects nanobot to WhatsApp through the `whatsapp` channel. The
|
||||
channel links as a WhatsApp device and uses the same nanobot agent runtime,
|
||||
tools, memory, and workspace as the CLI and WebUI.
|
||||
|
||||
## What this guide builds
|
||||
|
||||
- WhatsApp optional dependencies installed
|
||||
- a linked WhatsApp device session
|
||||
- the `whatsapp` channel enabled in `config.json`
|
||||
- one pairing-approved WhatsApp sender
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- A working local nanobot reply:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
- A WhatsApp account that can link a new device.
|
||||
- A machine that can keep `nanobot gateway` running.
|
||||
|
||||
## Install nanobot
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot onboard --wizard
|
||||
```
|
||||
|
||||
## Enable the WhatsApp channel
|
||||
|
||||
Install the optional channel dependency:
|
||||
|
||||
```bash
|
||||
nanobot plugins enable whatsapp
|
||||
```
|
||||
|
||||
Link WhatsApp as a device:
|
||||
|
||||
```bash
|
||||
nanobot channels login whatsapp
|
||||
```
|
||||
|
||||
Scan the QR code from WhatsApp -> Settings -> Linked Devices.
|
||||
|
||||
Merge this snippet into `~/.nanobot/config.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"whatsapp": {
|
||||
"enabled": true,
|
||||
"groupPolicy": "mention"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Omitting `allowFrom` enables pairing-only mode for private chats. `groupPolicy`
|
||||
defaults to `"open"` in the channel, but `"mention"` is safer for a first
|
||||
deployment.
|
||||
|
||||
## Run nanobot gateway
|
||||
|
||||
```bash
|
||||
nanobot channels status
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
## Test a message
|
||||
|
||||
Send the bot a private WhatsApp message. It should return a pairing code.
|
||||
Approve it from a trusted local surface:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "/pairing approve ABCD-EFGH"
|
||||
```
|
||||
|
||||
Send the message again after approval. The reply should use the same model and
|
||||
workspace as your local CLI check.
|
||||
|
||||
## Security notes
|
||||
|
||||
- Treat the WhatsApp session database as account access.
|
||||
- Prefer pairing-only mode for first setup. Add `allowFrom` only when you want a
|
||||
static allowlist.
|
||||
- Keep `groupPolicy` as `"mention"` before adding the bot to groups.
|
||||
- Avoid `allowFrom: ["*"]` unless the bot is intentionally public or isolated.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- If QR linking fails, rerun `nanobot channels login whatsapp`.
|
||||
- If you are migrating from the old bridge, remove `bridgeUrl` and
|
||||
`bridgeToken`, then re-login.
|
||||
- If a sender appears as a LID instead of a phone number, let nanobot learn the
|
||||
mapping at runtime or use `lidMappings` in the full reference.
|
||||
- If a first private message returns a pairing code, approve it before testing
|
||||
normal replies.
|
||||
|
||||
## Next: memory, automations, MCP tools
|
||||
|
||||
- [Chat Apps reference](../chat-apps.md)
|
||||
- [Pairing](../configuration.md#pairing)
|
||||
- [Secure local AI agent](./secure-local-ai-agent.md)
|
||||
- [Deployment](../deployment.md)
|
||||
@@ -0,0 +1,370 @@
|
||||
# Image Generation
|
||||
|
||||
nanobot can generate and edit images through the `generate_image` tool. Enable the tool in WebUI Settings, then ask for an image normally in chat; the agent decides when to call it and can keep iterating on generated images in the same conversation.
|
||||
|
||||
The feature is disabled by default. Enable it in `~/.nanobot/config.json`, configure a supported image provider, then restart the gateway.
|
||||
|
||||
## Quick Setup
|
||||
|
||||
This snippet uses the current built-in image-generation default so the JSON has concrete names. It is not a provider recommendation; replace `provider` and `model` with any supported image provider and model you intend to use.
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"openrouter": {
|
||||
"apiKey": "${OPENROUTER_API_KEY}"
|
||||
}
|
||||
},
|
||||
"tools": {
|
||||
"imageGeneration": {
|
||||
"enabled": true,
|
||||
"provider": "openrouter",
|
||||
"model": "openai/gpt-5.4-image-2"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
See [Provider Notes](#provider-notes) for Custom, AIHubMix, MiniMax, Gemini, Ollama, StepFun, and Zhipu configuration examples.
|
||||
|
||||
> [!TIP]
|
||||
> Prefer environment variables for API keys. nanobot resolves `${VAR_NAME}` values from the environment at startup.
|
||||
|
||||
## WebUI Usage
|
||||
|
||||
1. Open Settings and enable **Image Generation** with a configured provider and model.
|
||||
2. Describe the image or edit you want in chat.
|
||||
3. Include an aspect ratio or size in the request when the configured defaults are not suitable.
|
||||
4. Attach reference images when editing an existing image.
|
||||
|
||||
Generated images are rendered as assistant media in the chat. Follow-up prompts such as "make it warmer", "change the background", or "try a 16:9 version" can reuse the most recent generated artifact.
|
||||
|
||||
The WebUI hides provider storage details from the user. The agent sees the saved artifact path internally and can pass it back to `generate_image` as `reference_images` for iterative edits.
|
||||
|
||||
## Configuration Reference
|
||||
|
||||
| Option | Type | Default | Description |
|
||||
|--------|------|---------|-------------|
|
||||
| `tools.imageGeneration.enabled` | boolean | `false` | Register the `generate_image` tool |
|
||||
| `tools.imageGeneration.provider` | string | `"openrouter"` | Current built-in image provider default. Supported values: `openrouter`, `openai`, `openai_codex`, `custom`, `aihubmix`, `minimax`, `gemini`, `ollama`, `stepfun`, `zhipu` |
|
||||
| `tools.imageGeneration.model` | string | `"openai/gpt-5.4-image-2"` | Provider model name |
|
||||
| `tools.imageGeneration.defaultAspectRatio` | string | `"1:1"` | Default ratio when the prompt/tool call does not specify one |
|
||||
| `tools.imageGeneration.defaultImageSize` | string | `"1K"` | Default size hint, for example `1K`, `2K`, `4K`, or `1024x1024` |
|
||||
| `tools.imageGeneration.maxImagesPerTurn` | number | `4` | Maximum `count` accepted by one tool call. Valid range: `1` to `8` |
|
||||
| `tools.imageGeneration.saveDir` | string | `"generated"` | Relative directory under nanobot's media directory for generated artifacts |
|
||||
|
||||
Provider settings reuse normal provider config fields:
|
||||
|
||||
| Option | Description |
|
||||
|--------|-------------|
|
||||
| `providers.<name>.apiKey` | Provider API key. Prefer `${ENV_VAR}` |
|
||||
| `providers.<name>.apiBase` | Optional custom base URL |
|
||||
| `providers.<name>.extraHeaders` | Headers merged into provider requests |
|
||||
| `providers.<name>.extraBody` | Extra JSON fields merged into provider request bodies |
|
||||
|
||||
Both camelCase and snake_case config keys are accepted, but docs use camelCase to match `config.json`.
|
||||
|
||||
## Provider Notes
|
||||
|
||||
### OpenRouter
|
||||
|
||||
OpenRouter uses a chat-completions style image response. Configure:
|
||||
|
||||
```json
|
||||
{
|
||||
"tools": {
|
||||
"imageGeneration": {
|
||||
"enabled": true,
|
||||
"provider": "openrouter",
|
||||
"model": "openai/gpt-5.4-image-2"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Use a model that supports image generation and image editing if you want reference-image edits.
|
||||
|
||||
### Custom (OpenAI-compatible)
|
||||
|
||||
The `custom` image provider fits services that implement the synchronous OpenAI Images API:
|
||||
|
||||
```text
|
||||
POST /v1/images/generations
|
||||
```
|
||||
|
||||
The response must include generated images in `data[].b64_json` or `data[].url`. Native prediction APIs, such as Replicate's `/v1/models/{owner}/{model}/predictions`, are not directly compatible unless you put an OpenAI-compatible gateway in front of them.
|
||||
|
||||
Configure:
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"custom": {
|
||||
"apiKey": "${CUSTOM_IMAGE_API_KEY}",
|
||||
"apiBase": "https://api.example.com/v1"
|
||||
}
|
||||
},
|
||||
"tools": {
|
||||
"imageGeneration": {
|
||||
"enabled": true,
|
||||
"provider": "custom",
|
||||
"model": "your-model-name"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The `apiBase` is required. The provider sends requests to `{apiBase}/images/generations` using the OpenAI Images API format with `response_format: "b64_json"`. The `apiKey` is optional for local or unauthenticated endpoints. Reference-image edits are not supported by the generic `custom` provider.
|
||||
|
||||
`extraBody` can adapt provider-specific quirks because it is merged last into the request body. Examples:
|
||||
|
||||
- Agnes AI documents URL responses, so use `"extraBody": {"response_format": "url"}`.
|
||||
- Together AI documents `"response_format": "base64"`, so override the default.
|
||||
- Volcengine Ark Seedream models may require size hints such as `"2K"`, `"3K"`, `"4K"`, or explicit dimensions. Set `tools.imageGeneration.defaultImageSize` or `providers.custom.extraBody.size` to a value supported by the selected model.
|
||||
|
||||
For compatibility with the default nanobot setting, custom maps `defaultImageSize: "1K"` to `1024x1024`. Other explicit size hints are passed through unchanged.
|
||||
|
||||
### AIHubMix
|
||||
|
||||
AIHubMix `gpt-image-2-free` is supported through AIHubMix's unified predictions API. Internally nanobot calls:
|
||||
|
||||
```text
|
||||
/v1/models/openai/gpt-image-2-free/predictions
|
||||
```
|
||||
|
||||
Configure:
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"aihubmix": {
|
||||
"apiKey": "${AIHUBMIX_API_KEY}",
|
||||
"extraBody": {
|
||||
"quality": "low"
|
||||
}
|
||||
}
|
||||
},
|
||||
"tools": {
|
||||
"imageGeneration": {
|
||||
"enabled": true,
|
||||
"provider": "aihubmix",
|
||||
"model": "gpt-image-2-free"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`quality: low` is optional. It can make free image models faster and less likely to time out, but it is not required for correctness.
|
||||
|
||||
### MiniMax
|
||||
|
||||
MiniMax `image-01` supports text-to-image and reference-image (subject reference) edits. Supported aspect ratios are `1:1`, `16:9`, `4:3`, `3:2`, `2:3`, `3:4`, `9:16`, and `21:9`.
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"minimax": {
|
||||
"apiKey": "${MINIMAX_API_KEY}"
|
||||
}
|
||||
},
|
||||
"tools": {
|
||||
"imageGeneration": {
|
||||
"enabled": true,
|
||||
"provider": "minimax",
|
||||
"model": "image-01",
|
||||
"defaultAspectRatio": "1:1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Gemini
|
||||
|
||||
nanobot supports two Gemini image generation model families via Google's Generative Language API:
|
||||
|
||||
| Model | Endpoint | Reference images |
|
||||
|-------|----------|-----------------|
|
||||
| `imagen-4.0-generate-001` | `:predict` | Not supported by this integration |
|
||||
| `gemini-2.5-flash-image` | `:generateContent` | Supported |
|
||||
|
||||
For reference-image edits, use a Gemini Flash image model:
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"gemini": {
|
||||
"apiKey": "${GEMINI_API_KEY}"
|
||||
}
|
||||
},
|
||||
"tools": {
|
||||
"imageGeneration": {
|
||||
"enabled": true,
|
||||
"provider": "gemini",
|
||||
"model": "gemini-2.5-flash-image"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Imagen 4 supports the aspect ratios `1:1`, `9:16`, `16:9`, `3:4`, and `4:3`. Unsupported ratios are ignored and the model uses its default. The `defaultImageSize` setting has no effect on Gemini models; sizing is controlled by `defaultAspectRatio` only. Reference images passed with an Imagen model are ignored (with a warning logged).
|
||||
|
||||
### Ollama
|
||||
|
||||
Ollama's experimental native image generation API works with local servers and hosted ollama.com models. Local access at `http://localhost:11434/api` does not require an API key; set `providers.ollama.apiKey` only when targeting `https://ollama.com/api`.
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"ollama": {
|
||||
"apiBase": "http://localhost:11434/api"
|
||||
}
|
||||
},
|
||||
"tools": {
|
||||
"imageGeneration": {
|
||||
"enabled": true,
|
||||
"provider": "ollama",
|
||||
"model": "x/z-image-turbo",
|
||||
"defaultAspectRatio": "16:9",
|
||||
"defaultImageSize": "2K"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Ollama maps `defaultAspectRatio` and `defaultImageSize` to native `width` and `height` values. Reference images are not supported by this integration.
|
||||
|
||||
### StepFun
|
||||
|
||||
StepFun (阶跃星辰) `step-image-edit-2` supports text-to-image generation. The `step-1x-medium` variant additionally supports **style-reference** image edits, where a reference image guides the visual style of the output.
|
||||
|
||||
Supported aspect ratios: `1:1`, `16:9`, `9:16`, `3:4`, `4:3`. Sizes are specified as `WIDTHxHEIGHT` (e.g. `1024x1024`, `1280x800`, `800x1280`).
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"stepfun": {
|
||||
"apiKey": "${STEPFUN_API_KEY}"
|
||||
}
|
||||
},
|
||||
"tools": {
|
||||
"imageGeneration": {
|
||||
"enabled": true,
|
||||
"provider": "stepfun",
|
||||
"model": "step-image-edit-2"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
> The StepFun provider reuses the existing `providers.stepfun` config block (the same one used for StepFun's LLM API). Set `providers.stepfun.apiKey` once and it is shared between text and image generation.
|
||||
>
|
||||
> When `step-image-edit-2` is used, `reference_images` are ignored (the model does not support style reference). Switch to `step-1x-medium` to use reference-image-guided generation.
|
||||
|
||||
#### StepPlan (Subscription)
|
||||
|
||||
StepPlan is StepFun's subscription tier and uses a different API base URL. The image generation endpoint path is the same — just override `apiBase`:
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"stepfun": {
|
||||
"apiKey": "${STEPFUN_API_KEY}",
|
||||
"apiBase": "https://api.stepfun.ai/step_plan/v1"
|
||||
}
|
||||
},
|
||||
"tools": {
|
||||
"imageGeneration": {
|
||||
"enabled": true,
|
||||
"provider": "stepfun",
|
||||
"model": "step-image-edit-2"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`apiBase` takes precedence over the registry default, so with the StepPlan base URL configured, image requests are sent to `https://api.stepfun.ai/step_plan/v1/images/generations` — the same path prefix used for LLM calls. The API key is shared with the standard StepFun provider.
|
||||
|
||||
### Zhipu
|
||||
|
||||
Zhipu (智谱) `glm-image` model supports text-to-image generation. The API returns temporary image URLs (valid for 30 days); nanobot downloads and re-encodes them as base64 data URLs.
|
||||
|
||||
Supported aspect ratios: `1:1`, `16:9`, `9:16`, `3:4`, `4:3`. Sizes can be specified as `WIDTHxHEIGHT` (e.g. `1280x1280`, `1728x960`) or using aspect ratio presets.
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"zhipu": {
|
||||
"apiKey": "${ZAI_API_KEY}"
|
||||
}
|
||||
},
|
||||
"tools": {
|
||||
"imageGeneration": {
|
||||
"enabled": true,
|
||||
"provider": "zhipu",
|
||||
"model": "glm-image"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Other supported models: `cogview-4`, `cogview-4-250304`, `cogview-3-flash`. Reference images are not supported by this integration.
|
||||
|
||||
## Artifacts
|
||||
|
||||
Generated images are stored under the active nanobot instance's media directory:
|
||||
|
||||
```text
|
||||
~/.nanobot/media/generated/YYYY-MM-DD/img_<id>.<ext>
|
||||
~/.nanobot/media/generated/YYYY-MM-DD/img_<id>.json
|
||||
```
|
||||
|
||||
For non-default config locations, the media directory is relative to the active config file's directory.
|
||||
|
||||
The JSON sidecar stores:
|
||||
|
||||
| Field | Meaning |
|
||||
|-------|---------|
|
||||
| `id` | Short generated image id, such as `img_ab12cd34ef56` |
|
||||
| `path` | Local image path used internally for follow-up edits |
|
||||
| `mime` | Detected image MIME type |
|
||||
| `prompt` | Prompt used for the generation |
|
||||
| `model` | Provider model |
|
||||
| `provider` | Provider name |
|
||||
| `source_images` | Reference image paths used for edits |
|
||||
| `created_at` | Creation timestamp |
|
||||
|
||||
Do not paste base64 image payloads into chat. The agent should keep local artifact paths internal unless the user explicitly asks for debugging details.
|
||||
|
||||
## Prompting
|
||||
|
||||
Good image prompts include:
|
||||
|
||||
- Subject and scene.
|
||||
- Composition, camera, or layout.
|
||||
- Style, mood, lighting, and color palette.
|
||||
- Exact text that must appear in the image, quoted.
|
||||
- Constraints such as "keep the same character" or "preserve the logo".
|
||||
|
||||
Example:
|
||||
|
||||
```text
|
||||
A minimal app icon for nanobot: friendly robot head, rounded square, soft blue and white palette, clean vector style, no text
|
||||
```
|
||||
|
||||
For edits, describe what should change and what must stay fixed:
|
||||
|
||||
```text
|
||||
Use the reference image. Keep the same robot and composition, change the palette to warm orange, and add a subtle sunrise background.
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
| Symptom | Check |
|
||||
|---------|-------|
|
||||
| `generate_image` is not available | Set `tools.imageGeneration.enabled` to `true` and restart the gateway |
|
||||
| Missing API key error | Configure `providers.<provider>.apiKey`; if using `${VAR_NAME}`, confirm the environment variable is visible to the gateway process |
|
||||
| `unsupported image generation provider` | Use `openrouter`, `openai`, `openai_codex`, `custom`, `aihubmix`, `minimax`, `gemini`, `ollama`, `stepfun`, or `zhipu` |
|
||||
| AIHubMix says `Incorrect model ID` | Use `model: "gpt-image-2-free"`; nanobot expands it to the required `openai/gpt-image-2-free` model path internally |
|
||||
| Generation times out | Try a smaller/default image size, set AIHubMix `extraBody.quality` to `"low"`, or retry later |
|
||||
| Reference image rejected | Reference image paths must be inside the workspace or nanobot media directory and must be valid image files |
|
||||
+213
@@ -0,0 +1,213 @@
|
||||
# AI Agent Memory in nanobot
|
||||
|
||||
This page explains how nanobot implements long-term AI agent memory: session
|
||||
history, compressed archives, durable knowledge files, Dream consolidation, and
|
||||
Git-backed memory changes.
|
||||
|
||||
nanobot's memory is built on a simple belief: memory should feel alive, but it should not feel chaotic.
|
||||
|
||||
Good memory is not a pile of notes. It is a quiet system of attention. It notices what is worth keeping, lets go of what no longer needs the spotlight, and turns lived experience into something calm, durable, and useful.
|
||||
|
||||
That is the shape of memory in nanobot.
|
||||
|
||||
## The Design
|
||||
|
||||
nanobot does not treat memory as one giant file.
|
||||
|
||||
It separates memory into layers, because different kinds of remembering deserve different tools:
|
||||
|
||||
- `session.messages` holds the living short-term conversation.
|
||||
- `memory/history.jsonl` is the running archive of compressed past turns.
|
||||
- `SOUL.md`, `USER.md`, and `memory/MEMORY.md` are the durable knowledge files.
|
||||
- `GitStore` records how those durable files change over time.
|
||||
|
||||
This keeps the system light in the moment, but reflective over time.
|
||||
|
||||
## The Flow
|
||||
|
||||
Memory moves through nanobot in two stages.
|
||||
|
||||
### Stage 1: Consolidator
|
||||
|
||||
When a conversation grows large enough to pressure the context window, nanobot does not try to carry every old message forever.
|
||||
|
||||
Instead, the `Consolidator` summarizes the oldest safe slice of the conversation and appends that summary to `memory/history.jsonl`.
|
||||
|
||||
This file is:
|
||||
|
||||
- append-only
|
||||
- cursor-based
|
||||
- optimized for machine consumption first, human inspection second
|
||||
|
||||
Each line is a JSON object:
|
||||
|
||||
```json
|
||||
{"cursor": 42, "timestamp": "2026-04-03 00:02", "content": "- User prefers dark mode\n- Decided to use PostgreSQL"}
|
||||
```
|
||||
|
||||
It is not the final memory. It is the material from which final memory is shaped.
|
||||
|
||||
### Stage 2: Dream
|
||||
|
||||
`Dream` is the slower, more thoughtful layer. It runs on a cron schedule by default and can also be triggered manually.
|
||||
|
||||
Dream reads:
|
||||
|
||||
- new entries from `memory/history.jsonl`
|
||||
- the current `SOUL.md`
|
||||
- the current `USER.md`
|
||||
- the current `memory/MEMORY.md`
|
||||
|
||||
Then it edits the long-term files surgically in a single pass — not by rewriting everything, but by making the smallest honest change that keeps memory coherent.
|
||||
|
||||
This is why nanobot's memory is not just archival. It is interpretive.
|
||||
|
||||
## The Files
|
||||
|
||||
```text
|
||||
workspace/
|
||||
├── SOUL.md # The bot's long-term voice and communication style
|
||||
├── USER.md # Stable knowledge about the user
|
||||
├── prompts/
|
||||
│ ├── README.md # Notes for memory guidance files
|
||||
│ └── dream.md # Optional instructions for how Dream organizes memory
|
||||
└── memory/
|
||||
├── MEMORY.md # Project facts, decisions, and durable context
|
||||
├── history.jsonl # Append-only history summaries
|
||||
├── .cursor # Consolidator write cursor
|
||||
├── .dream_cursor # Dream consumption cursor
|
||||
└── .git/ # Version history for long-term memory files
|
||||
```
|
||||
|
||||
These files play different roles:
|
||||
|
||||
- `SOUL.md` remembers how nanobot should sound.
|
||||
- `USER.md` remembers who the user is and what they prefer.
|
||||
- `MEMORY.md` remembers what remains true about the work itself.
|
||||
- `history.jsonl` remembers what happened on the way there.
|
||||
|
||||
## Why `history.jsonl`
|
||||
|
||||
The old `HISTORY.md` format was pleasant for casual reading, but it was too fragile as an operational substrate.
|
||||
|
||||
`history.jsonl` gives nanobot:
|
||||
|
||||
- stable incremental cursors
|
||||
- safer machine parsing
|
||||
- easier batching
|
||||
- cleaner migration and compaction
|
||||
- a better boundary between raw history and curated knowledge
|
||||
|
||||
You can still search it with familiar tools:
|
||||
|
||||
```bash
|
||||
# grep
|
||||
grep -i "keyword" memory/history.jsonl
|
||||
|
||||
# jq
|
||||
cat memory/history.jsonl | jq -r 'select(.content | test("keyword"; "i")) | .content' | tail -20
|
||||
|
||||
# Python
|
||||
python -c "import json; [print(json.loads(l).get('content','')) for l in open('memory/history.jsonl','r',encoding='utf-8') if l.strip() and 'keyword' in l.lower()][-20:]"
|
||||
```
|
||||
|
||||
The difference is philosophical as much as technical:
|
||||
|
||||
- `history.jsonl` is for structure
|
||||
- `SOUL.md`, `USER.md`, and `MEMORY.md` are for meaning
|
||||
|
||||
## Commands
|
||||
|
||||
Memory is not hidden behind the curtain. Users can inspect and guide it.
|
||||
|
||||
| Command | What it does |
|
||||
|---------|--------------|
|
||||
| `/dream` | Run Dream immediately |
|
||||
| `/dream-log` | Show the latest Dream memory change |
|
||||
| `/dream-log <sha>` | Show a specific Dream change |
|
||||
| `/dream-restore` | List recent Dream memory versions |
|
||||
| `/dream-restore <sha>` | Restore memory to the state before a specific change |
|
||||
| `/dream-prompt` | Show how Dream is being guided for memory |
|
||||
| `/dream-prompt init` | Create an editable Dream memory guide at `prompts/dream.md` |
|
||||
|
||||
These commands exist for a reason: automatic memory is powerful, but users should always retain the right to inspect, understand, and restore it.
|
||||
|
||||
## Versioned Memory
|
||||
|
||||
After Dream changes long-term memory files, nanobot can record that change with `GitStore`.
|
||||
|
||||
This gives memory a history of its own:
|
||||
|
||||
- you can inspect what changed
|
||||
- you can compare versions
|
||||
- you can restore a previous state
|
||||
|
||||
That turns memory from a silent mutation into an auditable process.
|
||||
|
||||
## Guiding Dream
|
||||
|
||||
Dream decides what to keep, update, or forget using nanobot's built-in memory instructions. Most users can leave this alone.
|
||||
|
||||
If one workspace needs a different memory style, create an editable guide:
|
||||
|
||||
```text
|
||||
/dream-prompt init
|
||||
```
|
||||
|
||||
This creates:
|
||||
|
||||
```text
|
||||
workspace/prompts/dream.md
|
||||
```
|
||||
|
||||
Edit that file in plain Markdown. When it has content, Dream follows it for this workspace before reading the latest conversation history. You do not need to paste history into the file; Dream adds the current `## Conversation History` block automatically.
|
||||
|
||||
To return to nanobot's default behavior, delete `prompts/dream.md` or leave it empty.
|
||||
|
||||
Each workspace has its own guide. Changing this file does not affect other nanobot workspaces.
|
||||
|
||||
## Configuration
|
||||
|
||||
Dream is configured under `agents.defaults.dream`:
|
||||
|
||||
```json
|
||||
{
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"dream": {
|
||||
"intervalH": 2,
|
||||
"modelOverride": null,
|
||||
"maxBatchSize": 20,
|
||||
"maxIterations": 10
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
| Field | Meaning |
|
||||
|-------|---------|
|
||||
| `intervalH` | How often Dream runs, in hours |
|
||||
| `cron` | Cron expression override (takes precedence over `intervalH`) |
|
||||
| `modelOverride` | Optional Dream-specific model override *(pending implementation)* |
|
||||
| `maxBatchSize` | *(Deprecated — not used)* |
|
||||
| `maxIterations` | *(Deprecated — not used)* |
|
||||
|
||||
In practical terms:
|
||||
|
||||
- `intervalH` is the normal way to configure Dream frequency. Internally it runs as an `every` schedule.
|
||||
- `cron` overrides `intervalH` when set, allowing precise cron expressions (e.g. `0 */4 * * *`).
|
||||
- `modelOverride` is reserved for a future release. Currently Dream uses the same model as the main agent.
|
||||
- `maxBatchSize` and `maxIterations` are preserved for config compatibility but no longer affect behavior.
|
||||
|
||||
## In Practice
|
||||
|
||||
What this means in daily use is simple:
|
||||
|
||||
- conversations can stay fast without carrying infinite context
|
||||
- durable facts can become clearer over time instead of noisier
|
||||
- the user can inspect and restore memory when needed
|
||||
|
||||
Memory should not feel like a dump. It should feel like continuity.
|
||||
|
||||
That is what this design is trying to protect.
|
||||
@@ -0,0 +1,131 @@
|
||||
# Multiple Instances
|
||||
|
||||
Run multiple nanobot instances simultaneously with separate configs and runtime data. Use `--config` as the main entrypoint. Optionally pass `--workspace` during `onboard` when you want to initialize or update the saved workspace for a specific instance.
|
||||
|
||||
## Quick Start
|
||||
|
||||
If you want each instance to have its own dedicated workspace from the start, pass both `--config` and `--workspace` during onboarding.
|
||||
|
||||
**Initialize instances:**
|
||||
|
||||
```bash
|
||||
# Create separate instance configs and workspaces
|
||||
nanobot onboard --config ~/.nanobot-telegram/config.json --workspace ~/.nanobot-telegram/workspace
|
||||
nanobot onboard --config ~/.nanobot-discord/config.json --workspace ~/.nanobot-discord/workspace
|
||||
nanobot onboard --config ~/.nanobot-feishu/config.json --workspace ~/.nanobot-feishu/workspace
|
||||
```
|
||||
|
||||
**Configure each instance:**
|
||||
|
||||
Edit `~/.nanobot-telegram/config.json`, `~/.nanobot-discord/config.json`, etc. with different channel settings. The workspace you passed during `onboard` is saved into each config as that instance's default workspace.
|
||||
|
||||
**Run instances:**
|
||||
|
||||
```bash
|
||||
# Check one instance before starting it
|
||||
nanobot status --config ~/.nanobot-telegram/config.json
|
||||
|
||||
# Instance A - Telegram bot
|
||||
nanobot gateway --config ~/.nanobot-telegram/config.json
|
||||
|
||||
# Instance B - Discord bot
|
||||
nanobot gateway --config ~/.nanobot-discord/config.json
|
||||
|
||||
# Instance C - Feishu bot with custom port
|
||||
nanobot gateway --config ~/.nanobot-feishu/config.json --port 18792
|
||||
```
|
||||
|
||||
## Path Resolution
|
||||
|
||||
When using `--config`, nanobot derives its runtime data directory from the config file location. The workspace still comes from `agents.defaults.workspace` unless you override it with `--workspace`.
|
||||
|
||||
To open a CLI session against one of these instances locally:
|
||||
|
||||
```bash
|
||||
nanobot agent -c ~/.nanobot-telegram/config.json -m "Hello from Telegram instance"
|
||||
nanobot agent -c ~/.nanobot-discord/config.json -m "Hello from Discord instance"
|
||||
|
||||
# Open the browser workbench for a specific instance
|
||||
nanobot webui -c ~/.nanobot-telegram/config.json
|
||||
|
||||
# Optional one-off workspace override
|
||||
nanobot agent -c ~/.nanobot-telegram/config.json -w /tmp/nanobot-telegram-test
|
||||
```
|
||||
|
||||
> `nanobot agent` starts a local CLI agent using the selected workspace/config. It does not attach to or proxy through an already running `nanobot gateway` process.
|
||||
|
||||
| Component | Resolved From | Example |
|
||||
|-----------|---------------|---------|
|
||||
| **Config** | `--config` path | `~/.nanobot-A/config.json` |
|
||||
| **Workspace** | `--workspace` or config | `~/.nanobot-A/workspace/` |
|
||||
| **Cron Jobs** | workspace directory | `~/.nanobot-A/workspace/cron/` |
|
||||
| **Media / runtime state** | config directory | `~/.nanobot-A/media/` |
|
||||
|
||||
## How It Works
|
||||
|
||||
- `--config` selects which config file to load
|
||||
- By default, the workspace comes from `agents.defaults.workspace` in that config
|
||||
- If you pass `--workspace`, it overrides the workspace from the config file
|
||||
|
||||
## Minimal Setup
|
||||
|
||||
1. Copy your base config into a new instance directory.
|
||||
2. Set a different `agents.defaults.workspace` for that instance.
|
||||
3. Start the instance with `--config`.
|
||||
|
||||
Example config fragment:
|
||||
|
||||
```json
|
||||
{
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"workspace": "~/.nanobot-telegram/workspace"
|
||||
}
|
||||
},
|
||||
"channels": {
|
||||
"telegram": {
|
||||
"enabled": true,
|
||||
"token": "YOUR_TELEGRAM_BOT_TOKEN"
|
||||
}
|
||||
},
|
||||
"gateway": {
|
||||
"host": "127.0.0.1",
|
||||
"port": 18790
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The copied base config can keep using the same `modelPresets` and `agents.defaults.modelPreset`. If this instance needs a different model, add another preset and set `agents.defaults.modelPreset` to that preset name.
|
||||
|
||||
Start separate instances:
|
||||
|
||||
```bash
|
||||
nanobot status --config ~/.nanobot-telegram/config.json
|
||||
nanobot gateway --config ~/.nanobot-telegram/config.json
|
||||
nanobot gateway --config ~/.nanobot-discord/config.json
|
||||
```
|
||||
|
||||
Each gateway instance also exposes a lightweight HTTP health endpoint on `gateway.host:gateway.port`. By default, the gateway binds to `127.0.0.1`, so the endpoint stays local unless you explicitly set `gateway.host` to a public or LAN-facing address.
|
||||
|
||||
- `GET /health` returns `{"status":"ok"}`
|
||||
- Other paths return `404`
|
||||
|
||||
Override workspace for one-off runs when needed:
|
||||
|
||||
```bash
|
||||
nanobot gateway --config ~/.nanobot-telegram/config.json --workspace /tmp/nanobot-telegram-test
|
||||
```
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
- Run separate bots for Telegram, Discord, Feishu, and other platforms
|
||||
- Keep testing and production instances isolated
|
||||
- Use different models or providers for different teams
|
||||
- Serve multiple tenants with separate configs and runtime data
|
||||
|
||||
## Notes
|
||||
|
||||
- Each instance must use a different port if they run at the same time
|
||||
- Use a different workspace per instance if you want isolated memory, sessions, and skills
|
||||
- `--workspace` overrides the workspace defined in the config file
|
||||
- Cron jobs are stored in the active workspace; runtime media/state is derived from the config directory
|
||||
+211
@@ -0,0 +1,211 @@
|
||||
# My Tool
|
||||
|
||||
Let the agent sense and adjust its own runtime state — like asking a coworker "are you busy? can you switch to a bigger monitor?"
|
||||
|
||||
## Why You Need It
|
||||
|
||||
Normal tools let the agent operate on the outside world (read/write files, search code). But the agent knows nothing about itself — it doesn't know which model it's running on, how many iterations are left, or how many tokens it has consumed.
|
||||
|
||||
My tool fills this gap. With it, the agent can:
|
||||
|
||||
- **Know who it is**: What model am I using? Where is my workspace? How many iterations remain?
|
||||
- **Adapt on the fly**: Complex task? Expand the context window. Simple chat? Switch to a faster model.
|
||||
- **Remember across turns**: Store notes in your scratchpad that persist into the next conversation turn.
|
||||
|
||||
## Configuration
|
||||
|
||||
Enabled by default (read-only mode). The agent can check its state but not set it.
|
||||
|
||||
```yaml
|
||||
tools:
|
||||
my:
|
||||
enable: true # default: true
|
||||
allow_set: false # default: false (read-only)
|
||||
```
|
||||
|
||||
To allow the agent to set its configuration (e.g. switch models, adjust parameters), set `tools.my.allow_set: true`.
|
||||
|
||||
Legacy `tools.myEnabled` / `tools.mySet` keys are auto-migrated on load, and rewritten in-place the next time `nanobot onboard` refreshes the config.
|
||||
|
||||
All modifications are held in memory only — restart restores defaults.
|
||||
|
||||
---
|
||||
|
||||
## check — Check "my" current state
|
||||
|
||||
Without parameters, returns a key config overview:
|
||||
|
||||
```text
|
||||
my(action="check")
|
||||
# → max_iterations: 40
|
||||
# context_window_tokens: 200000
|
||||
# model: 'anthropic/claude-sonnet-4-6'
|
||||
# workspace: PosixPath('/tmp/workspace')
|
||||
# provider_retry_mode: 'standard'
|
||||
# max_tool_result_chars: 16000
|
||||
# _current_iteration: 3
|
||||
# _last_usage: {'prompt_tokens': 45000, 'completion_tokens': 8000}
|
||||
# Note: prompt_tokens is cumulative across all turns, not current context window occupancy.
|
||||
```
|
||||
|
||||
With a key parameter, drill into a specific config:
|
||||
|
||||
```text
|
||||
my(action="check", key="_last_usage.prompt_tokens")
|
||||
# → How many prompt tokens I've used so far
|
||||
|
||||
my(action="check", key="model")
|
||||
# → What model I'm currently running on
|
||||
|
||||
my(action="check", key="web_config.enable")
|
||||
# → Whether web search is enabled
|
||||
```
|
||||
|
||||
### What you can do with it
|
||||
|
||||
| Scenario | How |
|
||||
|----------|-----|
|
||||
| "What model are you using?" | `check("model")` |
|
||||
| "Which model preset is active?" | `check("model_preset")` |
|
||||
| "How many more tool calls can you make?" | `check("max_iterations")` minus `check("_current_iteration")` |
|
||||
| "How many tokens has this conversation used?" | `check("_last_usage")` — cumulative across all turns |
|
||||
| "Where is your working directory?" | `check("workspace")` |
|
||||
| "Show me your full config" | `check()` |
|
||||
| "Are there any subagents running?" | `check("subagents")` — shows phase, iteration, elapsed time, tool events |
|
||||
|
||||
---
|
||||
|
||||
## set — Runtime tuning
|
||||
|
||||
Changes take effect immediately, no restart required.
|
||||
|
||||
```text
|
||||
my(action="set", key="max_iterations", value=80)
|
||||
# → Bump iteration limit from 40 to 80
|
||||
|
||||
my(action="set", key="model_preset", value="fast")
|
||||
# → Switch to a configured model preset
|
||||
|
||||
my(action="set", key="model", value="fast-model")
|
||||
# → Switch to a raw model and clear the active preset
|
||||
|
||||
my(action="set", key="context_window_tokens", value=262144)
|
||||
# → Expand context window for long documents
|
||||
```
|
||||
|
||||
You can also store custom state in your scratchpad:
|
||||
|
||||
```text
|
||||
my(action="set", key="current_project", value="nanobot")
|
||||
my(action="set", key="user_style_preference", value="concise")
|
||||
my(action="set", key="task_complexity", value="high")
|
||||
# → These values persist into the next conversation turn
|
||||
```
|
||||
|
||||
### Protected parameters
|
||||
|
||||
These parameters have type and range validation — invalid values are rejected:
|
||||
|
||||
| Parameter | Type | Range | Purpose |
|
||||
|-----------|------|-------|---------|
|
||||
| `max_iterations` | int | 1–100 | Max tool calls per conversation turn |
|
||||
| `context_window_tokens` | int | 4,096–1,000,000 | Context window size |
|
||||
| `model` | str | non-empty | LLM model to use |
|
||||
| `model_preset` | str | configured preset name | Named preset to use |
|
||||
|
||||
Other parameters (e.g. `workspace`, `provider_retry_mode`, `max_tool_result_chars`) can be set freely, as long as the value is JSON-safe.
|
||||
|
||||
---
|
||||
|
||||
## Practical Scenarios
|
||||
|
||||
### "This task is complex, I need more room"
|
||||
|
||||
```text
|
||||
Agent: This codebase is large, let me expand my context window to handle it.
|
||||
→ my(action="set", key="context_window_tokens", value=262144)
|
||||
```
|
||||
|
||||
### "Simple question, don't waste compute"
|
||||
|
||||
```text
|
||||
Agent: This is a straightforward question, let me switch to the fast preset.
|
||||
→ my(action="set", key="model_preset", value="fast")
|
||||
```
|
||||
|
||||
### "Remember user preferences across turns"
|
||||
|
||||
```text
|
||||
Turn 1: my(action="set", key="user_prefers_concise", value=True)
|
||||
Turn 2: my(action="check", key="user_prefers_concise")
|
||||
# → True (still remembers the user likes concise replies)
|
||||
```
|
||||
|
||||
### "Self-diagnosis"
|
||||
|
||||
```text
|
||||
User: "Why aren't you searching the web?"
|
||||
Agent: Let me check my web config.
|
||||
→ my(action="check", key="web_config.enable")
|
||||
# → False
|
||||
Agent: Web search is disabled — please set web.enable: true in your config.
|
||||
```
|
||||
|
||||
### "Token budget management"
|
||||
|
||||
```text
|
||||
Agent: Let me check how much budget I have left.
|
||||
→ my(action="check", key="_last_usage")
|
||||
# → {"prompt_tokens": 45000, "completion_tokens": 8000}
|
||||
Agent: I've used ~53k tokens total so far. I'll keep my remaining replies concise.
|
||||
```
|
||||
|
||||
### "Subagent monitoring"
|
||||
|
||||
```text
|
||||
Agent: Let me check on the background tasks.
|
||||
→ my(action="check", key="subagents")
|
||||
# → 2 subagent(s):
|
||||
# [task-1] 'Code review'
|
||||
# phase: running, iteration: 5, elapsed: 12.3s
|
||||
# tools: read(✓), grep(✓)
|
||||
# usage: {'prompt_tokens': 8000, 'completion_tokens': 1200}
|
||||
# [task-2] 'Write tests'
|
||||
# phase: pending, iteration: 0, elapsed: 0.2s
|
||||
# tools: none
|
||||
Agent: The code review is progressing well. The test task hasn't started yet.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Safety Mechanisms
|
||||
|
||||
Core design principle: **All modifications live in memory only. Restart restores defaults.** The agent cannot cause persistent damage.
|
||||
|
||||
### Off-limits (BLOCKED)
|
||||
|
||||
Cannot be checked or modified — fully hidden:
|
||||
|
||||
| Category | Attributes | Reason |
|
||||
|----------|-----------|--------|
|
||||
| Core infrastructure | `bus`, `provider`, `_running` | Changes would crash the system |
|
||||
| Tool registry | `tools` | Must not remove its own tools |
|
||||
| Subsystems | `runner`, `sessions`, `consolidator`, etc. | Affects other users/sessions |
|
||||
| Sensitive data | `_mcp_servers`, `_pending_queues`, etc. | Contains credentials and message routing |
|
||||
| Security boundaries | `restrict_to_workspace`, `channels_config` | Bypassing would violate isolation |
|
||||
| Python internals | `__class__`, `__dict__`, etc. | Prevents sandbox escape |
|
||||
|
||||
### Read-only (check only)
|
||||
|
||||
Can be checked but not set:
|
||||
|
||||
| Category | Attributes | Reason |
|
||||
|----------|-----------|--------|
|
||||
| Subagent manager | `subagents` | Observable, but replacing breaks the system |
|
||||
| Execution config | `exec_config` | Can check sandbox/enable status, cannot change it |
|
||||
| Web config | `web_config` | Can check enable status, cannot change it |
|
||||
| Iteration counter | `_current_iteration` | Updated by runner only |
|
||||
|
||||
### Sensitive field protection
|
||||
|
||||
Sub-fields matching sensitive names (`api_key`, `password`, `secret`, `token`, etc.) are blocked from both check and set, regardless of parent path. This prevents credential leaks via dot-path traversal (e.g. `web_config.search.api_key`).
|
||||
@@ -0,0 +1,150 @@
|
||||
# Nanobot OpenAI-Compatible API: Run a Local Agent Behind /v1/chat/completions
|
||||
|
||||
nanobot can expose a minimal OpenAI-compatible endpoint for local integrations:
|
||||
|
||||
```bash
|
||||
nanobot plugins enable api
|
||||
nanobot agent -m "Hello!"
|
||||
nanobot serve
|
||||
```
|
||||
|
||||
Run the CLI check first. If `nanobot agent -m "Hello!"` fails, fix provider or config setup before debugging the API server. By default, the API binds to `127.0.0.1:8900`. You can change this in `config.json`.
|
||||
|
||||
For setup help, see [`quick-start.md`](./quick-start.md), [`providers.md`](./providers.md), and [`troubleshooting.md`](./troubleshooting.md).
|
||||
|
||||
## Authentication
|
||||
|
||||
Local-only `127.0.0.1` usage does not require an API key. If you bind the API
|
||||
server to all interfaces with `api.host: "0.0.0.0"` or `"::"`, nanobot requires
|
||||
`api.apiKey`; otherwise startup fails to avoid exposing an unauthenticated agent
|
||||
endpoint on the network.
|
||||
|
||||
```json
|
||||
{
|
||||
"api": {
|
||||
"host": "0.0.0.0",
|
||||
"port": 8900,
|
||||
"apiKey": "${NANOBOT_API_KEY}"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
When `api.apiKey` is set, send it as a Bearer token on API routes. The health
|
||||
endpoint remains unauthenticated so local probes and load balancers can still
|
||||
check process health.
|
||||
|
||||
```bash
|
||||
curl http://127.0.0.1:8900/v1/models \
|
||||
-H "Authorization: Bearer $NANOBOT_API_KEY"
|
||||
```
|
||||
|
||||
## Behavior
|
||||
|
||||
- Session isolation: pass `"session_id"` in the request body to isolate conversations; omit for a shared default session (`api:default`)
|
||||
- Single-message input: each request must contain exactly one `user` message
|
||||
- Fixed model: omit `model`, or pass the same model shown by `/v1/models`
|
||||
- Streaming: set `stream=true` to receive Server-Sent Events (`text/event-stream`) with OpenAI-compatible delta chunks, terminated by `data: [DONE]`; omit or set `stream=false` for a single JSON response
|
||||
- **File uploads**: supports images, PDF, Word (.docx), Excel (.xlsx), PowerPoint (.pptx) via JSON base64 or `multipart/form-data` (max 10MB per file)
|
||||
- API requests run in the synthetic `api` channel, so the `message` tool does **not** automatically deliver to Telegram/Discord/etc. To proactively send to another chat, call `message` with an explicit `channel` and `chat_id` for an enabled channel.
|
||||
|
||||
Example tool call for cross-channel delivery from an API session:
|
||||
|
||||
```json
|
||||
{
|
||||
"content": "Build finished successfully.",
|
||||
"channel": "telegram",
|
||||
"chat_id": "123456789"
|
||||
}
|
||||
```
|
||||
|
||||
If `channel` points to a channel that is not enabled in your config, nanobot will queue the outbound event but no platform delivery will occur.
|
||||
|
||||
## Endpoints
|
||||
|
||||
- `GET /health`
|
||||
- `GET /v1/models`
|
||||
- `POST /v1/chat/completions`
|
||||
|
||||
## curl
|
||||
|
||||
```bash
|
||||
curl http://127.0.0.1:8900/v1/chat/completions \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"messages": [{"role": "user", "content": "hi"}],
|
||||
"session_id": "my-session"
|
||||
}'
|
||||
```
|
||||
|
||||
## File Upload (JSON base64)
|
||||
|
||||
Send images inline using the OpenAI multimodal content format:
|
||||
|
||||
```bash
|
||||
curl http://127.0.0.1:8900/v1/chat/completions \
|
||||
-H "Content-Type: application/json" \
|
||||
-d '{
|
||||
"messages": [{"role": "user", "content": [
|
||||
{"type": "text", "text": "Describe this image"},
|
||||
{"type": "image_url", "image_url": {"url": "data:image/png;base64,iVBOR..."}}
|
||||
]}]
|
||||
}'
|
||||
```
|
||||
|
||||
## File Upload (multipart/form-data)
|
||||
|
||||
Upload any supported file type (images, PDF, Word, Excel, PPT) via multipart:
|
||||
|
||||
```bash
|
||||
# Single file
|
||||
curl http://127.0.0.1:8900/v1/chat/completions \
|
||||
-F "message=Summarize this report" \
|
||||
-F "files=@report.docx"
|
||||
|
||||
# Multiple files with session isolation
|
||||
curl http://127.0.0.1:8900/v1/chat/completions \
|
||||
-F "message=Compare these files" \
|
||||
-F "files=@chart.png" \
|
||||
-F "files=@data.xlsx" \
|
||||
-F "session_id=my-session"
|
||||
```
|
||||
|
||||
Supported file types:
|
||||
- **Images**: PNG, JPEG, GIF, WebP (sent to AI as base64 for vision analysis)
|
||||
- **Documents**: PDF, Word (.docx), Excel (.xlsx), PowerPoint (.pptx) (text extracted and sent to AI)
|
||||
- **Text**: TXT, Markdown, CSV, JSON, etc. (read directly)
|
||||
|
||||
## Python (`requests`)
|
||||
|
||||
```python
|
||||
import requests
|
||||
|
||||
resp = requests.post(
|
||||
"http://127.0.0.1:8900/v1/chat/completions",
|
||||
json={
|
||||
"messages": [{"role": "user", "content": "hi"}],
|
||||
"session_id": "my-session", # optional: isolate conversation
|
||||
},
|
||||
timeout=120,
|
||||
)
|
||||
resp.raise_for_status()
|
||||
print(resp.json()["choices"][0]["message"]["content"])
|
||||
```
|
||||
|
||||
## Python (`openai`)
|
||||
|
||||
```python
|
||||
from openai import OpenAI
|
||||
|
||||
client = OpenAI(
|
||||
base_url="http://127.0.0.1:8900/v1",
|
||||
api_key="dummy",
|
||||
)
|
||||
|
||||
resp = client.chat.completions.create(
|
||||
model="MiniMax-M2.7",
|
||||
messages=[{"role": "user", "content": "hi"}],
|
||||
extra_body={"session_id": "my-session"}, # optional: isolate conversation
|
||||
)
|
||||
print(resp.choices[0].message.content)
|
||||
```
|
||||
@@ -0,0 +1,626 @@
|
||||
# Provider Cookbook
|
||||
|
||||
This page is for cases where you already know what you want to connect and need a pasteable setup. Each recipe shows what to set, what to run, and what a failure usually means.
|
||||
|
||||
If this is your first install and terminal commands are new to you, start with [`start-without-technical-background.md`](./start-without-technical-background.md). If you want the field-by-field explanation, read [`providers.md`](./providers.md) and then [`configuration.md#providers`](./configuration.md#providers).
|
||||
|
||||
Most examples below are snippets to merge into `~/.nanobot/config.json`. Keep any existing sections you still need, and replace placeholder keys such as `${OPENROUTER_API_KEY}` with environment-variable references or real values only on your own machine.
|
||||
|
||||
Recipes are examples, not rankings. Pick the recipe that matches the credential, endpoint, and model ID you already intend to use.
|
||||
|
||||
## Choose a Recipe
|
||||
|
||||
Match the recipe to the credential or endpoint you already have:
|
||||
|
||||
| What you have | Recipe | Must match |
|
||||
|---|---|---|
|
||||
| A gateway key and model IDs that include a model family path, such as `provider/model-name` | [OpenRouter Gateway](#recipe-openrouter-gateway) | API key, provider config key, preset provider, and gateway model ID |
|
||||
| An OpenCode Zen or Go key | [OpenCode Zen or Go](#recipe-opencode-zen-or-go) | `OPENCODE_API_KEY`, the Zen/Go provider key, and a model ID from the matching OpenCode endpoint |
|
||||
| An OpenAI platform API key and OpenAI model ID | [OpenAI Direct](#recipe-openai-direct) | `OPENAI_API_KEY`, `provider: "openai"`, and an OpenAI model available to that account |
|
||||
| An Anthropic API key and Anthropic model ID | [Anthropic Direct](#recipe-anthropic-direct) | `ANTHROPIC_API_KEY`, `provider: "anthropic"`, and a non-gateway model ID |
|
||||
| A Kimi Coding Plan key | [Kimi Coding Plan](#recipe-kimi-coding-plan) | `KIMI_CODING_API_KEY`, `provider: "kimi_coding"`, and `model: "kimi-for-coding"` |
|
||||
| An OpenAI-compatible `/v1` endpoint that is not a named nanobot provider | [Custom OpenAI-Compatible Provider](#recipe-custom-openai-compatible-provider) | `apiBase`, optional API key, and the model ID served by that endpoint |
|
||||
| Ollama already running locally | [Ollama Local Model](#recipe-ollama-local-model) | Ollama `apiBase`, pulled model name, and local server availability |
|
||||
| vLLM, LM Studio, or another local OpenAI-compatible server | [vLLM or LM Studio](#recipe-vllm-or-lm-studio) | Local `/v1` base URL, any required key, and served model name |
|
||||
| A primary model plus one or more backups | [Fallback Presets](#recipe-fallback-presets) | Named presets in `modelPresets`, referenced from `agents.defaults.fallbackModels` |
|
||||
| A working agent and a Langfuse project | [Langfuse Tracing](#recipe-langfuse-tracing) | Langfuse env vars in the same process environment that starts nanobot |
|
||||
|
||||
## How to Use a Recipe
|
||||
|
||||
1. Install nanobot and run `nanobot onboard` once so `~/.nanobot/config.json` exists. Use `nanobot onboard --wizard` if you prefer prompts over hand-editing JSON.
|
||||
2. Put secrets in environment variables when possible.
|
||||
3. Merge the recipe snippet into `~/.nanobot/config.json`.
|
||||
4. Run `nanobot status`.
|
||||
5. Run `nanobot agent -m "Hello!"`.
|
||||
6. If the CLI works, then connect WebUI, gateway, or chat apps.
|
||||
|
||||
The active model should normally come from `agents.defaults.modelPreset`, and that name should point to an entry in `modelPresets`. Direct `agents.defaults.provider` and `agents.defaults.model` still work for older configs, but presets are easier to switch and easier to reuse as fallbacks.
|
||||
|
||||
## Secret Setup
|
||||
|
||||
Environment variables keep API keys out of the config file.
|
||||
|
||||
Use the variable name shown by the recipe you picked. The commands below use `OPENROUTER_API_KEY` only as an example; an OpenAI direct recipe uses `OPENAI_API_KEY`, an Anthropic direct recipe uses `ANTHROPIC_API_KEY`, and a custom endpoint can use any variable name you reference in `config.json`.
|
||||
|
||||
**macOS / Linux**
|
||||
|
||||
```bash
|
||||
export OPENROUTER_API_KEY="sk-or-v1-..."
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
**Windows PowerShell**
|
||||
|
||||
```powershell
|
||||
$env:OPENROUTER_API_KEY = "sk-or-v1-..."
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
Environment variables set this way apply only to the current terminal. For long-running services such as systemd, Docker, LaunchAgent, or a remote shell, set the variables in that service environment before starting nanobot.
|
||||
|
||||
## Recipe: OpenRouter Gateway
|
||||
|
||||
This recipe applies when one API key routes many hosted model families.
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"openrouter": {
|
||||
"apiKey": "${OPENROUTER_API_KEY}"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"label": "Primary",
|
||||
"provider": "openrouter",
|
||||
"model": "anthropic/claude-sonnet-4.5",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 65536,
|
||||
"temperature": 0.1
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Verify:
|
||||
|
||||
```bash
|
||||
nanobot status
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
If this fails with `401` or `unauthorized`, check that `OPENROUTER_API_KEY` is visible in the same terminal or service that starts nanobot. If it fails with `model not found`, choose a model ID that OpenRouter lists for your account.
|
||||
|
||||
## Recipe: OpenCode Zen or Go
|
||||
|
||||
This recipe applies when your credential comes from OpenCode Zen or OpenCode Go.
|
||||
Both providers use `OPENCODE_API_KEY`; pick the provider block that matches the
|
||||
subscription or balance you want to use.
|
||||
|
||||
OpenCode Zen:
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"opencodeZen": {
|
||||
"apiKey": "${OPENCODE_API_KEY}"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"label": "OpenCode Zen",
|
||||
"provider": "opencode_zen",
|
||||
"model": "opencode/deepseek-v4-pro",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 65536,
|
||||
"temperature": 0.1
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
OpenCode Go:
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"opencodeGo": {
|
||||
"apiKey": "${OPENCODE_API_KEY}"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"label": "OpenCode Go",
|
||||
"provider": "opencode_go",
|
||||
"model": "opencode-go/deepseek-v4-flash",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 65536,
|
||||
"temperature": 0.1
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Verify:
|
||||
|
||||
```bash
|
||||
nanobot status
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
OpenCode's docs list models across multiple endpoint types. The `opencode_zen`
|
||||
and `opencode_go` providers in nanobot use the OpenAI-compatible
|
||||
`chat/completions` path. If a model fails with `model not found` or an endpoint
|
||||
shape error, choose a model that OpenCode lists under `chat/completions` for the
|
||||
matching Zen or Go endpoint.
|
||||
|
||||
## Recipe: OpenAI Direct
|
||||
|
||||
This recipe applies when you have an OpenAI API key and want to call OpenAI directly instead of through a gateway.
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"openai": {
|
||||
"apiKey": "${OPENAI_API_KEY}"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"label": "OpenAI",
|
||||
"provider": "openai",
|
||||
"model": "gpt-5",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 128000,
|
||||
"temperature": 0.1
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Verify:
|
||||
|
||||
```bash
|
||||
OPENAI_API_KEY="sk-..." nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
If your shell cannot use inline environment variables, set `OPENAI_API_KEY` first and then run `nanobot agent -m "Hello!"`. If the provider rejects `apiType`, remove `apiType` unless you are using a documented OpenAI-specific mode.
|
||||
|
||||
## Recipe: Anthropic Direct
|
||||
|
||||
This recipe applies when your key comes from Anthropic and your model name is an Anthropic model ID, not an OpenRouter model path.
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"anthropic": {
|
||||
"apiKey": "${ANTHROPIC_API_KEY}"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"label": "Anthropic",
|
||||
"provider": "anthropic",
|
||||
"model": "claude-sonnet-4-5",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 200000,
|
||||
"temperature": 0.1
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Verify:
|
||||
|
||||
```bash
|
||||
ANTHROPIC_API_KEY="sk-ant-..." nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
If you copied a model name such as `anthropic/claude-sonnet-4.5`, that is a gateway-style model path and belongs under `provider: "openrouter"`, not `provider: "anthropic"`.
|
||||
|
||||
If you use an Anthropic-compatible proxy, keep the preset provider as `anthropic` and set `providers.anthropic.apiBase`:
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"anthropic": {
|
||||
"apiKey": "${ANTHROPIC_API_KEY}",
|
||||
"apiBase": "https://anthropic-proxy.example.com"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"label": "Anthropic proxy",
|
||||
"provider": "anthropic",
|
||||
"model": "claude-sonnet-4-5",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 200000,
|
||||
"temperature": 0.1
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Do not configure Anthropic-compatible endpoints as arbitrary custom provider names; named custom providers use the OpenAI-compatible request format.
|
||||
|
||||
## Recipe: Kimi Coding Plan
|
||||
|
||||
This recipe applies when your key comes from Kimi's Coding Plan endpoint. Nanobot uses a dedicated `kimi_coding` provider for this Anthropic Messages API endpoint; do not configure it as a generic `custom` provider.
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"kimiCoding": {
|
||||
"apiKey": "${KIMI_CODING_API_KEY}"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"kimiCoding": {
|
||||
"label": "Kimi Coding",
|
||||
"provider": "kimi_coding",
|
||||
"model": "kimi-for-coding",
|
||||
"maxTokens": 4096,
|
||||
"temperature": 0.1
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "kimiCoding"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Verify:
|
||||
|
||||
```bash
|
||||
nanobot status
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
The default base URL is `https://api.kimi.com/coding/v1`. This endpoint requires a Claude-compatible `User-Agent`; nanobot sends `claude-code/0.1.0` by default. If your account requires a different value, override it with `providers.kimiCoding.extraHeaders.User-Agent`.
|
||||
|
||||
## Recipe: Custom OpenAI-Compatible Provider
|
||||
|
||||
This recipe applies to an OpenAI-compatible service that is not a named nanobot provider.
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"custom": {
|
||||
"apiKey": "${CUSTOM_API_KEY}",
|
||||
"apiBase": "https://api.example.com/v1"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"label": "Custom",
|
||||
"provider": "custom",
|
||||
"model": "provider-model-name",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 65536,
|
||||
"temperature": 0.1
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Verify the endpoint before blaming nanobot:
|
||||
|
||||
```bash
|
||||
curl -sS https://api.example.com/v1/models
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
`apiBase` is the HTTP base URL, not the model name. Include the version path when the service expects it, such as `/v1`. If the service requires a non-empty key but does not validate it, use a placeholder such as `"apiKey": "EMPTY"`.
|
||||
|
||||
For multiple custom endpoints, do not overload the single `custom` block. Name each endpoint under `providers` and reference that same name from the preset:
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"workProxy": {
|
||||
"apiKey": "${WORK_PROXY_API_KEY}",
|
||||
"apiBase": "https://proxy.example.com/v1"
|
||||
},
|
||||
"lab-local": {
|
||||
"apiBase": "http://127.0.0.1:8000/v1"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"work": {
|
||||
"label": "Work proxy",
|
||||
"provider": "workProxy",
|
||||
"model": "gpt-4o-mini",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 65536,
|
||||
"temperature": 0.1
|
||||
},
|
||||
"lab": {
|
||||
"label": "Lab local",
|
||||
"provider": "lab-local",
|
||||
"model": "served-model-name",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 65536,
|
||||
"temperature": 0.1
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "work"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
These custom names behave like direct OpenAI-compatible providers: `apiBase` is required, `apiKey` is optional when the endpoint allows anonymous or placeholder credentials, and `apiType` should be left unset. They do not support Anthropic-compatible endpoints; use the `anthropic` provider with `apiBase` for that case.
|
||||
|
||||
## Recipe: Ollama Local Model
|
||||
|
||||
This recipe applies when Ollama is already installed and the model has been pulled locally.
|
||||
|
||||
```bash
|
||||
ollama serve
|
||||
ollama pull llama3.2
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"ollama": {
|
||||
"apiBase": "http://localhost:11434/v1"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"local": {
|
||||
"label": "Local",
|
||||
"provider": "ollama",
|
||||
"model": "llama3.2",
|
||||
"maxTokens": 2048,
|
||||
"contextWindowTokens": 32768,
|
||||
"temperature": 0.2
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "local"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Verify:
|
||||
|
||||
```bash
|
||||
curl -sS http://localhost:11434/v1/models
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
If you see `connection refused`, Ollama is not running or `apiBase` points to the wrong port. If the response is very slow, try a smaller local model or lower `contextWindowTokens`.
|
||||
|
||||
## Recipe: vLLM or LM Studio
|
||||
|
||||
This recipe applies when a local server exposes an OpenAI-compatible `/v1` API.
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"vllm": {
|
||||
"apiBase": "http://127.0.0.1:8000/v1",
|
||||
"apiKey": "EMPTY"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"local": {
|
||||
"label": "Local",
|
||||
"provider": "vllm",
|
||||
"model": "served-model-name",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 65536,
|
||||
"temperature": 0.2
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "local"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
For LM Studio, use its local base URL and provider name:
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"lmStudio": {
|
||||
"apiBase": "http://localhost:1234/v1"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"local": {
|
||||
"label": "LM Studio",
|
||||
"provider": "lm_studio",
|
||||
"model": "local-model",
|
||||
"maxTokens": 2048,
|
||||
"contextWindowTokens": 32768
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "local"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The config key can be `lmStudio` or `lm_studio`, but the preset provider should use the registry name `lm_studio`.
|
||||
|
||||
## Recipe: Fallback Presets
|
||||
|
||||
This recipe applies when one provider sometimes rate-limits, one model is expensive, or you want a local backup.
|
||||
|
||||
```json
|
||||
{
|
||||
"modelPresets": {
|
||||
"fast": {
|
||||
"label": "Fast",
|
||||
"provider": "openrouter",
|
||||
"model": "anthropic/claude-sonnet-4.5",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 65536,
|
||||
"temperature": 0.1
|
||||
},
|
||||
"deep": {
|
||||
"label": "Deep",
|
||||
"provider": "anthropic",
|
||||
"model": "claude-sonnet-4-5",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 200000,
|
||||
"temperature": 0.1
|
||||
},
|
||||
"local": {
|
||||
"label": "Local",
|
||||
"provider": "ollama",
|
||||
"model": "llama3.2",
|
||||
"maxTokens": 2048,
|
||||
"contextWindowTokens": 32768,
|
||||
"temperature": 0.2
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "fast",
|
||||
"fallbackModels": ["deep", "local"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`fallbackModels` belongs under `agents.defaults`. String entries are preset names, not raw model names. nanobot tries the active preset first, then the fallback presets in order.
|
||||
|
||||
Keep fallback candidates realistic. If the local fallback has a smaller context window, nanobot must build context that fits the smallest window in the active chain.
|
||||
|
||||
## Recipe: Langfuse Tracing
|
||||
|
||||
This recipe applies after the agent works and you want observability for OpenAI-compatible provider calls.
|
||||
|
||||
Install the optional package in the same Python environment that runs nanobot:
|
||||
|
||||
```bash
|
||||
python -m pip install langfuse
|
||||
```
|
||||
|
||||
Set the environment variables before starting nanobot:
|
||||
|
||||
```bash
|
||||
export LANGFUSE_SECRET_KEY="sk-lf-..."
|
||||
export LANGFUSE_PUBLIC_KEY="pk-lf-..."
|
||||
export LANGFUSE_BASE_URL="https://cloud.langfuse.com"
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
PowerShell:
|
||||
|
||||
```powershell
|
||||
$env:LANGFUSE_SECRET_KEY = "sk-lf-..."
|
||||
$env:LANGFUSE_PUBLIC_KEY = "pk-lf-..."
|
||||
$env:LANGFUSE_BASE_URL = "https://cloud.langfuse.com"
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
Langfuse is not a model provider in `config.json`. It is configured through environment variables and traces supported OpenAI-compatible provider calls. Native providers that do not use that client path may not produce Langfuse OpenAI-wrapper traces.
|
||||
|
||||
## Recipe: Switch Models at Runtime
|
||||
|
||||
Use this after you have more than one preset and are chatting through a supported channel.
|
||||
|
||||
```json
|
||||
{
|
||||
"modelPresets": {
|
||||
"fast": {
|
||||
"label": "Fast",
|
||||
"provider": "openrouter",
|
||||
"model": "anthropic/claude-sonnet-4.5",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 65536
|
||||
},
|
||||
"local": {
|
||||
"label": "Local",
|
||||
"provider": "ollama",
|
||||
"model": "llama3.2",
|
||||
"maxTokens": 2048,
|
||||
"contextWindowTokens": 32768
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "fast"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
In chat:
|
||||
|
||||
```text
|
||||
/model
|
||||
/model local
|
||||
/model fast
|
||||
```
|
||||
|
||||
`/model` switching is runtime-only. It does not rewrite `config.json`, and an in-progress turn keeps using the model it started with.
|
||||
|
||||
## Quick Failure Map
|
||||
|
||||
| Symptom | Usually means | First check |
|
||||
|---|---|---|
|
||||
| `401`, `unauthorized`, or `invalid API key` | The key is missing, wrong, expired, or under the wrong provider | Print or re-set the environment variable in the same terminal or service |
|
||||
| `model not found` | The model ID does not belong to the selected provider or gateway | Compare `modelPresets.<name>.provider` and `modelPresets.<name>.model` |
|
||||
| `connection refused` | Local server is not running or `apiBase` has the wrong port/path | Run `curl <apiBase>/models` |
|
||||
| `provider not found` | Provider name is misspelled or uses the config key instead of registry name | Use names such as `openrouter`, `openai`, `anthropic`, `ollama`, `vllm`, `lm_studio` |
|
||||
| Langfuse shows no traces | Env vars are missing, `langfuse` is not installed in the active Python environment, or the provider path is native | Run `python -m pip show langfuse` and restart nanobot from the same environment |
|
||||
|
||||
## Next References
|
||||
|
||||
| Need | Read |
|
||||
|---|---|
|
||||
| Field meanings and provider resolution | [`providers.md`](./providers.md) |
|
||||
| Full schema and provider table | [`configuration.md#providers`](./configuration.md#providers) |
|
||||
| Langfuse details | [`configuration.md#langfuse-observability`](./configuration.md#langfuse-observability) |
|
||||
| First-run diagnosis | [`troubleshooting.md`](./troubleshooting.md) |
|
||||
@@ -0,0 +1,604 @@
|
||||
# Providers and Models
|
||||
|
||||
Use this page when the first reply fails because of provider/model mismatch, or when you want to adapt the concrete setup example to a different provider. If you already know which provider you want and only need a pasteable setup, use [`provider-cookbook.md`](./provider-cookbook.md).
|
||||
|
||||
For every setup, answer three questions:
|
||||
|
||||
1. Which provider owns the credential or endpoint?
|
||||
2. What model name does that provider expect?
|
||||
3. Does the provider need `apiKey`, `apiBase`, OAuth login, cloud credentials, or only a local server URL?
|
||||
|
||||
Prefer a named `modelPresets` entry for the model/provider pair, then select it with `agents.defaults.modelPreset`. Direct `agents.defaults.provider` and `agents.defaults.model` still work for existing configs, but presets make runtime `/model` switching and fallback chains clearer. Pin `provider` inside the preset while setting up; you can switch back to `"auto"` later.
|
||||
|
||||
## Choose a Provider Without Guessing
|
||||
|
||||
The docs show concrete provider names so the JSON is copyable, not because nanobot ranks providers. Start from the service or endpoint you actually control:
|
||||
|
||||
| If you have... | Configure... |
|
||||
|---|---|
|
||||
| An API key from a hosted provider or gateway | That provider's `providers.<name>.apiKey`, then a preset with that provider name and a model ID from that service. |
|
||||
| An OpenCode Zen or Go key | `providers.opencodeZen.apiKey` or `providers.opencodeGo.apiKey`, then a preset with `provider: "opencode_zen"` or `provider: "opencode_go"`. |
|
||||
| A company proxy or regional endpoint | The matching provider block plus `apiBase` if the proxy gives you a URL. |
|
||||
| A local OpenAI-compatible server | A local provider block such as `ollama`, `vllm`, `lmStudio`, or `custom`, usually with `apiBase`. |
|
||||
| An OAuth-based account | Run the matching `nanobot provider login ...` command, then select that provider explicitly in a preset. |
|
||||
| No provider yet | Pick one outside nanobot based on account access, pricing, regional availability, privacy requirements, and the model IDs you need. Then come back with its key and model ID. |
|
||||
|
||||
## Minimal Shape
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"openrouter": {
|
||||
"apiKey": "sk-or-v1-xxx"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"provider": "openrouter",
|
||||
"model": "anthropic/claude-opus-4.5",
|
||||
"maxTokens": 8192,
|
||||
"contextWindowTokens": 65536,
|
||||
"temperature": 0.1
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The provider config gives nanobot credentials and endpoint details. The model preset names the provider/model pair. The agent defaults choose which named preset to use for normal turns. Replace the example provider and model together; mixing an API key from one provider with a model ID from another is the most common first-run failure.
|
||||
|
||||
## Provider, Model, API Key, and Base URL
|
||||
|
||||
These fields answer different questions:
|
||||
|
||||
| Field | Where it lives | Meaning |
|
||||
|---|---|---|
|
||||
| `provider` | `modelPresets.<name>.provider` | Which nanobot provider adapter should send the request. |
|
||||
| `model` | `modelPresets.<name>.model` | The model ID expected by that provider or gateway. |
|
||||
| `apiKey` | `providers.<provider>.apiKey` | Credential for that provider. Use `${ENV_VAR}` for secrets. |
|
||||
| `apiBase` | `providers.<provider>.apiBase` | HTTP base URL of the provider endpoint. |
|
||||
| `proxy` | `providers.<provider>.proxy` | Optional HTTP proxy for this provider only. Supported for OpenAI-compatible providers and OpenAI Codex. |
|
||||
|
||||
You usually omit `apiBase` for hosted built-in providers such as OpenRouter, Anthropic direct, OpenAI direct, Groq, or Bedrock because nanobot knows their default endpoints. Set `apiBase` for `custom`, local OpenAI-compatible servers, provider proxies, regional endpoints, or subscription endpoints. Include the API version path when the endpoint requires it, for example `https://api.example.com/v1` or `http://localhost:11434/v1`.
|
||||
|
||||
Use `proxy` when one provider must send HTTP traffic through a proxy without changing process-wide `HTTP_PROXY` / `HTTPS_PROXY`. This is supported for providers that use nanobot's OpenAI-compatible client, including `openai`, `custom`, named custom providers, OpenRouter-style gateways, local OpenAI-compatible servers, and similar registry entries. It is also supported for `openai_codex`, including Codex OAuth token exchange/refresh and Codex Responses API requests. Native provider backends such as `anthropic`, `bedrock`, `azure_openai`, and `github_copilot` reject `proxy`; use their endpoint-specific configuration instead.
|
||||
|
||||
## Common Provider Patterns
|
||||
|
||||
### OpenRouter Gateway
|
||||
|
||||
Gateway-style setup for model IDs served through OpenRouter.
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"openrouter": {
|
||||
"apiKey": "${OPENROUTER_API_KEY}"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"provider": "openrouter",
|
||||
"model": "anthropic/claude-opus-4.5",
|
||||
"maxTokens": 8192,
|
||||
"contextWindowTokens": 65536
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Use the model ID exactly as OpenRouter lists it.
|
||||
|
||||
### OpenCode Zen and Go
|
||||
|
||||
OpenCode Zen and OpenCode Go are OpenCode-managed gateways for coding-agent models.
|
||||
They share `OPENCODE_API_KEY`, but use separate provider config keys and default base
|
||||
URLs in nanobot.
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"opencodeZen": {
|
||||
"apiKey": "${OPENCODE_API_KEY}"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"provider": "opencode_zen",
|
||||
"model": "opencode/deepseek-v4-pro",
|
||||
"maxTokens": 8192,
|
||||
"contextWindowTokens": 65536
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
For OpenCode Go, switch the provider block and preset:
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"opencodeGo": {
|
||||
"apiKey": "${OPENCODE_API_KEY}"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"provider": "opencode_go",
|
||||
"model": "opencode-go/deepseek-v4-flash",
|
||||
"maxTokens": 8192,
|
||||
"contextWindowTokens": 65536
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
OpenCode documents model IDs with `opencode/<model-id>` for Zen and
|
||||
`opencode-go/<model-id>` for Go. nanobot accepts those prefixes and strips them
|
||||
before sending the request to OpenCode. Use model IDs that OpenCode lists under
|
||||
the `chat/completions` endpoint; models listed only under `responses`,
|
||||
`messages`, or provider-specific endpoints are not handled by this
|
||||
OpenAI-compatible provider path.
|
||||
|
||||
### Anthropic Direct
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"anthropic": {
|
||||
"apiKey": "${ANTHROPIC_API_KEY}"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"provider": "anthropic",
|
||||
"model": "claude-opus-4-5",
|
||||
"maxTokens": 8192,
|
||||
"contextWindowTokens": 200000
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Anthropic direct uses the native Anthropic provider. Do not use an OpenRouter model ID unless the provider is OpenRouter.
|
||||
|
||||
If you use an Anthropic-compatible proxy, keep the provider as `anthropic` and override `apiBase`:
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"anthropic": {
|
||||
"apiKey": "${ANTHROPIC_API_KEY}",
|
||||
"apiBase": "https://anthropic-proxy.example.com"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"provider": "anthropic",
|
||||
"model": "claude-sonnet-4-5"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Arbitrary custom provider names are OpenAI-compatible only; they do not use the Anthropic Messages API request format.
|
||||
|
||||
### OpenAI Direct
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"openai": {
|
||||
"apiKey": "${OPENAI_API_KEY}"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"provider": "openai",
|
||||
"model": "gpt-5",
|
||||
"maxTokens": 8192,
|
||||
"contextWindowTokens": 128000
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`providers.openai.apiType` may be set when you need to force a specific OpenAI API surface. Other providers reject `apiType`; leave it unset outside `providers.openai`. Replace the model with a model ID available to your OpenAI account.
|
||||
|
||||
### Custom OpenAI-Compatible Endpoint
|
||||
|
||||
The `custom` provider fits one OpenAI-compatible endpoint that is not represented by a named provider.
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"custom": {
|
||||
"apiKey": "${CUSTOM_API_KEY}",
|
||||
"apiBase": "https://example.com/v1"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"provider": "custom",
|
||||
"model": "provider-model-name",
|
||||
"maxTokens": 8192,
|
||||
"contextWindowTokens": 65536
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`custom` does not infer a default base URL. Set `apiBase`.
|
||||
|
||||
If you have more than one custom OpenAI-compatible endpoint, give each endpoint its own provider key under `providers` and use that same key in the model preset. The key can be a name that makes sense in your environment, such as `companyProxy`, `tenant-a`, or `dev-local`.
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"companyProxy": {
|
||||
"apiKey": "${COMPANY_PROXY_API_KEY}",
|
||||
"apiBase": "https://llm-proxy.example.com/v1"
|
||||
},
|
||||
"tenant-a": {
|
||||
"apiBase": "https://tenant-a.example.com/v1"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"company": {
|
||||
"provider": "companyProxy",
|
||||
"model": "gpt-4o-mini",
|
||||
"maxTokens": 8192,
|
||||
"contextWindowTokens": 65536
|
||||
},
|
||||
"tenantA": {
|
||||
"provider": "tenant-a",
|
||||
"model": "served-model-name",
|
||||
"maxTokens": 8192,
|
||||
"contextWindowTokens": 65536
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "company"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Custom provider keys are treated as direct OpenAI-compatible providers. `apiBase` is required because nanobot cannot know the endpoint URL. `apiKey` is optional for local servers or private proxies that do not require one. Choose a name that does not conflict with a built-in provider name or alias, such as `openai`, `openai-codex`, `github-copilot`, or `lm-studio`. Do not set `apiType` on custom provider keys; `apiType` is only for `providers.openai`.
|
||||
|
||||
If your custom endpoint documents a nonstandard thinking toggle, set `providers.<name>.thinkingStyle` to `thinking_type`, `enable_thinking`, or `reasoning_split`; nanobot then maps `reasoningEffort` onto that provider-specific request body. Leave it unset for ordinary OpenAI-compatible endpoints.
|
||||
|
||||
This named custom provider path is not for Anthropic-compatible endpoints. For Anthropic-compatible proxies, use `providers.anthropic.apiBase` and set the preset provider to `anthropic`.
|
||||
|
||||
### Ollama
|
||||
|
||||
Start Ollama separately, then point nanobot at the OpenAI-compatible endpoint.
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"ollama": {
|
||||
"apiBase": "http://localhost:11434/v1"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"provider": "ollama",
|
||||
"model": "llama3.2",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 32768
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Most Ollama setups do not require an API key.
|
||||
|
||||
### vLLM or Other Local OpenAI-Compatible Server
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"vllm": {
|
||||
"apiBase": "http://127.0.0.1:8000/v1",
|
||||
"apiKey": "EMPTY"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"provider": "vllm",
|
||||
"model": "served-model-name",
|
||||
"maxTokens": 8192,
|
||||
"contextWindowTokens": 65536
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Some OpenAI-compatible local servers require any non-empty API key even when they do not validate it.
|
||||
|
||||
### LM Studio
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"lmStudio": {
|
||||
"apiBase": "http://localhost:1234/v1"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"provider": "lm_studio",
|
||||
"model": "local-model",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 32768
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Config keys may be camelCase or snake_case. Provider names in model presets should use the registry name, such as `lm_studio`.
|
||||
|
||||
### AWS Bedrock
|
||||
|
||||
Bedrock can use the AWS credential chain, profile, region, or Bedrock bearer token depending on your AWS setup.
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"bedrock": {
|
||||
"region": "us-east-1",
|
||||
"profile": "default"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"provider": "bedrock",
|
||||
"model": "bedrock/anthropic.claude-sonnet-4-5-20250929-v1:0",
|
||||
"maxTokens": 8192,
|
||||
"contextWindowTokens": 200000
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
See [`configuration.md#providers`](./configuration.md#providers) for Bedrock-specific notes.
|
||||
|
||||
### OAuth Providers
|
||||
|
||||
Some providers do not use API keys in `config.json`.
|
||||
|
||||
```bash
|
||||
nanobot provider login openai-codex
|
||||
nanobot provider login github-copilot
|
||||
```
|
||||
|
||||
Then explicitly select the provider and model in a preset. OAuth providers are not valid automatic fallbacks.
|
||||
|
||||
For OpenAI Codex, add `providers.openai_codex.proxy` only when Codex OAuth/token refresh or Codex API requests must use a proxy:
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"openai_codex": {
|
||||
"proxy": "http://127.0.0.1:7890"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"codex": {
|
||||
"provider": "openai_codex",
|
||||
"model": "gpt-5.1-codex",
|
||||
"reasoningEffort": "high"
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "codex"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
If you run the login command on a remote/headless machine and open the authorization URL in a local browser, paste the final `http://localhost:1455/auth/callback?...` redirect URL back into the terminal when prompted. See [`configuration.md#providers`](./configuration.md#providers) for the full OAuth provider notes.
|
||||
|
||||
## Provider Resolution
|
||||
|
||||
The recommended path is a named preset selected by `agents.defaults.modelPreset`. The effective model parameters come from:
|
||||
|
||||
1. the named `modelPresets` entry referenced by `agents.defaults.modelPreset`;
|
||||
2. otherwise the implicit `default` preset built from `agents.defaults.model`, `provider`, `maxTokens`, `contextWindowTokens`, `temperature`, and related fields.
|
||||
|
||||
Provider selection follows this practical rule:
|
||||
|
||||
- Explicit `provider` in the active preset or implicit default config wins.
|
||||
- `provider: "auto"` tries model-name keywords, configured keys, local base URLs, and gateway providers.
|
||||
- Gateway providers such as OpenRouter and AiHubMix can route many model families, so the model name must be valid for that gateway.
|
||||
- Local providers should normally be explicit because generic local model names such as `llama3.2` do not always contain provider keywords.
|
||||
|
||||
### Model Name Prefixes
|
||||
|
||||
`family/model-name` does not always select provider `family`. Prefix-based provider inference only runs when the active provider is `"auto"`.
|
||||
|
||||
- Explicit provider wins: `provider: "openrouter"` with `model: "anthropic/claude-sonnet-4.5"` calls OpenRouter, not Anthropic.
|
||||
- With `provider: "auto"`, a prefix matching a configured built-in or named custom provider can select that provider. Named custom prefixes are stripped before request, so `companyProxy/gpt-4o-mini` is sent upstream as `gpt-4o-mini`.
|
||||
- With an explicit named custom provider, the model is sent as written; `provider: "companyProxy"` with `model: "openai/gpt-4o-mini"` sends `openai/gpt-4o-mini` to `companyProxy`.
|
||||
|
||||
Pin `provider` in presets when using gateway catalog IDs such as `anthropic/claude-sonnet-4.5`.
|
||||
|
||||
## Model Presets
|
||||
|
||||
Model presets are the recommended model configuration surface. Use them when you want named model choices, runtime `/model` switching, or reusable fallback targets.
|
||||
|
||||
```json
|
||||
{
|
||||
"modelPresets": {
|
||||
"fast": {
|
||||
"label": "Fast",
|
||||
"provider": "openrouter",
|
||||
"model": "anthropic/claude-sonnet-4.5",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 65536,
|
||||
"temperature": 0.1
|
||||
},
|
||||
"deep": {
|
||||
"label": "Deep",
|
||||
"provider": "anthropic",
|
||||
"model": "claude-opus-4-5",
|
||||
"maxTokens": 8192,
|
||||
"contextWindowTokens": 200000,
|
||||
"temperature": 0.1
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "fast"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The preset name `default` is reserved for the implicit `agents.defaults` settings. Do not define `modelPresets.default`; use `/model default` to return to the direct `agents.defaults.*` fields in older configs.
|
||||
|
||||
## Fallback Models
|
||||
|
||||
Fallbacks are useful for transient provider failures, rate limits, or model availability issues. Keep fallbacks compatible with the task size and tool use. Prefer fallback presets so each candidate has a name and a complete provider, model, generation, and context-window configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"modelPresets": {
|
||||
"fast": {
|
||||
"label": "Fast",
|
||||
"provider": "openrouter",
|
||||
"model": "anthropic/claude-sonnet-4.5",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 65536,
|
||||
"temperature": 0.1
|
||||
},
|
||||
"deep": {
|
||||
"label": "Deep",
|
||||
"provider": "anthropic",
|
||||
"model": "claude-opus-4-5",
|
||||
"maxTokens": 8192,
|
||||
"contextWindowTokens": 200000,
|
||||
"temperature": 0.1
|
||||
},
|
||||
"localSmall": {
|
||||
"label": "Local Small",
|
||||
"provider": "ollama",
|
||||
"model": "llama3.2",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 32768,
|
||||
"temperature": 0.2
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "fast",
|
||||
"fallbackModels": ["deep", "localSmall"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
String entries in `fallbackModels` are preset names, not raw model names. nanobot tries them in order after the active preset. Each fallback preset uses its own `provider`, `model`, `maxTokens`, `contextWindowTokens`, `temperature`, and optional `reasoningEffort`.
|
||||
|
||||
Use inline fallback objects only when a model is not worth naming as a preset:
|
||||
|
||||
```json
|
||||
{
|
||||
"modelPresets": {
|
||||
"fast": {
|
||||
"provider": "openrouter",
|
||||
"model": "anthropic/claude-sonnet-4.5",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 65536
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "fast",
|
||||
"fallbackModels": [
|
||||
{
|
||||
"provider": "deepseek",
|
||||
"model": "deepseek-v4-pro",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 262144
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
`fallbackModels` belongs under `agents.defaults`, not inside each preset. If fallback candidates use smaller context windows, nanobot builds context using the smallest window in the active chain so every candidate can receive the same prompt. See [`configuration.md#model-fallbacks`](./configuration.md#model-fallbacks) for failure conditions.
|
||||
|
||||
## Quick Checks
|
||||
|
||||
Run these before debugging a chat app:
|
||||
|
||||
```bash
|
||||
nanobot status
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
If `nanobot agent -m "Hello!"` fails:
|
||||
|
||||
| Symptom | Likely cause |
|
||||
|---|---|
|
||||
| 401, unauthorized, invalid API key | Key is missing, expired, copied with whitespace, or stored under the wrong provider |
|
||||
| model not found | Model ID does not exist for the selected provider or gateway |
|
||||
| connection refused | Local provider server is not running or `apiBase` points to the wrong port |
|
||||
| provider not found | The active preset uses a misspelled provider; use registry names such as `openrouter`, `anthropic`, `ollama`, `vllm`, `lm_studio` |
|
||||
| works in CLI but not chat app | Provider is fine; debug gateway/channel setup in [`chat-apps.md`](./chat-apps.md) or [`troubleshooting.md`](./troubleshooting.md) |
|
||||
|
||||
For the complete provider table and advanced provider-specific notes, see [`configuration.md#providers`](./configuration.md#providers).
|
||||
@@ -0,0 +1,760 @@
|
||||
# Nanobot Python SDK: Run an AI Agent from Python
|
||||
|
||||
Use nanobot as a Python library. The SDK gives you the same agent runtime used
|
||||
by the CLI, but from code: model routing, tools, workspace access, conversation
|
||||
history, memory, streaming events, and runtime helpers.
|
||||
|
||||
If you have used the OpenAI SDK before, the most important difference is this:
|
||||
|
||||
- OpenAI SDK calls a model.
|
||||
- nanobot SDK runs an agent around a model.
|
||||
|
||||
That means one SDK call can read files, call tools, keep session history, use
|
||||
memory, stream progress, and return structured runtime information.
|
||||
|
||||
```text
|
||||
your Python code
|
||||
-> Nanobot SDK
|
||||
-> agent runtime
|
||||
-> configured model provider
|
||||
-> tools
|
||||
-> workspace
|
||||
-> session history
|
||||
-> memory
|
||||
```
|
||||
|
||||
## Before You Start
|
||||
|
||||
Install and configure nanobot first. If you have not done that yet, follow the
|
||||
[Quick Start](quick-start.md) and complete the setup wizard. For SDK-only Python
|
||||
environments, install the package with:
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
```
|
||||
|
||||
`Nanobot.from_config()` reuses your normal `~/.nanobot/config.json` and
|
||||
`~/.nanobot/workspace/`. Provider, model, tools, memory, and session behavior
|
||||
match the CLI unless you override them. For the difference between config and
|
||||
workspace, see [Concepts: Config vs Workspace](concepts.md#config-vs-workspace).
|
||||
|
||||
Before writing SDK code, run the same first-run checks from the main
|
||||
[Install and Quick Start](quick-start.md):
|
||||
|
||||
```bash
|
||||
nanobot status
|
||||
```
|
||||
|
||||
`nanobot status` should show the config path, workspace path, active model or
|
||||
preset, and provider summary. Then send one real message:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
A normal assistant reply means install, config, provider/model selection, and
|
||||
workspace access are all usable. Once that works, the SDK should see the same
|
||||
runtime.
|
||||
|
||||
## 5-Minute Quick Start
|
||||
|
||||
### Ask One Question
|
||||
|
||||
```python
|
||||
import asyncio
|
||||
|
||||
from nanobot import Nanobot
|
||||
|
||||
|
||||
async def main() -> None:
|
||||
async with Nanobot.from_config() as bot:
|
||||
result = await bot.run("What time is it in Tokyo?")
|
||||
print(result.content)
|
||||
|
||||
|
||||
asyncio.run(main())
|
||||
```
|
||||
|
||||
Use `async with` when possible so tool connections and background cleanup are
|
||||
closed before the event loop exits. If you manage the instance manually, call
|
||||
`await bot.aclose()` in a `finally` block.
|
||||
|
||||
The SDK is async-first because agent runs may stream tokens, execute tools, and
|
||||
wait on external services. In a normal Python script, wrap your async function
|
||||
with `asyncio.run(...)` as shown above. In a notebook or another async app, call
|
||||
`await bot.run(...)` directly from your existing event loop.
|
||||
|
||||
### Inspect What Happened
|
||||
|
||||
`bot.run(...)` returns a `RunResult`, not just a string:
|
||||
|
||||
```python
|
||||
result = await bot.run("Review this repository")
|
||||
|
||||
print(result.content) # final answer
|
||||
print(result.tools_used) # tools the agent used
|
||||
print(result.usage) # token usage when available
|
||||
print(result.stop_reason) # why the run stopped
|
||||
```
|
||||
|
||||
### Continue A Conversation
|
||||
|
||||
Use a `session_key` when you want history to carry across turns. Different
|
||||
session keys are isolated from each other:
|
||||
|
||||
```python
|
||||
await bot.run("My name is Alice.", session_key="user:alice")
|
||||
result = await bot.run("What is my name?", session_key="user:alice")
|
||||
|
||||
print(result.content)
|
||||
```
|
||||
|
||||
This is the SDK equivalent of giving each user, task, eval case, or workflow
|
||||
its own conversation thread.
|
||||
|
||||
### Stream A Long Answer
|
||||
|
||||
For live output, use `bot.stream(...)`:
|
||||
|
||||
```python
|
||||
from nanobot import STREAM_EVENT_TEXT_DELTA
|
||||
|
||||
async for event in bot.stream("Write a migration plan"):
|
||||
if event.type == STREAM_EVENT_TEXT_DELTA:
|
||||
print(event.delta, end="", flush=True)
|
||||
```
|
||||
|
||||
Streaming returns structured events, so you can also observe tool calls,
|
||||
reasoning chunks, completion, and failures.
|
||||
|
||||
## Complete Starter Script
|
||||
|
||||
Save this as `sdk_demo.py` after `nanobot agent -m "Hello!"` works:
|
||||
|
||||
```python
|
||||
import asyncio
|
||||
import sys
|
||||
|
||||
from nanobot import (
|
||||
STREAM_EVENT_RUN_COMPLETED,
|
||||
STREAM_EVENT_RUN_FAILED,
|
||||
STREAM_EVENT_TEXT_DELTA,
|
||||
STREAM_EVENT_TOOL_STARTED,
|
||||
Nanobot,
|
||||
)
|
||||
|
||||
|
||||
async def main() -> None:
|
||||
prompt = " ".join(sys.argv[1:]) or "Explain what nanobot is in one paragraph."
|
||||
session_key = "sdk:demo"
|
||||
|
||||
async with Nanobot.from_config() as bot:
|
||||
print(f"model: {bot.runtime.model}")
|
||||
print(f"workspace: {bot.runtime.workspace}")
|
||||
print()
|
||||
|
||||
final_result = None
|
||||
async for event in bot.stream(prompt, session_key=session_key):
|
||||
if event.type == STREAM_EVENT_TEXT_DELTA:
|
||||
print(event.delta, end="", flush=True)
|
||||
elif event.type == STREAM_EVENT_TOOL_STARTED:
|
||||
print(f"\n[tool] {event.name}", flush=True)
|
||||
elif event.type == STREAM_EVENT_RUN_COMPLETED:
|
||||
final_result = event.result
|
||||
elif event.type == STREAM_EVENT_RUN_FAILED:
|
||||
raise RuntimeError(event.error or "nanobot run failed")
|
||||
|
||||
print()
|
||||
if final_result is not None:
|
||||
print(f"\nstop_reason: {final_result.stop_reason}")
|
||||
print(f"tools_used: {final_result.tools_used}")
|
||||
print(f"usage: {final_result.usage}")
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
asyncio.run(main())
|
||||
```
|
||||
|
||||
Run it:
|
||||
|
||||
```bash
|
||||
python sdk_demo.py "List the top-level files in the current workspace."
|
||||
```
|
||||
|
||||
You should see the configured model, workspace path, streamed assistant text,
|
||||
and final run metadata. The exact answer depends on your config and workspace,
|
||||
but a file-listing prompt may look like this:
|
||||
|
||||
```text
|
||||
model: openai/gpt-4.1-mini
|
||||
workspace: /Users/alice/.nanobot/workspace
|
||||
|
||||
[tool] list_dir
|
||||
Here are the top-level files I found...
|
||||
|
||||
stop_reason: completed
|
||||
tools_used: ['list_dir']
|
||||
usage: {'prompt_tokens': ..., 'completion_tokens': ..., 'total_tokens': ...}
|
||||
```
|
||||
|
||||
This script shows the usual production shape: create one `Nanobot`, choose a
|
||||
stable `session_key`, stream events, keep the final `RunResult`, and let
|
||||
`async with` close runtime resources.
|
||||
|
||||
## Core Concepts
|
||||
|
||||
| Concept | Meaning |
|
||||
|---------|---------|
|
||||
| `Nanobot` | The SDK object that owns one configured agent runtime. |
|
||||
| Run | One call to `bot.run(...)`, `bot.run_streamed(...)`, or `bot.stream(...)`. |
|
||||
| `session_key` | The conversation history key. Reuse it to continue a thread; change it to isolate a thread. |
|
||||
| Workspace | The local directory where file tools and shell tools operate. |
|
||||
| Tools | Capabilities the agent may call, such as file access, shell, web, or custom tools from your config. |
|
||||
| Memory | Long-term memory files managed by nanobot. |
|
||||
| Stream event | A typed event such as `text.delta`, `tool.started`, or `run.completed`. |
|
||||
| Model override | A temporary model or model preset used for one SDK instance or one run. |
|
||||
|
||||
For most users, the mental model is:
|
||||
|
||||
1. Create a `Nanobot` from config.
|
||||
2. Pick a `session_key`.
|
||||
3. Call `run` or `stream`.
|
||||
4. Read `RunResult` or stream events.
|
||||
5. Use session/memory/runtime helpers only when you need more control.
|
||||
|
||||
## SDK Or OpenAI-Compatible API?
|
||||
|
||||
nanobot has two programming surfaces:
|
||||
|
||||
| Use | Choose | Why |
|
||||
|-----|--------|-----|
|
||||
| Python code running in the same process as nanobot | Python SDK | Direct access to `RunResult`, sessions, memory, runtime helpers, hooks, and stream events. |
|
||||
| Existing OpenAI-compatible clients, another language, or a separate process | [OpenAI-Compatible API](openai-api.md) | HTTP `/v1/chat/completions` compatibility with familiar client libraries. |
|
||||
|
||||
The Python SDK is best when you are writing evals, notebooks, benchmark
|
||||
runners, product backends, local scripts, or integrations that should control
|
||||
nanobot directly.
|
||||
|
||||
The OpenAI-compatible API is best when you already have an HTTP client, want
|
||||
process isolation, or need to call nanobot from a non-Python service.
|
||||
|
||||
## Common Patterns
|
||||
|
||||
### Use a specific config or workspace
|
||||
|
||||
Set the workspace when your agent should work inside a specific project:
|
||||
|
||||
```python
|
||||
from nanobot import Nanobot
|
||||
|
||||
async with Nanobot.from_config(workspace="/my/project") as bot:
|
||||
result = await bot.run("Explain the project structure")
|
||||
```
|
||||
|
||||
Use a custom config when you run multiple nanobot instances or test an isolated
|
||||
setup:
|
||||
|
||||
```python
|
||||
async with Nanobot.from_config(
|
||||
config_path="./bot-a/config.json",
|
||||
workspace="./bot-a/workspace",
|
||||
) as bot:
|
||||
result = await bot.run("Hello from bot A")
|
||||
```
|
||||
|
||||
The config controls what nanobot may use. The workspace is where nanobot keeps
|
||||
state for that instance. See [multiple-instances.md](multiple-instances.md) for
|
||||
multi-instance CLI and gateway examples.
|
||||
|
||||
### Choose a default or per-run model
|
||||
|
||||
Set the SDK instance default model when you create the bot:
|
||||
|
||||
```python
|
||||
bot = Nanobot.from_config(model="openai/gpt-4.1")
|
||||
```
|
||||
|
||||
Override the model for one run without changing the instance default:
|
||||
|
||||
```python
|
||||
result = await bot.run("Summarize this file", model="openai/gpt-4.1-mini")
|
||||
```
|
||||
|
||||
Model presets from `config.json` work the same way:
|
||||
|
||||
```python
|
||||
bot = Nanobot.from_config(model_preset="fast")
|
||||
|
||||
result = await bot.run("Think deeply about this bug", model_preset="reasoning")
|
||||
```
|
||||
|
||||
`model` and `model_preset` are mutually exclusive.
|
||||
|
||||
For first setup, prefer named presets in `config.json`. Mixing an API key from
|
||||
one provider with a model ID from another is the most common first-run failure.
|
||||
For the exact difference between `provider`, `model`, `apiKey`, and `apiBase`,
|
||||
see [Providers: Provider, Model, API Key, and Base URL](providers.md#provider-model-api-key-and-base-url).
|
||||
If a run fails before the SDK does anything interesting, confirm the same
|
||||
provider and model work with `nanobot agent -m "Hello!"` first.
|
||||
|
||||
### Isolate conversations with `session_key`
|
||||
|
||||
Different session keys keep independent conversation history:
|
||||
|
||||
```python
|
||||
await bot.run("hi", session_key="user-alice")
|
||||
await bot.run("hi", session_key="task-42")
|
||||
```
|
||||
|
||||
Use stable keys in product code:
|
||||
|
||||
```python
|
||||
session_key = f"user:{user_id}"
|
||||
result = await bot.run(user_message, session_key=session_key)
|
||||
```
|
||||
|
||||
Avoid using the default `"sdk:default"` for multiple users or unrelated
|
||||
workflows. It is convenient for local experiments, but stable product code
|
||||
should choose explicit keys such as `user:<id>`, `project:<id>`, or
|
||||
`eval:<case-id>`.
|
||||
|
||||
### Handle failures
|
||||
|
||||
For a normal non-streamed run, catch exceptions around `bot.run(...)` and inspect
|
||||
`RunResult.error` when the runtime returns a structured failure:
|
||||
|
||||
```python
|
||||
try:
|
||||
result = await bot.run("Review this repo", session_key="project:demo")
|
||||
except Exception as exc:
|
||||
print(f"SDK call failed before a result was returned: {exc}")
|
||||
else:
|
||||
if result.error:
|
||||
print(f"Agent run failed: {result.error}")
|
||||
else:
|
||||
print(result.content)
|
||||
```
|
||||
|
||||
For streamed runs, either consume the stream to completion or close it:
|
||||
|
||||
```python
|
||||
run = await bot.run_streamed("Write a long answer", session_key="task:123")
|
||||
try:
|
||||
async for event in run.stream_events():
|
||||
...
|
||||
finally:
|
||||
if not run.done:
|
||||
await run.aclose()
|
||||
```
|
||||
|
||||
Use `await run.cancel()` when the user presses a stop button or leaves the page
|
||||
before the stream finishes.
|
||||
|
||||
### Stream long-running output
|
||||
|
||||
Use `bot.stream()` when you want Cursor/OpenAI-style live events instead of
|
||||
waiting for the final `RunResult`:
|
||||
|
||||
```python
|
||||
from nanobot import (
|
||||
STREAM_EVENT_RUN_COMPLETED,
|
||||
STREAM_EVENT_TEXT_DELTA,
|
||||
STREAM_EVENT_TOOL_STARTED,
|
||||
)
|
||||
|
||||
async for event in bot.stream("Review this repository"):
|
||||
if event.type == STREAM_EVENT_TEXT_DELTA:
|
||||
print(event.delta, end="", flush=True)
|
||||
elif event.type == STREAM_EVENT_TOOL_STARTED:
|
||||
print(f"\nusing {event.name}")
|
||||
elif event.type == STREAM_EVENT_RUN_COMPLETED:
|
||||
print("\nfinal:", event.result.content)
|
||||
```
|
||||
|
||||
Use `run_streamed()` when you also want a handle you can wait on:
|
||||
|
||||
```python
|
||||
from nanobot import STREAM_EVENT_TEXT_DELTA
|
||||
|
||||
run = await bot.run_streamed("Write a detailed migration plan")
|
||||
|
||||
async for event in run.stream_events():
|
||||
if event.type == STREAM_EVENT_TEXT_DELTA:
|
||||
print(event.delta, end="", flush=True)
|
||||
|
||||
result = await run.wait()
|
||||
```
|
||||
|
||||
Always either consume the stream, call `await run.wait()` / `await run.text()`,
|
||||
or close it with `await run.cancel()` / `await run.aclose()`. Exiting
|
||||
`stream_events()` or `bot.stream()` early cancels the underlying run so a
|
||||
half-consumed stream cannot leave a background task stuck behind backpressure.
|
||||
|
||||
### Import an existing transcript
|
||||
|
||||
This is useful for evals, benchmark runners, migrations, and tests.
|
||||
|
||||
Use `bot.sessions.ingest()` when you already have a transcript and want it to
|
||||
become nanobot session history. Ingesting a transcript does not call the model,
|
||||
execute tools, update memory, or compact automatically.
|
||||
|
||||
```python
|
||||
await bot.sessions.ingest(
|
||||
"eval:case-1",
|
||||
[
|
||||
{
|
||||
"role": "user",
|
||||
"content": "I graduated with a degree in Business Administration.",
|
||||
"timestamp": "2023/05/30 (Tue) 17:27",
|
||||
"source_session_id": "answer_280352e9",
|
||||
},
|
||||
{
|
||||
"role": "assistant",
|
||||
"content": "Congratulations on your degree.",
|
||||
"timestamp": "2023/05/30 (Tue) 17:27",
|
||||
},
|
||||
],
|
||||
source="longmemeval",
|
||||
)
|
||||
|
||||
await bot.runtime.compact_session("eval:case-1")
|
||||
|
||||
result = await bot.run(
|
||||
"Current Date: 2023/05/30 (Tue) 23:40\n"
|
||||
"Question: What degree did I graduate with?",
|
||||
session_key="eval:case-1",
|
||||
)
|
||||
print(result.content)
|
||||
```
|
||||
|
||||
### Attach hooks for observability
|
||||
|
||||
Hooks are an advanced escape hatch. Use them when you want custom logging,
|
||||
metrics, tracing, or output post-processing without modifying nanobot internals:
|
||||
|
||||
```python
|
||||
from nanobot.agent import AgentHook, AgentHookContext
|
||||
|
||||
|
||||
class AuditHook(AgentHook):
|
||||
async def before_execute_tools(self, context: AgentHookContext) -> None:
|
||||
for tc in context.tool_calls:
|
||||
print(f"[tool] {tc.name}")
|
||||
|
||||
|
||||
result = await bot.run("Review this change", hooks=[AuditHook()])
|
||||
```
|
||||
|
||||
## Where To Go Next
|
||||
|
||||
The SDK page is the programming entry point. The fuller conceptual and
|
||||
configuration docs remain the source of truth for the runtime around it:
|
||||
|
||||
| Need | Read |
|
||||
|------|------|
|
||||
| First working install and config | [Install and Quick Start](quick-start.md) |
|
||||
| Mental model for config, workspace, sessions, tools, and memory | [Concepts](concepts.md) |
|
||||
| Provider/model/API key/base URL matching | [Providers and Models](providers.md) |
|
||||
| Pasteable provider recipes | [Provider Cookbook](provider-cookbook.md) |
|
||||
| Complete configuration reference | [Configuration](configuration.md) |
|
||||
| Long-term memory design | [Memory](memory.md) |
|
||||
| HTTP API instead of Python SDK | [OpenAI-Compatible API](openai-api.md) |
|
||||
| Debugging install, config, provider, or runtime failures | [Troubleshooting](troubleshooting.md) |
|
||||
|
||||
## API Reference
|
||||
|
||||
### `Nanobot.from_config(config_path=None, *, workspace=None, model=None, model_preset=None)`
|
||||
|
||||
Create a `Nanobot` instance from a config file.
|
||||
|
||||
| Param | Type | Default | Description |
|
||||
|-------|------|---------|-------------|
|
||||
| `config_path` | `str \| Path \| None` | `None` | Path to `config.json`. Defaults to `~/.nanobot/config.json`. |
|
||||
| `workspace` | `str \| Path \| None` | `None` | Override the workspace directory from config. |
|
||||
| `model` | `str \| None` | `None` | Override the instance default model. |
|
||||
| `model_preset` | `str \| None` | `None` | Override the instance default model preset from `config.json`. |
|
||||
|
||||
Raises `FileNotFoundError` if an explicit config path does not exist.
|
||||
Raises `ValueError` if both `model` and `model_preset` are provided.
|
||||
|
||||
### `await bot.run(...)`
|
||||
|
||||
Run the agent once and return a `RunResult`.
|
||||
|
||||
| Param | Type | Default | Description |
|
||||
|-------|------|---------|-------------|
|
||||
| `message` | `str` | *(required)* | The user message to process. |
|
||||
| `session_key` | `str` | `"sdk:default"` | Session identifier for conversation isolation. Different keys get independent history. |
|
||||
| `channel` | `str` | `"cli"` | Logical channel label used in runtime context. |
|
||||
| `chat_id` | `str` | `"direct"` | Logical chat identifier used in runtime context. |
|
||||
| `sender_id` | `str` | `"user"` | Logical sender identifier used in runtime context. |
|
||||
| `media` | `list[str] \| None` | `None` | Optional local media paths attached to the message. |
|
||||
| `ephemeral` | `bool` | `False` | Run without persisting the turn or compacting session history. |
|
||||
| `hooks` | `list[AgentHook] \| None` | `None` | Lifecycle hooks for this run only. |
|
||||
| `model` | `str \| None` | `None` | Override the model for this run only. |
|
||||
| `model_preset` | `str \| None` | `None` | Override the model preset for this run only. |
|
||||
|
||||
`model` and `model_preset` are per-run overrides and do not change
|
||||
`bot.runtime.model` after the run completes. They are mutually exclusive.
|
||||
|
||||
### `await bot.run_streamed(...)`
|
||||
|
||||
Start a streamed agent turn and return a `RunStream`. It accepts the same
|
||||
parameters as `bot.run(...)`.
|
||||
|
||||
```python
|
||||
run = await bot.run_streamed("Generate a long answer")
|
||||
|
||||
async for event in run.stream_events():
|
||||
...
|
||||
|
||||
result = await run.wait()
|
||||
```
|
||||
|
||||
### `bot.stream(...)`
|
||||
|
||||
Convenience wrapper around `run_streamed()` for direct event iteration. It
|
||||
accepts the same parameters as `bot.run(...)`.
|
||||
|
||||
```python
|
||||
async for event in bot.stream("Generate a long answer"):
|
||||
...
|
||||
```
|
||||
|
||||
### `RunStream`
|
||||
|
||||
| Method | Description |
|
||||
|--------|-------------|
|
||||
| `stream_events()` | Single-consumer async iterator of `StreamEvent` objects. |
|
||||
| `await wait()` | Wait for the run to finish and return `RunResult`. |
|
||||
| `await text()` | Wait for the run to finish and return `RunResult.content`. |
|
||||
| `await cancel()` | Cancel the run and release stream resources. |
|
||||
| `await aclose()` | Close the stream; equivalent cleanup primitive for `async with` / manual lifecycle code. |
|
||||
|
||||
Normal SDK runs with different session keys may overlap. Runs that use per-run
|
||||
`model` or `model_preset` overrides are exclusive while the override is active,
|
||||
because the current `AgentLoop` provider/model state is mutable.
|
||||
|
||||
### `StreamEvent`
|
||||
|
||||
| Field | Type | Description |
|
||||
|-------|------|-------------|
|
||||
| `type` | `StreamEventType` | Event type, such as `text.delta` or `run.completed`. |
|
||||
| `delta` | `str` | Incremental text or reasoning chunk. |
|
||||
| `content` | `str` | Completed text segment or final content. |
|
||||
| `result` | `RunResult \| None` | Present on `run.completed`. |
|
||||
| `name` | `str \| None` | Tool name for tool events. |
|
||||
| `tool_call_id` | `str \| None` | Provider tool call id when available. |
|
||||
| `arguments` | `dict \| None` | Tool arguments when available. |
|
||||
| `iteration` | `int \| None` | Agent loop iteration when available. |
|
||||
| `resuming` | `bool \| None` | Whether a text segment ended before more tool work. |
|
||||
| `usage` | `dict[str, int]` | Token usage on completion events. |
|
||||
| `error` | `str \| None` | Error text on failed events. |
|
||||
| `metadata` | `dict` | Additional event metadata. |
|
||||
|
||||
Use the exported constants instead of hard-coded strings when possible:
|
||||
|
||||
| Constant | Value |
|
||||
|----------|-------|
|
||||
| `STREAM_EVENT_RUN_STARTED` | `run.started` |
|
||||
| `STREAM_EVENT_TEXT_DELTA` | `text.delta` |
|
||||
| `STREAM_EVENT_TEXT_COMPLETED` | `text.completed` |
|
||||
| `STREAM_EVENT_REASONING_DELTA` | `reasoning.delta` |
|
||||
| `STREAM_EVENT_REASONING_COMPLETED` | `reasoning.completed` |
|
||||
| `STREAM_EVENT_TOOL_STARTED` | `tool.started` |
|
||||
| `STREAM_EVENT_TOOL_COMPLETED` | `tool.completed` |
|
||||
| `STREAM_EVENT_TOOL_FAILED` | `tool.failed` |
|
||||
| `STREAM_EVENT_RUN_COMPLETED` | `run.completed` |
|
||||
| `STREAM_EVENT_RUN_FAILED` | `run.failed` |
|
||||
|
||||
`STREAM_EVENT_TYPES` contains all stable v1 event values.
|
||||
|
||||
### `await bot.aclose()`
|
||||
|
||||
Release resources held by the SDK instance, including tool connections. The async context manager calls this automatically:
|
||||
|
||||
```python
|
||||
async with Nanobot.from_config() as bot:
|
||||
result = await bot.run("Summarize this repo")
|
||||
```
|
||||
|
||||
### `RunResult`
|
||||
|
||||
| Field | Type | Description |
|
||||
|-------|------|-------------|
|
||||
| `content` | `str` | The agent's final text response. |
|
||||
| `tools_used` | `list[str]` | Tool names used during the run. |
|
||||
| `messages` | `list[dict]` | Final message list from the run. |
|
||||
| `usage` | `dict[str, int]` | Token usage reported or estimated by the runtime. |
|
||||
| `stop_reason` | `str \| None` | Why the run stopped, such as `"completed"` or `"max_iterations"`. |
|
||||
| `error` | `str \| None` | Error text when the run failed inside the agent runtime. |
|
||||
| `metadata` | `dict` | Outbound metadata such as latency. |
|
||||
|
||||
## Session, Memory, And Runtime Helpers
|
||||
|
||||
### `bot.sessions`
|
||||
|
||||
| Method | Description |
|
||||
|--------|-------------|
|
||||
| `await ingest(session_key, messages, metadata=None, source=None, save=True)` | Import existing transcript messages without running the model. |
|
||||
| `get(session_key)` | Return a `SessionSnapshot`, or `None` if missing. |
|
||||
| `list()` | Return compact `SessionInfo` rows. |
|
||||
| `export(session_key)` | Return a trusted full `SessionSnapshot`, including model-only runtime context, suitable for JSON serialization. |
|
||||
| `await restore(snapshot, session_key=None, save=True)` | Restore a trusted exported snapshot into an empty session; the returned snapshot is display-safe. |
|
||||
| `clear(session_key)` | Clear and persist one session. |
|
||||
| `delete(session_key)` | Delete one session from disk and cache. |
|
||||
| `flush()` | Flush cached sessions to durable storage. |
|
||||
|
||||
Ingested messages must include `role` and `content`. Roles may be `user`,
|
||||
`assistant`, `tool`, or `system`. Other fields, such as `timestamp`,
|
||||
`source_session_id`, or `source_date`, are persisted as message metadata.
|
||||
|
||||
`get()` and snapshots returned by ordinary SDK operations are display-safe and omit
|
||||
model-only runtime context. `export()` is an explicit backup boundary and includes
|
||||
that internal context so `restore()` can preserve the exact model-visible history.
|
||||
Do not expose exported snapshots directly to chat users.
|
||||
|
||||
### `bot.memory`
|
||||
|
||||
| Method | Description |
|
||||
|--------|-------------|
|
||||
| `read()` | Read `memory/MEMORY.md`. |
|
||||
| `write(text)` | Overwrite `memory/MEMORY.md`. |
|
||||
| `append_history(text, session_key=None)` | Append one `memory/history.jsonl` entry and return its cursor. |
|
||||
| `read_history(session_key=None)` | Read memory history entries, optionally filtered by session key. |
|
||||
|
||||
### `bot.runtime`
|
||||
|
||||
| Method / Property | Description |
|
||||
|-------------------|-------------|
|
||||
| `model` | Current runtime model name. |
|
||||
| `workspace` | Current runtime workspace path. |
|
||||
| `await compact_session(session_key)` | Run token/replay-window consolidation for a session. |
|
||||
| `await compact_idle_session(session_key, max_suffix=8)` | Run idle-session compaction and return its summary. |
|
||||
|
||||
## Hooks
|
||||
|
||||
Hooks let you observe or customize the agent loop. Subclass `AgentHook` and override the methods you need.
|
||||
|
||||
### Hook lifecycle
|
||||
|
||||
| Method | When |
|
||||
|--------|------|
|
||||
| `wants_streaming()` | Return `True` if you want token-by-token `on_stream()` callbacks |
|
||||
| `before_iteration(context)` | Before each LLM call |
|
||||
| `on_stream(context, delta)` | On each streamed token when streaming is enabled |
|
||||
| `on_stream_end(context, *, resuming)` | When streaming finishes |
|
||||
| `before_execute_tools(context)` | Before tool execution |
|
||||
| `after_iteration(context)` | After each iteration |
|
||||
| `finalize_content(context, content)` | Transform final output text |
|
||||
|
||||
Useful fields on `AgentHookContext` include:
|
||||
|
||||
- `iteration`
|
||||
- `messages`
|
||||
- `response`
|
||||
- `usage`
|
||||
- `tool_calls`
|
||||
- `tool_results`
|
||||
- `tool_events`
|
||||
- `final_content`
|
||||
- `stop_reason`
|
||||
- `error`
|
||||
|
||||
### Example: audit tool calls
|
||||
|
||||
```python
|
||||
from nanobot.agent import AgentHook, AgentHookContext
|
||||
|
||||
|
||||
class AuditHook(AgentHook):
|
||||
def __init__(self) -> None:
|
||||
super().__init__()
|
||||
self.calls: list[str] = []
|
||||
|
||||
async def before_execute_tools(self, context: AgentHookContext) -> None:
|
||||
for tc in context.tool_calls:
|
||||
self.calls.append(tc.name)
|
||||
print(f"[audit] {tc.name}({tc.arguments})")
|
||||
```
|
||||
|
||||
```python
|
||||
hook = AuditHook()
|
||||
result = await bot.run("List files in /tmp", hooks=[hook])
|
||||
print(result.content)
|
||||
print(f"Tools observed: {hook.calls}")
|
||||
```
|
||||
|
||||
### Example: receive streaming tokens
|
||||
|
||||
```python
|
||||
from nanobot.agent import AgentHook, AgentHookContext
|
||||
|
||||
|
||||
class StreamingHook(AgentHook):
|
||||
def wants_streaming(self) -> bool:
|
||||
return True
|
||||
|
||||
async def on_stream(self, context: AgentHookContext, delta: str) -> None:
|
||||
print(delta, end="", flush=True)
|
||||
|
||||
async def on_stream_end(self, context: AgentHookContext, *, resuming: bool) -> None:
|
||||
print()
|
||||
```
|
||||
|
||||
### Compose multiple hooks
|
||||
|
||||
Pass multiple hooks when you want to combine behaviors:
|
||||
|
||||
```python
|
||||
result = await bot.run("hi", hooks=[AuditHook(), MetricsHook()])
|
||||
```
|
||||
|
||||
Async hook methods are fan-out with error isolation. `finalize_content` is a pipeline: each hook receives the previous hook's output.
|
||||
|
||||
### Example: post-process final content
|
||||
|
||||
```python
|
||||
from nanobot.agent import AgentHook
|
||||
|
||||
|
||||
class Censor(AgentHook):
|
||||
def finalize_content(self, context, content):
|
||||
return content.replace("secret", "***") if content else content
|
||||
```
|
||||
|
||||
## Full Example
|
||||
|
||||
```python
|
||||
import asyncio
|
||||
import time
|
||||
|
||||
from nanobot import Nanobot
|
||||
from nanobot.agent import AgentHook, AgentHookContext
|
||||
|
||||
|
||||
class TimingHook(AgentHook):
|
||||
def __init__(self) -> None:
|
||||
super().__init__()
|
||||
self._started_at = 0.0
|
||||
|
||||
async def before_iteration(self, context: AgentHookContext) -> None:
|
||||
self._started_at = time.perf_counter()
|
||||
|
||||
async def after_iteration(self, context: AgentHookContext) -> None:
|
||||
elapsed_ms = (time.perf_counter() - self._started_at) * 1000
|
||||
print(f"[timing] iteration {context.iteration} took {elapsed_ms:.1f}ms")
|
||||
|
||||
|
||||
async def main() -> None:
|
||||
async with Nanobot.from_config(workspace="/my/project") as bot:
|
||||
result = await bot.run(
|
||||
"Explain the main function",
|
||||
session_key="sdk:demo",
|
||||
hooks=[TimingHook()],
|
||||
)
|
||||
print(result.content)
|
||||
|
||||
|
||||
asyncio.run(main())
|
||||
```
|
||||
@@ -0,0 +1,349 @@
|
||||
# Install and Quick Start
|
||||
|
||||
This page gets one local nanobot reply working. After that, you can add the WebUI, chat apps, local models, web search, MCP, deployment, or custom plugins.
|
||||
|
||||
If you have never used a terminal or edited a config file before, use [`start-without-technical-background.md`](./start-without-technical-background.md) first. This page assumes you are comfortable pasting commands and editing JSON snippets.
|
||||
|
||||
## Before You Start
|
||||
|
||||
You need:
|
||||
|
||||
- Python 3.11 or newer.
|
||||
- One LLM provider, company endpoint, subscription endpoint, or local model server you can call. The examples below use a generic OpenAI-compatible `custom` provider so the compact path does not recommend one hosted service; any supported provider works when the key, provider name, and model ID match.
|
||||
- Git only if you install from source.
|
||||
- Node.js or Bun only if you are developing the WebUI itself.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Repository docs may describe features that are available first in source. Install from PyPI or `uv` for the stable day-to-day release; install from source when you want the newest repository behavior or plan to contribute.
|
||||
|
||||
## 1. Install
|
||||
|
||||
Pick one install method.
|
||||
|
||||
**One-command setup:**
|
||||
|
||||
```bash
|
||||
curl -fsSL https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.sh | sh
|
||||
```
|
||||
|
||||
On Windows PowerShell:
|
||||
|
||||
```powershell
|
||||
irm https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.ps1 | iex
|
||||
```
|
||||
|
||||
The default command installs or upgrades `nanobot-ai` from PyPI, then starts `nanobot onboard --wizard`. It avoids system-wide pip installs by using an active virtual environment, `uv`, `pipx`, or a managed venv under `~/.nanobot/venv`. If Quick Start finishes, go straight to [Open the WebUI](#5-open-the-webui).
|
||||
|
||||
To preview the plan without changing your environment, pass `--dry-run`; combine it with `--dev` when you want to preview the main-branch install.
|
||||
|
||||
```bash
|
||||
curl -fsSL https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.sh | sh -s -- --dry-run
|
||||
```
|
||||
|
||||
```powershell
|
||||
& ([scriptblock]::Create((irm https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.ps1))) --dry-run
|
||||
```
|
||||
|
||||
To install the current `main` branch instead, pass `--dev`:
|
||||
|
||||
```bash
|
||||
curl -fsSL https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.sh | sh -s -- --dev
|
||||
```
|
||||
|
||||
```powershell
|
||||
& ([scriptblock]::Create((irm https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.ps1))) --dev
|
||||
```
|
||||
|
||||
If `curl` or `irm` is unavailable, or GitHub raw downloads are blocked on your network, use one of the manual install methods below.
|
||||
|
||||
If you prefer to inspect the script first, open [`../scripts/install.sh`](../scripts/install.sh) or [`../scripts/install.ps1`](../scripts/install.ps1).
|
||||
|
||||
**Stable release with `uv`:**
|
||||
|
||||
```bash
|
||||
uv tool install nanobot-ai
|
||||
nanobot --version
|
||||
```
|
||||
|
||||
**Stable release with pip:**
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
nanobot --version
|
||||
```
|
||||
|
||||
Use pip only inside an environment you control. If pip reports `externally-managed-environment` on macOS or Linux, use the one-command installer, `uv tool install nanobot-ai`, `pipx install nanobot-ai`, or create a virtual environment first.
|
||||
|
||||
**Latest source checkout:**
|
||||
|
||||
```bash
|
||||
git clone https://github.com/HKUDS/nanobot.git
|
||||
cd nanobot
|
||||
python -m pip install -e .
|
||||
nanobot --version
|
||||
```
|
||||
|
||||
If your shell cannot find `nanobot` after a pip install, run the module form:
|
||||
|
||||
```bash
|
||||
python -m nanobot --version
|
||||
python -m nanobot onboard
|
||||
```
|
||||
|
||||
On Windows, `~` in the docs means your user profile directory, for example `C:\Users\you`.
|
||||
|
||||
The docs use `python` in commands. If your system exposes Python 3.11+ as `python3` or `py`, use that command in the same place, for example `python3 -m pip install nanobot-ai` or `py -m nanobot --version`.
|
||||
|
||||
## 2. Initialize
|
||||
|
||||
Skip this section if the one-command setup already started the wizard and Quick Start finished there.
|
||||
|
||||
```bash
|
||||
nanobot onboard
|
||||
```
|
||||
|
||||
Use the wizard if you prefer prompts instead of editing JSON by hand:
|
||||
|
||||
```bash
|
||||
nanobot onboard --wizard
|
||||
```
|
||||
|
||||
Initialization creates:
|
||||
|
||||
| Path | What it is |
|
||||
|------|------------|
|
||||
| `~/.nanobot/config.json` | Main settings file for providers, models, channels, tools, gateway, and API |
|
||||
| `~/.nanobot/workspace/` | Agent workspace for memory, sessions, heartbeat tasks, skills, and artifacts |
|
||||
|
||||
If you already have a config, `nanobot onboard` can refresh missing default fields without overwriting your existing values. Use `nanobot onboard --refresh` to do the same refresh without an interactive prompt.
|
||||
|
||||
## 3. Configure a Provider
|
||||
|
||||
Skip this section if you already configured provider and model settings in the wizard.
|
||||
|
||||
Open `~/.nanobot/config.json`. Add or merge these blocks into the file created by `nanobot onboard`; do not replace the whole file unless you want to reset the config.
|
||||
|
||||
**API key:**
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"custom": {
|
||||
"apiKey": "your-api-key",
|
||||
"apiBase": "https://api.example.com/v1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Model preset:**
|
||||
|
||||
```json
|
||||
{
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"label": "Primary",
|
||||
"provider": "custom",
|
||||
"model": "model-id-from-your-provider",
|
||||
"maxTokens": 8192,
|
||||
"contextWindowTokens": 65536,
|
||||
"temperature": 0.1
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The provider and model inside a preset must match. The snippet above is only an example. For another provider, replace these values together:
|
||||
|
||||
| Replace | Where |
|
||||
|---|---|
|
||||
| Provider config key, such as `custom` | `providers.<provider>` |
|
||||
| API key or environment variable | `providers.<provider>.apiKey` |
|
||||
| Preset provider name | `modelPresets.primary.provider` |
|
||||
| Model ID | `modelPresets.primary.model` |
|
||||
| Endpoint URL, only when needed | `providers.<provider>.apiBase` |
|
||||
|
||||
Direct `agents.defaults.provider` and `agents.defaults.model` still work for existing configs, but named presets are the recommended path because they also power `/model` switching and fallback chains. For provider-specific examples across direct, gateway, OAuth, cloud, and local setups, see [`providers.md`](./providers.md).
|
||||
|
||||
**What about `apiBase` / base URL?**
|
||||
|
||||
`apiBase` is the HTTP base URL of the provider endpoint, not the model name. Most hosted providers in nanobot already know their default endpoint, so you usually only set `apiKey` and a model preset. Set `apiBase` when you are using:
|
||||
|
||||
- `custom` for a third-party or self-hosted OpenAI-compatible API;
|
||||
- a local OpenAI-compatible server such as Ollama, vLLM, or LM Studio;
|
||||
- a provider-specific alternate endpoint, regional endpoint, proxy, or subscription endpoint.
|
||||
|
||||
Examples:
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"custom": {
|
||||
"apiKey": "${CUSTOM_API_KEY}",
|
||||
"apiBase": "https://api.example.com/v1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"ollama": {
|
||||
"apiBase": "http://localhost:11434/v1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
If the provider's docs say the endpoint is `/v1`, include `/v1` in `apiBase`. The model ID still belongs in the active `modelPresets` entry.
|
||||
|
||||
If you prefer not to store secrets in `config.json`, reference an environment variable and set it before starting nanobot:
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"custom": {
|
||||
"apiKey": "${PROVIDER_API_KEY}",
|
||||
"apiBase": "https://api.example.com/v1"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 4. Check the Setup
|
||||
|
||||
```bash
|
||||
nanobot status
|
||||
```
|
||||
|
||||
This should show the config path, workspace path, active model or preset, and provider summary. It does not send a message to the model, so use it as a quick config check before the first real request.
|
||||
|
||||
Read it like this:
|
||||
|
||||
| Status line | What you want |
|
||||
|---|---|
|
||||
| `Config` | A check mark. |
|
||||
| `Workspace` | A check mark. |
|
||||
| `Model` | The model or preset you expect. |
|
||||
| Provider list | Most providers can say `not set`; the provider used by the active preset should show a check mark, OAuth status, or local URL. |
|
||||
|
||||
## 5. Open the WebUI
|
||||
|
||||
Start the browser workbench:
|
||||
|
||||
```bash
|
||||
nanobot webui
|
||||
```
|
||||
|
||||
`nanobot webui` prepares the local WebSocket channel and WebUI bootstrap secret if needed, starts the gateway, and opens `http://127.0.0.1:8765`. First-run WebUI setup binds to `127.0.0.1` by default, so it is not exposed to your LAN. Use `nanobot webui --background` when you want the gateway to keep running without an open terminal.
|
||||
|
||||
## 6. Test One CLI Message
|
||||
|
||||
Use this path if you skipped Quick Start, declined the WebSocket channel, or want a terminal-only check.
|
||||
|
||||
Run a one-shot CLI message:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
A successful first run proves that:
|
||||
|
||||
- the `nanobot` command is installed;
|
||||
- `~/.nanobot/config.json` can be loaded;
|
||||
- the selected provider and model can answer;
|
||||
- the default workspace can be created and used.
|
||||
|
||||
The reply text itself will vary. Any normal assistant answer means the install, config, provider, model, and workspace path are all usable.
|
||||
|
||||
If that works, start an interactive CLI chat:
|
||||
|
||||
```bash
|
||||
nanobot agent
|
||||
```
|
||||
|
||||
After the interactive session can answer normally, nanobot can help with its own next setup step. Ask it to read the relevant docs, inspect your current `~/.nanobot/config.json`, and make one concrete change such as enabling WebUI, adding a provider preset, or configuring one chat channel. When nanobot says the config is updated, run `/restart` in the chat or restart the nanobot process manually so long-running processes reload `config.json`.
|
||||
|
||||
Example prompt:
|
||||
|
||||
```text
|
||||
Read docs/quick-start.md, docs/providers.md, and docs/configuration.md in this checkout.
|
||||
Then update ~/.nanobot/config.json to add a model preset named "primary" for my provider.
|
||||
Tell me exactly what changed and whether I need to run /restart.
|
||||
```
|
||||
|
||||
In interactive mode, `Enter` sends the current message. Press `Alt+Enter` to add a newline before sending.
|
||||
|
||||
Exit interactive mode with `exit`, `quit`, `/exit`, `/quit`, `:q`, or `Ctrl+D`.
|
||||
|
||||
## 7. Choose Your Next Step
|
||||
|
||||
| Want to... | Go to |
|
||||
|---|---|
|
||||
| Understand config, workspace, gateway, channels, memory, and tools | [`concepts.md`](./concepts.md) |
|
||||
| Copy another provider or local model setup | [`provider-cookbook.md`](./provider-cookbook.md) |
|
||||
| Understand provider/model matching | [`providers.md`](./providers.md) |
|
||||
| Open the bundled browser UI | [`webui.md`](./webui.md) |
|
||||
| Connect Telegram, Discord, WeChat, Slack, Email, Mattermost, or another chat app | [`chat-apps.md`](./chat-apps.md) |
|
||||
| Configure web search, MCP, security, memory, gateway, or runtime settings | [`configuration.md`](./configuration.md) |
|
||||
| Run with Docker, systemd, or LaunchAgent | [`deployment.md`](./deployment.md) |
|
||||
| Debug a failure | [`troubleshooting.md`](./troubleshooting.md) |
|
||||
|
||||
## Updating
|
||||
|
||||
**pip:**
|
||||
|
||||
```bash
|
||||
python -m pip install -U nanobot-ai
|
||||
nanobot --version
|
||||
```
|
||||
|
||||
If pip reports `externally-managed-environment`, upgrade with the same isolated method you used to install nanobot, such as `uv tool upgrade nanobot-ai`, `pipx upgrade nanobot-ai`, or the managed venv created by the one-command installer.
|
||||
|
||||
**uv:**
|
||||
|
||||
```bash
|
||||
uv tool upgrade nanobot-ai
|
||||
nanobot --version
|
||||
```
|
||||
|
||||
**pipx:**
|
||||
|
||||
```bash
|
||||
pipx upgrade nanobot-ai
|
||||
nanobot --version
|
||||
```
|
||||
|
||||
**Source checkout:**
|
||||
|
||||
```bash
|
||||
git pull
|
||||
python -m pip install -e .
|
||||
nanobot --version
|
||||
```
|
||||
|
||||
If you use WhatsApp from a source checkout, keep the optional dependencies installed:
|
||||
|
||||
```bash
|
||||
nanobot plugins enable whatsapp
|
||||
```
|
||||
|
||||
## First-Run Troubleshooting
|
||||
|
||||
| Symptom | What to check |
|
||||
|---------|---------------|
|
||||
| `nanobot: command not found` | Use `python -m nanobot ...`, or add your Python scripts directory to `PATH`. |
|
||||
| `ModuleNotFoundError: nanobot` | Confirm you installed into the same Python environment that is running the command. |
|
||||
| JSON parse errors | Check commas and braces in `~/.nanobot/config.json`; examples above are partial snippets to merge. |
|
||||
| Authentication or 401 errors | Check that the API key is valid, copied without spaces, and placed under the provider you selected. |
|
||||
| Provider/model errors | Make sure the active preset uses the provider that owns your API key and that the model exists there. |
|
||||
| The CLI works but a chat app does not reply | First keep `nanobot gateway` running, then follow [`chat-apps.md`](./chat-apps.md). |
|
||||
| WebUI does not open | Run `nanobot webui`; the browser UI uses port `8765`, not the gateway health port `18790`. |
|
||||
|
||||
For a fuller diagnosis flow, see [`troubleshooting.md`](./troubleshooting.md).
|
||||
@@ -0,0 +1,147 @@
|
||||
# Release Archive
|
||||
|
||||
This page keeps release and daily update history outside the README so the project homepage can stay focused on what nanobot is, what it can do, and how to start.
|
||||
|
||||
For tagged releases, see [GitHub Releases](https://github.com/HKUDS/nanobot/releases).
|
||||
|
||||
## Highlights
|
||||
|
||||
- **2026-06-22** 🚀 Released **v0.2.2** — **The Durability Release** makes nanobot sturdier for daily agent work: segmented WebUI transcripts, first-class Python SDK runtime controls, automation management, richer search/STT providers, and stronger gateway/session/provider reliability. Please see [release notes](https://github.com/HKUDS/nanobot/releases/tag/v0.2.2) for details.
|
||||
- **2026-06-21** 🧰 Python SDK runtime controls, optional Keenable key, cleaner run hooks.
|
||||
- **2026-06-20** 💬 Telegram rich messages, safer SDK concurrency, smoother Quick Start.
|
||||
- **2026-06-19** 🔎 Firecrawl app, OpenAI image edits, safer session deletion.
|
||||
- **2026-06-18** 💬 Feishu recovery, Keenable search, Mistral polish, workspace-aware git.
|
||||
- **2026-06-17** 🧠 Default idle auto-compact, clearer `/dream`, macOS installer fixes.
|
||||
- **2026-06-16** 🎯 Fresher goal context, Kimi K2.7 thinking, cleaner API retries.
|
||||
- **2026-06-15** 📱 Mobile WebUI polish, optional file tools, real API usage.
|
||||
- **2026-06-14** 🖼️ Themed cover, partner links, stronger Codex image streaming.
|
||||
- **2026-06-13** 🗓️ Session-bound automations, sturdier WhatsApp, faster WebUI startup.
|
||||
|
||||
- **2026-06-12** 💬 Slack allowlisted channels can require mentions.
|
||||
- **2026-06-11** ✂️ Fenced-code message splitting.
|
||||
- **2026-06-10** 📜 Segmented transcripts, Exa/Bocha search, StepFun/SiliconFlow ASR.
|
||||
- **2026-06-09** 🎙️ Shared voice input, more STT providers, TeX and email polish.
|
||||
- **2026-06-08** 🧮 Token heatmap fix, safer MCP HTTP probing, docs cleanup.
|
||||
- **2026-06-06** 🧰 SDK MCP cleanup, removable OpenAI image defaults.
|
||||
- **2026-06-05** 🖼️ Azure AAD, custom image providers, `/skill`, steadier pairing.
|
||||
- **2026-06-04** 🔌 MCP reconnects, `uv pip` install fallback, QQ pairing.
|
||||
- **2026-06-03** 🧠 Hidden-history recovery, quieter email progress handling.
|
||||
- **2026-06-02** 📬 Email attachments, Napcat QQ, Volcengine search, simpler Dream.
|
||||
- **2026-06-01** 🚀 Released **v0.2.1** — **The Workbench Release** turns the packaged WebUI into a daily agent workbench: clearer Thought/response timelines, live file-edit activity, project workspaces, model and context controls, steadier sustained goals, CLI Apps + MCP extensions, and broader provider/channel support. Please see [release notes](https://github.com/HKUDS/nanobot/releases/tag/v0.2.1) for details.
|
||||
- **2026-05-30** 🔐 Safer Matrix verification, bounded media downloads, clearer WebUI model timeline.
|
||||
- **2026-05-29** 🧩 Extension registry, context-window tuning, document extraction controls.
|
||||
- **2026-05-28** 🗂️ Project workspaces, access controls, steadier goals and streaming.
|
||||
- **2026-05-27** ⏱️ Codex streams respect idle timeouts during long runs.
|
||||
- **2026-05-26** 📡 Telegram webhooks, refreshed Kagi search, cleaner transport errors.
|
||||
- **2026-05-25** 🔌 Unified CLI Apps and MCP, Step Plan support, steadier sustained goals.
|
||||
- **2026-05-24** 🧰 MCP presets, richer slash actions, configurable OpenAI-compatible requests.
|
||||
- **2026-05-23** 🖼️ Zhipu image generation, longer exec windows, cleaner transcription config.
|
||||
- **2026-05-22** 🛠️ CLI Apps, more image providers, safer web redirects and edits.
|
||||
- **2026-05-21** ⚡ Novita provider, faster sidebar, smoother coding tools and Weixin replies.
|
||||
- **2026-05-20** 📶 Signal channel, faster gateway startup, multilingual README links.
|
||||
- **2026-05-19** 🎨 Image provider registry, StepFun and Skywork, stronger WebUI controls.
|
||||
- **2026-05-18** 🖌️ Gemini and MiniMax images, Ant Ling, live file-edit activity.
|
||||
- **2026-05-17** 🌊 Smoother WebUI streaming, AutoCompact fixes, buffered CLI reasoning.
|
||||
- **2026-05-16** 🧠 Atomic Chat provider, goal-aware timeouts, safer exec URL handling.
|
||||
- **2026-05-15** 🚀 Released **v0.2.0** — **`/goal`** holds sustained objectives across turns, WebUI now ships inside the wheel, image generation end to end, 5 new providers with `fallback_models`, and a real agent-loop refactor. Please see [release notes](https://github.com/HKUDS/nanobot/releases/tag/v0.2.0) for details.
|
||||
- **2026-05-14** 🎯 **`/goal`** for long-term objectives, visible multi-step progress, long-horizon missions in chat.
|
||||
- **2026-05-13** 🧠 Streaming reasoning before answers, automatic backup models, smoother plug-in reconnects.
|
||||
- **2026-05-12** 🎛️ Saved model presets with WebUI badge, simpler plug-in tools, quieter Feishu topic threads.
|
||||
- **2026-05-11** 🖥️ NVIDIA NIM support, terminal bot name and icon, streamed reasoning and MiMo toggle clarity.
|
||||
- **2026-05-09** 🖼️ Sharper image replay, BYO web-search keys in Settings, Feishu threads routed cleanly.
|
||||
- **2026-05-08** ✨ Inline chat image, redesigned Settings and keys, Dream memory aligned with visible history.
|
||||
- **2026-05-07** 📜 Locale-aware slash palette in WebUI, LAN login, faithful HTTP streaming responses.
|
||||
- **2026-05-06** 🧩 Tunable tool hint, steadier voice and plug-in startups, schedules and reminders that stick.
|
||||
- **2026-05-05** 🛡️ Quiet deny for unknown Telegram chats, Dream cleanup, fuller automation summaries.
|
||||
- **2026-05-04** 🔐 Safer DingTalk outbound media links, durable cron persistence, DeepSeek polish.
|
||||
- **2026-05-03** ⚙️ Predictable shell allow-list behavior, isolated chats mid-reply, cleaner interactive retries.
|
||||
- **2026-05-02** 🐈 LongCat support, smarter token sizing hints, clearer bundled upgrade guidance.
|
||||
- **2026-05-01** ☁️ Native AWS Bedrock provider, tighter helper handoffs and scoped session files.
|
||||
- **2026-04-30** 💬 Feishu threads that honor replies and topics, WhatsApp bridge refresh on source edits.
|
||||
- **2026-04-29** 🚀 Released **v0.1.5.post3** — Smarter threads on Feishu, Discord, Slack, and Teams; **DeepSeek-V4**; Hugging Face & Olostep; choices, `/history`, and steadier long chats. Please see [release notes](https://github.com/HKUDS/nanobot/releases/tag/v0.1.5.post3) for details.
|
||||
- **2026-04-28** 🌐 Olostep web search, Hugging Face provider, safer workspace-tool interruptions.
|
||||
- **2026-04-27** 💬 `/history` command, smarter session replay caps, smoother Discord / Slack threads.
|
||||
- **2026-04-26** 🧭 Natural cron reminders, thread-aware restarts, safer local provider and shell behavior.
|
||||
- **2026-04-25** 🧩 `ask_user` choices, macOS LaunchAgent deployment, MSTeams stale-reference cleanup.
|
||||
- **2026-04-24** 🎥 Video attachments for channels, DeepSeek thinking control, faster document startup.
|
||||
- **2026-04-23** 🧵 Discord thread sessions, Telegram inline buttons, structured tool progress updates.
|
||||
- **2026-04-22** 🔎 GitHub Copilot GPT-5 / o-series support, configurable web fetch, WebUI image uploads.
|
||||
- **2026-04-21** 🚀 Released **v0.1.5.post2** — Windows & Python 3.14 support, Office document reading, SSE streaming for the OpenAI-compatible API, and stronger reliability across sessions, memory, and channels. Please see [release notes](https://github.com/HKUDS/nanobot/releases/tag/v0.1.5.post2) for details.
|
||||
- **2026-04-20** 🎨 Kimi K2.6 support, Telegram long-message split, WebUI typography & dark-mode polish.
|
||||
- **2026-04-19** 🌐 WebUI i18n locale switcher, atomic session writes with auto-repair.
|
||||
- **2026-04-18** 🧪 Initial WebUI chat, smarter setup wizard menus, WebSocket multi-chat multiplexing.
|
||||
- **2026-04-17** 🪟 Windows & Python 3.14 CI, Dream line-age memory, email self-loop guard.
|
||||
- **2026-04-16** 📡 SSE streaming for OpenAI-compatible API, Discord channel allow-list.
|
||||
- **2026-04-15** 🎛️ LM Studio & nullable API keys, MiniMax thinking endpoint, runtime SelfTool.
|
||||
- **2026-04-14** 🚀 Released **v0.1.5.post1** — Dream skill discovery, mid-turn follow-up injection, WebSocket channel, and deeper channel integrations. Please see [release notes](https://github.com/HKUDS/nanobot/releases/tag/v0.1.5.post1) for details.
|
||||
- **2026-04-13** 🛡️ Agent turn hardened — user messages persisted early, auto-compact skips active tasks.
|
||||
- **2026-04-12** 🔒 Lark global domain support, Dream learns discovered skills, shell sandbox tightened.
|
||||
- **2026-04-11** ⚡ Context compact shrinks sessions on the fly; Kagi web search; QQ & WeCom full media.
|
||||
- **2026-04-10** 📓 Multiple MCP servers, Feishu streaming & done-emoji.
|
||||
- **2026-04-09** 🔌 WebSocket channel, unified cross-channel session, `disabled_skills` config.
|
||||
- **2026-04-08** 📤 API file uploads, OpenAI reasoning auto-routing with Responses fallback.
|
||||
- **2026-04-07** 🧠 Anthropic adaptive thinking, MCP resources & prompts exposed as tools.
|
||||
- **2026-04-06** 🛰️ Langfuse observability, unified Whisper transcription, email attachments.
|
||||
- **2026-04-05** 🚀 Released **v0.1.5** — sturdier long-running tasks, Dream two-stage memory, production-ready sandboxing and programming Agent SDK. Please see [release notes](https://github.com/HKUDS/nanobot/releases/tag/v0.1.5) for details.
|
||||
- **2026-04-04** 🚀 Jinja2 response templates, Dream memory hardened, smarter retry handling.
|
||||
- **2026-04-03** 🧠 Xiaomi MiMo provider, chain-of-thought reasoning visible, Telegram UX polish.
|
||||
- **2026-04-02** 🧱 Long-running tasks run more reliably — core runtime hardening.
|
||||
- **2026-04-01** 🔑 GitHub Copilot auth restored; stricter workspace paths; OpenRouter Claude caching fix.
|
||||
- **2026-03-31** 🛰️ WeChat multimodal alignment, Discord/Matrix polish, Python SDK facade, MCP and tool fixes.
|
||||
- **2026-03-30** 🧩 OpenAI-compatible API tightened; composable agent lifecycle hooks.
|
||||
- **2026-03-29** 💬 WeChat voice, typing, QR/media resilience; fixed-session OpenAI-compatible API.
|
||||
- **2026-03-28** 📚 Provider docs refresh; skill template wording fix.
|
||||
- **2026-03-27** 🚀 Released **v0.1.4.post6** — architecture decoupling, litellm removal, end-to-end streaming, WeChat channel, and a security fix. Please see [release notes](https://github.com/HKUDS/nanobot/releases/tag/v0.1.4.post6) for details.
|
||||
- **2026-03-26** 🏗️ Agent runner extracted and lifecycle hooks unified; stream delta coalescing at boundaries.
|
||||
- **2026-03-25** 🌏 StepFun provider, configurable timezone, Gemini thought signatures.
|
||||
- **2026-03-24** 🔧 WeChat compatibility, Feishu CardKit streaming, test suite restructured.
|
||||
- **2026-03-23** 🔧 Command routing refactored for plugins, WhatsApp/WeChat media, unified channel login CLI.
|
||||
- **2026-03-22** ⚡ End-to-end streaming, WeChat channel, Anthropic cache optimization, `/status` command.
|
||||
- **2026-03-21** 🔒 Replace `litellm` with native `openai` + `anthropic` SDKs. Please see [commit](https://github.com/HKUDS/nanobot/commit/3dfdab7).
|
||||
- **2026-03-20** 🧙 Interactive setup wizard — pick your provider, model autocomplete, and you're good to go.
|
||||
- **2026-03-19** 💬 Telegram gets more resilient under load; Feishu now renders code blocks properly.
|
||||
- **2026-03-18** 📷 Telegram can now send media via URL. Cron schedules show human-readable details.
|
||||
- **2026-03-17** ✨ Feishu formatting glow-up, Slack reacts when done, custom endpoints support extra headers, and image handling is more reliable.
|
||||
- **2026-03-16** 🚀 Released **v0.1.4.post5** — a refinement-focused release with stronger reliability and channel support, and a more dependable day-to-day experience. Please see [release notes](https://github.com/HKUDS/nanobot/releases/tag/v0.1.4.post5) for details.
|
||||
- **2026-03-15** 🧩 DingTalk rich media, smarter built-in skills, and cleaner model compatibility.
|
||||
- **2026-03-14** 💬 Channel plugins, Feishu replies, and steadier MCP, QQ, and media handling.
|
||||
- **2026-03-13** 🌐 Multi-provider web search, LangSmith, and broader reliability improvements.
|
||||
- **2026-03-12** 🚀 VolcEngine support, Telegram reply context, `/restart`, and sturdier memory.
|
||||
- **2026-03-11** 🔌 WeCom, Ollama, cleaner discovery, and safer tool behavior.
|
||||
- **2026-03-10** 🧠 Token-based memory, shared retries, and cleaner gateway and Telegram behavior.
|
||||
- **2026-03-09** 💬 Slack thread polish and better Feishu audio compatibility.
|
||||
- **2026-03-08** 🚀 Released **v0.1.4.post4** — a reliability-packed release with safer defaults, better multi-instance support, sturdier MCP, and major channel and provider improvements. Please see [release notes](https://github.com/HKUDS/nanobot/releases/tag/v0.1.4.post4) for details.
|
||||
- **2026-03-07** 🚀 Azure OpenAI provider, WhatsApp media, QQ group chats, and more Telegram/Feishu polish.
|
||||
- **2026-03-06** 🪄 Lighter providers, smarter media handling, and sturdier memory and CLI compatibility.
|
||||
- **2026-03-05** ⚡️ Telegram draft streaming, MCP SSE support, and broader channel reliability fixes.
|
||||
- **2026-03-04** 🛠️ Dependency cleanup, safer file reads, and another round of test and Cron fixes.
|
||||
- **2026-03-03** 🧠 Cleaner user-message merging, safer multimodal saves, and stronger Cron guards.
|
||||
- **2026-03-02** 🛡️ Safer default access control, sturdier Cron reloads, and cleaner Matrix media handling.
|
||||
- **2026-03-01** 🌐 Web proxy support, smarter Cron reminders, and Feishu rich-text parsing improvements.
|
||||
- **2026-02-28** 🚀 Released **v0.1.4.post3** — cleaner context, hardened session history, and smarter agent. Please see [release notes](https://github.com/HKUDS/nanobot/releases/tag/v0.1.4.post3) for details.
|
||||
- **2026-02-27** 🧠 Experimental thinking mode support, DingTalk media messages, Feishu and QQ channel fixes.
|
||||
- **2026-02-26** 🛡️ Session poisoning fix, WhatsApp dedup, Windows path guard, Mistral compatibility.
|
||||
- **2026-02-25** 🧹 New Matrix channel, cleaner session context, auto workspace template sync.
|
||||
- **2026-02-24** 🚀 Released **v0.1.4.post2** — a reliability-focused release with a redesigned heartbeat, prompt cache optimization, and hardened provider & channel stability. See [release notes](https://github.com/HKUDS/nanobot/releases/tag/v0.1.4.post2) for details.
|
||||
- **2026-02-23** 🔧 Virtual tool-call heartbeat, prompt cache optimization, Slack mrkdwn fixes.
|
||||
- **2026-02-22** 🛡️ Slack thread isolation, Discord typing fix, agent reliability improvements.
|
||||
- **2026-02-21** 🎉 Released **v0.1.4.post1** — new providers, media support across channels, and major stability improvements. See [release notes](https://github.com/HKUDS/nanobot/releases/tag/v0.1.4.post1) for details.
|
||||
- **2026-02-20** 🐦 Feishu now receives multimodal files from users. More reliable memory under the hood.
|
||||
- **2026-02-19** ✨ Slack now sends files, Discord splits long messages, and subagents work in CLI mode.
|
||||
- **2026-02-18** ⚡️ nanobot now supports VolcEngine, MCP custom auth headers, and Anthropic prompt caching.
|
||||
- **2026-02-17** 🎉 Released **v0.1.4** — MCP support, progress streaming, new providers, and multiple channel improvements. Please see [release notes](https://github.com/HKUDS/nanobot/releases/tag/v0.1.4) for details.
|
||||
- **2026-02-16** 🦞 nanobot now integrates a [ClawHub](https://clawhub.ai) skill — search and install public agent skills.
|
||||
- **2026-02-15** 🔑 nanobot now supports OpenAI Codex provider with OAuth login support.
|
||||
- **2026-02-14** 🔌 nanobot now supports MCP! See [MCP section](./configuration.md#mcp-model-context-protocol) for details.
|
||||
- **2026-02-13** 🎉 Released **v0.1.3.post7** — includes security hardening and multiple improvements. **Please upgrade to the latest version to address security issues**. See [release notes](https://github.com/HKUDS/nanobot/releases/tag/v0.1.3.post7) for more details.
|
||||
- **2026-02-12** 🧠 Redesigned memory system — Less code, more reliable. Join the [discussion](https://github.com/HKUDS/nanobot/discussions/566) about it!
|
||||
- **2026-02-11** ✨ Enhanced CLI experience and added MiniMax support!
|
||||
- **2026-02-10** 🎉 Released **v0.1.3.post6** with improvements! Check the updates [notes](https://github.com/HKUDS/nanobot/releases/tag/v0.1.3.post6) and our [roadmap](https://github.com/HKUDS/nanobot/discussions/431).
|
||||
- **2026-02-09** 💬 Added Slack, Email, and QQ support — nanobot now supports multiple chat platforms!
|
||||
- **2026-02-08** 🔧 Refactored Providers—adding a new LLM provider now takes just 2 simple steps! Check [here](./configuration.md#providers).
|
||||
- **2026-02-07** 🚀 Released **v0.1.3.post5** with Qwen support & several key improvements! Check [here](https://github.com/HKUDS/nanobot/releases/tag/v0.1.3.post5) for details.
|
||||
- **2026-02-06** ✨ Added Moonshot/Kimi provider, Discord integration, and enhanced security hardening!
|
||||
- **2026-02-05** ✨ Added Feishu channel, DeepSeek provider, and enhanced scheduled tasks support!
|
||||
- **2026-02-04** 🚀 Released **v0.1.3.post4** with multi-provider & Docker support! Check [here](https://github.com/HKUDS/nanobot/releases/tag/v0.1.3.post4) for details.
|
||||
- **2026-02-03** ⚡ Integrated vLLM for local LLM support and improved natural language task scheduling!
|
||||
- **2026-02-02** 🎉 nanobot officially launched! Welcome to try 🐈 nanobot!
|
||||
@@ -0,0 +1,419 @@
|
||||
# Start Without Technical Background
|
||||
|
||||
This page is for you if you have never used a terminal, edited a JSON file, or configured an AI model before.
|
||||
|
||||
The goal is small: get one local nanobot reply in your browser. Do not connect Telegram, Discord, Docker, local models, or deployment yet. Those are easier after the first reply works.
|
||||
|
||||
## What You Are Setting Up
|
||||
|
||||
You only need these words for Quick Start:
|
||||
|
||||
| Word | Plain meaning |
|
||||
|---|---|
|
||||
| Terminal | A text window where you paste commands and press Enter. |
|
||||
| Command | One line of text you run in the terminal. |
|
||||
| API key | A password-like token from an AI provider. Do not share it publicly. |
|
||||
| Config file | The settings file nanobot reads when it starts. |
|
||||
| Wizard | An interactive terminal menu that edits the config file for you. |
|
||||
| Browser UI | The local web page where you chat with nanobot. |
|
||||
|
||||
## 1. Open a Terminal
|
||||
|
||||
You will paste commands into a terminal. Copy only the command text inside each code block; do not copy the ``` marks.
|
||||
|
||||
| System | How to open it |
|
||||
|---|---|
|
||||
| Windows | Press `Win`, type `PowerShell`, then open **Windows PowerShell**. |
|
||||
| macOS | Press `Command` + `Space`, type `Terminal`, then press `Enter`. |
|
||||
| Linux | Open your app launcher, search for `Terminal`, then open it. |
|
||||
|
||||
When the terminal opens, click inside it, paste the command, and press `Enter`. If a command prints text and returns to a prompt, that is usually normal.
|
||||
|
||||
## 2. Install Python
|
||||
|
||||
Install Python 3.11 or newer from [python.org](https://www.python.org/downloads/).
|
||||
|
||||
On Windows, enable **Add python.exe to PATH** during installation if the installer shows that option.
|
||||
|
||||
In that terminal, check Python:
|
||||
|
||||
```bash
|
||||
python --version
|
||||
```
|
||||
|
||||
If Windows says `python` is not found, close and reopen PowerShell. If it still does not work, try:
|
||||
|
||||
```bash
|
||||
py --version
|
||||
```
|
||||
|
||||
If `py` works but `python` does not, replace `python` with `py` in the commands below.
|
||||
|
||||
If macOS or Linux says `python` is not found, try:
|
||||
|
||||
```bash
|
||||
python3 --version
|
||||
```
|
||||
|
||||
If `python3` works but `python` does not, replace `python` with `python3` in the manual commands below. The one-command installer already checks both `python3` and `python`.
|
||||
|
||||
## 3. Get a Provider API Key
|
||||
|
||||
nanobot does not create AI accounts or API keys for you. Use an AI provider account, company endpoint, subscription endpoint, or local model server that you already control. If the provider has an OpenAI-compatible base URL in its docs, keep that nearby too.
|
||||
|
||||
For the setup path:
|
||||
|
||||
1. Open your provider's API key page.
|
||||
2. Create or copy an API key.
|
||||
3. Keep the key private.
|
||||
4. Keep the provider's base URL nearby if the provider docs show one.
|
||||
|
||||
## 4. Install nanobot
|
||||
|
||||
The easiest path is the one-command installer. It installs or upgrades nanobot, then starts the setup wizard. On macOS and Linux it avoids system-wide pip installs by using an active virtual environment, `uv`, `pipx`, or a managed venv under `~/.nanobot/venv`.
|
||||
|
||||
**macOS / Linux**
|
||||
|
||||
```bash
|
||||
curl -fsSL https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.sh | sh
|
||||
```
|
||||
|
||||
**Windows PowerShell**
|
||||
|
||||
```powershell
|
||||
irm https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.ps1 | iex
|
||||
```
|
||||
|
||||
These commands install the stable PyPI package. To preview what the installer would do without changing your environment, pass `--dry-run`:
|
||||
|
||||
```bash
|
||||
curl -fsSL https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.sh | sh -s -- --dry-run
|
||||
```
|
||||
|
||||
```powershell
|
||||
& ([scriptblock]::Create((irm https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.ps1))) --dry-run
|
||||
```
|
||||
|
||||
Use the development installer only when a maintainer asks you to test the current `main` branch:
|
||||
|
||||
```bash
|
||||
curl -fsSL https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.sh | sh -s -- --dev
|
||||
```
|
||||
|
||||
```powershell
|
||||
& ([scriptblock]::Create((irm https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.ps1))) --dev
|
||||
```
|
||||
|
||||
If the command says `curl` or `irm` is not found, or it cannot download from GitHub, use one of the manual install commands below.
|
||||
|
||||
If `uv` is installed, use:
|
||||
|
||||
```bash
|
||||
uv tool install nanobot-ai
|
||||
```
|
||||
|
||||
If you prefer pip, use it only inside an environment you control:
|
||||
|
||||
```bash
|
||||
python -m pip install nanobot-ai
|
||||
```
|
||||
|
||||
If pip reports `externally-managed-environment` on macOS or Linux, go back to the one-command installer, use `uv tool install nanobot-ai`, use `pipx install nanobot-ai`, or create a virtual environment first.
|
||||
|
||||
Then check that nanobot is installed:
|
||||
|
||||
```bash
|
||||
nanobot --version
|
||||
```
|
||||
|
||||
If the terminal cannot find `nanobot`, use the module form:
|
||||
|
||||
```bash
|
||||
python -m nanobot --version
|
||||
```
|
||||
|
||||
Use `python3 -m nanobot --version` or `py -m nanobot --version` if that is the Python command that worked in step 2.
|
||||
|
||||
## 5. Run the Setup Wizard
|
||||
|
||||
The one-command installer starts this for you after installation. If you installed manually, run:
|
||||
|
||||
```bash
|
||||
nanobot onboard --wizard
|
||||
```
|
||||
|
||||
If `nanobot` is not found, run:
|
||||
|
||||
```bash
|
||||
python -m nanobot onboard --wizard
|
||||
```
|
||||
|
||||
Use `python3 -m nanobot onboard --wizard` or `py -m nanobot onboard --wizard` if that is the Python command that worked in step 2.
|
||||
|
||||
The wizard is a terminal menu. It is not a graphical app, but it lets you choose options instead of hand-editing every JSON field.
|
||||
|
||||
You will see a menu like this:
|
||||
|
||||
```text
|
||||
> What would you like to do?
|
||||
[Q] Quick Start
|
||||
[A] Advanced Settings
|
||||
[X] Exit
|
||||
```
|
||||
|
||||
Move through the wizard like this:
|
||||
|
||||
| When you see | Do this |
|
||||
|---|---|
|
||||
| A menu | Use the arrow keys to highlight an option, then press `Enter`. |
|
||||
| The provider menu | Choose the company or service you want to use. |
|
||||
| An endpoint menu | Choose the standard API or subscription plan endpoint that matches your key. |
|
||||
| An API key field | Paste the key, then press `Enter`. |
|
||||
| A provider base URL field | Paste the provider base URL from its docs, then press `Enter`. |
|
||||
| The Model ID field | Paste a model name from your provider, then press `Enter`. |
|
||||
| A back option in Advanced Settings | Choose it to return to the previous menu. |
|
||||
|
||||
For the first setup, choose `[Q] Quick Start`. It configures the recommended local browser UI and default AI settings for you. Use `Advanced Settings` later only if you need a chat app, a tool setup, or provider-specific fields.
|
||||
|
||||
1. Choose `[Q] Quick Start`.
|
||||
2. Choose the provider you want to use.
|
||||
3. Choose the endpoint if the wizard asks, such as Standard API, Coding Plan, Token Plan, or Step Plan.
|
||||
4. Paste your API key if the wizard asks for one.
|
||||
5. Paste the provider base URL if the wizard asks for one.
|
||||
6. Paste a model ID that provider can run.
|
||||
7. Confirm that Quick Start should configure the local WebUI.
|
||||
8. Set the WebUI password when prompted.
|
||||
9. Review the Quick Start summary. The wizard saves and exits when Quick Start finishes.
|
||||
|
||||
The recommended path configures the local WebUI, requires a WebUI password, and writes default AI settings. You do not need to choose a separate chat app for the first run.
|
||||
|
||||
If you already know that you need custom headers, provider-specific request fields, a chat app, or tools, choose `Advanced Settings` instead. [`provider-cookbook.md`](./provider-cookbook.md) has copyable examples for several common provider setups. After you change advanced settings, a save option appears in the main menu. Choose `[S] Save and Exit`.
|
||||
|
||||
The wizard creates or updates:
|
||||
|
||||
| Path | Meaning |
|
||||
|---|---|
|
||||
| `~/.nanobot/config.json` | Settings file. |
|
||||
| `~/.nanobot/workspace/` | Working folder for memory, sessions, and generated files. |
|
||||
|
||||
If Quick Start finished successfully, skip to [Open the WebUI](#7-open-the-webui). The next two sections are only for manual setup.
|
||||
|
||||
## Manual Setup: How to Merge JSON Snippets
|
||||
|
||||
Most docs examples are snippets, not whole files. Your `config.json` has one outer `{ ... }`. Add new top-level sections such as `providers`, `modelPresets`, `agents`, or `channels` inside that same outer object.
|
||||
|
||||
Do not paste two separate JSON objects into one file:
|
||||
|
||||
```text
|
||||
{
|
||||
"providers": { "...": "..." }
|
||||
}
|
||||
{
|
||||
"channels": { "...": "..." }
|
||||
}
|
||||
```
|
||||
|
||||
Merge them into one object:
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"custom": {
|
||||
"apiKey": "your-api-key",
|
||||
"apiBase": "https://api.example.com/v1"
|
||||
}
|
||||
},
|
||||
"channels": {
|
||||
"websocket": {
|
||||
"tokenIssueSecret": "your-webui-password",
|
||||
"websocketRequiresToken": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Notice the comma after the `providers` block. JSON needs commas between sibling sections, but not after the last section. If this feels hard, use `nanobot onboard --wizard` whenever possible.
|
||||
|
||||
## 6. Manual Setup: Config Fallback
|
||||
|
||||
Use this only if the wizard is unavailable or you prefer opening the file yourself.
|
||||
|
||||
Run `nanobot onboard` first if `~/.nanobot/config.json` does not exist yet.
|
||||
|
||||
Use one of these commands:
|
||||
|
||||
**Windows PowerShell**
|
||||
|
||||
```powershell
|
||||
notepad "$env:USERPROFILE\.nanobot\config.json"
|
||||
```
|
||||
|
||||
**macOS**
|
||||
|
||||
```bash
|
||||
open -e ~/.nanobot/config.json
|
||||
```
|
||||
|
||||
**Linux**
|
||||
|
||||
```bash
|
||||
xdg-open ~/.nanobot/config.json
|
||||
```
|
||||
|
||||
If this is a brand-new install and you have not configured anything else yet, replace the file with this minimal config:
|
||||
|
||||
```json
|
||||
{
|
||||
"providers": {
|
||||
"custom": {
|
||||
"apiKey": "your-api-key",
|
||||
"apiBase": "https://api.example.com/v1"
|
||||
}
|
||||
},
|
||||
"modelPresets": {
|
||||
"primary": {
|
||||
"label": "Primary",
|
||||
"provider": "custom",
|
||||
"model": "model-id-from-your-provider",
|
||||
"maxTokens": 4096,
|
||||
"contextWindowTokens": 65536,
|
||||
"temperature": 0.1
|
||||
}
|
||||
},
|
||||
"agents": {
|
||||
"defaults": {
|
||||
"modelPreset": "primary"
|
||||
}
|
||||
},
|
||||
"channels": {
|
||||
"websocket": {
|
||||
"tokenIssueSecret": "your-webui-password",
|
||||
"websocketRequiresToken": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Replace `your-api-key`, `https://api.example.com/v1`, `model-id-from-your-provider`, and `your-webui-password` with your own values.
|
||||
|
||||
For copyable provider-specific examples, use [`provider-cookbook.md`](./provider-cookbook.md).
|
||||
|
||||
Save the file.
|
||||
|
||||
## 7. Open the WebUI
|
||||
|
||||
First check that nanobot can read the saved setup:
|
||||
|
||||
```bash
|
||||
nanobot status
|
||||
```
|
||||
|
||||
This should show the config file path, workspace path, and the active model or preset. If `nanobot` is not found, use `python -m nanobot status`, `python3 -m nanobot status`, or `py -m nanobot status`, matching the Python command that worked in step 2.
|
||||
|
||||
It is normal for most providers to say `not set`. Only the provider you selected for the active preset needs to look configured.
|
||||
|
||||
Start the local browser UI:
|
||||
|
||||
```bash
|
||||
nanobot webui
|
||||
```
|
||||
|
||||
This starts nanobot and opens `http://127.0.0.1:8765` in your browser. Leave the terminal open while you use the WebUI. Enter the WebUI password you set in the wizard if the browser asks for one.
|
||||
|
||||
Send this first message in the browser:
|
||||
|
||||
```text
|
||||
Hello!
|
||||
```
|
||||
|
||||
If that works, nanobot is installed and can call the model. You should see a normal assistant reply in the browser. The exact words will differ, but it should look like this shape:
|
||||
|
||||
```text
|
||||
Hello! How can I help you today?
|
||||
```
|
||||
|
||||
If `nanobot` is not found, run:
|
||||
|
||||
```bash
|
||||
python -m nanobot webui
|
||||
```
|
||||
|
||||
Use `python3 -m nanobot webui` or `py -m nanobot webui` if that is the Python command that worked in step 2.
|
||||
|
||||
Once this works, nanobot can help with its own next setup step. In the browser UI, ask it to read these docs and update your current config for one specific goal, then run `/restart` when nanobot tells you the config is ready. For example, ask it to add one provider preset or configure one chat app.
|
||||
|
||||
## 8. If Something Fails
|
||||
|
||||
Do not change many things at once. Check the exact error:
|
||||
|
||||
| Error or symptom | What it usually means |
|
||||
|---|---|
|
||||
| `JSON parse error` | The config file has a missing comma, extra comma, or mismatched brace. Copy the example again. |
|
||||
| `401`, `unauthorized`, or `invalid API key` | The API key is wrong, expired, has extra spaces, or was pasted under the wrong provider. |
|
||||
| `model not found` | Your account cannot use the default model. Return to `nanobot onboard --wizard`, choose `Advanced Settings`, then edit `Model Presets`. |
|
||||
| `nanobot: command not found` | The install worked in Python, but your shell cannot find the script. Use `python -m nanobot ...`, `python3 -m nanobot ...`, or `py -m nanobot ...`, matching the Python command that worked earlier. |
|
||||
| No response after editing config | Restart the command. Long-running processes read config when they start. |
|
||||
|
||||
For a fuller diagnosis path, see [`troubleshooting.md`](./troubleshooting.md).
|
||||
|
||||
## What Not to Configure Yet
|
||||
|
||||
Skip these until the first local message works:
|
||||
|
||||
- `apiBase`: hosted built-in providers often already have default endpoints. You only need `apiBase` for local models, proxies, custom OpenAI-compatible providers, or special regional/subscription endpoints.
|
||||
- chat apps: first prove the local browser UI can answer.
|
||||
- fallback models: useful later, but not needed for the first reply.
|
||||
- Langfuse: useful for observability, but not needed for first setup.
|
||||
|
||||
## Next Steps
|
||||
|
||||
After the first reply works, choose only one next goal. Keep the terminal that runs `nanobot webui` open whenever you use the WebUI. Chat apps use the same gateway service underneath.
|
||||
|
||||
### Open the Browser UI Again
|
||||
|
||||
Run:
|
||||
|
||||
```bash
|
||||
nanobot webui
|
||||
```
|
||||
|
||||
Leave that terminal open; the browser should open automatically.
|
||||
|
||||
To stop the WebUI later, return to the gateway terminal and press `Ctrl+C`.
|
||||
|
||||
If `nanobot` is not found, run `python -m nanobot webui`, `python3 -m nanobot webui`, or `py -m nanobot webui`, matching the Python command that worked earlier. More details are in [`webui.md`](./webui.md).
|
||||
|
||||
### Connect a Chat App
|
||||
|
||||
1. Read the section for one app in [`chat-apps.md`](./chat-apps.md).
|
||||
2. Add only that app's config snippet. Merge it into the existing file instead of replacing the whole file.
|
||||
3. Run:
|
||||
|
||||
```bash
|
||||
nanobot channels status
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
4. Leave the gateway terminal open, then send a message from the allowed account.
|
||||
|
||||
Start with a private chat or a test server. Do not set `allowFrom` to `["*"]` unless you intentionally want anyone who can reach that channel to talk to the bot.
|
||||
|
||||
### Change Models or Add Backups
|
||||
|
||||
Use [`providers.md`](./providers.md) when a provider/model pair fails, and [`provider-cookbook.md`](./provider-cookbook.md) when you want copyable snippets. Keep model choices in `modelPresets`, then select the active one with `agents.defaults.modelPreset`.
|
||||
|
||||
### Ask for Help
|
||||
|
||||
When you ask for help, include:
|
||||
|
||||
- your operating system;
|
||||
- the command you ran;
|
||||
- `nanobot --version`;
|
||||
- `nanobot status`;
|
||||
- whether the browser UI can answer `Hello!`;
|
||||
- the exact error text;
|
||||
- a config snippet with API keys and tokens removed.
|
||||
|
||||
Never paste real API keys, bot tokens, OAuth tokens, or private chat IDs into a public issue or chat.
|
||||
|
||||
If you find a docs mistake, outdated command, or confusing step, please open an issue: <https://github.com/HKUDS/nanobot/issues>.
|
||||
@@ -0,0 +1,267 @@
|
||||
# Troubleshooting
|
||||
|
||||
Use this page to isolate where a failure lives. Start with the smallest surface that proves the most: local CLI first, then gateway, then WebUI or chat apps.
|
||||
|
||||
## Fast Diagnosis Order
|
||||
|
||||
Run these in order:
|
||||
|
||||
```bash
|
||||
nanobot --version
|
||||
nanobot status
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
Then, only if the CLI works:
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
This separates failures into layers:
|
||||
|
||||
| Layer | What it proves |
|
||||
|---|---|
|
||||
| `nanobot --version` | Install and shell command discovery |
|
||||
| `nanobot status` | Config path, workspace path, active model, and provider summary |
|
||||
| `nanobot agent -m "Hello!"` | Config loading, provider/model access, workspace writes, and agent loop |
|
||||
| `nanobot gateway` | Channel startup, cron system jobs, heartbeat, WebUI/WebSocket, and health endpoint |
|
||||
|
||||
If `nanobot agent -m "Hello!"` fails, fix that before debugging WebUI, Telegram, Discord, Docker, systemd, or any chat app.
|
||||
|
||||
## How to Read `nanobot status`
|
||||
|
||||
`nanobot status` does not call a model. It only checks whether nanobot can find the selected config, selected workspace, active model or preset, and provider setup summary.
|
||||
|
||||
The output has this shape:
|
||||
|
||||
```text
|
||||
nanobot Status
|
||||
|
||||
Config: /path/to/config.json ✓
|
||||
Workspace: /path/to/workspace ✓
|
||||
Model: provider/model-name (preset: primary)
|
||||
Provider A: not set
|
||||
Provider B: ✓
|
||||
Local Provider: ✓ http://localhost:11434/v1
|
||||
OAuth Provider: ✓ (OAuth)
|
||||
```
|
||||
|
||||
Read it like this:
|
||||
|
||||
| Line | Good sign | What to do if it looks wrong |
|
||||
|---|---|---|
|
||||
| `Config` | It points to the config file you meant to use and shows `✓`. | Run `nanobot onboard`, or pass `--config` to `nanobot agent`, `gateway`, or `serve` when testing a non-default instance. |
|
||||
| `Workspace` | It points to the workspace you meant to use and shows `✓`. | Run `nanobot onboard`, create the folder, fix permissions, or pass `--workspace` on commands that support it. |
|
||||
| `Model` | It shows the active model or the preset name you expect. | Set `agents.defaults.modelPreset` to the intended preset, or check `/model` if you changed models during a chat session. |
|
||||
| Provider rows | The provider used by the active preset shows `✓`, an OAuth marker, or a local URL. | Configure only the active provider first. It is normal for unused providers to say `not set`. |
|
||||
|
||||
If `nanobot status` looks right but `nanobot agent -m "Hello!"` fails, the install and config paths are probably fine. Continue with [Provider and Model Problems](#provider-and-model-problems).
|
||||
|
||||
## Installation Problems
|
||||
|
||||
Use the same Python command for install checks and module fallback. On macOS/Linux that may be `python3`; on Windows it may be `python` or `py`.
|
||||
|
||||
| Symptom | Check |
|
||||
|---|---|
|
||||
| `python: command not found` | Try `python3 --version` on macOS/Linux or `py --version` on Windows. Then replace `python` in docs commands with the command that worked. |
|
||||
| `curl: command not found` | The macOS/Linux one-command installer could not download the script. Install curl, or use a manual isolated install such as `uv tool install nanobot-ai` or `pipx install nanobot-ai`. |
|
||||
| `irm` is not recognized | PowerShell could not run the download helper. Use manual install: `uv tool install nanobot-ai`, `pipx install nanobot-ai`, or `py -m pip install nanobot-ai` inside an environment you control. |
|
||||
| Could not download `raw.githubusercontent.com` | Your network, proxy, or firewall blocked the installer script download. Use manual install from PyPI, or configure your proxy and rerun the command. |
|
||||
| `nanobot: command not found` | Use the module form, for example `python -m nanobot ...`, `python3 -m nanobot ...`, or `py -m nanobot ...`. Reinstall with the same Python command, or add that Python's scripts directory to `PATH`. |
|
||||
| `No module named nanobot` | You are running a different Python than the one used for installation. Run `python -m pip show nanobot-ai`, `python3 -m pip show nanobot-ai`, or `py -m pip show nanobot-ai`, matching the command that installed nanobot. |
|
||||
| `pip is not available` | When the installer uses a virtual environment, it tries `python -m ensurepip --upgrade`. If that fails, install pip for that Python, or use a Python installer/distribution that includes pip. |
|
||||
| `externally-managed-environment` | Your system Python blocks global pip installs. Use the one-command installer, `uv tool install nanobot-ai`, `pipx install nanobot-ai`, or create a virtual environment; do not add `--break-system-packages` for nanobot. |
|
||||
| Installer chose the wrong Python | Set `PYTHON` before running the installer, such as `curl -fsSL https://raw.githubusercontent.com/HKUDS/nanobot/main/scripts/install.sh | PYTHON=python3 sh` or `$env:PYTHON="py"` before the PowerShell command. |
|
||||
| Editable source install does not update | From the repo root, run `python -m pip install -e .` again with the Python command used for development, then check `python -m nanobot --version` or `nanobot --version`. |
|
||||
| WebUI build tools missing | They are only needed for WebUI development. Packaged installs already include the WebUI bundle. |
|
||||
|
||||
## Config Problems
|
||||
|
||||
Default config path:
|
||||
|
||||
```text
|
||||
~/.nanobot/config.json
|
||||
```
|
||||
|
||||
Default workspace path:
|
||||
|
||||
```text
|
||||
~/.nanobot/workspace/
|
||||
```
|
||||
|
||||
`nanobot status` reads the default config unless you pass explicit paths. Use the same `--config` and `--workspace` across status checks and runtime commands when debugging multiple instances:
|
||||
|
||||
```bash
|
||||
nanobot status --config ./bot-a/config.json --workspace ./bot-a/workspace
|
||||
nanobot agent --config ./bot-a/config.json --workspace ./bot-a/workspace -m "Hello"
|
||||
nanobot gateway --config ./bot-a/config.json --workspace ./bot-a/workspace
|
||||
```
|
||||
|
||||
Common config mistakes:
|
||||
|
||||
| Symptom | Check |
|
||||
|---|---|
|
||||
| JSON parse error | Validate commas, braces, and quotes. Most docs examples are partial snippets to merge. |
|
||||
| Unknown or missing provider | Use provider registry names such as `openrouter`, `anthropic`, `openai`, `ollama`, `vllm`, `lm_studio`, or define a custom OpenAI-compatible provider key under `providers` and reference that exact key from the active preset. |
|
||||
| snake_case vs camelCase confusion | Both are accepted, but docs use camelCase because nanobot writes config with aliases such as `apiKey`, `modelPresets`, `intervalS`. |
|
||||
| Environment variable error | `${VAR_NAME}` references are resolved at startup. Set the variable before running nanobot. |
|
||||
| Edited config but behavior did not change | Restart `nanobot gateway`; long-running processes read config at startup. |
|
||||
|
||||
To refresh missing defaults without overwriting existing settings, run:
|
||||
|
||||
```bash
|
||||
nanobot onboard --refresh
|
||||
```
|
||||
|
||||
For an interactive choice between resetting and refreshing, run `nanobot onboard` and choose the option that keeps current values and merges missing defaults.
|
||||
|
||||
## Provider and Model Problems
|
||||
|
||||
First prove the provider in the CLI:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "Hello!"
|
||||
```
|
||||
|
||||
Then compare your config against [`providers.md`](./providers.md).
|
||||
|
||||
If you need a known-good snippet instead of diagnosis, use [`provider-cookbook.md`](./provider-cookbook.md).
|
||||
|
||||
| Symptom | Likely cause |
|
||||
|---|---|
|
||||
| 401, unauthorized, invalid API key | Key is missing, expired, pasted with whitespace, or under the wrong provider key. |
|
||||
| Model not found | The model ID belongs to a different provider or gateway. |
|
||||
| Provider cannot be inferred | Pin `modelPresets.<name>.provider` in the active preset instead of using `"auto"`. For legacy direct configs, pin `agents.defaults.provider`. |
|
||||
| Local model connection refused | Ollama, vLLM, LM Studio, or another local server is not running, or `apiBase` points to the wrong port. |
|
||||
| Bedrock validation error | Check AWS region, credentials, model access, model ID, and whether the model supports Converse. |
|
||||
| OAuth provider fails | Run `nanobot provider login openai-codex` or `nanobot provider login github-copilot`, then select the provider explicitly. |
|
||||
|
||||
## Langfuse Problems
|
||||
|
||||
Langfuse tracing is optional and controlled by environment variables.
|
||||
|
||||
| Symptom | Check |
|
||||
|---|---|
|
||||
| `LANGFUSE_SECRET_KEY is set but langfuse is not installed` | Install `langfuse` in the same Python environment that runs nanobot, then restart the process. |
|
||||
| No traces appear | Set `LANGFUSE_SECRET_KEY`, `LANGFUSE_PUBLIC_KEY`, and `LANGFUSE_BASE_URL` before starting nanobot. |
|
||||
| Wrong Langfuse project or region | Check that the key pair and `LANGFUSE_BASE_URL` come from the same Langfuse project/region. |
|
||||
| Only some providers trace | Langfuse tracing applies to OpenAI-compatible provider calls; native providers may not use that client path. |
|
||||
|
||||
See [`configuration.md#langfuse-observability`](./configuration.md#langfuse-observability) for setup commands.
|
||||
|
||||
## Gateway Problems
|
||||
|
||||
`nanobot gateway` is required for WebUI, chat apps, heartbeat, Dream, and long-running channel connections.
|
||||
|
||||
Default ports:
|
||||
|
||||
| Surface | Default |
|
||||
|---|---|
|
||||
| Gateway health endpoint | `http://127.0.0.1:18790/health` |
|
||||
| WebUI/WebSocket channel | `http://127.0.0.1:8765` |
|
||||
| OpenAI-compatible API (`nanobot serve`) | `http://127.0.0.1:8900` |
|
||||
|
||||
Common gateway checks:
|
||||
|
||||
```bash
|
||||
nanobot gateway --verbose
|
||||
```
|
||||
|
||||
| Symptom | Check |
|
||||
|---|---|
|
||||
| Port already in use | Change `gateway.port`, `channels.websocket.port`, or the `--port` CLI flag for the relevant command. |
|
||||
| WebUI opened on `18790` but shows nothing useful | Open `8765`; `18790` is the health endpoint. |
|
||||
| Config changes ignored | Restart the gateway. |
|
||||
| Heartbeat never runs | Keep the gateway running, add tasks under `<workspace>/HEARTBEAT.md` -> `## Active Tasks`, and make sure `gateway.heartbeat.enabled` is true. |
|
||||
| Cron jobs disappeared after switching workspaces | Cron jobs are workspace-scoped at `<workspace>/cron/jobs.json`; check you are using the intended workspace. |
|
||||
|
||||
## WebUI Problems
|
||||
|
||||
The packaged WebUI is served by the WebSocket channel.
|
||||
|
||||
Minimal config:
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"websocket": {
|
||||
"enabled": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Then run:
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
Open:
|
||||
|
||||
```text
|
||||
http://127.0.0.1:8765
|
||||
```
|
||||
|
||||
If accessing from another device, bind the WebSocket channel to `0.0.0.0` and set `token` or `tokenIssueSecret`. The WebSocket channel refuses public binds without a token or token issue secret.
|
||||
|
||||
See [`webui.md#lan-access`](./webui.md#lan-access) for LAN setup and [`../webui/README.md`](../webui/README.md) for frontend development.
|
||||
|
||||
## Chat App Problems
|
||||
|
||||
Before debugging a chat app:
|
||||
|
||||
```bash
|
||||
nanobot agent -m "Hello!"
|
||||
nanobot channels status
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
Then check:
|
||||
|
||||
| Symptom | Check |
|
||||
|---|---|
|
||||
| Bot never replies | Gateway is not running, the channel is not enabled, or the bot/app token is wrong. |
|
||||
| Unknown sender ignored | Configure `allowFrom`, pairing, or the channel-specific allow list. |
|
||||
| Telegram fails | Confirm the BotFather token and `allowFrom` user ID. |
|
||||
| Discord replies missing | Enable Message Content intent and invite the bot with the required permissions. |
|
||||
| WhatsApp or WeChat login expired | Re-run `nanobot channels login whatsapp` or `nanobot channels login weixin`. |
|
||||
| Chat app works but WebUI does not | The provider and gateway are likely fine; debug the WebSocket channel separately. |
|
||||
|
||||
See [`chat-apps.md`](./chat-apps.md) for channel-specific setup.
|
||||
|
||||
## Tool and Workspace Problems
|
||||
|
||||
| Symptom | Check |
|
||||
|---|---|
|
||||
| File access denied | Check `tools.restrictToWorkspace` and whether the target path is inside the active workspace. |
|
||||
| Shell commands fail in Docker | Sandbox settings may need Linux capabilities; see [`deployment.md`](./deployment.md). |
|
||||
| Web fetch blocked | SSRF protection blocks unsafe targets; use `tools.ssrfWhitelist` only for trusted private networks. |
|
||||
| MCP tools missing | Check `tools.mcpServers`, server startup command, environment variables, and tool allow list. |
|
||||
| Generated artifacts are missing | Check the active workspace and channel media directory. |
|
||||
|
||||
## Memory and Session Problems
|
||||
|
||||
| Symptom | Check |
|
||||
|---|---|
|
||||
| Conversation context seems wrong | Confirm the active workspace and session. WebUI chats and chat app threads may use different sessions. |
|
||||
| Memory does not update immediately | Dream consolidation is periodic; recent turns still live in session history. |
|
||||
| Old sessions appear after moving config | Session files are stored under `<workspace>/sessions/`; verify the workspace path. |
|
||||
| You want one shared session across devices | Set `agents.defaults.unifiedSession` intentionally; otherwise keep separate sessions. |
|
||||
|
||||
## Collect Useful Evidence
|
||||
|
||||
When opening an issue or asking for help, include:
|
||||
|
||||
- install method and `nanobot --version`;
|
||||
- operating system and Python version;
|
||||
- the command you ran;
|
||||
- relevant `nanobot status` output;
|
||||
- sanitized config snippets, especially provider, model, channel, and tool settings;
|
||||
- gateway logs from `nanobot gateway --verbose`;
|
||||
- whether `nanobot agent -m "Hello!"` works.
|
||||
|
||||
Never paste real API keys, bot tokens, OAuth tokens, or private chat IDs into public issues.
|
||||
|
||||
If you find a docs mistake, outdated command, or confusing step, please open an issue: <https://github.com/HKUDS/nanobot/issues>.
|
||||
@@ -0,0 +1,432 @@
|
||||
# WebSocket Server Channel
|
||||
|
||||
Nanobot can act as a WebSocket server, allowing external clients (web apps, CLIs, scripts) to interact with the agent in real time via persistent connections.
|
||||
|
||||
## Features
|
||||
|
||||
- Bidirectional real-time communication over WebSocket
|
||||
- Streaming support — receive agent responses token by token
|
||||
- Token-based authentication (static tokens and short-lived issued tokens)
|
||||
- Multi-chat multiplexing — one connection can run many concurrent `chat_id`s
|
||||
- TLS/SSL support (WSS) with enforced TLSv1.2 minimum
|
||||
- Client allow-list via `allowFrom`
|
||||
- Auto-cleanup of dead connections
|
||||
|
||||
## Quick Start
|
||||
|
||||
### 1. Configure
|
||||
|
||||
The WebSocket channel is enabled by default. Add only the fields you want to
|
||||
override under `channels.websocket`:
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"websocket": {
|
||||
"host": "127.0.0.1",
|
||||
"port": 8765,
|
||||
"path": "/",
|
||||
"tokenIssueSecret": "your-webui-password",
|
||||
"websocketRequiresToken": true,
|
||||
"allowFrom": ["*"],
|
||||
"streaming": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 2. Start nanobot
|
||||
|
||||
```bash
|
||||
nanobot gateway
|
||||
```
|
||||
|
||||
You should see:
|
||||
|
||||
```text
|
||||
WebSocket server listening on ws://127.0.0.1:8765/
|
||||
```
|
||||
|
||||
### 3. Connect a client
|
||||
|
||||
```bash
|
||||
# Using websocat
|
||||
websocat ws://127.0.0.1:8765/?client_id=alice
|
||||
|
||||
# Using Python
|
||||
import asyncio, json, websockets
|
||||
|
||||
async def main():
|
||||
async with websockets.connect("ws://127.0.0.1:8765/?client_id=alice") as ws:
|
||||
ready = json.loads(await ws.recv())
|
||||
print(ready) # {"event": "ready", "chat_id": "...", "client_id": "alice"}
|
||||
await ws.send(json.dumps({"content": "Hello nanobot!"}))
|
||||
reply = json.loads(await ws.recv())
|
||||
print(reply["text"])
|
||||
|
||||
asyncio.run(main())
|
||||
```
|
||||
|
||||
## Connection URL
|
||||
|
||||
```text
|
||||
ws://{host}:{port}{path}?client_id={id}&token={token}
|
||||
```
|
||||
|
||||
| Parameter | Required | Description |
|
||||
|-----------|----------|-------------|
|
||||
| `client_id` | No | Identifier for `allowFrom` authorization. Auto-generated as `anon-xxxxxxxxxxxx` if omitted. Truncated to 128 chars. |
|
||||
| `token` | Conditional | Authentication token. Required when `websocketRequiresToken` is `true` or `token` (static secret) is configured. |
|
||||
|
||||
## Wire Protocol
|
||||
|
||||
All frames are JSON text. Each message has an `event` field.
|
||||
|
||||
### Server → Client
|
||||
|
||||
**`ready`** — sent immediately after connection is established:
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "ready",
|
||||
"chat_id": "uuid-v4",
|
||||
"client_id": "alice"
|
||||
}
|
||||
```
|
||||
|
||||
**`message`** — full agent response:
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "message",
|
||||
"chat_id": "uuid-v4",
|
||||
"text": "Hello! How can I help?",
|
||||
"media": ["/tmp/image.png"],
|
||||
"reply_to": "msg-id"
|
||||
}
|
||||
```
|
||||
|
||||
`media` and `reply_to` are only present when applicable.
|
||||
|
||||
**`delta`** — streaming text chunk (only when `streaming: true`):
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "delta",
|
||||
"chat_id": "uuid-v4",
|
||||
"text": "Hello",
|
||||
"stream_id": "s1"
|
||||
}
|
||||
```
|
||||
|
||||
**`stream_end`** — signals the end of a streaming segment:
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "stream_end",
|
||||
"chat_id": "uuid-v4",
|
||||
"stream_id": "s1"
|
||||
}
|
||||
```
|
||||
|
||||
**`reasoning_delta`** — incremental model reasoning / thinking chunk for the active assistant turn. Mirrors `delta` but targets the reasoning bubble above the answer rather than the answer body:
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "reasoning_delta",
|
||||
"chat_id": "uuid-v4",
|
||||
"text": "Let me decompose ",
|
||||
"stream_id": "r1"
|
||||
}
|
||||
```
|
||||
|
||||
**`reasoning_end`** — close marker for the active reasoning stream. WebUI uses this to lock the in-place bubble and switch from the shimmer header to a static collapsed state:
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "reasoning_end",
|
||||
"chat_id": "uuid-v4",
|
||||
"stream_id": "r1"
|
||||
}
|
||||
```
|
||||
|
||||
Reasoning frames only flow when the channel's `showReasoning` is `true` (default) and the model returns reasoning content (DeepSeek-R1 / Kimi / MiMo / OpenAI reasoning models, Anthropic extended thinking, or inline `<think>` / `<thought>` tags). Models without reasoning produce zero `reasoning_delta` frames.
|
||||
|
||||
**`runtime_model_updated`** — broadcast when the gateway runtime model changes, for example after `/model <preset>`:
|
||||
|
||||
```json
|
||||
{
|
||||
"event": "runtime_model_updated",
|
||||
"model_name": "openai/gpt-4.1-mini",
|
||||
"model_preset": "fast"
|
||||
}
|
||||
```
|
||||
|
||||
`model_preset` is omitted when no named preset is active. WebUI clients use this event to keep the displayed model badge in sync across slash commands, config reloads, and settings changes.
|
||||
|
||||
**`attached`** — confirmation for `new_chat` / `attach` inbound envelopes (see [Multi-chat multiplexing](#multi-chat-multiplexing)):
|
||||
|
||||
```json
|
||||
{"event": "attached", "chat_id": "uuid-v4"}
|
||||
```
|
||||
|
||||
**`error`** — soft error for malformed inbound envelopes. The connection stays open:
|
||||
|
||||
```json
|
||||
{"event": "error", "detail": "invalid chat_id"}
|
||||
```
|
||||
|
||||
### Client → Server
|
||||
|
||||
**Legacy (default chat):** send a plain string, or a JSON object with a recognized text field:
|
||||
|
||||
```json
|
||||
"Hello nanobot!"
|
||||
```
|
||||
|
||||
```json
|
||||
{"content": "Hello nanobot!"}
|
||||
```
|
||||
|
||||
Recognized fields: `content`, `text`, `message` (checked in that order). Invalid JSON is treated as plain text. These frames route to the connection's default `chat_id` (the one announced in `ready`).
|
||||
|
||||
**Typed envelopes (multi-chat):** any JSON object with a string `type` field is a typed envelope:
|
||||
|
||||
| `type` | Fields | Effect |
|
||||
|--------|--------|--------|
|
||||
| `new_chat` | — | Server mints a new `chat_id`, subscribes this connection, replies with `attached`. |
|
||||
| `attach` | `chat_id` | Subscribe to an existing `chat_id` (e.g. after a page reload). Replies with `attached`. |
|
||||
| `message` | `chat_id`, `content` | Send `content` on `chat_id`. First use auto-attaches; no explicit `attach` needed. |
|
||||
|
||||
See [Multi-chat multiplexing](#multi-chat-multiplexing) for the full flow.
|
||||
|
||||
## Configuration Reference
|
||||
|
||||
All fields go under `channels.websocket` in `config.json`.
|
||||
|
||||
### Connection
|
||||
|
||||
| Field | Type | Default | Description |
|
||||
|-------|------|---------|-------------|
|
||||
| `enabled` | bool | `true` | Enable the WebSocket server. Set to `false` only when you intentionally do not want the bundled WebUI/WebSocket surface. |
|
||||
| `host` | string | `"127.0.0.1"` | Bind address. Use `"0.0.0.0"` to accept external connections. |
|
||||
| `port` | int | `8765` | Listen port. |
|
||||
| `path` | string | `"/"` | WebSocket upgrade path. Trailing slashes are normalized (root `/` is preserved). |
|
||||
| `maxMessageBytes` | int | `37748736` | Maximum inbound message size in bytes (1 KB – 40 MB). Default (36 MB) is sized to accept up to 4 base64-encoded image attachments at 8 MB each; lower it if the channel only carries text. |
|
||||
|
||||
### Authentication
|
||||
|
||||
| Field | Type | Default | Description |
|
||||
|-------|------|---------|-------------|
|
||||
| `token` | string | `""` | Static shared secret. When set, clients must provide `?token=<value>` matching this secret (timing-safe comparison). Issued tokens are also accepted as a fallback. |
|
||||
| `websocketRequiresToken` | bool | `true` | When `true` and no static `token` is configured, clients must still present a valid issued token. Set to `false` to allow unauthenticated connections (only safe for local/trusted networks). |
|
||||
| `tokenIssuePath` | string | `""` | HTTP path for issuing short-lived tokens. Must differ from `path`. See [Token Issuance](#token-issuance). |
|
||||
| `tokenIssueSecret` | string | `""` | Secret required to obtain tokens via the issue endpoint. If empty, any client can obtain WebSocket connection tokens from `tokenIssuePath` (logged as a warning). `/webui/bootstrap` still issues WebUI REST API tokens for same-machine localhost browser requests; remote or forwarded bootstrap requires `tokenIssueSecret` or `token`. |
|
||||
| `tokenTtlS` | int | `300` | Time-to-live for issued tokens in seconds (30 – 86,400). |
|
||||
|
||||
### Access Control
|
||||
|
||||
| Field | Type | Default | Description |
|
||||
|-------|------|---------|-------------|
|
||||
| `allowFrom` | list of string | `["*"]` | Allowed `client_id` values. `"*"` allows all; `[]` denies all. |
|
||||
|
||||
### Streaming
|
||||
|
||||
| Field | Type | Default | Description |
|
||||
|-------|------|---------|-------------|
|
||||
| `streaming` | bool | `true` | Enable streaming mode. The agent sends `delta` + `stream_end` frames instead of a single `message`. |
|
||||
|
||||
### Keep-alive
|
||||
|
||||
| Field | Type | Default | Description |
|
||||
|-------|------|---------|-------------|
|
||||
| `pingIntervalS` | float | `20.0` | WebSocket ping interval in seconds (5 – 300). |
|
||||
| `pingTimeoutS` | float | `20.0` | Time to wait for a pong before closing the connection (5 – 300). |
|
||||
|
||||
### TLS/SSL
|
||||
|
||||
| Field | Type | Default | Description |
|
||||
|-------|------|---------|-------------|
|
||||
| `sslCertfile` | string | `""` | Path to the TLS certificate file (PEM). Both `sslCertfile` and `sslKeyfile` must be set to enable WSS. |
|
||||
| `sslKeyfile` | string | `""` | Path to the TLS private key file (PEM). Minimum TLS version is enforced as TLSv1.2. |
|
||||
|
||||
## Token Issuance
|
||||
|
||||
For production deployments where `websocketRequiresToken: true`, use short-lived tokens instead of embedding static secrets in clients.
|
||||
|
||||
### How it works
|
||||
|
||||
1. Client sends `GET {tokenIssuePath}` with `Authorization: Bearer {tokenIssueSecret}` (or `X-Nanobot-Auth` header).
|
||||
2. Server responds with a one-time-use token:
|
||||
|
||||
```json
|
||||
{"token": "nbwt_aBcDeFg...", "expires_in": 300}
|
||||
```
|
||||
|
||||
3. Client opens WebSocket with `?token=nbwt_aBcDeFg...&client_id=...`.
|
||||
4. The token is consumed (single use) and cannot be reused.
|
||||
|
||||
The embedded WebUI's `/webui/bootstrap` route also returns a WebSocket token.
|
||||
It returns a separate `api_token` for REST routes to same-machine localhost
|
||||
browser requests, or after the request proves knowledge of `tokenIssueSecret`
|
||||
or the static `token`.
|
||||
|
||||
### Example setup
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"websocket": {
|
||||
"port": 8765,
|
||||
"path": "/ws",
|
||||
"tokenIssuePath": "/auth/token",
|
||||
"tokenIssueSecret": "your-secret-here",
|
||||
"tokenTtlS": 300,
|
||||
"websocketRequiresToken": true,
|
||||
"allowFrom": ["*"],
|
||||
"streaming": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Client flow:
|
||||
|
||||
```bash
|
||||
# 1. Obtain a token
|
||||
curl -H "Authorization: Bearer your-secret-here" http://127.0.0.1:8765/auth/token
|
||||
|
||||
# 2. Connect using the token
|
||||
websocat "ws://127.0.0.1:8765/ws?client_id=alice&token=nbwt_aBcDeFg..."
|
||||
```
|
||||
|
||||
### Limits
|
||||
|
||||
- Issued tokens are single-use — each token can only complete one handshake.
|
||||
- Outstanding tokens are capped at 10,000. Requests beyond this return HTTP 429.
|
||||
- Expired tokens are purged lazily on each issue or validation request.
|
||||
|
||||
## Multi-chat multiplexing
|
||||
|
||||
A single WebSocket can carry many concurrent chats. The server tracks `chat_id -> {connections}` as a fan-out set, so the same chat can also be mirrored across multiple connections (e.g. two browser tabs).
|
||||
|
||||
### Typical flow (web UI with a sidebar)
|
||||
|
||||
```text
|
||||
client server
|
||||
| --- connect --------------------> |
|
||||
| <-- {"event":"ready", |
|
||||
| "chat_id":"d3..."} (default)|
|
||||
| |
|
||||
| --- {"type":"new_chat"} ---------> |
|
||||
| <-- {"event":"attached", |
|
||||
| "chat_id":"a1..."} |
|
||||
| |
|
||||
| --- {"type":"message", |
|
||||
| "chat_id":"a1...", |
|
||||
| "content":"hi"} ------------> |
|
||||
| <-- {"event":"delta", ...} |
|
||||
| <-- {"event":"stream_end", ...} |
|
||||
| |
|
||||
| --- {"type":"attach", | # after page reload
|
||||
| "chat_id":"a1..."} ---------> |
|
||||
| <-- {"event":"attached", ...} |
|
||||
```
|
||||
|
||||
### Rules
|
||||
|
||||
- Every outbound event carries `chat_id`. Clients must dispatch by that field.
|
||||
- `chat_id` format: `^[A-Za-z0-9_:-]{1,64}$`. Non-matching values return `error`.
|
||||
- `message` auto-attaches on first use — no separate `attach` is required for chats the server minted (`new_chat`) on the same connection.
|
||||
- Errors (invalid envelope, unknown `type`, bad `chat_id`) are soft: the server replies with `{"event":"error","detail":"..."}` and keeps the connection open.
|
||||
|
||||
### Backward compatibility
|
||||
|
||||
Legacy clients that only send plain text or `{"content": ...}` keep working unchanged: those frames route to the connection's default `chat_id` (the one from `ready`). No config flag is needed.
|
||||
|
||||
### Security boundary
|
||||
|
||||
`chat_id` is a *capability*: anyone holding a valid WebSocket auth credential and the chat_id can attach to that conversation and see its output. This is safe for nanobot's local, single-user model. Multi-tenant deployments should namespace chat_ids per user (or introduce a per-tenant auth gate) — nanobot does not do this today.
|
||||
|
||||
## Security Notes
|
||||
|
||||
- **Timing-safe comparison**: Static token validation uses `hmac.compare_digest` to prevent timing attacks.
|
||||
- **Defense in depth**: `allowFrom` is checked at both the HTTP handshake level and the message level.
|
||||
- **chat_id as capability**: see [Multi-chat multiplexing](#multi-chat-multiplexing). Auth on the WebSocket handshake is the single line of defense; callers who pass it can attach to any chat_id they know.
|
||||
- **TLS enforcement**: When SSL is enabled, TLSv1.2 is the minimum allowed version.
|
||||
- **Default-secure**: `websocketRequiresToken` defaults to `true`. Explicitly set it to `false` only on trusted networks.
|
||||
|
||||
## Media Files
|
||||
|
||||
Outbound `message` events may include a `media` field containing local filesystem paths. Remote clients cannot access these files directly — they need either:
|
||||
|
||||
- A shared filesystem mount, or
|
||||
- An HTTP file server serving the nanobot media directory
|
||||
|
||||
## Common Patterns
|
||||
|
||||
### Trusted local network (no auth)
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"websocket": {
|
||||
"host": "0.0.0.0",
|
||||
"port": 8765,
|
||||
"websocketRequiresToken": false,
|
||||
"allowFrom": ["*"],
|
||||
"streaming": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Static token (simple auth)
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"websocket": {
|
||||
"token": "my-shared-secret",
|
||||
"allowFrom": ["alice", "bob"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Clients connect with `?token=my-shared-secret&client_id=alice`.
|
||||
|
||||
### Public endpoint with issued tokens
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"websocket": {
|
||||
"host": "0.0.0.0",
|
||||
"port": 8765,
|
||||
"path": "/ws",
|
||||
"tokenIssuePath": "/auth/token",
|
||||
"tokenIssueSecret": "production-secret",
|
||||
"websocketRequiresToken": true,
|
||||
"sslCertfile": "/etc/ssl/certs/server.pem",
|
||||
"sslKeyfile": "/etc/ssl/private/server-key.pem",
|
||||
"allowFrom": ["*"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Custom path
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"websocket": {
|
||||
"path": "/chat/ws",
|
||||
"allowFrom": ["*"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Clients connect to `ws://127.0.0.1:8765/chat/ws?client_id=...`. Trailing slashes are normalized, so `/chat/ws/` works the same.
|
||||
+265
@@ -0,0 +1,265 @@
|
||||
# Nanobot WebUI: Browser Workbench for Self-Hosted AI Agents
|
||||
|
||||
<!-- Meta description: Run nanobot from a browser WebUI with persistent chat sessions, visible tool activity, workspace controls, Apps, MCP presets, Skills, settings, and Automations. -->
|
||||
|
||||
The WebUI is nanobot's browser workbench for persistent chat sessions, visible
|
||||
agent activity, workspace controls, Apps, Skills, settings, and Automations in
|
||||
one place.
|
||||
|
||||
The published `nanobot-ai` wheel already includes the WebUI bundle. You only need
|
||||
the `webui/` source directory when you are changing the frontend itself.
|
||||
|
||||
## Open the WebUI
|
||||
|
||||
Use the launcher:
|
||||
|
||||
```bash
|
||||
nanobot webui
|
||||
```
|
||||
|
||||
`nanobot webui` creates the config/workspace when needed, checks provider setup,
|
||||
offers Quick Start when the model provider is not ready, enables the local
|
||||
WebSocket channel after confirmation, generates a WebUI bootstrap secret when
|
||||
one is missing, starts the gateway, and opens the browser. The first-run path
|
||||
binds the WebUI to `127.0.0.1` by default, so it is not available from other
|
||||
devices on your LAN.
|
||||
|
||||
Run it in the background when you do not want to keep a terminal open:
|
||||
|
||||
```bash
|
||||
nanobot webui --background
|
||||
```
|
||||
|
||||
Manage the background gateway with `nanobot gateway status`, `nanobot gateway
|
||||
logs`, `nanobot gateway restart`, and `nanobot gateway stop`.
|
||||
|
||||
Manual config still works. Same-machine localhost WebUI access can run without
|
||||
a browser password. Set `tokenIssueSecret` when you intentionally expose the
|
||||
WebUI beyond localhost or want a browser password:
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"websocket": {
|
||||
"enabled": true,
|
||||
"host": "127.0.0.1",
|
||||
"tokenIssueSecret": "your-webui-password",
|
||||
"websocketRequiresToken": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The WebUI is served by the WebSocket channel on port `8765` by default. The
|
||||
gateway health endpoint, `18790` by default, is not the browser UI.
|
||||
|
||||
## What It Is For
|
||||
|
||||
| Area | Use it for |
|
||||
|---|---|
|
||||
| Chat | Start, switch, search, fork, and delete browser sessions |
|
||||
| Agent activity | See thinking, tool calls, file edits with diffs, command output, and generated artifacts in context |
|
||||
| Workspace | Pick the project workspace before asking for file or shell work |
|
||||
| Access | Choose the access mode for local capabilities allowed by your gateway configuration |
|
||||
| Composer | Send text, images, voice input, slash commands, and `@` mentions for Apps or MCP presets |
|
||||
| Apps | Install, test, update, and use local CLI App adapters and MCP presets |
|
||||
| Skills | Inspect available built-in and workspace skills before relying on them |
|
||||
| Automations | Review, search, run, pause, edit, and delete scheduled and local-trigger agent turns |
|
||||
| Settings | Adjust models, providers, image generation, voice, web tools, runtime, and safety options |
|
||||
|
||||
## Chat Workspace
|
||||
|
||||
The sidebar is the session switcher. A session keeps its own history, title,
|
||||
workspace metadata, and linked automations. Use a new session when you want a
|
||||
separate context; use fork when you want to continue from an existing point
|
||||
without changing the original thread.
|
||||
|
||||
The message timeline shows both user-visible replies and agent activity. Long
|
||||
tool or reasoning sections can be expanded when you need the details.
|
||||
|
||||
When the agent writes or edits files, the activity item shows the target path,
|
||||
status, changed line counts, and, when available, a unified diff. Use **View
|
||||
diff** to expand the change; large diffs may hide unchanged lines or truncate the
|
||||
inline preview. Use **Open file** from a file edit to open the read-only file
|
||||
preview panel.
|
||||
|
||||
File previews follow the active session access mode. Restricted workspace access
|
||||
previews only files under the selected workspace. Full Access can preview files
|
||||
outside the workspace when that access mode is allowed by the gateway.
|
||||
|
||||
## Workspace and Access
|
||||
|
||||
Use the workspace picker before starting project-specific work. This gives the
|
||||
agent the right project context for file paths, shell commands, and session
|
||||
metadata.
|
||||
|
||||
The access control in the composer controls the local capability level for the
|
||||
chat. It does not bypass your gateway, provider, shell sandbox, or operating
|
||||
system configuration; it only selects among the capabilities that are already
|
||||
available to this WebUI session.
|
||||
|
||||
Remote WebUI sessions may reduce access for the current workspace. Selecting a
|
||||
different workspace or enabling Full Access remains limited to local and native
|
||||
clients.
|
||||
|
||||
## Composer
|
||||
|
||||
The composer supports plain messages, image attachments, voice input when
|
||||
transcription is configured, slash commands, and `@` mentions for installed Apps
|
||||
or MCP presets. The model badge shows the current model or preset and links back
|
||||
to model settings when setup is incomplete.
|
||||
|
||||
For image generation, configure an image provider first and then use the WebUI
|
||||
image mode from the composer. See [`image-generation.md`](./image-generation.md)
|
||||
for provider setup and output behavior.
|
||||
|
||||
## Apps
|
||||
|
||||
Open Apps from the sidebar or settings navigation to manage integrations that
|
||||
nanobot can call from a chat. Nanobot features can enable built-in channels and
|
||||
optional capabilities such as `bedrock` or `documents`. CLI Apps install local
|
||||
adapters that nanobot runs on your machine; they do not modify the native apps
|
||||
themselves. MCP presets add predefined MCP server configurations.
|
||||
|
||||
Enabling a Nanobot feature may install Python packages into the environment
|
||||
running nanobot. By default, the WebUI can install missing packages only when
|
||||
you open it on the same machine as nanobot. If you open the WebUI from another
|
||||
device, a domain name, a tunnel, or a reverse proxy, package install is blocked
|
||||
unless you explicitly allow it with `tools.webuiAllowRemotePackageInstall`.
|
||||
|
||||
Optional feature installs use your existing pip download settings. If PyPI is
|
||||
slow or unavailable from your network, configure pip or set `PIP_INDEX_URL`
|
||||
before starting nanobot.
|
||||
|
||||
Some MCP presets connect to hosted keyless endpoints. For example, the Firecrawl
|
||||
preset uses Firecrawl's hosted MCP endpoint for search, scrape, crawl, and
|
||||
extraction tools without requiring an API key. This does not replace nanobot's
|
||||
built-in web search provider; mention the Firecrawl MCP preset with `@` when a
|
||||
turn needs Firecrawl's richer web data tools.
|
||||
|
||||
After an App or MCP preset is available, mention it from the composer with `@`
|
||||
to attach that capability to the next message.
|
||||
|
||||
## Skills
|
||||
|
||||
The Skills view shows the skill instructions available to the agent, including
|
||||
built-in skills and workspace-provided skills. Check this view when you want to
|
||||
know whether nanobot already has a focused workflow for a task before you ask it
|
||||
to perform that task.
|
||||
|
||||
## Automations
|
||||
|
||||
Automations are agent turns that run later in a linked chat/session. They should
|
||||
be created from the chat, channel, or session where they are supposed to run so
|
||||
nanobot keeps the correct target context. When an automation runs, it normally
|
||||
delivers the result back to that linked chat.
|
||||
|
||||
For the full automation model, creation flow, trigger CLI usage, and delivery
|
||||
semantics, see [`automations.md`](./automations.md).
|
||||
|
||||
There are two user-facing automation types:
|
||||
|
||||
- Scheduled automations, created by the agent's cron tool, run at a time,
|
||||
interval, or cron expression.
|
||||
- Local triggers, created with `/trigger <name>`, run when you call a local
|
||||
command such as `nanobot trigger trg_8K4P2Q9X "Review PR #4502"`.
|
||||
|
||||
For recurring background checks that should stay quiet unless there is something
|
||||
useful to report, use the protected heartbeat job by editing `HEARTBEAT.md`
|
||||
instead of creating a chat automation.
|
||||
|
||||
Use the Automations view to:
|
||||
|
||||
- Filter by all, active, paused, needs-attention, or system jobs.
|
||||
- Search by task name, message, trigger command, linked chat, schedule, or status.
|
||||
- Sort by next run, last run, updated time, or name.
|
||||
- Run scheduled automations now.
|
||||
- Pause or resume, rename, or delete user-created automations.
|
||||
- Copy the CLI command for local triggers.
|
||||
- Inspect protected system automations without changing them.
|
||||
|
||||
Search accepts plain text and field filters such as `name:backup`,
|
||||
`chat:WeChat`, `schedule:09:30`, `cron:"0 23 * * *"`, `trigger`, and
|
||||
`status:paused`.
|
||||
|
||||
An automation without a linked chat cannot be enabled or run from the WebUI,
|
||||
because nanobot would not know where to deliver the scheduled turn. Recreate it
|
||||
from the target chat or channel so the automation has complete context.
|
||||
|
||||
Local triggers do not have a WebUI "Run now" action because each run needs a
|
||||
message. Use the copied `nanobot trigger ...` command and replace `"message"`
|
||||
with the content that should be delivered.
|
||||
|
||||
## Settings
|
||||
|
||||
Settings is the control surface for the browser session and gateway-backed
|
||||
runtime configuration. Use it to review or adjust model presets, provider
|
||||
visibility, image generation, voice transcription, web tools, Apps, Automations,
|
||||
Skills, runtime identity, and advanced safety controls.
|
||||
|
||||
Some settings take effect immediately. Runtime settings that affect the gateway
|
||||
or agent process may require a restart; the WebUI shows that requirement next to
|
||||
the relevant control.
|
||||
|
||||
Browser-only display preferences, such as file edit display mode, take effect
|
||||
immediately for the current browser and do not change gateway configuration.
|
||||
|
||||
## LAN Access
|
||||
|
||||
To open the WebUI from another device on the same network, bind the WebSocket
|
||||
channel to all interfaces and set a token or token issue secret:
|
||||
|
||||
```json
|
||||
{
|
||||
"channels": {
|
||||
"websocket": {
|
||||
"host": "0.0.0.0",
|
||||
"port": 8765,
|
||||
"tokenIssueSecret": "your-secret-here"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The gateway refuses to start with `host` set to `"0.0.0.0"` unless `token` or
|
||||
`tokenIssueSecret` is configured. After the gateway starts, open
|
||||
`http://<your-ip>:8765` from the other device and enter the secret in the login
|
||||
form.
|
||||
|
||||
Remote WebUI clients can view Apps and toggle already-installed features with a
|
||||
valid token, but they cannot install missing Python packages by default. To allow
|
||||
trusted remote admins to install optional feature dependencies from the WebUI,
|
||||
opt in explicitly:
|
||||
|
||||
```json
|
||||
{
|
||||
"tools": {
|
||||
"webuiAllowRemotePackageInstall": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Use this only for a private deployment where every authenticated WebUI user is
|
||||
trusted to change the Python environment that nanobot runs in. If you publish
|
||||
the WebUI through Nginx, Caddy, Cloudflare Tunnel, or a similar service, treat it
|
||||
as remote access and leave package installs disabled unless that is intentional.
|
||||
|
||||
Optional feature installs use pip's configured package index, including
|
||||
`PIP_INDEX_URL`.
|
||||
|
||||
Leave remote package installs disabled when the WebUI is exposed beyond a
|
||||
private, trusted network.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
If the page does not open, check these in order:
|
||||
|
||||
1. `nanobot agent -m "Hello!"` works in the same Python environment.
|
||||
2. `~/.nanobot/config.json` does not explicitly set `channels.websocket.enabled` to `false`.
|
||||
3. `nanobot gateway` is still running.
|
||||
4. You are opening port `8765`, not the gateway health port.
|
||||
5. LAN access uses `host: "0.0.0.0"` and a token or token issue secret.
|
||||
|
||||
For detailed diagnostics, see
|
||||
[`troubleshooting.md#webui-problems`](./troubleshooting.md#webui-problems).
|
||||
For frontend development, see [`../webui/README.md`](../webui/README.md).
|
||||
Executable
+15
@@ -0,0 +1,15 @@
|
||||
#!/bin/sh
|
||||
dir="$HOME/.nanobot"
|
||||
if [ -d "$dir" ] && [ ! -w "$dir" ]; then
|
||||
owner_uid=$(stat -c %u "$dir" 2>/dev/null || stat -f %u "$dir" 2>/dev/null)
|
||||
cat >&2 <<EOF
|
||||
Error: $dir is not writable (owned by UID $owner_uid, running as UID $(id -u)).
|
||||
|
||||
Fix (pick one):
|
||||
Host: sudo chown -R 1000:1000 ~/.nanobot
|
||||
Docker: docker run --user \$(id -u):\$(id -g) ...
|
||||
Podman: podman run --userns=keep-id ...
|
||||
EOF
|
||||
exit 1
|
||||
fi
|
||||
exec nanobot "$@"
|
||||
+101
@@ -0,0 +1,101 @@
|
||||
"""Hatch build hook that bundles the webui (Vite) into nanobot/web/dist.
|
||||
|
||||
Triggered automatically by `python -m build` (and any other hatch-driven build)
|
||||
so published wheels and sdists ship a fresh webui without requiring developers
|
||||
to remember `cd webui && bun run build` beforehand.
|
||||
|
||||
Behaviour:
|
||||
|
||||
- Skips for editable installs (`pip install -e .`). Editable mode is for Python
|
||||
development; webui contributors use `cd webui && bun run dev` (Vite HMR) and
|
||||
do not need a packaged `dist/`.
|
||||
- No-op when `webui/package.json` is absent (e.g. installing from an sdist that
|
||||
already contains a prebuilt `nanobot/web/dist/`).
|
||||
- Skips when `NANOBOT_SKIP_WEBUI_BUILD=1` is set.
|
||||
- Skips when `nanobot/web/dist/index.html` already exists, unless
|
||||
`NANOBOT_FORCE_WEBUI_BUILD=1` is set.
|
||||
- Uses `bun` when available, otherwise falls back to `npm`. The chosen tool
|
||||
performs `install` followed by `run build`.
|
||||
"""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
import os
|
||||
import shutil
|
||||
import subprocess
|
||||
from pathlib import Path
|
||||
|
||||
from hatchling.builders.hooks.plugin.interface import BuildHookInterface
|
||||
|
||||
|
||||
class WebUIBuildHook(BuildHookInterface):
|
||||
PLUGIN_NAME = "webui-build"
|
||||
|
||||
def initialize(self, version: str, build_data: dict) -> None: # noqa: D401
|
||||
root = Path(self.root)
|
||||
webui_dir = root / "webui"
|
||||
package_json = webui_dir / "package.json"
|
||||
dist_dir = root / "nanobot" / "web" / "dist"
|
||||
index_html = dist_dir / "index.html"
|
||||
|
||||
# `pip install -e .` builds an editable wheel; skip the (slow) webui
|
||||
# bundle since editable installs target Python development and webui
|
||||
# work uses `bun run dev` instead.
|
||||
if self.target_name == "wheel" and version == "editable":
|
||||
self.app.display_info(
|
||||
"[webui-build] skipped for editable install "
|
||||
"(use `cd webui && bun run build` to bundle webui manually)"
|
||||
)
|
||||
return
|
||||
|
||||
if os.environ.get("NANOBOT_SKIP_WEBUI_BUILD") == "1":
|
||||
self.app.display_info("[webui-build] skipped via NANOBOT_SKIP_WEBUI_BUILD=1")
|
||||
return
|
||||
|
||||
if not package_json.is_file():
|
||||
self.app.display_info(
|
||||
"[webui-build] no webui/ source tree, assuming prebuilt nanobot/web/dist/"
|
||||
)
|
||||
return
|
||||
|
||||
force = os.environ.get("NANOBOT_FORCE_WEBUI_BUILD") == "1"
|
||||
if index_html.is_file() and not force:
|
||||
self.app.display_info(
|
||||
f"[webui-build] reusing existing build at {dist_dir} "
|
||||
"(set NANOBOT_FORCE_WEBUI_BUILD=1 to rebuild)"
|
||||
)
|
||||
return
|
||||
|
||||
runner = self._pick_runner()
|
||||
if runner is None:
|
||||
raise RuntimeError(
|
||||
"[webui-build] neither `bun` nor `npm` is available on PATH; "
|
||||
"install one or set NANOBOT_SKIP_WEBUI_BUILD=1 to bypass."
|
||||
)
|
||||
|
||||
self.app.display_info(f"[webui-build] using {runner} to build webui")
|
||||
self._run([runner, "install"], cwd=webui_dir)
|
||||
self._run([runner, "run", "build"], cwd=webui_dir)
|
||||
|
||||
if not index_html.is_file():
|
||||
raise RuntimeError(
|
||||
f"[webui-build] build finished but {index_html} is missing; "
|
||||
"check webui/vite.config.ts outDir."
|
||||
)
|
||||
self.app.display_info(f"[webui-build] webui ready at {dist_dir}")
|
||||
|
||||
@staticmethod
|
||||
def _pick_runner() -> str | None:
|
||||
for candidate in ("bun", "npm"):
|
||||
if shutil.which(candidate):
|
||||
return candidate
|
||||
return None
|
||||
|
||||
def _run(self, cmd: list[str], *, cwd: Path) -> None:
|
||||
self.app.display_info(f"[webui-build] $ {' '.join(cmd)} (cwd={cwd})")
|
||||
try:
|
||||
subprocess.run(cmd, cwd=cwd, check=True)
|
||||
except subprocess.CalledProcessError as exc:
|
||||
raise RuntimeError(
|
||||
f"[webui-build] command failed ({exc.returncode}): {' '.join(cmd)}"
|
||||
) from exc
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 490 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 187 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 287 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 67 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 83 KiB |
@@ -0,0 +1,83 @@
|
||||
"""
|
||||
nanobot - A lightweight AI agent framework
|
||||
"""
|
||||
|
||||
import tomllib
|
||||
from importlib.metadata import PackageNotFoundError
|
||||
from importlib.metadata import version as _pkg_version
|
||||
from pathlib import Path
|
||||
|
||||
|
||||
def _read_pyproject_version() -> str | None:
|
||||
"""Read the source-tree version when package metadata is unavailable."""
|
||||
pyproject = Path(__file__).resolve().parent.parent / "pyproject.toml"
|
||||
if not pyproject.exists():
|
||||
return None
|
||||
data = tomllib.loads(pyproject.read_text(encoding="utf-8"))
|
||||
return data.get("project", {}).get("version")
|
||||
|
||||
|
||||
def _resolve_version() -> str:
|
||||
try:
|
||||
return _pkg_version("nanobot-ai")
|
||||
except PackageNotFoundError:
|
||||
# Source checkouts often import nanobot without installed dist-info.
|
||||
return _read_pyproject_version() or "0.2.2"
|
||||
|
||||
|
||||
__version__ = _resolve_version()
|
||||
__logo__ = "🐈"
|
||||
|
||||
_LAZY_EXPORTS = {
|
||||
"Nanobot": ".nanobot",
|
||||
"RunStream": ".nanobot",
|
||||
"RunResult": ".nanobot",
|
||||
"SessionInfo": ".nanobot",
|
||||
"SessionSnapshot": ".nanobot",
|
||||
"STREAM_EVENT_REASONING_COMPLETED": ".nanobot",
|
||||
"STREAM_EVENT_REASONING_DELTA": ".nanobot",
|
||||
"STREAM_EVENT_RUN_COMPLETED": ".nanobot",
|
||||
"STREAM_EVENT_RUN_FAILED": ".nanobot",
|
||||
"STREAM_EVENT_RUN_STARTED": ".nanobot",
|
||||
"STREAM_EVENT_TEXT_COMPLETED": ".nanobot",
|
||||
"STREAM_EVENT_TEXT_DELTA": ".nanobot",
|
||||
"STREAM_EVENT_TOOL_COMPLETED": ".nanobot",
|
||||
"STREAM_EVENT_TOOL_FAILED": ".nanobot",
|
||||
"STREAM_EVENT_TOOL_STARTED": ".nanobot",
|
||||
"STREAM_EVENT_TYPES": ".nanobot",
|
||||
"StreamEvent": ".nanobot",
|
||||
"StreamEventType": ".nanobot",
|
||||
}
|
||||
|
||||
|
||||
def __getattr__(name: str):
|
||||
module_path = _LAZY_EXPORTS.get(name)
|
||||
if module_path is None:
|
||||
raise AttributeError(f"module {__name__!r} has no attribute {name!r}")
|
||||
from importlib import import_module
|
||||
mod = import_module(module_path, __name__)
|
||||
val = getattr(mod, name)
|
||||
globals()[name] = val
|
||||
return val
|
||||
|
||||
|
||||
__all__ = [
|
||||
"Nanobot",
|
||||
"RunResult",
|
||||
"RunStream",
|
||||
"SessionInfo",
|
||||
"SessionSnapshot",
|
||||
"STREAM_EVENT_REASONING_COMPLETED",
|
||||
"STREAM_EVENT_REASONING_DELTA",
|
||||
"STREAM_EVENT_RUN_COMPLETED",
|
||||
"STREAM_EVENT_RUN_FAILED",
|
||||
"STREAM_EVENT_RUN_STARTED",
|
||||
"STREAM_EVENT_TEXT_COMPLETED",
|
||||
"STREAM_EVENT_TEXT_DELTA",
|
||||
"STREAM_EVENT_TOOL_COMPLETED",
|
||||
"STREAM_EVENT_TOOL_FAILED",
|
||||
"STREAM_EVENT_TOOL_STARTED",
|
||||
"STREAM_EVENT_TYPES",
|
||||
"StreamEvent",
|
||||
"StreamEventType",
|
||||
]
|
||||
@@ -0,0 +1,8 @@
|
||||
"""
|
||||
Entry point for running nanobot as a module: python -m nanobot
|
||||
"""
|
||||
|
||||
from nanobot.cli.commands import app
|
||||
|
||||
if __name__ == "__main__":
|
||||
app()
|
||||
@@ -0,0 +1,29 @@
|
||||
"""Agent core module."""
|
||||
|
||||
from nanobot.agent.context import ContextBuilder
|
||||
from nanobot.agent.hook import (
|
||||
AgentHook,
|
||||
AgentHookContext,
|
||||
AgentRunHookContext,
|
||||
AgentTurnHookContext,
|
||||
AgentTurnHookFactory,
|
||||
CompositeHook,
|
||||
)
|
||||
from nanobot.agent.loop import AgentLoop
|
||||
from nanobot.agent.memory import MemoryStore
|
||||
from nanobot.agent.skills import SkillsLoader
|
||||
from nanobot.agent.subagent import SubagentManager
|
||||
|
||||
__all__ = [
|
||||
"AgentHook",
|
||||
"AgentHookContext",
|
||||
"AgentRunHookContext",
|
||||
"AgentTurnHookContext",
|
||||
"AgentTurnHookFactory",
|
||||
"AgentLoop",
|
||||
"CompositeHook",
|
||||
"ContextBuilder",
|
||||
"MemoryStore",
|
||||
"SkillsLoader",
|
||||
"SubagentManager",
|
||||
]
|
||||
@@ -0,0 +1,125 @@
|
||||
"""Auto compact: proactive compression of idle sessions to reduce token cost and latency."""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
from collections.abc import Collection
|
||||
from datetime import datetime
|
||||
from typing import TYPE_CHECKING, Callable, Coroutine
|
||||
|
||||
from loguru import logger
|
||||
|
||||
from nanobot.session.manager import Session, SessionManager
|
||||
|
||||
if TYPE_CHECKING:
|
||||
from nanobot.agent.memory import Consolidator
|
||||
from nanobot.utils.llm_runtime import LLMRuntime
|
||||
|
||||
|
||||
class AutoCompact:
|
||||
_RECENT_SUFFIX_MESSAGES = 8
|
||||
_INTERNAL_SESSION_PREFIXES = ("dream:",)
|
||||
|
||||
def __init__(self, sessions: SessionManager, consolidator: Consolidator,
|
||||
session_ttl_minutes: int = 0):
|
||||
self.sessions = sessions
|
||||
self.consolidator = consolidator
|
||||
self._ttl = session_ttl_minutes
|
||||
self._archiving: set[str] = set()
|
||||
self._summaries: dict[str, tuple[str, datetime]] = {}
|
||||
|
||||
def _is_expired(self, ts: datetime | str | None,
|
||||
now: datetime | None = None) -> bool:
|
||||
if self._ttl <= 0 or not ts:
|
||||
return False
|
||||
if isinstance(ts, str):
|
||||
ts = datetime.fromisoformat(ts)
|
||||
return ((now or datetime.now()) - ts).total_seconds() >= self._ttl * 60
|
||||
|
||||
def _has_compactable_idle_tail(self, key: str) -> bool:
|
||||
session = self.sessions.get_or_create(key)
|
||||
tail = list(session.messages[session.last_consolidated:])
|
||||
if not tail:
|
||||
return False
|
||||
probe = Session(
|
||||
key=session.key,
|
||||
messages=tail,
|
||||
created_at=session.created_at,
|
||||
updated_at=session.updated_at,
|
||||
metadata={},
|
||||
last_consolidated=0,
|
||||
)
|
||||
result = probe.retain_recent_legal_suffix(
|
||||
self._RECENT_SUFFIX_MESSAGES,
|
||||
extend_to_user=True,
|
||||
)
|
||||
messages_to_remove = result.dropped[result.already_consolidated_count:]
|
||||
return bool(messages_to_remove)
|
||||
|
||||
@staticmethod
|
||||
def _format_summary(text: str, last_active: datetime) -> str:
|
||||
return f"Previous conversation summary (last active {last_active.isoformat()}):\n{text}"
|
||||
|
||||
@classmethod
|
||||
def _is_internal_session(cls, key: str) -> bool:
|
||||
return key.startswith(cls._INTERNAL_SESSION_PREFIXES)
|
||||
|
||||
def check_expired(
|
||||
self,
|
||||
schedule_background: Callable[[Coroutine], None],
|
||||
resolve_runtime: Callable[[], LLMRuntime],
|
||||
active_session_keys: Collection[str] = (),
|
||||
) -> None:
|
||||
"""Schedule archival for idle sessions, skipping those with in-flight agent tasks."""
|
||||
now = datetime.now()
|
||||
for info in self.sessions.list_sessions():
|
||||
key = info.get("key", "")
|
||||
if not key or self._is_internal_session(key) or key in self._archiving:
|
||||
continue
|
||||
if key in active_session_keys:
|
||||
continue
|
||||
updated_at = info.get("updated_at")
|
||||
if self._is_expired(updated_at, now) and self._has_compactable_idle_tail(key):
|
||||
runtime = resolve_runtime()
|
||||
self._archiving.add(key)
|
||||
schedule_background(self._archive(key, runtime=runtime))
|
||||
|
||||
async def _archive(self, key: str, *, runtime: LLMRuntime) -> None:
|
||||
if self._is_internal_session(key):
|
||||
self._archiving.discard(key)
|
||||
return
|
||||
try:
|
||||
summary = await self.consolidator.compact_idle_session(
|
||||
key,
|
||||
runtime=runtime,
|
||||
max_suffix=self._RECENT_SUFFIX_MESSAGES,
|
||||
)
|
||||
if summary and summary != "(nothing)":
|
||||
session = self.sessions.get_or_create(key)
|
||||
meta = session.metadata.get("_last_summary")
|
||||
if isinstance(meta, dict):
|
||||
self._summaries[key] = (
|
||||
meta["text"],
|
||||
datetime.fromisoformat(meta["last_active"]),
|
||||
)
|
||||
except Exception:
|
||||
logger.exception("Auto-compact: failed for {}", key)
|
||||
finally:
|
||||
self._archiving.discard(key)
|
||||
|
||||
def prepare_session(self, session: Session, key: str) -> tuple[Session, str | None]:
|
||||
if self._is_internal_session(key):
|
||||
self._archiving.discard(key)
|
||||
self._summaries.pop(key, None)
|
||||
return session, None
|
||||
if key in self._archiving or self._is_expired(session.updated_at):
|
||||
logger.info("Auto-compact: reloading session {} (archiving={})", key, key in self._archiving)
|
||||
session = self.sessions.get_or_create(key)
|
||||
# Hot path: summary from in-memory dict (process hasn't restarted).
|
||||
entry = self._summaries.pop(key, None)
|
||||
if entry:
|
||||
return session, self._format_summary(entry[0], entry[1])
|
||||
# Cold path: summary persisted in session metadata (process restarted).
|
||||
meta = session.metadata.get("_last_summary")
|
||||
if isinstance(meta, dict):
|
||||
return session, self._format_summary(meta["text"], datetime.fromisoformat(meta["last_active"]))
|
||||
return session, None
|
||||
@@ -0,0 +1,149 @@
|
||||
"""Shared coordination for session-bound automation turns."""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
import asyncio
|
||||
import dataclasses
|
||||
from collections.abc import Awaitable, Callable, Iterable
|
||||
|
||||
from nanobot.bus.events import InboundMessage, OutboundMessage
|
||||
|
||||
|
||||
class AutomationTurnError(RuntimeError):
|
||||
"""Raised when an automation turn reaches the agent and finishes with an error."""
|
||||
|
||||
|
||||
async def publish_next_deferred_turn(
|
||||
*,
|
||||
deferred_queues: dict[str, list[InboundMessage]],
|
||||
publish_inbound: Callable[[InboundMessage], Awaitable[None]],
|
||||
session_key: str,
|
||||
) -> bool:
|
||||
"""Publish the next deferred automation turn for a session."""
|
||||
queue = deferred_queues.get(session_key)
|
||||
if not queue:
|
||||
return False
|
||||
msg = queue.pop(0)
|
||||
if not queue:
|
||||
deferred_queues.pop(session_key, None)
|
||||
await publish_inbound(msg)
|
||||
return True
|
||||
|
||||
|
||||
class AutomationTurnCoordinator:
|
||||
"""Manage automation turns without mixing them into live injections."""
|
||||
|
||||
def __init__(
|
||||
self,
|
||||
*,
|
||||
publish_inbound: Callable[[InboundMessage], Awaitable[None]],
|
||||
dispatch: Callable[[InboundMessage], Awaitable[object]],
|
||||
is_running: Callable[[], bool],
|
||||
turn_id: Callable[[InboundMessage], str | None],
|
||||
pending_id: Callable[[InboundMessage], str | None],
|
||||
should_defer_turn: Callable[[InboundMessage, str, Iterable[str]], bool],
|
||||
missing_id_error: str,
|
||||
duplicate_id_error: Callable[[str], str],
|
||||
deferred_queues: dict[str, list[InboundMessage]] | None = None,
|
||||
) -> None:
|
||||
self._publish_inbound = publish_inbound
|
||||
self._dispatch = dispatch
|
||||
self._is_running = is_running
|
||||
self._turn_id = turn_id
|
||||
self._pending_id = pending_id
|
||||
self._should_defer_turn = should_defer_turn
|
||||
self._missing_id_error = missing_id_error
|
||||
self._duplicate_id_error = duplicate_id_error
|
||||
self.deferred_queues = deferred_queues if deferred_queues is not None else {}
|
||||
self._waiters: dict[str, asyncio.Future[OutboundMessage | None]] = {}
|
||||
self._pending_messages_by_turn_id: dict[str, InboundMessage] = {}
|
||||
|
||||
async def submit(self, msg: InboundMessage) -> OutboundMessage | None:
|
||||
"""Submit an automation turn and wait for its session response."""
|
||||
turn_id = self._turn_id(msg)
|
||||
if not turn_id:
|
||||
raise ValueError(self._missing_id_error)
|
||||
if turn_id in self._waiters:
|
||||
raise RuntimeError(self._duplicate_id_error(turn_id))
|
||||
|
||||
loop = asyncio.get_running_loop()
|
||||
future: asyncio.Future[OutboundMessage | None] = loop.create_future()
|
||||
self._waiters[turn_id] = future
|
||||
self._pending_messages_by_turn_id[turn_id] = msg
|
||||
try:
|
||||
if self._is_running():
|
||||
await self._publish_inbound(msg)
|
||||
else:
|
||||
await self._dispatch(msg)
|
||||
try:
|
||||
return await future
|
||||
except asyncio.CancelledError:
|
||||
raise
|
||||
except AutomationTurnError:
|
||||
raise
|
||||
except Exception as exc:
|
||||
raise AutomationTurnError(str(exc) or exc.__class__.__name__) from exc
|
||||
finally:
|
||||
self._waiters.pop(turn_id, None)
|
||||
self._pending_messages_by_turn_id.pop(turn_id, None)
|
||||
|
||||
def defer_if_active(
|
||||
self,
|
||||
msg: InboundMessage,
|
||||
*,
|
||||
session_key: str,
|
||||
active_session_keys: Iterable[str],
|
||||
) -> bool:
|
||||
"""Defer an automation turn when its target session is already active."""
|
||||
if not self._should_defer_turn(msg, session_key, active_session_keys):
|
||||
return False
|
||||
pending_msg = msg
|
||||
if session_key != msg.session_key:
|
||||
pending_msg = dataclasses.replace(
|
||||
msg,
|
||||
session_key_override=session_key,
|
||||
)
|
||||
self.deferred_queues.setdefault(session_key, []).append(pending_msg)
|
||||
return True
|
||||
|
||||
def complete(
|
||||
self,
|
||||
msg: InboundMessage,
|
||||
*,
|
||||
response: OutboundMessage | None = None,
|
||||
error: BaseException | None = None,
|
||||
) -> None:
|
||||
turn_id = self._turn_id(msg)
|
||||
if not turn_id:
|
||||
return
|
||||
future = self._waiters.get(turn_id)
|
||||
if future is None or future.done():
|
||||
return
|
||||
if error is not None:
|
||||
if isinstance(error, asyncio.CancelledError):
|
||||
error = AutomationTurnError(str(error) or error.__class__.__name__)
|
||||
future.set_exception(error)
|
||||
else:
|
||||
future.set_result(response)
|
||||
|
||||
def pending_ids_for_session(self, session_key: str) -> set[str]:
|
||||
"""Return automation IDs that are waiting for or running in *session_key*."""
|
||||
pending_ids: set[str] = set()
|
||||
for msg in self.deferred_queues.get(session_key, []):
|
||||
pending_id = self._pending_id(msg)
|
||||
if pending_id:
|
||||
pending_ids.add(pending_id)
|
||||
for msg in self._pending_messages_by_turn_id.values():
|
||||
if msg.session_key != session_key:
|
||||
continue
|
||||
pending_id = self._pending_id(msg)
|
||||
if pending_id:
|
||||
pending_ids.add(pending_id)
|
||||
return pending_ids
|
||||
|
||||
async def publish_next_deferred(self, session_key: str) -> bool:
|
||||
return await publish_next_deferred_turn(
|
||||
deferred_queues=self.deferred_queues,
|
||||
publish_inbound=self._publish_inbound,
|
||||
session_key=session_key,
|
||||
)
|
||||
@@ -0,0 +1,245 @@
|
||||
"""Context builder for assembling agent prompts."""
|
||||
|
||||
import base64
|
||||
import mimetypes
|
||||
import platform
|
||||
from pathlib import Path
|
||||
from typing import Any, Mapping, Sequence
|
||||
|
||||
from nanobot.agent.memory import MemoryStore
|
||||
from nanobot.agent.skills import SkillsLoader
|
||||
from nanobot.agent.tools import mcp as mcp_tools
|
||||
from nanobot.agent.tools.registry import ToolRegistry
|
||||
from nanobot.apps.cli import utils as cli_app_utils
|
||||
from nanobot.bus.events import InboundMessage
|
||||
from nanobot.runtime_context import (
|
||||
RUNTIME_CONTEXT_END,
|
||||
RUNTIME_CONTEXT_MESSAGE_META,
|
||||
RUNTIME_CONTEXT_TAG,
|
||||
RuntimeContextBlock,
|
||||
append_runtime_context,
|
||||
)
|
||||
from nanobot.utils.helpers import (
|
||||
detect_image_mime,
|
||||
load_bundled_template,
|
||||
truncate_text_to_tokens,
|
||||
)
|
||||
from nanobot.utils.prompt_templates import render_template
|
||||
|
||||
|
||||
def session_extra(metadata: Mapping[str, Any] | None) -> dict[str, Any]:
|
||||
"""Return persisted kwargs for turn-attached capabilities."""
|
||||
return cli_app_utils.session_extra(metadata) | mcp_tools.session_extra(metadata)
|
||||
|
||||
|
||||
async def connect_mcp(state: Any, tools: ToolRegistry) -> None:
|
||||
await mcp_tools.connect_missing_servers(state, tools)
|
||||
|
||||
|
||||
async def close_mcp(state: Any) -> None:
|
||||
await mcp_tools.close_mcp_servers(state)
|
||||
|
||||
|
||||
async def handle_runtime_control(state: Any, msg: InboundMessage, tools: ToolRegistry) -> bool:
|
||||
return await mcp_tools.handle_runtime_control(state, msg, tools)
|
||||
|
||||
|
||||
class ContextBuilder:
|
||||
"""Builds the context (system prompt + messages) for the agent."""
|
||||
|
||||
BOOTSTRAP_FILES = ["AGENTS.md", "SOUL.md", "USER.md"]
|
||||
_RUNTIME_CONTEXT_TAG = RUNTIME_CONTEXT_TAG
|
||||
_MAX_RECENT_HISTORY = 50
|
||||
_MAX_HISTORY_TOKENS = 8_000 # hard cap on recent history section size (tokens)
|
||||
_RUNTIME_CONTEXT_END = RUNTIME_CONTEXT_END
|
||||
|
||||
def __init__(self, workspace: Path, timezone: str | None = None, disabled_skills: list[str] | None = None):
|
||||
self.workspace = workspace
|
||||
self.timezone = timezone
|
||||
self.memory = MemoryStore(workspace)
|
||||
self.skills = SkillsLoader(workspace, disabled_skills=set(disabled_skills) if disabled_skills else None)
|
||||
|
||||
def build_system_prompt(
|
||||
self,
|
||||
skill_names: list[str] | None = None,
|
||||
channel: str | None = None,
|
||||
session_summary: str | None = None,
|
||||
workspace: Path | None = None,
|
||||
include_memory_recent_history: bool = True,
|
||||
session_key: str | None = None,
|
||||
unified_session: bool = False,
|
||||
) -> str:
|
||||
"""Build the system prompt from identity, bootstrap files, memory, and skills."""
|
||||
root = workspace or self.workspace
|
||||
parts = [self._get_identity(channel=channel, workspace=root)]
|
||||
|
||||
bootstrap = self._load_bootstrap_files(root)
|
||||
if bootstrap:
|
||||
parts.append(bootstrap)
|
||||
|
||||
parts.append(render_template("agent/tool_contract.md"))
|
||||
|
||||
memory = self.memory.get_memory_context()
|
||||
if memory and not self._is_template_content(self.memory.read_memory(), "memory/MEMORY.md"):
|
||||
parts.append(f"# Memory\n\n{memory}")
|
||||
|
||||
always_skills = self.skills.get_always_skills()
|
||||
if always_skills:
|
||||
always_content = self.skills.load_skills_for_context(always_skills)
|
||||
if always_content:
|
||||
parts.append(f"# Active Skills\n\n{always_content}")
|
||||
|
||||
skills_summary = self.skills.build_skills_summary(exclude=set(always_skills))
|
||||
if skills_summary:
|
||||
parts.append(render_template("agent/skills_section.md", skills_summary=skills_summary))
|
||||
|
||||
if include_memory_recent_history:
|
||||
entries = self.memory.read_recent_history_for_prompt(
|
||||
since_cursor=self.memory.get_last_dream_cursor(),
|
||||
session_key=session_key,
|
||||
unified_session=unified_session,
|
||||
)
|
||||
if entries:
|
||||
capped = entries[-self._MAX_RECENT_HISTORY:]
|
||||
history_text = "\n".join(
|
||||
f"- [{e['timestamp']}] {e['content']}" for e in capped
|
||||
)
|
||||
history_text = truncate_text_to_tokens(history_text, self._MAX_HISTORY_TOKENS)
|
||||
parts.append("# Recent History\n\n" + history_text)
|
||||
|
||||
if session_summary:
|
||||
parts.append(f"[Archived Context Summary]\n\n{session_summary}")
|
||||
|
||||
return "\n\n---\n\n".join(parts)
|
||||
|
||||
def _get_identity(self, channel: str | None = None, workspace: Path | None = None) -> str:
|
||||
"""Get the core identity section."""
|
||||
root = workspace or self.workspace
|
||||
workspace_path = str(root.expanduser().resolve())
|
||||
system = platform.system()
|
||||
runtime = f"{'macOS' if system == 'Darwin' else system} {platform.machine()}, Python {platform.python_version()}"
|
||||
|
||||
return render_template(
|
||||
"agent/identity.md",
|
||||
workspace_path=workspace_path,
|
||||
runtime=runtime,
|
||||
platform_policy=render_template("agent/platform_policy.md", system=system),
|
||||
channel=channel or "",
|
||||
)
|
||||
|
||||
@staticmethod
|
||||
def _merge_message_content(left: Any, right: Any) -> str | list[dict[str, Any]]:
|
||||
if isinstance(left, str) and isinstance(right, str):
|
||||
if not left:
|
||||
return right
|
||||
if not right:
|
||||
return left
|
||||
return f"{left}\n\n{right}"
|
||||
|
||||
def _to_blocks(value: Any) -> list[dict[str, Any]]:
|
||||
if isinstance(value, list):
|
||||
return [item if isinstance(item, dict) else {"type": "text", "text": str(item)} for item in value]
|
||||
if value is None:
|
||||
return []
|
||||
return [{"type": "text", "text": str(value)}]
|
||||
|
||||
return _to_blocks(left) + _to_blocks(right)
|
||||
|
||||
def _load_bootstrap_files(self, workspace: Path | None = None) -> str:
|
||||
"""Load all bootstrap files from workspace."""
|
||||
parts = []
|
||||
root = workspace or self.workspace
|
||||
|
||||
for filename in self.BOOTSTRAP_FILES:
|
||||
file_path = root / filename
|
||||
if file_path.exists():
|
||||
content = file_path.read_text(encoding="utf-8")
|
||||
parts.append(f"## {filename}\n\n{content}")
|
||||
|
||||
return "\n\n".join(parts) if parts else ""
|
||||
|
||||
@staticmethod
|
||||
def _is_template_content(content: str, template_path: str) -> bool:
|
||||
"""Check if *content* is identical to the bundled template (user hasn't customized it)."""
|
||||
tpl = load_bundled_template(template_path)
|
||||
if tpl is not None:
|
||||
return content.strip() == tpl.strip()
|
||||
return False
|
||||
|
||||
def build_messages(
|
||||
self,
|
||||
history: list[dict[str, Any]],
|
||||
current_message: str,
|
||||
skill_names: list[str] | None = None,
|
||||
media: list[str] | None = None,
|
||||
channel: str | None = None,
|
||||
chat_id: str | None = None,
|
||||
current_role: str = "user",
|
||||
sender_id: str | None = None,
|
||||
session_summary: str | None = None,
|
||||
session_metadata: Mapping[str, Any] | None = None,
|
||||
runtime_context_blocks: Sequence[RuntimeContextBlock] | None = None,
|
||||
workspace: Path | None = None,
|
||||
include_memory_recent_history: bool = True,
|
||||
session_key: str | None = None,
|
||||
unified_session: bool = False,
|
||||
) -> list[dict[str, Any]]:
|
||||
"""Build the complete message list for an LLM call."""
|
||||
root = workspace or self.workspace
|
||||
user_content = self._build_user_content(current_message, media)
|
||||
blocks = list(runtime_context_blocks or ()) if current_role == "user" else []
|
||||
merged, runtime_context_meta = append_runtime_context(user_content, blocks)
|
||||
messages = [
|
||||
{
|
||||
"role": "system",
|
||||
"content": self.build_system_prompt(
|
||||
skill_names,
|
||||
channel=channel,
|
||||
session_summary=session_summary,
|
||||
workspace=root,
|
||||
include_memory_recent_history=include_memory_recent_history,
|
||||
session_key=session_key,
|
||||
unified_session=unified_session,
|
||||
),
|
||||
},
|
||||
*history,
|
||||
]
|
||||
if messages[-1].get("role") == current_role:
|
||||
last = dict(messages[-1])
|
||||
last["content"] = self._merge_message_content(last.get("content"), merged)
|
||||
if current_role == "user" and runtime_context_meta is not None:
|
||||
internal_meta = dict(last.get("_meta") or {})
|
||||
internal_meta[RUNTIME_CONTEXT_MESSAGE_META] = runtime_context_meta
|
||||
last["_meta"] = internal_meta
|
||||
messages[-1] = last
|
||||
return messages
|
||||
current = {"role": current_role, "content": merged}
|
||||
if current_role == "user" and runtime_context_meta is not None:
|
||||
current["_meta"] = {RUNTIME_CONTEXT_MESSAGE_META: runtime_context_meta}
|
||||
messages.append(current)
|
||||
return messages
|
||||
|
||||
def _build_user_content(self, text: str, media: list[str] | None) -> str | list[dict[str, Any]]:
|
||||
"""Build user message content with optional base64-encoded images."""
|
||||
if not media:
|
||||
return text
|
||||
|
||||
images = []
|
||||
for path in media:
|
||||
p = Path(path)
|
||||
if not p.is_file():
|
||||
continue
|
||||
raw = p.read_bytes()
|
||||
mime = detect_image_mime(raw) or mimetypes.guess_type(path)[0]
|
||||
if not mime or not mime.startswith("image/"):
|
||||
continue
|
||||
b64 = base64.b64encode(raw).decode()
|
||||
images.append({
|
||||
"type": "image_url",
|
||||
"image_url": {"url": f"data:{mime};base64,{b64}"},
|
||||
"_meta": {"path": str(p)},
|
||||
})
|
||||
|
||||
if not images:
|
||||
return text
|
||||
return images + [{"type": "text", "text": text}]
|
||||
@@ -0,0 +1,503 @@
|
||||
"""Model-message governance for agent runner requests.
|
||||
|
||||
This module owns model-facing message shaping and tool-result content normalization.
|
||||
It may return copied messages or persisted-result placeholders, but it must not
|
||||
mutate an existing session history list in place.
|
||||
"""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
from dataclasses import dataclass
|
||||
from pathlib import Path
|
||||
from typing import TYPE_CHECKING, Any
|
||||
|
||||
from loguru import logger
|
||||
|
||||
from nanobot.utils.helpers import (
|
||||
estimate_message_tokens,
|
||||
estimate_prompt_tokens_chain,
|
||||
find_legal_message_start,
|
||||
maybe_persist_tool_result,
|
||||
truncate_text,
|
||||
)
|
||||
from nanobot.utils.runtime import ensure_nonempty_tool_result
|
||||
|
||||
if TYPE_CHECKING:
|
||||
from nanobot.providers.base import LLMProvider
|
||||
|
||||
SNIP_SAFETY_BUFFER = 1024
|
||||
MICROCOMPACT_KEEP_RECENT = 10
|
||||
MICROCOMPACT_MIN_CHARS = 500
|
||||
INFLIGHT_COMPACT_TARGET_RATIO = 0.85
|
||||
COMPACTABLE_TOOLS = frozenset({
|
||||
"read_file", "exec", "grep", "find_files",
|
||||
"web_search", "web_fetch", "list_dir", "list_exec_sessions",
|
||||
})
|
||||
# read_file is the recovery path for persisted results; exempting it prevents persist->read->persist loops.
|
||||
TOOL_RESULT_OFFLOAD_EXEMPT_TOOLS = frozenset({"read_file"})
|
||||
BACKFILL_CONTENT = "[Tool result unavailable — call was interrupted or lost]"
|
||||
PLACEHOLDER_TEXTS = frozenset({
|
||||
"[Previous assistant message omitted.]",
|
||||
})
|
||||
|
||||
|
||||
def _tool_call_name_is_valid(tool_call: Any) -> bool:
|
||||
"""Whether a persisted OpenAI-style tool_call carries a usable name.
|
||||
|
||||
Mirrors ``ToolCallRequest.has_valid_name`` for the dict shape stored in
|
||||
message history: a degenerate call with ``name=None`` / ``""`` cannot be
|
||||
executed and is rejected by upstream APIs if replayed.
|
||||
"""
|
||||
if not isinstance(tool_call, dict):
|
||||
return False
|
||||
fn = tool_call.get("function")
|
||||
name = fn.get("name") if isinstance(fn, dict) else tool_call.get("name")
|
||||
return isinstance(name, str) and bool(name)
|
||||
|
||||
|
||||
@dataclass(slots=True)
|
||||
class ContextGovernanceConfig:
|
||||
provider: LLMProvider
|
||||
model: str
|
||||
tools: Any
|
||||
workspace: Path | None
|
||||
session_key: str | None
|
||||
max_tool_result_chars: int
|
||||
context_window_tokens: int | None = None
|
||||
context_block_limit: int | None = None
|
||||
max_tokens: int | None = None
|
||||
inflight_start_index: int = 0
|
||||
|
||||
|
||||
class ContextGovernor:
|
||||
"""Prepare model-copy messages while preserving persisted history."""
|
||||
|
||||
def prepare_for_model(
|
||||
self,
|
||||
config: ContextGovernanceConfig,
|
||||
messages: list[dict[str, Any]],
|
||||
compacted_tool_call_ids: set[str],
|
||||
) -> list[dict[str, Any]]:
|
||||
updated = self.strip_placeholder_assistant_messages(messages)
|
||||
updated = self.strip_malformed_tool_calls(updated)
|
||||
updated = self.drop_orphan_tool_results(updated)
|
||||
updated = self.backfill_missing_tool_results(updated)
|
||||
updated = self.apply_tool_result_budget(config, updated)
|
||||
updated = self.compact_inflight_overflow(config, updated, compacted_tool_call_ids)
|
||||
updated = self.snip_history(config, updated)
|
||||
updated = self.drop_orphan_tool_results(updated)
|
||||
return self.backfill_missing_tool_results(updated)
|
||||
|
||||
@staticmethod
|
||||
def input_budget(config: ContextGovernanceConfig) -> int:
|
||||
if not config.context_window_tokens:
|
||||
return 0
|
||||
|
||||
provider_max_tokens = getattr(
|
||||
getattr(config.provider, "generation", None),
|
||||
"max_tokens",
|
||||
4096,
|
||||
)
|
||||
max_output = config.max_tokens if isinstance(config.max_tokens, int) else (
|
||||
provider_max_tokens if isinstance(provider_max_tokens, int) else 4096
|
||||
)
|
||||
budget = config.context_block_limit or (
|
||||
config.context_window_tokens - max_output - SNIP_SAFETY_BUFFER
|
||||
)
|
||||
return budget if budget > 0 else 0
|
||||
|
||||
@staticmethod
|
||||
def normalize_tool_result(
|
||||
config: ContextGovernanceConfig,
|
||||
tool_call_id: str,
|
||||
tool_name: str,
|
||||
result: Any,
|
||||
) -> Any:
|
||||
result = ensure_nonempty_tool_result(tool_name, result)
|
||||
if tool_name in TOOL_RESULT_OFFLOAD_EXEMPT_TOOLS:
|
||||
return result
|
||||
try:
|
||||
content = maybe_persist_tool_result(
|
||||
config.workspace,
|
||||
config.session_key,
|
||||
tool_call_id,
|
||||
result,
|
||||
max_chars=config.max_tool_result_chars,
|
||||
)
|
||||
except Exception:
|
||||
logger.exception(
|
||||
"Tool result persist failed for {} in {}; using raw result",
|
||||
tool_call_id,
|
||||
config.session_key or "default",
|
||||
)
|
||||
content = result
|
||||
if isinstance(content, str) and len(content) > config.max_tool_result_chars:
|
||||
return truncate_text(content, config.max_tool_result_chars)
|
||||
return content
|
||||
|
||||
@staticmethod
|
||||
def strip_placeholder_assistant_messages(
|
||||
messages: list[dict[str, Any]],
|
||||
) -> list[dict[str, Any]]:
|
||||
"""Remove assistant messages that are compaction placeholders.
|
||||
|
||||
Messages like ``[Previous assistant message omitted.]`` carry no useful
|
||||
context for the model and can cause it to repeatedly attempt tool calls
|
||||
that previously failed, producing malformed responses in a loop.
|
||||
Consecutive same-role messages that result from removal are handled
|
||||
downstream by the provider's merge-consecutive logic. Only the
|
||||
model-facing copy is repaired; the persisted transcript is untouched
|
||||
(a copy is returned, or the same list object when nothing changes).
|
||||
"""
|
||||
updated: list[dict[str, Any]] | None = None
|
||||
for idx, msg in enumerate(messages):
|
||||
if msg.get("role") != "assistant":
|
||||
if updated is not None:
|
||||
updated.append(msg)
|
||||
continue
|
||||
content = msg.get("content", "")
|
||||
text = content if isinstance(content, str) else ""
|
||||
is_placeholder = text.strip() in PLACEHOLDER_TEXTS
|
||||
has_tool_calls = bool(msg.get("tool_calls"))
|
||||
if is_placeholder and not has_tool_calls:
|
||||
if updated is None:
|
||||
updated = list(messages[:idx])
|
||||
logger.debug(
|
||||
"Stripping placeholder assistant message from history: {!r}",
|
||||
text[:60],
|
||||
)
|
||||
continue
|
||||
if updated is not None:
|
||||
updated.append(msg)
|
||||
if updated is None:
|
||||
return messages
|
||||
return updated
|
||||
|
||||
@staticmethod
|
||||
def strip_malformed_tool_calls(
|
||||
messages: list[dict[str, Any]],
|
||||
) -> list[dict[str, Any]]:
|
||||
"""Drop persisted assistant tool_calls whose name is missing/non-string.
|
||||
|
||||
A degenerate tool call (``name=None`` or ``""``) that slipped into the
|
||||
saved history before this guard existed gets replayed on every turn and
|
||||
makes upstream APIs reject the whole request
|
||||
(``messages.content.N.tool_use.name: Input should be a valid string``),
|
||||
permanently wedging the session. Removing the bad call here lets the
|
||||
existing orphan-result cleanup drop its now-dangling tool result, so a
|
||||
polluted session self-heals on its next turn. The persisted transcript
|
||||
is left untouched; only the model-facing copy is repaired (a copy is
|
||||
returned, or the same list object when nothing changes).
|
||||
"""
|
||||
updated: list[dict[str, Any]] | None = None
|
||||
for idx, msg in enumerate(messages):
|
||||
if msg.get("role") != "assistant":
|
||||
if updated is not None:
|
||||
updated.append(msg)
|
||||
continue
|
||||
calls = msg.get("tool_calls")
|
||||
if not calls:
|
||||
if updated is not None:
|
||||
updated.append(msg)
|
||||
continue
|
||||
kept = [tc for tc in calls if _tool_call_name_is_valid(tc)]
|
||||
if len(kept) == len(calls):
|
||||
if updated is not None:
|
||||
updated.append(msg)
|
||||
continue
|
||||
if updated is None:
|
||||
updated = [dict(m) for m in messages[:idx]]
|
||||
logger.warning(
|
||||
"Stripping {} malformed tool_call(s) with missing/non-string "
|
||||
"name from assistant history before request",
|
||||
len(calls) - len(kept),
|
||||
)
|
||||
repaired = dict(msg)
|
||||
if kept:
|
||||
repaired["tool_calls"] = kept
|
||||
else:
|
||||
repaired.pop("tool_calls", None)
|
||||
# An assistant turn with neither content nor any valid tool call is
|
||||
# itself invalid upstream; drop it entirely in that case.
|
||||
has_content = bool(repaired.get("content"))
|
||||
if not kept and not has_content:
|
||||
continue
|
||||
updated.append(repaired)
|
||||
|
||||
if updated is None:
|
||||
return messages
|
||||
return updated
|
||||
|
||||
@staticmethod
|
||||
def drop_orphan_tool_results(
|
||||
messages: list[dict[str, Any]],
|
||||
) -> list[dict[str, Any]]:
|
||||
"""Drop tool results that have no matching assistant tool_call earlier in history."""
|
||||
declared: set[str] = set()
|
||||
updated: list[dict[str, Any]] | None = None
|
||||
for idx, msg in enumerate(messages):
|
||||
role = msg.get("role")
|
||||
if role == "assistant":
|
||||
for tc in msg.get("tool_calls") or []:
|
||||
if isinstance(tc, dict) and tc.get("id"):
|
||||
declared.add(str(tc["id"]))
|
||||
if role == "tool":
|
||||
tid = msg.get("tool_call_id")
|
||||
if tid and str(tid) not in declared:
|
||||
if updated is None:
|
||||
updated = [dict(m) for m in messages[:idx]]
|
||||
continue
|
||||
if updated is not None:
|
||||
updated.append(dict(msg))
|
||||
|
||||
if updated is None:
|
||||
return messages
|
||||
return updated
|
||||
|
||||
@staticmethod
|
||||
def backfill_missing_tool_results(
|
||||
messages: list[dict[str, Any]],
|
||||
) -> list[dict[str, Any]]:
|
||||
"""Insert synthetic error results for assistant tool_calls with missing tool outputs."""
|
||||
declared: list[tuple[int, str, str]] = []
|
||||
fulfilled: set[str] = set()
|
||||
for idx, msg in enumerate(messages):
|
||||
role = msg.get("role")
|
||||
if role == "assistant":
|
||||
for tc in msg.get("tool_calls") or []:
|
||||
if isinstance(tc, dict) and tc.get("id"):
|
||||
name = ""
|
||||
func = tc.get("function")
|
||||
if isinstance(func, dict):
|
||||
name = func.get("name", "")
|
||||
declared.append((idx, str(tc["id"]), name))
|
||||
elif role == "tool":
|
||||
tid = msg.get("tool_call_id")
|
||||
if tid:
|
||||
fulfilled.add(str(tid))
|
||||
|
||||
missing = [(ai, cid, name) for ai, cid, name in declared if cid not in fulfilled]
|
||||
if not missing:
|
||||
return messages
|
||||
|
||||
updated = list(messages)
|
||||
offset = 0
|
||||
for assistant_idx, call_id, name in missing:
|
||||
insert_at = assistant_idx + 1 + offset
|
||||
while insert_at < len(updated) and updated[insert_at].get("role") == "tool":
|
||||
insert_at += 1
|
||||
updated.insert(insert_at, {
|
||||
"role": "tool",
|
||||
"tool_call_id": call_id,
|
||||
"name": name,
|
||||
"content": BACKFILL_CONTENT,
|
||||
})
|
||||
offset += 1
|
||||
return updated
|
||||
|
||||
def apply_tool_result_budget(
|
||||
self,
|
||||
config: ContextGovernanceConfig,
|
||||
messages: list[dict[str, Any]],
|
||||
) -> list[dict[str, Any]]:
|
||||
updated = messages
|
||||
for idx, message in enumerate(messages):
|
||||
if message.get("role") != "tool":
|
||||
continue
|
||||
normalized = self.normalize_tool_result(
|
||||
config,
|
||||
str(message.get("tool_call_id") or f"tool_{idx}"),
|
||||
str(message.get("name") or "tool"),
|
||||
message.get("content"),
|
||||
)
|
||||
if normalized != message.get("content"):
|
||||
if updated is messages:
|
||||
updated = [dict(m) for m in messages]
|
||||
updated[idx]["content"] = normalized
|
||||
return updated
|
||||
|
||||
def compact_inflight_overflow(
|
||||
self,
|
||||
config: ContextGovernanceConfig,
|
||||
messages: list[dict[str, Any]],
|
||||
compacted_tool_call_ids: set[str],
|
||||
) -> list[dict[str, Any]]:
|
||||
"""Compact in-flight tool results only when the request would overflow."""
|
||||
budget = self.input_budget(config)
|
||||
if budget <= 0:
|
||||
return messages
|
||||
|
||||
tools = config.tools.get_definitions()
|
||||
updated = self._apply_recorded_compactions(messages, compacted_tool_call_ids)
|
||||
estimate, source = estimate_prompt_tokens_chain(
|
||||
config.provider,
|
||||
config.model,
|
||||
updated,
|
||||
tools,
|
||||
)
|
||||
if estimate <= budget:
|
||||
return updated
|
||||
|
||||
target = int(budget * INFLIGHT_COMPACT_TARGET_RATIO)
|
||||
candidates = self._inflight_compaction_candidates(
|
||||
config,
|
||||
updated,
|
||||
compacted_tool_call_ids,
|
||||
)
|
||||
if not candidates:
|
||||
return updated
|
||||
|
||||
for candidate_idx, (idx, tool_call_id) in enumerate(candidates):
|
||||
is_newest_candidate = candidate_idx == len(candidates) - 1
|
||||
if is_newest_candidate and estimate <= budget:
|
||||
break
|
||||
if tool_call_id in compacted_tool_call_ids:
|
||||
continue
|
||||
if updated is messages:
|
||||
updated = [dict(m) for m in messages]
|
||||
compacted_tool_call_ids.add(tool_call_id)
|
||||
self._compact_tool_result_at(updated, idx)
|
||||
estimate, source = estimate_prompt_tokens_chain(
|
||||
config.provider,
|
||||
config.model,
|
||||
updated,
|
||||
tools,
|
||||
)
|
||||
if estimate <= target:
|
||||
break
|
||||
|
||||
logger.debug(
|
||||
"In-flight context compaction for {}: prompt={} budget={} target={} via {}, ids={}",
|
||||
config.session_key or "default",
|
||||
estimate,
|
||||
budget,
|
||||
target,
|
||||
source,
|
||||
len(compacted_tool_call_ids),
|
||||
)
|
||||
return updated
|
||||
|
||||
def snip_history(
|
||||
self,
|
||||
config: ContextGovernanceConfig,
|
||||
messages: list[dict[str, Any]],
|
||||
) -> list[dict[str, Any]]:
|
||||
if not messages or not config.context_window_tokens:
|
||||
return messages
|
||||
|
||||
budget = self.input_budget(config)
|
||||
if budget <= 0:
|
||||
return messages
|
||||
|
||||
tools = config.tools.get_definitions()
|
||||
estimate, _ = estimate_prompt_tokens_chain(
|
||||
config.provider,
|
||||
config.model,
|
||||
messages,
|
||||
tools,
|
||||
)
|
||||
if estimate <= budget:
|
||||
return messages
|
||||
|
||||
system_messages = [dict(msg) for msg in messages if msg.get("role") == "system"]
|
||||
non_system = [dict(msg) for msg in messages if msg.get("role") != "system"]
|
||||
if not non_system:
|
||||
return messages
|
||||
|
||||
system_tokens = sum(estimate_message_tokens(msg) for msg in system_messages)
|
||||
fixed_tokens, _ = estimate_prompt_tokens_chain(
|
||||
config.provider,
|
||||
config.model,
|
||||
system_messages,
|
||||
tools,
|
||||
)
|
||||
remaining_budget = max(0, budget - max(system_tokens, fixed_tokens))
|
||||
kept: list[dict[str, Any]] = []
|
||||
kept_tokens = 0
|
||||
for message in reversed(non_system):
|
||||
msg_tokens = estimate_message_tokens(message)
|
||||
if kept and kept_tokens + msg_tokens > remaining_budget:
|
||||
break
|
||||
kept.append(message)
|
||||
kept_tokens += msg_tokens
|
||||
kept.reverse()
|
||||
|
||||
return system_messages + self._legal_history_tail(kept, non_system)
|
||||
|
||||
@staticmethod
|
||||
def _summary_for(message: dict[str, Any]) -> str:
|
||||
name = message.get("name", "tool")
|
||||
return f"[Prior {name} result compacted to fit context; the tool call already completed.]"
|
||||
|
||||
def _legal_history_tail(
|
||||
self,
|
||||
kept: list[dict[str, Any]],
|
||||
non_system: list[dict[str, Any]],
|
||||
) -> list[dict[str, Any]]:
|
||||
fallback = kept if kept else (non_system[-1:] if non_system else [])
|
||||
kept = self._user_tail(kept) or self._user_tail(non_system, last=True) or fallback
|
||||
|
||||
start = find_legal_message_start(kept)
|
||||
return kept[start:] if start else kept
|
||||
|
||||
@staticmethod
|
||||
def _user_tail(messages: list[dict[str, Any]], *, last: bool = False) -> list[dict[str, Any]]:
|
||||
indexes = range(len(messages) - 1, -1, -1) if last else range(len(messages))
|
||||
for idx in indexes:
|
||||
if messages[idx].get("role") == "user":
|
||||
return messages[idx:]
|
||||
return []
|
||||
|
||||
def _apply_recorded_compactions(
|
||||
self,
|
||||
messages: list[dict[str, Any]],
|
||||
compacted_tool_call_ids: set[str],
|
||||
) -> list[dict[str, Any]]:
|
||||
if not compacted_tool_call_ids:
|
||||
return messages
|
||||
updated = messages
|
||||
for idx, msg in enumerate(messages):
|
||||
if msg.get("role") != "tool":
|
||||
continue
|
||||
tool_call_id = msg.get("tool_call_id")
|
||||
if not tool_call_id or str(tool_call_id) not in compacted_tool_call_ids:
|
||||
continue
|
||||
summary = self._summary_for(msg)
|
||||
if msg.get("content") == summary:
|
||||
continue
|
||||
if updated is messages:
|
||||
updated = [dict(m) for m in messages]
|
||||
updated[idx]["content"] = summary
|
||||
return updated
|
||||
|
||||
def _inflight_compaction_candidates(
|
||||
self,
|
||||
config: ContextGovernanceConfig,
|
||||
messages: list[dict[str, Any]],
|
||||
compacted_tool_call_ids: set[str],
|
||||
) -> list[tuple[int, str]]:
|
||||
compactable: list[tuple[int, str]] = []
|
||||
for idx, msg in enumerate(messages):
|
||||
if idx < config.inflight_start_index:
|
||||
continue
|
||||
if msg.get("role") != "tool" or msg.get("name") not in COMPACTABLE_TOOLS:
|
||||
continue
|
||||
tool_call_id = msg.get("tool_call_id")
|
||||
if not tool_call_id or str(tool_call_id) in compacted_tool_call_ids:
|
||||
continue
|
||||
content = msg.get("content")
|
||||
if not isinstance(content, str) or len(content) < MICROCOMPACT_MIN_CHARS:
|
||||
continue
|
||||
compactable.append((idx, str(tool_call_id)))
|
||||
|
||||
if not compactable:
|
||||
return []
|
||||
primary_count = max(0, len(compactable) - MICROCOMPACT_KEEP_RECENT)
|
||||
primary = compactable[:primary_count]
|
||||
# Hard overflow beats the keep-recent preference. Return recent results
|
||||
# after stale ones so the newest result is naturally last.
|
||||
fallback = compactable[primary_count:]
|
||||
return primary + fallback
|
||||
|
||||
def _compact_tool_result_at(self, messages: list[dict[str, Any]], idx: int) -> None:
|
||||
messages[idx]["content"] = self._summary_for(messages[idx])
|
||||
@@ -0,0 +1,57 @@
|
||||
"""Coordination for scheduled cron turns."""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
from collections.abc import Awaitable, Callable, Iterable
|
||||
|
||||
from nanobot.agent.automation_turns import AutomationTurnCoordinator
|
||||
from nanobot.bus.events import InboundMessage
|
||||
from nanobot.cron.session_turns import (
|
||||
cron_run_id,
|
||||
cron_trigger,
|
||||
defer_cron_until_session_idle,
|
||||
)
|
||||
|
||||
|
||||
class CronTurnCoordinator(AutomationTurnCoordinator):
|
||||
"""Manage scheduled cron turns without mixing them into live injections."""
|
||||
|
||||
def __init__(
|
||||
self,
|
||||
*,
|
||||
publish_inbound: Callable[[InboundMessage], Awaitable[None]],
|
||||
dispatch: Callable[[InboundMessage], Awaitable[object]],
|
||||
is_running: Callable[[], bool],
|
||||
deferred_queues: dict[str, list[InboundMessage]] | None = None,
|
||||
) -> None:
|
||||
super().__init__(
|
||||
publish_inbound=publish_inbound,
|
||||
dispatch=dispatch,
|
||||
is_running=is_running,
|
||||
turn_id=lambda msg: cron_run_id(msg.metadata),
|
||||
pending_id=_cron_job_id,
|
||||
should_defer_turn=_should_defer_cron_turn,
|
||||
missing_id_error="cron turn metadata must include a run_id",
|
||||
duplicate_id_error=lambda run_id: f"cron run {run_id!r} is already pending",
|
||||
deferred_queues=deferred_queues,
|
||||
)
|
||||
|
||||
def pending_job_ids_for_session(self, session_key: str) -> set[str]:
|
||||
"""Return cron jobs that are waiting for or running in *session_key*."""
|
||||
return self.pending_ids_for_session(session_key)
|
||||
|
||||
|
||||
def _should_defer_cron_turn(
|
||||
msg: InboundMessage,
|
||||
session_key: str,
|
||||
active_session_keys: Iterable[str],
|
||||
) -> bool:
|
||||
return defer_cron_until_session_idle(msg.metadata) and session_key in active_session_keys
|
||||
|
||||
|
||||
def _cron_job_id(msg: InboundMessage) -> str | None:
|
||||
trigger = cron_trigger(msg.metadata)
|
||||
if not trigger:
|
||||
return None
|
||||
value = trigger.get("job_id")
|
||||
return value if isinstance(value, str) and value else None
|
||||
@@ -0,0 +1,29 @@
|
||||
"""Turn-local permission for explicit sustained-goal mutations."""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
from contextlib import contextmanager
|
||||
from contextvars import ContextVar
|
||||
|
||||
_GOAL_MUTATION_ALLOWED: ContextVar[bool] = ContextVar(
|
||||
"nanobot_goal_mutation_allowed",
|
||||
default=False,
|
||||
)
|
||||
|
||||
|
||||
def goal_mutation_allowed() -> bool:
|
||||
return _GOAL_MUTATION_ALLOWED.get()
|
||||
|
||||
|
||||
def revoke_goal_mutation_permission() -> None:
|
||||
_GOAL_MUTATION_ALLOWED.set(False)
|
||||
|
||||
|
||||
@contextmanager
|
||||
def goal_mutation_permission(allowed: bool):
|
||||
"""Bind goal permission for one agent-run or direct tool execution scope."""
|
||||
token = _GOAL_MUTATION_ALLOWED.set(allowed)
|
||||
try:
|
||||
yield
|
||||
finally:
|
||||
_GOAL_MUTATION_ALLOWED.reset(token)
|
||||
@@ -0,0 +1,292 @@
|
||||
"""Shared lifecycle hook primitives for agent runs."""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
from collections.abc import Awaitable, Callable
|
||||
from dataclasses import dataclass, field
|
||||
from pathlib import Path
|
||||
from typing import Any
|
||||
|
||||
from loguru import logger
|
||||
|
||||
from nanobot.providers.base import LLMResponse, ToolCallRequest
|
||||
|
||||
|
||||
@dataclass(slots=True)
|
||||
class AgentHookContext:
|
||||
"""Mutable per-iteration state exposed to runner hooks."""
|
||||
|
||||
iteration: int
|
||||
messages: list[dict[str, Any]]
|
||||
response: LLMResponse | None = None
|
||||
usage: dict[str, int] = field(default_factory=dict)
|
||||
tool_calls: list[ToolCallRequest] = field(default_factory=list)
|
||||
tool_results: list[Any] = field(default_factory=list)
|
||||
tool_events: list[dict[str, str]] = field(default_factory=list)
|
||||
streamed_content: bool = False
|
||||
streamed_reasoning: bool = False
|
||||
final_content: str | None = None
|
||||
stop_reason: str | None = None
|
||||
error: str | None = None
|
||||
session_key: str | None = None
|
||||
|
||||
|
||||
@dataclass(slots=True)
|
||||
class AgentRunHookContext:
|
||||
"""Run-level state snapshot exposed to runner hooks."""
|
||||
|
||||
messages: list[dict[str, Any]]
|
||||
final_content: str | None = None
|
||||
tools_used: list[str] = field(default_factory=list)
|
||||
usage: dict[str, int] = field(default_factory=dict)
|
||||
stop_reason: str | None = None
|
||||
error: str | None = None
|
||||
tool_events: list[dict[str, str]] = field(default_factory=list)
|
||||
had_injections: bool = False
|
||||
exception: BaseException | None = None
|
||||
|
||||
|
||||
@dataclass(slots=True)
|
||||
class AgentTurnHookContext:
|
||||
"""Turn-local inputs available when constructing per-turn hooks."""
|
||||
|
||||
on_progress: Callable[..., Awaitable[None]] | None = None
|
||||
workspace: Path | None = None
|
||||
channel: str = "cli"
|
||||
chat_id: str = "direct"
|
||||
message_id: str | None = None
|
||||
session_key: str | None = None
|
||||
metadata: dict[str, Any] = field(default_factory=dict)
|
||||
ephemeral: bool = False
|
||||
|
||||
|
||||
class AgentHook:
|
||||
"""Minimal lifecycle surface for shared runner customization."""
|
||||
|
||||
def __init__(self, reraise: bool = False) -> None:
|
||||
self._reraise = reraise
|
||||
|
||||
def wants_streaming(self) -> bool:
|
||||
return False
|
||||
|
||||
async def before_run(self, context: AgentRunHookContext) -> None:
|
||||
pass
|
||||
|
||||
async def after_run(self, context: AgentRunHookContext) -> None:
|
||||
pass
|
||||
|
||||
async def on_error(self, context: AgentRunHookContext) -> None:
|
||||
pass
|
||||
|
||||
async def on_finally(self, context: AgentRunHookContext) -> None:
|
||||
pass
|
||||
|
||||
async def before_iteration(self, context: AgentHookContext) -> None:
|
||||
pass
|
||||
|
||||
async def on_stream(self, context: AgentHookContext, delta: str) -> None:
|
||||
pass
|
||||
|
||||
async def on_stream_end(self, context: AgentHookContext, *, resuming: bool) -> None:
|
||||
pass
|
||||
|
||||
async def before_execute_tools(self, context: AgentHookContext) -> None:
|
||||
pass
|
||||
|
||||
async def before_execute_tool(
|
||||
self,
|
||||
context: AgentHookContext,
|
||||
tool_call: ToolCallRequest,
|
||||
tool: Any,
|
||||
params: Any,
|
||||
) -> None:
|
||||
pass
|
||||
|
||||
async def after_execute_tool(
|
||||
self,
|
||||
context: AgentHookContext,
|
||||
tool_call: ToolCallRequest,
|
||||
tool: Any,
|
||||
params: Any,
|
||||
result: Any,
|
||||
) -> None:
|
||||
pass
|
||||
|
||||
async def on_execute_tool_error(
|
||||
self,
|
||||
context: AgentHookContext,
|
||||
tool_call: ToolCallRequest,
|
||||
tool: Any,
|
||||
params: Any,
|
||||
error: Any,
|
||||
) -> None:
|
||||
pass
|
||||
|
||||
async def emit_reasoning(self, reasoning_content: str | None) -> None:
|
||||
pass
|
||||
|
||||
async def emit_reasoning_end(self) -> None:
|
||||
"""Mark the end of an in-flight reasoning stream.
|
||||
|
||||
Hooks that buffer ``emit_reasoning`` chunks (for in-place UI updates)
|
||||
flush and freeze the rendered group here. One-shot hooks ignore.
|
||||
"""
|
||||
pass
|
||||
|
||||
async def after_iteration(self, context: AgentHookContext) -> None:
|
||||
pass
|
||||
|
||||
def finalize_content(self, context: AgentHookContext, content: str | None) -> str | None:
|
||||
return content
|
||||
|
||||
|
||||
AgentTurnHookFactory = Callable[[AgentTurnHookContext], AgentHook | None]
|
||||
|
||||
|
||||
class CompositeHook(AgentHook):
|
||||
"""Fan-out hook that delegates to an ordered list of hooks.
|
||||
|
||||
Error isolation: async methods catch and log per-hook exceptions
|
||||
so a faulty custom hook cannot crash the agent loop.
|
||||
``finalize_content`` is a pipeline (no isolation — bugs should surface).
|
||||
"""
|
||||
|
||||
__slots__ = ("_hooks",)
|
||||
|
||||
def __init__(self, hooks: list[AgentHook]) -> None:
|
||||
super().__init__()
|
||||
self._hooks = list(hooks)
|
||||
|
||||
def wants_streaming(self) -> bool:
|
||||
return any(h.wants_streaming() for h in self._hooks)
|
||||
|
||||
async def _for_each_hook_safe(self, method_name: str, *args: Any, **kwargs: Any) -> None:
|
||||
for h in self._hooks:
|
||||
if getattr(h, "_reraise", False):
|
||||
await getattr(h, method_name)(*args, **kwargs)
|
||||
continue
|
||||
|
||||
try:
|
||||
await getattr(h, method_name)(*args, **kwargs)
|
||||
except Exception:
|
||||
logger.exception("AgentHook.{} error in {}", method_name, type(h).__name__)
|
||||
|
||||
async def before_iteration(self, context: AgentHookContext) -> None:
|
||||
await self._for_each_hook_safe("before_iteration", context)
|
||||
|
||||
async def before_run(self, context: AgentRunHookContext) -> None:
|
||||
await self._for_each_hook_safe("before_run", context)
|
||||
|
||||
async def after_run(self, context: AgentRunHookContext) -> None:
|
||||
await self._for_each_hook_safe("after_run", context)
|
||||
|
||||
async def on_error(self, context: AgentRunHookContext) -> None:
|
||||
await self._for_each_hook_safe("on_error", context)
|
||||
|
||||
async def on_finally(self, context: AgentRunHookContext) -> None:
|
||||
await self._for_each_hook_safe("on_finally", context)
|
||||
|
||||
async def on_stream(self, context: AgentHookContext, delta: str) -> None:
|
||||
await self._for_each_hook_safe("on_stream", context, delta)
|
||||
|
||||
async def on_stream_end(self, context: AgentHookContext, *, resuming: bool) -> None:
|
||||
await self._for_each_hook_safe("on_stream_end", context, resuming=resuming)
|
||||
|
||||
async def before_execute_tools(self, context: AgentHookContext) -> None:
|
||||
await self._for_each_hook_safe("before_execute_tools", context)
|
||||
|
||||
async def before_execute_tool(
|
||||
self,
|
||||
context: AgentHookContext,
|
||||
tool_call: ToolCallRequest,
|
||||
tool: Any,
|
||||
params: Any,
|
||||
) -> None:
|
||||
await self._for_each_hook_safe("before_execute_tool", context, tool_call, tool, params)
|
||||
|
||||
async def after_execute_tool(
|
||||
self,
|
||||
context: AgentHookContext,
|
||||
tool_call: ToolCallRequest,
|
||||
tool: Any,
|
||||
params: Any,
|
||||
result: Any,
|
||||
) -> None:
|
||||
await self._for_each_hook_safe(
|
||||
"after_execute_tool",
|
||||
context,
|
||||
tool_call,
|
||||
tool,
|
||||
params,
|
||||
result,
|
||||
)
|
||||
|
||||
async def on_execute_tool_error(
|
||||
self,
|
||||
context: AgentHookContext,
|
||||
tool_call: ToolCallRequest,
|
||||
tool: Any,
|
||||
params: Any,
|
||||
error: Any,
|
||||
) -> None:
|
||||
await self._for_each_hook_safe(
|
||||
"on_execute_tool_error",
|
||||
context,
|
||||
tool_call,
|
||||
tool,
|
||||
params,
|
||||
error,
|
||||
)
|
||||
|
||||
async def emit_reasoning(self, reasoning_content: str | None) -> None:
|
||||
await self._for_each_hook_safe("emit_reasoning", reasoning_content)
|
||||
|
||||
async def emit_reasoning_end(self) -> None:
|
||||
await self._for_each_hook_safe("emit_reasoning_end")
|
||||
|
||||
async def after_iteration(self, context: AgentHookContext) -> None:
|
||||
await self._for_each_hook_safe("after_iteration", context)
|
||||
|
||||
def finalize_content(self, context: AgentHookContext, content: str | None) -> str | None:
|
||||
for h in self._hooks:
|
||||
content = h.finalize_content(context, content)
|
||||
return content
|
||||
|
||||
|
||||
class SDKCaptureHook(AgentHook):
|
||||
"""Record tool names and the final message list for ``RunResult``.
|
||||
|
||||
The runner mutates ``context.messages`` in place across iterations, so the
|
||||
snapshot is refreshed on every ``after_iteration`` call; the last call
|
||||
reflects the end-of-turn state the SDK caller cares about. The run-level
|
||||
snapshot is authoritative when available and covers paths without a final
|
||||
per-iteration callback.
|
||||
"""
|
||||
|
||||
def __init__(self) -> None:
|
||||
super().__init__()
|
||||
self.tools_used: list[str] = []
|
||||
self.messages: list[dict[str, Any]] = []
|
||||
self.usage: dict[str, int] = {}
|
||||
self.stop_reason: str | None = None
|
||||
self.error: str | None = None
|
||||
self.tool_events: list[dict[str, str]] = []
|
||||
self.had_injections: bool = False
|
||||
|
||||
async def after_iteration(self, context: AgentHookContext) -> None:
|
||||
for call in context.tool_calls:
|
||||
self.tools_used.append(call.name)
|
||||
self.messages = list(context.messages)
|
||||
self.usage = dict(context.usage)
|
||||
self.stop_reason = context.stop_reason
|
||||
self.error = context.error
|
||||
self.tool_events = list(context.tool_events)
|
||||
|
||||
async def after_run(self, context: AgentRunHookContext) -> None:
|
||||
self.tools_used = list(context.tools_used)
|
||||
self.messages = list(context.messages)
|
||||
self.usage = dict(context.usage)
|
||||
self.stop_reason = context.stop_reason
|
||||
self.error = context.error
|
||||
self.tool_events = list(context.tool_events)
|
||||
self.had_injections = context.had_injections
|
||||
@@ -0,0 +1,11 @@
|
||||
"""Concrete agent hook implementations."""
|
||||
|
||||
from nanobot.agent.hooks.file_edit_activity import (
|
||||
FileEditActivityHook,
|
||||
create_file_edit_activity_hook,
|
||||
)
|
||||
|
||||
__all__ = [
|
||||
"FileEditActivityHook",
|
||||
"create_file_edit_activity_hook",
|
||||
]
|
||||
@@ -0,0 +1,135 @@
|
||||
"""Agent hook that observes file-editing tools and emits file-edit activity."""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
from collections.abc import Awaitable, Callable
|
||||
from pathlib import Path
|
||||
from typing import Any
|
||||
|
||||
from nanobot.agent.hook import (
|
||||
AgentHook,
|
||||
AgentHookContext,
|
||||
AgentRunHookContext,
|
||||
AgentTurnHookContext,
|
||||
)
|
||||
from nanobot.providers.base import ToolCallRequest
|
||||
from nanobot.utils.file_edit_events import (
|
||||
FileEditTracker,
|
||||
build_file_edit_end_event,
|
||||
build_file_edit_error_event,
|
||||
build_file_edit_start_event,
|
||||
prepare_file_edit_trackers,
|
||||
)
|
||||
from nanobot.utils.progress_events import (
|
||||
invoke_file_edit_progress,
|
||||
on_progress_accepts_file_edit_events,
|
||||
)
|
||||
|
||||
|
||||
class FileEditActivityHook(AgentHook):
|
||||
"""Translate file-editing tool lifecycle events into WebUI progress events."""
|
||||
|
||||
def __init__(
|
||||
self,
|
||||
*,
|
||||
on_progress: Callable[..., Awaitable[None]] | None,
|
||||
workspace: Path | None,
|
||||
) -> None:
|
||||
super().__init__()
|
||||
self._on_progress = (
|
||||
on_progress
|
||||
if on_progress is not None and on_progress_accepts_file_edit_events(on_progress)
|
||||
else None
|
||||
)
|
||||
self._workspace = workspace
|
||||
self._trackers_by_call: dict[str, list[FileEditTracker]] = {}
|
||||
|
||||
async def before_iteration(self, context: AgentHookContext) -> None:
|
||||
self._trackers_by_call.clear()
|
||||
|
||||
async def before_execute_tool(
|
||||
self,
|
||||
context: AgentHookContext,
|
||||
tool_call: ToolCallRequest,
|
||||
tool: Any,
|
||||
params: Any,
|
||||
) -> None:
|
||||
if self._on_progress is None or not isinstance(params, dict):
|
||||
return
|
||||
trackers = prepare_file_edit_trackers(
|
||||
call_id=tool_call.id,
|
||||
tool_name=tool_call.name,
|
||||
tool=tool,
|
||||
workspace=self._workspace,
|
||||
params=params,
|
||||
)
|
||||
if not trackers:
|
||||
return
|
||||
self._trackers_by_call[self._tool_call_key(tool_call)] = trackers
|
||||
await self._emit([build_file_edit_start_event(tracker, params) for tracker in trackers])
|
||||
|
||||
async def after_execute_tool(
|
||||
self,
|
||||
context: AgentHookContext,
|
||||
tool_call: ToolCallRequest,
|
||||
tool: Any,
|
||||
params: Any,
|
||||
result: Any,
|
||||
) -> None:
|
||||
key = self._tool_call_key(tool_call)
|
||||
trackers = self._trackers_by_call.get(key, [])
|
||||
if trackers:
|
||||
await self._emit([build_file_edit_end_event(tracker) for tracker in trackers])
|
||||
self._trackers_by_call.pop(key, None)
|
||||
|
||||
async def on_execute_tool_error(
|
||||
self,
|
||||
context: AgentHookContext,
|
||||
tool_call: ToolCallRequest,
|
||||
tool: Any,
|
||||
params: Any,
|
||||
error: Any,
|
||||
) -> None:
|
||||
key = self._tool_call_key(tool_call)
|
||||
trackers = self._trackers_by_call.get(key, [])
|
||||
if trackers:
|
||||
await self._emit([
|
||||
build_file_edit_error_event(tracker, str(error)) for tracker in trackers
|
||||
])
|
||||
self._trackers_by_call.pop(key, None)
|
||||
|
||||
async def on_finally(self, context: AgentRunHookContext) -> None:
|
||||
if context.stop_reason != "cancelled" or not self._trackers_by_call:
|
||||
return
|
||||
trackers = [
|
||||
tracker
|
||||
for trackers in self._trackers_by_call.values()
|
||||
for tracker in trackers
|
||||
]
|
||||
self._trackers_by_call.clear()
|
||||
await self._emit([
|
||||
build_file_edit_error_event(
|
||||
tracker,
|
||||
"Task interrupted before this tool finished.",
|
||||
)
|
||||
for tracker in trackers
|
||||
])
|
||||
|
||||
async def _emit(self, events: list[dict[str, Any]]) -> None:
|
||||
if self._on_progress is not None:
|
||||
await invoke_file_edit_progress(self._on_progress, events)
|
||||
|
||||
@staticmethod
|
||||
def _tool_call_key(tool_call: ToolCallRequest) -> str:
|
||||
call_id = getattr(tool_call, "id", "") or ""
|
||||
return f"{call_id}|{tool_call.name}" if call_id else f"{id(tool_call)}|{tool_call.name}"
|
||||
|
||||
|
||||
def create_file_edit_activity_hook(context: AgentTurnHookContext) -> AgentHook | None:
|
||||
"""Create the default file-edit observer for one agent turn."""
|
||||
if context.on_progress is None:
|
||||
return None
|
||||
return FileEditActivityHook(
|
||||
on_progress=context.on_progress,
|
||||
workspace=context.workspace,
|
||||
)
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,65 @@
|
||||
"""Helpers for runtime model preset selection."""
|
||||
|
||||
from __future__ import annotations
|
||||
|
||||
from collections.abc import Callable
|
||||
from typing import Any
|
||||
|
||||
from nanobot.config.schema import ModelPresetConfig
|
||||
from nanobot.providers.base import LLMProvider
|
||||
from nanobot.providers.factory import ProviderSnapshot, build_provider_snapshot
|
||||
|
||||
PresetSnapshotLoader = Callable[[str], ProviderSnapshot]
|
||||
|
||||
|
||||
def default_selection_signature(signature: tuple[object, ...] | None) -> tuple[object, ...] | None:
|
||||
return signature[:2] if signature else None
|
||||
|
||||
|
||||
def configured_model_presets(config: Any) -> dict[str, ModelPresetConfig]:
|
||||
return {**config.model_presets, "default": config.resolve_default_preset()}
|
||||
|
||||
|
||||
def make_preset_snapshot_loader(
|
||||
config: Any,
|
||||
provider_snapshot_loader: Callable[..., ProviderSnapshot] | None,
|
||||
) -> PresetSnapshotLoader:
|
||||
if provider_snapshot_loader is not None:
|
||||
return lambda name: provider_snapshot_loader(preset_name=name)
|
||||
return lambda name: build_provider_snapshot(config, preset_name=name)
|
||||
|
||||
|
||||
def build_static_preset_snapshot(
|
||||
provider: LLMProvider,
|
||||
name: str,
|
||||
preset: ModelPresetConfig,
|
||||
) -> ProviderSnapshot:
|
||||
return ProviderSnapshot(
|
||||
provider=provider,
|
||||
model=preset.model,
|
||||
context_window_tokens=preset.context_window_tokens,
|
||||
signature=("model_preset", name, preset.model_dump_json()),
|
||||
generation=preset.to_generation_settings(),
|
||||
)
|
||||
|
||||
|
||||
def build_runtime_preset_snapshot(
|
||||
*,
|
||||
name: str,
|
||||
presets: dict[str, ModelPresetConfig],
|
||||
provider: LLMProvider,
|
||||
loader: PresetSnapshotLoader | None,
|
||||
) -> ProviderSnapshot:
|
||||
if loader is not None:
|
||||
return loader(name)
|
||||
return build_static_preset_snapshot(provider, name, presets[name])
|
||||
|
||||
|
||||
def normalize_preset_name(name: str | None, presets: dict[str, ModelPresetConfig]) -> str:
|
||||
if not isinstance(name, str) or not name.strip():
|
||||
raise ValueError("model_preset must be a non-empty string")
|
||||
name = name.strip()
|
||||
if name not in presets:
|
||||
raise KeyError(f"model_preset {name!r} not found. Available: {', '.join(presets) or '(none)'}")
|
||||
return name
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user