原创声明：本卷为课程原创教学模拟题，不是、也不冒充官方真题；未使用任何 brain dump 或泄露材料。 对齐 2026-08-30 VERIFIED 的 CCAR-F 形式：60 题 / 120 分钟 / 720 及格（scaled score，量表 100–1,000）。题型 MC + MR（多选标注选择数量）；含 4 道 scenario 题。域配比按官方 VERIFIED 权重 27/20/20/18/15（域名为官方原文）。 与 mock-01 零重复，覆盖互补：本卷侧重 agent 生产的工程细节（生产就绪清单、subagent 隔离与合并）、Claude Code 的 hooks 事件与项目级配置、缓存断点与 prompt 迭代纪律、MCP 服务器配置与工具命名、长会话状态保存与降级可恢复性。
Q1. Per Anthropic's guidance, what makes a system an agent rather than a workflow? (Agentic Architecture & Orchestration) A. It calls more than three tools B. It uses a vector database C. The model directs its own process and tool use to accomplish the task, looping until a stop condition — control flow lives with the model D. It has a web interface
Q2. Why is the "verify results" step essential in an agent loop? (Agentic Architecture & Orchestration) A. It doubles token usage for no benefit B. Without verifying outcomes (tool results, environment state) before finishing, the agent reports success on unverified assumptions and errors compound across the loop C. It is only needed when streaming is enabled D. It replaces stopping conditions
Q3. A generation ends mid-sentence and the API reports stop_reason: "max_tokens". What happened and what should you do? (Agentic Architecture & Orchestration) A. The output hit the max_tokens ceiling and was truncated — raise max_tokens (within model limits) or split the task, then continue B. The model finished normally C. The model requested a tool call D. A stop sequence matched — remove stop sequences
Q4. Which project should use a full agent (not a workflow)? (Agentic Architecture & Orchestration) A. Nightly currency-rate import with a fixed schema B. Template rendering for weekly reports C. Invoice classification into 15 codes D. Open-ended bug triage that must roam an unfamiliar codebase, run searches, form hypotheses, and decide next steps dynamically
Q5. Orchestrator-workers differs from fixed prompt chaining mainly because: (Agentic Architecture & Orchestration) A. It always uses three workers B. It requires a vector database C. A central LLM dynamically decomposes the task and assigns subtasks to worker LLMs whose number and scope are not fixed in advance D. It cannot use tools
Q6. A team runs a stable weekly-report generator: collect from 3 fixed sources → summarize → format. A consultant proposes rewriting it as a 5-subagent multi-agent system. The right architectural response is: (Agentic Architecture & Orchestration) A. Keep the single deterministic workflow — the path is fixed and predictable; multi-agent fails the preconditions (not open-ended, no window overflow) and multiplies token cost (~15×) B. Accept — multi-agent is always more advanced C. Split the difference: 3 subagents D. Accept — fewer than 5 subagents is always wasteful
Q7. In a coordinator-subagent system, a subagent fails on a transient error. The isolation benefit means: (Agentic Architecture & Orchestration) A. The whole system must restart B. The failure (and its retry) stays contained in the subagent's context; the coordinator can retry or reassign without its own context being polluted by the failed attempt C. Subagents can never fail D. The coordinator must absorb the subagent's full failed context
Q8. An evaluator-optimizer loop beats a single pass only when: (Agentic Architecture & Orchestration) A. The task is one-shot classification B. Latency must be minimal C. The steps are strictly ordered with no feedback D. There is a clear evaluation signal and iteration measurably improves quality — otherwise the loop is wasted latency and cost
Q9. Running the same generation 3–5 times and taking a majority vote (parallel voting) is used to: (Agentic Architecture & Orchestration) A. Improve consistency on tasks with variance, trading extra token cost for stability B. Reduce total token cost C. Guarantee correctness D. Eliminate the need for evaluation
Q10. The pattern "agent proposes, deterministic code disposes" refers to: (Agentic Architecture & Orchestration) A. Letting the agent execute writes directly for speed B. Asking the model to choose the runtime language C. The LLM produces recommendations/parameters, and application code validates and executes them — enforcement never depends on the model D. Copying model output straight into production configs
Q11. In multi-agent systems, the recommended way for agents to exchange task state is: (Agentic Architecture & Orchestration) A. Sharing one giant raw transcript across all agents B. Structured handoffs — compact, schema-defined artifacts (findings, decisions, next steps), not full-context dumps C. Verbal instructions via audio D. Letting each agent read the others' entire context windows
Q12.（Select TWO) Which TWO are preconditions that, taken together, justify multi-agent architecture? (Agentic Architecture & Orchestration) A. The task is deterministic and fully enumerable in advance B. The task is open-ended, with an unpredictable number of subtasks C. Subtasks can run in parallel without strict ordering D. The task fits comfortably in one context window with trivial value
Q13.（Select THREE) Match each pattern to its canonical use — which THREE pairings are correct? (Agentic Architecture & Orchestration) A. Routing → triage: send easy requests to a cheap fast path, hard ones to a strong model B. Parallelization → enforce a strictly ordered 5-step sequence C. Prompt chaining → fixed pipeline where each step's output feeds the next D. Evaluator-optimizer → generate, grade against a rubric, revise
Q14.（Select THREE) Which THREE items belong in an agent's production-readiness checklist? (Agentic Architecture & Orchestration) A. Stopping conditions (max iterations, budget, wall-clock) B. An evaluation harness with golden cases that runs on every change C. A plan to disable all monitoring after launch D. Fallback/degradation behavior when dependencies fail
Q15.【Scenario: The multi-agent retrofit debate】 (Agentic Architecture & Orchestration) Scenario: A working single-agent system generates the weekly ops report: fetch metrics from 3 fixed APIs → summarize → format → email. It runs well: 30 s latency, $0.05 per run. A new architect proposes rebuilding it as 5 cooperating subagents (one per source, a summarizer, a formatter, a reviewer). Constraints: source list is stable; no context-overflow issues exist; the budget cannot absorb a 10× cost increase. Options: A. Approve the redesign — multi-agent is the modern default B. Keep the deterministic workflow — the task fails the multi-agent preconditions (not open-ended, parallelizable value is low, no window overflow), and the ~15× token economics do not justify it C. Approve a 3-subagent compromise to show progress D. Replace the LLM steps with handwritten templates only
Q16.【Scenario: Reviewing a huge pull request】 (Agentic Architecture & Orchestration) Scenario: A code-review assistant must review a 40-file, 12k-line pull request. Review quality drops when files are summarized together; per-file depth matters; the aggregate report must stay coherent. Constraints: one context window cannot hold all files with adequate attention; review must complete within 10 minutes; findings must be traceable to files. Options: A. Concatenate all files into one prompt and ask for a single-pass review B. Truncate to the first 50 KB and review only that C. Orchestrator-workers: a coordinator assigns file groups to worker subagents (isolated contexts, read-only tools), workers return structured findings; the coordinator merges and deduplicates into one report D. Ask the model to "try harder" with a higher effort setting on the full diff
Q17. Which content belongs in a project's CLAUDE.md? (Claude Code Configuration & Workflows) A. Repo conventions, build/test commands, coding standards, and pointers to key docs B. API keys for the team's services C. Full CI logs from the last 30 runs D. Nothing — CLAUDE.md is deprecated
Q18. A team wants Claude Code permissions and hooks shared with everyone who clones the repo. The correct location is: (Claude Code Configuration & Workflows) A. Each person's ~/.claude/settings.json B. .claude/settings.local.json (gitignored) C. Project settings committed to the repo (.claude/settings.json), e.g., shared allow/deny rules D. A Slack pinned message
Q19. For a risky, unfamiliar refactor, the recommended working mode is: (Claude Code Configuration & Workflows) A. bypassPermissions to move fast B. acceptEdits, since edits are reversible C. default mode without any review D. Plan mode first: read-only exploration, review the plan, then execute after approval
Q20. What does the acceptEdits permission mode actually auto-accept? (Claude Code Configuration & Workflows) A. Every shell command B. File edits only — other tool classes (e.g., Bash) still follow their rules C. All network access D. Nothing; it is an alias for plan mode
Q21. In Claude Code hooks, a PreToolUse hook exiting with code 2 means: (Claude Code Configuration & Workflows) A. Success; continue the tool call B. A warning is printed but the call proceeds C. The hook crashed and is ignored D. The tool call is blocked, and the hook's stderr is fed back to Claude so it can adjust
Q22. Which hook event is designed for after-the-fact logging/auditing of tool executions (cannot block)? (Claude Code Configuration & Workflows) A. SessionStart B. PreToolUse C. UserPromptSubmit D. PostToolUse
Q23. To guarantee Claude never reads credential files like .env or **/secrets/* in a repo, the right mechanism is: (Claude Code Configuration & Workflows) A. A sentence in CLAUDE.md asking it not to B. Mentioning the files in the system prompt C. A permissions.deny rule such as Read(**/.env) / Read(**/secrets/**) — enforcement at the permissions layer D. Renaming the files to do-not-read.env
Q24. Running claude -p "..." headless in CI, which statement is correct? (Claude Code Configuration & Workflows) A. It can interactively prompt for permissions mid-run B. It behaves exactly like an interactive session C. It requires a GUI display D. It runs non-interactively, so permissions must be pre-authorized (allow-list/deny/hooks) since nothing can be approved mid-run
Q25. What kind of work should be packaged as a Skill? (Claude Code Configuration & Workflows) A. A one-off question about the codebase B. Any secret value C. A repeatable multi-step workflow with stable instructions (and optionally scripts/resources) that the team runs often D. Unrelated personal notes
Q26.（Select TWO) Which TWO mechanism→goal pairings are correct? (Claude Code Configuration & Workflows) A. "Automatically run the test suite after each edit" → PostToolUse / Stop hook B. "Prefer our internal HTTP library over axios" → CLAUDE.md guidance C. "Never let Claude push to main" → write it in CLAUDE.md and rely on the model D. "Block all writes outside src/" → ask nicely in the system prompt
Q27.（Select THREE) Which THREE are true of Claude Code subagents? (Claude Code Configuration & Workflows) A. They run with their own isolated context window B. They can be given a narrower tool set than the main session (least privilege) C. They can explore at scale and return summaries, keeping the main context clean D. They remove the need for an evaluation pipeline
Q28.【Scenario: Migrating a legacy payments module】 (Claude Code Configuration & Workflows) Scenario: An engineer must use Claude Code to refactor a legacy payments module: unfamiliar code, sensitive keys on disk (.env, keys/), and a hard rule that no changes go live without a reviewed plan. Constraints: the engineer wants maximum useful autonomy for exploration; secrets must never enter the context; execution may start only after the plan is approved. Options: A. bypassPermissions + paste the .env contents so Claude "understands the config" B. default mode, no hooks, review the diff manually at the end C. Explore via read-only subagents in plan mode; deny Read on .env/keys/**; produce the plan; human approves; then execute with an edit allow-list D. Skip Claude Code; hand-write the refactor in full
Q29. In the Messages API, the canonical place for standing instructions is: (Prompt Engineering & Structured Output) A. The first user message, repeated every turn B. A preamble inside the latest user message C. The top-level system parameter — a stable prefix that also participates in prompt caching D. The model's display name field
Q30. When assembling few-shot examples, the set should: (Prompt Engineering & Structured Output) A. Reflect the real input distribution, including hard and edge cases — not only the easiest successes B. Contain only the simplest case, repeated C. Come from a different domain than the task D. Be as large as possible, hundreds of examples
Q31. You need guaranteed-valid structured extraction (field names, types, enums). The most direct mechanism is: (Prompt Engineering & Structured Output) A. Describing the JSON in prose and hoping B. Prefilling the assistant turn with { C. Raising temperature for creativity D. Strict tool use / structured output: define the target schema and let schema validation constrain the output
Q32. A repair-retry loop should include a retry cap because: (Prompt Engineering & Structured Output) A. Retries are always free B. Without a cap, a systematically failing case loops forever, burning budget — cap retries, then fall back (e.g., queue for human review or default handling) C. The API forbids retries entirely D. Caps improve creativity
Q33. Your JSON is schema-valid but a field value is factually wrong. The correct diagnosis and fix: (Prompt Engineering & Structured Output) A. This is a format problem — tighten the schema B. This is a model-capability problem — buy a bigger GPU C. This is a semantic problem — constrained decoding cannot help; improve the prompt/few-shots/field descriptions and verify with an evaluation pipeline D. This means the schema is broken; regenerate it
Q34. Per current API behavior (as of 2026-08-30), which statement about thinking/reasoning parameters is correct? (Prompt Engineering & Structured Output) A. Legacy manually tuned thinking budgets (budget_tokens-style parameters) are rejected by newest models — use adaptive thinking, where the model manages reasoning effort (with an effort hint where supported) B. Thinking must be implemented via few-shot examples only C. Temperature replaces thinking entirely D. Thinking parameters apply only to vision inputs
Q35. A job submitted to the Message Batches API returns results within: (Prompt Engineering & Structured Output) A. 60 seconds, guaranteed B. Real-time streaming as rows complete C. Synchronous, before the request returns D. A 24-hour window at roughly half the cost — downstream schedules must tolerate this latency
Q36. With prompt caching, cache breakpoints should be placed: (Prompt Engineering & Structured Output) A. After every single message regardless of stability B. At the boundary after stable content (system prompt + tool definitions) and before per-request variable content, covering the whole stable prefix C. Only on the final message D. Nowhere — placement is irrelevant
Q37. When iterating on a prompt, the sound discipline is: (Prompt Engineering & Structured Output) A. Change several things at once to save time B. Ship vibes-first; measure later, maybe never C. Rely on one anecdotal example as proof D. Change one variable at a time and measure against a fixed eval set before/after
Q38. For system prompts shared across teams, a sound governance practice is: (Prompt Engineering & Structured Output) A. Everyone forks silently and diverges B. Version them centrally and regression-test changes against shared evals before rollout C. Edit them directly in production at will D. Store them in personal chat history
Q39.（Select TWO) Which TWO statements about prompt caching are correct? (Prompt Engineering & Structured Output) A. Cached segments are billed at a discount relative to uncached input B. Cache hits work on any arbitrary middle segment of the request C. The prefix must be identical (byte-for-byte) up to the breakpoint for a hit D. Cache hits make output tokens free
Q40.（Select THREE) Which THREE are sound JSON schema design practices for structured output? (Prompt Engineering & Structured Output) A. Use enums for closed value sets B. Add as many optional fields as possible for "flexibility" C. Write clear field descriptions D. Keep schemas minimal — only fields the task actually needs
Q41. The first question of tool design for any capability is: (Tool Design & MCP Integration) A. Which vendor's tool is cheapest B. What must be decided by deterministic code (validation, authorization, irreversible actions) versus what is genuinely delegated to the model C. How to make every action a tool D. Whether the tool name sounds impressive
Q42. Your extraction step MUST use the schema tool every time (no free-text escape). The right tool_choice setting is: (Tool Design & MCP Integration) A. auto — the model may answer directly B. none C. A forced setting (e.g., tool/any) that requires the named tool / any tool call D. Removing the system prompt
Q43. When a tool call fails for a recoverable reason (bad arguments, missing record), the application should: (Tool Design & MCP Integration) A. Throw an unhandled exception and kill the session B. Return the error to the model as a tool result with an actionable message so it can self-correct C. Silently substitute fake data D. Retry the identical call forever
Q44. A team wants an MCP server config shared with everyone who clones the repo. The standard place is: (Tool Design & MCP Integration) A. A wiki page only B. Each user's global config, entered by hand C. The user's private local-only scope D. .mcp.json at the project root, committed to version control (project scope)
Q45. An MCP server that wraps a local developer database (same machine, no remote clients) should typically use: (Tool Design & MCP Integration) A. Streamable HTTP exposed on 0.0.0.0 B. stdio transport — local process communication, no network exposure C. Email transport D. A public HTTPS endpoint with open access
Q46. Which tool naming/description practice reduces misuse? (Tool Design & MCP Integration) A. Vague names like run_process with no description B. One tool named do_stuff for everything C. Concrete, intent-revealing names plus descriptions stating what it does, when to use it, and constraints D. Randomly generated names for security
Q47. Tool definitions affect cost because: (Tool Design & MCP Integration) A. Tools are billed per definition B. Every exposed tool definition consumes context tokens in each request — unused tools are pure overhead; prune and consolidate C. Tools double output tokens D. They do not affect cost at all
Q48. A tool returns a 50 KB raw JSON blob when the model needs three fields. The best fix: (Tool Design & MCP Integration) A. Increase the context window B. Have the model read it anyway — "more data is better" C. Raise temperature so the model copes D. Trim/reshape tool results server-side to return the fields needed (concise, structured results), preserving context budget
Q49.（Select TWO) Which TWO are sound MCP server security practices? (Tool Design & MCP Integration) A. Forward the end user's token to all downstream services verbatim to "keep identity" B. For local HTTP servers, validate the Origin header to block DNS-rebinding C. Give each server its own scoped, minimal credentials (no token passthrough) D. Bind local servers to 0.0.0.0 so everyone can reach them
Q50.（Select TWO) Which TWO belong in a tool-design checklist? (Tool Design & MCP Integration) A. Keep tools focused: one tool, one purpose B. Overlap tool functionality so the model has "choice" C. Avoid overlapping tools that do near-identical things — ambiguity degrades selection D. Hide errors from the model to avoid confusing it
Q51.【Scenario: The enterprise tool sprawl】 (Tool Design & MCP Integration) Scenario: An internal platform lets 12 teams register MCP servers for a shared enterprise agent. Users now see 90+ tools; selection accuracy has dropped, wrong-tool incidents are rising, and per-request cost climbed 40%. Constraints: no team will accept deletion of its capabilities; tool definitions keep growing; per-request token budget is fixed. Options: A. Load all 90 tool definitions into every request and hope scale fixes it B. Freeze registrations permanently — no new tools ever C. Keep every tool but rename them all to 3-letter codes D. Progressive discovery / tool search: expose a searchable catalog of tool descriptions; load full definitions only when relevant; back it with a registry requiring quality descriptions and ownership
Q52. "We have a 1M-token context window now — we can stop building retrieval and just stuff everything in." This is wrong primarily because: (Context Management & Reliability) A. 1M tokens is still too small for any corpus B. Long contexts are billed at zero C. Vendors forbid large contexts in production D. Context rot: recall and reasoning degrade as the window fills; plus cost and latency scale with tokens — curation and JIT retrieval remain necessary
Q53. Just-in-time retrieval means: (Context Management & Reliability) A. Downloading the whole knowledge base nightly B. Fetching specific material at the moment a task needs it, keeping the context lean and current C. Caching everything at session start forever D. Asking the user to paste documents manually
Q54. Escalation rate (share of conversations handed to humans) should be monitored because: (Context Management & Reliability) A. It is the only metric that matters B. A spike signals quality regressions, policy drift, or tool failures — and it directly drives staffing cost; track it against a target band C. Regulators require it in all industries D. It replaces the need for CSAT
Q55. The predictable failure mode of approval prompts that fire too often is: (Context Management & Reliability) A. Faster approvals B. Better models C. Approval fatigue: reviewers rubber-stamp without reading, defeating the control D. Lower latency
Q56. A regulator asks you to justify a specific AI-drafted decision made last quarter. The design element that makes this answerable is: (Context Management & Reliability) A. Model weights B. Temperature logs C. The prompt's SHA hash only D. Provenance: stored citations linking each claim in the output to source documents (with versions/IDs), retrievable after the fact
Q57. A circuit breaker differs from a retry with backoff in that it: (Context Management & Reliability) A. Retries faster than backoff B. Stops calling the failing dependency entirely (for a cooldown) to prevent cascade failure, instead of continuing timed retries C. Is a load balancer feature only D. Applies only to client-side errors
Q58.（Select THREE) Which THREE practices keep long agent sessions reliable? (Context Management & Reliability) A. Periodically checkpoint state as structured notes (task progress, key facts, constraints) B. Re-inject critical constraints after compaction/summarization so early rules are not "forgotten" C. Verify results before irreversible actions D. Raise temperature progressively as the session lengthens
Q59.（Select TWO) Which TWO items belong in a human escalation handoff? (Context Management & Reliability) A. The original request and customer intent B. What was already attempted and the outcomes (plus a trace ID) C. Only the last assistant message, out of context D. A bare "please handle this" note
Q60.（Select THREE) Which THREE are properties of well-designed graceful degradation? (Context Management & Reliability) A. Responses on the degraded path are explicitly marked as degraded B. Degraded-path traffic is measured separately in observability C. Degraded mode pretends nothing happened, silently D. There is a tested path to switch back to full quality
（Mock 02 完） · 对答案：mock-02-answers.md · 回看卷一：mock-01.md
来源：考试形式与域权重 = 官方 Exam Guide + Skilljar 认证页（VERIFIED，截至 2026-08-30，见 ../00-certification-current-status/certification-status.md）；题目技术内容 = 本课程模块 M01–M13 原创。📚 目录