Chapter 08 · Domain 1（本章 skill 权重合计 9.8%）
Agent 架构与构建从「该不该用 agent」推到「用哪条落地路径」
整章从一个分岔口推起：这个需求该写成 workflow，还是该做成 agent？ TS 1.1 考的是这个判断本身与它派生的结构（manager/supervisor 层级、subagents 的作用）；TS 1.2 考的是判断做完之后落到哪条路径上（Claude Agent SDK、custom agent loops 与 harnesses、managed agent 的两种部署形态、hooks 用于确定性动作）。两条 skill 是同一条决策链的上下游，所以本章按链条顺序走，不按名词罗列。
本章的事实纪律 — 「agent」这个词在业界被用得极松，所以本章每个定义都挂官方出处：workflow 与 agent 的定义、五个模式、agent loop 的步骤、Agent SDK 的能力面、hooks 的确定性语义、managed agent 的两种 Environment，全部有 vb: 登记。本章不写任何 SDK 的具体 API 签名 ——那超出 blueprint 的粒度，也是最容易过期的部分。
一、分岔口：谁在决定下一步
Anthropic 给的定义把界线画在一个地方——控制流由谁掌握 。
workflow 是 LLM 与工具被预先写好的代码路径 （predefined code paths）编排起来的系统；agent 是 LLM 自己动态指挥 其流程与工具使用、并对「如何完成任务」保有控制权的系统。
把这句话翻译成读题动作：看题干里「下一步做什么」是谁定的。 如果步骤序列在需求里就是固定的——先抽取、再校验、再入库，永远这三步——那它是 workflow，哪怕每一步内部都在调 LLM。如果步骤数和步骤内容取决于中途看到了什么——文件里有几个引用就跟进几个，测试红了就回头改——那才是 agent。
信号 指向
步骤序列在设计时就能写死 workflow 需要的工具调用次数事先不知道 agent 「根据上一步结果决定跳哪个分支」，但分支集合是有限且已知的 workflow（routing） 「根据环境反馈自己决定接下来干什么」，动作空间开放 agent
官方对 agent 的补充描述值得抄下来：agent 从人的一条命令或一次交互式讨论开始，任务明确之后就独立规划与运行 ；它们能处理复杂任务，但实现往往很直接——典型形态就是 LLM 在一个循环里根据环境反馈使用工具 。最后半句是本章第四节的引子：agent 不是一套神秘架构，它就是一个循环。
二、先轻后重：官方自己先说了「多数情况别上」
这是本章最容易被跳过、却在题目里出现频率最高的一节。官方的建议原话是：找最简单可行的方案，只在需要时才增加复杂度 ；agentic 系统常常是拿延迟与成本换更好的任务表现 ，你要判断这笔交换划不划算；而且——对很多应用来说，用检索与 in-context 示例优化单次 LLM 调用通常就够了 。
这段话是 ch01 P10 「先轻后重」在 Domain 1 的官方背书，也是 D7 过度工程 这一类干扰项的判据来源。考场上的用法很直接：题干如果没有给出「轻量方案已经试过且失败」的证据，那么「建一套多 agent 编排」通常就是那个错误选项。
代价那一侧也有原话。agent 的自主性让它适合在受信环境 里扩展任务；但自主也意味着更高的成本与错误累积（compounding errors）的可能 ，官方建议在沙箱环境里充分测试 并配上适当的 guardrails。三个关键词——受信环境、错误累积、沙箱测试——每一个都能单独成为一道题的判据。
三、五个 workflow 模式，与那个「manager 层级」
决定用 workflow 之后，官方给了五个有名字的模式。记住定义比记住名字有用，因为题干通常描述形状而不点名。
模式 官方定义 什么形状的需求
Prompt chaining 把任务拆成一串步骤，每次 LLM 调用处理上一次的输出 步骤固定且有序，前一步的产物就是后一步的输入 Routing 对输入分类，并把它导向一个专门的后续任务 输入有若干已知类别，每类该走不同的处理 Parallelization 多个 LLM 同时处理一个任务，输出被程序化地 聚合 子任务彼此独立，或需要多次独立判断再投票 Orchestrator-workers 一个中心 LLM 动态拆解任务、委派给 worker LLM、再综合它们的结果 子任务的划分方式 事先不知道，要看输入才能定 Evaluator-optimizer 一个 LLM 调用生成回应，另一个在循环里提供评估与反馈 有明确的质量标准，且反馈能带来可观改进
TS 1.1 点名的「manager/supervisor 层级结构」在官方词汇里就是 orchestrator-workers。 它与 parallelization 的分界线只有一条，也是最常被做成干扰项的一条——子任务是谁划分的 。parallelization 里子任务是你在代码里切好的；orchestrator-workers 里子任务是中心 LLM 看了输入之后现场决定的。「我们并行跑五个固定的检查」不是 orchestrator-workers；「让它自己看这个 PR 要跑哪几类检查、跑几个」才是。
四、agent loop 的解剖：一个 turn 到底是什么
决定用 agent 之后，你要么自己写这个循环（custom agent loop），要么用别人写好的 harness。两条路都得先知道循环长什么样。
官方对循环的描述是：Claude 评估你的 prompt、调工具采取行动、拿到结果，如此往复直到任务完成 。展开成步骤是：① 收到 prompt（连同 system prompt、tool 定义与对话历史）；② 评估并回应——可能是文本、可能是一个或多个 tool call、也可能两者都有；③ 执行工具并收集结果，结果回喂给 Claude 做下一个决定；④ ②③ 反复循环，每个完整 cycle 是一个 turn ；⑤ Claude 一直调工具、处理结果，直到它产出一个不含任何 tool call 的回应 ——那就是终止条件。
终止条件是这一节的考点。 循环不是靠步数停的，是靠「模型这一轮没有再要工具」停的。所以它天然可能不停。官方对 turn 的定义里还有一句集成层必须知道的话：一个 turn 是循环里的一个来回——Claude 产出含 tool call 的输出、SDK 执行这些工具、结果自动回喂给 Claude——这个过程不会把控制权交回你的代码 。也就是说，你不能靠「在两次调用之间检查一下」来兜底。
官方给的兜底是两个显式上限：max_turns（只数 tool-use 来回）与 max_budget_usd（按花费封顶）；触顶时返回带对应 error subtype 的 ResultMessage。不设限时，循环会一直跑到 Claude 自己收手 ——官方说这对界定清楚的任务没问题，但对开放式 prompt 可能跑很久。
把这条接回 ch01 — 「agent 跑飞了」在题目里常被写成一个成本或时长的数字（跑了 40 分钟、烧了 $18、调了 200 次工具）。这类题干指认的变量是循环的边界 ，不是模型能力，也不是 prompt 措辞。看到「换个更聪明的模型让它早点收手」先按 D4 处理，看到「在 system prompt 里要求它最多调十次工具」先按 D3 处理——那是请求，不是闸门（P3 ）。
五、subagents：它改进的是上下文，不是智力
TS 1.1 把「subagents 在改进任务执行中的角色」单列。官方给的机制解释很具体，而且答案不在「更聪明」那一侧。
每个 subagent 从全新对话 开始（没有此前的消息历史，但会加载自己的 system prompt 与项目级上下文如 CLAUDE.md）；它看不到父的各个 turn ；只有它的最终回应会回到父 。于是主 agent 的 context 增长的是那份 summary，而不是整段子任务记录。
把这句话拆成两个工程收益：
主上下文不被子任务的过程污染。 一次「把这个仓库里所有调用点找出来」的搜索可能产生几十次 tool call 与上万 token 的输出；放进主循环，它们会一路跟着后面每一轮重发。放进 subagent，主循环只拿到结论。这是 ch01 P9 「上下文是预算」最有力的一个落点。子任务可以带自己的工具集与 system prompt。 它不继承父的对话，也就意味着可以给它一套更窄的工具面。
反过来，subagent 不解决的问题也要记清楚 ：它不让模型变强，也不让子任务更准；而且「父看不到过程」是双向的——如果下游需要子任务的中间证据，那份证据不会自动出现在主上下文里，得由 subagent 显式写进它的最终回应。题干说「主 agent 后来引用了一个它其实没看到的细节」时，这就是根因。
六、四条落地路径：别把它们当成同一个东西的四种叫法
TS 1.2 点名了 Claude Agent SDK、custom agent loops 与 harnesses、managed agent 部署模型。官方文档正好有一张四选一的表，把边界划得很干净。
你在做的事 选 官方给的理由
要建一个 agent，但不想自己实现 tool loop Agent SDK 一个在你自己的进程 里跑 agent loop 的库，Python 或 TypeScript 在终端里做交互式开发或跑一次性任务 Claude Code CLI 面向日常交互使用的终端界面 直接调 API，自己实现 tool loop Client SDK 直接访问 Claude API 而不是 Claude Code；tool loop 自己写，或交给 beta tool runner ；需要人工审批时官方让你回到 manual loop 跑长时间或异步的 agent，又不想自己管 sandbox 与 session 基础设施 Managed Agents Anthropic 托管的 agent harness，与 Agent SDK 是两个不同的产品 ；agent loop 由 Anthropic 跑，session 跑在 Anthropic 管理的云沙箱或你自托管的沙箱里
Claude Agent SDK 是什么 ：它把驱动 Claude Code 的同一套 工具、agent loop 与 context management 交给你，在 Python 与 TypeScript 里可编程。一条容易被做成干扰项的限制：它只 以 Python 与 TypeScript 库的形式提供；要在别的语言里驱动同一个 agent loop，官方给的办法是把 CLI 当子进程跑 （-p 加 --output-format json），而不是有一个 Go 或 Java 版的 Agent SDK。
它带来什么 ：built-in tools（读写编辑文件、跑命令、搜网）、hooks（在 agent 生命周期关键点跑自定义代码）、subagents（为聚焦的子任务生成专门 agent）、MCP、permissions（控制哪些工具自动跑、哪些要审批）、sessions（跨轮保持上下文，可 resume 或 fork），以及 skills / commands / memory 与 plugins。
与 Client SDK 的界线 由 ch06 第七节主讲（七种语言、内建的 streaming／retries／error handling、以及「你发每一个请求、处理每一个响应」那条定性），本章不重复。这里只补它没有 覆盖的增量：选了 Client SDK 之后你要自己写的那段东西——tool loop 的调度、终止判定、turn 与预算的记账、subagent 的派生与结果回收 ——正是 Agent SDK 直接给你的运行时。「custom agent loop」不是一个产品名，它就是这段自研代码的统称。
七、managed agent 的部署模型：Anthropic-hosted 与 self-hosted
TS 1.2 把 self-hosted vs. Anthropic-hosted 单独点名。官方文档里这个取舍不在「agent」这一层，而在 Environment 这一层。
先定位产品：Claude Managed Agents 是预制、可配置的 agent harness，跑在托管基础设施上 ，适合 long-running 与异步工作；它提供 harness 与基础设施，你不用自己建 agent loop、tool execution 与 runtime。对照之下 Messages API 是直接的模型提示访问，适合 custom agent loops 与细粒度控制。
它围绕四个概念构建：Agent （模型、system prompt、tools、MCP servers、skills）、Environment （session 在哪儿跑的配置：Anthropic 托管的 cloud sandbox，或你自己基础设施上的 self-hosted sandbox ）、Session （environment 里一个正在运行的 agent 实例）、Events （你的应用与 agent 之间往来的消息）。部署形态是 Environment 的属性，不是 Agent 的属性 ——同一个 agent 定义可以配到不同的 environment 上，这是本节最容易被做成干扰项的一处。
self-hosted 到底把什么留在了你这边
这是全章最需要精确的一段，因为「self-hosted」这个词很容易被读成「什么都在我这儿」。
官方的分工是：工具执行移进你控制的基础设施 ，Anthropic 继续运行 agent——Claude 在 Anthropic 一侧请求 tool call，你这边在本地执行并回传结果；工具的输入与输出仍然流向 Anthropic 的 control plane ，好让模型看到结果并决定下一步。换成数据面的说法：agent 的文件与进程留在你的 worker 上，但 tool 返回给模型的内容仍会到达 Managed Agents 服务。
承载这件事的组件有个名字：environment worker 是你在自己基础设施上运行的一个进程，服务 self-hosted 环境的 work queue：领取 session 的 work item，在本地执行 Claude 请求的每个 tool call 并回传结果。
还有一条数据面的细节容易被忽略：即使 self-host，agent 的 skills 与 memory stores 仍由 Anthropic 存储 ，worker 在 session 期间下载一份副本到你的沙箱；memory store 的工作副本放在 /mnt/memory/ 下，改动会同步回去，session 结束时删除。
Anthropic-managed cloud sandbox Self-hosted sandbox
工具在哪执行 Anthropic 的沙箱 你的主机 （由 environment worker 接单）模型在哪跑 Anthropic Anthropic（tool 输入输出仍流向 control plane ） 能触达的网络 沙箱预置的网络访问 你控制 ，可达非公网可路由的内部服务典型动因 不想管基础设施 数据不能出网络边界、合规与审计控制
官方给的选型判据：agent 需要操作不能离开你网络边界 的数据、需要触达非公网可路由 的内部服务、或需要在你们组织自己的合规与审计控制 下运行——满足其一就适合 self-hosting。反过来，Managed Agents 整体适合的场景官方也列了：long-running execution、cloud infrastructure、self-hosted execution、minimal infrastructure、stateful sessions、scheduled execution。
八、hooks：确定性动作那一面
TS 1.2 的措辞是「hooks 用于 deterministic actions 」，官方文档几乎是同一句话的展开。
hooks 是用户自定义的 shell 命令，Claude Code 在其生命周期的特定点运行它们，这带来确定性控制：某些动作总会发生，而不是依赖 LLM 选择去跑它们 。reference 页把载体写得更全：hooks 是用户自定义的 shell 命令、HTTP 端点、MCP tool call、LLM prompt 或 subagent ，在生命周期的特定点自动执行。
常用的事件名要能认得出来：SessionStart（会话开始或恢复）、UserPromptSubmit（你提交 prompt 后、Claude 处理前）、PreToolUse（工具调用执行前 ，可阻断 ）、PermissionRequest（工具调用需要权限决定时）、PostToolUse（工具调用成功后 ）、PostToolUseFailure（工具调用失败后）、SubagentStart / SubagentStop、Stop（Claude 回应完成时）、PreCompact（上下文压缩前）、SessionEnd。
本章只讲确定性那一面 — hooks 在 TS 7.3 还会出现，那是
安全阻断 的角度（拦住破坏性动作、把注入进来的指令挡在敏感操作之外），写在
ch14 。本章的角度是 TS 1.2 的
deterministic actions ：
不是「拦住坏事」，是「保证好事每次都发生」 ——编辑完文件总要跑格式化、任务结束总要归档 transcript、subagent 完成总要记一笔。两章用的是同一个机制，判据不同。
两条工程性质决定了 hooks 在 agent 里的位置。其一，hooks 跑在你的应用进程里，不在 agent 的 context window 里，所以它们不消耗 context ——这让「每轮都要做的杂事」有了一个不吃预算的去处。其二，hooks 能给循环短路 ：一个拒绝该次 tool call 的 PreToolUse hook 会阻止它执行，Claude 收到的是那条 rejection message。
那么什么时候不 该用 hook？官方自己给了边界：对于需要判断 而不是确定性规则的决策，可以用 prompt-based hooks 或 agent-based hooks，它们用一个 Claude 模型来评估条件。换句话说：能写成规则的用命令 hook，写不成规则的才让模型来判——而不是反过来，把一条本可以写死的规则塞进 prompt 里祈祷它被遵守。
本章刻意没写的：Agent SDK 的具体 API 签名（
query() 的参数表、消息类型联合体、permission mode 的逐档语义）、hook 的 JSON 输入输出 schema、Managed Agents 的端点与 beta header。这些是真实存在且已查证的，但粒度远超 blueprint——TS 1.2 考的是「知道有这条路径、知道它解决什么」，不是「默写参数名」。同理，agentic 抽象框架（Strands / LangGraph / PydanticAI）与 tool-use loops、memory 等模式属 TS 1.3，见
ch09 ；hooks 的安全用法见
ch14 。
考点回链 — 本章覆盖：TS 1.1（workflow 与 agent 的官方定义与「控制流归谁」这条判据、「先找最简方案」与 agentic 系统拿延迟成本换表现的取舍、五个 workflow 模式及 orchestrator-workers 即 manager/supervisor 层级、parallelization 与 orchestrator-workers 的分界、agent 自主性带来的成本与错误累积及沙箱测试加 guardrails、subagents 的全新对话／只回传最终回应／主上下文只增长 summary）、TS 1.2（Claude Agent SDK 的定位与仅 Python／TypeScript 的限制、其能力面、agent loop 五步与「产出无 tool call 的回应」这一终止条件、turn 的定义与不交回控制权、
max_turns 与
max_budget_usd 两个上限、Agent SDK／CLI／Client SDK／Managed Agents 四选一、custom agent loop 的含义、Managed Agents 的四个核心概念与 Environment 决定部署形态、self-hosted 下工具执行在你的主机而 tool 输入输出仍流向 control plane、environment worker、self-hosting 的三条动因、hooks 的确定性语义与常用事件名、hooks 不消耗 context 且可短路循环、判断类决策改用 prompt-based 或 agent-based hooks）。相邻考点：agent 设计模式与第三方框架见
ch09 ；一次调用的解剖与 tools 往返见
ch02 ；plugin 打包与依赖见
ch04 ；SDK 与 REST 的关系、effort 对工具调用密度的影响见
ch06 ；context 预算与 compaction 见
ch11 ；工具实现与 MCP server 见
ch12 ；hooks 的安全阻断用法见
ch14 。
本章题组
QUESTION 01 · TS 1.1 · WORKFLOW OR AGENT
An invoice pipeline runs the same three steps on every document: extract fields, validate them against a schema, then write a row to Postgres. Volume is 40k/day, the step order never varies, and each step already works as a single Claude call. A new engineer proposes rebuilding it as an autonomous agent with file, database, and shell tools "so it can handle edge cases on its own." What should the reviewer conclude?
A Rebuild it as an agent but cap the loop with max_turns and a per-document budget, since the caps recover the predictability the current pipeline has while still letting the model handle documents the fixed steps mishandle. B Adopt a hybrid: keep extraction and validation as fixed steps, but let an agent decide at runtime whether the database write should be an insert, an update, or a skip, which is where most of the current edge-case failures land. C Rebuild it as an agent, because a three-step chain where each step calls an LLM already meets the definition of an agentic system, and the proposal only makes the existing autonomy explicit rather than adding any. D Keep it a workflow. The dividing line is who directs the control flow, and here the sequence never varies, so predefined code paths are the right shape. Add agency only where a documented failure shows the fixed path cannot cover it.
正确 D 官方的定义把界线画在控制流归谁：workflow 是 LLM 与工具被预先写好的代码路径 编排的系统，agent 是 LLM 自己动态指挥流程与工具使用的系统。题干明说 step order never varies——这正是 workflow 的形状。加上官方那条「找最简单可行的方案，只在需要时才增加复杂度」，在没有失败证据之前重建就是过度工程。
D7 过度工程 违反 P10 A ：加 max_turns 与预算上限本身是对的做法，但它是在为一个尚未被论证的重建补救风险 。轻的一档（现有 workflow）没有被证明失败过，题干里「handle edge cases」连一个数字都没有。
D6 半对半错 违反 P1 B ：混合形态在别的场景确实是好答案，但这一项自带一个题干没有的前提——「most of the current edge-case failures land」在写库那一步。题干没给任何失败分布数据。而且「insert / update / skip」是一个有限且已知 的分支集合，那是 routing 的形状，用代码写死即可，不需要 agency。
D1 凭空捏造 违反 P5 C ：「每步都调 LLM 就已经是 agentic system」与官方定义直接冲突——判据是 LLM 有没有动态指挥自己的流程 ，不是调用次数。这一项把一个真实术语安上了它没有的判定标准。
QUESTION 02 · TS 1.1 · WHICH MULTI-LLM PATTERN
A code-review service must review incoming PRs. Which checks apply is not known in advance: a migration PR needs schema and rollback review, a UI PR needs accessibility and bundle-size review, and some PRs need neither. The team currently fans out to the same five reviewer prompts on every PR and aggregates the scores in code; 60% of those calls return "not applicable." Which pattern fits the requirement?
A Keep parallelization but add a cheap pre-filter prompt per reviewer that returns early when the check does not apply, which preserves the fixed fan-out shape while eliminating most of the wasted reasoning tokens. B Switch to prompt chaining so each reviewer receives the previous reviewer's findings, letting later checks skip work that earlier ones already ruled out and removing the not-applicable calls. C Orchestrator-workers: a central LLM breaks the task down at runtime, delegates the checks this PR needs, and synthesizes what comes back. The subtask set is decided per input rather than fixed in code. D Evaluator-optimizer: run the five reviewers as generators and add an evaluator that scores each finding, discarding the not-applicable ones in a feedback loop until only relevant findings remain.
正确 C 官方定义：orchestrator-workers 是一个中心 LLM 动态拆解任务、委派给 worker LLM、再综合它们的结果 。题干的关键句是「which checks apply is not known in advance」——子任务的划分方式 要看输入才能定，这正是它与 parallelization 的分界线（后者的子任务是你在代码里切好的）。
D6 半对半错 违反 P1 A ：预过滤确实能省 token，但它把「哪些检查适用」这个判断复制了五份、各自独立做一遍，仍然是固定 fan-out。题干指认的变量是子任务集合应当由输入决定 ，这一项没有改变那个形状，只是让浪费变便宜。
D5 错层承载 违反 P4 B ：prompt chaining 的定义是把任务拆成一串有序步骤 ，每次调用处理上一次的输出。把五个彼此独立的检查串成链，等于给它们强加一个不存在的顺序依赖，还把可并行的工作变成串行。
D7 过度工程 违反 P10 D ：evaluator-optimizer 是「一个生成、一个在循环里评估反馈」，用在有明确质量标准且反馈能带来改进的场景。这里的问题不是findings 质量不够好，是压根不该跑那些检查 ；加一层评估循环去丢弃本不该产生的输出，比在源头选对检查贵得多。
QUESTION 03 · TS 1.2 · BOUNDING THE LOOP
A nightly repo-maintenance agent built on the Agent SDK is given the prompt "improve test coverage in this service." Most nights it finishes in 6 minutes. Twice this month it ran for over four hours and spent $40 before an operator killed it; the transcripts show it kept opening more files and writing more tests, never producing a turn without tool calls. What is the correct fix?
A Set max_turns and max_budget_usd, and narrow the prompt to a scoped objective. max_turns counts tool-use round trips, and hitting either limit returns a ResultMessage carrying the matching error subtype for the caller to handle. B Wrap the SDK call in a wall-clock timeout in the scheduler and cancel the process at 20 minutes, since the loop yields control back to the caller between turns and can therefore be interrupted cleanly at a turn boundary. C Add a line to the agent's system prompt stating that it must stop after at most 15 tool calls and report what it completed, and have the operator alert on sessions exceeding 20 minutes as a backstop. D Lower effort to "low" for the nightly job so each turn produces fewer tokens and fewer tool calls, which brings the long runs back in line without changing the agent's objective.
正确 A 循环的终止条件是「Claude 产出一个不含 tool call 的回应」，而题干说的正是这个条件从未满足。官方给的显式边界就是这两个：max_turns 只数 tool-use 来回、max_budget_usd 按花费封顶，触顶时返回带对应 error subtype 的 ResultMessage；不设限时循环会一直跑到 Claude 自己收手。「improve test coverage」正是官方点名的开放式 prompt。
D1 凭空捏造 违反 P5 B ：理由那半句与官方原文相反——一个 turn 里 Claude 产出 tool call、SDK 执行、结果自动回喂，这个过程不会把控制权交回你的代码 。所以「在 turn 边界干净地中断」这个前提不成立；进程级超时能杀掉它，但拿不到 ResultMessage 里的用量与 session id。
D3 措辞冒充控制 违反 P3 C ：在 system prompt 里写「最多调十五次工具」是请求 而不是闸门。而且告警只是在事后通知你已经烧掉了钱，它作用在「你什么时候知道」上，不作用在「它什么时候停」上。
D4 换模型当解法 违反 P1 D ：effort levels 是 blueprint 点名的 model option，降它确实会让 Claude 少调工具，但它是软引导而不是上限。题干要的是「不会再出现四小时 $40」的保证，而这一项给的是一个倾向；开放式目标没有变，循环仍然可以跑很久，只是每一步便宜一点。
QUESTION 04 · TS 1.1 · WHAT A SUBAGENT ACTUALLY BUYS
A migration agent must find every call site of a deprecated function across a large monorepo, then rewrite them one by one. Running the search inline costs ~120 tool calls and 90k tokens of grep output, and the main session hits compaction before the rewrites start. The team moves the search into a subagent. Rewrites now proceed, but the agent occasionally rewrites a call site using the wrong overload, and the transcript shows it never saw the surrounding code it needed. What explains both outcomes?
A The subagent inherits the parent's conversation but not its tool results, so the search output was dropped while the plan was kept; pass the search results back explicitly as a user message to restore the missing detail. B Only the subagent's final response returns to the parent, so the main context grew by a summary instead of 90k tokens — and anything it omitted is invisible downstream. Have it emit the overload context. C The parent's compaction ran anyway and summarized away the subagent's result, so the rewrite step worked from a lossy summary; disable automatic compaction for this session so the full subagent output stays in context. D Subagents run with a smaller model by default to keep delegation cheap, which is why the search succeeded but the overload disambiguation, a harder judgment, came back wrong; raise the subagent's model to match the parent.
正确 B 官方对 subagent 的机制描述同时解释了两个结果：每个 subagent 从全新对话开始、看不到父的 turn，只有它的最终回应会回到父 ，主 agent 的 context 增长的是那份 summary 而不是整段子任务记录。省下 90k token 与「父看不到过程」是同一条机制的两面 ，所以修法是让 subagent 把下游需要的证据写进最终回应。
D1 凭空捏造 违反 P5 A ：「继承父的对话但不继承 tool result」是编的。官方说 subagent starts with a fresh conversation，看不到父的各个 turn ——方向正好相反。后半句的动作恰好会把省下来的 90k token 原样搬回主上下文，等于取消这次改造。
D6 半对半错 违反 P9 C ：compaction 确实会把早期历史压成摘要，这半句是真的。但题干说的是主会话在改造之前 才撞到 compaction；改造之后主上下文只增长一份 summary，问题变成了那份 summary 本身不含 overload 信息。关掉压缩不会让从未进入上下文的内容出现。
D4 换模型当解法 违反 P5 D ：「subagent 默认换小模型」不是官方描述的机制。而且题干给的证据是 it never saw the surrounding code it needed ——那是信息缺失，不是判断力不足；给一个看不到证据的模型升档，它只会更自信地猜错。
QUESTION 05 · TS 1.2 · MAKE THE GOOD THING ALWAYS HAPPEN
A team's Agent SDK service edits TypeScript files. Their convention is that prettier --write must run on every file the agent touches. They put "always run prettier after editing a file" in CLAUDE.md; over 200 sessions it happened in 71% of edits. They also note their context budget is already tight. What should they implement?
A Move the instruction from CLAUDE.md into the agent's system prompt and repeat it once more in the user prompt, since system-level instructions are re-sent on every request and are followed far more consistently than project memory. B Add a Stop hook that formats the whole repository once the agent finishes, which keeps the per-edit path untouched and guarantees the final tree is formatted regardless of how many files were edited. C Register prettier as a custom tool and describe in the tool description that it must be called after every Edit, so the model has an explicit affordance instead of a prose instruction to remember. D A PostToolUse hook on the edit tool, which fires when that call succeeds. Hooks give deterministic control — the action always happens instead of depending on the model — and they run in your process, off the context window.
正确 D 这正是官方给 hooks 的定位：Claude Code 在生命周期的特定点运行它们，这带来确定性控制：某些动作总会发生，而不是依赖 LLM 选择去跑它们 ；PostToolUse 的触发时机是「工具调用成功后」。题干的第二个约束也被同时满足——hooks 跑在你的应用进程里、不在 agent 的 context window 里，所以不消耗 context。
D3 措辞冒充控制 违反 P3 A ：换个位置放同一句话，仍然是措辞。CLAUDE.md 本身就被官方定性为 context 而不是被强制的配置，要在不管模型怎么判断的情况下让动作发生，该用 hook。而且重复两遍还额外吃 context，与题干的第二个约束相反。
D6 半对半错 违反 P1 B ：Stop hook 是真实事件、时机也没写错，收尾格式化确实能让最终树是格式化的。但它把「每个被触碰的文件」偷换成了「整个仓库一次」——在大仓库里这会改动大量 agent 没碰过的文件，把一次编辑变成一个巨大的 diff。约束被换掉了。
D3 措辞冒充控制 违反 P3 C ：把「必须调用」写进 tool description，还是在请求模型自觉。tool description 的官方职责是说明工具做什么、何时用、如何表现，它影响的是模型的选择倾向，而题干给出的 71% 恰恰说明倾向不够。
QUESTION 06 · TS 1.2 · PICK THE PATH
A Go backend team must add an agent that triages incoming support tickets: it reads internal docs, calls two internal REST services, and drafts a reply. They want the agent loop, tool execution, and permission gating handled for them rather than hand-rolled, and the agent must run inside their existing Go service process. Which option is correct, and why?
A Use the Claude Agent SDK's Go client, which provides the same agent loop, hooks, and permission model as the Python and TypeScript packages and links directly into an existing Go binary. B The Agent SDK ships only as Python and TypeScript libraries, so there is no Go build. Run the Claude Code CLI as a subprocess with -p and --output-format json to drive the same loop from Go. C Use the Go Client SDK and implement the tool loop over the Messages API, since the Client SDK already handles retries and streaming, which is the substantive part of an agent loop. D Use Claude Managed Agents and call it from Go over its REST API, which is the supported way to get a managed agent loop from a language without an SDK, and keeps ticket handling inside the team's process.
正确 B 官方把这条限制与它的解法写在同一段：Agent SDK 只 以 Python 与 TypeScript 库的形式提供；要在别的语言里驱动同一个 agent loop，就把 CLI 当子进程跑（-p 加 --output-format json）。这同时满足题干的两个约束——不自己实现 loop，且跑在自家进程边界内。
D1 凭空捏造 违反 P5 A ：Go 版 Agent SDK 不存在——这个包名是本书自制的干扰项，没有官方出处 。Anthropic 确实有 Go 的 Client SDK，名字相近正是这一项的诱饵；但 Agent SDK 的语言支持官方写得很死。
D6 半对半错 违反 P4 C ：Client SDK 确实内建 streaming、retries 与 error handling，但官方对它的定位是「直接访问 Claude API，tool loop 自己写，或交给 beta tool runner 」。这一项把重试当成了 agent loop；而即便改用 tool runner，官方也说需要 human-in-the-loop 审批时要回到 manual loop，满足不了题干「permission gating 也交给框架」。
D5 错层承载 违反 P4 D ：Managed Agents 是 Anthropic 托管的 agent harness，agent loop 由 Anthropic 跑 （沙箱可以是 Anthropic 管理的云沙箱，也可以自托管）。它是个合理的产品选择，但与题干「agent 必须跑在他们现有的 Go 服务进程里」直接冲突——agent loop 不在那个进程里。
QUESTION 07 · TS 1.2 · WHERE THE SANDBOX LIVES
A bank wants a Managed Agents deployment for log triage. Regulatory constraints: the log files themselves may not leave the bank's network, and the agent must query an internal metrics service that has no public route. Security asks whether a self-hosted sandbox means "nothing reaches Anthropic." What is the accurate answer?
A Correct as stated: with a self-hosted sandbox the model is served from the environment worker on the bank's own infrastructure, so neither the log files nor any derived content crosses the network boundary. B Self-hosting is not the right control here; configure the Anthropic-managed sandbox with an egress allowlist for the metrics service and rely on zero-retention terms so the log contents are never persisted outside the bank. C Tool execution stays on the bank's host, run by an environment worker there, but tool inputs and outputs still flow to Anthropic's control plane, where Claude runs and picks the next step. Scope what the tools return. D Self-hosting applies to the agent rather than the environment, so the bank should define one self-hosted agent for log access and a separate managed agent for drafting, and route each session to the appropriate one.
正确 C 官方把分工写得毫不含糊：工具执行移进你控制的基础设施，由你的 worker 在本地执行——但工具的输入与输出仍然流向 Anthropic 的 control plane，Claude 在 Anthropic 一侧运行 ，好让模型看到结果并决定下一步。承载执行的是你自己跑的 environment worker。self-hosting 的确切动因（数据不能出边界、要触达非公网可路由的内部服务）也正是题干那两条。
D1 凭空捏造 违反 P5 A ：「模型由 environment worker 提供服务」是编的。worker 的官方职责是领取 work item、在本地执行 Claude 请求的 tool call 并回传结果；Claude 在 Anthropic 一侧运行。这是本题最危险的选项，因为它会让读者对合规边界形成错误认知。
D6 半对半错 违反 P1 B ：egress allowlist 与保留条款都是真实存在的手段，但它们作用的变量不是题干指认的那两条。题干的硬约束是「日志文件不得离开银行网络」与「内部服务无公网路由」——官方给这两条的对应解法明确是 self-hosting。
D1 凭空捏造 违反 P5 D ：把部署形态挂错了层。官方的四个核心概念里，Environment 才是「session 在哪儿跑」的配置——Anthropic 托管的 cloud sandbox，或你自己基础设施上的 self-hosted sandbox；Agent 是模型、system prompt、tools、MCP servers 与 skills。不存在「self-hosted agent」这个东西。
QUESTION 08 · TS 1.1 · THE COST OF AUTONOMY
A team is about to ship its first autonomous agent: it will run unattended against the production billing database with write credentials, driven by free-text requests from support staff. Their plan is to launch to 5% of tickets and watch the error rate for a week. They have run the agent 30 times on their laptops against production, and it was correct every time. What is the strongest objection?
A Autonomy suits trusted environments and brings compounding errors. Test in a sandbox with guardrails first — not against production with write credentials. B Free-text requests from support staff make the agent's behavior unpredictable turn to turn; require staff to pick from a fixed set of request templates so the input space is bounded before any rollout. C A 5% rollout is the wrong granularity for a billing system; gate the rollout by ticket type instead, starting with read-only balance inquiries and adding write operations once each type has clean numbers. D Thirty runs is too small a sample to establish a per-request error rate at the precision a 5% rollout needs; expand the manual trial to several hundred runs first, then ship the same plan with the tighter estimate.
正确 A 官方对 agent 自主性的三句话正好覆盖题干的三个问题：自主性让 agent 适合在受信环境 里扩展任务；自主也意味着更高的成本与错误累积 的可能；建议在沙箱环境里充分测试 并配上适当的 guardrails。「带写权限直接对生产跑了 30 次」违反的正是这条——而且错误累积意味着单次成功率不能线性外推。
D2 无关杠杆 违反 P1 B ：把输入限制成模板确实缩小了输入空间，但题干指认的变量是「无人值守 + 生产写权限 + 未经沙箱验证」。模板化不改变其中任何一条——一个模板化的请求同样可以在循环第七步写坏数据。
D6 半对半错 违反 P10 C ：从只读开始是一条很好的工程直觉，方向也对。但它仍然把首次验证放在生产上，跳过了官方点名的沙箱那一档；「先在受控环境里验证，再谈灰度比例与切分方式」才是顺序，这一项把两步合成了一步。
D6 半对半错 违反 P1 D ：样本量的批评本身成立，但它默认「再多跑几百次」可以在同一个环境 里进行——那正是被反对的做法。它还漏掉了错误累积这一层：agent 的失败不是独立同分布的单次事件，多跑几百次生产请求只是把风险敞口放大了几百倍。