你以为你在用 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：
python
# 伪代码：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 是流程中的一个节点。
csharp
流程图（开发者预先定义）：
接收用户问题
↓
[LLM节点] 判断问题类型
↓
如果是"账单问题" → [工具节点] 查询账单系统
如果是"投诉" → [工具节点] 创建工单
↓
[LLM节点] 生成最终回复
↓
输出给用户这类 Agent 的执行路径是开发者预先设计的。LLM 在里面负责自然语言理解和生成，但"下一步做什么"的逻辑写死在流程图里。
优点：
- 行为可预测，上线前能完整测试每条路径
- 出了问题容易定位（哪个节点出错一目了然）
- 不需要 LLM 理解复杂的任务规划
适合场景：
- 客服机器人（问题类型固定，处理流程明确）
- 审批流自动化（步骤固定，条件判断清晰）
- 表单处理、数据 ETL（结构化、可预测）
AI Native Agent
代表框架：LangGraph、AutoGen、CrewAI
核心思路：LLM 是控制中心，自己决定做什么。
css
用户问题输入
↓
[LLM 思考]：这个问题我需要查最新数据
↓
[调用搜索工具]：返回结果
↓
[LLM 思考]：结果里提到了一个数字，我需要验证一下
↓
[调用计算工具]：返回结果
↓
[LLM 思考]：信息足够了，可以回答了
↓
输出最终答案每一步"做什么"都是 LLM 在运行时动态决定的，没有人写死流程。这就是 AI Native Agent 的精髓：LLM 不是工具，LLM 是指挥家。
优点：
- 能处理开放式、边界不清晰的任务
- 能根据中间结果动态调整策略
- 适合需要多步骤推理的复杂问题
适合场景：
- 开放式研究（用户问题多样，无法穷举）
- Bug 自动修复（需要根据代码分析结果决定下一步）
- 复杂数据分析（需要多轮检索和计算）
一个类比帮你记住
想象你要完成一次出行：
流程驱动 Agent = 高铁系统。轨道固定，站点固定，出发时间固定。效率极高，绝不会迷路，但只能去铁路到达的地方。
AI Native Agent = 一个经验丰富的导游。你说"我想去一个有历史感的地方"，他会问你几个问题，实时查攻略，根据当天天气调整行程，还能处理"景区临时关门"这种意外情况。灵活，但也有可能带你走弯路。
什么时候用 Agent，什么时候用 LLM 直接调用就够了
这是工程里最重要的判断，也是最容易被过度设计的地方。
一个容易踩的坑：Agent 听起来很高级，所以很多人不管什么需求都上 Agent。但 Agent 是有成本的------更长的响应时间、更高的 Token 消耗、更复杂的调试过程。
用下面这个决策树来判断：
markdown
你的任务是否需要 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 最经典的范式，下一篇会详细讲）：
python
# 依赖：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 会自动：
- 判断需要搜索苹果公司市值
- 调用
search_web工具 - 拿到结果后，判断需要计算差值
- 调用
calculate工具 - 整合结果给出最终回答
全程没有人告诉它要先搜索再计算------这是它自己规划的。这就是 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"，而是说清楚为什么选它，以及你意识到了它的代价。
总结
这篇文章讲了三件事：
-
LLM、Chatbot、Agent 的层次关系：LLM 是大脑，Chatbot 是加了记忆的大脑，Agent 是能自主规划和行动的完整系统。核心区别不是"能不能调工具"，而是"谁来决定何时调哪个工具"。
-
Agent 的四要素：感知（看到什么）、记忆（记住什么）、决策（规划什么）、行动（执行什么）。LLM 在这里扮演的是"指挥家"角色，而不是"执行者"。
-
两种 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，建议从这篇读起，然后按顺序往后读。有任何问题，欢迎留言讨论。