逐日AI

面试题库

共 328 题,当前筛选 1 题。

标签
还有 361 个标签
#api-design9#coding-agent9#distributed-systems8#multi-agent8#rag8#chunking7#debugging7#pipeline-design7#structured-output7#agent-loop6#mcp6#operations6#prompt-injection6#sse6#tool-calling6#tool-design6#context5#context-engineering5#deployment5#embeddings5#hybrid-search5#message-bus5#scheduling5#system-prompt5#agentic-rag4#behavioral4#client4#concurrency4#consistency4#framework-design4#ingestion4#prompt-engineering4#rate-limiting4#retrieval4#routing4#trade-offs4#abstention3#agents-sdk3#caching3#communication3#context-window3#cost-control3#data-quality3#failure-modes3#image-generation3#interview-prep3#langgraph3#latency3#llm-as-judge3#long-context3#model-migration3#model-routing3#orchestration3#ordering3#progressive-disclosure3#prompt-basics3#prompt-caching3#protocol3#provider-abstraction3#ranking3#recall3#redis-streams3#responses-api3#resume3#retry3#runtime3#scalability3#skills3#state-management3#statelessness3#subagents3#timeline3#versioning3#workflow-engine3#access-control2#agent-design2#async-task2#auth2#checkpointing2#citation-verification2#citations2#claude-md2#code-review2#compaction2#context-rot2#contextual-retrieval2#cost-tradeoff2#data-modeling2#database2#distribution2#fallback2#ffmpeg2#golden-set2#grounding2#interview-process2#llm-basics2#long-term-memory2#media-pipeline2#memory2#multi-hop2#multi-tenancy2#oauth2#prioritization2#project-storytelling2#prompt-techniques2#query-rewriting2#react2#refusal2#reproducibility2#rerank2#retrieval-quality2#retrospective2#scripts2#sharding2#state-machine2#tool-permissions2#tooling2#tools2#tracing2#transport2#tts2#ux2#vector-database2#verification2#workflow2#agent-basics1#agent-quality1#agent-sdk1#agents-md1#altitude1#analytics1#approvals1#architecture-review1#async1#atomicity1#attention-budget1#av-sync1#backoff1#bi-encoder1#bm251#budget-control1#build-vs-buy1#cancellation1#candidate-selection1#capacity-planning1#career1#chain-of-thought1#ci1#circuit-breaker1#claude-code1#cli-design1#client-integration1#cloud1#compliance1#compression1#configuration1#confused-deputy1#consistent-hashing1#content-hash1#content-safety1#context-assembly1#context-compression1#context-management1#copyright1#coreference1#correctness1#cost-accounting1#cost-analysis1#cost-optimization1#cross-encoder1#cross-model1#customer-support1#dag1#decision-making1#decomposition1#degradation1#deliberate-practice1#design1#diagnostics1#dimensions1#docker1#documentation1#embedding-migration1#encoding1#engineering-judgement1#engineering-tradeoffs1#error-propagation1#escalation1#eval1#event-driven1#evidence1#failure-analysis1#fairness1#faithfulness1#fan-out1#feedback-loop1#fencing-token1#few-shot1#filter-pushdown1#filtering1#fine-tuning1#forking1#four-elements1#framework-selection1#frontend1#global-market1#graph-rag1#guardrails1#hallucination1#handoff1#handoffs1#headless1#hnsw1#hooks1#human-in-the-loop1#hybrid1#hyde1#incremental-recompute1#incremental-sync1#index-maintenance1#index-routing1#indexing1#information-retrieval1#instruction-hierarchy1#integration1#intent-routing1#interrupt-merge1#invalidation1#isolation1#iterative-scan1#ivfflat1#json-parsing1#json-schema1#just-in-time1#jwt1#knowledge-organization1#labeling1#latency-budget1#lease1#least-privilege1#llm-output-quality1#long-session1#loop-guard1#maintenance1#mcp-basics1#mental-model1#messages-api1#metadata1#methodology1#metrics1#migration1#mobile1#model-selection1#moderation1#modularity1#multi-turn1#multimodal1#nodejs1#normalisation1#notifications1#ocr1#offline-testing1#openai1#overlap1#pagination1#parent-child1#pdf-parsing1#performance1#permissions1#persistence1#pgvector1#pipeline-reliability1#portfolio1#primitives1#priority-queue1#proactive-messaging1#product-engineering1#production-readiness1#prompt1#prompt-assembly1#prompt-bloat1#prompt-design1#prompt-limits1#prompt-surface1#prompt-template1#prompt-versioning1#prompting1#protocol-versions1#quality1#quality-check1#quantization1#query-transformation1#quiet-hours1#rag-basics1#rank-fusion1#reasoning1#reconnect1#redis1#reflection1#replay1#reporting1#retrieval-failure1#retrieval-metrics1#retry-semantics1#retry-strategy1#review1#risk-assessment1#rollback1#rollout1#rrf1#safety1#sandbox1#sandboxing1#scaling1#schema-design1#schema-validation1#scoping1#secrets-management1#self-assessment1#self-introduction1#self-presentation1#self-reflection1#server-design1#service-architecture1#session-management1#sessions1#similarity1#skill-authoring1#skill-design1#spec1#split-brain1#stakeholder-communication1#star1#state-persistence1#stateless1#stdio-transport1#stopping-criteria1#storytelling1#subagent1#subscriptions1#subtitles1#task-graph1#team-governance1#test-set1#test-strategy1#testing1#thresholds1#timezone1#token-accounting1#token-budget1#tool-budget1#tool-execution1#tool-naming1#tool-schema1#trust-boundary1#tuning1#validation1#vector-index1#workflow-design1#xml-tags1#zero-downtime1

7 天 Agent Skills:把经验做成可复用能力

D2 写第一个 skill:description 的触发词怎么写、结构怎么分层、怎么装进客户端

  • skill 的 description 写得太泛会怎样?太窄又会怎样?你怎么找到中间那个点?What goes wrong when a skill description is too broad, and what goes wrong when it is too narrow? How do you find the middle?
    国内高频海外高频进阶#agent-skills#skill-description

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

    1. 这题的题眼在「代价」两个字。只说「太泛会误触发、太窄会不触发」是把题目复述了一遍,面试官等的是后面那句:误触发到底损失了什么。
    2. 先说太泛的代价,而且要说满三层:这个 skill 的正文白占了上下文位置;它的指令会干扰当前任务;更麻烦的是模型一旦选定了一个 skill,就更不容易再去选真正对的那个。**一个太泛的 skill 会拖累整个技能库**,这一句是拿分点。
    3. 再说太窄的代价:它只在用户按你预想的说法提问时才触发,而真实用户几乎不会那样说话。太窄的 skill 通常不是不好用,是根本没被用过,所以你连它不好用都不知道。
    4. 找中间点的方法要给成一套动作而不是感觉:写覆盖多种说法而不是多个关键词,末尾补一句边界排除相邻能力,然后用一组正例加近似负例把触发率量出来,按结果改描述。
    5. 补一个容易被忽略的事实:有些任务简单到模型觉得自己就能干,这时候描述写得再匹配也不会触发。判断描述好不好之前,先确认这个任务值不值得一个 skill。
    6. 可预期的追问是「改描述时怎么避免过拟合」。答案是不要把失败查询的原话抄进描述,要归纳出它代表的那一类说法,并留一部分查询不参与优化、只用来验证。

    How to reason about it · think before answering

    1. The hinge word is cost. Saying too broad misfires and too narrow never fires just restates the question; the interviewer wants to know what a misfire actually costs.
    2. Give three layers of cost for over-broad descriptions: the body wastes context, its instructions interfere with the current task, and once the model has committed to one skill it is less likely to reach for the right one. One over-broad skill degrades the whole library.
    3. For too narrow: it only fires when the user phrases things exactly as you imagined, and real users never do. Such a skill is usually not bad, it is simply never exercised, so you never learn that it is bad.
    4. Give the middle as a procedure, not a feeling: cover phrasings rather than keywords, add a boundary clause that excludes adjacent capabilities, then measure trigger rate against positives and near-miss negatives and revise from the data.
    5. Add the often-missed fact that agents typically only consult skills for tasks beyond what they handle alone, so a trivially easy task will not trigger no matter how well the description matches.
    6. Expected follow-up: how do you avoid overfitting when revising? Never paste the failing query verbatim; generalize to the category it represents, and hold out a validation split.

    答题要点

    • 太泛的三层代价:占上下文、干扰当前任务、挤掉真正该用的那个 skill。
    • 太窄的代价是根本没被触发过,问题被掩盖,你连它好不好用都测不出来。
    • 写法上覆盖「多种说法」而不是「多个关键词」,末尾补一句边界排除相邻能力。
    • 用正例加近似负例量出触发率,按数据改描述,不靠手感。
    • 任务本身太简单时不会触发任何 skill,这不是描述的问题。

    Key points

    • Three costs of over-broad: wasted context, interference with the current task, and crowding out the correct skill.
    • Over-narrow means it never fires, which hides the problem rather than surfacing it.
    • Cover phrasings rather than keywords, and add a closing boundary clause that excludes adjacent capabilities.
    • Measure trigger rate with positives and near-miss negatives, then revise from the data.
    • A task simple enough for the model alone will not trigger any skill; that is not a description problem.