什么是 AI Agent？从 LLM 到自主执行

第一次接触 AI 的人，大概都会感叹：这玩意儿真聪明。但用久了你会发现一个根本限制——它只会说，不会做。

你问它”帮我发封邮件”，它会给你写好草稿，然后说”你可以把这段文字复制到邮件客户端发送”。

这就是 LLM 和 Agent 的核心区别。

LLM 是什么：一台无状态的预测机器

大语言模型的本质是一个条件概率函数：给定一段文本，预测下一个 token 最可能是什么。它没有记忆（每次对话都是从零开始），没有持久状态，更没有办法主动触发任何副作用。

输入 tokens → Transformer 前向传播 → 输出 tokens

这个过程是纯函数式的——相同输入（温度为 0 时）得到相同输出，不会对外部世界产生任何影响。

那么，Agent 是什么让 LLM “动”起来的？

Agent 的四个核心能力

一个完整的 AI Agent 围绕 LLM 构建了四层能力：

1. 感知（Perception）

Agent 能接收多种形式的输入：文字、图片、文件内容、网页、API 返回值、代码执行结果……

这不是 LLM 原生支持的——需要一层输入处理管道，把外部世界的信号转换成 token 序列送给模型。

2. 记忆（Memory）

LLM 的上下文窗口是它唯一的”工作记忆”。一旦超出窗口大小，早期信息就被截断了。

Agent 通过外部存储（向量数据库、文件、KV store）实现长期记忆，并在需要时检索相关内容注入上下文。

3. 规划（Planning）

面对一个复杂任务，LLM 需要把它分解成可执行的步骤。这包括：

• 任务分解：把”帮我整理这份报告”拆成若干子任务
• 自我反思：执行结果不符合预期时，重新规划
• 依赖管理：哪些步骤可以并行，哪些必须串行

4. 行动（Action / Tool Use）

这是最关键的一环。Agent 通过工具调用与外部世界交互：

• 读写文件
• 执行代码
• 调用 API
• 浏览网页
• 发送消息

工具调用把 LLM 从”只会说”变成了”能做”。

ReAct：驱动 Agent 运转的核心框架

ReAct（Reasoning + Acting）是目前最主流的 Agent 执行框架，2022 年由 Google 提出。

其核心思路是让 LLM 在推理和行动之间交替循环：

Thought: 我需要知道今天的天气，让我调用天气 API
Action: get_weather(city="上海")
Observation: {"temp": 22, "condition": "晴"}
Thought: 天气不错，现在我可以回答用户了
Answer: 上海今天晴天，22°C，适合出行

每一轮：

1. Thought：模型输出推理过程（Chain-of-Thought）
2. Action：模型决定调用哪个工具，参数是什么
3. Observation：工具执行结果反馈给模型
4. 循环直到任务完成或达到最大步数

这个循环的关键洞察是：让模型先想清楚再行动，行动结果再反哺思考。

Tool Use 原理：Function Calling

工具调用在技术上是怎么实现的？以 OpenAI 的 Function Calling 为例：

// 工具描述（JSON Schema）
{
  "name": "read_file",
  "description": "读取本地文件内容",
  "parameters": {
    "type": "object",
    "properties": {
      "path": {
        "type": "string",
        "description": "文件路径，绝对路径或相对路径"
      }
    },
    "required": ["path"]
  }
}

你把工具描述（一组 JSON Schema）和用户消息一起发给模型，模型如果判断需要用工具，会返回一个结构化的调用指令：

{
  "tool_calls": [{
    "function": {
      "name": "read_file",
      "arguments": "{\"path\": \"/tmp/report.txt\"}"
    }
  }]
}

你的代码负责实际执行这个调用，把结果作为 tool 角色消息返回给模型，模型继续推理。

模型本身并不执行任何代码——它只是输出结构化的”意图”，宿主程序负责执行。

Agent vs Chatbot vs Workflow

这三个词经常被混用，但有本质区别：

Workflow 适合已知流程的自动化——你知道第一步做什么、第二步做什么。
Agent 适合未知路径的任务——你只知道目标，具体怎么达到由模型决定。

一个完整执行例子：文件操作 Agent

任务：「找出 /tmp/logs/ 下所有包含 ERROR 的日志文件，统计每个文件的错误数量，写成报告」

用户: 找出 /tmp/logs/ 下所有包含 ERROR 的日志文件，统计每个文件的错误数量，写成报告

[Thought] 我需要先列出 /tmp/logs/ 目录下的所有文件
[Action] list_directory(path="/tmp/logs/")
[Observation] ["app.log", "access.log", "error.log", "worker.log"]

[Thought] 现在逐个检查哪些文件包含 ERROR
[Action] search_in_file(path="/tmp/logs/app.log", pattern="ERROR")
[Observation] 找到 23 处匹配

[Action] search_in_file(path="/tmp/logs/access.log", pattern="ERROR")
[Observation] 找到 0 处匹配

[Action] search_in_file(path="/tmp/logs/error.log", pattern="ERROR")
[Observation] 找到 157 处匹配

[Action] search_in_file(path="/tmp/logs/worker.log", pattern="ERROR")
[Observation] 找到 8 处匹配

[Thought] access.log 没有 ERROR，其他三个有。现在生成报告。
[Action] write_file(path="/tmp/error_report.md", content="# 错误统计报告\n...")
[Observation] 文件写入成功

[Answer] 报告已生成至 /tmp/error_report.md，共 3 个文件包含错误：
- error.log: 157 处
- app.log: 23 处  
- worker.log: 8 处

整个过程中，模型决定了执行路径，而不是程序员预先写好的固定流程。

主流框架横向对比

选型建议：

• 快速原型 / 非技术团队 → Dify
• Python 重度用户，RAG 场景 → LlamaIndex
• 复杂多 Agent 协作 → AutoGen
• 本地私有化、系统集成 → OpenClaw
• 最广泛生态 → LangChain（但注意 API 频繁变动）

注：上图为作者主观评分（1=最低，5=最高），仅供参考。上手难度、工具生态、社区活跃度随版本迭代持续变化，以各框架官方文档为准。

总结

LLM 是 Agent 的大脑，但光有大脑还不够。Agent 是在 LLM 外面包了一层执行环境：

外部世界 ←→ [工具层] ←→ [记忆层] ←→ [规划层] ←→ LLM

ReAct 循环驱动这个系统持续运转，直到任务完成。

理解 Agent 的关键认知转变是：从「问答」到「委托」。你不再是在和一个聊天机器人对话，而是在给一个能动的执行者下达目标。