逐日AI

面试题库

共 328 题,当前筛选 3 题。

标签
还有 362 个标签
#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#llm-basics3#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#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#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#sampling1#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-description1#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:把经验做成可复用能力

D5 手写一个 skill 运行时:扫描、frontmatter 解析、注入系统提示、按需读取正文

  • 如果让你自己给一个 Agent 实现 skill 支持,发现阶段和激活阶段各要做什么?为什么要分成两步?If you implemented skill support in your own agent, what happens in the discovery stage versus the activation stage, and why split them?
    国内高频海外高频进阶#agent-skills#runtime#progressive-disclosure

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

    1. 这题在考你有没有把渐进式加载当成一个可实现的机制,而不是一句口号。只复述「发现、激活、执行」三个词是不够的,要落到每一步读了什么、写进了哪里。
    2. 发现:扫描约定目录,把所有含 SKILL.md 的文件夹找出来,解析出名字与描述,拼成一份清单注入系统提示。**这一步正文一个字都不进来**,清单里只有名字、描述、位置三样。
    3. 激活:模型判断当前任务命中了某条描述,才去读那一份完整的 SKILL.md,把正文放进上下文,同时告诉它技能目录在哪、附带哪些资源文件。
    4. 分两步的理由是成本结构不对称,这是本题的核心句:**披露的成本每一轮都要付,激活的成本只付一次。** 系统提示随每次请求重发,清单每多一个字都要乘会话轮数;正文只在被激活的那一轮进上下文,之后作为历史消息留着。
    5. 由这条不对称性可以顺手解释规范里的硬约束:为什么描述有长度上限而正文没有,为什么描述必须写触发条件而不是使用说明——描述是每轮都在花钱的那一段。
    6. 可预期的追问是「位置这一项能不能省」。不能:模型要靠它知道去读哪个文件,而且它的父目录是正文里所有相对路径的解析基准。

    How to reason about it · think before answering

    1. This tests whether progressive disclosure is a mechanism you could build, not a slogan. Repeating the three stage names is not enough; say what each stage reads and where it writes.
    2. Discovery: scan the conventional directories, find every folder containing SKILL.md, parse out name and description, and assemble a catalog injected into the system prompt. No body text enters here; each entry carries only name, description and location.
    3. Activation: once the model judges that a task matches a description, read that full SKILL.md into context, along with the skill directory path and a list of bundled resource files.
    4. The reason for the split is an asymmetry in cost: disclosure is paid every turn, activation is paid once. The system prompt is resent with every request, so each extra character in the catalog is multiplied by the number of turns.
    5. That asymmetry also explains the spec's hard limits: descriptions are capped and bodies are not, and descriptions must state trigger conditions rather than usage instructions, because the description is the part that keeps costing money.
    6. Expected follow-up: can the location field be dropped? No. The model needs it to know which file to read, and its parent directory is the base for every relative path in the body.

    答题要点

    • 发现阶段扫描目录、解析名字与描述、拼成清单注入系统提示,正文不进来。
    • 激活阶段才读完整 SKILL.md,并附上技能目录与资源文件名清单。
    • 分两步的根据是披露每轮付费、激活只付一次这条不对称性。
    • 这条不对称性解释了描述为什么有长度上限、为什么要写触发条件而不是使用说明。
    • 清单里位置字段不能省,它既是读取目标也是相对路径的解析基准。

    Key points

    • Discovery scans directories, parses name and description, and injects a catalog into the system prompt with no body text.
    • Activation reads the full SKILL.md and adds the skill directory plus a list of bundled resource filenames.
    • The split exists because disclosure is paid every turn while activation is paid once.
    • That asymmetry explains why descriptions are length-capped and must state triggers rather than usage.
    • The location field is required: it is both the read target and the base for relative paths.
  • 你的运行时解析到一份不合规范的 SKILL.md,是拒绝加载还是降级加载?另外,两个作用域里有同名 skill 时你怎么处理?When your runtime parses a SKILL.md that violates the spec, do you refuse to load it or degrade gracefully? And how do you handle a name collision across scopes?
    国内高频海外高频进阶#agent-skills#runtime#error-handling

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

    1. 两个小问共用一个立场:**运行时是给人干活的,不是校验器。** 先把这句说出来,后面两半都好答。
    2. 宽松加载这一半要给出可判定的边界,不能只说「尽量宽松」。**唯一的硬性淘汰是缺 description**——少了它这个 skill 在发现阶段没有触发面,永远不会被选中,留在清单里只是白占 token。
    3. 其余一律只告警仍然加载:名字与目录名不一致、名字用了大写或下划线、描述超过上限。它们影响质量,不影响能不能用。
    4. 举一个最常见的畸形做证据:YAML 值里没加引号的冒号会让正规解析器判整行非法,进而拒绝整个文件。正确的兜底顺序是先用完整 YAML 解析,失败了再退回按行取值,只抠出认识的那几个标量字段。
    5. 同名冲突这一半,方向不是重点,**处理方式才是**。跨客户端通行约定是项目级压过用户级,但 Claude Code 的顺序是企业级、个人级、项目级由高到低,两种都合理,关键是固定一种并保持一致。
    6. 最糟的做法是静默丢弃:用户改了项目里那份,行为一点没变,他会去怀疑缓存和保存,就是不会想到别处有个同名的。**必须留一条警告并把两个路径都打出来**,那条日志是排查这类问题的第一现场。
    7. 可预期的追问是「宽松会不会把坏 skill 放进来」。答案是这两件事的层次不同:宽松说的是格式容错,安全靠的是来源信任与工具权限,不能拿格式校验当安全边界。

    How to reason about it · think before answering

    1. Both halves share one stance: a runtime exists to get work done, not to validate. State that first.
    2. For loose loading, give a decidable boundary. The only hard rejection is a missing description: without it the skill has no trigger surface, can never be selected, and only wastes catalog tokens.
    3. Everything else warns and still loads: a name that differs from the directory, a name using capitals or underscores, an over-long description. These hurt quality but not usability.
    4. Cite the most common malformation as evidence: an unquoted colon inside a YAML value makes a strict parser reject the whole file. The right fallback order is full YAML parsing first, then a line-wise field reader that extracts only the scalar fields you know.
    5. For collisions, the direction matters less than the handling. The cross-client convention is project over user, while Claude Code orders enterprise, personal, then project. Both are defensible; pick one and stay consistent.
    6. The worst handling is silent discard. The user edits the project copy, nothing changes, and they suspect caching or a failed save rather than a same-named skill elsewhere. Always log a warning that prints both paths.
    7. Expected follow-up: does loose loading let bad skills in? These are different layers. Looseness is format tolerance; safety comes from source trust and tool permissions, not from schema validation.

    答题要点

    • 立场是运行时不是校验器,默认降级加载。
    • 唯一硬性淘汰是缺 description,因为它没有触发面、永远不会被选中。
    • 名字不一致、名字不合规、描述超长都只记诊断仍然加载。
    • 解析顺序是先完整 YAML、失败再按行取值兜底,专治值里没加引号的冒号。
    • 同名冲突要固定一种优先级并保持一致,绝不静默丢弃,警告里要带上两个路径。

    Key points

    • A runtime is not a validator; degrade by default.
    • The only hard rejection is a missing description, which leaves no trigger surface.
    • Name mismatches, invalid names and over-long descriptions warn but still load.
    • Parse with full YAML first, then fall back to line-wise field reading for unquoted colons.
    • Fix one collision priority, keep it consistent, and never discard silently: log both paths.
  • skill 的正文进了上下文之后,长会话里怎么保证它不失效?激活方式上文件读取和专用工具你会选哪个?Once a skill body is in context, how do you keep it effective across a long session? And would you activate skills by file read or by a dedicated tool?
    国内高频海外高频深入#agent-skills#runtime#long-session

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

    1. 这题考的是「演示能跑」和「上线能用」之间那段距离。前半是长会话的失效模式,后半是激活机制的取舍。
    2. 长会话有两个问题。第一个是重复激活:模型忘了自己读过,第二次又选中同一个 skill,同一段指令出现两遍既浪费又容易在措辞出入时互相干扰。修法是维护一个已激活集合,命中就直接返回。
    3. 第二个问题更要命——**被压缩掉**。压缩会把早期消息换成摘要,skill 正文落在那个区间里**不会报任何错**,模型只是悄悄退回没有这个 skill 的行为。用户看到的现象是「聊到后面它又不按规范写了」,这是这套机制里最难查的一类问题。
    4. 解法是给激活出来的那条消息打一个受保护标记,压缩时整段保留,或者在压缩后重新注入一次。标记本身很简单,难的是记得给它。
    5. 后半的取舍要给判据而不是偏好。文件读取式零新增机制,任何有读文件能力的 Agent 都能立刻支持,这正是这个格式能在几十家客户端铺开的原因;代价是没有明确钩子做去重和保护,模型还可能读错路径。
    6. 专用工具式把激活变成一次可观测可拦截的调用,能在这一步做去重、权限检查、连技能目录与资源清单一起返回;代价是多一个工具定义,且要求宿主愿意开这条通路。**判据是你控不控得住宿主**:自己写 Agent 用工具式,做通用实现用文件读取式。
    7. 可预期的追问是「资源文件要不要在激活时一起读进来」。不要,只列文件名。三阶段的全部价值就在于第三阶段大多数时候不会发生。

    How to reason about it · think before answering

    1. This is about the gap between a working demo and something you can ship. The first half is long-session failure modes, the second is the activation mechanism trade-off.
    2. Two long-session problems. Duplicate activation: the model forgets it already read the skill and selects it again, so the same instructions appear twice, wasting tokens and creating conflicts where the wording differs. Fix it with a set of already-activated names.
    3. The worse problem is compaction. Summarizing early messages can drop the skill body, and nothing errors: the model quietly reverts to its behavior without the skill. Users report that it stopped following the convention later in the conversation, and it is the hardest failure here to diagnose.
    4. The fix is to mark the activated message as protected so compaction preserves it, or to re-inject it afterward. The marker is trivial; remembering to set it is not.
    5. For the second half give criteria, not a preference. File-read activation adds no new mechanism, so any agent that can read files supports skills immediately, which is why the format spread across dozens of clients. The cost is no clean hook for dedup or protection, and the model can read the wrong path.
    6. A dedicated tool turns activation into an observable, interceptable call where you can dedupe, check permissions, and return the skill directory and resource list together. The cost is another tool definition and host cooperation. The criterion is whether you control the host.
    7. Expected follow-up: should resource files be read during activation? No, list filenames only. The value of three stages is that the third usually never happens.

    答题要点

    • 重复激活要靠已激活集合去重,否则同一段指令会出现两遍并互相干扰。
    • 压缩掉 skill 正文不会报错,模型只会悄悄退回原行为,是最难查的失效。
    • 激活出来的消息要打受保护标记,压缩时保留或事后重新注入。
    • 文件读取式零新增机制、兼容性最好,但没有去重与保护的钩子。
    • 专用工具式可观测可拦截,判据是你控不控得住宿主;两者都只列资源文件名,不预读内容。

    Key points

    • Dedupe with a set of activated skills or the same instructions appear twice and conflict.
    • Losing a skill body to compaction raises no error; the model silently reverts, which is the hardest failure to spot.
    • Mark the activated message as compaction-protected, or re-inject after compaction.
    • File-read activation adds no mechanism and has the best compatibility but offers no hook for dedup or protection.
    • A dedicated tool is observable and interceptable; choose by whether you control the host, and in both cases list resource filenames without reading them.