# Kiến Trúc AI Agent: Năng Lực Không Phương Với Việc Sử Dụng

Tuần trước, tôi đã nói chuyện với một nhà quản lý sản phẩm (PM) vừa triển khai trợ lý AI của mình trong vài tháng gần đây. Các chỉ số trông ấn tượng: 89% độ chính xác, thời gian phản hồi dưới một giây, phản hồi tích cực từ người dùng trong khảo sát. Nhưng người dùng lại từ bỏ trợ lý sau khi gặp vấn đề đầu tiên, như trường hợp một người dùng vừa có tranh chấp thanh toán vừa bị khóa tài khoản.

“Trợ lý của chúng tôi có thể xử lý các yêu cầu thông thường hoàn hảo, nhưng khi đối mặt với các vấn đề phức tạp, người dùng sẽ thử một lần, cảm thấy thất vọng và ngay lập tức yêu cầu một con người.”

Mô hình này được quan sát trên mọi nhóm sản phẩm tập trung vào việc làm trợ lý của họ “thông minh hơn” khi thách thức thực sự là đưa ra các quyết định kiến trúc định hình cách người dùng trải nghiệm và bắt đầu tin tưởng trợ lý.

Trong bài viết này, tôi sẽ hướng dẫn bạn qua các lớp khác nhau của kiến trúc trợ lý AI. Cách các quyết định sản phẩm của bạn xác định liệu người dùng có tin tưởng trợ lý của bạn hay từ bỏ nó. Đến cuối cùng, bạn sẽ hiểu tại sao một số trợ lý cảm thấy “thần kỳ” trong khi những người khác lại cảm thấy “khó chịu” và quan trọng hơn, các PM nên kiến trúc như thế nào để có trải nghiệm thần kỳ.

Chúng tôi sẽ sử dụng ví dụ về một trợ lý hỗ trợ khách hàng cụ thể xuyên suốt, để bạn có thể thấy chính xác cách mỗi lựa chọn kiến trúc được thể hiện trong thực tế. Chúng ta cũng sẽ thấy tại sao cách tiếp cận ngược lại với niềm tin (gợi ý: không phải là về việc đúng thường xuyên hơn) thực sự hoạt động tốt hơn cho việc áp dụng của người dùng.

Hãy tưởng tượng bạn đang xây dựng một trợ lý hỗ trợ khách hàng

Bạn là PM đang xây dựng một trợ lý giúp người dùng giải quyết vấn đề tài khoản – đặt lại mật khẩu, câu hỏi thanh toán, thay đổi gói dịch vụ. Có vẻ đơn giản, phải không?

Nhưng khi người dùng nói “Tôi không thể truy cập tài khoản của mình và gói đăng ký dường như có vấn đề” thì điều gì sẽ xảy ra?

Kịch bản A: Trợ lý của bạn ngay lập tức bắt đầu kiểm tra hệ thống. Nó tìm kiếm tài khoản, xác định mật khẩu đã được đặt lại hôm qua nhưng email không bao giờ đến, phát hiện ra vấn đề thanh toán đã hạ cấp gói, giải thích chính xác những gì đã xảy ra và đề nghị sửa cả hai vấn đề với một cú nhấp chuột.

Kịch bản B: Trợ lý của bạn đặt câu hỏi làm rõ. “Bạn lần cuối đăng nhập thành công khi nào? Bạn thấy thông báo lỗi nào? Bạn có thể cho tôi biết thêm về vấn đề đăng ký không?” Sau khi thu thập thông tin, nó nói “Để tôi chuyển bạn đến một con người có thể kiểm tra tài khoản và thanh toán của bạn.”

Cùng một yêu cầu của người dùng. Cùng một hệ thống cơ bản. Hoàn toàn khác biệt về sản phẩm.

Bốn Lớp Nơi Các Quyết Định Sản Phẩm Của Bạn Sống

Hãy tưởng tượng kiến trúc trợ lý giống như một ngăn xếp (stack) nơi mỗi lớp đại diện cho một quyết định sản phẩm bạn phải đưa ra.

Lớp 1: Bối Cảnh & Trí Nhớ (Trợ lý nhớ điều gì?)

Quyết Định: Nên để trợ lý nhớ bao nhiêu và trong bao lâu?

Điều này không chỉ là lưu trữ kỹ thuật – đó là về việc tạo ra ảo giác về sự thấu hiểu. Trí nhớ của trợ lý quyết định nó có cảm giác như đang nói chuyện với một robot hay một đồng nghiệp am hiểu.

Đối với trợ lý hỗ trợ của chúng ta: Bạn chỉ lưu cuộc trò chuyện hiện tại, hay lịch sử hỗ trợ của khách hàng? Mô hình sử dụng sản phẩm của họ? Khiếu nại trước đó?

Các loại trí nhớ cần xem xét:

Trí nhớ phiên: Cuộc trò chuyện hiện tại (“Bạn đã đề cập đến vấn đề thanh toán trước đó…”)

Trí nhớ khách hàng: Tương tác trong quá khất qua các phiên (“Tháng trước bạn có một vấn đề tương tự với…”)

Trí nhớ hành vi: Mô hình sử dụng (“Tôi nhận thấy bạn thường sử dụng ứng dụng di động của chúng tôi…”)

Trí nhớ ngữ cảnh: Trạng thái tài khoản hiện tại, đăng ký hoạt động, hoạt động gần đây

Càng nhiều thứ trợ lý nhớ, nó càng có thể dự đoán nhu cầu thay vì chỉ phản hồi câu hỏi. Mỗi lớp trí nhớ làm cho phản hồi trở nên thông minh hơn nhưng cũng tăng độ phức tạp và chi phí.

Lớp 2: Dữ Liệu & Tích Hợp (Bạn đi sâu đến mức nào?)

Quyết Định: Nên kết nối trợ lý với những hệ thống nào và mức độ truy cập nên như thế nào?

Càng sâu trợ lý kết nối với quy trình làm việc của người dùng và hệ thống hiện có, càng khó để người dùng chuyển đổi. Lớp này xác định bạn là một công cụ hay một nền tảng.

Đối với trợ lý hỗ trợ của chúng ta: Nó nên tích hợp chỉ với hệ thống thanh toán Stripe, hay cũng với CRM Salesforce, hệ thống tạo vé ZenDesk, cơ sở dữ liệu người dùng và nhật ký kiểm toán? Mỗi tích hợp làm cho trợ lý hữu ích hơn nhưng cũng tạo ra nhiều điểm có thể thất bại hơn – hãy nghĩ đến giới hạn tỷ lệ API, thách thức xác thực và thời gian hệ thống ngừng hoạt động.

Điều thú vị ở đây là – Hầu hết trong chúng ta bị mắc kẹt khi cố gắng tích hợp mọi thứ cùng một lúc. Nhưng những trợ lý thành công nhất bắt đầu chỉ với 2-3 tích hợp chính và thêm dựa trên những gì người dùng thực sự yêu cầu.

Lớp 3: Kỹ Năng & Khả Năng (Điều gì làm bạn khác biệt?)

Quyết Định: Trợ lý nên có những khả năng cụ thể nào và mức độ sâu của chúng là gì?

Lớp kỹ năng của bạn là nơi bạn thắng hoặc thua trước đối thủ. Không phải là có nhiều tính năng nhất – là có những khả năng đúng tạo ra sự phụ thuộc của người dùng.

Đối với trợ lý hỗ trợ của chúng ta: Nó chỉ nên đọc thông tin tài khoản, hay cũng nên sửa đổi thanh toán, đặt lại mật khẩu và thay đổi cài đặt gói? Mỗi kỹ năng thêm làm tăng giá trị cho người dùng nhưng cũng tăng độ phức tạp và rủi ro.

Ghi chú triển khai: Các công cụ như MCP (Model Context Protocol) đang khiến việc xây dựng và chia sẻ kỹ năng trên các trợ lý khác nhau trở nên dễ dàng hơn nhiều, thay vì xây dựng lại khả năng từ đầu.

Lớp 4: Đánh Giá & Niềm Tin (Người dùng biết điều gì nên trông đợi?)

Quyết Định: Bạn đo lường thành công như thế nào và giao hạn chế của trợ lý cho người dùng như thế nào?

Lớp này xác định liệu người dùng có phát triển sự tự tin vào trợ lý của bạn hay từ bỏ nó sau sai lầm đầu tiên. Không chỉ là về độ chính xác – là về việc đáng tin cậy.

Đối với trợ lý hỗ trợ của chúng ta: Bạn có hiển thị điểm tự tin (“Tôi 85% tự tin điều này sẽ giải quyết vấn đề của bạn”)? Bạn có giải thích lý do (“Tôi đã kiểm tra ba hệ thống và tìm thấy…”)? Bạn luôn xác nhận trước khi hành động (“Tôi nên đặt lại mật khẩu cho bạn bây giờ không?”)? Mỗi lựa chọn ảnh hưởng đến cách người dùng nhận thức về độ tin cậy.

Chiến lược niềm tin cần xem xét:

Chỉ báo tự tin: “Tôi tự tin về tình trạng tài khoản của bạn, nhưng hãy để tôi kiểm tra lại chi tiết thanh toán”

Sự minh bạch lý do: “Tôi tìm thấy hai lần đăng nhập không thành công và phương thức thanh toán đã hết hạn”

Giới hạn tinh tế: “Đây có vẻ là vấn đề thanh toán phức tạp – để tôi kết nối bạn với chuyên gia thanh toán của chúng tôi, người có quyền truy cập vào nhiều công cụ hơn”

Mô hình xác nhận: Khi hỏi sự cho phép so với khi hành động và giải thích

Lời hiểu ngược lại: Người dùng tin tưởng trợ lý hơn khi chúng thừa nhận sự không chắc chắn hơn khi chúng tự tin mắc sai lầm.

Vậy bạn thực sự kiến trúc một trợ lý như thế nào?

Ok, vậy bạn đã hiểu về các lớp. Bây giờ đến câu hỏi thực tế mà mọi PM đều hỏi: “Tôi thực sự triển khai điều này như thế nào? Trợ lý nói chuyện với kỹ năng như thế nào? Kỹ năng truy cập dữ liệu như thế nào? Đánh giá xảy ra trong khi người dùng đang chờ đợi?”

Lựa chọn điều phối (orchestration) của bạn quyết định mọi thứ về trải nghiệm phát triển, quy trình gỡ lỗi và khả năng lặp lại của bạn.

Hãy cùng xem xét các cách tiếp cận chính, và tôi sẽ thẳng thắn về khi nào mỗi cách hoạt động và khi nào nó trở thành cơn ác mộng.

1. Kiến Trúc Agent Đơn Lẻ (Bắt đầu từ đây)

Mọi thứ xảy ra trong ngữ cảnh của một trợ duy nhất.

Đối với trợ lý hỗ trợ của chúng ta: Khi người dùng nói “Tôi không thể truy cập tài khoản”, một trợ lý xử lý tất cả – kiểm tra trạng thái tài khoản, xác định vấn đề thanh toán, giải thích những gì đã xảy ra, đề xuất giải pháp.

Tại sao điều này hoạt động: Đơn giản để xây dựng, dễ gỡ lỗi, chi phí có thể dự đoán. Bạn biết chính xác trợ lý của mình có thể và không thể làm gì gì.

Tại sao nó không hoạt động: Có thể trở nên tốn kém với các yêu cầu phức tạp vì bạn tải toàn bộ ngữ cảnh mỗi lần. Khó tối ưu hóa các phần cụ thể.

Hầu hết các đội nhóm bắt đầu từ đây, và thực sự, nhiều đội không bao giờ cần chuyển sang thứ gì phức tạp hơn. Nếu bạn đang cân nhắc giữa cách này và thứ gì đó phức tạp hơn, hãy bắt đầu từ đây.

2. Kiến Trúc Dựa Trên Kỹ Năng (Khi bạn cần hiệu quả)

Bạn có một bộ định tuyến (router) xác định người dùng cần gì, sau đó chuyển đến các kỹ năng chuyên biệt.

Đối với trợ lý hỗ trợ của chúng ta: Bộ định tuyến nhận ra đây là vấn đề truy cập tài khoản và chuyển đến `Kỹ năngĐăng nhập`. Nếu `Ký năngĐăng nhập` phát hiện ra thực chất đây là vấn đề thanh toán, nó chuyển đến `Kỹ năngThanh toán`.

Luồng ví dụ thực tế:

Người dùng: “Tôi không thể đăng nhập”

Bộ định tuyến → Kỹ năngĐăng nhập

Kỹ năngĐăng nhập kiểm tra: Tài khoản tồn tại ✓, Mật khẩu chính xác ✗, Tình trạng thanh toán… chờ, đăng ký đã hết hạn

Kỹ năngĐăng nhập → Kỹ năngThanh toán: “Xử lý đăng ký hết hạn cho người dùng123”

Kỹ năngThanh toán xử lý quy trình gia hạn

Tại sao điều này hoạt động: Hiệu quả hơn – bạn có thể sử dụng mô hình rẻ hơn cho các kỹ năng đơn giản, mô hình đắt tiền cho lý luận phức tạp. Mỗi kỹ năng có thể được tối ưu hóa độc lập.

Tại sao nó không hoạt động: Điều phối giữa các kỹ năng nhanh chóng trở nên phức tạp. Ai quyết định khi nào chuyển giao? Các kỹ năng chia sẻ ngữ cảnh như thế nào?

Đây là nơi MCP thực sự giúp ích – nó tiêu chuẩn hóa cách các kỹ năng hiển thị khả năng của chúng, vì vậy bộ định tuyến biết mỗi kỹ năng có thể làm gì mà không cần duy trì ánh xạ đó thủ công.

3. Kiến Trúc Dựa Trên Quy Trình (Yêu thích của Doanh nghiệp)

Bạn xác định trước các quy trình từng bước cho các kịch bản phổ biến. Hãy nghĩ đến LangGraph, CrewAI, AutoGen, N8N, v.v.

Đối với trợ lý hỗ trợ của chúng ta: “Vấn đề truy cập tài khoản” kích hoạt một quy trình:

Kiểm tra trạng thái tài khoản

Nếu bị khóa, kiểm tra lần đăng nhập không thành công

Nếu quá nhiều lần thất bại, kiểm tra tình trạng thanh toán

Nếu có vấn đề thanh toán, chuyển đến khôi phục thanh toán

Nếu không phải thanh toán, chuyển đến đặt lại mật khẩu

Tại sao điều này hoạt động: Mọi thứ đều có thể dự đoán và kiểm toán. Hoàn hảo cho các ngành nặng tuân thủ. Dễ tối ưu hóa từng bước.

Tại sao nó không hoạt động: Khi người dùng có các trường hợp ngoại lệ kỳ lạ không phù hợp với quy trình đã xác định trước của bạn, bạn bị mắc kẹt. Cảm giác cứng nhắc với người dùng.

4. Kiến Trúc Hợp Tác (Tương lai?)

Nhiều trợ lý chuyên biệt làm việc cùng nhau bằng cách sử dụng giao thức A2A (agent-to-agent).

Tầm nhìn: Trợ lý của bạn phát hiện rằng trợ lý của một công ty khác có thể giúp với các vấn đề, tự động thiết lập kết nối an toàn và hợp tác để giải quyết vấn đề của khách hàng. Hãy nghĩ đến trợ lý booking.com tương tác với trợ lý American Airlines!

Đối với trợ lý hỗ trợ của chúng ta: `Trợ lýXác thực` xử lý vấn đề đăng nhập, `Trợ lýThanh toán` xử lý vấn đề thanh toán, `TrợLiệuGiaoTiếp` quản lý tương tác với người dùng. Họ phối hợp thông qua các giao thức tiêu chuẩn để giải quyết các vấn đề phức tạp.

Kiểm tra thực tế: Điều này nghe có vẻ tuyệt vời nhưng introduces sự phức tạp xung quanh bảo mật, thanh toán, niềm tin và độ tin cậy mà hầu hết các công ty chưa sẵn sàng. Chúng tôi vẫn đang cố gắng tìm ra các tiêu chuẩn.

Điều này có thể tạo ra kết quả tuyệt vời cho các kịch bản tinh vi, nhưng gỡ lỗi các cuộc trò chuyện đa trợ lý thực sự khó khăn. Khi có sự cố, xác định trợ lý nào đã mắc sai lầm và tại sao giống như công việc điều tra.

Điều này ở đây: hãy bắt đầu đơn giản. Kiến trúc trợ lý đơn xử lý nhiều trường hợp sử dụng hơn bạn nghĩ. Chỉ thêm sự phức tạp khi bạn gặp những giới hạn thực sự, không phải những giới hạn tưởng tượng.

Nhưng điều thú vị ở đây là – ngay cả với kiến trúc hoàn hảo, trợ lý của bạn vẫn có thể thất bại nếu người dùng không tin tưởng nó. Điều đó đưa chúng ta đến bài học ngược đời nhất về việc xây dựng trợ lý.

Điều về niềm tin mà mọi người đều sai

Đây là một điều ngược đời: Người dùng không tin tưởng những trợ lý luôn đúng. Họ tin tưởng những trợ lý trung thực khi chúng có thể sai.

Hãy nghĩ về nó từ góc nhìn của người dùng. Trợ lý hỗ trợ của bạn tự tin nói “Tôi đã đặt lại mật khẩu và cập nhật địa chỉ thanh toán của bạn.” Người dùng nghĩ “tuyệt vời!” Sau đó họ cố gắng đăng nhập và… nó không hoạt động. Bây giờ họ không chỉ có một vấn đề kỹ thuật – họ có một vấn đề về niềm tin.

So sánh với một trợ lý nói “Tôi nghĩ tôi đã tìm thấy vấn đề với tài khoản của bạn. Tôi 80% tự tin điều này sẽ giải quyết nó. Tôi sẽ đặt lại mật khẩu và cập nhật địa chỉ thanh toán của bạn. Nếu điều này không hoạt động, tôi ngay lập tức chuyển đến một con người có thể đào sâu hơn.”

Cùng khả năng kỹ thuật. Trải nghiệm người dùng hoàn toàn khác nhau.

Xây dựng trợ lý đáng tin tưởng đòi hỏi tập trung vào ba điều:

Điều chỉnh sự tự tin: Khi trợ lý nói nó tự tin 60%, nó nên đúng khoảng 60% thời gian. Không phải 90%, không phải 30%. Thực sự là 60%.

Sự minh bạch lý do: Người dùng muốn thấy công việc của trợ lý. “Tôi đã kiểm tra tình trạng tài khoản của bạn (đang hoạt động), lịch sử thanh toán (thanh toán thất bại hôm qua), và lần đăng nhập (bị khóa sau 3 lần thất bại). Vấn đề dường như là…”

Nâng cấp tinh tế: Khi trợ lý đạt đến giới hạn của nó, nó chuyển giao như thế nào? Chuyển tiếp mượt mà đến một con người với ngữ cảnh đầy đủ tốt hơn nhiều so với “Tôi không thể giúp với điều đó.”

Nhiều lần chúng ta ám ảnh việc làm cho trợ lý chính xác hơn, trong khi những gì người dùng thực sự muốn là sự minh bạch hơn về giới hạn của trợ lý.

Điều Sắp Đến Tiếp Theo

Phần 2, tôi sẽ đi sâu hơn vào các quyết định tự chủ khiến hầu hết các PM phải thức trắng. Bạn nên cho trợ lý độc lập đến mức nào? Nó nên hỏi cho phép trước khi tha thứ? Làm thế nào để cân bằng tự động hóa với kiểm soát của người dùng?

Chúng ta cũng sẽ xem xét các mối quan tâm quản trị thực sự quan trọng trong thực tế – không chỉ là các vấn đề bảo mật lý thuyết, mà là những thách thức triển khai thực sự có thể tạo nên hoặc phá hỏng lịch trình ra mắt của bạn.

Nếu bạn đã đọc đến cuối hướng dẫn này, hãy chia sẻ nó với bạn bè và chắc chắn đăng ký!