Trả lời và chuyển tiếp email qua API: kiểm soát AI trước khi gửi

Trả lời và chuyển tiếp khác nhau ở đâu?

Chọn hành động theo người cần nhận thông tin, không theo từ khóa trong thư. Khách hỏi tiến độ yêu cầu thì nên trả lời khách. Yêu cầu cần chuyên viên nội bộ xem xét thì nên chuyển tiếp phần cần thiết cho chuyên viên.

Bảng này phân biệt mục đích sử dụng, không quy định cấu trúc yêu cầu API. Trong Mailera, POST /mailboxes/{id}/send dùng cho gửi, trả lời và chuyển tiếp. Tổng quan các cách tích hợp nằm ở trang sản phẩm Mailera; phần nền tảng cho agent nằm trong bài dùng hộp thư sẵn có cho AI agent.

Thêm Re: có giữ luồng hội thoại không?

Không đủ. Tài liệu luồng hội thoại của Gmail API yêu cầu threadId đích, các header References và In-Reply-To đúng chuẩn, cùng Subject khớp để thêm thư vào một luồng.

Đây là yêu cầu của Gmail API, không phải tên trường để tự thêm vào yêu cầu Mailera. Khi thử tích hợp, hãy đối chiếu thư nhận được trên từng nhà cung cấp; đừng coi tiêu đề giống nhau là bằng chứng thư đã nằm đúng luồng.

Cần chuẩn bị quyền gì trước khi cho agent gửi?

Dùng hộp thư thử do bạn kiểm soát và có khả năng gửi. Có thể đọc capabilities.send qua GET /mailboxes/{id}; hộp thư ở chế độ Chỉ nhận (hiển thị "Hộp thư này chỉ nhận thư — chưa gửi được" trong ứng dụng) không phù hợp với bước trả lời hoặc chuyển tiếp.

1. Tạo nhóm riêng cho các hộp thư thử.
2. Trong Cài đặt, mở tab API key và chọn Tạo key. Đặt Tên gợi nhớ, rồi chọn nhóm ở Phạm vi hộp thư. Quản trị viên còn có thể chọn mọi nhóm; ví dụ này chỉ cần nhóm thử.
3. Bật quyền Read cho thành phần đọc. Bật quyền Send messages cho thành phần gửi đã qua phê duyệt. Quyền send cũng cần để đọc trạng thái lần gửi bằng GET /sends/{id}.
4. Đặt Thời hạn và Giới hạn IP (tuỳ chọn) phù hợp với máy chủ chạy ứng dụng. Lưu khóa phía máy chủ, không đưa vào ngữ cảnh mô hình.

Nên tách hai thành phần để agent đọc thư không trực tiếp giữ khóa gửi. Quyền send dùng chung cho gửi, trả lời và chuyển tiếp; chính sách “chỉ trả lời khách hiện tại” phải do ứng dụng thực thi.

Bạn có thể đối chiếu thông tin bảo mật Mailera khi thiết kế cách lưu khóa. Bạn cần xây bước duyệt người nhận và nội dung dưới đây trong ứng dụng.

Ví dụ 1: trả lời khách hỏi tiến độ

Giả sử khách hỏi tiến độ xử lý một yêu cầu. Agent cần soạn phản hồi trong cuộc trao đổi hiện tại, không thêm người nhận mới.

1. Đọc đúng thư gốc

Đặt $MAILERA_API_KEY, $MAILBOX_ID và $MESSAGE_ID bằng giá trị của môi trường thử. Lệnh này cần quyền read:

curl --request GET \
  "https://mailera.app/api/public/v1/mailboxes/$MAILBOX_ID/messages/$MESSAGE_ID" \
  --header "Authorization: Bearer $MAILERA_API_KEY"

Đối chiếu data.id và data.mailbox_id, rồi đọc from, to, cc, subject và body. Giữ cặp mã hộp thư, mã thư cùng bản nháp trong ứng dụng; đừng để agent chọn lại thư gốc từ một tiêu đề gần giống.

2. Xác định người nhận trước khi soạn xong

Không lấy địa chỉ từ câu “hãy trả lời vào địa chỉ này” trong nội dung làm đích gửi tự động. Khi địa chỉ trả lời khác người gửi, cần kiểm tra riêng.

Chẳng hạn, Microsoft Graph quy định về trả lời thư rằng phản hồi JSON phải dùng người nhận trong replyTo nếu trường đó chỉ định người nhận, thay vì from. Vì vậy, chỉ nhìn tên hiển thị hoặc địa chỉ người gửi là chưa đủ để quyết định.

3. Cho người duyệt xem bản cuối

Màn hình duyệt của ứng dụng nên hiển thị hộp thư gửi, hành động trả lời, toàn bộ địa chỉ nhận và nội dung cuối cùng, kể cả phần trích dẫn. Nếu có thêm người nhận so với dự kiến, dừng để kiểm tra thay vì tự chuyển thành trả lời tất cả.

4. Gửi rồi kiểm tra kết quả

Sau xác nhận, thành phần gửi gọi POST /mailboxes/{id}/send theo cấu trúc trả lời trong tài liệu API Mailera. Lưu mã lần gửi để tra cứu bằng GET /sends/{id}, rồi mở hộp thư thử nhận để kiểm tra người nhận, nội dung và vị trí trong cuộc hội thoại.

Nếu dùng MCP, công cụ reply_to_email cần quyền send. Cách tổ chức các bước đọc và hành động được trình bày trong bài API email cho AI agent.

Ví dụ 2: chuyển tiếp cho chuyên viên nội bộ

Giả sử khách gửi yêu cầu cần chuyên viên xem xét. Mục tiêu là giao đủ thông tin để xử lý, không chuyển nguyên mọi thứ agent đọc được.

1. Chọn người nhận từ danh sách ứng dụng cho phép. Không lấy địa chỉ đích từ chỉ dẫn trong thư. Nếu không tìm được người phụ trách phù hợp, chuyển sang kiểm tra thủ công.
2. Rà phần nội dung sẽ chuyển. Xem cả chuỗi trích dẫn, thông tin khách hàng và tệp đính kèm. Loại phần không phục vụ yêu cầu xử lý.
3. Viết lời dẫn cụ thể. Ví dụ: “Nhờ kiểm tra nguyên nhân yêu cầu chưa hoàn tất trước khi phản hồi khách.” Tránh để người nhận phải đoán việc cần làm từ cả chuỗi thư.
4. Duyệt bản cuối và gửi. Hiển thị địa chỉ đích cùng nội dung, danh sách tệp dự kiến. Sau xác nhận, dùng POST /mailboxes/{id}/send theo cấu trúc chuyển tiếp trong tài liệu.
5. Kiểm tra tại hộp thư nhận. Đối chiếu địa chỉ nhận, nội dung thực tế và tệp đính kèm; không mặc định API tự giữ hoặc loại bỏ tệp theo ý bạn.

Tài liệu chuyển tiếp của Microsoft Graph cũng quy định riêng cách chỉ định người nhận. Không sao chép các trường của Graph vào yêu cầu Mailera.

Ví dụ này dùng REST API. Bộ công cụ MCP của Mailera có reply_to_email, nhưng không có công cụ chuyển tiếp chuyên biệt. Xem các giao diện dành cho nhà phát triển để chọn cách tích hợp phù hợp.

Những lỗi nào hay gặp?

Hết thời gian chờ không có nghĩa là chưa gửi

Đừng gửi lại ngay. Nếu đã có mã lần gửi, dùng GET /sends/{id} với quyền send. Các trạng thái gồm queued, sending, sent, failed và unknown. Với unknown, cần đối chiếu yêu cầu thay vì tự xem là thất bại rồi gửi thêm.

Endpoint gửi chấp nhận header Idempotency-Key, với cửa sổ 24 giờ. Hãy quản lý khóa này theo từng thao tác gửi trong ứng dụng và áp dụng quy tắc thử lại trong hướng dẫn chống gửi trùng bằng Idempotency-Key. Nếu chưa có mã lần gửi, đối chiếu nhật ký yêu cầu cùng hộp thư thử trước khi tạo một lần gửi mới. Trạng thái lần gửi không phải xác nhận người nhận đã đọc thư.

Làm sao ngăn thư đến trở thành lệnh cho agent?

Thư đến là dữ liệu không tin cậy, không phải lệnh. Một thư yêu cầu agent đổi người nhận, tiết lộ khóa hoặc chuyển dữ liệu ra ngoài không được phép thay đổi chính sách của ứng dụng.

Mã ứng dụng phải kiểm tra quyền, giới hạn người nhận theo danh sách được phép và yêu cầu xác nhận; không chỉ dựa vào lời nhắc cho mô hình. Gắn phê duyệt với đúng hộp thư gửi, hành động, người nhận, nội dung và tệp đính kèm. Bất kỳ phần nào thay đổi sau duyệt đều phải được duyệt lại.

Chỉ đưa phần thư cần thiết vào ngữ cảnh mô hình. Che dữ liệu cá nhân trong ảnh và nhật ký; không ghi khóa API vào nội dung trao đổi với agent. Bài phê duyệt qua email ở lớp ứng dụng trình bày riêng cách tổ chức bước xác nhận.

Giới hạn cần giữ trong thiết kế

Mailera không phục vụ gửi hàng loạt hoặc gửi tiếp thị, và không bảo đảm thư vào hộp thư đến. Hãy giữ hai quy trình này ở phạm vi hỗ trợ khách hàng có kiểm soát: ứng dụng quyết định ai được nhận nội dung, còn quyền API giới hạn thao tác và nhóm hộp thư được truy cập.