Interview Bank

From Frontend Engineer to Agent Engineer in 30 Days

D1 LLM API Basics: messages/roles, Tokens, Streaming, Temperature; What an Agent Actually Is

• What are tokens and the context window, and how do they shape agent design?什么是 token 和上下文窗口？它们如何影响 Agent 的设计？

  Common in ChinaCommon overseasBasic#llm-basics#context

  How to reason about it · think before answering

  1. First decide whether this asks for definitions or engineering consequences; a definition-only answer reads as inexperienced.
  2. Follow the causal chain: tokens are the unit of billing and length, the window caps that unit, models are stateless so history is resent every turn, cost grows with turns, hence context engineering.
  3. The differentiator is why agents suffer more: a loop calls the model repeatedly and appends tool results back into history.
  4. Close with concrete tactics: sliding window, summarization, externalized long-term memory, and the cost of each.
  5. Expect the follow-up: why compress before the window is full? Long contexts dilute attention and raise latency and cost.

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

  1. 先判断这题问的是「概念」还是「工程后果」。只答定义会被认为没做过工程，必须落到设计影响上。
  2. 从一条因果链推：token 是计费与长度的计量单位 → 窗口是这个单位的上限 → 模型无状态、历史每轮重发 → 成本随轮数增长 → 所以必须做上下文工程。
  3. 关键要点出在「Agent 比聊天更严重」：Agent 在循环里反复调模型，还要把工具返回结果也塞回历史，增长速度快得多。
  4. 结论给出具体手段：滑动窗口、摘要压缩、长期记忆外置到检索系统，并说明各自代价。
  5. 可以预期的追问：窗口没满为什么也要压缩？答案是长上下文会稀释注意力、抬高延迟与成本，不是塞满了才处理。

  Key points

  • A token is the smallest unit the model processes; roughly 1.3 tokens per English word
  • The context window caps input + output tokens per request; beyond it you truncate or compress
  • Models are stateless, so the full history is re-sent every turn and cost grows with length
  • Hence context engineering: sliding windows, summarization, and external long-term memory

  答题要点

  • token 是模型处理文本的最小单位，大致 1 个汉字 ≈ 1–2 token，1 个英文单词 ≈ 1.3 token
  • 上下文窗口是一次请求里输入 + 输出 token 的上限；超出就要截断或压缩
  • 模型没有记忆，历史必须每轮重新塞进 messages，所以长对话的成本随轮数线性增长
  • Agent 设计因此要做上下文工程：滑动窗口、摘要压缩、把长期记忆外置到检索系统

Mastering Claude: From Conversation to Claude Code in 5 Days

D3 Getting Started With Claude Code and Managing Context: Install, Writing CLAUDE.md and "Trim Until You Can't", Permission Modes, Plan Mode's "Explore, Then Plan, Then Write", /clear /compact /rewind, Giving Claude a Verifiable Check

• How do CLAUDE.md and skills divide responsibilities, what goes where, and what goes wrong when CLAUDE.md grows to 500 lines?CLAUDE.md 和 skill 的分工是什么？什么内容该放哪边？一份 CLAUDE.md 写到 500 行会出什么问题？

  Common in ChinaCommon overseasBasic#claude-md#skills#context

  How to reason about it · think before answering

  1. This tests context-cost awareness. 'CLAUDE.md holds rules, skills hold procedures' is the conclusion; derive it from how each is loaded.
  2. Start from load timing: CLAUDE.md enters context in full every session — a fixed cost; a skill keeps only its one-line description resident and loads its body on invocation — a variable cost. Hence short facts that always apply go in CLAUDE.md, occasional multi-step procedures go in skills.
  3. Give the table: commands, non-default style, repo etiquette, environment quirks, and the definition of done belong in CLAUDE.md; deployment runbooks, issue-fixing steps, document generators belong in skills. Multi-step procedures in CLAUDE.md or always-on rules inside a skill are both misplacements.
  4. At 500 lines the failure is dilution, not capacity: important rules drown, adherence drops, and every turn pays for the bloat. Fixes: prune ruthlessly (would removing this cause a mistake?), move occasional content to skills, split path-scoped rules into .claude/rules/ so they load only when matching files are touched.
  5. Follow-ups: a rule that keeps being ignored — prune, then disambiguate, then emphasize; anything that must run every time should be a hook, not a sentence.

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

  1. 这题考的是「上下文成本意识」。答成「CLAUDE.md 放规则、skill 放流程」只是结论，面试官想听你从加载方式推出这个结论。
  2. 拆法从加载时机入手：CLAUDE.md 每次会话整份进入上下文，是固定成本；skill 只有描述那一行常驻，正文在被触发（模型判断相关或用户输入 /name）时才加载，是按需成本。所以「每次都成立的短事实」放 CLAUDE.md，「偶尔才用、一用就是多步」的流程放 skill。
  3. 给判据表：命令、风格差异、仓库礼仪、环境怪癖、完成的判据进 CLAUDE.md；部署流程、修 issue 的固定步骤、某类文档的生成方法进 skill。反过来，CLAUDE.md 里出现了多步流程，或 skill 里放了「每次都要遵守」的规则，都是放错了。
  4. 500 行的问题不是「太长跑不动」，而是稀释：重要规则被淹没，模型的遵守度反而下降，还白白吃掉每轮的窗口。对策是「删到不能再删」（删掉会不会让它犯错？不会就删）、把偶尔用的挪进 skill、按路径拆进 .claude/rules/ 只在碰到匹配文件时加载。
  5. 可预期的追问：「规则它老是不听怎么办」——先删再改再强调；「必须每次执行」的动作根本不该靠 CLAUDE.md，要改成 hook。

  Key points

  • CLAUDE.md loads in full every session — fixed cost; a skill keeps one line resident and loads on demand
  • CLAUDE.md: short always-true facts — commands, style deltas, etiquette, definition of done; skills: occasional multi-step procedures
  • Bloat dilutes: key rules drown, adherence drops, every turn pays
  • Fixes: prune, move occasional content to skills, split path-scoped rules; must-run actions become hooks

  答题要点

  • CLAUDE.md 每次会话整份加载，是固定成本；skill 只常驻一行描述，正文按需加载
  • CLAUDE.md 放每次都成立的短事实：命令、风格差异、规矩、完成判据；skill 放偶尔用的多步流程
  • 写长的后果是稀释：重要规则被淹没、遵守度下降、每轮白付窗口
  • 对策：删到不能再删、偶尔用的进 skill、按路径拆进 rules；必须每次做的改成 hook

D4 Extending Claude Code: Hooks (Deterministic) vs. CLAUDE.md (Advisory), Skills, Subagents, Plugins, Wiring Up an MCP Server, CLI Tools First

• What is progressive loading for skills, why does it save context, and how should the description be written?skill 的渐进式加载是怎么回事？为什么能省上下文？description 应该怎么写？

  Common in ChinaCommon overseasIntermediate#skills#context

  How to reason about it · think before answering

  1. This tests the on-demand loading idea and whether you have actually written a skill. The third part separates candidates: a poorly written description makes the skill dead weight.
  2. Mechanism: at session start only each skill's one-line description from the frontmatter is resident; the body loads when the model judges the task relevant or the user types /name. Body length therefore barely affects daily cost, so it can hold long procedures, examples, and caveats.
  3. Contrast with CLAUDE.md: loaded in full every session, a fixed cost; a procedure used twice a week wastes the window the rest of the time. Moving such content into skills is how CLAUDE.md keeps shrinking after pruning.
  4. Writing the description: state what it does plus the phrases a user would say, about a hundred words; too broad triggers on unrelated tasks, too narrow never triggers. Add disable-model-invocation: true for side-effecting workflows so only /name invokes them; $ARGUMENTS takes parameters; allowed-tools pre-approves commands.
  5. Follow-ups: how do you test triggering? Try several natural phrasings and check whether the body loaded. Skill versus subagent: a skill loads a manual into the current context; a subagent opens a separate context to do work; they compose.

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

  1. 这题考的是「按需加载」这个设计思想，以及你有没有真写过 skill。第三问是区分度：description 写不好，skill 就形同虚设。
  2. 机制：会话开始时只有每个 skill 的 frontmatter 里那一行 description 常驻上下文；当模型判断当前任务相关、或用户输入 /name 时，正文才被读进来。所以正文长短几乎不影响日常成本，可以放几十步的流程、示例、注意事项。
  3. 对比 CLAUDE.md：它整份每次加载，是固定成本；一周只用两次的流程放进去等于其余时间白占窗口。把这类内容挪到 skill，是「删到不能再删」之后 CLAUDE.md 还能继续变短的主要手段。
  4. description 的写法：说清做什么 + 用户会怎么说（触发词），一百来字；太泛会被无关任务误触发，太窄永远触发不到。有副作用的流程（部署、发消息）加 disable-model-invocation: true 只允许手动 /name 触发。$ARGUMENTS 接参数，allowed-tools 预授权命令。
  5. 可预期的追问：怎么测 skill 有没有被触发？用几个自然语言说法试，看模型是否读了正文；再追问「skill 与 subagent 的区别」——skill 是在当前上下文里加载一份说明书，subagent 是另起一个上下文去做事，两者可以组合。

  Key points

  • Only the description is resident; the body loads on invocation, so body length barely costs
  • CLAUDE.md loads in full each time; moving occasional procedures to skills keeps it short
  • Write the description as what it does plus how users phrase it, about a hundred words
  • Side-effecting workflows get disable-model-invocation; $ARGUMENTS carries parameters

  答题要点

  • 只有 description 常驻，正文在被触发时才加载；正文长短几乎不影响日常成本
  • CLAUDE.md 整份每次加载；偶尔用的流程挪进 skill 是让它继续变短的手段
  • description 写「做什么 + 用户会怎么说」，一百来字，不泛不窄
  • 副作用流程加 disable-model-invocation；$ARGUMENTS 接参数
• What problem do subagents solve? Do they see the main conversation's history? When should you not use one?subagent 解决了什么问题？它看得到主会话的历史吗？什么时候不该用？

  Common in ChinaCommon overseasIntermediate#subagents#context

  How to reason about it · think before answering

  1. The key is the problem solved: protecting the main conversation's context window, not the side benefits of parallelism or specialization. The second part is a common misconception; the third tests judgment.
  2. Chain: research and review tasks read a lot and keep little — thirty files for one conclusion. Done in the main session, all thirty land in the window and crowd out the actual implementation. A subagent has its own context window, reads everything, and returns only a summary; the main session pays only for the summary.
  3. Second part: no. A subagent starts with the system prompt, the task you delegated, CLAUDE.md, and a git status snapshot — not the main history, your earlier file reads, or previously loaded skills. That is both a limit and a strength: a reviewer without the memory of having just written the code finds more faults, which is what adversarial review in D5 relies on.
  4. Configuration: .claude/agents/<name>.md with tools restricting what it may use (no Edit for a reviewer) and model to pick a cheaper or stronger model; built-ins are Explore (read-only), Plan (plan mode research), and general-purpose.
  5. When not to: tasks needing multi-turn back-and-forth (every dispatch re-explains), phases that share heavy context, and one-line fixes where dispatch plus summary costs more than the work. Follow-up: subagent versus /compact — one keeps content out of the window, the other compresses it afterward; the former is cheaper.

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

  1. 题眼是「解决了什么问题」——答案是保护主会话的上下文窗口，而不是「并行」或「专业化」这些附带好处。第二问是常见误区，第三问考边界感。
  2. 推导：查资料、审代码这类任务的特征是「读很多、留很少」——读三十个文件只为一段结论。放在主会话里做，三十个文件全进窗口，真正的实现反而没地方放。subagent 拥有独立的上下文窗口，读完只把总结带回来，主会话只付总结的成本。
  3. 第二问：看不到。subagent 起步时只有系统提示、你派给它的任务描述、CLAUDE.md、git 状态快照；主会话的历史、你之前读过的文件、之前加载的 skill 都不在。这是限制也是优点：一个没有「刚写完这段代码」记忆的审查者更容易挑出毛病，D5 的对抗式审查就靠这个性质。
  4. 配置：.claude/agents/<name>.md，frontmatter 的 tools 限定它能用什么（审查者不给 Edit）、model 可以配更便宜或更强的模型；内置的 Explore 只读、Plan 用于计划模式、general-purpose 全能。
  5. 不该用的场景：需要多轮来回讨论的活（每次派出去都要重新交代）、几个阶段要共享大量上下文的活、一句话就能改完的活（交代 + 总结的开销大于任务本身）。可预期的追问：subagent 与 /compact 的关系——一个是不让东西进窗口，一个是进了以后压缩，前者更省。

  Key points

  • Solves the main window being flooded by read-heavy, keep-little tasks; a subagent has its own window and returns a summary
  • It does not see the main history — only the task, CLAUDE.md, and a git snapshot — which makes its review more objective
  • tools restricts permissions, model picks the model; built-ins are Explore, Plan, general-purpose
  • Avoid for multi-turn discussion, heavy shared context across phases, and one-line fixes

  答题要点

  • 解决的是主会话上下文被「读很多留很少」的任务撑满；subagent 独立窗口，只带回总结
  • 看不到主会话历史，只有任务描述、CLAUDE.md、git 快照；因此审查更客观
  • tools 限定权限、model 选模型；内置 Explore / Plan / general-purpose
  • 不该用：多轮讨论、多阶段共享上下文、一句话能改完的小活

Mastering Codex and the OpenAI Agents SDK in 5 Days

D1 Getting Started With the Codex CLI: Install, AGENTS.md, Approval Modes and the Sandbox, Common Commands

• What belongs in a project instruction file for a coding agent (such as Codex's AGENTS.md), what does not, and why is there a size limit?给 coding agent 写的项目说明文件（比如 Codex 的 AGENTS.md）应该写什么、不该写什么？为什么它要有大小上限？

  Common in ChinaCommon overseasBasic#coding-agent#context#agents-md

  How to reason about it · think before answering

  1. This probes whether you treat context as a scarce resource, not whether you know the file format; answering with a project overview signals inexperience.
  2. Use one test: can the agent discover this by opening files? If yes, leave it out (directory layout, framework); if no, write it down (conventions, no-go areas, environment facts, test commands).
  3. Add the lookup rules: a global file in the home directory, then project files concatenated from the repo root down to the current directory, so closer files override earlier ones.
  4. The size cap (32 KiB by default in Codex) forces prioritization: a long manual crowds out the task and dilutes adherence to every rule.
  5. Expect the follow-up: will the model always obey the file? No, it is prompt text and fades over long sessions; hard limits belong to the sandbox and approvals.

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

  1. 这题考的不是文件格式，而是你对「上下文是有限资源」有没有工程直觉。把它答成「写项目介绍」会被判为没真用过。
  2. 拆法是一个判断句：这条信息 agent 打开文件自己能不能发现？能发现的不写（目录结构、用了什么框架），发现不了的才写（约定、禁区、环境事实、测试命令）。
  3. 再补一层查找规则：全局层在用户目录，项目层从根目录到当前目录依次拼接，越靠近当前目录越靠后、越优先，所以子目录可以覆盖根规则。
  4. 大小上限（Codex 默认 32 KiB）的意义是逼你做取舍：手册太长会挤占任务本身的上下文，还会让模型对每一条规则的遵守度下降。
  5. 可预期的追问：写在说明文件里的规则模型一定会遵守吗？不一定，它是提示词的一部分，会被长对话稀释；硬约束要靠沙箱与审批，不是靠文字。

  Key points

  • Write conventions, no-go areas, environment facts and verification commands; skip anything discoverable from the files
  • Lookup goes global first, then project files concatenated root-down, with closer files taking precedence
  • The size cap forces you to keep only high-value guidance so the task itself keeps its context budget
  • Instruction files are advisory; hard limits come from the sandbox and approval policy

  答题要点

  • 写约定、禁区、环境事实和验证命令；不写 agent 自己打开文件就能发现的内容
  • 查找顺序是全局文件在前、项目文件从根到当前目录拼接，越靠近当前目录越优先
  • 大小上限逼你只保留高价值信息，避免挤占任务上下文、降低规则遵守度
  • 文字规则是建议性的，真正不能越的线交给沙箱与审批