面试题库
共 328 题,当前筛选 1 题。
课程全部30 天从前端工程师到 Agent 工程师5 天提示词工程零基础Claude 高效使用:从对话到 Claude CodeCodex 与 OpenAI Agents SDK 高效使用7 天 MCP:把工具接进任何 Agent7 天 Agent Skills:把经验做成可复用能力5 天上下文工程14 天 RAG:从检索到可信回答14 天用 Agent 搭一条 AI 短剧生产线
标签
全部#tool-execution1#evaluation30#cost29#reliability24#architecture22#agent-skills21#security18#observability15#streaming12#error-handling11#idempotency10#system-design10
还有 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-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-naming1#tool-schema1#trust-boundary1#tuning1#validation1#vector-index1#workflow-design1#xml-tags1#zero-downtime1
30 天从前端工程师到 Agent 工程师
D22 安全:prompt injection、工具最小权限、沙箱思路、密钥管理
Agent 要执行不受信任的代码或命令时,有哪些沙箱隔离思路?你们选了哪一档,为什么?When an agent has to run untrusted code or commands, what sandboxing options do you have? Which tier would you pick and why?
国内高频海外高频进阶#sandboxing#security#tool-execution分析过程 · 先想清楚再作答
- 这题的区分度不在于能背出几种隔离手段,而在于你说不说得出每一档挡住了什么、放过了什么。只说「我们用了沙箱」等于没说,面试官下一句一定是「那它挡得住外发数据吗」。
- 先说清这类工具为什么特殊:白名单管的是「能不能调」,但「执行一段你给的东西」这类工具一旦进了工具表,白名单就退化成一张通行证,因为危险面在参数里不在工具名里。所以要换一种手段——不判断这段代码坏不坏,而是收窄它能触碰的东西。这和权限侧强制是同一个思路,只是对象从工具换成了进程。
- 然后按代价从低到高给三档。进程级:独立子进程、超时必杀、环境变量白名单、只读工作目录;挡住崩溃传染、死循环挂住主进程、密钥被读走;挡不住网络外发和读系统里的其他文件。容器级:无网络、只读 rootfs、非 root、CPU 与内存限额、进程数限额、用完即弃;把外发和越界读写也挡掉;挡不住内核漏洞逃逸。microVM:独立内核的轻量虚拟机,挡住多数逃逸,代价是冷启动和成本。
- 给选型判据,这是面试官真正想听的:代码是你写的、只是参数不可信,进程级够用;代码本身来自模型或用户,最低容器级;要跑第三方任意代码还对外提供服务,上 microVM。
- 点一个高频实现坑:很多人起了子进程就以为隔离了,却把父进程的环境变量整个传过去——进程是独立了,密钥跟着过去了,子进程一句读环境变量就把 API key 打印出来。子进程的环境必须是白名单拷出来的新对象,而不是继承。
- 可以预期的追问:超时之后怎么办?要用能真正杀死进程的信号,并且把「被超时杀掉」当成一个独立的失败类型上报,而不是混进普通报错——它通常意味着有人在试资源耗尽,而不是代码写错了。
How to reason about it · think before answering
- The spread here is not how many isolation techniques you can name, it is whether you can say what each tier stops and what it lets through. 'We use a sandbox' says nothing, and the next question will be 'does it stop data exfiltration?'
- First explain why these tools are special: an allowlist governs whether a tool may be called, but for a tool whose whole job is 'run this thing I hand you', the allowlist degrades into a hall pass, because the danger lives in the arguments rather than the name. So you switch technique — instead of judging whether the code is bad, you shrink what it can reach. Same idea as permission enforcement, applied to a process instead of a tool.
- Then give three tiers by cost. Process level: a separate child process, a hard timeout, an environment-variable allowlist, a read-only working directory; stops crash propagation, hung loops and secret theft; does not stop network exfiltration or reads elsewhere on the host. Container level: no network, read-only rootfs, non-root user, CPU/memory/pid limits, disposable per run; adds exfiltration and out-of-bounds access; does not stop a kernel escape. MicroVM: a lightweight VM with its own kernel, stops most escapes, at the price of cold start and cost.
- Give the selection rule, which is what the interviewer actually wants: if you wrote the code and only the arguments are untrusted, process level is enough; if the code itself comes from the model or a user, container level is the floor; if you run arbitrary third-party code as a service, go to microVM.
- Call out the classic implementation bug: people spawn a child process and assume they are isolated, then hand it the parent's entire environment. The process is separate but the secrets went with it, and one line reading an environment variable prints your API key. The child's environment must be a fresh object copied from an allowlist, never inherited.
- Expect the follow-up: what happens on timeout? Use a signal that actually kills the process, and report 'killed by timeout' as its own failure class rather than folding it into generic errors — it usually means somebody is probing for resource exhaustion, not that the code has a bug.
答题要点
- 执行类工具的危险面在参数里,白名单管不住,要靠隔离:不判断代码坏不坏,而是收窄它能触碰的东西
- 进程级:子进程 + 超时必杀 + 环境变量白名单 + 只读工作目录;挡崩溃、死循环、密钥泄漏,挡不住外发
- 容器级:无网络、只读 rootfs、非 root、CPU 内存与进程数限额、用完即弃;挡外发与越界读写,挡不住内核逃逸
- microVM:独立内核,挡多数逃逸,代价是冷启动与成本;判据是代码来自谁、要不要对外提供服务
- 最常见的实现坑是把 process.env 整个传给子进程——进程隔离了,密钥跟着过去了
Key points
- For execute-style tools the danger is in the arguments, so an allowlist cannot help; isolate instead — shrink what the code can reach rather than judging it
- Process level: child process, hard timeout, environment allowlist, read-only workdir; stops crashes, hangs and secret theft, not exfiltration
- Container level: no network, read-only rootfs, non-root, CPU/memory/pid limits, disposable; stops exfiltration and out-of-bounds access, not kernel escapes
- MicroVM: own kernel, stops most escapes, costs cold start and money; choose by who wrote the code and whether you serve it publicly
- The classic bug is handing the child process the whole parent environment — isolated process, leaked secrets