面试题库

Claude 高效使用：从对话到 Claude Code

D1 提示词进阶与 Claude 的「性格」：system prompt、XML 标签、让模型先思考、结构化输出

• system prompt 应该放什么、不该放什么？如果一条规则模型总是不遵守，你会先检查什么？What belongs in a system prompt and what doesn't? If the model keeps ignoring one rule, what do you check first?

  国内高频海外高频基础#system-prompt#prompt-design

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

  1. 这题考的是「职责边界」而不是「会不会写」。答成「放角色和要求」是及格线，能说出「不该放什么」以及「为什么」才有区分度。
  2. 先给一条判据：system prompt 是每次请求都重发的固定前提，所以只放整场对话都成立的东西——角色、边界（禁止项）、输出风格；每次都变的（时间、用户名、本轮材料）放 user 消息。
  3. 再说反面：把模型本来就知道的常识（「写干净的代码」）、大段 API 文档、每轮都不一样的材料塞进 system，只会稀释真正重要的规则，还会让 prompt caching 的前缀每次都变。
  4. 「规则总是不遵守」的排查顺序：先看 system 是不是太长导致规则被淹没（删到不能再删），再看规则是否含糊或与别的规则冲突，最后才考虑加强调；如果是「每次必须执行」的动作，应该改成程序层面的门禁而不是继续加规则。
  5. 可预期的追问：system 放最后行不行？可以但不推荐——模型对靠前的指令更敏感，且会破坏缓存前缀。

  How to reason about it · think before answering

  1. The question tests boundaries, not writing skill. Naming what to exclude, and why, is what separates a strong answer.
  2. Give the rule: the system prompt is a fixed premise resent on every request, so it holds only what is true for the whole conversation — role, constraints as prohibitions, output style. Anything that varies per turn belongs in the user message.
  3. Then the anti-patterns: obvious conventions, pasted API docs, and per-turn material dilute the important rules and also invalidate the prompt-cache prefix on every call.
  4. Debug order for an ignored rule: check length first and prune, then check for ambiguity or conflicting rules, and only then add emphasis. If the rule is a must-run action, move it to a deterministic gate instead of adding more words.
  5. Likely follow-up: can system go last? Possible but unwise — earlier instructions carry more weight and a moving prefix breaks caching.

  答题要点

  • 放：角色、边界（写禁止项）、输出风格；整场对话都成立的固定前提
  • 不放：会变的信息（时间、用户名、本轮材料）、模型本来就知道的常识、大段文档
  • system 每次请求重发，越长越贵，也越容易让关键规则被淹没
  • 规则不被遵守先删再改再强调；「每次必须做」的动作改成程序门禁

  Key points

  • Include role, prohibitions, and output style — premises that hold for the whole conversation
  • Exclude volatile facts, common sense the model already has, and long pasted docs
  • The system prompt is resent every request: longer means costlier and rules get buried
  • For an ignored rule: prune first, disambiguate second, emphasize last; must-run actions become deterministic gates
• 为什么用 XML 标签组织长提示词对 Claude 特别有效？和用 Markdown 分段比有什么区别？Why does organizing long prompts with XML tags work so well for Claude, and how does it differ from using Markdown sections?

  国内高频海外高频进阶#xml-tags#long-context

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

  1. 题眼在「为什么」。只答「官方推荐」等于没答；要能从「模型如何分辨内容边界」这个角度解释。
  2. 拆法：长提示词的核心风险是不同性质的内容（材料、指令、示例）混在一起，模型分错边界就会把材料里的句子当指令执行、或把示例当成事实。成对的标签给每一段一个明确的起止和名字，模型分辨边界的准确率更高，也能在回答里精确引用「哪一段」。
  3. 与 Markdown 的区别：Markdown 靠标题和围栏分段，但没有显式的结束标记；当贴进去的材料本身含 Markdown（比如一份 README）时容易串位。XML 标签成对、可嵌套、名字自定义，材料越杂优势越大。
  4. 补一条工程习惯：标签名前后一致，指令放在材料之后，回答时要求引用标签名。三到六个顶层标签是常态，不要过度包装。
  5. 可预期的追问：标签名有没有固定词表？没有，模型看的是结构和语义，但同一个提示词内要一致；另一个追问是「材料本身含 XML 怎么办」——换一个不会撞的标签名，或用 CDATA 式的转义说明。

  How to reason about it · think before answering

  1. The keyword is why. Citing the docs is not an answer; explain it in terms of how the model detects content boundaries.
  2. Breakdown: the core risk in a long prompt is mixing material, instructions, and examples. Paired tags give each part an explicit start, end, and name, so the model separates them reliably and can reference a specific section in its reply.
  3. Versus Markdown: headings and fences delimit but have no explicit closing marker, so pasted material that itself contains Markdown breaks the structure. XML tags are paired, nestable, and freely named, and the benefit grows with messier input.
  4. Add the engineering habits: consistent tag names, instructions after the material, and asking the model to cite tags in its answer. Three to six top-level tags is typical.
  5. Follow-ups: is there a fixed tag vocabulary? No — structure and semantics matter, consistency within one prompt matters. What if the material contains XML? Pick non-colliding names.

  答题要点

  • 长提示词的风险是材料、指令、示例混在一起；成对标签给每段明确的起止和名字
  • 模型分辨边界更准，也能在回答里精确引用某一段
  • Markdown 没有显式结束标记，材料含 Markdown 时会串位；XML 标签成对、可嵌套、可自定义
  • 习惯：标签名一致、指令放材料之后、要求引用标签、顶层标签三到六个

  Key points

  • Long prompts mix material, instructions, and examples; paired tags give each an explicit boundary and name
  • Boundary detection becomes reliable and the model can cite a specific section
  • Markdown has no closing marker and breaks when pasted material contains Markdown; XML tags are paired, nestable, and freely named
  • Habits: consistent names, instructions after material, ask for tag citations, three to six top-level tags
• 什么时候该让模型先写分析再回答，什么时候直接要结构化输出？两者能同时要吗？When should you have the model write its analysis before answering, and when should you go straight to structured output? Can you have both?

  国内高频海外高频进阶#structured-output#reasoning

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

  1. 这题考取舍，判据是「谁消费输出」和「错误的代价」。答「都用」或「看情况」没有信息量，要给出可执行的判断句。
  2. 推导链：分析段是输出 token，按输出价计费，且会让响应变长；它换来的是复杂任务上更高的准确率与可核对的推理过程。所以任务越复杂、错误代价越高、越需要人审计，越该要分析段；批量、简单、程序直接消费的任务，直接要结构化输出。
  3. 「能不能同时要」：一旦传了 JSON Schema，输出被约束成 JSON，自由文本的分析段没地方放。两条路：在 schema 里加一个 reasoning 字段放在其他字段前面（模型会先生成它），或者依赖模型内部的 thinking——它是内部推理，你控制深度不控制内容。
  4. 生产视角：结构化输出解决的是「解析可靠性」，不是「判断正确性」；schema 不支持数值范围与字符串长度约束，这些校验要自己补。
  5. 可预期的追问：分析段会不会被程序误用？会，所以要用标签把分析段与答案段分开，程序只取答案段；另一个追问是 thinking 与分析段的区别——一个内部一个外显，一个控深度一个控内容。

  How to reason about it · think before answering

  1. This is a trade-off question; the criteria are who consumes the output and what an error costs. Give a decision rule, not 'it depends'.
  2. Chain: the analysis is output tokens, billed at output rates and adding latency, in exchange for higher accuracy on complex tasks and an auditable trace. The more complex, high-stakes, or human-reviewed the task, the more you want it; bulk, simple, machine-consumed tasks go straight to structured output.
  3. Can you have both? Once a JSON schema is passed the output is constrained to JSON, so free-text analysis has nowhere to go. Two options: add a reasoning field placed before the other fields, or rely on the model's internal thinking, whose depth you control but not its content.
  4. Production nuance: structured output fixes parsing reliability, not judgment quality; the schema cannot express numeric ranges or string lengths, so validate those yourself.
  5. Follow-ups: can the analysis leak into downstream code? Yes — separate analysis and answer with tags and parse only the answer. Thinking versus a written analysis: internal versus visible, depth versus content.

  答题要点

  • 分析段：输出 token 计费、更慢，但复杂任务更准、过程可核对；适合高风险、需人审的任务
  • 结构化输出：程序直接消费、解析零失败；适合批量、简单、明确的抽取与分类
  • 同时要：在 schema 里加靠前的 reasoning 字段，或依赖内部 thinking
  • 结构化输出保证的是格式不是正确性；范围与长度校验要自己补

  Key points

  • Written analysis costs output tokens and latency but raises accuracy and gives an auditable trace — use for high-stakes, human-reviewed work
  • Structured output is consumed directly by code with zero parse failures — use for bulk, simple extraction and classification
  • To combine: put a reasoning field first in the schema, or rely on internal thinking
  • Structured output guarantees shape, not correctness; add range and length validation yourself

D2 长文档、多模态与 API 初见：大上下文怎么用、prompt caching 省钱、PDF 与图片输入、带引用回答；Messages API 最小调用

• 为什么说上下文窗口是 LLM 应用里最稀缺的资源？窗口已经有一百万 token 了，这个说法还成立吗？Why is the context window called the scarcest resource in LLM applications? With million-token windows, does that still hold?

  国内高频海外高频基础#context-window#cost

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

  1. 题眼在第二句。只答「窗口有上限」已经过时了，面试官想听的是「窗口变大之后为什么还稀缺」。
  2. 从三条因果链推：一、模型无状态，每次请求都把全部输入重读一遍，输入 token 按次计费——窗口大只解决了放得下，没解决每次都要重搬；二、上下文越长，延迟越高、注意力越稀释，模型对早期指令的遵守度会下降，也就是「性能随填充度下降」；三、Agent 场景里每读一个文件、每跑一条命令的输出都进同一个窗口，填得比聊天快得多。
  3. 结论：窗口大了，稀缺性从「放不下」变成了「每一 token 都在花钱和稀释注意力」，所以管理手段变成了主动管：只放必要的、把不变的缓存起来、把查资料的活派给独立上下文的子代理、该清就清。
  4. 生产视角：算一笔账——60 页 PDF 约 10 万 token，围着它问 10 个问题就是 100 万输入 token；不用缓存和不用缓存的差价是一个量级。
  5. 可预期的追问：那什么时候应该让上下文积累？在一个复杂问题里深挖时历史是有价值的；判据是「这段历史下一步还会不会用到」。

  How to reason about it · think before answering

  1. The second sentence is the point. 'The window has a limit' is a dated answer; explain why scarcity survives large windows.
  2. Three causal chains: models are stateless so every request re-reads the whole input and bills it, a big window only solves fitting, not re-sending; longer context means more latency and diluted attention, so adherence to early instructions degrades as the window fills; and in agent workflows every file read and command output lands in the same window, filling it far faster than chat does.
  3. Conclusion: scarcity shifted from 'won't fit' to 'every token costs money and attention', so the discipline becomes active management — include only what is needed, cache the stable prefix, delegate research to subagents with their own context, and clear between tasks.
  4. Production math: a 60-page PDF is roughly 100k tokens; ten questions about it are a million input tokens; caching versus not caching is an order of magnitude apart.
  5. Follow-up: when should context accumulate? While deep in one complex problem where the history is still load-bearing; the test is whether the next step will use it.

  答题要点

  • 模型无状态，每次请求重读全部输入并计费；窗口大只解决放得下，不解决每次重搬
  • 上下文越长延迟越高、注意力越稀释，早期指令遵守度下降
  • Agent 场景每次读文件、跑命令的输出都进窗口，填得比聊天快得多
  • 对策：只放必要的、缓存不变前缀、用子代理隔离查资料、任务之间清空

  Key points

  • Models are stateless: every request re-reads and bills the full input; a large window solves fitting, not re-sending
  • Longer context raises latency and dilutes attention; adherence to early instructions drops
  • Agent workflows dump every file read and command output into the same window
  • Tactics: include only what's needed, cache the stable prefix, isolate research in subagents, clear between tasks
• prompt caching 省在哪？什么情况下反而不省？线上发现缓存命中率是零，你怎么排查？Where does prompt caching save money, when does it cost more, and how do you debug a zero cache-hit rate in production?

  国内高频海外高频进阶#prompt-caching#cost

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

  1. 三问对应三层：原理、边界、排查。只答第一层是背文档，第三层才体现有没有真的上过线。
  2. 原理一句话：缓存匹配的是请求开头到 cache_control 标记为止的精确前缀（顺序是工具、system、messages），命中时这段只收正常输入价的 0.1 倍；代价是写入那一次收 1.25 倍（1 小时档 2 倍）。
  3. 不省的情况由此推出：同一前缀只用一次（多付 25%）；前缀里有每次都变的内容（时间戳、随机 id、未排序 JSON、用户名），导致每次都在写永远用不上的缓存；前缀短于最小门槛（主力模型 1024 token，Haiku 4.5 是 4096）根本不会缓存；两次请求间隔超过 TTL。
  4. 排查清单按发生概率排：一看 system 或工具定义开头有没有动态内容；二看两次请求的模型 id 是否一致；三看前缀长度是否过门槛；四看间隔是否超 5 分钟；五看工具列表顺序是否稳定。判据只有一个字段：usage.cache_read_input_tokens 是否大于 0。
  5. 可预期的追问：断点应该打在哪？不变的末尾——工具定义末尾、system 末尾、长文档末尾、多轮对话倒数第二条消息，最多四个；打在每轮都变的内容上等于白写。

  How to reason about it · think before answering

  1. Three questions, three layers: mechanism, boundaries, debugging. The third layer is what shows production experience.
  2. Mechanism: the cache matches the exact byte prefix from the start of the request to the cache_control marker (tools, then system, then messages). A hit bills that prefix at 0.1x input price; the write costs 1.25x (2x for the one-hour TTL).
  3. When it costs more: a prefix used only once (+25%); volatile content inside the prefix — timestamps, random ids, unsorted JSON, user names — so every call writes a cache nothing will read; a prefix below the minimum (1024 tokens on current flagship models, 4096 on Haiku 4.5) that silently never caches; requests spaced beyond the TTL.
  4. Debug order by likelihood: dynamic content at the head of system or tool definitions; model id mismatch between calls; prefix under the minimum; gap over five minutes; unstable tool ordering. The single signal is usage.cache_read_input_tokens greater than zero.
  5. Follow-up: where do breakpoints go? At the end of stable sections — tools, system, the long document, the second-to-last message in a multi-turn chat — at most four; a breakpoint on per-turn content is a wasted write.

  答题要点

  • 匹配精确前缀（工具 → system → messages 到标记为止）；命中 0.1 倍，写入 1.25 倍
  • 不省：前缀只用一次、前缀含动态内容、前缀短于最小门槛、间隔超过 TTL
  • 排查：动态内容、模型不一致、长度不够、间隔太久、工具顺序变了；看 cache_read_input_tokens
  • 断点打在不变部分的末尾，最多四个

  Key points

  • Matches the exact prefix (tools → system → messages up to the marker); hits bill 0.1x, writes 1.25x
  • Costs more when the prefix is used once, contains volatile content, is under the minimum length, or requests exceed the TTL
  • Debug: dynamic content, model mismatch, length, gap, tool ordering; verify via cache_read_input_tokens
  • Place breakpoints at the end of stable sections, at most four
• citations 和在提示词里要求模型「引用原文并注明页码」有什么本质区别？什么场景下不能用 citations？How do API citations fundamentally differ from prompting the model to quote sources with page numbers, and when can't you use them?

  国内高频海外高频进阶#citations#grounding

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

  1. 这题考的是「可信度从哪来」。答成「citations 更方便」是表面；本质区别是谁来保证引用的真实性。
  2. 拆法：提示词方案里，引用和页码都是模型生成的自由文本——它可能顺手改写原文、可能记错页码，你无法区分「真引用」和「自以为引用」。citations 方案里，模型内部以标准格式输出引用意图，API 在服务端解析并核对，返回的 cited_text 一定是文档里真实存在的段落，page_location 的页码由 API 给出。真实性由 API 保证而不是由模型自觉保证。
  3. 附带的两点好处：cited_text 不计入输出 token，比让模型抄原文便宜；返回是结构化的内容块，程序可以直接高亮、跳转，不用正则去猜「第 3 页」出现在哪。
  4. 不能用的场景：与结构化输出（JSON Schema）不兼容，二者同开会报 400；此时要么放弃 API 级引用、在 schema 里留 page 字段让模型自己填（可靠性差一档），要么分两步：先 citations 拿事实，再用结构化输出整理。
  5. 可预期的追问：页码字段的语义？start_page_number 从 1 开始，end_page_number 不包含；多文档时 document_index 区分来源。再追问「能否验证引用质量」——能，用 cited_text 与原文做字符串比对，或抽样人工核对。

  How to reason about it · think before answering

  1. The question is about where trust comes from. 'Citations are more convenient' is surface; the real difference is who guarantees the quote is real.
  2. With prompting, both the quote and the page number are free text the model generates — it may paraphrase, it may misremember the page, and you cannot tell a real quote from an imagined one. With citations, the model emits citation intent in a standard format, the API parses and verifies it server-side, cited_text is guaranteed to exist in the document, and page_location comes from the API. Fidelity is enforced by the API rather than promised by the model.
  3. Two side benefits: cited_text does not count toward output tokens, so it is cheaper than asking the model to copy; and the result is structured content blocks your UI can highlight and jump to without regex guessing.
  4. When you can't: citations are incompatible with structured outputs (JSON Schema) — enabling both returns a 400. Either drop API-level citations and add a page field to the schema (one notch less reliable), or split into two calls: citations for facts, structured output for shaping.
  5. Follow-ups: page semantics — start_page_number is 1-indexed and end_page_number is exclusive; document_index distinguishes sources. Can you audit citation quality? Yes — string-match cited_text against the source, or sample manually.

  答题要点

  • 提示词引用是模型生成的自由文本，可能改写、记错页码，无法区分真假
  • citations 由 API 在服务端解析核对，cited_text 一定存在于文档中，页码由 API 给出
  • cited_text 不计输出 token，返回结构化便于高亮跳转
  • 与结构化输出互斥；需要两者时分两步或在 schema 留 page 字段

  Key points

  • Prompted quotes are free text the model generates — it may paraphrase or misplace pages, and you can't tell
  • Citations are parsed and verified server-side; cited_text is guaranteed to exist and page numbers come from the API
  • cited_text is free of output-token cost and the structured blocks enable highlighting and navigation
  • Mutually exclusive with structured outputs; split into two calls or add a page field to the schema

D3 Claude Code 入门与上下文管理：安装、CLAUDE.md 写法与「删到不能再删」、权限模式、Plan Mode「先探索再计划再写」、/clear /compact /rewind、给 Claude 一个可验证的检查

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

  国内高频海外高频基础#claude-md#skills#context

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

  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。

  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.

  答题要点

  • CLAUDE.md 每次会话整份加载，是固定成本；skill 只常驻一行描述，正文按需加载
  • CLAUDE.md 放每次都成立的短事实：命令、风格差异、规矩、完成判据；skill 放偶尔用的多步流程
  • 写长的后果是稀释：重要规则被淹没、遵守度下降、每轮白付窗口
  • 对策：删到不能再删、偶尔用的进 skill、按路径拆进 rules；必须每次做的改成 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 Code 里为什么上下文窗口需要主动管理？/clear、/compact、/rewind 分别在什么时候用？Why does the context window need active management in Claude Code, and when do you use /clear, /compact, and /rewind respectively?

  国内高频海外高频进阶#context-window#claude-code

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

  1. 题眼是「主动」。被动等自动压缩也能用，面试官想知道你是否理解「窗口填满之前性能就已经在下降」。
  2. 先说为什么：Claude Code 读的每个文件、跑的每条命令输出、每轮对话都进同一个窗口，一次调试就是几万 token；窗口越满模型越容易忘掉早先的指令、越容易出错，所以不是满了才处理，而是从一开始就控制进什么。
  3. 再分三个命令，判据是「这段历史还有没有用」：任务切换且历史无用——/clear 清零；任务未完但窗口快满、历史有用——/compact 压缩成摘要，可带指令指定保留什么；走错了方向、想回到某个点——/rewind（Esc Esc）恢复对话或代码到检查点，也能只对某一段做摘要。
  4. 补两条经验规则：同一问题纠正两次还不对就 /clear 重开，失败的尝试留在窗口里只会继续污染；旁枝问题用 /btw，答案不进历史；查资料派给 subagent，让它在自己的窗口里翻。
  5. 可预期的追问：什么时候应该让上下文积累？深挖一个复杂问题、历史仍在被引用时；判据是下一步还会不会用到这段历史。再追问 rewind 的边界：只追踪 Claude 用编辑工具做的改动，Bash 改的文件不在其中，不替代 git。

  How to reason about it · think before answering

  1. The keyword is active. Waiting for auto-compaction works, but the interviewer wants to hear that performance degrades before the window is full.
  2. Why: every file read, command output, and turn lands in one window; a single debugging pass can be tens of thousands of tokens; as it fills the model forgets earlier instructions and errs more, so the discipline is controlling what enters from the start.
  3. Then the three commands, keyed on whether the history is still useful: switching tasks with useless history — /clear; mid-task with useful history but a filling window — /compact, optionally with instructions on what to keep; wrong direction — /rewind (Esc Esc) to restore conversation or code to a checkpoint, or summarize just one span.
  4. Two rules of thumb: after two failed corrections, /clear and rewrite the prompt — failed attempts keep polluting; use /btw for side questions that shouldn't enter history; delegate research to a subagent with its own window.
  5. Follow-ups: when should context accumulate? While deep in one problem where history is still referenced. Limits of rewind: it tracks only edits made through Claude's editing tools, not Bash-driven changes, and is no substitute for git.

  答题要点

  • 所有文件读取、命令输出、对话都进同一窗口；越满越容易忘指令、出错，要从一开始控制
  • /clear：切换任务、历史无用时清零；两次纠正无效也清
  • /compact：任务未完、历史有用但窗口快满；可带指令指定保留内容
  • /rewind：回到检查点恢复对话或代码，或只对一段做摘要；不替代 git

  Key points

  • Every read, output, and turn shares one window; fullness degrades adherence, so control inputs from the start
  • /clear between unrelated tasks or after two failed corrections
  • /compact mid-task when history matters but space runs low; pass instructions on what to keep
  • /rewind to a checkpoint for conversation or code, or summarize a span; not a git replacement
• 为什么说「给 Claude 一个可验证的检查」是用好 Agent 的分水岭？检查可以有哪几档硬度？Why is 'give Claude a check it can run' the dividing line for using agents well, and what levels of enforcement can that check have?

  国内高频海外高频进阶#verification#agent-loop

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

  1. 这题考对 Agent 循环的理解。答成「测试很重要」是常识；要说清没有检查时循环在谁那里闭合。
  2. 推导：Agent 在「做、看结果、改」的循环里工作，停下来的信号是「看起来做完了」。没有可运行的检查，「看起来做完了」是唯一信号，验证环落在人身上——每个错误都要等你注意到，你在场它是工具，你不在场它是风险。有了检查（测试、构建退出码、lint、比对脚本、截图对照），循环在机器里闭合：它做、它跑、它读结果、它改到通过，你只审证据。
  3. 硬度分四档：写进提示词（「实现后跑 pnpm test 直到全过」）——今天就能用；设为 /goal——独立评估器每轮复核直到达成；写成 Stop hook——测试不过不允许结束，确定性门禁；交给另一个 subagent 复核——做的人和判的人分开。每升一档多一点配置，换来少一点盯着。
  4. 生产视角：要求展示证据而不是宣布成功——贴测试输出、贴命令与返回值、贴截图；审证据比自己重跑快。
  5. 可预期的追问：检查本身会不会被绕过？会——模型可能改测试让它过。对策是把测试目录放进禁改清单，或让 reviewer subagent 专门核对「有没有为了过而改测试」。

  How to reason about it · think before answering

  1. This tests understanding of the agent loop. 'Tests matter' is common sense; explain where the loop closes without a check.
  2. Chain: an agent works in a do–observe–adjust loop and stops on 'looks done'. Without a runnable check, 'looks done' is the only signal and the verification step falls on you — every mistake waits to be noticed; present, it is a tool, absent, it is a risk. With a check (tests, build exit code, lint, diff-against-fixture, screenshot compare) the loop closes inside the machine: it works, runs, reads, and iterates to green while you review evidence.
  3. Four levels: in the prompt ('run the tests until they pass') — usable today; as a /goal — an independent evaluator re-checks every turn; as a Stop hook — the turn cannot end until the check passes, deterministic; as a reviewer subagent — the one who did the work is not the one grading it. Each step trades setup for attention.
  4. Production nuance: demand evidence, not claims — test output, commands and return values, screenshots; reviewing evidence beats re-running.
  5. Follow-up: can the check itself be gamed? Yes — the model might edit tests to pass. Counter with a deny rule on the test directory or a reviewer specifically checking for test tampering.

  答题要点

  • 没有检查时循环在人身上闭合，每个错误都等你发现；有检查时循环在机器里闭合
  • 检查可以是测试、构建、lint、比对脚本、截图对照，任何能产生通过/失败信号的东西
  • 四档硬度：提示词里要求、/goal 每轮复核、Stop hook 确定性门禁、subagent 独立复核
  • 要证据不要宣言；防止改测试作弊要靠禁改清单或专门的复核

  Key points

  • Without a check the loop closes on you; with one it closes inside the machine
  • A check is anything with a pass/fail signal: tests, build, lint, fixture diff, screenshot compare
  • Four levels: prompt instruction, /goal re-evaluation, Stop hook gate, independent reviewer subagent
  • Demand evidence over claims; guard against test tampering with deny rules or a dedicated reviewer

D4 扩展 Claude Code：hooks（确定性）vs CLAUDE.md（建议性）、skills、subagents、plugins、接 MCP server、CLI 工具优先

• 为什么 hooks 比 CLAUDE.md 里的规则更可靠？各适合放什么？举一个你会从 CLAUDE.md 挪到 hook 的例子。Why are hooks more reliable than rules in CLAUDE.md? What belongs in each? Give one rule you would move from CLAUDE.md to a hook.

  国内高频海外高频基础#hooks#claude-md

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

  1. 这题考的是「建议 vs 确定性」的系统位置，不是背功能名。答「hooks 是自动执行的脚本」只是描述，要说清为什么模型的遵守率不等于程序的执行率。
  2. 拆法：CLAUDE.md 的内容作为文字进入模型上下文，由模型读后决定怎么做——遵守率高但不是百分之百，文件越长越低，压缩后还可能丢失。hook 是 Claude Code 程序在固定生命周期点（PreToolUse / PostToolUse / Stop 等）无条件运行的脚本，由退出码决定拦不拦，与模型的判断无关。
  3. 判据一句话：一次例外都不能有的动作做成 hook；通常应该这样的偏好写进 CLAUDE.md。反向操作也成立：CLAUDE.md 里模型已经默认遵守的删掉，必须百分之百的换成 hook，文件就短了。
  4. 例子要具体：「提交前跑 lint 与测试」——作为文字它偶尔会被跳过；做成 Stop hook，测试不过 exit 2，模型收到失败摘要继续修，直到通过；「不许改 migrations/」做成 PreToolUse hook 匹配 Edit|Write，路径命中就 exit 2。
  5. 可预期的追问：hook 有没有风险？有——它是代码，跑在你机器上，clone 陌生仓库时别人的 hook 会执行，无头模式没有信任对话框；Stop hook 连续 8 次阻止后会被放行防死循环。

  How to reason about it · think before answering

  1. This tests the systemic position of advisory versus deterministic, not feature recall. 'Hooks are scripts that run automatically' is a description; explain why model adherence is not program execution.
  2. Breakdown: CLAUDE.md enters the model's context as text and the model decides after reading — adherence is high but not total, drops as the file grows, and can be lost after compaction. A hook is a script Claude Code itself runs unconditionally at fixed lifecycle points (PreToolUse, PostToolUse, Stop), with the exit code deciding whether to block, independent of the model's judgment.
  3. One-line rule: actions that allow zero exceptions become hooks; preferences that usually apply stay in CLAUDE.md. The inverse also holds — delete rules the model follows by default, convert must-always rules into hooks, and the file shrinks.
  4. Make the example concrete: 'run lint and tests before committing' is occasionally skipped as text; as a Stop hook, failing tests exit 2 and the model receives the summary and keeps fixing. 'Never edit migrations/' becomes a PreToolUse hook matching Edit|Write that exits 2 on a path hit.
  5. Follow-ups: risks? Hooks are code running on your machine — a cloned repo's hooks execute, and headless mode shows no trust dialog; a Stop hook is overridden after 8 consecutive blocks to prevent loops.

  答题要点

  • CLAUDE.md 是送进上下文的文字，由模型读后决定，遵守率高但不是百分之百
  • hook 是程序在固定生命周期点无条件跑的脚本，退出码决定拦不拦，与模型判断无关
  • 一次例外都不能有的做 hook；通常应该这样的写 CLAUDE.md
  • 例：提交前测试改成 Stop hook；禁改 migrations 改成 PreToolUse hook

  Key points

  • CLAUDE.md is text the model reads and then decides on — high but not total adherence
  • A hook is a script the program runs unconditionally at lifecycle points; the exit code decides, not the model
  • Zero-exception actions become hooks; usual preferences stay in CLAUDE.md
  • Examples: pre-commit tests as a Stop hook; a migrations deny as a PreToolUse hook
• skill 的渐进式加载是怎么回事？为什么能省上下文？description 应该怎么写？What is progressive loading for skills, why does it save context, and how should the description be written?

  国内高频海外高频进阶#skills#context

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

  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 是另起一个上下文去做事，两者可以组合。

  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.

  答题要点

  • 只有 description 常驻，正文在被触发时才加载；正文长短几乎不影响日常成本
  • CLAUDE.md 整份每次加载；偶尔用的流程挪进 skill 是让它继续变短的手段
  • description 写「做什么 + 用户会怎么说」，一百来字，不泛不窄
  • 副作用流程加 disable-model-invocation；$ARGUMENTS 接参数

  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
• subagent 解决了什么问题？它看得到主会话的历史吗？什么时候不该用？What problem do subagents solve? Do they see the main conversation's history? When should you not use one?

  国内高频海外高频进阶#subagents#context

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

  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 的关系——一个是不让东西进窗口，一个是进了以后压缩，前者更省。

  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.

  答题要点

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

  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

D5 自动化与规模化：headless -p 进 CI、并行会话与 worktree、Writer / Reviewer 双会话、对抗式审查、常见失败模式；Agent SDK 20 行最小 agent

• 把 claude -p 放进 CI 时要控制哪三件事？具体用哪些参数？为什么推荐加 --bare？What three things must you control when running claude -p in CI, with which flags, and why is --bare recommended?

  国内高频海外高频进阶#headless#ci#permissions

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

  1. 这题考无人值守的风险意识。答「加个 API key 就能跑」会被判没上过线；面试官想听权限、预算、可复现三道锁，以及每道锁对应的参数。
  2. 权限：无人值守时没人回答「允许吗」，所以要么白名单放行（--allowedTools "Read,Grep" 或 "Bash(git diff *)"，注意 * 前的空格），要么定基线（--permission-mode dontAsk 一律拒绝白名单外的动作；acceptEdits 允许改文件），再加 --permission-prompts none 把本来要问人的动作直接拒掉。-p 模式的起始档位是 Manual，必须显式传。
  3. 预算：--max-turns 限轮数、--max-budget-usd 限花费，到了就停并报错。没有它们，一个卡在循环里的任务能耗尽额度；有 Stop hook 时要给足轮数，否则会以「轮数耗尽」而不是「测试通过」结束。
  4. 可复现：--bare 跳过 hooks、skills、插件、MCP、CLAUDE.md 的自动发现，让每台 runner 结果一致、启动更快；同时也是安全措施——不加它，clone 下来的陌生仓库里别人写的 hook 会在 -p 下无提示地执行（无头模式没有信任对话框）。配合 --no-session-persistence 不落盘，提示词与 --append-system-prompt 进版本控制。
  5. 可预期的追问：--bare 之后怎么认证？它不读订阅登录，必须设 ANTHROPIC_API_KEY；再追问怎么判断成败——--output-format json 的 is_error / subtype / total_cost_usd，退出码非零脚本就 fail。

  How to reason about it · think before answering

  1. This tests awareness of unattended risk. 'Add an API key and run it' reads as no production experience; the interviewer wants the three locks — permissions, budget, reproducibility — each with its flags.
  2. Permissions: nobody answers 'allow?' unattended, so either allowlist tools (--allowedTools "Read,Grep" or "Bash(git diff *)", mind the space before *) or set a baseline (--permission-mode dontAsk denies anything outside the allowlist; acceptEdits permits file edits), plus --permission-prompts none to deny anything that would have prompted. -p starts in Manual on every plan, so pass the mode explicitly.
  3. Budget: --max-turns caps turns, --max-budget-usd caps spend; both stop with an error. Without them a looping task can drain your quota; with a Stop hook, allow enough turns or the run ends on 'max turns' rather than 'tests pass'.
  4. Reproducibility: --bare skips auto-discovery of hooks, skills, plugins, MCP, and CLAUDE.md so every runner behaves the same and starts faster — and it is a security measure, since a cloned repo's hooks would otherwise run silently under -p (no trust dialog). Add --no-session-persistence and keep the prompt and --append-system-prompt in version control.
  5. Follow-ups: authentication under --bare — it ignores subscription login, so set ANTHROPIC_API_KEY. Judging success — is_error, subtype, and total_cost_usd from --output-format json; fail the job on a non-zero exit.

  答题要点

  • 权限：--allowedTools 白名单 + --permission-mode dontAsk / acceptEdits + --permission-prompts none；-p 默认 Manual 必须显式传
  • 预算：--max-turns 与 --max-budget-usd，到了就停；有 Stop hook 时给足轮数
  • 可复现：--bare 跳过本机配置自动发现，也防陌生仓库的 hook 在 CI 上跑；--no-session-persistence
  • --bare 需要 ANTHROPIC_API_KEY；成败看 --output-format json 的 is_error 与退出码

  Key points

  • Permissions: --allowedTools allowlist plus --permission-mode dontAsk or acceptEdits and --permission-prompts none; -p defaults to Manual
  • Budget: --max-turns and --max-budget-usd stop the run; leave headroom for Stop hooks
  • Reproducibility: --bare skips local auto-discovery and keeps a cloned repo's hooks from running in CI; --no-session-persistence
  • --bare requires ANTHROPIC_API_KEY; judge success from is_error in the JSON and the exit code
• 为什么 Writer / Reviewer 双会话的审查比同一个会话自查更有效？审查者报出来的问题要全改吗？Why is a Writer / Reviewer two-session review more effective than self-review in one session, and should you fix everything the reviewer reports?

  国内高频海外高频进阶#review#subagents

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

  1. 题眼是「为什么」和后半句。答「多一双眼睛」是常识；要说清上下文在这里扮演的角色，以及审查的副作用。
  2. 推导：写完实现的会话，上下文里装满了「我为什么这么写」的推理；让它自审，它倾向于确认而不是质疑——这不是态度问题，是上下文偏置。Reviewer 换一个全新的上下文，只看到 diff 和你给的标准，不知道 Writer 的理由，所以挑的是代码本身的毛病。这和人类 code review 要求「非作者审」是同一个道理。
  3. 形态有三种：两个终端手动传递输出；一个 subagent 做对抗式审查（独立上下文天然就是无记忆的审查者，而且结果直接回到主会话可以立刻修）；内置的 /code-review 在新 subagent 里审当前 diff。同样的思路可以反过来用：一个会话写测试，另一个写实现去通过。
  4. 后半句是区分度：不要全改。被要求找问题的审查者一定会报出问题来，哪怕代码没毛病；照单全收会导致过度工程——多余抽象、防御不存在情况的代码、测不可能发生的用例。审查提示词里要写「只报告影响正确性或明确需求的差距，其余视为可选」，最终由人判断。
  5. 可预期的追问：Reviewer 需要什么输入？diff、计划或需求（PLAN.md）、明确的判据；给它 Writer 的推理过程反而会削弱独立性。再追问「能不能自动化」——能，-p 模式里一条命令跑 Reviewer，结果贴回 PR。

  How to reason about it · think before answering

  1. The point is the why and the second half. 'A second pair of eyes' is common sense; explain the role of context and the side effect of review.
  2. Chain: the session that wrote the code has a context full of its own reasoning; asked to review, it tends to confirm rather than challenge — a context bias, not an attitude problem. A Reviewer in a fresh context sees only the diff and your criteria, not the Writer's reasons, so it critiques the code itself. Same principle as non-author code review among humans.
  3. Three shapes: two terminals passing output by hand; a subagent doing adversarial review (its isolated context is the memoryless reviewer, and findings land back in the main session for immediate fixing); the built-in /code-review that reviews the current diff in a fresh subagent. The idea also inverts: one session writes tests, another writes the implementation to pass them.
  4. The second half separates candidates: don't fix everything. A reviewer told to find gaps will report some even in sound code; accepting all of it leads to over-engineering — extra abstraction, defensive code for impossible cases, tests for unreachable paths. Tell it to flag only gaps affecting correctness or stated requirements, and let a human decide.
  5. Follow-ups: what does the Reviewer need? The diff, the plan or requirements, explicit criteria; feeding it the Writer's reasoning weakens independence. Can it be automated? Yes — run the Reviewer via -p and post results to the PR.

  答题要点

  • 自审受上下文偏置：装满自己推理的会话倾向于确认而非质疑
  • Reviewer 用全新上下文，只看 diff 与判据，挑的是代码本身的毛病
  • 形态：双终端、subagent 对抗式审查、内置 /code-review；反向可用于测试先行
  • 不要全改：审查者必报问题，照单全收导致过度工程；限定只报影响正确性的差距

  Key points

  • Self-review suffers context bias: a session full of its own reasoning confirms rather than challenges
  • A Reviewer in a fresh context sees only the diff and criteria, so it critiques the code itself
  • Shapes: two terminals, an adversarial subagent, built-in /code-review; invert for test-first
  • Don't fix everything: reviewers always report something; limit findings to correctness and stated requirements
• Agent SDK 和直接调 Messages API 各适合什么场景？它们和 claude -p 是什么关系？When do you use the Claude Agent SDK versus the Messages API directly, and how do both relate to claude -p?

  国内高频海外高频基础#agent-sdk#messages-api

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

  1. 这题考的是分层认知：三个入口底下是同一个模型，差别在于「谁提供循环和工具」。答成「SDK 更高级」没有信息量。
  2. Messages API（@anthropic-ai/sdk / anthropic）：一次请求一次响应，工具由你定义、循环由你写、上下文由你管。适合问答、抽取、分类、结构化输出、带引用的文档问答，以及你想完全掌控循环的自定义 Agent。
  3. Agent SDK（@anthropic-ai/claude-agent-sdk / claude-agent-sdk）：把 Claude Code 打包成库——内置 Read / Edit / Bash / Glob / Grep 等工具、完整的 agent 循环、上下文管理、权限系统、hooks、subagent、会话。你给一句任务和一组选项（allowedTools、permissionMode、maxTurns、systemPrompt），它在文件系统里干活。适合「在自己的程序里嵌一个会改代码的 agent」。
  4. claude -p：同一套 Claude Code 能力的命令行形态，适合 shell 脚本与 CI；Agent SDK 就是它的库形态，官方文档把两者放在同一页讲。判据一句话：要模型调用用 API，要文件系统里的 agent 用 Agent SDK，只想在脚本里调一下用 -p。
  5. 生产视角：Agent SDK 的部署仍是你自己的（它只提供循环，不提供托管），密钥走 ANTHROPIC_API_KEY，不能复用 claude.ai 的订阅登录给第三方产品。可预期的追问：Agent SDK 和 Messages API 里的 tool runner 是不是一回事？不是——tool runner 只帮你跑「你自己定义的工具」的循环，没有内置文件工具。

  How to reason about it · think before answering

  1. This tests layered understanding: all three entry points share one model; the difference is who supplies the loop and the tools. 'The SDK is higher level' says nothing.
  2. Messages API (@anthropic-ai/sdk / anthropic): one request, one response; you define tools, write the loop, manage context. Fits Q&A, extraction, classification, structured output, cited document Q&A, and custom agents where you want full control of the loop.
  3. Agent SDK (@anthropic-ai/claude-agent-sdk / claude-agent-sdk): Claude Code packaged as a library — built-in Read/Edit/Bash/Glob/Grep, the full agent loop, context management, permissions, hooks, subagents, sessions. You pass a task and options (allowedTools, permissionMode, maxTurns, systemPrompt) and it works in the filesystem. Fits embedding a code-editing agent in your own program.
  4. claude -p: the CLI form of the same Claude Code capabilities, for shell scripts and CI; the Agent SDK is its library form and the docs present them together. One-line rule: model call → API; filesystem agent → Agent SDK; quick scripted call → -p.
  5. Production nuance: with the Agent SDK you still own deployment (it supplies the harness, not hosting); auth is ANTHROPIC_API_KEY, and claude.ai subscription login can't be offered to third-party products. Follow-up: is the Agent SDK the same as the Messages API tool runner? No — the tool runner loops over tools you define and has no built-in file tools.

  答题要点

  • Messages API：一问一答，工具与循环自己写；适合问答、抽取、结构化输出、自定义 Agent
  • Agent SDK：Claude Code 的库形态，内置文件与 Bash 工具、循环、权限、hooks；适合嵌入会改代码的 agent
  • claude -p 是同一能力的命令行形态，适合脚本与 CI
  • 部署仍归自己，认证用 ANTHROPIC_API_KEY；tool runner 不是 Agent SDK

  Key points

  • Messages API: request/response, you write tools and the loop; for Q&A, extraction, structured output, custom agents
  • Agent SDK: Claude Code as a library with built-in file/Bash tools, loop, permissions, hooks; for embedding a code-editing agent
  • claude -p is the CLI form of the same capabilities, for scripts and CI
  • You still own deployment; auth via ANTHROPIC_API_KEY; the tool runner is not the Agent SDK