Kết hợp các primitives thành Augmented Call, Workflow, Agent

Sau khi đã xác định phần việc nào do Claude đảm nhiệm so với hệ thống hiện tại và con người, quyết định tiếp theo thuộc về mặt cấu trúc: sự tham gia của Claude sẽ có hình thái (shape) như thế nào?

Có 3 patterns để lựa chọn: Augmented LLM, Workflow, và Agent. Mỗi mô hình đứng ở một vị trí khác nhau trên 2 trục:

• Predictability: Mức độ có thể dự đoán trước của luồng công việc.

• Model autonomy: Mức độ quyền tự quyết mà bạn sẵn sàng giao cho model.

3 mô hình định hình sự tham gia của Claude

• Augmented LLM: Một lần gọi model đơn lẻ (single model invocation): bạn gửi request, model hoàn thành tác vụ, và code của bạn xử lý phần kết nối xung quanh. Bạn có thể thêm tool use, retrieval, hoặc extended thinking vào cuộc gọi đó, nhưng model vẫn chỉ làm một công việc có giới hạn trong một lần xử lý. Luồng điều khiển (control flow) không bao giờ phân nhánh dựa trên quyết định của model. Hãy dùng mô hình này khi tác vụ được xác định rõ ràng, đầu ra có thể kiểm chứng, và không có lý do gì để chia nhỏ công việc thành nhiều bước.

Định vị các use cases theo Predictability và Autonomy

• Augmented LLMs nằm ở góc Predictability cao, Autonomy thấp. Bạn biết rõ tác vụ, biết thế nào là chuẩn, và model thực thi nó đúng một lần.

• Workflows nằm ở dải giữa. Cấu trúc tổng thể có thể dự đoán trước, nhưng từng bước có thể chứa sự đánh giá của model theo cách được kiểm soát.

• Agents nằm ở góc Autonomy cao, Predictability thấp. Đây là pattern cần tìm đến khi việc liệt kê trước các bước là không thể hoặc là phần tốn kém nhất của bài toán: điều tra mở (open-ended investigation), công việc kéo dài (long-horizon work), và các tác vụ mà bước tiếp theo phụ thuộc vào kết quả của bước trước. Claude Code là một ví dụ đã chứng minh hiệu quả trên production: nó khám phá một codebase xa lạ, quyết định đọc file nào dựa trên những gì đã tìm thấy, và chạy các tác vụ kỹ thuật nhiều bước mà không ai có thể viết script trước. Đó là năng lực mà agents mở ra, nhưng chi phí đi kèm cũng rất thực tế. Đây là nơi các thất bại non-deterministic tập trung nhiều nhất trên production, bởi vì quỹ đạo của model chính là luồng điều khiển và không có ranh giới code nào để đặt cơ chế bảo vệ (guard).

Các Sub-patterns bên trong Workflows

Lựa chọn một workflow chưa định hình xong toàn bộ thiết kế. Có 4 hình thái mà một workflow có thể đảm nhận, và mỗi hình thái phản ánh một giả định khác nhau về cách các bước liên kết với nhau:

4 sub-patterns này không loại trừ lẫn nhau. Hầu hết các workflows trên production đều kết hợp nhiều hơn một mô hình. Lựa chọn đúng thường là phương án đơn giản nhất đáp ứng được mức độ chịu lỗi (error tolerance) và yêu cầu giám sát (observability) của tác vụ; chỉ nâng cấp mô hình khi dữ liệu production cho thấy phương án đơn giản hơn không đạt yêu cầu.

Khung quyết định lựa chọn Pattern: 5 yếu tố theo thứ tự

Hãy đi qua 5 yếu tố này theo đúng thứ tự. Với mỗi yếu tố, hãy hỏi liệu nó có loại trừ bất kỳ pattern nào trong 3 mô hình (Augmented LLM, Workflow, Agent) hay không. Yếu tố đầu tiên loại trừ một pattern chính là yếu tố quyết định.

Thử nghiệm Prompting trước khi cân nhắc Fine-tuning

Nếu prompting cảm thấy không ổn định, bản năng của nhiều kỹ sư là tìm đến fine-tuning. Với Claude, đó thường là bước đi sai lầm đầu tiên. Hãy đi theo thứ tự sau:

1. Tối ưu hóa prompt: Hầu hết các vấn đề về độ tin cậy đều là vấn đề về prompt.

2. Thêm tool use hoặc retrieval nếu chỉ dùng prompt là chưa đủ.

3. Chuyển sang pattern mạnh hơn như evaluator-optimizer nếu chất lượng vẫn chưa đạt yêu cầu.

4. Sau đó mới cân nhắc fine-tuning.

Fine-tuning chỉ thực sự có chỗ đứng trong các tình huống cụ thể:

• Tác vụ chạy ở volume cực lớn và chi phí inference là rào cản thực sự.

• Latency là yếu tố sống còn và một model chuyên biệt nhỏ hơn sẽ vượt trội hơn model chung được prompt.

• Đầu ra (output) cần tuân theo định dạng cố định và prompting không thể giải quyết một cách đáng tin cậy.

Ngoại trừ các trường hợp đó, fine-tuning sẽ khóa bạn vào một phiên bản model cố định và thu hẹp các lựa chọn của bạn. Hãy coi đó là bước cuối cùng trong một lộ trình có tính toán, chứ không phải biện pháp chữa cháy cho một prompt chưa hoạt động tốt.

Lưu ý về tính khả dụng: Fine-tuning Claude hiện chưa được mở rộng rãi. Quyền truy cập bị hạn chế, thay đổi tùy theo model và delivery route. Hãy xác nhận lại các tùy chọn hiện tại với đội ngũ Anthropic trước khi đề xuất lộ trình này cho đối tác.

Kiến trúc dựa trên Skills (Skills-based architecture) như một lựa chọn đóng gói

Bên cạnh việc chọn pattern, bạn cần quyết định cách năng lực được đóng gói. Có 3 lựa chọn trên một dải phổ:

1. Prompt-only solution: Chỉ sử dụng câu lệnh hướng dẫn đơn thuần.

2. Direct tool use: Model gọi trực tiếp các hàm trong code của bạn.

3. Skills-based architecture: Một Skill có quản lý phiên bản, tái sử dụng được, đóng gói quy trình, hướng dẫn và các scripts thành một đơn vị duy nhất được quản trị.

Hãy tìm đến Skill khi cùng một quy trình chạy lặp đi lặp lại nhiều lần, cần phân phối qua nhiều team/sản phẩm, hoặc bắt buộc phải quản lý phiên bản (versioned) và quản trị (governed).

Chi phí · Độ phức tạp · Rủi ro

• Chi phí (Cost): Agent không tự động tốn nhiều tiền hơn Workflow. Thứ đẩy chi phí lên là lượng context tích tụ qua cuộc trò chuyện và số lượng cuộc gọi model. Một workflow thiết kế kém có thể tốn kém hơn một agent được thiết kế tốt.

• Độ phức tạp (Complexity): Workflow và Agent thất bại theo những cách khác nhau. Workflow thất bại khi một bước trong code của bạn bị lỗi. Agent thất bại khi model đưa ra một quyết định sai lầm đâu đó trong một chuỗi các lượt thoại. Kiểu thất bại thứ hai khó phát hiện và chẩn đoán hơn nhiều.

• Rủi ro (Risk): Quyền tự quyết của Agent chính là phạm vi trách nhiệm rủi ro của bạn. Agent có thể làm bất cứ điều gì mà tools của nó cho phép, bao gồm cả những sự kết hợp mà bạn chưa từng thử nghiệm. Quyền hạn của tool càng rộng, khoảng không gian xảy ra lỗi càng lớn. Hãy giữ entry point của tool hẹp nhất có thể dựa trên yêu cầu tác vụ.