Claude Certified Architect Foundations 认证完全指南（上）：理论篇

2026-05-29

前言
谁适合考这个认证？
考试格式
五大考试领域
需要理解的考试场景
第一部分：理论基础知识
推荐阅读的官方文档

前言

AI 工具早已不再是简单的问答机器人。如今，人们正在使用 Claude 构建完整的应用程序、编码代理、自动化系统、研究流水线、客户支持代理和开发者工具。

这时，Claude Certified Architect Foundations 认证就显得尤为重要。

这项认证旨在证明你不仅会写基础提示词，更懂得如何用 Claude 构建真实世界中的解决方案。它关注的是——在使用 Claude 构建系统时，你能否做出正确的技术决策。

简单来说，这项考试检验的是你对 Claude 生态系统基础原理的理解。

它涵盖 Claude Code、Claude Agent SDK、Claude API 和 Model Context Protocol（MCP）等核心领域。这些都是开发者用 Claude 构建生产级应用时所依赖的基础构件。

但这项认证不仅仅是背诵定义。考试基于真实场景构建。例如，你需要理解 Claude 如何在客户支持中发挥作用、多个 Agent 如何在研究系统中协同工作、Claude Code 如何接入 CI/CD 工作流、如何创建开发者生产力工具、以及 Claude 如何从杂乱文档中提取有用的结构化数据。

这也是为什么这项认证对开发者、AI 构建者、解决方案架构师以及任何希望在真实项目中深入使用 Claude 的人来说都非常有价值。

在本指南中，我将以简单易懂的方式逐步解释基础知识。目标不是把事情搞复杂，而是帮助你理解真正重要的内容——这些概念如何相互关联、以及如何更有信心地准备认证考试。

谁适合考这个认证？

Claude Certified Architect Foundations 认证并不只面向会用 Claude 聊天的人。

它主要面向构建者。

理想的考生是那些希望使用 Claude 设计、构建和交付真实生产应用的人，包括解决方案架构师、AI 工程师、后端开发者、自动化构建者、开发者工具创建者，或在真实系统中使用 Claude 的任何人。

简单来说，这个认证是为想要理解 Claude 如何融入实际软件架构的人设计的。

你不需要有 10 年 AI 经验，但最好有一些实践经验。大约 6 个月使用 Claude 工具和流程的实操经验会让备考轻松很多。

在准备考试之前，你应该熟悉 Claude 生态系统的核心部分：

理解 Claude Agent SDK 的工作原理，特别是构建 Agent 系统时，一个主 Agent 如何将任务委派给更小的子 Agent
了解工具如何连接、生命周期钩子如何工作、多个 Agent 如何协同而不产生混乱
对 Claude Code 有基本了解，包括 CLAUDE.md、MCP 服务器、Agent Skills 和计划模式
理解 Model Context Protocol（MCP）——可以把它看作 Claude 与外部系统之间的桥梁
掌握提示工程，但不仅仅是”写更好的提示”，而是设计能产生可靠输出的提示
了解上下文窗口的工作原理——Claude 可以处理长文档，但实际项目中你仍需决定传递哪些信息、哪些需要总结、上下文如何在 Agent 之间流转
了解 CI/CD 流水线的基本知识
理解可靠性——真实的 AI 系统可能失败、误解或输出不完整，因此考试也会检验你是否知道如何设计回退处理、人工审核步骤、升级路径和更安全的工作流

考试格式

考试采用选择题形式。

每道题提供 4 个选项，只有 1 个正确。

评分范围从 100 到 1000，及格线为 720 分。

好消息是猜题不扣分，所以永远不要留空。即使不确定，也要选一个最可能的答案。

考试基于场景。题目不是问定义，而是给出实际情境，让你选择最合理的方案。

例如，题目可能描述一个客户支持 Agent、一个多 Agent 研究系统、一个 Claude Code 工作流、或一个文档提取流水线。你需要选出最合适的架构或方法。

考试从 8 种场景类型中随机抽取 4 种，所以不要只聚焦于某一个领域，需要对所有主要话题都有均衡的理解。

五大考试领域

认证分为 5 个主要领域：

1. Agent 架构与编排（27%）

权重最高，意味着你必须理解 Agent 如何设计、任务如何委派、多个 Agent 如何通信、Agent 工作流如何构建。

2. 工具设计与 MCP 集成（18%）

关注 Claude 如何通过 MCP 与外部工具、API、资源和后端系统连接。

3. Claude Code 配置与工作流（20%）

检验你对 Claude Code、项目指令、计划模式、Agent Skills 和开发工作流的理解。

4. 提示工程与结构化输出（20%）

关于编写可靠提示、设计输出格式、使用 JSON Schema、添加示例、让 Claude 产生一致的结果。

5. 上下文管理与可靠性（15%）

包括处理长文档、管理 Agent 间的上下文、避免不必要的 Token 消耗、设计回退系统、以及在必要时加入人工审核。

总而言之，这项考试不仅仅是了解 Claude 的功能。它关乎如何在真实系统中负责任地使用 Claude。因此，备考重点不应是死记硬背术语，而是理解如何做出更好的架构决策。

需要理解的考试场景

场景 1：客户支持 Agent

想象你正在构建一个 AI 支持系统，帮助用户处理退货、账单纠纷、订单问题、账户问题和退款请求。Claude 不仅回复文字，还可以使用工具。

例如，Agent 可能需要：

获取客户详情
查找订单
检查退款资格
处理退款
升级到人工客服

这时 Claude Agent SDK 和 MCP 工具就显得至关重要。

这类系统的目标不仅仅是快速回答，而是正确解决大多数用户问题，同时知道何时该停下来。如果问题简单，Agent 可以直接处理；但如果案件敏感、混乱或高风险，就应该升级到人工。

核心要点：一个好的支持 Agent 应该既能提供帮助，也知道自己的极限。

场景 2：使用 Claude Code 生成代码

另一个重要场景是使用 Claude Code 加速软件开发。Claude 可以帮助编写代码、重构旧代码、调试错误、生成文档、或解释不熟悉的代码库。

考试可能会检验你是否知道如何正确配置 Claude Code。例如，你应该理解 CLAUDE.md 的作用——它帮助 Claude 理解项目规则、编码风格、架构决策、测试指令等重要指南。

你还应该了解自定义斜杠命令和计划模式的使用时机。当任务复杂、不希望 Claude 立即修改文件时，计划模式非常有用。Claude 会先思考步骤、创建计划，然后再安全地推进。

核心要点：Claude Code 在理解项目上下文时最强大，盲目工作时则不然。

场景 3：多 Agent 研究系统

一个主协调 Agent 管理多个小型专业 Agent：

一个 Agent 搜索网页
一个 Agent 阅读文档
一个 Agent 分析信息
一个 Agent 撰写最终报告
一个 Agent 检查引用和完整性

这种架构适用于任务太大或太广、单一 Agent 无法干净处理的情况。

但多 Agent 系统也会带来新挑战：协调者必须知道将哪个任务分配给哪个 Agent，系统需要仔细管理上下文、避免重复工作、确保最终报告完整且引用正确。

核心要点：仅在专业化能改善结果时才使用多 Agent，而不是因为”多 Agent”听起来更高级。

场景 4：开发者生产力工具

Agent 可以帮助工程师探索新代码库、理解文件结构、生成模板代码、发现 bug、或自动化重复任务。

Claude 可能使用内置工具（如 Read、Bash、Grep、Glob），也可能通过 MCP 服务器连接外部系统。关键在于安全和控制——生产力 Agent 非常有用，但不应随意修改文件、运行危险命令、或不做检查就做出假设。

核心要点：开发者 Agent 应该强大，但其行为必须可控且可解释。

场景 5：Claude Code 的 CI/CD 集成

当有人提交 Pull Request 时，Claude 可以自动审查代码、提出改进建议、生成测试或留下反馈。

但这有一个大问题：误报。如果 Claude 给出太多不必要的警告，开发者会失去信任。因此提示词和工作流必须精心设计。

好的 CI/CD 集成应关注有用的反馈、真实的风险、缺失的测试、安全问题、有问题的逻辑或不清晰的代码，而不是像一个吵闹的审查者一样对每件事都发表评论。

核心要点：在 CI/CD 中，Claude 应该提升开发者的信心，而不是制造额外的噪音。

场景 6：结构化数据提取

从混乱的非结构化文档中提取干净、可用的数据。例如，从发票、合同、报告、简历、支持工单或手写表单中提取信息。

在生产系统中，仅说”提取数据”是不够的。输出必须可靠，这就是 JSON Schema 重要的原因。Schema 告诉 Claude 最终输出应该遵循什么结构。

系统还应处理边界情况，如缺失值、格式不清、重复条目或不完整文档。

核心要点：结构化提取不仅仅是得到一个答案，而是得到一个你的应用程序可以信任的格式的答案。

场景 7：对话式 AI 架构模式

构建多轮对话系统。用户可能改变主意、提供不完整信息、提出模糊问题、或说出与先前指令矛盾的内容。

系统必须处理：上下文窗口管理、指令持久化、记忆策略、安全的工具执行、模糊的用户请求、何时使用子 Agent、何时使用计划模式、何时升级到人工、何时验证结构化输出、何时保留上下文、何时保持系统简单。

最好的准备不是死记硬背，而是理解每个架构决策背后的目的。

第一部分：理论基础知识

1. Claude API — 模型交互基础

API 请求结构

Claude API 采用请求-响应模型。你的应用向 Claude 发送请求，Claude 根据模型、指令、对话历史和可用工具返回响应。

重要字段：

model — 选择使用哪个 Claude 模型
max_tokens — 控制 Claude 响应的最大长度
system — 系统提示词，定义 Claude 的主要行为、角色、规则和指令
messages — 对话历史，每次请求需发送完整的上下文
tools — Claude 可用的外部工具定义
tool_choice — 控制 Claude 如何选择工具

消息角色

user — 用户消息
assistant — Claude 的先前响应
tool — 工具调用返回的结果

非常重要：每个 API 请求都是独立的，Claude 不会自动记住之前的请求。

stop_reason 字段

end_turn — Claude 已完成响应
tool_use — Claude 想调用工具
max_tokens — 达到 Token 限制
stop_sequence — 遇到定义的停止序列

对于 Agent 系统，最重要的值是 tool_use 和 end_turn。

上下文窗口

上下文窗口包含：系统提示词、完整消息历史、工具定义、工具结果。

需要了解的上下文问题：

Lost-in-the-middle 效应 — 长输入时，模型对开头和末尾的信息处理更好，可能遗漏中间的重要细节
工具结果累积 — 每次工具调用都会向上下文增加数据，工具输出应当精简
渐进式总结 — 长历史被压缩成总结时，数字、百分比、日期等精确值可能变得模糊

2. 工具与 tool_use

什么是 tool_use？

tool_use 是 Claude 使用外部工具的过程。Claude 不会直接运行代码，而是创建一个结构化请求，说明应该使用哪个工具以及传递什么参数。你的应用负责执行实际工具并返回结果。

工具定义

每个工具使用 JSON Schema 定义。最重要的部分是描述（description） ——Claude 主要通过读取描述来选择工具。描述应说明工具的功能、输入格式、边界条件以及何时使用。

tool_choice 参数

{"type": "auto"} — Claude 自行决定是否调用工具
{"type": "any"} — Claude 必须调用至少一个可用工具
{"type": "tool", "name": "xxx"} — Claude 必须调用指定工具

JSON Schema 结构化输出

使用 JSON Schema 可以获得干净、有效的 JSON 输出，而不是松散的文本。但要注意：JSON Schema 保证结构，不保证真实性——Claude 仍可能返回错误值。

Schema 设计规则：

只在字段总是存在时才标记为 required
使用 nullable 字段（如 ["string", "null"]）应对信息可能缺失的情况
枚举类型添加 “other” 选项覆盖未列出的情况
添加 “unclear” 选项让模型在不确认时诚实回答

语法错误 vs 语义错误

语法错误 — 输出格式被破坏（JSON 无效、括号缺失）
语义错误 — 格式正确但含义错误（总额对不上、信息放错字段）

3. Claude Agent SDK — 构建 Agent 系统

Agent 循环

Agent 循环是自主任务执行的核心模式。Claude 可以多步完成任务：使用工具、读取结果、决定下一步。

如果 stop_reason 是 tool_use，继续循环；如果是 end_turn，任务完成。

AgentDefinition 配置

定义 Agent 的名称、目的、指令和可用工具。应遵循最小权限原则——Agent 只获得它实际需要的工具。

Hub-and-Spoke：协调者与子 Agent

一个主协调 Agent 管理多个专业子 Agent。关键点：

子 Agent 有隔离的上下文，不会自动接收协调者的完整对话历史
子 Agent 在不同调用之间不共享记忆
所有通信流经协调者，使系统更易观察、调试和控制

Task 工具

使用 Task 工具创建子 Agent。上下文必须显式传递——不好的写法：”分析文档”；好的写法：”分析以下文档：[文档全文]”。

生命周期钩子（Hooks）

PreToolUse — 在工具执行前运行，可用于阻止违规操作
PostToolUse — 在工具执行后运行，可用于清理或转换结果

钩子是确定性的——如果规则写在代码中，每次都会执行。而提示词指令只是引导，模型不一定每次都完美遵循。

简单规则：如果失败会造成财务、法律或安全风险，使用钩子而不是仅依赖提示词。

4. Model Context Protocol（MCP）

什么是 MCP？

MCP 是一种开放协议，帮助 Claude 连接外部系统。它定义了三类资源：

Tools — Agent 可调用的功能（CRUD、API 调用、命令执行等）
Resources — Agent 可读取的上下文数据（文档、数据库 Schema 等）
Prompts — 常见任务的预定义提示模板

MCP 服务器

MCP 服务器遵循 MCP 协议，向 Claude 提供工具或资源。多个 MCP 服务器连接后，所有工具可同时可用。

可以在项目级（.mcp.json，团队共享）或用户级（~/.claude.json，个人使用）配置。

isError 标志

当 MCP 工具失败时，应返回 isError: true，并提供清晰、结构化、可操作的建议——告诉 Agent 发生了什么、是否可以重试、下一步该怎么做。

5. Claude Code — 配置与工作流

CLAUDE.md 层级

用户级：~/.claude/CLAUDE.md（个人偏好）
项目级：.claude/CLAUDE.md 或根目录 CLAUDE.md（团队共享）
目录级：子目录中的 CLAUDE.md（特定规则）

.claude/rules/ 路径规则

通过 YAML frontmatter 中的 paths 字段，让 Claude 只在编辑匹配文件时加载特定规则，节省上下文。

Skills 技能

Skills 是高级斜杠命令，使用 SKILL.md 配置。重要 frontmatter 参数：

context: fork — 在隔离子 Agent 中运行
allowed-tools — 限制技能可用的工具
argument-hint — 帮助提示

计划模式 vs 直接执行

计划模式适用于：跨多文件的大范围更改、多种可能的方案、架构建决策、不熟悉的代码库、库迁移。

直接执行适用于：单文件修复、添加简单校验、理解明确的变更。

/compact 命令

压缩当前上下文，为上下文窗口腾出空间。注意：总结过程中精确值可能丢失。

/memory 命令

管理跨会话的记忆，保存项目知识。

CI/CD 集成

使用 -p 或 --print 标志在非交互模式下运行。使用 --output-format json 和 --json-schema 生成结构化输出。

代码审查时，使用独立的 Claude 实例——因为生成代码的同一个会话不太可能质疑自己的决策。

6. 提示工程 — 高级技巧

Few-Shot 提示

添加 2-4 个输入输出示例，展示 Claude 的预期行为。示例比单纯文字指令更有效。

显式标准 vs 模糊指令

好的提示工程不仅是告诉 Claude 做什么，还要明确定义什么算问题、什么不算。

例如，不要说”保守一点，只报告高置信度的发现”，而要说”仅当满足以下条件之一时才标记：……”。

提示链

将大任务分解为小的、聚焦的步骤，而不是让 Claude 一次完成所有事情。