面试题库

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

D3 Pi SDK 上手：三层架构、Agent Loop 对照（dg P01/P02/M02/M03）

• Pi SDK 的三层架构分别对应什么职责？这样分层解决了什么问题？What are the responsibilities of Pi SDK's three layers, and what does that layering buy you?

  国内高频海外高频基础#framework-design#architecture

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

  1. 前半句是记忆题，后半句才有区分度。只背出三个包名而说不出「为什么这么切」，面试官会判断你只是照着文档看了一遍。
  2. 先把三层说准：最底层是统一的模型调用层，负责把各家 provider 的请求格式、鉴权、流式分包收敛成一套接口，还统计 token 与成本；中间是 Agent 内核层，构建在模型层之上，负责 Agent 循环、工具执行、状态管理和事件流；最上层是应用层，负责会话存取、扩展与资源装载、内置工具，以及交互式、打印、进程间调用、嵌入式 SDK 这几种运行模式。依赖方向严格单向向下。
  3. 然后回答「解决了什么」：分层的价值是让你能「只要一半」——只想要统一的模型调用层就停在最底层，想要完整循环但不要终端交互就停在中间层。这条判据可以用来评估任何框架，比复述包名有用得多。
  4. 补一个很实际的收益：排障时先判断问题落在哪一层。报错栈里出现模型层，多半是鉴权、模型 id 或请求格式；出现内核层，那是循环或工具执行；两者的排查方向完全不同。
  5. 可以预期的追问：这套分层跟你手写的版本怎么对应？答手写版把三层揉在了一个文件里——fetch 那几行是模型层，while 循环和工具分派是内核层，命令行交互是应用层。能当场做这个映射，比任何背诵都有说服力。

  How to reason about it · think before answering

  1. The first half is recall; the second half carries the signal. Reciting three package names without explaining the cut suggests you only skimmed the docs.
  2. State the layers precisely: the bottom is a unified model layer that normalizes each provider's request format, auth and streaming into one interface while tracking tokens and cost; the middle is the agent kernel built on top of it, owning the agent loop, tool execution, state and the event stream; the top is the application layer, owning session storage, extension and resource loading, built-in tools, and the interactive, print, RPC and embedded-SDK run modes. Dependencies point strictly downward.
  3. Then answer what it buys: layering lets you take only half. Want just a unified model layer and your own loop? Stop at the bottom. Want the full loop but none of the terminal UX? Stop in the middle. That test generalizes to any framework and is worth far more than the package names.
  4. Add the practical payoff: when something breaks, first place it in a layer. A stack trace through the model layer points at auth, a wrong model id or a malformed request; one through the kernel points at the loop or tool execution. The two investigations look nothing alike.
  5. Expect the follow-up: how does this map onto the loop you wrote by hand? All three layers were collapsed into one file — the fetch calls were the model layer, the while loop and tool dispatch were the kernel, and the CLI was the application layer. Making that mapping live is more convincing than any recitation.

  答题要点

  • 模型层：统一各家 provider 的请求格式、鉴权与流式，附带 token 与成本统计，只收录支持工具调用的模型
  • 内核层：Agent 循环、工具执行与结果回填、状态管理、事件流，构建在模型层之上
  • 应用层：会话存取、扩展与资源装载、内置工具，以及交互式、打印、进程间调用、嵌入式 SDK 几种运行模式
  • 依赖单向向下，好处是每层可单独替换、单独测试，也能「只要一半」
  • 排障时先定位问题落在哪一层，模型层和内核层的排查方向完全不同

  Key points

  • Model layer: normalizes provider request formats, auth and streaming, tracks tokens and cost, and only ships tool-calling models
  • Kernel layer: the agent loop, tool execution and result folding, state management and the event stream, built on the model layer
  • Application layer: session storage, extension and resource loading, built-in tools, and the interactive, print, RPC and embedded-SDK run modes
  • Dependencies point one way, so each layer is replaceable and testable on its own and you can adopt only part of the stack
  • For debugging, place the failure in a layer first — model-layer and kernel-layer investigations diverge immediately

D8 为什么 Gateway/Worker 分离；Postgres 表设计（sessions/runs/messages）+ Drizzle

• 为什么生产级 Agent 服务通常要把 Gateway 和 Worker 拆开？什么情况下不该拆？Why do production agent services usually split a gateway from workers, and when should you not split?

  国内高频海外高频基础#architecture#scalability

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

  1. 题眼在后半句。只答「解耦、可扩展」是从架构书上抄来的，面试官想知道你有没有被某个具体现象逼着拆过——所以答案里必须出现「什么现象」和「不拆的代价」。
  2. 先给一条可复用的推导链：Agent 的一次执行是长耗时且时长不可预测的（模型响应加上多轮工具调用，几秒到几十秒），而接入层要承载全部流量、必须是毫秒级的短请求；把两种时长量级差三个数量级的工作放进同一个进程，慢的那一类必然会挤占快的那一类的资源。
  3. 把现象说具体：单进程时一台机器同时跑十几次长执行，连接与内存被占满，新来的健康检查开始超时，编排系统判定实例已死并重启它——正在跑的执行全部陪葬。这个「健康检查被自己的业务拖挂」的故事比任何抽象论证都有说服力。
  4. 然后给判据：能在 Worker 做的不放 Gateway，接入层只留鉴权、限流、落库、投递这四件耗时确定的事。拆开之后 Gateway 无状态可以任意扩缩，Worker 的并发度可以按模型配额单独调，两者的扩容曲线本来就不一样。
  5. 主动说代价，这是区分度所在：接口语义从 200 变成 202，客户端要多一次订阅往返；系统里多了一条总线和一张 runs 表，可观测性和排障链路都变长；本地开发要起更多进程。所以单次执行只有几百毫秒、没有工具调用、日活很小的场景不该拆——那时候拆分带来的复杂度远大于收益。
  6. 可以预期的追问：不拆但用线程池或者子进程行不行？答案是能缓解「挤占」但解决不了「重启即丢失」和「多实例状态不共享」，因为那两件事的根因是状态在进程里，不是并发模型不对。

  How to reason about it · think before answering

  1. The hinge is the second half. Answering only 'decoupling and scalability' sounds copied from a textbook; the interviewer wants to know which concrete symptom forced you to split, and what splitting costs.
  2. Offer a reusable chain: one agent run is long and unpredictable (model latency plus several tool calls, seconds to tens of seconds), while the ingress path carries all traffic and must stay in the millisecond range. Put workloads three orders of magnitude apart in the same process and the slow one starves the fast one.
  3. Make the symptom concrete: a single process running a dozen long executions saturates connections and memory, health checks start timing out, the orchestrator declares the instance dead and restarts it, and every in-flight run dies with it. That story lands harder than any abstract argument.
  4. Then state the rule: anything a worker can do should not live in the gateway, which keeps only auth, rate limiting, persistence and dispatch — four steps with bounded latency. After the split the stateless gateway scales with traffic while worker concurrency is tuned against model quota; the two curves were never the same.
  5. Volunteer the cost, which is where candidates separate: the contract becomes 202 instead of 200 so clients need a second subscribe round trip, you now operate a bus and a runs table, tracing spans more hops, and local development needs more processes. So do not split when a run takes a few hundred milliseconds, uses no tools, and serves modest traffic.
  6. Expect the follow-up: could a thread pool or child processes do instead? They ease starvation but fix neither 'restart loses in-flight work' nor 'two instances cannot see each other's state', because the root cause is state living inside the process, not the concurrency model.

  答题要点

  • 一次 Agent 执行是几秒到几十秒的长任务，接入层是毫秒级短请求，两者同进程时长任务必然挤占短请求的资源
  • 单进程的三个具体死法：重启丢掉在途执行、多实例状态各存各的、长执行把健康检查拖超时导致实例被误杀
  • 判据是「能在 Worker 做的不放 Gateway」，接入层只留鉴权、限流、落库、投递
  • 拆开后 Gateway 无状态按流量扩容、Worker 按模型配额扩容，两条曲线可以独立调
  • 代价是接口从 200 变 202、多一次订阅往返、排障链路变长；单次执行仅几百毫秒且无工具调用的场景不该拆

  Key points

  • A run takes seconds to tens of seconds while ingress requests are millisecond-scale; in one process the long work starves the short work
  • Three concrete failure modes: restarts lose in-flight runs, multiple instances hold separate state, and long runs stall health checks so the orchestrator kills a healthy instance
  • The rule is that anything a worker can do stays out of the gateway, which keeps only auth, rate limiting, persistence and dispatch
  • After splitting, gateways scale on traffic and workers scale on model quota — two independent curves
  • Costs: a 202 contract plus a subscribe round trip, an extra bus and table to operate, longer traces; skip the split for sub-second runs with no tool calls

D15 多 Agent 模式全景（Router/Supervisor、Planner-Executor、Critic、Swarm、Blackboard）与何时不该用；LangGraph 入门

• 常见的多 Agent 协作模式有哪些？分别适合什么形状的任务？What are the common multi-agent collaboration patterns, and what shape of task suits each?

  国内高频海外高频基础#multi-agent#orchestration#architecture

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

  1. 这题看似送分，其实在筛「背过名词」和「拆过系统」。只报五个名字最多拿及格分，面试官真正想听的是你用什么维度把它们区分开——有维度说明你能给没见过的架构归类，没维度说明你只是读过一篇综述。
  2. 给一个可复用的维度：模式的差别不在名字，在图的形状。盯四件事就够——有没有分叉（运行时三选一）、有没有扇出（同时交给多个人）、有没有汇合（多份产出合到一起）、有没有回边（可以打回重做）。
  3. 然后逐个落位：Router/Supervisor 只有分叉，一次只找一个专家，难点在判断该找谁；Planner-Executor 是扇出加汇合，适合一件事拆成几件、几件之间没有先后；Critic 是分叉加回边，适合对错有明确判据、且重做比发出去便宜的产出；Swarm 也是分叉加回边，但下一棒交给谁由当前这位自己决定；Blackboard 是扇出加汇合加回边，参与者互相不知道对方存在，只认公共状态。
  4. 主动指出 Critic 和 Swarm 的四个特征一模一样，区别落在「回边由谁决定」——Critic 是固定的评审节点在判，Swarm 是当前这位自己判。**主动承认自己的判据在哪里失效，比多背一个模式名更能加分**，因为它证明你真的用过这套维度而不是刚编出来。
  5. 每种模式还要配一句代价，这是区分度所在：Router 多一次路由调用的延迟；Planner-Executor 的并行会带来状态写冲突，字段必须配合并规则；Critic 的回路必须有次数上限，否则永远出不了稿；Swarm 事先不知道会走多少步，成本和延迟都难封顶；Blackboard 的终止条件最难写，容易谁都不接活或者反复触发。
  6. 可以预期的追问：生产上你最常用哪个？答 Router/Supervisor，理由是它的失败模式最好理解——路由判错了看一眼路由理由就知道，而且它是唯一一个能顺便省钱的模式，简单意图可以路由到便宜的小模型。

  How to reason about it · think before answering

  1. This looks like a giveaway but it separates people who memorised names from people who have split a system. Listing five names is a bare pass; the interviewer wants the axis you use to tell them apart, because an axis means you can classify an architecture you have never seen.
  2. Offer a reusable axis: the difference is not the name, it is the shape of the graph. Four questions suffice — is there a branch (pick one at runtime), a fan-out (hand it to several at once), a join (merge several outputs), a back edge (send it back for rework).
  3. Then place each one: Router/Supervisor is branch only, one specialist per turn, the hard part is deciding who; Planner-Executor is fan-out plus join, for work that splits into independent pieces; Critic is branch plus back edge, for output with a clear pass/fail test where redoing is cheaper than shipping; Swarm is also branch plus back edge, but the next hop is chosen by whoever holds the baton; Blackboard is fan-out plus join plus back edge, participants unaware of each other, reacting only to shared state.
  4. Point out yourself that Critic and Swarm score identically on all four, and that the real difference is who decides the back edge — a fixed reviewer node versus the current agent. Volunteering where your own criterion breaks down scores better than reciting one more pattern name, because it proves you have used the axis rather than invented it on the spot.
  5. Attach a cost to each: Router adds one routing call of latency; Planner-Executor's parallelism creates write conflicts so fields need merge rules; Critic loops need a hard retry cap or nothing ever ships; Swarm has no upfront bound on steps so cost and latency are hard to cap; Blackboard has the hardest termination condition and tends to either stall or re-trigger.
  6. Expect: which do you use most in production? Say Router/Supervisor, because its failure mode is the easiest to read — check the recorded routing reason — and because it is the one pattern that can save money, by routing simple intents to a cheaper model.

  答题要点

  • 先给维度再给名字：分叉、扇出、汇合、回边四个特征就能把五种模式分开
  • Router/Supervisor 只有分叉，一次只找一个专家，难点是判断该找谁
  • Planner-Executor 是扇出加汇合，适合拆成几件互不依赖的小任务再合成一份交付
  • Critic 是分叉加回边，适合对错有明确判据、重做比发出去便宜的产出，必须配打回次数上限
  • Swarm 与 Critic 的四个特征相同，区别在回边由谁决定；Blackboard 靠公共状态解耦，终止条件最难写
  • 每种模式配一句代价：多一次调用的延迟、并行的写冲突、回路的死循环、步数不封顶、终止条件难定

  Key points

  • Give the axis before the names: branch, fan-out, join and back edge separate all five patterns
  • Router/Supervisor is branch only — one specialist per turn, the hard part is choosing who
  • Planner-Executor is fan-out plus join — split into independent subtasks, then merge into one deliverable
  • Critic is branch plus back edge — for output with a clear pass/fail test, and it needs a hard retry cap
  • Swarm scores the same as Critic; the difference is who decides the back edge. Blackboard decouples via shared state and has the hardest termination condition
  • Pair each with a cost: extra call latency, parallel write conflicts, infinite review loops, unbounded step count, fuzzy termination

D17 Planner–Executor–Critic + 共享工作区：workspace state、toolBudget、并行 fan-out、review 回路

• Planner-Executor-Critic 这种结构解决了什么问题？它和 Supervisor 路由的区别在哪？What problem does the Planner-Executor-Critic structure solve, and how is it different from Supervisor routing?

  国内高频海外高频基础#multi-agent#orchestration#architecture

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

  1. 题眼在后半句。只答「拆解、执行、评审」是在背名词，面试官想确认的是你能不能用图的形状把两种模式分开，而不是靠记忆背模式表。
  2. 先用形状拆：Supervisor 是一个岔路口，运行时在几条路里选一条走，一次只交给一个人，图上只有分叉；Planner-Executor-Critic 是先扇出、再汇合、中间还有一条回边。分叉解决「交给谁」，扇出解决「一件事要拆成几件」，回边解决「谁来验收」。
  3. 再给适用判据：一次只需要一个专家、难点在判断该找谁，用 Supervisor；一件事必须拆成几件且几件之间没有先后依赖，才值得扇出；产出的对错有明确判据、且错了重做比错了发出去便宜，才值得加 Critic。三条判据都不命中就别上这套结构。
  4. 结论要落到代价，这是区分「读过文档」和「上线过」的地方：拆出三件事意味着模型调用次数从一次变成七次起步（拆解一次、三次执行、三次评审），有一轮打回就是九次；延迟被最慢的那件事决定而不是平均值，而且并行只省延迟不省钱。
  5. 可以预期的追问：Critic 一定要单独一个节点吗？答案是不一定——如果验收判据是可以用代码判的（比如 JSON schema 校验、必填字段检查），就别花一次模型调用，代码判更快更准也更便宜。只有判据本身需要理解语义时，Critic 才值得是一次模型调用。

  How to reason about it · think before answering

  1. The hinge is the second half. Reciting plan, execute, review is naming shapes from memory; the interviewer wants to see you separate the two patterns by graph shape.
  2. Separate by shape: a Supervisor is a fork — at runtime it picks one of several paths and hands the work to exactly one agent, so the graph only branches. Planner-Executor-Critic fans out, joins, and adds a back edge. Branching answers who takes this, fan-out answers this must be split into several pieces, the back edge answers who signs it off.
  3. Then give the criteria: use a Supervisor when only one specialist is needed per request and the hard part is picking them; only fan out when a request genuinely splits into independent pieces with no ordering between them; only add a Critic when correctness has an explicit rubric and redoing is cheaper than shipping something wrong. If none of these hold, do not build this.
  4. Land on cost, which is where shipped-it separates from read-the-docs: three subtasks turn one model call into seven (one plan, three executions, three reviews) and nine after a single rejection round; latency is set by the slowest branch rather than the average, and parallelism buys latency, never money.
  5. Expect: does the Critic have to be its own node? Not necessarily — if the rubric is checkable in code (schema validation, required fields), check it in code: faster, cheaper, and more reliable. A Critic earns a model call only when the rubric requires understanding meaning.

  答题要点

  • Supervisor 是分叉（一次派一个人），Planner-Executor-Critic 是扇出加汇合加回边（拆成几件并行做，做完有人验收）
  • 三条适用判据：一次只需一个专家用路由；能拆成互不依赖的几件才扇出；对错有明确判据且重做便宜才加评审
  • 拆解的代价是模型调用从一次涨到七到九次、延迟由最慢的分支决定，而并行只省延迟不省成本
  • 评审判据能用代码判就别用模型判，Critic 只在需要理解语义时才值一次模型调用

  Key points

  • A Supervisor branches (one agent per request); Planner-Executor-Critic fans out, joins, and loops back (split, run in parallel, then sign off)
  • Three criteria: route when one specialist suffices; fan out only for genuinely independent pieces; add review only when the rubric is explicit and redoing beats shipping wrong
  • The cost is seven to nine model calls instead of one, with latency set by the slowest branch — parallelism buys latency, not money
  • If the rubric is checkable in code, check it in code; a Critic deserves a model call only when semantics must be understood

7 天 MCP：把工具接进任何 Agent

D1 为什么需要一个协议：host / client / server 三角、JSON-RPC 消息与三种原语

• MCP 和模型自带的函数调用到底差在哪？什么情况下你不该用 MCP？How is MCP actually different from a model's built-in function calling, and when should you not use MCP?

  国内高频海外高频基础#mcp-basics#architecture

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

  1. 这题在筛「有没有真正接过工具」。把 MCP 说成「函数调用的升级版」就露馅了，因为两者根本不在同一层，答对的人第一句就会先把层次拆开。
  2. 拆法：问自己「这一步是模型 API 的事，还是工具从哪来的事」。函数调用是模型 API 的能力——你把工具定义放进请求，模型回一个要调谁；MCP 管的是那份定义和执行体住在哪个进程里、用什么语言交换。
  3. 接着点出两者是叠加而非替代：MCP 客户端拿到 tools/list 之后，还要把它翻译成模型 API 的工具参数，最终仍然走函数调用那条路。
  4. 结论：MCP 解决的是 M 个应用乘 N 个工具的重复接线，把乘法变成加法；它换来的代价是多一层进程、一层序列化、一层要排查的地方。
  5. 不该用的三种情况：工具只有自己这一个程序用；调用极频繁且对延迟敏感（远程一次往返几十到几百毫秒，一轮连调五次用户就有感）；这件事根本不需要模型决定，产品逻辑本来就是确定的。
  6. 可预期的追问：那本机 stdio 的开销很小，是不是就可以随便用？答案是开销不只在传输，还在多一个要部署、要监控、要授权的进程上。

  How to reason about it · think before answering

  1. The screen is whether you have actually wired tools yourself. Calling MCP an upgraded function call fails, because the two sit at different layers.
  2. Separate the layers first: function calling is a model API feature — you pass tool definitions in the request and the model replies with which one to invoke. MCP governs where that definition and its executor live and how they are exchanged.
  3. They compose rather than compete: an MCP client still translates tools/list output into the model API's tool parameters, so the final hop is ordinary function calling.
  4. Conclusion: MCP turns an M-applications-by-N-tools wiring problem into M plus N, at the cost of an extra process, an extra serialization boundary, and an extra place to debug.
  5. Skip MCP when the tool has exactly one consumer, when calls are hot and latency-sensitive (a remote round trip is tens to hundreds of milliseconds, five per turn is noticeable), or when the decision does not need a model at all.
  6. Likely follow-up: local stdio is cheap, so why not use it everywhere? Because the cost is not only transport — it is one more process to deploy, monitor, and authorize.

  答题要点

  • 函数调用是模型 API 的能力，MCP 是工具定义与执行体的分发协议，两者叠加而不是替代
  • MCP 的价值是把 M 乘 N 的适配器数量变成 M 加 N，代价是多一层进程与序列化
  • 单一消费者、延迟敏感的热路径、以及本来就确定的产品流程，这三种情况不该用 MCP
  • 判据是「这个能力要不要给第二个程序用」，只要答案是要，协议的成本就摊得开

  Key points

  • Function calling is a model API capability; MCP is a distribution protocol for tool definitions and executors — they stack, not compete
  • MCP converts M-by-N adapters into M plus N, paying with an extra process and serialization hop
  • Skip it for single-consumer tools, latency-sensitive hot paths, and flows that are deterministic by design
  • The test is whether a second program will ever need this capability; if yes, the protocol cost amortizes

14 天 RAG：从检索到可信回答

D7 第一周综合：把六天的零件装成一个可一键启动的检索问答服务并复盘

• 你会怎么划分一个检索增强生成系统的模块边界？其中哪一层最应该做成可替换的，为什么？How would you draw the module boundaries of a RAG system, and which layer most needs to be swappable? Why?

  国内高频海外高频基础#architecture#modularity#embeddings

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

  1. 这题考的是你有没有真的维护过这类系统。只按「解析、切块、检索、生成」复述一遍流程图，面试官会判定你只搭过 demo——流程图人人都会画，切口画在哪才是经验。
  2. 给一条可复用的判据再往下推：切口应该落在「将来最可能被整个换掉」的地方，而不是按代码量或者功能名称均分。
  3. 用它过一遍：embedding 一年会换好几次，换一次库里所有向量作废、必须全量重算，所以它必须是接口；存储可能从 PostgreSQL 换成专用向量库，而且摄取和查询都要通过它，所以它是两条链路的唯一交界；切块策略在调优期天天改，所以它必须是配置项而不是硬编码。
  4. 结论：最该做成可替换的是 embedding 那一层，理由不是「设计模式」，而是「换模型这件事真的会发生，且发生时代价极高」。
  5. 顺手点出抽象的代价：每多一层间接就多一次跳转和一份心智负担，所以判据是「那件事会不会真的发生」，不会发生的别抽象。
  6. 可预期的追问：那生成模型要不要也抽象？答案是要，但优先级低——换生成模型不需要重算任何存量数据，回滚也便宜，所以它是配置项而不是一层接口。

  How to reason about it · think before answering

  1. This question separates people who have maintained such a system from people who have only built a demo. Reciting the pipeline diagram is not an answer; where you cut it is.
  2. Offer a reusable criterion first: cut where a layer is most likely to be replaced wholesale, not by lines of code or by tidy functional names.
  3. Apply it. Embedding models change several times a year, and each change invalidates every stored vector, so that layer must be an interface. Storage may move from PostgreSQL to a dedicated vector database, and both ingestion and query talk through it, so it is the single shared boundary. Chunking changes daily during tuning, so it belongs in config, not in code.
  4. Conclusion: the embedding layer is the one that must be swappable, because the swap is both likely and expensive, not because interfaces are good style.
  5. Name the cost of abstraction too: every indirection is one more hop while debugging, so the test is whether the change will actually happen.
  6. Expected follow-up: should the generation model be abstracted as well? Yes, but at lower priority, because swapping it does not force recomputation of stored data and rollback is cheap. It is a config value, not a layer.

  答题要点

  • 先给判据：切口落在最可能被整体替换的那一层，不按代码量或功能名称均分。
  • embedding 是最该抽象的一层：换模型意味着存量向量全部作废、必须全量重算，代价高且真的会发生。
  • 存储层是摄取与查询唯一的交界，接口要先定下来再谈两边实现。
  • 切块与检索路数做成配置项，因为它们在调优期改动最频繁，改一次不该动代码。
  • 抽象有成本，判据是那件事会不会真的发生；不会发生的抽象就是过度设计。

  Key points

  • Lead with the criterion: cut where a layer is most likely to be replaced wholesale.
  • The embedding layer is the one to abstract: swapping models invalidates every stored vector and forces a full recompute.
  • Storage is the single boundary shared by ingestion and query, so define its interface before either implementation.
  • Chunking and retrieval routes belong in configuration because they change most often during tuning.
  • Abstraction costs indirection, so only abstract changes that will actually happen.

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

D1 一条 AI 短剧生产线长什么样：工序拆解、任务图架构与四类生成模型选型

• 为什么要在厂商 SDK 之上再套一层自己的 provider 接口？什么时候这层反而是负担？Why wrap a vendor SDK in your own provider interface, and when does that layer become a liability?

  国内高频海外高频基础#provider-abstraction#architecture

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

  1. 这题在筛「有没有真的换过一次厂商」。只答「解耦、方便替换」的人，说的是一句所有人都会说的话，区分度在于你能不能给出「这层带来了什么、又赔上了什么」的具体清单。
  2. 怎么拆：先问自己「如果不套这层，哪些能力会散掉」。答案有三样，而且都能落到具体文件上——离线可跑（网络出口收敛到一处才可能打桩）、多厂商并存（业务代码写的是动作而不是某家的四步流程）、计量收口（每次调用的花费必须有唯一一处记账）。
  3. 接着说抽象的位置：接口要按业务动作定义，不按厂商的 HTTP 请求定义。异步视频任务的提交、轮询、取件、下载四步，对业务代码来说是一个 generate；把这四步漏到业务层，抽象就白做了。
  4. 结论与代价：这层会磨掉各家的独有能力（某家支持首尾帧、某家支持结构化运镜参数）。正确处理不是把接口撑大，而是留一个可选透传字段，让需要它的那一处显式承认自己绑定了某一家。
  5. 什么时候是负担：你只会用一家、也永远不会离线跑的时候；以及出现两个信号时——为加一个厂商改了接口签名让另外三个实现跟着改，或者接口里出现了只有一家有的参数名。这两个信号说明抽象抽在了厂商能力的最小公倍数上，位置错了。
  6. 可预期的追问：那要不要直接用某个统一网关或聚合 SDK？可以，但你仍然需要自己的接口，因为聚合层解决的是协议差异，解决不了你自己的落盘契约与记账口径。

  How to reason about it · think before answering

  1. The screen is whether you have ever actually swapped a vendor. Answering only decoupling and easy replacement is what everyone says; the signal is naming what the layer buys and what it costs.
  2. How to break it down: ask what you lose without the layer. Three concrete things — offline runnability (you can only stub when network egress is funneled into one place), multi-vendor coexistence (business code expresses an action, not one vendor's four-step flow), and metering (every call's cost must be recorded in exactly one place).
  3. Then place the abstraction: define it by business action, not by the vendor's HTTP request. Submit, poll, retrieve, download for an async video job is one generate to the caller; leaking those four steps upward defeats the purpose.
  4. Conclusion and cost: the layer sands off vendor-specific capabilities, such as first-and-last-frame conditioning or structured camera parameters. The fix is not a wider interface but one optional passthrough field, so the single call site explicitly admits it is vendor-bound.
  5. When it is a liability: single vendor forever and no offline path. Two warning signs — adding a vendor forced a signature change across the other implementations, or a vendor-only parameter name appeared in the interface. Both mean you abstracted the least common multiple of vendor features.
  6. Likely follow-up: why not just use an aggregation gateway or SDK? You still need your own interface, because aggregators normalize protocols but not your on-disk artifact contract or your cost ledger.

  答题要点

  • 三个理由要说具体：离线可跑、多厂商并存、计量收口，每一个都对应一处真实代码
  • 接口按业务动作定义，异步任务的提交轮询取件下载四步必须关在实现里
  • 把落盘路径写进接口契约，因为厂商返回的图片与视频链接都是会失效的临时链接
  • 代价是磨掉独有能力，用可选透传字段处理，而不是撑大公共接口
  • 两个「抽错了」的信号：加厂商要改签名、接口里出现厂商专有参数名

  Key points

  • Name three concrete reasons: offline runnability, multi-vendor coexistence, and a single metering point
  • Define the interface by business action; submit-poll-retrieve-download stays inside the implementation
  • Put the output file path in the contract, because vendor image and video URLs are short-lived temporary links
  • The cost is losing vendor-specific features; handle it with one optional passthrough field, not a fatter interface
  • Two signs you abstracted wrong: adding a vendor changes the signature, or a vendor-only parameter leaks into the interface

D8 工作流引擎：把流水线做成可断点续跑的任务图

• 什么时候该自己写调度，什么时候该直接上现成的工作流引擎？When should you write your own scheduler, and when should you adopt an off-the-shelf workflow engine?

  国内高频海外高频基础#architecture#build-vs-buy#workflow-engine

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

  1. 这题考的是技术选型的成熟度。两个极端都会被扣分：什么都自己写显得不懂杠杆，什么都上框架显得没判断力。面试官想听的是你的切换信号是什么。
  2. 先给一条通用判据：自己写的收益是理解和贴合，框架的收益是省掉你还没遇到的那些问题。所以决策取决于「你现在需要的功能有多少落在框架的核心能力上」。
  3. 自己写划算的情形：单机、节点数是个位数、路径是你定死的、需要的只是拓扑排序加幂等加状态落盘这几件事。这时候自己写不到三百行，而且换来的理解是通用的——你会彻底搞懂幂等键为什么要包含依赖指纹、状态为什么必须每步落盘。
  4. 该换的三个信号：一是开始需要跨机器调度，自己实现分布式调度的复杂度是指数级上升的；二是开始需要人工介入节点，流程要挂起几小时甚至几天，状态必须外置到数据库而不是一个 JSON 文件；三是开始需要给非工程师看和操作，那你需要的其实是一个带界面的产品。
  5. 反过来说，过早引入重型框架的代价很具体：每一个业务改动都要先绕过它的抽象，而它的收益要等规模上来才兑现。这是典型的成本前置、收益后置。
  6. 可预期的追问是「自己写的那一套能不能平滑迁走」。答：能，前提是你从一开始就把节点定义成纯声明（依赖、输入、产物、执行体），调度和状态不侵入业务。这样迁移时改的是引擎，不是六个节点。

  How to reason about it · think before answering

  1. This tests selection maturity. Both extremes lose points: building everything yourself shows no sense of leverage, adopting a framework for everything shows no judgment. The interviewer wants your switching signals.
  2. Give a general criterion: writing it yourself buys understanding and fit; a framework buys you past problems you have not hit yet. So the decision hinges on how much of what you need overlaps with the framework's core.
  3. Writing your own pays off when: single machine, a handful of nodes, a path you fixed yourself, and you only need topological ordering plus idempotency plus state persistence. That is under three hundred lines, and the understanding transfers to any engine you adopt later.
  4. Three signals to switch: you need cross-machine scheduling, where rolling your own scales in complexity exponentially; you need human-in-the-loop nodes, so runs suspend for hours or days and state must live in a database rather than a JSON file; or non-engineers need to see and operate it, in which case you need a product with a UI, not an engine.
  5. Conversely, adopting a heavy framework too early has a concrete cost: every business change must route around its abstractions, while its benefits only land at scale. Cost up front, payoff deferred.
  6. Expect the follow-up 'can you migrate off your own version cleanly'. Yes, if nodes were declarative from the start — dependencies, inputs, outputs, body — with scheduling and state kept out of the business code. Then migration replaces the engine, not the nodes.

  答题要点

  • 判据是你需要的功能与框架核心能力的重叠度，不是「自研还是选型」的立场。
  • 自己写划算：单机、节点数少、路径固定，只需要拓扑排序加幂等加状态落盘。
  • 该换的三个信号：跨机器调度、人工介入导致流程长时间挂起、非工程师要操作。
  • 过早上重型框架的代价是每次业务改动都要绕过它的抽象，收益却要等规模。
  • 把节点写成纯声明，调度与状态不侵入业务，将来迁移改的是引擎而不是节点。

  Key points

  • Decide by how much your needs overlap the framework's core, not by a build-versus-buy stance.
  • Rolling your own wins on a single machine with few nodes and a fixed path, needing only topo order, idempotency and state persistence.
  • Three switching signals: cross-machine scheduling, human-in-the-loop suspension, and non-engineers needing to operate it.
  • Adopting a heavy framework early costs a detour around its abstractions on every change, with benefits deferred to scale.
  • Keep nodes declarative and scheduling non-invasive so a later migration replaces the engine, not the nodes.