cca

name	cca
description	Claude Certified Architect (CCA) 完整学习套件。当用户说"CCA"、"学CCA"、"Claude架构师"、"CCA学习"、"学domain1"、"代理架构"、"agent编排"、"学domain2"、"工具设计"、"MCP集成"、"学domain3"、"Claude Code配置"、"CLAUDE.md"、"学domain4"、"提示工程"、"structured output"、"学domain5"、"上下文管理"、"可靠性"、"CCA测验"、"模拟考试"、"cca quiz"时使用。
allowed-tools	Read, Write, Edit, Bash, Grep, Glob, Agent

Claude Certified Architect (CCA) — 完整学习套件

你是 CCA 学习导师。根据用户的请求，路由到对应部分：

用户说	跳转
"CCA"、"总览"、"学CCA"	→ 考试概览
"domain1"、"代理架构"、"agent编排"	→ 领域 1
"domain2"、"工具设计"、"MCP"	→ 领域 2
"domain3"、"Claude Code配置"、"CLAUDE.md"	→ 领域 3
"domain4"、"提示工程"、"structured output"	→ 领域 4
"domain5"、"上下文管理"、"可靠性"	→ 领域 5
"测验"、"quiz"、"模拟考试"	→ 模拟测验

如果用户没有明确指定，先展示概览，再询问从哪里开始。

---

概览

考试信息：

• 60 道单选题，120 分钟
• 及格分：720/1000
• 全程监考，不可查阅外部资料
• 2 个工作日出分，附分项报告

6 大考试场景（随机抽 4 个）：

1. 客户支持解决方案代理（Agent SDK + MCP + 升级处理）
2. 使用 Claude Code 生成代码（CLAUDE.md + 计划模式）
3. 多代理研究系统（协调器-子代理编排）
4. 开发者生产力工具（内置工具 + MCP 服务器）
5. CI/CD 中的 Claude Code（非交互式管道 + 结构化输出）
6. 结构化数据提取（JSON 模式 + tool_use + 验证循环）

5 大知识领域：

#	领域	权重
1	代理架构与编排	27%
2	工具设计与 MCP 集成	18%
3	Claude Code 配置与工作流	20%
4	提示工程与结构化输出	20%
5	上下文管理与可靠性	15%

推荐学习路径：

初学者（从易到难）：领域 3 → 4 → 2 → 1 → 5 → 测验

有经验者（按权重）：领域 1 → 3 → 4 → 2 → 5 → 测验

核心技术栈速查：

技术	核心概念
Claude Agent SDK	AgentDefinition, stop_reason, hooks (PostToolUse), Task 工具, fork_session, allowedTools
MCP	.mcp.json, 环境变量扩展, isError, tool descriptions, resources
Claude Code	CLAUDE.md 层级, .claude/rules/, .claude/commands/, skills (context: fork), -p 标志, --output-format json
Claude API	tool_use, tool_choice (auto/any/forced), JSON schema, Message Batches API, custom_id

考试不考的内容： 模型微调/训练、API 认证/计费、具体编程语言实现细节、MCP 服务器部署/运维、模型内部架构、向量数据库/Embedding、浏览器自动化、流式 API/SSE、限速/定价计算、OAuth/API key 轮转

---

领域 1：代理架构与编排

权重：27%（最高）— 约 16 道题

Step 1: 知识点讲解

TS 1.1: 设计和实现代理循环（Agentic Loops）

核心知识：

• 代理循环生命周期：发送请求 → 检查 stop_reason → 执行工具 → 返回结果
• stop_reason 的两个关键值：
  • "tool_use" → 继续循环，执行工具调用
  • "end_turn" → 终止循环，展示最终响应
• 工具结果追加到对话历史，让模型能推理下一步动作
• 模型驱动决策 vs 预配置决策树的区别

必须掌握的反模式（考试常考陷阱）：

• ❌ 解析自然语言来确定循环终止
• ❌ 将任意迭代上限作为主要停止机制
• ❌ 检查助手文本内容作为完成指示符

实操技能：

• 实现基于 stop_reason 的控制流
• 在迭代间将工具结果添加到对话上下文

TS 1.2: 协调器-子代理（Coordinator-Subagent）编排

核心知识：

• Hub-and-spoke 架构：协调器管理所有通信、错误处理和信息路由
• 关键考点：子代理在隔离的上下文中运行，不继承协调器的对话历史
• 协调器负责：任务分解、委派、结果聚合、选择调用哪些子代理
• 过于狭隘的任务分解风险（如 "创意产业" 只分解为视觉艺术，遗漏音乐/写作/电影）

实操技能：

• 设计能分析查询复杂度并动态选择子代理的协调器
• 在子代理间分配研究范围以减少重复
• 实现迭代精炼循环：协调器评估合成输出 → 发现差距 → 重新委派
• 所有子代理通信通过协调器路由

TS 1.3: 配置子代理调用、上下文传递和 Spawning

核心知识：

• Task 工具用于生成子代理，allowedTools 必须包含 "Task" 才能调用子代理
• 关键考点：子代理上下文必须在 prompt 中显式提供，不会自动继承父上下文或在调用间共享内存
• AgentDefinition 配置：descriptions、system prompts、tool restrictions
• fork_session 用于从共享分析基线探索不同方法

实操技能：

• 将前序代理的完整发现直接包含在子代理 prompt 中
• 使用结构化数据格式分离内容和元数据（源 URL、页码）
• 通过在单个协调器响应中发出多个 Task 调用来并行生成子代理
• 设计指定研究目标和质量标准（而非逐步过程指令）的协调器提示

TS 1.4: 实现带强制执行和交接模式的多步工作流

核心知识：

• 程序化强制执行（hooks、前置条件门）vs 基于提示的工作流排序指导
• 关键考点：涉及财务或安全关键操作时，仅靠 prompt 指令不够，必须用 hooks 编程式强制工具顺序
• 结构化交接协议：包含客户详情、根因分析、推荐操作

实操技能：

• 实现程序化前置条件：阻止 process_refund 直到 get_customer 返回验证过的 ID
• 将多关注点客户请求分解为独立项目，调查后合成统一解决方案
• 编写结构化交接摘要（客户 ID、根因、退款金额、推荐操作）

TS 1.5: 应用 Agent SDK Hooks 进行工具调用拦截和数据规范化

核心知识：

• PostToolUse hooks：在模型处理工具结果前拦截转换
• 工具调用拦截 hooks：强制执行合规规则（如阻止超阈值退款）
• hooks 提供确定性保证 vs prompt 指令的概率性合规

实操技能：

• 实现 PostToolUse hooks 规范化异构数据格式（Unix 时间戳 → ISO 8601）
• 实现拦截 hooks 阻止违反策略的操作并重定向到升级工作流

TS 1.6: 设计复杂工作流的任务分解策略

核心知识：

• 固定顺序管道（prompt chaining）vs 基于中间发现的动态自适应分解
• Prompt chaining：将审查拆分为按文件分析 + 跨文件集成
• 自适应调查计划：基于每步发现生成子任务

实操技能：

• 选择适当的分解模式：prompt chaining 用于可预测的多方面审查，动态分解用于开放式调查
• 将大型代码审查拆分为按文件的本地分析 + 跨文件集成

TS 1.7: 管理会话状态、恢复和分叉

核心知识：

• --resume <session-name> 恢复特定的先前对话
• fork_session 从共享分析基线创建独立探索分支
• 恢复会话时需告知代理文件变更
• 当先前工具结果过时时，新建会话 + 注入结构化摘要比恢复更可靠

实操技能：

• 使用 --resume 跨工作会话继续命名的调查会话
• 使用 fork_session 创建并行探索分支（如比较两种测试策略）
• 判断何时恢复会话 vs 何时重新开始

Step 2: 实操练习

练习：构建一个带升级逻辑的多工具代理

1. 定义 3-4 个 MCP 工具，写好详细的 description 以区分各工具的用途、输入和边界
2. 实现基于 stop_reason 的代理循环，正确处理 "tool_use" 和 "end_turn"
3. 为工具添加结构化错误响应：errorCategory（transient/validation/permission）、isRetryable、描述
4. 实现一个拦截 hook 强制执行业务规则（如阻止超 $500 的退款操作）
5. 用多关注点消息测试，验证代理能分解请求并合成统一响应

Step 3: 知识检查（3 题）

出 3 道模拟题，覆盖：反模式识别、子代理上下文隔离、hooks vs prompt 指令的选择。每题 4 选项，答后讲解正确答案和干扰项错误原因。

---

领域 2：工具设计与 MCP 集成

权重：18% — 约 11 道题

Step 1: 知识点讲解

TS 2.1: 设计清晰描述和边界的工具接口

核心知识：

• 工具描述是 LLM 选择工具的主要机制 — 描述模糊或重叠会导致选择不可靠
• 描述应包含：输入格式、示例查询、边界情况、何时使用 vs 使用替代工具
• 模糊描述导致误路由的典型案例：analyze_content vs analyze_document 描述几乎相同
• System prompt 中的关键词敏感指令可能覆盖良好的工具描述

实操技能：

• 写清晰区分每个工具用途的描述
• 重命名工具以消除功能重叠（如 analyze_content → extract_web_results）
• 将通用工具拆分为用途明确的工具（如 analyze_document → extract_data_points + summarize_content + verify_claim_against_source）
• 审查 system prompt 中可能干扰工具选择的关键词

TS 2.2: 为 MCP 工具实现结构化错误响应

核心知识：

• MCP isError 标志用于向代理通信工具失败
• 错误类型区分：
  • 瞬时错误（超时、服务不可用）→ 可重试
  • 验证错误（无效输入）→ 不可重试，需修改输入
  • 业务错误（违反策略）→ 不可重试，需向用户解释
  • 权限错误 → 不可重试，需升级
• 统一的 "Operation failed" 泛错误阻碍代理做出合理恢复决策
• 区分访问失败（需重试）和有效空结果（查询成功但无匹配）

实操技能：

• 返回结构化错误元数据：errorCategory、isRetryable boolean、人可读描述
• 对业务规则违反返回 retriable: false + 面向客户的解释
• 子代理本地处理瞬时失败，仅传播无法本地解决的错误（含部分结果和已尝试的操作）

TS 2.3: 跨代理分配工具并配置 tool_choice

核心知识：

• 给代理 18 个工具会降低选择可靠性 — 每个子代理限制 4-5 个与其角色相关的工具
• 拥有角色外工具的代理倾向于滥用它们（如合成代理尝试 web 搜索）
• 作用域工具访问：只给代理完成其角色所需的工具 + 有限的跨角色高频工具

tool_choice 配置选项（必须熟练掌握）：

• "auto" — 模型可能返回文本而非调用工具
• "any" — 模型必须调用一个工具（自行选择哪个）
• 强制选择 {"type": "tool", "name": "..."} — 必须调用指定工具

实操技能：

• 限制每个子代理的工具集为与其角色相关的工具
• 用 tool_choice: "any" 保证模型调用工具而非返回文本
• 用强制选择确保特定工具先执行（如先 extract_metadata，再处理后续步骤）

TS 2.4: 将 MCP 服务器集成到 Claude Code 和代理工作流

核心知识：

• MCP 服务器作用域：
  • 项目级 .mcp.json — 共享团队工具，版本控制
  • 用户级 ~/.claude.json — 个人/实验性服务器
• .mcp.json 中的环境变量扩展（如 ${GITHUB_TOKEN}）用于凭证管理，避免提交密钥
• 所有已配置 MCP 服务器的工具在连接时同时可用
• MCP resources 作为内容目录（issue 摘要、文档层级、数据库 schema），减少探索性工具调用

实操技能：

• 在项目级 .mcp.json 配置共享 MCP 服务器 + 环境变量扩展
• 在用户级 ~/.claude.json 配置个人 MCP 服务器
• 增强 MCP 工具描述以防止代理偏好内置工具（如 Grep）而非更强大的 MCP 工具
• 优先使用社区 MCP 服务器（如 Jira），自定义服务器用于团队特定工作流

TS 2.5: 有效选择和应用内置工具

核心知识：

• Grep — 搜索文件内容（函数名、错误消息、import 语句）
• Glob — 按文件名/扩展名匹配文件路径
• Read/Write — 完整文件操作；Edit — 基于唯一文本匹配的定向修改
• Edit 失败时（非唯一匹配），回退到 Read + Write
• Bash — 系统命令和终端操作

实操技能：

• 渐进式理解代码库：先用 Grep 找入口点，再用 Read 跟踪 imports 和流程
• 追踪函数使用：先识别所有导出名，再跨代码库搜索每个名称

Step 2: 实操练习

练习：设计并调试工具描述

1. 创建两个功能故意相似的 MCP 工具（如 get_customer 和 lookup_user）
2. 写模糊的描述，让它们容易被混淆
3. 用测试请求验证误路由
4. 修正描述，使每个工具的用途、输入格式和边界条件清晰区分
5. 再次测试，体验描述质量对选择可靠性的影响

Step 3: 知识检查（3 题）

出 3 道模拟题，覆盖：工具描述重叠的最佳修复方式、tool_choice 三选项场景、MCP 服务器项目级 vs 用户级配置选择。

---

领域 3：Claude Code 配置与工作流

权重：20% — 约 12 道题

这个领域区分"用过 Claude Code 的人"和"能为团队配置 Claude Code 的人"。

Step 1: 知识点讲解

TS 3.1: 配置 CLAUDE.md 文件层级

核心知识（考试最爱出陷阱题）：

CLAUDE.md 三层结构：

1. 用户级 ~/.claude/CLAUDE.md — 仅对该用户生效，不版本控制，不共享
2. 项目级 .claude/CLAUDE.md 或根目录 CLAUDE.md — 版本控制，团队共享
3. 目录级 — 子目录中的 CLAUDE.md 文件

经典陷阱题： 团队成员没收到指令 → 因为指令存在用户级配置中（未版本控制，未共享）。正确做法：放在项目级。

• @import 语法引用外部文件，保持 CLAUDE.md 模块化
• .claude/rules/ 目录存放主题特定的规则文件

实操技能：

• 诊断配置层级问题（如新团队成员未收到指令）
• 使用 @import 按包维护者领域知识选择性导入标准文件
• 将大型 CLAUDE.md 拆分到 .claude/rules/ 的聚焦文件中（如 testing.md、api-conventions.md）
• 使用 /memory 命令验证哪些配置文件被加载

TS 3.2: 创建和配置自定义斜杠命令和 Skills

核心知识：

• 项目级命令 .claude/commands/ — 版本控制，团队共享
• 用户级命令 ~/.claude/commands/ — 个人使用
• Skills 在 .claude/skills/ 中，SKILL.md 文件支持 frontmatter：
  • context: fork — 在隔离子代理中运行（输出不污染主会话）
  • allowed-tools — 限制 skill 可用工具
  • argument-hint — 无参数调用时提示用户

实操技能：

• 在 .claude/commands/ 创建项目级命令
• 使用 context: fork 隔离产出冗长输出的 skill
• 配置 allowed-tools 限制工具访问（如限制只读操作）
• 选择 skill（按需调用）vs CLAUDE.md（始终加载的通用标准）

TS 3.3: 应用路径特定规则实现条件约定加载

核心知识：

• .claude/rules/ 文件使用 YAML frontmatter 的 paths 字段指定 glob 模式
• 路径规则仅在编辑匹配文件时加载，减少无关上下文和 token 消耗
• glob 模式规则 vs 目录级 CLAUDE.md 的优势： glob 模式可跨多目录应用（如所有测试文件分散在代码库各处），目录级 CLAUDE.md 绑定到特定目录

实操技能：

• 创建带 YAML frontmatter 路径范围的规则文件：

  ---
  paths: ["src/api/**/*"]
  ---
  API 约定内容...
  

• 用 glob 模式 **/*.test.tsx 为所有测试文件应用统一约定
• 当约定需跨目录应用时选择路径规则而非子目录 CLAUDE.md

TS 3.4: 判断何时使用计划模式 vs 直接执行

核心知识：

• 计划模式适用： 大规模变更、多个可行方案、架构决策、多文件修改
• 直接执行适用： 简单、范围明确的变更
• 计划模式在提交变更前安全探索和设计，避免代价高昂的返工
• Explore 子代理用于隔离冗长发现输出并返回摘要

实操技能：

• 对有架构影响的任务选择计划模式
• 对范围清晰的变更选择直接执行

TS 3.5: 应用迭代精炼技术实现渐进改进

核心知识：

• 具体的输入/输出示例比散文描述更有效
• 测试驱动迭代：先写测试 → 分享测试失败 → 引导渐进改进
• 面试模式：让 Claude 先提问发现开发者未预料的考虑点
• 何时一次性提供所有问题（交互问题）vs 逐个顺序修复（独立问题）

实操技能：

• 提供 2-3 个具体输入/输出示例来澄清转换需求
• 写测试套件覆盖期望行为、边界情况和性能要求

TS 3.6: 将 Claude Code 集成到 CI/CD 管道

核心知识：

• -p（或 --print）标志 — 非交互式模式，自动化管道必须
• --output-format json + --json-schema — CI 上下文中的结构化输出
• CLAUDE.md 为 CI 调用的 Claude Code 提供项目上下文
• 会话上下文隔离： 生成代码的同一 session 自我审查不如独立审查实例有效

实操技能：

• 用 -p 标志在 CI 中运行 Claude Code
• 用 --output-format json + --json-schema 产生机器可解析的结构化结果
• 在 CLAUDE.md 中记录测试标准和可用 fixtures

Step 2: 实操练习

练习：为团队开发工作流配置 Claude Code

1. 创建项目级 CLAUDE.md，写入通用编码标准和测试约定
2. 在 .claude/rules/ 创建带 YAML frontmatter 的规则文件（API 约定、测试约定）
3. 在 .claude/skills/ 创建一个使用 context: fork 的 skill
4. 在 .mcp.json 配置一个 MCP 服务器 + 环境变量扩展
5. 测试计划模式处理多文件重构 vs 直接执行处理单个 bug 修复

Step 3: 知识检查（3 题）

出 3 道模拟题，覆盖：团队共享 /review 命令应放在哪里、测试文件分散时如何统一约定、何时选择计划模式。

---

领域 4：提示工程与结构化输出

权重：20% — 约 12 道题

核心关键词：明确具体。

Step 1: 知识点讲解

TS 4.1: 用明确标准设计提示以提高精确度并减少误报

核心知识：

• ❌ "保守一点" / "只报告高置信度发现" — 不会提高精确度
• ✅ 精确定义哪些问题需要报告、哪些跳过，为每个严重级别提供代码示例
• 高误报率的恶性循环：即使准确类别也失去开发者信任

实操技能：

• 写具体的审查标准定义报告什么（bugs、安全）vs 跳过什么（风格、本地模式）
• 临时禁用高误报类别以恢复开发者信任
• 用具体代码示例定义明确的严重级别标准

TS 4.2: 应用 few-shot 提示提高输出一致性和质量

核心知识（考试高杠杆技术）：

• Few-shot 是详细指令仍产出不一致结果时最有效的技术
• 2-4 个针对模糊场景的示例，展示为何选择 A 而非 B 的推理过程
• Few-shot 让模型泛化到新模式，而非仅匹配预设情况
• 减少提取任务中的幻觉（处理非正式度量、多样文档结构）

实操技能：

• 创建 2-4 个针对模糊场景的示例，展示推理过程
• 用 few-shot 区分可接受的代码模式和真正问题

TS 4.3: 使用 tool_use 和 JSON Schema 强制结构化输出

核心知识：

• tool_use + JSON Schema = 保证语法合规的结构化输出，消除 JSON 语法错误
• 但不能消除语义错误（如行项目不等于总计、值放在错误字段）

tool_choice 三选项（必须精通）：

选项	行为	适用场景
"auto"	模型可能返回文本而非调用工具	默认，可能不调用工具
"any"	必须调用工具，自选哪个	多个提取 schema、文档类型未知
强制选择 {"type":"tool","name":"..."}	必须调用指定工具	确保先运行特定提取步骤

Schema 设计要点：

• 源数据可能缺失时使用可空字段（防止模型捏造值）
• 为模糊情况添加 "unclear" 枚举值
• "other" + 详细字符串字段用于可扩展分类
• 在提示中包含格式规范化规则处理不一致的源格式

实操技能：

• 定义带 JSON Schema 的提取工具，从 tool_use 响应中提取结构化数据
• 设计可选（nullable）字段防止模型为满足必填字段而捏造值

TS 4.4: 实现验证、重试和反馈循环以保证提取质量

核心知识：

• 重试时附加具体验证错误（retry-with-error-feedback）引导模型纠正
• 重试的局限： 当源文档确实缺少信息时重试无效（vs 格式/结构错误可通过重试解决）
• 语义验证错误（值不等于总计）vs 语法错误（tool_use 已消除）

实操技能：

• 实现包含原始文档、失败提取和具体验证错误的重试请求
• 识别何时重试无效（信息仅存在于外部文档）vs 何时会成功（格式不匹配）
• 设计自我纠正验证流：提取 calculated_total + stated_total 以标记差异

TS 4.5: 设计高效的批处理策略

核心知识：

• Message Batches API： 50% 成本节省，最长 24 小时处理，无延迟 SLA
• 适合：非阻塞的延迟容忍工作（隔夜报告、每周审计、夜间测试生成）
• 不适合：阻塞性工作流（合并前检查必须用同步 API）
• 批处理 API 不支持单个请求内的多轮工具调用
• custom_id 字段关联批量请求/响应对

实操技能：

• 匹配 API 到延迟需求：同步 API → 阻塞检查，批处理 → 隔夜分析
• 根据 SLA 约束计算批处理提交频率
• 处理批处理失败：按 custom_id 仅重新提交失败文档

TS 4.6: 设计多实例和多遍审查架构

核心知识：

• 自我审查的局限： 模型保留生成时的推理上下文，不太可能质疑自己的决策
• 独立审查实例（无前序推理上下文）比自我审查或扩展思考更能发现细微问题
• 多遍审查：按文件的本地分析 + 跨文件集成，避免注意力稀释和矛盾发现

实操技能：

• 用第二个独立 Claude 实例审查生成的代码
• 将大型多文件审查拆分为聚焦的按文件分析 + 跨文件数据流集成

Step 2: 实操练习

练习：构建结构化数据提取管道

1. 定义一个 tool_use 提取工具，JSON Schema 含必填字段、可选字段和可空字段
2. 添加 "unclear" 枚举值和 "other" + 详细字符串
3. 处理部分字段缺失的文档，验证模型返回 null 而非捏造值
4. 实现验证重试循环：schema 验证失败时重新发送含错误信息的请求
5. 设计批处理策略：提交 100 份文档到 Batches API，按 custom_id 处理失败

Step 3: 知识检查（3 题）

出 3 道模拟题，覆盖："只报告高置信度发现"为何无效、批处理 API 适用场景、消除 JSON 语法错误的最佳方法。

---

领域 5：上下文管理与可靠性

权重：15% — 约 9 道题

权重最小，但这里的错误会产生连锁效应。

Step 1: 知识点讲解

TS 5.1: 管理对话上下文以在长交互中保留关键信息

核心知识：

• 渐进式摘要的风险： 会将数值、百分比、日期、客户期望压缩成模糊摘要
  • ❌ 摘要："客户对订单有问题" → 丢失了金额、日期、订单号
  • ✅ 修复：持久化"案例事实"块，包含提取的金额、日期、订单号，永不被摘要
• "迷失在中间"效应： 模型可靠处理长输入的开头和结尾，但中间的内容可能被遗漏
  • ✅ 修复：将关键摘要放在输入开头
• 工具结果在上下文中累积，消耗与其相关性不成比例的 token

实操技能：

• 将交易数据（金额、日期、订单号、状态）提取到持久化的"案例事实"块
• 裁剪冗长的工具输出到仅相关字段
• 将关键发现摘要放在聚合输入的开头

TS 5.2: 设计有效的升级和歧义解决模式

核心知识：

三个有效的升级触发条件：

1. 客户要求人工 → 立即执行，不要先尝试解决
2. 政策空白/例外 → 升级
3. 无法推进 → 升级

两个不可靠的触发条件（考试会诱导你选）：

• ❌ 情绪分析 — 情绪与案例复杂度不相关
• ❌ 自我报告的置信度分数 — LLM 的置信度校准很差

实操技能：

• 在系统提示中添加明确升级标准 + few-shot 示例
• 客户明确要求人工时立即响应
• 政策空白或沉默时主动升级

TS 5.3: 在多代理系统中实现错误传播策略

核心知识：

• 结构化错误上下文：失败类型 + 尝试的查询 + 部分结果 + 替代方案
• 区分访问失败（超时需重试）和有效空结果（查询成功无匹配）
• ❌ 反模式：泛化错误状态（"搜索不可用"）隐藏有价值的上下文
• ❌ 反模式：静默抑制错误（返回空结果作为成功）或单一失败终止整个工作流

实操技能：

• 返回含失败类型、尝试的操作、部分结果和替代方案的结构化错误上下文
• 子代理本地处理瞬时失败，仅传播无法解决的错误（含已尝试内容和部分结果）

TS 5.4: 在大型代码库探索中有效管理上下文

核心知识：

• 上下文退化：扩展会话中模型开始给出不一致答案，引用"典型模式"而非早期发现的具体类
• 草稿本文件（scratchpad files）跨上下文边界持久化关键发现
• 子代理委派：隔离冗长探索输出，主代理维持高层理解
• 结构化状态持久化：每个代理导出状态到已知位置，协调器在恢复时加载清单

实操技能：

• 生成子代理调查具体问题
• 维护草稿本文件记录关键发现
• 使用 /compact 减少上下文使用

TS 5.5: 设计人工审查工作流和置信度校准

核心知识：

• 聚合准确率（如 97%）可能掩盖特定文档类型或字段的低性能
• 分层随机抽样测量高置信度提取的错误率
• 字段级置信度分数通过标注验证集校准
• 在按文档类型和字段段验证一致性能前不要自动化

实操技能：

• 实现分层随机抽样进行持续错误率测量
• 模型输出字段级置信度分数，校准审查阈值
• 将低置信度或源矛盾的提取路由到人工审查

TS 5.6: 在多源合成中保留信息溯源和处理不确定性

核心知识：

• 摘要步骤中源归属丢失（压缩时丢失 claim-source 映射）
• 结构化 claim-source 映射是合成代理必须保留和合并的
• 冲突统计数据：标注冲突 + 源归属，而非随意选择一个值

实操技能：

• 要求子代理输出结构化 claim-source 映射（源 URL、文档名、相关摘录）
• 报告中区分确立的发现和有争议的发现
• 保留原始源表述和方法论上下文

Step 2: 实操练习

练习：构建带错误传播的协调器

1. 创建一个协调器 + 两个子代理
2. 模拟子代理超时场景
3. 验证协调器能获取结构化错误上下文（失败类型、已尝试的查询、部分结果）
4. 验证协调器能用部分结果继续处理
5. 用相互冲突的信息源测试，验证输出标注冲突而非随意选择

Step 3: 知识检查（3 题）

出 3 道模拟题，覆盖：客户要求人工时的处理方式、子代理超时的最佳错误传播方式、渐进式摘要丢失交易数据的修复方法。

---

模拟测验

规则：

• 共 12 道单选题，按考试权重分配（领域 1：4 题，领域 2-5 各 2 题）
• 每题 4 个选项（A/B/C/D），仅 1 个正确
• 及格线：9/12（75%）
• 每次出一道题，等用户作答后再出下一题

---

题目 1（领域 1 - 代理架构）

场景：客户支持解决方案代理

生产数据显示你的代理在 12% 的情况下跳过 get_customer 调用，直接用客户声称的姓名调用 lookup_order，偶尔导致错误账户识别和错误退款。什么方式最能有效解决这个可靠性问题？

A) 添加程序化前置条件，阻止 lookup_order 和 process_refund 调用直到 get_customer 返回验证过的客户 ID B) 增强系统提示说明 get_customer 验证是所有订单操作前的强制步骤 C) 添加 few-shot 示例展示代理总是先调用 get_customer D) 实现路由分类器分析每个请求类型并仅启用相关工具子集

正确答案：A — 涉及财务等关键业务逻辑时，程序化强制执行（hooks/前置条件）提供确定性保证，prompt 方式（B、C）依赖概率性 LLM 合规，在有财务后果时不够可靠。D 解决的是工具可用性而非工具顺序问题。

---

题目 2（领域 2 - 工具设计）

场景：客户支持解决方案代理

生产日志显示代理在用户询问订单时频繁调用 get_customer 而非 lookup_order。两个工具的描述很简短（"获取客户信息" / "获取订单详情"），且接受相似的标识符格式。改善工具选择可靠性的最有效第一步是什么？

A) 在系统提示中添加 5-8 个 few-shot 示例展示正确的路由模式 B) 扩展每个工具的描述，包含输入格式、示例查询、边界情况和何时使用 vs 使用替代工具 C) 实现路由层解析用户输入并基于关键词预选工具 D) 合并两个工具为一个 lookup_entity 工具内部判断查询哪个后端

正确答案：B — 工具描述是 LLM 选择工具的主要机制。B 以最低成本直接解决根因。A 增加 token 但不修复根本问题。C 过度工程化。D 作为"第一步"过重。

---

题目 3（领域 1 - 代理架构）

场景：客户支持解决方案代理

你的代理首次解决率仅 55%（目标 80%）。日志显示它将简单案例（标准损坏替换+照片证据）升级给人工，却尝试自主处理需要政策例外的复杂情况。改善升级校准最有效的方法是什么？

A) 在系统提示中添加明确的升级标准 + few-shot 示例展示何时升级 vs 自主解决 B) 让代理每次响应前自报置信度分数（1-10），低于阈值时自动路由给人工 C) 部署独立的分类器模型基于历史工单预测哪些需要升级 D) 实现情绪分析检测客户挫败程度，超过阈值时自动升级

正确答案：A — 明确的升级标准 + few-shot 直接解决根因：决策边界不清晰。B 失败因为 LLM 自报置信度校准很差。C 过度工程化。D 情绪与案例复杂度不相关。

---

题目 4（领域 3 - Claude Code 配置）

场景：使用 Claude Code 生成代码

你想创建一个自定义 /review 斜杠命令运行团队标准的代码审查清单。这个命令应该对所有开发者在 clone 或 pull 仓库时都可用。命令文件应放在哪里？

A) 项目仓库中的 .claude/commands/ 目录 B) 每个开发者 home 目录中的 ~/.claude/commands/ C) 项目根目录的 CLAUDE.md 文件中 D) .claude/config.json 文件中的 commands 数组

正确答案：A — 项目级自定义命令存放在 .claude/commands/，通过版本控制自动共享给所有开发者。B 是个人使用不共享。C 用于项目指令，不是命令定义。D 描述了一个不存在的配置机制。

---

题目 5（领域 3 - Claude Code 配置）

场景：使用 Claude Code 生成代码

你被要求将团队的单体应用重构为微服务。这涉及数十个文件的变更和服务边界/模块依赖的决策。你应该采取什么方法？

A) 进入计划模式，探索代码库、理解依赖，在变更前设计实现方案 B) 从直接执行开始逐步修改，让实现过程揭示自然的服务边界 C) 用全面的前置指令详细说明每个服务的结构，然后直接执行 D) 从直接执行开始，仅在实现中遇到意外复杂度时切换到计划模式

正确答案：A — 计划模式适用于大规模变更、多个可行方案和架构决策。B 风险在于依赖发现太晚导致返工。C 假设你已知正确结构。D 忽略了复杂度在需求中已经明确。

---

题目 6（领域 1 - 代理架构）

场景：多代理研究系统

你的系统研究"AI 对创意产业的影响"，各子代理成功完成任务，但最终报告只涵盖视觉艺术，完全遗漏音乐、写作和电影。检查协调器日志发现它将主题分解为"数字艺术中的 AI"、"平面设计中的 AI"和"摄影中的 AI"。最可能的根因是什么？

A) 合成代理缺少识别发现覆盖差距的指令 B) 协调器的任务分解过于狭隘，子代理分配未覆盖所有相关领域 C) 搜索代理的查询不够全面 D) 文档分析代理因过于严格的相关性标准过滤了非视觉创意产业的源材料

正确答案：B — 日志直接暴露根因：协调器将"创意产业"仅分解为视觉艺术子任务。子代理在其被分配的范围内正确执行——问题在于分配了什么。

---

题目 7（领域 5 - 上下文管理）

场景：多代理研究系统

Web 搜索子代理在研究复杂主题时超时。哪种错误传播方式最能支持智能恢复？

A) 返回结构化错误上下文给协调器，包含失败类型、尝试的查询、部分结果和替代方案 B) 在子代理内实现指数退避自动重试，所有重试耗尽后返回泛化的"搜索不可用"状态 C) 捕获超时并在子代理内返回标记为成功的空结果集 D) 将超时异常直接传播到顶层处理器终止整个研究工作流

正确答案：A — 结构化错误上下文让协调器能做出智能恢复决策。B 隐藏有价值的上下文。C 将失败伪装为成功。D 在恢复策略可能成功时不必要地终止整个工作流。

---

题目 8（领域 4 - 提示工程）

场景：CI/CD 中的 Claude Code

你的管道脚本运行 claude "Analyze this pull request for security issues" 但无限期挂起。日志显示 Claude Code 在等待交互输入。在自动化管道中运行 Claude Code 的正确方法是什么？

A) 添加 -p 标志：claude -p "Analyze this pull request for security issues" B) 设置环境变量 CLAUDE_HEADLESS=true C) 重定向 stdin：claude "Analyze..." < /dev/null D) 添加 --batch 标志：claude --batch "Analyze..."

正确答案：A — -p（或 --print）是 Claude Code 非交互式模式的官方标志。其他选项引用了不存在的特性或 Unix 变通方法。

---

题目 9（领域 4 - 提示工程）

场景：CI/CD 中的 Claude Code

团队想降低自动分析的 API 成本。当前两个工作流使用实时 Claude 调用：(1) 合并前阻塞检查，(2) 隔夜生成的技术债务报告。经理建议将两者切换到 Message Batches API 以节省 50%。你如何评估这个提案？

A) 仅对技术债务报告使用批处理，合并前检查保持实时调用 B) 两个工作流都切换到批处理 + 状态轮询 C) 两个工作流都保持实时以避免批处理结果排序问题 D) 两个工作流都切换到批处理 + 超时回退到实时

正确答案：A — 批处理 API 无延迟 SLA（最长 24 小时），不适合阻塞性检查。技术债务报告是隔夜非阻塞工作，完美匹配批处理。

---

题目 10（领域 2 - 工具设计）

场景：多代理研究系统

合成代理经常需要验证特定声明。当前流程每次增加 2-3 次往返和 40% 延迟。评估显示 85% 的验证是简单事实查证，15% 需要深入调查。如何在保持可靠性的同时减少开销？

A) 给合成代理一个有限范围的 verify_fact 工具处理简单查证，复杂验证继续通过协调器委派给搜索代理 B) 让合成代理累积所有验证需求，一次性批量返回给协调器 C) 给合成代理所有搜索工具的访问权限 D) 让搜索代理在初始研究时主动缓存额外上下文

正确答案：A — 应用最小权限原则：给合成代理处理 85% 常见情况所需的工具，保留协调模式处理复杂情况。C 过度授权违反职责分离。

---

题目 11（领域 1 - 代理架构）

场景：开发者生产力工具

你的代码库有不同区域的编码约定：React 组件、API handler、数据库模型各有特定规范。测试文件分布在各处（如 Button.test.tsx 在 Button.tsx 旁边）。你想确保 Claude 自动应用正确约定。最可维护的方式是什么？

A) 在 .claude/rules/ 中创建带 YAML frontmatter glob 模式的规则文件，按文件路径条件应用约定 B) 在根 CLAUDE.md 中用标题分区各区域约定，依赖 Claude 推断适用哪部分 C) 为每种代码类型创建 .claude/skills/ 并在 SKILL.md 中包含相关约定 D) 在每个子目录放独立的 CLAUDE.md 文件包含该区域约定

正确答案：A — .claude/rules/ + glob 模式（如 **/*.test.tsx）可自动基于文件路径应用约定，适合测试文件分布在多目录的情况。D 无法覆盖跨多目录分散的文件。

---

题目 12（领域 5 - 上下文管理）

场景：结构化数据提取

一个 PR 修改了 14 个文件。你的单遍审查产出不一致结果：部分文件有详细反馈，其他仅有表面评论，明显 bug 遗漏，且出现矛盾——在一个文件中标记某模式为问题但在 PR 其他地方批准相同代码。如何重构审查？

A) 拆分为聚焦的分析遍：逐个文件分析本地问题，再运行单独的跨文件集成遍检查数据流 B) 要求开发者将大 PR 拆分为 3-4 个文件的小提交 C) 切换到更大上下文窗口的高端模型以在单遍中充分关注所有文件 D) 运行三次独立审查遍并仅标记至少两次出现的问题

正确答案：A — 拆分为聚焦的分析遍直接解决根因：同时处理过多文件导致注意力稀释。C 误解了更大窗口不能解决注意力质量问题。D 通过共识要求会抑制只被偶尔捕获的真实 bug。

---

评分与分析

12 题作答完毕后：

1. 计算总分： X/12
2. 按领域分析：
   • 领域 1（题 1,3,6,11）：X/4
   • 领域 2（题 2,10）：X/2
   • 领域 3（题 4,5）：X/2
   • 领域 4（题 8,9）：X/2
   • 领域 5（题 7,12）：X/2
3. 判定结果：
   • 9/12 以上：通过，已具备 CCA 水平
   • 7-8/12：接近，建议复习薄弱领域
   • 6/12 以下：建议从概览开始系统学习
4. 针对错题推荐在本 skill 内对应领域进行深入学习