设计题 - 面试题解答
生成日期：2026-05-05 | 共 28 题 来源：牛客 / 各大厂面经 / 知乎 / Datawhale 2026-05-05 更新：新增 8 题（来源：牛客/知乎/卡码笔记/小红书 2026年面经）
Q1：[来源:书中原题][2025-04] 为一个法律文书润色场景，设计从数据收集到上线的完整微调方案
考察点
对微调全流程的系统性设计能力，从数据到部署的端到端思考。
解答思路
- 数据收集与清洗
- 模型选型与训练
- 评估验证
- 部署上线
参考答案
1. 数据收集（预计 2000-5000 条）： - 来源：历史法律文书（合同、起诉状、法律意见书）+ 人工标注的"原文 vs 润色后"对照 - 格式：Alpaca 格式，instruction 为润色要求，input 为原文，output 为润色后文本 - 质量控制：由 2-3 名律师独立审核，一致性 >80% 才入库
2. 模型选型： - 基座：Qwen2.5-7B（中文法律能力强，开源可商用） - 微调方法：QLoRA（r=16, alpha=32），单卡 A100 即可训练 - 训练框架：Unsloth（训练速度快 2x，显存减半）
3. 训练配置： - 学习率：2e-4，warmup 5% - 训练轮次：3 epochs（监控验证集 loss，早停防止过拟合） - 数据划分：80% 训练 / 10% 验证 / 10% 测试
4. 评估： - 自动指标：ROUGE-L、BERTScore - LLM-as-Judge：用 GPT-4 对润色结果评分（流畅度、专业性、法律术语准确性） - 人工评估：律师盲评（原始 vs 润色，判断哪个更好）
5. 部署： - 合并 LoRA 权重 → GGUF 格式 → Ollama 本地部署 - 或用 vLLM 部署为 API 服务 - 前端：Web 界面上传文档，返回润色结果 + 修改建议
Q2：[来源:书中原题][2025-04] 为客服场景设计一套 Prompt 管理体系
考察点
对 Prompt 工程化和生产管理的理解。
解答思路
- 管理的核心问题
- 系统架构设计
- 版本控制与 A/B 测试
参考答案
核心问题： 客服场景下 Prompt 需要频繁调整（新增业务线、话术优化、多语言），直接硬编码在代码中难以管理。
架构设计：
Prompt 管理后台（Web UI）
├── Prompt 模板编辑（变量占位符 {{user_name}}, {{order_id}}）
├── 版本管理（Git-like 版本历史 + diff 对比）
├── 环境隔离（dev / staging / prod 三套）
└── 效果监控（每个 Prompt 的用户满意度评分）
关键设计： - 模板语言：支持 Jinja2 语法，变量替换 + 条件逻辑 - Prompt 拆分：system prompt（角色定义）+ context prompt（上下文）+ instruction prompt（任务指令）三层解耦 - A/B 测试：同一任务配置两套 Prompt，流量按比例分配，对比用户满意度 - 热更新：修改 Prompt 后无需重启服务，通过 Redis Pub/Sub 通知各实例重新加载
版本控制：
prompt_id: customer_service_greeting
version: 2.1.0
environment: prod
template: "您好 {{user_name}}，我是客服助手..."
metrics:
satisfaction: 4.2
avg_tokens: 150
last_updated: 2026-05-01
Q3：[来源:书中原题][2025-04] 为法律文书场景设计一套可追溯引用的 RAG 系统
考察点
对 RAG 系统精准度和可解释性的设计能力。
解答思路
- 文档解析和切块
- 检索策略
- 引用生成
参考答案
核心需求： 法律场景下每个结论必须有依据，不能编造。
1. 文档解析：
- 用 Layout-aware Parser（如 markitdown + 自定义规则）保留法律文档的层级结构（章节、条款、子项）
- 每个 chunk 的 metadata 包含：doc_id, section, article_number, version_date, page
2. 检索策略：
- 混合检索：BM25（法律术语精确匹配）+ 向量检索（语义理解）
- RRF 融合：score = 1/(60 + rank_bm25) + 1/(60 + rank_vector)
- 权限过滤：按用户角色过滤可访问的法律条文
3. 引用生成：
- 生成答案时，要求 LLM 在每个结论后附加引用标记：[来源：《公司法》第 42 条]
- 实现方式：在 prompt 中强制要求 "回答中每一处事实陈述必须注明对应的法律条文编号"
- 置信度：无法从检索内容中找到依据时，明确回复 "暂未找到相关法律依据"
4. 追溯界面： - 用户点击引用标记 → 跳转到对应法律条文的原文位置 - 显示检索到的原始片段 + 完整条文
Q4：[来源:书中原题][2025-04] 为一个需要人工审批的采购流程设计 Agent 架构
考察点
对 Agent 与人类协作流程的设计能力。
解答思路
- 流程分析
- Agent 架构设计
- 审批节点集成
参考答案
流程分析：
采购申请 → Agent 校验 → 金额判断 → ≤5K 自动批准 / >5K 转人工审批 → 审批结果 → 执行采购 → 通知申请人
Agent 架构（LangGraph 有状态图）：
[采购申请] → [信息校验节点] → [金额判断节点]
├── ≤5K → [自动批准] → [执行采购]
└── >5K → [INTERRUPT] → [人工审批] → [审批结果]
├── 批准 → [执行采购]
└── 拒绝 → [通知申请人]
关键设计：
- 校验节点：检查采购申请格式是否正确、必填项是否完整、预算是否充足
- 中断节点：用 LangGraph 的 interrupt_before 在审批前暂停，生成审批卡片推送给审批人（企业微信/钉钉/Slack）
- 审批人界面：卡片显示采购详情 + Agent 的校验结果 + 推荐建议（"该供应商历史合作 3 次，均无异常，建议批准"）
- 审批人操作：一键批准 / 拒绝 / 要求补充材料
- 状态持久化：每个节点执行结果存入 Checkpoint，审批人可在任意时间点恢复
Q5：[来源:书中原题][2025-04] 设计一套支持千万用户的 LLM 网关架构
考察点
对大规模 AI 服务基础设施的系统设计能力。
解答思路
- 架构总览
- 各层设计
- 关键问题处理
参考答案
架构总览（四层架构）：
┌──────────────┐
客户端 → CDN/WAF → │ API Gateway │ （限流、鉴权、路由）
└──────┬───────┘
┌──────┴───────┐
│ Router Layer │ （模型路由、负载均衡）
└──────┬───────┘
┌──────┴───────┐
│ Inference │ （vLLM/TGI 集群）
│ Cluster │ + GPU 资源池
└──────┬───────┘
┌──────┴───────┐
│ Cache + DB │ （Redis + 向量库）
└──────────────┘
关键设计：
- API Gateway 层：
- Nginx/Envoy 做第一层限流和 WAF 防护
- JWT 鉴权 + API Key 验证
-
按租户/用户分桶限流
-
Router 层（核心）：
- 模型路由：根据用户等级、任务类型、当前负载选择后端模型实例
- 语义缓存：Redis + Embedding 向量检索，相似查询直接返回
-
Fallback：主模型不可用时自动切换备用模型
-
Inference 层：
- GPU 集群分片：按模型类型分片（7B/70B 分别部署）
- vLLM continuous batching，最大化 GPU 利用率
-
多副本部署，HPA 基于 QPS 自动扩缩容
-
存储层：
- Redis：会话状态、缓存、限流计数
- 向量库：RAG 知识索引
- PostgreSQL：用户信息、计费、审计日志
千万用户的容量估算： - 日活 10% = 100 万 DAU - 人均 50 次请求/天 = 5000 万次/天 ≈ 580 QPS（平均），峰值 ~3000 QPS - 单张 A100 处理 GPT-4 级别请求 ~50 QPS → 需要 ~60 张 A100（峰值） - 加上语义缓存命中率 40%，实际需要 ~36 张 A100
Q6：[来源:书中原题][2025-04] 用 Multi-Agent 设计一套自动化内容审核系统
考察点
对多 Agent 协作模式的系统设计能力。
解答思路
- 审核需求分析
- Agent 分工设计
- 协作流程
参考答案
Agent 分工：
| Agent | 职责 | 工具 |
|---|---|---|
| 内容解析 Agent | 解析文本/图片/视频，提取关键特征 | OCR、ASR、图像识别 |
| 规则审核 Agent | 基于规则引擎进行初筛 | 敏感词库、正则匹配 |
| 语义审核 Agent | 理解上下文语义，判断违规 | LLM + 审核 prompt |
| 风险评估 Agent | 综合判断风险等级 | 历史数据、用户画像 |
| 决策 Agent | 最终裁决：通过/拒绝/转人工 | 聚合各 Agent 结果 |
| 人工审核 Agent | 处理高风险或不确定的内容 | 人工操作界面 |
协作流程：
内容输入 → [解析 Agent] → 提取特征
→ [规则审核 Agent] → 初筛（命中敏感词 → 直接拒绝）
→ [语义审核 Agent] → 深度语义分析（疑似违规 → 高置信度）
→ [风险评估 Agent] → 综合风险评分
→ [决策 Agent]
├── 低风险（评分 <0.3）→ 自动通过
├── 中风险（0.3-0.7）→ 转人工审核
└── 高风险（>0.7）→ 自动拒绝 + 记录
关键设计： - 并行审核：规则审核和语义审核可并行，缩短端到端延迟 - 申诉机制：用户可对审核结果申诉，触发人工复审 - 持续学习：人工审核的结果反馈给语义审核 Agent，用于微调优化
Q7：[来源:书中原题][2025-04] 设计一套可插拔的工具权限管理体系
考察点
对 Agent 工具安全管控的设计能力。
解答思路
- 权限模型
- 架构设计
- 执行流程
参考答案
权限模型（RBAC + ABAC 混合）：
- 角色（Role）：用户角色（管理员、普通用户、访客）
- 工具（Tool）：每个工具定义权限需求（read-only、write、admin）
- 属性（Attribute）：时间、地点、数据范围等动态属性
架构设计：
Agent → [工具调用请求] → [权限检查中间件]
├── 角色检查：该角色是否有权调用此工具
├── 属性检查：时间/地点/数据范围是否符合
├── 配额检查：该用户今日调用次数是否超限
└── 通过 → 执行工具 / 拒绝 → 返回权限错误
可插拔设计：
class ToolPermission:
"""工具权限检查器"""
def check(self, user, tool_name, args) -> PermissionResult:
# 从策略引擎查询权限
policy = self.policy_engine.query(user.role, tool_name)
# 检查动态属性
if not self.attribute_checker.check(user, args):
return PermissionResult.DENIED
# 检查配额
if self.quota_checker.is_exceeded(user.id, tool_name):
return PermissionResult.RATE_LIMITED
return PermissionResult.ALLOWED
权限配置示例：
tools:
search:
roles: [admin, user, guest] # 所有人可用
rate_limit: 100/hour
database_write:
roles: [admin, user] # 访客不可写
rate_limit: 10/hour
require_approval: true # 高风险操作需审批
delete_user:
roles: [admin] # 仅管理员
require_approval: true
approval_level: senior # 需高级审批
Q8：[来源:小红书][2025-04] 为 Deep Research 场景设计多轮检索的停止判断逻辑
考察点
对 Agent 自主决策终止条件的设计能力。
解答思路
- 分析停止判断的维度
- 给出判断条件
- 说明边界保护
参考答案
停止判断需要满足的条件：
- 信息充分性：检索到的内容已覆盖问题的核心方面
- 用 LLM 评估：将已收集的信息与问题对比，输出"是否还需要更多信息"的判断
-
事实覆盖率：已获取的事实数量 ≥ 预期所需事实数
-
边际收益递减：连续 N 次检索未获得新的关键信息
-
新信息量 < 阈值（如最近 3 次检索获得的新事实 < 2 条）
-
置信度达标：对最终答案的置信度超过阈值
-
多个来源交叉验证同一结论
-
最大步骤保护：无论是否满足上述条件，达到最大检索轮次（如 10 轮）后强制停止
实现方式：
def should_stop(search_history, current_answer, max_rounds=10):
if len(search_history) >= max_rounds:
return True, "达到最大检索轮次"
# 边际收益检查
recent_new_facts = count_new_facts(search_history[-3:])
if recent_new_facts < 2:
return True, "边际收益递减"
# 置信度检查
confidence = evaluate_answer_confidence(current_answer, search_history)
if confidence > 0.85:
return True, "置信度达标"
return False, "继续检索"
Q9：[来源:牛客][2025-04] 设计一个企业内部知识库问答 Agent
考察点
对 RAG + Agent 系统整体架构的设计能力。
解答思路
- 需求分析
- 架构设计
- 关键优化点
参考答案
需求： 员工用自然语言提问，Agent 从企业内部知识库（Wiki、文档、邮件）中找到答案并引用来源。
架构设计：
用户提问 → [意图识别 Agent]
├── 知识问答 → [RAG Pipeline] → 混合检索 → Rerank → 生成回答
├── 数据查询 → [Text2SQL Agent] → 生成 SQL → 执行 → 解释结果
├── 操作请求 → [Tool Call Agent] → 调用内部 API
└── 闲聊/无关 → [闲聊回复]
核心模块： 1. 文档处理流水线：PDF/Word/PPT 解析 → 智能切块 → Embedding → Qdrant 向量库 2. 检索层：BM25 + 向量混合检索 + BGE-Reranker 重排 3. 生成层：带引用的回答生成，每个结论附角注引用 4. 权限过滤：基于用户部门的 metadata 过滤，只看有权限的文档
关键优化： - 增量更新：文档变更时只重新向量化变更部分 - 语义缓存：高频问题直接返回缓存 - 拒答机制：无答案时明确告知"暂未找到相关信息"而非编造
Q10：[来源:牛客][2025-04] 设计一个 Text2SQL Agent，如何解决 SQL 注入、表结构识别、复杂查询问题？
考察点
对 Text2SQL 系统安全性和可靠性的设计能力。
解答思路
- 安全防护设计
- Schema 感知方案
- 复杂查询处理
参考答案
SQL 注入防护： 1. 只读模式：数据库连接使用只读账号，禁止 INSERT/UPDATE/DELETE/DROP 2. 沙箱执行：SQL 在沙箱环境中执行，限制执行时间（如 30s）和返回行数（如 1000 行） 3. SQL 审核：生成后先经规则引擎检查（是否有子查询嵌套过深、是否全表扫描） 4. 参数化查询：将用户输入的值（如日期、名称）作为参数传入，不拼接 SQL
Schema 感知： - 动态注入：不把所有表结构放入 prompt（token 爆炸），而是用向量检索找到相关表 - 注入内容：表名、字段名、字段类型、字段注释、示例数据（每表 3-5 行） - 关系图：表之间的外键关系用简短的文本描述注入
复杂查询处理： - 自我修正循环：生成的 SQL 执行报错 → 错误信息反馈给 LLM → 修正后重试（最多 3 次） - 分步生成：复杂查询（多表 JOIN + 子查询）分步生成，先写 FROM/JOIN，再写 WHERE，最后写 SELECT - 人工审批：超过一定复杂度的 SQL（如涉及 5+ 表 JOIN）需人工确认后执行
Q11：[来源:牛客][2025-04] 设计一个客服多 Agent 系统，实现意图识别、知识库检索、工单生成、人工转接的无缝衔接
考察点
对多 Agent 协作在客服场景中的全流程设计能力。
解答思路
- 流程拆解
- Agent 设计
- 状态流转
参考答案
Agent 设计：
[意图识别 Agent]
├── 查询类 → [知识检索 Agent] → RAG 检索知识库 → 生成回答
├── 操作类 → [工单生成 Agent] → 提取关键信息 → 创建工单
└── 复杂类 → [人工转接 Agent] → 收集上下文 → 分配给合适客服
状态流转： 1. 初始：用户进线，意图识别 Agent 分类 2. 自助解答：知识库能回答 → 直接回复，询问是否满意 3. 工单创建：需要后续处理 → 工单 Agent 提取信息创建工单 4. 人工转接：用户不满意或问题超出范围 → 转人工，附带完整对话历史 5. 结束：问题解决，生成工单/对话摘要
无缝衔接关键： - 共享上下文：所有 Agent 共享同一 session 状态，无需用户重复描述 - 平滑过渡：转人工时，先告知用户"正在为您转接专业客服，请稍候"，同时向客服推送完整上下文 - 降级兜底：知识库无答案 → "这个问题比较专业，我为您转接专业客服"
Q12：[来源:牛客][2025-04] 设计一个自动化运维 Agent，实现日志读取、问题定位、命令执行、异常提醒
考察点
对运维自动化场景的 Agent 设计能力。
解答思路
- Agent 能力设计
- 安全约束
- 异常处理
参考答案
Agent 能力：
| 能力 | 工具 | 说明 |
|---|---|---|
| 日志读取 | tail -f, grep, ELK API |
读取应用和系统日志 |
| 问题定位 | 日志分析、错误模式匹配 | 识别常见错误模式 |
| 命令执行 | SSH、K8s API | 执行诊断和修复命令 |
| 监控查询 | Prometheus API、Grafana | 查询系统指标 |
| 通知推送 | Slack/钉钉 Webhook | 发送告警和报告 |
安全约束：
- 命令白名单：只允许执行预定义的命令列表
- 危险操作（如 rm -rf、DROP TABLE）完全禁止
- 修改操作需人工确认
- 所有执行记录审计日志
工作流程： 1. 监控告警触发 → Agent 接收告警信息 2. 自动诊断：读取相关日志，查询指标，定位根因 3. 生成修复方案 → 高风险操作需人工确认 4. 执行修复 → 验证结果 5. 发送报告
Q13：[来源:牛客][2025-04] 设计一个低延迟、高并发的 RAG 服务（百万级文档场景）
考察点
对大规模 RAG 系统的性能设计能力。
解答思路
- 性能瓶颈分析
- 架构优化
- 缓存策略
参考答案
核心架构：
查询 → [API Gateway] → [语义缓存检查]
├── 命中 → 直接返回缓存
└── 未命中 → [查询改写] → [混合检索] → [Rerank] → [生成回答]
性能优化：
| 环节 | 优化手段 | 目标延迟 |
|---|---|---|
| 查询改写 | 小模型（Haiku/1-3B） | <100ms |
| 混合检索 | HNSW + BM25（Elasticsearch），分片部署 | <50ms |
| Rerank | Batch 推理，GPU 加速 | <100ms |
| 生成 | 流式输出，首 token <500ms | 流式 |
并发优化： - 检索层无状态，水平扩展 - 生成层用 vLLM continuous batching - 读写分离：检索走 HNSW 读副本，写入异步同步 - CDN 缓存静态文档内容
Q14：[来源:牛客][2025-04] 从后端工程师角度，如何搭建可上线的 Agent 平台？
考察点
对 Agent 平台工程化的全局思考。
解答思路
- 核心模块
- 技术选型
- 工程化保障
参考答案
核心模块：
- Agent 运行时：LangGraph/LangChain 作为执行引擎
- 工具注册中心：统一的工具注册、描述、权限管理
- 记忆存储：短期记忆（Redis）+ 长期记忆（向量库）
- 可观测性：LangFuse 全链路 Trace + Grafana 监控
- 用户界面：Web Chat 界面 + API
技术选型：
| 层级 | 推荐 | 理由 |
|---|---|---|
| 框架 | LangGraph | 有状态图、可循环、checkpoint |
| 模型调用 | LiteLLM | 统一接口、多模型 Fallback |
| 向量库 | Qdrant | 性能好、Rust 编写、支持过滤 |
| 缓存 | Redis | 通用、支持多种数据结构 |
| 监控 | LangFuse + Grafana | Agent 专用 + 通用基础设施 |
| 部署 | Docker + K8s | 标准、可扩展 |
工程化保障： - CI/CD：每次 Prompt 或工具变更自动跑回归测试 - 灰度发布：新 Agent 版本先对 5% 用户开放 - 回滚机制：Agent 行为异常时一键回退到上一版本
Q15：[来源:牛客][2025-04] 设计多模型服务网格，实现模型的动态切换、负载均衡、健康检查
考察点
对 AI 服务基础设施的架构设计能力。
解答思路
- 服务网格架构
- 路由策略
- 健康检查
参考答案
架构：
┌─────────────────┐
Client → │ Mesh Gateway │ （统一入口、限流、鉴权）
└────────┬────────┘
┌──────┼──────┐
┌───┴──┐┌─┴───┐┌─┴───┐
│GPT-4 ││Claude││Qwen │ ← 各模型独立服务实例
└───┬──┘└─┬───┘└─┬───┘
┌───┴───┴───┐
│ Controller │ （健康检查、权重管理、熔断）
└───────────┘
动态切换策略： - 权重路由：GPT-4 60%、Claude 30%、Qwen 10% - 基于延迟：自动将请求路由到延迟最低的实例 - 基于成本：简单任务路由到便宜模型，复杂任务路由到强模型
健康检查： - 主动探测：每 30 秒向每个模型发送标准测试请求 - 判定标准：延迟 <5s、返回格式正确、内容质量达标 - 不健康实例自动摘除，流量重新分配
Q16：[来源:牛客][2025-04] 灾备设计：主模型/主服务挂了如何自动切换备用？
考察点
对高可用系统的设计能力。
解答思路
- 故障检测
- 切换策略
- 数据一致性
参考答案
故障检测：
- 健康检查端点 /health，每 10 秒探测
- 连续 3 次失败判定为不可用
- Prometheus 监控 + Alertmanager 告警
切换策略： 1. 自动切换：主服务不可用时，DNS/网关层自动将流量切到备用服务 2. 优雅降级：备用服务可能是较低规格的模型（如 GPT-4 → Qwen-Plus），需在用户界面提示 3. 自动恢复：主服务恢复后，逐步将流量切回（10% → 50% → 100%）
关键保证： - 切换过程不丢失用户会话状态（会话存储在共享 Redis 中） - 切换期间正在进行中的请求继续完成，不受影响
Q17：[来源:书中原题][2025-04] 为客服场景设计 Prompt 管理体系（补充设计）
考察点
补充 Q2 中未覆盖的方面：多语言和个性化。
解答思路
- 多语言支持
- 个性化配置
- 持续优化闭环
参考答案
多语言支持： - 每种语言独立维护 Prompt 模板，共享变量定义 - 根据用户语言偏好自动选择对应模板 - 翻译一致性：专业术语在各语言版本中保持一致
个性化配置： - 按业务线（售前/售后/技术支持）配置不同的 Prompt - 按用户等级（VIP/普通）配置不同的服务语气和优先级 - A/B 测试自动收集效果数据，辅助 Prompt 优化决策
持续优化闭环：
用户反馈 → 效果评分 → 低分案例收集 → 人工分析 → Prompt 优化 → A/B 测试 → 上线
Q18：[来源:Datawhale][2025-04] 如何为 LLM 设计特定能力（如事实性、推理能力、安全性）的评估方案？
考察点
对 LLM 专项评估的设计能力。
解答思路
- 各能力的评估维度
- 评估数据集构建
- 评估方法
参考答案
事实性评估： - 数据集：TruthfulQA、自建企业知识 QA 对 - 指标：Faithfulness（回答是否忠于检索到的上下文）、幻觉率（编造信息的比例） - 方法：LLM-as-Judge + 人工抽样验证
推理能力评估： - 数据集：GSM8K（数学）、HumanEval（代码）、BBH（大规模推理） - 指标：Pass@1、准确率、步骤正确率 - 方法：执行验证（代码题直接运行测试用例，数学题对比标准答案）
安全性评估： - 数据集：自建红队测试集（Prompt Injection、越狱、敏感信息请求） - 指标：拒绝率（正确拒绝的比例）、误杀率（合理请求被拒绝的比例） - 方法：自动化测试 + 人工审核
Q19：[来源:腾讯云][2025-05] 场景设计：用户退款请求的 Agent 处理流程
考察点
对具体业务场景的 Agent 设计能力。
解答思路
- 流程分析
- Agent 设计
- 异常处理
参考答案
流程：
用户申请退款 → [信息验证 Agent] 确认订单信息
→ [规则检查 Agent] 检查退款条件（是否在退款窗口内、商品状态）
→ [策略决策 Agent] 根据用户等级和历史记录决定退款策略
├── 符合条件 → 自动退款 → 通知用户
├── 部分符合 → 提供部分退款选项 → 用户确认
└── 不符合 → 说明原因 → 转人工
关键设计： - 信息验证：核对用户身份（订单号 + 手机号） - 规则检查：7 天无理由退款、已使用/未使用、特殊商品例外 - 异常处理：用户情绪识别（愤怒/不满 → 优先转人工），系统故障 → 记录工单后处理
Q20：[来源:书中原题][2025-04] 设计一套支持千万用户的 LLM 网关架构（补充成本分析）
考察点
补充 Q5 中未覆盖的成本优化方面。
解答思路
- 成本构成
- 优化策略
- 监控预警
参考答案
成本构成： - GPU 推理成本（60-70%） - 存储和带宽（10-15%） - API 调用费用（外部模型，15-25%）
优化策略： - 语义缓存：命中率每提升 10%，成本降低约 8% - 模型降级路由：简单任务用小模型，成本可降低 50-70% - Prompt 压缩：LLMLingua 可将 prompt 压缩 30-50%，减少输入 token - 批量推理：将多个请求合并为一个 batch，提升 GPU 利用率
监控预警： - 按用户维度统计 Token 消耗和费用 - 每日成本报表，异常增长 >20% 触发告警 - 自动预算控制：达到预算 80% 时通知，100% 时暂停服务
Q21：[来源:牛客/小红书][2026-04] LangGraph 的 StateGraph 完整执行流程是什么？Node 和 Edge 的作用分别是什么？
考察点
对 LangGraph 框架核心概念的理解，以及与传统工作流的区别。
解答思路
- 解释 StateGraph 的定义和执行流程
- 说明 Node（节点）和 Edge（边）的职责
- 对比传统 LangChain Chain 的差异
参考答案
StateGraph 的完整执行流程：
from langgraph.graph import StateGraph, END
# 1. 定义状态结构
class AgentState(TypedDict):
messages: list
current_tool: str
retries: int
# 2. 创建图
graph = StateGraph(AgentState)
# 3. 添加节点（处理逻辑）
graph.add_node("plan", plan_node) # 规划节点
graph.add_node("execute", execute_node) # 执行节点
graph.add_node("reflect", reflect_node) # 反思节点
# 4. 添加边（控制流）
graph.set_entry_point("plan")
graph.add_edge("plan", "execute")
graph.add_edge("execute", "reflect")
graph.add_conditional_edges("reflect", should_continue, {
"continue": "plan", # 循环回规划
"end": END # 结束
})
# 5. 编译
app = graph.compile(checkpointer=...)
Node（节点）： 是具体的处理单元——接收 State 作为输入，执行特定操作（调用 LLM、执行工具、处理数据），返回更新后的 State 字典。
Edge（边）： 是控制流——分为普通边（固定顺序执行）和条件边（根据 State 动态决定下一步）。条件边替代了传统 if-else 的硬编码逻辑，使流程可配置化。
与传统 Chain 的区别： Chain 是线性的（A → B → C），无法表达循环和条件分支。StateGraph 是一个有向图，支持循环（反思后回到规划）、条件分支（根据结果选择不同路径）、状态持久化（Checkpointer），更适合复杂的 Agent 流程。
加分项： 提到 LangGraph 的 interrupt_before/interrupt_after 功能可以在特定节点前后暂停执行，等待人工审批或修改 State 后再继续——这是生产级 Agent 实现 Human-in-the-loop 的关键能力。
Q22：[来源:牛客/小红书][2026-04] 用 LangGraph 如何实现多 Agent 协作？Agent 之间如何通信？
考察点
对 LangGraph 框架中 Multi-Agent 架构的设计能力。
参考答案
LangGraph 实现 Multi-Agent 的核心思路： 每个 Agent 是一个子图（SubGraph），主图通过节点调用子图，实现 Agent 间的编排。
架构示例：
┌─────────┐
│ Router │ (路由 Agent)
└────┬────┘
┌──────────┼──────────┐
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│Research│ │ Code │ │ Math │ (专业 Agent 子图)
│ Agent │ │ Agent │ │ Agent │
└────────┘ └────────┘ └────────┘
└──────────┬──────────┘
▼
┌─────────┐
│Synthesizer│ (汇总 Agent)
└─────────┘
通信机制：
- 通过 State 通信： 所有 Agent 共享同一个 State 对象（如 messages: list、results: dict），每个 Agent 读取和修改 State 中的字段
- 通过消息传递： 每个 Agent 的输出追加到 messages 列表，下一个 Agent 读取前一个的输出作为输入
- 通过工具结果： 一个 Agent 的结果作为工具返回值传递给另一个 Agent
关键设计：
# 主图调用子图（Multi-Agent）
graph.add_node("research_agent", research_subgraph)
graph.add_node("code_agent", code_subgraph)
graph.add_conditional_edges("router", route_to_agent, {
"research": "research_agent",
"code": "code_agent",
"math": "math_agent"
})
生产实践建议： 当 Agent 间依赖强时用 StateGraph（共享状态）；当 Agent 完全独立时用 Multi-Agent 框架（如 CrewAI、AutoGen），通过 API 或 A2A 协议通信。
Q23：[来源:知乎/牛客][2026-04] Agent 的记忆系统如何设计？跨会话记忆怎么实现？记忆污染怎么防止？
考察点
对 Agent 记忆系统的完整设计能力，涵盖短期记忆、长期记忆、跨会话持久化和数据质量控制。
解答思路
- 设计多层记忆架构
- 说明跨会话存储方案
- 解释记忆污染的成因和防护
参考答案
多层记忆架构：
┌──────────────────────────────────────┐
│ 第 1 层：工作记忆（Working Memory） │
│ 存储：当前对话的最近 N 轮 │
│ 位置：内存 / 上下文窗口 │
│ 生命周期：会话结束即清除 │
├──────────────────────────────────────┤
│ 第 2 层：会话摘要（Session Summary） │
│ 存储：每轮对话结束后的压缩摘要 │
│ 位置：Redis / 轻量 DB │
│ 生命周期：30 天 │
├──────────────────────────────────────┤
│ 第 3 层：长期记忆（Long-term Memory） │
│ 存储：用户画像、偏好、关键事实 │
│ 位置：向量数据库（Milvus/Qdrant） │
│ 生命周期：持久化，用户可管理 │
└──────────────────────────────────────┘
跨会话记忆实现： - 用户再次对话时，先从第 2 层加载最近 N 次会话的摘要，注入到 system prompt - 从第 3 层向量库中检索与当前问题相关的历史记忆，按需加载 - 使用用户 ID 作为记忆的分片 Key，实现用户级记忆隔离
记忆污染防止：
- 写入过滤： 不是所有对话都写入长期记忆。只在对话中明确提取事实时才写入（如"我喜欢用 Python" → 提取 user.language_preference = "Python"）
- 去重机制： 新记忆写入前与已有记忆做语义相似度比对，相似度 >90% 的更新而非新增
- TTL 过期： 为记忆设置过期时间，过时信息自动失效
- 置信度评分： 每条记忆附带置信度（来源可靠性、冲突检测结果），低于阈值的记忆不参与检索
Q24：[来源:牛客][2026-04] ACP（Agent Communication Protocol）协议的设计思路是什么？它和 MCP 是什么关系？
考察点
对新兴 Agent 通信协议的理解，以及协议选型的分析能力。
参考答案
ACP 的设计思路： 是专门为 Agent 间通信设计的协议，选择 REST 作为底层传输协议（而非 gRPC 或 WebSocket），核心理念是简单、通用、易于调试。
ACP vs MCP 的关系：
| 维度 | MCP | ACP |
|---|---|---|
| 目标 | 工具服务与 AI 应用的集成 | Agent 之间的对等通信 |
| 传输层 | stdio + SSE | REST (HTTP) |
| 通信模式 | Client-Server | Agent-to-Agent |
| 发现机制 | tools/list | Agent 注册中心 |
| 适用场景 | 应用内工具管理 | 跨服务 Agent 协作 |
ACP 选择 REST 而非 gRPC 的考量： - 优势： 通用性极强（任何语言都能调用）、调试简单（curl 即可测试）、防火墙友好（标准 80/443 端口）、生态成熟（API 网关、监控、限流等工具链完善） - 劣势： 相比 gRPC 序列化效率低、不支持双向流式传输、无内置服务发现
生产实践建议： 如果 Agent 之间在同一个组织内部、对延迟要求极高，gRPC 更合适；如果需要跨组织、跨网络的 Agent 通信，REST 的通用性优势大于性能损失。
Q25：[来源:知乎/牛客/小红书][2026-04] Agentic RAG 与传统 RAG 的差别是什么？
考察点
对 RAG 技术前沿演进的理解，以及 Agent 思维在检索中的应用。
参考答案
传统 RAG 的局限： 一次查询 → 一次检索 → 一次生成。如果检索结果不好，无法自适应调整。
Agentic RAG 的核心差异： 将 Agent 的"思考-行动-观察"循环引入 RAG，使检索过程智能化、自适应、可迭代。
关键能力差异：
| 能力 | 传统 RAG | Agentic RAG |
|---|---|---|
| 查询处理 | 直接使用用户输入 | Agent 先改写查询（Query Rewriting） |
| 检索策略 | 固定的一次检索 | 多轮迭代检索，根据结果调整 |
| 结果判断 | 直接生成答案 | Agent 评估结果质量，不足则继续检索 |
| 工具使用 | 仅向量检索 | 可调用多种工具（搜索引擎、API、数据库） |
| 冲突处理 | 直接拼接上下文 | Agent 分析冲突，选择最可信来源 |
Agentic RAG 的执行流程：
用户问题 → Agent 分析问题类型
→ 决定检索策略（向量检索 / 搜索 / API）
→ 执行检索
→ 评估结果质量（是否足够回答问题？）
→ 如果不够：改写查询，换策略再次检索
→ 如果冲突：分析来源可信度，选择最可靠信息
→ 基于最终检索结果生成答案
生产价值： 在复杂问答场景（如"对比 A 和 B 的最新差异"）中，Agentic RAG 的准确率比传统 RAG 提升 20-40%，但延迟也增加 2-3 倍。适合对准确率要求高、对延迟容忍的场景。
Q26：[来源:小红书][2026-04] RAG 项目中怎么做召回闭环？如何让系统越用越准？
考察点
对 RAG 系统效果持续优化和数据闭环的设计能力。
参考答案
召回闭环的核心： 建立"用户反馈 → 效果评估 → 策略调整"的数据飞轮。
闭环设计：
用户提问 → RAG 返回答案
→ 用户行为采集（点赞/踩/重新提问/会话结束）
→ 每周自动收集"踩"的问题和未解决问题
→ 标注团队审核，建立黄金 QA 数据集
→ 用黄金数据评估当前 RAG 的检索准确率
→ 分析失败原因（检索不准？回答跑偏？知识缺失？）
→ 针对性优化（调整 chunk 策略？更新 Embedding？补充文档？）
→ 回归测试，确认效果提升
关键指标追踪： - 检索侧： Hit Rate@5、MRR（平均倒数排名） - 生成侧： Faithfulness（忠实度）、Answer Relevancy（答案相关性） - 业务侧： 用户满意度（点赞率）、重复提问率、转人工率
让系统越用越准的具体做法： 1. 自动收集困难样本： 用户"踩"了答案、重新提问或转人工的问题 2. 定期标注： 每周由领域专家对这些问题的正确答案进行标注 3. 离线评估： 用标注数据评估当前系统的 RAGAS 指标 4. A/B 测试： 优化后上线 A/B 实验，对比新旧版本的用户满意度 5. 知识更新： 根据失败案例，补充缺失的文档到知识库
Q27：[来源:小红书][2026-04] 为 Deep Research 场景设计多轮检索的停止判断逻辑
考察点
对 Agent 在自主研究场景中如何判断"信息已足够"的设计能力。
参考答案
核心挑战： Agent 不停检索会消耗过多 token 和时间，过早停止又会遗漏关键信息。
停止判断的多维度决策：
def should_stop_retrieval(state):
# 1. 信息饱和度：新检索结果与已有信息的重叠度
if state.new_info_ratio < 0.1: # 新信息占比 <10%
return True
# 2. 答案完整度：是否已覆盖问题的所有关键方面
if state.answer_coverage(state.question, state.findings) >= 0.8:
return True
# 3. 置信度：Agent 对当前答案的自信程度
if state.confidence_score >= 0.9:
return True
# 4. 轮次上限：防止无限循环
if state.retrieval_rounds >= 5:
return True
# 5. Token 预算：上下文窗口使用率
if state.total_tokens > max_context * 0.8:
return True
# 6. 时间预算：总耗时超过限制
if state.elapsed_time > 60: # 60秒
return True
return False
信息饱和度计算： 每轮检索后，计算新结果与已有信息的语义相似度。如果 >80% 的新结果都是重复的，说明已经接近信息饱和。
答案完整度： 将用户问题拆解为关键子问题（如"苹果公司 2025 年财报" → 营收、利润、增长率、业务分部），检查每个子问题是否有对应信息支撑。
Q28：[来源:小红书/牛客][2026-04] 设计一个企业级 Agent 系统，需要考虑哪些核心要点？
考察点
对 Agent 系统从原型到生产级的全面架构设计能力。
参考答案
企业级 Agent 系统的 10 个核心维度：
1. 安全与权限： - 工具调用基于用户权限，而非 Agent 权限（用户 A 不能通过 Agent 访问用户 B 的数据） - Prompt Injection 防御（输入过滤 + 输出验证） - 敏感操作需要人工审批（Human-in-the-loop）
2. 可靠性与容错： - 工具调用超时重试（指数退避，最多 3 次） - 模型 API 降级切换（主模型挂了切备用模型） - 死循环检测与自动终止
3. 可观测性： - 完整的 Trace 链路（请求 → 规划 → 工具调用 → 响应） - 关键指标监控（延迟、Token 消耗、成功率、工具调用频率） - LangSmith/LangFuse 等工具的集成
4. 成本控制： - 语义缓存减少重复 LLM 调用 - 多模型调度（简单任务用小模型） - Prompt 压缩
5. 记忆与上下文： - 多层记忆架构（短期/长期） - 跨会话记忆加载 - 记忆过期和冲突管理
6. 知识管理： - RAG 知识库的增量更新 - 文档版本控制 - 权限隔离（不同部门的知识库隔离）
7. 性能： - 流式输出降低感知延迟 - 并行工具调用 - 预加载常用上下文
8. 扩展性： - 插件化架构（新工具通过 MCP Server 接入） - 多 Agent 协作（通过 A2A 协议） - 水平扩展（无状态服务 + 外部状态存储）
9. 合规与审计： - 完整的执行日志（不可篡改） - 数据保留和销毁策略 - GDPR/个人信息保护法合规
10. 测试与评估： - 黄金 QA 数据集 - 自动化回归测试 - A/B 实验平台