Xây dựng AI Agent cho doanh nghiệp: 7 bước từ chọn công việc đến nghiệm thu

Xây dựng AI Agent cho doanh nghiệp không nên bắt đầu bằng câu hỏi “dùng framework nào?” mà bằng câu hỏi “công việc nào đủ rõ để giao cho một hệ thống AI thực hiện nhiều bước?”. Một agent tốt không phải bot biết nói hay. Nó cần mục tiêu, dữ liệu, công cụ, giới hạn quyền, tiêu chí nghiệm thu và checkpoint để con người biết nó đã làm đến đâu.

Bài viết này đưa ra 7 bước từ chọn công việc đến nghiệm thu. Mục tiêu là giúp doanh nghiệp tránh hai cực: hoặc chỉ dùng AI như chatbot, hoặc giao quá nhiều quyền cho một hệ thống chưa được kiểm thử.

1. Chọn đúng công việc trước khi nghĩ tới Agent

Công việc phù hợp thường có đầu vào tương đối rõ, lặp lại thường xuyên, có các bước xác định được và có đầu ra dễ kiểm tra. Ví dụ: tổng hợp báo cáo tuần, nghiên cứu đối thủ, chuẩn bị proposal, phân loại ticket, làm brief SEO hoặc tạo bản nháp nội dung.

Không nên bắt đầu với quyết định khó đảo ngược như tự chi ngân sách lớn, tự ký hợp đồng, tự xóa dữ liệu hoặc tự công bố nội dung nhạy cảm. Mức tự chủ nên tăng theo bằng chứng ổn định.

Hãy viết một câu outcome, ví dụ: “Mỗi sáng tạo brief 5 lead nóng có bằng chứng, không sửa CRM”. Câu này tốt hơn “xây AI Agent cho sales”, vì nó nói rõ sản phẩm đầu ra và giới hạn.

2. Vẽ workflow hiện tại và xác định điểm Agent được phép hành động

Trước khi tự động hóa, hãy vẽ cách con người đang làm: trigger, bước đọc dữ liệu, quyết định, tạo output, người duyệt và nơi lưu kết quả. Nhiều dự án Agent thất bại vì workflow hiện tại vốn đã mơ hồ.

Chia các bước thành ba loại: đọc, suy luận/tạo đề xuất, và ghi/hành động. Quyền đọc có thể mở sớm; quyền ghi nên mở sau; hành động ảnh hưởng tiền, khách hàng hoặc dữ liệu nhạy cảm cần gate chặt hơn.

Một Agent nghiên cứu có thể đọc web và kho nội bộ, sau đó ghi brief. Một Agent nội dung có thể tạo draft nhưng không tự publish. Một Agent vận hành có thể phát hiện bất thường nhưng không tự đổi cấu hình production nếu chưa được duyệt.

3. Chuẩn hóa Input Contract và Output Contract

Input Contract trả lời: Agent nhận gì, từ nguồn nào, dữ liệu nào được phép dùng và dữ liệu nào cấm. Output Contract trả lời: sản phẩm phải có trường gì, định dạng nào, chất lượng tối thiểu và lưu ở đâu.

Ví dụ với SEO Agent, input có keyword, Ubersuggest, GSC, Intel, bài đã có. Output là brief gồm intent, outline, nguồn, internal link, CTA, độ dài mục tiêu. Khi contract rõ, bạn có thể thay model mà workflow ít bị thay đổi.

Đây cũng là cách giảm phụ thuộc vào lịch sử chat. Trạng thái công việc phải nằm trong database, CRM, CMS, Notion hoặc hệ thống vận hành; conversation chỉ là môi trường tương tác.

4. Thiết kế Tool, Memory và quyền tối thiểu

Tool là những gì Agent được phép dùng: tìm kiếm, database, email, calendar, CRM, CMS hoặc API. Mỗi tool cần quyền tối thiểu đủ để hoàn thành nhiệm vụ. Nếu Agent chỉ cần đọc email để tạo báo cáo, đừng cho quyền xóa mail.

Memory nên lưu thông tin giúp tiếp tục công việc, không phải lưu mọi thứ. Có thể lưu checkpoint, quyết định đã duyệt, phiên bản template và các ID cần thiết. Không nên coi memory hội thoại là nguồn chuẩn cho dữ liệu nghiệp vụ.

OpenAI gần đây mô tả xu hướng doanh nghiệp chuyển từ AI hỗ trợ sang AI thực thi workflow. Điểm đáng học là kết nối AI với công việc và hệ thống thật, nhưng vẫn cần governance và đo lường thay vì chỉ tăng mức tự chủ. Nguồn tham khảo.

5. Xây Guardrail và cơ chế fail-closed

Fail-closed nghĩa là khi thiếu dữ liệu, lỗi model, mất connector hoặc không chắc quyền, Agent dừng đúng bước thay vì đoán tiếp. Ví dụ scorer lỗi không được tự ghi điểm 0; writer lỗi không được publish bản dở; không tìm thấy URL CTA thì không bịa đường dẫn.

Guardrail nên bao gồm giới hạn ngân sách, publish, xóa dữ liệu, PII, claim, external communication và production changes. Với mỗi hành động, ghi rõ “được tự làm”, “được đề xuất” hay “bắt buộc người duyệt”.

Cơ chế rollback cũng quan trọng. Với nội dung cần version history; với database cần transaction hoặc precondition; với automation cần biết cách pause; với CRM cần log ai/agent đã sửa field nào.

6. Pilot bằng case thật và đo tỷ lệ phải sửa

Đừng chỉ demo case đẹp. Pilot nên có 5–20 tình huống thật, gồm cả dữ liệu thiếu, input mâu thuẫn, lỗi tool và case cần từ chối. Đo thời gian, tỷ lệ output dùng được, số lỗi, số lần human intervention và mức độ sử dụng kết quả.

KPI quan trọng không phải số tác vụ Agent chạy. Nếu chạy 100 lần nhưng phần lớn bị bỏ, đó không phải năng suất. Hãy đo “accepted output”, time-to-useful-output và business movement khi có đủ baseline.

Ví dụ một Agent báo cáo tuần chỉ thực sự tốt nếu báo cáo được quản lý dùng để ra quyết định, không phải vì nó tạo file rất nhanh.

7. Nghiệm thu, mở quyền từng bước và vận hành lâu dài

Sau pilot, tạo rubric nghiệm thu: đúng dữ liệu, đủ trường, không vi phạm guardrail, logic hợp lý, nguồn truy vết được và trạng thái ghi đúng nơi. Chỉ khi hai hoặc nhiều batch liên tiếp ổn định mới mở thêm quyền.

Vận hành lâu dài cần versioning cho skill/prompt, health check connector, cost tracking, checkpoint, incident log và người chịu trách nhiệm. Model có thể mạnh lên nhưng hệ thống vẫn cần kỷ luật.

Checklist 10 câu trước khi đưa Agent vào production

• Outcome đã viết thành một câu chưa?
• Workflow hiện tại có rõ không?
• Input/output contract đủ chưa?
• Nguồn dữ liệu nào là canonical?
• Quyền ghi đã tối thiểu chưa?
• Có human gate cho điểm rủi ro?
• Có fail-closed khi lỗi model/tool?
• Có rollback và trace?
• Pilot có case xấu, không chỉ case đẹp?
• Đã đo accepted output thay vì số lần chạy?

Đọc thêm cách viết brief cho AI Agent, cách nghiệm thu kết quả AI, bảo mật dữ liệu với AI và một tuần làm việc cùng AI Agent.

Một ví dụ dễ hình dung

Giả sử doanh nghiệp muốn Agent xử lý báo giá đào tạo. Agent đọc email yêu cầu, xác định số người, mục tiêu và thời lượng; đối chiếu catalogue; tạo proposal draft; kiểm tra trường bắt buộc; sau đó dừng chờ người phụ trách duyệt giá và điều khoản. Khi duyệt xong, hệ thống mới tạo bản gửi khách hàng. Đây là Agent có ích vì giảm việc chuẩn bị, nhưng không tự quyết định phần thương mại nhạy cảm.

Thiết kế theo cách này giúp doanh nghiệp mở rộng dần: đầu tiên chỉ tạo draft, sau đó có thể tự đọc CRM, rồi tự cập nhật trạng thái. Mỗi lần tăng quyền đều có bằng chứng và checkpoint.

Cách nhận biết workflow đã đủ rõ để giao cho Agent

Hãy thử giao workflow cho một nhân sự mới chỉ bằng tài liệu. Nếu người đó vẫn phải hỏi lại liên tục “lấy dữ liệu ở đâu?”, “khi thiếu field thì làm gì?”, “ai duyệt?” hoặc “xong thì lưu ở đâu?”, workflow chưa đủ chín để tự động hóa. Agent cũng sẽ gặp đúng những khoảng mơ hồ đó, chỉ khác là nó có thể tự suy diễn nhanh hơn và tạo cảm giác mọi thứ vẫn đang chạy.

Một workflow đủ rõ thường có trigger, nguồn đầu vào, bước xử lý, điểm quyết định, output, owner và trạng thái kết thúc. Không cần mọi chi tiết đều cứng; nhưng phần nào được phép linh hoạt và phần nào là bất biến phải được ghi rõ. Ví dụ, Agent có thể tự chọn thứ tự đọc 5 nguồn, nhưng không được bỏ qua bước fact-check trước khi tạo nội dung public.

Ví dụ Agent SEO và Agent CSKH khác nhau ở điểm nào?

SEO Agent có thể chịu lỗi ở mức thấp hơn trong giai đoạn draft vì nội dung còn qua review, nhưng phải rất chặt ở publish, claim và canonical URL. CSKH Agent lại cần ưu tiên tính đúng của chính sách, quyền riêng tư và escalation. Một câu trả lời hơi kém mượt có thể chấp nhận; một câu trả lời sai chính sách hoàn tiền thì không.

Điều này cho thấy “AI Agent chuẩn” không có một cấu hình chung. Contract phải theo nghiệp vụ. Chính sách quyền, mức tự chủ, tiêu chí QA và timeout đều nên khác. Đừng mua một nền tảng rồi cố ép toàn doanh nghiệp vào cùng một bot.

Thiết kế checkpoint để Agent có thể đổi runtime hoặc phục hồi sau lỗi

Checkpoint tối thiểu nên có: mục tiêu còn lại, đã làm, chưa làm, quyết định/giả định, nguồn/link, bước tiếp theo, rủi ro và hạn. Khi Agent lỗi ở bước 5/7, runtime khác chỉ cần đọc checkpoint và canonical data để tiếp tục. Nếu trạng thái chỉ nằm trong hidden memory hoặc local conversation, hệ thống chưa thật sự vận hành được ở cấp doanh nghiệp.

Với tác vụ dài, checkpoint nên được ghi sau mỗi mutation quan trọng, không chỉ cuối phiên. Ví dụ đã tạo brief, đã ghi post draft, đã upload asset, đã chờ reviewer. Cách này giảm việc chạy lại và giảm duplicate khi hệ thống khởi động lại.

Chọn model theo nhiệm vụ, không theo tâm lý “model mạnh nhất”

Phân loại, format, kiểm field và tạo metadata thường không cần model đắt nhất. Nhiệm vụ cần suy luận sâu, tổng hợp nhiều nguồn hoặc viết nội dung cạnh tranh mới cần model mạnh hơn. Kiến trúc tốt cho phép route model theo độ khó và fallback khi provider lỗi.

Quan trọng hơn giá model là QA contract. Một model rẻ nhưng có evidence, deterministic checks và reviewer có thể tạo hệ thống ổn định hơn model đắt chạy một prompt dài không kiểm soát.

Khung nghiệm thu 5 lớp cho Agent doanh nghiệp

Lớp một là đúng dữ liệu: Agent có đọc đúng nguồn, đúng bản mới nhất và không dùng dữ liệu ngoài quyền không? Lớp hai là đúng logic: các bước suy luận có bám mục tiêu và không bỏ qua điều kiện quan trọng không? Lớp ba là đúng output: đủ trường, đúng format, dùng được ngay hay vẫn cần làm lại?

Lớp bốn là đúng hành động: Agent có chỉ ghi vào nơi được phép, không tự tạo lịch, không tự gửi hoặc không tự thay đổi production ngoài phạm vi không? Lớp năm là đúng trace: có thể truy ra nguồn, version, thời điểm, tool đã dùng và checkpoint hay không?

Doanh nghiệp có thể chấm mỗi lớp theo PASS/REVISE/BLOCKED thay vì một điểm tổng duy nhất. Cách này an toàn hơn vì một Agent có thể viết rất hay nhưng vẫn phải BLOCKED nếu quyền dữ liệu sai. Ngược lại, một output chưa đẹp nhưng đúng logic và đúng dữ liệu có thể chỉ cần REVISE.

Khi vận hành ở quy mô lớn, hãy có “circuit breaker”: nếu một loại lỗi lặp lại vượt ngưỡng, dừng batch và kiểm nguyên nhân thay vì để Agent tiếp tục tạo thêm lỗi. Đây là khác biệt giữa thử AI và vận hành AI.

Một nguyên tắc cuối: không để Agent tự nâng quyền của chính nó. Quyền phải đến từ hệ thống governance hoặc người có authority. Agent có thể phát hiện thiếu quyền và đề xuất remediation, nhưng không được coi “nhiệm vụ quan trọng” là lý do để tự mở thêm access.

Ở cấp doanh nghiệp, kiến trúc tốt không nhằm làm AI tự do nhất; nó nhằm làm AI hữu ích nhất trong phạm vi có thể kiểm soát, đo lường và phục hồi.

Khi đã vận hành ổn, hãy đo chi phí trên một output được chấp nhận, không chỉ chi phí mỗi lần gọi model. Đây là chỉ số giúp so sánh model rẻ nhưng sửa nhiều với model đắt hơn nhưng ít rework, và giúp tối ưu routing theo bằng chứng.

Nếu một Agent chưa thể giải thích vì sao nó dừng, dùng nguồn nào và cần ai quyết tiếp, đừng vội tăng tự chủ. Khả năng bàn giao và giải trình là một phần của chất lượng, không phải giấy tờ đi kèm.