逐日AI

面试题库

共 328 题,当前筛选 2 题。

标签
还有 125 个标签
#abstention2#agent-loop2#behavioral2#claude-md2#coding-agent2#consistency2#context-engineering2#context-window2#distributed-systems2#embeddings2#framework-design2#interview-prep2#interview-process2#mcp2#memory2#observability2#orchestration2#prompt-engineering2#provider-abstraction2#rag2#resume2#scalability2#scheduling2#skills2#sse2#streaming2#structured-output2#agent-basics1#agent-design1#agent-sdk1#agentic-rag1#agents-md1#api-design1#async-task1#auth1#backoff1#bi-encoder1#build-vs-buy1#career1#chunking1#communication1#concurrency1#configuration1#consistent-hashing1#content-safety1#context-assembly1#context-management1#coreference1#cost-accounting1#cost-analysis1#cross-encoder1#data-quality1#encoding1#failure-analysis1#fairness1#few-shot1#ffmpeg1#fine-tuning1#frontend1#global-market1#golden-set1#hooks1#human-in-the-loop1#hybrid-search1#image-generation1#ingestion1#json-schema1#jwt1#langgraph1#long-context1#long-term-memory1#maintenance1#mcp-basics1#media-pipeline1#mental-model1#message-bus1#messages-api1#migration1#model-routing1#moderation1#modularity1#multi-turn1#normalisation1#openai1#operations1#ordering1#overlap1#primitives1#prioritization1#priority-queue1#proactive-messaging1#product-engineering1#project-storytelling1#prompt1#prompt-basics1#prompt-bloat1#prompt-design1#prompt-injection1#prompt-surface1#prompt-techniques1#prompting1#protocol1#query-rewriting1#rag-basics1#rate-limiting1#redis-streams1#reliability1#responses-api1#retrieval1#routing1#sampling1#schema-validation1#scripts1#server-design1#sharding1#similarity1#skill-design1#stakeholder-communication1#star1#state-machine1#system-prompt1#test-set1#token-budget1#tts1#workflow-engine1

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

D23 MCP 与 Skills:协议、server/client、与 function calling 区别;Claude Agent SDK 一览

  • MCP 协议解决了什么问题?它和 function calling 有什么区别?What problem does MCP solve, and how is it different from function calling?
    国内高频海外高频基础#mcp#tool-calling#protocol

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

    1. 这题有一个标准的错误答案,面试官就是靠它筛人:把 MCP 说成「function calling 的升级版」「以后不用写 function calling 了」。说出这句,后面讲得再多也已经扣完分了。
    2. 把两者放回各自的链路上就不会混:function calling 是「模型 ↔ 你的程序」之间的约定,MCP 是「你的程序 ↔ 能力提供方」之间的约定。它们不在同一段线上,所以是上下游,不是替代。
    3. 给一个能一句话验证的证据:MCP server 通过 tools/list 返回的每个工具,它的 inputSchema 本身就是 JSON Schema,你要做的只是把它搬进 function calling 的 parameters 字段发给模型。模型自始至终不知道 MCP 存在。接了 MCP 之后 function calling 那段代码一行都不会少。
    4. 再答「解决了什么问题」:接入成本从乘法变加法。N 个宿主乘 M 个能力等于 N 乘 M 份接入代码,有了协议就变成 N 加 M;顺带把责任边界划清楚了,第三方能力出问题不用先在你的服务里复现。
    5. 顺手把 Skills 也区分掉,这是很自然的追问:MCP 扩展的是「能做什么」(新增可调用的动作),Skills 扩展的是「怎么做得好」(一组提示词、脚本和参考资料打成的按需加载包)。一个给能力,一个给方法论。
    6. 可以预期的追问:那 MCP 的价值到底在哪?答案是它把「能力的发现与调用」标准化了,所以能力可以由别人维护、被多个宿主复用、不改代码就增删——但发给模型的那一段,永远还是 function calling。

    How to reason about it · think before answering

    1. This question has a canonical wrong answer that interviewers screen on: calling MCP 'function calling v2' or saying you no longer need function calling. Say that and the rest of your answer cannot recover the points.
    2. Put each one back on its own hop and the confusion disappears: function calling is the contract between the model and your program; MCP is the contract between your program and a capability provider. Different hops, so they stack — they do not replace each other.
    3. Offer a one-line proof: every tool returned by an MCP server's tools/list carries an inputSchema that is already plain JSON Schema, and all you do is copy it into the parameters field of a function-calling tool definition. The model never learns MCP exists, and adopting MCP removes not a single line of your function-calling code.
    4. Then answer what it actually solves: integration cost goes from multiplication to addition. N hosts times M capabilities means N times M integrations; a shared protocol makes it N plus M. It also draws a responsibility boundary — a third-party capability failing is no longer something you must first reproduce inside your own service.
    5. Volunteer the Skills distinction, since it is the natural follow-up: MCP extends what the agent can do (new callable actions), Skills extend how well it does it (a bundle of prompt, scripts and reference material, loaded on demand). One adds capability, the other adds method.
    6. Expect the follow-up: then where is MCP's value? In standardizing discovery and invocation, so capabilities can be owned by another team, reused by several hosts, and added or removed without a code change — while the hop to the model stays function calling.

    答题要点

    • function calling 是「模型和你的程序」之间的约定,MCP 是「你的程序和能力提供方」之间的约定,两者是上下游不是替代
    • MCP server 列出的每个工具最终仍要翻译成 function calling 的 JSON Schema 发给模型,模型不知道 MCP 存在
    • 它解决的是接入成本:N 个宿主乘 M 个能力的乘法,变成 N 加 M 的加法,同时把责任边界划到进程边界上
    • 把 MCP 说成 function calling 的升级版是最常见的错误答案,主动点破这一点会加分
    • 顺带区分 Skills:MCP 扩展「能做什么」,Skills 扩展「怎么做得好」

    Key points

    • Function calling is the model-to-your-program contract; MCP is the your-program-to-provider contract — they stack rather than replace
    • Every MCP tool still gets translated into a function-calling JSON Schema before it reaches the model, which never learns MCP exists
    • It solves integration cost: N hosts times M capabilities becomes N plus M, and the process boundary becomes the ownership boundary
    • Calling MCP an upgraded function calling is the classic wrong answer — naming that yourself scores points
    • Distinguish Skills too: MCP extends what the agent can do, Skills extend how well it does it