AI教程 2026/05/10 7 分钟

OpenClaw 深度拆解：新一代 AI Agent 框架的架构设计与生态野心

从工作流引擎、Skill 系统、MCP 集成、多模态支持四个维度拆解 OpenClaw，对比 LangGraph/CrewAI 给出迁移路径和适用场景分析。

AinoCode 编辑部

OpenClaw 深度拆解：新一代 AI Agent 框架的架构设计与生态野心

2026 年的 AI Agent 框架赛道，LangGraph 和 CrewAI 占了开发者心智的半壁江山。但有一个新名字出现频率越来越高：OpenClaw。

它不是一个”又一个 Agent 框架”。OpenClaw 在架构层面做了几件 LangGraph 和 CrewAI 没有做过——或者说没有做好——的事：

把 Skill 系统做成了一等公民，而不是事后追加的插件。
原生支持 MCP，不是通过 adapter 桥接，而是从协议层开始设计。
多模态支持不是”能处理图片”，而是从工作流引擎层面原生理解多模态输入输出。
声明式工作流定义，而不是 Python 代码里用 decorator 堆出来的 DAG。

这篇文章不是产品宣传。我要做的是把 OpenClaw 的架构拆开，看每一层怎么工作，和 LangGraph/CrewAI 比差异在哪，以及——最重要的——你的团队到底要不要换。

一、架构总览

┌─────────────────────────────────────────────────────────┐
│                    Application Layer                     │
│  Workflow YAML / SDK / CLI / Web Console                │
└──────────────────┬──────────────────────────────────────┘
                   │
┌──────────────────▼──────────────────────────────────────┐
│                  Workflow Engine                         │
│  声明式 DAG + 条件分支 + 并行执行 + 错误恢复            │
│  (类似 Airflow 的 DAG 定义方式，但是为 LLM 任务设计)     │
└──────────────────┬──────────────────────────────────────┘
                   │
        ┌──────────┼──────────┐
        ▼          ▼          ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Skill    │ │ MCP      │ │ Multi-   │
│ Runtime  │ │ Gateway  │ │ modal    │
│          │ │          │ │ Engine   │
└──────────┘ └──────────┘ └──────────┘
        │          │          │
        └──────────┼──────────┘
                   ▼
┌─────────────────────────────────────────────────────────┐
│                  Infrastructure Layer                    │
│  LLM Provider / Vector Store / Message Queue / Cache    │
└─────────────────────────────────────────────────────────┘

OpenClaw 的核心理念是：Agent 应该由可组合的 Skill 构成，通过声明式工作流编排，通过 MCP 协议接入外部工具。

这和 LangGraph 的”图即代码”理念有本质差异。

二、工作流引擎：声明式 vs 代码式

LangGraph 的工作流

在 LangGraph 里，工作流是用 Python 代码构建的状态机：

from langgraph.graph import StateGraph, END

workflow = StateGraph(AgentState)
workflow.add_node("research", research_node)
workflow.add_node("write", write_node)
workflow.add_node("review", review_node)

workflow.add_edge("research", "write")
workflow.add_edge("write", "review")
workflow.add_conditional_edges("review", should_revise, {
    "revise": "write",
    "approve": END,
})

app = workflow.compile()

好处是灵活，坏处是：

工作流逻辑和业务逻辑混在同一个文件里
调试需要跑代码才能看到图结构
修改工作流 = 改代码 = 重新部署

OpenClaw 的工作流

# workflow.yaml
name: article-generation
version: "1.0"

steps:
  - id: research
    skill: web-research
    input:
      topic: "{{ params.topic }}"
    parallel: false
    
  - id: outline
    skill: content-outline
    input:
      research_results: "{{ steps.research.output }}"
    
  - id: draft
    skill: content-writer
    input:
      outline: "{{ steps.outline.output }}"
    retry:
      max_attempts: 2
      on_error: "regenerate"
    
  - id: review
    skill: content-reviewer
    input:
      draft: "{{ steps.draft.output }}"
    
  - id: publish
    skill: cms-publisher
    input:
      content: "{{ steps.draft.output }}"
      review: "{{ steps.review.output }}"
    condition: "{{ steps.review.approved == true }}"
    on_fail:
      action: "notify"
      channel: "slack"

声明式工作流的几个关键差异：

可读性：一个不懂 Python 的产品经理也能看懂工作流。
版本控制：YAML diff 比 Python diff 直观得多。
热更新：修改工作流定义不需要重启服务。
可观测性：每一步的输入输出自动记录，开箱即用的 tracing。

代价

声明式 = 灵活性牺牲。如果你的工作流有大量动态生成的节点、运行时决定的分支，OpenClaw 的 YAML 可能不够表达。LangGraph 的 Python 代码在这方面没有上限。

三、Skill 系统：一等公民

OpenClaw 的 Skill 是整个框架的核心抽象。一个 Skill 就是一个可复用的能力单元。

Skill 定义

# skills/web-research/SKILL.md
name: web-research
version: "1.0"
description: "从多个搜索引擎获取 topic 相关信息并结构化输出"

inputs:
  - name: topic
    type: string
    required: true
  - name: depth
    type: integer
    default: 3
    
outputs:
  - name: findings
    type: array
    schema:
      - url: string
      - title: string
      - summary: string
      - relevance_score: float

tools:
  - google-search
  - url-extractor
  - content-summarizer

instructions: |
  1. 使用 google-search 搜索 topic
  2. 取前 depth 个结果
  3. 用 url-extractor 获取页面内容
  4. 用 content-summarizer 生成摘要
  5. 按 relevance_score 排序输出

llm_config:
  model: "gpt-4o"
  temperature: 0.3
  max_tokens: 4000

和 LangGraph / CrewAI 的对比

维度	OpenClaw	CrewAI	LangGraph
能力封装	SKILL.md（声明式）	Agent 类（代码）	Node 函数（代码）
复用性	跨项目即插即用	需要 copy agent 定义	需要 copy node 代码
版本管理	Skill version + 独立仓库	无内建版本	无内建版本
热加载	支持	不支持	不支持
组合方式	YAML 工作流引用	Agent 间 delegation	Graph 边连接

实际影响

Skill 系统的最大价值不是”写起来更方便”，而是团队协作方式的改变：

一个开发者负责维护 web-research skill，所有项目复用。
测试团队可以单独测试一个 skill 的输入输出，不需要启动整个工作流。
运营团队可以配置新的工作流组合，不需要等开发改代码。

CrewAI 的 Agent 和 LangGraph 的 Node 更像是”代码模块”，而 OpenClaw 的 Skill 更像是”产品能力”。

四、MCP 集成：原生支持

MCP（Model Context Protocol）已经成为 AI Agent 接入外部工具的事实标准。但各框架的支持程度差异很大。

CrewAI 的 MCP 支持

# CrewAI 通过 Tool 包装
from crewai.tools import BaseTool

class MCPToolWrapper(BaseTool):
    def __init__(self, mcp_server_url: str):
        # 需要自己实现 MCP client
        self.client = MCPClient(mcp_server_url)
    
    def run(self, **kwargs):
        return self.client.call_tool(**kwargs)

需要自己桥接。每个 MCP Server 写一个 wrapper。

LangGraph 的 MCP 支持

# LangChain MCP Adapter
from langchain_mcp import MCPServer

server = MCPServer("stdio", command="npx", args=["-y", "@modelcontextprotocol/server-filesystem"])
tools = server.get_tools()  # 返回 LangChain Tool 对象

通过 adapter 转换。能用，但多了一层抽象。

OpenClaw 的 MCP 集成

# 在 workflow 或 skill 中直接引用
tools:
  - mcp: filesystem
    server: "stdio://npx -y @modelcontextprotocol/server-filesystem /workspace"
    operations: ["read", "write", "list"]
    
  - mcp: database
    server: "http://localhost:3001"
    operations: ["query", "insert"]
    
  - mcp: github
    server: "sse://github-mcp-server.example.com"
    operations: ["create_issue", "list_repos"]

MCP 是原生协议，不需要 adapter。OpenClaw 直接消费 MCP Server 的 tool definitions，自动映射到 skill 的工具调用。

MCP Gateway 模式

OpenClaw 还引入了 MCP Gateway——一个集中管理所有 MCP Server 的代理层：

Skill → MCP Gateway → [文件系统 MCP]
                     → [数据库 MCP]
                     → [GitHub MCP]
                     → [飞书 MCP]

Gateway 做的事情：

统一鉴权：所有 MCP Server 的 token 集中在 Gateway 管理
请求路由：根据 tool name 自动路由到对应的 Server
限流与熔断：防止某个 MCP Server 慢查询拖垮整个工作流
审计日志：所有工具调用自动记录

这对企业环境特别重要。CrewAI 和 LangGraph 都需要你自己实现这些。

五、多模态支持

OpenClaw 的多模态不是”能处理图片”，而是从工作流引擎层面原生理解多模态数据流。

数据流设计

steps:
  - id: capture
    skill: screenshot-capture
    output_type: image/png
    
  - id: analyze
    skill: vision-analyzer
    input:
      image: "{{ steps.capture.output }}"  # 直接传递 image 类型
      prompt: "分析截图中的 UI 问题"
    output_type: json
    
  - id: generate_fix
    skill: code-fixer
    input:
      analysis: "{{ steps.analyze.output }}"  # json → text 自动转换
      source_code: "{{ read_file('src/App.tsx') }}"

关键差异：

类型感知：每一步声明输出类型（image / json / text），框架自动处理类型转换。
大对象传递：图片、音频等大对象不通过 prompt 传递，而是通过内部对象存储，只在 prompt 中引用指针。
多模态 Skill：一个 Skill 可以同时处理多种模态的输入输出，不需要拆成多个步骤。

和 LangGraph 对比

LangGraph 也能处理多模态，但需要你自己在 state 里管理：

class MultiModalState(TypedDict):
    image: bytes  # 你自己管理编码/解码
    analysis: dict
    fix: str
    
# 每个 node 都要处理 image bytes 的传递
def vision_node(state: MultiModalState):
    image = state["image"]  # 需要自己处理 base64 编码等
    # ...

OpenClaw 把这个过程自动化了。代价是你失去了对底层传递细节的控制权。

六、错误恢复机制

这是 OpenClaw 相比竞品最被低估的一个功能。

内置重试策略

steps:
  - id: draft
    skill: content-writer
    retry:
      max_attempts: 3
      strategy: "exponential_backoff"  # 指数退避
      backoff_base: 2
      on_error: "regenerate"           # 重试时重新生成
      fallback:                        # 最终失败后的降级方案
        skill: template-writer
        input:
          template: "basic-article"
          topic: "{{ params.topic }}"

LangGraph 的错误处理需要你自己在代码里写 try/except 和状态回滚。CrewAI 有基本的重试但不支持策略配置。

Checkpointing

OpenClaw 的每个步骤执行完成后会自动 checkpoint：

[2026-05-10 06:15:22] step=research status=completed checkpoint_id=ck_abc123
[2026-05-10 06:15:23] step=outline status=completed checkpoint_id=ck_def456
[2026-05-10 06:15:25] step=draft status=failed error="rate_limit"
[2026-05-10 06:15:25] retry step=draft attempt=2/3
[2026-05-10 06:15:30] step=draft status=completed checkpoint_id=ck_ghi789

如果工作流中断（服务器重启、网络断开），可以从最近的 checkpoint 恢复，不需要从头执行。

七、迁移路径：从 LangGraph / CrewAI 到 OpenClaw

CrewAI → OpenClaw

CrewAI 的 Agent → OpenClaw Skill 的映射最直接：

# CrewAI
researcher = Agent(
    role="Researcher",
    goal="Research the topic",
    backstory="You are an expert researcher",
    tools=[search_tool],
    llm=llm,
)

# OpenClaw - 等价
# skills/researcher/SKILL.md
name: researcher
instructions: |
  你是一个专家研究员。
  你的目标是调研指定 topic。
  使用 search_tool 获取信息并结构化输出。
tools:
  - search-tool
llm_config:
  model: "gpt-4o"

迁移成本：低。Agent 定义基本可以逐行翻译为 SKILL.md。

LangGraph → OpenClaw

LangGraph 的迁移更复杂，因为工作流是用代码写的：

# LangGraph
workflow.add_conditional_edges("review", should_revise, {...})

需要分析每个 node 的输入输出关系、条件分支逻辑、状态传递，然后翻译成 YAML。

迁移成本：中到高。建议按以下顺序渐进迁移：

先在最简单的场景（线性工作流）试水
逐步把条件分支也迁过来
复杂动态工作流保留在 LangGraph，通过 MCP 和 OpenClaw 通信

八、适用场景分析

应该选 OpenClaw 的场景

场景	理由
内容生产流水线	声明式工作流 + Skill 复用 = 快速搭建内容 pipeline
多 MCP Server 集成	原生 MCP + Gateway = 开箱即用的工具管理
企业级 Agent 平台	热更新 + 版本管理 + 审计日志 = 运维友好
非技术团队参与编排	YAML 工作流 = 产品经理可配置
多模态任务流	类型感知 + 大对象传递 = 减少胶水代码

应该保留 LangGraph / CrewAI 的场景

场景	理由
高度动态的工作流	运行时决定 DAG 结构，YAML 表达不了
极致的灵活性需求	Python 代码 > YAML 的表达力
已有大量 LangGraph/CrewAI 投资	迁移成本 > 收益
小型团队快速原型	CrewAI 的上手速度最快

九、OpenClaw 的生态野心

OpenClaw 不只是想做一个框架。从它的架构可以看出更大的意图：

Skill Marketplace：标准化 Skill 定义格式，天然支持第三方 Skill 的发布和订阅。
MCP 优先：通过 MCP 协议，OpenClaw 可以连接任何实现了 MCP 的 Server，不局限于自己生态。
声明式工作流：降低编排门槛，让”组装 Agent”变成”画流程图”级别的难度。

它的竞品不是 LangGraph 或 CrewAI，而是整个 Agent 编排层的标准制定权。

十、总结

OpenClaw 的核心设计哲学可以概括为一句话：把 Agent 从代码变成产品。

Skill 系统让能力可复用、可版本化、可热加载
声明式工作流让编排从代码变成配置
原生 MCP 让工具接入从写 adapter 变成写 YAML
多模态原生支持让复杂数据流不需要胶水代码
内置错误恢复让生产部署更可靠

但这不意味着你应该立刻从 LangGraph 或 CrewAI 迁移过来。OpenClaw 的生态还在早期，社区规模、文档完整性、第三方 Skill 数量都远不及 LangChain 生态。

务实的建议：新项目可以在非核心场景先试 OpenClaw，跑通 2-3 个工作流后评估收益。存量项目不建议急着迁移，除非你已经被 LangGraph 的”代码即工作流”模式卡住了可维护性的脖子。

#OpenClaw #Agent 框架 #LangGraph #CrewAI #工作流引擎 #MCP #多模态