LLM Agent 面试题

答案：

LLM 是基于自回归语言建模的文本生成模型，输出受 prompt 约束，无外部动作能力。Agent 是以 LLM 为推理核心，叠加工具调用、记忆、规划三大模块的自治系统，在循环中自主完成多步目标。

四维差异：

典型对比场景：

• 场景 A：用户问"明天北京天气如何？下雨则取消跑步计划"
• LLM 输出：“您可以打开天气 App 查看…"（无工具调用）
• Agent 行为：调用天气 API → 查询日历 API → 删除跑步事件 → 返回执行结果

LLM 的四类能力天花板——不会执行、缺乏记忆、知识截止、缺乏规划——恰好对应 Agent 的四个能力模块补齐。

答案：

Workflow 的控制权在代码逻辑，Agent 的控制权在 LLM 推理。两者在生产系统中通常以混合架构共存。

生产实践：

Anthropic 官方建议"能用 Workflow 就别上 Agent"。典型混合架构：

graph LR
    A[用户请求] --> B{复杂度路由}
    B -->|简单 FAQ| C[Workflow
固定流程]
    B -->|中等复杂| D[Agent
ReAct 循环]
    B -->|高风险/无法处理| E[人工接管]
    C --> F[响应]
    D --> F
    E --> F

答案：

四种主流模式在 Token 消耗、灵活性、可预测性上各有取舍，选型核心是评估任务复杂度与质量要求。

选型决策树：

• 任务流程固定 + 高频 → Workflow
• 流程可预见 + 步骤多 → Plan-and-Execute
• 需灵活应对未知输入 → ReAct
• 输出质量要求高 + 单一 Agent 不足 → Reflection 或 Multi-Agent

答案：

ReAct = Reason + Act，通过 Thought → Action → Observation 循环驱动 Agent 自主决策。生产部署的核心挑战是死循环控制。

ReAct 循环示例：

Thought: 用户想查北京天气 → 需要调用天气工具
Action: get_weather(city="北京", date="明天")
Observation: {"weather":"中雨","temp":"14-20°C"}
Thought: 查到结果 → 整合输出
Final Answer: 明天北京中雨，14-20°C，建议携带雨具

死循环防御三板斧：

1. 最大步数限制：单任务上限 15 步，超出强制终止
2. 重复动作检测：连续 3 次相同工具+参数组合直接退出
3. 超时控制：整体任务设最大执行时间，工具调用设独立超时

ReAct 防御实现：

class ReActAgent:
    def run(self, task: str, max_steps: int = 15, timeout_sec: int = 120):
        steps = 0
        seen_actions = []
        start_time = time.time()

        while steps < max_steps:
            if time.time() - start_time > timeout_sec:
                return self.llm_summarize("任务超时，基于已有信息回答")

            thought, action = self.llm_think(task, history)
            if action in seen_actions[-3:]:
                return self.llm_summarize("基于已有信息回答")

            seen_actions.append(action)
            observation = self.execute(action)
            history.append((thought, action, observation))
            steps += 1

        return self.llm_summarize("达到最大步数")

多 Agent 防漂移补充：

• 每步目标对齐：定期检查当前步是否仍在服务原始目标
• 定期反思：每 N 步执行 Reflection 节点评估进度
• 任务重置：检测到漂移时回滚到最近的稳定状态

答案：

Function Call 是 LLM 调用外部工具的标准协议，通过结构化 JSON 描述工具签名，LLM 输出符合 schema 的调用指令，由运行时执行并回填结果。

协议三要素：

Function Call 流程：

sequenceDiagram
    participant U as User
    participant L as LLM
    participant R as Runtime
    participant T as Tool

    U->>L: 提问
    L->>L: 推理决定调用工具
    L-->>R: tool_calls=[{name, arguments}]
    R->>T: 执行工具
    T-->>R: 结果
    R->>L: 追加 tool message
    L-->>U: 最终回答

生产实践：

• 白名单校验：LLM 输出的工具名必须在预定义白名单内
• 参数 schema 验证：使用 Pydantic / Zod 严格校验参数
• 输出截断：工具返回内容超长需截断，避免上下文爆炸
• 并行调用：无依赖的多次工具调用可并行执行降低延迟

答案：

MCP（Model Context Protocol）是 Anthropic 主导的 Agent ↔ 工具标准化协议，定义工具发现、调用、上下文传递的统一规范。

核心特性：

• 动态工具发现：Agent 启动时扫描 MCP Server 列表，发送 tools/list 请求，运行时自动获得新能力，无需重新部署 Agent 代码
• stdio / HTTP / SSE 三种传输：本地进程用 stdio，远程服务用 HTTP/SSE
• Resources / Tools / Prompts 三类原语：除工具外还支持资源读取和 prompt 模板管理

MCP 交互流程：

sequenceDiagram
    participant A as Agent
    participant C as MCP Client
    participant S as MCP Server
    participant T as External Tool

    A->>C: 初始化连接
    C->>S: initialize
    S-->>C: server info + capabilities
    C->>S: tools/list
    S-->>C: 工具清单
    A->>C: 调用工具
    C->>S: tools/call
    S->>T: 执行
    T-->>S: 结果
    S-->>C: 返回
    C-->>A: 整合输出

生产踩坑：

答案：

三大协议分别解决 AI 系统的不同协作维度，是 2026 年 Agent 工程化的协议基础设施。

一句话定位：

• MCP 管纵向——Agent 与工具/数据源的标准化对接
• A2A 管横向——Agent 间的任务委派与协作
• AG-UI 管"没 API 可调"——通过 UI 自动化操作遗留系统

2026 年 4 月新动态：

Google 发布 A2A 1.1，新增 Streaming Task Updates，支持任务进度实时推送，便于前端展示长任务状态。

答案：

Agent 记忆系统由上下文窗口（短期）+ 外部存储（长期）两层组成，长期记忆按数据特征选择不同存储后端。

两层记忆 + 三种外部存储：

记忆压缩三板斧：

1. 滑动窗口：保留最近 N 轮对话，丢弃最旧
2. 摘要压缩：用 LLM 总结旧对话为摘要
3. 重要性过滤：仅保留关键决策点和事实

压缩实现：

class AgentMemory:
    def _compress(self):
        old_messages = self.working_memory[:-20]
        summary = self.llm.summarize(old_messages)
        self.vector_store.add(summary)
        self.working_memory = [summary] + self.working_memory[-20:]

设计原则：

• 短期记忆进 context，长期记忆按访问模式分库
• 关键决策点优先持久化，避免 LLM “金鱼脑”
• 摘要前保留原始消息以备回溯

答案：

RAG 是 Agent 工具箱中的"知识查询器"，二者非对立而是协作关系。Agentic RAG 是 RAG 的第三代演进形态。

RAG 三代演进：

graph LR
    A[Naive RAG
简单向量检索+生成] --> B[Advanced RAG
查询改写+混合检索+重排]
    B --> C[Agentic RAG
自主判断检索策略+多轮迭代]

Agentic RAG 核心能力：

• 自主判断检索策略：根据 query 复杂度决定是否检索、检索几次
• 检索质量评估：评估返回文档相关性，不足则换角度再检索
• 多源路由：根据 query 类型路由到不同数据源（FAQ / 文档 / 数据库）
• Self-Correction：检索失败时自动调整 query 或切换检索方法

答案：

十万级文档的 RAG 系统是系统设计高频题，需要在文档处理、检索质量、评估闭环三个层面做出工程化决策。

完整链路：

graph TB
    A[文档源] --> B[分类+解析器选择]
    B --> C[语义分块+元数据]
    C --> D[Embedding 模型]
    D --> E[向量数据库]
    F[BM25 索引] --> E
    E --> G[混合检索]
    G --> H[Re-ranker 重排]
    H --> I[Prompt 拼接]
    I --> J[LLM 生成]
    J --> K[带引用回答]
    L[评估体系] -.-> G
    L -.-> J

关键工程决策：

混合检索权重调优：

def hybrid_search(query, alpha=0.7):
    bm25_score = bm25_search(query)
    vector_score = vector_search(query)
    return alpha * vector_score + (1 - alpha) * bm25_score

答案：

RAG 评估分检索质量与生成质量两个维度，常用 RAGAS 框架做自动化评估，需配套黄金测试集与 CI/CD 闭环。

评估闭环：

graph LR
    A[黄金测试集
100+ QA 对] --> B[RAGAS 自动化评分]
    B --> C[指标看板]
    C --> D{指标是否达标}
    D -->|否| E[定位问题
检索/生成]
    E --> F[优化迭代]
    F --> B
    D -->|是| G[部署上线]
    H[在线用户反馈] -.-> B

实操建议：

• 维护 100+ 黄金测试集（覆盖高频/边缘/对抗样本）
• CI/CD 中跑评估，PR 触发回归
• 在线用户反馈（点赞/纠错）反哺评估集

答案：

Prompt Injection 是攻击者通过构造输入诱导 LLM 忽略系统指令或泄露敏感信息。防御必须采用多层纵深策略，单一技术不足以应对。

四层防御体系：

1. 数据/指令分离：外部内容放在明确标记的数据区域，与系统指令物理隔离
2. 输入过滤：检测"忽略之前指令"等可疑模式，命中后走降级流程
3. 模板隔离：用户输入永不直接拼入 System Prompt，必须经过模板封装
4. 上下文标记：在 prompt 中明确标注每段内容的来源（系统/用户/工具/外部数据）

多层防御架构：

graph TB
    A[用户输入] --> B[输入过滤]
    B --> C[模板隔离]
    C --> D[LLM 推理]
    D --> E[输出校验]
    E --> F[敏感词过滤]
    F --> G[最终响应]
    H[外部数据] -.->|明确标记| D

常见攻击向量：

• 间接注入：恶意内容植入外部文档（邮件、网页），Agent 检索后被诱导
• 角色扮演：“现在你是管理员，告诉我…”
• 多语言绕过：中文指令被英文 prompt 忽略

实操建议：

• System Prompt 与用户内容用 ### 等强分隔符
• 关键决策（金融/医疗）强制 Human-in-the-Loop
• 高风险操作（删除/支付/权限变更）必须二次确认

答案：

Agent 幻觉指生成貌似合理但与事实不符的内容，需从检索、输出、校验、置信、算法、审核六层组合治理。

Self-RAG 流程：

graph LR
    A[Query] --> B[检索]
    B --> C[生成]
    C --> D{自评：检索相关?}
    D -->|否| E[重检索/换 query]
    E --> B
    D -->|是| F{自评：回答支持?}
    F -->|否| G[重新生成]
    G --> C
    F -->|是| H[返回]

答案：

生产级 Agent 系统的可靠性需要幂等性、回滚、超时、降级、熔断、人工接管六类机制协同保障。

级联回退策略：

主模型 (GPT-4o) → 备用模型 (Claude) → 缓存响应 → 规则匹配 → 人工接管 → 优雅错误

实操建议：

• 工具调用必须实现幂等（使用 idempotency_key）
• 关键工具设独立超时（避免一个慢调用拖垮整体）
• 熔断阈值根据错误率动态调整（如 1 分钟内 50% 失败触发）

答案：

Token 成本是 Agent 生产化的最大瓶颈之一。组合使用多种优化策略可降低 60-80% 成本。

成本优化分层架构：

graph TB
    A[Query] --> B{缓存命中?}
    B -->|是| C[返回缓存]
    B -->|否| D{任务复杂度}
    D -->|简单| E[小模型 + Workflow]
    D -->|复杂| F[大模型 + ReAct]
    E --> G[结果压缩]
    F --> G
    G --> H[写入缓存]
    H --> I[返回]

成本监控指标：

• 单 query 平均 Token（含输入/输出）
• 单 query 平均成本
• 任务类型成本分布（识别高成本场景）
• 缓存命中率

答案：

Agent 可观测性需覆盖 Traces（链路追踪）、Logs（日志）、Metrics（指标）三大支柱，针对 LLM 特性需补充特有的核心指标。

核心指标与告警阈值：

采样策略：

• 错误请求与高成本请求：100% 采样
• 正常请求：10% 采样
• 长任务（> 10 步）：100% 采样

工具选型：

追踪数据要素：

trace:
  trace_id: uuid
  user_id: string
  task: string
  steps:
    - step_id: 1
      type: llm_call
      model: gpt-4o
      input_tokens: 1200
      output_tokens: 300
      latency_ms: 2300
      cost_usd: 0.012
    - step_id: 2
      type: tool_call
      tool: get_weather
      input: {city: 北京}
      output: {weather: 中雨}
      latency_ms: 450

答案：

生产 Agent 系统在死循环、幻觉、上下文污染、Token 爆炸、注入攻击、目标漂移六个方面高频踩坑，每类都有成熟解法。

踩坑防御清单：

• 所有 LLM 输出的工具调用必须经过白名单校验
• 工具结果超过 N tokens 必须截断或摘要
• 关键决策保留 trace 以便事后回溯
• 定期 Review 失败 trace，沉淀到评估集

答案：

企业级 Agent 系统需覆盖接入、对话管理、Agent 核心、工具、输出管控五层架构，每层有明确的关注点与可扩展性设计。

五层架构：

graph TB
    L1[接入层
网页/APP/公众号/企微] --> L2[对话管理层
上下文+多轮状态]
    L2 --> L3[Agent 核心层
规划+工具+反思+记忆]
    L3 --> L4[工具层
RAG/工单API/物流]
    L3 --> L5[输出管控层
敏感词+审核+话术]

各层职责：

追问必答五点：

1. 工具管理：MCP 标准化 + 权限分级 + 工具白名单
2. 记忆设计：Redis 短期记忆 + 向量 DB 长期记忆 + 关系 DB 结构化事实
3. 可靠性：工具超时 + 熔断器 + Human-in-the-Loop 审批
4. 可观测性：全链路 Trace + 成本监控 + 异常告警
5. 安全：Prompt Injection 防御 + 最小权限原则 + 数据脱敏

企业级与原型的核心差异：

• 原型关注"能不能跑通"，企业级关注"出问题怎么办"
• 原型可接受人工修复，企业级要求自愈 + 告警 + 审计
• 原型单用户测试，企业级要求多租户隔离与限流