AI Agent全栈架构

主题

高频面试题

什么是 AI Agent？与传统问答应用有何区别？

面试官问“什么是 AI Agent”，不是想听一句“它能调用工具”，而是在看你能不能把目标、状态、循环、工具反馈和工程边界讲清楚。

适合阶段：Agent 入门 / AI 应用工程面核心能力：Goal · State · Tool Use · Agent Loop

面试官角度分析，想考什么 ​

  • 什么是 AI Agent？
    考你能否把它说成目标驱动的执行系统，而不是“会聊天、会调工具的大模型”。

  • 它和传统问答应用差在哪？
    考你能否从目标、状态、循环和工具反馈讲清机制差异：问答应用是固定链路的一问一答，Agent 会根据观察结果持续决策并推进任务。

  • 这个边界为什么重要？
    考工程取舍：有 Tool Calling 不等于 Agent；固定问答、RAG、Workflow 往往更稳；Agent 成本更高、失败更难排查，不是所有问答应用都该升级。

可直接抄走的 30 秒参考答案 ​

text
我理解 AI Agent 不是简单的“会调工具的大模型”，而是一个围绕目标推进任务的执行系统。传统问答应用通常是用户问一句，系统组织 prompt 或 RAG 资料，模型返回一段答案；Agent 会维护任务状态，在循环里判断下一步要做什么，调用工具拿到反馈，再更新状态，直到任务完成、失败或需要人工确认。它适合多步、开放、需要外部交互的任务，但成本、延迟、调试、安全和可靠性都会更复杂，所以不是所有问答应用都应该升级成 Agent。

面试回答详解，知其所以然 ​

面试里可以先把两者的边界讲清楚，再展开差异。传统问答的核心是对话响应，AI Agent 的核心是任务推进。

1. 传统问答：更像一个会回答问题的对话入口 ​

传统问答通常围绕一次用户输入工作。用户问一句，系统把问题、提示词模板、历史上下文或 RAG 检索结果拼好，交给大模型生成回复。

它的主链路比较固定：

text
用户消息 -> Prompt / RAG -> LLM -> 回复

这种形态适合摘要、翻译、改写、客服 FAQ、知识库问答等场景。它的优点是简单、稳定、成本可控，也更容易测试。缺点是它主要“回答”，通常不会主动拆任务、持续执行，也不会根据中间执行结果反复调整策略。

2. AI Agent：更像一个有工具权限的任务执行者 ​

AI Agent 不只是生成回复，而是围绕一个目标持续推进。用户给它的不是单个问题，而是一个需要完成的任务，例如“帮我调研三个方案并给出结论”“检查仓库测试失败原因并修复”“查询订单状态并判断是否能退款”。

它的主链路更接近：

text
目标 -> 状态 -> 决定动作 -> 调用工具 -> 观察结果 -> 更新状态 -> 继续或停止

这里的大模型不仅负责组织语言，还会参与决策：下一步要不要查资料、要不要调用工具、工具失败后要不要换路径、证据不足时要不要追问用户。Runtime 则负责把这种自主性关进边界里，比如权限校验、参数检查、最大步数、停止条件和人工确认。

3. 核心差异：不是“能不能聊天”，而是“能不能推进任务” ​

两者最关键的差异可以拆成四类：

  • 目标不同：问答面向一次用户消息，目标通常是给出一个好回复；Agent 面向一个可推进、可验收的任务，目标是把事情做完，或者明确说明为什么做不下去。
  • 执行方式不同：问答多数走固定链路；Agent 会在循环中不断决定下一步动作，根据工具返回和环境反馈调整路线。
  • 状态要求不同：问答可以主要依赖对话上下文；Agent 必须显式记录已完成步骤、工具结果、待确认事项和停止原因。
  • 工程风险不同：问答主要风险是答错或幻觉；Agent 还要处理越权调用、工具副作用、死循环、状态污染、成本失控和不可复现。

面试官追问3个问题 ​

追问一：有 Tool Calling 就算 Agent 吗？ ​

不一定。有 Tool Calling 不等于 Agent，Tool Calling 只是让模型能输出结构化工具调用参数，它解决的是“怎么调工具”。Agent 还需要解决“为什么调、调完怎么更新状态、下一步做什么、什么时候停、失败怎么恢复”。一次性工具调用更像 tool-augmented LLM，只有放进目标驱动的多步闭环里，才更接近 Agent。

追问二：Agent 和 Workflow 怎么选？ ​

看控制流是否稳定、风险是否可控。如果流程固定、规则明确、失败代价高，用 Workflow 更可靠；如果任务路径不确定，需要根据中间结果动态决策，Agent 更合适。真实生产里常用混合模式：Workflow 管住主路径和风险边界，Agent 负责开放探索和复杂判断。

追问三：Agent 最大的落地难点是什么？ ​

最大难点是可控性，不是模型会不会回答。问答应用失败通常只是答错；Agent 会多步执行、调用工具、改外部环境，每一步都可能选错动作、带错参数、写脏状态，还可能越权、死循环或提前停，事后也更难复现。所以落地要把自主性关进硬边界里：权限和工具 schema 限制能做什么，步数和停止条件限制能跑多久，trace 和评估让失败可定位，高风险动作再用人工确认和降级兜底。

扩展知识 ​

Agent 的本质是 LLM + Loop + Tools ​

理解 Agent 最快的方式，可以先记一个简化公式：

text
Agent = LLM + Loop + Tools

LLM 负责理解目标、判断下一步和组织表达；Loop 让系统可以持续推进任务，而不是一问一答后结束；Tools 让 Agent 能读取外部信息、调用业务系统、执行代码或改变环境状态。

这个循环通常可以概括为 ReAct：先 Reasoning，判断当前该做什么；再 Acting，执行一个动作或工具调用；最后 Observation，把执行结果拿回来进入下一轮。循环会持续运行，直到任务完成、无法继续、需要人工确认，或触发系统设置的停止条件。

传统问答最大的边界在这里：它主要负责“回复”。Agent 则要对“推进任务”负责。它不只是说“我建议你这么做”，而是可能真的去查资料、调用接口、写文件、跑测试、记录结果。

从 Prompt 到 Agent 的演进路径 ​

大模型应用不是一开始就是 Agent，常见演进路径大概是：

text
Prompt Engineering
  -> RAG
  -> Function Calling / Tool Calling
  -> Agent Loop
  -> 生产级 Agent Runtime

最早的 LLM 应用主要靠 Prompt Engineering，把用户输入和模板拼好，让模型生成更稳定的文本。后来发现模型不知道私有数据、知识也有时效性，于是引入 RAG：先检索文档，再把相关内容放进上下文，让模型基于资料回答。

但 RAG 主要解决“查资料”，不能真正执行操作。比如创建工单、查询订单、跑 SQL、修改代码，都需要工具调用。Function Calling / Tool Calling 让模型能输出结构化参数，应用层解析后调用外部函数，再把结果返回给模型。

再往前一步，把工具调用放进受控循环中，让模型根据中间结果持续决定下一步，这就进入 Agent 范式。到生产系统里，还需要 runtime、trace、权限、状态机、重试、回滚、评估和人工确认，不然 Agent 很容易变成不可控的循环调用器。

Agent 和 Workflow 的区别 ​

Agent 和 Workflow 的区别不在于谁更高级，而在于控制流由谁决定。

Workflow 是人提前把路径写清楚：

text
识别意图 -> 检索资料 -> 调模型生成 -> 返回结果

它像一条固定流水线，优点是稳定、可测、可控；缺点是遇到开放分支或未知情况时弹性不足。

Agent 是模型在运行时参与决策：

text
目标 -> 判断下一步 -> 调工具 -> 看结果 -> 更新状态 -> 继续或停止

它更像一个有工具权限的助理。你给它目标，它会自己安排步骤；中间卡住了，它可以换路径、问澄清、补证据或转人工。

实际项目里两者经常混用：高风险、强规则、强一致性的部分用 Workflow；开放探索、多步判断、工具组合的部分用 Agent。成熟的工程答案不是“全上 Agent”，而是把自主性放在真正需要的地方，把权限、审批、终止条件和关键业务规则留在代码里。

基于 MIT 协议开源

Copyright © 2026 AI Agent全栈架构