Một công ty phát triển AI agent là đơn vị thiết kế, xây dựng và vận hành các software agent — những hệ thống dùng large language model để lập kế hoạch cho một tác vụ, gọi tool và API, rồi hoàn thành công việc nhiều bước với rất ít giám sát của con người. Nó không giống một shop phần mềm thông thường chỉ gắn thêm một con chatbot. Agent ra quyết định ngay tại runtime, và chỉ riêng khác biệt đó thôi cũng nên thay đổi cách bạn đánh giá đơn vị mình định thuê.
Đây là cẩm nang cho người mua năm 2026. Nếu bạn đang so sánh các nhà cung cấp, đang scope một dự án, hay tự viết shortlist, checklist dưới đây được thiết kế để chấm điểm từng cái tên trong danh sách. Nó chấm đúng những thứ thật sự dự báo được liệu một agent có sống sót khi va vào production hay không — chứ không phải những thứ trông đẹp trong một buổi demo.
Vì sao thẩm định một công ty agent lại khác
Thẩm định một shop phần mềm bình thường chủ yếu xoay quanh tay nghề và khả năng giao hàng: code có sạch không, có kịp deadline không, giao tiếp có ổn không. Những thứ đó vẫn quan trọng. Nhưng một AI agent là một loại sản phẩm khác, và ba đặc tính của nó làm thay đổi cách đánh giá.
Thứ nhất, agent mang tính non-deterministic. Cùng một input có thể ra hành động khác nhau ở những lần chạy khác nhau. Một nhà cung cấp chỉ từng ship phần mềm tất định thường đánh giá thấp lượng công sức để làm một hệ thống xác suất chạy ổn định — các bộ eval, các guardrail, các đường fallback.
Thứ hai, agent hành động, không chỉ trả lời. Nó gửi email, cập nhật ticket, chuyển tiền. Bán kính thiệt hại của một con bug lớn hơn nhiều so với một dòng chữ sai trên trang web, nên kỷ luật của nhà cung cấp quanh phân quyền, testing và human-in-the-loop là mối quan tâm hạng nhất, không phải thứ có cũng được.
Thứ ba, agent gần như không bao giờ thật sự "xong". Model đổi, tool đổi, dữ liệu trôi (drift). Một công ty coi agent như một website scope cố định — build xong, giao một file zip, rồi biến mất — là đang bán cho bạn một khoản nợ. Câu hỏi đúng không chỉ là "họ build được không" mà còn là "sáu tháng nữa nó còn chạy không, và ai đang trông nó".
Giữ ba đặc tính này trong đầu khi bạn đi qua checklist. Mỗi điểm dưới đây tồn tại vì một trong ba đặc tính đó.
Checklist đánh giá 10 điểm
Chấm mỗi nhà cung cấp từ 0 đến 2 cho mỗi điểm (0 = không có bằng chứng, 1 = một phần, 2 = mạnh, có minh chứng). Một nhà cung cấp vượt được phần lớn các điểm này là hiếm; dùng điểm số để so sánh, đừng đòi hoàn hảo.
1. Họ đã ship agent lên production chưa — không phải demo?
Tín hiệu dự báo mạnh nhất. Ai cũng dựng được một buổi demo bóng bẩy nơi happy path chạy đúng đúng một lần trên sân khấu. Hãy hỏi những agent đang live, trước mặt người dùng thật hoặc bên trong một vận hành thật, ngay lúc này, và đã như vậy nhiều tháng. Production là nơi những việc chán mà quyết định lộ ra: rate limit, retry, tool trả về sai định dạng, chi phí đội lên, cú sập lúc 2 giờ sáng. Một nhà cung cấp mới chỉ làm proof-of-concept sẽ học tất cả những thứ đó bằng ngân sách của bạn.
2. Họ có tự build và vận hành sản phẩm AI của chính mình không?
Có khác biệt thật giữa một shop chỉ bán giờ công và một công ty còn tự gánh rủi ro vận hành phần mềm của chính nó. Một công ty vận hành sản phẩm AI của mình sẽ cảm nhận từng chỗ gợn mà khách hàng của họ cảm nhận — những lần bị page lúc on-call, những lần model bị regression, cái hoá đơn cuối tháng. Kinh nghiệm vận hành đó khó giả và khó mua. Ở ISEMI đây là tư thế mặc định: bọn mình build và vận hành sản phẩm AI của chính mình, nên cơ bắp mang tới roadmap của khách chính là cơ bắp bọn mình dùng cho bản thân.
3. Chiều sâu về tool-calling và MCP của họ tới đâu?
Một agent chỉ hữu ích tới mức những tool mà nó với tới được. Hỏi cụ thể về kinh nghiệm tool-calling và Model Context Protocol (MCP): họ expose hệ thống cho agent thế nào, xử lý xác thực và scoping ra sao, chặn một tool call làm điều không thể hoàn tác bằng cách nào. Chiều sâu ở đây phân tách những team có thể cắm agent vào stack thật của bạn — hệ ticket, CRM, data warehouse — với những team chỉ gọi được một API model rồi parse text.
4. Họ có thực hành evaluation và testing thật sự không?
Vì agent là non-deterministic, câu "bọn tôi có test rồi" phải mang nghĩa cụ thể. Một nhà cung cấp nghiêm túc chạy eval: một bộ tác vụ đại diện được chấm điểm tự động, theo dõi theo thời gian, và chạy lại mỗi khi một prompt, model hay tool thay đổi. Hỏi xem họ đo chất lượng thế nào, bắt regression trước bạn ra sao, và quy trình của họ là gì khi một bản cập nhật model lặng lẽ đổi hành vi. Nếu câu trả lời là "bọn tôi bấm thử loanh quanh", hãy đi tiếp.
5. Ai sở hữu code, dữ liệu và IP?
Đọc điều này vào hợp đồng, đừng tin miệng. Bạn nên sở hữu source code, prompt, bộ eval và dữ liệu mà agent chạm vào, không có lock-in khiến việc rời đi trở nên đắt đỏ. Xác nhận nhà cung cấp sẽ không train model bên thứ ba trên dữ liệu của bạn, và có NDA ký trước khi bất cứ thứ gì nhạy cảm được trao tay. Quyền sở hữu và bảo mật là nơi một hợp đồng tốt lặng lẽ bảo vệ bạn, còn một hợp đồng tệ lặng lẽ giăng bẫy.
6. Mô hình hợp tác có rõ ràng và thành thật không?
Bạn phải hiểu được, gọn trong một trang, họ bắt đầu thế nào và tính tiền ra sao. Các nhà cung cấp chín thường mời một discovery sprint nhỏ để giảm rủi ro scope trước khi build đầy đủ, rồi một lộ trình lên production, rồi một thoả thuận vận hành. Giá cả mập mờ, đòi cam kết lớn ngay từ đầu khi chưa scope gì, hay không mô tả nổi một bước nhỏ đầu tiên — đều là dấu hiệu nhà cung cấp đang quản trị rủi ro bằng cách đẩy nó sang bạn.
7. Họ có quan sát được agent trên production không?
Khi một agent làm sai, họ có nói được vì sao không? Hỏi về observability: tracing từng lần agent chạy, log các tool call và quyết định, dashboard cho chi phí và độ trễ, cảnh báo khi chất lượng tụt. Thiếu những thứ này, debug một agent đang live là đoán mò, và mỗi sự cố thành một cuộc điều tra nhiều ngày. Có chúng, phần lớn sự cố chỉ là một lần chạy đã được trace và một dòng fix.
8. Họ có agnostic với model và framework không?
Bức tranh model đổi vài tháng một lần. Một nhà cung cấp gắn chặt vào một model hay một framework orchestration duy nhất sẽ hoặc khoá bạn vào lựa chọn đó, hoặc phải build lại tốn kém khi nó không còn là phương án tốt nhất. Hãy ưu tiên team biết cân nhắc trade-off — model này để reasoning, model kia để tiết kiệm chi phí, framework này cho dạng bài toán này — và thiết kế sao cho việc thay đổi là một thay đổi cấu hình, không phải viết lại.
9. Ai bảo trì agent sau khi launch?
Hỏi thẳng câu khó chịu: sau go-live, ai giữ cho cái này chạy, và theo điều khoản nào? Model bị deprecate, API đổi, mẫu hình sử dụng dịch chuyển. Tìm hiểu xem bảo trì là một thoả thuận liên tục hay chỉ là suy nghĩ sau cùng, thời gian phản hồi khi agent hỏng là bao lâu, và liệu người build có phải là người sẽ fix. Một agent không có kế hoạch bảo trì là một chiếc đồng hồ đếm ngược, không phải một tài sản.
10. Khung giờ làm việc của họ có khớp với bạn không?
Một agent hành động thay cho công việc của bạn cần có ai đó gọi được khi nó giở chứng. Bạn không cần nhà cung cấp ở đúng thành phố mình, nhưng cần độ phủ và giao thoa giờ giấc khớp với nơi và lúc vận hành của bạn diễn ra. Team phân tán phủ giờ làm việc US, EU và APAC có thể trông agent xuyên múi giờ; một team chỉ rảnh vài giờ mỗi ngày, lệch múi giờ với bạn, biến mỗi sự cố thành một đêm chờ đợi.
Dấu hiệu đáng lo
Vài mẫu hình nên khiến bạn chậm lại, dù điểm ở chỗ khác có tốt:
- Chỉ có demo làm bằng chứng. Mọi ví dụ đều là video dàn dựng; không gì đang live và gánh việc thật hôm nay.
- Diễn kịch độ chính xác. Những con số nghe kêu ("chính xác 99,7%") mà không có phương pháp eval phía sau. Team thật nói bằng tác vụ, failure mode, và cách họ đo — không phải một con số tròn trịa đáng ngờ.
- Mập mờ về dữ liệu. Né tránh chuyện sở hữu dữ liệu, thời gian lưu, hay liệu dữ liệu của bạn có train model của người khác.
- Không có câu chuyện bảo trì. Hào hứng về việc build, im lặng về việc vận hành.
- Cuồng tín framework. Một tool cho mọi bài toán, và ngại bàn khi nào nó là công cụ sai.
- Tối đa hoá scope. Từ chối bắt đầu nhỏ; đẩy một hợp đồng lớn cố định trước khi có bất kỳ discovery nào.
Câu hỏi nên hỏi trong buổi gọi
Mang những câu này tới cuộc trò chuyện nghiêm túc đầu tiên. Chất lượng câu trả lời nói cho bạn nhiều hơn bất kỳ slide nào:
- "Cho tôi xem một agent các bạn đang chạy trên production. Nó live bao lâu rồi, và thứ gì hay hỏng nhất?"
- "Bộ evaluation của các bạn trông thế nào, và làm sao các bạn bắt được regression khi model cập nhật?"
- "Dẫn tôi qua cách các bạn nối một agent vào một hệ như CRM hay ticketing của chúng tôi — các bạn scope quyền của nó ra sao?"
- "Cuối cùng ai sở hữu code, prompt và dữ liệu? Gửi giúp tôi mẫu NDA và điều khoản IP tiêu chuẩn của các bạn được không?"
- "Bước hợp tác đầu tiên nhỏ nhất mà các bạn khuyến nghị là gì, và nó sẽ chứng minh điều gì?"
- "Sau khi launch, ai bảo trì, phản hồi nhanh cỡ nào, và chi phí ra sao?"
- "Khi một agent làm sai trên production, các bạn tìm ra nguyên nhân bằng cách nào?"
Câu hỏi thường gặp
Công ty phát triển AI agent là gì? Là đơn vị thiết kế, xây dựng và vận hành các agent chạy bằng LLM — phần mềm lập kế hoạch tác vụ, gọi tool và API, hoàn thành công việc nhiều bước với ít giám sát. Khác một shop phần mềm truyền thống, nó giao một hệ thống ra quyết định tại runtime, đòi hỏi evaluation, observability và bảo trì liên tục là năng lực lõi, không phải phần thêm.
Nó khác gì so với thuê một agency phần mềm bình thường? Agent là non-deterministic, chúng hành động thật, và cần chăm sóc liên tục khi model và tool thay đổi. Vậy nên bạn đang đánh giá kỷ luật của một team quanh eval, guardrail, phân quyền và vận hành — không chỉ khả năng ship tính năng đúng hạn.
Tôi nên đòi bằng chứng gì? Agent đang live trên production (không phải demo), một thực hành evaluation được mô tả rõ, một thiết lập observability, điều khoản sở hữu code và dữ liệu rõ ràng kèm NDA, và một thoả thuận bảo trì cụ thể. Những team tự build và vận hành sản phẩm của mình thường trưng được tất cả những thứ đó ngay trên chính họ.
Bước hợp tác đầu tiên nên lớn cỡ nào? Ưu tiên một discovery sprint nhỏ, có scope, hơn là một hợp đồng lớn trả trước. Mục tiêu của bước đầu là giảm rủi ro: chứng minh nhà cung cấp cắm được vào hệ thống của bạn và tạo ra một lát cắt chạy được trước khi bạn cam kết build đầy đủ. Những team uy tín sẽ khuyên bắt đầu nhỏ.
Tôi có sở hữu thứ họ build không? Bạn nên — source code, prompt, bộ eval và dữ liệu của bạn — không có lock-in mang tính trừng phạt và có NDA ký trước khi thông tin nhạy cảm được trao tay. Xác nhận nó trong hợp đồng; đừng mặc định.
Đi tiếp từ đâu
Nếu bạn đang scope một dự án agent, cách nhanh nhất để đối chiếu một nhà cung cấp với checklist này là nhìn thứ họ thật sự vận hành. Bọn mình build và vận hành sản phẩm của chính mình — Spikdi, một app tiêu dùng đang live, và các pipeline open-source Flow Kit cùng Flowboard — và bọn mình ship agent vào vận hành thật, như AI Agent Jira Bot, thứ đọc và ghi xuyên Jira, GitLab, Notion, Confluence, Drive và Calendar thông qua MCP tools.
Nếu đó là kiểu team production-first bạn muốn đánh giá, bắt đầu từ dịch vụ phát triển AI agent của bọn mình và mang những câu hỏi trên tới buổi gọi đầu tiên.