面试题库
共 328 题,当前筛选 2 题。
课程全部30 天从前端工程师到 Agent 工程师5 天提示词工程零基础Claude 高效使用:从对话到 Claude CodeCodex 与 OpenAI Agents SDK 高效使用7 天 MCP:把工具接进任何 Agent7 天 Agent Skills:把经验做成可复用能力5 天上下文工程14 天 RAG:从检索到可信回答14 天用 Agent 搭一条 AI 短剧生产线
标签
全部#protocol2#reliability10#cost9#observability7#architecture5#streaming5#api-design4#deployment4#distributed-systems4#error-handling4#idempotency3#message-bus3
还有 92 个标签收起标签
#operations3#rag3#security3#tool-calling3#cost-control2#langgraph2#latency2#mcp2#model-routing2#multi-agent2#ordering2#react2#redis-streams2#routing2#sse2#system-design2#agent-design1#agent-loop1#agent-quality1#async1#atomicity1#auth1#behavioral1#capacity-planning1#checkpointing1#chunking1#communication1#compression1#concurrency1#context-compression1#context-engineering1#data-modeling1#database1#debugging1#deliberate-practice1#docker1#documentation1#engineering-tradeoffs1#evaluation1#event-driven1#fan-out1#forking1#framework-design1#framework-selection1#interrupt-merge1#interview-prep1#isolation1#knowledge-organization1#lease1#loop-guard1#mobile1#multi-tenancy1#nodejs1#orchestration1#performance1#persistence1#pgvector1#portfolio1#prompt-engineering1#provider-abstraction1#quiet-hours1#ranking1#rate-limiting1#redis1#reflection1#reporting1#rerank1#retrieval-quality1#retry1#retry-semantics1#rrf1#sandboxing1#scalability1#schema-design1#secrets-management1#self-assessment1#self-presentation1#service-architecture1#session-management1#sharding1#state-machine1#state-management1#stateless1#structured-output1#system-prompt1#testing1#tool-execution1#tracing1#trade-offs1#transport1#ux1#vector-database1
30 天从前端工程师到 Agent 工程师
D1 LLM API 基础:messages/roles、token、流式、temperature;Agent 到底是什么
为什么 LLM 应用几乎都用流式输出?SSE 和 WebSocket 该怎么选?Why do LLM apps stream responses, and how do you choose between SSE and WebSockets?
国内高频海外高频进阶#streaming#protocol分析过程 · 先想清楚再作答
- 第一问考的是对延迟指标的敏感度:要能区分「首字延迟」和「全文延迟」,并说出模型逐 token 生成决定了前者远小于后者。
- 把它翻译成产品语言:用户 1 秒内看到反馈 vs 对着空白等 20 秒,这是体验的分水岭,不是锦上添花。
- 第二问不要背优缺点表,先问自己「客户端需不需要频繁上行」——这一条几乎决定了答案。
- 只需要服务器往下推 token,SSE 就够:它跑在普通 HTTP 上,代理和负载均衡友好,还自带重连。需要语音、协同、频繁打断这类双向高频交互,才值得上 WebSocket。
- 给出多数产品的真实形态:请求走普通 POST,回复走 SSE,另配一个取消接口——顺势可以引到「POST 的 SSE 用不了 EventSource 的自动重连」这个坑。
How to reason about it · think before answering
- The first half tests latency literacy: separate time-to-first-token from total latency and tie it to sequential generation.
- Translate to product terms: feedback within a second versus twenty seconds of blank screen.
- For the second half, skip the pros-and-cons table and ask whether the client needs frequent upstream messages.
- Server-to-client tokens only means SSE suffices: plain HTTP, proxy-friendly, with built-in reconnection. Voice, collaboration or frequent interrupts justify WebSockets.
- 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.
答题要点
- 模型逐 token 生成,首字延迟远小于全文延迟;流式让用户 1 秒内看到反馈而不是等 20 秒
- SSE 是单向、基于 HTTP 的文本协议,自动重连、穿透代理容易,天然适合服务器→客户端的 token 流
- WebSocket 双向、更适合需要客户端频繁上行(语音、协同编辑、打断)的场景,但代理/负载均衡更麻烦
- 多数聊天产品:请求用普通 HTTP POST,回复用 SSE;需要打断时再加一个取消接口
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
D23 MCP 与 Skills:协议、server/client、与 function calling 区别;Claude Agent SDK 一览
MCP 里 server 和 client 分别承担什么角色?server 能暴露哪几类东西,传输方式有哪些?What roles do the MCP server and client play, what can a server expose, and which transports exist?
国内高频海外高频进阶#mcp#protocol#transport分析过程 · 先想清楚再作答
- 这题看着是背概念,实际区分度在两个小地方:一是能不能把宿主和 client 分开说,二是知不知道 tools 之外还有别的原语。只答「server 提供工具、client 调用工具」是及格线以下。
- 先把三个角色摆清楚:server 是能力提供方,一个独立进程;client 是宿主里负责跟某一个 server 说话的那一小块,一个 client 只连一个 server;宿主是你的 Agent 应用,它同时持有多个 client。很多人把宿主和 client 当成一个东西,一问「连三个 server 怎么办」就露馅。
- server 侧三种原语要一起说,并且要说清谁来选:tools 是可执行的动作,由模型来挑;resources 是按 URI 读的只读数据;prompts 是可复用的提示词模板,后两者通常由用户或宿主来挑。这句「谁来选」比原语名字本身更能体现你真读过协议——把一份大文档做成 resource 而不是 tool,等于把花不花这笔 token 的决定权从模型手里收回给人。
- client 侧也能声明能力让 server 反过来请求宿主:sampling 是让宿主跑一次模型补全,roots 是告诉 server 哪些目录可见,elicitation 是请宿主向用户要一条输入。知道有这三样、不展开,分寸刚好。
- 传输两种:stdio 用于本地子进程,Streamable HTTP 用于远程。这里有个时间戳式的加分点——旧的 HTTP 加 SSE 双端点传输已经被标为 legacy,只为兼容老客户端保留;把它当现行方案讲,等于告诉对方你看的是去年的文章。
- 可以预期的追问:stdio server 有什么特别要注意的?答 stdout 被 JSON-RPC 独占,所有日志必须走 stderr,否则 client 会收到解析不了的消息;另外子进程的生命周期归宿主管,退出时要杀掉,不然留一堆孤儿进程。
How to reason about it · think before answering
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
答题要点
- 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;子进程生命周期由宿主负责回收
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