Tóm tắt nhanh

  • Khi AI được đưa vào messaging, desktop và lịch, công việc kỹ thuật không dừng ở việc gọi mô hình. Đội ngũ cần mô tả công cụ, kiểm tra tham số, quản lý trạng thái và đưa kết quả trở lại UI theo cách người dùng có thể xác minh.
  • Một kiến trúc workflow có ràng buộc tốt giúp hạn chế lỗi thực thi và cho phép thay đổi mô hình hoặc bề mặt tích hợp mà không viết lại logic nghiệp vụ.
  • Chọn một hành động AI và mô hình hóa nó thành các trạng thái đề xuất–xem trước–xác nhận–thực thi, với kiểm tra quyền và nhật ký ở backend.

Điều gì đã xảy ra

AI nhúng vào ứng dụng không nên được kiến trúc như một ô nhập prompt có quyền làm mọi thứ. Khi trợ lý chạm vào messaging, ứng dụng desktop hay lịch, nó cần một lớp workflow biến ý định mơ hồ thành thao tác có giới hạn và kiểm chứng được.

Các tin tức về ChatGPT trong Apple Messages, Meta AI trên Mac và Calendly ở mảng ghi chú cuộc họp cùng hướng sự chú ý vào điểm giao giữa ngôn ngữ tự nhiên và thao tác sản phẩm.

Tách suy luận khỏi thực thi

Mô hình có thể giúp diễn giải yêu cầu và đề xuất thao tác, nhưng không nên là lớp duy nhất quyết định việc gọi công cụ. Backend cần xác thực người dùng, kiểm tra quyền, chuẩn hóa tham số, áp chính sách và tạo bản ghi trước khi thay đổi xảy ra.

Luồng trạng thái AI từ ngữ cảnh đến đề xuất, kiểm tra, xác nhận, thực thi và phục hồi.
Luồng trạng thái AI từ ngữ cảnh đến đề xuất, kiểm tra, xác nhận, thực thi và phục hồi.

Nguyên tắc hữu ích là: mô hình đề xuất, hệ thống quyết định. Điều đó không phủ nhận giá trị của AI; nó đặt AI vào phần phù hợp nhất với tính bất định của ngôn ngữ.

Mô tả công cụ như hợp đồng sản phẩm

Mỗi công cụ nên có mục đích hẹp, kiểu đầu vào rõ, điều kiện tiền đề và kết quả có cấu trúc. Tránh một công cụ “làm bất cứ điều gì với tài khoản”, vì nó khó cấp quyền, khó quan sát và khó phục hồi.

draft_message(recipients, subject, body)
preview_change(resource, proposed_update)
commit_change(change_id, user_confirmation)

Ví dụ này không mô tả API thực tế; nó minh họa việc tách tạo nội dung, xem thay đổi và cam kết thay đổi. Cách tách đó cũng giúp UI biết lúc nào cần yêu cầu xác nhận.

Workflow cần quản lý trạng thái, không chỉ câu trả lời

Một tương tác có thể trải qua các trạng thái như thu thập ngữ cảnh, tạo đề xuất, chờ kiểm tra, xác nhận, thực thi và thất bại. Mỗi chuyển trạng thái cần có quy tắc riêng, đặc biệt khi thao tác có thể bị lặp do mạng, người dùng gửi lại yêu cầu hoặc mô hình trả về kế hoạch khác.

Thiết kế idempotency, mã tham chiếu thao tác và nhật ký sự kiện ngay từ đầu. Những chi tiết này bình thường trong hệ thống phân tán, nhưng trở nên thiết yếu khi đầu vào là ngôn ngữ tự nhiên không ổn định.

Thử nghiệm bằng kịch bản, không chỉ bằng benchmark

Đánh giá phải bao gồm dữ liệu thiếu, yêu cầu mơ hồ, lệnh trái chính sách và trường hợp người dùng đổi ý. Đặt tiêu chí cho việc AI phải hỏi lại, phải dừng hoặc chỉ được tạo bản nháp.

Đợt thử nghiệm hợp lý là một công cụ có tác dụng hẹp, dữ liệu giới hạn và phê duyệt bắt buộc. Khi đó, nhóm có thể quan sát lỗi workflow trước khi mở rộng sang chuỗi hành động dài hơn.

Trong 5 phút

  • AI nhúng cần một lớp workflow, không chỉ một lời gọi mô hình.
  • Để mô hình đề xuất; để backend xác thực, cấp quyền và thực thi.
  • Thiết kế công cụ hẹp, có hợp đồng rõ và bước xem trước.
  • Kiểm thử trạng thái lỗi, mơ hồ và đổi ý như các luồng chính.

Nguồn tham khảo

Vì sao developer cần quan tâm

Một kiến trúc workflow có ràng buộc tốt giúp hạn chế lỗi thực thi và cho phép thay đổi mô hình hoặc bề mặt tích hợp mà không viết lại logic nghiệp vụ.

  1. 1Chọn một hành động AI và mô hình hóa nó thành các trạng thái đề xuất–xem trước–xác nhận–thực thi, với kiểm tra quyền và nhật ký ở backend.