OpenClaw 是什么 #

定义 #

• 产品层：是一个为个人服务的 AI Agent，能聊天、问答、以及自主规划完成复杂的任务，有长久的记忆机制。
• 运行层：是一个24小时运行的服务，通过多种 Channel 提代沟通渠道，可以远程发送指令。
• 实现层：是一npm包，通过Node.js运行，提供 openclaw onboard、openclaw gateway status、openclaw dashboard 这类命令进行控制和交互，是一个完整运行系统。

一句话理解 #

• OpenClaw = 用 Gateway 把消息接进来，用 Agent Runtime 把上下文和工具串起来，再用 Workspace/Memory 让 AI 变成一个能长期运行、完成任务的助手。

总体架构和工作流程 #

flowchart LR
    U[用户发起：<br/><br/>Channels<br/>WebChat<br/>CLI]

    X[外部调用：<br/><br/>Webhooks]

    I[内部触发：<br/><br/>Cron<br/>Heartbeat<br/>Hooks<br/>Sub-agent]

    U --> G[统一入口<br/>Gateway]
    X --> G
    I --> G

    G --> R[路由<br/>Binding / Routing]
    R --> Q[队列<br/>Session / Lane Queue]
    Q --> A[上下文组装<br/>Agent Runtime]
    A --> P[推理执行<br/>Agent Loop]
    P --> O[输出<br/>Output]

主要概念一览 #

入口与触发 #

网关与调度 #

会话与状态 #

Agent 运行 #

能力与知识 #

自动化与协作 #

Workspace 介绍 #

• Workspace 是 OpenClaw 很核心的设计，几乎存储了所有的信息：你对Agent的要求、你自己的信息、按天记录的日志等。
• 通常位于: ~/.openclaw/workspace 目录下，也可以改名字，或有多个workspace

主要预定义 MD 文件 #

Memory 文件 #

• MEMORY.md：长期、稳定、值得反复带上的记忆。
• memory/YYYY-MM-DD.md：每天的日志式短期记忆。

一些最佳实践 #

• 通常一个Channel对应一个Agent，但多个Agent可以共享同一个Workspace
• 如果有多人使用的话，建议建多个Workspace

注意：完整的对话记录不存在Workspace里 #

• 完整对话历史存在 ~/.openclaw/agents/<agentId>/sessions/*.jsonl

• 这更像原始 transcript，而不是“精炼知识”
• 官方文档也强调，必要时可以对 transcript 做删除或清理，减少敏感信息残留
• 最新版本的OpenClaw，似乎支持单条信息删除（如果不小心把敏感信息发给它了的话）

模型调用时的上下文组装 #

一个重要事实：上下文由Agent管理，模型不存储上下文 #

• 一个比喻：模型是一个N层（比如96层）高的，每一层内部都巨复杂通路的大楼，N（哪怕是50K）个Token一起从第一层进入，到顶层出来，输出一个Token，工作结束。下一次是同样的过程，没有状态，不保存任何信息。计算量会有差异，主要在于KV Cache机制的存在，会减少第2次和第N次的工作量
• 每次的输入和输出是无状态的，每次相同的输入，输出的结果高概率是相似的（实际会有所不同，和模型的算法相关）

上下文组装 #

• 每次 Run 前，OpenClaw 会先组装上下文，按照官方文档，这个上下文有：
  • 当前工具和工具规则
  • workspace 路径和环境信息
  • 可用 skills 的入口
  • 安全提醒
  • 时间、时区、运行时元数据
  • heartbeat / reply tags 之类的运行约定
  • 注入的工作区文件内容
• 其中工作区文件内容也需要组装如下

┌─────────────────────────────────────────────────────────┐
│  完整上下文 (Full Context)                              │
│                                                         │
│  [System Prompt]  ← 固定保留                            │
│  [SOUL.md]        ← 通常保留                            │
│  [USER.md]        ← 通常保留                            │
│  [TOOL.md]        ← 通常保留                            │
│  [Recent Messages] ← 高优先级保留                       │
│  [Older Messages]  ← 可能被压缩/丢弃                    │
│  [Memory Snippets] ← 按需检索                           │
└─────────────────────────────────────────────────────────┘

• 最后还要加入用户本次的真实输入
• 所以每一次的模型调用，实际输入内容远多于用户输入的“Prompt”

上下文压缩（接近上限或手动夺缩时） #

┌─────────────────────────────────────────────────────────┐
│  完整上下文 (Full Context)                              │
│                                                         │
│  [System Prompt]  ← 固定保留                            │
│  [SOUL.md]        ← 通常保留                            │
│  [USER.md]        ← 通常保留                            │
│  [TOOL.md]        ← 通常保留                            │
│  [Recent Messages] ← 高优先级保留                       │
│  [Older Messages]  ← 可能被压缩/丢弃                    │
│  [Memory Snippets] ← 按需检索                           │
└─────────────────────────────────────────────────────────┘
	                      │
                          ▼  接近上限时
                          │
┌─────────────────────────────────────────────────────────┐
│  压缩后上下文 (Compressed Context)                      │
│                                                         │
│  [System Prompt]  ✅ 100% 保留                           │
│  [SOUL.md]        ✅ 100% 保留 (通常)                    │
│  [USER.md]        ✅ 100% 保留 (通常)                    │
│  [Recent 10-20 条对话] ✅ 保留                           │
│  [Older Messages]  ⚠️ 压缩成摘要或丢弃                   │
│  [Memory Snippets] ⚠️ 只保留最相关的                     │
└─────────────────────────────────────────────────────────┘

LLM 注意力分布（简化） #

Token 位置：[  开头  ]──────[  中间  ]──────[  结尾  ]
                │               │               │
注意力强度：  ██████░░░░░░░░░░░░░░░░░░░░░░░░░░██████
            ↑                  ↑                  ↑
           高                 低                 高

• Lost in the middle

优化策略（尽可能确保重要Prompt有用） #

• 关键信息放上下两头
• 分层加载（按需加载）
• 重复关键信息
• md文件不要写太长，尽量写在前面
• 标记重要内容: 特殊标记（⚠️、🔴、加粗）能吸引注意力

## ⚠️ 核心规则（必须遵守）
1. 不要删除文件
2. 外部操作前确认

## 一般规则
- 保持友好
- 详细解释

对话中的技巧 #

用户：记住，永远不要用 rm 命令

Agent: 好的，我记住了：不使用 rm 命令

[后续对话中偶尔提及]
用户：刚才说的 rm 的事...
Agent: 对，我会用 trash 代替 rm
原理： 在对话中重复，让规则进入"最近对话"区域（高注意力）

Memory 注入过程 #

• Memory 不是每次全量注入，而是按需召回。过程：
  1. 先从 Memory 里检索与本次输入相关的片段（RAG）
  2. 再把相关片段作为对话历史放进本次上下文
  3. 检过出来的对话历史优先级高于其它对话记录（与最近10-20条比谁高谁低未知，大概率是放一起）

RAG 检索简介 #

• 一个核心事实：RAG（检索增强生成）通常在本地完成。现代 AI Agent（如 OpenClaw）会内置轻量级的 Embedding（向量化）模型和本地向量数据库（如 SQLite-vec）。
• RAG 的核心运转过程：
  • 存入数据 (Embedding)：系统将冗长的对话历史或文档切分成一个个小的“文本块”(Chunk)。轻量级模型将这些文本块转化为高维数字向量（通常在 1024 维左右）并持久化存入本地磁盘
  • 取出数据 (Retrieval)：当用户提问时，系统瞬间将新问题也变成向量，去数据库中寻找“数学距离”最接近的历史记忆块
• 计算复杂度极低：
  • 假设我们沉淀了 10,000 个记忆文本块，每个向量 1,000 维
  • 即使采用最基础的暴力比对，计算量也仅约 1,000 万次乘法，对于现代计算机（CPU 每秒可执行千亿次运算），1,000 万次计算不到 0.1 毫秒
  • 现代向量数据库的索引算法加持，检索过程可以说是字面意义上的“瞬间完成”
• 持久记忆的本质：
  • 无论用户和 Agent 聊了几个月，积累了多少 Markdown 数据，系统都能在瞬间精准捞出最相关的“记忆切片”
  • 这些切片会被当做高价值的上下文（Context）喂给大模型。既实现了用户的“无限记忆”体验，又完美避开了大模型每次全量读取历史记录带来的高昂 Token 成本和响应延迟

大模型记算复杂度 #

0. 背景假设：物理大楼的“出厂设定” #

• 模型全貌：总参数 500B（5000 亿），物理结构为 96 层楼。
• 单层结构：每一层楼包含两个核心部门。
  • 部门 A（多头注意力机制）：负责跨 Token 看上下文。
  • 部门 B（MoE 专家网络）：负责推理。包含多个专家，但每次只激活部分。
• 向量维度（Dimension）：每个 Token 在进入大楼前（大堂安检），会被查表转换为 4096 维的密集浮点数向量。这 4096 个数字蕴含了该词的初始语义，并且这 4096 个维度的矩阵将贯穿整个 96 层大楼的全部计算过程。
• 算力基准：对于每一次流经这 96 层大楼的计算，真正通电干活的“激活参数量”永远固定为 30B（300 亿）。
• 行业通用公式：大模型处理 Token 的单次计算量（浮点运算次数 FLOPs）粗略估算为：2 × 激活参数量 × Token 数量。

1. Prefill（预填充）阶段：50,000 个 Token 一次性输入 #

• 运行过程：这是“一目十行”的并行处理阶段。50,000 个 Token（各自携带着 4096 维的特征向量）同时涌入大楼，并行爬完 96 层。在每一层的注意力部门里，它们互相交换信息，并将所有中间状态写成厚厚的“草稿纸”（即 50K 的 KV Cache）存入显存。接着经过专家部门，被 Router 动态分配给对应的 30B 专家处理。
• 计算量估算：2 × 300亿 (激活参数) × 50,000 (Token数) = 3,000 万亿次浮点运算（即 3,000 TFLOPs）。
• 硬件感知：这是一个纯粹的算力密集型任务。对于现代顶级显卡（如单卡算力近千 TFLOPs 的 Nvidia H100），3,000 TFLOPs 的绝对计算量并不夸张，几秒钟内就能满载轰完。

2. 输出第 1 个字（Token 50,001） #

• 运行过程：这是“挤牙膏”式串行生成的起点。基于前 50,000 个词形成的最终语义，模型在顶层预测出第 1 个字。为了让这个字能继续参与后续推理，这个新 Token 会单独带着自己的 4096 维向量重新爬一次 96 层楼。在每一层，显卡必须把之前存好的 50,000 个词的 KV Cache 完整搬运出来给它核对，它再把自己的信息追加进去，最后激活 30B 专家进行推理。
• 计算量估算：2 × 300亿 (激活参数) × 1 (Token数) = 600 亿次浮点运算（即 60 GFLOPs）。
• 硬件感知：纯数学计算量极低，但开始受到内存带宽的严重挤压（因为伴随了一次 50K 级别大容量缓存的完整显存读取）。

3. 输出第 2 个字（Token 50,002） #

• 运行过程：过程与第 1 个字完全相同，只是背负的“历史包袱”又重了一点。预测出第 2 个字后，这个字再次回到一楼单独爬楼。在每一层，显卡需要搬运出 50,001 个词的 KV Cache（比上一步多了一层厚度），追加自己的信息后，再次激活 30B 专家推理。
• 计算量估算：依然是 2 × 300亿 × 1 = 600 亿次浮点运算（即 60 GFLOPs）。
• 核心结论：无论生成第几个字，单次的计算量永远死死钉在 60 GFLOPs。但每多生成一个字，显存搬运到计算核心的数据量就会变得更大。

4. 商业云端算力推演：倒推大厂提供服务的真实硬件成本（FP16 满血版） #

如果这是云厂商（如阿里云、火山引擎）提供的 API 服务，为了保证生成质量，模型通常运行在标准 FP16（16位半精度）环境下。要求单并发达到 50 Token/秒，我们来算一算大厂背后要扛多大的硬件成本。

• A. 显存容量评估（极其恐怖的 VRAM 需求）：

  • 装下 500B 的模型：FP16 格式下每个参数占 2 Bytes。5000亿 × 2 Bytes = 1000 GB = 1 TB 纯模型权重！
  • 装下 50K 的 KV Cache 草稿纸：预留约 30 GB 显存。
  • 系统与框架冗余：预留约 50 GB。
  • 容量结论（大厂的痛点）：总计需要约 1080 GB（1.08 TB）显存。 以目前最主流的顶级企业级算力 Nvidia H100（单卡 80 GB 显存）为例，一台标准的 8 卡服务器总显存只有 640 GB，根本装不下！大厂必须横跨两台物理服务器，动用 14 到 16 张 H100 80G 显卡（约合 40-50 万美金的硬件成本），才能把这个模型勉强拉起来。

• B. 显存带宽评估（极其奢侈的算力闲置）：

  • 搬运 1 个字的数据量：激活的 30B 权重（FP16 下约 60 GB）+ KV Cache（约 30 GB） = 90 GB 数据量。
  • 达到 50 字/秒的吞吐量：每秒必须搬运 90 GB × 50 次 = 4,500 GB/s（即需要 4.5 TB/s 的实际内存带宽）。
  • 带宽结论（有趣的商业悖论）：为了满足 1 TB 的容量，大厂被迫用了 16 张 H100。而这 16 张卡拼在一起的理论峰值带宽高达 50 TB/s，远远超出了 4.5 TB/s 的需求。
  • 商业启示：在逐字生成（Decode）阶段，那 16 张天价显卡的计算核心（CUDA）90% 的时间都在喝茶等数据，算力被极度浪费，但大厂又无可奈何（因为少一张卡，显存就爆了）。这就解释了为什么大模型 API 的定价这么高，以及为什么各家厂商都在拼命研发 PagedAttention (vLLM) 和 Context Caching 等技术——都是为了榨干内存，多接客来平摊这 16 张卡的沉没成本。

5. 商业启发：为什么大模型 API 的定价如此复杂？ #

• 定价维度一：为什么“输出 Token”永远比“输入 Token”贵好几倍？
  • 输入（Prefill 阶段）：是并行计算，算力密集型。GPU 上的几万个核心同时满载开火，几秒钟就能轰完几万字。对大厂来说，这极大地提高了硬件的利用率，所以输入极其便宜。
  • 输出（Decode 阶段）：是串行计算，内存带宽瓶颈。为了吐出一个字，十几张天价显卡的计算核心只能闲置着，苦苦等待几十 GB 的 KV Cache 从显存搬运过来。输出占用了极长的物理时间，拉低了服务器的接客率（并发吞吐量），所以必须卖得极其昂贵。
• 定价维度二：为什么会推出“上下文缓存命中（Prompt Caching）”且打骨折价？
  • 物理真相：如果系统发现你这次传来的 50K 背景资料，和上一秒传来的一模一样（比如你在反复修改同一篇长文档）。大厂的服务器根本不需要再去算那 3000 TFLOPs 的矩阵乘法，因为这 50K 的 KV Cache 草稿纸还热乎乎地躺在显存里没删！
  • 商业逻辑：直接跳过最耗算力的 Prefill 阶段，直接进入 Decode 阶段。大厂省下了巨额的电费和算力，所以立刻给你“缓存命中（Cache Hit）”打 5 折甚至 1 折。这本质上是在用低价诱导用户多用缓存，从而减轻服务器的算力压力。
• 定价维度三：为什么超长上下文（如 > 128K）单价会突然飙升？
  • 物理真相：正如我们前面所算，50K 的 KV Cache 大约占 25GB 到 30GB 显存。那如果是 200K 呢？这就意味着仅仅为了服务你这一个请求，就要在显卡里硬生生划出 100 GB 以上的显存来存放你的专属草稿纸。
  • 商业逻辑（机会成本）：一台 8 卡 H100 服务器总共才 640GB 显存。你一个人占了 100GB，意味着原本能同时接待 20 个短文本用户的服务器，现在只能接待你和另外 4 个人。超长上下文挤占了极其宝贵的显存容量池（VRAM），导致大厂能卖出去的并发数断崖式下跌。 所以，超过一定长度后，大厂必须收你极高的“显存占地费”。
• 产品设计启示（回归 OpenClaw 架构）**： 这就是为什么我们在设计 OpenClaw 这种 Agent 架构时，必须死磕 RAG（检索）和 Memory（记忆压缩）机制。如果我们像个小白一样，把用户半年的聊天记录几十万字毫无节制地全塞进 Prompt 里每次重算，那无论是调云端 API 还是跑本地显卡，要么账单爆炸，要么内存撑爆。用工程手段（精准备考）代替纯模型（死记硬背）！

6. 关于模型调用定价实例 #

• 输入输出价格不同、不同上下文长度价格不同、是否命中缓存价格不同
• qwen3.5 plus ![[Pasted image 20260315112541.png]]
• Opus 4.6 *![[Pasted image 20260315112808.png]]
• GPT5.4 Pro ![[Pasted image 20260315112711.png]]
• 以最小输入算对比，三者价格对比约为：1:40:240
• GPT5.4 Pro的输出价格高的离谱。。。

高上下文主要发生在重任务，不主要发生在长寿命会话本身 #

• 因为系统通常只会保留：
  • system prompt
  • 关键 workspace 文件
  • 最近对话
  • 按需召回的 memory（RAG）
• 而不是把几个月的全部历史每次都重新塞进去。
• 所以“聊得久”不等于“每次都超长上下文”。
• • 真正容易爆成本的是“长上下文 + 长输出”的任务，比如写代码、生成长文档。

• 成本优化也不只是看模型单价，还要看缓存、上下文复用、是否做检索而不是全量拼接。

OpenClaw的Session处理逻辑 #

• Session过期：默认网关地凌晨4点重置Session，当然还有一个idleMinutes配合，保证不会无条件重置
• auto-compaction：当 session 接近或超过模型上下文窗口时，它会自动把旧历史做摘要压缩，并用压缩后的上下文重试当前请求。官方还明确区分了：compaction 是“总结并持久化”，而不是简单丢弃
• pre-compaction memory flush：提醒模型把“值得长期保留的信息”写入 memory 文件，再去压缩上下文
• session pruning：在每次 LLM 调用前，从内存中的上下文里裁掉旧工具输出

Agent Runtime： OpenClaw 管平台与上下文，PI 管 Agent Loop 与工具执行 #

• OpenClaw并没有手搓关键的agent-loop部分，而是引入了PI
• 准确地说：OpenClaw 是 agent runtime 平台层，PI 是被嵌入进去的 loop engine
• 作为对照：ZeroClaw则是全新实现了agent-loop部分，说是别人的框架都比较臃肿，得重新发明轮子
• 工作流程：

flowchart TD
    A["用户 / Telegram / Discord"] --> B["OpenClaw Gateway"]

    subgraph OC["OpenClaw"]
        B --> C["Session / Routing / Context / Prompt"]
        C --> D["Embedded PI"]
        E["Streaming reply + Persistence"]
    end

    subgraph PI["PI Runtime"]
        D --> F["LLM loop + Tool execution"]
    end

    F --> E

PI框架：一个极简概念的coding-agent框架 #

• 只有4个基本工具：Read、Write、Edit、Bash
• 所有其它任务靠这4个工具堆起来，比如调用Bash，或写一个脚本用Bash执行
• 主要功能：

OpenClaw 原生 和 PI 的分工 #

PI干了什么脏活累活 #

1. LLM 适配与兼容层 #

1. 统一多家 LLM provider 和模型接口
   pi-ai 提供统一的 multi-provider LLM API，上层不用为 OpenAI、Anthropic、Google 等分别写一套调用逻辑。
2. 处理不同 provider 的请求细节和兼容差异
   包括默认 headers、认证方式、请求格式差异，以及请求发出前的 payload 检查和改写。
3. 模型选择、切换、恢复和 provider-agnostic model switching
   运行时需要支持模型切换、恢复默认模型，以及在不同 provider 之间做统一抽象。

2. 工具调用与 Agent Loop 执行层 #

1. 真正驱动 agent loop
   不只是发一次模型请求，而是持续完成“发给 LLM → 执行工具 → 回注结果 → 继续下一轮”直到结束。
2. 把工具定义适配成模型能消费的格式
   需要桥接不同工具接口的定义方式，例如 name、description、parameters、execute 等签名差异。
3. 管理工具执行的时序、并发和结果顺序
   工具可以并行执行，但预处理、状态更新和最终结果顺序仍要保持稳定和可预期。
4. 动态注册工具，并确保 LLM 立刻看见新工具
   即使在 session 已启动后新增工具，也要能及时刷新并对模型可见，不要求手动重载。

3. 输出事件流与结果后处理 #

1. 暴露完整事件流，方便流式 UI、调试和编排
   包括 turn_start、message_update、tool_execution_start/end、agent_end 等事件。
2. 处理工具的部分输出、错误结果和持续回注
   工具不只是成功/失败两态，还可能有中间输出、部分结果、错误结果，都要被接住并继续喂回 loop。
3. 保证持久化顺序和会话恢复正确性
   assistant 消息、tool call、tool result 的顺序必须一致，否则恢复 session 时容易出错。

4. 报错恢复与运行时稳态控制 #

1. 自动重试、等待和错误恢复
   要处理 rate limit、server error、internal error 等场景，而不是一报错就直接中断。
2. 异常后的结果修剪与状态收敛
   当某轮工具失败、返回格式异常、结果过长或顺序错乱时，runtime 要能做清理、裁剪、修复和重新进入稳定状态。
3. 循环退出与终止条件控制
   要判断什么时候继续下一轮，什么时候正常结束，什么时候因报错、中断、取消或达到条件而退出 loop。

5. Session 持久化与上下文管理 #

1. 会话生命周期和持久化
   包括 session 创建、恢复、分支、持久化，以及下一轮如何延续当前状态。
2. 上下文压缩、分支总结、文件读改历史追踪
   不只是简单截断上下文，还要记录读过哪些文件、改过哪些文件，并在压缩后保留足够可恢复信息。

本章小结和启发 #

• OpenClaw 将 PI 作为 Agent Loop 的关键执行内核嵌入进来；两者分工配合，完成最核心的 loop：OpenClaw 更偏平台与上下文运行时，PI 更偏 LLM loop 与工具执行
• **Agent Loop 这类能力已经有比较成熟的框架可选；除非需求非常窄、流程非常固定，否则一般不建议手搓，优先选成熟框架更稳。可选的有以下，他们都已经在把持久化、流式、工具循环、人类介入等能力做成现成抽象：
  • LangGraph：Python、复杂长流程
  • Mastra：TypeScript、想一体化 agent/workflow/evals/server
  • 厂商绑定的：OpenAI Agents SDK、Claude Agent SDK
  • PI、AI SDK ToolLoopAgent、CrewAI等等。

HeartBeat 和 Cron #

• 这两个功能很像，但定位不同。

• 适合 Heartbeat 的：
  • 多个小检查合并执行。
  • 需要结合最近聊天上下文判断轻重缓急。
  • “有事再说，没事别打扰我”的任务。
  • 持续巡视型任务。
• 不适合 Heartbeat、应该交给 Cron 的：
  • 必须精确到某个时间点。
  • 一次性提醒。
  • 很重、很长、最好独立隔离运行的任务。
  • 希望用不同模型、不同 session 单独执行的任务。

Sub-agent：一次任务里的并行/后台协作 #

• 主Agent会把一个复杂任务拆成几个子任务并行处理（提升效率），比如：
  • 一个子 agent 去检索资料
  • 一个子 agent 去读文件
  • 一个子 agent 去依据文档模板生成初稿
• 它的本质不是“多个人格”，而是 临时 worker。
• 如何自动启用Sub-Agent来处理耗时或复杂任务？
  • 手动指定
  • 在Agent.md里定义规则

## Subagent Delegation Policy

收到请求后，先做快速分流，不要立即展开长推理。

首轮只做三选一：
1. 直接回答
2. 在当前 session 内处理
3. 调用 `sessions_spawn`

满足以下任一条件时，优先调用 `sessions_spawn`：
- 预计需要较长时间
- 预计需要多轮检索 / 调查 / 整理
- 预计要调用慢工具
- 任务适合拆成独立子任务
- 不适合长时间阻塞主会话

不要先做长分析或长检索后才决定委派；应尽量在首轮早期完成判断。

调用 `sessions_spawn` 时，给出清晰 task，写明目标、范围、输出格式和边界。

• Agent自己判断（据我测试，几乎没有测到他能自己Spawn一个Sub Agent来工作的）
  • 据说是任务发到LLM后，LLM会依据初步的判断返回一个是否要启用subagent的说明。但这个不保证，也查不到详细资料相关的机制，怀疑这一块官方并没有真的花很大精力设计，或当前仍不完善

Multi-agent：多个长期存在的角色/人格/工作空间 #

• Multi-agent 不是为了炫技，而是为了隔离。，比如：
  • home agent：家庭、个人事务
  • work agent：工作项目
  • public agent：公开回复或对外渠道
• 它的价值主要体现在四种隔离：
  • 角色隔离：人格、语气、规则不同
  • 数据隔离：workspace、sessions、auth profiles 不共享
  • 权限隔离：不同 agent 的工具和 sandbox 策略可以不同
  • 成本隔离：不同 agent 可以使用不同模型和缓存策略
  • 甚至，部分简单功能，用专用Agent绑定本地模型执行，既省成本，也绝对安全
• 为什么需要多 Agent：
  • 有的任务值得用强模型
  • 有的任务只需要本地小模型
  • 有的任务不能接触敏感数据
  • 有的角色不该拥有高风险工具权限
• 所以 multi-agent 更像“组织结构设计”，不是单纯多开几个聊天窗口。

安全机制 #

Trust model：一个 Gateway = 一个信任边界 #

• Gateway 是总控面。谁能接入、谁能发消息、谁能调度任务，本质上都受它控制。
• 所以在 OpenClaw 里，“一个 Gateway”基本就等于“一个信任边界”。

Gateway auth + device pairing #

• 官方文档里 pairing 是显式批准动作，用于：
  • 设备接入
  • 节点配对
  • 私聊用户配对
• 这一步的意义是：不是谁都能直接驱动你的 agent。

Secure DM mode #

• 如果多个用户和一个 bot 交互，而上下文又共用，就可能出现串话风险。
• Secure DM mode 的核心就是让不同私信会话更明确地隔离，减少上下文串台。

Sandbox / tool allow-deny / elevated / exec approvals #

• 这是最现实的一层安全：
  • 工具可以跑在宿主机，也可以跑在 Docker sandbox 里
  • 可以定义哪些工具允许，哪些禁止
  • 某些高风险操作可以要求额外审批
  • 需要 elevated 权限的动作也可以单独控制
• 这说明 OpenClaw 的安全思路不是“相信模型”，而是“限制模型”。

Prompt Injection 防御机制 #

• 有，但官方文档的表述很克制：
• OpenClaw 并不声称“解决了 prompt injection”，而是提供一组降低风险的机制。
• 官方安全文档的核心观点是：
  • system prompt guardrails 只是软约束
  • 真正的硬防护来自工具策略、审批、sandbox 和 channel allowlists
  • prompt injection 不一定来自陌生人私信，也可能来自网页、附件、文档、邮件、日志、代码片段等“不可信内容”
• 所以它的防御思路不是“让模型一定识别攻击”，而是“即使被诱导，也尽量少出事”。

可以把它理解成四层 #

1. 入口收紧
   • 尽量用 pairing / allowlists
   • 群里尽量用 mention gating
   • 避免公开群里的 always-on bot
2. 把不可信内容当成 hostile input
   • 链接、附件、网页、日志、粘贴代码都默认不可信
   • 不要因为“消息是自己转发的”就默认安全
3. 缩小 blast radius
   • 给会接触不可信内容的 agent 开 sandbox
   • 对工具做 allow/deny
   • 高风险 exec 走 approvals
   • secrets 不要放进 prompt 或 agent 可直接读到的位置
4. 角色拆分
   • 官方建议可以用一个只读、少工具的 reader agent 先读不可信内容
   • 再把整理后的摘要交给主 agent
   • 这样就算被注入，也先卡在低权限层

一个很现实的提醒 #

• 官方文档明确提到，小模型通常更容易被 adversarial prompt 带偏
• 所以只要 agent 能跑工具、能读文件、能碰网络，就更适合用更强的模型，或者进一步收紧权限

一句话总结 #

OpenClaw 有 prompt injection 风险缓解机制，但没有“魔法免疫”；它主要靠最小权限、隔离执行和审批，把问题从“完全失控”降到“可控范围”。

OpenClaw 不保证什么 #

• 官方文档和外部讨论都很明确：OpenClaw 不是“绝对安全”的。
• 它不保证：
  • 模型不会被 prompt injection 影响
  • 插件和 skills 没有供应链风险
  • 拿着真实权限的 agent 一定不会误操作
• 所以最后还是要回到传统安全原则：
  • 最小权限
  • 隔离运行
  • 审批高风险动作
  • 对敏感信息做可删除、可审计、可轮换
• 如果只留一句总结：OpenClaw 的安全，不是靠模型足够聪明，而是靠系统边界设计。