Thiết kế kiến trúc giải pháp

Khi nào Claude phù hợp

Câu hỏi đầu tiên là Claude có nên làm giải pháp chính hay không. Claude mạnh ở việc cần hiểu ngôn ngữ và suy luận, yếu ở việc cần phản hồi cực nhanh hoặc kết quả tất định.

• Hợp làm giải pháp chính

  Soạn bản nháp từ dữ liệu bán cấu trúc để người duyệt, rà tài liệu dài và trích xuất thông tin có cấu trúc, phân loại kèm lý do.

• Không hợp làm giải pháp chính

  Chấm điểm thời gian thực trong vài chục mili giây, thay thế hạ tầng như vector index, phép tính cần kết quả tuyệt đối chính xác. Những việc này nên dùng code, cơ sở dữ liệu hoặc mô hình ML chuyên dụng. Claude vẫn có thể là một thành phần bên cạnh.

Kiểm tra đủ 4 thành phần

Mọi kiến trúc đều cần đủ 4 phần. Hãy kiểm tra trước khi bàn đến chi tiết khác.

• Input

  Dữ liệu, câu hỏi hoặc tín hiệu khởi động quy trình.

• Processing

  Logic, lời gọi model, chạy tool. Phần này thường được chú ý nhiều nhất.

• Output

  Kết quả có cấu trúc, gửi cho bước sau hoặc người dùng.

• Feedback loop

  Eval, phản hồi của người dùng và monitoring, giúp bạn biết hệ thống còn tốt không để cải thiện.

3 trụ giá trị để phân xử

Khi nhiều phương án đều chạy được, hãy xem đề bài nhấn mạnh trụ nào rồi chọn theo trụ đó.

• Efficiency: hiệu suất

  Đo gì

  Lượng việc xử lý được, tỉ lệ tự động hóa.

  Ưu tiên

  Kiểu kiến trúc ít cần người can thiệp.

• Cost: chi phí

  Đo gì

  Chi phí mỗi giao dịch, lượng token.

  Ưu tiên

  Batch API cho việc không gấp, prompt caching, model rẻ như Haiku.

• Performance: hiệu năng

  Đo gì

  Độ trễ p95/p99, độ chính xác tối thiểu.

  Ưu tiên

  Model mạnh hơn, streaming, re-ranking cho RAG.

3 kiểu kiến trúc

Quy tắc chính: nếu một lần gọi model đã đủ thì không cần Workflow hay Agentic. Mỗi mức phức tạp thêm đều phải có lý do.

• Augmented LLM

  Một lần gọi model, có thêm tài liệu, tool hoặc bộ nhớ.

  Hình dung

  Một chuyên viên giỏi có sổ tay để tra.

  Dùng khi

  Một việc rõ ràng, phạm vi hẹp.

  Đánh đổi

  Rẻ và nhanh nhất.

• Workflow

  Nhiều lần gọi model theo trình tự do developer định sẵn.

  Hình dung

  Dây chuyền nhà máy, từng công đoạn cố định.

  Dùng khi

  Biết trước các bước, cần kiểm toán hoặc tuân thủ.

  Đánh đổi

  Dễ đoán, dễ audit, nhưng kém linh hoạt.

• Agentic

  Model tự chọn tool và bước tiếp theo trong vòng lặp, đến khi gặp điều kiện dừng.

  Hình dung

  Thám tử tự quyết định điều tra gì tiếp theo.

  Dùng khi

  Việc mở, không liệt kê trước được các bước.

  Đánh đổi

  Linh hoạt nhất, nhưng chi phí và thời gian khó đoán.

Managed Agents hay tự vận hành

Managed Agents là bộ khung agent dựng sẵn, chạy trên hạ tầng được quản lý. Bạn không phải tự xây vòng lặp agent, sandbox và lớp chạy tool.

• Managed Agents

  Hợp với việc chạy dài hoặc bất đồng bộ, cần phiên có trạng thái, và đội muốn bớt công vận hành hạ tầng.

• Messages API, tự xây vòng lặp

  Hợp khi cần vòng lặp riêng và kiểm soát chi tiết từng bước.

Chia việc và điều phối

Hai cách chia agent

• Theo năng lực: agent nghiên cứu, agent phân tích, agent viết.
• Theo miền dữ liệu: agent theo khu vực hoặc sản phẩm. Cách này hợp khi ranh giới agent cũng là ranh giới quản trị: quyền truy cập, nơi lưu dữ liệu, người sở hữu.

Hai cách phối hợp

• Sequential handoff: đầu ra của bước này là đầu vào của bước sau.
• Parallel fan-out: các việc con độc lập chạy song song. Sau đó một synthesizer gộp kết quả và kiểm tra chất lượng lần cuối.

Mô hình hub-and-spoke

Coordinator đứng giữa, giao việc cho các subagent và gộp kết quả. Cần nhớ:

• Subagent không thấy lịch sử của coordinator. Coordinator phải truyền rõ mọi dữ liệu subagent cần. Đây là nguyên nhân hàng đầu của lỗi “agent tổng hợp bỏ sót kết quả”.
• Muốn tạo subagent, coordinator phải được phép dùng Task tool.
• Muốn chạy song song, coordinator gọi nhiều Task trong cùng một lượt trả lời. Chờ xong từng Task mới gọi tiếp sẽ chạy nối tiếp và chậm.
• Mỗi subagent chỉ nên có ít tool, khoảng 4 đến 5. Một agent ôm quá nhiều tool gọi là capability bloat và hay chọn nhầm tool.
• Thiếu dữ liệu ở bước tổng hợp? Coordinator giao lại một truy vấn cụ thể cho subagent tìm kiếm.
• Chia quá hẹp cũng có hại: nhiều chủ đề con bị bỏ sót, kết quả không đầy đủ.
• Truyền dữ liệu có cấu trúc để giữ được nguồn trích dẫn qua các bước.

Giữ tool nào trong agent

Nên giữ tool bắt buộc cho nhiệm vụ đã định và tool dùng thường xuyên giúp giảm chuyển giao. Nên bỏ tool chỉ thỉnh thoảng dùng cho việc không liên quan và tool để dành cho tương lai.

Bằng chứng để tách agent thay vì thêm một lớp router: có tool không được gọi trong thời gian dài, mô tả tool chồng chéo, và các tool phục vụ nhiều miền công việc khác nhau. Router thêm một lần gọi model cho mỗi request mà không xử lý gốc vấn đề.

Tách pipeline theo lớp

Khi phân rã một quy trình, mỗi việc thuộc về một lớp. Việc nào code làm chắc chắn được thì để code làm, chỉ dùng model ở chỗ cần hiểu ngôn ngữ.

• Pre-processing

  Chuẩn bị dữ liệu trước khi gọi model: OCR ảnh scan, làm sạch văn bản, che PII.

• Model stage

  Việc cần Claude: phân loại, trích xuất có cấu trúc, tóm tắt.

• Post-processing

  Xử lý sau khi model trả lời: kiểm tra schema, đối chiếu quy tắc nghiệp vụ, lưu vào hệ thống gốc.

Đặt hàng rào bằng code

Prompt là lời dặn: model thường làm theo, nhưng không chắc chắn. Code là hàng rào: luôn chạy và không phụ thuộc vào model. Việc gì bắt buộc phải đúng thì đặt trong code.

• PreToolUse hook

  Chạy trước khi tool thực thi, để kiểm tra input, quyền và chặn injection. Đề có thể gọi là tool call interception.

  Ví dụ

  Chặn lệnh xóa nếu người dùng không phải admin.

• PostToolUse hook

  Chạy sau khi tool trả kết quả, trước khi kết quả vào context.

  Ví dụ

  Đổi ngày tháng từ nhiều API về cùng một định dạng.

• stop_reason

  Tín hiệu quyết định vòng lặp có chạy tiếp không. Giá trị tool_use nghĩa là model muốn gọi tool: hãy chạy tool rồi gửi kết quả lại. Giá trị end_turn nghĩa là model đã xong. Luôn thêm giới hạn số vòng hoặc thời gian để vòng lặp chắc chắn kết thúc.

• isError

  Khi tool lỗi, hãy báo lỗi rõ ràng kèm lý do. Nếu trả về rỗng, agent sẽ tưởng là “không có dữ liệu” và không biết cách xử lý lỗi.

Thiết kế cho quy mô lớn

Khi một review hỏi kiến trúc có chịu được hàng nghìn người dùng đồng thời không, hãy kiểm tra các điểm sau:

• Rate limit: thử lại 429 và 529 với backoff, giới hạn số request đồng thời.
• Trạng thái: lưu trạng thái phiên bên ngoài từng máy chủ để mở rộng và phục hồi được.
• Chi phí: cache phần prefix ổn định, định tuyến việc đơn giản sang model nhẹ, đưa việc không gấp vào Batch API.
• Giám sát: theo dõi p95/p99, token và lỗi theo từng bước.
• Ranh giới: mỗi agent chỉ có đúng tool cần dùng, quyền theo từng người dùng.

Ghi lại và phục hồi

• ADR (Architecture Decision Record)

  Ghi vì sao chọn phương án này, đã loại phương án nào, và khi nào cần xem xét lại. Lý do từ chối phương án phức tạp cũng là một phần của bài làm.

• Checkpoint

  Agent chạy dài bị crash thì lưu trạng thái có cấu trúc, rồi nạp vào một phiên mới để chạy tiếp.

• context: fork

  Chạy skill trong subagent riêng, để các kết quả trung gian dài dòng không làm đầy lịch sử chính.

• Progressive discovery

  Với bộ tài liệu lớn và liên tục tăng, cho agent khám phá dần thay vì nạp hết từ đầu.

Ví dụ: xử lý hồ sơ bảo hiểm ban đêm

Yêu cầu: chạy theo lô ban đêm, các bước cố định và cần kiểm toán. Áp lực chính là chi phí mỗi hồ sơ, không cần phản hồi nhanh.

1. Kiểu kiến trúc: Workflow, vì các bước cố định và cần audit.
2. Chi phí: Batch API, prompt caching cho chỉ dẫn lặp lại, model tier thấp.
3. Chia việc: chưa cần chia theo năng lực. Nếu tách bước trích xuất thành subagent thì truyền dữ liệu rõ ràng và giới hạn tool.
4. Hàng rào: PostToolUse để chuẩn hóa dữ liệu, chặn bằng code quanh thao tác thanh toán và từ chối hồ sơ, stop_reason kèm giới hạn số vòng.
5. Tài liệu: ADR nêu chi phí là tiêu chí phân xử, vì sao chọn Workflow, và khi nào cần xem lại.

Nhớ nhanh

• Bắt đầu bằng phương án đơn giản nhất: Augmented LLM, rồi Workflow, rồi Agentic.
• Bước cố định và cần audit thì chọn Workflow.
• Subagent không thấy lịch sử chung. Dữ liệu phải được truyền rõ ràng.
• Giới hạn bắt buộc đặt trong code, không đặt trong prompt.
• Vòng lặp dừng theo stop_reason, kèm một giới hạn cứng.