LLM Agent 是什么？工作流、工具调用与多 Agent 协作

Agent 是 2025-2026 年 AI 面试里热度最高的主题之一。因为大家已经不再满足于“让模型回答问题”，而是希望模型能自己拆任务、调用工具、读取外部信息、执行多步流程，最后交付结果。

如果只用一句话概括：

LLM Agent = 以大语言模型为核心决策器，能够感知环境、规划步骤、调用工具并持续迭代直到完成任务的系统。

但这句话只是入口。真正的面试高分回答，要讲清：

Agent 和普通 chatbot 的本质区别
Agent 的完整闭环是什么
什么是 ReAct
工具调用为什么关键
多 Agent 为什么会出现
Agent 的问题和边界在哪

一、先理解：LLM Agent 和普通问答机器人有什么不同？#

普通 chatbot 的流程通常很简单：

用户提问
模型生成回答
返回结果

而 LLM Agent 往往不是一次性吐出答案，而是：

理解目标
制定计划
调工具
获取观察结果
调整下一步动作
最终完成任务

也就是说，普通问答更像：

“你问，我答”

而 Agent 更像：

“你给目标，我自己想办法一步步完成”

这就是两者的根本差别：

Agent 有“行动能力”和“闭环执行能力”，而不只是生成能力。

二、Agent 的核心闭环：感知、推理、行动、再观察#

从抽象层看，一个 Agent 系统通常包括：

输入 / 感知
推理 / 规划
行动 / 工具调用
观察 / 反馈
再次决策

一个通用的 Agent 架构示意如下：

Agent architecture

如果把它映射到 LLM Agent 中，大致就是：

用户输入目标
LLM 理解任务并制定下一步
调用工具（搜索、数据库、代码执行器、API 等）
获取工具返回结果
再基于结果推理下一步
重复直到完成

这就是为什么 Agent 常被称为：

Reasoning + Acting + Feedback Loop

三、为什么光靠大模型本身不够？#

因为纯 LLM 有几个天然限制：

3.1 知识不一定最新#

模型参数有知识截止日期。

3.2 不能直接操作外部世界#

模型本身不会：

查数据库
打开网页
调用内部系统
运行代码

3.3 多步任务容易中途失控#

如果任务很复杂，例如：

“帮我分析过去三个月销售下滑原因，并生成一页总结”

纯聊天模型往往只能“猜一个答案”，而不是真的：

先取数
再分析
再生成报告

所以 Agent 出现的核心原因是：

模型会推理，但真正完成复杂任务，还需要工具、环境和多步执行框架。

四、LLM Agent 的典型组成部分#

一个成熟的 LLM Agent，通常至少包含下面几层：

4.1 Planner（规划器）#

负责把目标拆成步骤。

例如把：

“帮我规划去东京的 5 天行程”

拆成：

确认出发日期与预算
搜索航班
搜索酒店
规划景点路线
汇总成日程

4.2 Executor（执行器）#

负责真正执行每一步动作。

4.3 Tools（工具）#

例如：

搜索引擎
浏览器
数据库
Python 执行器
CRM / ERP API
邮件 / 日历系统

4.4 Memory（记忆）#

用于保存：

对话历史
中间状态
用户偏好
任务上下文

4.5 Critic / Evaluator（反思或评估模块）#

用于检查：

当前结果是否正确
是否需要重试
是否需要切换策略

五、ReAct 为什么重要？#

在 Agent 讨论里，一个高频关键词是：

ReAct

它来自论文 ReAct: Synergizing Reasoning and Acting in Language Models。

ReAct 的关键思想不是让模型一直“想”，也不是让模型一直“做”，而是：

让推理（Reasoning）和行动（Acting）交替进行。

典型流程像这样：

1
Thought: 我需要先找到相关资料
2
Action: Search["2026 AI market share"]
3
Observation: ...
4
Thought: 我需要继续比较两个来源
5
Action: Search["OpenAI market share 2026"]
6
Observation: ...
7
Final Answer: ...

它的价值很大：

让模型在行动前明确自己的推理
让行动结果反过来修正推理
提高可解释性
降低纯推理幻觉

所以 ReAct 本质上是：

把“想”和“做”交错组织起来。

六、工具调用（Tool Use）为什么是 Agent 的关键？#

很多人以为 Agent 的重点只是“prompt 更复杂”，其实不是。

Agent 真正的质变点在于：

模型不再只输出自然语言，还能输出结构化动作，并触发外部工具。

例如：

search(query="...")
sql(query="...")
python(code="...")
book_flight(...)
send_email(...)

工具调用让 LLM 从“语言生成器”升级成“任务控制器”。

这带来了两个本质变化：

6.1 从封闭知识到开放世界#

模型不再只能依赖参数里的知识，而是能实时访问外部信息。

6.2 从回答问题到完成任务#

例如用户说：

“帮我找出本周销售额前十的城市并画图。”

纯 LLM 只能解释怎么做；带工具的 Agent 可以真的：

查数据库
提取数据
运行 Python 画图
返回结果

七、Workflow 和 Agent 有什么区别？#

这是现在 AI 面试和系统设计中非常常见的一道题。

Workflow#

通常是：

预定义固定步骤
每一步逻辑相对确定
可控性强
适合稳定业务流程

例如：

OCR
文本抽取
分类
存库

Agent#

通常是：

路径不完全预定义
会根据中间结果动态调整
更灵活
适合开放式、复杂、探索型任务

例如：

“帮我做一份竞品研究”

它可能需要动态决定：

搜索什么
看哪些页面
什么时候停
是否继续验证

所以一个很实用的总结是：

Workflow 更像固定流程编排
Agent 更像动态决策执行体

很多真实系统，其实是两者结合：

用 Workflow 控制大流程，用 Agent 处理不确定子任务。

八、多 Agent 为什么会出现？#

当任务复杂度进一步提升时，一个 Agent 可能承担太多职责。

于是就会出现 Multi-Agent 架构。

例如把一个复杂系统拆成：

Planner Agent：任务拆解
Research Agent：资料检索
Coding Agent：代码执行
Review Agent：结果审核
Writer Agent：生成报告

多 Agent 的优点：

角色清晰
可以分工
更适合复杂任务拆解
某些场景下可并行

但它也有代价：

系统复杂度高
成本更高
协调与状态同步更难
错误传播链更长

所以多 Agent 不是默认更好，而是更适合：

超复杂任务
明显可拆角色的任务
需要多轮交叉验证的任务

九、LLM Agent 最常见的失败点#

真正懂 Agent 的回答，不能只讲理想流程，还要能说清它为什么经常翻车。

9.1 规划错误#

任务拆解本身就错了，后面全错。

9.2 工具选择错误#

该查数据库时去搜网页，该用计算器时让模型心算。

9.3 上下文漂移#

多轮执行后，模型忘了原始目标，开始跑偏。

9.4 无限循环 / 过度执行#

Agent 一直觉得“还可以再试一次”，导致任务无法停止。

9.5 观察理解错误#

工具返回了复杂结果，模型没正确读懂。

9.6 安全风险#

例如：

Prompt Injection
工具滥用
权限过大
数据泄露

这也是为什么 Agent 系统上线时，必须设计：

权限边界
工具白名单
审计日志
中止条件

十、Agent 和 RAG 是什么关系？#

这也是高频追问。

RAG 和 Agent 并不是替代关系，而是常常组合使用。

RAG 的定位#

更偏知识增强
回答前先检索资料
擅长知识库问答

Agent 的定位#

更偏任务执行
会规划、调用工具、做多步动作

很多现实系统其实是：

Agent 在某一步里调用 RAG 子系统。

例如：

Agent 接收任务
判断需要先查公司知识库
调用 RAG 检索内部文档
拿到结果后继续规划和执行

所以你可以理解为：

RAG 是能力模块
Agent 是决策与编排框架

十一、如何评估一个 Agent 系统？#

这也是很重要的工程问题。

不能只看“它看起来很聪明”，而要看：

11.1 任务成功率#

最终任务是否真的完成。

11.2 步数效率#

是否用了过多无效步骤。

11.3 工具调用准确率#

选没选对工具，参数传得对不对。

11.4 鲁棒性#

工具失败、网络波动、信息缺失时，是否能恢复。

11.5 安全性#

是否容易被 prompt injection 诱导。

11.6 成本#

包括：

token 消耗
工具调用成本
延迟

真正能落地的 Agent，不是“最会思考”的那个，而是：

在效果、稳定性、成本之间取得平衡的那个。

十二、面试里怎么回答“LLM Agent 是什么？”#

建议按这个结构回答：

第一步：先下定义#

LLM Agent 是以大语言模型为核心决策器，能够理解目标、规划步骤、调用外部工具并根据反馈迭代完成任务的系统。

第二步：讲核心闭环#

它的核心不是一次性回答，而是：

感知输入
推理规划
工具调用
获取观察
再次决策

第三步：讲 ReAct 和 Tool Use#

ReAct 让模型把推理和行动交替进行，工具调用则让模型从“只能说”升级成“真的能做事”。

第四步：讲 Workflow 与 Multi-Agent#

简单场景用 workflow 就够
更开放复杂的任务适合 agent
更复杂任务可拆成多 agent 协作

第五步：讲挑战#

Agent 最大难点在于：

规划稳定性
工具选择准确率
安全控制
成本和延迟

这样回答，既有原理，也有系统设计视角。

十三、总结#

LLM Agent 的本质，不是“把 Prompt 写长一点”，而是把大模型放进一个可执行闭环里：

模型负责理解与决策
工具负责连接外部世界
观察结果反过来修正下一步动作

所以真正准确的总结应该是：

Agent 的价值在于把 LLM 从“回答者”升级成“执行者”，让它能围绕目标持续推理、行动和迭代。