Make hay Zapier cho AI agent: 9.000 kết nối không luôn thắng luồng rẽ nhánh

Với AI agent chủ yếu gọi một hành động trong ứng dụng đích, Zapier thường là lựa chọn thuận tiện nếu hành động đó có sẵn: danh mục ứng dụng của Zapier ghi hơn 9.000 tích hợp. Con số này nói về độ phủ danh mục, không bảo đảm mọi ứng dụng đều cung cấp đúng thao tác hoặc trường dữ liệu mà agent cần.

Khi agent phải đưa yêu cầu qua nhiều điều kiện, đổi dạng dữ liệu và lần theo nhánh đã chạy, Make đáng được ưu tiên đánh giá. Scenario Builder của Make nối các mô-đun trên canvas, hỗ trợ logic điều kiện, biến đổi dữ liệu và chạy lại kịch bản bằng dữ liệu lịch sử. Lựa chọn vì thế phụ thuộc vào hành động cụ thể, hình dạng quy trình và tài nguyên tiêu thụ trên từng đường đi.

Độ phủ ứng dụng chỉ có ích khi đúng hành động

Với một agent tiếp nhận yêu cầu bán hàng, việc CRM xuất hiện trong danh mục tích hợp mới trả lời được một phần câu hỏi. Agent còn cần tìm liên hệ theo email, đọc trường phù hợp, cập nhật đúng bản ghi và chuyển kết quả cho bước sau. Nếu thiếu một hành động thiết yếu, nhóm triển khai có thể phải gọi API hoặc thay đổi cách chia việc giữa agent và workflow.

Điều này đặc biệt quan trọng với ứng dụng nội bộ hoặc quy trình dùng trường dữ liệu tùy chỉnh. Một kết nối dựng sẵn giúp triển khai nhanh khi thao tác cần dùng đã được hỗ trợ; quyền truy cập và dữ liệu trả về vẫn phải khớp với thiết kế. Khi các ứng dụng và hành động cần thiết đều có mặt ở cả hai nền tảng, số lượng tích hợp không còn là tiêu chí quyết định. Khả năng biểu diễn đường đi của một yêu cầu và tìm lỗi ở bước phát sinh sẽ đáng xem hơn.

Ba kiến trúc agent cho ba cách cân nhắc

Một hành động đơn

Giả sử agent đọc yêu cầu của người dùng rồi tạo một việc trong ứng dụng quản lý công việc. Nếu công cụ tạo việc nhận đủ thông tin và trả về kết quả rõ ràng, Zapier là điểm khởi đầu hợp lý: phần lớn giá trị nằm ở kết nối tới ứng dụng đích. Make cũng có thể thực hiện luồng này, nhưng khả năng dựng nhiều nhánh ít được sử dụng khi yêu cầu chỉ dẫn tới một hành động.

Cần phân biệt agent chủ động gọi công cụ với workflow tự chạy khi có sự kiện kích hoạt. Cả hai có thể tạo cùng một việc, nhưng cách phát sinh lượt chạy và cách tính tài nguyên không giống nhau. Đối với agent, một yêu cầu cũng có thể dẫn tới nhiều lần gọi công cụ nếu dữ liệu thiếu hoặc lần gọi trước trả về kết quả chưa đủ để hoàn tất.

Chuỗi CRM năm bước

Xét ví dụ giả định gồm tìm liên hệ, chuẩn hóa thông tin, cập nhật CRM, giao cho nhân viên phụ trách và tạo việc theo dõi. Nếu dữ liệu đi thẳng qua các bước theo thứ tự cố định, một Zap nhiều bước có thể diễn đạt quy trình dễ hiểu. Make trở nên hấp dẫn hơn khi kết quả tìm kiếm cần tách hoặc gộp, trường CRM phải ánh xạ lại, hay mỗi loại liên hệ đòi hỏi một đường xử lý riêng.

Điểm làm thay đổi thiết kế là tình huống không tìm thấy liên hệ. Quy trình có thể tạo bản ghi mới, yêu cầu xác minh hoặc dừng trước khi ghi dữ liệu. Đây là quyết định của workflow, không nên giao cho mô hình suy đoán mỗi lần chạy. Sau khi xác định quy tắc, nhóm vận hành cần nhìn được yêu cầu đã đi theo đường nào và dữ liệu đổi ra sao trước khi cập nhật CRM.

Luồng có nhánh và phê duyệt

Giả sử agent phân loại khách hàng tiềm năng, chỉ chuyển trường hợp đạt điều kiện sang CRM và đợi người phụ trách duyệt nội dung phản hồi. Ở đây, phần khó nằm ở mối quan hệ giữa các nhánh: yêu cầu bị loại không được đi tiếp, yêu cầu chờ duyệt chưa được gửi và yêu cầu được sửa phải dùng nội dung sau khi sửa. Canvas của Make giúp biểu diễn các đường đi đó trong cùng kịch bản.

Zapier cũng hỗ trợ điều kiện và nhánh, nên một quy trình rẽ nhánh không tự động loại nền tảng này. Vấn đề thực tế là mức độ dễ hiểu khi nhánh lồng nhau, cách lần theo một lượt chạy cụ thể và công sức sửa quy tắc mà không ảnh hưởng các đường khác. Nếu luồng thường xuyên thay đổi theo chính sách bán hàng, khả năng bảo trì có thể quan trọng hơn tốc độ dựng phiên bản đầu.

Đưa phê duyệt vào workflow

Agent có thể đề xuất nội dung, nhưng trạng thái duyệt phải quyết định hành động cuối. Hướng dẫn Human in the Loop của Zapier mô tả bước tạm dừng Zap để người được chỉ định chấp thuận, từ chối hoặc sửa dữ liệu; tính năng này yêu cầu tài khoản trả phí. Người dựng luồng có thể cấu hình việc tiếp tục hay dừng khi bị từ chối, cũng như cách xử lý khi hết thời gian chờ.

Trong ví dụ khách hàng tiềm năng, dữ liệu đưa ra duyệt nên là dữ liệu mà người phụ trách cần để ra quyết định, gồm cả nội dung agent định gửi. Nếu người duyệt sửa nội dung, bước gửi phải nhận phiên bản đã sửa. Nếu yêu cầu bị từ chối hoặc hết thời gian chờ, đường đi tiếp theo phải được xác định trước; chỉ nhắc agent “chờ phê duyệt” không tạo ra một trạng thái vận hành có thể theo dõi.

Task, credit và token phải tính theo đường đi

Bảng định mức task của Zapier ghi một tool call qua Zapier MCP tiêu 2 task; bước ứng dụng tiêu chuẩn tiêu 1 task, còn Paths, Filters và Formatter tiêu 0 task. Với AI by Zapier, một bước hoặc tool call dùng model Advanced tiêu 3 task, model Premium tiêu 5 task. Các định mức thuộc những cách triển khai khác nhau: không cộng chi phí MCP vào một Zap không dùng MCP.

Nếu một agent giả định gọi Zapier MCP ba lần để hoàn tất một yêu cầu, phần MCP sẽ là sáu task theo định mức trên. Một yêu cầu khác chỉ gọi một lần sẽ dùng ít task hơn dù cùng tạo được bản ghi cuối. Với Zap chứa bước AI, cần tính bước AI và các hành động ứng dụng thực sự chạy trên nhánh được chọn. Những nhánh dừng sớm hoặc phải thử lại sẽ cho tổng khác với số bước vẽ trong bản thiết kế.

Quy tắc credit của Make ghi phần lớn mô-đun ứng dụng không dùng AI tiêu 1 credit cho mỗi thao tác. Khi dùng Make AI Provider, mức tiêu thụ còn phụ thuộc vào token đầu vào, token đầu ra và mô hình được chọn. Nếu dùng kết nối tới nhà cung cấp AI bằng tài khoản riêng, Make tính credit cho thao tác, còn nhà cung cấp tính tiền token trực tiếp.

Vì vậy, không thể so một task với một credit như hai đơn vị tiền tệ ngang nhau. Với cùng yêu cầu CRM giả định, hãy tách đường thành công ngay, đường thiếu dữ liệu, đường bị từ chối và đường cần gọi lại công cụ. Mỗi đường có số thao tác ứng dụng, lần gọi công cụ và token khác nhau; tần suất xuất hiện của từng đường mới quyết định mức dùng tổng thể. Phần token trả cho nhà cung cấp bên ngoài cần được giữ riêng khỏi hóa đơn nền tảng tự động hóa.

Tiêu chí quyết định nằm ở phần khó nhất

Zapier phù hợp khi agent cần tiếp cận nhiều ứng dụng và mỗi yêu cầu dẫn tới một hành động đã có sẵn. Make đáng ưu tiên khi phần việc chính là điều hướng các nhánh, biến đổi dữ liệu giữa các bước và tìm lại đường đi của một lượt chạy. Với luồng có phê duyệt, hãy đánh giá thêm ai được duyệt, dữ liệu nào được sửa và hệ thống xử lý ra sao sau quyết định đó.

Một phép so sát nhu cầu là dựng cùng yêu cầu điển hình trên các nền tảng đang cân nhắc: kiểm tra hành động cần dùng, quan sát trường hợp dữ liệu sai hoặc thiếu, rồi tính tài nguyên cho từng đường đi có khả năng xảy ra. Cách đó cho thấy độ phủ ứng dụng có giải quyết được việc của agent hay không, đồng thời bộc lộ chi phí của những nhánh mà một mức giá chung cho mỗi lượt chạy thường che khuất.

Đọc thêm:

• LINK áp sát Swift còn 15 km, cuộc giải cứu vẫn kết thúc vì thiếu nhiên liệu
• Bong bóng AI có thật không? Năm chỉ báo tách doanh thu khỏi kỳ vọng
• Ping đưa đặt lại mật khẩu vào Gemini, agent không giữ quyền thường trực