高频面试题

LLM Agent 的基本架构有哪些组成部分？

这道题看起来像组件罗列，实际是在考你能不能把一个可运行、可观测、可控的 Agent 系统讲成工程架构，而不是只背“规划、记忆、工具”。

适合阶段：Agent 架构 / 应用工程面核心能力：Architecture · Runtime · Tool Loop · Governance

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

• LLM Agent 基本架构由哪些模块组成？
  考入口、上下文、LLM 决策、循环、工具、状态记忆、runtime。

• 模型和工具、运行时分别扮演什么角色？
  考决策与执行分离：LLM 是 planner，执行、校验、权限在 runtime。

• 生产还缺什么？
  考 guardrail、trace、评估、成本、人工确认和回滚。

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

LLM Agent 的基本架构可以按一条执行链路理解：用户或事件触发任务，runtime 创建状态并构建上下文，把目标、工具 schema、记忆和检索结果交给 LLM；LLM 决定下一步动作或工具调用；工具执行层做参数校验、鉴权、调用外部系统并返回 observation；runtime 更新状态和记忆，再决定继续还是停止。生产里还要有 guardrail、trace、评估、成本预算、人工确认和回滚，否则只是 demo 级 Agent。

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

不要把 Agent 架构答成几个孤立名词。高分答案要按“请求进来后怎么跑、工具怎么调、状态怎么更新、风险怎么管”来讲。

1. 一个最小 Agent 架构

最小可用的 LLM Agent 可以画成：

User / Trigger
  -> Agent Runtime
  -> Context Builder
  -> LLM Planner / Policy
  -> Tool Executor
  -> Observation
  -> State / Memory
  -> Loop until done

其中 LLM 负责理解目标、选择动作和生成结果；runtime 负责把模型输出变成受控执行；工具层负责连接外部世界；状态和记忆负责让多轮执行可持续。

2. 用户入口和任务触发

Agent 的入口不一定只是聊天框，也可能是定时任务、Webhook、工单事件、代码仓库事件、邮件、IM 消息或工作流节点。

入口层要做的事包括：

• 识别用户、租户、项目和权限范围。
• 解析任务目标、输入文件、上下文资源和验收标准。
• 判断是否需要澄清。
• 给本次运行创建 run id / trace id。
• 加载可用工具和策略。

入口层如果不清楚，后面 Agent 就不知道“为谁做、能访问什么、做到什么算完成”。

3. Context Builder：把信息组织给模型

Context Builder 负责把模型这次决策需要的信息组装进上下文。它通常会合并：

• system / developer 指令。
• 用户目标和最近消息。
• 当前任务 state。
• 工具列表和 tool schema。
• RAG 检索结果。
• 长期记忆召回结果。
• 上一轮工具 observation 摘要。
• 输出格式和停止约束。

这层的关键是预算和优先级。上下文不是越多越好，过长会增加成本、延迟和污染风险。成熟系统会做检索、摘要、裁剪、排序和隔离。

4. LLM 决策层：规划、选择动作、生成结果

LLM 在 Agent 中通常承担三类职责：

• 理解目标：把自然语言任务转成可执行意图和约束。
• 规划动作：决定下一步查什么、调什么工具、是否需要拆子任务。
• 解释结果：根据 observation 生成用户可读结论或下一步问题。

LLM 决策可以是单步，也可以是多步：

Plan -> Act -> Observe -> Re-plan

但 LLM 不应该直接拥有执行权。它输出的是动作意图或结构化 tool call，真正执行由 runtime 控制。

5. Tool Executor：连接外部世界

工具层让 Agent 能获取新信息或产生动作。常见工具包括：

• 搜索、浏览器、文档解析、代码执行。
• 数据库查询、业务 API、工单系统、邮件和 IM。
• RAG retriever、向量库、文件系统。
• MCP Server 暴露的标准化 tools、resources 和 prompts。

工具层要做的不只是调用函数，还要处理：

• 参数 schema 校验。
• 鉴权和最小权限。
• 超时、重试、限流和熔断。
• 幂等、回滚和危险动作确认。
• 结果压缩和结构化 observation。
• 工具调用日志和 trace。

6. State 和 Memory：支撑多轮执行

Agent 需要两类持久信息：

• 运行状态：本次任务已经做了什么、当前计划、工具结果、阻塞点、预算、停止原因。
• 记忆系统：跨会话可复用的偏好、事实、经验、项目知识和流程。

可以简单区分：

State = 当前 run 怎么继续
Memory = 未来 run 还要记得什么
Context = 本轮模型调用临时看到什么

状态适合结构化保存，便于恢复和调试；长期记忆适合带来源、时间、scope、置信度和删除状态，按需检索后少量注入上下文。

7. Agent Runtime：把循环管起来

Runtime 是生产 Agent 的骨架，负责管理整个执行循环：

• 初始化任务和工具。
• 构建上下文。
• 调用模型。
• 解析 tool call。
• 执行工具并回灌结果。
• 更新 state / memory。
• 判断继续、完成、失败、转人工或暂停。

同时 runtime 要提供工程边界：

• 最大步数、token 预算、时间预算。
• tool_choice 或工具白名单。
• guardrail 和策略检查。
• approval / human-in-the-loop。
• checkpoint 和恢复。
• tracing 和 replay。

没有 runtime，Agent 很容易变成“while true 调模型”的脆弱脚本。

8. 评估、安全和可观测性

生产架构必须包含非功能模块：

• 评估：单步工具选择评估、端到端任务成功率、轨迹质量、成本、延迟和回归集。
• 安全：prompt injection 防护、权限隔离、数据脱敏、工具最小权限、沙箱和危险动作审批。
• 可观测性：记录 prompt、response、tool call、tool result、state diff、token、延迟和错误。
• 成本控制：模型分层、缓存、并行工具、上下文裁剪、预算停止。
• 人工协作：低置信度、敏感操作、不可恢复操作和业务异常时转人工。

这些模块决定 Agent 能不能长期运行，而不只是 demo 能不能跑通。

面试官追问3个问题

追问一：Context、State、Memory 有什么区别？

• 考察点：上下文工程边界。
• 回答方向：Context 是本轮模型能看到的输入；State 是当前任务可恢复、可追踪的运行状态；Memory 是跨任务可复用的信息。State 和 Memory 可以存外部系统，按需进入 Context。

追问二：为什么说模型不应该直接执行工具？

• 考察点：决策与执行分离。
• 回答方向：模型只生成结构化调用意图，执行在应用层。权限、参数校验、超时、重试、审计和回滚都必须由 runtime / tool executor 控制。

追问三：Agent 架构里 verifier 放在哪里？

• 考察点：质量闭环。
• 回答方向：Verifier 可以在工具调用后检查 observation，也可以在最终回答前检查目标是否满足，还可以作为独立模型、规则或测试集。它不一定每步都用，但高风险任务需要。

扩展知识

常见分层视角

可以把 Agent 架构分成五层：

• 交互层：聊天、API、Webhook、定时任务、工作流触发。
• 认知层：LLM、prompt、planning、reflection、verifier。
• 上下文层：RAG、短期上下文、长期记忆、任务 state。
• 行动层：tool calling、MCP、浏览器、代码执行、业务 API。
• 治理层：权限、安全、trace、eval、成本、人工确认。

面试时按这五层回答，会比单纯背“感知、决策、记忆、工具”更有工程感。

Agent Runtime 和框架的关系

LangGraph、OpenAI Agents SDK、LlamaIndex Workflows 等框架都在不同程度上提供 runtime 能力。框架不是 Agent 的本质，但能帮你管理状态、工具循环、handoff、trace、checkpoint 和 guardrail。

选型时要看：

• 任务是否需要显式状态图。
• 是否需要多 Agent handoff。
• 是否需要长任务恢复。
• 是否需要可视化 trace 和评估集成。
• 是否能接入现有工具和权限体系。

架构复杂度要和任务风险匹配

简单 Agent 可以只有 LLM、几个工具和短期状态；生产 Agent 可能需要工作流外壳、审批、可观测性、评估、记忆治理和权限系统。

判断标准是：

任务越长、工具越危险、用户越多、错误代价越高，runtime 和治理层越不能省。