OpenClaw 深度解析:AI Agent 的基础设施长什么样子?

上次发了篇讲消息路由的文章，有童鞋说不过瘾，想听更详细的。今天干脆把 OpenClaw 的老底都掀开，从里到外聊个透。

先说背景：为什么需要 Agent 基础设施？

这两年大模型能力越来越强，从最早的文本问答，到 Function Calling，再到 Tool Use 和 Agentic Loop，AI 已经不满足于"回答问题"，开始"干活"了。

但真正做起来才发现问题一堆：

• 渠道碎片化：企业微信、飞书、Slack、Telegram，每个平台都得单独接，协议差异还特别大
• Agent 没记忆：每次对话都是全新的，之前的偏好、任务进度全忘了
• 安全边界模糊：谁都能发消息触发 Shell 执行，风险极高
• 多 Agent 协作难：客服、数据分析、内容创作好几个 Agent，怎么统一管？

现有方案要么太底层（LangChain 只管逻辑编排，其他自己搞定），要么太封闭（Coze 挺好但深度定制困难），要么太老旧（传统 Chatbot 框架根本不支持 Agent 能力）。

OpenClaw 就是来解决这些问题的。它不抢"大脑"的活，而是专门做"大脑"下面的基础设施——相当于 AI Agent 的操作系统。

核心架构：Gateway 就是中枢

OpenClaw 的核心是一个常驻进程 Gateway，扮演的角色类似操作系统内核。

┌─────────────────────────────────────────┐
│  IM Channels Layer                      │
│  企业微信 Telegram Discord Slack ...    │
└───────────────┬─────────────────────────┘
                │ 统一接入 / 消息路由
┌───────────────▼─────────────────────────┐
│  OpenClaw Gateway                      │
│  ┌────────┐ ┌────────┐ ┌────────┐     │
│  │ Agent A│ │ Agent B│ │ Agent C│     │
│  │ (运营) │ │ (炒股) │ │ (客服) │     │
│  └────┬───┘ └────┬───┘ └────┬───┘     │
│  ┌────▼──────────▼──────────▼────┐     │
│  │ Tools & Skills Layer           │     │
│  │ exec browser memory web_fetch │     │
│  └────────────────────────────────┘     │
└─────────────────────────────────────────┘

Gateway 天然支持：

• 多渠道并发接入（每个渠道是独立插件）
• 多 Agent 路由（消息按规则精确分发）
• 工具统一调度（所有 Agent 共享工具池）

多 Agent 路由：不是随便分发

路由系统采用"最具体优先"原则，优先级是这样的：

peer（特定用户）
> parentPeer（群内特定成员）
> guild（特定服务器/空间）
> channel（特定频道）
> channelType（渠道类型）
> fallback（默认 Agent）

这意味着你可以做到：

• VIP 用户专属 Agent（某个用户永远走高配模型）
• 群组专属 Agent（投资群→炒股 Agent，运营群→内容 Agent）
• 渠道类型路由（企业微信→内部助手，Telegram→公开助手）

配置长这样：

{
  "agents": {
    "list": [
      {
        "id": "stock-agent",
        "label": "炒股助手",
        "bindings": [
          { "match": { "channelType": "telegram", "group": "投资交流群" } }
        ]
      }
    ]
  }
}

Session 管理：上下文怎么活起来？

Session 是 OpenClaw 最核心的概念。它不是"一次对话"，而是 Agent 与特定上下文绑定关系的持久化容器。

Session 包含：

• sessionKey（唯一标识）
• messages（完整对话历史）
• compactedSummary（压缩后的历史摘要）
• tokenUsage（当前 token 消耗）
• agentId（绑定的 Agent）
• metadata（渠道、发送方等）

三种隔离策略：

策略	sessionKey 构成	适用场景
main	agent::main	单用户私人助手
per-channel-peer	agent:::	多用户，每个用户×渠道独立
per-account-channel-peer	agent::::	多账号+多渠道+多用户完全隔离

Session 生命周期：

1. 消息到达 → Gateway 计算 sessionKey → 查询 Session Store
2. 命中 → 加载历史上下文；未命中 → 创建新 Session，注入 System Prompt
3. 上下文构建：System Prompt = SOUL.md + AGENTS.md + USER.md + 今日日记 + MEMORY.md + 工具列表
4. Agent Turn 执行：LLM 推理 → 工具调用 → 循环，直到输出 stop_reason = "end_turn"
5. 上下文压缩：token 接近上限时，调用摘要 API 生成 compactedSummary
6. Session 持久化：每次 Turn 结束后异步写入磁盘

还有一个特别的 Isolated Session，专门用于定时任务和 Sub-Agent——每次执行都是全新独立的上下文，不继承主 Session 历史，也不污染主 Session。

记忆系统：四层分级架构

这是 OpenClaw 最特别的能力之一。

L0: 感知层 — 当前 Session 上下文窗口（工作记忆）
    ↓ pre-compaction flush
L1: 日记层 — memory/YYYY-MM-DD.md（情景记忆）
    ↓ Heartbeat 定期提炼
L2: 长期记忆 — MEMORY.md（语义记忆）
    ↓ watcher 增量索引
L3: 检索层 — memory_search（向量索引）

关键设计：pre-compaction memory flush

当 Session 上下文窗口接近上限时，Gateway 会先触发一个静默 Agent Turn，让 Agent 把重要信息写入磁盘，再执行压缩。这就是为什么 OpenClaw 的记忆不会在上下文切换中丢失。

记忆检索的工程细节：

• 混合检索：BM25 关键词 + 向量语义搜索加权融合
• MMR 去重：避免返回大量重复片段
• 时间衰减：指数衰减函数，赋予近期记录更高权重（半衰期默认 30 天）

Agent 的人格体系：不是静态字符串

OpenClaw 对 Agent 的设计理念很有意思：Agent 是一个有连续自我认知的实体，而不是处理请求的无状态函数。

每个 Agent 有一套"自我认知文件"：

• SOUL.md：价值观、行为哲学。定义"真正帮忙而非表演帮忙"、"有自己的判断"、"先自己想办法再提问"
• AGENTS.md：操作规程。规定每个 Session 开始时读哪些文件、怎么用 Memory、群聊和私聊的不同策略
• USER.md：用户画像。记录用户偏好、背景、沟通风格
• IDENTITY.md：身份认同。名字、Avatar、性格标签

而且这些文件 Agent 可以自己改。用户说"以后回复简洁一些"，Agent 立刻写入 USER.md；发现某类任务有更好的处理方式，更新 AGENTS.md。

人格不是被配置的，而是被塑造的。

Skills：可插拔的能力扩展

Skills 是 OpenClaw 的能力扩展机制，本质上是一个带 YAML frontmatter 的 Markdown 文件。

三层优先级：
workspace/skills/ ← 最高（项目专属）
~/.openclaw/skills/ ← 中（用户级全局）
bundled skills ← 最低（内置）

每个 Skill 可以声明自己的激活条件（需要的环境变量、二进制依赖），Agent 启动时自动检测环境，只加载当前满足条件的 Skills。

安全架构：纵深防御

OpenClaw 的安全模型采用"访问控制先于智能"：

第一层：身份（谁能和 Bot 说话）
→ DM pairing / allowlist / open

第二层：范围（Bot 能做什么）
→ Tool Policy（工具黑白名单）
→ Docker Sandbox（隔离执行）
→ Workspace-only FS（文件系统限制）

第三层：模型（提示注入兜底）
→ 假设 LLM 可被操控，前两层已限制爆炸半径

核心洞见：不要假设 LLM 一定能抵抗提示注入。安全不能依赖模型的"聪明"，必须在模型层之下建立独立的访问控制体系。

总结一下

OpenClaw 的定位不是一个更好的 Agent 框架，而是一个 Agent 运行时（Agent Runtime）——解决的是 Agent 在生产环境中"活下去"的问题。

核心优势：

1. Agent 有"灵魂"：人格文件体系，可进化可审查
2. 记忆是"一等公民"：四层分级，透明可控
3. 多渠道统一接入：15+ 渠道，零重复开发
4. 精确多 Agent 路由：配置驱动，精确到用户级
5. 安全是架构级别：纵深防御，不是事后补丁

好了，篇幅有限，只能讲个大概。还有更多细节（比如上下文管理、工具策略、Cron 定时任务这些）下次再聊。

觉得有用就点个赞、在看、转发吧。谢谢阅读，下次见。