面试题库

30 天从前端工程师到 Agent 工程师

D1 LLM API 基础：messages/roles、token、流式、temperature；Agent 到底是什么

• 什么是 token 和上下文窗口？它们如何影响 Agent 的设计？What are tokens and the context window, and how do they shape agent design?

  国内高频海外高频基础#llm-basics#context

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

  1. 先判断这题问的是「概念」还是「工程后果」。只答定义会被认为没做过工程，必须落到设计影响上。
  2. 从一条因果链推：token 是计费与长度的计量单位 → 窗口是这个单位的上限 → 模型无状态、历史每轮重发 → 成本随轮数增长 → 所以必须做上下文工程。
  3. 关键要点出在「Agent 比聊天更严重」：Agent 在循环里反复调模型，还要把工具返回结果也塞回历史，增长速度快得多。
  4. 结论给出具体手段：滑动窗口、摘要压缩、长期记忆外置到检索系统，并说明各自代价。
  5. 可以预期的追问：窗口没满为什么也要压缩？答案是长上下文会稀释注意力、抬高延迟与成本，不是塞满了才处理。

  How to reason about it · think before answering

  1. First decide whether this asks for definitions or engineering consequences; a definition-only answer reads as inexperienced.
  2. Follow the causal chain: tokens are the unit of billing and length, the window caps that unit, models are stateless so history is resent every turn, cost grows with turns, hence context engineering.
  3. The differentiator is why agents suffer more: a loop calls the model repeatedly and appends tool results back into history.
  4. Close with concrete tactics: sliding window, summarization, externalized long-term memory, and the cost of each.
  5. Expect the follow-up: why compress before the window is full? Long contexts dilute attention and raise latency and cost.

  答题要点

  • token 是模型处理文本的最小单位，大致 1 个汉字 ≈ 1–2 token，1 个英文单词 ≈ 1.3 token
  • 上下文窗口是一次请求里输入 + 输出 token 的上限；超出就要截断或压缩
  • 模型没有记忆，历史必须每轮重新塞进 messages，所以长对话的成本随轮数线性增长
  • Agent 设计因此要做上下文工程：滑动窗口、摘要压缩、把长期记忆外置到检索系统

  Key points

  • A token is the smallest unit the model processes; roughly 1.3 tokens per English word
  • The context window caps input + output tokens per request; beyond it you truncate or compress
  • Models are stateless, so the full history is re-sent every turn and cost grows with length
  • Hence context engineering: sliding windows, summarization, and external long-term memory
• messages 里的 system / user / assistant 三种角色各起什么作用？为什么要有 system？What do the system / user / assistant roles do, and why does system exist?

  国内高频海外高频基础#llm-basics#prompt

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

  1. 题眼在后半句「为什么要有 system」——前半句是送分，后半句才是区分度所在。
  2. 先说清三者构成一段可被模型续写的完整文本，角色是给这段文本打的结构化标记。
  3. 再回答「为什么」：如果把规则写进 user，它就只是对话里的一句话，会被后续几十轮对话稀释；放进 system 才能保持稳定权重，且便于产品侧统一管控、单独灰度。
  4. 补一条生产视角：真实的 system prompt 通常是模板拼出来的——人设 + 工具说明 + 记忆片段 + 当前时间，而不是一个写死的字符串。
  5. 常见追问：能不能把 system 放在最后？可以但不推荐，多数模型对靠前的指令更敏感，且会破坏缓存前缀。

  How to reason about it · think before answering

  1. The discriminating half is 'why does system exist'; the first half is a warm-up.
  2. Explain that the three roles are structural markers over one continuous text the model continues.
  3. Then the why: rules placed in user are just another turn and get diluted over dozens of turns; system keeps stable weight and can be governed centrally.
  4. Add production nuance: a real system prompt is templated — persona plus tool docs plus memory plus runtime facts.
  5. Likely follow-up: can system go last? Possible but unwise — models weight earlier instructions more and it breaks prompt-cache prefixes.

  答题要点

  • system 设定身份、边界与输出格式，通常放在最前面，权重高于普通对话
  • user 是用户输入，assistant 是模型历史回复，两者交替构成对话记录
  • 把规则放 system 而不是 user，是为了让规则不被后续对话冲淡，也便于产品统一管控
  • 生产里 system prompt 往往由模板拼接：人设 + 工具说明 + 记忆 + 当前时间等动态信息

  Key points

  • system sets identity, constraints and output format; it sits first and carries more weight
  • user is the human turn, assistant is the model's prior replies; they alternate
  • Rules live in system so they are not diluted by later turns and can be controlled centrally
  • In production the system prompt is templated: persona + tool docs + memory + runtime facts
• 聊天机器人和 Agent 的本质区别是什么？What fundamentally separates a chatbot from an agent?

  国内高频海外高频基础#agent-basics

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

  1. 这题最容易答成营销话术。判断标准很简单：你的回答里有没有出现「工程代价」，没有就是背概念。
  2. 先给结构：聊天是一问一答的单次调用；Agent 是在循环里反复「思考 → 调工具 → 观察」直到目标达成。
  3. 点出三个新增件——循环、工具、记忆——并强调关键差异是「工具能对外部世界产生副作用」，这是可逆与不可逆的分界线。
  4. 紧接着说代价：有副作用就要管权限与沙箱，有循环就要管步数与成本预算，有多步就要可观测性和失败重试。这一段才是面试官想听的。
  5. 用一个具体例子收尾（能查库、发消息、定时提醒的助手），并点出它背后需要队列、状态机、成本计量。

  How to reason about it · think before answering

  1. This one invites marketing language; the test is whether your answer names engineering costs.
  2. Give the structure first: a chatbot is one call, an agent loops think → act → observe until the goal is met.
  3. Name the three additions — loop, tools, memory — and stress that tools cause side effects on the world.
  4. Immediately pair each with its cost: permissions and sandboxing, step and budget caps, observability and retries.
  5. Close with a concrete example and the infrastructure it implies: queues, state machines, cost metering.

  答题要点

  • 聊天机器人是一问一答；Agent 是模型在一个循环里反复思考、调用工具、观察结果直到完成目标
  • 三个新增件：循环（多步）、工具（能对外界产生副作用）、记忆（跨轮次/跨会话）
  • 随之而来的工程问题：工具权限与沙箱、失败重试、成本与步数预算、可观测性
  • 举例：一个能查库、发消息、定时提醒的助手，背后要有消息队列、状态机和成本计量

  Key points

  • A chatbot answers once; an agent loops think → act (tool call) → observe until the goal is met
  • Three additions: a loop (multi-step), tools (side effects on the world), memory (across turns/sessions)
  • They bring engineering concerns: tool permissions and sandboxing, retries, step/cost budgets, observability
  • Example: an assistant that queries a DB, sends messages and schedules reminders needs queues, state machines and cost tracking
• temperature 和 top_p 分别控制什么？什么场景用 0，什么场景用 0.7？What do temperature and top_p control, and when would you use 0 versus 0.7?

  海外高频基础#llm-basics#sampling

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

  1. 先说清两者作用在同一个地方——模型算出的下一个 token 概率分布——但作用方式不同，这是区分度所在。
  2. temperature 是缩放整个分布：越低越尖锐、越确定；top_p 是截断——只保留累计概率达到 p 的那一小圈候选再采样。
  3. 由此推出实践建议：一般只调其中一个，两个同时调会互相干扰，出了问题分不清是谁造成的。
  4. 选值不按「创意程度」凭感觉，按「这一步的输出要不要可复现」来定：工具参数、分类判断、结构化输出必须可复现，用 0。
  5. 补一句 Agent 视角：Agent 的规划与工具调用环节几乎都用低温，只有最终面向用户的自然语言回复才考虑调高。

  How to reason about it · think before answering

  1. Establish that both act on the same next-token distribution but in different ways — that is the discriminator.
  2. temperature rescales the whole distribution; top_p truncates it to the smallest set reaching cumulative probability p.
  3. Hence the practical rule: tune one, not both, or you cannot attribute a regression.
  4. Choose by reproducibility, not by vibes: tool arguments, classification and structured output must be reproducible, so use 0.
  5. Add the agent angle: planning and tool-calling steps stay cold; only the final user-facing prose warrants higher values.

  答题要点

  • temperature 缩放下一个 token 的概率分布：越低越确定，越高越随机
  • top_p 只从累计概率达到 p 的候选里采样，是另一种截断随机性的方式；一般只调其中一个
  • 结构化输出、工具参数、分类判断用 0 或接近 0，保证可复现
  • 创意写作、头脑风暴用 0.7–1.0；生产 Agent 的规划步骤通常也偏低温

  Key points

  • temperature rescales the next-token distribution: lower is more deterministic, higher more random
  • top_p samples only from the smallest set whose cumulative probability reaches p; tune one, not both
  • Use ~0 for structured output, tool arguments and classification to keep results reproducible
  • Use 0.7–1.0 for creative writing; planning steps in production agents usually stay low

D2 工具调用原理：JSON Schema、tool_use 循环；不用框架手写 Agent Loop

• function calling 的完整流程是怎样的？Walk me through the complete function calling flow.

  国内高频海外高频基础#tool-calling#agent-loop

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

  1. 题眼在「完整」两个字。大多数人答到「模型返回一个 tool_call、我执行、把结果给它」就停了，漏掉了两头——工具定义是怎么进到请求里的，以及结果回填之后循环凭什么继续。判据是你能不能把它讲成一个闭环，而不是一次单向调用。
  2. 顺着一次请求的生命周期走五步：第一步把 tools（name、description、JSON Schema 参数）一起放进请求，注意它每一轮都要重发；第二步模型返回 tool_calls，同时停止原因是 tool_calls；第三步你解析 arguments 并执行——arguments 是一段 JSON 文本而不是对象，要再解析一次；第四步把模型那条 assistant 消息原样追加回历史，再为每一个 tool_call 追加一条 role 为 tool 的消息，tool_call_id 逐个对上；第五步带着变长的 messages 再发一次，直到停止原因不再是 tool_calls。
  3. 结论要落到一句能划安全边界的话：模型不执行任何东西，它只输出一个结构化的「请求」，真正执行、校验、鉴权、审计的全是你的代码。而这个请求的内容归根结底来自用户输入，所以权限和额度绝不能指望模型自觉。
  4. 主动说三个最高频的 400，能立刻证明你真写过：漏掉模型那条带 tool_calls 的 assistant 消息、并行调用只回了一条 tool 消息、把 arguments 当对象直接取字段。
  5. 可以预期的追问：工具会不会一直占 token？会——tools 每一轮都要重发，十个工具一两千 token 再乘以循环步数，所以工具集要按场景动态裁剪，不是接得越多越好。
  6. 第二个追问：模型请求了一个不存在的工具怎么办？不要抛异常，把「没有这个工具，请从工具列表里重新选」当成一条正常的 tool 消息回传，模型通常下一轮就自己纠正了。

  How to reason about it · think before answering

  1. The word 'complete' is the hinge. Most candidates stop at 'the model returns a tool_call, I run it, I hand back the result' and drop both ends: how the tool definitions get into the request, and what makes the loop continue after the result goes back. They want a closed loop, not a one-way call.
  2. Walk the lifecycle in five steps: send tools (name, description, JSON Schema parameters) with every request, since they are not remembered; the model replies with tool_calls and a finish reason of tool_calls; you parse arguments — a JSON string, not an object — and execute; you append the assistant message verbatim plus one tool-role message per tool call with matching tool_call_id; you send the now-longer messages again until the finish reason is no longer tool_calls.
  3. Land on the sentence that draws the security boundary: the model executes nothing. It emits a structured request, and execution, validation, authorization and auditing all live in your code. Since that request ultimately derives from user input, permissions and quotas can never be delegated to the model's good behavior.
  4. Volunteer the three most common 400s — dropping the assistant message that carried the tool_calls, answering only one of several parallel calls, and treating arguments as an object. Naming them shows you have shipped this.
  5. Expect the follow-up: do tools cost tokens forever? Yes — the tool list is re-sent every turn, so ten tools is one to two thousand tokens multiplied by the number of steps. Trim the tool set per scenario instead of registering everything.
  6. Second follow-up: what if the model calls a tool that does not exist? Do not throw. Return 'no such tool, pick one from the list' as an ordinary tool message and the model usually corrects itself on the next turn.

  答题要点

  • 请求里带上 tools 定义（name、description、JSON Schema 参数），每一轮都要重发
  • 模型返回 tool_calls，停止原因为 tool_calls；arguments 是 JSON 字符串，需要再解析一次
  • 先把模型那条 assistant 消息原样追加回 messages，再为每个 tool_call 追加一条 role 为 tool 的消息，tool_call_id 一一对应
  • 带着变长的 messages 继续下一轮，直到停止原因不再是 tool_calls，这才构成闭环
  • 模型只发出请求，执行、校验、鉴权、审计全在你的代码里

  Key points

  • Send the tool definitions (name, description, JSON Schema parameters) on every request — they are not remembered
  • The model returns tool_calls with a finish reason of tool_calls; arguments is a JSON string that needs a second parse
  • Append the assistant message verbatim, then one tool-role message per call with a matching tool_call_id
  • Send the longer message list again until the finish reason changes — that loop is what makes it an agent
  • The model only requests; execution, validation, authorization and auditing stay in your code

D3 Pi SDK 上手：三层架构、Agent Loop 对照（dg P01/P02/M02/M03）

• Agent 框架内部的 Agent Loop 一般要解决哪些问题？What problems does an agent framework's built-in agent loop have to solve?

  国内高频海外高频基础#agent-loop#framework-design

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

  1. 这题看着像背清单，区分度其实在「你有没有自己写过一遍」。只答「循环调用模型直到结束」会被认为读过文档但没写过代码。
  2. 最稳的拆法是把手写版的代码从上往下念一遍，每一行都是内核必须解决的一件事：发模型请求、维护消息历史、判断停止原因决定继不继续、按工具名分派、按 schema 校验参数、把工具结果回填成一条消息、控制最大轮数。这条链路念完，答案自然是完整的。
  3. 点名停止原因这一环最能加分：循环的出口条件不是「模型说完了」，而是这一轮的停止原因是不是「要调工具」。很多人把它含糊过去，而它恰恰是整个循环的开关。
  4. 然后补上手写版通常没做、但框架必须做的三件：并发执行同一批工具调用、把每一步以事件形式播报出去（否则外部完全是黑箱）、以及上下文超限时的压缩与会话持久化。
  5. 最后落到工具报错这一条，它是最能体现工程经验的：工具异常不应该被吞掉，要转成一条带错误标记的工具结果回给模型，让模型自己改参数重试；吞掉异常返回一句「操作失败」，模型会以为工具成功了。
  6. 可以预期的追问：怎么防死循环？答最大轮数只是兜底，更实际的是给单次运行设 token 与耗时预算，并在工具调用前留一个可以拦截的钩子，触发条件时把拦截原因回传给模型让它改道。

  How to reason about it · think before answering

  1. This looks like a checklist question, but the real signal is whether you have written such a loop yourself. 'Call the model repeatedly until it stops' reads as documentation-only knowledge.
  2. The safest structure is to walk down your own hand-written loop line by line, because every line is one problem the kernel must own: issue the model request, maintain message history, decide from the stop reason whether to continue, dispatch by tool name, validate arguments against the schema, fold the tool result back in as a message, and cap the number of turns.
  3. Naming the stop reason explicitly scores well: the loop exits not when 'the model finished talking' but when the turn's stop reason is not a tool-use one. Most candidates blur past this, and it is the switch that drives the whole loop.
  4. Then add the three things a hand-rolled version usually skips but a framework cannot: running a batch of tool calls concurrently, emitting the whole run as an event stream so callers are not staring at a black box, and compaction plus session persistence once the context outgrows the window.
  5. Close on tool errors, which is where production experience shows: a failing tool should raise, and the kernel should turn that into a tool result flagged as an error so the model can fix its arguments and retry. Swallowing the exception and returning 'operation failed' as a normal result makes the model believe the tool succeeded.
  6. Expect the follow-up: how do you stop runaway loops? A max-turn cap is only a backstop; per-run token and wall-clock budgets plus a pre-execution hook that can block a call and hand the reason back to the model are what actually work.

  答题要点

  • 循环骨架：调模型、维护消息历史、按停止原因判断继不继续、分派工具、校验参数、回填工具结果
  • 停止原因是循环的出口条件，工具分支意味着还要再来一轮，其他取值意味着结束
  • 工具执行的工程细节：同一批调用可以并发、执行前后要留钩子、异常要转成带错误标记的工具结果回给模型
  • 对外要有事件流，否则调用方看不到 Agent 在做什么，也没法做可观测性
  • 安全阀：最大轮数、token 与耗时预算、上下文超限时的压缩，以及会话的持久化与恢复

  Key points

  • The skeleton: call the model, maintain history, branch on the stop reason, dispatch tools, validate arguments, fold results back in
  • The stop reason is the loop's exit condition — a tool-use reason means one more turn, anything else means done
  • Tool execution details: batch calls can run concurrently, hooks belong before and after, and exceptions become error-flagged tool results the model can react to
  • An event stream is mandatory, otherwise callers see a black box and observability is impossible
  • Safety valves: max turns, token and latency budgets, context compaction, and session persistence for resume
• Pi SDK 的三层架构分别对应什么职责？这样分层解决了什么问题？What are the responsibilities of Pi SDK's three layers, and what does that layering buy you?

  国内高频海外高频基础#framework-design#architecture

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

  1. 前半句是记忆题，后半句才有区分度。只背出三个包名而说不出「为什么这么切」，面试官会判断你只是照着文档看了一遍。
  2. 先把三层说准：最底层是统一的模型调用层，负责把各家 provider 的请求格式、鉴权、流式分包收敛成一套接口，还统计 token 与成本；中间是 Agent 内核层，构建在模型层之上，负责 Agent 循环、工具执行、状态管理和事件流；最上层是应用层，负责会话存取、扩展与资源装载、内置工具，以及交互式、打印、进程间调用、嵌入式 SDK 这几种运行模式。依赖方向严格单向向下。
  3. 然后回答「解决了什么」：分层的价值是让你能「只要一半」——只想要统一的模型调用层就停在最底层，想要完整循环但不要终端交互就停在中间层。这条判据可以用来评估任何框架，比复述包名有用得多。
  4. 补一个很实际的收益：排障时先判断问题落在哪一层。报错栈里出现模型层，多半是鉴权、模型 id 或请求格式；出现内核层，那是循环或工具执行；两者的排查方向完全不同。
  5. 可以预期的追问：这套分层跟你手写的版本怎么对应？答手写版把三层揉在了一个文件里——fetch 那几行是模型层，while 循环和工具分派是内核层，命令行交互是应用层。能当场做这个映射，比任何背诵都有说服力。

  How to reason about it · think before answering

  1. The first half is recall; the second half carries the signal. Reciting three package names without explaining the cut suggests you only skimmed the docs.
  2. State the layers precisely: the bottom is a unified model layer that normalizes each provider's request format, auth and streaming into one interface while tracking tokens and cost; the middle is the agent kernel built on top of it, owning the agent loop, tool execution, state and the event stream; the top is the application layer, owning session storage, extension and resource loading, built-in tools, and the interactive, print, RPC and embedded-SDK run modes. Dependencies point strictly downward.
  3. Then answer what it buys: layering lets you take only half. Want just a unified model layer and your own loop? Stop at the bottom. Want the full loop but none of the terminal UX? Stop in the middle. That test generalizes to any framework and is worth far more than the package names.
  4. Add the practical payoff: when something breaks, first place it in a layer. A stack trace through the model layer points at auth, a wrong model id or a malformed request; one through the kernel points at the loop or tool execution. The two investigations look nothing alike.
  5. Expect the follow-up: how does this map onto the loop you wrote by hand? All three layers were collapsed into one file — the fetch calls were the model layer, the while loop and tool dispatch were the kernel, and the CLI was the application layer. Making that mapping live is more convincing than any recitation.

  答题要点

  • 模型层：统一各家 provider 的请求格式、鉴权与流式，附带 token 与成本统计，只收录支持工具调用的模型
  • 内核层：Agent 循环、工具执行与结果回填、状态管理、事件流，构建在模型层之上
  • 应用层：会话存取、扩展与资源装载、内置工具，以及交互式、打印、进程间调用、嵌入式 SDK 几种运行模式
  • 依赖单向向下，好处是每层可单独替换、单独测试，也能「只要一半」
  • 排障时先定位问题落在哪一层，模型层和内核层的排查方向完全不同

  Key points

  • Model layer: normalizes provider request formats, auth and streaming, tracks tokens and cost, and only ships tool-calling models
  • Kernel layer: the agent loop, tool execution and result folding, state management and the event stream, built on the model layer
  • Application layer: session storage, extension and resource loading, built-in tools, and the interactive, print, RPC and embedded-SDK run modes
  • Dependencies point one way, so each layer is replaceable and testable on its own and you can adopt only part of the stack
  • For debugging, place the failure in a layer first — model-layer and kernel-layer investigations diverge immediately

D4 模型接入与系统提示词：多 provider 抽象与 fallback、覆盖默认人设（dg P03/P04/M04）

• 为什么生产级 Agent 通常要接入多个模型 provider？Why do production agents usually integrate more than one model provider?

  国内高频海外高频基础#model-routing#reliability

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

  1. 先判断这题问的是「可用性」还是「架构」。只答「防止挂掉」拿不到分，因为面试官想看的是你有没有真的算过账、踩过坑。
  2. 从一条因果链推：模型 API 是外部依赖 → 外部依赖必然有故障率 → 你的可用性上限被它锁死 → 所以要么接受这个上限，要么加冗余。
  3. 把可用性说成数字才有说服力：单家 99.5% 意味着每月约 3.6 小时不可用；三家独立故障时理论不可用时间降到秒级。数量级差异比形容词有力得多。
  4. 第二个理由往往被忽略，但更能体现工程视角：模型的价格和能力每月都在变，接入成本高会让你因为「改起来麻烦」而一直用贵的慢的那个——高耦合真正的代价是剥夺未来的选择权。
  5. 这里有个必须自己先说破的前提：那个数量级是拿「三家故障互不相关」算出来的。如果三家其实都走同一个聚合网关、共用同一把 key（很多人的第一版就是这样），网关一挂三家一起挂，冗余是假的，聚合网关反而成了新的单点。真正的独立要落到不同厂商的直连端点、各自的凭证和计费上。主动点破这一条，比背出 0.005 的三次方更能体现你真的部署过。
  6. 可以预期的追问：多接几家不是更贵吗？答案是不会——正常路径只调一家，多的只是配置和一层抽象；真正贵的是 fallback 被频繁触发，那说明你该查主 provider 而不是砍掉冗余。

  How to reason about it · think before answering

  1. First decide whether this is an availability question or an architecture question; answering only 'so it doesn't go down' reads as inexperienced.
  2. Follow the causal chain: the model API is an external dependency, dependencies have failure rates, your ceiling is capped by theirs, so you either accept the cap or add redundancy.
  3. Quantify it: 99.5% monthly availability is about 3.6 hours of downtime; three independently failing providers push that to seconds. Orders of magnitude beat adjectives.
  4. The second reason shows engineering maturity: model pricing and capability shift monthly, and high switching cost means you stay on the expensive slow one out of inertia — coupling really costs you future optionality.
  5. Say the premise out loud before they ask: that order of magnitude assumes the three providers fail independently. If all three are model ids behind one aggregator gateway on a single key — which is what most first versions look like — the gateway going down takes all three with it, the redundancy is fake, and the aggregator has become the new single point of failure. Real independence means direct endpoints at different vendors, with separate credentials and billing. Naming this yourself signals operational experience far more than reciting 0.005 cubed.
  6. Expect the follow-up: isn't this more expensive? No — the happy path calls one provider; what costs money is fallback firing often, which is a signal to investigate the primary, not to remove redundancy.

  答题要点

  • 模型 API 是外部依赖，厂商故障、限流、模型下线都是每月都会遇到的日常，不是小概率事件
  • 单家 99.5% 可用性等于每月约 3.6 小时不可用；多家冗余能把理论不可用时间降低几个数量级
  • 价格与能力每月都在变，统一抽象层让换模型变成改配置，保住了未来做选择的自由
  • 正常路径只调一家，冗余的成本是一层抽象而不是多倍账单

  Key points

  • The model API is an external dependency; outages, rate limits and model deprecations are monthly realities
  • 99.5% monthly availability is roughly 3.6 hours down; multi-provider redundancy cuts that by orders of magnitude
  • Pricing and capability shift constantly, so an abstraction layer turns model swaps into config changes
  • The happy path still calls one provider — redundancy costs an abstraction, not a multiplied bill

D5 工具系统与事件驱动：参数校验、错误回传让模型自纠错、事件订阅（dg P05/P06/M05/M07）

• 设计 Agent 的工具时你会遵循哪些原则？名字、描述、参数分别该怎么写？What principles do you follow when designing tools for an agent — how do you write the name, the description and the parameter schema?

  国内高频海外高频基础#tool-design#prompt-engineering

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

  1. 这题的区分度在于你把工具描述当成什么。当成函数注释的人会答「写清楚做什么」，当成提示词的人才会答到点子上——描述会原样进入模型的上下文，参与「该不该调、参数填什么」的判断，它的读者是模型不是同事。
  2. 拆成三件事分别说：名字要动词加宾语（query_order 而不是 handler2），因为名字是模型的第一道筛选；描述最有价值的一句不是「做什么」而是「什么时候不该用它」，把边界写进去能砍掉一大半误用；参数里每个字段都要有自己的 description，格式类字段还要给一个合法示例——模型对「订单号」没有概念，看到 SO20260901 这个样例，填对的概率会陡增。
  3. 接着给出一条几乎没人主动说的成本判断：工具定义每一轮都会被完整重发，一个写得扎实的工具约 100 到 150 token，挂 20 个就是每轮两三千 token 的固定开销。所以「工具越多越强」是错的，只挂当前场景用得上的那几个。
  4. 再补一条可迁移的工程判断：工具改名或改语义是破坏性变更，等价于换了个工具——调好的提示词会失效，历史会话的 messages 里还留着旧名字，恢复旧会话时模型会去调一个不存在的工具。所以改工具要像改公开 API 一样走版本与灰度。
  5. 可以预期的追问：几十上百个工具怎么办？答案是先用一轮便宜模型做工具检索，只把最相关的几个塞进正式请求，而不是一股脑全挂上。

  How to reason about it · think before answering

  1. The discriminator is what you think a tool description is. People who treat it as a docstring answer 'describe what it does'; people who treat it as part of the prompt get it right — the description goes verbatim into the model's context and drives both tool selection and argument filling. Its reader is the model, not your teammate.
  2. Split it into three: names read like commands (query_order, not handler2) because the name is the model's first filter; the most valuable sentence in a description is not what the tool does but when NOT to use it, which removes most misrouting; and every parameter needs its own description plus a concrete example for format-shaped fields — a model has no notion of 'order id', but SO20260901 makes it far more likely to get it right.
  3. Then raise the cost point most candidates miss: tool definitions are resent in full every turn. A well-written tool runs 100 to 150 tokens, so twenty of them is a fixed two- to three-thousand-token tax per turn. More tools is not more capable — only mount what the current scenario needs.
  4. Add a transferable engineering judgment: renaming a tool or silently widening its semantics is a breaking change. Tuned prompts stop working, and old sessions still carry the old name in messages, so resuming one makes the model call a tool that no longer exists. Version and roll out tool changes the way you would a public API.
  5. Expect the follow-up: what about dozens or hundreds of tools? Retrieve tools with a cheap model first and mount only the top few, rather than shipping the whole catalog every turn.

  答题要点

  • 工具定义是提示词的一部分，读者是模型：它只能看到名字、描述、参数 schema，看不到你的实现
  • 名字用动词加宾语；描述里最值钱的是「什么时候不该用它」；每个参数都要有 description，格式类字段给一个合法示例
  • 工具定义每轮完整重发，20 个工具就是每轮固定两千多 token，只挂当前场景用得上的
  • 改名或改语义等于换工具，会让调好的提示词失效、让旧会话调到不存在的工具，要走版本与灰度
  • 工具规模上去之后，先用便宜模型做工具检索再挂载最相关的几个

  Key points

  • A tool definition is part of the prompt; the model only sees name, description and parameter schema
  • Name it verb plus object; the most valuable line in a description is when not to use it; every parameter needs a description, and format fields need a concrete example
  • Definitions are resent every turn, so twenty tools is a fixed two- to three-thousand-token tax — mount only what the scenario needs
  • Renaming or redefining a tool is a breaking change that invalidates tuned prompts and breaks resumed sessions
  • At scale, retrieve the relevant tools with a cheap model before mounting them

D6 消息、上下文工程与压缩、会话存储/恢复/分叉（dg M06/M08/M09/M10）

• 短期上下文和长期记忆的边界怎么划？一条信息该往哪放，你的判断依据是什么？Where do you draw the line between short-term context and long-term memory, and how do you decide where a given fact belongs?

  国内高频海外高频基础#memory#context-engineering

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

  1. 这题看着像概念题，其实考的是你有没有一条可执行的判据。背出「短期在 messages 里、长期在向量库里」只是描述现状，答不出「为什么这条该进长期」就没有区分度。
  2. 先把两者的工程属性摆出来，边界自然就清楚了：短期上下文随会话结束作废、全量进请求、按 token 计费、受窗口约束；长期记忆跨会话存在、不进请求而是检索后注入、按条存储、受检索质量约束。
  3. 给一条可复用的判据，这是本题的核心：问三句话——跨会话之后还需要吗、会随时间失效吗、能通过检索捞回来吗。三个都是「是」就进长期记忆，第一个是「否」就留在短期。举例说明：用户住上海进长期，用户刚才让我把段落改成三句话留短期。
  4. 点出最常见的误用：把长期记忆当上下文一次性全塞进去。用了半年攒两百条偏好，全塞进请求既撑爆窗口，又因为大量不相关记忆干扰模型判断——长期记忆的价值在于按需检索出最相关的三五条，不在于存了多少。
  5. 可以预期的追问：长期记忆怎么更新和失效？答要点是记忆要带时间戳和来源，用户改了主意要能覆盖旧记忆而不是并存两条矛盾的；再补一句删除权——用户要求删数据时，长期记忆是必须能定位并整体删掉的那一部分。

  How to reason about it · think before answering

  1. This looks conceptual but is really asking for an operational test. Reciting 'short-term lives in messages, long-term lives in a vector store' just describes the status quo and gives no signal.
  2. Lay out the engineering properties and the boundary draws itself: short-term context dies with the session, ships in full on every request, is billed per token and capped by the window; long-term memory spans sessions, is retrieved and injected rather than always sent, is stored per item and capped by retrieval quality.
  3. Give a reusable test — this is the core of the answer. Ask three questions: is it still needed after this session ends, does it expire with time, can retrieval find it again? Three yeses means long-term; a no on the first means it stays short-term. Illustrate: 'the user lives in Shanghai' is long-term, 'the user just asked me to shorten that paragraph to three sentences' is not.
  4. Name the common failure: stuffing all long-term memory into the prompt. Two hundred preferences accumulated over six months will both blow the window and drown the model in irrelevance. The value of long-term memory is retrieving the three or four relevant items, not the volume stored.
  5. Expect the follow-up on updates and expiry: memories need timestamps and provenance, and a changed preference must overwrite rather than coexist with a contradictory one. Add the deletion angle — long-term memory is the part you must be able to locate and erase when a user asks for their data to be deleted.

  答题要点

  • 短期上下文随会话作废、全量进请求、按 token 计费受窗口约束；长期记忆跨会话、按需检索后注入、按条存储受检索质量约束
  • 判据三问：跨会话还需要吗、会随时间失效吗、能被检索捞回来吗——三个都是就进长期记忆
  • 常见误用是把长期记忆整包塞进上下文，既撑爆窗口又用不相关的记忆干扰模型，正确做法是检索最相关的三五条
  • 长期记忆要带时间戳和来源，用户改主意时覆盖旧记忆，避免两条矛盾记忆并存
  • 长期记忆是合规上必须能按用户定位并整体删除的那一部分，短期上下文随会话删除即可

  Key points

  • Short-term context dies with the session, ships in full, and is billed per token under the window cap; long-term memory spans sessions, is retrieved on demand, and is capped by retrieval quality
  • The three-question test: is it needed after this session, does it expire, can retrieval find it — three yeses means long-term
  • The common failure is injecting the whole memory store, which blows the window and drowns the model in irrelevance; retrieve the three or four relevant items instead
  • Long-term memories need timestamps and provenance so a changed preference overwrites the old one instead of contradicting it
  • Long-term memory is the part that must be locatable and deletable per user for compliance, while short-term context simply dies with the session

D7 封装成服务：Fastify + SSE + Docker（dg P07）；W1 复盘

• 流式返回大模型回复，你会选 SSE 还是 WebSocket？为什么？For streaming LLM responses, would you pick SSE or WebSocket, and why?

  国内高频海外高频基础#sse#streaming#api-design

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

  1. 这题的题眼是「怎么选」，不是「有什么区别」。只背出「SSE 单向、WebSocket 双向」拿不到分，因为那是文档第一段。
  2. 先问自己一个问题，它几乎决定了答案：这条连接上客户端需不需要频繁上行？聊天补全是「一次请求、一路往回推」，上行只有最开始那一次，完全落在 SSE 的形状里；协同编辑、实时游戏、语音这种双向高频才轮到 WebSocket。
  3. 然后给 SSE 的三条实际好处：它就是普通 HTTP，鉴权头、Cookie、限流、日志、CDN、反向代理这一整套现成设施全部照用；服务端只是往响应里写字节，不需要额外的连接管理；协议是纯文本，出问题 curl 一下就能看。WebSocket 走的是升级后的独立协议，前面那套东西大多要重做一遍。
  4. 接着说 SSE 的两个真实限制，主动说破比被问出来强：一是浏览器原生的 EventSource 只能发 GET，而大模型接口必须 POST，所以真实前端都是 fetch 手写解析，规范里那套 Last-Event-ID 自动重连一行都用不上；二是 HTTP/1.1 下同域并发连接数有限制，多个标签页各开一条长连接会互相挤占，HTTP/2 之后这条基本消失。
  5. 结论要落到一句可判断的话：单向推送选 SSE，双向高频选 WebSocket；拿不准就先用 SSE，因为它的退路是加一个上行接口，而 WebSocket 的退路是重做整套基础设施。
  6. 可以预期的追问：那大模型产品里的「停止生成」按钮怎么办？答案是它根本不需要走同一条连接——另发一个普通的 POST 请求带上这次生成的 id，服务端收到就中止上游，SSE 那条连接自然结束。这个追问很能区分有没有真做过。

  How to reason about it · think before answering

  1. The hinge is 'how would you pick', not 'what is the difference'. Reciting 'SSE is one-way, WebSocket is two-way' scores nothing — that is the first paragraph of any doc.
  2. Ask one question that nearly decides it: does the client need frequent upstream messages on this connection? Chat completion is one request followed by a long push, which is exactly SSE's shape. Collaborative editing, realtime games and voice are what WebSocket is for.
  3. Give three practical wins for SSE: it is ordinary HTTP, so auth headers, cookies, rate limiting, logging, CDNs and reverse proxies all keep working; the server just writes bytes into a response, with no separate connection lifecycle to manage; and the wire format is plain text, so curl is your debugger. WebSocket runs an upgraded protocol where most of that tooling has to be rebuilt.
  4. Volunteer SSE's two real limits before they are raised. First, the browser's native EventSource can only issue GET, while model endpoints require POST, so real frontends hand-roll the parser with fetch and the spec's Last-Event-ID auto-reconnect never applies. Second, HTTP/1.1 caps concurrent connections per origin, so several tabs each holding a stream compete; HTTP/2 largely removes this.
  5. Land on a decision rule: one-way push means SSE, high-frequency bidirectional means WebSocket, and when unsure start with SSE — its escape hatch is adding one upstream endpoint, while WebSocket's escape hatch is rebuilding your infrastructure.
  6. Expect the follow-up: what about the 'stop generating' button? It does not need the same connection — send a plain POST carrying the run id, have the server abort upstream, and the SSE stream ends on its own. This one separates people who shipped it from people who read about it.

  答题要点

  • 先判断上行频率：一次请求、一路往回推的场景（聊天补全）用 SSE，双向高频（协同编辑、语音）用 WebSocket
  • SSE 就是普通 HTTP，鉴权、限流、日志、代理、CDN 这套设施全部照用，排查时 curl 就够
  • SSE 的限制要主动说：EventSource 只能 GET，而模型接口必须 POST，所以自动重连用不上；HTTP/1.1 下同域连接数有限
  • 拿不准先选 SSE：加一个上行接口就能补足，而换 WebSocket 要重做整套基础设施
  • 「停止生成」不用走同一条连接，另发一个 POST 带 run id 让服务端中止上游即可

  Key points

  • Decide by upstream frequency: one request plus a long push (chat completion) fits SSE; high-frequency bidirectional traffic needs WebSocket
  • SSE is plain HTTP, so auth, rate limiting, logging, proxies and CDNs all still apply, and curl is enough to debug it
  • Name SSE's limits yourself: EventSource is GET-only while model endpoints need POST, so spec auto-reconnect does not apply; HTTP/1.1 also caps per-origin connections
  • When unsure start with SSE — adding one upstream endpoint is cheaper than rebuilding infrastructure around WebSocket
  • A stop button does not need the same connection: POST the run id and abort upstream, and the stream ends by itself
• 自我介绍时，怎么在两分钟里讲清楚一个 Agent 项目的价值？In a two-minute self-introduction, how do you convey the value of an agent project?

  国内高频海外高频基础#interview-prep#communication

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

  1. 这题没有标准答案，但有明确的失败模式：从技术栈开始报菜名（我用了 Fastify、SSE、Docker、向量库……）。面试官记不住工具清单，他记得住的是问题和数字。
  2. 用一条固定结构去组织，两分钟正好够：一句话说你是谁和转型方向，一句话说项目解决的业务问题（谁在什么场景下受什么苦），三到四句说你的关键技术决定和它换来了什么，最后一句给可验证的结果。
  3. 关键技术决定要挑「有取舍的」讲，不要讲「有实现的」。比如「流式用 SSE 而不是 WebSocket，因为上行只有一次，这样鉴权限流日志这套现成设施全部照用」——这种句子同时展示了你知道有别的选项、也知道选它的代价，比列出十个工具有效得多。
  4. 结果要尽量带数字，哪怕是自测数据：首字延迟从几秒降到几百毫秒、分层路由把日成本从 300 元降到 125 元、多 provider 冗余让可用性不再取决于单家厂商。没有生产数据就诚实说明是自测环境，编数字是最危险的做法，追问两句就穿帮。
  5. 常见误区是把学习项目说成生产项目。正确姿势是主动定位：这是我为了搞懂生产级 Agent 架构而完整实现的一套系统，规模是自测级，但每个决定都对着真实约束做过取舍——面试官对诚实的自评远比对夸大的描述宽容。
  6. 可以预期的追问：这个项目最难的地方是什么？提前准备一个具体的、有过程的答案（比如流式接口推流之后没法用状态码报错，最后改成流内 error 事件加上把校验全部前置），比任何形容词都有说服力。

  How to reason about it · think before answering

  1. There is no model answer, but there is a clear failure mode: opening with a tool list. Interviewers do not remember stacks; they remember problems and numbers.
  2. Use a fixed structure that fits two minutes: one line on who you are and where you are heading, one line on the business problem (who suffers, in what situation), three or four lines on your key technical decisions and what each bought you, and one closing line with a verifiable result.
  3. Choose decisions that involved a trade-off, not decisions that merely involved implementation. 'We stream over SSE rather than WebSocket because upstream traffic is a single request, which lets us keep existing auth, rate limiting and logging' shows you knew the alternative and priced it — far stronger than naming ten tools.
  4. Attach numbers wherever you can, even self-measured ones: time-to-first-token dropping from seconds to a few hundred milliseconds, tiered routing cutting daily spend by more than half, multi-provider fallback removing a single vendor from your availability ceiling. If the numbers are from a test environment, say so; inventing them collapses after two follow-ups.
  5. A common mistake is presenting a learning project as production. Position it yourself: a complete system built to understand production agent architecture, at self-test scale, where every decision was made against real constraints. Interviewers forgive honest scoping far more readily than inflated claims.
  6. Expect: what was the hardest part? Prepare one concrete story with a process — for example, discovering that a streaming endpoint cannot report errors by status code once it has started pushing, and redesigning around an in-stream error event plus front-loaded validation.

  答题要点

  • 结构固定：定位一句、业务问题一句、三到四个有取舍的技术决定、一句可验证的结果
  • 不要报菜名：面试官记不住工具清单，记得住问题、取舍和数字
  • 技术决定要讲取舍而不是讲实现，说清楚备选方案是什么、为什么没选它
  • 结果尽量带数字，自测数据也可以，但必须标明来源，绝不编造
  • 主动定位项目规模：为搞懂生产架构而完整实现、自测级规模，诚实自评比夸大更容易通过

  Key points

  • Keep a fixed structure: positioning, the business problem, three or four traded-off decisions, and one verifiable result
  • Do not recite a stack — interviewers retain problems, trade-offs and numbers, not tool lists
  • Frame decisions as trade-offs, naming the alternative and why it lost
  • Attach numbers even from self-testing, but label their source and never invent them
  • Scope the project honestly as a complete build at self-test scale; honest framing survives follow-ups better than inflation