OpenClaw落地场景与最佳实践

文档整理时间：2025年2月24日
基于谷歌等搜索引擎及官方文档整理，涵盖：落地场景与实战案例、生产环境最佳实践与安全、Skills 与 ClawHub、企业内网/私有化部署、LLM 路由（本地与远端模型）、多 Agent 与 Agent 间互调。

一、落地场景与实战案例

1.1 社交与信息管理

场景	说明
X/Twitter 账号分析	分析发文风格、互动数据、粉丝画像
Daily Reddit Digest	自动整理关注版块的精华内容，生成每日摘要
多渠道个人助理	跨 Telegram、Slack、邮件、日历统一任务路由与提醒

1.2 创意与内容生产

场景	说明
YouTube 内容管道	自动化视频选题、素材整理与进度追踪
Mini-App Builder	过夜自动生成迷你应用原型
社交媒体内容运营	管理 X 和 LinkedIn，自动抓热点、起草与发布内容

1.3 办公效率提升

场景	说明
邮件管理	自动筛选重要邮件、总结 newsletters、分类与跟进
Personal CRM	从邮件和日历自动建立人际关系管理与提醒
飞书群管理	自动欢迎新人、发送内容、维持群内互动与答疑

1.4 健康与生活管理

场景	说明
Health Symptom Tracker	追踪健康指标、设置用药/复诊提醒
个人与家庭日程协调	管理家庭成员共同日程和任务分配

1.5 研究与知识管理

场景	说明
Personal Knowledge Base (RAG)	构建可搜索的个人知识库，与对话结合
AI Earnings Tracker	自动收集公司财报并生成摘要与要点

1.6 开发与运维

场景	说明
远程代码调试与完成	在通勤等场景通过手机/平板远程完成代码调试
浏览器自动化	自动部署、测试网页应用，填表单、截图、导出 PDF
「聊天框里办大事」案例	网站重建、买车砍价、Bug 修复等通过对话完成复杂任务

1.7 核心优势总结

非技术用户赋能：无需编程基础，通过自然语言或语音完成复杂操作
跨平台集成：飞书、Telegram、邮件、日历等多渠道统一入口
长期记忆：持续使用中学习用户习惯，执行效率提升
权限控制：支持分级权限与敏感操作审批，避免误操作与泄露

二、生产环境最佳实践与安全清单

2.1 安全形势（2026）

公开研究显示存在大量暴露在公网且使用默认配置的实例，生产环境必须做加固。
OpenClaw 具备真实能力：凭证访问、网络访问、文件操作、Shell 执行，必须按生产标准配置安全。

2.2 网络安全

项	建议
绑定地址	网关绑定 `127.0.0.1`，不要绑定 `0.0.0.0`，仅接受本地或反向代理连接
mDNS	禁用 mDNS 发现，避免在局域网内被自动发现
Control UI	禁用或置于反向代理后，并做身份验证
反向代理	使用 nginx / Caddy / Traefik 对外提供 HTTPS，终止 SSL
网关认证	启用 256 位 token 认证，所有请求必须带有效 token

2.3 凭证与密钥管理

项	建议
存储	禁止明文存储；使用环境变量或密钥管理（如 AWS Secrets Manager、HashiCorp Vault）
轮换	API Key、数据库密码等建议每 90 天轮换
权限	遵循最小权限，仅授予必要权限的 API Key
监控	设置用量与账单告警，发现异常调用及时排查

2.4 Agent 与 Skills 配置

项	建议
System Prompt	明确范围、禁止事项、升级规则、输出格式与语气
Skills	最小权限：只启用业务需要的 skills，避免「全部打开」
Memory	记忆分区清晰、定期清理过期上下文，重要记忆可做版本管理

2.5 审计与运维

项	建议
审计日志	记录对话历史、外部 API 调用、Shell 命令、文件操作、工具调用
日志格式	结构化日志便于检索与事件追踪
保留策略	建议至少 90 天，企业场景可 365 天
出口过滤	域名白名单（如通过 Squid 代理等）限制可访问外网
高风险操作	文件删除、发邮件、执行 Shell 等可配置为需人工审批（human-in-the-loop）
容器化	在 Docker 等容器中运行，限制影响范围；以非 root 用户运行

2.6 部署方式选择

托管/一键加固：使用 Clawctl 等托管方案可在约 60 秒内完成安全加固，适合快速上线。
自建：需自行落实上述清单，预计 2–40+ 小时配置与验证，适合对控制力要求高的场景。

三、Skills 体系概览

3.1 能力分层

类型	说明
Built-in Tools（内置工具）	随 OpenClaw 安装，约 8 个基础 + 17 个高级（文件、Shell、网页搜索/浏览、记忆、看图等），无需单独安装
Skills	符合 AgentSkills 规范的扩展，通过 SKILL.md + 目录结构定义，可从 ClawHub 安装或本地放置
Plugins（MCP）	基于 MCP 的集成，可与更多外部系统对接

3.2 加载位置与优先级

Workspace skills：/skills（当前工作区，最高优先级）
Managed/Local：~/.openclaw/skills
Bundled：随安装包自带的技能（最低优先级）
额外目录：通过 skills.load.extraDirs 配置（优先级最低）

同名 skill 时：workspace 覆盖 local，local 覆盖 bundled。

3.3 ClawHub 与安装方式

ClawHub：官方技能市场，clawhub.com（原 openclawskills.org 等索引站），可发现、安装、更新、备份 skills。
安装方式：
- 推荐：在 OpenClaw 内置 Skills UI 中安装（可见配置项与开关）
- CLI：clawhub install <skill-name>，或 openclaw skills list --eligible 查看可用的
- 对话：直接对 OpenClaw 说「帮我安装 XXX Skill」
常用命令：
- clawhub sync --all — 同步/扫描并发布更新
- clawhub update --all — 更新已安装的 skills
- clawhub search "关键词" — 搜索技能

默认安装到当前工作区的 ./skills，下次会话生效。

3.4 三大核心 Skills（入门必装）

常被称作「让 OpenClaw 从聊天变干活」的底座三件套：

顺序	Skill	作用
1	Tavily Search / Brave Search	实时获取最新资讯与数据，打破模型时间边界
2	Agent Browser	网页自动化：打开页面、填表单、截图、导出 PDF 等
3	Shell	终端命令执行：文件操作、脚本、系统管理

在此基础上再按需加「通讯入口」类（Telegram、飞书、Slack、Discord、WhatsApp 等）。

3.5 Top 10–20 必装清单（按梯队）

第一梯队：地基能力（建议先装）

ClawHub — 技能市场本体，便于后续安装其他 skill
Agent Browser — 网页自动化与信息抓取
Brave Search / Tavily — 联网搜索
Shell — 本地命令与文件操作
Cron / Wake — 定时任务与提醒

第二梯队：通讯入口（按使用场景选 1–2 个）

Telegram — 个人助理常用入口
飞书（Feishu） — 国内团队协作
Slack — 企业办公
Discord — 社区与开源协作
WhatsApp — 海外日常

第三梯队：按场景扩展

图片生成/编辑、天气、股票、新闻聚合
邮件、日历、笔记、RAG 知识库
智能家居、媒体控制等

数据参考：社区技能数量已达 1700+（31+ 分类），ClawHub 索引 5000+；优先用内置能力，再按需加社区 skill，避免重复与扩大攻击面。

3.6 Skills 使用最佳实践

最小权限：只启用当前工作流需要的 skills。
先读后装：第三方 skill 视为不可信代码，安装前阅读代码与权限说明。
密钥与配置：通过 skills.entries.<name>.env / apiKey 注入，勿写进 prompt 或日志；敏感信息放环境变量或密钥管理器。
沙箱：对不可信输入或高风险工具启用沙箱运行（参见官方 Sandboxing 文档）。
能内置不社区：若内置工具已满足需求，不必再装同类社区 skill，减少复杂度和风险。

四、企业内网与私有化部署（不使用外部大模型）

企业若涉及内部文件、敏感数据，可不使用任何外部大模型，全部推理在内网完成，数据不出网。

4.1 为什么可以完全不用外部 API

OpenClaw 通过 Model Providers 调用大模型，只要配置的 provider 指向内网自建推理服务，即可实现 100% 本地/私有化推理。
支持所有 OpenAI 兼容 的本地服务：只要暴露 /v1 端点（如 /v1/chat/completions），即可作为 provider 接入。
不配置任何云端 provider、且网络层禁止访问外网时，即无任何请求发往外部大模型。

4.2 常见内网推理方案

方案	说明	适用场景
Ollama	本地 LLM 运行时，一条命令拉模型、起服务，默认 `http://127.0.0.1:11434/v1`	开发/测试、小团队内网、Linux 服务器
LM Studio + MiniMax M2.1	官方推荐本地栈；Responses API 分离推理与最终文本，大上下文	对效果与安全要求高的内网部署
vLLM / LiteLLM	高性能推理服务或统一代理，暴露 OpenAI 风格 `/v1`	企业已有 GPU 集群、统一模型网关
自建网关 / OAI-proxy	任意自研或开源代理，只要实现 OpenAI 兼容 API	已有内部推理平台、需严格管控

4.2.1 LiteLLM、vLLM、Ollama 介绍与对比

三者常与 OpenClaw 内网部署一起出现，但角色不同：LiteLLM 是 API 网关，vLLM 与 Ollama 是推理引擎。

一句话定位

工具	定位	核心价值
LiteLLM	统一 API 网关/代理	用一套 OpenAI 风格 API 调用 100+ 模型源（云端 + 本地），并做路由、负载均衡、计费
vLLM	高性能推理引擎	在自有 GPU 上做高吞吐、多并发推理，面向生产部署
Ollama	本地 LLM 运行时	一条命令拉模型、起服务，极简本地体验，适合开发/小团队

分项说明

LiteLLM：Python 库 + 可选 Proxy 服务，提供 OpenAI 兼容的 /v1/chat/completions 等接口；不跑模型，只把请求转发到 OpenAI、Anthropic、本地 Ollama、本地 vLLM 等。适合「一个入口、多模型/多机房」或开发时用同一套代码切云端/本地。
vLLM：面向生产的推理服务，跑在你自己的 GPU 上；PagedAttention、continuous batching、多 GPU 张量并行，适合企业 GPU 集群、80+ 并发生产；暴露 OpenAI 兼容 API，可与 LiteLLM 或 OpenClaw 直连。
Ollama：本地 LLM 运行时（基于 llama.cpp），ollama run <model> 即拉模型并起服务（默认 http://127.0.0.1:11434）；GGUF、内置量化，对消费级显卡友好；也暴露 /v1，适合本机/内网开发、小团队，不适合单机扛 80+ 并发生产。

对比小结

维度	LiteLLM	vLLM	Ollama
角色	API 网关/代理	推理引擎（服务端）	本地推理运行时
是否跑模型	否，只转发	是	是
部署复杂度	低（多为配置）	中高（GPU、环境）	低（一键本地）
多用户/高并发	取决于后端（可配 vLLM）	强（PagedAttention + 批处理）	弱，单机易成瓶颈
典型场景	多模型统一入口、路由、降本	企业 GPU 集群、生产推理	开发/测试、小团队、内网

组合用法：LiteLLM + vLLM（网关挂 vLLM 做生产推理）、LiteLLM + Ollama（同一套代码切本地）；OpenClaw 可将 Ollama、vLLM、LiteLLM 等均配置为 Model Provider，按场景选其一或组合使用。

4.3 配置要点（仅用内网模型）

只配置内网 provider：在 ~/.openclaw/openclaw.json 的 models.providers 中只保留指向内网地址的 provider（如 ollama、lmstudio、local）。
不配置云端 provider：不要添加 OpenAI、Anthropic、MiniMax 云 API 等；若之前有，可删除或注释。
默认模型指向本地：agents.defaults.model.primary 设为上述本地 provider 的模型 ID（如 ollama/llama3.2:latest、lmstudio/minimax-m2.1-gs32）。
可选：关闭 fallback：若不允许任何外网回退，不要设置 fallbacks 到云端模型；仅保留本地或内网 fallback。
网络隔离：防火墙/代理限制 OpenClaw 所在机器仅能访问内网推理服务地址，禁止访问公网 API 域名。

4.4 示例：仅用 Ollama（纯本地）

{
  "models": {
    "providers": {
      "ollama": {
        "baseUrl": "http://127.0.0.1:11434/v1",
        "apiKey": "ollama-local",
        "api": "openai-responses",
        "models": [{ "id": "llama3.2:latest" }]
      }
    },
    "defaults": {
      "provider": "ollama",
      "model": "llama3.2:latest"
    }
  }
}

baseUrl 须以 /v1 结尾；多机部署时改为内网推理机地址（如 http://192.168.1.100:11434/v1）。
Ollama 官方建议本地模型至少 64k token 上下文；显存不足时可选用较小模型，但需接受上下文截断与更高提示注入风险。

4.5 示例：仅用内网 LM Studio / 自建 v1 服务

将 baseUrl 改为内网服务地址即可，例如：

{
  "models": {
    "providers": {
      "local": {
        "baseUrl": "http://192.168.1.100:1234/v1",
        "apiKey": "sk-internal",
        "api": "openai-responses",
        "models": [
          {
            "id": "minimax-m2.1-gs32",
            "name": "内网 MiniMax M2.1",
            "reasoning": false,
            "input": ["text"],
            "cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
            "contextWindow": 196608,
            "maxTokens": 8192
          }
        ]
      }
    },
    "defaults": { "provider": "local", "model": "minimax-m2.1-gs32" }
  }
}

4.6 硬件与安全注意

阅读指引：按「并发规模」选机器见 4.6.1，按「显存/场景」选模型见 4.6.2。

硬件：大上下文+抗提示注入场景下，不必强制 2 台。单台满配 Mac Studio（如 M3 Ultra 512GB 统一内存）即可支撑大模型+长上下文+中等并发；2 台适用于高可用（HA）或负载分担。若选 NVIDIA 方案，多用户高并发见 4.6.1（vLLM + A100 等）。单卡 24GB 仅适合较轻负载且延迟更高。企业按实际并发、可用性与预算选型。
安全：本地/内网模型无云端内容过滤，需靠 System Prompt 限定范围、禁止事项，并开启压缩（compaction）、缩小 agent 权限，降低提示注入影响。具体安全清单见 二、生产环境最佳实践。
审计：与「二、生产环境最佳实践」一致：审计日志、敏感操作人工审批、出口过滤（内网仅放行推理服务地址），容器化与非 root 运行。

4.6.1 约 80 人并发、纯本地模型的 GPU 与硬件建议

部署 OpenClaw + 本地模型、支撑约 80 人同时使用 时，瓶颈在 LLM 推理，网关本身资源需求较小。建议按以下思路选型。

维度	建议
推理后端	生产环境优先用 vLLM（或 LiteLLM 代理 vLLM），不建议用单机 Ollama 扛 80 并发。vLLM 的 PagedAttention + 连续批处理在高并发下吞吐通常为 Ollama 的 3–6 倍，且 128+ 并发时 Ollama 易不稳定。
模型规模与显存	7B 级：FP16 约 14GB，INT4 约 3.5GB；70B 级：FP16 约 140GB，INT4 约 35GB。需为 KV 缓存和 batch 预留显存，上下文越大（如 OpenClaw 推荐 64k–196k）预留越多。
GPU 配置（80 人并发）	• 7B/13B 级模型：2× NVIDIA A100 40GB 或 1–2× A100 80GB，用 vLLM 做 continuous batching，可支撑约 80 并发、延迟可接受。 • 30B–70B 级模型：2× A100 80GB（NVLink）或 4× A100 40GB/80GB 做张量并行；若要 50+ 并发且低延迟，考虑 2× H100 80GB 或 4× A100 80GB。 • 单卡 24GB（如 RTX 4090）：仅适合轻负载或 10 人以内；80 人会出现排队与高延迟，不推荐。
参考数据	vLLM 在单卡 A100-40GB 上 256 并发约 793 TPS、P99 约 80ms；Ollama 同条件约 41 TPS、P99 约 673ms。80 并发下通常需 2–3 张 A100（或等价算力）视模型与上下文而定。
其他硬件	网关/应用层（与推理分离时）：8 核 CPU、16GB 内存、50GB 磁盘通常足够。推理机：按 GPU 数量配足 CPU 与内存（如 2×A100 建议 32 核+、128GB+）；系统盘与日志建议 SSD。

小结：80 人、本地模型、生产可用 → 推荐 2× A100 40GB 或 1–2× A100 80GB + vLLM（7B/13B）；若选 70B 级或更大上下文 → 2–4× A100 80GB 或 2× H100 80GB，并配合 vLLM 张量并行与 max-num-seqs 等参数调优。

4.6.2 本地模型推荐（OpenClaw / Agent 场景）

OpenClaw 作为智能体框架，对模型的工具调用稳定性、长上下文、少幻觉要求高；社区共识 <14B 不推荐，14B–32B 起步，32B+ 更稳。以下为当前可本地部署的推荐（含最新 Qwen3.5 说明）。

模型	说明	显存建议	适用场景
Qwen3-Coder 32B	工具调用最稳定，极少乱调用/漏参数；Ollama: `qwen3-coder:32b`	24–32GB（q4/q5 量化）	首选：Agent/工具调用、编码任务
Qwen3 32B	通用能力强，长上下文支持好；Ollama: `qwen3:32b`	24–32GB（q4_K_M 约 20GB）	通用对话 + 工具调用
Qwen3 72B	接近云端强模型水准	48GB+（q4 量化）	硬件充足时的顶配本地
GLM-4.7-Flash	30B 级，工具调用精准，听话度高	24–32GB	与 Qwen3-Coder 32B 并列为「本地最强组合」备选
DeepSeek-R1 32B	推理与编码强；Ollama: `deepseek-r1:32b`	24–32GB	复杂推理、代码、工具使用
Llama 3.3 70B	Meta 最新，多功能与工具支持好	48GB+	多卡或 80GB 单卡
GPT-OSS 20B / 120B	专为 Agent 设计，工具调用干净	20B 约 24GB；120B 需 40GB+	Agent 专用、追求工具格式稳定

关于 Qwen3.5（2026 年 2 月发布）

Qwen3.5-397B-A17B：阿里开源，MoE 架构（总参数 397B，激活约 17B），原生多模态，在 MMLU-Pro、GPQA、IFBench 及 Agent 基准上表现优异；显存占用较前代降约 60%，长上下文吞吐提升明显。
本地部署现状：权重已在 HuggingFace / 魔搭开放，但全精度体量极大（约 800GB 级），8× H100 仍易 OOM；vLLM 需等 MoE 与量化支持完善，Ollama 尚未官方支持该架构。
建议：当前优先用 Qwen3 32B / Qwen3-Coder 32B 或 GLM-4.7 做本地部署；Qwen3.5 可关注官方或社区的 FP8/INT8 量化版 及 vLLM/Ollama 支持更新后再上本地；若需最强效果且可接受云端，可先用 通义 API（Qwen3.5 定价较低） 作混合方案。

按显存快速选型（与上表对应）

8–16GB：qwen3-coder:14b 勉强可用，需调优 prompt 与温度。
24–32GB：qwen3-coder:32b 或 glm-4.7-flash，强烈推荐。
40GB+：qwen3:72b、gpt-oss:120b 或 Llama 3.3 70B。

使用建议：温度建议 0 或 0.1–0.2 以降低幻觉；优先 q4_K_M / q5_K_M 量化以兼顾速度与显存；上下文尽量 32k+（Qwen3、GLM-4.7 支持良好）。

4.7 参考

官方本地模型文档：Local Models、本地模型（中文）
Ollama 集成：Ollama - OpenClaw；Ollama 模型库（拉取 qwen3、glm 等）
配置参考：~/.openclaw/openclaw.json 见 Configuration Reference
推理与并发（对应 4.6.1）：vLLM 文档、LiteLLM 代理
模型与权重（对应 4.6.2）：Qwen 系列、Qwen3.5

五、LLM 路由：按场景使用本地与远端模型

OpenClaw 支持多种与模型选择相关的机制，但并非都能实现「根据场景判断用本地还是外部模型」，需区分清楚。

5.1 主模型 + 备用模型（Primary + Fallbacks）— 不能按场景判断

同一 Agent 可配置「主模型 + 备用模型」：仅在主模型失败时（超时、限流、鉴权失败）自动切换到下一个模型。

不能实现：根据「任务类型、是否敏感、复杂度」等场景主动选择本地或远端；只是故障时的自动切换。
配置项：agents.defaults.model.primary、agents.defaults.model.fallbacks（数组，按顺序尝试）。
需同时配置多个 provider（如 ollama 与 openai），并设 models.mode: "merge"。

示例：Ollama 为主，GPT 为备用（仅失败时切到 GPT）

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "ollama/llama3.2:latest",
        "fallbacks": ["openai/gpt-4o"]
      }
    }
  },
  "models": {
    "mode": "merge",
    "providers": {
      "ollama": {
        "baseUrl": "http://127.0.0.1:11434/v1",
        "apiKey": "ollama",
        "api": "openai-responses",
        "models": [{ "id": "llama3.2:latest" }]
      }
    }
  }
}

5.2 多 Agent + Bindings — 仅能按「入口」路由，不能按内容/任务类型

通过 多 Agent + 绑定（bindings），可让不同通道/账号/会话使用不同默认模型。

能实现：按「从哪个渠道进来」固定用哪个模型，例如 WhatsApp 一律用 Ollama、Telegram 一律用 GPT。
不能实现：同一条对话里，根据「这句话是否涉及敏感数据、是简单还是复杂」动态选本地或外部模型；bindings 只看 channel/accountId/peer，不看消息内容。

配置：agents.list[].model 为每个 Agent 的默认模型；bindings 按 channel、accountId、peer 决定消息进哪个 Agent。

示例：按通道固定模型（入口级路由）

{
  "agents": {
    "list": [
      { "id": "chat", "name": "日常", "workspace": "~/.openclaw/workspace-chat", "model": "ollama/llama3.2:latest" },
      { "id": "deep", "name": "深度", "workspace": "~/.openclaw/workspace-deep", "model": "openai/gpt-4o" }
    ]
  },
  "bindings": [
    { "agentId": "chat", "match": { "channel": "whatsapp" } },
    { "agentId": "deep", "match": { "channel": "telegram" } }
  ]
}

5.3 真正的「按场景判断」调用本地或外部模型

若需求是：根据对话内容、任务类型或是否涉及敏感数据，在单次请求前决定用本地还是远端模型，目前官方能力与可行做法如下。

能力	说明
Plugin 钩子 `before_prompt_build` 返回 `modelOverride`	社区 PR 已实现：在构建 prompt 前根据上下文返回 `modelOverride`/`providerOverride`，即可实现「按会话/上下文动态选模型」。需自行或通过插件实现「场景判断逻辑」（如简单规则或小模型分类）。合并进度与 API 以官方 plugins、Hooks 及主仓 PR 为准。
Webhook 调用时传 `model`	若请求由自有系统发起（如 `POST /hooks/agent`），可在请求体里带 `model` 覆盖本次使用的模型；场景判断在调用方，OpenClaw 只按传入的 model 调用。
外部路由层	在 OpenClaw 前加一层路由：先根据规则或分类决定「本次用本地还是云端」，再转发到对应模型或不同 Agent；OpenClaw 本身不负责「按内容判断」。

小结：主模型/备用模型只能做失败切换，不能做按场景判断；按场景判断需依赖「入口级多 Agent」、插件钩子返回 modelOverride，或调用方/外部路由在请求前决定模型。

5.4 小结

方式	能否「按场景判断用本地/外部」	说明
Primary + Fallbacks	否	仅主模型失败时切换，不根据场景主动选择
多 Agent + Bindings	仅按入口	按 channel/account/peer 固定模型，不按内容或任务类型
Plugin `before_prompt_build` → modelOverride	是（需插件/合并后）	可根据上下文在请求前动态指定模型
Webhook 传 model / 外部路由	是	由调用方或前置服务做场景判断并指定模型

5.5 参考

Model Failover — 回退与鉴权轮转（仅失败时切换）
Multi-Agent Routing — 多 Agent 与 bindings（按入口路由）
Model Providers — Provider 与 Ollama/OpenAI 等配置
Hooks、Plugins — 插件钩子与可能的 modelOverride 能力

六、多 Agent 与 Agent 间互相调用

结论：支持。 OpenClaw 支持多 Agent、为不同 Agent 配置不同 LLM，且 Agent 之间可以互相调用（发消息、派发子任务）。

6.1 多 Agent 与每 Agent 独立 LLM

多 Agent：在 agents.list 中配置多个 Agent，每个 Agent 有独立 id、workspace、agentDir、会话存储（~/.openclaw/agents/<agentId>/sessions）。
每 Agent 独立模型：每个 Agent 可配置自己的默认模型，例如 agents.list[].model（如 ollama/llama3.2、openai/gpt-4o）。未设置时继承全局 agents.defaults.model。
入站路由：通过 bindings 按 channel/accountId/peer 将消息路由到对应 Agent（见第五节）。

6.2 Agent 之间互相调用的两种方式

方式	工具	说明
发消息到对方会话	`sessions_send`	Agent A 向 Agent B 的某个 session 发送一条消息，触发 B 的一次运行；支持 ping-pong 式多轮回复（由 `session.agentToAgent.maxPingPongTurns` 控制，0–5，默认 5），以及结果回传（announce）。
派发子任务到对方 Agent	`sessions_spawn` + `agentId`	Agent A 发起一次子任务，指定 `agentId: "B"`，则该任务在 Agent B 的上下文中执行（用 B 的 workspace、B 的模型），结果通过 announce 回传给 A。需在 B 的配置中允许被 A 调用（见下）。

6.3 启用 Agent 间调用的配置

允许 Agent 互发消息：默认关闭，需显式开启并设置白名单：
```
"tools": {
  "agentToAgent": {
    "enabled": true,
    "allow": ["home", "work"]
  }
}
```
allow 为可参与互调的 Agent id 列表（双方都需在名单内或通过可见性看到对方 session）。

允许某 Agent 被其他 Agent 派发任务：在目标 Agent 上配置 subagents.allowAgents，例如只允许 main 派发任务给 work：

"agents": {
  "list": [
    { "id": "main", "workspace": "...", "model": "ollama/llama3.2" },
    {
      "id": "work",
      "workspace": "...",
      "model": "openai/gpt-4o",
      "subagents": { "allowAgents": ["main"] }
    }
  ]
}

若允许任意 Agent 派发："allowAgents": ["*"]。未配置时默认仅允许同 Agent 自己 spawn。

子任务用不同模型：sessions_spawn 可传 model 覆盖本次子任务使用的模型；也可在 agents.defaults.subagents.model 或 agents.list[].subagents.model 中为子任务设置默认模型（常用来用更便宜的模型跑子任务）。

6.4 相关能力简述

Sub-Agent（sessions_spawn）：子任务在独立 session（agent::subagent:<runId>）中运行，默认不持有 session 类工具（避免递归）；完成后通过 announce 将结果回传到发起方所在会话。支持嵌套（如 maxSpawnDepth: 2 时，一层子 Agent 可再 spawn 二层子 Agent）。
Session 工具：sessions_list、sessions_history、sessions_send、sessions_spawn 等由 tools.sessions / tools.subagents 及可见性（如 visibility: "tree" | "agent" | "all"）控制；跨 Agent 发消息还受 tools.agentToAgent 约束。

6.5 参考

Multi-Agent Routing — 多 Agent 配置与 bindings
Sub-Agents — sessions_spawn、嵌套、model/thinking 覆盖
Session Tools — sessions_send、sessions_spawn、agentToAgent 行为

七、参考链接汇总

类别	链接
官方 Skills 文档	https://docs.openclaw.ai/tools/skills
ClawHub 技能市场	https://clawhub.com
Skills 配置参考	https://docs.openclaw.ai/tools/skills-config
安全与沙箱	https://docs.openclaw.ai/gateway/security、https://docs.openclaw.ai/gateway/sandboxing
本地/内网模型	https://docs.openclaw.ai/gateway/local-models、https://docs.openclaw.ai/zh-CN/gateway/local-models
LLM 路由 / 回退 / 多 Agent	https://docs.openclaw.ai/concepts/model-failover、https://docs.openclaw.ai/concepts/multi-agent、https://docs.openclaw.ai/concepts/model-providers
多 Agent 互调 / Sub-Agents / Session 工具	https://docs.openclaw.ai/concepts/multi-agent、https://docs.openclaw.ai/tools/subagents、https://docs.openclaw.ai/concepts/session-tool
Ollama 集成	https://docs.ollama.com/integrations/openclaw
飞书通道	https://docs.openclaw.ai/zh-CN/channels/feishu
社区技能索引示例	https://openclawskills.org、https://openclawskills.dev

说明：落地场景与案例来自社区文章与用户实践总结；安全与最佳实践参考 2026 年生产部署与安全清单；Skills 数量与 ClawHub 地址以官方文档与当前站点为准。

一、落地场景与实战案例​

1.1 社交与信息管理​

1.2 创意与内容生产​

1.3 办公效率提升​

1.4 健康与生活管理​

1.5 研究与知识管理​

1.6 开发与运维​

1.7 核心优势总结​

二、生产环境最佳实践与安全清单​

2.1 安全形势（2026）​

2.2 网络安全​

2.3 凭证与密钥管理​

2.4 Agent 与 Skills 配置​

2.5 审计与运维​

2.6 部署方式选择​

三、Skills 体系概览​

3.1 能力分层​

3.2 加载位置与优先级​

3.3 ClawHub 与安装方式​

3.4 三大核心 Skills（入门必装）​

3.5 Top 10–20 必装清单（按梯队）​

3.6 Skills 使用最佳实践​

四、企业内网与私有化部署（不使用外部大模型）​

4.1 为什么可以完全不用外部 API​

4.2 常见内网推理方案​

4.2.1 LiteLLM、vLLM、Ollama 介绍与对比​

4.3 配置要点（仅用内网模型）​

4.4 示例：仅用 Ollama（纯本地）​

4.5 示例：仅用内网 LM Studio / 自建 v1 服务​

4.6 硬件与安全注意​

4.6.1 约 80 人并发、纯本地模型的 GPU 与硬件建议​

4.6.2 本地模型推荐（OpenClaw / Agent 场景）​

4.7 参考​

五、LLM 路由：按场景使用本地与远端模型​

5.1 主模型 + 备用模型（Primary + Fallbacks）— 不能按场景判断​

5.2 多 Agent + Bindings — 仅能按「入口」路由，不能按内容/任务类型​

5.3 真正的「按场景判断」调用本地或外部模型​

5.4 小结​

5.5 参考​

六、多 Agent 与 Agent 间互相调用​

6.1 多 Agent 与每 Agent 独立 LLM​

6.2 Agent 之间互相调用的两种方式​

6.3 启用 Agent 间调用的配置​

6.4 相关能力简述​

6.5 参考​

七、参考链接汇总​