先说清楚 CCA 是什么

CCA 是 Anthropic 官方的技术认证，60 道单选题、120 分钟、全程监考、不能查资料，2 个工作日出分并附详细报告。定位上类似 AWS Solutions Architect，只不过面向的是 Claude 生态。

但有个门槛：目前只对 Anthropic 合作伙伴公司的员工开放。

这重要吗？我觉得不重要。证书能证明能力，但能力不需要证书来获得。你把这套知识体系吃透，一样能构建生产级应用，一样能接企业项目。所以我把整个考试大纲拆了个底朝天，把真正值钱的东西提炼出来。

你需要掌握的四大核心技能

考试覆盖的核心技术栈：Claude Code、Claude Agent SDK、Claude API、模型上下文协议（MCP）。这四个东西不是孤立的，它们组合在一起就是当下构建 AI Agent 应用的完整工具链。

考试通过实战场景来测试，包括：

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

每一个都是可以直接变现的场景。下面按考试的五大领域逐个拆解。

领域一：代理架构与编排（占比 27%）

这是权重最大的部分，也是我认为最容易踩坑的地方。

考试会测试三种必须立刻拒绝的反模式：用自然语言解析来判断循环是否终止、把固定迭代上限当主要停止机制、以及检查助手的文本输出来判断任务是否完成。全错，一个都不能选。

最大的认知误区：很多人以为子代理和协调器共享内存。不共享。子代理在完全隔离的上下文中运行，每条信息都必须通过提示显式传递。我当时就踩过这个坑，调了半天发现子代理根本拿不到协调器的状态。

最关键的规则：涉及财务或安全关键场景时，光靠提示词指令是不够的。你必须通过钩子（hooks）和前置条件门（precondition gates）以编程方式强制执行工具调用顺序。这一点在实际生产中也是血泪教训——提示词可以被绕过，代码逻辑不会。

实践建议：构建一个包含 3-4 个 MCP 工具的多工具代理，正确处理 stop_reason 事件，添加 PostToolUse 钩子来规范数据格式，再加一个工具调用拦截钩子来阻止违反策略的行为。做完这个练习，这个领域的核心知识基本就覆盖了。

领域二：工具设计与 MCP 集成（占比 18%）

这个领域有个被严重低估的知识点：工具描述（tool description）。

工具描述是 Claude 进行工具选择的主要依据。如果你的描述写得模糊或者多个工具描述重叠，选择就会变得不靠谱。考试中有个示例：get_customer 和 lookup_order 的描述几乎一样，导致持续误路由。正确的修复不是加 few-shot、不是加路由分类器、不是合并工具——就是把描述写清楚。

说实话这个我用了才知道好在哪。之前搭代理老觉得是模型不够聪明，后来发现纯粹是自己工具描述写得烂。

另外几个关键点：

  • tool_choice 的三种模式要烂熟于心："auto"（模型可能返回文本不调工具）、"any"（必须调工具但自己选）、强制指定（必须调某个特定工具）
  • 给一个代理塞 18 个工具会显著降低选择准确率。每个子代理控制在 4-5 个工具，只给它角色相关的

实践建议：故意构建两个功能相似的 MCP 工具，先写模糊描述看它怎么出错，再修正描述体验区别。这个练习非常直观。

领域三：Claude Code 配置与工作流（占比 20%）

这部分区分的是"用过 Claude Code"和"给团队配过 Claude Code"的人。

CLAUDE.md 的层级结构是核心考点，三个层级：

  • 用户级：~/.claude/CLAUDE.md（个人配置，不进版本控制）
  • 项目级：.claude/CLAUDE.md（团队共享）
  • 目录级：子目录中的文件（特定目录生效）

考试最爱出的坑：团队成员没收到某个指令，因为它写在了用户级配置里——没有版本控制，没有共享。

还有个容易被忽略的功能：.claude/rules/ 目录下可以用 YAML 前置元数据配合 glob 模式（比如 **/*.test.tsx）在整个代码库中统一应用规范。这比目录级 CLAUDE.md 灵活得多，因为后者绑定在特定目录。

计划模式 vs 直接执行的选择也很关键：

  • 计划模式适合：单体架构重构、多文件迁移、架构决策
  • 直接执行适合：单文件 Bug 修复、一次性验证、范围明确的任务

另外要了解 context: fork 在技能前置元数据中的作用（隔离冗长输出）、-p 标志用于非交互式 CI/CD、以及独立审查实例比同一会话自我审查能发现更多问题。

实践建议：搭一个完整的项目，包含 CLAUDE.md 层级结构、带 glob 模式的 .claude/rules/ 目录、一个使用 context: fork 的技能、以及在 .mcp.json 中配置了环境变量扩展的 MCP 服务器。然后分别用计划模式和直接执行模式各跑一个任务感受差异。

领域四：提示工程与结构化输出（占比 20%）

两个字贯穿全领域：具体。

"保守一点"不会提高精确度。"只报告高置信度发现"不会减少误报。真正有效的做法是：精确定义哪些问题要报告、哪些要跳过，并为每个严重等级提供具体的代码示例。这一点我在实际项目中感受极深，模糊的指令就会得到模糊的输出。

Few-shot 是杠杆最高的技术。2-4 个针对模糊场景的目标示例，要展示为什么选 A 而不是 B 的推理过程，而不是只给"正确答案"。

结构化输出方面，tool_use 配合 JSON 模式能消除语法错误，但消除不了语义错误。模式设计的几个要点：

  • 源数据可能缺失时用可空字段（防止模型编造值）
  • 枚举里加 "unclear" 选项
  • 留 "other" + 详细字符串的兜底

消息批处理 API 也值得了解：费用省 50%，最长 24 小时处理，没有延迟 SLA，不支持多轮工具调用。批量处理用于隔夜报告之类的场景，阻塞性的合并前检查就别用了。

实践建议：构建一个用 tool_use 的提取管道，包含必填、可选和可空字段，加上验证重试循环，再通过批处理 API 跑一批任务，按 custom_id 处理失败请求。

领域五：上下文管理与可靠性（占比 15%）

权重最小，但这里出问题会产生连锁反应。

渐进式摘要会吞掉关键数据。修复方法是维护一个持久的"案例事实"块，包含金额、日期、订单号等提取信息，永不被摘要覆盖，每次提示都带上。

"迷失在中间"效应：模型处理长文本时，埋在中间的关键信息容易被忽略。解决办法简单粗暴——把关键摘要放在开头。

升级触发条件方面，三个靠谱的：客户要求人工（立即执行）、遇到政策空白、无法推进。两个不靠谱的（考试会故意诱导你选）：情绪分析和自我报告的置信度分数。

错误传播的正确方式：返回结构化上下文（故障类型、尝试的查询、部分结果、替代方案）。反模式是静默吞掉错误或者因为单点故障就终止整个工作流。

实践建议：搭一个带两个子代理的协调器，模拟超时场景，验证协调器能拿到结构化错误上下文并用部分结果继续执行。再用相互矛盾的信息源测试它的处理逻辑。

写在最后

回过头看，这套考试大纲其实就是一份非常系统的 Claude 生产级应用开发指南。对于独立开发者来说，你不需要那个认证标签，但你需要这套知识体系。Claude Code + Agent SDK + MCP 这个组合，已经足够一个人撑起从开发到部署的完整链路。

建议按领域权重分配学习时间，从领域一的代理编排开始，每个领域都动手做一个小项目。纸上得来终觉浅，这些东西不写代码跑一遍是真的理解不了。