Claude Certified Architect
25 道情景式模拟题

stop_reason 是 API 提供的结构化信号，专门用于控制流判断。end_turn 表示模型认为任务完成，tool_use 表示模型需要调用工具获取更多信息。这是唯一可靠的循环终止机制。

A：固定迭代上限可能在任务未完成时强制退出，或在任务完成后浪费调用。

B：文本措辞不可控——模型每次的表达方式不同，依赖文本解析极易误判。

D：回复长度与任务完成度毫无关系。

Hub-and-spoke 是最适合并行独立研究的架构。协调者接收用户问题，将相关子任务分发给隔离上下文的专业子智能体，各自返回结果后协调者进行信息溯源和合成。关键词：上下文隔离 + 并行执行 + 协调者统一合成。

A：共享上下文会导致干扰和噪声，且全量历史消耗大量 token。子智能体间信息泄露会影响独立性。

C：链式依赖在此场景无必要——三个数据源互不依赖，串行只会浪费时间和成本。

D：多数投票对事实性问题不可靠，且让所有子智能体查所有源失去了专业化分工的意义。

Hook 提供确定性、可测试的规则执行。PostToolUse Hook 在工具调用完成后立即检查参数（如退款金额），如果超过阈值，可以阻止执行并触发升级流程。Prompt 是概率性的——模型可能在边界案例中忽略指令。

A：系统提示词是指导性的，不是强制性的。模型可能在某些情况下忽略或绕过。这是最常考的反模式（AP-03）。

C：让模型自审同类错误——不可靠且延迟判断。

D：将业务规则推给数据库层，缺少业务上下文和升级路径。

对于大文档分析，应该先建立结构视图（章节、主题），再将工作分解为可管理的块。每个阶段有明确的输入、输出和质量检查点。这避免了上下文超载，并允许每个阶段做专门的优化（如分类阶段可以使用 few-shot）。

A：500 页内容远超合理上下文窗口，且长上下文中模型注意力会下降（"lost in the middle"）。

C：无结构地顺序处理会丢失全局视图，无法做跨章节关联分析。

D：通用智能体可能选择不合理的分解策略，应该由架构师设计显式的分解逻辑。

升级应基于客观标准：客户明确请求人工、策略缺口（如退款限额）、能力边界（如无法处理的业务类型），而非主观的情绪判断。但智能体应该对情绪做出恰当回应（同理心），同时在能力范围内解决问题。

A：纯情绪升级会导致过度升级——大量可自动解决的问题被推给人工。

B：完全忽略情绪也不专业，但核心问题是升级逻辑不应依赖情绪。

D：模型置信度分数不可靠校准，不能作为升级判据（AP-05）。

fork_session 允许从当前状态创建独立的探索分支，避免探索噪音污染主会话。探索完成后，只将最重要的结论和行动项以摘要形式传回主会话，保持主上下文的清洁。

A：/compact 是渐进式摘要，可能在压缩中丢失关键信息（AP-16）。且探索噪声仍会进入主会话。

B："忽略之前内容"的指令不可靠——模型无法真正"忘记"上下文中的内容。

D：从零开始丢失了前面 40 轮对话积累的宝贵上下文。

工具数量超过 5 个后，模型的选择准确率会迅速下降。相似的描述会造成歧义。最佳实践是保持每个智能体 4–5 个工具，将剩余工具分配给专门的子智能体。这是考试中的高频考点（AP-08）。

A：更长的描述可能加剧选择困难——模型需要在更多文本中区分相似工具。

B：换更大模型只是掩盖问题，且增加成本和延迟。

D：编号不解决根本问题——模型仍需在 18 个选项中做选择。

Read 是专门为读取文件设计的内置工具。当内置工具能完成任务时，绝对不要用 Bash 代替——Bash 存在命令注入风险，且缺乏文件读取的专属优化（如行号、编码处理）。

A：绝对不要用 Bash 做文件读取。这是一个必考反模式。

C：Grep 用于搜索模式，不应用于完整文件读取。

D：已知文件路径时不需要 Glob 先定位。

服务器配置（地址、端口、工具列表）应放在项目级的 .mcp.json 中以便团队共享和版本控制。但密钥绝不能硬编码在配置文件中——应使用 ${ENV_VAR} 语法引用环境变量。每个开发者在自己的环境中设置密钥值。

A：硬编码密钥在配置文件中——一旦提交到 git 就会泄露。这是 Critical 级反模式（AP-09）。

B：~/.claude.json 是用户级配置，仅对个人生效，不能共享团队 MCP 服务器设置。

D：CLAUDE.md 是行为指导文件，不是密钥存储位置。

结构化错误让智能体做出正确决策。isRetryable 告诉它可以重试（transient error）而不是换方案或升级。errorCategory 帮助分类（transient vs permanent vs permission）。context 提供人类可读的细节。

A：通用错误消息——智能体无法判断该重试还是放弃。这是 Critical 级反模式（AP-06）。

C：静默返回空结果是 Critical 级反模式（AP-07）——智能体会认为"确实没库存"而非"无法查询"。

D：仅有 HTTP 状态码，缺少上下文和可操作性指引。

工具描述应包含：工具的用途（何时用/何时不用）、输入格式、输出格式、边界情况和典型用例。如果两个工具确实重叠严重，合并为一个并通过参数区分也是合理选择。C 虽然能减少工具数量，但与题目场景不完全匹配——题目问的是工具选择困难，而非工具过多。

CLAUDE.md 有三级体系：用户级（~/.claude/CLAUDE.md）、项目级（.claude/CLAUDE.md）、目录级。团队规范必须放在项目级以版本控制并共享给所有人。个人偏好放用户级，仅影响自己的行为，不影响团队成员。

A：个人偏好不应强加给团队——这是反模式（AP-10）。

C：用户级配置对团队不可见，无法共享团队规范。

D：代码注释不是配置机制，且无法被 Claude Code 系统级读取。

Skills 提供 context forking（上下文分叉）和 allowed-tools 限制，非常适合需要隔离的复杂任务。Commands 在当前会话中运行，会把探索噪音和中间输出带入主上下文。对于数据库迁移审查这种需要大量探索且需要权限控制的任务，skill 是正确选择（AP-11）。

A：Command 在当前会话运行，探索噪音会污染主上下文。

C：两者有本质区别——context: fork 和 allowed-tools 是 skill 独有的。

D：CLAUDE.md 中的静态规则无法替代主动执行审查逻辑。

Plan Mode 的设计原则：多文件架构变更用，简单明确定义的修复不用。Plan Mode 有开销——它需要额外的思考和规划步骤。对于改颜色间距这种 2 行 CSS，Plan Mode 是浪费。对于涉及 12 个文件的重构，Plan Mode 的价值在于：先设计好整体方案再执行，避免返工。

A：永远用 Plan Mode 对简单任务是多余的。

B：永远不用 Plan Mode 对复杂变更是危险的。

D：恰好相反——简单任务不需要计划，复杂任务需要。

CI/CD 环境中没有交互终端。-p flag 专为非交互模式设计，接受一个 prompt 并返回结果。--output-format json 确保输出可被流水线工具解析。这两个 flag 组合是 CI/CD 场景的标准用法。

A：CI 环境不支持交互模式，会挂起或失败。

C：--resume 需要已有会话，CI 每次运行应该是独立的新会话。

D：stdin 方式不适用于非交互 CI 场景。

对于非紧急的批量处理任务，Message Batches API 是正确选择。它提供 50% 的成本节省，处理窗口 24 小时。夜间审计完美符合这个场景——不需要实时响应，结果在第二天早上可用即可。

A：同步请求非紧急任务意味着 2 倍成本且无额外价值。

C：每个提交单独触发是同步模式——成本翻倍，且可能影响 CI 速度。

D：200 个文件合并在一起可能超出上下文窗口，且难以区分每个文件的审计结果。

tool_use 配合 JSON schema 是唯一能保证输出结构合规的机制。tool_choice 可以强制模型必须调用指定的提取工具。它保证字段名、类型和必需字段都符合 schema 定义。

A：裸 JSON 提示只是建议——模型可能输出带 markdown 包裹的 JSON、多余文本或格式错误。

C：正则解析非结构化输出极其脆弱——格式稍有变化就失效。

D：两阶段处理增加了延迟、成本和错误累积。

这是考试中最关键的区分之一：tool_use 保证结构合法，不保证语义正确（AP-14）。"永久" 这个值在结构上是合法的（它是 string），但语义上不在业务允许的枚举值内。你需要额外的业务校验层，并在重试时附上精确的错误信息（哪个字段 + 为什么错 + 期望值），而不是说"有错，重试"（AP-15）。

A：tool_use 不做语义校验——这是最常见的理解错误。

C/D：temperature 和模型大小解决不了业务规则校验问题。

"找出所有问题"是典型的模糊指令（AP-13）。它会导致模型过度标记、产生大量误报，最终开发者停止信任审查工具。好的 prompt 应该提供明确的评判标准，例如："检查是否存在：未处理的异常、SQL 注入风险、N+1 查询、缺少输入校验。"

A：这恰恰是一个有问题的 prompt——太模糊，没有给模型提供有效的评判框架。

C：语言不影响 prompt 的质量——清晰度才是关键。

D：few-shot 在某些场景有用，但此处核心问题是缺少明确的评判标准而非缺少示例。

刚性枚举没有 escape hatch 时，模型会强制将未知类型错误归类。标准做法：(1) 加 'other' 选项作为兜底；(2) 加 document_type_detail 自由文本字段让模型解释为什么选了 'other'；(3) 用 2–4 个 few-shot 示例展示边界情况的处理。这既保持了结构化输出的优势，又不会强制错误分类。

A：扩充枚举只是推迟问题——现实世界的文档类型无穷无尽，总有无法覆盖的。

C：完全放弃 enum 失去了结构化输出的优势。

D：留空处理方式不明确，且丢失了数量信息。

对于模糊的、需要判断的边界情况，few-shot prompting 比长篇描述更有效。示例可以展示：什么样的引用组合构成隐含的违约责任、如何从分散条款中推断出完整义务。考试中注意：few-shot 最适合模糊判断场景。

A：对模糊概念的长篇描述不如具体示例有效。

C：隐式条款恰恰是模型容易遗漏的，需要专门指导。

D：这是 pipeline 策略，不是 few-shot 策略。两者可以结合，但题目问的是识别策略。

这是考试高频考点。case facts 块是放在上下文开头的固定信息块，不参与摘要/压缩流程。它确保关键事实（姓名、ID、金额、日期）在任何情况下都不会被渐进式摘要"吞噬"。

A：渐进式摘要每轮都会丢失具体信息——姓名、金额、日期是最容易被丢掉的（AP-16）。

C：重新总结仍然有丢失风险，不如不可变块可靠。

D：无限保留不现实——30 轮后上下文窗口会溢出。

访问失败和空结果是截然不同的信号，必须区分。如果权限问题或 API 宕机时返回空结果，协调者会得出错误结论。结构化错误报告让协调者能做合理决策：重试、切换源、或在报告中注明数据源不可用。

A：静默返回空结果是 Critical 级反模式（AP-07）——掩盖了真实问题。

B：更糟——不仅掩盖了问题，还产生不完整结果。

D：无限制重试可能永无止境。应先上报给协调者，由协调者决定策略。

在处理来自不同来源的矛盾信息时，正确的做法是维护每项信息的溯源记录（provenance）：哪个子智能体从哪个源获取、源的可靠性如何、时间戳、提取方式（精确提取 vs 模型推断）。基于这些元数据做加权判断，而非简单多数投票。还要在最终输出中区分 "well-established" 和 "contested" 的结论。

A：多数投票对事实性判断无效——1 个专利数据库的可靠声明比 10 条新闻报道更可信。

C：让模型自行判断缺少可审计性——溯源才能被验证。

D：平均数值型信息有时可以，但对声明式信息毫无意义。

同一会话中审查自己刚生成的代码是 Critical 级反模式（AP-12）。原因：审查者带着生成者的完整推理上下文，会产生强烈的确认偏差——"它为什么这么写我都知道，看起来没问题"。单独的审查会话不给审查者任何生成历史，迫使它从零开始理解代码，更容易发现不一致、遗漏和逻辑错误。

A："最了解上下文"正是问题所在——了解得太多了。

C：多轮审查本身是对的，但如果都在同会话中完成，确认偏差依然存在。

D：没有任何代码生成系统可以免于审查。

PreToolUse Hook 在工具被执行之前运行。它可以检查前置条件（如用户已验证），条件不满足时直接阻止工具调用并返回错误。PostToolUse 用于调用后的数据校验和日志记录，PreToolUse 用于调用前的权限和前置条件检查。

A：PostToolUse 发生在工具执行之后——扣款已完成，回滚远比阻止复杂且不可靠。

C：Prompt 是概率性的，不能用于关键的安全检查。

D：工具自己检查是最后一道防线，但无法防止模型错误地选择调用该工具。

生产级多智能体系统需要容错能力。维护一个 checkpoint manifest，记录每个子任务的 ID、状态（pending/running/done/failed）和结果摘要。协调者恢复时读取 manifest，跳过已完成的任务，只重跑未完成或失败的任务。这既省成本又省时间。

A：从头跑一遍浪费已完成子智能体的计算和 API 成本。

C：协调者的合成步骤也必须重跑——子智能体结果需要被整合。

D：让模型自行判断不可靠——应该用确定性的状态追踪。

当数据规模和分布未知时，动态自适应分解优于静态流水线。先做探索：有多少封邮件？涉及多少产品线？时间分布如何？然后根据发现设计合适的分解粒度——如果只有 50 封和 3 个产品线，策略与 5000 封和 20 个产品线完全不同。

A：静态流水线在数据规模未知时可能选错粒度——太粗或太细。

C："过去一年的邮件"可能远超上下文窗口。

D：随机抽样对客户反馈不适用——低频但严重的问题可能恰好被抽中。

当模型在同一次响应中发出多个互不依赖的 tool_use 调用时，应该并行执行它们，然后把所有结果合并到一个 user 消息中发回。这减少了往返次数、降低延迟，且不会影响结果质量。关键判断：这些工具调用之间有没有数据依赖？没有 → 并行。

A：顺序执行互不依赖的工具浪费了不必要的往返延迟。

C/D：模型选择多个工具意味着它需要所有工具的信息来做决策，不能随意丢弃。

当工作流中包含有副作用的操作（扣款、扣库存）且后续步骤可能失败时，必须设计补偿事务。每步成功后记录状态快照，后续失败时按逆序执行补偿：如果支付后运单生成失败 → 退款 + 释放库存。这和数据库事务的 rollback 逻辑一致。

A：简单链式调用不考虑失败补偿——支付成功后运单失败，钱却扣了。

C：路由解决的是分派问题，不是失败补偿问题。

D：支付和运单有严格的顺序依赖——不能并行。

Hub-and-spoke 架构的精髓在于每个子智能体是专业化的。协调者的职责包括将通用任务翻译成每个子智能体领域的特定指令——不同的搜索语法、输出 schema、注意事项。统一 prompt 等于放弃了专业化的优势。

A：同质化浪费了专业化架构的优势。

C："自行探索"是不确定的——应该提供明确的领域指令。

D：包含所有指令会让子智能体困惑——它不知道自己是哪个角色。

stdio 传输通过子进程启动 MCP 服务器，通过标准输入/输出通信。对于本机工具，这是最简单、最快、最安全的方式——无需暴露网络端口，无需身份验证。Streamable HTTP 适合远程服务或需要多客户端共享的服务器。

B：本机容器用 HTTP 增加了不必要的网络层和安全考虑。

C：有实际区别——性能、安全模型、部署复杂度都不同。

D：stdio 仍然是 MCP 规范中的主要传输方式之一。

大结果集的处理需要平衡信息量和上下文消耗。好的做法：返回少量代表样本、提供总数和分布统计、允许智能体通过过滤参数（关键词、日期范围、分类）缩小结果范围。如果智能体需要更多数据，它可以调整参数再次查询。

A：500 条记录会消耗大量上下文，可能超出窗口或稀释关键信息。

C：随机样本可能遗漏智能体真正需要的记录。

D：信息不足——智能体无法判断"是否需要更多数据"。

当 8 处修改互不重叠（修改不同的 old_string）时，可以在一次响应中并行调用 8 个 edit_file。这比逐个修改快得多。但前提是 old_string 之间没有重叠——如果修改 A 改变了修改 B 需要匹配的文本，则必须先 A 后 B。

B：8 个往返增加延迟和成本——对于互不重叠的修改没必要。

C：Write 替换整个文件——可能丢失未包含的原有内容。

D：合并为一个大替换难以精确匹配且容易出错。

安全必须在工具实现层面强制执行，而非依赖 prompt 或模型自觉。参数化查询防止注入，查询白名单限制允许的表和操作，结果行数限制防止数据泄漏，审计日志记录所有查询以便事后审查。

A：工具描述对安全毫无约束力——模型可能被 prompt injection 操控。

C：人工确认破坏自动化流程的价值，且人类也无法实时判断每条 SQL 是否安全。

D：与 A 相同——描述不是强制机制。攻击者可通过 prompt injection 绕过。

Grep 是专门为代码搜索设计的内置工具，能快速定位模式匹配的位置。搜索到匹配文件后再用 Read 检查上下文来判断是否确实是 deprecated 调用（排除注释、文档中的引用）。这是内置工具链的标准组合用法。

A：Bash grep 可以工作但不是最佳实践——内置工具优先。

C：逐个 Read 500 个文件是不可行的——效率极低。

D：先找到再改——不能跳过查找步骤。且不是所有引用都需要立即替换。

CLAUDE.md 支持 @import 语法引入其他文件。将不同主题的规则拆分为 .claude/rules/ 目录下的独立文件，使每个文件聚焦单一主题、易于维护。Claude Code 会递归加载所有导入的规则。

A：更长更难以维护。

C：删除规则会丢失重要的上下文指导。

D：代码注释不是配置机制，无法被系统级读取和遵循。

项目级的 .claude/skills/ 目录会被团队所有成员自动加载。放在这里：(1) 所有人同步获取最新版本；(2) git 管理变更历史；(3) 无额外分发成本。个人 skills 放 ~/.claude/skills/，团队 skills 放项目仓库。

A：手动分发无法自动同步——你改进后别人拿不到更新。

C/D：同样存在同步问题和维护负担。

Claude Code 支持两种路径特定规则：(1) 在规则文件顶部用 YAML frontmatter 指定 paths glob 模式；(2) 在特定目录下放置 CLAUDE.md，该文件仅在该目录下的文件操作时生效。两种方式各有用处——frontmatter 适合跨目录的主题规则，目录级 CLAUDE.md 适合特定子项目的规则。

A：混合所有规则会降低准确性——处理前端文件时后端规则是噪声。

用户级配置 ~/.claude.json 对所有项目生效，适合公司级别的公共服务（Jira、Slack、内部 API）。项目级 .mcp.json 适合项目特定的 MCP 服务器。密钥仍然通过 ${ENV_VAR} 引用，不在配置文件中硬编码。

A：重复配置增加维护负担——配置改了要更新所有项目。

C：只有一个项目有配置——其他项目用不了。

D：环境变量存储的是值，不是 MCP 服务器结构定义。

Agent SDK 封装了智能体循环（检查 stop_reason、执行工具、发回结果），适合标准场景。手动实现循环提供最大灵活性，适合有特殊需求（自定义日志、错误处理、状态管理）的场景。两者都是有效的选择，Claude Code -p flag 适用于一次性任务，而非持续运行的后端服务。

A：Claude Code -p 是为 CLI 一次性任务设计的，不适合作为后端服务组件。

System prompt 是设定持久角色、行为边界和全局规则的正确位置——它在整个对话中持续生效。每条消息的具体上下文（如当前对话轮次、客户信息、case facts）应放在 user message 中，因为它是动态变化的。这种分离让持久规则和动态信息各得其所。

A：system prompt 中放动态上下文会越来越长，且 system prompt 不适合频繁变化的内容。

C：system prompt 是可靠的——它是专门为持久行为设置设计的。

D：第一条设为角色设定后，后续消息缺乏上下文信息。

对于需要多步骤推理的复杂分析任务，引导模型按步骤思考（Chain-of-Thought）比直接跳到结论有效得多。结构化的步骤让模型：(1) 不遗漏条款；(2) 每个条款独立评估；(3) 风险等级可追溯；(4) 总结有依据。这比单纯描述"什么是不利条款"效果好得多。

A：更长的描述不如结构化的流程有效。

C：换大模型不解决推理结构的问题。

D：分段分析丢失了跨段落的条款关联。

模型的拒绝通常是因为缺少上下文——它不知道这段敏感内容为什么需要被分析。在 system prompt 中明确说明：你是谁、你在什么合规框架下工作、这些内容用于什么合法目的（医疗审核、法律合规审查），可以显著减少误拒绝。这是 prompt engineering 的标准做法。

A：降低 safety 设置影响整体安全性，不是精准解决方案。

C：换模型不解决根本问题——新模型缺少同样的上下文。

D：替换敏感词改变了内容语义，审核结果不可靠。

多轮对话的状态应由应用层确定性地管理（而非依赖模型记忆）。在每条 user message 中嵌入当前状态：已收集的字段、当前步骤、待收集的字段、上一条回答是否完整。这让模型有明确的上下文做决策——不需要"回忆"前面发生了什么。

A：system prompt 不适合频繁变化的状态——应该在 user message 中传递动态信息。

C：依赖模型记忆不可靠——长对话中可能遗忘或混淆。

D：不维护状态会导致重复询问或遗漏字段。

嵌套 JSON schema 需要逐层精确定义：每层哪些字段是 required、array 内每个 item 的 schema、嵌套对象的约束。例如工作经历数组中每个元素的 {公司, 职位, 起止时间} 必须完整定义。Schema 越精确，tool_use 输出的结构就越可靠。关键：每层都显式定义，不要依赖模型的"理解"。

A：拍平丢失了数据间的逻辑关系——一段工作经历的公司和职位是关联的。

C：不定义嵌套 schema 等于放弃了结构化输出的保证。

D：拆成多个调用可能丢失跨部分的关联信息。

分块分析的最大风险是丢失跨块关联——第 5 页提到的概念到第 60 页才定义，如果每块独立分析就无法关联。解决方案：每分析完一块，提取关键实体、定义、未解决的引用，作为"running context"传递给下一块。这样后面的分析能关联前面的内容。

A：独立分析丢失跨块关联——这是分块最核心的陷阱。

C：随机打乱破坏了文档的逻辑结构——定义--使用--扩展的顺序是重要的。

D：后半部分可能包含安全要求、实施细节等关键内容。

上下文隔离不意味着零共享——而是共享"必要的、结构化的、精简的"背景。将公司信息、领域术语、合规要求等提炼为一份短文档（可能只有几十行），作为每个子智能体的固定背景。这比共享完整对话历史高效得多，同时确保子智能体的输出与公司语境相关。

A：完整历史是上下文隔离的反面——包含了大量与子任务无关的噪声。

C：子智能体不知道缺少什么——它可能不会主动查询。

D：system prompt 不便于动态更新（不同任务可能需要不同背景）。

生产智能体系统需要和任何生产系统一样的可观测性。结构化日志至少记录：会话 ID、每次 API 调用的 stop_reason、每轮的工具调用名称和参数、延迟、升级触发条件和原因、错误类型。这些数据聚合后可回答产品经理的所有问题，并帮助发现异常（如某个工具突然频繁失败、循环轮次异常增加）。

A：让模型总结自己既不精确也不可审计。

C：账单只看总调用量，无法回答分类问题。

D：10 个样本无法代表一个月的运行状况。

幻觉不能通过 prompt 消除——它是模型的基本特性。正确的架构策略是：要求每条声明标注来源和出处，明确区分"原文直接引用"和"模型基于多源的推断"，对关键声明（如论文标题、统计数据）在输出前做反向校验（用声称的标题去搜索确认是否存在）。

A：prompt 指令不能消除幻觉——模型不知道它在编造。

C：temperature=0 减少但不会消除幻觉，且可能遗漏真实但低概率的信息。

D：模型不知道自己不确定——它可能对编造的内容也有高置信度。

handoff 的核心原则：传递结构化结果而非自由文本，下游 agent 透传而非重新生成。标准协议应包括：结果 payload（不可变的原样内容）、来源 agent ID、置信度分数、生成时间戳。Router 只负责路由和透传，不做语义改写——每次改写都是引入错误的入口。

A：更强模型不能消除重新解释引入的误差，根源在流程设计而非模型能力。

C：去掉 Router 会失去多 agent 编排的核心价值——统一入口和路由逻辑。

D：「改写为用户友好语言」正是引入错误的来源——应透传原始结果。

三层防护：① max_turns 作为硬上限（防止无限运行）；② 检测连续 N 次是否调用相同的工具+相同的参数（重复检测）；③ 比较前后两轮的状态变化——如果关键指标无进展（如未找到新信息、未解决更多子问题），触发终止。这三种机制互补：max_turns 防失控、重复检测防死循环、无进展检测防无效探索。

A：max_tokens 控制的是单次响应的输出长度，不是循环次数。

C：temperature 影响随机性，与循环退出逻辑无关。

D：移除循环会失去多步推理能力——很多复杂任务需要多次工具调用。

重试策略三要素：① 指数退避（1s → 2s → 4s → 8s...）减轻被调用方压力，避免雪崩；② 最大重试次数（通常 3-5 次）防止无限等待；③ 错误类型区分——网络超时、503 等临时故障可重试，401/403 等认证错误不应重试（重试也不会成功），400 参数错误不应重试（需修正请求）。工具层做完这些后，将最终结果（成功 or 终局失败）返回智能体。

A：固定长超时会让正常用户等待过久，且不能解决根本问题。

B：立即重试 10 次可能在 1 秒内向故障服务发起 10 次请求，加剧问题。

D：吞掉所有错误会让智能体和用户不知道发生了什么，可能导致错误决策。

跨会话状态保持的最佳实践：① 定义「case facts」结构（已确认的事实、待验证的假设、已排除的方向、当前进度百分比）；② 每个会话结束前，智能体将 case facts 写入外部存储（文件、数据库）；③ 下一会话启动时，从存储加载 case facts，注入 system prompt（不占用 user message 空间）；④ 新会话基于该快照继续工作，无需重做已完成的分析。这种方法比保存全文对话更结构化、更省 context。

A：context window 再大也是有限且成本高的——这是回避问题而非解决问题。

C：重新执行所有步骤浪费时间和算力，且可能产生不一致的结果。

D：把历史对话全量贴入下一会话会迅速耗尽 context window 且信息密度低。

有依赖的并行任务最佳方案：① 定义任务 DAG（A 无依赖 → B 依赖 A → C 依赖 A 和 B）；② 编排器先启动所有无依赖任务（A 立即开始）；③ A 完成后，触发 B（依赖满足）；④ A 和 B 都完成后，触发 C；⑤ 如果某任务失败，其下游任务自动标记为 blocked 而非静默等待。这样可以最大化并行度同时保证依赖正确。完全串行（B）虽然正确但浪费了 A 和 B 之间潜在的并行机会——实际上 B 的「统计设计」阶段可能不需要 A 的完整输出。

A：同时启动会乱——B 和 C 可能在 A 还没完成时就开始，使用空数据。

B：完全串行虽然正确但低效，且无法扩展到更多任务的场景。

D：合并到一个 Agent 失去了并行性和专业化优势。

权限控制分层策略：① 定义命令白名单（如 apt-get install <已审核的包名>、systemctl restart <特定服务>）——这些可以自动放行；② PreToolUse hook 拦截所有 sudo 命令，在白名单中的自动通过，不在白名单中的触发用户确认；③ hook 记录所有 sudo 调用的完整日志（命令、时间、结果）。这比「完全禁止」（阻碍工作）或「完全信任」（安全风险）更实用。创建另一个有完整 sudo 的子智能体（D）只是转移了问题而非解决问题。

A：prompt 不是安全机制——智能体可能被注入攻击诱导使用 sudo。

B：完全禁止会阻塞必要的自动化操作，降低效率。

D：新建有完整 sudo 的子智能体会创建更大的攻击面，且绕过了权限审查。

Tool response 设计三原则：① 扁平化——超过 2 层嵌套的结构应拆分为多个顶层键或通过引用关联；② 每个字段的值旁附简短语义说明（如 "status": "active" // 账户状态：活跃/暂停/关闭），帮助模型理解枚举含义；③ 按需返回——不要 dump 整个数据库记录，只返回智能体当前步骤需要的字段。JSON Schema 定义应放在 tool definition 的 output_schema 中（D），而非每次 response 里。

A：XML 和 JSON 准确率差异不大，关键在于结构复杂度而非格式。

C：自然语言描述会丢失结构化信息的精确性，不利于程序化处理。

D：每次 response 都带 schema 浪费 tokens，schema 应放在 tool definition 中。

凭据管理黄金法则：凭据绝不进入配置文件。.mcp.json 使用 ${ENV_VAR} 语法引用环境变量；实际凭据由操作系统密钥管理器（macOS Keychain、Linux secret-tool）、CI/CD secret 变量或 vault 服务提供。.gitignore（A）是必要但不充分——即使不提交，明文凭据也可能通过日志、备份、屏幕共享泄露。环境变量注入是 MCP 官方推荐的做法。

A：.gitignore 防止提交但不足以防止其他泄露渠道（日志、调试输出、备份）。

C：硬编码在代码中是最不安全的方式——任何有代码访问权限的人都能看到。

D：手动输入不适用于自动化场景（CI/CD、定时任务、后台服务）。

Tool description 最佳实践：① 功能声明（一句话说清工具做什么）；② 使用条件（什么场景下应选择此工具）；③ 排除条件（什么场景下不应使用——避免误用）；④ 关键参数说明（尤其是有歧义的参数）；⑤ 一个典型调用示例。这个结构在 150-300 tokens 内提供了模型所需的全部决策信息。「何时不用」是最容易被忽略但最重要的部分——它能避免模型在不合适的场景误调用工具。

A：太简短，模型无法判断何时该用此工具 vs 其他工具。

B：过于冗长的描述占用宝贵 context 且可能让模型在细节中迷失。

D：仅有 schema 没有文字描述，模型不知道工具的设计意图和使用场景。

批量操作的部分失败处理模式：① 响应状态为 partial_success（而非简单的 success/error 二元）；② 返回三个部分——成功列表（已处理项）、失败列表（每项附 error_code + error_message + 是否可重试）、汇总统计（total/ succeeded/ failed）；③ 智能体基于这些信息决定：对可重试的失败项单独重试（而非整个批次），对不可重试的（如数据格式错误）跳过或报告用户。这种设计避免了重复处理已成功项，同时给智能体足够的决策信息。

A：静默忽略失败会让问题消失——用户不知道有 5 条没处理。

C：降低批次大小治标不治本——无论批次多大，部分失败的情况都会出现。

D：整个批次重试会重复处理成功的 95 条，可能产生重复数据或浪费资源。

MCP Resource vs Tool 的判断标准：Resource = 暴露数据（文件内容、数据库记录、API 响应），用 URI 标识，支持订阅变更通知；Tool = 暴露操作（执行搜索、修改数据、调用外部服务），有输入参数和返回结果。产品目录场景下的最佳设计：用 Resource 暴露目录的只读视图（mcp://products/catalog），支持按 ID 读取单个产品和订阅每日更新；用 Tool 提供复杂搜索能力（searchProducts 支持多条件筛选）。两者互补而非互斥。

A：只用 Tool 会失去 Resource 的 URI 直接访问和变更订阅能力。

B：只用 Resource 无法高效处理复杂搜索（跨字段组合查询）。

D：硬编码在 system prompt 中无法实时更新且占用宝贵 context。

CLAUDE.md 采用层级合并策略：① Claude 在工作目录及其所有父目录中寻找 CLAUDE.md；② 所有找到的 CLAUDE.md 内容合并加载；③ 当规则冲突时，离工作目录最近的 CLAUDE.md 优先（就近优先原则）——即子目录可覆盖父级设置；④ 子目录可以在 CLAUDE.md 中显式引用父级规则（"继承根目录的代码风格规范，补充以下前端特定规则"）。这样团队规范提供基线，子项目可按需调整。

A：完全忽略父级会失去团队通用规范的价值——DRY 原则。

C：父级优先会让子项目无法针对自身需求调整——比如前端和后台可能需要不同的 lint 规则。

D：手动选择增加操作负担且不可自动化（CI/CD 场景无法手动选择）。

可组合的命令设计模式：① 将 deploy 的核心流程（构建步骤、测试命令、部署顺序、回滚策略）封装为一个 Skill；② 项目级命令文件（.claude/commands/deploy.md）只写项目特定的配置——目标环境（staging/prod）、项目名、额外的健康检查端点；③ 命令文件通过参数 `$0, $1` 或引用 Skill 来复用通用逻辑。这样团队添加新项目时，只需写一个轻量的命令文件，核心流程由 Skill 统一维护。

A：复制粘贴导致流程漂移——修复一个 bug 需要更新所有副本。

B：用户级命令不在仓库中，无法通过 git 与团队共享。

D：CLAUDE.md 应放持久性规则，命令逻辑更适合放在专门的命令文件中。

Plan Mode 强制执行的工程化方案：① 在 .claude/hooks/ 中配置 PreToolUse hook，监听 Edit 和 Write 工具调用；② hook 检查工作目录（或指定的 plan 目录）中是否存在已批准的 plan 文件（如 plan-approved.md）；③ 如果不存在，hook 返回阻止并提示「请先进入 Plan Mode 并获取方案审批」；④ 紧急修复可以通过特定标记（如 --hotfix）绕过——保留逃生通道；⑤ plan 文件合入后自动清理标记，下一次变更需要新 plan。这是流程保障而非信任依赖。

A：文档靠自觉——在交付压力下会被跳过，不是工程化方案。

C：完全禁用编辑过于极端——紧急修复、小改动不应被阻塞。

D：弹出确认对话框是 UI 层面的提醒，用户可以直接点「确认」绕过。

多仓库配置管理策略：① 创建 claude-config-templates 仓库，存放团队共享的 CLAUDE.md 基线、通用 skills、标准 hooks；② 各服务仓库通过 git submodule（或 subtree）引用模板仓库；③ 每个仓库保留自己的 .claude/ 目录用于覆盖特定配置——子目录的 CLAUDE.md 优先级更高，自动覆盖模板中的对应规则；④ 模板仓库发版时，各仓库通过更新 submodule 引用来获取最新配置。对比脚本复制（A）：submodule 可追溯版本、可回滚、有明确的更新机制。

A：复制脚本无法追溯版本——你不知道每个仓库在用哪个版本，更新靠手动重新运行脚本。

C：中心化 API 动态加载引入网络依赖——离线或 API 故障时所有仓库都受影响。

D：其他仓库没有配置，Claude 无法理解项目特定约定，工作效率大幅下降。

跨 IDE 一致性的关键：项目 .claude/ 目录（CLAUDE.md、commands/、skills/、hooks/、agents/）是所有 Claude Code 集成（VS Code 扩展、JetBrains 插件、终端 CLI）的统一配置源。无论用户使用哪种界面，Claude Code 都从同一目录加载相同的规则、技能和钩子。用户级配置（~/.claude/）可用于个人偏好但不应包含项目关键规则。这保证了：团队成员换 IDE 不影响行为、CI/CD 中的 Claude Code 与本地行为一致、新人 onboarding 只需 clone 仓库。

A：多份配置必然漂移——修一个 bug 需要记得同步所有版本。

C：强制统一 IDE 不现实且没必要——Claude Code 的设计目标就是跨界面一致。

D：云端同步引入网络依赖和额外的安全风险——配置应随代码一起版本化。

动态 few-shot 管道：① 维护一个带标签的示例库（每条示例标注：查询类型、难度、所需输出格式）；② 收到用户查询后，先用轻量方式分类（关键词匹配或小模型快速分类）；③ 根据分类标签从示例库中检索最匹配的 2-3 个示例（用语义相似度或标签精确匹配）；④ 将选中的示例动态拼入当前请求的 prompt。这种方法精准、节省 context（只加载相关示例），且示例库可独立迭代（新增类型不需要改 prompt 模板）。

A：50 种类型的全量示例会占用大量 context window，且大多数与当前查询无关。

C：模型在没有示例的情况下难以精确匹配企业特定的回复格式要求。

D：50 个 Agent 的维护成本极高，且很多查询类型之间共享回复结构。

输出验证三层架构：① Schema 验证——检查 JSON 结构、字段类型、必填项（可用 JSON Schema validator 自动完成）；② 业务规则验证——检查内容逻辑：年龄 ≥ 0、日期 ≤ 今天、金额 = 单价 × 数量、状态转换合法等；③ 异常检测——统计层面：单条输出的字段分布是否与历史数据偏离过大。任一层失败时，将具体的失败原因（哪条规则违反了什么约束）反馈给模型，触发修正循环（最多 2-3 次，超过则降级处理）。

A：Schema 只验证结构，不验证内容逻辑——负数年龄在 JSON Schema 中是合法的 number。

B：自然语言指令无法精确约束逻辑——模型可能忽略或理解偏差。

D：人工审核无法规模化——高吞吐量场景下人工是不可行的瓶颈。

多模态 prompt 最佳实践：① 使用 content block 数组，将图片（image content block）和文字说明（text content block）放在同一个 user message 中；② 给出明确的判断维度（如：产品颜色、形状、标签文字、包装特征），每个维度定义一致/不一致/无法判断三种结果；③ 使用 tool_use 定义输出 schema，确保判断结果结构化（而非自由文本）；④ 要求模型标注每个维度判断的依据（「图片中标签显示 X，文字描述为 Y」）。两步法（A）增加延迟且第一步可能丢失关键细节。

A：两步法引入中间环节误差——第一步的描述可能遗漏关键细节，且总延迟翻倍。

C：没有判断标准，模型可能关注错误的维度（如背景而非产品本身）。

D：base64 嵌入到文字中是错误做法——图片应使用 image content block 而非文本拼接。

「澄清优先（Clarification-First）」策略的 prompt 设计：① 要求模型先做信息缺口分析——列出要处理此请求需要知道但当前缺失的信息（产品名、订单号、具体问题、期望处理方式）；② 根据缺口生成结构化的追问，一次问 2-3 个最关键的问题（不要一次问太多）；③ 追问要友好且具体——不是「请重新描述」，而是「您提到的产品是哪个？方便提供订单号吗？具体是什么问题呢？」；④ 同时告诉用户「如果您能提供订单号，我可以立刻帮您查询」。这比猜测（可能错误导致后续修复成本更高）或粗暴拒绝（差体验）都要好。

A：猜测可能错误——错误处理比多问一句的成本高得多（退款给错人、发错替换品）。

C：粗暴要求用户重新描述是差体验——用户可能不知道如何「描述得更清晰」。

D：直接转人工失去了自动化的价值——大部分模糊请求通过 1-2 轮追问可以澄清。

System prompt 工程化四要素：① 版本控制——prompt 文件随代码一起用 git 管理，每次修改有 commit message 说明改动原因和预期效果；② 单变量原则——每次只改一处（一段指令、一个示例、一个参数），这样才能归因效果变化；③ 固定 eval 基准——维护 50-100 个测试用例的 eval set，覆盖正常路径、边界情况和错误恢复，每个新版本必须在 eval set 上跑完并对比基线；④ 性能阈值——设定关键指标的最低可接受值（如任务完成率 ≥ 85%、幻觉率 ≤ 5%），低于阈值时 CI 自动告警阻止合并。

A：人工检查不可规模化且不一致——同一个人不同时间可能给出不同判断。

C：回滚到 git commit 解决了回退问题但解决了归因——不知道是 5 处修改中哪处导致的。

D：手动对比多个版本效率低且容易遗漏——应该自动化 eval 对比而非人工 diff。

Checkpoint summary 策略：① 在任务分解时标识 checkpoints——每完成一个独立子任务后触发压缩；② 压缩格式：已确认的事实（只保留结论，丢弃原始的搜索/推理过程）、当前总体进度、下一步计划；③ 压缩后的 checkpoint 保留在上下文中（约 200-500 tokens），原始中间数据从上下文中移除；④ 关键原始数据（如重要的引用原文）可通过引用链接保存（存到外部文件，需要时重新读取）。这比升级模型（A）更根本——context 管理是架构问题，不是资源问题。

A：更大的 context window 只是推迟问题——长任务总会超过某个上限。

C：粗暴截断可能丢失关键信息——500 字符的引用不完整可能导致后续推理错误。

D：删除所有工具输出会让智能体失去已获取的信息，等于重新开始。

长运行会话可靠性三原则：① 增量持久化——每处理一个单元（文件/记录）立即将结果写入外部存储，不依赖内存中的状态；② 进度追踪——维护一个独立的进度文件（如 progress.json），记录「已处理 ID 列表」「处理到第几个」「最后成功时间」；③ 崩溃恢复——会话重新启动时，先读取进度文件，跳过已完成的项，从断点继续。这确保即使会话在第 6 小时崩溃，损失仅限于当前正在处理的那一项（而非 600 项）。

A：retry 只在请求层面有效——如果整个会话/进程崩溃，retry 无法恢复已丢失的内存状态。

C：缩短批次降低了单次失败的影响面，但每次新会话都有冷启动成本，且仍需进度追踪。

D：专用服务器不能消除 API 5xx 错误或网络故障——基础设施永远可能出问题，应用层必须有容错。

跨会话记忆架构：① 利用 Claude Code Project 的 memory 功能（可设置为 persistent），Claude 可以将关键事实写入 memory 文件；② 设计一个「会话结束」流程——当前会话结束前，Claude 生成一份结构化的 session summary（本次讨论的核心主题、已做出的决策、待解决的问题、下一次会话的建议起点），写入 Project 的文件系统中；③ 下一会话启动时，Claude 自动加载 Project 中的所有文件包括上次的 summary，无需用户重新解释背景。这比 CLAUDE.md（A）更适合频繁变化的研究状态——CLAUDE.md 适合持久性规则，memory 文件适合动态进展。

A：CLAUDE.md 适合团队的持久性规范，不适合频繁更新的研究进展——每次改 CLAUDE.md 会产生 git diff 噪音。

C：永不关闭会话不可行——API 有超时、token 限制、服务端可能会话过期。

D：贴完整对话记录会迅速占满 context window 且信息密度低。

优雅降级设计原则：① 依赖隔离——每个外部服务的故障不应级联影响其他正常服务；② 独立降级策略——每个依赖都有独立的 fallback：知识库不可用用缓存或跳过、数据库故障切换副本、MCP 不可用禁用相关功能；③ 透明告知——降级时必须明确告诉用户哪些信息/功能因外部服务不可用而受限（如「以下回答未查询实时知识库，基于已有信息生成」）；④ 替代方案——尽可能给用户其他选择（如「您可以稍后重试，或通过以下方式手动查询」）。编造信息（D）是绝对不能接受的——宁可承认能力受限也不能提供虚假信息。

A：单个故障可能影响答案质量——知识库不可用时回答可能不准确，应告知用户。

C：增加超时让用户等待更久但外部服务仍不可用——不解决根本问题。

D：让模型编造信息是危险的反模式——用户信任基于诚实，不是看似完整的回答。