面试题库

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

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