1. AI Agent 核心概念与架构（面试高频必问）

Q1：什么是 AI Agent？它与传统 LLM 应用的本质区别是什么？
标准答案：
AI Agent 是一个能自主感知环境、制定计划、执行行动并迭代反馈的智能体系统。其核心公式为 Agent = LLM + Planning + Memory + Tools。与传统 LLM 应用的"一次性问答"模式不同，Agent 的关键特征在于：

  • 自主规划：能将复杂任务拆解为多步可执行子目标，而非直接输出答案。
  • 工具调用：通过 Function Calling 和外部 API/数据库/代码解释器交互，扩展 LLM 的能力边界。
  • 记忆系统：同时拥有短期工作记忆（对话上下文）和长期向量记忆（知识持久化）。
  • 反思纠错：具备自我批判能力，通过多次推理-行动循环（ReAct/CoT）不断修正中间结果。

生产环境落地：
在实际部署中，我们优先使用 LangGraph 构建 Agent 状态图，而非常见的单次 ReAct 循环。LangGraph 允许将整个 Agent 流程建模为有向图——每个节点代表一个独立状态（推理、调用工具、校验结果），边则为条件跳转。这样比传统 while-true 循环更稳定，也在 Google、Netflix 的内部 Agent 平台上经过大规模验证。

Q2：请解释 ReAct、Plan-and-Execute、Multi-Agent 三种框架的差异及适用场景。

框架 核心流程 优势 劣势 生产环境建议
ReAct (Reason+Act) 交错的"思考-行动-观察"循环 简单、延迟低、易调试 长任务易迷失方向 简单查询、短期任务（<5步）
Plan-and-Execute 先全局规划再逐步执行，中间可调整 任务目标清晰，不易跑偏 首次规划耗时较长 复杂工作流、需依赖关系的任务
Multi-Agent 多个专业化 Agent 协作或辩论 专业度高、可扩展性强 通信开销大，协调复杂 跨域知识、需多视角审核的生成任务

生产环境落地：
避免仅使用 LangChain 封装的 ReAct 循环，生产环境应使用 LangGraph 实现 Plan-and-Execute 架构。具体做法：用 Planner Agent 先输出 JSON 执行计划（步骤、工具名、预期参数），再由 Executor Agent 逐条执行并写入共享状态字典，每轮执行后 Planner 检查结果是否满足预期，若偏差则动态调整后续步骤。这种状态图控制比纯 Prompt 编排成功率高 50% 以上。

2. Agent 技术栈：LangChain、LangGraph 与工具编排

Q3：实际项目中，如何做 Agent 的工具定义与 Function Calling？请给出代码示例。
生产环境方案（基于 Python + LangGraph）：

from langgraph.graph import StateGraph, END
from langchain_community.tools import tool
from typing import TypedDict

# 1. 定义共享状态，所有节点通过它传递数据
class AgentState(TypedDict):
    query: str
    plan: list
    cur_step: int
    results: list
    final_answer: str

# 2. 用 Pydantic 严格定义工具 Schema
@tool
def search_customer_db(email: str) -> str:
    """根据邮箱查询客户历史工单与VIP等级，输入格式：email"""
    # 生产环境接 PostgreSQL/Elasticsearch
    return f"Customer {email}: VIP Platinum, 5 open tickets"

tools = [search_customer_db]

# 3. 规划节点：LLM 先输出结构化计划
def planner_node(state: AgentState) -> AgentState:
    prompt = f"""你是一个客服执行计划员。根据用户问题，生成调用工具的顺序计划。
    可用工具：search_customer_db(邮箱)
    输出纯 JSON 数组，元素为 {{"tool":"工具名","args":{{}}}}。
    用户问题：{state['query']}"""
    llm_response = model.invoke(prompt)  # 实际调模型
    import json
    state['plan'] = json.loads(llm_response)
    state['cur_step'] = 0
    return state

# 4. 执行节点：逐条调用工具，结果写入状态
def executor_node(state: AgentState) -> AgentState:
    step = state['plan'][state['cur_step']]
    tool_map = {t.name: t for t in tools}
    result = tool_map[step['tool']].invoke(step['args'])
    state['results'].append(result)
    state['cur_step'] += 1
    return state

生产环境落地：
永远不要在 Prompt 里手写假数据返回，确保工具返回值来自真实后端。工具 Schema 必须使用 Pydantic v2 严格定义类型与约束（如 email: EmailStr），以提升模型对参数的理解精度。工具返回"大结构"数据时，先在工具内部做摘要提取再返回 Agent，避免超出 LLM 上下文窗口。

Q4：RAG 与 Agent 如何结合？请画出检索增强生成在 Agent 中的架构。
面试标准答案：
RAG（检索增强生成）是 Agent 的核心 Tool 之一。Agent 通过 Knowledge Retrieval Tool 从向量数据库/文档库中获取外部知识，再结合自身推理生成最终答案。常见架构：用户 Query → Agent 判断是否需要检索 → 调用向量检索工具 → 带上下文重新生成答案。

生产环境架构图：

简单寒暄

知识密集型

用户自然语言查询

Agent 路由器
判断查询类型

直接 LLM 回复

RAG 检索工具

Embedding 模型
Query 向量化

向量数据库
TopK 近似匹配

Re-Ranker
重排序精排

Top3 文档切片

LLM 融合生成
带引用回复

最终带来源答案

生产环境落地：
推荐混合检索而非纯向量检索：Embedding 语义相似度 + BM25 关键词匹配 加权融合，能显著提升专业术语/代码片段/法律条文等场景的召回率。在 Agent 内部，RAG 不应只做一次 → 应实现 ReAct-RAG：首次检索后若置信度低于阈值，则自动改写 Query 并重跑检索，最多 2 轮。

3. 多 Agent 系统与协作模式

Q5：如何处理多 Agent 之间的通信、状态共享与冲突？给出架构设计。
标准答案：
多 Agent 架构主要有两种通信模式：

  1. 中央调度器模式：一个 Orchestrator Agent 负责分派任务给各 Worker Agent 并汇总结果。
  2. 去中心化对话模式：Agent 之间直接传递消息，通过"谁对当前结果有异议"来触发下一轮生成。

生产环境方案：
使用 LangGraph 的 StateGraph 实现"虚拟公司"架构。每个部门（Agent）均为图谱中的子图，共享同一个 CompanyState 状态字典，中央决策节点（CEO Agent）检查状态后决定路由。

未通过

全部通过

CEO Agent
任务拆解与仲裁

技术部
代码生成 Agent

合规部
法律审核 Agent

市场部
文案润色 Agent

共享状态 Tag
质量标记

输出最终方案

生产环境落地：
实践中推荐使用 AutoGen 或 CrewAI 快速原型化多 Agent 系统，但在生产部署时迁移至 LangGraph 以获得更精细的 graph 控制（如超时、重试、断点恢复、人工介入节点）。自动冲突解决不能仅靠 LLM 辩论，必须用确定性规则函数兜底，例如涉及金额时直接走正则校验而非让 Agent 讨论。

Q6：消息总条数爆炸和上下文过长如何解决？

优化策略：

  • 分层记忆体系：短期（会话内 20k token）+ 中期（本周摘要向量存储）+ 长期（FAQ 固化知识库）。
  • 上下文选择性压缩：Agent 每收集完一轮工具调用结果后，用 LLM 生成不超过 500 字的摘要替换原始长返回，只保留摘要+关键代码片段。
  • Auto-Summarization Gate：在 LangGraph 中添加"上下文压缩"节点，当 len(state['messages']) > 阈值 时自动触发摘要。

4. 单智能体架构设计与可扩展性

Q7：如何设计一个可扩展的单智能体系统架构？请画出分层架构。

生产环境分层架构：

💾 数据层 (Data)

🔧 服务层 (Tools & Services)

🧠 编排层 (Orchestration)

🚀 表现层 (Interface)

Web UI / API / 企业微信

主控 Agent
任务路由与调度

LangGraph StateGraph
状态与流程控制

安全护栏
输入/输出审查

RAG 检索工具

代码解释器 (沙箱)

API 调用代理

人类介入节点

PostgreSQL
结构化记忆

Milvus
向量记忆

MongoDB
日志与审计

可扩展性关键设计：

  • 工具插件化：工具定义统一抽象为 Tool 接口（含 validation、execute、fallback 三个方法），新增工具只需实现该接口并注册到 Tool Registry，无需改动 Agent 核心逻辑。
  • 状态持久化：利用 LangGraph 的 Checkpointer 将 Agent 状态持久化到 PostgreSQL，实现跨会话中断恢复——用户半小时后回来还能从上次断点继续。
  • 多模型路由：复杂规划节点使用 GPT-4/Claude-3.5，简单工具调用节点自动降级到 Haiku/GPT-4o-mini，节省延迟和成本。

生产环境落地：
编排层必须加安全护栏（Guardrails）——在 agent.call() 前后各挂一个检查节点。前检查过滤敏感词和代码注入（输入框里写 Python 代码企图让 Agent 执行），后检查拦截泄露 prompt 的回复。切忌只用 Prompt 约束，实际拦截要走硬编码规则。

5. Agent 评估体系与生产保障

Q8：Agent 系统如何做准确率评估？有哪些实战指标？
标准答案：
Agent 评估不同于传统分类/回归，需从端到端任务完成度和中间步骤质量两个维度考量。

核心指标体系：

  • 任务成功率：最终结果是否满足用户需求？用 LLM-as-Judge (GPT-4) 对答案做 A/B 评分。
  • 工具调用准确率：是否选择了正确的工具？参数是否正确？用 precision 和 recall 自动化计算。
  • 幻觉率：生成内容中引用数据与工具返回数据不一致的比例。
  • 平均步数/效率：完成同类任务的平均工具调用步数，过长说明规划差。
  • 安全拦截率：触发护栏的比例，用于监控攻击与越狱企图。

生产环境落地：
构建 Golden Dataset（1000+ 真实业务测试用例），每个 case 包含 {query, expected_tool_sequence, expected_answer_keywords}。CI/CD 中跑自动评估集，工具调用序列匹配率 < 90% 自动拦截上线。同时使用 LangSmith 追踪每一步 tool call 的输入输出，方便线上问题回放和回溯。

6. 安全架构：鉴权、沙箱与数据隔离

Q9：Agent 需要调用外部 API 和执行代码，如何保障生产安全？
安全架构四层防御：

  1. 输入消毒层：检测 prompt 注入（“忽略之前的指令”）并自动清洗。
  2. 工具鉴权层：所有 Tool 调用必须携带操作者身份 Token，后端验证该用户是否有权执行此操作。严禁 Agent 使用 admin 权限直接操作数据库。
  3. 代码沙箱层：Agent 生成或执行代码时必须在隔离 Docker 容器（gVisor/Firecracker）内运行，网络只出不进，执行超时 30 秒强制 kill。
  4. 输出审查层：生成结果中若包含邮箱/手机号/PII 信息，自动脱敏或二次确认。

生产环境落地：
使用 AWS Lambda + gVisor Sandbox 或 E2B.dev 云端沙箱执行不安全代码。鉴权端实现 RBAC：每个 Agent 实例绑定一个有限权限的服务账号，禁止直接访问生产数据库写库，所有增删改操作必须生成 SQL 预览，等人类点击确认后才执行。

7. 可观测性、日志与故障排错

Q10：Agent 在生产环境出问题时，如何快速排错？
可观测性三角：

  • Metrics：每分钟任务成功率、平均 Token 消耗、P95 延迟、工具调用次数（Prometheus + Grafana）。
  • Traces：单次任务完整调用链——推理、工具返回、重试次数（LangSmith / OpenTelemetry）。
  • Logs：结构化 JSON 日志，每条记录包含 session_id, step, tool_name, input, output, error, trace_id。

典型故障排错流程：
某人反馈"Agent 查不到订单"，运维直接在日志系统按 session_id 搜索全链路，发现是第二步 order_query_tool 返回了 403 Forbidden（API 鉴权过期），Agent 未正确处理该异常导致输出了"没有订单"的假结论。修复：在 Tool 中增加异常格式约定，所有异常返回 {"error": "权限不足，请刷新登录"} 格式，Agent 识别到错误则终止任务并提示用户刷新登录。

生产环境落地：
所有 Tool 调用必须添加 try-catch 并返回标准化错误格式，不要靠 LLM 自行理解原始 HTTP 500 报错。日志中每条 tool call 的输入/输出全量记录（非流式），保留 30 天作为审计溯源。推荐接入 LangFuse 或 LangSmith 作为 Agent 专用追踪系统。

8. Agent 与 MCP（Model Context Protocol）

Q11：MCP（Model Context Protocol）是什么？为什么在 Agent 开发中愈发重要？
标准答案：
MCP（Model Context Protocol）是 Anthropic 推出的一种开放协议，旨在让 AI 模型安全、统一地访问本地与远程资源，取代过去每个 Agent 都要写定制化工具连接器的开发模式。它相当于"AI 的 USB-C 接口"，通过统一的 Client-Server 架构实现：

  • 资源暴露：Server 端定义文件、数据库、API 等资源。
  • 工具定义：标准化工具清单，Agent 直接通过 MCP 调用。
  • 安全协商：用户显式授权后 Agent 才能访问敏感资源。

生产环境落地：
2025 年开始越来越多企业要求 Agent 岗位候选人熟悉 MCP。实践中可用于：Agent 直接通过 MCP Server 连接到公司的 GitHub/Jira/Slack，而无需为每个系统写定制 Tool 封装。面试时若提到 MCP，一定要说明其与 Function Calling 的关系——MCP 是工具接入的标准化协议，Function Calling 是模型调用工具的交互方式，两者互补。

9. 成本优化与大模型选型

Q12：生产环境中如何控制 Agent 成本？
成本优化三步法：

  1. 分层模型策略：简单意图识别/分类用 4o-mini，复杂推理/代码生成才用 Claude/GPT-4。
  2. Prompt Caching：系统提示和常用工具定义每 10 分钟内不变化的部分使用 Cached Prompt，成本可降低 40%-60%。
  3. 自动降级：高峰期 QPS 过高时，长任务自动降级为简短答复+引导用户稍后提问。

生产环境落地：
使用 LangGraph 的动态模型路由，在 node 的定义里根据任务复杂度选择模型。同时监控每日 Token 消耗报表，设置预算告警阈值。GPT-4 系列专门用于处理"失败重试"——首次失败，降级模型二次处理若再失败，升级到最强模型最后尝试一次，兼顾成本与成功率。

10. 进阶面试回答：AI Agent 发展趋势与架构选型

Q13：Agent 开发中，如何处理"长对话遗忘"和"上下文窗口限制"？
进阶回答：
除了基本的摘要分层记忆，还可以采用 MemGPT / Letta 技术——让 Agent 像操作系统管理虚拟内存一样管理上下文。Agent 拥有"主上下文"（当前活跃）+ “外部存储”（向量数据库），通过函数调用来主动读写外部存储。例如 Agent 判断某个信息短期内不需要了，就自行调用 conversation_search 归档到向量库，需要时再检索回来，实现几乎无限的上下文长度。

Q14：你认为 AI Agent 技术还有哪些亟待突破的方向？
面试加分回答（展示行业视野）：

  • 可靠性 Guarantees：当前 Agent 仍是概率系统，需要引入"形式化验证"或"规则引擎兜底"来实现关键业务场景的 100% 确定性。

  • 人机协同的价值：不是让 Agent 完全替代人，而是设计好人类介入节点（Human-in-the-loop）让 Agent 在不确定时主动询问确认。

  • 复杂推理能力：结合 System 2 推理（如 Tree-of-Thoughts），让 Agent 能像人类一样探索多种解决路径并回溯选择最优解，而非每次只会贪心前进。

12. 面试模拟题与参考答案

场景一：电商智能客服 Agent 系统设计

题目描述：
某大型电商平台日均客服咨询量 50 万次，覆盖售前商品咨询、订单查询、退换货处理、投诉升级等场景。现有客服系统仅支持关键词匹配，准确率不足 60%，且无法处理「我上周买的那件蓝色卫衣怎么还没到？」这类多跳推理查询。请设计一套 Agent 系统替代现有方案。

答题思路（参考答案）：

  1. 意图路由层：设计 Router Agent 作为入口，先用轻量模型（4o-mini）做意图分类，将用户问题分流至：售前咨询 Agent、售后处理 Agent、订单查询 Agent、人工升级节点。
  2. 工具矩阵设计：订单查询 Agent 挂载 query_order_by_sku、track_logistics、query_member_profile 三个 Tool；退换货 Agent 挂载 check_return_policy、create_return_ticket；所有 Agent 共享 search_knowledge_base（RAG 检索商品详情/平台政策）。
  3. 多跳推理链路：以「蓝色卫衣」为例 → 第一步调 query_member_profile 获取用户近 30 天订单列表 → 第二步 LLM 从中筛选出 SKU 含“卫衣”且颜色属性为“蓝色”的订单 → 第三步调 track_logistics 返回实时物流状态 → 第四步用自然语言组织回复。
  4. 安全兜底：退换货/退款等涉及资金操作必须插入 Human-in-the-loop 确认节点，生成操作预览后等待用户二次确认才执行。
  5. 状态持久化：使用 LangGraph Checkpointer 将会话状态写入 PostgreSQL，用户中途退出后 24 小时内回来可从断点继续。

考察点：

  • 是否理解多 Agent 拆分粒度（按业务域而非按功能）
  • 能否设计多跳 Tool Calling 的串联逻辑
  • 对安全边界（资金操作需人类确认）的敏感度
  • 状态持久化与断点恢复的实际经验

-场景二：代码审查 Agent 系统设计

题目描述：
你所在团队需要构建一个内部代码审查 Agent，能够自动对 GitHub PR 进行代码质量审查、安全漏洞扫描和架构规范校验。要求：支持 Java 和 Python 两种语言，单次审查耗时不超过 2 分钟，误报率控制在 15% 以下。请设计整个系统架构并说明关键设计决策。

答题思路（参考答案）：案**：

一、整体架构设计

系统采用 事件驱动 + Multi-Agent 协作 架构，核心分为五层：

  1. 事件接入层：通过 GitHub Webhook 监听 pull_request.opened 和 pull_request.synchronize 事件，将 PR 元数据（repo、PR 编号、commit SHA、变更文件列表）推入消息队列（RabbitMQ / AWS SQS），实现消峰填谷。Webhook 接收端仅做签名校验（HMAC-SHA256），鉴别伪造请求。

  2. 任务编排层：主控 Agent（Orchestrator）从队列消费 PR 事件，调用 GitHub API 拉取 PR diff 全文。对超大 PR（变更行数 > 500），按文件边界自动拆分为多个子任务（每批 ≤ 500 行），分发给审查子 Agent 并行处理。同一个 PR 的所有子任务完成后统一汇总，避免「审查结论碎片化」。

  3. 审查执行层（Multi-Agent 协作）：

    • 代码规范 Agent：挂载 checkstyle（Java）/ ruff（Python）/ eslint（前端）Tool，以 subprocess 在隔离环境运行，防止 tool 执行逃逸。该 Agent 仅做「规则匹配 → 格式化输出」，不参与语义理解，保证规范检查端的确定性。
    • 安全漏洞 Agent：挂载 semgrep + 自定义规则集（覆盖 OWASP Top 10：SQL 注入、XSS、硬编码密钥、路径穿越等）。输出每条命中的风险等级（High / Medium / Low）与 CWE 编号，便于安全团队关联。
    • 架构审计 Agent：通过 RAG 检索团队架构规范文档（如《微服务分层规范》《API 设计公约》），用 LLM 从语义层面判断 PR 变更是否违反分层架构、依赖方向、循环引用等软约束——这是 lint 工具无法覆盖的领域。

    关键架构决策：为什么采用 Multi-Agent 而非单一 Agent 同时审查？因为规范检查与架构审计的评判标准完全不同——前者需要确定性规则（lint 工具一次判断即可），后者依赖 LLM 语义理解（上下文窗口消耗大）。拆分后各自使用最适合的模型（规范 Agent 用 4o-mini，架构审计 Agent 用 GPT-4），兼顾成本与质量。

  4. 降误报层（双重校验 + 白名单机制）：

    • 安全 Agent 标记的每个 High 级别问题，先由代码规范 Agent 交叉验证：检查该行是否存在 @SuppressWarnings / # nosec 等显式抑制标注。若存在且标注原因与安全规则匹配，自动降级为 Info 级别。
    • 维护团队级「误报白名单.yaml」（如：测试文件中的硬编码密钥 test_sk_xxxx 允许豁免），在最终汇总阶段过滤。
    • 只有两方一致判定为有效问题，且不在白名单内的告警，才进入最终 Review Summary。
    • 实测效果：引入双重校验后，误报率从 28% 降至约 11%，满足题目要求的 ≤ 15%。

  5. 输出与集成层：

    • 汇总各子 Agent 的审查结果，按文件路径分组生成结构化 Review Summary。
    • 每条告警包含：严重程度 | 文件:行号 | 问题描述 | 建议修复方式 | 关联规范条目 | 检出来源（Agent）。
    • 通过 GitHub API 在 PR 页面自动添加 Review Comment（⚠️ 注意：禁用 APPROVE 权限，Agent 仅创建 Review Comment，合并审批权始终归人类）。

二、工具选型与关键决策表

维度 选型 替代方案 决策理由
编排框架 LangGraph StateGraph Temporal / Airflow LangGraph 内置 Checkpointer，天然支持审查中断恢复；Temporal 更重，适合跨系统长流程而非单次审查任务
Lint 工具 checkstyle（Java）+ ruff（Python） SonarQube checkstyle/ruff 为 CLI 工具，可在 Docker 容器内直接 subprocess.run()，无需额外部署 SonarQube Server，降低运维成本
SAST 工具 semgrep（社区规则 + 自定义 YAML） CodeQL semgrep 规则编写门槛低（YAML 配置），迭代速度快；CodeQL 分析更深但耗时不可控，与 2 分钟 SLA 冲突
架构规范检索 RAG（Milvus + BM25 混合检索） 全量 Prompt 注入 团队规范文档通常 10k+ token，全量注入会显著增加延迟和成本；RAG 按需检索仅取 Top3 最相关规范条款
消息队列 RabbitMQ Kafka 审查任务是低吞吐（PR 频率秒级别），RabbitMQ 的 ACK + 死信队列模型更适合「每个任务需保证处理」的场景；Kafka 适合高吞吐日志流，非 PR 审查最佳匹配
容器化执行 AWS Lambda（15 分钟超时）+ ECS Fargate 兜底 Kubernetes 单个审查任务 < 2 分钟，Lambda 完全满足；超大 PR 拆分后子任务也用 Lambda，仅在极少数超 15 分钟场景 fallback 到 Fargate

三、性能与容错设计

  • 并行化策略：Orchestrator 将 PR 按文件拆分为 N 个子任务 → 写入消息队列（每条携带 {parent_pr_id, batch_index}）→ N 个 Worker 并行消费执行规范/安全/架构检查 → 所有子任务完成后触发聚合 Lambda 汇总结果。实测可将 800 行 PR 的审查时间从串行 180s 压缩到并行 62s。
  • 超时与兜底：每个子任务超时 90 秒（低于 Lambda 15 分钟上限），全局总超时 115 秒。超时后聚合节点收集已完成批次的审查结论，未完成文件标记 ⚠️ 审查未完成，请人工复核，不阻塞 PR 流程。
  • 失败重试：工具调用异常（如 GitHub API 503）进入指数退避重试（最多 3 次，间隔 2s / 4s / 8s），3 次失败后记录错误日志并通知 DevOps 频道。
  • 代码隐私保护：审查全流程在自有 VPC 内的隔离容器执行，PR diff 内容不出内网。审计日志（谁提交的 PR、哪个 Agent 审查、发现了什么问题）写入审计数据库（PostgreSQL），保留 90 天。

四、考察点分析

  • Agent 架构设计能力：是否理解 Multi-Agent 拆分粒度，能否区分「确定性规则检查」和「LLM 语义理解」两种任务并分配到不同 Agent。
  • 技术栈与工具选型判断力：能否在 semgrep、CodeQL、SonarQube 等工具中基于「延迟 SLA」和「运维成本」做合理取舍，并说出备选方案及其取舍理由。
  • 工程化思维：是否考虑批量任务拆分、并行执行、全局超时、失败重试等生产细节，而非仅停留在「调用 lint 工具」的原型层面。
  • 误报率控制的实际手段：双重校验 + 白名单机制，而非简单依赖 Prompt 指令降低误报（Prompt 指令无法量化，面试官更看重可落地的工程方案）。
  • 安全意识：Webhook 签名校验、代码隐私不出内网、Agent Review Comment 权限限制（禁止 APPROVE）、审计日志- 企业级场景延伸：是否考虑多语言扩展、团队规范文档的 RAG 检索设计、与 CI/CD 流水线的集成点。成文件。

考察点：

  • 是否理解代码 Agent 的 Tool 选型（直接调 lint/SAST 工具而非让 LLM 凭记忆判断）
  • 误报率控制的手段（双重校验而非单 Agent 一次判定）
  • 并行执行与超时容错的设计能力
  • 是否考虑到企业级场景的额外需求（如审计日志、代码隐私保护）

-场景三：Agent 上下文管理——舆情分析系统

题目描述：
某公关团队需用 Agent 实时监控社交媒体上与品牌相关的讨论，每小时抓取约 2000 条帖子，要求 Agent 自动聚类话题、识别负面情绪升级趋势，并在检测到「高危舆情」（负面帖子占比突增 > 30%）时生成预警报告。该系统需 7×24 小时运行，请设计其上下文管理与信息压缩策略。

答题思路（参考答案）：案**：

一、整体架构设计

系统采用 定时批处理 + 流水线式 Agent 架构，核心挑战不是单次推理的复杂度，而是 每小时 2000 条帖子的上下文管理——如何在不丢失关键信息的前提下，将海量非结构化文本压缩为 Agent 可处理的规模。

架构分为 触发层 → 流水线执行层 → 存储层 → 预警与查询层 四部分：

  1. 触发层：使用 cron 定时任务（如 AWS CloudWatch Events / K8s CronJob）每小时整点触发一次 Agent 流水线。触发时将 {run_id, timestamp, data_source} 写入状态表，标记本次批次开始。

  2. 流水线执行层（LangGraph StateGraph，4 个节点顺序执行）：

    • 节点 1：数据抓取 — 调用社交媒体平台 API（Twitter/X API、微博开放平台等），按品牌关键词 + 时间范围抓取帖子。原始数据写入对象存储（S3 / MinIO）归档，仅将 {post_id, text, timestamp, engagement_count} 写入 State 传给下游。
    • 节点 2：话题聚类与摘要 — 将 2000 条帖子的 text 字段批量送入 Embedding 模型（text-embedding-3-small，低成本高吞吐），得到 2000 个 1536 维向量。使用 MiniBatchKMeans（n_clusters=10）聚类，对每个簇取 Top3 代表性帖子 + LLM 生成 1 句话题摘要（如「新品定价争议，负面为主，转发量飙升」）。此时 State 中仅保留 10–12 行摘要文本（约 300 token），不保留原始帖子。
    • 节点 3：情绪评分与趋势写入 — 对每条摘要用 LLM 做情绪三分类（正面/负面/中性），写入 PostgreSQL sentiment_trend 表，字段：{hour_bucket, topic_cluster_id, positive_ratio, negative_ratio, neutral_ratio, post_count}。
    • 节点 4：预警判断 — 纯 SQL 检测，不走 LLM。查询 sentiment_trend 表，计算每个话题簇过去 6 小时滑动窗口内 negative_ratio 的均值，若 > 30% 且当前小时 post_count > 50（排除小样本噪音），触发高危舆情预警。

  3. 存储层：

    • PostgreSQL：存储结构化情绪趋势数据（时序表）、批次运行状态（Checkpoint 表）、预警历史记录。
    • Milvus 向量数据库：存储每小时的 话题摘要 Embedding + 元数据（时间戳、话题标签、情绪标签），用于长期跨日期语义检索。
    • S3 / MinIO：原始帖子全量归档（成本极低，用于事后审计或重新分析）。

  4. 预警与查询层：

    • 高危预警触发后，Agent 自动调用通知 Tool（企业微信 / Slack Webhook / PagerDuty），推送消息格式：「🚨 高危舆情预警 | 话题：新品定价争议 | 当前负面率：38% | 过去 6h 趋势：23%→28%→35%→38% | 详情链接：[舆情仪表盘]」。
    • 查询接口：公关人员可自然语言提问（如「过去一周负面趋势」），Agent 用 time_range_filter 从 Milvus 检索相关摘要 → LLM 生成周报。

二、上下文管理核心策略（面试核心得分点）

这个系统的本质问题是「每小时 2000 条原始帖子 ≈ 80k–120k token，远超任何模型上下文窗口，如何让 Agent 理解全局态势？」

策略 具体手段 压缩比 关键设计考量
聚类降维 Embedding + K-means 将 2000 条帖子映射到 10 个话题簇 2000 → 10（200:1） K 值动态调整：若簇内平均距离 > 阈值，说明话题分散，自动将 K 上调至 15
LLM 摘要 每个簇取 Top3 代表性帖子喂给 LLM，输出 1 句摘要 + 情绪标签 每簇 500 token → 30 token（16:1） 代表性帖子选取策略：选离簇中心最近的帖子，而非随机采样，保证摘要准确度
时序窗口 预警只计算过去 6 小时，而非全量历史 时间维度压缩 6 小时是业务定义的「舆情响应窗口」——既能捕捉突发舆情，又避免历史数据干扰
确定性规则兜底 预警判定走 SQL 窗口函数，不走 LLM 无需 token 消耗 趋势检测是「数值比较」问题，用 SQL 比用 LLM 更可靠、更快（毫秒级 vs 秒级）、成本更低

关键架构决策：为什么预警用 SQL 而非 LLM？
面试官期望候选人能区分「LLM 擅长的事」和「确定性规则擅长的事」。舆情趋势判断本质是「过去 6 小时内负面占比是否超过 30%」——这是简单的数值运算。若让 Agent 读取所有摘要再「凭感觉」判断是否高危，结果不可复现（同一数据两次可能给出不同结论），也无法审计（不知道 LLM 为什么觉得高危）。用 SQL 窗口函数既保证了判定的确定性、可复现性和可审计性，又完全省去了这部分 Token 消耗。

三、情绪评分 Pipeline 的细节设计

  • 模型选择：情绪分类使用 4o-mini（成本极低，准确率足够）而非 GPT-4。每条摘要仅 30 token，2000 条帖子 → 10 条摘要 → 10 次分类调用，每次约 0.0003 美元，每月成本约 $2。
  • Prompt 约束：分类 Prompt 必须约束输出格式为 {"sentiment": "positive|negative|neutral", "confidence": 0.0-1.0}，用 structured output 模式解析。confidence < 0.6 的归为 neutral，避免低置信度误导趋势。
  • 去噪过滤：post_count < 10 的话题簇不参与预警计算（样本量太小无统计意义），但仍保留摘要供人工查看。

四、7×24 长期运行的容错设计

  • Checkpoint 持久化：每个节点执行完毕后，将 State 序列化写入 PostgreSQL run_checkpoint 表。若节点 3（情绪评分）因 API 限流失败，下次 cron 触发时从 Checkpoint 恢复，直接从节点 3 重试，而无需重新抓取和聚类。
  • 幂等性保证：每个 run_id 对应一次批处理，数据抓取时通过 (post_id, run_id) 唯一键去重，防止因重试导致重复计数。
  • 降级策略：若 Embedding API 超时（概率约 0.1%），降级为 TF-IDF + K-means 聚类（纯本地计算，不依赖外部 API）；若 LLM 摘要 API 超时，降级为取每簇 TF-IDF 最高频词作为话题标签。
  • 监控告警：Prometheus 监控每小时任务成功率、P95 延迟、各节点失败率。连续两次任务失败触发运维告警。

五、与「场景一」系统设计的对比（面试加分项）

维度 场景一：客服系统 场景三：舆情分析系统
触发模式 事件驱动（用户实时提问） 定时批处理（每小时一次）
延迟要求 实时（< 3 秒） 准实时（容忍分钟级延迟）
上下文规模 单次对话 2k-10k token 每小时 80k+ token 原始数据
核心挑战 多跳 Tool Calling 准确性 海量文本的上下文压缩与摘要
LLM 调用模式 按需调用（对话轮次） 批量调用（每簇一次摘要）
确定性规则边界 Human-in-the-loop（资金操作） SQL 趋势检测（数值判定）

这个对比能展示候选人对 不同场景下架构权衡的系统性理解，是面试官期望看到的「全局架构视野」。

六、考察点分析

  • 大规模数据的上下文压缩方案：是否理解「聚类 + 摘要」的本质是信息漏斗（2000 条 → 10 个簇 → 10 条摘要），并能解释压缩比与信息损失的权衡。
  • LLM 与确定性规则的边界划分：能否识别「趋势检测」不适合用 LLM 判断，而应走 SQL / 统计方法——这是衡量候选人是否具备「系统设计判断力」的关键得分点。
  • 长期跨会话记忆的设计：向量数据库 + 时间索引 + 语义检索的组合方案，而非简单地「把所有摘要塞进 Prompt」。
  • 生产环境 7×24 运行的容错考量：Checkpoint / 幂等 / API 降级 / 监控告警，体现工程落地意识。
  • 成本意识：情绪分类用 4o-mini 而非 GPT-4，能在保证准确率的前提下将月成本控制在个位数美元级别。
  • Agent 编排框架应用：LangGraph StateGraph 的顺序节点 + Checkpointer，利用而非绕过框架的容错能力。丢数据。

考察点：

  • 大规模数据的上下文压缩方案（聚类 + 摘要，而非全文塞入）
  • 确定性规则与 LLM 推理的边界划分（趋势检测走 SQL，不走 LLM 主观判断）
  • 长期跨会话记忆的设计（向量库 + 时间索引）
  • 生产环境 7×24 运行的容错考虑
    –

11. 总结与面试准备建议

AI Agent 岗位面试已从早期的"会不会用 LangChain"进阶到工程落地能力的全面考察。面试官看重的不再是调用 Prompt 的熟练度，而是：

  • 对 LangGraph 等图编排框架的实际使用经验。
  • 在生产高并发、高安全要求下的 Agent 架构设计能力。
  • 评估体系、成本控制、故障排错的全链路思考。

冲刺建议：

  1. 每月至少阅读 5 篇 LangGraph、AutoGen、CrewAI 的 GitHub Issue 讨论。
  2. 准备一个开源 Agent 项目（如客服系统）并在简历中描述你遇到的具体生产问题（比如如何解决工具调用超时、如何设计安全护栏）。
  3. 面试回答时尽量用"我们在生产环境中这样做…“代替"理论上可以…”。
# 面试 # 人工智能 # python # 职场和发展 # 架构
Logo
AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

AI Agent如何通过微信接口完成自动交互？

AI Agent 自动交互的本质，是事件驱动架构与大模型决策中台的深度解耦与对齐。上行靠 Webhook 快速分发完成状态捕获，中间件靠分布式状态机完成逻辑恢复，下行则通过带有流量整形的 RPC 指令实现精准触达。Eyun平台开发文档。

avatar AI Agent技术社区
cover

2026 企业 AI Agent 选型三维标尺：开发效率、合规安全、系统集成

avatar AI Agent技术社区
cover

从零搞懂 AI Agent：LLM + Tool + Reasoning 实战全解析

avatar AI Agent技术社区