Maven Apps: Tác tử của bạn cần người vận hành, không phải bảng công tắc

Một bảng chuyển mạch chỉ làm đúng những gì nó được đấu dây để làm: gạt công tắc, nhận về một phản hồi cố định, lần nào cũng vậy. Yêu cầu nó xử lý bất cứ điều gì nằm ngoài mạch đó thì nó bó tay, vì nó không xử lý được biến số, nó chỉ có dây nối.

Nhân viên tổng đài thì khác. Đưa cho họ một yêu cầu, chẳng hạn nối máy giúp tôi tới quầy lễ tân, và họ sẽ tự tìm cách: dùng đường dây nào, làm gì nếu máy bận, làm gì nếu chính yêu cầu đó còn mơ hồ. Họ không chỉ chuyển tín hiệu đi; họ diễn giải và hành động dựa trên nó.

Maven Apps là nhân viên tổng đài, không phải bảng chuyển mạch. Khi bắt tay xây dựng framework vận hành hạ tầng App của mình, chúng tôi đã đặt cược có chủ đích: không xây thêm một lớp tích hợp nữa. Thay vào đó, xây một nền tảng ứng dụng thực thụ, nơi các tác tử AI là công dân hạng nhất.

Hiện nay, đã có hàng nghìn ứng dụng chạy trên framework của chúng tôi. Đúng vậy, trong đó có các ứng dụng cho những hệ thống bên thứ ba lớn như Salesforce, Zendesk và Notion. Nhưng cũng có hàng trăm ứng dụng tùy chỉnh đang chạy production trên các tác tử thực tế.

Vì sao tích hợp cơ bản là chưa đủ

Hỏi mười nhà cung cấp xem “tích hợp với Salesforce” có nghĩa là gì với sản phẩm của họ, bạn sẽ nhận được mười câu trả lời khác nhau, bởi một hệ thống như Salesforce, Zendesk hay Front không bao giờ chỉ là một thứ. Nó có thể là:

• Nơi tác tử cần tìm đến để lấy thông tin (cơ sở tri thức, lịch sử case)
• Nơi tác tử cần tìm đến để thực hiện hành động (tạo phiếu hỗ trợ, cập nhật bản ghi, hoàn tiền)
• Giao diện mà tác tử cần hiện diện (một co-pilot hỗ trợ nhân viên ngay trong console mà đội hỗ trợ của bạn vẫn làm việc hằng ngày)

Một “tích hợp Salesforce” chỉ biết đọc bài viết không phải là cùng một sản phẩm với loại có thể tạo case, và cũng không phải cùng một sản phẩm với loại có thể nằm ngay trong console của nhân viên như một co-pilot. Những thứ này thường bị gộp chung dưới một từ ngữ marketing, để rồi bạn chỉ phát hiện ra lỗ hổng khi triển khai.

Đó là vấn đề của máy bán hàng tự động: một menu cố định chạy đúng như quảng cáo, cho tới khi thứ bạn cần lại không có trong danh sách, và lúc đó bạn đã cam kết rồi. Chúng tôi không muốn Maven Apps vận hành như vậy, nên chúng tôi xây framework xoay quanh câu hỏi thực sự được đặt ra (tri thức, năng lực hay kênh) thay vì xoay quanh một “connector” chung chung.

Maven Apps: hơn cả tích hợp

Maven Apps có thể mang nhiều hình thái, nhưng phần lớn dựa trên một vài mô hình phổ biến. Một số ví dụ về những gì ứng dụng có thể làm:

• Ứng dụng tri thức đọc và lập chỉ mục nội dung từ một hệ thống bên ngoài để tác tử có thể trả lời dựa trên đó: chỉ đọc, có quản lý phiên bản, gắn thẻ theo đối tượng.
• Ứng dụng năng lực cho phép tác tử thực sự làm việc trong hệ thống đó: một lệnh gọi API thật, được nối thành quy trình nhiều bước (tra cứu đơn hàng, kiểm tra chính sách đổi trả, hoàn tiền, xác nhận lại với khách hàng), tất cả trong một cuộc hội thoại duy nhất. Nếu máy ATM chỉ chạy một giao dịch theo kịch bản từ một menu cố định, thì ứng dụng năng lực giống một chuyên viên ngân hàng riêng hơn: nó nhận một kết quả cần đạt, không phải một mục trong menu, và làm mọi thứ cần thiết để đạt được, kể cả xử lý ngoại lệ.
• Ứng dụng kênh đưa tác tử đến đúng nơi khách hàng hoặc đội hỗ trợ của bạn đang có mặt: một widget nhúng, một cuộc gọi điện thoại, một hộp thư, hoặc một bảng co-pilot ngay trong console mà nhân viên của bạn dùng hằng ngày.

Một ứng dụng dựng sẵn trong thư mục của chúng tôi thường có thể cài đặt trong vài phút. Khi hệ thống của khách hàng chưa có trong danh mục, lập trình viên sẽ dùng chính framework đó, cùng SDK, cùng lifecycle hook, cùng mô hình bảo mật, để xây một ứng dụng tùy chỉnh.

Không có một tầng framework “cấp doanh nghiệp” riêng biệt mà chỉ kỹ sư của chúng tôi được dùng; App Studio, nền tảng dành cho lập trình viên để xây dựng ứng dụng, chạy trên cùng một kiến trúc. Đó là TypeScript thực thụ, một SDK thực thụ (@mavenagi/mavenagi) và một quy trình triển khai thực thụ, không phải một ngôn ngữ kịch bản độc quyền mà bạn phải học chỉ để dùng với chúng tôi.

Nếu bạn từng làm việc với MCP, Maven App mang lại ý tưởng tương tự nhưng được quản lý hoàn toàn. Một MCP server tiêu chuẩn vẫn đòi hỏi bạn tự dựng, tự đăng ký, tự duy trì và tự mở rộng quy mô. Maven App gần với một endpoint MCP tự đăng ký, tự mở rộng quy mô hơn, và bạn không phải tự quản lý bất kỳ hạ tầng nào: bạn viết logic, còn endpoint, xác thực và hosting đã được lo sẵn.

Apps được thiết kế mạnh mẽ như thế nào

Maven App là một ứng dụng serverless chạy trong môi trường bảo mật, cô lập và giao tiếp với nền tảng Maven thông qua một SDK được định nghĩa rõ ràng. Cụ thể:

Hỗ trợ đa tenant. Một ứng dụng được xây một lần và cài đặt nhiều lần, cho nhiều tổ chức và tác tử khác nhau. Mỗi lượt cài đặt có ngữ cảnh riêng (ID tổ chức, ID tác tử và cấu hình runtime riêng) nhưng dùng chung mã nguồn bên dưới. Nghĩa là khi chúng tôi cải tiến ứng dụng Salesforce, mọi khách hàng đang dùng đều được hưởng lợi, và không ai bị kẹt với một phiên bản tích hợp “của riêng mình” đã lỗi thời, tự chắp vá.

Được cô lập, không phải gắn thêm. Mỗi ứng dụng chạy như một function riêng trong môi trường bảo mật, tách biệt khỏi backend lõi của Maven và tách biệt khỏi ứng dụng của các khách hàng khác. Logic tùy chỉnh của bạn không bao giờ chạy trong một khối monolith dùng chung bên cạnh logic của người khác. Kết nối tới các hệ thống lưu trữ dữ liệu gốc của bạn có thể đi qua VPN, VPC peering, OIDC hoặc HTTPS thông thường kèm danh sách IP cho phép, do bạn chọn, không phải chúng tôi.

Phản ứng với sự kiện thực, không phải lịch polling. Thay vì một tác vụ đồng bộ hằng đêm, ứng dụng có thể triển khai các event hook gọi là trigger: một cuộc hội thoại được tạo, có phản hồi mới, cơ sở tri thức được làm mới, và nền tảng sẽ thông báo cho ứng dụng ngay khi sự kiện đó xảy ra. Đây là một mô hình khác với các công cụ tự động hóa bạn có thể đã quen. Trigger của Maven mang tính thụ động: chính nền tảng lắng nghe các thay đổi trạng thái và đẩy chúng tới bất kỳ ứng dụng nào quan tâm, không có sự ràng buộc giữa ứng dụng gây ra sự kiện và ứng dụng phản ứng với nó. Trên thực tế, một ứng dụng phản hồi email và một ứng dụng đồng bộ Salesforce hoàn toàn tách biệt có thể cùng phản ứng độc lập với một sự kiện “cuộc hội thoại được cập nhật”, mỗi bên làm việc của mình, mà không bên nào biết bên kia tồn tại.

Đó cũng chính là cơ chế phối hợp của một đàn kiến. Không con kiến nào lên kế hoạch cho hành vi của cả đàn, và không con nào nhắn tin trực tiếp cho con khác; một con kiến thay đổi điều gì đó trong môi trường chung (một vệt pheromone) và mọi con kiến khác phản ứng độc lập với thay đổi đó, mỗi con theo một quy tắc đơn giản của riêng mình. Trí tuệ ở cấp độ cả đàn (tuyến kiếm ăn tối ưu, cân bằng tải, thậm chí cả quyết định tập thể như di dời tổ) hình thành từ đó, không cần bộ điều phối trung tâm và không con kiến nào biết toàn bộ kế hoạch. Maven Apps phối hợp theo cách tương tự: một sự kiện thay đổi trạng thái chung, và mọi ứng dụng quan tâm tự phản ứng.

Có vòng đời thực sự. Mỗi ứng dụng triển khai một tập nhỏ lifecycle hook:

• preInstall: xác thực thông tin đăng nhập và cấu hình trước khi bất cứ thứ gì được đưa vào hoạt động. Nếu API key sai, quá trình cài đặt sẽ báo lỗi rõ ràng ngay tại đây thay vì âm thầm hỏng sau 3 tuần.
• postInstall: đăng ký các hành động của ứng dụng và cấp phát mọi tài nguyên cần thiết sau khi cài đặt thành công.
• executeAction: thực hiện công việc mà tác tử yêu cầu, được cung cấp cho khách hàng dưới dạng một năng lực: tra cứu đơn hàng, tạo case, hoàn tiền, kiểm tra số dư tài khoản.

Phần lớn tích hợp giống một công tắc đèn: bật hoặc tắt, không có gì ở giữa. Ứng dụng của chúng tôi chạy trọn vòng đời cài đặt, xác thực, vận hành, gỡ bỏ, gần với một quy trình biết đọc ngữ cảnh và thích ứng (kiểm tra những gì đang mở, xác nhận điều gì an toàn, rồi mới hành động) hơn là một công tắc hai trạng thái. Đó chính là kỷ luật bạn kỳ vọng ở một phần mềm production, vì nó đúng là như vậy.

Apps và tích hợp

Một tích hợp thông thường chỉ trả lời một câu hỏi hẹp, thường là “dữ liệu có đi được từ A sang B không”, và coi đó là đích đến. Maven App được xây dựng để trả lời một câu hỏi khó hơn và hữu ích hơn: liệu tác tử AI có thể nắm chắc điều gì đang đúng trong hệ thống của bạn ngay lúc này, và có thể được tin tưởng để hành động thay bạn khi cần không?

Hầu hết nền tảng doanh nghiệp đều có kiểu “tự xây nếu chúng tôi chưa có sẵn”. Điều họ thường không nói là tự xây nghĩa là bạn phải tự vận hành server, tự mở rộng quy mô, tự đánh giá bảo mật, trên hạ tầng của chính bạn. Điều đó biến một khoảng trống đơn giản trong danh mục connector thành một quyết định nhân sự: xin ngân sách kỹ thuật và hạ tầng, hay chấp nhận giới hạn trong những gì dựng sẵn? Với Maven Apps, khách hàng không bị buộc phải chọn phương án ít tệ nhất. Ứng dụng tùy chỉnh do bạn hoặc lập trình viên của bạn xây dựng sẽ chạy trên hạ tầng của chúng tôi, với cùng cơ chế giám sát, mở rộng quy mô và bảo mật như mọi ứng dụng dựng sẵn trong thư mục. Bạn viết code; chúng tôi vận hành.

Đó cũng là lý do kiến trúc này đòi hỏi những điều mà một webhook đơn giản không bao giờ phải bận tâm:

• Phản hồi có cấu trúc, giới hạn kích thước. Mỗi hành động ứng dụng thực hiện đều trả về một phản hồi rõ ràng kèm dữ liệu có cấu trúc để tác tử suy luận, không phải một khối dữ liệu thô, không giới hạn mà nó phải đoán.
• Xác thực hai chiều có chữ ký. Nền tảng ký mọi yêu cầu gửi tới ứng dụng để ứng dụng xác minh đúng là Maven đang gọi, và ứng dụng xác thực ngược lại với nền tảng bằng thông tin đăng nhập riêng. Không bên nào phải chỉ dựa vào mạng để tin tưởng.
• Cấu hình được xác thực trước khi lên production. Vì preInstall chạy trước khi ứng dụng hoạt động, thông tin đăng nhập lỗi hay thiết lập còn thiếu sẽ bị phát hiện ngay lúc cài đặt, chứ không phải lần đầu khách hàng cần đến.
• Hạ tầng thực sự bên dưới, không chỉ là một lệnh gọi function. Vì là ứng dụng hoàn chỉnh, chúng có thể lưu giữ trạng thái thực: bộ nhớ đệm, bộ đếm tần suất, một cơ sở dữ liệu nhỏ, không chỉ là yêu cầu và phản hồi phi trạng thái. Nhờ đó có thể làm những việc như theo dõi liệu tỷ lệ giải quyết của một lĩnh vực cụ thể có giảm hơn 10% trong 24 giờ qua hay không và cảnh báo cho đội của bạn khi điều đó xảy ra. Một lệnh gọi API đơn thuần không thể lưu loại bộ nhớ đó. Một ứng dụng thực thụ thì có thể, giống như đàn kiến nhớ được chỗ có thức ăn dù không con kiến nào nhớ.
• Giữ dữ liệu nhạy cảm tránh xa mô hình. Có những bước hoàn toàn không nên đi qua AI. Khi khách hàng sẵn sàng mua hàng trong giỏ, tác tử kích hoạt quy trình thanh toán của ứng dụng, và ứng dụng thu thập thông tin thanh toán cùng dữ liệu cá nhân trực tiếp từ khách hàng qua giao diện bảo mật riêng. Tác tử điều phối luồng xử lý, nhưng số thẻ và các thông tin nhạy cảm khác không bao giờ đi vào cuộc hội thoại với AI.
• Một codebase, mọi khách hàng, phạm vi ảnh hưởng được cô lập. Đa tenant nghĩa là bản sửa lỗi và cải tiến chỉ cần phát hành một lần là đến được mọi người, còn cô lập nghĩa là logic tùy chỉnh của khách hàng này không bao giờ ảnh hưởng tới khách hàng khác.

Điều này có ý nghĩa gì với bạn

Nếu bạn đang đánh giá Maven, điều cốt lõi là: khi chúng tôi nói một tác tử có thể trả lời câu hỏi và hành động dựa trên đó, chúng tôi muốn nói rằng có một ứng dụng thực sự đứng sau hành động ấy, được quản lý phiên bản, xác thực, cô lập và xây dựng trên cùng một framework, dù do đội của chúng tôi hay của bạn phát hành. Đó là khác biệt giữa một tác tử chỉ có thể nói về hệ thống của bạn và một tác tử thực sự được kết nối vào chúng.

Chúng tôi xây dựng Maven Apps vì tin rằng đó mới là ý nghĩa đúng của “tích hợp” ngay từ đầu.