AI agent cho doanh nghiệp: chuẩn bị kỹ thuật trước khi triển khai
admin
Dạo gần đây, AI agent cho doanh nghiệp xuất hiện gần như trong mọi buổi trao đổi công nghệ mà chúng tôi tham gia. Nhưng khi ngồi làm việc cùng các đội kỹ thuật, chúng tôi nhận ra nhiều người vẫn chưa phân biệt rõ nó với chatbot hay một đoạn script tự động hóa quen thuộc. Bài này được viết từ góc nhìn của người đã trực tiếp đưa agent vào hệ thống thật. Chúng tôi sẽ nói agent là gì, nó khác chatbot ở đâu, và trước khi dùng thật cần chuẩn bị những gì.
AI agent khác gì chatbot hay script tự động hóa truyền thống
Chatbot thường trả lời theo luật cố định hoặc dựa vào RAG. Nó nhận câu hỏi, đối chiếu tài liệu rồi đưa ra câu trả lời. Khá hữu ích khi câu hỏi nằm trong phạm vi đã chuẩn bị sẵn. Nhưng khi người dùng hỏi ngoài kịch bản, nó thường lúng túng. Chúng tôi từng thử với một chatbot hỗ trợ khách hàng, chỉ cần đổi cách diễn đạt một chút là câu trả lời đã lệch hẳn.
Automation script thì chạy theo chuỗi bước đã định sẵn. Mọi thứ diễn ra đúng như lập trình viên đã viết. Chỉ cần tình huống khác đi một chút, script có thể dừng lại hoặc cho kết quả sai. Chúng tôi từng thấy một script đồng bộ dữ liệu chạy suôn sẻ suốt nhiều tháng, rồi dừng hẳn chỉ vì một trường ngày tháng đổi định dạng. Không ai phát hiện ngay, và dữ liệu thiếu hụt âm thầm trong gần hai tuần.
AI agent bổ sung hai khả năng mà hai loại trên không có. Thứ nhất là lập kế hoạch: agent tự chia nhỏ một mục tiêu lớn thành các bước cần làm. Thứ hai là sử dụng công cụ: gọi API, đọc file, chạy một đoạn code khi cần. Nhờ đó agent xử lý được những việc không có quy trình cố định từ trước. Tất nhiên, đổi lại, nó cũng khó đoán trước hơn, và đó chính là lý do việc chuẩn bị kỹ càng trở nên quan trọng.
Giống như khi học Android bằng Kotlin, bạn cần hiểu vòng đời của ứng dụng trước khi viết dòng code đầu tiên, việc triển khai AI agent cũng nên bắt đầu từ cơ chế vận hành bên trong. Chúng tôi thấy không ít đội ngũ tích hợp agent vào hệ thống thật khi chưa nắm rõ cách nó ra quyết định. Hậu quả thường là những lỗi khó lường, khó tái hiện và khó truy vết.
Những quy trình nội bộ phù hợp để thử nghiệm
Theo kinh nghiệm của chúng tôi, quy trình phù hợp để bắt đầu thường có ba đặc điểm. Thứ nhất, nó xử lý thông tin từ nhiều nguồn khác nhau. Thứ hai, nó cần phán đoán dựa trên ngữ cảnh chứ không chỉ tra cứu. Thứ ba, nó diễn ra đủ thường xuyên để giá trị mang lại hiện rõ ràng.
Vài ví dụ dễ hình dung:
- Agent đọc và tóm tắt ticket hỗ trợ, rồi gợi ý hướng xử lý cho nhân viên.
- Agent theo dõi các pull request đang mở và tổng hợp thành bản tóm tắt cho buổi họp đứng hằng ngày.
- Agent đọc log lỗi hệ thống và giúp xếp thứ tự ưu tiên theo mức độ nghiêm trọng.
Mỗi việc trên vốn tốn khá nhiều thời gian đọc và tổng hợp thủ công. Khi giao phần này cho agent, đội ngũ có thể dồn sức vào những việc cần tư duy sâu hơn. Ở một dự án chúng tôi từng theo dõi, riêng khâu đọc log đã chiếm gần nửa thời gian trực hằng ngày của kỹ sư. Sau khi thử agent ở khâu này, thời gian đó giảm đi rõ rệt, và kỹ sư có thêm sức để xử lý nguyên nhân gốc của lỗi thay vì chỉ đọc triệu chứng.
Nếu muốn hình dung rõ hơn cách một quy trình như vậy được nối vào toàn bộ hoạt động, bạn có thể xem thêm giải pháp tự động hóa doanh nghiệp trên trang chủ Mona Media. Ở đó có các ví dụ về cách kết nối nhiều bước xử lý với nhau.
Các yếu tố kỹ thuật cần chuẩn bị
Một điểm dễ bị bỏ qua là quản lý context window. Agent thường phải đọc nhiều tài liệu mới ra quyết định đúng, nhưng context thì có giới hạn. Vì vậy cần thiết kế cách chọn lọc thông tin, chỉ đưa vào những gì thực sự liên quan đến bước đang làm. Nhồi tất cả vào một lúc chỉ khiến agent bị nhiễu và trả lời lệch hướng. Chúng tôi thường bắt đầu bằng việc liệt kê những nguồn dữ liệu thật sự cần cho từng loại quyết định, rồi mới quyết định cách đưa chúng vào.
Thứ hai là định nghĩa rõ từng hành động. Mỗi tool mà agent được phép gọi nên được mô tả bằng function với schema chuẩn, tên tham số rõ ràng và kiểu dữ liệu đầy đủ. Mô tả mập mờ sẽ khiến agent tự suy diễn, và đôi khi suy diễn sai. Một lỗi phổ biến chúng tôi gặp là tham số tên “id” nhưng không nói rõ đó là id của khách hàng hay của đơn hàng, và agent đã truyền nhầm.
Thứ ba là xử lý lỗi ngay từ đầu. Khi một tool gọi thất bại, hệ thống cần có phương án dự phòng: thử lại có giới hạn số lần, chuyển cho người xử lý, hoặc ghi nhận rồi dừng lại. Nếu không, agent có thể lặp đi lặp lại một hành động lỗi, hoặc đứng im không biết làm gì tiếp. Chúng tôi luôn đặt ngưỡng số lần thử lại cố định, vì một vòng lặp không có điểm dừng là nguyên nhân phổ biến nhất khiến mọi thứ vượt khỏi tầm kiểm soát.
Thứ tư là theo dõi chi phí. Hãy ghi log và đặt cảnh báo khi agent tiêu tốn token vượt ngưỡng cho phép. Chúng tôi từng gặp trường hợp một vòng lặp lỗi làm chi phí API tăng đột biến trong một buổi tối mà không ai hay biết. Sáng hôm sau, hóa đơn đã vượt xa dự kiến. Cảnh báo sớm sẽ tránh được chuyện đó, và cũng giúp đội ngũ biết được agent đang tiêu tốn tài nguyên vào đâu.
Bắt đầu nhỏ và đo hiệu quả rõ ràng
AI agent không phải thứ triển khai một lần rồi bỏ đó. Cách làm chúng tôi thường khuyên là chọn đúng một quy trình, đặt mục tiêu đo được cụ thể, rồi xây bản dùng thử trong một đến hai sprint. Ví dụ, mục tiêu có thể là rút ngắn thời gian tóm tắt ticket xuống còn một nửa, hoặc giảm số ticket bị phân loại sai. Sau đó đo tác động thực tế và mới quyết định có mở rộng hay không.
Cách tiếp cận này giúp đội ngũ vừa học được cách vận hành thật, vừa kiểm soát rủi ro. Nếu kết quả chưa như kỳ vọng, thiệt hại vẫn nằm trong phạm vi nhỏ và dễ điều chỉnh. Với chúng tôi, đó là điểm khởi đầu an toàn nhất khi đưa AI agent vào doanh nghiệp, và cũng là cách để những người trong đội không bị cuốn theo những lời hứa quá lớn về công nghệ mới.
