Quy tắc 100 giây: Hết thời gian chờ (timeout), thử lại và xử lý lỗi trong Copilot Studio Agent Flow

Mô hình "phản hồi trước" (respond-first) trong Bài 5 tồn tại vì một lý do: Flow cần cung cấp câu trả lời cho agent thật nhanh, trong khi con người lại phản hồi chậm. Ngày nay, chúng ta phải tính đến cả yếu tố thời gian - cùng mọi sự cố khác có thể xảy ra trong môi trường thực tế: Các kết nối chập chờn, những tiến trình chạy dở dang, hay cơ chế thử lại âm thầm tạo ra hai yêu cầu xử lý cùng lúc.

Dưới đây là trình tự thời gian chi tiết của một lệnh gọi công cụ từ agent, bao gồm các thông số cụ thể lấy từ tài liệu chính thức:

Ba chiến lược thiết kế giúp bạn tránh gặp sự cố nghiêm trọng (tránh rơi vào "vực thẳm" lỗi):

Trả về ít dữ liệu hơn - hãy lọc ngay trong truy vấn thay vì lọc sau đó; việc gọi kết nối để lấy 1.500 hàng nhưng chỉ dùng 5 hàng là nguyên nhân kinh điển dẫn đến lỗi quá thời gian (timeout) do chính người thiết kế gây ra.

Phản hồi sớm - bất kỳ thông tin nào người dùng không cần thấy ngay trong khung chat thì nên để ở bước sau hành động "Respond to the agent" (Phản hồi cho agent).

Tiếp theo, hãy cân nhắc chế độ "express mode" - một tùy chọn xem trước (trên thẻ kích hoạt flow, hoặc tại mục Overview → Details → Edit) giúp thực thi các flow đủ điều kiện nhanh hơn. Chế độ này hữu ích cho các flow có logic phức tạp nhưng lại gây hại cho những flow xử lý nhiều dữ liệu: Khi bật chế độ này, các lần chạy vẫn phải hoàn tất trong vòng 2 phút, giới hạn dưới 100 hành động, biến dưới 1.024 ký tự và dữ liệu của mỗi hành động dưới 64 KB. Hãy kiểm thử kỹ trước khi tin dùng nó.

Hãy đọc thông báo lỗi, đừng đoán mò!

Các lỗi flow phía agent đều nằm trong danh sách lỗi đã được ghi nhận. Hãy phân loại và xử lý chúng thay vì xây dựng lại flow từ đầu:

• Lỗi 3000, "Unexpected error" (Lỗi không xác định) - với flow mới, hãy kiểm tra nguyên nhân phổ biến trước: Tùy chọn "Asynchronous response" trong phần cài đặt của hành động "Respond to the agent" đang được bật. Lỗi này cũng xuất hiện khi giá trị tham số là null hoặc không được hỗ trợ.
• 3001 / 3003 - Power Automate không khả dụng hoặc không thể kết nối; hãy thử lại sau, không cần sửa gì trong thiết kế của bạn.
• 3002, "…your request to your flow wasn't accepted" (Yêu cầu gửi tới flow không được chấp nhận) - tài liệu chỉ ra vấn đề nằm ở thời gian phản hồi: flow có thể đã vượt quá giới hạn 2 phút.
• FlowActionTimedOut - lỗi quá thời gian thực thi (timeout), thường gặp trên các kênh như Teams. Hãy áp dụng ba chiến lược thiết kế đã nêu.
• FlowActionBadRequest - lỗi không khớp schema hoặc dữ liệu đầu vào là null. Giải pháp từ Bài học số 3: Làm mới liên kết công cụ, xác minh tham số và xuất bản lại agent.

Xây dựng quy trình xử lý lỗi trước khi cần đến nó

Bộ công cụ đảm bảo độ tin cậy của Power Automate hoạt động tương tự bên trong các agent flow - bao gồm 4 thành phần, mỗi thành phần là một thẻ:

Run after (Chạy sau khi...) - mọi hành động đều có thể phản ứng dựa trên kết quả của hành động trước đó: thành công (mặc định), thất bại, bị bỏ qua (skipped) hoặc quá thời gian (timed out). Tư duy "nhấp chuột phải" (xem xét các tùy chọn thay thế): "nếu bước này thất bại, người dùng cần biết thông tin gì?" Một nhánh xử lý lỗi trả về thông báo "Tôi không thể kết nối với hệ thống quản lý yêu cầu - dữ liệu chưa được lưu" sẽ tốt hơn nhiều so với phản hồi chung chung kiểu "tôi không biết" từ agent.

Scopes as try/catch - nhóm các bước chính vào một Scope ("Try"), thêm một Scope thứ hai ("Catch") được thiết lập để chỉ chạy khi nhánh "Try" thất bại. Đây là nơi tập trung ghi lại lỗi và soạn thảo câu trả lời trung thực cho người dùng. Đây chính là mô hình được tài liệu hướng dẫn chính thức khuyến nghị.

Retry policy (Chính sách thử lại) - các hành động của connector có thể tự động thử lại khi gặp lỗi tạm thời (cấu hình trong tab cài đặt); khoảng thời gian tăng dần theo cấp số nhân là phương án được khuyên dùng (thử lại nhanh ở lần đầu, sau đó kéo dài thời gian chờ giữa các lần thử tiếp theo). Thử lại rất phù hợp cho các thao tác đọc dữ liệu. Đối với thao tác ghi dữ liệu, hãy xem tiếp phần dưới.

Terminate (Kết thúc) - chủ động kết thúc quy trình với trạng thái "Failed" (Thất bại) kèm theo thông báo cụ thể, giúp lịch sử chạy quy trình hiển thị rõ nguyên nhân thay vì để lại một kết quả mơ hồ, khó hiểu.

Và khái niệm phân biệt giữa quy trình thực tế (production) và bản demo: Tính lũy đẳng (idempotency). Lỗi hết thời gian chờ (timeout) tại agent không phải lúc nào cũng có nghĩa là flow của bạn đã hỏng - có thể nó đã hoàn tất thành công nhưng chậm hơn dự kiến ​​một giây. Khi hệ thống điều phối hoặc người dùng thử lại, cùng một yêu cầu đó sẽ được thực thi lần thứ hai. Bất kỳ bước nào tạo ra dữ liệu mới đều cần cơ chế bảo vệ: Tạo một key định danh ổn định từ yêu cầu (ví dụ: người yêu cầu + hạng mục + ngày tháng), kiểm tra xem key đó đã tồn tại chưa, và thực hiện cập nhật thay vì tạo mới nếu nó đã tồn tại. Nhờ đó, việc thử lại sẽ không gây ra tác dụng phụ ngoài ý muốn.

Hãy thử ngay: Thiết kế cơ chế xử lý lỗi cho Microsoft Copilot Studio agent flow

Nơi dán nội dung: claude.ai hoặc chatgpt.com.

Sao chép câu lệnh (prompt) này và điền thông tin từ kế hoạch dự án cuối khóa của bạn vào các phần giữ chỗ:

Hãy thiết kế cơ chế xử lý lỗi cho Microsoft Copilot Studio agent flow của tôi.

Các bước trong quy trình: [dán danh sách các bước từ Bài 1]

Với mỗi bước, hãy cho tôi biết:
1. Những lỗi thực tế có thể xảy ra (ví dụ: connector bị lỗi, kết quả trả về trống, dữ liệu đầu vào không hợp lệ)
2. Việc thử lại là AN TOÀN (thao tác đọc) hay NGUY HIỂM (thao tác ghi) — và đối với thao tác ghi,
key định danh ổn định nào giúp bước đó có tính lũy đẳng (idempotency)
3. Nội dung thông báo lỗi hiển thị cho người dùng — cần trung thực, cụ thể,
và nêu rõ những gì KHÔNG bị thay đổi

Sau đó, hãy trình bày bố cục Scope Try/Catch dưới dạng một danh sách ngắn gọn.

Kết quả bạn sẽ nhận được: Sơ đồ xử lý lỗi từng bước, xác định các lệnh an toàn khi thử lại và bố cục Scope — đây chính là bản đặc tả độ tin cậy cho quy trình của bạn.

Xử lý kết quả đầu ra: Lưu lại; bản build của Bài 8 triển khai cấu trúc Try/Catch dựa trực tiếp trên danh sách này.

Những điểm chính cần nhớ

• Ngân sách 100 giây, giới hạn cứng ở mức ~2 phút, thời gian xử lý sau phản hồi lên tới 30 ngày - hãy thiết kế dựa trên con số đầu tiên
• Trả về ít dữ liệu hơn, phản hồi sớm, sau đó cân nhắc chế độ "express" (nhanh hơn, nhưng giới hạn ở 100 hành động / biến 1.024 ký tự / 64 KB mỗi hành động và không hỗ trợ mở rộng thời gian chờ)
• Phân loại lỗi dựa trên mã: 3000 → chuyển sang chế độ bất đồng bộ (async) hoặc tham số không hợp lệ; 3002/FlowActionTimedOut → vấn đề thời gian phản hồi; FlowActionBadRequest → cần làm mới schema
• Cấu hình "Run after" + phạm vi Try/Catch + thử lại theo cấp số nhân + Terminate = bộ công cụ 4 thành phần đảm bảo độ tin cậy
• Tính lũy đẳng là yêu cầu bắt buộc đối với các thao tác tạo mới: Key định danh ổn định, kiểm tra trước khi tạo, và các lần thử lại không gây ra tác dụng phụ (trở thành thao tác vô hại).