Skip to main content

​
Use Loong

Use this section when you already know Loong is relevant and need the public runtime model before diving into configuration details. The highlighted playbooks are representative rollout paths. The provider and channel pages keep the broader supported surface visible. This section is organized in two layers on purpose:
  • chooser pages explain which route fits
  • recipe and playbook pages show concrete config and command paths

​
Most Common Reading Paths

If you are trying to…Start hereThen continue to…
reach one complete hosted team-chat rollout quicklyCommon Setupsstart with the playbook that matches the real rollout shape, then fall back to Provider Guides or Channel Guides when you need the broader map
understand the shared public config shape before deep recipesConfiguration PatternsProvider Guides, Channel Setup, or Memory Profiles
unblock managed skills, browser preview, or domain-policy frictionManaged SkillsBrowser And Web Boundaries, Doctor And Health, or Tool Surface
choose a provider first, then configure it directlyProviders And ModelsProvider Guides and Provider Recipes
choose a delivery surface first, then configure it directlyChannelsChannel Guides, Channel Recipes, and Gateway And Supervision
understand the runtime surface before touching configthis pageProviders And Models, Channels, and Tools And Memory
go from basic setup to continuity and governed capabilitiesTools And MemoryTool Surface and Memory Profiles

​
Page Types

  • Use chooser pages when you are still deciding which route fits.
  • Use guide pages when one provider or channel is already decided and you need the exact built-in contract.
  • Use recipe pages when you want representative rollout patterns, smoke tests, or sequencing.
  • Use playbooks when provider, channel, and ownership need to be treated as one rollout.
  • Use reference pages after the operator path is already clear.

​
Common Rollout Paths

If the stack is already clear, skip the generic recipe pass and start with one complete rollout path.
If you already know you want…Start hereWhy
Volcengine plus Feishu or LarkVolcengine Plus Feishu Or Larkhosted provider and primary team-chat runtime stay in one path
Volcengine plus WeComWeCom Rollouthosted provider and the shipped WeCom lane stay together
BytePlus Coding plus TelegramBytePlus Coding Plus Telegramthe coding lane and the lightweight bot surface remain explicit
a local model plus outbound deliveryLocal Model Plus Outbound Deliverylocal inference and outbound-only delivery stay truthful
several runtime-backed channels on one hostGateway Rolloutselector and owner-contract rollout stays in one document

​
How To Read This Section

  1. Start with the base CLI path and make sure ask or chat works locally.
  2. Use Common Setups when the rollout shape is already clear and you want one proven route.
  3. Use Providers And Models or Channels when you still need to choose the right lane first.
  4. Drop into recipe pages when the chooser pages stop being concrete enough.
  5. Add channel or gateway surfaces only after the local assistant path is healthy.
  6. Turn on memory or managed-skills flows when you need continuity or reuse rather than on day zero.

​
Current Public Runtime Shape

  • Assistant entrypoints: onboard, ask, chat, and doctor are the shortest public operator path.
  • Provider and model selection: onboard and list-models keep provider choice and model discovery visible instead of burying them behind one hardcoded provider story.
  • Operator runtime commands: audit, tasks, skills, plugins, channels, and runtime-snapshot are part of the public surface.
  • Gateway ownership: gateway run, gateway status, gateway stop, and multi-channel-serve cover the current owner and compatibility layer for longer-lived delivery.
  • Delivery surfaces: Loong distinguishes runtime-backed reply-loop surfaces from a wider config-backed outbound inventory instead of flattening them into one story.
  • Governed runtime capabilities: tools, memory behavior, prompt defaults, policy, approval, and audit stay inside the same runtime model.

​
Page Guide

PageRead it when…
Common Setupsyou want end-to-end playbooks that combine provider, channel, and gateway choices
Volcengine Plus Feishu Or Larkyou already know the hosted-plus-team-chat rollout shape
WeCom Rolloutyou already know WeCom should own the enterprise runtime lane
BytePlus Coding Plus Telegramyou want a dedicated coding lane plus a lightweight bot surface
Local Model Plus Outbound Deliveryyou want local inference without overclaiming runtime-backed delivery
Gateway Rolloutyou want the multi-channel ownership sequence as one playbook
Configuration Patternsyou want the shared public config shape before field-level specs or recipes
Managed Skillsyou want the operator path for discovery, install, policy, and browser preview enablement
Browser And Web Boundariesyou want private-host, domain, and browser runtime troubleshooting without guessing which config lane owns it
Providers And Modelsyou want the public provider and model-selection contract before touching config
Provider Guidesyou want the exact built-in contract for one provider kind
Provider Recipesyou want a concrete hosted, gateway, local, or multi-profile config path
Channelsyou want the delivery-surface model and runtime-backed vs outbound-only boundary
Channel Guidesyou want the exact built-in contract for one shipped channel surface
Channel Setupyou want the practical setup contract for shipped surfaces
Gateway And Supervisionyou want to choose between gateway run and multi-channel-serve, or pin explicit channel accounts
Channel Recipesyou want smoke tests, rollout order, and multi-channel examples
Tools And Memoryyou want the governed-capability overview
Tool Surfaceyou want the visible-tool truth contract
Memory Profilesyou want the continuity model
Referenceyou want roadmap, reliability, security, and release references after the runtime model is clear