Agent到底是什么？和普通大模型问答有什么区别？

前段时间有个录友面试大模型应用岗，项目里写了一个"智能客服 Agent"。

面试官问他："你这个 Agent 和普通客服机器人有什么区别？"

他回答："我们用了更强的大模型，能理解用户问题，还能多轮对话。"

面试官继续追问："那它有没有自己决定下一步做什么？有没有调用工具？有没有根据工具结果继续调整动作？如果只是用户问一句，它答一句，为什么叫 Agent？"

这下就卡住了。

这类问题现在很常见。很多简历上写了 Agent，但讲出来还是一个 ChatBot；很多产品宣传说自己是 Agent，但本质只是 Prompt 包了一层页面。

所以这篇先把最基础的问题讲清楚：Agent 到底是什么？它和普通大模型问答到底差在哪？

一、普通大模型问答，本质是"你问我答"

先别急着定义 Agent，我们从最熟的普通问答说起。

普通大模型问答是什么？

就是用户输入一句话，模型根据上下文生成一段回复。

比如你问：

帮我解释一下 Redis 为什么快？

模型会回答：

Redis 快，主要因为它基于内存、单线程避免锁竞争、使用 IO 多路复用、数据结构高效……

这就是典型的大模型问答。

它可以很聪明，可以讲得很细，也可以帮你写代码、改简历、总结文章。

但它有一个核心特点：它主要是在生成文本。

你让它讲 Redis，它讲给你听。

你让它写 SQL，它把 SQL 写出来。

你让它分析日志，它只能基于你贴给它的日志分析。

这类系统的交互方式很简单：

用户给问题 -> 模型生成答案 -> 用户继续追问。

整个过程中，模型大多数时候没有真正"动手"。

它不知道你的数据库现在有什么数据，不会自己去查监控，不会自己打开系统后台，不会自己执行脚本，也不会在发现第一步失败后自动换方案。

所以普通问答更像一个知识很强的顾问。

它能给建议，但行动还得你来做。

二、Agent 的关键，不是"回答更聪明"

很多人理解 Agent，第一反应是：Agent 是不是更聪明的大模型？

不是。

Agent 的关键不是更会说，而是更会做。

这句话很重要。

普通问答的核心产物是"答案"。

Agent 的核心产物是"完成任务的过程和结果"。

举个例子。

你对普通大模型说：

帮我分析一下这个网站为什么最近转化率下降。

如果是普通问答，它可能会给你一套分析思路：

• 看流量来源有没有变化
• 看页面加载速度有没有变慢
• 看按钮点击率有没有下降
• 看最近有没有改版
• 看用户反馈里有没有负面信号

这些建议可能都对，但你还是要自己去查数据。

如果是一个真正的 Agent，它应该能做更多事：

1. 先拆解问题：转化率下降可能来自流量、页面、价格、性能、用户路径。
2. 调用数据工具：查最近 30 天 PV、UV、点击率、跳出率、支付转化。
3. 调用日志工具：看接口延迟、错误率、页面加载耗时。
4. 对比历史数据：找出异常时间点。
5. 生成初步结论：比如"移动端支付页加载时间从 1.2 秒涨到 4.8 秒"。
6. 继续验证：查看是否和某次发布有关。
7. 最后输出结论和建议：哪个环节出问题，证据是什么，下一步怎么修。

你看，这里已经不是"回答问题"了。

它是在围绕一个目标，自己决定下一步做什么，并不断根据结果调整。

这才是 Agent 的味道。

三、Agent 至少要有四个能力

讲 Agent，不要一上来就堆一堆高大上的词。

先记住这四个能力：规划、工具、执行、反馈。

没有这四个东西，很多所谓 Agent 其实只是披了个名字。

1. 规划：知道任务要怎么拆

用户给 Agent 的往往不是一个简单问题，而是一个目标。

比如：

帮我整理一下这个仓库的技术债，并给出优先级。

这不是一句话能答完的。

Agent 需要先拆任务：

• 先看项目目录
• 再看核心模块
• 再看最近提交
• 再找重复代码、复杂函数、缺测试的地方
• 再判断哪些问题影响最大
• 最后整理成报告

这一步就是规划。

没有规划，Agent 就会变成想到哪做到哪。

很多 Agent 翻车，就是因为计划不稳定：一开始说要检查测试，跑着跑着忘了；一开始说要分析全仓库，最后只看了两个文件就开始总结。

2. 工具：能连接外部世界

没有工具，Agent 很多时候只能"会说不会做"。

工具可以是：

• 搜索工具
• 数据库查询工具
• 文件读写工具
• 代码执行工具
• 浏览器工具
• 业务 API
• 发邮件、发消息、创建工单的接口

工具的意义，是让模型从"文本生成器"变成"能操作环境的执行者"。

比如用户问：

帮我查一下昨天订单失败最多的原因。

普通问答只能说："你可以从支付失败、库存不足、风控拦截几个方向排查。"

Agent 应该能调用订单数据库，查失败码分布，再调用日志系统看异常接口，最后给出真实结论。

这就是 Function Calling / Tool Use 为什么重要。

它不是 Agent 的附属能力，而是 Agent 行动能力的入口。

3. 执行：一步一步把任务跑完

会规划不等于会执行。

很多模型特别擅长列计划：

第一步，收集数据；第二步，分析问题；第三步，输出报告。

听起来很完整，但真正执行时就散了。

因为执行不是写计划，而是把每一步真的做完。

比如查数据库失败怎么办？

工具返回为空怎么办？

某个接口超时怎么办？

发现数据不够，要不要换一个工具继续查？

这些都属于执行过程。

真正的 Agent，需要能在执行中处理分支，而不是只按一张固定清单往下走。

4. 反馈：看结果，再决定下一步

Agent 和普通程序最大的区别之一，是它会根据中间结果调整动作。

比如它先查订单失败原因，发现失败最多的是"支付超时"。

那下一步就不应该继续查库存，而应该去查支付接口延迟、第三方支付回调、网关错误日志。

这就是反馈。

它的基本循环是：

思考 -> 行动 -> 观察结果 -> 再思考 -> 再行动。

很多人听过 ReAct，其实就是这个思路。

Reasoning 是思考，Acting 是行动，中间靠 Observation 把工具结果带回来。

四、一个简单判断：它有没有"自己决定下一步"

怎么判断一个系统是不是 Agent？

我给一个很实用的判断标准：

看它有没有在任务过程中，自己决定下一步做什么。

如果它只是固定流程：

1. 用户输入问题
2. 系统检索知识库
3. 模型总结答案
4. 返回给用户

这更像 RAG 问答，不一定是 Agent。

如果它是：

1. 用户给一个目标
2. 模型判断需要先查知识库
3. 查完发现信息不够，又决定查数据库
4. 数据库结果异常，又决定调用日志工具
5. 根据日志继续定位问题
6. 最后生成结论

这就更像 Agent。

因为它不是在机械执行固定流程，而是在根据任务状态做动态决策。

这里要注意，不是用了大模型就叫 Agent。

也不是用了 Function Calling 就一定叫 Agent。

如果工具调用路径完全固定，没有开放决策，那它可能只是一个带工具的 Workflow。

Agent 的核心是：目标驱动 + 动态决策 + 外部行动 + 反馈迭代。

这四个词，面试时可以直接说。

五、Agent 和 Workflow 到底差在哪？

Agent 和 Workflow 很容易混。

Workflow 是工作流。

它适合流程明确、步骤稳定、规则清楚的任务。

比如发票审核：

1. OCR 识别发票
2. 提取金额、税号、日期
3. 校验字段
4. 调用财务系统入账
5. 返回审核结果

这个流程很固定，用 Workflow 就很好。

你不需要让模型每次自由发挥："我想想接下来要不要入账。"

那太危险了。

Agent 适合什么？

适合任务开放、路径不固定、需要中途判断的场景。

比如：

帮我定位线上接口变慢的原因。

这个任务没有固定路径。

可能是数据库慢，可能是缓存击穿，可能是某个服务发布导致，可能是第三方 API 超时。

你没法提前写死每一步。

这时候 Agent 的价值就出来了：它可以根据查到的现象，决定下一步查哪里。

所以别神化 Agent。

能用 Workflow 稳定解决的问题，就不要硬上 Agent。

Agent 的自由度更高，但不代表更可靠。

自由度越高，越需要约束、评估、权限控制和失败恢复。

六、Agent 不是一个模型，而是一套系统

这点很容易被忽略。

很多人说"我用了 GPT-5，所以我做了 Agent"。

不对。

模型只是 Agent 的一部分。

一个完整 Agent 系统，通常至少包括：

• 模型：负责理解、推理、生成
• Prompt：定义角色、目标、边界
• 工具：连接外部系统
• 执行器：真正调用工具、处理返回结果
• 状态管理：记录当前任务进度
• 记忆系统：保存跨轮信息
• 评估机制：判断做得对不对
• 权限控制：限制能做什么、不能做什么
• 失败恢复：出错后能不能重试、回滚、停止

所以 Agent 不是"一个更强模型"。

它更像一个围绕模型搭起来的工程系统。

模型负责思考，但系统负责让它安全地行动。

这也是为什么同样用一个模型，不同团队做出来的 Agent 效果差很多。

差距往往不在模型本身，而在工具设计、上下文管理、执行编排、评估观测这些工程细节。

七、面试时怎么回答"Agent 是什么"

如果面试官问：

你怎么理解 Agent？

不要只回答：

Agent 是智能体，可以自主完成任务。

这句话太虚了。

你可以这样回答：

我理解的 Agent，不是单纯的大模型问答，而是一个围绕目标持续行动的系统。它会根据用户目标进行任务规划，选择合适的工具调用外部环境，执行中观察工具返回结果，再决定下一步动作。普通 ChatBot 主要是生成回答，而 Agent 更强调行动、反馈和迭代。它的核心不是模型更聪明，而是系统具备规划、工具调用、执行编排和状态反馈能力。

这个回答就比较稳。

如果面试官继续问：

那 Agent 和 Workflow 有什么区别？

你可以补一句：

Workflow 更适合步骤固定、规则明确的任务；Agent 更适合路径不确定、需要动态决策的任务。工程上不是所有场景都应该上 Agent，如果流程能写死，用 Workflow 往往更稳定、更可控。

这句话很加分。

因为它说明你不是看到 Agent 热就硬套，而是知道取舍。

八、总结

Agent 不是"会聊天的大模型"，也不是"套了几个工具的大模型"。

它真正的特点，是能围绕一个目标持续行动。

普通问答解决的是：怎么回答。

Workflow 解决的是：按固定步骤怎么执行。

Agent 解决的是：目标不变，但路径不确定时，怎么边做边判断。

所以理解 Agent，抓住四个关键词就够了：

规划、工具、执行、反馈。

会讲这四个词，才能把 Agent 从一个热词，讲成一个真正能落地的工程系统。