
AI Agent, chìa khóa giúp quy mô kinh doanh tăng gấp trăm lần
Tuyển chọn TechFlowTuyển chọn TechFlow

AI Agent, chìa khóa giúp quy mô kinh doanh tăng gấp trăm lần
Hướng dẫn thực hành xây dựng Agent thông minh có thể sử dụng được.
Bài viết: vas
Biên dịch: AididiaoJP, Foresight News
AI không phải là phép màu, nhưng cũng chẳng đơn giản đến mức "chỉ cần dựng một chương trình AI, mọi thứ tự động hoàn tất, rồi ngồi chờ thu lợi". Phần lớn mọi người thực ra không hiểu rõ AI thực sự là gì.
Và những người thực sự hiểu (dưới 5%) khi tự tay xây dựng, thường lại thất bại. Trí tuệ nhân tạo sẽ sinh ra "ảo giác", quên mất mình đang ở bước nào giữa chừng, hoặc gọi sai công cụ vào lúc không nên dùng. Nó hoạt động hoàn hảo khi trình diễn, nhưng vừa đưa vào môi trường sản xuất lập tức sụp đổ.
Tôi đã triển khai các hệ thống AI hơn một năm nay. Sự nghiệp phần mềm của tôi bắt đầu tại Meta, nhưng nửa năm trước tôi nghỉ việc để thành lập một công ty chuyên triển khai các tác nhân AI (agent) sử dụng được trong thực tế cho doanh nghiệp. Hiện tại doanh thu định kỳ hàng năm của chúng tôi đạt 3 triệu USD và vẫn đang tăng trưởng. Không phải vì chúng tôi thông minh hơn người khác, mà là vì chúng tôi đã trải qua vô số lần thử – sai – thất bại, cuối cùng mới tìm ra công thức thành công.
Dưới đây là tất cả những điều tôi học được trong quá trình xây dựng các tác nhân thực sự hữu ích. Dù bạn là người mới bắt đầu, chuyên gia hay ở giữa hai thái cực này, những kinh nghiệm này đều có thể áp dụng.
Bài học 1: Ngữ cảnh là tất cả
Nghe có vẻ hiển nhiên, và có lẽ bạn đã từng nghe điều này. Nhưng chính vì tầm quan trọng quá lớn nên cần phải nhấn mạnh lại. Nhiều người nghĩ rằng xây dựng tác nhân chỉ đơn giản là nối các công cụ lại với nhau: chọn một mô hình, mở quyền truy cập cơ sở dữ liệu, rồi buông tay. Cách làm này chắc chắn sẽ thất bại ngay lập tức, vì vài lý do:
Tác nhân không biết đâu là điểm then chốt. Nó không nhớ được chuyện xảy ra năm bước trước, chỉ thấy được bước hiện tại, rồi đoán xem tiếp theo nên làm gì (và thường xuyên đoán sai), cuối cùng trông cậy vào may rủi.
Chính yếu tố ngữ cảnh thường là ranh giới giữa một tác nhân trị giá hàng triệu đô la và một tác nhân vô giá trị. Bạn cần tập trung tối ưu hóa những khía cạnh sau:
Tác nhân ghi nhớ điều gì: không chỉ nhiệm vụ hiện tại, mà còn toàn bộ lịch sử dẫn đến trạng thái hiện tại. Ví dụ khi xử lý ngoại lệ hóa đơn, tác nhân cần biết: ngoại lệ phát sinh thế nào, ai gửi hóa đơn gốc, chính sách nào áp dụng, lần trước nhà cung cấp này gặp vấn đề đã xử lý ra sao. Thiếu những dữ liệu lịch sử này, tác nhân chỉ đang đoán mò — tệ hơn cả không dùng tác nhân. Bởi nếu để con người xử lý, vấn đề có thể đã được giải quyết từ lâu. Đây cũng là lý do tại sao nhiều người phàn nàn “AI thật khó dùng”.
Cách thông tin lưu chuyển: Khi bạn có nhiều tác nhân, hoặc một tác nhân xử lý quy trình đa bước, thông tin phải được truyền chính xác giữa các giai đoạn, không bị mất mát, sai lệch hay hiểu nhầm. Tác nhân phân loại yêu cầu phải truyền ngữ cảnh sạch, có cấu trúc sang cho tác nhân giải quyết vấn đề. Nếu bàn giao không chặt chẽ, phía sau sẽ rối tung. Điều này nghĩa là mỗi bước đều phải có đầu vào và đầu ra có cấu trúc, có thể kiểm chứng. Một ví dụ là chức năng /compact trong Claude Code, cho phép truyền ngữ cảnh giữa các phiên LLM khác nhau.
Kiến thức chuyên môn của tác nhân về lĩnh vực kinh doanh: Một tác nhân xử lý rà soát hợp đồng pháp lý phải hiểu rõ điều khoản nào quan trọng, đánh giá rủi ro ra sao, chính sách thực tế của công ty là gì. Bạn không thể ném đống tài liệu vào đó rồi mong nó tự nhận ra điểm mấu chốt — trách nhiệm đó thuộc về bạn. Và trách nhiệm của bạn bao gồm: cung cấp tài nguyên cho tác nhân theo cách có cấu trúc, để nó thực sự sở hữu kiến thức chuyên ngành.
Dấu hiệu của quản lý ngữ cảnh kém: Tác nhân gọi lại cùng một công cụ vì quên mất câu trả lời đã có; gọi sai công cụ do nhận thông tin sai; đưa ra quyết định mâu thuẫn với các bước trước; thậm chí luôn coi mỗi nhiệm vụ như hoàn toàn mới, bất chấp các mẫu hình rõ ràng từ những nhiệm vụ tương tự trước đó.
Quản lý ngữ cảnh tốt khiến tác nhân giống như một chuyên gia kinh doanh dày dạn: nó tự thiết lập mối liên hệ giữa các thông tin khác nhau, mà không cần bạn phải nói rõ từng mối quan hệ.
Ngữ cảnh chính là yếu tố phân biệt giữa “tác nhân chỉ dùng để trình diễn” và “tác nhân vận hành thực tế, tạo ra kết quả trong môi trường sản xuất”.
Bài học 2: Tác nhân AI là bộ khuếch đại năng suất
Quan điểm sai lầm: “Có nó rồi thì ta không cần tuyển người nữa.”
Quan điểm đúng: “Có nó rồi, ba người có thể làm việc của mười lăm người trước đây.”
Tác nhân cuối cùng sẽ thay thế một phần lao động con người, phủ nhận điều này chỉ là tự lừa dối bản thân. Nhưng mặt tích cực là: tác nhân không thay thế phán đoán của con người, mà loại bỏ những ma sát xung quanh phán đoán đó — như tìm kiếm tài liệu, thu thập dữ liệu, đối chiếu chéo, định dạng, phân phối nhiệm vụ, nhắc nhở theo dõi, v.v.
Ví dụ: đội tài chính vẫn cần ra quyết định cho các trường hợp bất thường, nhưng nhờ có tác nhân, họ không còn phải dành 70% thời gian tuần quyết toán để tìm giấy tờ thiếu, mà có thể dùng 70% thời gian đó để thực sự giải quyết vấn đề. Tác nhân hoàn tất mọi công việc nền tảng, con người chỉ cần phê duyệt cuối cùng. Theo kinh nghiệm phục vụ khách hàng của tôi, thực tế là doanh nghiệp không vì thế mà cắt giảm nhân sự. Nội dung công việc của nhân viên thay đổi, từ các thao tác thủ công nhàm chán sang các nhiệm vụ có giá trị cao hơn — ít nhất là hiện tại. Dĩ nhiên, về dài hạn, khi AI tiến xa hơn, tình hình này có thể thay đổi.
Các công ty thực sự hưởng lợi từ tác nhân không phải những nơi muốn loại bỏ con người khỏi quy trình, mà là những nơi nhận ra: phần lớn thời gian nhân viên bị tiêu tốn vào “công việc chuẩn bị”, chứ không phải vào phần tạo ra giá trị thực sự.
Thiết kế tác nhân theo hướng này, bạn sẽ không còn phải vật lộn với “độ chính xác”: tác nhân làm điều nó giỏi, con người tập trung vào điều con người giỏi.
Điều này cũng có nghĩa bạn có thể triển khai nhanh hơn. Không cần tác nhân xử lý mọi trường hợp cực đoan, chỉ cần nó giải quyết tốt các trường hợp phổ biến, đồng thời chuyển các ngoại lệ phức tạp cho con người — kèm theo đầy đủ ngữ cảnh để con người có thể giải quyết nhanh chóng. Ít nhất, đây là cách nên làm ở thời điểm hiện tại.
Bài học 3: Quản lý bộ nhớ và trạng thái
Việc tác nhân lưu trữ thông tin như thế nào trong một nhiệm vụ và giữa các nhiệm vụ, quyết định khả năng mở rộng quy mô của nó.
Có ba mô hình phổ biến:
Tác nhân độc lập: Xử lý toàn bộ quy trình từ đầu đến cuối. Loại này dễ xây dựng nhất vì mọi ngữ cảnh nằm tại một chỗ. Nhưng khi quy trình dài ra, quản lý trạng thái sẽ trở thành thách thức: tác nhân phải nhớ quyết định ở bước ba, để dùng đến khi thực hiện bước mười. Nếu cửa sổ ngữ cảnh đầy, hoặc cấu trúc bộ nhớ sai, các quyết định sau sẽ thiếu thông tin ban đầu, dẫn đến lỗi.
Tác nhân song song: Đồng thời xử lý các phần khác nhau của cùng một vấn đề. Nhanh hơn, nhưng phát sinh vấn đề phối hợp: kết quả hợp nhất thế nào? Nếu hai tác nhân đưa ra kết luận mâu thuẫn thì sao? Cần có giao thức rõ ràng để tổng hợp thông tin và giải quyết xung đột. Thường cần thêm một “trọng tài” (người hoặc một LLM khác) để xử lý xung đột hoặc điều kiện đua tranh.
Tác nhân cộng tác: Truyền công việc theo thứ tự. Tác nhân A phân loại, truyền cho B nghiên cứu, rồi tới C thực thi giải pháp. Mô hình này phù hợp với các quy trình có các giai đoạn rõ ràng, nhưng khâu bàn giao dễ gặp lỗi nhất. Những gì tác nhân A học được phải được truyền sang tác nhân B dưới định dạng có thể dùng trực tiếp.
Sai lầm phổ biến của đa số người là coi các mô hình này như “giải pháp kỹ thuật”. Thực tế, chúng là các quyết định kiến trúc, trực tiếp xác định giới hạn năng lực của tác nhân bạn.
Ví dụ, nếu bạn muốn xây dựng một tác nhân xử lý phê duyệt hợp đồng bán hàng, bạn phải quyết định: để một tác nhân chịu trách nhiệm toàn bộ, hay thiết kế một tác nhân định tuyến, phân phát nhiệm vụ cho các tác nhân chuyên biệt như xét duyệt giá, pháp chế, phê duyệt cấp cao? Chỉ khi bạn hiểu rõ quy trình kinh doanh thực tế, hy vọng rằng cuối cùng bạn cũng dạy được quy trình đó cho tác nhân của mình.
Chọn thế nào? Phụ thuộc vào độ phức tạp từng bước, lượng ngữ cảnh cần truyền giữa các giai đoạn, và việc các bước có cần phối hợp thời gian thực hay thực hiện tuần tự.
Nếu chọn sai kiến trúc, bạn có thể tốn cả vài tháng để gỡ lỗi những vấn đề vốn dĩ không phải lỗi. Đó thực chất là sự lệch pha giữa thiết kế của bạn, vấn đề bạn muốn giải quyết và giải pháp bạn đưa ra.
Bài học 4: Chủ động chặn ngoại lệ, chứ không báo cáo sau sự kiện
Khi làm hệ thống AI, phản ứng đầu tiên của nhiều người thường là: làm một bảng điều khiển (dashboard), hiển thị thông tin để mọi người thấy chuyện gì đang xảy ra. Xin hãy đừng làm bảng điều khiển nữa.
Bảng điều khiển chẳng có tác dụng gì.
Đội tài chính đã biết có hóa đơn thiếu, đội bán hàng cũng biết có hợp đồng đang kẹt ở pháp chế.
Tác nhân nên trực tiếp chặn vấn đề ngay khi nó xảy ra, chuyển cho người phụ trách giải quyết, đồng thời cung cấp đầy đủ mọi thông tin cần thiết, và thực hiện ngay lập tức.
Hóa đơn đến nhưng hồ sơ không đủ? Đừng chỉ ghi vào báo cáo. Đánh dấu ngay, xác định rõ ai cần bổ sung tài liệu gì, chuyển vấn đề kèm ngữ cảnh đầy đủ (nhà cung cấp, số tiền, chính sách áp dụng, thiếu gì cụ thể) cho người đó. Đồng thời ngăn giao dịch này hạch toán, cho đến khi vấn đề được giải quyết. Bước này rất quan trọng, nếu không, vấn đề sẽ rò rỉ khắp tổ chức, và bạn không kịp khắc phục.
Phê duyệt hợp đồng chậm quá 24 giờ chưa có phản hồi? Đừng đợi tới cuộc họp tuần mới nhắc. Tự động nâng cấp, kèm chi tiết giao dịch, giúp người phê duyệt có thể ra quyết định nhanh mà không cần tra cứu khắp nơi. Phải tạo cảm giác khẩn trương.
Nhà cung cấp không hoàn thành mốc quan trọng đúng hạn? Đừng chờ ai phát hiện. Tự động kích hoạt kế hoạch dự phòng, khởi động quy trình ứng phó trước cả khi ai nhận ra vấn đề.
Trách nhiệm của tác nhân AI là: khiến vấn đề không thể bị phớt lờ, và việc giải quyết phải cực kỳ dễ dàng.
Hãy trực diện phơi bày vấn đề, chứ không gián tiếp trình bày qua bảng điều khiển.
Điều này ngược lại với cách đa số công ty dùng AI: họ dùng AI để “thấy” vấn đề, còn bạn nên dùng AI để “ép buộc” giải quyết vấn đề — và phải nhanh. Khi tỷ lệ giải quyết gần đạt 100%, lúc đó hãy cân nhắc làm bảng điều khiển để xem xét.
Bài học 5: So sánh kinh tế: Tác nhân AI vs SaaS phổ quát
Doanh nghiệp cứ mua các công cụ SaaS mà chẳng ai dùng là có lý do.
SaaS dễ mua: có demo, có báo giá, có ô tích trên danh sách yêu cầu. Có người phê duyệt là coi như việc xong (dù thực tế thường không phải vậy).
Mua SaaS AI tệ nhất ở chỗ: nó thường chỉ nằm đó. Nó không hòa nhập vào quy trình làm việc thực tế, trở thành một hệ thống khác cần đăng nhập. Bạn bị ép phải di chuyển dữ liệu, một tháng sau lại thêm một nhà cung cấp để quản lý. 12 tháng sau nó bị bỏ không dùng, nhưng bạn không thể loại bỏ vì chi phí chuyển đổi quá cao, kết quả là gánh “nợ công nghệ”.
Tác nhân AI tùy chỉnh, xây trên hệ thống hiện có của bạn, sẽ loại bỏ hoàn toàn vấn đề này.
Nó chạy trong các công cụ bạn đã dùng, không tạo nền tảng làm việc mới, mà giúp hoàn thành công việc hiện tại nhanh hơn. Tác nhân xử lý nhiệm vụ, con người chỉ xem kết quả.
So sánh chi phí thực sự không phải “chi phí phát triển vs phí bản quyền”, mà là logic đơn giản hơn:
SaaS tích lũy “nợ công nghệ”: Mỗi khi mua một công cụ, bạn thêm một tích hợp cần bảo trì, một hệ thống sớm muộn sẽ lỗi thời, một nhà cung cấp có thể bị mua lại/thay đổi mô hình/ngừng hoạt động.
Tác nhân tự xây tích lũy “năng lực”: Mỗi lần cải tiến khiến hệ thống thông minh hơn, mỗi quy trình mới mở rộng thêm khả năng. Khoản đầu tư mang lại lợi nhuận kép, chứ không mất giá theo thời gian.
Vì vậy, suốt một năm qua tôi luôn nói: SaaS AI phổ quát không có tương lai. Số liệu ngành cũng đang chứng minh điều này: đa số doanh nghiệp mua SaaS AI ngừng dùng trong vòng 6 tháng và hoàn toàn không thấy tăng năng suất. Những bên thực sự hưởng lợi từ AI đều là các công ty sở hữu tác nhân tùy chỉnh, dù tự phát triển hay thuê bên thứ ba.
Đây cũng là lý do vì sao các công ty sớm nắm bắt tác nhân sẽ có lợi thế cấu trúc dài hạn: họ đang xây dựng cơ sở hạ tầng ngày càng mạnh lên. Những người khác chỉ đang thuê các công cụ rồi sớm muộn cũng phải thay. Trong thời đại lĩnh vực này thay đổi từng tháng, mỗi tuần lãng phí đều gây tổn thất nghiêm trọng cho lộ trình sản phẩm và toàn bộ hoạt động kinh doanh của bạn.
Bài học 6: Triển khai phải nhanh
Nếu dự án tác nhân AI của bạn cần lên kế hoạch một năm mới triển khai, thì bạn đã thua rồi.
Kế hoạch không theo kịp biến động. Quy trình bạn thiết kế có thể không phù hợp với cách làm việc thực tế, và các trường hợp ngoại lệ bạn chưa lường tới thường lại là quan trọng nhất. Mười hai tháng sau, lĩnh vực AI có thể đã thay đổi hoàn toàn, và sản phẩm bạn làm ra có thể đã lỗi thời.
Tối đa 3 tháng, phải đưa vào môi trường sản xuất.
Trong thời đại thông tin bùng nổ này, năng lực thực sự nằm ở việc biết cách tận dụng hiệu quả thông tin và cộng tác với nó, chứ không chống lại nó. Phải thực sự hành động: xử lý nhiệm vụ thật, ra quyết định thật, để lại dấu vết có thể truy xuất.
Tôi thấy vấn đề phổ biến nhất là: các đội phát triển nội bộ thường ước lượng dự án AI đáng lẽ 3 tháng thành 6–12 tháng. Hoặc tệ hơn — miệng nói 3 tháng, nhưng khi bắt tay vào lại viện đủ “lý do bất ngờ” để kéo dài vô hạn. Cũng không hoàn toàn do lỗi họ, lĩnh vực AI quả thực phức tạp.
Vì vậy bạn cần những kỹ sư thực sự hiểu AI: người hiểu cách AI mở rộng quy mô, từng thấy các vấn đề trong môi trường thực tế, rõ ràng về năng lực và giới hạn của AI. Hiện nay có quá nhiều lập trình viên “nửa vời”, tưởng rằng AI có thể làm mọi thứ — cách thực tế rất xa. Nếu bạn là một kỹ sư phần mềm muốn tham gia lĩnh vực ứng dụng AI doanh nghiệp, bạn phải nắm vững ranh giới thực tế của năng lực AI.
Tóm tắt
Xây dựng tác nhân dùng được, chìa khóa nằm ở những điểm sau:
Ngữ cảnh là tất cả: Một tác nhân không có ngữ cảnh tốt chỉ là máy tạo số ngẫu nhiên đắt tiền. Phải làm tốt luồng thông tin, duy trì bộ nhớ, nhúng kiến thức chuyên ngành. Trước đây mọi người cười nhạo “kỹ sư prompt”, giờ “kỹ sư ngữ cảnh” chính là phiên bản 2.0 của nó.
Thiết kế để “tăng hiệu quả”, chứ không phải “thay thế”: để con người làm điều con người giỏi, để tác nhân dọn đường, giúp con người tập trung hơn.
Kiến trúc quan trọng hơn lựa chọn mô hình: Dùng tác nhân độc lập, song song hay cộng tác — quyết định này quan trọng hơn nhiều so với việc chọn mô hình nào. Trước tiên phải làm đúng kiến trúc.
Chặn và giải quyết, chứ không báo cáo và nhìn lại: Bảng điều khiển là “nghĩa địa” của các vấn đề. Hãy xây dựng hệ thống buộc vấn đề phải được giải quyết nhanh chóng.
Triển khai nhanh, cải tiến liên tục: Tác nhân tốt nhất là cái đang chạy trong môi trường sản xuất và không ngừng được cải thiện, chứ không phải cái vẫn đang trong giai đoạn thiết kế. (Và phải sát sao với tiến độ của bạn)
Còn lại đều là chi tiết.
Công nghệ đã sẵn sàng, nhưng có lẽ bạn chưa.
Hiểu được điều này, bạn có thể nhân quy mô doanh nghiệp lên 100 lần.
Chào mừng tham gia cộng đồng chính thức TechFlow
Nhóm Telegram:https://t.me/TechFlowDaily
Tài khoản Twitter chính thức:https://x.com/TechFlowPost
Tài khoản Twitter tiếng Anh:https://x.com/BlockFlow_News














