Skip to content

Claude Certified Architect Foundations 考試完整指南

2026年8月18日 1 分鐘
TL;DR Claude 官方架構師認證(CCAR-F)的完整備考指南:五大領域權重 27/18/20/20/15、六大考試情境抽四個、常見反模式與實際演練建議。官方規格為 60 題 / 120 分鐘 / $125 / 效期 12 個月 / 及格 720,報考限 Claude Partner Network 成員,準時續期免費且非監考。
目錄
  1. 考試結構
    1. 誰能報考、怎麼報
    2. 12 個月到期怎麼辦
  2. Domain 1 — Agentic Architecture & Orchestration(27%)
    1. Agentic Loop 的正確終止條件
    2. Multi-Agent 的 Hub-and-Spoke 架構
    3. 工作流程強制執行 vs. Prompt 指示
    4. Session 管理
  3. Domain 2 — Tool Design & MCP Integration(18%)
    1. 工具描述決定工具選擇可靠性
    2. 結構化錯誤回應
    3. 工具數量影響選擇品質
    4. MCP Server 配置
  4. Domain 3 — Claude Code Configuration & Workflows(20%)
    1. CLAUDE.md 層級結構
    2. Slash Command 與 Skills
    3. Plan Mode vs. Direct Execution
    4. CI/CD 整合
  5. Domain 4 — Prompt Engineering & Structured Output(20%)
    1. 明確標準比模糊指示有效
    2. Few-Shot Examples 的用途
    3. 結構化輸出用 tool_use
    4. Validation-Retry Loop
    5. Message Batches API
  6. Domain 5 — Context Management & Reliability(15%)
    1. 避免 Lost-in-the-Middle
    2. 保留關鍵事實,不要摘要它們
    3. Provenance(來源可溯)
    4. Escalation 的正確觸發條件
    5. 大 Codebase 探索的 Context 管理
  7. 常見考題陷阱
  8. 備考策略
  9. 與 3 月版的差異
  10. 參考資料

Claude Certified Architect — Foundations(CCAR-F)測試的是你對 agentic 系統的實際設計能力。考題以情境為單位,要求你在具體的生產場景中做出正確的架構決策。這篇整理考試的所有重點領域、常見陷阱,以及最有效的準備方式。

本文內容依官方 **CCAR-F Exam Guide(Version 1.0, Effective July 2026)**逐節核對。前身是 2026 年 3 月的同名文章,當時 Anthropic 只有這一張認證;這次全面翻新後改以新文發佈,舊網址 /posts/ai/2026-03-20-claude-certified-architect-foundations-guide 已轉向本頁。Anthropic 現在共有四張認證,整體規格與選擇建議見 2026 年工程師 AI 證照有哪些

說明性質:作者未報考本考試,內容全部來自官方 exam guide 與認證頁,不含應考實錄,也不含任何考古題。

考試結構

官方 exam guide 的「Exam Details at a Glance」寫得很完整:

項目內容
考試代碼CCAR-F
題數60 題
題型單選與複選混合,每題會標明要選幾個答案
結構六個情境題庫隨機抽四個
時間120 分鐘
費用$125 USD(結帳金額會反映你所屬 partner tier 的折扣)
效期12 個月,自取得證書日起算
及格量尺分數 720(範圍 100–1,000)
形式線上監考或 Pearson 考場二選一

五大領域與權重:

領域比重
Domain 1: Agentic Architecture & Orchestration27%
Domain 2: Tool Design & MCP Integration18%
Domain 3: Claude Code Configuration & Workflows20%
Domain 4: Prompt Engineering & Structured Output20%
Domain 5: Context Management & Reliability15%

計分方式是標準參照(criterion-referenced):跟固定標準比,不是跟其他考生比。及格線由專家標準設定研究決定,成績單會列出各領域的答對百分比——沒過的話知道要補哪一塊。官方 guide 沒有說明答錯是否倒扣,別把「答錯不扣分」當成已知。

六大情境(考試隨機抽四個):

  1. Customer Support Resolution Agent — 用 Claude Agent SDK 處理退款、帳戶問題、客服升級
  2. Code Generation with Claude Code — 團隊開發流程中整合 Claude Code
  3. Multi-Agent Research System — 多個 subagent 協作做研究報告
  4. Developer Productivity with Claude — 幫工程師探索陌生 codebase
  5. Claude Code for CI/CD — 自動化 code review 與 PR 回饋
  6. Structured Data Extraction — 從非結構化文件提取 JSON 資料

誰能報考、怎麼報

這張不是任何人都能考。 Pearson VUE 官方頁寫明「Certification is open to organizations in the Claude Partner Network and counts toward partner program standing」——報名走 Anthropic Partner Academy 結帳,再到 Pearson VUE 排考期。考前 24 小時內取消或改期會沒收考試費,考當天要出示與報名姓名完全一致的政府核發附照片證件。

沒過的話有間隔規定:第一次後等 14 天,第二次後 30 天,第三次後 90 天,同一張考試在任何 12 個月內最多 4 次

12 個月到期怎麼辦

效期只有一年,但準時續期是免費的:在到期前於 Partner Academy 完成一份非監考的更新評量即可,不用重考正式考試。過期就沒有這條路 —— 官方 guide 寫得很直白,證照失效後要恢復必須付全額重考。另外如果考試內容有重大改版,Anthropic 可以要求持證者直接重考而不是做更新評量。

Domain 1 — Agentic Architecture & Orchestration(27%)

這個領域考的是多代理系統的設計,重點不只是「呼叫 subagent」,而是「怎麼設計可靠的協調流程」。

Agentic Loop 的正確終止條件

最常考的反模式:不要用解析自然語言文字來判斷 loop 是否結束,應該靠 stop_reason

while True:
    response = client.messages.create(...)

    if response.stop_reason == "end_turn":
        break  # ✅ 正確:靠 stop_reason 終止
    elif response.stop_reason == "tool_use":
        # 執行工具,把結果加回 conversation history
        tool_results = execute_tools(response.content)
        messages.append({"role": "assistant", "content": response.content})
        messages.append({"role": "user", "content": tool_results})

反模式:

  • 解析 assistant 回應文字判斷「是否完成」
  • 用固定迭代次數作為主要終止條件
  • 不把 tool result 加回 conversation history

Multi-Agent 的 Hub-and-Spoke 架構

coordinator 負責所有 subagent 的通訊、錯誤處理、資訊路由。subagent 不會自動繼承 coordinator 的對話歷史,必須在 prompt 裡明確傳入所需的上下文。

要在 coordinator 的 allowedTools 加上 "Task",才能呼叫 subagent:

coordinator = Agent(
    allowed_tools=["Task", "search_web"],  # 必須包含 Task
    system_prompt="Analyze the query and delegate to appropriate subagents..."
)

平行執行 subagent:在單一 coordinator response 中發出多個 Task tool call,而不是分多個 turn。

工作流程強制執行 vs. Prompt 指示

這是這個 domain 最重要的概念:當某個工具呼叫順序是業務邏輯必要條件時,用程式碼強制執行,不要只靠 prompt

例如:必須先驗證客戶身份才能處理退款。如果只在 prompt 說「請先呼叫 get_customer」,有一定機率 Claude 會跳過這步。應該用程式碼在 lookup_orderprocess_refund 的 hook 裡檢查 get_customer 是否已執行。

Session 管理

  • --resume <session-name>:繼續命名 session
  • fork_session:從同一個分析基礎分出兩條探索路徑,互不影響
  • session resumption 適合「大部分 context 還有效」;如果 tool result 已過時,改用新 session + 注入摘要

Domain 2 — Tool Design & MCP Integration(18%)

工具描述決定工具選擇可靠性

LLM 選擇工具的主要依據是 description。描述太簡略(如 "Retrieves customer information")會導致工具被錯誤呼叫。

好的工具描述包含:

  • 這個工具做什麼(具體,不模糊)
  • 期望的輸入格式與範例
  • 邊界條件(什麼時候用這個 vs. 用另一個)
  • 輸出格式說明
{
  "name": "lookup_order",
  "description": (
    "Look up order details using an order ID (format: ORD-XXXXXX) or order number. "
    "Use this when the customer provides an order reference. "
    "Do NOT use this for customer account lookup — use get_customer for that. "
    "Returns order status, items, shipping info, and timestamps."
  )
}

結構化錯誤回應

工具的錯誤回應要提供足夠資訊讓 agent 做出正確的恢復決策:

# ❌ 差的錯誤回應
{"error": "Operation failed"}

# ✅ 好的錯誤回應
{
  "isError": True,
  "errorCategory": "transient",  # transient / validation / permission / business
  "isRetryable": True,
  "description": "Payment service timeout after 3 attempts",
  "attemptedAction": "process_refund for order ORD-12345"
}

transient 錯誤可以 retry;business 錯誤(如退款超過政策上限)不應 retry,而應該升級到人工。

工具數量影響選擇品質

給一個 agent 18 個工具,比給 4-5 個相關工具的選擇可靠性低很多。原則:每個 subagent 只拿它角色需要的工具。synthesis agent 不需要 web search 工具。

MCP Server 配置

層級位置用途
專案層級.mcp.json團隊共用的工具(進版控)
使用者層級~/.claude.json個人實驗性工具

credential 用環境變數注入,不要寫死:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_TOKEN": "${GITHUB_TOKEN}"
      }
    }
  }
}

MCP Resources vs. MCP Tools:Resources 適合暴露內容目錄(issue 清單、文件索引、schema);Tools 適合執行動作。善用 Resources 可以減少不必要的探索性工具呼叫。


Domain 3 — Claude Code Configuration & Workflows(20%)

CLAUDE.md 層級結構

~/.claude/CLAUDE.md            # 使用者層級(不進版控,不共享給團隊)
CLAUDE.md / .claude/CLAUDE.md  # 專案層級(版控,全團隊共用)
src/api/CLAUDE.md              # 目錄層級(只有在該目錄工作時載入)

常見錯誤:把應該給整個團隊的規範放在 ~/.claude/CLAUDE.md,導致新成員沒有收到。

@import 保持 CLAUDE.md 模組化:

@import ./docs/api-conventions.md
@import ./docs/testing-standards.md

或用 .claude/rules/ 目錄加 YAML frontmatter 做路徑條件式載入:

---
paths: ["src/api/**/*"]
---
# API 層規範
所有 handler 必須用 async/await,錯誤統一用 AppError class...

用 glob pattern 的優點:跨目錄套用規範(例如所有 **/*.test.tsx 都套用同一份測試規範,不管在哪個子目錄)。

Slash Command 與 Skills

Commands.claude/commands/):純 prompt 模板,適合固定的任務流程。

Skills.claude/skills/):有 frontmatter 配置,功能更強:

---
context: fork          # 在隔離的子 agent 跑,不污染主 session
allowed-tools: Read,Grep,Glob  # 限制可用工具
argument-hint: "PR number to review"
---

Review PR #$ARGUMENTS...

context: fork 是很重要的選項:分析 codebase 這類會產生大量 verbose output 的任務,用 fork 跑完後只把摘要回傳給主 session。

Plan Mode vs. Direct Execution

用 Plan Mode用 Direct Execution
大規模架構變更(跨 45+ 個檔案)單一檔案 bug fix
有多種可行方案需要評估已知解法、清楚範圍
Library migration加一個 input validation
微服務重構依照 stack trace 修一個錯誤

CI/CD 整合

-p flag 跑非互動模式,加 --output-format json 輸出機器可讀的結果:

- name: Code Review
  run: |
    claude -p "Review the changed files for bugs and security issues.
    Previous review findings: $(cat .claude/prior-review.json)
    Only report new or unaddressed issues." \
    --output-format json \
    --json-schema review-schema.json > review-results.json

注意:讓同一個 Claude session 審查它自己寫的程式碼效果較差——它會保留生成時的推理 context,比較不會質疑自己的決定。用獨立的 review instance。


Domain 4 — Prompt Engineering & Structured Output(20%)

明確標準比模糊指示有效

「只回報高信心的問題」或「保守一點」不會降低 false positive 率。需要明確定義:

Review criteria:
- REPORT: Logic errors, null pointer dereferences, SQL injection, missing auth checks
- SKIP: Minor style issues, local variable naming, comment formatting
- REPORT as HIGH: Any issue that could lead to data loss or security breach
- REPORT as MEDIUM: Logic errors that affect correctness but not security

Few-Shot Examples 的用途

Few-shot 最有效的場景:

  • 工具選擇在模稜兩可的情境下容易出錯 → 加範例示範正確選擇
  • 想要特定輸出格式 → 給 2-3 個完整範例比描述格式更有效
  • 文件結構差異大(有些用內文引用、有些用參考書目)→ 每種結構給一個範例

結構化輸出用 tool_use

最可靠的結構化輸出方式:用 tool_use + JSON schema,而非要求 Claude 輸出 JSON 字串。

tools = [{
    "name": "extract_invoice",
    "description": "Extract structured data from invoice",
    "input_schema": {
        "type": "object",
        "properties": {
            "invoice_number": {"type": "string"},
            "total_amount": {"type": "number"},
            "line_items": {
                "type": "array",
                "items": {
                    "type": "object",
                    "properties": {
                        "description": {"type": "string"},
                        "amount": {"type": ["number", "null"]}  # nullable
                    }
                }
            },
            "payment_status": {
                "type": "string",
                "enum": ["paid", "pending", "overdue", "other"],
            },
            "payment_status_detail": {  # 搭配 "other" 用
                "type": ["string", "null"]
            }
        },
        "required": ["invoice_number", "total_amount"]
    }
}]

response = client.messages.create(
    tools=tools,
    tool_choice={"type": "any"}  # 保證 Claude 一定會呼叫工具
)

tool_choice 的三個選項:

  • "auto":Claude 自己決定要不要用工具(可能回傳純文字)
  • "any":一定要呼叫某個工具,但自己選哪個
  • {"type": "tool", "name": "extract_metadata"}:強制呼叫特定工具

重要: tool_use 消除 JSON 語法錯誤,但不消除語意錯誤(例如 line items 加總不等於 total)。語意驗證要另外實作。

Validation-Retry Loop

for attempt in range(3):
    result = extract_with_claude(document)
    errors = validate(result)

    if not errors:
        break

    # 把具體錯誤告訴 Claude,讓它修正
    document = f"""
    Original document: {document}
    Previous extraction: {result}
    Validation errors: {errors}
    Please fix these specific issues.
    """

注意:如果資訊根本不在文件裡,retry 不會有幫助。先判斷是「格式錯誤」還是「資料不存在」。

Message Batches API

50% 成本節省,但最多 24 小時處理時間,沒有延遲 SLA。

適合不適合
隔夜批次報告Pre-merge check(開發者在等結果)
每週技術債分析任何需要 blocking 的流程
大量文件批次處理需要 multi-turn tool calling

Domain 5 — Context Management & Reliability(15%)

避免 Lost-in-the-Middle

模型對輸入的開頭和結尾注意力最高,中間的容易被忽略。整合多個 subagent 結果時:

  • 把關鍵摘要放在最前面
  • 用明確的 section header 分隔各來源的詳細內容
  • 不要把 15 個 subagent 的完整 output 直接串接

保留關鍵事實,不要摘要它們

客服情境中,日期、金額、訂單號碼、狀態這類「事實性資料」不應該被 summarize 掉:

# 在每個 prompt 裡附上 structured facts block
case_facts = {
    "customer_id": "C-78901",
    "order_id": "ORD-45623",
    "refund_amount": 89.99,
    "order_date": "2026-02-14",
    "stated_issue": "item never arrived"
}

prompt = f"""
Case Facts (do not summarize these):
{json.dumps(case_facts, indent=2)}

Conversation summary:
{compressed_history}

Customer: {latest_message}
"""

Provenance(來源可溯)

multi-source synthesis 最重要的設計原則:每個 claim 都要附帶它的來源

subagent 的輸出格式應該是:

{
  "findings": [
    {
      "claim": "市場規模預計在 2026 年達到 $2.3B",
      "source_url": "https://example-report.com/2025",
      "source_name": "Industry Report 2025",
      "publication_date": "2025-11-01",
      "excerpt": "The market is projected to reach $2.3B by 2026..."
    }
  ]
}

兩個來源的數字衝突時,不要選一個,兩個都保留並標注來源,讓報告讀者自己判斷。

Escalation 的正確觸發條件

應該升級不應該升級
客戶明確要求真人案件複雜(但有解法)
政策沒有涵蓋的情境客戶語氣不好
無法取得進展Claude 自評「信心不高」

客戶要求真人 → 直接升級,不要先試圖自己解決。政策例外(如跨品牌比價,但政策只寫了自家網站)→ 升級。

大 Codebase 探索的 Context 管理

長 session 的 context 會「退化」:Claude 開始給出「根據一般 patterns」這類模糊回應,而不是根據你的 codebase。

解法:

  • /compact 壓縮 context(Claude Code 指令)
  • 把關鍵發現存到 scratchpad 檔案,下次查詢前先載入
  • 用 subagent 做探索,只把摘要回傳主 session

crash recovery 用 manifest 模式:每個 agent 把自己的狀態 export 到固定路徑,coordinator 重啟時載入 manifest 繼續。


常見考題陷阱

這幾個概念在 sample questions 裡反覆出現:

「先改 prompt」不一定是正確答案。 當業務邏輯需要 100% 確保某個順序時,答案是「用程式碼強制執行」,不是「加更多指示到 prompt」。

工具描述是工具選擇的根本。 工具選錯的 root cause 通常是描述不夠清楚,而不是需要一個 routing classifier。

Message Batches API 不適合 blocking workflow。 這個選項幾乎永遠是錯的,只要情境裡有人在等待結果。

Self-review 不如獨立 review instance。 讓同個 session 審查自己的輸出效果差,因為它記得自己的推理過程。

不是所有複雜情況都應該升級。 升級的觸發是客戶明確要求、政策無法涵蓋、或無法取得進展,不是「感覺很複雜」。


備考策略

官方指定的免費課程有七門,全部在 Anthropic Academy 上、對應本文五個 domain:AI Fluency: Framework & Foundations、Claude 101、Building with the Claude API、Claude with Amazon Bedrock、Claude on Google Cloud、Introduction to Model Context Protocol、Claude Code in Action。前兩門是概念打底,後五門直接對應 Domain 1 到 Domain 5。

但最有效的準備是動手做,不是把課上完。 官方考試指南列了四個練習題,每個都直接對應一個真實的 domain:

  1. Build a Multi-Tool Agent with Escalation Logic:做完你就懂 agentic loop、hook、結構化錯誤處理
  2. Configure Claude Code for a Team Development Workflow:CLAUDE.md hierarchy、path-scoped rules、skills
  3. Build a Structured Data Extraction Pipeline:tool_use + JSON schema、validation retry、batch processing
  4. Design and Debug a Multi-Agent Research Pipeline:coordinator 設計、parallel subagent、provenance tracking

快速確認清單:

  • 能用 stop_reason 正確實作 agentic loop,知道哪些是反模式
  • 知道 subagent 需要明確傳入 context,不會自動繼承
  • 能寫出清楚區分相似工具的 tool description
  • 能設計帶有 errorCategoryisRetryable 的結構化錯誤回應
  • 能設定 .mcp.json 用環境變數管理 credential
  • 能說明 CLAUDE.md 三層層級的差異與用途
  • 知道 context: fork 是什麼、什麼時候用
  • 能分辨 plan mode vs direct execution 的適用情境
  • 知道 tool_choice: "auto" / "any" / forced 的差異
  • 能說明 Message Batches API 的限制與適用場景
  • 知道 escalation 的正確觸發條件(不是「感覺複雜」)
  • 能設計保留 provenance 的 multi-source synthesis 結構

與 3 月版的差異

這篇的前身寫於 2026 年 3 月。依官方 CCAR-F Exam Guide(Version 1.0, Effective July 2026)全文重新核對後:五大領域權重(27/18/20/20/15)、及格線 720、六情境抽四個都與原文一致,不需更動。修正一處:原文寫「考題全部是選擇題,每題一個正確答案」,官方寫的是單選與複選混合、每題會標明選幾個。移除一處:原文的「答錯不扣分」在官方 guide 裡找不到依據。補上:費用 $125、效期 12 個月、60 題 / 120 分鐘、標準參照計分與各領域答對率、Claude Partner Network 報考門檻、重考間隔(14 / 30 / 90 天、12 個月內 4 次)、免費非監考續期與過期後須全額重考、官方七門免費課程。另加開場說明本文與四張認證現況的關係。

參考資料