AI agent cho doanh nghiệp đang trở thành chủ đề được nhắc đến nhiều trong các dự án nội bộ. Khi nhận được yêu cầu này, điều đầu tiên đội ngũ chúng tôi thường hỏi khách hàng là: agent khác gì so với một chatbot thông thường? Câu trả lời nằm ở cách hệ thống được thiết kế. Chatbot chờ người dùng gõ câu hỏi rồi trả lời. Agent thì có mục tiêu, theo dõi trạng thái và tự hành động khi một điều kiện nào đó xảy ra.
Bài viết này chia sẻ góc nhìn kỹ thuật từ kinh nghiệm triển khai thực tế. Nếu bạn là lập trình viên hoặc kỹ sư đang được giao nhiệm vụ này, chúng tôi hy vọng những kinh nghiệm dưới đây sẽ giúp bạn tránh được một số cái bẫy quen thuộc.
Chatbot và AI agent khác nhau ở đâu?
Có thể hình dung chatbot như một nhân viên lễ tân: bạn hỏi, họ trả lời, xong việc. Agent giống một nhân viên vận hành hơn. Nó được giao một mục tiêu, có quyền truy cập một số hệ thống, và tự quyết định bước tiếp theo.
Chatbot hoạt động thụ động. Nó không có trạng thái nào tồn tại ngoài cuộc hội thoại hiện tại. Khi người dùng đóng cửa sổ chat, mọi thứ coi như kết thúc.
Agent thì khác. Ví dụ, một hệ thống chăm sóc ticket nội bộ mà chúng tôi từng xây dựng có quy tắc đơn giản: nếu ticket chưa được gán người xử lý sau 30 phút, agent tự động chuyển (escalate) lên trưởng nhóm. Không ai phải nhắc, không ai phải mở trang theo dõi. Khi chỉ số hạ tầng vượt ngưỡng, agent gửi cảnh báo và tạo incident ticket.
- Đọc và ghi dữ liệu: agent truy cập được cơ sở dữ liệu và các API nội bộ, không chỉ sinh câu trả lời bằng chữ.
- Kích hoạt workflow: agent có thể khởi chạy một chuỗi bước đã định nghĩa sẵn khi một sự kiện kích hoạt xảy ra.
Kiến trúc kỹ thuật của một AI agent cho doanh nghiệp
Qua nhiều dự án với các đội kỹ thuật khác nhau, chúng tôi nhận thấy một agent đủ tốt cho môi trường production thường có bốn lớp được tách bạch rõ ràng. Thiếu một trong số đó, hệ thống thường gặp vấn đề ngay khi tải tăng lên.
LLM core, tool-use và memory
LLM core đóng vai trò bộ não. Nó nhận ngữ cảnh hiện tại, phân tích và quyết định hành động tiếp theo. Tuy nhiên, LLM không nên được giao quyền tự do tuyệt đối. Vì vậy cần có lớp tool-use: một danh sách các hàm cụ thể mà agent được phép gọi, chẳng hạn get_order_status, update_ticket hay send_notification. Mỗi hàm cần có mô tả rõ ràng và schema tham số chính xác, vì LLM dựa vào chính những mô tả này để chọn công cụ phù hợp.
Memory chia làm hai loại. Short-term memory giữ ngữ cảnh trong một lần chạy workflow. Long-term memory lưu những kiến thức cần tồn tại qua nhiều phiên, ví dụ quy trình xử lý khiếu nại của một phòng ban cụ thể. Không nên nhồi tất cả vào context window, vì chi phí và độ trễ sẽ tăng rất nhanh.
Orchestrator cho tác vụ nhiều bước
Có những việc đơn giản như trả lời một câu hỏi, và có những việc phức tạp hơn nhiều, chẳng hạn tổng hợp báo cáo từ ba nguồn dữ liệu khác nhau, định dạng lại rồi gửi lên kênh Slack của phòng kinh doanh. Với loại việc thứ hai, cần một orchestrator đứng ra điều phối: xác định từng bước, theo dõi tiến độ, bắt lỗi ở từng bước và thử lại khi cần thiết.
Trong thực tế, chúng tôi đã dùng cả AgentExecutor của LangChain lẫn các state machine tự viết. Với workflow đơn giản, LangChain tiết kiệm được nhiều thời gian. Với workflow có nhiều nhánh rẽ và yêu cầu audit nghiêm ngặt, state machine tự viết cho phép kiểm soát rõ hơn từng trạng thái.
Nếu bạn muốn tham khảo thêm một hướng tiếp cận đã được đóng gói sẵn cho các tình huống quản trị doanh nghiệp, có thể xem giải pháp AI agent cho doanh nghiệp. Bài này bàn về nguyên lý, còn tài liệu kia đi vào các use case cụ thể.
Thách thức về tích hợp và bảo mật
Theo kinh nghiệm của đội ngũ, phần lớn sự cố production với AI agent không đến từ mô hình ngôn ngữ mà đến từ việc tích hợp và phân quyền. Agent có quyền càng rộng thì rủi ro càng lớn, và rủi ro này khó nhận ra cho đến khi có sự cố xảy ra.
Phân quyền tối thiểu
Nguyên tắc chúng tôi luôn áp dụng là agent chỉ được làm đúng những gì nó cần. Điều này cần được thực hiện ở hai tầng. Ở tầng prompt, mô tả rõ phạm vi công việc để LLM tự giới hạn hành vi. Nhưng prompt không phải là hàng rào bảo mật thật sự, vì nó có thể bị vượt qua. Do đó tầng hạ tầng cần có kiểm soát truy cập theo vai trò (role-based access control) cho từng công cụ, để ngay cả khi LLM quyết định sai, hệ thống vẫn chặn được hành động ngoài phạm vi.
Quyền của agent cũng nên được rà soát định kỳ như quyền của một người dùng thông thường. Có những quyền được cấp lúc thử nghiệm rồi quên thu hồi, và đó chính là lỗ hổng dễ bị bỏ qua nhất.
Xử lý lỗi và tránh vòng lặp vô hạn
Một tình huống chúng tôi gặp khá thường xuyên: agent thử gọi một công cụ, nhận lỗi, thử lại, lại lỗi, rồi cứ thế lặp. Mỗi vòng lặp tiêu tốn token và có thể gây lỗi dây chuyền (cascade failure) lên các hệ thống phía sau. Cách xử lý cần có ba thành phần. Thứ nhất là giới hạn số bước tối đa cho mỗi workflow. Thứ hai là circuit breaker, tức là ngừng gọi một công cụ khi nó liên tục thất bại trong một khoảng thời gian. Thứ ba là hàng đợi thư chết (dead letter queue) để ghi lại những workflow lỗi, phục vụ việc xem xét sau.
Ngoài ra, nên ghi log đầy đủ từng quyết định của agent. Khi có sự cố, bạn cần biết agent đã suy luận gì và đã gọi công cụ nào, chứ không chỉ thấy kết quả cuối cùng.
Để hiểu thêm về cách đặt tiêu chuẩn kỹ thuật cho quy trình phát triển phần mềm, bạn có thể tham khảo CMMI level 5, nơi trình bày các cấp độ trưởng thành quy trình khá chi tiết. Phần kiến trúc tích hợp nội bộ được bàn kỹ hơn trong tích hợp AI agent vào hệ thống nội bộ: kiến trúc chuẩn. Nếu bạn đang đi từ tự động hóa đơn giản lên AI, bài từ script tự động hóa đến ứng dụng AI trong doanh nghiệp sẽ phù hợp hơn.
Các thành phần cần chú ý
Khi thiết kế, chúng tôi thường đối chiếu lại bốn lớp chính dưới đây. Mỗi lớp có một lưu ý riêng mà nếu bỏ qua sẽ dễ gây lỗi về sau.
- LLM core: nên đặt temperature thấp để kết quả ổn định hơn khi xử lý nghiệp vụ.
- Tool registry: mô tả và schema càng rõ, LLM càng ít chọn nhầm công cụ.
- Memory: tách biệt short-term và long-term ngay từ đầu, đừng gộp chung.
- Orchestrator: giới hạn số bước và xử lý lỗi là bắt buộc, không phải tính năng tùy chọn.
Lời kết
AI agent nội bộ chỉ tạo ra giá trị thật khi được thiết kế với kiến trúc đúng và phạm vi công việc rõ ràng. Lời khuyên chúng tôi thường đưa ra cho các đội mới bắt đầu là chọn một use case thiên về đọc dữ liệu trước, đo lường tác động thực tế, rồi mới mở rộng sang các hành động ghi dữ liệu kèm theo guardrail phù hợp. Đi chậm ở giai đoạn đầu thường giúp tiết kiệm nhiều công sửa lỗi về sau.