10 High-Frequency AI Agent Interview Questions: Technical Deep Dive with Code & Diagrams

Introduction

This article presents 10 high-frequency AI Agent interview questions, each accompanied by diagrams, code examples, and structured summaries. The content spans fundamental concepts, architectural patterns, engineering practices, and evaluation strategies for building reliable Agent systems.

Q1: What Is an AI Agent? Difference from Ordinary LLM Applications

The core distinction lies in three keywords: autonomous decision-making, goal-driven, closed loop . Ordinary LLM apps follow a single-turn mapping (question → answer), while Agents operate in a loop: think → act → observe → think again. A comparison table highlights differences in interaction mode, decision rights, external tool use, termination conditions, and typical use cases.

Because LLMs are autoregressive (generating one token at a time without global visibility), they cannot plan an entire solution upfront; the loop is forced by the generation mechanism, not by design. An example illustrates the loop: a user asks to check order logistics and notify the customer if delayed. The Agent queries the order, sees a delay, sends an email, and confirms success.

Follow-up: Does an Agent self-evolve? Model weights are frozen; “getting smarter” comes from accumulation in three layers: memory (user preferences, historical conclusions), tools (bug fixes, parameter additions), and processes (prompt tuning, reflection logic iteration).

Q2: When to Use Workflow, Single Agent, or Multi-Agent?

Three concrete examples clarify the boundaries:

Workflow – Refund status query: fixed three-step path (retrieve record → template → LLM generates reply). Steps are predictable; code orchestrates directly.

Single Agent – Production ticket diagnosis: next action depends on previous findings (OOM → check memory config; timeout → check gateway). Branches cannot be enumerated upfront; the model must decide dynamically.

Multi-Agent – Code generation + review: one Agent writes code, another runs unit tests in a sandbox. The reviewer brings new information (test failures) that the generator cannot obtain by re-reading its own output.

A comparison table contrasts flow, controllability, cost/latency, and suitable scenarios. The decision framework: if the path can be predefined → Workflow; if the path requires dynamic decisions → Single Agent; if collaboration yields new information (execution results, not just another model’s opinion) → Multi-Agent. Three questions to ask before splitting: (1) Is there new information? (2) Why not self-review? (3) Is role-switching enough? Common multi-Agent patterns: peer collaboration, manager mode, decentralized.

Q3: Choosing Among ReAct, CoT, Plan-and-Execute, Self-Refine

A paradigm comparison table outlines core actions, tool use, looping, and ideal scenarios:

CoT – Pure reasoning (think → think → answer). No tools. Suitable when all information is in the prompt (math, reading comprehension).

ReAct – Reasoning + action alternating (think → act → observe → think). Adds “hands” to fetch real-time data (weather, DB). Cost: risk of loops, token bloat, error propagation.

Plan-and-Execute – Global planning first, then step-by-step execution. Mitigates ReAct’s short-sightedness. Includes optional re-planner for mid-course correction.

Self-Refine – Generate → self-critique → revise → re-critique. Operates at the review layer, not the execution layer.

Production systems often combine them: Plan-and-Execute decomposes the task, ReAct executes each sub-task flexibly, Self-Refine polishes the final output. Code snippets illustrate each paradigm with concrete examples (chicken-rabbit math problem, weather query, quarterly report).

Q4: Function Calling Complete Flow

Iron law: The model only decides; it never executes. Six-step flow with Python code:

Define the tool function (e.g., query_order).

Describe tools to the LLM via JSON Schema (name, description, parameters).

Send user query + tool descriptions to LLM.

LLM returns a JSON tool call (e.g., {"name": "query_order", "arguments": {"order_id": "123"}}).

Application code executes the actual function.

Result is fed back to LLM for final answer generation.

Distinction from code generation: Function Calling outputs an invocation intent (JSON); execution runs pre-registered functions. Code generation outputs runnable code text executed in a sandbox. Pydantic validation serves dual purpose: auto-generating JSON Schema for the LLM and validating returned arguments before execution.

from pydantic import BaseModel, Field

class QueryOrderInput(BaseModel):
    order_id: str = Field(description="订单号，如 12345")
    days: int = Field(default=7, description="查询最近几天，默认 7")

# 用途① 调用前：自动生成 JSON Schema 给 LLM 看
# 用途② LLM 返回参数后：校验，脏参数拦住
QueryOrderInput(order_id="12345", days=7)        # ✅ 通过
QueryOrderInput(order_id=12345, channel="小程序") # ❌ ValidationError

Q5: What Is MCP? Relationship with Function Calling

MCP (Model Context Protocol) is an open standard by Anthropic for tool integration — the “USB-C of tools.” Function Calling is a model capability (how the model expresses intent); MCP is a tool-side protocol (how tools expose themselves). They are orthogonal: the model uses FC to pick a tool; the tool can be exposed via MCP or custom registration.

When tool count grows (dozens/hundreds), three independent dimensions must be managed:

Tool form – CLI, dedicated function, HTTP call.

Access protocol – custom registration vs. MCP.

Routing strategy – flat list, hierarchical drill-down, on-demand retrieval.

Context explosion is caused by routing (flat listing), not by MCP itself. MCP’s native Server → Tool two-level structure supports hierarchical routing naturally. Three real-world combinations demonstrate that form and protocol are interchangeable; only routing determines token consumption.

Q6: Tool Call Failure Handling & Infinite Loop Prevention

Two failure locations:

Parsing failure (A) – Invalid JSON before execution. Handle with Pydantic validation + retry + fallback.

Execution failure (B) – JSON parsed, function errors. Feed error back to model for parameter adjustment or tool switch.

Three high-frequency failures and remedies:

Parsing failure: validate → retry once with error message → fallback to default/degraded answer.

Timeout: exponential backoff (1s, 2s, 4s) → soft failure: return “tool temporarily unavailable” to model, let it decide alternative.

Data too large: trim at tool level (field selection, pagination), summarize at Agent level before LLM sees it, offload huge data to disk/vector store.

# ① 解析失败：校验 → 重试 → 兜底
try:
    args = QueryOrderInput(**response.tool_call.arguments)
except ValidationError as e:
    retry_response = llm.chat(messages=[..., {"role": "tool", "content": f"参数错误: {e}"}])
    # 再失败走兜底

# ② 超时：指数退避 + 软失败
for delay in [1, 2, 4]:
    try:
        result = call_tool(args, timeout=delay)
        break
    except Timeout:
        sleep(delay)
else:
    result = "工具暂时不可用"  # 回喂给模型

# ③ 数据太大：三层
# 工具层：精简字段 / 分页
# Agent 层：摘要压缩（进 LLM 前）
summary = small_model.summarize(huge_result, query=current_question)
# 超大数据：落盘或存向量库

Four loop-prevention lines:

Max iteration counter in state (hard stop).

Completion flag set by planner/reflection node (goal achieved).

Result verification each round (stop when criteria met).

Human-in-the-loop for high-risk or repeated failures.

Verification produces judgment; flag produces action; causal chain: verify → flag → terminate . LangGraph implementation shows state with iteration counter, should_continue logic, and framework-level recursion_limit.

class State(TypedDict):
    messages: Annotated[list, add_messages]
    iteration: int

def should_continue(state):
    if state["iteration"] >= 5:
        return "end"
    if state.get("done"):
        return "end"
    if last_message.tool_calls:
        return "tool"
    return "end"

app.invoke(state, config={"recursion_limit": 25})

Q7: Short-term/Long-term Memory, Knowledge Base, Logs – Differentiation

A table distinguishes four stores by content, retrieval method, and update mechanism:

Short-term memory – Current conversation window; retrieved via context; lost on compression/overflow.

Long-term memory – User-specific preferences/facts; semantic retrieval; continuously rewritten, merged, evicted.

Knowledge base (RAG) – Public business docs; semantic retrieval; updated via review process.

Execution logs – What ran this session; time-based file storage; append-only.

Key test for memory: Will it be semantically retrieved and influence future decisions? Example: “user prefers SF Express” → memory; “user queried logistics on Mar 8” → log. Memory lifecycle: write (explicit or auto-extracted), retrieve (each turn), evict (time decay, merge similar, capacity-based). Conflict resolution: Mem0 v2 updates/deletes at write time (risk of irreversible loss); Mem0 v3 append-only with timestamp, resolve at retrieval via semantic search + time sorting (safer, reversible).

# v2 风格：写入时消歧
memory.upsert("用户住在北京")
memory.upsert("用户搬到上海")  # → UPDATE：把北京那条改掉

# v3 风格：只追加
memory.add("用户住在北京", timestamp="2025-01")
memory.add("用户搬到上海", timestamp="2025-06")
# 查询时：语义检索 + 时间排序 → 返回"用户现在住在上海"

Q8: Context Overflow vs. Rot – Differences and Solutions

Overflow = capacity exceeded (immediate error). Rot = capacity okay but attention diluted; useful info buried, quality degrades silently (no error). Rot is more insidious: an 80-turn conversation may still contain the refund record from turn 20, but the model says “no info found.”

Three-layer engineering approach:

Overflow trio : sliding window (keep recent N turns), summarization (compress old turns), external memory (vector store + retrieval).

Isolation over compression : delegate heavy sub-tasks to child Agents; only task description and conclusion enter main context. Example: main Agent asks sub-Agent to search codebase; sub-Agent processes tens of thousands of tokens and returns only the file path.

Cost accounting + KV Cache three laws : (1) Never change system prompt or tool definitions (any change invalidates cache). (2) Append dynamic info at the end, not in system. (3) Use standard API formats. Real incident: adding Current time: {{now}} to system prompt caused 6-10× latency spike and doubled bill because timestamp changed every request, busting KV Cache. Optimization gains are not additive; combined testing required.

Q9: RAG Complete Pipeline & Retrieval Accuracy

RAG = open-book exam. Core is retrieving the right passage; generation quality is secondary. Two phases:

Offline indexing : load document → chunk (recursive/structure-aware, 256-1024 tokens, 10-20% overlap) → embed → store in vector DB with metadata (title hierarchy).

Online query : embed question → vector recall top 20-50 → cross-encoder rerank top 3-5 → pack into prompt → generate.

Example: “Can I expense a taxi in Shanghai?” Offline: parse travel policy, chunk by section. Online: recall “local transport standards,” “accommodation,” “approval flow”; rerank promotes the transport chunk; answer cites “daily limit 200 RMB.” Critical: both phases must use the same embedding model; mismatch causes silent failures.

Three-layer retrieval optimization:

Hybrid retrieval : dense (vector) for semantics + sparse (BM25) for exact keywords. Fuse with RRF (Reciprocal Rank Fusion): score = Σ 1/(60 + rank). Documents ranking high in both win.

Rerank : bi-encoder for fast recall (doc vectors precomputed), cross-encoder for precise scoring (question+doc jointly encoded). Trade-off: speed vs. accuracy.

Agentic RAG : model decides whether to retrieve (private/real-time data → yes; common knowledge → no), and how many hops (multi-hop for complex questions).

Chunk size guidelines: 256-1024 tokens, recursive splitting, 10-20% overlap. Evaluation metrics: recall@k, MRR, nDCG.

Q10: Evaluating and Iterating an Agent

Metrics layer : task completion rate (hard metric), end-to-end latency, tool call count, token consumption, hallucination rate (guardrails).

Evaluation layer : deterministic tasks (file write, config change) → automated verifiers (not self-report). Open-ended tasks (report generation) → LLM-as-Judge with rubric. Verifier design follows SWE-bench: FAIL_TO_PASS (broken before, fixed after) + PASS_TO_PASS (passed before and after) — both required to prevent test deletion or regression masking.

Iteration loop : run eval (auto) → analyze failures (AI-assisted + human) → modify prompt/tools/planning (human decision) → re-run. Three key insights:

Evaluation can be automated; optimization cannot. The loop is eval → attribution → human decision → re-eval.

Pass@k vs Pass^k : Pass@k = at least one success in k tries (capability ceiling); Pass^k = all k tries succeed (business reliability). For p=0.6, Pass@5 ≈ 99%, Pass^5 ≈ 7.8%. Side-effect scenarios must use Pass^k.

Root-cause attribution must target the first error in the trajectory and the correct layer (harness vs. model). AndroidWorld example: Agent reported success but record missing; root cause was missing image observation in harness, not model OCR ability. Misattribution wastes effort.

Closing Remarks

The author reflects on the tough job market, personal career uncertainty, and the importance of mindset, quoting a perspective on focusing on happiness over anxiety.