标签题目
系统设计相关面试题第 2 页
MCP 的传输层有哪些方式,stdio 和 Streamable HTTP 分别适合什么场景?
这题考 MCP 的通信协议和传输层取舍,回答重点是 MCP 定义的是客户端、服务器和工具的上下文协议,传输上要区分本地 stdio、当前远程 Streamable HTTP,以及旧 HTTP+SSE 的历史或兼容语境。
LLM 推理中 Continuous Batching 和 Prefix Caching 如何影响请求切分、batch 维度和吞吐/延迟取舍?
这题考 LLM 推理调度中的 Continuous Batching 和 Prefix Caching,回答重点是请求在 prefill/decode 阶段如何切分、按什么维度组 batch,以及吞吐和延迟如何取舍。
有一个状态机模型时,如何设计状态、转移、异常路径和覆盖率测试?
这题考状态机测试的建模能力。高质量答案要先把状态机拆成状态、事件、转移、守卫条件和动作,再说明如何覆盖正常路径、非法转移、异常恢复、并发和持久化一致性,最后用覆盖矩阵和运行证据证明测试有效。
推理优化中为什么常把动态图转成静态图再做算子融合,转换开销如何评估和控制?
这题考动态图和静态图在推理优化中的取舍,重点是静态图提供全局依赖、shape、pattern 和内存信息,便于融合和调度优化;转换开销要靠缓存、shape bucketing、warmup、fallback 和端到端摊销控制。
AI Coding 落地时,如何给模型提供有效仓库上下文,并限制它触碰事务、权限、资金等高风险链路?
这题考 AI Coding 的上下文工程和风险边界。答案要同时讲清如何给模型足够信息完成任务,以及如何通过范围控制、权限控制、测试和 review 防止它碰坏核心链路。
AI 生成代码进入工程仓库前,如何用沙箱分支、最小改动范围、测试和 review 防止污染主分支?
这题考 AI 生成代码的分支治理和合入门禁。优秀回答要把主分支保护、沙箱隔离、diff 范围、自动化检查、人工 review、回滚审计串成一条工程流程。
生产级 RAG 为什么可以用 Java 承担后端主链路,而不是全链路都用 Python?
这题考 RAG 从实验脚本到生产服务的语言和架构取舍。核心不是贬低 Python,而是说明在线主链路需要服务治理、稳定性、并发、权限和工程生态,Java 可以承担这些职责。
高风险在线环境中的 Agent 异常管控体系应如何设计,覆盖权限分级、执行隔离、熔断止损和审计追踪?
这题考的是高风险在线 Agent 的工程治理能力,重点不是说模型更聪明或加人工确认,而是把权限、工具、执行环境、熔断止损、可观测性和审计恢复设计成一套闭环。
RAG 外部知识库分片过大时,如何重新切分、保留语义边界并控制召回噪声?
这题考 RAG 知识库切分的工程细节,重点是说明分片过大会稀释 embedding、挤占上下文、引入噪声,并给出递归切分、层级索引、元数据继承、召回重排和回归评测方案。
同题还出现在 1 个公司岗位
公开群聊搜索排序如何设计,如何结合群名称/内容相关性、活跃度、用户兴趣、质量安全和多样性信号决定排名?
这题考搜索排序系统设计:候选人要能从召回、相关性、质量安全、个性化、多样性和评估指标出发,设计公开群聊搜索的排名策略。
给定群聊数据表,如何为公开搜索排序设计群聊特征提取系统,并从 UID、群主、兴趣、活跃度等字段构建可用特征?
这题考特征工程和数据系统设计:要能把原始群聊表变成可供搜索排序使用的群、用户、群主、兴趣、活跃度、质量和实时特征,并保证一致性、可解释性和可监控。
Agent 的计划模式是什么?如何把用户目标拆成步骤、工具调用和可恢复执行状态?
这题考 Agent 运行机制:计划模式不是让模型多想一会儿,而是把开放目标转成可执行、可观测、可重试、可恢复的任务状态机或工作流。
同题还出现在 1 个公司岗位
Agent 调用服务端 API 工具的完整流程是什么?如何完成参数生成、鉴权、执行、错误处理和结果回填?
这题考 Agent 工具调用的工程链路:模型通常不直接访问业务 API,而是由宿主系统基于工具 schema、权限、参数校验、执行器、错误处理和结果回填来完成闭环。
同题还出现在 2 个公司岗位
Agent 的 thinking 阶段如何判断该调用工具还是直接回复,如何设计决策信号和安全约束?
这题考的是 Agent 运行时决策设计:候选人要能说明什么时候直接回答、什么时候调用工具、什么时候追问,以及如何用置信度、权限、安全和回归评估约束决策。
同题还出现在 1 个公司岗位
MCP、Function Call 和 A2A 在 Agent 系统中分别解决什么边界,如何协同?
这题考 Agent 系统的协议和责任边界。Function Call 解决模型到宿主工具调用意图的结构化表达,MCP 解决宿主和外部工具/资源服务之间的标准化连接,A2A 解决 Agent 与 Agent 之间的任务委托和协作。三者层级不同,不能混成同一个概念。
RAG 为什么要引入父子索引,如何兼顾小粒度召回和大粒度上下文回填?
这题考的是 RAG 检索粒度设计:小 chunk 更容易被向量或关键词召回命中,但单独放进上下文时可能缺少标题、章节、定义、前提和表格上下文;父子索引用子块做高精度召回,用父文档或父章节做证据回填,从而兼顾召回命中率、答案可读性和上下文预算。
RAG rerank 后 TopK 与上下文长度预算如何选择,过短或过长时怎么处理?
这题考的是 rerank 之后的证据选择策略:TopK 不是固定返回几个 chunk,而是在相关性、证据覆盖、去重多样性、父子扩展、token 预算、模型长上下文能力、延迟成本和拒答策略之间做动态取舍。
Spring AI Alibaba Graph 的底层原理是什么,图式编排如何表达 Agent 节点、状态流转、条件分支和工具调用?
这题考察对图式 Agent 编排的理解,重点是状态、节点、边、条件路由、工具调用、失败处理和可测试性,而不是背某个版本的 API。
大模型训练中的 3D 并行和 DeepSpeed 分别解决什么问题,如何组合使用?
这题考的是大模型训练系统的分解能力:3D 并行解决模型和计算如何切到多卡上,DeepSpeed 提供 ZeRO、混合精度、checkpoint、offload 和并行编排等工程能力,两者可以组合但不是同一个概念。
生产级 RAG 的数据解析与入库流水线如何设计,如何处理 PDF、DOCX、表格、图片和多格式文档?
生产级 RAG 的数据解析与入库流水线应从文件接入、格式识别、内容解析、结构保留、规范化切分、embedding、索引落库、权限和质量监控全链路设计。PDF、DOCX、表格、图片、Markdown、TXT 和富文本的解析策略不同:PDF 要区分数字文本和扫描件,DOCX 要保留标题层级和表格,表格要理解 sheet、表头和单元格关系,图片要 OCR 或生成视觉描述,多格式文档要保留统一的 document、section、chunk 和 asset 元数据。入库侧要支持幂等、版本、增量更新、失败重试、死信队列、ACL 过滤、向量库和关键词索引协同,以及可回溯的解析证据。
GraphRAG 中 local、global、混合检索和社区检索分别如何工作,适合什么问题?
这题考的是候选人是否理解 GraphRAG 不是单一检索方法,而是一组利用实体、关系、社区和文本证据组织上下文的策略:local 偏实体邻域,global 偏全局主题,社区检索偏聚合摘要,混合检索负责把图和文本召回结合起来。
ReAct 的思考-行动-观察循环如何驱动 Agent 工具调用,和普通 CoT 有什么区别?
这题考的是候选人是否理解 ReAct 把模型推理和外部行动交织起来:模型不是一次性输出答案,而是在思考、选择工具、观察结果、继续推理的闭环中逐步完成任务;它和普通 CoT 的关键区别是能通过工具调用改变外部状态并用真实观察修正推理。
RAG 中既然向量检索已经计算相似度,为什么还需要 Cross-Encoder 重排?
这道题考察 RAG 检索链路中双塔向量召回和 Cross-Encoder 重排的职责边界。好的回答要说明向量检索适合在大规模语料上做低成本粗召回,但它把 query 和文档分别编码,主要比较全局语义相似度,难以精细判断短语匹配、否定关系、字段约束、时效和答案可用性。Cross-Encoder 把 query 与候选片段一起输入模型,可以做 token 级交互和上下文相关判断,因此通常用于小候选集精排。回答还应覆盖成本、延迟、候选规模、失败模式、评估指标和何时不需要重排。
向量数据库检索到语义相关但时间过久的历史信息时,RAG 系统应如何判断能否使用?
这道题考察 RAG 系统面对“语义相关但时间过久”的向量检索结果时,如何把相关性判断升级为证据可用性判断。回答要说明不能只看 embedding 分数,而要结合问题的时效敏感度、文档时间戳、版本、生效范围、来源权威性、与新证据的冲突情况和业务风险来决定使用、降权、补检、拒答或提示不确定。好的方案还要覆盖元数据过滤、时间衰减、动态检索、冲突检测、评估指标和上线监控。
RAG 什么时候只用静态知识库,什么时候需要接入动态网页检索?
这道题考察 RAG 检索源选择和系统边界设计。回答要说明静态知识库适合权威、可治理、更新频率低或组织受控知识,优势是稳定、可审计、低延迟、低风险;动态网页检索适合新闻、政策、价格、版本、故障状态、市场信息等变化快且静态库无法覆盖的问题,优势是新鲜度和覆盖面。高质量回答应给出 query 路由、混合检索、来源可信度、成本延迟、安全合规、冲突处理、引用和评估方案,而不是简单说“静态不够就联网”。
VikingDB 这类向量数据库如何设计核心链路,向量写入、ANN 索引、元数据过滤和查询召回如何协同?
这道题考察对向量数据库核心链路的系统设计能力,而不是背某个产品未公开实现。回答要从写入、向量化、分片、持久化、ANN 索引构建、增量更新、元数据过滤、查询召回、重排和运维指标串起来,说明向量、原始文档、元数据和索引如何保持一致。关键是讲清近似召回与过滤条件的协同:先过滤、后过滤、混合过滤各有什么代价;写入与索引的实时性、删除更新、分布式扩展、一致性和评估指标如何设计。
如果项目要基于 Claude Code 这类现成 Agent 做领域适配,如何设计数据边界、工具接入、RAG、评测和监控?
这道题考察如何把现成 Coding Agent 或通用 Agent 平台做成某个业务域可用的工程系统。回答不能停留在“加提示词”或“接几个工具”,而要围绕数据边界、权限隔离、工具契约、领域知识 RAG、任务流程、评测集、灰度发布、监控和人工接管设计。重点是让通用 Agent 只在授权数据和明确工具能力内行动,用可回放、可评测、可审计的方式逐步扩大自主能力。
在现有 LangGraph Agent 上新增功能时,如何设计节点、边、state schema、工具注册和回归测试?
这题考的是把 Agent 功能扩展做成可维护的状态机工程,而不是在一个大 prompt 或一个大节点里继续堆逻辑。高质量回答应说明如何先界定新功能的触发条件和输出契约,再决定是否新增节点、边、state 字段和工具,并用可回放测试证明新增路径没有破坏原有 Agent 行为。
当 Agent 有 100 个 Tool 时,如何做工具分组、动态子集检索、schema 治理、监控和 meta-tool/Skill 收口?
这题考的是大规模工具接入后的 Agent 治理能力。100 个 Tool 不能简单全部塞进模型上下文,否则会带来选择混乱、token 成本、schema 冲突、误调用和监控不可解释。好的回答应从工具分类、检索式候选集、契约治理、调用观测和能力收口几层展开。
同题还出现在 1 个公司岗位
文本搜图场景如何设计图片搜索系统,让用户搜“小狗”时能召回包含小狗的图片?
文本搜图系统要让用户输入“小狗”时召回包含小狗的图片,核心不是只按文件名搜索,而是建立图片内容理解、文本语义表示、索引召回和排序评估的完整链路。图片侧需要离线或实时提取对象标签、检测框、caption、OCR、视觉向量和多模态向量;查询侧需要把文本解析成语义向量和关键词;召回侧结合倒排索引、向量检索和元数据过滤;排序侧再按语义匹配、对象置信度、图片质量和用户意图重排。
Agent 中 Function Call、MCP 和 Skill 的工具描述上下文占用有什么差异,如何降低 token 成本?
这道题考察对 Agent 工具接入方式和上下文成本的工程理解。好答案要区分 Function Call 是模型请求内的工具 schema,MCP 是客户端和外部工具服务器之间的协议,Skill 是把说明、脚本和资源按能力打包并按需加载的机制。回答不能简单说 MCP 一定比 Skill 大,而要说明上下文占用取决于客户端暴露了多少工具描述、schema 是否冗长、是否做动态路由和懒加载。高质量答案还应给出降低 token 成本的方法,包括工具分层、候选工具筛选、描述压缩、结果引用、prompt caching 和按任务加载。
开发 MCP 服务时,如何设计 resources/tools/prompts、输入输出 schema、权限和可观测性?
这道题考察的是 MCP 服务的能力建模和治理能力,而不是会不会写一个 HTTP endpoint。好答案要从 resources、tools、prompts 三类能力暴露开始,定义清晰的输入输出 schema、权限和错误语义,再补上发现机制、版本兼容、超时重试、可观测性、回放和审计,保证 Agent 能安全、稳定、可追踪地使用 MCP 服务。
如何设计 AI 模型调用缓存,避免相同输入重复推理,同时控制一致性、过期和成本?
这道题考 AI 服务缓存设计。重点是缓存边界、key 设计、模型版本、prompt 参数、语义相似缓存、过期策略、隐私隔离和命中率评估。
MCP 接入多个测评工具时,如果不同工具对同一问题返回格式不统一,应该如何设计统一输出协议或适配层?
这题考 MCP 多工具输出治理。多个 MCP 工具返回格式不统一时,应在工具和 Agent Runtime 之间加适配层,统一 envelope、内容块、结构化数据、错误协议、元数据、版本和审计,而不是让模型解析各类私有格式。
超大模型部署到计算集群时,如何按计算图切分并做分布式模型管理?
这题考超大模型部署系统设计。关键是把模型表示为计算图,按依赖、内存、计算量、通信和 SLA 做图切分与设备放置,再用分布式模型管理处理分片版本、加载、路由、健康检查、灰度和回滚。
Agent 开发框架通常由哪些核心组件组成,Planner、Memory、Tools、Executor 和 Evaluator 分别负责什么?
这题考察候选人是否能把 Agent 从“调用大模型的应用”拆成可工程化的运行系统。好的回答应说明 Planner 负责把目标拆成步骤,Memory 负责保留和检索上下文,Tools 负责连接外部能力,Executor 负责按计划执行并处理状态,Evaluator 负责判断结果质量和是否需要重试、修正或终止。重点不是背组件名,而是讲清楚组件之间的数据流、控制流、失败兜底和可观测性。
Agent Skill 如何用渐进式披露按需加载能力说明、执行步骤和工具细节?
这题考察 Agent Skill 的核心机制,以及如何通过渐进式披露降低上下文负担。Skill 不是简单工具函数,而是一组可被 Agent 发现、选择和执行的能力包,通常包含能力说明、适用条件、输入输出、执行步骤、工具依赖和失败处理。渐进式披露的关键是先暴露轻量索引和选择信号,只有命中时再加载详细说明、示例和执行细节。
多工具 Agent 如何设计工具选择与调用调度链路,并在超时、参数错误或工具失败时做 fallback?
这题考察多工具 Agent 的工程调度能力。好的回答不能停在“让模型选择工具”,而要说明工具注册、候选召回、参数生成、权限校验、执行编排、状态记录、错误分类和 fallback 策略。面试官重点看你是否能把不稳定的 LLM 工具调用变成可观测、可恢复、可降级的业务链路。
AI 服务中的多模型降级与熔断机制如何设计,怎样定义异常、状态流转和自动恢复条件?
这题考察 AI 服务后端的稳定性设计。多模型降级和熔断不是简单把模型 A 挂了切到模型 B,而要定义异常、统计窗口、状态机、路由策略、自动恢复和质量兜底。好的回答要覆盖可用性、质量、成本、延迟、限流、观测和安全边界。
Agent 工具服务为什么要独立部署并注册到 Nacos,而不是直接用 MCP 暴露工具?
这题考 Agent 工具服务的工程化部署边界:Nacos 解决服务发现和治理,MCP 解决模型侧工具协议,二者不是同一层能力,不能简单互相替代。回答时要强调在已有微服务治理体系下,Nacos 更适合管理真实工具服务的实例、健康、配置和流量,MCP 更适合统一工具契约、schema 和 Agent 侧调用方式。
大模型反欺诈项目从开发、测试到部署应如何设计流程,Agent 框架选型需要关注哪些工程约束?
这题考大模型反欺诈项目的端到端工程化能力,不是只问“用了哪个 Agent 框架”。高质量回答要从业务边界、数据合规、Agent 工具链、离线评测、测试门禁、灰度部署、监控回流和框架选型约束讲清楚,体现反欺诈场景对准确性、可解释性、安全和稳定性的要求。
MCP 在 Agent 工具接入中解决什么问题,适合哪些场景,又有哪些落地边界?
这题考 MCP 在 Agent 工具接入中的协议价值和工程边界。高质量回答要说明它解决的是 Agent 与外部工具、资源、提示模板之间的标准化连接问题,并能覆盖工具发现、resources/tools/prompts、schema、跨进程接入、权限、审计、超时、版本和服务治理。
视频剪辑智能体的全链路架构如何设计,核心模块的职责和交互逻辑是什么?
这道题考察 AI 应用开发候选人能否把“视频剪辑智能体”设计成可落地的工程系统:从用户意图理解、素材解析、剪辑计划、工具执行、预览修正到渲染导出,拆清楚核心模块、数据结构和交互闭环。
对接多家国内大模型官方 API 时,如何设计统一调用网关来屏蔽接口差异?
这题考察的是多大模型供应商接入时的工程抽象能力,不是简单写几个 if else 适配接口。好的统一调用网关要把业务层看到的协议收敛成稳定的内部模型契约,同时把供应商差异隔离在 adapter 层:消息格式、模型名、参数范围、流式协议、错误码、限流、鉴权、计费、上下文长度、工具调用、JSON 输出能力都不能泄漏给上层。架构上通常分为统一 API、路由与策略、provider adapter、可靠性治理、观测与审计、配置和灰度几个部分。回答要强调边界:网关不是只做转发,而是承担能力抽象、故障隔离、降级切换、成本治理和可观测性;但也不能把所有模型能力抹平成最低公约数,否则会损失模型特性。因此设计上要有基础统一契约和可扩展 capability 描述,既屏蔽常见差异,又允许业务显式选择高级能力。
用 LangChain 编排 AI 工作流时,如何和原生调用、自研引擎做选型,并分析各自优缺点和瓶颈?
这题考察的是 AI 工作流编排的技术选型,而不是问 LangChain 好不好。高质量回答要先拆清楚业务复杂度:只是单轮模型调用、少量 prompt 链、RAG 检索增强、工具调用、长流程状态机、多 Agent 协作,还是需要可视化编排、回放、权限、灰度和审计。原生调用的优势是简单、可控、性能和依赖风险低,适合链路短、业务稳定、团队希望自己掌握协议的场景;LangChain 的优势是生态组件多、原型快、抽象现成,适合探索期和标准 RAG/Tool/Agent 流程,但瓶颈是抽象层厚、版本变化、调试复杂、性能和可观测性需要补强;自研引擎适合业务流程复杂、稳定性和治理要求高、需要平台化复用的场景,但成本高、周期长,容易重复造轮子。最终选型不是三选一的宗教问题,而是按阶段演进:原型期可以用框架提速,核心生产链路要收敛成自己的稳定接口和可观测执行模型。
在推荐系统中,双塔召回和精排在候选规模、特征复杂度、实时性和准确率上有什么差异?为什么精排通常更准,双塔如何支持用户侧向量实时更新?
这道题考察推荐系统召回与精排的职责边界。好的回答要解释双塔为什么适合大规模向量召回,精排为什么通常更准,以及用户侧向量实时更新如何工程落地。
AI/自动化 Agent 平台如何结合 Jenkins 调度执行、Linux 日志采集解析和配置规则治理,实现状态回传、参数校验,并从拉日志演进到自动排障?
这题考 AI/自动化 Agent 平台的工程落地能力,重点是 Jenkins 调度、Linux 多机日志采集、配置规则治理、状态回传、参数校验,以及从拉日志工具演进到自动诊断和受控排障的路线。
主流 Agent 框架如何选型,如何按 RAG 检索、有状态工作流、多 Agent 协作、工具/记忆/检索能力和自主性与可控性边界做取舍?
这题考 Agent 框架选型边界,而不是背框架名。好的回答应按业务需要拆分:RAG 检索优先看数据索引和检索评估,有状态工作流优先看可控状态机,多 Agent 协作优先看角色协议和收敛性,工具、记忆、检索抽象要看边界清晰度,最终在 Agent 自主性和工程可控性之间取舍。