Các nguyên tắc thiết kế AI agent thành công theo Anthropic [bài dịch]

> # TL;DR
>
> - Xây dựng LLM/AI agent
> - luôn lấy sự đơn giản làm nguyên tắc cốt lõi, chỉ thêm độ phức tạp khi thực sự cần
> - "hiểu sâu rồi mới áp dụng framework", "kết hợp và kiểm thử các workflow·mẫu agent (chaining, routing, parallelization, evaluator-optimizer, v.v.) theo đúng môi trường thực tế và mục tiêu, đồng thời thiết kế API công cụ, tài liệu hóa và kiểm thử thật kỹ".

1. Nguyên tắc thiết kế LLM agent thành công

• Tập trung vào sự đơn giản: Những triển khai thành công thường có xu hướng sử dụng các mẫu đơn giản và có thể ghép nối (compoundable), thay vì phụ thuộc vào framework phức tạp.
• Chỉ thêm độ phức tạp khi cần: Cấu trúc nền tảng nên được thiết kế đơn giản nhất có thể, và chỉ đưa độ phức tạp vào khi thực sự cần thiết để đạt hiệu quả.
• (Nguyên văn: "Những triển khai thành công nhất không phụ thuộc vào thư viện chuyên biệt hay framework phức tạp... mà được xây dựng dựa trên các mẫu đơn giản nhưng có thể kết hợp theo kiểu lắp ghép.")

2. Phân biệt khái niệm workflow và agent

• Workflow: LLM và công cụ xử lý theo tuyến đường đã được định nghĩa trước (đường đi của mã).
• Agent: LLM tự động quản lý công việc và việc sử dụng công cụ một cách động (LLM là chủ thể ra quyết định).
• (Nguyên văn: "Workflow điều phối LLM và công cụ theo các đường đi mã được xác định trước... còn agent để LLM động chỉ đạo quy trình và cách dùng công cụ của chính nó")

3. Tiêu chí quyết định khi nào nên dùng agent

• Bắt đầu bằng cách đơn giản → tăng dần độ phức tạp khi cần: Ban đầu hãy thử với lời gọi LLM đơn giản, tìm kiếm, v.v.; nếu chưa đủ thì dần dần đưa vào Workflows/Agents.
• Khả năng dự đoán/tính nhất quán quan trọng → phù hợp dùng workflow
• Cần tính linh hoạt ở quy mô lớn và ra quyết định do mô hình dẫn dắt → agent phù hợp hơn

4. Nguyên tắc áp dụng framework

• Có nhiều công cụ/framework như LangGraph, Bedrock, Rivet, Vellum,
• nhưng khuyến nghị bắt đầu từ việc trực tiếp sử dụng LLM API, và chỉ đưa framework vào khi cần.
• Khi dùng framework, bắt buộc phải hiểu sâu cách nó vận hành bên trong (vì lớp trừu tượng có thể khiến việc xử lý sự cố trở nên khó hơn).
• (Nguyên văn: "Khuyến nghị các nhà phát triển trước tiên hãy bắt đầu từ cách sử dụng trực tiếp LLM API")

5. Workflow theo từng mẫu thực chiến và ví dụ

• Augmented LLM: Bổ sung các khả năng mở rộng tích hợp sẵn như tìm kiếm, kết nối công cụ, bộ nhớ, v.v. (thiết kế giao diện cụ thể và tài liệu hóa là rất quan trọng)
• Prompt Chaining: Chia một nhiệm vụ thành nhiều lời gọi LLM (nhiều bước) để đảm bảo độ rõ ràng và chính xác.
  • Ví dụ: tạo nội dung marketing → dịch, bản nháp tài liệu → rà soát → viết hoàn chỉnh
• Routing: Phân loại đầu vào rồi rẽ nhánh sang xử lý/công cụ phù hợp
  • Ví dụ: định tuyến theo loại yêu cầu khách hàng, chỉ chuyển câu hỏi khó sang mô hình hiệu năng cao
• Parallelization:
  • Sectioning: Chia công việc thành nhiều tác vụ con để xử lý đồng thời
  • Voting: Thử cùng một công việc nhiều lần để chọn ra kết quả tốt nhất
  • Ví dụ: rà soát lỗ hổng mã nguồn, tự động hóa đánh giá LLM
• Orchestrator-Workers: Agent điều phối chính phân phối và tổng hợp các tác vụ con.
  • Ví dụ: trong công việc lập trình phức tạp, chỉ phân phối các phần cần thiết theo thời gian thực; thu thập/tổng hợp nhiều nguồn dữ liệu
• Evaluator-Optimizer: Một LLM tạo câu trả lời, LLM khác đánh giá và phản hồi để cải thiện lặp đi lặp lại
  • Ví dụ: cải thiện lặp lại kết quả dịch, thu thập thông tin phức hợp

6. Các trường hợp áp dụng thực tế trong công nghiệp

• Hỗ trợ khách hàng: Tích hợp chatbot + công cụ, tự động hóa dữ liệu khách hàng/đơn hàng/hoàn tiền; tiêu chí thành công được xác định rõ là "giải quyết vấn đề". Đã có các tham chiếu doanh nghiệp như áp dụng mô hình tính phí usage-based trong thực tế.
• Coding agent: Lặp lại và cải thiện dựa trên phản hồi từ kiểm thử tự động, đã được chứng minh qua SWE-bench, v.v. Miền bài toán và chất lượng đầu ra có thể đo lường rõ ràng. Tuy vậy, luôn cần con người tham gia khâu rà soát cuối cùng.

7. Mẹo về tool prompt engineering (Phụ lục 2)

• Khuyến nghị định dạng dễ dùng cho LLM và phân bổ đủ token
• Mô tả công cụ thật rõ ràng (cách dùng, ví dụ, edge case, ranh giới, v.v.)
• Kiểm thử ⇒ cải thiện cách mô hình thực sự sử dụng công cụ (có thể dùng workbench, v.v.)
• Thiết kế theo kiểu poka-yoke để ngăn cả những sai sót nhỏ
• (Nguyên văn: "Một định nghĩa công cụ tốt nên bao gồm ví dụ sử dụng, edge case, yêu cầu định dạng đầu vào, và ranh giới rõ ràng với các công cụ khác.")

8. Các nguyên tắc cốt lõi

• Duy trì sự đơn giản (Keep it simple)
• Tính minh bạch trong quá trình lập kế hoạch (Planning) của agent là bắt buộc
• Tài liệu hóa và kiểm thử rõ ràng cho công cụ·giao diện
• Framework có lợi cho tốc độ ban đầu, nhưng nên giảm tối đa lớp trừu tượng và ưu tiên quyền kiểm soát trực tiếp