OpenClaw Agent 架构设计（企业级实践）

上一篇我们聊了 OpenClaw 的整体设计理念与基础模块，这一篇我们深入企业级落地最核心的四块拼图：MCP 接入、多 Agent 调度、Tool Router、Memory 架构。这四个模块决定了一个 Agent 系统能不能从 Demo 走向 Production。

写在前面：为什么企业级 Agent 这么难落地？

很多同学在本地跑了一个 Agent Demo，感觉效果不错，但一到生产环境就翻车。原因是什么？

工具乱、调度乱、记性差。

• • 工具越接越多，没有统一协议，维护成本爆炸 → 需要 MCP
• • 任务越来越复杂，单个 Agent 搞不定 → 需要多 Agent 调度
• • 工具太多塞不进 Prompt，模型选错工具 → 需要 Tool Router
• • 每次对话都是"失忆"状态，无法积累经验 → 需要 Memory 架构

这四个问题，是 Agent 工程落地的核心挑战。我们一个一个来拆。

一、MCP 接入：给 Agent 装上"标准接口"🔌

先讲一个比喻

你有没有遇到过这种情况：家里买了五六件电器，结果每个充电口都不一样，Type-A、Type-C、Micro-USB……一堆线缆塞满抽屉，乱得很。

企业里的 Agent 接工具，以前就是这种状态——接 ERP 一套逻辑，接 CRM 一套逻辑，接数据库又一套。每接一个系统就要写一套专属 Adapter，代码烟囱式堆叠，维护成本极高。

MCP（Model Context Protocol）就是 Agent 世界的"Type-C 接口"——工具方按协议暴露能力，Agent 按协议调用，双方解耦，一劳永逸。

MCP 解决了什么？

OpenClaw 的 MCP 接入架构

┌─────────────────────────────────────────┐│              Agent Runtime              ││                                         ││   ┌──────────────┐  ┌────────────────┐  ││   │  MCP Client  │  │  Tool Registry │  ││   └──────┬───────┘  └───────┬────────┘  │└──────────┼──────────────────┼───────────┘           │  MCP Protocol    │ 注册/发现    ┌──────┴──────┐    ┌──────┴──────┐    │  MCP Server │    │  MCP Server │    │  (内部 ERP) │    │  (文件系统) │    └─────────────┘    └─────────────┘

整体流程分三步：

1. 1. 启动阶段：ToolRegistry 向各 MCP Server 拉取工具清单，缓存到本地
2. 2. 调用阶段：Agent 触发工具时，MCP Client 负责序列化请求、发送、反序列化结果，对上层完全透明
3. 3. 更新阶段：新工具上线只需部署新的 MCP Server，Agent 下次拉取清单时自动感知

🔑 企业级落地的关键决策

MCP Server 一定要独立部署，不能让 Agent 直连内部系统。

原因很简单：Agent 是一个"有主观判断"的组件，你无法完全预测它会怎么调用工具。通过 MCP Server 做一层隔离，可以在这一层做鉴权、审计、限流，大幅降低安全风险。

💡 一句话总结：MCP 是 Agent 工具接入的"标准化协议层"，把"烟囱式对接"变成"插件式扩展"。

二、多 Agent 调度：从"独行侠"到"特种小队"🎯

单 Agent 的天花板

想象你要完成这样一个任务："分析竞品动态，生成一份市场报告，并发给指定团队成员"。

如果让一个 Agent 串行完成，它需要：搜索信息 → 整理数据 → 撰写报告 → 发送通知。每一步都依赖上一步，整个链路很长，而且：

• • 上下文窗口撑满：中间过程的数据都堆在一个 Prompt 里，很快就超限
• • 一步出错，全盘重来：中间某个环节失败，整个任务失败
• • 速度慢：所有步骤串行，没法并发

多 Agent 的思路是：把一个大任务拆分给多个专业 Agent 并行处理，最后汇总结果。

Orchestrator + Worker 模式

OpenClaw 采用业界主流的 Orchestrator（编排者）+ Worker（执行者） 模式：

                  ┌─────────────────┐                  │  Orchestrator   │                  │ （任务拆解/汇总）│                  └────────┬────────┘           ┌───────────────┼───────────────┐           ▼               ▼               ▼    ┌─────────────┐ ┌─────────────┐ ┌─────────────┐    │ Search Agent│ │ Write Agent │ │Review Agent │    └─────────────┘ └─────────────┘ └─────────────┘

两类角色的职责划分：

任务调度的核心：DAG（有向无环图）

这里有个非常容易踩的坑：子任务之间的依赖关系，必须显式建模为 DAG，而不是靠 Prompt 隐式描述。

什么叫依赖关系？比如"写报告"必须等"搜索信息"完成，但"发送通知"可以等报告写完后独立触发。这种关系如果不明确建模，Agent 很可能会搞乱执行顺序。

任务 A（搜索竞品信息）    │    ├──────────────────┐    ▼                  ▼任务 B（数据分析）   任务 C（收集历史数据）    │                  │    └────────┬─────────┘             ▼         任务 D（生成报告）             │             ▼         任务 E（发送通知）

在这个 DAG 里，B 和 C 可以并行执行（都依赖 A），D 必须等 B 和 C 都完成，E 最后执行。Orchestrator 的核心能力，就是识别这种结构并驱动正确的执行顺序。

🔑 多 Agent 设计的三条铁律

1. 1. Worker Agent 要"无状态化"：每次调用传入完整上下文，不依赖本地状态，方便水平扩展和重试
2. 2. 子任务粒度要合适：太细了调度开销大，太粗了失去并发优势——一个好的子任务应该是"一个人、一件事"
3. 3. 失败要可重试：每个 Worker 的结果要记录，Orchestrator 支持对失败节点单独重跑，而不是整个任务重来

💡 一句话总结：多 Agent 调度的本质，是把"复杂任务"变成"可并行的 DAG"，用 Orchestrator 统一编排，Worker 专注执行。

三、Tool Router：给 Agent 配一个"工具导购" 🗂️

工具太多是个大问题

当系统里只有 5 个工具时，把所有工具描述都塞进 Prompt 完全没问题。但当工具数量增长到 50 个、500 个，问题就来了：

• • Token 爆炸：500 个工具的描述，每次推理都要消耗大量 Token，成本飙升
• • 噪音增大：工具越多，模型越容易被无关工具干扰，选错的概率直线上升
• • 延迟变长：处理大量工具描述本身就会拖慢推理速度

Tool Router 的目标很简单：在 Agent 需要工具之前，先帮它筛选出最相关的 Top-K 个，其余的不出现在 Prompt 里。

两层路由架构

OpenClaw 采用"粗筛 + 精排"的两层策略，思路和电商的推荐系统非常相似：

用户意图   │   ▼┌──────────────────────┐│  L1：语义召回          │  ← 向量检索，快速粗筛，召回 Top-20│  （Embedding 检索）   │└──────────┬───────────┘           │           ▼┌──────────────────────┐│  L2：LLM 精排         │  ← 让 LLM 从 20 个里选最合适的 Top-5│  （Rerank）           │└──────────┬───────────┘           │           ▼    Top-5 工具注入 Prompt

L1 语义召回：把所有工具描述预先向量化存入向量数据库。Agent 执行时，将当前任务描述向量化，做相似度检索，快速召回 20 个候选工具。这一步成本极低、速度极快。

L2 LLM 精排：把这 20 个候选工具的描述拼成一个轻量 Prompt，让 LLM 选出最相关的 5 个，并给出选择理由。候选工具少，这一步成本也很低，但准确率提升明显。

被严重低估的细节：工具描述的质量

工具描述写得越精准，路由就越准。 这是一个被大多数人忽视的工程细节。

来看一个对比：

❌ 差的工具描述：

query_order: 查询订单信息

✅ 好的工具描述：

query_order_status: 根据订单号查询订单的当前状态，包括支付状态、物流状态和预计到达时间。适用场景：用户询问"我的订单到哪了"、"订单有没有发货"等。不适用于：修改订单、取消订单、申请退款。

好的描述包含三个要素：功能说明 + 适用场景 + 不适用场景。写不适用场景尤为重要，它帮助模型在多个相似工具中做出更准确的区分。

各层路由方案对比

💡 一句话总结：Tool Router 是 Agent 的"导购员"，用两层路由把 500 个工具精准缩减到 5 个，既省 Token 又提准确率。

四、Memory 架构：让 Agent 不再"失忆" 🧠

Agent 为什么会"失忆"？

默认情况下，LLM 每次对话都是从零开始的——它不记得你上次说了什么，不记得上次任务怎么解决的，每次都像第一次见面。

这在个人助手场景还能接受，但在企业级场景，这是一个致命缺陷：

• • 用户反复解释同样的背景
• • Agent 遇到类似问题，无法复用之前的解决方案
• • 系统无法随使用积累"经验"

Memory 架构要解决的，就是让 Agent 拥有不同层次的"记忆能力"。

四层记忆模型

OpenClaw 将 Memory 分为四层，对应人类大脑的不同记忆机制：

这四层之间有明确的分工，不是替代关系，而是互补关系。

Working Memory：会话级的"工作台"

Working Memory 是当前任务执行过程中的中间状态容器。一个好的 Working Memory 应该存储：

• • 当前计划（Plan）：Orchestrator 拆解出来的子任务列表
• • 步骤历史（Step History）：已经执行了哪些步骤，结果是什么
• • 草稿板（Scratchpad）：工具调用的中间数据

一个关键设计：滑动窗口压缩。 当步骤历史超过一定长度时，不能无限堆叠，否则 Prompt 会撑爆。正确做法是把早期的步骤压缩成摘要，只保留最近 N 步的完整记录。这个摘要同时会被写入 Episodic Memory，供未来会话召回。

步骤 1、2、3 → 压缩为摘要 → 写入 Episodic Memory步骤 4、5、6 → 保留完整记录（在窗口内）步骤 7（当前）→ 正在执行

Episodic Memory：跨会话的"情景回忆"

这是 Memory 架构里最有价值、也最复杂的一层。它让 Agent 能记住"上次这类问题是怎么解决的"。

工作原理：

新会话开始    │    ▼提取当前任务的语义特征    │    ▼检索 Episodic Memory（向量相似度）    │    ▼召回最相关的 3~5 条历史 Episode    │    ▼注入 Prompt：「参考历史经验：上次处理类似问题时，步骤是...」    │    ▼Agent 基于经验执行当前任务

一个 Episode 应该存什么：

• • 任务描述（用于向量化，支持相似度检索）
• • 解决方案摘要（注入 Prompt 的内容）
• • 用到了哪些工具（辅助 Tool Router 决策）
• • 是否成功（负向经验同样有价值）
• • 执行时间、用户反馈等元数据

Semantic Memory：持久的"业务知识库"

这一层和 RAG（检索增强生成）高度重合——把企业的产品文档、业务规则、操作手册等知识存入向量数据库，Agent 需要时检索注入。

这里不展开 RAG 的细节，但有一点值得强调：Semantic Memory 是"静态的"，Episodic Memory 是"动态积累的"。前者存的是人工整理的知识，后者存的是系统运行中自动积累的经验。两者结合，才构成一个真正有"学习能力"的 Agent。

🔑 Memory 写入的时机：一定要异步

这是一个容易被忽视的工程细节。Memory 的写入不应该阻塞用户等待响应。

原因：Episodic Memory 的写入需要压缩摘要（一次 LLM 调用）+ 向量化 + 存库，这个过程可能需要几百毫秒甚至更长。把它放在同步链路上会直接拉高响应延迟。

正确的做法：

任务完成   │   ├── 同步 ──→ 清理 Working Memory → 返回结果给用户（快）   │   └── 异步 ──→ 压缩 Episode → 向量化 → 写入 Episodic Memory（慢，不影响用户）

💡 一句话总结：Memory 架构是 Agent 从"工具"走向"助手"的关键——四层记忆各司其职，让 Agent 既能聚焦当下任务，又能积累长期经验。

五、四个模块的全景整合 🗺️

把这四块拼在一起，一次完整的用户请求的处理流程如下：

用户请求    │    ▼┌───────────────────────────────────────────────────┐│                  Orchestrator                     ││                                                   ││  Memory Manager 召回历史 Episode ──→ 辅助 Task Planner 拆解任务  ││                                                   ││  Task Planner 生成 DAG，分发给 Worker Agent        │└───────────────────────────────────────────────────┘                            │        ┌───────────────────┼───────────────────┐        ▼                   ▼                   ▼ ┌────────────┐      ┌────────────┐      ┌────────────┐ │Worker Agent│      │Worker Agent│      │Worker Agent│ │ Tool Router│      │ Tool Router│      │ Tool Router│ │  精选工具  │      │  精选工具  │      │  精选工具  │ └─────┬──────┘      └─────┬──────┘      └─────┬──────┘       │                   │                   │       ▼                   ▼                   ▼  MCP Client           MCP Client          MCP Client       │                   │                   │ ─────────────────────────────────────────────────────                      MCP Servers          （ERP / 文件系统 / 数据库 / 外部 API）

数据流向总结：

• • 向内流：用户请求 → Orchestrator → 召回 Episodic Memory → Task Planner → Worker Agent → Tool Router → MCP Client → 工具执行
• • 向外流：工具结果 → Worker Agent → Orchestrator 汇总 → 返回用户
• • 异步写：任务完成后 → 压缩 Episode → 写入 Episodic Memory

六、模块对比速查表 📋

写在最后

这篇文章聊的四个模块，其实背后有一个共同的设计哲学：把"隐式的复杂度"变成"显式的结构"。

• • MCP 把"散乱的工具接入"变成"标准化协议"
• • 多 Agent 调度把"模糊的大任务"变成"清晰的 DAG"
• • Tool Router 把"全量工具 Prompt"变成"精准的动态召回"
• • Memory 架构把"无状态的对话"变成"有层次的记忆体系"

Agent 工程的难度，往往不在于调用 LLM 本身，而在于这些"胶水层"的设计质量。每一个模块都需要结合你的业务场景反复打磨，没有银弹。

觉得有收获？欢迎 点赞 + 转发 给身边对AI感兴趣的朋友 👋关注 瀚曦说，一起跟上AI时代的节奏。