- Kỳ thi CCA Foundations (CCA-F) kiểm tra năng lực ra quyết định và đánh đổi kiến trúc (tradeoffs) của Solution Architect khi xây dựng giải pháp thực tế với Claude.
- Cốt lõi của việc ôn tập nằm ở 12 quy luật phán đoán kiến trúc giúp loại bỏ các phương án nhiễu (distractors) được thiết kế tinh vi trong đề thi.
- Tích hợp 4 hệ thống mẫu thực tế (Customer Support, Developer Workflow, Structured Extraction, Multi-Agent Research) kết nối toàn diện kiến thức 5 domain.
TL;DR — Kỳ thi Claude Certified Architect – Foundations (CCA-F) của Anthropic kiểm tra phán đoán kiến trúc thực tế chứ không hỏi lý thuyết suông. Để ôn thi hiệu quả và bảo đảm điểm số tối ưu, tôi đúc kết 12 quy luật phán đoán kiến trúc cốt lõi, 4 hệ thống mẫu thực tế và chia nhỏ nội dung ôn tập thành 5 Domain chuyên biệt giúp tăng tốc độ tải trang.
1. Cấu trúc và Scenarios của đề thi
Đề thi CCA-F gồm các câu hỏi trắc nghiệm dựa trên các tình huống sản xuất thực tế. Trong quá trình thi, hệ thống sẽ chọn ngẫu nhiên 4 trong số 6 scenario dưới đây làm khung bối cảnh cho các câu hỏi:
- Scenario 1: Customer Support Resolution Agent (Agent hỗ trợ khách hàng bằng Agent SDK, gọi các công cụ MCP để truy vấn đơn hàng, khách hàng, xử lý hoàn tiền hoặc chuyển lên người thực).
- Scenario 2: Code Generation với Claude Code (Ứng dụng Claude Code để refactor, debug, viết tài liệu và kiểm soát workflow bằng Plan mode vs Direct execution).
- Scenario 3: Multi-Agent Research System (Hệ thống điều phối nhiều agent: Coordinator phân rã nhiệm vụ và ủy thác cho các subagent tìm kiếm, phân tích và tổng hợp).
- Scenario 4: Developer Productivity với Claude (Sử dụng các built-in tools như Read, Write, Bash, Grep, Glob để phân tích và tối ưu hóa hệ thống legacy lạ).
- Scenario 5: Claude Code cho Continuous Integration (Tích hợp Claude Code vào CI/CD pipeline để review code tự động, giảm thiểu tỷ lệ báo động giả - false positive).
- Scenario 6: Structured Data Extraction (Trích xuất thông tin từ tài liệu thô, validate bằng JSON Schema và tối ưu hóa quy trình kiểm duyệt thủ công của con người).
2. 12 Quy luật Phán đoán Kiến trúc (Architect's Judgement Rules)
Dưới đây là 12 nguyên tắc đinh để định hướng chọn đáp án đúng, giúp loại bỏ các phương án nhiễu (distractors) thường gặp:
- Tất định > Xác suất: Với các quy tắc kinh doanh bắt buộc (xác minh danh tính trước khi hoàn tiền, chặn hoàn tiền > $500), luôn sử dụng hooks lập trình (PreToolUse/PostToolUse) của Agent SDK. Không bao giờ tin cậy hoàn toàn vào prompt hay few-shot vì chúng chỉ mang tính xác suất.
- Sửa nguyên nhân gốc bằng cách rẻ nhất trước: Nếu agent chọn sai tool do mô tả sơ sài, giải pháp đầu tiên là viết lại tool description (thêm ví dụ, ranh giới rõ ràng). Đừng vội vàng over-engineer bằng cách thêm layer phân loại (classifier) hay gộp tool.
- Tối ưu prompt trước khi thêm hạ tầng: Để cải thiện hiệu chuẩn (calibration) định tuyến, ưu tiên thêm tiêu chí rõ ràng và few-shot vào prompt trước khi huấn luyện mô hình phân loại (ML classifier) hay phân tích cảm xúc khách hàng.
- Phạm vi chia sẻ quyết định vị trí cấu hình: Công cụ, lệnh hay chuẩn code dùng chung cho cả team phải được commit vào repository (đặt tại
.claude/commands/,.claude/rules/hoặc.mcp.json). Những gì dùng cá nhân thì đặt ở thư mục home (~/.claude/...). - Tác vụ phức tạp, ảnh hưởng rộng → Plan mode ngay: Nếu công việc đụng tới hàng chục file và đòi hỏi quyết định cấu trúc/ranh giới microservice, hãy dùng Plan mode để khảo sát và thiết kế an toàn trước khi chạy thực tế.
- Quy chuẩn theo loại file rải rác → rules + glob pattern: Để áp đặt quy tắc cho file test nằm rải rác khắp nơi, dùng file cấu hình trong
.claude/rules/kết hợp glob pattern (VD:**/*.test.tsx). Tránh dùngCLAUDE.mdtrong từng thư mục con vì khó bảo trì. - Lỗi thiếu hụt nằm ở khâu phân rã nhiệm vụ: Nếu các subagent thực thi hoàn hảo nhưng kết quả tổng hợp vẫn bị thiếu mảng thông tin lớn, lỗi nằm ở khâu phân rã task quá hẹp của coordinator, đừng đổ lỗi cho các subagent downstream.
- Lỗi phải mang đầy đủ ngữ cảnh (Contextual Error): Khi tool hoặc subagent thất bại, nó phải trả về thông tin chi tiết (loại lỗi, query đã thử, kết quả một phần và hướng xử lý). Nuốt lỗi hoặc huỷ bỏ toàn bộ luồng đều là anti-patterns.
- Quyền hạn tối thiểu & Tối ưu cho số đông: Cấp cho agent công cụ vừa đủ cho 85% tác vụ đơn giản thường gặp (như verify fact nhanh) để giảm tải latency cho coordinator. 15% ca phức tạp mới route ngược về coordinator điều phối.
- Cảnh giác với tính năng không tồn tại: Đề thi của Anthropic rất hay cài bẫy bằng các flag, biến môi trường hay file cấu hình tự bịa (VD:
--batchflag cho CLI,CLAUDE_HEADLESSenv, hay.claude/config.json). - Khớp API với yêu cầu về độ trễ (Latency SLA): Workflow chặn (developer đang chờ code merge) bắt buộc dùng API đồng bộ real-time. Workflow không chặn, chạy định kỳ (báo cáo nợ kỹ thuật qua đêm) hãy dùng Message Batches API để tiết kiệm 50% chi phí.
- Attention là tài nguyên hữu hạn: Để xử lý đống code PR lớn gồm nhiều file, hãy chia thành các pass tập trung (pass 1: file-by-file độc lập; pass 2: integration chéo). Việc tăng context window hay đổi model lớn hơn không giải quyết được chất lượng attention.
3. Apply thực tế: 4 kiến trúc hệ thống mẫu end-to-end
Để mường tượng trực quan cách vận hành của hệ thống trong thực tế và cách giải quyết các bài toán tradeoffs, tôi thiết kế 4 hệ thống mẫu đại diện cho các scenario chính:
Hệ 1: Agent CSKH cho shop e-commerce (Scenario 1)
Khách hàng (Chat Widget)
│
▼
┌─────────────────────────────────────────────────────┐
│ AGENT (Claude Agent SDK) │
│ • System prompt: tiêu chí escalation + few-shot │
│ • [CASE FACTS] block: được giữ cố định mỗi lượt │
│ • Agentic loop: chạy theo stop_reason │
│ │
│ Hooks: │
│ • PreToolUse → Chặn process_refund khi chưa có │
│ customer ID xác minh; chặn refund > $500 │
│ • PostToolUse → Chuẩn hóa timestamp/status code │
└──────────────┬──────────────────────────────────────┘
│ MCP Giao tiếp (.mcp.json)
▼
get_customer / lookup_order / process_refund / escalate_to_human
- Vòng lặp Agentic Loop: Agent nhận input, gọi
Messages APIvà kiểm trastop_reason. Nếu là"tool_use", agent chạy tool tương ứng (VD:lookup_order), lấy kết quả đưa ngược vào context để gọi lượt kế tiếp. Nếu là"end_turn", agent trả lời khách và thoát vòng lặp. - Hoạt động của PreToolUse Hook: Nếu khách hàng yêu cầu hoàn $650, hook lập trình
PreToolUsesẽ lập tức chặn cuộc gọiprocess_refund(vì số tiền vượt ngưỡng tự động $500), đồng thời ép agent gọi toolescalate_to_human. - Escalation & Handoff: Khi escalate, agent tự động xuất một Handoff Summary có cấu trúc gửi cho nhân viên trực hỗ trợ (người này không đọc transcript):
[HANDOFF SUMMARY] - Customer ID: C-88213 (Đã xác minh qua get_customer) - Yêu cầu: Hoàn tiền đơn hàng giao thiếu #A-1023 - Số tiền: $650.00 (Vượt ngưỡng tự động của Agent) - Đề xuất: Nhân viên duyệt chi bằng tay sau khi kiểm kho. - PostToolUse & Case Facts: Nếu
lookup_ordertrả về 40+ trường dữ liệu,PostToolUsehook sẽ cắt gọn chỉ giữ lại 5 trường liên quan (order_id, status, items, total, date) và ghi vào block[CASE FACTS]nằm ở đầu prompt để tránh bị trôi khi tóm tắt chat.
Hệ 2: Claude Code cho team dev + CI review (Scenario 2, 4, 5)
Thư mục dự án (Repo Git)
├─ CLAUDE.md ← Quy chuẩn code chung, cách chạy test, @import rules con
├─ .claude/
│ ├─ rules/
│ │ ├─ testing.md ← Rule viết test functional (paths: ["**/*.test.*"])
│ │ └─ api-conventions.md ← Rule thiết kế API (paths: ["src/api/**/*"])
│ ├─ commands/
│ │ └─ review ← Custom command /review chạy checklist của team
│ └─ skills/
│ └─ analyze-module ← Custom skill cá nhân, context: fork (chạy cô lập)
└─ .mcp.json ← Khai báo server MCP dùng chung (Jira/GitHub)
- Tải rule có điều kiện (Path-scoped rules): Khi dev sửa file
src/api/user.ts, chỉ cóapi-conventions.mdđược nạp vào context. Khi viết file test,testing.mdđược nạp. Thiết lập này giúp tiết kiệm tối đa token và không làm loãng sự tập trung của mô hình. - Explore Subagent trong Plan Mode: Khi dev chạy task di chuyển thư viện lớn (VD: moment sang date-fns trên 50 files), Claude Code tự động spawn một Explore Subagent chạy ngầm để đọc codebase và lên kế hoạch (Plan). Kết quả khảo sát dài dòng được subagent nén lại thành một bản tóm tắt kiến trúc gửi cho coordinator, giữ cho context hội thoại chính luôn sạch sẽ.
- Tích hợp CI/CD tự động: Pipeline chạy lệnh non-interactive để review PR:
Instance này chạy độc lập hoàn toàn với instance dev dùng để viết code, đảm bảo tính khách quan tối đa khi review (không bị thiên kiến xác nhận - confirmation bias).claude -p "/review" --output-format json --json-schema review-schema.json
Hệ 3: Pipeline trích xuất 5.000 hoá đơn mỗi đêm (Scenario 6)
23:00 Gom 5.000 hoá đơn PDF ──→ Messages Batches API (custom_id = mã file)
│ (Tiết kiệm 50% chi phí, xử lý trong 24h)
▼
07:00 Nhận kết quả trích xuất ──→ Validate bằng Pydantic/JSON Schema
│
├─ Thành công ──→ So sánh Confidence của từng trường dữ liệu
│ ├─ Điểm tự tin cao ──→ Ghi thẳng vào cơ sở dữ liệu
│ └─ Điểm tự tin thấp ──→ Đẩy vào hàng đợi kiểm duyệt thủ công
│
└─ Thất bại ──→ Phân loại lỗi
├─ Lỗi format/cấu trúc ──→ Gửi lại (Retry) kèm log lỗi chi tiết
└─ Lỗi thiếu thông tin ──→ Ghi nhận missing, chuyển sang duyệt thủ công
- Sử dụng Schema Nullable chống ảo tưởng: Trong JSON Schema định nghĩa công cụ trích xuất, các trường không bắt buộc (VD:
due_date) được khai báo kiểu["string", "null"]và mô tả "để null nếu tài liệu không ghi, không được đoán". Điều này giúp Claude trả vềnullthay vì tự bịa ra một ngày ngẫu nhiên để thỏa mãn schema. - Quy trình Validation-Retry: Nếu kết quả trích xuất bị lệch số học (VD: tổng tiền các mặt hàng không bằng tổng tiền thanh toán), hệ thống gửi lại request:
[FOLLOW-UP REQUEST] Tài liệu gốc: [Nội dung hóa đơn] Bản trích xuất lỗi: {"items": [{"price": 10}, {"price": 20}], "total": 40} Lỗi phát hiện: Tổng giá trị items (30) không khớp với trường total (40). Hãy kiểm tra lại và thực hiện trích xuất chính xác. - Kiểm duyệt dựa trên Confidence: Hệ thống lấy mẫu ngẫu nhiên phân tầng (stratified random sampling) từ nhóm dữ liệu tự động ghi (high-confidence) để kiểm định chất lượng định kỳ, phát hiện sớm các lỗi trôi dạt (concept drift).
Hệ 4: Hệ nghiên cứu multi-agent ra báo cáo có trích dẫn (Scenario 3)
┌──────────────────────┐
Yêu cầu nghiên cứu │ COORDINATOR │ (allowedTools chứa "Task")
────────────────────→│ Phân rã subtasks │
│ Gom & Fact-check │
└──────────┬───────────┘
│ Spawning song song (nhiều Task call)
┌─────────────────┼──────────────────┐
▼ ▼ ▼
[Search Agent] [Search Agent] [Analysis Agent]
(Mảng nhạc) (Mảng phim) (Đọc PDF nguồn)
└─────────────────┬──────────────────┘
│ Trả dữ liệu có cấu trúc:
│ { claim, evidence, source_url }
▼
┌──────────────────────┐
│ SYNTHESIS AGENT │ (Verify claims qua
│ Tổng hợp báo cáo │ verify_fact tool chuyên biệt)
└──────────────────────┘
- Orchestration & Parallel Spawning: Coordinator nhận đề bài, chia thành các nhánh tìm kiếm song song. Nó phát ra 3 lệnh gọi tool
Taskcùng một lúc trong một lượt API để spawn 3 subagent chạy song song, giảm 60% thời gian phản hồi (latency). - Memory Isolation: Mỗi subagent được cấp một system prompt riêng và nhận thông tin đầu vào tường minh. Coordinator không chia sẻ lịch sử hội thoại gốc của mình để tránh làm nhiễu ngữ cảnh làm việc của subagent.
- Fact-Checking và Provenance: Subagent trả dữ liệu về theo định dạng cấu trúc nghiêm ngặt để giữ nguồn gốc (provenance):
Synthesis Agent sử dụng một tool có phạm vi hẹp ({ "claim": "Thị trường streaming nhạc tăng trưởng 12% năm 2025", "evidence": "Doanh thu nhạc số đạt 18 tỷ USD, tăng 12% so với năm trước...", "source_url": "https://musicreports.com/2025", "retrieved_date": "2026-07-10" }verify_fact) để tự tra cứu nhanh các thông số đơn giản mà không cần route ngược qua nhiều lượt với Coordinator. - Xử lý mâu thuẫn dữ liệu: Nếu nguồn A báo tăng 12% nhưng nguồn B báo tăng 15%, Synthesis Agent bắt buộc phải ghi nhận cả hai con số kèm theo nguồn và ngày xuất bản trong báo cáo cuối cùng, không được phép tự tính trung bình cộng hoặc tự ý bỏ một nguồn.
4. Lộ trình ôn tập chi tiết theo 5 Domain
Chi tiết nội dung và các ghi chú thực chiến cho từng phần kiến thức của kỳ thi nằm ở các liên kết dưới đây:
- Domain 1: Agentic Architecture & Orchestration (Trọng số 27%) — Agentic loop, điều phối multi-agent, hooks chặn tool call, quản lý state và resume session.
- Domain 2: Tool Design & MCP Integration (Trọng số 18%) — Thiết kế tool interface, structured error response, scoped tools, tích hợp MCP servers và các built-in tools.
- Domain 3: Claude Code Configuration & Workflows (Trọng số 20%) — Cấu hình CLAUDE.md hierarchy, path rules, skills, plan mode vs direct execution và CI/CD integration.
- Domain 4: Prompt Engineering & Structured Output (Trọng số 20%) — Few-shot prompting, JSON Schema, validation-retry loop, Message Batches API và multi-pass review.
- Domain 5: Context Management & Reliability (Trọng số 15%) — Tối ưu context window, "lost in the middle", escalation patterns, confidence calibration và provenance dữ liệu.
Từ khoá cần thuộc
🔴 Core: Agentic loop · Tool description · Programmatic hooks · Plan mode · 🟡 Important: Scoped tools · custom_id (Batch API) · Structured error propagation · glob path rules · 🟢 Good-to-know: Lost-in-the-middle · Confidence calibration · Stratified sampling · Provenance mappings
Muốn tự kiểm tra? Làm đề thi thử ở tab "Đề thi thử".