面试题库
共 328 题,当前筛选 3 题。
课程全部30 天从前端工程师到 Agent 工程师5 天提示词工程零基础Claude 高效使用:从对话到 Claude CodeCodex 与 OpenAI Agents SDK 高效使用7 天 MCP:把工具接进任何 Agent7 天 Agent Skills:把经验做成可复用能力5 天上下文工程14 天 RAG:从检索到可信回答14 天用 Agent 搭一条 AI 短剧生产线
标签
全部#progressive-disclosure3#cost14#evaluation14#reliability12#agent-skills11#architecture11#observability10#error-handling9#security9#api-design6#coding-agent6#debugging5
还有 235 个标签收起标签
#idempotency5#streaming5#structured-output5#chunking4#deployment4#distributed-systems4#rag4#system-prompt4#tool-calling4#client3#embeddings3#failure-modes3#ingestion3#mcp3#message-bus3#operations3#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-design1#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
7 天 Agent Skills:把经验做成可复用能力
D1 Skills 是什么:SKILL.md 规范、目录结构与三阶段渐进式加载
渐进式加载的三个阶段分别加载什么?为什么不能一次性把所有 skill 全加载进去?What does each of the three progressive disclosure stages load, and why not just load every skill up front?
国内高频海外高频进阶#agent-skills#progressive-disclosure分析过程 · 先想清楚再作答
- 这题在考你对机制的记忆精度,同时也在考工程感。只背出三个阶段的名字拿不到分,要说出每一阶段加载的**是哪些字段、哪些文件**。
- 拆法很简单,按加载的粒度从粗到细数:阶段一只加载 name 与 description,量级是每个 skill 五十到一百个 token;阶段二加载整份 SKILL.md 正文,建议不超过五千 token 与五百行;阶段三按文件粒度加载脚本、引用与资源。
- 回答「为什么不全加载」时给一个具体的数:二十个 skill 各三千 token 的正文加上引用文件,全量是十几万 token,超过很多模型的窗口,而且每一轮都要重发。渐进式加载后总量落在一万上下。
- 补一条更本质的理由:省下来的不只是钱,是窗口位置。腾出来的空间要留给真正在做的这件事的代码和数据,这就是上下文工程的核心取舍。
- 可预期的追问是「阶段三怎么触发」。答案是正文里必须写明读取条件——写「细节见 references 目录」等于没写,写「接口返回非 200 时读 references 里的错误码文件」才真正把时机交给了模型。
How to reason about it · think before answering
- This tests both recall precision and engineering sense. Naming the three stages is not enough; say which fields and which files each stage pulls in.
- Order them by granularity: stage one loads only name and description, roughly fifty to a hundred tokens per skill; stage two loads the full SKILL.md body, recommended under five thousand tokens and five hundred lines; stage three loads individual scripts, references and assets.
- Answer the why with a number: twenty skills at three thousand tokens of body plus reference files is well over a hundred thousand tokens, past many context windows, and resent every turn. Progressive loading lands around ten thousand.
- Add the deeper reason: what you save is window space, not just money, and that space belongs to the actual task.
- Expected follow-up: how does stage three fire? The body must state the loading condition. See the references folder is useless; read the error-code reference when the API returns a non-200 hands the timing to the model.
答题要点
- 阶段一发现:只加载 name 与 description,每个 skill 约五十到一百 token。
- 阶段二激活:读入完整 SKILL.md 正文,建议不超过五千 token 与五百行。
- 阶段三执行:按需读取 scripts、references、assets 里的单个文件,不是整目录倒进来。
- 全量加载会撑爆窗口且每轮重发,渐进式加载能把量级压到十分之一左右。
- 阶段三能不能被触发,取决于正文有没有写清「什么条件下读哪个文件」。
Key points
- Discovery: only name and description, about fifty to a hundred tokens per skill.
- Activation: the full SKILL.md body, ideally under five thousand tokens and five hundred lines.
- Execution: individual files from scripts, references or assets, loaded one at a time on demand.
- Loading everything up front blows the window and is resent every turn; progressive loading cuts it to roughly a tenth.
- Stage three only fires if the body spells out which file to read under which condition.
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分析过程 · 先想清楚再作答
- 这题在考你有没有把渐进式加载当成一个可实现的机制,而不是一句口号。只复述「发现、激活、执行」三个词是不够的,要落到每一步读了什么、写进了哪里。
- 发现:扫描约定目录,把所有含 SKILL.md 的文件夹找出来,解析出名字与描述,拼成一份清单注入系统提示。**这一步正文一个字都不进来**,清单里只有名字、描述、位置三样。
- 激活:模型判断当前任务命中了某条描述,才去读那一份完整的 SKILL.md,把正文放进上下文,同时告诉它技能目录在哪、附带哪些资源文件。
- 分两步的理由是成本结构不对称,这是本题的核心句:**披露的成本每一轮都要付,激活的成本只付一次。** 系统提示随每次请求重发,清单每多一个字都要乘会话轮数;正文只在被激活的那一轮进上下文,之后作为历史消息留着。
- 由这条不对称性可以顺手解释规范里的硬约束:为什么描述有长度上限而正文没有,为什么描述必须写触发条件而不是使用说明——描述是每轮都在花钱的那一段。
- 可预期的追问是「位置这一项能不能省」。不能:模型要靠它知道去读哪个文件,而且它的父目录是正文里所有相对路径的解析基准。
How to reason about it · think before answering
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
5 天上下文工程
D2 系统提示与指令层次:高度适中、持久指令文件、渐进披露,少即是多
哪些内容该进系统提示,哪些该进持久指令文件,哪些该按需加载?What belongs in the system prompt, what belongs in a persistent instruction file, and what should be loaded on demand?
国内高频海外高频进阶#instruction-hierarchy#progressive-disclosure分析过程 · 先想清楚再作答
- 这题在考分层意识。只回答「常用的放系统提示」是循环论证——问题恰恰是怎么定义常用。面试官想听的是一条排序明确的判定流程。
- 怎么拆:给三问,第一个答是就落定。第一问,模型不看这条会做错吗,不会就删除;第二问,是不是每一类任务都用得上,不是就下沉到引用文件、主提示里只留一句索引;剩下的保留,并重写成能被机械核对的一句话。
- 补一层常被漏掉的划分:还有一类内容根本不属于以上三者——随时间变化的运行时事实,比如当前是不是夜间、是不是节假日延迟期、本次会话的订单号。它们看着像规则,写死在系统提示里就会在半天之后开始骗用户,应该由工具返回或每次拼进用户消息。
- 结论:判据是稳定程度加使用频率。越稳定越靠前,越少用越靠后;而每次都变的东西根本不进系统提示。附带一个工程收益——按稳定程度排序之后,缓存前缀才有机会命中,改一条任务变量不会打掉整段缓存。
- 可预期的追问:下沉是不是比删除安全?不是。搬进引用文件的内容仍然要维护、仍然会在需要时占上下文,只是晚一点少一点。真正没用的条目要删,「先留着以防万一」正是提示词膨胀的主因。
How to reason about it · think before answering
- This tests layering. Answering that frequently used content goes in the system prompt is circular, since defining frequently used is the actual question. Give an ordered decision procedure instead.
- Three questions, first yes wins. Would the model get it wrong without this rule? If not, delete. Is it needed for every class of task? If not, push it into a reference file and leave a one-line index. Whatever remains stays, rewritten as a mechanically checkable sentence.
- Add the category people miss: runtime facts that change over time, such as whether it is currently night hours, whether holiday shipping delays apply, or this session's order id. They look like rules but start lying to users hours later. They belong in tool output or in the user message.
- Conclusion: sort by stability and frequency. The more stable, the earlier; the rarer, the later; anything that changes every call never enters the system prompt. Bonus: this ordering is what makes a cache prefix hittable, so editing a task variable does not invalidate everything.
- Expect the follow-up: is pushing content down safer than deleting it? No. Reference files still have to be maintained and still consume context when read, just later and less often. Keeping things just in case is the main cause of prompt bloat.
答题要点
- 三问定去处:模型不看会做错吗(不会就删)、每类任务都用得上吗(不是就下沉)、剩下的保留并重写成可核对的一句话。
- 第四类是运行时事实(时间、节假日、本次订单号),不属于系统提示,应由工具返回或拼进用户消息。
- 分层顺序按稳定程度排,稳定的在前,这样缓存前缀才有机会命中。
- 下沉不是免罪符:引用文件仍要维护、仍会占上下文,没用的要删掉。
Key points
- Three questions decide placement: would the model err without it (no means delete), is it needed by every task class (no means push down), and the rest stays as a checkable sentence.
- A fourth category is runtime fact (time of day, holiday delays, this session's order id); it belongs in tool output or the user message, not the system prompt.
- Order layers by stability so the cache prefix stays hittable.
- Pushing down is not free: reference files still cost maintenance and context, so genuinely useless rules should be deleted.