面试题库

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

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

• 什么是 ReAct 模式？它和你手写的工具调用循环是什么关系？What is the ReAct pattern, and how does it relate to a hand-rolled tool-calling loop?

  国内高频海外高频进阶#react#agent-loop#tool-calling

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

  1. 这题最容易答成名词解释。区分度在于你能不能指出 ReAct 和那个 while 循环是同一个东西，而不是两套并列的技术——把它们说成两样，面试官会认为你只读过博客没写过代码。
  2. 先给历史脉络：ReAct 出现时模型接口还没有工具字段，做法是在提示词里跟模型约定一套纯文本格式，让它交替吐出 Thought、Action、Action Input，你用正则把动作抠出来执行，再把 Observation 拼回提示词里继续。
  3. 再做映射，这是拿分的一步：今天的 function calling 把这套口头约定固化成了协议——Thought 对应 message.content，Action 对应结构化的 tool_calls，Observation 对应你追加回去的那条 role 为 tool 的消息。所以 ReAct 是那个循环的名字，不是另一种实现。
  4. 把取舍说出来：文本版脆在解析，模型少写一个换行、把参数写成 JSON、把 Action 和 Thought 换个顺序，正则就崩；结构化版把这个包袱交给了服务端，是今天的默认选择。但文本版没死——本地小模型、老接口不支持 tools 字段时，回退到「提示词约定 + 正则」仍是唯一可行的兜底，代价是解析失败率自己扛。
  5. 可以预期的追问：要不要让模型显式写出 Thought？它多花 token，但复杂任务的准确率通常更好，日志也终于可读。这是一个可调旋钮，不是必选项，按任务复杂度决定。
  6. 第二个追问：ReAct 和先规划后执行（Plan-and-Execute）有什么区别？ReAct 每一步都重新决策，边走边看，适合环境会变、信息要边查边补的任务；先规划后执行一次性出完整计划，步数和成本更可控，但对中途出现的意外不敏感。真实系统常常混用：先出一个粗计划，每一步内部再走 ReAct。

  How to reason about it · think before answering

  1. The trap is answering with a definition. What separates candidates is whether you can say that ReAct and the while loop you wrote are the same thing rather than two parallel technologies.
  2. Give the history first: when ReAct appeared, model APIs had no tool field. The trick was a prompt-level convention — the model emitted Thought, Action and Action Input as plain text, you regex-extracted the action, ran it, and pasted the Observation back into the prompt.
  3. Then map it, which is where the points are: function calling froze that convention into the protocol. Thought became message.content, Action became structured tool_calls, Observation became the tool-role message you append. ReAct is the name of your loop, not an alternative to it.
  4. State the trade-off: the text version is brittle at the parsing layer — a missing newline, JSON where plain text was expected, or a reordered Thought and Action all break the regex. Structured tool calls hand that problem to the server, which is why they are the default today. The text version is still alive though: local small models and older endpoints without a tools field leave you no other option, and you own the parse failure rate.
  5. Expect: should the model write its Thought out loud? It costs tokens, but accuracy on multi-step tasks usually improves and your logs finally become readable. Treat it as a dial, not a requirement.
  6. Second follow-up: ReAct versus plan-and-execute? ReAct re-decides at every step, which suits environments that change or information you have to gather as you go; plan-and-execute commits to a full plan up front, giving predictable step counts and cost but reacting poorly to surprises. Production systems often nest them: a coarse plan on the outside, a ReAct loop inside each step.

  答题要点

  • ReAct 是 Reasoning 加 Acting，让模型交替进行推理与行动，观察结果后再决定下一步
  • 原始形态靠提示词约定纯文本格式加正则解析；function calling 把这套约定固化进了 API 协议
  • 三步一一对应代码：Thought 是 message.content，Action 是 tool_calls，Observation 是回填的 role 为 tool 的消息
  • 结构化调用的好处是不用自己解析，代价是依赖模型支持 tools 字段；不支持时只能回退到文本版并自担解析失败率
  • 与先规划后执行相比，ReAct 每步重新决策、更适应变化，但步数与成本不如前者可控

  Key points

  • ReAct is Reasoning plus Acting: the model alternates thinking and acting, observing each result before deciding the next step
  • The original form was a prompt convention parsed by regex; function calling froze that convention into the API protocol
  • The three words map to code: Thought is message.content, Action is tool_calls, Observation is the tool-role message you append
  • Structured calls remove the parsing burden but require model support; without it you fall back to text ReAct and own the failure rate
  • Versus plan-and-execute, ReAct adapts better to change but has less predictable step count and cost

D25 前端侧 Agent 体验：流式渲染、工具调用可视化、打断/重试、SSE hooks

• 流式场景下前端的状态管理要注意什么？为什么不能每个 token 都 setState？What is different about frontend state management under streaming, and why not call setState on every token?

  国内高频海外高频进阶#react#streaming#performance

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

  1. 这题考的是「你有没有在长回复下真的看过掉帧」。答「用 useState 存消息数组，收到 delta 就 setState」在功能上没错，但它暴露的是只在短回复上试过。
  2. 先算一笔账：流式一秒来几十个 token，每个 token 一次 setState 就是一秒几十轮完整渲染。而消息列表是越来越长的，每一轮的代价随对话轮数增长——所以卡顿在回复后半段和长会话里最明显，正好是最不该卡的时候。
  3. 做法是攒批：token 先追加进 ref（不触发渲染），一个定时器每 30 毫秒把攒下的一次性提交。30 毫秒约等于 33 帧每秒，肉眼仍是连续的打字机，渲染次数掉一到两个数量级——实测 200 个 token 只提交 8 次。
  4. 三个必须配套的细节：流结束时强制 flush 一次（否则最后不足一个批次的内容永远留在缓冲里，用户看到回复少半句）；打断时也要 flush（让用户看到停在哪个字）；缓冲状态必须放 ref 不放 state，否则你为了省渲染写的代码本身在触发渲染。
  5. 再往上一层是分层：**流式逻辑应该活在 React 外面。** 解析、事件归并、攒批都是纯函数，store 持有状态并暴露 subscribe 和 getSnapshot，React 侧只用 useSyncExternalStore 订阅。这样做的直接好处是**这套逻辑可以在没有浏览器的环境里跑单元测试**，而不是只能靠手点。
  6. 可预期的追问：为什么不直接用某个状态库？答：状态库解决的是跨组件共享和更新粒度，而流式的难点在生命周期（连接、取消、卸载清理）和批处理频率——这两件事没有哪个库替你做。面试官问这题想听的是你怎么想，不是你会用哪个库。

  How to reason about it · think before answering

  1. This question probes whether you have watched a long reply drop frames. 'Keep messages in useState and setState on each delta' is functionally correct but reveals you only tried short replies.
  2. Do the arithmetic first: streaming delivers tens of tokens per second, so one setState per token means tens of full render passes per second. The message list keeps growing, so each pass gets more expensive as the conversation goes — the jank peaks late in long replies and long sessions, exactly when it hurts most.
  3. The fix is batching: append tokens into a ref without rendering, and flush the accumulated text on a 30 ms timer. Thirty milliseconds is roughly 33 fps, still a smooth typewriter, while render count drops by one to two orders of magnitude — measured, 200 tokens produced 8 commits.
  4. Three details that must ship with it: force a final flush when the stream ends, or the last sub-batch stays in the buffer and the user sees a truncated reply; flush on interrupt too, so the user sees exactly where it stopped; and keep the buffer in a ref, not state, or the code you wrote to avoid renders is itself causing them.
  5. One level up is layering: streaming logic should live outside React. Parsing, event reduction and batching are pure functions; a store holds state and exposes subscribe and getSnapshot; React only calls useSyncExternalStore. The concrete payoff is that this logic can be unit tested with no browser instead of being click-tested.
  6. Expected follow-up: why not just use a state library? Libraries solve cross-component sharing and update granularity, while the hard parts here are lifecycle (connect, cancel, cleanup on unmount) and flush cadence — no library does those for you. The interviewer wants your reasoning, not your library list.

  答题要点

  • 每个 token 一次 setState 等于一秒几十轮全量渲染，而消息列表越长每轮越贵，长回复后半段必然掉帧。
  • 做法是攒批：token 进 ref 不触发渲染，30 毫秒定时 flush 一次，实测 200 个 token 只提交 8 次。
  • 必须配套：流结束和打断时强制 flush；缓冲放 ref 不放 state。
  • 流式逻辑（解析、归并、攒批）应该是 React 之外的纯函数，React 只用 useSyncExternalStore 订阅。
  • 这样分层的直接好处是能脱离浏览器做单元测试，而不是只能手点验证。

  Key points

  • One setState per token means tens of full renders per second, and each render costs more as the list grows — long replies jank at the end.
  • Batch instead: accumulate tokens in a ref and flush every 30 ms; measured, 200 tokens produced only 8 commits.
  • Ship the details with it: force a flush on stream end and on interrupt, and keep the buffer in a ref rather than state.
  • Keep parsing, event reduction and batching as pure functions outside React; subscribe via useSyncExternalStore.
  • The payoff of that split is unit-testable streaming logic with no browser in the loop.