面试题库

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
• 什么是 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
• 怎么防止 Agent 循环停不下来？只加一个最大步数够吗？How do you keep an agent loop from running forever — is a max-step counter enough?

  国内高频海外高频深入#agent-loop#reliability#cost

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

  1. 后半句是明摆着的陷阱。只答「加一个计数器」是及格线，面试官真正想听的是你知道计数器拦不住什么。
  2. 先解释它为什么会停不下来：停止原因一直是 tool_calls，通常是因为工具返回的东西没帮模型前进——结果为空、字段答非所问、错误文案没说清该怎么改，于是它换个参数一试再试。所以第一层其实不是护栏，是把工具的返回值和错误文案写得有信息量。
  3. 再给硬护栏，三条互补：步数上限最直接；token 与成本预算拦的是「步数不多但每步都很贵」；单轮的墙上时钟超时拦的是「一步就卡了两分钟」。只有步数上限的系统，照样会被一次超长上下文的调用打爆预算。
  4. 语义层面再加一条：检测重复调用。同一个工具、同一份参数连续出现两次以上，几乎可以断定它在原地打转，直接截断并把「你已经用完全相同的参数调过这个工具了，换个思路或者告诉用户你做不到」回传给模型，往往比等步数耗尽更快收敛。
  5. 触顶之后必须有交代：不能静默返回空字符串，要给用户一句能理解的话；同时把触顶记成一个指标，触顶率上升通常意味着某个工具的描述或返回值该改了，而不是把上限调大。
  6. 可以预期的追问：上限设多少？没有普适值。聊天类任务 5 到 10 步通常够，需要多轮检索的任务可以更高。正确做法是看线上的步数分布，取 p99 再留一点余量，而不是拍脑袋——上限设得越死，你的系统就越靠近固定流程那一端，越不像一个 Agent。

  How to reason about it · think before answering

  1. The second half is an open trap. 'Add a counter' is the passing grade; what they want is whether you know what a counter cannot catch.
  2. Explain why it runs away first: the finish reason stays tool_calls because the tool results are not moving the model forward — empty results, fields that do not answer the question, error text that never says what correct looks like. So the first line of defense is not a guard rail at all; it is writing tool results and error messages that carry information.
  3. Then three complementary hard limits: a step cap is the obvious one; a token and cost budget catches 'few steps, all of them expensive'; a per-step wall-clock timeout catches 'one call hung for two minutes'. A system with only a step cap can still blow its budget on a single enormous context.
  4. Add a semantic guard: detect repeats. The same tool with identical arguments twice in a row is almost always spinning. Cut it short and tell the model so — 'you already called this tool with exactly these arguments' — which usually converges faster than waiting for the counter to run out.
  5. Hitting the cap needs an honest ending: never return an empty string, give the user a sentence they can act on, and record cap hits as a metric. A rising cap-hit rate usually means a tool's description or return value needs fixing, not that the cap should be raised.
  6. Expect: what number do you pick? There is no universal one. Chat-style tasks usually fit in five to ten steps; retrieval-heavy tasks need more. Read the production distribution, take p99 plus headroom, and remember that the tighter the cap, the closer your system sits to a fixed workflow rather than an agent.

  答题要点

  • 根因通常是工具返回值或错误文案没信息量，模型无法前进只能反复重试，先把这层写好
  • 三条硬护栏互补：最大步数、token 与成本预算、单步墙上时钟超时，只有步数上限并不够
  • 语义护栏：同一工具加同一份参数连续重复调用即判定原地打转，截断并把这个事实回传给模型
  • 触顶要给用户一句交代，不能静默返回空；同时把触顶率当指标，上升说明工具该改而不是把上限调大
  • 上限值按线上步数分布取 p99 加余量；上限越死越接近固定流程，越不像 Agent

  Key points

  • The root cause is usually uninformative tool results or error text, so fix that layer before adding guards
  • Three complementary hard limits: max steps, a token and cost budget, and a per-step wall-clock timeout
  • Add a semantic guard: identical tool plus identical arguments twice in a row means it is spinning — cut it and tell the model
  • Give the user an honest message when the cap is hit, and track the cap-hit rate as a signal that a tool needs fixing
  • Size the cap from the production step distribution, not intuition; a tighter cap makes the system a workflow rather than an agent

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

Claude 高效使用：从对话到 Claude Code

D3 Claude Code 入门与上下文管理：安装、CLAUDE.md 写法与「删到不能再删」、权限模式、Plan Mode「先探索再计划再写」、/clear /compact /rewind、给 Claude 一个可验证的检查

• 为什么说「给 Claude 一个可验证的检查」是用好 Agent 的分水岭？检查可以有哪几档硬度？Why is 'give Claude a check it can run' the dividing line for using agents well, and what levels of enforcement can that check have?

  国内高频海外高频进阶#verification#agent-loop

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

  1. 这题考对 Agent 循环的理解。答成「测试很重要」是常识；要说清没有检查时循环在谁那里闭合。
  2. 推导：Agent 在「做、看结果、改」的循环里工作，停下来的信号是「看起来做完了」。没有可运行的检查，「看起来做完了」是唯一信号，验证环落在人身上——每个错误都要等你注意到，你在场它是工具，你不在场它是风险。有了检查（测试、构建退出码、lint、比对脚本、截图对照），循环在机器里闭合：它做、它跑、它读结果、它改到通过，你只审证据。
  3. 硬度分四档：写进提示词（「实现后跑 pnpm test 直到全过」）——今天就能用；设为 /goal——独立评估器每轮复核直到达成；写成 Stop hook——测试不过不允许结束，确定性门禁；交给另一个 subagent 复核——做的人和判的人分开。每升一档多一点配置，换来少一点盯着。
  4. 生产视角：要求展示证据而不是宣布成功——贴测试输出、贴命令与返回值、贴截图；审证据比自己重跑快。
  5. 可预期的追问：检查本身会不会被绕过？会——模型可能改测试让它过。对策是把测试目录放进禁改清单，或让 reviewer subagent 专门核对「有没有为了过而改测试」。

  How to reason about it · think before answering

  1. This tests understanding of the agent loop. 'Tests matter' is common sense; explain where the loop closes without a check.
  2. Chain: an agent works in a do–observe–adjust loop and stops on 'looks done'. Without a runnable check, 'looks done' is the only signal and the verification step falls on you — every mistake waits to be noticed; present, it is a tool, absent, it is a risk. With a check (tests, build exit code, lint, diff-against-fixture, screenshot compare) the loop closes inside the machine: it works, runs, reads, and iterates to green while you review evidence.
  3. Four levels: in the prompt ('run the tests until they pass') — usable today; as a /goal — an independent evaluator re-checks every turn; as a Stop hook — the turn cannot end until the check passes, deterministic; as a reviewer subagent — the one who did the work is not the one grading it. Each step trades setup for attention.
  4. Production nuance: demand evidence, not claims — test output, commands and return values, screenshots; reviewing evidence beats re-running.
  5. Follow-up: can the check itself be gamed? Yes — the model might edit tests to pass. Counter with a deny rule on the test directory or a reviewer specifically checking for test tampering.

  答题要点

  • 没有检查时循环在人身上闭合，每个错误都等你发现；有检查时循环在机器里闭合
  • 检查可以是测试、构建、lint、比对脚本、截图对照，任何能产生通过/失败信号的东西
  • 四档硬度：提示词里要求、/goal 每轮复核、Stop hook 确定性门禁、subagent 独立复核
  • 要证据不要宣言；防止改测试作弊要靠禁改清单或专门的复核

  Key points

  • Without a check the loop closes on you; with one it closes inside the machine
  • A check is anything with a pass/fail signal: tests, build, lint, fixture diff, screenshot compare
  • Four levels: prompt instruction, /goal re-evaluation, Stop hook gate, independent reviewer subagent
  • Demand evidence over claims; guard against test tampering with deny rules or a dedicated reviewer

14 天用 Agent 搭一条 AI 短剧生产线

D2 剧本 Agent：把一句话变成人物卡、场景与分镜的结构化数据

• 生成加评审这种双角色循环，收敛条件该怎么定才不会一直烧钱？In a generator-plus-reviewer loop, how do you define convergence so it does not burn budget indefinitely?

  国内高频海外高频深入#agent-loop#cost-control

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

  1. 这题在考「你有没有让这种循环真的停下来过」。只答「设一个最大轮数」拿不到分，那只是防死循环，不是收敛设计。区分度在于你能不能说出三个出口以及评审本身该怎么构造。
  2. 先拆评审：评审不该是一个模型，而是两层——能被程序判定的硬伤用代码查（字段缺失、数值越界、长度超限、引用不合法），程序判不了的软伤才交给模型。这一步决定了分数稳不稳定：全交给模型，同一份稿子两次评分能差十几分，循环就没有收敛可言。
  3. 再说三个出口：达标就停（阈值是「够用」不是「完美」，追最后几分成本远高于收益）；到轮数上限就停，而且要交出历史最高分那一稿而不是最后一稿，因为评审有波动；剩下的问题全是软伤时转人工，因为让模型自己评自己改只会原地打转。
  4. 还要说计分方式：硬伤应该占大头（比如七成），软分占小头。否则模型一句好评就能盖过五条实打实的字段问题，循环会在第一轮就假装达标。
  5. 结论加代价：三个出口都需要参数，而参数必须实测调。阈值高了轮数用满，低了稿子不能看；上限大了烧钱，小了永远差一口气。上线前要把分数曲线画出来看它是不是单调上升。
  6. 可预期的追问：怎么知道循环真的在变好而不是在抖动？看硬伤条数，它是确定性的；分数会抖，硬伤条数不会。硬伤降不下去就说明写手根本没在按意见改，问题出在意见的粒度上——意见要带分类标签，模型才知道该改哪一类。

  How to reason about it · think before answering

  1. This screens whether you have ever made such a loop actually terminate. Answering only set a max round count scores nothing — that prevents an infinite loop, it is not convergence design. The signal is naming three exits plus how the reviewer itself is built.
  2. Start with the reviewer: it should not be one model but two layers. Machine-checkable defects (missing fields, out-of-range numbers, length limits, invalid references) go to code; only the judgment calls go to the model. This decides score stability — a pure-model reviewer can swing by ten-plus points on the same draft, and then convergence is meaningless.
  3. Then the three exits: stop on threshold (the threshold means good enough, not perfect — chasing the last few points costs far more than it returns); stop at the round cap, handing back the highest-scoring draft rather than the last one, because review scores fluctuate; and escalate to a human once only judgment-call issues remain, since a model reviewing and revising itself just circles.
  4. Also cover the scoring weights: hard defects should dominate, say seventy percent, with the model's soft score at thirty. Otherwise one flattering model review outweighs five real field errors and the loop declares success on round one.
  5. Conclusion and cost: all three exits need parameters, and parameters need empirical tuning. Too high a threshold burns every round; too low ships an unusable draft. Plot the score curve before shipping and confirm it rises monotonically.
  6. Likely follow-up: how do you know it is improving rather than oscillating? Track the hard-defect count — it is deterministic, while the score jitters. If hard defects do not fall, the writer is not acting on feedback, and the fix is feedback granularity: tag each issue with a category so the model knows which class to repair.

  答题要点

  • 评审分两层：硬伤用代码判，软伤才交给模型，否则分数不稳定、循环无从收敛
  • 三个出口：达标就停、到轮数上限交历史最高分那一稿、只剩软伤时转人工
  • 计分让硬伤占大头，避免模型一句好评盖过实打实的字段问题
  • 评语必须带分类标签，写手才能只改那一类，改稿才是收敛的
  • 观测收敛看硬伤条数而不是分数，分数会抖、硬伤条数是确定的

  Key points

  • Split the reviewer: code judges hard defects, the model judges only judgment calls — otherwise scores are unstable and nothing converges
  • Three exits: stop on threshold, stop at the round cap returning the best draft, escalate to a human when only soft issues remain
  • Weight hard defects heavily so a flattering model review cannot mask real field errors
  • Tag each review issue with a category so the writer repairs one class at a time
  • Measure convergence by hard-defect count, not score — the score jitters, the count does not