逐日AI

面试题库

共 328 题,当前筛选 1 题。

标签
还有 235 个标签
#idempotency5#streaming5#structured-output5#chunking4#deployment4#distributed-systems4#rag4#system-prompt4#tool-calling4#client3#embeddings3#failure-modes3#ingestion3#mcp3#message-bus3#operations3#progressive-disclosure3#ranking3#timeline3#agent-loop2#agentic-rag2#agents-sdk2#caching2#citations2#code-review2#communication2#concurrency2#consistency2#context2#context-engineering2#context-rot2#cost-control2#data-modeling2#grounding2#hybrid-search2#langgraph2#latency2#model-migration2#model-routing2#multi-agent2#ordering2#pipeline-design2#prompt-basics2#prompt-engineering2#protocol2#rate-limiting2#react2#redis-streams2#responses-api2#retrieval2#retrieval-quality2#routing2#runtime2#sse2#state-management2#statelessness2#subagents2#system-design2#tool-design2#tooling2#tracing2#trade-offs2#transport2#vector-database2#versioning2#workflow2#abstention1#access-control1#agent-design1#agent-quality1#altitude1#approvals1#async1#async-task1#atomicity1#attention-budget1#auth1#av-sync1#behavioral1#bm251#candidate-selection1#capacity-planning1#chain-of-thought1#checkpointing1#ci1#citation-verification1#claude-code1#cli-design1#cloud1#compaction1#compression1#content-hash1#context-compression1#context-window1#contextual-retrieval1#cost-optimization1#cross-model1#dag1#data-quality1#database1#decision-making1#decomposition1#degradation1#deliberate-practice1#design1#diagnostics1#dimensions1#distribution1#docker1#documentation1#engineering-judgement1#engineering-tradeoffs1#eval1#event-driven1#fallback1#fan-out1#ffmpeg1#forking1#four-elements1#framework-selection1#golden-set1#hallucination1#handoffs1#headless1#hnsw1#hybrid1#hyde1#image-generation1#incremental-recompute1#incremental-sync1#index-maintenance1#index-routing1#indexing1#information-retrieval1#instruction-hierarchy1#intent-routing1#interrupt-merge1#interview-prep1#invalidation1#isolation1#ivfflat1#just-in-time1#knowledge-organization1#lease1#llm-as-judge1#llm-output-quality1#long-context1#loop-guard1#media-pipeline1#metadata1#metrics1#mobile1#model-selection1#multi-tenancy1#multimodal1#nodejs1#orchestration1#pagination1#parent-child1#pdf-parsing1#performance1#permissions1#persistence1#pgvector1#pipeline-reliability1#portfolio1#prioritization1#production-readiness1#prompt-assembly1#prompt-caching1#prompt-injection1#prompt-limits1#prompt-techniques1#prompt-template1#prompt-versioning1#provider-abstraction1#quality-check1#quantization1#query-transformation1#quiet-hours1#rank-fusion1#reasoning1#recall1#redis1#reflection1#refusal1#reporting1#reproducibility1#rerank1#retrieval-failure1#retrieval-metrics1#retry1#retry-semantics1#retry-strategy1#review1#rollback1#rrf1#sandbox1#sandboxing1#scalability1#scheduling1#schema-design1#scoping1#scripts1#secrets-management1#self-assessment1#self-presentation1#self-reflection1#service-architecture1#session-management1#sessions1#sharding1#skill-authoring1#skill-description1#skills1#spec1#state-machine1#stateless1#stopping-criteria1#subtitles1#task-graph1#team-governance1#testing1#tool-budget1#tool-execution1#tool-naming1#tools1#tts1#tuning1#ux1#validation1#vector-index1#verification1#workflow-engine1#xml-tags1

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

D3 Pi SDK 上手:三层架构、Agent Loop 对照(dg P01/P02/M02/M03)

  • 选择使用 Agent 框架还是手写 Agent,你会怎么权衡?How do you decide between adopting an agent framework and hand-rolling the loop?
    国内高频海外高频进阶#framework-design#engineering-tradeoffs

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

    1. 题眼在「权衡」。答「框架更快」或者「手写更可控」都只说了一半,面试官想听的是你有没有一条能当场执行的判据,而不是立场。
    2. 给判据:问自己「我需不需要看见并改动这段循环里的每一步」。需要就手写——学习调试阶段、合规审计要求每次模型调用和工具调用都可拦截可留痕、或者场景本身只有一两个工具两三轮循环,那点代码量的收益抵不过一整棵依赖树。
    3. 不需要就用框架,判断标准是这几件事你是不是迟早都要做:工具数量上去、要把每一步实时推给前端、会话要能重启后继续、上下文满了要压缩、要随时换模型。这些凑齐了就是一个小型框架,自己写等于重新发明一个没人帮你测的版本。
    4. 然后主动说出框架的三笔代价,这是区分度所在:一是排障栈变深,工具没被调用可能是描述、schema、钩子拦截三种完全不同的原因;二是你继承了一堆没写过的默认值,模型、系统提示词、内置工具都是别人替你选的;三是升级会改变你没测过的行为,代码一行没动线上表现却变了,这类问题最难定位。
    5. 结论要给出可落地的折中:先手写一遍把循环吃透,再上框架;上了框架也要显式覆盖掉默认值,并把框架版本锁死。这样既拿到了开发速度,也没把行为的控制权整个交出去。
    6. 可以预期的追问:那你怎么评估一个框架好不好?答看它的分层能不能让你「只要一半」——只要模型调用层、循环自己写行不行;必须整包吞下的框架,迟早要为用不上的那一半付代价。

    How to reason about it · think before answering

    1. The hinge word is 'decide'. 'Frameworks are faster' and 'hand-rolling is more controllable' are each half an answer; what earns points is a criterion you can apply on the spot rather than a preference.
    2. Offer the criterion: ask whether you need to see and change every step inside the loop. If yes, hand-roll — during learning and debugging, under compliance rules that require every model call and tool call to be interceptable and auditable, or when the scenario really is two tools and three turns and the saved lines do not justify a large dependency tree.
    3. If no, take the framework, and justify it by what you will inevitably need anyway: more tools, streaming every step to a UI, sessions that survive a restart, compaction when context fills up, swapping models on demand. Assemble all of those yourself and you have written a small framework — an untested one.
    4. Then volunteer the three costs, which is where the signal is: debugging spans more layers, so a tool that never runs could be a bad description, a schema rejection, or a hook that blocked it; you inherit defaults you never wrote, including the model, the system prompt, and the built-in tools; and upgrades change behavior you never tested, which is brutal to diagnose because your own code did not change.
    5. Land on a practical middle: hand-roll once to internalize the loop, then adopt a framework, override its defaults explicitly, and pin its version. You keep the delivery speed without handing over control of behavior.
    6. Expect the follow-up: how do you judge a framework? By whether its layering lets you take only half of it — model layer only, loop your own. Anything you must swallow whole will eventually bill you for the half you do not use.

    答题要点

    • 判据是「需不需要看见并改动循环里的每一步」,需要就手写,不需要就用框架
    • 手写更合适:学习调试、合规要求每步可拦截可留痕、场景极简、对依赖体积与冷启动敏感
    • 框架更合适:工具多、要事件流、要会话持久化与压缩、要多模型——这些凑齐等于自己造一个框架
    • 框架的三笔代价:排障栈变深、继承一堆没写过的默认值、升级会改变没测过的行为
    • 折中做法:先手写吃透循环再上框架,显式覆盖默认值并锁死版本

    Key points

    • The criterion is whether you need to see and modify every step of the loop
    • Hand-roll for learning and debugging, for compliance that demands interceptable and auditable steps, for genuinely tiny scenarios, and where dependency size or cold start matters
    • Use a framework once you need many tools, an event stream, persistent sessions, compaction, and model swapping — building all of that is writing a framework yourself
    • Three costs: deeper debugging surface, inherited defaults you never wrote, and upgrades that shift untested behavior
    • The middle path: hand-roll once, then adopt, override defaults explicitly, and pin the version