当前位置：首页 > news >正文

现在面试官竟然这么问问题，你知道吗？

news 2026/6/1 10:15:29

背景

前段时间我去面一家公司的全栈工程师岗位，由于最近 AI Agent 火热，面试官就问了我一个看似很简单的问题：

“假设用户在你的 AI Agent 产品上问‘今天天气怎么样？’，请你站在 AI Agent 全栈工程师的角度，从头到尾讲一下发生了什么。”

说实话，这个问题问得很有水平。它不考死记硬背的 API，也不考八股文，而是看你有没有真正理解一个 Agent 系统的完整链路。

一个看似简单的问题，能挖出你多深的技术功底

今天我就把我在面试现场的回答整理出来，顺带分析一下面试官到底想听到什么。

一、面试官为什么要问这个问题？

站在面试官的角度，这个问题可以同时考察好几个维度：

考察点	具体内容
系统架构能力	你能不能把一个端到端的流程讲清楚，从用户输入到模型响应，中间经过了哪些层？
对 Agent 原理的理解	你知不知道 Agent 不是直接调工具，而是先让 LLM“决策”要不要用工具？知不知道两次 LLM 调用？
对 MCP 协议的理解	如果产品用了 MCP，你能不能说清楚 MCP Client 和 Server 怎么协作？
工程落地细节	你有没有考虑过安全审批、异常处理、异步日志？还是只会讲理想情况？
沟通表达能力	能不能在 5-8 分钟内把复杂流程讲得清晰有条理？

所以，这个问题回答得好不好，基本能看出你是“用过 API 的调包侠”还是“真正做过 Agent 产品的工程师”。

二、面试回答（完整版）

下面是我面试时的一个回答流程，我把它整理加工完善成了分步骤的结构。你可以直接拿去参考。

第一步：先理清前置条件

“面试官你好，我假设我们的 Agent 产品有以下特征：
后端用 TypeScript + Node.js；
通过 MCP 协议集成了一个天气插件（weather-server）；
支持多轮对话、工具调用、用户审批；
用户已经登录，会话 ID 有效。
基于这些假设，我会从用户点击发送开始，一直讲到最终回复渲染出来。”

面试官心理活动：嗯，这个人知道先定边界，没有一上来就瞎扯。

第二步：前端与网关层（入口）

“用户在前端输入‘今天天气怎么样’，点击发送。
前端做的事：打包消息，带上会话 ID 和历史聊天记录，通过 WebSocket 或 HTTP 发到后端的/api/chat接口，同时前端 UI 切换到‘正在思考’的状态。
网关层的事：请求到达后端服务，先经过 API 网关或 Express 中间件层，做三件事———
认证：检查请求头里的 API Key 或 JWT 是否有效；
限流：看看这个用户是否超过了每秒/每分钟的调用次数；
基础校验：消息不能为空、长度不能超过限制。
过了这关，请求才被转发给 Agent 运行时。”

关键点：不要一上来就钻进 LLM 细节，先把入口说清楚。面试官想看你能不能“分层说话”。

第三步：Agent 运行时核心

“Agent 运行时是整个大脑。它维护着几个关键东西：
系统 Prompt（比如‘你是一个助手，可以用工具查天气’）；
工具注册表ToolRegistry；
已经预加载好的 MCP 客户端（天气插件在启动时就连好了）；
当前会话的对话历史。
第一次 LLM 调用（决策）：
Agent 把用户消息、系统 Prompt、历史消息拼在一起，发给 LLM。同时把工具列表（get_weather的定义）也传过去。LLM 看到用户问天气，但没说城市。如果历史记录里有过‘我在北京’，或者系统能从用户 IP 解析出城市，LLM 就会返回一个工具调用指令，类似这样——
{"tool_calls":[{"function":{"name":"get_weather","arguments":"{\"city\":\"北京\"}"}}]}
如果没有城市信息，LLM 会先反问用户。这里假设有历史记录，所以 LLM 直接返回了工具调用。”

面试官心理活动：不错，他知道 Agent 不是硬编码调工具，而是让 LLM 做决策。也提到了反问的情况，考虑得挺全。

第四步：MCP 工具调用

“Agent 收到tool_calls后，去工具注册表里找get_weather。因为这是 MCP 插件，所以拿到的是一个MCPToolAdapter。
安全审批：
查天气通常不需要用户确认，低风险。但如果配置了严格模式或者这个工具被标记为敏感，Agent 会先发一个approval_request给前端，等用户点了‘允许’再继续。
MCP Client 调用：
假设不需要审批，Adapter 调用对应的 MCP Client。这个 Client 在 mini-cc 启动时就已经通过 stdio 模式创建了一个子进程（weather-server），一直保持连接。调用走 JSON-RPC 协议——
Client 把请求写入子进程的标准输入；
weather-server 解析后，去请求第三方天气 API（比如和风天气）；
拿到结果北京 22°C 晴后，通过标准输出返回；
MCP Client 解析响应，把结果包装成统一的ToolResult返回给 Agent。
Agent 把这条结果追加到消息数组里，role是tool。”

面试官心理活动：MCP 这块说得细，stdio、JSON-RPC、子进程都提到了，说明真用过，不是背概念。

第五步：第二次 LLM 调用（生成最终回复）

“现在消息数组里有了：
系统指令
用户问‘今天天气怎么样’
Assistant 请求调工具
工具返回的原始数据北京 22°C 晴
Agent 再次调用 LLM，这次不传工具列表（因为已经不需要再调工具了）。LLM 看到工具返回的数据，就会生成一段自然语言回复，比如‘今天北京天气晴，温度 22°C，很适合出门走走’。
这一步很关键：LLM 不是直接把工具返回的字符串原样吐给用户，而是会‘翻译’成更友好的表达。”

面试官心理活动：知道两次 LLM 调用，分别做什么，这个区分很重要。

第六步：返回前端 + 异步后台任务

“Agent 把最终回复通过 WebSocket 发回前端，前端停止‘正在思考’动画，把文字渲染出来。
与此同时，系统还在做几件用户看不到的事：
记录完整日志（消息、工具耗时、token 消耗）；
更新会话缓存到 Redis；
给监控系统上报一条指标（比如weather_query_success）；
如果是敏感操作，写审计日志。”

第七步：边说边写整个链路

用户输入 "今天天气怎么样？" ↓ 前端打包请求 ↓ API 网关（认证、限流） ↓ Agent 运行时 ↓ 第一次 LLM 调用（判断需要 get_weather 工具） ↓ MCP Client 通过 stdio 调用 weather-server ↓ weather-server 请求第三方天气 API ↓ 工具结果返回（"北京 22°C 晴"） ↓ 第二次 LLM 调用（生成自然语言回复） ↓ 前端渲染，用户看到结果 ↓ （异步）日志、缓存、监控

第八步：异常情况（加分项）

“以上是正常路径。我还想补充两个常见异常，面试官你可以看看我考虑得全不全。
异常一：天气服务挂了
MCP Client 调用超时或抛异常，Agent 捕获后会把错误信息作为 tool 结果返回给 LLM。LLM 会生成类似‘天气服务暂时不可用，请稍后再试’的回复，用户不会看到堆栈。
异常二：用户拒绝审批
如果天气查询配置了需要审批，用户点了拒绝。Agent 会注入一条系统消息告诉 LLM‘用户拒绝了工具调用’，LLM 就会回复‘请允许我获取位置信息’之类的友好提示。”

面试官心理活动：主动提异常情况，说明有生产环境经验，不是只写过 demo。