Tổng kết và Lắp ráp Hệ thống

5 bài học cốt lõi (Key Takeaways)

01. Decomposition là bước đi tiên quyết trước khi thiết kế kiến trúc

(Decomposition is the move that comes before architecture)

Trước khi có thể lựa chọn bất kỳ một pattern nào, bạn bắt buộc phải phân rã công việc vào 3 nhóm đảm nhiệm (buckets):

• What Claude handles: Công việc hưởng lợi từ việc hiểu ngôn ngữ, suy luận, tóm tắt hoặc điều phối công cụ.

• What existing systems handle: Những gì hệ thống hiện tại vốn đã làm ổn định, tin cậy và chuẩn xác với chi phí rẻ (database, SQL check, rules engine).

• What humans handle: Các điểm phán đoán nghiệp vụ mang tính sống còn, xử lý ngoại lệ và phê duyệt pháp lý.

Sự phân chia này được dẫn dắt bởi cách model hành xử trên từng phần việc (dưới lăng kính 4 đặc tính: Next-token prediction, Knowledge, Working memory, Steerability). Những thiết kế bỏ qua bước này sẽ rơi vào hai vết xe đổ: ép Claude làm những việc mà hệ thống sẵn có xử lý tốt hơn với chi phí chỉ bằng một phần nhỏ, hoặc bắt Claude tự vận hành mà thiếu đi ngữ cảnh chuyên môn mà một con người sẽ cung cấp cho đồng nghiệp.

02. Chọn Pattern là chọn mức độ quyền tự quyết trao cho Model

(Choosing a pattern is choosing how much autonomy to grant)

Ba mô hình Augmented LLM, Workflow, và Agent là các điểm nằm trên một dải phổ kéo dài từ "Claude hỗ trợ trong một bước đơn lẻ" cho đến "Claude tự lập kế hoạch cho toàn bộ chuỗi hành động", đi kèm 4 sub-patterns cốt lõi bên trong workflow (Chaining, Routing, Parallelization, Evaluator-optimizer).

Quyết định lựa chọn dựa trên 5 yếu tố theo trình tự loại trừ:

1. Predictability: Có thể liệt kê trước các bước bằng code không?

2. Error cost: Chi phí cho một câu trả lời sai là gì (thử lại, kiểm toán hay kiện tụng)?

3. Observability: Đội ngũ vận hành có thể nhìn thấy và giải trình các bước thực thi không?

4. Latency budget: Thời gian chờ tối đa của người dùng là bao lâu?

5. Cost: Ngân sách token trên mỗi request ở quy mô thực tế.

Khi mức độ thiệt hại do sai sót (error cost) là rào cản mang tính ràng buộc, chính error cost sẽ quyết định pattern. Ràng buộc khắt khe nhất (tightest constraint) luôn là yếu tố chốt hạ thiết kế.

03. Tìm đến các Reference Architectures đã được kiểm chứng trước khi tự sáng chế

(Reach for tested reference architectures before inventing your own)

5 kiến trúc tham chiếu tiêu chuẩn: Agent, RAG, Document processing pipeline (Evaluator-optimizer), Customer/ticket triage (Routing), và Coding agent được đúc kết từ những bài học mà ngành công nghiệp đã phải trả giá để hoàn thiện:

• Chỉ kết hợp nhiều kiến trúc khi các phần khác nhau trong bài toán thất bại theo những cách khác nhau và cần được quản trị riêng biệt.

• Khi chưa xác định rõ ranh giới bài toán, hãy chọn và tinh chỉnh một kiến trúc duy nhất thay vì cố ghép nối phức tạp.

• Sai lầm phổ biến nhất: Dùng retrieval thay thế cho live state. Retrieval sinh ra để phục vụ tài liệu tĩnh và các bản chụp quá khứ (stale snapshots); đối với dữ liệu thời gian thực biến động liên tục, bắt buộc phải sử dụng tool call trực tiếp vào system of record.

04. Chọn Model: Khởi đầu với Sonnet và đối xử với mỗi đợt hoán đổi như một đợt Release

(Choosing a model: start with Sonnet and treat every swap as a release)

Sonnet là phân cấp mặc định (default tier) cho hầu hết các bài toán production nhờ sự cân bằng tối ưu giữa năng lực suy luận, tốc độ và chi phí.

• Việc chuyển lên Opus hay hạ cấp xuống Haiku phải là một quyết định có chủ đích và có cơ chế kiểm soát nghiêm ngặt: yêu cầu một bộ eval set xác định rõ thế nào là đạt chuẩn, và một tiêu chí rút lui (rollback criterion) được thống nhất từ trước khi chạy thử nghiệm, chứ không phải đặt ra sau khi đã thấy dữ liệu.

• Nguyên lý này áp dụng tương tự cho context window: Chiến lược ngữ cảnh tiệm tiến (Progressive context — chỉ nạp những gì bước tiếp theo cần) duy trì độ bền vững cao hơn nhiều qua các phiên làm việc dài so với chiến lược nguyên khối (Monolithic context — nạp tất cả ngay từ đầu và phình to cho đến khi chạm vách rơi bộ nhớ).

05. Chọn Entry Point dựa trên bản chất công việc, không phải dựa trên thói quen có sẵn

(Pick the entry point by the work it has to do, not by what is already on the shelf)

Claude.ai, Direct API, SDK, Claude Code, và MCP mang những đánh đổi cốt lõi hoàn toàn khác nhau:

• Tốc độ triển khai ban đầu đối lập với độ sâu kiểm soát hệ thống.

• Giao diện người dùng dựng sẵn đối lập với tích hợp tùy biến vào sản phẩm riêng.

• Phạm vi công cụ rộng mở đối lập với sự tập trung vào nghiệp vụ cụ thể.

Một khuyến nghị kiến trúc chuẩn xác là khi bạn có thể gọi tên rõ ràng sự đánh đổi ngay tại thời điểm đưa ra quyết định. Việc minh bạch hóa sự đánh đổi này ngay từ đầu chính là cơ sở duy nhất giúp bạn nhận biết chính xác thời điểm hệ thống phát triển vượt ngưỡng và cần phải chuyển đổi sang một entry point khác.

Tài liệu nguồn tham chiếu (Course Sources)

• Anthropic Skilljar — Claude 101: Tổng quan họ mô hình (Opus, Sonnet, Haiku), các entry points qua Claude.ai và Direct API.

• Anthropic Skilljar — Claude Code 101 In Action: Ngăn xếp tùy biến và quản trị Claude Code (CLAUDE.md, subagents, MCP, Skills, Hooks, Permissions).

• Anthropic Skilljar — AI Fluency Foundations: Khung 4 đặc tính hành vi cốt lõi (Next-token prediction, Knowledge, Working memory, Steerability).

• Anthropic Skilljar — Building with the Claude API: Kỹ thuật xây dựng RAG chuyên sâu, chiến lược chunking, hybrid retrieval, tool use, extended thinking, và phương pháp luận thiết lập bộ đánh giá (evaluation sets).