Files
LangBot/en/deploy/settings.mdx
T
99185d0b1d Feat/sandbox (#94)
* docs: add sandbox documentation for all languages

Add comprehensive documentation for the code sandbox feature:
- Overview, built-in tools, scope and lifecycle
- Backend configuration (Docker/Nsjail/E2B)
- Security profiles (default/offline_readonly/network_basic/network_extended)
- Complete configuration reference

Languages: zh, en, ja

* docs: add skills documentation for all languages

Add comprehensive Skills system documentation covering:
- Design philosophy and industry practices comparison (Claude Code, OpenAI GPTs, Cursor)
- Layered architecture (management, import, execution layers)
- Current activation mechanism ([ACTIVATE_SKILL:] marker) with TODO for future Tool Call optimization
- Agent Skills open standard compliance with field specifications
- Complete tools API reference

Languages: zh, en, ja

Co-Authored-By: Claude Opus 4.7 <[email protected]>

* docs: update sandbox documentation to include new tools and configuration options

* Refactor Skills API documentation to align with Tool Call mechanism

- Updated the overview of the Skills system to emphasize the Tool Call mechanism for activating and registering skills.
- Removed deprecated tools and consolidated functionality into `activate` and `register_skill`.
- Revised usage examples and parameters for the new tools, ensuring clarity on their requirements and expected responses.
- Enhanced descriptions of the activation process, including the injection of skill instructions and mounting of skill packages.
- Improved error handling documentation for better user guidance.
- Added notes on sandbox requirements for tool usage and the creation of new skills.

* docs: align sandbox runtime guides

* docs: align sandbox & skills guides with current Box implementation

Correct five inaccuracies across the zh/en/ja sandbox and skills docs so
they match the actual code:

- Box launch command: use the lbp CLI subcommand
  (`langbot_plugin.cli.__init__ box`) instead of the removed
  `langbot_plugin.box --mode ws`.
- Environment variables: replace the obsolete `LANGBOT_BOX_LOCAL_*`
  vars with the unified `SECTION__SUBSECTION__KEY` override convention
  (`BOX__LOCAL__*`); note that the langbot_box service reads no
  config.yaml/env and is configured by LangBot over INIT RPC.
- Skills: drop the stale "falls back to data/skills" claims — the Box
  Runtime is the sole source of skills; when Box is unavailable the
  skill list is simply empty.
- Document the new `box.enabled` master switch (default true) and what
  it gates.
- Document that the langbot_box compose service is optional, gated
  behind the `box`/`all` compose profile.

* docs: align sandbox docs with implementation

* docs: simplify sandbox naming and diagrams

* docs: shorten AI capability nav labels

* docs: merge sandbox configuration pages

* docs: document BOX__BACKEND as sole backend selector

* docs: recommend all profile for docker deploy

* docs: add docker permission fix for sandbox

* chore(skills): add obra/superpowers writing-skills

Install the writing-skills skill from obra/superpowers via
`npx skills add`. Lands the skill files under .agents/skills/
(universal layout) with a Claude Code symlink at .claude/skills/
and the pin in skills-lock.json.

Also gitignore .claude/settings.local.json since it's per-user
Claude Code state (skill symlinks under .claude/skills/ remain
tracked).

* docs(sandbox,skills): tighten user guides for onboarding

Rewrite the sandbox and skills user guides to be shorter, plainer, and
focused on getting users productive instead of explaining internals.

Changes per page (zh/en/ja kept in lockstep):

- sandbox/readme: 170 → 73 lines. Drop the "what is a sandbox" essay,
  decorative mermaid, and the backend table that already lives in
  config.mdx. Lead with the six built-in tools and the scope picker
  (the parts users actually configure).
- sandbox/runtime-relationships: 75 → 54 lines. Replace the runtime
  prose with a single comparison table; tighten the troubleshooting
  entry-points.
- skills/readme: 320 → 114 lines. Cut the "design philosophy" /
  "industry comparison" / "KV cache theory" sections — those are
  implementation details users don't need to ship. Lead with the
  user-visible flow (Agent reads <available_skills> → calls activate →
  follows the SKILL.md).
- skills/skill-format: 360 → 134 lines. One excellent example
  (api-tester) instead of three overlapping ones. Drop the standalone
  "field details" subsections that just restate the table.
- skills/tools-api: 200 → 122 lines. Drop the old-vs-new historical
  comparison and the duplicated activation section; keep the two tool
  signatures, parameters, returns and errors.

sandbox/config.mdx left untouched (already condensed upstream).

Principles applied come from obra/superpowers writing-skills (installed
in 08c35a4): lead with use, one excellent example, tables for scanning,
cut internals and history.

* docs(sandbox): drop redundant 'how to choose' table from runtime-relationships

The 对照表 above already has a '何时使用 / When to use' column that says
the same thing. Repeating it as a second 怎么选 / How to Choose table
was pure noise.

* docs(skills): collapse to one page, link out for SKILL.md spec

Delete skill-format.mdx and tools-api.mdx — Skills now has a single
page. The format details and tools reference were already covered in
shorter form inside readme.mdx; the separate pages were repetition.

In readme.mdx:
- Inline a compact 'SKILL.md format' section (one example + a three-
  field table) and point at agentskills.io for the canonical spec.
- Drop the 'next steps' section and the tools-api link, since both
  destinations no longer exist.

docs.json: remove the two pages from each locale's Skills nav. Add
redirects from the old paths to readme so existing links don't 404.

* docs(nav): flatten Skills — single page, no group wrapper

Group with one child is just visual noise in the sidebar. Replace
{ group: Skills, pages: [...readme] } with the readme path directly
in the parent AI Configuration group, in all three locales.

* docs(mcp,skills): lead with LangBot Space as the preferred install path

LangBot Space (https://space.langbot.app) now hosts a curated list of
MCP servers and Skills. Surface that as the first install option in
both user guides.

- usage/mcp/readme: rework the intro Info block to recommend LangBot
  Space first (third-party channels demoted to "alternative source").
  Add a "Install from LangBot Space (Preferred)" section above the
  existing manual flow; rename that flow to "Add MCP Server Manually".
- usage/skills/readme: add a "Install from LangBot Space (Preferred)"
  section above "Creating a Skill"; rename the existing section to
  "Creating a Custom Skill" so the contrast is clear.

zh/en/ja kept in sync.

* docs(skills): reorganize the readme around the user journey

The old structure interleaved "what it is" → "how it works internally"
→ "prerequisites" → "format spec" → install options. Reorder around
how users actually approach the page:

  Intro → compare with plugins/MCP → install → enable → write → debug

Specific moves:
- Drop the standalone "Workflow" flow diagram; fold the one important
  point (activation pulls SKILL.md via Tool Result) into the intro.
- Merge the standalone "Prerequisites" section into a short Note on the
  Install heading — that's where the constraint actually applies.
- Bring "Install from LangBot Space" and "Create your own" together
  under one "Install" H2 with H3 subsections; they were sibling H2s
  before, which buried the relationship.
- Move "Writing a SKILL.md" after install + enable, since most users
  start with marketplace skills.
- Demote the "Tools the Agent sees" table to an H3 inside the writing
  section — it's reference, not a top-level concern.

114 → 100 lines, zh/en/ja in lockstep.

* docs(mcp,models): reorder MCP page + move tool-use capability to Models

Two related changes, same as the Skills cleanup pattern:

usage/mcp/readme — reorganize around the user journey
- Drop the standalone "Enable function calling on the model" section;
  that belongs in the Models doc (it's not MCP-specific — sandbox tools
  and Skills depend on the same model capability).
- Drop the redundant "Effect" section — its one fact (built-in Agent +
  tool-use model) already lives in the Note under "Three Transport
  Modes".
- Group install paths under one "Installing an MCP Server" H2 with
  Space (preferred) and manual flows as H3 siblings, mirroring the
  Skills doc layout.
- Move the stdio MCP technical block under a clearly-labeled
  "Advanced: stdio MCP" H2 so casual readers skim past it.
- Trim screenshot duplication and collapse three steps in the manual
  flow into one paragraph + one screenshot per step.
- 140 → 107 lines, zh/en/ja kept in lockstep.

usage/models/readme — rename and expand "function calling" → "tool use"
- The checkbox is renamed to "Tool Use" (zh: 工具使用能力 / ja: ツール
  使用); function calling kept in parentheses for recognition.
- Expand the bullet into a Note that explicitly lists where the
  capability matters: MCP servers, sandbox built-ins (exec/read/write/
  edit/glob/grep), Skills. Without it, even bound extensions stay
  silent.
- Note that the underlying model must actually support function
  calling for the checkbox to take effect.

* docs(sandbox): point sandbox/config readers to System Environment Settings

The page lists box.* YAML blocks without ever telling the reader where
those settings actually go. Add a one-line Note at the top linking to
deploy/settings (System Environment Settings), where the data/config.yaml
location and load mechanism are documented.

* docs(sandbox/config): align the page with the real config structure

The previous version listed local / docker / nsjail / e2b as four
parallel "backends" in one flat table. That's wrong: looking at the
config template and the SDK's _select_backend, the real model is:

- box.backend accepts 'local' | 'docker' | 'nsjail' | 'e2b'
- 'local' is shorthand for "auto-pick from Docker / Nsjail" — not a
  fourth backend
- 'local', 'docker', 'nsjail' all *share* the box.local.* config
  section; the section is misleadingly named ("local" here means
  "host-local backends", not "for backend: 'local'")
- 'e2b' uses box.e2b.* instead
- 'local' is the only value that auto-falls-back; everything else is a
  hard selection

Rewrite the page around that structure:
- Group backends as "local containers" vs "cloud" with the four values
  inside, and call out the local-vs-fourth-backend distinction.
- Split the old single "common settings" table into two clearly-scoped
  tables: box.local.* (for local backends) and box.e2b.* (for cloud).
- Move box.runtime.endpoint into the Docker Compose section, where it
  actually matters.
- Add an explicit note that backend is a hard selection — only 'local'
  fans out.

zh/en/ja kept in lockstep.

* docs(deploy): note Box control-plane transport differs by deploy method

In Docker deployments the Box control plane runs as the langbot_box
container (WebSocket); manual / uvx deployments use a stdio subprocess.
Also clarify the LangBot image bundles the docker client so langbot_box
can create sandbox containers via the mounted socket without extra setup.
zh / en / ja.

---------

Co-authored-by: Claude Opus 4.7 <[email protected]>
Co-authored-by: Junyan Qin <[email protected]>
2026-06-04 20:18:29 +08:00

173 lines
6.8 KiB
Plaintext
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
title: "System Environment Settings"
---
Configure system runtime settings in `data/config.yaml`.
Generally, no modification is needed.
```yaml
admins: []
api:
port: 5300
webhook_prefix: 'http://127.0.0.1:5300'
extra_webhook_prefix: ''
command:
enable: true
prefix:
- '!'
- !
privilege: {}
concurrency:
pipeline: 20
session: 1
proxy:
http: ''
https: ''
system:
instance_id: ''
edition: community
recovery_key: ''
allow_modify_login_info: true
disabled_adapters: []
limitation:
max_bots: -1
max_pipelines: -1
max_extensions: -1
task_retention:
# Keep at most this many completed async task records in memory
completed_limit: 200
jwt:
expire: 604800
secret: ''
database:
use: sqlite
sqlite:
path: 'data/langbot.db'
postgresql:
host: '127.0.0.1'
port: 5432
user: 'postgres'
password: 'postgres'
database: 'postgres'
vdb:
use: chroma
qdrant:
url: ''
host: localhost
port: 6333
api_key: ''
seekdb:
mode: embedded # 'embedded' or 'server'
# Embedded mode options:
path: './data/seekdb'
database: 'langbot'
# Server mode options (used when mode='server'):
host: 'localhost'
port: 2881
user: 'root'
password: ''
tenant: '' # Optional, for OceanBase server
milvus:
uri: 'http://127.0.0.1:19530'
token: ''
db_name: ''
pgvector:
host: '127.0.0.1'
port: 5433
database: 'langbot'
user: 'postgres'
password: 'postgres'
storage:
use: local
cleanup:
# Enable periodic cleanup of local/S3 uploaded files and old log files
enabled: true
# Cleanup check interval in hours
check_interval_hours: 1
# Root-level uploaded files older than this will be deleted
uploaded_file_retention_days: 7
# LangBot log files older than this many days will be deleted
log_retention_days: 3
s3:
endpoint_url: ''
access_key_id: ''
secret_access_key: ''
region: 'us-east-1'
bucket: 'langbot-storage'
plugin:
enable: true
runtime_ws_url: 'ws://langbot_plugin_runtime:5400/control/ws'
enable_marketplace: true
display_plugin_debug_url: 'ws://localhost:5401/plugin/debug/ws'
binary_storage:
# Max bytes for a single plugin binary storage value
max_value_bytes: 10485760
monitoring:
auto_cleanup:
# Enable automatic cleanup of expired monitoring records
enabled: true
# Retention period in days, records older than this will be deleted
retention_days: 30
# Cleanup check interval in hours
check_interval_hours: 1
# Number of expired rows to delete per table batch
delete_batch_size: 1000
box:
enabled: true # Master switch for Box Runtime. When false, Box-dependent features such as sandbox tools, Skill add/edit, and stdio MCP are disabled.
backend: 'local' # 'local' (Docker/nsjail), 'docker', 'nsjail', or 'e2b'. Can be written via BOX__BACKEND.
runtime:
endpoint: '' # External Box Runtime base URL, e.g. 'ws://127.0.0.1:5410'. When empty, non-Docker deployments use a locally managed Runtime; Docker deployments connect to langbot_box:5410 on the Compose network.
local:
profile: 'default'
image: '' # Custom local sandbox image. Leave empty to use the profile default.
host_root: './data/box' # Base host directory for local workspace mounts. Docker deployments should use an absolute host path mounted by langbot_box.
default_workspace: '' # Defaults to '<host_root>/default'.
skills_root: 'skills' # Box-owned Skill package directory. Relative paths are resolved under host_root.
allowed_mount_roots: # Defaults to ['<host_root>'] when left empty.
- './data/box'
- '/tmp'
workspace_quota_mb: null # Optional disk quota override (>= 0). null = profile default.
e2b:
api_key: '' # Can also be set via E2B_API_KEY env var.
api_url: '' # Custom API URL for self-hosted deployments.
template: '' # Default template ID (e.g. 'base', 'python-3.11').
space:
# Space service URL for OAuth and API
url: 'https://space.langbot.app'
# Space API URL for model requests (MaaS)
models_gateway_api_url: 'https://api.langbot.cloud/v1'
# OAuth authorization page URL
oauth_authorize_url: 'https://space.langbot.app/auth/authorize'
disable_models_service: false
disable_telemetry: false
```
## Notes
- `storage.cleanup.uploaded_file_retention_days` only cleans temporary uploaded files at the storage root. It does not delete plugin configuration files or internal objects stored under directories.
- `storage.cleanup.log_retention_days` cleans old log files by the date in their file names. The default keeps at most 3 days of logs.
- When SQLite is used as the database, automatic monitoring cleanup directly releases database file space after deleting expired records.
- `plugin.binary_storage.max_value_bytes` limits the size of a single plugin binary storage value. The default is 10 MiB.
- The WebUI sidebar includes a “Storage Analysis” page for viewing database, logs, uploaded files, vector store, plugins, MCP, temporary files, and cleanup candidates.
## Set Configuration Via Environment Variables
The configuration in `config.yaml` can be set via environment variables. Environment variable names use uppercase letters and double underscores, for example: `API__PORT` represents `api.port`.
- `API__PORT` represents `api.port`
- `CONCURRENCY__PIPELINE` represents `concurrency.pipeline`
- `DATABASE__SQLITE__PATH` represents `database.sqlite.path`
- `STORAGE__CLEANUP__UPLOADED_FILE_RETENTION_DAYS` represents `storage.cleanup.uploaded_file_retention_days`
- `STORAGE__CLEANUP__LOG_RETENTION_DAYS` represents `storage.cleanup.log_retention_days`
- `MONITORING__AUTO_CLEANUP__RETENTION_DAYS` represents `monitoring.auto_cleanup.retention_days`
- `PLUGIN__BINARY_STORAGE__MAX_VALUE_BYTES` represents `plugin.binary_storage.max_value_bytes`
- `BOX__BACKEND` represents `box.backend`
- `BOX__LOCAL__HOST_ROOT` represents `box.local.host_root`
- `BOX__LOCAL__SKILLS_ROOT` represents `box.local.skills_root`
On startup, LangBot reads all environment variables, applies the corresponding configuration to `config.yaml`, and writes it to `data/config.yaml`.
<Note>
Set Box-related configuration on the `langbot` service with the unified `BOX__*` environment variables. LangBot applies them to `data/config.yaml` on startup and sends the Box configuration to `langbot_box` through INIT RPC. Do not set `LANGBOT_BOX_*` or `BOX__*` on the `langbot_box` service; they are not read directly there.
</Note>