Interview Bank

From Frontend Engineer to Agent Engineer in 30 Days

D1 LLM API Basics: messages/roles, Tokens, Streaming, Temperature; What an Agent Actually Is

• Why do LLM apps stream responses, and how do you choose between SSE and WebSockets?为什么 LLM 应用几乎都用流式输出？SSE 和 WebSocket 该怎么选？

  Common in ChinaCommon overseasIntermediate#streaming#protocol

  How to reason about it · think before answering

  1. The first half tests latency literacy: separate time-to-first-token from total latency and tie it to sequential generation.
  2. Translate to product terms: feedback within a second versus twenty seconds of blank screen.
  3. For the second half, skip the pros-and-cons table and ask whether the client needs frequent upstream messages.
  4. Server-to-client tokens only means SSE suffices: plain HTTP, proxy-friendly, with built-in reconnection. Voice, collaboration or frequent interrupts justify WebSockets.
  5. State the common shape: plain POST for the request, SSE for the reply, plus a cancel endpoint — which sets up the trap that POST-based SSE cannot use EventSource auto-reconnect.

  分析过程 · 先想清楚再作答

  1. 第一问考的是对延迟指标的敏感度：要能区分「首字延迟」和「全文延迟」，并说出模型逐 token 生成决定了前者远小于后者。
  2. 把它翻译成产品语言：用户 1 秒内看到反馈 vs 对着空白等 20 秒，这是体验的分水岭，不是锦上添花。
  3. 第二问不要背优缺点表，先问自己「客户端需不需要频繁上行」——这一条几乎决定了答案。
  4. 只需要服务器往下推 token，SSE 就够：它跑在普通 HTTP 上，代理和负载均衡友好，还自带重连。需要语音、协同、频繁打断这类双向高频交互，才值得上 WebSocket。
  5. 给出多数产品的真实形态：请求走普通 POST，回复走 SSE，另配一个取消接口——顺势可以引到「POST 的 SSE 用不了 EventSource 的自动重连」这个坑。

  Key points

  • Models emit tokens sequentially; time-to-first-token is far lower than full latency
  • SSE is one-way over HTTP with built-in reconnect and easy proxying, ideal for server→client token streams
  • WebSockets are bidirectional, better when the client sends often (voice, collaboration, interrupts) but harder to load-balance
  • Most chat products: plain POST for the request, SSE for the reply, plus a cancel endpoint

  答题要点

  • 模型逐 token 生成，首字延迟远小于全文延迟；流式让用户 1 秒内看到反馈而不是等 20 秒
  • SSE 是单向、基于 HTTP 的文本协议，自动重连、穿透代理容易，天然适合服务器→客户端的 token 流
  • WebSocket 双向、更适合需要客户端频繁上行（语音、协同编辑、打断）的场景，但代理/负载均衡更麻烦
  • 多数聊天产品：请求用普通 HTTP POST，回复用 SSE；需要打断时再加一个取消接口

D23 MCP and Skills: the Protocol, Server/Client, How It Differs From Function Calling; a Tour of the Claude Agent SDK

• What problem does MCP solve, and how is it different from function calling?MCP 协议解决了什么问题？它和 function calling 有什么区别？

  Common in ChinaCommon overseasBasic#mcp#tool-calling#protocol

  How to reason about it · think before answering

  1. This question has a canonical wrong answer that interviewers screen on: calling MCP 'function calling v2' or saying you no longer need function calling. Say that and the rest of your answer cannot recover the points.
  2. Put each one back on its own hop and the confusion disappears: function calling is the contract between the model and your program; MCP is the contract between your program and a capability provider. Different hops, so they stack — they do not replace each other.
  3. Offer a one-line proof: every tool returned by an MCP server's tools/list carries an inputSchema that is already plain JSON Schema, and all you do is copy it into the parameters field of a function-calling tool definition. The model never learns MCP exists, and adopting MCP removes not a single line of your function-calling code.
  4. Then answer what it actually solves: integration cost goes from multiplication to addition. N hosts times M capabilities means N times M integrations; a shared protocol makes it N plus M. It also draws a responsibility boundary — a third-party capability failing is no longer something you must first reproduce inside your own service.
  5. Volunteer the Skills distinction, since it is the natural follow-up: MCP extends what the agent can do (new callable actions), Skills extend how well it does it (a bundle of prompt, scripts and reference material, loaded on demand). One adds capability, the other adds method.
  6. Expect the follow-up: then where is MCP's value? In standardizing discovery and invocation, so capabilities can be owned by another team, reused by several hosts, and added or removed without a code change — while the hop to the model stays function calling.

  分析过程 · 先想清楚再作答

  1. 这题有一个标准的错误答案，面试官就是靠它筛人：把 MCP 说成「function calling 的升级版」「以后不用写 function calling 了」。说出这句，后面讲得再多也已经扣完分了。
  2. 把两者放回各自的链路上就不会混：function calling 是「模型 ↔ 你的程序」之间的约定，MCP 是「你的程序 ↔ 能力提供方」之间的约定。它们不在同一段线上，所以是上下游，不是替代。
  3. 给一个能一句话验证的证据：MCP server 通过 tools/list 返回的每个工具，它的 inputSchema 本身就是 JSON Schema，你要做的只是把它搬进 function calling 的 parameters 字段发给模型。模型自始至终不知道 MCP 存在。接了 MCP 之后 function calling 那段代码一行都不会少。
  4. 再答「解决了什么问题」：接入成本从乘法变加法。N 个宿主乘 M 个能力等于 N 乘 M 份接入代码，有了协议就变成 N 加 M；顺带把责任边界划清楚了，第三方能力出问题不用先在你的服务里复现。
  5. 顺手把 Skills 也区分掉，这是很自然的追问：MCP 扩展的是「能做什么」（新增可调用的动作），Skills 扩展的是「怎么做得好」（一组提示词、脚本和参考资料打成的按需加载包）。一个给能力，一个给方法论。
  6. 可以预期的追问：那 MCP 的价值到底在哪？答案是它把「能力的发现与调用」标准化了，所以能力可以由别人维护、被多个宿主复用、不改代码就增删——但发给模型的那一段，永远还是 function calling。

  Key points

  • Function calling is the model-to-your-program contract; MCP is the your-program-to-provider contract — they stack rather than replace
  • Every MCP tool still gets translated into a function-calling JSON Schema before it reaches the model, which never learns MCP exists
  • It solves integration cost: N hosts times M capabilities becomes N plus M, and the process boundary becomes the ownership boundary
  • Calling MCP an upgraded function calling is the classic wrong answer — naming that yourself scores points
  • Distinguish Skills too: MCP extends what the agent can do, Skills extend how well it does it

  答题要点

  • function calling 是「模型和你的程序」之间的约定，MCP 是「你的程序和能力提供方」之间的约定，两者是上下游不是替代
  • MCP server 列出的每个工具最终仍要翻译成 function calling 的 JSON Schema 发给模型，模型不知道 MCP 存在
  • 它解决的是接入成本：N 个宿主乘 M 个能力的乘法，变成 N 加 M 的加法，同时把责任边界划到进程边界上
  • 把 MCP 说成 function calling 的升级版是最常见的错误答案，主动点破这一点会加分
  • 顺带区分 Skills：MCP 扩展「能做什么」，Skills 扩展「怎么做得好」
• What roles do the MCP server and client play, what can a server expose, and which transports exist?MCP 里 server 和 client 分别承担什么角色？server 能暴露哪几类东西，传输方式有哪些？

  Common in ChinaCommon overseasIntermediate#mcp#protocol#transport

  How to reason about it · think before answering

  1. This looks like recall, but it discriminates on two small things: whether you separate host from client, and whether you know there are primitives beyond tools. 'Server provides tools, client calls them' is below the bar.
  2. Lay out three roles: the server is the capability provider and its own process; the client is the piece inside the host that talks to exactly one server; the host is your agent application, holding several clients at once. People who conflate host and client fall apart the moment you ask how they would connect to three servers.
  3. Cover all three server-side primitives and say who chooses each: tools are executable actions chosen by the model; resources are read-only data addressed by URI; prompts are reusable templates — the latter two are normally chosen by the user or host. That 'who chooses' framing shows you actually read the spec: modelling a large document as a resource rather than a tool moves the decision to spend those tokens from the model back to a human.
  4. The client side declares capabilities too, letting the server call back into the host: sampling asks the host to run a model completion, roots tells the server which directories are visible, elicitation asks the host to collect user input. Naming them without elaborating is the right level of detail.
  5. Two transports: stdio for a local subprocess, Streamable HTTP for remote. The dated detail worth knowing is that the older two-endpoint HTTP+SSE transport is now legacy, kept only for backwards compatibility — presenting it as current signals you read last year's blog posts.
  6. Expect the follow-up: anything special about stdio servers? Stdout is reserved for JSON-RPC, so every log line must go to stderr or the client receives unparseable messages; and the host owns the subprocess lifecycle, so it must reap the child on exit or leave orphans behind.

  分析过程 · 先想清楚再作答

  1. 这题看着是背概念，实际区分度在两个小地方：一是能不能把宿主和 client 分开说，二是知不知道 tools 之外还有别的原语。只答「server 提供工具、client 调用工具」是及格线以下。
  2. 先把三个角色摆清楚：server 是能力提供方，一个独立进程；client 是宿主里负责跟某一个 server 说话的那一小块，一个 client 只连一个 server；宿主是你的 Agent 应用，它同时持有多个 client。很多人把宿主和 client 当成一个东西，一问「连三个 server 怎么办」就露馅。
  3. server 侧三种原语要一起说，并且要说清谁来选：tools 是可执行的动作，由模型来挑；resources 是按 URI 读的只读数据；prompts 是可复用的提示词模板，后两者通常由用户或宿主来挑。这句「谁来选」比原语名字本身更能体现你真读过协议——把一份大文档做成 resource 而不是 tool，等于把花不花这笔 token 的决定权从模型手里收回给人。
  4. client 侧也能声明能力让 server 反过来请求宿主：sampling 是让宿主跑一次模型补全，roots 是告诉 server 哪些目录可见，elicitation 是请宿主向用户要一条输入。知道有这三样、不展开，分寸刚好。
  5. 传输两种：stdio 用于本地子进程，Streamable HTTP 用于远程。这里有个时间戳式的加分点——旧的 HTTP 加 SSE 双端点传输已经被标为 legacy，只为兼容老客户端保留；把它当现行方案讲，等于告诉对方你看的是去年的文章。
  6. 可以预期的追问：stdio server 有什么特别要注意的？答 stdout 被 JSON-RPC 独占，所有日志必须走 stderr，否则 client 会收到解析不了的消息；另外子进程的生命周期归宿主管，退出时要杀掉，不然留一堆孤儿进程。

  Key points

  • The server is the capability provider in its own process; a client connects to exactly one server; the host holds many clients
  • Three server-side primitives: tools chosen by the model, resources as URI-addressed read-only data, prompts as reusable templates — the latter two usually chosen by a human
  • Clients can declare sampling, roots and elicitation so the server can call back into the host
  • Two transports: stdio for local subprocesses and Streamable HTTP for remote; the old HTTP+SSE transport is legacy
  • On stdio, stdout belongs to JSON-RPC so logs must go to stderr, and the host must reap the child process

  答题要点

  • server 是能力提供方（独立进程），client 是宿主里连接单个 server 的那一块，宿主可以同时持有多个 client
  • server 侧三种原语：tools 由模型挑，resources 是按 URI 读的只读数据，prompts 是可复用模板，后两者通常由人来挑
  • client 侧还能声明 sampling、roots、elicitation，让 server 反过来请求宿主做事
  • 传输两种：stdio（本地子进程）与 Streamable HTTP（远程）；旧的 HTTP 加 SSE 已是 legacy，不要当现行方案讲
  • stdio server 的 stdout 被 JSON-RPC 独占，日志必须走 stderr；子进程生命周期由宿主负责回收