考试从 6 个情景中随机抽取 4 个。每个情景跨域考察多个领域的能力。
下面逐项拆解每个情景的关键架构决策——每个决策都标注了正确做法（✅）与常见错误（✗），
以及背后的设计原理。
设计一个 AI 驱动的客服智能体，处理客户咨询、解决常见问题、在必要时升级复杂案例到人工客服。
核心挑战：如何安全地控制智能体循环？如何确保业务规则不被绕过？如何在长时间对话中保持关键上下文？
决策 1
如何终止智能体循环？
✅ 正确做法
检查 stop_reason 字段：
· tool_use = 继续循环，执行工具
· end_turn = 任务完成，退出
这是 API 提供的结构化信号，专门用于控制流判断。
✗ 常见错误
解析模型输出查找 "done" / "complete" 等关键词——文本措辞不可控。或使用固定迭代次数上限——可能半路终止任务。
原因：语言的本质是模糊的，控制流需要结构化信号。stop_reason 是唯一的可靠选项。对应反模式 AP-01、AP-02。
决策 2
如何强制执行 $500 退款限额？
✅ 正确做法
使用 PostToolUse Hook 在退款工具被调用后拦截金额，超过 $500 就阻断执行并触发升级流程。Hook 提供确定性、可测试的规则执行。
✗ 常见错误
在系统提示词中写"绝不处理超过 $500 的退款"。Prompt 是概率性的、建议性的——模型可能在边界案例中忽略这条指令。
原因：Prompt 无法提供确定性执行保障。Hook 是程序化的、可测试的、确定性的。对应反模式 AP-03。
决策 3
什么情况下应该升级到人工？
✅ 正确做法
基于客观标准触发升级：
· 客户明确请求人工客服
· 策略缺口（如超过退款限额）
· 能力边界（智能体无法处理的业务类型）
· 业务阈值（如单笔金额上限）
✗ 常见错误
检测到负面情绪就升级——情绪激动但需求简单的客户完全可以在自动化流程中解决。或依赖模型自报的置信度分数——这些分数缺乏可靠校准。
原因：情绪是噪声信号，置信度分数不可靠。升级应基于可验证的客观条件。对应反模式 AP-04、AP-05。
决策 4
如何在 30+ 轮对话后保留关键客户信息？
✅ 正确做法
在上下文开头放置不可变的 case facts 块：
· 姓名、账号 ID、订单号、退款金额
· 此块不参与渐进式摘要
· 始终在最优先位置，模型不会遗漏
✗ 常见错误
依赖渐进式摘要自然保留所有重要信息。每轮摘要都会丢失具体细节——姓名、金额、日期是最先被吞噬的。
原因：渐进式摘要本质上是信息丢失的过程。不可变的 case facts 块是唯一能确保关键信息完整保留的机制。对应反模式 AP-16。
🎯 考试要点：Hook 式强制执行（非 Prompt 式）和 case facts 块（非渐进式摘要）是这个情景的核心考点。每一道关于升级逻辑的题都会试图用情绪判断来诱惑你。记住：客户大喊大叫 ≠ 需要人工介入。
为一个 8 人开发团队配置 Claude Code 环境。需要设置统一的编码规范、Plan Mode 使用策略、复杂重构的隔离方案，以及迭代改进流程。
决策 1
团队编码规范应该放在哪里？
✅ 正确做法
.claude/CLAUDE.md（项目级）：
· 版本控制，全团队共享
· 随项目代码一起检出
· 个人偏好放 ~/.claude/CLAUDE.md（用户级）
✗ 常见错误
把个人偏好（缩进风格、注释习惯）放进项目级 CLAUDE.md——这会把你的偏好强加给每个团队成员。或把团队规范放在 ~/.claude/CLAUDE.md——其他成员看不到。
原因：三级体系（用户 → 项目 → 目录）的设计就是为了分离个人与团队关注点。对应反模式 AP-10。
决策 2
什么时候用 Plan Mode？
✅ 正确做法
区分任务类型：
· 多文件架构变更 → 用 Plan Mode
· 简单的明确定义修复 → 直接执行
Plan Mode 有开销，但不用于复杂变更会导致返工。
✗ 常见错误
永远用 Plan Mode（对简单任务是浪费）或永远不用（对复杂变更是危险的）。两种极端都是错误的。
原因：Plan Mode 的设计目的是在复杂度需要时提供结构化的规划和验证，而非用一个尺寸适配所有任务。
决策 3
复杂重构需要上下文隔离，用什么机制？
✅ 正确做法
使用 Skill，配置：
· context: fork — 上下文分叉隔离
· allowed-tools — 限制可用工具
探索和重构在隔离环境中完成，完成后只将结果传回主会话。
✗ 常见错误
用 Command 在主会话中执行——探索噪音和中间输出会污染主上下文。或直接在主会话中操作——上下文会迅速膨胀。
原因：Skills 提供 context: fork 和 allowed-tools，是为需要隔离和权限控制的复杂任务专门设计的。Commands 是为简单的、不需要隔离的操作设计的。对应反模式 AP-11。
决策 4
最佳迭代改进策略是什么？
✅ 正确做法
TDD 迭代循环：
先写失败的测试 → Claude 实现代码 → 验证测试通过 → 重构优化 → 保持测试绿色
每次迭代都有客观的通过/失败标准。
✗ 常见错误
模糊指令："让它更好"、"改进代码质量"——没有客观标准，每次运行结果不同，无法判断是否真的改进了。
原因：测试提供了客观的通过/失败信号。没有测试的迭代就像蒙着眼睛走路——你不知道自己是否在前进。对应反模式 AP-13。
🎯 考试要点：三级配置的区分（用户 vs 项目 vs 目录）、何时用 Skill vs Command、TDD 迭代模式。考试喜欢测试你是否把个人偏好放在项目配置中。
构建协调者–子智能体系统，支持并行研究任务。协调者接收研究问题，将子任务分发到专业子智能体（学术论文、新闻档案、专利库），最后合成综合报告。
决策 1
整体架构如何设计？
✅ 正确做法
Hub-and-spoke（协调者–辐条）：
· 协调者负责任务分解和结果合成
· 各子智能体在隔离上下文中独立运行
· 各子智能体只获取任务相关的上下文
✗ 常见错误
扁平架构——所有子智能体共享全局上下文和完整对话历史。这会：消耗大量 token、引入噪声、且子智能体之间互相干扰。
原因：隔离上下文防止干扰并节省 token。子智能体只需要知道自己的任务，不需要知道其他子智能体在做什么。
决策 2
如何向子智能体传递上下文？
✅ 正确做法
只传递与该子智能体特定任务相关的上下文：
· 查询学术论文的子智能体 → 只给研究问题 + 学术源配置
· 查询新闻的子智能体 → 只给研究问题 + 新闻源配置
✗ 常见错误
将协调者的完整对话历史分享给所有子智能体——额外上下文稀释注意力、浪费 token、降低准确率。
原因：最小化上下文传递 = 更高准确率 + 更低成本。每个子智能体是专注的执行者，不是全知全能者。
决策 3
不同子智能体返回矛盾信息怎么办？
✅ 正确做法
追踪信息溯源（provenance）：
· 每条信息标注来源、置信度、时间戳
· 区分"数据库精确值"和"模型推断值"
· 基于可靠性加权判断，而非简单计数
✗ 常见错误
多数投票法取最常见结果——忽略了不同来源的可靠性差异。或让模型自行判断——缺少可审计性。
原因：专利数据库的 1 条精确声明可能比 10 条新闻报道更可靠。信息溯源是可靠决策的基础。
决策 4
子智能体查询失败了怎么办？
✅ 正确做法
结构化错误传播：
· 明确区分 "访问失败" 和 "结果为空"
· 携带：尝试了什么、错误类型、是否可重试
· 先尝试本地恢复，失败后再升级到协调者
✗ 常见错误
静默返回空结果——这是最危险的错误。协调者会认为"确实没有相关数据"而非"无法查询"。或返回通用"操作失败"——协调者无法判断该重试还是放弃。
原因：不同错误需要不同恢复策略。访问失败（可能是临时的）和结果为空（信息不存在）是完全不同的信号。对应反模式 AP-06、AP-07。
🎯 考试要点：核心陷阱——(1) 把全量历史传给子智能体（永远错），(2) 静默吞掉子智能体失败（永远错），(3) 解决矛盾时不看信息溯源。记住：Hub-and-spoke + 最小上下文 + 结构化错误 + 信息溯源 = 唯一正确答案。
使用 Claude Agent SDK 和 MCP 服务器构建代码库探索与开发辅助工具。核心挑战：工具太多时如何保持选择准确率？如何正确选择内置工具？如何安全配置 MCP？
决策 1
智能体有 18 个工具，频繁选错，怎么办？
✅ 正确做法
减少到每个智能体 4–5 个工具，其余分配给专用子智能体：
· 代码分析子智能体：lint + 安全扫描 + 依赖检查
· 测试子智能体：运行测试 + 覆盖率 + 性能基准
· 每个子智能体只面对 3–5 个相关工具
✗ 常见错误
给工具写更长的描述——可能加剧混淆。或切换到更大的模型——成本翻倍但不一定解决问题。或用编号代替名称——仍在 18 个选项中选。
原因：工具超过 5 个后选择准确率迅速下降。关键不是更好的描述，而是减少选择面。对应反模式 AP-08。
决策 2
读取配置文件应该用哪个工具？
✅ 正确做法
使用 Read 工具——专门设计用于文件读取。提供行号、编码支持、大文件分页。
✗ 常见错误
Bash('cat config.json') ——绝不能用 Bash 代替专用工具。Bash 存在命令注入风险，且没有文件读取的专属特性。
原因：当内置工具能完成任务时，绝不降级到 Bash。Bash 是通用 escape hatch，不是首选方案。
决策 3
如何配置项目级 MCP 服务器（需要 API 密钥）？
✅ 正确做法
.mcp.json（项目级）+ ${ENV_VAR}：
· 服务器定义放在 .mcp.json（版本控制）
· 密钥通过环境变量引用，不写进文件
· 每个开发者在自己的 .env 中设置密钥
✗ 常见错误
在 .mcp.json 中硬编码 API 密钥——一旦 git push，密钥就泄露了。或放在 ~/.claude.json——仅个人生效，团队无法共享服务器配置。
原因：.mcp.json 是团队共享的、版本控制的；~/.claude.json 是个人的、私有的；${ENV_VAR} 是安全的密钥传递方式。对应反模式 AP-09。
决策 4
修改已有文件的某个部分，用 Write 还是 Edit？
✅ 正确做法
Edit 用于定向修改——它做精确的字符串替换，保留未修改部分。对已有文件的局部修改是正确的选择。
✗ 常见错误
用 Write 替换整个文件——它要求提供完整的新文件内容。如果遗漏了原有的某些部分，它们就永久丢失了。Write 适用于创建新文件，不是修改已有文件。
原因：Edit 是手术刀，Write 是重写。用重写工具做手术级别的修改，风险极高。
🎯 考试要点："18 个工具"这道题几乎必考——标准答案永远是"分配给子智能体"。第二个高频考点：绝不用 Bash 做文件操作。第三个：.mcp.json + ${ENV_VAR}，绝不硬编码密钥。
将 Claude Code 集成到 CI/CD 流水线中。实现自动代码审查、非交互执行、批处理优化和结构化输出。核心挑战：如何在自动化环境中安全高效地运行 Claude Code？
决策 1
在 CI 流水线中如何运行 Claude Code？
✅ 正确做法
使用 -p flag（非交互模式）：
· claude -p "review this PR"
· 配合 --output-format json 获得结构化结果
· CI 环境没有终端，不能交互
✗ 常见错误
在 CI 中运行交互模式——会挂起等待用户输入。或通过 stdin 管道传命令——笨拙且不可靠。
原因：-p flag 专为非交互环境设计。它接受一个 prompt，执行任务，返回结果，然后退出——完全适配 CI/CD 场景。
决策 2
如何审查 Claude 生成的代码？
✅ 正确做法
使用单独会话审查：
· 生成者和审查者在隔离上下文中运行
· 审查者从零开始理解代码
· 没有生成推理上下文 → 无确认偏差
✗ 常见错误
同会话自我审查——审查者带着生成者的推理过程，产生强烈的确认偏差。"它为什么这么写我都知道"正好让审查失去意义。这是 Critical 级反模式。
原因：确认偏差是审查中最危险的陷阱。隔离上下文是消除它的唯一方式。对应反模式 AP-12。
决策 3
夜间代码审计——用什么 API？
✅ 正确做法
Message Batches API：
· 50% 成本节省
· 24 小时处理窗口
· 适合非紧急、不需要实时响应的任务
· 第二天早上看结果即可
✗ 常见错误
用同步 API 逐个请求——2 倍成本、实时等待、CB 计算资源——但用户第二天才需要结果。完全没有收益的浪费。
原因：选择 API 应基于任务的紧迫性。同步 = 即时需要结果，批处理 = 延迟可接受。把非紧急任务放进批处理是成本优化的重要原则。
决策 4
如何确保 CI 输出可被自动处理？
✅ 正确做法
使用 --json-schema flag 强制输出格式：
· 定义审查结果的结构（文件、问题类型、严重度、建议）
· CI 工具链直接解析 JSON
· 不依赖文本解析
✗ 常见错误
用正则表达式解析非结构化文本输出中的信息——格式稍有变化就全部崩溃。
原因：JSON schema 保证了输出的结构和语义。正则解析文本是不可靠的、脆弱的、维护成本高的。自动化流水线必须依赖结构化输出。
🎯 考试要点：三个必须记住的事实：(1) -p = 非交互模式，(2) 绝不自我审查（隔离会话），(3) Batch API = 50% 成本节省。任何关于 CI/CD 审查的题，只要看到"同一个会话审查"就是错的。
从非结构化文档构建数据提取流水线。需要保证输出结构可靠、内容准确，并处理模糊的边界情况。核心挑战：如何平衡结构保证和语义正确性？如何优雅处理分类外的情况？
决策 1
如何保证输出是合法的 JSON？
✅ 正确做法
tool_use + JSON schema + tool_choice：
· 定义提取工具的 schema（字段名、类型、必填项）
· tool_choice 强制模型必须调用提取工具
· 唯一能保证输出结构合规的机制
✗ 常见错误
提示词中写"输出为 JSON"——模型可能输出带 markdown 包裹的 JSON、多行文本、或格式错误。或后期用正则提取——脆弱且不可靠。
原因："输出 JSON"只是建议，tool_use + schema 是保证。
决策 2
tool_use 能保证提取的内容也正确吗？
✅ 正确做法
不能。tool_use 只保证结构合法。
语义正确性需要额外的业务校验层：
· 检查枚举值是否在允许范围内
· 检查数值合理性（日期不可能是未来年份）
· 检查逻辑一致性（合同金额 = 各项之和）
✗ 常见错误
假设 tool_use 输出就是正确的——因为 JSON schema 匹配了就以为一切 OK。这是最常见的理解错误。schema 管的是格式，不管事实。
原因：tool_use 保证结构 ≠ 保证语义。这是考试考得最多的区分。对应反模式 AP-14。
决策 3
校验失败后如何重试？
✅ 正确做法
在重试消息中附上具体错误细节：
· 哪个字段出错
· 实际值 vs 期望值
· 错误原因（类型不符 / 超出范围 / 未知枚举值）
然后将这些细节追加到 prompt 中重新提取
✗ 常见错误
通用重试消息："有错误，请重试"——模型缺乏足够的信号来修正问题。结果往往是第二次仍然失败。对应反模式 AP-15。
原因：模型需要具体的错误信号来引导修正。模糊的反馈 = 模糊的修正。
决策 4
文档类型不总是能归入预设分类，怎么办？
✅ 正确做法
在 enum 中添加 'other' 选项：
· 加 document_type_detail 自由文本字段
· 用 2–4 个 few-shot 示例展示边界情况处理
· 'other' 是逃逸口，防止强制错误分类
✗ 常见错误
刚性枚举没有 'other' 选项——模型被迫将未知类型归入已有分类。这是强制错误，且你会丢失"这类型不对"的信号。
原因：现实世界不总是完美适配预定义分类。'other' 是结构化的兜底方案——保留了结构化输出的优势，同时避免强制错误。
🎯 考试要点：tool_use 保证结构但不保证语义——这是本情景最重要的一句话。其次：重试消息必须包含具体错误（字段 + 原因 + 期望值），不能用模糊消息。第三：enum 必须有 'other'。掌握了这三点，结构化提取的题就基本不会错。
跨情景主题总结
以下 6 个主题在多个情景中反复出现。掌握它们，就是掌握了考试的核心思想。
1. Hook 优于 Prompt
关键业务规则必须用程序化 Hook（确定性）执行，而非依赖系统提示词（概率性）。情景 1 的退款限额是最典型体现。
2. 上下文隔离
子智能体只获取任务相关的上下文。绝不共享完整对话历史。Hub-and-spoke 是标准模式。情景 3 完美体现。
3. 结构化优于非结构化
优先使用 schema、tool_use、JSON 输出，而非依赖文本解析。解析自然语言做控制流或数据判断都是错的。贯穿情景 1、4、6。
4. 具体反馈才有用
校验重试必须包含精确的错误细节（哪个字段 + 为什么错 + 期望值）。"有错请重试"的通用消息是反模式。情景 6 的核心考点。
5. 生成与审查分离
代码生成和代码审查必须在不同的会话中完成。同会话自审产生确认偏差。情景 2、5 都会考察。
6. 项目级 > 个人级
团队规范放在版本控制的项目配置中，个人偏好放在用户配置中。CLAUDE.md 和 .mcp.json 都遵循这个原则。情景 2、4 的核心考点。
情景 × 域速查矩阵
| 情景 |
D1 · Agentic |
D2 · 工具/MCP |
D3 · CC 配置 |
D4 · Prompt |
D5 · 上下文 |
| 01 · 客服智能体 |
✓ 循环 + Hook |
✓ 结构化错误 |
|
|
✓ case facts |
| 02 · CC 团队配置 |
|
|
✓ CLAUDE.md · Commands vs Skills |
✓ TDD 迭代 |
|
| 03 · 多智能体研究 |
✓ Hub-and-spoke |
|
|
|
✓ 信息溯源 · 错误传播 |
| 04 · 开发者工具 |
|
✓ 工具分发 · 内置工具 · MCP |
|
|
|
| 05 · CI/CD |
|
|
✓ -p flag · Batch API · 会话隔离 |
✓ --json-schema |
|
| 06 · 结构化提取 |
|
|
|
✓ tool_use · Schema · 校验重试 |
✓ 分类准确性 |