Agent interviews in 2026 basically revolve around a few core moves: first explain clearly 'what an Agent actually is and how it differs from chat,' then break down the paradigms (ReAct / Function Calling / LangGraph / MCP), and finally — where candidates pull ahead — hands-on Agent system-design problems. This article lays out the high-frequency question styles and answer skeletons for each layer.
What's the essential difference between an Agent and an ordinary LLM application?Must-answer
An ordinary LLM application is 'one input in → one output out'; the model isn't accountable to the outside world. An Agent is a closed loop of 'perceive (read state) → decide (plan the next step) → act (call a tool / change state) → perceive again': the model repeatedly emits tool calls and consumes the tool results until the task is done. The core increment is tool calling + looped execution + state management, not the model itself.
What role does the LLM play in an Agent? Does an Agent always need a very strong model?Must-answer
The model is the 'decision brain': intent understanding, planning, generating tool arguments, and interpreting results. Task difficulty sets the model floor — writing a tagline is fine with a small model, but multi-step reasoning, long-task error correction, and synthesizing complex tool arguments need a large model. In engineering you often have 'the large model plan and judge, while the small model handles cheap subtasks.'
What is ReAct? Why is the 'think–act–observe' loop useful?Must-answer
ReAct (Reasoning + Acting) makes the model alternately emit Thought / Action / Observation: the Thought decides what to look up, the Action calls a tool, and the Observation feeds the result back so the next Thought is grounded in real evidence. This breaks the illusion that the model 'already knows' and turns a multi-step problem into a verifiable chain of steps.
How are Function Calling / Tool Calling and ReAct related?Must-answer
Tool Calling registers tools to the model as JSON Schema and has the model return a structured call (tool name + arguments); ReAct is the high-level paradigm of 'whether and how to loop over tools.' Working together: Tool Calling supplies a stable argument format, and ReAct decides the calling cadence. The pit to call out istool-argument hallucination——the model may fabricate arguments, so you need schema constraints + enum validation + feeding call results back.
What do LangGraph / graph-style orchestration and the MCP protocol each solve?Advanced
LangGraph models an Agent as a state machine / graph: nodes are a single step (LLM / tool / human approval) and edges are conditional transitions — suited to production flows that need 'human confirmation, loop caps, and recovery from branches,' more controllable than a free-form loop. MCP standardizes 'how tools are exposed to the model' (like a USB-C interface: plug in once, use everywhere), solving tool-ecosystem fragmentation — the service side provides an MCP server, and the Agent client discovers and calls tools directly.
How many layers does an Agent's 'memory' split into, and where is each stored?Advanced
Three layers: ① context / working memory — the current turn plus intermediate results, held in the prompt window; ② session memory — multi-turn history, compressed by summarization to avoid overflowing the window; ③ long-term memory — cross-session user profiles / task archives, usually stored in a vector DB and retrieved. The interview point is explaining 'what belongs in the window, what belongs in storage, and when to retrieve,' plus preventing memory pollution (stale / contradictory info leaking into context).
Where do long tasks (tens of steps) break most easily, and how do you backstop them?Advanced
Most easily at: context exploding without bound (intermediate outputs pile up in the window), error accumulation (one wrong step poisons the rest), loops stuck dead (repeating the same thing), and external-dependency failure (interface timeouts / format changes). Backstops: persist intermediate results and feed only a summary into the window; cap max attempts and set a timeout per step; abort when you detect 'actions no longer change state'; and degrade on failure (retry → simplify → hand to a human).
When do you need multiple Agents instead of one Agent + a pile of tools?Advanced
A single Agent whose task grows too long blows up its context, and prompts interfere with each other. The value of splitting into multiple Agents isisolate context and responsibilities: a planner decomposes the task, executors each run a segment, and a reviewer catches mistakes — each keeps a clean window and can be evaluated independently. The cost is orchestration complexity and higher cost. Decision rule: has too much information that needn't 'see each other' piled into a single Agent's context? If yes, split.
How do multiple Agents collaborate? How do you keep them from spiraling out of control?Advanced
Common topologies: pipeline (A→B→C), planner–executor (a planner produces a plan, executors run it, a critic validates and loops it back), and hierarchical (a lead Agent with sub-Agents). Guardrails: global rate limits and loop caps; every step's output passes schema validation; sensitive operations need human confirmation; cost / attempt budgets. 'Letting Agents chat freely with each other' is nearly a disaster in production — controllability beats flashiness.
'Design a customer-service Agent' — from which layers do you answer?Bonus
Follow 'input → understand → retrieve → act → reply → guardrail': ① knowledge / intent — first RAG over the FAQ and the order database, with intent routing deciding self-service vs human handoff; ② tools — order lookup / address change / refund applications and more, wired via Tool Calling + argument validation + idempotency; ③ memory — session summaries + a user profile (membership tier / order history); ④ guardrails — money- or privacy-related actions always give a conclusion first then ask for human confirmation, refunds go through approval; ⑤ evaluation — intent hit rate, tool success rate, human-handoff rate, satisfaction, with bad cases fed back in.
How do you stop 'the code Agent from writing unreliable code'?Bonus
The core for a code Agent is separating 'generation' from 'verification': after generating, you must run tests / static checks in a sandbox and feed the failures back for the model to fix (a self-repair loop with a max count); constrain the edit scope (only the specified function) and never allow escaping the sandbox to run arbitrary commands; evaluate with 'test pass rate + sampled human review' rather than eyeballing whether the code looks right.
How do you evaluate an Agent before shipping? How is that different from evaluating ordinary RAG/chat?Bonus
An Agent is multi-step interaction, so single-turn metrics aren't enough. Evaluate: task success rate (was the goal reached end-to-end?), tool-call correctness and argument-error rate, average steps and cost, loop-runaway rate, and process controllability (how often guardrails fired / human intervention was needed). Trajectory-level evaluation typically 'auto-scores first (LLM-as-Judge + rule checks) then confirms with sampled human review' — the Agent Evaluation Learning Material on this site lets you try exactly this setup online.
Aimed at AI application engineers / Agent engineers / LLM-application roles. If you lean toward algorithm roles, layer model-side knowledge on top (see the 'LLM Algorithm Interview Topics Checklist').
Use this article to self-check the concepts, then pick one real task (e.g. auto-writing copy / researching and summarizing material) and build it end-to-end with LangGraph or bare Tool Calling — get 'tools → loop → guardrails → evaluation' running. In the interview, tell it through your own implementation and the pitfalls you hit, which lands far better than reciting definitions.
Follow 「兔老板工作室」 on Xiaohongshu and DM 「资料」 for a free PDF of real questions; online you can try the 'AI Short-Drama Workshop' (a multi-step Agent pipeline) and the 'Agent Evaluation Learning Material' (trajectory evaluation).
Not having a domestic internship doesn't hurt: Agent interviews value projects you've actually run yourself. Pick one real task (auto-writing copy / summarizing material / an evaluation script), build the full chain with LangGraph or bare Tool Calling, and quantify the results — then tell it as a hard project you took 'from 0 to 1'; being able to explain it in both Chinese and English is even more solid. If you want systematic hands-on coaching, book remote lessons over WeChat.
📚 Free long-form series:LLM algorithm-role high-frequency checklist · 10 RAG Interview Questions · LLM fine-tuning & alignment points · LLM inference optimization points · Big-tech talent programs compared · Résumé & project pitfall guide · AI Jobs for Chinese Students in the US · AI Infra free practice question bank