Mọi nhóm xây dựng AI agent đều gặp phải rào cản giống nhau.
Bạn bắt đầu với một prompt và vài công cụ.
Nó hoạt động.
Rồi yêu cầu tăng lên. Thêm nhiều trường hợp ngoại lệ. Thêm nhiều nhóm. Thêm nhiều rủi ro.
Bỗng nhiên "agent" của bạn là một system prompt dài 3.000 từ cố gắng làm năm việc cùng lúc.
Cách khắc phục không phải là thêm kỹ thuật prompt.
Mà là chọn đúng mẫu hình.
Dưới đây là 15 mẫu hình mà mọi hệ thống agentic trong sản xuất đều được xây dựng từ đó — và chính xác khi nào nên sử dụng từng mẫu.
Trước khi chọn mẫu hình
Không phải mọi tác vụ đều cần một agent.
Một tác vụ xứng đáng có agent khi:
→ Một lần gọi mô hình đơn lẻ không thể tạo ra kết quả đáng tin cậy
→ Mô hình phải lựa chọn giữa các công cụ hoặc nguồn dữ liệu trong thời gian chạy
→ Tác vụ cần lập kế hoạch, xác thực hoặc tinh chỉnh lặp đi lặp lại
→ Quy trình làm việc có độ bất định thực sự không thể mã hóa cứng được
Một tác vụ thường KHÔNG cần agent khi đường đi từ đầu vào đến đầu ra có thể dự đoán được.
Tóm tắt. Phân loại. Trích xuất đơn giản. Tạo mẫu theo khuôn mẫu.
Những việc này nhanh hơn, rẻ hơn và đáng tin cậy hơn khi gọi mô hình trực tiếp.
Bọc chúng trong một agent chỉ làm tăng độ trễ và điểm lỗi mà không mang lại lợi ích gì.
MẪU HÌNH 1 — Agent Đơn Lẻ
Điểm khởi đầu đơn giản và phổ biến nhất.
Một mô hình. Một system prompt. Một bộ công cụ có giới hạn.
Mô hình quyết định gọi công cụ nào, quan sát kết quả và tiếp tục cho đến khi có đủ thông tin để trả lời.
Ví dụ thực tế: Một agent hỗ trợ khách hàng tra cứu trạng thái đơn hàng, kiểm tra vận chuyển và tạo ticket nếu không thể giải quyết vấn đề — tất cả chỉ với 2-3 công cụ và một nhiệm vụ rõ ràng.
Sử dụng khi: tác vụ được xác định rõ ràng, bộ công cụ nhỏ và một agent có thể nắm giữ toàn bộ ngữ cảnh mà không bị nhầm lẫn.
Nó hỏng khi: bạn liên tục thêm công cụ và system prompt phát triển dài hơn một trang. Đó là dấu hiệu bạn cần một mẫu hình khác — không phải một prompt dài hơn.
MẪU HÌNH 2 — Đa Agent Tuần Tự
Các agent chuyên biệt chạy theo một thứ tự cố định. Đầu ra của mỗi agent là đầu vào cho agent tiếp theo.
Ví dụ thực tế: Một quy trình xem xét hợp đồng — một agent trích xuất nghĩa vụ, agent tiếp theo xác định rủi ro, agent thứ ba soạn thảo bản tóm tắt cho bộ phận mua sắm. Trình tự không bao giờ thay đổi.
Sử dụng khi: quy trình làm việc có các giai đoạn rõ ràng, có thể lặp lại và mỗi giai đoạn tạo ra chính xác những gì giai đoạn tiếp theo cần.
Nó hỏng khi: thứ tự thực sự cần thay đổi dựa trên những gì được tìm thấy trong quá trình xử lý. Các pipeline tuần tự giả định đường đi là cố định — nếu không, bạn cần một thứ gì đó linh hoạt hơn.
MẪU HÌNH 3 — Đa Agent Song Song
Các tác vụ con độc lập chạy đồng thời, sau đó được kết hợp thành một góc nhìn duy nhất.
Ví dụ thực tế: Một sự cố sản xuất lúc 2 giờ sáng. Ba agent điều tra nhật ký, số liệu và các bản triển khai gần đây cùng một lúc — không phải lần lượt — bởi vì mỗi phút đều quan trọng trong thời gian ngừng hoạt động.
Sử dụng khi: các tác vụ con thực sự độc lập và tốc độ là quan trọng.
Nó hỏng khi: các tác vụ thực sự phụ thuộc vào kết quả của nhau. Buộc công việc phụ thuộc chạy song song chỉ tạo ra các điều kiện cạnh tranh và ngữ cảnh không đầy đủ.
MẪU HÌNH 4 — Vòng Lặp
Lặp lại một chuỗi các bước cho đến khi đạt được điều kiện thoát.
Ví dụ thực tế: Một agent làm sạch dữ liệu phân tích dữ liệu CSV lộn xộn, đề xuất kế hoạch làm sạch, kiểm tra xem nó có đạt tiêu chuẩn chất lượng không và thử lại nếu không — lên đến một số vòng giới hạn.
Sử dụng khi: tác vụ cần nhiều lần thử và bạn có thể xác định một điều kiện dừng rõ ràng, có thể kiểm tra được.
Nó hỏng khi: không có điều kiện thoát đáng tin cậy. Nếu không có, bạn sẽ phải chịu chi phí vượt tầm kiểm soát và một hệ thống có thể không bao giờ kết thúc.
MẪU HÌNH 5 — Đánh Giá và Phê Bình
Một agent giám khảo xem xét đầu ra của agent khác, phê bình và đưa ra phản hồi cụ thể có thể thực hiện được.
Ví dụ thực tế: Một báo cáo được tạo ra được một agent "phê bình" riêng biệt xem xét, đánh dấu các tuyên bố yếu, thiếu bằng chứng hoặc các phần không rõ ràng trước khi nó đến tay con người.
Sử dụng khi: chất lượng quan trọng hơn tốc độ và bạn muốn có một ý kiến thứ hai được tích hợp vào hệ thống, không phải được gắn vào sau.
Nó hỏng khi: agent phê bình sử dụng cùng những điểm mù với agent tạo ra. Một người đánh giá được đào tạo trên các giả định tương tự sẽ không phát hiện ra những sai lầm giống nhau.
MẪU HÌNH 6 — Tinh Chỉnh Lặp Đi Lặp Lại
Một vòng phản hồi với ngưỡng điểm chất lượng. Agent tạo ra tiếp tục tinh chỉnh cho đến khi vượt qua mức đó.
Ví dụ thực tế: Một agent tạo nội dung tiếp thị tự chấm điểm bản nháp của mình so với hướng dẫn thương hiệu và tiếp tục viết lại cho đến khi đạt điểm chất lượng tối thiểu — không chỉ một lần kiểm tra đậu/rớt, mà là cải thiện theo cấp độ.
Sử dụng khi: chất lượng đầu ra thực sự thay đổi và "đủ tốt" có một ngưỡng có thể đo lường được.
Nó hỏng khi: hàm chấm điểm mơ hồ hoặc có thể bị lợi dụng. Nếu mô hình có thể tự tăng điểm mà không có cải thiện thực sự, vòng lặp chỉ đốt token.
MẪU HÌNH 7 — Điều Phối Viên
Một agent định tuyến trung tâm chuyển hướng các yêu cầu đến các agent chuyên biệt dựa trên những gì thực sự được yêu cầu.
Ví dụ thực tế: Các ticket hỗ trợ được định tuyến đến các chuyên gia thanh toán, kỹ thuật, tài khoản, vận chuyển hoặc gian lận — mỗi chuyên gia có ngữ cảnh hẹp thay vì một agent cố gắng biết mọi thứ.
Sử dụng khi: bạn có các loại yêu cầu thực sự khác nhau cần ngữ cảnh, công cụ hoặc logic quyết định khác nhau.
Nó hỏng khi: bản thân việc định tuyến trở nên mơ hồ. Nếu các yêu cầu không rơi gọn gàng vào một danh mục, điều phối viên trở thành một nút thắt cổ chai mới và nguồn gốc của việc định tuyến sai.
MẪU HÌNH 8 — Phân Rã Tác Vụ Theo Thứ Bậc
Một agent gốc chia một mục tiêu phức tạp thành các mục tiêu con nhỏ hơn, ủy quyền chúng cho các worker chuyên biệt, sau đó tổng hợp mọi thứ thành một câu trả lời.
Ví dụ thực tế: "Chúng ta nên mở rộng sang 3 quốc gia nào vào năm tới?" được chia thành phân tích cạnh tranh, nghiên cứu quy định, khả thi hậu cần và định cỡ thị trường — mỗi phần được xử lý bởi một chuyên gia khác nhau, sau đó được kết hợp.
Sử dụng khi: vấn đề quá rộng cho một lần suy luận nhưng lại phân chia rõ ràng thành các lĩnh vực chuyên môn độc lập.
Nó hỏng khi: các mục tiêu con không thực sự độc lập. Nếu các luồng công việc cần thông tin cho nhau trong thời gian thực, việc phân rã chúng từ đầu sẽ mất đi sự tương tác đó.
MẪU HÌNH 9 — Bầy Đàn
Nhiều agent chuyên biệt đóng góp vào một cuộc thảo luận chung, thách thức các giả định của nhau và một người điều phối tổng hợp một khuyến nghị cuối cùng.
Ví dụ thực tế: Công ty có nên ra mắt một gói đăng ký không? Các agent nghiên cứu, kỹ thuật, tài chính và hỗ trợ mỗi bên tranh luận quan điểm của mình qua nhiều vòng trước khi người điều phối cân nhắc các đánh đổi.
Sử dụng khi: không có một câu trả lời "đúng" duy nhất — bạn cần một quyết định được suy luận tốt, được định hình bởi các quan điểm thực sự cạnh tranh.
Nó hỏng khi: bạn cần một câu trả lời nhanh, xác định. Bầy đàn cố tình chậm và khám phá — công cụ sai nếu bạn cần tốc độ.
MẪU HÌNH 10 — ReAct (Suy Luận và Hành Động)
Agent xen kẽ giữa suy luận và hành động: quyết định điều tra gì, gọi một công cụ, quan sát kết quả, quyết định xem đã có đủ bằng chứng chưa.
Ví dụ thực tế: "Bộ xử lý hàng đợi có vẻ bị kẹt" — agent tìm kiếm tài liệu, kiểm tra tình trạng dịch vụ, đối chiếu các phát hiện và chỉ sau đó đề xuất một giải pháp. Đường điều tra không được xác định trước; nó phụ thuộc vào những gì nó tìm thấy trên đường đi.
Sử dụng khi: đường đi đến câu trả lời thực sự không thể được lập kế hoạch trước — nó phụ thuộc vào những gì mỗi bước tiết lộ.
Nó hỏng khi: các cuộc điều tra kéo dài mà không hội tụ. Luôn giới hạn số chu kỳ suy luận-hành động, nếu không bạn có nguy cơ khám phá vô hạn.
MẪU HÌNH 11 — Con Người Trong Vòng Lặp
Agent điều tra và đề xuất, nhưng con người đưa ra quyết định cuối cùng về bất cứ điều gì rủi ro hoặc mơ hồ.
Ví dụ thực tế: Phê duyệt hoàn tiền — các trường hợp rủi ro thấp, rõ ràng được tự động hóa. Số tiền lớn, dấu hiệu gian lận hoặc ngoại lệ chính sách sẽ tạm dừng để con người xem xét trước khi bất cứ điều gì được hoàn tất.
Sử dụng khi: quyết định mang rủi ro tài chính, pháp lý hoặc uy tín thực sự và tự động hóa hoàn toàn vẫn chưa thể chấp nhận được.
Nó hỏng khi: bạn coi đây chỉ là một tính năng UI thay vì một tính năng kiến trúc. Bạn cần trạng thái bền vững, phân công người đánh giá, xử lý thời gian chờ và các đường dẫn leo thang — không chỉ là một nút "tạm dừng".
MẪU HÌNH 12 — Lập Kế Hoạch và Thực Thi
Một agent lập kế hoạch tạo ra một kế hoạch có cấu trúc đầy đủ từ trước — có thể xem xét và sửa đổi — trước khi bất kỳ hành động nào được thực hiện. Sau đó, một người thực thi chạy qua các bước.
Ví dụ thực tế: "Thay đổi kích thước cụm worker từ 10 lên 20 phiên bản, xác minh hàng đợi được xử lý, cập nhật runbook." Toàn bộ kế hoạch có thể nhìn thấy trước khi thực thi bắt đầu, không giống như ReAct nơi đường đi xuất hiện từng bước một.
Sử dụng khi: bạn muốn kế hoạch có thể được xem xét hoặc phê duyệt trước khi bất kỳ hành động nào diễn ra — quan trọng đối với các hoạt động có hậu quả thực sự.
Nó hỏng khi: môi trường thay đổi nhanh hơn kế hoạch có thể thực thi. Một kế hoạch lỗi thời được thực thi một cách mù quáng còn tệ hơn không có kế hoạch nào.
MẪU HÌNH 13 — Suy Ngẫm
Agent đánh giá những thất bại của chính nó, suy ngẫm về những gì đã sai và mang ký ức đó vào lần thử tiếp theo.
Ví dụ thực tế: Một agent tạo mã viết một script, nó thất bại trong thời gian chạy, agent phân tích lỗi thực tế, ghi lại những gì cần sửa và thử lại — thông minh hơn sau mỗi lần thử thay vì lặp lại cùng một sai lầm.
Sử dụng khi: thất bại mang tính thông tin và tự sửa lỗi thực sự cải thiện lần thử tiếp theo.
Nó hỏng khi: các chế độ thất bại là ngẫu nhiên hoặc không liên quan đến nhau. Suy ngẫm chỉ hữu ích khi có một mẫu hình thực sự để học hỏi.
MẪU HÌNH 14 — Logic Tùy Chỉnh
Một sự kết hợp: mã xác định xử lý các quy tắc không bao giờ được sai, trong khi mô hình xử lý phán đoán, soạn thảo và xử lý ngoại lệ.
Ví dụ thực tế: Một quy trình hoàn tiền trong đó xác minh mua hàng và kiểm tra gian lận chạy dưới dạng các quy tắc xác định cứng — không bao giờ được ủy quyền cho mô hình — trong khi soạn thảo phản hồi khách hàng và đề xuất định tuyến vẫn mang tính agentic.
Sử dụng khi: quy trình làm việc có logic rẽ nhánh thực sự với hậu quả pháp lý hoặc tài chính và bạn cần chính xác về những gì là xác định so với những gì là linh hoạt.
Nó hỏng khi: các nhóm làm mờ ranh giới và để mô hình đưa ra các quyết định lẽ ra phải là các quy tắc được mã hóa cứng. Điều kiện đủ, quyền hạn và chuyển tiền không bao giờ chỉ nên do mô hình quyết định.
MẪU HÌNH 15 — Agent Hướng Sự Kiện
Agent không chờ được yêu cầu. Nó đăng ký một luồng sự kiện và hành động ngay khi một điều kiện được kích hoạt.
Ví dụ thực tế: Một agent phát hiện gian lận phản ứng ngay khi một sự kiện giao dịch đáng ngờ xảy ra — không phải khi một ticket hỗ trợ cuối cùng làm lộ nó, lúc đó thiệt hại đã xảy ra.
Sử dụng khi: thời điểm quan trọng hơn bất cứ điều gì khác và việc chờ đợi yêu cầu từ con người đồng nghĩa với việc bỏ lỡ cơ hội hành động.
Nó hỏng khi: các điều kiện kích hoạt được xác định kém. Một luồng sự kiện ồn ào với các trình kích hoạt mơ hồ biến thành một hệ thống liên tục báo động giả — hoặc tệ hơn, bỏ lỡ tín hiệu thực sự.
Lựa chọn mẫu hình — khớp với độ bất định, không phải sự cường điệu
Mẫu hình đúng khớp với hình dạng của độ bất định trong công việc của bạn:
→ Không chắc chắn nên dùng công cụ nào → Agent Đơn Lẻ hoặc ReAct
→ Không chắc chắn nên định tuyến ở đâu → Điều Phối Viên
→ Không chắc chắn về chất lượng → Đánh Giá & Phê Bình hoặc Tinh Chỉnh Lặp Đi Lặp Lại
→ Không chắc chắn về đường thực thi → Lập Kế Hoạch và Thực Thi hoặc ReAct
→ Không chắc chắn cách tự sửa lỗi → Suy Ngẫm hoặc Vòng Lặp
→ Không chắc chắn về rủi ro kinh doanh → Con Người Trong Vòng Lặp hoặc Logic Tùy Chỉnh
→ Không chắc chắn về cấu trúc vấn đề → Phân Rã Theo Thứ Bậc hoặc Bầy Đàn
→ Không thể chờ đợi yêu cầu → Agent Hướng Sự Kiện
Một bầy đàn không tiên tiến hơn một agent đơn lẻ nếu tác vụ chỉ cần một lần gọi công cụ đáng tin cậy.
Lập Kế Hoạch và Thực Thi không phải là một nâng cấp từ ReAct nếu kế hoạch của bạn trở nên lỗi thời vào bước thứ ba.
Các hệ thống sản xuất đáng tin cậy nhất không phải là những hệ thống tự động nhất.
Chúng đặt quyền tự động chính xác vào nơi nó tạo ra giá trị — và hạn chế nó ở mọi nơi khác.
10 quy tắc cho hệ thống agentic trong sản xuất
- Bắt đầu với mẫu hình nhỏ nhất có hiệu quả. Một agent đơn lẻ với các hợp đồng công cụ sạch sẽ sẽ tốt hơn một hệ thống đa agent với các hợp đồng yếu.
- Viết mô tả công cụ như các hợp đồng. Mô hình chỉ biết công cụ làm gì từ mô tả — không phải từ ý định của bạn.
- Giới hạn số lần lặp, lần gọi công cụ và chi phí cho mỗi yêu cầu. Một agent không có giới hạn ngân sách là một khoản nợ đang chờ xuất hiện trong hóa đơn.
- Ghi lại toàn bộ dấu vết hành động. Các lần gọi công cụ, đối số, đầu ra, quyết định cuối cùng. Nếu không có điều này, điều tra sự cố chỉ là phỏng đoán.
- Giữ các hành động không thể đảo ngược sau các kiểm tra xác định hoặc sự chấp thuận của con người. Đừng bao giờ để mô hình là rào cản duy nhất trước khi chuyển tiền hoặc thay đổi sản xuất.
- Đánh giá với các trường hợp thất bại thực tế, không chỉ các đường đi hạnh phúc. Tính đúng đắn trên đường đi hạnh phúc là một nguyên mẫu. Tính đúng đắn trên trường hợp ngoại lệ là một sản phẩm.
- Tách biệt các prompt theo trách nhiệm trước khi system prompt trở nên không thể đọc được. "Nhưng đừng làm X khi Y" len lỏi vào prompt của bạn có nghĩa là agent đang làm hai công việc.
- Coi các hệ thống đa agent như các hệ thống phân tán. Lỗi một phần, thời gian chờ, thử lại và khả năng quan sát là không thể thiếu.
- Đánh giá của mô hình không phải là sự thay thế cho xác thực xác định. Sử dụng giám khảo để cải thiện chất lượng. Sử dụng các bài kiểm tra và kiểm tra quyền hạn để thực thi tính đúng đắn.
- Ưu tiên mẫu hình đơn giản hơn — không phải vì đơn giản luôn tốt hơn, mà vì ngân sách phức tạp bạn tiết kiệm được có thể được chi cho các công cụ tốt hơn, prompt tốt hơn, đánh giá tốt hơn.
Đó là tất cả 15 mẫu hình.
Hầu hết các nhóm không thất bại vì họ chọn sai mẫu hình.
Họ thất bại vì họ không bao giờ hỏi độ bất định nào họ thực sự đang giải quyết.
Chọn mẫu hình. Khớp với hình dạng của vấn đề. Đừng thêm quyền tự động ở nơi nó không xứng đáng.
Nếu bài viết này hữu ích:
→ Đăng lại để chia sẻ với mọi kỹ sư đang xây dựng agent trong nhóm của bạn
→ Theo dõi @sairahul1 để biết thêm nhiều bài phân tích như thế này
→ Đánh dấu trang này — bạn sẽ quay lại mỗi khi bắt đầu một dự án agent mới
Tôi viết về AI, xây dựng sản phẩm và các hệ thống hoạt động mà không cần bạn.
