Ten Must-Know Agent Loop Interview Questions: Breaking Down Bilibili's Most Detailed Loop Engineering Tutorial

Why Has Agent Loop Become an Interview Favorite?

Interview trends are shifting. In the past, interviewers cared about "can you use it"; now they ask directly "how did you design it"—how is the Agent Loop designed, why must Maker and Checker be separated, what are the Loop's exit conditions. If you can't answer these questions, the interview is basically over.

According to observations from the Bilibili creator in the "Ten Must-Know Agent Loop Interview Questions" tutorial, these questions have gone from bonus points to mandatory. This article is based on the first question of that tutorial, breaking down the essence of Agent Loop and providing interview answer templates you can apply directly.

Question One: The Essential Difference Between Agent Loop and a Single API Call

This is the most basic and also the easiest question to mess up. When interviewers ask "what is the essential difference between an Agent Loop and a normal single LLM API call," many people answer "one can call tools, the other can't."

That answer isn't wrong, but it's too thin. The creator's advice is to break it into four dimensions and expand along this framework during the interview—the logic will be much clearer.

Dimension One: Lifecycle

A single call is one question, one answer—done when it's done. An Agent Loop is a continuous looping process that must run until the goal is achieved or an exit condition is triggered. The lifecycle length is completely different; this is the most fundamental difference.

Dimension Two: Tool Calling

A single call has no tool-calling capability; the model can only output text. An Agent Loop can call the file system, databases, and external APIs. Tools are the Loop's hands and feet, letting it have a real impact on the external world.

The underlying mechanism of tool calling (Function Calling / Tool Use) is worth adding: the model itself does not execute tools—it outputs a structured call request (e.g., JSON containing the tool name and parameters), which an external runtime parses and actually executes, then feeds the result back to the model as a new message. This means an Agent Loop must include three stages: "parse → execute → feed back." Any failure in one stage will cause the loop to spin idle. Common designs include tool whitelists, parameter validation, timeouts and retries, and feeding error messages back to the model for self-correction. Only by understanding this mechanism can you explain why the Loop's exit conditions need to be tied to tool execution results.

Dimension Three: Memory

A single call is a brand-new conversation each time, with context starting from zero. An Agent Loop can continuously accumulate information within the loop; results from earlier steps become input for later steps. This in-loop memory accumulation is a prerequisite for the Loop to handle complex tasks.

The LLM's "context window" is key background for understanding the memory dimension. With a single call, every request must stuff the entire conversation history back into the window; when the window fills up, it must be truncated or summarized—so memory is "stateless." An Agent Loop, within the loop, appends each step's tool returns and intermediate results to the context, forming a "rolling accumulation" state. But this also brings window overflow issues—when the task chain is long, memory must be managed through summarization/compression, external vector store retrieval, or sub-agent isolation. If you can point out in the interview that "the Loop's memory is not unlimited and requires compression and retrieval strategies," that's a significant plus.

Dimension Four: Deliverables

A single call's output is usually a piece of text. An Agent Loop delivers task results—possibly modified code, a fixed bug, or a complete report. The nature of the deliverable shifts from "information" to "outcome."

Interview Answer Template

String the four dimensions together, and you can answer on the spot like this:

"The difference between an Agent Loop and a single call can be seen from four dimensions. First is lifecycle: a single call ends with one question and one answer, while a Loop must loop until the goal is achieved or an exit condition is triggered. Second is tools: a single call has no tool capability, while a Loop can call the file system, databases, and APIs. Third is memory: a single call is a new conversation each time, while a Loop continuously accumulates context within the loop. Fourth is deliverables: a single call outputs text, while a Loop delivers task results, such as modified code."

The benefit of this template is that it's structured and layered—the interviewer can immediately judge that you understand it systematically.

Extended Thinking: Why This Question Matters

This question seems to test concepts, but it's actually screening people. Those who can answer across four dimensions show they've truly used and designed Agent systems; those who only answer "can call tools" most likely have only called APIs.

The creator mentions in the tutorial that later installments will break down advanced questions such as why Maker and Checker are separated and Loop exit conditions. What these questions have in common: they all examine the trade-offs behind design decisions, not whether you can use a feature. For developers preparing for interviews, thinking through every design choice of the Loop is more valuable than memorizing answers.

Maker-Checker separation is a typical design trade-off in Agent Loop. Maker is responsible for generation or execution, and Checker is responsible for independently verifying whether the output meets the goal. The value of separation is breaking "self-confirmation bias"—when the same model both generates and checks, it easily overlooks its own errors. The cost is doubled expense, increased latency, and the Checker itself may also err. Therefore, in practice, hybrid strategies are often used: "lightweight Checker + sampled full verification" or "rule-based Checker + model-based Checker." When asked about this in an interview, the focus should be on the trade-off judgment of "in what scenarios is it worth paying double the cost."

Common Pitfalls

• Only answering tool calling, ignoring lifecycle and memory dimensions
• Describing Agent Loop as "an LLM call with tools," without reflecting the loop and exit conditions
• Deliverable description stuck at "text output," failing to realize the Loop produces task results

Remember these four dimensions, and you basically won't lose points on the first question.

Loop exit conditions are also a high-frequency follow-up point. Common designs include: goal achieved (Checker判定通过), maximum iteration cap, timeout limit, continuous lack of progress (repeating the same action or error), and explicit termination signals. Relying only on "the model says it's done" is the most dangerous approach, because the model may declare success prematurely or fall into an infinite loop. A robust Loop usually combines multiple conditions: a hard cap as a fallback, progress detection for stop-loss, and Checker as a quality gate. Emphasizing that "exit conditions are a safety net, not optional" demonstrates engineering maturity.