mirror of
https://github.com/langbot-app/LangBot.git
synced 2026-10-29 20:05:25 +08:00
* 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]>
--- title: "Models" --- ## LangBot Models LangBot Models is an official model service provided by LangBot. When you initialize a local instance with your LangBot Space account, available models will be automatically added to your instance without any configuration. You will receive a certain amount of free quota to get started quickly. <img src="/images/zh/deploy/models/langbot_models.png" alt="langbot_models" /> For specific available models, please check [LangBot Space](https://space.langbot.app/models). ## Custom Models You can also add models from other sources. ### LLM Model Models will be used by pipelines to process messages. The first model you configure will be set as the model for the default pipeline.  You can add multiple models, and then select which model to use in the pipeline. <img width="400px" src="/images/zh/deploy/models/model_config.png" alt="model_config" /> Enter these four parameters: `Model Name`, `Model Provider`, `Request URL`, and `API Key`, then submit. For model capabilities, enable the ones the underlying model actually supports: - **Vision**: enable to recognize images - **Tool Use** (function calling / tool use): enable so the LLM can call tools during a conversation <Note> **Tool Use must be enabled on the model whenever you want to use tools from MCP servers, sandbox built-ins (`exec`/`read`/`write`/`edit`/`glob`/`grep`), or Skills.** Without it, even if the pipeline binds those extensions, the Agent won't call any tools. The underlying model has to actually support function calling for this checkbox to take effect — check the model provider's docs if unsure. </Note> ### Embedding Model Embedding models are used to compute vector representations of messages. If you need to use knowledge bases, please configure this model. <img width="400px" src="/images/zh/deploy/models/embedding_model.png" alt="embedding_model" /> Enter these four parameters: `Model Name`, `Model Provider`, `Request URL`, and `API Key`, then submit. After that, please configure the knowledge base to use this model. ### Using seekdb Built-in Embedding Model (Zero Configuration) The system has integrated the official embedding model provided by seekdb, no parameters required. - On the "Embedding Model" page, select "seekdb-built-in"; - Click "Save" to use it immediately; - Then select this model in your knowledge base to take effect. ### Using Chroma Built-in Embedding Model (Zero Configuration) The system has integrated Chroma's built-in embedding model (all-MiniLM-L6-v2), no parameters required. - On the "Embedding Model" page, select "chroma-built-in"; - Click "Save" to use it immediately; - Then select this model in your knowledge base to take effect. ### Rerank Model Rerank models re-score RAG retrieval results to significantly improve the precision of knowledge base answers. When a knowledge base returns multiple candidate documents, the rerank model uses a cross-encoder to precisely score each document's relevance to the query, selecting only the most relevant content. Enter `Model Name` and select `Model Provider`, then submit. After that, select this model in your pipeline's "AI" configuration. <Tip> Rerank models are optional. Without one, knowledge base results are used in their original retrieval order. With a rerank model configured, results are re-scored and only the top-K most relevant results are kept. </Tip>