什么是 AI Agent，为什么说 OpenClaw 是炒冷饭？

最近 AI Agent 概念火得不行，各种开源项目层出不穷。但仔细看会发现，很多项目只是把 2023 年就有的技术重新组合了一遍。

AI Agent 和普通的对话 AI 有什么区别？简单说，Agent 会用工具、能查资料、可以执行复杂任务。听起来很厉害，但技术上并没有什么新东西。

Agent 的核心组件

Memory（记忆）

大模型本身没有记忆，每次对话都是从零开始。Memory 机制就是给它加个"笔记本"。

实现起来很简单：

短期记忆：把最近的对话塞进上下文窗口
长期记忆：重要的东西存到数据库里

RAG（检索增强生成）

大模型的知识会过时，RAG 让它能查资料。

传统数据库只能做字面匹配。比如搜"韩老魔"，找不到"黄枫谷厉飞羽"，虽然它们指的是同一个人。

解决办法是把文本转成向量，用向量距离判断语义相似度。向量数据库（Milvus、Pinecone、PostgreSQL 的 pgvector）就是干这个的。

RAG 的流程：用户提问 → 转成向量 → 在数据库里找相似内容 → 把结果喂给大模型 → 生成回答。

Tool Use（工具使用）

有了 Memory 和 RAG，大模型能记事、能查资料，但还是只能说话。Tool Use 让它能动手干活。

工作原理

Tool Use 的核心是约定一种消息格式：

外部系统告诉大模型有哪些工具，包括名称、描述、参数
大模型在回复中说要调用哪个工具
外部系统执行工具，返回结果
大模型拿到结果继续干活

工具定义示例

json

{
  "name": "search_web",
  "description": "搜索网页内容，返回相关结果",
  "parameters": {
    "type": "object",
    "properties": {
      "query": {
        "type": "string",
        "description": "搜索关键词"
      },
      "max_results": {
        "type": "integer",
        "description": "最多返回结果数",
        "default": 5
      }
    },
    "required": ["query"]
  }
}

大模型的调用请求

json

{
  "tool_calls": [
    {
      "id": "call_123",
      "type": "function",
      "function": {
        "name": "search_web",
        "arguments": "{\"query\": \"AI Agent 技术原理\", \"max_results\": 3}"
      }
    }
  ]
}

工具返回结果

json

{
  "tool_call_id": "call_123",
  "role": "tool",
  "content": "[{\"title\": \"AI Agent 入门\", \"url\": \"...\", \"snippet\": \"...\"}]"
}

常见工具类型

工具类型	功能	示例
信息检索	搜索、查询数据	网页搜索、数据库查询
文件操作	读写文件	读取文件、写入文件
代码执行	运行代码	Python 解释器、Shell 命令
API 调用	调用外部服务	天气 API、翻译 API
系统操作	操作系统功能	创建文件夹、发送邮件

Tool Use 的问题

工具调用听起来很美好，但实际用起来有不少坑：

安全风险：工具可能删文件、发邮件，搞砸了很麻烦
错误处理：工具调用失败怎么办？重试还是放弃？
成本控制：频繁调用 API 会烧钱
调用链复杂：多个工具串起来容易出错

MCP（Model Context Protocol）

Anthropic 在 2024 年搞了个 MCP 协议，想统一大模型和外部工具的交互方式。就像 USB 统一了硬件接口一样。

在 MCP 之前，每家都有自己的格式：OpenAI 的 Function Calling、Anthropic 的 Tool Use、LangChain 的 Tool 抽象，还有各种自定义实现。结果就是每个应用都要重新实现一遍工具，工具没法复用，维护起来很麻烦。

MCP 的架构

MCP 用的是客户端-服务器架构。AI 应用（Host）通过 MCP 客户端（Client）连接 MCP 服务器（Server），服务器提供工具和资源。

MCP 定义了三种东西：

Resources（资源） - 可以读取的数据，比如文件、数据库记录、API 响应。

Tools（工具） - 可以调用的函数，比如搜索、计算、文件操作。

Prompts（提示词模板） - 预定义的提示词，可以复用。

MCP 服务器示例

一个简单的 MCP 服务器（Python）：

python

from mcp.server import Server
from mcp.types import Tool, Resource

server = Server("my-mcp-server")

@server.list_tools()
async def list_tools():
    return [
        Tool(
            name="get_weather",
            description="获取天气信息",
            inputSchema={
                "type": "object",
                "properties": {
                    "city": {"type": "string"}
                }
            }
        )
    ]

@server.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "get_weather":
        city = arguments["city"]
        # 调用天气 API
        return {"temperature": 25, "condition": "晴"}

MCP 的优势和问题

MCP 确实解决了一些问题：统一了格式，工具可以跨应用复用，内置了权限控制。

但也有不少坑：

生态还不成熟，MCP 服务器数量有限
学习成本高，要理解协议规范
进程间通信有延迟
客户端-服务器架构调试起来很麻烦

Claude Desktop、VS Code 扩展、一些企业应用在用 MCP，但普及度还不高。

Skills（技能系统）

Skills 是对 Tool Use 的高级封装，把多个工具和提示词打包成"技能包"。就像给 AI Agent 装应用一样。

Tool 是单个函数（比如 read_file(path)），Skill 是工具组合加工作流（比如 code_review：读文件 + 分析代码 + 生成报告）。

一个 Skill 包含：工具集合、提示词模板、工作流程。

Skill 的结构

以"代码审查"Skill 为例：

yaml

name: code_review
description: 对代码进行全面审查
version: 1.0.0

tools:
  - read_file        # 读取代码文件
  - search_code      # 搜索相关代码
  - run_linter       # 运行代码检查工具

prompts:
  system: |
    你是一个代码审查专家。请按以下步骤审查代码：
    1. 读取目标文件
    2. 搜索相关的依赖代码
    3. 运行 linter 检查
    4. 分析代码质量、安全性、性能
    5. 生成审查报告

workflow:
  - step: read_target
    tool: read_file
    input: ${file_path}

  - step: search_dependencies
    tool: search_code
    input: ${imports}

  - step: lint_check
    tool: run_linter
    input: ${file_path}

  - step: generate_report
    action: analyze_and_report

Skills 的实际应用

Claude Desktop 支持通过配置文件定义 Skills。比如 commit 技能（分析代码变更并生成提交信息）、review-pr 技能（审查 PR 的代码变更）。

开发者也可以自己写 Skills。比如一个数据分析 Skill：读 CSV → 分析数据 → 画图 → 生成报告。

Skills 的优缺点

好处是封装了复杂性，可以复用，用户不用了解底层细节。

坏处是简单任务用 Skill 反而麻烦，预定义的流程不够灵活，还得维护。

Skills 可以基于 MCP 实现，形成三层架构：Skill 层（高级封装）→ MCP 层（标准协议）→ 实现层（具体功能）。

为什么说一些项目是"炒冷饭"？

技术本质没变

很多"新"项目只是把这些技术组合起来：

Memory = 数据库存储
RAG = 向量检索 + 上下文注入
Tool Use = 函数调用
MCP = 标准化接口
Skills = 工具封装

这些技术 2023 年就有了。

案例：OpenClaw vs Claude Desktop

拿 OpenClaw 举例（假设它是个开源 AI Agent 项目）：

对话能力：OpenClaw 调用 API，Claude Desktop 原生支持工具调用：OpenClaw 自定义实现，Claude Desktop 用 MCP 标准安全隔离：OpenClaw 本地执行，Claude Desktop 可选沙箱部署方式：OpenClaw 要自己部署，Claude Desktop 开箱即用

OpenClaw 的"创新"只是把已有技术重新包装，核心问题一个没解决。

真正的挑战

AI Agent 的难点不在于"能不能做"，而在于：

安全性：怎么防止 Agent 删文件、发垃圾邮件？可靠性：怎么保证 Agent 不会陷入死循环？成本控制：怎么避免 API 调用费用失控？用户体验：怎么让普通用户能轻松使用？

简单堆砌技术解决不了这些问题。

理性看待 AI Agent

很多项目打着"革命性"、"颠覆性"的旗号，但仔细看只是旧技术重新包装。

在用或开发 AI Agent 之前，先问自己：

我到底要 Agent 做什么？
这事真的需要 Agent 吗？
现有工具能不能解决？

真正有价值的创新应该是提出新架构、解决现有痛点、降低使用门槛、提升安全性和可靠性，而不是简单地把已有技术重新组合。

总结

AI Agent 的技术栈：Memory（记忆）、RAG（检索）、Tool Use（工具）、MCP（协议）、Skills（封装）。

这些技术 2023-2024 年就成熟了。很多"新"项目只是重新组合，没什么实质性创新。

技术演进路径：对话式 AI → 加 Memory → 加 RAG → 加 Tool Use → 加 MCP → 加 Skills → 完整的 AI Agent。

选择或开发 AI Agent 时：理解技术本质，明确实际需求，评估技术成熟度，关注真正创新。

技术本身没有好坏，关键在于是否真正解决了用户的问题。