前言：这篇文章在近3个月前完成了编写，一直存放在本地。近期抽空做了更新，分享到社区。

基本介绍

官网介绍（https://docs.openclaw.ai/）：OpenClaw 是一个自托管 Gateway 网关，可将你常用的聊天应用和渠道界面——包括内置渠道，以及 Discord、Google Chat、iMessage、Matrix、Microsoft Teams、Signal、Slack、Telegram、WhatsApp、Zalo等内置或外部渠道插件——连接到像 Pi 这样的 AI 编码智能体。你只需在自己的机器上（或服务器上）运行一个 Gateway 网关进程，它就会成为你的消息应用与一个始终在线的 AI 助手之间的桥梁。

使用感受

相较于传统LLM一问一答的Chatbot，OpenClaw不仅具备各种channel的对接，还具备记忆能力，能完成复杂任务的拆解，能安装、生成、编排各类工具（Skills），让智能体又更进了一步。从个人使用上的感受，OpenClaw一些开创性优点：

• 海量工具（skills）便捷安装，功能即刻扩展，即刻可用：社区已有面向不同应用场景、不计其数的skills。仅需数条命令，或直接通过对话就能完成相应skills的安装，即刻具备相应的功能。也支持便捷集成用户自己开发的工具、脚本。这就相当于给使用者提供了一个聚宝盆，使用者可以根据自身场景便捷的挑选所需的宝贝。
• 文件、网页、邮件、日历等操作，办公搭子：通过安装相应的skills，能搜索、读取、操作、整理、分析本机上的各类文件（PDF、word、Excel、ppt、markdown、JSON等系列格式），还能抓取和分析网页内容，操作邮件、日历、处理图片、视频等，且能将结果生成文件。而且这些丰富的处理能力，并非是固化的程序，而是大量结合了LLM针对个性化任务生成相应的执行代码（如Python程序），再执行这些代码来实现。
• 工作流拆解和编排能力，多Agent协作：能自行拆解复杂任务成工作流，完成工作流的设计和开发，还能将不同的任务流构建成子Agent。并能将拆解的工作流或者用户自己的工作流编排成完整的流水线，联动多Agent协作，完成复杂任务。
• 记忆能力（Memory），以及自我改进：除了能24小时持续工作外，还能根据用户在使用过程中的调校记入记忆模块，进行自我改进，匹配个人的知识关注点、使用风格和习惯等，越用越顺。
• 即时通讯应用接入（Channel）：不仅支持在个人电脑、云主机上安装。还支持常用的即时通讯软件接入，如国内的钉钉、飞书、QQ、微信等。可以在通讯软件上进行直接对话、发布任务。也能将任务结果发送给通讯软件。比如，针对个人的关注点、兴趣爱好等设计一个每日早八点的行业动态、股市咨询等任务，OpenClaw跑完后，可以将任务结果在通讯软件上直接推送出来。
• 定时任务：日常例行的工作，可以设置定时任务，比如可以自行定制一个晨间早报，让OpenClaw自行搜集、整理自己感兴趣的早间新闻、行业动态等。通过对话即可便捷完成设置。

这些新奇功能、使用上的变化，以及产生的效果令人欣喜，是之前一问一答式Chatbot所不具备的。使用一个日常生活中比如饿了要吃饭的例子来类比做个说明，之前的方式是跟LLM一问一答式对话：

用户问：“我饿了，该怎么办？”。

LLM答：“你需要吃饭，补充能量”。

用户问：“饭应该怎么做？”。

LLM答：“将米放入电饭锅，加入适量水。。。。。”

。。。。。。

由始至终，需要使用者来思考和主导整个流程，拆分具体步骤，并执行具体步骤。LLM只能根据用户在具体步骤上问到的具体问题给出答复。而OpenClaw等智能体的处理方式是会先思考需要吃饭，并直接把饭做好，再提醒人吃饭。自行完成做饭任务的步骤拆解，自行解决过程中遇到的各种问题：比如做饭过程中先选择并调用相关的工具（Skills）查看是否还有米，如果发现没米了，则根据用户的喜好（Memory）搜索并买好米。然后继续做饭流程……过程中如果发现了新问题，则继续选择并调用对应的工具（Skills）自行解决。做好饭后，给用户的手机上发送通知信息（Channel）。用户吃饭时，因个人偏好可能觉得饭太稀了，则告知OpenClaw，让它下次少放些水。OpenClaw会将用户的喜好、习惯记录下来（Memory），并在下次做饭时做好调整。甚至还可以给OpenClaw下达定时任务，每天XX时间定时把饭做好等等。使用者只需要提出问题，拿到最终结果即可，至于该问题中间的可能涉及各种各样的任务拆解、分析、解决，以及流程编排等，OpenClaw都将自行完成。接下来，我们尝试解析OpenClaw的原理，看其为何能实现这种效果。

原理解析

基本思路：OpenClaw的本质是处理用户发出的对话指令（message），给出答复。所以抓住数据流的完整处理流程这条线，就能理顺实现原理。至于具体模块的代码实现原理，除了参考网上已有的分析文章外，还可以下载好源码，直接借助OpenClaw做代码分析，形成自己的理解。

架构图：

### 官方文档

- **主文档**：https://docs.openclaw.ai

- **GitHub 仓库**：https://github.com/openclaw/openclaw

- **架构文档**：https://github.com/openclaw/openclaw/blob/main/docs/concepts/architecture.md

Message处理流程

## 🔄 OpenClaw 数据流处理完整链路

### 一、宏观数据流架构图

```

┌─────────────────────────────────────────────────────────────────┐

│                        消息输入层                               │

│ WhatsApp/Telegram/Discord/Slack/WebChat/iOS Node/Android Node  │

└─────────────────────────────────────────────────────────────────┘

                             │

                             ▼

┌─────────────────────────────────────────────────────────────────┐

│                    Gateway WebSocket 层                          │

│  - 设备配对 (device.pair.*)                                      │

│  - 挑战签名 (connect.challenge)                                  │

│  - 角色/权限验证 (operator/node)                                 │

│  - 事件广播 (chat/agent/presence/health)                         │

└─────────────────────────────────────────────────────────────────┘

                             │

                             ▼

┌─────────────────────────────────────────────────────────────────┐

│                    会话路由层 (Session Routing)                  │

│ src/routing/session-key.ts                                     │

│  格式：agent:<agent-id>:<key-variant>                            │

│  路由优先级：Peer ID → Guild ID → Team ID → Channel ID → Fallback │

└─────────────────────────────────────────────────────────────────┘

                             │

                             ▼

┌─────────────────────────────────────────────────────────────────┐

│                    命令队列层 (Command Queue)                    │

│  - 会话级串行化 (session:<key> lane)                            │

│  - 全局并发控制 (agents.defaults.maxConcurrent)                 │

│  - 队列模式：collect/steer/followup/interrupt                   │

└─────────────────────────────────────────────────────────────────┘

                             │

                             ▼

┌─────────────────────────────────────────────────────────────────┐

│                    Agent Loop 执行层                             │

│ src/agents/pi-embedded.ts                                      │

│  1. resolveSession() - 会话解析                                  │

│  2. registerAgentRunContext() - 上下文准备                       │

│  3. runEmbeddedPiAgent() - Pi SDK 调用                           │

│  4. subscribeEmbeddedPiSession() - 事件订阅                      │

└─────────────────────────────────────────────────────────────────┘

                             │

                             ▼

┌─────────────────────────────────────────────────────────────────┐

│                    上下文组装层 (Context Assembly)               │

│  - System Prompt (工具列表 + Skills + Bootstrap 文件)            │

│  - Session History (JSONL transcript)                           │

│  - Tool Schemas (JSON Schema)                                   │

│  - Memory 注入 (MEMORY.md + memory/YYYY-MM-DD.md)               │

└─────────────────────────────────────────────────────────────────┘

                             │

                             ▼

┌─────────────────────────────────────────────────────────────────┐

│                    Model Inference 层                            │

│  - Provider SDK (Anthropic/OpenAI/Ollama)                       │

│  - Streaming 分块 (EmbeddedBlockChunker)                        │

│  - Tool Call 解析                                               │

│  - Compaction 触发 (context overflow)                           │

└─────────────────────────────────────────────────────────────────┘

                             │

                             ▼

┌─────────────────────────────────────────────────────────────────┐

│                    Tool Execution 层                             │

│  - 工具调用 (read/write/edit/exec/process/...)                  │

│  - Exec 审批 (exec.approval.request)                            │

│  - 结果收集与 sanitization                                      │

└─────────────────────────────────────────────────────────────────┘

                             │

                             ▼

┌─────────────────────────────────────────────────────────────────┐

│                    响应流式传输层                               │

│  - Assistant Delta 流式推送                                     │

│  - Block Streaming (text_end/message_end)                       │

│  - Preview Streaming (Telegram/Discord/Slack)                   │

│  - MEDIA: 附件交付                                              │

└─────────────────────────────────────────────────────────────────┘

                             │

                             ▼

┌─────────────────────────────────────────────────────────────────┐

│                    持久化层                                     │

│  - Session Transcript: ~/.openclaw/agents/<id>/sessions/<id>.jsonl │

│  - Session Index: ~/.openclaw/agents/<id>/sessions/sessions.json   │

│  - Memory 更新：MEMORY.md + memory/YYYY-MM-DD.md                │

│  - Usage Tracking: token 统计与成本计算                          │

└─────────────────────────────────────────────────────────────────┘

```

---

### 二、核心数据流详解

#### 1️⃣ **WebSocket 协议层** (Gateway Protocol)

**关键源码**: `/opt/homebrew/lib/node_modules/openclaw/src/gateway/protocol/schema/frames.ts`

**握手流程**:

```json

// 1. Gateway 发送challenge

{

"type": "event",

"event": "connect.challenge",

"payload": { "nonce": "abc123", "ts": 1737264000000 }

}

// 2. Client 签名响应

{

"type": "req",

"id": "req-001",

"method": "connect",

"params": {

  "minProtocol": 3,

  "client": { "id": "cli", "version": "1.2.3" },

  "role": "operator",

  "scopes": ["operator.read", "operator.write"],

  "device": {

    "id": "device_fingerprint",

    "publicKey": "...",

    "signature": "...", // 签名 v2/v3 payload

    "signedAt": 1737264000000,

    "nonce": "abc123"

   }

 }

}

// 3. Gateway 返回hello-ok

{

"type": "res",

"id": "req-001",

"ok": true,

"payload": {

  "type": "hello-ok",

  "protocol": 3,

  "features": { "methods": [...], "events": [...] },

  "policy": {

    "maxPayload": 26214400, // 25MB

    "maxBufferedBytes": 52428800,

    "tickIntervalMs": 15000

   }

 }

}

```

**关键机制**:

- **设备配对**: 新设备需审批，签发 deviceToken

- **角色隔离**: operator (控制平面) vs node (能力宿主)

- **作用域门控**: broadcast 事件根据 scopes 过滤

- **序列号**: 每客户端独立 seq，保证单调顺序

---

#### 2️⃣ **会话路由层** (Session Routing)

**关键文件**: `src/routing/session-key.ts`

**路由算法**:

```typescript

// 会话键格式

sessionKey = `agent:${agentId}:${keyVariant}`

// 路由优先级 (6 级级联)

1. Peer ID (最具体 - 精确到发送者)

2. Guild ID (Discord 服务器)

3. Team ID (Slack 工作区)

4. Channel ID (特定频道)

5. Account ID (平台账号)

6. Fallback agent (兜底)

// 配置示例

{

"session": {

  "dmScope": "per-channel-peer"  // 推荐：按频道 + 发送者隔离

 }

}

```

**会话存储结构**:

```

~/.openclaw/agents/<agentId>/sessions/

├── sessions.json           # 会话索引 (元数据)

└── <sessionId>.jsonl       # 完整对话记录 (每行一个 JSON 对象)

```

**JSONL 格式示例**:

```jsonl

{"role":"user","content":"你好","ts":1737264000000}

{"role":"assistant","content":"你好！有什么可以帮助你的？","ts":1737264001000}

{"role":"tool","name":"read","result":"...","ts":1737264002000}

```

---

#### 3️⃣ **命令队列层** (Command Queue)

**关键文件**: `src/agents/queue.ts`

**队列架构**:

```

入队消息

  │

 ├─→ 会话级队列 (session:<key> lane)  ← 保证单会话串行

 │        │

 │        ▼

 └─→ 全局队列 (main lane)            ← 控制总并发

          │

          ▼

     runEmbeddedPiAgent()

```

**队列模式详解**:

| 模式 | 行为 | 适用场景 |

|------|------|----------|

| `collect` (默认) | 合并所有等待消息为单个 followup | 减少 thrashing，提供完整上下文 |

| `steer` | 立即注入当前运行，取消待定工具 | 需要紧急干预 |

| `followup` | 当前运行结束后排队 | 保持顺序 |

| `interrupt` | 中止当前运行，处理最新消息 | 高优先级打断 |

| `steer-backlog` | 立即 steer + 保留 followup | 需要即时响应 + 后续跟进 |

**配置示例**:

```json5

{

"messages": {

  "queue": {

    "mode": "collect",

    "debounceMs": 1000,  // 等待静默期

    "cap": 20,           // 最大队列深度

    "drop": "summarize" // 溢出策略：old/new/summarize

   }

 }

}

```

---

#### 4️⃣ **Agent Loop 执行层**

| 模块 | 文档路径 | 重点 |

|------|----------|------|

| Agent Loop | `concepts/agent-loop.md` | 生命周期、流式响应、超时控制 |

| Session 路由 | `concepts/session.md` + `routing/session-key.ts` | 会话隔离、跨平台上下文 |

| WebSocket 协议 | `gateway/protocol.md` | 请求/响应帧、事件推送 |

| Queue 系统 | `concepts/queue.md` | 四种队列模式(collect/steer/followup/interrupt) |

| Memory 系统 | `concepts/memory.md` | 三层上下文管理(Pruning/Compaction/Flush) |

**关键代码位置**：

```

src/

├── agents/          # Agent 执行引擎

│  ├── pi-embedded.ts        # 核心编排循环

│  └── tools/cron-tool.ts    # 自调度系统

├── infra/

│  └── heartbeat-runner.ts   # 心跳系统

├── routing/

│  └── session-key.ts        # 会话路由

└── channels/        # 通道适配器 (16+)

```

参考文档：https://github.com/botx-work/OpenClaw-Internals/blob/main/README.zh.md

总结：可以看出，OpenClaw在message处理上，核心就是一个循环。用户的问题提交后，内部不断的调用工具、大模型进行尝试性答复，每次的结果都会注入到上下文，再进入下一次处理，直到最终的答案LLM判断满足要求了，再退出循环，并且更新记忆。

此外，不要小看了这个循环处理，这种处理方式相较于之前一问一答Chatbot产品，带来的token消耗量是数十数百数千倍数量级的增长，当然效果也是很惊艳的。LLM可以粗略分成模型训练+模型推理两大块，众所周知，LLM模型训练门槛高、投入大，极其烧钱，而模型推理才能让LLM最终走向应用，实现商业变现。如果把LLM看做一场徒步旅行，模型训练会决定能走到的高度，模型推理决定能走多远，二者都十分关键。回望LLM的发展历程，以GPT-3（发表于2020年7月）为里程碑，至今也就数年时间，这些年全球各LLM科技公司主要竞争赛道还是在基础大模型的打造上，也即在模型训练上拼刺刀。OpenClaw出来后，给行业带来了一股新风，让行业看到了LLM大规模应用、变现的曙光。

Agent Loop代码解析

# OpenClaw Agent Loop 实现原理分析

> **分析文件**: `src/agents/pi-embedded-runner/run.ts`  

> **核心循环**: 第 870 行 `while (true)`  

> **分析时间**: 2026-05-13

---

## 📋 一、循环的核心职责

这个 `while (true)` 循环是 **OpenClaw 嵌入式 Agent 的运行引擎**，负责：

| 职责 | 说明 |

|------|------|

| **调用 LLM** | 处理流式响应，解析模型输出 |

| **执行工具调用** | 处理 Tool Calls，累积结果 |

| **错误恢复与重试** | 认证失败、限流、超时自动恢复 |

| **上下文管理** | 自动压缩（Compact）防止溢出 |

| **多模型降级** | Failover 策略保证可用性 |

---

## 🏗️ 二、循环主体结构

```typescript

while (true) {

 // 1. 检查迭代次数上限（防止无限重试）

 if (runLoopIterations >= MAX_RUN_LOOP_ITERATIONS) {

  return handleRetryLimitExhausted({...});

 }

runLoopIterations += 1;

 // 2. 构建请求参数（Prompt、模型配置、认证信息）

const runtimePlan = buildAgentRuntimePlan({...});

 // 3. 调用后端执行单次尝试

const rawAttempt = await runEmbeddedAttemptWithBackend({...});

const attempt = normalizeEmbeddedRunAttemptResult(rawAttempt);

 // 4. 更新使用量统计

mergeUsageIntoAccumulator(usageAccumulator, attemptUsage);

 // 5. 错误检测与恢复逻辑

//    - 上下文溢出 → 触发 Compact

//    - 认证失败 → 刷新 Token

//    - 限流/超时 → 重试或降级

 // 6. 成功完成 → 返回结果

return { payloads, meta, ... };

}

```

---

## 🔄 三、关键错误恢复路径

### 3.1 超时触发压缩（Timeout-triggered Compaction）

```typescript

if (timedOut && !timedOutDuringCompaction) {

const tokenUsedRatio = lastTurnPromptTokens / ctxInfo.tokens;

 if (tokenUsedRatio > 0.65) {

  // 上下文使用率 > 65% 且超时 →先压缩再重试

  timeoutCompactResult = await contextEngine.compact({...});

  if (timeoutCompactResult.compacted) {

    continue; // 压缩成功，重新循环

   }

 }

}

```

> **💡 设计原理**：当 LLM 因上下文过大超时时，直接重试会陷入"死亡螺旋"。先压缩上下文再重试可以打破循环。

---

### 3.2 上下文溢出处理（Context Overflow）

```typescript

if (contextOverflowError) {

 // 检测是否已尝试过压缩

 if (!hadAttemptLevelCompaction && overflowCompactionAttempts < MAX_OVERFLOW_COMPACTION_ATTEMPTS) {

  // 显式触发压缩

  compactResult = await contextEngine.compact({...});

  if (compactResult.compacted) {

    continue; // 压缩成功，重试

   }

 }

 // 压缩失败 → 尝试截断工具结果

 if (!toolResultTruncationAttempted) {

  truncResult = await truncateOversizedToolResultsInSession({...});

  if (truncResult.truncated) {

    continue; // 截断成功，重试

   }

 }

 // 所有恢复手段都失败 → 返回错误给用户

return { payloads: [{ text: "Context overflow: prompt too large...", isError: true }] };

}

```

---

### 3.3 认证失败自动刷新

```typescript

if (authFailure && await maybeRefreshRuntimeAuthForAuthError(...)) {

authRetryPending = true;

continue; // 刷新成功后重试

}

```

---

### 3.4 多 Profile 轮转（Auth Profile Rotation）

```typescript

if (promptFailoverDecision.action === "rotate_profile") {

 if (await advanceAuthProfile()) {

  lastRetryFailoverReason = mergeRetryFailoverReason({...});

  continue; // 切换到下一个认证 Profile 重试

 }

}

```

> **💡 设计原理**：当某个 API Key 限流或失效时，自动切换到备用 Profile，提高可用性。

---

## 🚪 四、循环退出条件

| 退出场景 | 代码路径 | 返回值 |

|---------|---------|-------|

| ✅ **成功完成** | 正常生成回复 | `payloads + meta` |

| ❌ **重试超限** | `runLoopIterations >= MAX` | 错误消息 |

| ❌ **上下文溢出** | 压缩/截断均失败 | 错误消息 |

| ⚠️ **认证失败** | 无法刷新Token | 抛出 `FailoverError` |

| ⚠️ **限流/超时** | 降级策略耗尽 | 抛出 `FailoverError` |

| 🛑 **外部中止** | `aborted === true` | 部分结果 |

| ✅ **工具调用完成** | 无更多工具需要执行 | `payloads + toolCalls` |

---

## 🔁 五、特殊重试机制

### 5.1 Planning-only 重试

```typescript

if (nextPlanningOnlyRetryInstruction && planningOnlyRetryAttempts < maxPlanningOnlyRetryAttempts) {

planningOnlyRetryAttempts += 1;

planningOnlyRetryInstruction = nextPlanningOnlyRetryInstruction;

continue; // 注入"立即执行"指令，要求模型输出行动而非计划

}

```

> **📌 场景**：模型只输出计划但没有执行 →注入指令要求行动

---

### 5.2 Reasoning-only 重试

```typescript

if (nextReasoningOnlyRetryInstruction && reasoningOnlyRetryAttempts < maxReasoningOnlyRetryAttempts) {

reasoningOnlyRetryAttempts += 1;

continue; // 注入指令要求输出可见答案

}

```

> **📌 场景**：模型只输出思考过程但没有最终答案 → 要求补充答案

---

### 5.3 空响应重试

```typescript

if (nextEmptyResponseRetryInstruction && emptyResponseRetryAttempts < maxEmptyResponseRetryAttempts) {

emptyResponseRetryAttempts += 1;

continue; // 重新提交相同 Prompt

}

```

> **📌 场景**：模型返回空内容 → 重试

---

## 📊 六、执行追踪（Execution Trace）

循环会记录每次尝试的结果：

```typescript

traceAttempts.push({

provider,

model: modelId,

result: "timeout" | "rotate_profile" | "fallback_model" | "success",

reason: failoverReason,

stage: "prompt" | "assistant",

});

```

最终返回给调用者，用于诊断和可观测性。

---

## ✨ 七、设计亮点

| 亮点 | 说明 |

|------|------|

| **1. 分层恢复策略** | 先尝试轻量恢复（刷新 Token），再尝试重量恢复（压缩上下文），最后降级（切换模型） |

| **2. 防无限循环** | 所有重试路径都有计数器上限 |

| **3. 状态累积** | Usage、Compact 次数、重试原因等在循环中持续累积|

| **4. 优雅降级** | 认证失败 → 限流 → 超时 → 上下文溢出，每种错误有专属处理路径 |

| **5. 可观测性** | 每次尝试都记录到 `traceAttempts`，支持故障诊断 |

---

## 📌 总结

这个 `while (true)` 循环是 OpenClaw **高可用性**和**自愈能力**的核心实现。通过多层错误恢复机制、智能重试策略和完整的执行追踪，确保 Agent 能够在各种异常情况下自动恢复或优雅降级。

Skills加载机制

渐进式加载机制：

1. 启动时：AI 只加载每个技能的名称和描述，只保留最基本的识别信息。

2. 激活阶段：当任务匹配某个技能的描述时，AI 才把完整的 SKILL.md 读⼊上下⽂。

3. 执⾏阶段：AI 按照指令执⾏，按需加载参考⽂件或运⾏代码。

这种设计让 AI 保持快速，同时能按需获取更多信息。

记忆系统：memory

记忆能力也是OpenClaw有别于直接基于LLM一问一答产品的关键差异之一，LLM自身是缺乏记忆能力的，所以，之前的一些做法是，用户自行把一些记忆信息或者历史对话加载到prompt中。OpenClaw关于记忆这块的处理，是直接记录到文件，向量化处理后存放在sqllite数据库中：

●长期记忆：决策、偏好、重要事实 → MEMORY.md

●短期记忆：日常笔记、运行上下文 → memory/YYYY-MM-DD.md

●用户明确要求：如"记住这个" → 立即写入MEMORY.md

此外，如果要其删除或者更新某些已记录的记忆，可以直接通过对话进行更新，比如：删除之前关于XXX的记忆。你记错了，xxx信息已经更新成xxx。

这些文件里面的语料，还能自动化加工成向量存放在sqllite数据库中，且能自动更新。此外，在信息检索上做了向量+BM25关键词匹配的混合检索：finalScore = vectorWeight * vectorScore + textWeight * textScore。默认权重 vectorWeight=0.7，textWeight=0.3

记忆的局限：

有大小限制： MEMORY.md单个文件超过约 20,000 个字符会被截断。只保留最重要的信息。

可能会滞后/冲突： 如果改了偏好但忘告诉它更新记忆，它可能还按旧的来。可直接说"帮我更新记忆，把 xxx 改成 yyy"。

只记文字： 不能记图片、文件等。

小技巧： 如果发现记忆混乱，可以说"把MEMORY.md的信息整理一下"。它会自己整理。

Workspace工作目录

Workspace是用户最为关键的文件目录，用户相关的配置、安装的skills、用户的memory文件、以及工作时生成的文件、脚本、用户创建的Agent等等，都在这个目录下。可以简单理解为其他目录是OpenClaw的系统目录，而workspace是用户目录。Workspace的目录结构：

~/.openclaw/workspace/

├── .agents/              # ACP 代理配置

├── .clawhub/             # ClawHub 技能缓存

├── .firecrawl/           # Firecrawl 配置

├── .git/                 # Git 版本控制

├── .openclaw/            # OpenClaw 本地配置

├── .qoder/               # Qoder 代理配置

├── memory/               # 记忆文件（日常日志）

├── skills/               # 自定义技能

├── state/                # 状态存储

├── tools/                # 工具脚本

├── docs/                 # 文档

│   └── plans/            # 规划文档

│   └── presentations/    # 演示文稿

├── competitor-monitor/   # 竞品监控系统：用户自定义的Agent

│   ├── data/             # 采集数据

│   ├── reports/          # 生成的报告

│   └── skills/           # 监控相关技能

├── 权限点/                # PolarDB 权限分析项目

└── 核心配置文件

├── AGENTS.md         # 助手行为指南

├── SOUL.md           # 人格定义

├── USER.md           # 用户信息

├── IDENTITY.md       # 身份标识

├── MEMORY.md         # 长期记忆

├── TOOLS.md          # 本地工具配置

└── HEARTBEAT.md      # 心跳任务

OpenClaw带来的变革与启发

从使用和实现原理上可以看到，OpenClaw设计的独到之处在于，并未固化某种工具或程序，而是能根据用户的不同场景要求，结合LLM和基础工具（skills），灵活生成新工具和代码，这就使其能非常灵活的完成各种各样的任务，而不是局限于某个单一任务场景，颠覆了传统应用的开发模式和使用方式。

之前，我们开发一个应用时，通常只能用于某个确定的场景，很难扩展，以文档处理为例，比如开发一个word读写软件，则就只能处理单个word文档，很难处理网页等其他格式的文档，也很难同时处理多个文档（如多个文档的差异比对，则需要另外再开发一个软件），而且所能处理的功能在该软件中也基本上定死了。而OpenClaw的做法是将LLM融合至任务流程中，借助LLM的诸多惊艳能力（如摘要/概括、理解、推断、文本转换、文本扩展、function calling等）作为处理任务的核心大脑。并将一些基础能力以skills等方式集成到系统中，而且这些能力还可以随时安装、随时扩展，也能自定义开发，并未限制死。当用户输入具体任务后，系统调用LLM来理解用户任务意图，进行任务拆解，然后不断的和LLM联动，并让LLM来判断所需调用的工具，为特定任务即时生成所需的代码、脚本等，再通过完整的任务流编排和执行，就可以联动海量工具和即时生成的代码或脚本来灵活处理各种各样的复杂任务。如文件处理场景，将文件的打开、编辑等基本能力以Skills方式进行集成。当用户输入的任务，涉及到文件处理时，则调用对应的skills来完成，使得文件处理只是任务中的一个子环节，而复杂的一些处理，则通过联动LLM，生成即时代码、脚本等协助完成。所以，会经常看到给OpenClaw下发一个任务后，除了会调用相关skills来完成一些基本操作外，还可能会生成特定的Python脚本，这些脚本就是给该任务量身打造的，能处理极其定制化的复杂任务。

由此可见，OpenClaw给LLM时代开启了一种全新的软件设计思路、新范式，会给各行各业的传统软件带来颠覆性革命。局限于特定场景提供特定功能的传统软件，尤其是一些面向办公、搜索、代码编写、内容创作、娱乐、购物等个人使用者和消费者的传统软件，未来将会被最先重构。用户再也不需要安装一堆的小工具软件了，用户软件的交互也会迎来重大变化，只剩一个对话框，用户只需要将自身需求以自然语言的方式描述出来，以文字或直接以语音方式输入到对话框即可，再也不是之前要按传统软件定好的各种操作按钮和步骤来使用软件了，软件使用的学习成本近乎为0。

头脑风暴：LLM未来形态展望

      从OpenClaw的实现原理可以看出，核心能力依然依赖LLM，对比早期基于LLM一问一答chatbot，功能和应用场景上都得到了极大扩展。但再回到LLM本身，LLM的基准能力和自身知识并未做任何增强，LLM之所以看上去实现了针对特定任务的个性化推理，原理是LLM在推理之前加载一堆信息作为上下文，如SOUL.md、USER.md、AGENTS.md、IDENTITY.md等配置文件、Memory文件、Skills文件等，这些信息也会不断累积而变得臃肿，所以，会经常看到一些文章或产品如何解决上下文臃肿问题。由此可见，LLM+Agent方式依然存在大量弊端，也并非终态。OpenClaw并没有给LLM本身带来任何颠覆性的变革。LLM自身知识的自我学习和迭代问题依然是待攻克的难题，需要LLM自身来解决。就好比一个人练武，目前的方式更多是LLM使用上的招式变化和扩展，而LLM自身的内功并未增强。

此外，针对每个用户的个性化能力，以及持续更新的知识学习，是否有可能做到LLM模型内部，固化成LLM自身的模型参数？有没可能实现千人千面、能自我知识迭代的LLM原生能力？比如，将LLM的参数智能抽取和分层，分成基础参数层（基本定律）+个性化参数层，将个性化记忆和能力以低秩矩阵等方式放入个性化参数层，个性化参数随使用者变化和知识更新而便捷更新。LLM推理时，同时加载基础参数和个性化参数。相当于LLM面向个性化推理时，不仅仅具备了招式变化，而是内功上的增强，将个性化知识刻入LLM的基因中。这样未来可便捷推出各行业的行业大模型、公司大模型、甚至是个人大模型，整个LLM的生态构建将百花齐放。当然，这只是个人受OpenClaw实现原理启发的突发奇想，目前要想将个性化知识刻入LLM基因中，还是需要各种微调手段，门槛依然较高，且LLM自身知识依然是固定不变，难以做到自我学习自我更新。

企业级Agent构建及数据产品的机会点

数据处理流程关键点

Message（文本） --- 过程结果（脚本、文件）、日志、向量存取 --- 最终结果：文本

从前文的分析可以看出，单就数据产品的视角看，OpenClaw涉及数据存取、处理的有两大关键点：Memory记忆系统和WorkSpace工作目录。Memory系统涉及的关键是向量、图、RAG等能力构建，在业界已有大量类似产品布局，但企业级workspace这个场景其实也值得重视和深挖。此外，就是在整个使用过程中会产生大量日志，日志的存取和分析业界也有不少产品在做了。

问题与挑战

OpenClaw在很多方面已有优异表现，但如果是在要求高安全高可控的企业内部使用，依然还有系列问题和挑战：

• 安全：OpenClaw的优点在于极其灵活，各种各样极其丰富的Skills都可以安装，用户也能自行编写。但风险点也在于这些五花八门，让人眼花缭乱的Skills，质量参差不齐，甚至有大量bug和安全缺陷，安装和使用不受管控，这在企业级使用场景，难以接受。此外，LLM的使用，LLM的API Key、token配额及管理等等均涉及安全管控问题。
• 易用性：

• Agent安装和使用：虽然目前OpenClaw等Agent产品在Linux、MAC笔记本上的安装已经足够简单了。但依然还是需要安装的，如果已有的浏览器、APP产品能直接集成，就可以实现免安装直接用了。此外，在Windows电脑上，安装和使用依然很繁琐，还需要先安装和配置Ubuntu子系统，使用也没那么便利。
• Skills：Agent的处理能力，除了所使用的LLM外，主要取决所安装的skills。而skills是数量庞大、五花八门的，本身的质量参差不齐。个人用户通常很难识别其实用性、安全性等。

• 知识库：叠加企业专业知识+个人偏好知识，实现行业智能体+千人千面。

• 企业知识库：企业内部使用，尤其是一些专业性强的企业场景，如：金融、电力、政企、医疗、司法等行业，通常是有企业独有知识信息的，而且有些信息是独有专业术语或不对外的私密信息，这类信息LLM不具备，公开搜索也难以获取。这类问题使用通用的Agent和LLM就难以解决，问答效果差。
• 个人知识库：除了企业知识信息场景。个人也有一些自己独有的资料、文档、个人私密信息等，个人也想针对自己喜爱的场景做一些带有个人偏好的知识构建，比如，科技、美食、健身、股票、音乐、小众文学等等。这些知识信息需要一个方法，能便捷的集成到智能体中。这样才能使智能体不仅具备处理通用知识、企业知识相关问题，还能实现千人千面，智能处理包含个人知识的问题。

企业级方案构思与展望

通过前文的分析，未来所期望的智能体：

端侧智能，个性化智能助理：云脑智能体+端智能体+网络互联。

云脑-智能体：云厂商做的比较多，比如阿里云百炼。LLM+Skills集成，可扩展，满足80%常用场景。有人可能会问，为何要在LLM服务平台层也叠加Skills能力，直接都放在端侧不就行了吗？主要考虑有如下场景，一方面如果LLM服务平台层就已经具备了通用Skills能力，那就不需要每个端侧都去重复安装和维护这些通用Skills了，统一放在LLM服务平台层来持续迭代和提升，服务平台层甚至可以针对不同行业不同用户，通过传入不同参数而加载不同的个性化Skills。另一方面，全民AI、全行业AI时代，还有大量的嵌入式应用场景，嵌入式设备本身的资源是极其有限的，很难安装Agent，而且商家技术能力也参差不齐，但联网调用LLM服务是可行的，如果LLM服务平台本身就具备常用的Skills能力，而且还能个性化调用，那端侧就可以无限做薄，海量嵌入式设备就可以便捷的构建智能化功能，极大降低技术门槛，真正做到AI普惠，在各行业百花齐放。

端智能体：C端产品可以直接集成Agent能力，避免还需要单独安装。如阿里钉钉、夸克浏览器等都可以集成Agent能力，不要搞过多的入口。针对端智能体，在大企业、公司，其最为关键的用户目录workspace需要统一管控。Skills统一管理，自动预制，进一步轻量化、标准化，可扩展个性化skills。需要具备本地个人文件，日历，邮件等处理能力，支持个性化配置，本地memory，企业知识库。也需要支持个人知识库的便捷构建，如提供用户只需要按要求提供语料，系统具备自动加工成知识库，并集成到使用流程中的能力。

skills市场：skills as a service。统一管控、开发、发布的安全合规的企业级skills。支持个人一键安装企业提供的标准skills，个人也可上传，实现每个人都可以是skills制作者，激发skills市场的组织活力。但个人上传的skills需要经过公司的安全工具测验，需满足公司安全要求。