考察点
这是 Agent 面试的开场题，面试官想看你是否理解 Agent 的本质，而不是背一个教科书定义。关键要答出「闭环」二字：感知环境、做决策、执行动作、拿到反馈再决策，这个循环才是 Agent 和普通问答的分水岭。追问一般会往 ReAct 循环、规划能力怎么落地、什么场景不适合用 Agent 这几个方向走。
参考答案
Agent 是什么
Agent 是以大模型为决策核心、能自主完成多步任务的系统。它和普通问答最大的区别在于：问答是「一问一答，模型输出即终点」，Agent 是「模型输出是中间过程，任务完成才是终点」。模型在 Agent 里不只是生成文本，而是在每一轮决定下一步做什么——调用哪个工具、传什么参数、还是已经可以收尾了。
用一个具体例子说清楚。用户问「帮我查一下明天北京到上海的机票，选最便宜的那班订了」。普通问答模型只能回复一段「我无法订票」的客套话，或者编一个答案（幻觉就是这么来的）。而 Agent 会把任务拆开：先调用日期工具把「明天」解析成具体日期，再调机票查询 API 拿候选列表，按价格排序，最后调订票接口。中间任何一步失败，它还能换路子重试。
核心区别的四个维度
| 维度 | 普通问答 | Agent |
|---|---|---|
| 交互模式 | 单轮或被动多轮，输出即结束 | 自主多轮循环，直到任务完成或放弃 |
| 与环境关系 | 无交互，只能基于训练知识 | 通过工具读写真实环境（API、数据库、文件） |
| 状态 | 无任务状态，只有对话历史 | 有明确的中间状态：已完成的步骤、收集到的信息 |
| 错误处理 | 答错就错了 | 能观察执行结果，发现失败后自我修正 |
这里最容易被追问的是「循环」和「反馈」。Agent 的每一步行动都会产生观察结果（observation），这个结果会回流到模型的上下文里，影响下一步决策。订票接口返回「该航班已满」，Agent 应该退回去选次优航班，而不是硬着头皮继续——这就是问答系统完全不具备的能力。
工程视角的一句话总结
面试里我会这样收尾：普通问答是「模型即应用」，Agent 是「模型 + 工具 + 循环控制 + 状态管理」的系统工程。模型的推理能力决定了 Agent 的上限，但工程框架（循环终止条件、工具失败的兜底、上下文管理）决定了它的下限。实际项目里大多数 Agent 翻车在工程细节上，而不是模型不够聪明。
顺带要提一句边界：不是所有任务都需要 Agent。能一次问答解决的（改写、翻译、知识问答）不要套 Agent 壳，能固定流程走通的用 Workflow 更稳。Agent 的价值在于路径不确定、需要临场决策的任务，这点在「Workflow 和 Agent 怎么选」那道题里可以展开。
可能的追问
追问：那 ReAct 和 Agent 是什么关系？
ReAct 是实现 Agent 最经典的一种范式：让模型交替输出 Thought（推理）和 Action（动作），执行后拿到 Observation 再进入下一轮。它把「闭环」具体化成了一个可实现的 prompt 结构，现在主流框架的工具调用循环本质上都是 ReAct 的变体。
追问：什么场景你坚决不用 Agent？
高频、低容错、路径固定的场景，比如支付对账、固定格式的报表生成。这类场景 Agent 的自主决策反而引入不确定性，用硬编码流程或 Workflow 编排更可靠，成本也更可控。
追问：Agent 和普通问答在评估上有什么不同？
问答评的是单条回复质量，Agent 评的是任务完成率（task success rate），而且要按步骤归因——是规划错了、工具调错了、还是工具本身坏了。没有步骤级 trace 就没法定位问题，所以可观测性是 Agent 工程的标配。