Agent 系列（一）：Agent 是什么——不只是「会调工具的 LLM」

你以为你在用 Agent，其实你只是在用一个高级聊天框

2023 年，"AI Agent"突然成了热词。每家公司都在说自己做了 Agent，每个产品都贴上了 Agent 的标签。

但如果你问他们：你的 Agent 和普通 LLM 调用有什么本质区别？

大多数人会沉默 3 秒，然后说："……它能调工具。"

这个回答错了吗？没错，但也没说到点子上。就好像有人问"汽车和自行车有什么区别"，你回答"汽车有四个轮子"——对，但你漏掉了发动机。

这篇文章的目标只有一个：帮你搞清楚 Agent 到底是什么，以及它和 LLM、Chatbot 的本质区别在哪里。搞清楚这个，你才能在实际工作中做出正确的技术选型——而不是把一个 LLM API 调用包装一下，对外号称"我们有 Agent 系统"。

---

从一个场景说起

假设你要做一个"帮用户分析竞品"的 AI 工具。用户输入一个公司名，工具输出竞品分析报告。

方案 A：直接调 LLM

用户输入：分析一下 Notion 的竞品
↓
LLM 直接生成报告
↓
输出（基于训练数据，可能已经过时）

方案 B：Chatbot

用户输入：分析一下 Notion 的竞品
↓
LLM 生成回复，记住对话历史
用户追问：重点对比一下价格策略
↓
LLM 结合上下文继续回答
↓
多轮对话，但还是基于训练数据

方案 C：Agent

用户输入：分析一下 Notion 的竞品
↓
Agent 思考：我需要最新数据，应该先搜索
↓
调用搜索工具，拿到最新竞品信息
↓
Agent 思考：需要分析价格对比，调用计算工具
↓
Agent 思考：信息足够了，开始生成报告
↓
输出（基于实时搜索结果，有数据来源）

看出来了吗？Agent 会主动思考"我需要做什么"，并自主决定下一步行动。这才是 Agent 的核心——不是能不能调工具，而是谁在决定何时调哪个工具。

---

三个概念，三个层次

LLM：有语言能力的"大脑"

大语言模型（LLM）本质上是一个函数：

输入：一段文本（Prompt）
输出：预测的下一个词（不断重复直到结束）

它的能力来自于在海量文本上学到的统计规律。它懂语言，懂推理，但它没有记忆、没有感知、没有行动能力。每次调用都是独立的，上一次聊了什么，它完全不知道。

单独的 LLM 更像一个只知道"回答问题"的天才学者：知识渊博，但住在与世隔绝的书房里，不知道窗外发生了什么，也没法主动帮你做任何事。

Chatbot：加了记忆的 LLM

Chatbot = LLM + 对话历史管理。

它解决的问题很简单：让 LLM 能"记住"这轮对话说了什么。实现方式也很简单——把历史消息一起塞进 Prompt：

# 伪代码：Chatbot 的核心逻辑
messages = []
while True:
    user_input = get_user_input()
    messages.append({"role": "user", "content": user_input})
    response = llm.invoke(messages)  # 把全部历史一起发给 LLM
    messages.append({"role": "assistant", "content": response})
    print(response)

Chatbot 的局限在于：它只能聊，不能做。它没法主动去查资料、调用 API、执行代码——它只能根据记忆里的信息给你答案。

如果说 LLM 是天才学者，Chatbot 就是这位学者终于装了电话——你们能对话了，但他还是待在书房里。

Agent：会主动行动的"执行者"

Agent 在 Chatbot 的基础上加了两个关键能力：工具使用和自主决策循环。

但这里有个关键点常被误解：工具本身不是 Agent 的核心，"谁来决定用哪个工具、什么时候用"才是。

• Chatbot 配工具 = 你告诉它"查一下天气"，它才会调天气 API
• Agent = 它自己判断"回答这个问题需要查天气"，然后主动去调

这个区别，就是被动响应和主动规划的区别。

---

Agent 的四要素

理解 Agent，最清晰的框架是把它拆成四个部分。这个框架来自认知科学对智能行为的研究，也是目前工程实现的主流理解方式。

┌─────────────────────────────────────────────────────────┐
│                        Agent                            │
│                                                         │
│  ┌─────────────┐    ┌─────────────┐    ┌─────────────┐  │
│  │  感知        │    │  记忆        │    │  行动        │  │
│  │ Perception  │    │  Memory     │    │  Action     │  │
│  │             │    │             │    │             │  │
│  │ · 用户消息   │    │ · 对话历史   │    │ · 调用工具   │  │
│  │ · 工具结果   │    │ · 工具结果   │    │ · 执行代码   │  │
│  │ · 环境状态   │    │ · 外部知识库  │    │ · 调用 API   │  │
│  └──────┬──────┘    └──────┬──────┘    └──────▲──────┘  │
│         │                  │                  │         │
│         └──────────┬───────┘                  │         │
│                    ▼                           │         │
│             ┌─────────────┐                   │         │
│             │  决策/推理   │───────────────────┘         │
│             │  Reasoning  │                             │
│             │             │                             │
│             │ · 规划步骤   │                             │
│             │ · 选择工具   │                             │
│             │ · 判断终止   │                             │
│             └─────────────┘                             │
└─────────────────────────────────────────────────────────┘

感知（Perception）：Agent 能"看到"什么。最基本的是用户输入，进阶一点还有工具的返回结果、外部数据库的查询结果，甚至是截图、文件内容。感知决定了 Agent 的"眼界"——它不知道的，就做不到。

记忆（Memory）：Agent 能"记住"什么。这里的记忆分几个层次：当前对话的历史（短期记忆），通过向量数据库存储的过往经验（长期记忆），以及静态的外部知识库（语义记忆）。我们后面会单独写一篇专门讲记忆系统。

决策/推理（Reasoning）：这是 Agent 的"大脑"，也是它和 Chatbot 最本质的区别所在。LLM 在这里扮演的角色是控制器，而不是"回答问题的工具"。它负责：拆解任务、规划步骤、选择下一步该用哪个工具、判断任务是否完成。

行动（Action）：Agent 能"做"什么。工具调用是最常见的行动，比如搜索、查数据库、发邮件、执行代码。行动的范围决定了 Agent 的能力边界——工具越丰富，能处理的任务就越复杂。但工具越多，失控的风险也越高（这是后面 Harness Engineering 要讲的内容）。

这四要素是理解 Agent 架构的基础框架，也是后续系列文章的核心线索：

• 感知 + 记忆 → 第六篇《记忆管理》
• 决策/推理 → 第二篇《ReAct 范式》、第三篇《Plan-and-Solve》
• 行动 → 第四篇《工具调用》、第五篇《意图识别》

---

两种 Agent 范型：流水线 vs 自由探索家

现实中的 Agent 系统，按照"谁在主导执行流程"分成两大派：

流程驱动 Agent（Workflow-Driven）

代表工具：Dify、n8n、Coze、Zapier AI

核心思路：先画好流程图，LLM 是流程中的一个节点。

流程图（开发者预先定义）：
接收用户问题
    ↓
[LLM节点] 判断问题类型
    ↓
如果是"账单问题" → [工具节点] 查询账单系统
如果是"投诉"    → [工具节点] 创建工单
    ↓
[LLM节点] 生成最终回复
    ↓
输出给用户

这类 Agent 的执行路径是开发者预先设计的。LLM 在里面负责自然语言理解和生成，但"下一步做什么"的逻辑写死在流程图里。

优点：

• 行为可预测，上线前能完整测试每条路径
• 出了问题容易定位（哪个节点出错一目了然）
• 不需要 LLM 理解复杂的任务规划

适合场景：

• 客服机器人（问题类型固定，处理流程明确）
• 审批流自动化（步骤固定，条件判断清晰）
• 表单处理、数据 ETL（结构化、可预测）

AI Native Agent

代表框架：LangGraph、AutoGen、CrewAI

核心思路：LLM 是控制中心，自己决定做什么。

用户问题输入
    ↓
[LLM 思考]：这个问题我需要查最新数据
    ↓
[调用搜索工具]：返回结果
    ↓
[LLM 思考]：结果里提到了一个数字，我需要验证一下
    ↓
[调用计算工具]：返回结果
    ↓
[LLM 思考]：信息足够了，可以回答了
    ↓
输出最终答案

每一步"做什么"都是 LLM 在运行时动态决定的，没有人写死流程。这就是 AI Native Agent 的精髓：LLM 不是工具，LLM 是指挥家。

优点：

• 能处理开放式、边界不清晰的任务
• 能根据中间结果动态调整策略
• 适合需要多步骤推理的复杂问题

适合场景：

• 开放式研究（用户问题多样，无法穷举）
• Bug 自动修复（需要根据代码分析结果决定下一步）
• 复杂数据分析（需要多轮检索和计算）

一个类比帮你记住

想象你要完成一次出行：

流程驱动 Agent = 高铁系统。轨道固定，站点固定，出发时间固定。效率极高，绝不会迷路，但只能去铁路到达的地方。

AI Native Agent = 一个经验丰富的导游。你说"我想去一个有历史感的地方"，他会问你几个问题，实时查攻略，根据当天天气调整行程，还能处理"景区临时关门"这种意外情况。灵活，但也有可能带你走弯路。

---

什么时候用 Agent，什么时候用 LLM 直接调用就够了

这是工程里最重要的判断，也是最容易被过度设计的地方。

一个容易踩的坑：Agent 听起来很高级，所以很多人不管什么需求都上 Agent。但 Agent 是有成本的——更长的响应时间、更高的 Token 消耗、更复杂的调试过程。

用下面这个决策树来判断：

你的任务是否需要 Agent？
│
├─ 任务步骤固定、可枚举？
│   └─ 是 → 直接用 LLM + 固定 Prompt，或流程驱动 Agent
│
├─ 任务只需要一次 LLM 调用（无需工具）？
│   └─ 是 → 直接调 LLM API，不需要 Agent
│
├─ 任务需要根据中间结果决定下一步？
│   └─ 是 → 需要 Agent
│
├─ 任务步骤多于 3 步且相互依赖？
│   └─ 是 → 需要 Agent
│
└─ 任务需要处理你事先无法预测的情况？
    └─ 是 → 需要 Agent（且是 AI Native Agent）

实际案例对应：

场景	推荐方案	原因
文章摘要生成	直接调 LLM	一次调用，固定 Prompt 搞定
FAQ 问答机器人	Chatbot	需要多轮对话，但不需要工具
客服分类路由	流程驱动 Agent	流程固定，可穷举
Bug 自动分析修复	AI Native Agent	需要看代码、搜文档、分析结果、动态决策
竞品调研报告	AI Native Agent	开放式任务，需要多轮搜索和整合
代码审查	AI Native Agent	需要理解代码结构，动态决定检查哪些方面

**不要因为"能用 Agent"就用 Agent**

如果你的任务可以用一个精心设计的 Prompt 解决，那就用 Prompt。Agent 带来的额外复杂度（调试难度、延迟、成本）只有在任务真正需要动态决策时才值得。

Anthropic 在官方指南里说得很直接："LLM 应该只在自主性和灵活性真正有价值时才被用作 Agent，否则直接的 API 调用更可靠、更可预测。"

---

一个最小的 AI Native Agent 长什么样

理解了概念，来看看代码。下面是一个用 LangGraph 实现的最简 ReAct Agent（这是 AI Native Agent 最经典的范式，下一篇会详细讲）：

# 依赖：pip install langchain-anthropic langgraph
from langchain_anthropic import ChatAnthropic
from langchain_core.tools import tool
from langgraph.prebuilt import create_react_agent

# 1. 定义工具（Agent 可以调用的"手"）
@tool
def search_web(query: str) -> str:
    """搜索网络获取最新信息"""
    # 实际使用时接入真实搜索 API，这里用模拟数据
    return f"搜索结果：关于 '{query}' 的最新信息..."

@tool
def calculate(expression: str) -> str:
    """计算数学表达式"""
    try:
        result = eval(expression)  # 注意：生产环境不要直接 eval
        return str(result)
    except Exception as e:
        return f"计算错误：{e}"

# 2. 创建 Agent（LLM 是控制中心）
llm = ChatAnthropic(model="claude-sonnet-4-6")
tools = [search_web, calculate]

agent = create_react_agent(llm, tools)

# 3. 运行
result = agent.invoke({
    "messages": [("user", "苹果公司现在的市值大概是多少？比 1 万亿美元多多少？")]
})
print(result["messages"][-1].content)

运行这段代码，Agent 会自动：

1. 判断需要搜索苹果公司市值
2. 调用 search_web 工具
3. 拿到结果后，判断需要计算差值
4. 调用 calculate 工具
5. 整合结果给出最终回答

全程没有人告诉它要先搜索再计算——这是它自己规划的。这就是 AI Native Agent 的工作方式。

**关于上面代码的注意事项**

• eval(expression) 在生产环境中存在安全风险，实际使用请换成安全的数学计算库（如 numexpr）
• 真实的搜索工具需要接入 Tavily、SerpAPI 等搜索 API
• 模型参数 claude-sonnet-4-6 是本文写作时（2026年5月）的推荐版本，请根据实际情况调整

---

面试时怎么讲清楚这个问题

高频面试题：你们的系统是 Agent 还是 Workflow？区别是什么？

很多候选人被这个问题问住，是因为他们从来没认真想过自己做的东西到底算哪种。

一个清晰的回答框架：

"我们的系统用的是 AI Native Agent 架构，核心区别在于谁来决定执行流程。

流程驱动方案中，开发者预先定义好所有可能的路径，LLM 只是路径上的一个处理节点——它更可控，也更适合步骤固定的场景。

我们选择 AI Native Agent，是因为我们的任务（比如 Bug 自动分析）边界不固定——代码可能涉及多个模块，需要根据每次分析的中间结果动态决定接下来检索哪些信息。流程驱动方案无法穷举所有可能的代码场景。

当然，自主性越高，风险也越高。所以我们在 Agent 上加了执行边界控制（Harness），确保它不会做超出授权的操作。"

这个回答的关键在于：不只说"我用了 Agent"，而是说清楚为什么选它，以及你意识到了它的代价。

---

总结

这篇文章讲了三件事：

1. LLM、Chatbot、Agent 的层次关系：LLM 是大脑，Chatbot 是加了记忆的大脑，Agent 是能自主规划和行动的完整系统。核心区别不是"能不能调工具"，而是"谁来决定何时调哪个工具"。

2. Agent 的四要素：感知（看到什么）、记忆（记住什么）、决策（规划什么）、行动（执行什么）。LLM 在这里扮演的是"指挥家"角色，而不是"执行者"。

3. 两种 Agent 范型的选型逻辑：流程驱动适合步骤固定、可预测的任务；AI Native Agent 适合开放式、需要动态决策的任务。不要因为"Agent 听起来高级"就用 Agent——合适的才是最好的。

---

下一篇预告：Agent 系列第二篇——ReAct：Agent 最重要的推理范式。我们会深入拆解 Thought → Action → Observation 的循环逻辑，看看"Agent 在想什么"，以及为什么 Chain-of-Thought 单独用还不够。

---

参考资料

• hello-agents 开源教程（第一章、第四章）
• Anthropic, Building Effective Agents, 2024
• OpenAI, A Practical Guide to Building Agents, 2025
• LangGraph 官方文档：langchain-ai.github.io/langgraph

---

这是 Agent 工程系列的第一篇。如果你刚开始学 Agent，建议从这篇读起，然后按顺序往后读。有任何问题，欢迎留言讨论。