校招未知部门 / 算法 / 一面

[面试日期] 2026-09-28 [面试时长] 未知

[学校背景] 电子科技大学 | 985 [学历背景] 未知

[发布人] 面试之星官方收录

<h2>宏图智能一面</h2> 1agent调用tool的原理2tool.cli，mcp的区别3mcp的原理。4spring mvc的理解5er图怎么设计6数据库优化慢查询下附鲸鱼娘解析1. Agent 调用 Tool 的原理Agent 调用 Tool 的核心机制是 Function Calling（函数调用）。LLM 本身并不能直接执行外部代码或访问数据库，它的角色是决定何时调用、调用哪个工具、传递什么参数，然后由你的应用程序代码去实际执行这个函数。完整的工作流程如下：<ol><li>定义工具：开发者在调用 LLM API 时，通过 JSON Schema 描述可用函数的名称、功能和参数结构。</li><li>模型决策：模型接收到用户请求后，结合对话上下文，自主判断是否需要调用工具。如果需要，模型不会直接输出自然语言回答，而是返回一个结构化的函数调用请求，包含函数名和参数。</li><li>代码执行：你的应用程序（Agent 框架）解析这个结构化请求，在本地或远程实际执行对应的函数（如查询数据库、调用 API）。</li><li>结果回传：函数执行结果被返回给模型，模型基于这个结果生成最终的、有依据的回答（grounded response）。</li></ol>以微软的示例为例，当用户问“现在几点了”，模型识别出需要调用 <code>get_time</code> 函数，返回函数调用请求后，由外部代码执行 <code>get_time()</code>，再把时间结果传回模型，模型据此生成最终回答。<h3>2. Tool、CLI、MCP 的区别</h3>这三者处于 Agent 工具生态的不同层次：<table><tbody><tr><td>层次</td><td>能力层：模型决定调用什么</td><td>执行层：直接操作命令行</td><td>协议层：标准化连接外部工具与数据源</td></tr><tr><td>通信方式</td><td>模型返回结构化 JSON</td><td>启动子进程，传递命令行参数</td><td>JSON-RPC over 持久连接</td></tr><tr><td>适用场景</td><td>模型内嵌的轻量工具调用</td><td>本地、快速、零开销的任务（内循环）</td><td>外部系统、共享基础设施、需要结构化权限管理的场景（外循环）</td></tr><tr><td>成本</td><td>取决于模型 API 调用</td><td>极低，零 schema 开销</td><td>较高，需维护服务器和协议开销</td></tr><tr><td>安全性</td><td>由应用层控制</td><td>依赖 shell 权限</td><td>集中式认证和权限控制</td></tr></tbody></table>关键区别：<ul><li>CLI 适合内循环场景（inner loop），特点是快速、本地、零开销。Agent 通过命令行直接操作已有工具，不需要额外的协议层。</li><li>MCP 适合外循环场景（outer loop），提供集中式认证、工具发现和结构化 JSON 交互。MCP 服务器保持连接状态，而不是像 CLI 那样每次命令都启动新进程。</li><li>性能差异：在相同后端工具条件下，CLI 的 token 效率比 MCP 高约 33%，MCP 的运行成本在某些场景下可达 CLI 的 5 到 28 倍。</li><li>选择建议：对于快速变化或轻量封装的工具，CLI 维护成本更低；对于需要版本化接口、多用户共享的企业级场景，MCP 的投入更值得。</li></ul><h3>3. MCP 的原理</h3>MCP（Model Context Protocol）是一个开放协议，用于标准化 AI 应用与外部工具、数据源之间的集成。架构：MCP 采用 Host-Client-Server 架构：<ul><li>Host：宿主应用（如 Claude Desktop、IDE），负责创建和管理多个客户端实例，控制连接权限，协调 AI/LLM 集成和上下文聚合。</li><li>Client：由 Host 创建，每个 Client 与一个 Server 建立一对一的隔离连接，负责协议协商、消息路由和订阅管理。</li><li>Server：提供专门的能力，通过 MCP 原语暴露资源（Resources）、工具（Tools）和提示（Prompts）。Server 可以是本地进程，也可以是远程服务。</li></ul>通信基础：MCP 基于 JSON-RPC 2.0，提供一个有状态的会话协议，专注于客户端与服务器之间的上下文交换和采样协调。安全设计原则：Server 只能看到必要的上下文信息，无法读取完整对话历史，也无法“看到”其他 Server。Host 进程强制执行安全边界。能力协商：在会话初始化时，客户端和服务器通过能力协商系统明确声明各自支持的功能，确保双方在会话期间遵守已声明的能力范围。<h3>4. Spring MVC 的理解</h3>Spring MVC 是一个基于 MVC 设计模式的 Web 框架，核心是 DispatcherServlet（前端控制器）。核心组件：<ul><li>DispatcherServlet：Spring MVC 的“心脏”，所有请求的入口点，负责协调各个组件完成请求处理并返回响应。</li><li>HandlerMapping：维护 <访问路径, 处理器> 映射，为请求找到合适的 Controller。</li><li>HandlerAdapter：负责实际调用处理器方法。</li><li>ViewResolver：将逻辑视图名解析为具体的 View 对象。</li><li>View：负责渲染模型数据并返回给客户端。</li></ul>请求处理流程：<ol><li>请求到达：客户端发起 HTTP 请求，Servlet 容器将请求委托给 DispatcherServlet。</li><li>上下文绑定：DispatcherServlet 查找并绑定 WebApplicationContext，绑定 LocaleResolver 和 ThemeResolver 等组件到请求上。</li><li>查找处理器：DispatcherServlet 通过 HandlerMapping 找到对应的处理器（Controller）及其执行链（包含拦截器）。</li><li>执行处理器：HandlerAdapter 调用处理器方法，准备 Model 数据。</li><li>渲染视图：如果返回 Model，则通过 ViewResolver 解析视图并渲染；如果处理器直接写入了响应（如 REST API），则不再渲染视图。</li><li>异常处理：处理过程中抛出的异常由 HandlerExceptionResolver 处理。</li></ol>DispatcherServlet 的核心价值在于职责分离：它只负责协调，具体工作由各个专门组件完成，组件之间互不干扰，便于扩展和替换。<h3>5. ER 图的设计</h3>ER 图（实体-关系图）是数据库概念设计阶段的图形化工具，用三种基本符号描述数据模型：矩形表示实体，椭圆表示属性，菱形表示关系。设计步骤：<ol><li>确定实体：找出系统中的核心对象（如用户、订单、商品）。</li><li>定义属性：为每个实体添加描述性字段（如用户的 ID、姓名、邮箱）。</li><li>建立关系：明确实体之间的关联，如“用户与订单是一对多关系”。</li><li>标注基数：用 1:N、M:N 等符号表示关联的数量对应关系。</li></ol>实例：以学生选课系统为例——实体“学生”（属性：学号、姓名）和“课程”（属性：课程号、课程名），通过关系“选课”连接，标注为多对多（一个学生可选多门课，一门课可被多名学生选）。从 ER 图到数据库表：ER 图是概念模型，最终需要转换为关系模型（即具体的表结构），包括表名、字段名、数据类型、主外键约束等。常用工具包括 <a href="https://gw-c.nowcoder.com/api/sparta/jump/link?link=https%3A%2F%2Fdraw.io%2F">Draw.io</a>、Visio、ProcessOn、Visual Paradigm 等。<h3>6. 数据库慢查询优化</h3>慢查询优化遵循 “先定位、再看执行计划、后优化” 的方法论，80% 以上的数据库性能瓶颈源于慢 SQL。第一步：定位慢 SQL<ul><li>慢查询日志：MySQL 内置工具，记录执行时间超过阈值的 SQL。生产环境建议将阈值设为 1 秒，核心场景可设为 0.5 秒。</li><li>performance_schema 与 sys 库：MySQL 8.0 默认开启，可通过 sys.schema_unused_indexes 查看无用索引，sys.statement_analysis 聚合分析全量 SQL 的执行耗时和扫描行数。</li><li>show processlist：实时查看正在执行的线程，定位长执行时间的 SQL 和阻塞问题。</li></ul>第二步：EXPLAIN 执行计划分析定位到慢 SQL 后，用 <code>EXPLAIN</code> 解析执行计划，重点关注：<ul><li>type：访问类型（ALL 全表扫描最差，ref/range 较好）</li><li>key：实际使用的索引（为 NULL 表示索引失效）</li><li>rows：预估扫描行数</li><li>Extra：是否出现 Using filesort、Using temporary 等性能警告</li></ul>第三步：索引优化与常见失效场景索引失效的高频场景包括：<ol><li>索引列上使用函数/表达式：如 WHERE YEAR(create_time) = 2026 会导致索引失效。</li><li>隐式类型转换：如字段是 varchar 类型，但 WHERE 条件传入数字，MySQL 会进行隐式转换导致索引失效。</li><li>违反最左前缀原则：联合索引 (a, b, c)，如果查询条件跳过 a 直接使用 b 或 c，整个索引失效。</li><li>模糊查询以通配符开头：LIKE '%keyword' 无法使用索引，LIKE 'keyword%' 可以使用。</li><li>OR 条件连接非索引列：如果 OR 连接的某一列没有索引，可能导致全表扫描。</li></ol>第四步：SQL 改写与表结构优化<ul><li>避免 SELECT *，只查询需要的列。</li><li>深分页用游标或子查询优化，避免 LIMIT 1000000, 10。</li><li>合理设计联合索引的列顺序，将区分度高的列放在前面。</li><li>定期用 sys.schema_unused_indexes 清理无用索引，减少维护成本。</li></ul>

AI 推荐面试题

校招 未知部门 / 算法 / 一面

校招未知部门 / 算法 / 一面