Bài viết
Đừng Fan-out vô tội vạ: Thực chiến kiến trúc điều phối 4 tầng với Claude Haiku 5.5
Claude Haiku 5.5 vừa nhanh vừa rẻ, nhưng ném bừa mọi task song song cho nó chỉ tổ khuếch đại phán đoán sai, thiên vị khi review và rủi ro Supply Chain. Bài viết này mổ xẻ kiến trúc phân tầng: Fable nhận định, Opus điều phối, Sonnet và Haiku triển khai, CI xác minh, Opus nghiệm thu, cùng với việc loại task nào mới thực sự đáng để Fan-out.
· 9 phút đọc
Claude Haiku 5.5 ra mắt vào ngày 07 tháng 10 năm 2026. Với prompt dưới 100,000 tokens, giá của nó chỉ bằng một phần hai mươi so với Sonnet 5.5, và độ trễ cũng thuộc hàng nhanh nhất trong thế hệ Claude hiện tại.
Vừa rẻ vừa nhanh, rất dễ khiến người ta nảy ra ý định: bẻ nhỏ mọi task coding rồi ném song song cho một bầy Haiku làm là xong.
Làm prototype thì có thể chạy ổn. Nhưng đưa vào môi trường kỹ thuật production, bạn sẽ sớm va phải 3 vấn đề:
- Model nhỏ không xử lý tốt sự mơ hồ. Định vị chính thức của Haiku 5.5 là phân loại, trích xuất thông tin, định tuyến và các tác vụ subagent với tần suất cao, độ trễ thấp. Khi yêu cầu vẫn còn mơ hồ về mặt nghiệp vụ, cần hiểu toàn bộ ngữ cảnh hệ thống, nó rất dễ đưa ra kết quả trông thì hoàn chỉnh nhưng thực chất là đoán sai hướng.
- Để model tự chọn câu trả lời sẽ sinh ra thiên vị khi review. Ném vài chục bản output cho một model lớn đọc, nó sẽ có xu hướng chọn phiên bản "trông cấu trúc có vẻ đẹp", thay vì phiên bản thực sự đúng về mặt logic và thực thi.
- Quyền hạn sẽ bị khuếch đại theo số lượng Worker. Nếu cho phép các subagent chạy song song tự động cài package hoặc sửa file cấu hình, mở N Worker đồng nghĩa với việc tạo ra thêm N cửa ngõ có nguy cơ đưa mã độc vào hệ thống.
Vì vậy, tôi chuyển sang dùng điều phối phân tầng (Hierarchical Orchestration): mỗi tầng chỉ làm việc mình giỏi nhất, còn năng lực chạy song song của Haiku chỉ được dùng ở những nơi thực sự cần thiết.
Nói trước kết luận: Fable chịu trách nhiệm nghĩ cho thấu đáo, Opus phân bổ và nghiệm thu, Sonnet gánh phần triển khai chính, Haiku chỉ nhận các task cơ học và task dạng tìm kiếm có thể tự động xác minh. Các phương án ứng viên phải vượt qua CI trước rồi mới đưa cho model xem.
Kiến trúc 4 tầng: Phán đoán, Điều phối, Xác minh, Nghiệm thu#
Input yêu cầu
│
▼
[Tầng phán đoán] Fable: Quyết định kiến trúc, bẻ nhỏ task, Acceptance Criteria
│
▼
[Tầng điều phối] Opus Main Session: Chỉ phân bổ, không bẻ nhỏ lại
├─► Nhánh A: Phức tạp nhưng ranh giới rõ ràng ──► Sonnet triển khai
├─► Nhánh B: Task cơ học ──► Một Haiku duy nhất
├─► Nhánh C: Dạng tìm kiếm, nhiều cách giải ──► Nhiều Haiku, mỗi con một Git Worktree
│
▼
[Tầng xác minh] Build, Type Check, Test, Benchmark (Nhánh C chỉ giữ lại top 2–3)
│
▼
[Tầng nghiệm thu] Opus chốt kết quả theo Acceptance Criteria
Thất bại thì leo thang: Haiku sửa 2 lần vẫn fail ➔ Sonnet ➔ Trả về Opus
Việc xếp từng model vào tầng nào được quyết định dựa trên định vị chính thức và mức giá. Dưới đây là các con số trong tài liệu chính thức của Anthropic tính đến ngày 08 tháng 10 năm 2026, đơn vị giá là USD trên mỗi triệu tokens:
| Model |
Định vị chính thức |
Độ trễ |
Giá Input / Output |
| Claude Fable 5.1 |
Suy luận độ khó cao và tác vụ agentic chạy dài hạn |
Khá chậm |
$10 / $50 |
| Claude Opus 5.5 |
Agentic coding dài hạn và công việc tri thức |
Trung bình |
$4 / $20 |
| Claude Sonnet 5.5 |
Sự kết hợp tối ưu giữa tốc độ và năng lực |
Nhanh |
$2 / $10 |
| Claude Haiku 5.5 |
Tác vụ phân loại, trích xuất, định tuyến và subagent số lượng lớn, độ trễ thấp |
Nhanh nhất |
Từ $0.10 / $0.50 |
Giá của Haiku 5.5 chia làm hai bậc: khi prompt vượt quá 100,000 tokens, giá sẽ chuyển thành $0.50 / $2.50.
Tầng phán đoán: Fable chịu trách nhiệm quyết định kiến trúc và Acceptance Criteria#
Không phải yêu cầu nào cũng cần đến Fable. Đây là tầng đắt nhất và cũng chậm nhất, tôi chỉ dùng khi yêu cầu có sự mơ hồ, liên quan đến tích hợp liên hệ thống, hoặc cần đưa ra các quyết định kiến trúc cốt lõi.
Fable phải bàn giao được 3 thứ:
- Thiết kế giải pháp
- Phân rã task
- Tiêu chí nghiệm thu (Acceptance Criteria) cho từng subtask có thể kiểm chứng bằng test
Khâu suy luận và bẻ nhỏ task phải do cùng một tầng đảm nhiệm. Tầng nào nhìn thấu được các điểm mù của hệ thống thì mới vạch ra được ranh giới rõ ràng cho các subtask; giao kiến trúc cho A rồi giao bẻ task cho B thì định nghĩa interface thường sẽ trở nên nhập nhằng.
Tác vụ bảo mật là ngoại lệ. Thế hệ Claude hiện tại đều có bộ phân loại an toàn, khi request bị chặn sẽ trả về stop_reason: "refusal", khiến ngay cả công việc bảo mật chính đáng cũng có thể bị chặn nhầm. Bộ phân loại của Fable 5.1 bao trùm phần lớn nội dung bảo mật, tài liệu chính thức cũng nêu rõ nó không được thiết kế cho mảng bảo mật; trong khi Opus 5.5 lại cho phép tìm lỗ hổng trong source code. Vì vậy với các yêu cầu kiểu vá lỗ hổng bảo mật, khâu phân tích đầu vào tôi giao thẳng cho Opus.
Tầng điều phối: Opus chỉ phân bổ, không bẻ nhỏ lại#
Opus đóng vai trò Main Session, phụ trách định tuyến và giao việc. Tầng này không lật lại kiến trúc, cũng không bẻ nhỏ task lần thứ hai.
- Nhánh A, phức tạp nhưng ranh giới rõ ràng: Các task logic phức tạp nhưng ranh giới interface đã được định nghĩa rõ ràng sẽ giao cho Sonnet. Đây là lực lượng nòng cốt để triển khai.
- Nhánh B, task cơ học đơn thuần: Viết boilerplate code, đổi tên biến, bổ sung unit test đơn giản, viết thêm tài liệu, giao cho một Haiku xử lý.
- Nhánh C, task dạng tìm kiếm và tối ưu hóa: Tinh chỉnh hiệu năng, thử nhiều cách viết SQL hoặc Regex phức tạp, điều tra Flaky Test, lúc này mới kích hoạt Fan-out: điều động nhiều Haiku, mỗi con tự thử các cách giải khác nhau trong một Git Worktree độc lập.
Bất kể đi theo nhánh nào, output đều phải đi vào tầng xác minh.
Tầng xác minh: Máy móc đi trước, model theo sau#
Một cách làm rất phổ biến là ném toàn bộ code sinh ra song song cho Opus hoặc Sonnet, rồi nhờ nó review bằng prompt.
Vấn đề là, khi model đọc code, nó rất dễ bị thu hút bởi những câu trả lời format gọn gàng, khai báo type đầy đủ, nhưng điều đó không có nghĩa là code đã vượt qua được các edge case. Do đó, các phương án ứng viên phải qua ải máy móc trước:
- Build và Type Check: Phải compile được, type phải chuẩn
- Unit / Integration Tests: Vượt qua kiểm thử đơn vị và kiểm thử tích hợp
- Benchmark / Profiling: Đo lường hiệu năng và mức tiêu thụ bộ nhớ
Code nào không qua được automated test thì loại thẳng tay. Với các phương án ở nhánh C, Opus chỉ cần xem top 2–3 phương án đã pass kiểm tra và có chỉ số tốt nhất, vừa tiết kiệm context window vừa đỡ tốn token.
Tầng nghiệm thu: Opus chốt kết quả, thất bại thì leo thang#
Cuối cùng, Opus sẽ dựa trên Acceptance Criteria do tầng phán đoán định nghĩa để chốt kết quả. Khi Worker bị tắc, quy trình xử lý sẽ leo thang (Escalation Path) theo thứ tự:
- Haiku thất bại, tự sửa 2 lần vẫn không qua thì dừng việc retry.
- Chuyển cho Sonnet tiếp quản để sửa.
- Nếu Sonnet cũng không qua được nghiệm thu, thường là do khâu bẻ task hoặc giả định ban đầu có mâu thuẫn. Task sẽ được trả về cho Opus, để Opus quyết định xem có cần gửi lại cho Fable bẻ task từ đầu hay không.
3 nguyên tắc trước khi đưa vào production#
Đừng Fan-out mù quáng#
Task đơn giản không cần nhiều Worker, còn task có độ mơ hồ cao thì model nhỏ lại không giải nổi. Chỉ những task dạng tìm kiếm có "không gian giải pháp rộng" và "xác minh nhanh được bằng automated test" mới đáng để cho nhiều Haiku chạy song song.
Cô lập môi trường, khóa chặt Lockfile#
Git Worktree chỉ cô lập các thay đổi trong code để các Worker chạy song song không ghi đè file lên nhau; nó không hề giới hạn mạng, cũng không giới hạn phạm vi truy cập của chương trình. Muốn phòng chống Supply Chain Attack, bạn vẫn cần sandbox và cấm Worker tự ý cài đặt package chưa qua kiểm duyệt hoặc sửa đổi Lockfile. Tùy tiện mở quyền cài đặt chẳng khác nào để Agent rước các package và script không rõ nguồn gốc vào codebase.
Nghiệm thu bằng số liệu đo lường, không dùng lời nhận xét của model#
Kết quả test, coverage, mức dùng memory và độ trễ mới là những căn cứ có thể tái lập và so sánh được. Lời nhận xét bằng văn bản của model chỉ mang tính tham khảo, không thể dùng để nghiệm thu chất lượng code.
Model rẻ phải dùng đúng chỗ#
Haiku 5.5 giúp việc chạy song song trở nên rẻ, nhưng bản thân việc song song không làm cho kết quả đúng hơn. Hãy tách bạch phán đoán, phân bổ, xác minh và nghiệm thu trước, khi đó rẻ và nhanh mới biến thành lợi thế thực sự.
Kiến trúc phân tầng này thực chất chính là Graph mà tôi đã đề cập trong bài AI Agent thực chất là một team Agile: ai làm trước, làm xong giao cho ai, gặp sự cố thì chuyển cho ai.