Xây dựng quy trình tự động hóa đã lên kế hoạch ở Bài 1
Ở Bài 1, bạn đã chọn một quy trình tự động hóa thực tế và lưu lại các bước cũng như dữ liệu đầu vào của nó. Mỗi bài học sau đó đã âm thầm xây dựng từng phần của quy trình này: Siêu dữ liệu (metadata) ở Bài 3, ghi chú thông tin xác thực ở Bài 4, nội dung phê duyệt ở Bài 5, sơ đồ xử lý lỗi ở Bài 6, và danh mục triển khai ở Bài 7. Hôm nay, bạn sẽ tiến hành lắp ráp các phần đó lại với nhau - không có khái niệm mới nào cả, chỉ là công việc xây dựng thực tế.
Chúng ta sẽ sử dụng quy trình xử lý yêu cầu của nhóm làm mẫu tham chiếu (các yêu cầu về thiết bị, nghỉ phép hay quyền truy cập đều phù hợp với mô hình này). Kịch bản riêng của bạn có thể được áp dụng ngay vào cấu trúc này.
Từ agent của bạn: Chọn Tools → Add a tool → New tool → Agent flow. Template khởi tạo sẽ cung cấp sẵn bước kích hoạt (trigger) và bước phản hồi cho agent (Respond to the agent).
2. Thiết lập các tham số (Bài 3)
Thêm dữ liệu đầu vào từ phần siêu dữ liệu đã lưu — kiểu Text cho tên và ngày tháng đã định dạng, Number cho số lượng, Boolean cho các flag trạng thái. Dán nguyên văn phần mô tả tham số; chúng đóng vai trò định hướng luồng dữ liệu.
3. Thêm các bước xử lý chính (Bài 4 – 5)
Sử dụng bước Condition (Điều kiện) để phân tách các yêu cầu nhỏ và lớn. Bước ghi dữ liệu sẽ ghi thông tin vào danh sách bằng thông tin xác thực của người dùng cuối - trừ khi quy trình của bạn thuộc trường hợp đặc biệt đã được ghi nhận là sử dụng thông tin xác thực do người tạo cung cấp. Hãy đặt mọi thao tác ghi dữ liệu bên trong phạm vi Try.
4. Phản hồi trước (Bài 5)
Trước khi thực hiện bất kỳ thao tác nào tốn thời gian: Hãy phản hồi cho agent bằng nội dung xác nhận đã soạn thảo - ví dụ: "Đã gửi yêu cầu phê duyệt; bạn sẽ nhận được thông báo sau." Sau đó, thực hiện bước Start và chờ phê duyệt đối với nhánh yêu cầu lớn, rồi mới gửi thông báo kết quả.
5. Kiểm soát các thao tác ghi dữ liệu (Bài 6)
Thực hiện kiểm tra trước khi tạo tại bước ghi dữ liệu; áp dụng cơ chế thử lại theo cấp số nhân chỉ cho các thao tác đọc; sử dụng phạm vi Catch để ghi nhận lỗi chính xác; và kết thúc quy trình (Terminate) kèm thông báo lỗi đối với các trường hợp không thể khôi phục.
6. Gắn kết, mô tả, kiểm thử (Bài 2 - 3, 7)
Xuất bản flow, xác nhận phần mô tả công cụ, sau đó thực hiện quy trình gỡ lỗi: Bản đồ hoạt động → tab Activity → Tổng quan kết nối. Schema có thay đổi trong quá trình xây dựng không? Hãy làm mới và xuất bản lại agent.
Kiểm tra nhanh: Hai thành phần nào từ các bài học trước bạn nên sao chép thay vì viết lại?
Trả lời: siêu dữ liệu của Bài 3 - tên và mô tả được thiết kế làm quy tắc định tuyến - và nội dung phê duyệt của Bài 5. Việc viết lại dựa trên trí nhớ chính là nguyên nhân dẫn đến sự sai lệch so với thiết kế ban đầu.
Danh sách kiểm tra trước khi triển khai
Đây là bảng tham chiếu được xây dựng xuyên suốt khóa học. Mỗi dòng đều tương ứng với một bài học; hãy sao chép nó vào ghi chú của bạn và kiểm tra trước khi bất kỳ agent nào vận hành dựa trên flow được đưa vào sử dụng thực tế.
DANH SÁCH KIỂM TRA TRIỂN KHAI FLOW — [tên flow] — [ngày]
GIAO THỨC KÉT NỐI (Bài 2)
[ ] Có kích hoạt (trigger) "Khi agent gọi luồng" + hành động "phản hồi agent" (Respond to the agent)
[ ] Phản hồi bất đồng bộ (Asynchronous response) = Tắt (Cài đặt phản hồi → Mạng)
[ ] Flow đã xuất bản; công cụ đã được liệt kê trong mục Tools của agent
THAM SỐ (Bài 3)
[ ] Tất cả đầu vào/đầu ra đều là Văn bản (Text), Số (Number) hoặc Boolean; dùng JSON-trong-Văn bản (JSON-in-Text) cho dữ liệu có cấu trúc
[ ] Mỗi tham số đều có mô tả chất lượng cao, hỗ trợ tốt cho việc trích xuất dữ liệu
[ ] Các đầu vào liên quan đến bảo mật sử dụng giá trị tùy chỉnh, không dùng tính năng AI tự điền
[ ] Schema có thay đổi sau khi gắn kết không? Đã làm mới công cụ + xuất bản lại agent
THÔNG TIN XÁC THỰC & CHÍNH SÁCH (Bài 4)
[ ] Đã xem xét xác thực công cụ VÀ kiểm tra tổng quan kết nối của flow
[ ] Thông tin xác thực do người tạo cung cấp: chỉ dùng khi đã có tài liệu hướng dẫn, liệt kê tại đây: ______
[ ] Sự kết hợp các connector tuân thủ các nhóm dữ liệu DLP; không dán thông tin bí mật vào các hành động
THỜI GIAN & TƯƠNG TÁC NGƯỜI DÙNG (Bài 5, Bài 6)
[ ] Phần xử lý đồng bộ có thời gian thực hiện dưới 100 giây với khối lượng dữ liệu thực tế
[ ] Các bước phê duyệt và tác vụ chậm nằm SAU hành động "phản hồi agent"
[ ] Các thao tác ghi có tính lũy đẳng; chỉ thử lại (retry) đối với các thao tác đọc; Phạm vi khối Catch + các lỗi vô ý
TRIỂN KHAI & BẰNG CHỨNG (L7)
[ ] Kiểm tra toàn bộ một lần chạy trong tab Activity, từng bước một
[ ] Một đồng nghiệp KHÔNG PHẢI là người tạo đã chạy thử thành công trên kênh thực tế
[ ] Giải pháp bao gồm flow+ tham chiếu kết nối + biến môi trường
[ ] Kế hoạch nhập cho môi trường Production nêu rõ ai cung cấp từng kết nối
Thử ngay
Nơi dán nội dung: claude.ai hoặc chatgpt.com, cùng với danh sách kiểm tra đã điền thông tin của bạn.
Đây là danh sách kiểm tra triển khai đã hoàn tất cho một agent flow trong Copilot Studio,
cùng với mô tả chức năng của flow đó: [dán checklist + mô tả ngắn gọn trong một câu]
Hãy đóng vai một người đánh giá khắt khe. Đối với ba mục chưa được đánh dấu hoặc
được xác minh sơ sài nhưng tiềm ẩn nhiều rủi ro nhất, hãy cho tôi biết: sự cố thực tế mà mục đó giúp ngăn chặn,
cách tôi có thể xác minh nó trong vòng chưa đầy 10 phút, và tôi sẽ nói gì với những người dùng bị ảnh hưởng
nếu tôi triển khai mà thiếu nó và hệ thống gặp lỗi.
Kết quả nhận được: Bản phân tích rủi ro có thứ tự ưu tiên dựa trên chính checklist của bạn - thường thì nó sẽ chỉ ra đúng mục mà bạn đang âm thầm định bỏ qua.
Kiểm tra nhanh: Không cuộn lên trên - ba mục đầu tiên trong checklist triển khai của bạn là gì? (Nếu bạn không nhớ ngay phần về "giao thức kết nỗi", hãy đọc lại các tiêu chí của Bài 2; đó là nền tảng cho mọi thứ khác).
Bước tiếp theo
Ba hướng đi, tùy thuộc vào việc dự án khiến bạn muốn tìm hiểu thêm về điều gì: Microsoft Copilot cho Microsoft 365 giúp mở rộng phạm vi hoạt động ngay trong môi trường làm việc quen thuộc của người dùng; Các quy trình tự động hóa AI trên n8n thể hiện tư duy tự động hóa tương tự nhưng nằm ngoài hệ sinh thái Microsoft; đồng thời, các quy trình này giúp mở rộng thư viện mô hình mà bạn có thể nhận diện ngay lập tức.
Cách đây 8 bài học, agent của bạn chỉ có thể giao tiếp. Giờ đây, nó có thể thu thập dữ liệu dạng văn bản từ cuộc trò chuyện, thực hiện quy trình tự động hóa nhiều bước có kiểm soát với các thông tin xác thực phù hợp, chuyển các quyết định quan trọng cho con người xử lý mà không làm trễ tiến độ, xử lý lỗi một cách minh bạch, cũng như hoàn thiện quy trình với đầy đủ nhật ký dữ liệu và kế hoạch triển khai. Đó không chỉ là bản demo - đó là kỹ năng mà các tổ chức đang tích cực tìm kiếm.
Những điểm chính cần ghi nhớ
Tính an toàn trong môi trường thực tế (production) là kết quả của nhiều lớp bảo vệ chứ không phải sự may mắn: Giao thức kết nối, tham số, thông tin xác thực, thời gian, bằng chứng - theo đúng thứ tự đó.
Bài kiểm tra quan trọng nhất trước khi ra mắt là để một đồng nghiệp không trực tiếp xây dựng hệ thống vận hành thử trên kênh thực tế.
Các lần chạy thành công chỉ chứng minh hệ thống có thể vận hành chứ không đảm bảo tính chính xác tuyệt đối - hãy kiểm tra dữ liệu khi người dùng báo cáo các vấn đề phát sinh.
Danh mục kiểm tra trước khi triển khai có thể tái sử dụng: Mọi quy trình trong tương lai đều bắt đầu từ đó, thay vì dựa vào trí nhớ.
Kế hoạch từ Bài 1, được phát triển qua các Bài 2 – 7, giờ đây đã trở thành một quy trình tự động hóa hoàn chỉnh và đáng tin cậy.
Câu 1:
Một tuần sau khi triển khai, tab Activity hiển thị trạng thái màu xanh cho mọi lần chạy - tuy nhiên, hai người dùng khẳng định họ chưa bao giờ nhận được thông báo kết quả. Bước đi đầu tiên hiệu quả là gì?
GIẢI THÍCH:
Trạng thái màu xanh chỉ có nghĩa là các hành động đã được thực thi - chứ không có nghĩa là chúng chạy với dữ liệu chính xác. Việc mở các lần chạy cụ thể và xem dữ liệu mà bước gửi thông báo đã nhận (thói quen kiểm tra bằng chứng trong Bài học số 7) sẽ làm sáng tỏ vấn đề chỉ trong vài phút: dữ liệu đầu vào cho địa chỉ bị bỏ trống sẽ dẫn đến việc gửi thông báo "thành công" nhưng không đến đích nào cả. Biểu đồ phân tích chỉ hiển thị khối lượng dữ liệu, việc đăng lại không tác động đến các thành phần bên trong quy trình, còn việc khôi phục phiên bản cũ mà không chẩn đoán nguyên nhân chỉ đơn thuần là chuyển vấn đề bí ẩn đó sang một trạng thái khác.
Câu 2:
Bước cuối cùng của dự án là đăng một bản tóm tắt vào kênh thông báo bị khóa, nơi người dùng thông thường không thể đăng bài. Nhóm đang có ý kiến trái chiều về thiết kế. Quan điểm nào là hợp lý?
GIẢI THÍCH:
Đây là trường hợp cụ thể, hợp lệ về việc người tạo cung cấp thông tin xác thực đã nêu trong Bài học số 4: Một hành động có thể kiểm tra và bắt buộc phải thành công thay mặt cho những người dùng vốn không có quyền thực hiện hành động đó. Việc chỉ sử dụng thông tin xác thực của người dùng cuối sẽ làm hỏng tính năng; việc từ bỏ tính năng này vì lý do đó là sự nhầm lẫn giữa quyết định về thông tin xác thực và lỗi thiết kế; còn agent không có xác thực thì hoàn toàn không thể chạy các công cụ yêu cầu thông tin xác thực người dùng - nó làm tăng phạm vi rủi ro thay vì thu hẹp lại.
Câu 3:
Việc triển khai chính thức sẽ diễn ra vào ngày mai và bạn chỉ có đủ thời gian để kiểm tra kỹ lưỡng đúng một mục trong danh sách kiểm tra. Mục nào mang lại sự đảm bảo an toàn cao nhất?
GIẢI THÍCH:
Việc chạy thử trong dashboard của chính người tạo flow không thể phát hiện các lỗi kinh điển như: Kết nối gắn với tài khoản người tạo, agent chưa được chia sẻ, hay lỗi schema chỉ xuất hiện trên kênh thực tế. Chỉ cần một lần chạy thử bởi đồng nghiệp thực tế trên kênh thực tế là có thể kiểm tra toàn diện quy trình triển khai. Dữ liệu Analytics có độ trễ quá lớn để dùng làm điều kiện quyết định việc ra mắt, và công cụ Flow checker đã chặn mọi lỗi mà nó có thể phát hiện ngay tại thời điểm xuất bản.
Câu 4:
Tomás đã triển khai dự án của mình với quy trình: Xác thực → tạo bản ghi → phản hồi cho agent → phê duyệt → thông báo. Khi hệ thống chịu tải cao, một số người dùng gặp lỗi hết thời gian chờ (timeout) VÀ xuất hiện các bản ghi trùng lặp. Cặp lỗi nào giải thích cho cả hai hiện tượng này?
GIẢI THÍCH:
Cả hai triệu chứng đều bắt nguồn từ phần xử lý đồng bộ: Thao tác tạo bản ghi chậm nằm trước bước phản hồi cho agent khiến quy trình chạy vượt quá giới hạn thời gian (gây lỗi timeout), và mỗi lệnh gọi bị timeout sẽ kích hoạt việc thử lại tại bước vốn sẽ tiếp tục tạo bản ghi mới (gây trùng lặp). Bước phê duyệt nằm an toàn sau bước phản hồi; việc lưu cache chỉ làm hỏng schema chứ không tạo bản ghi; còn chính sách DLP hay lịch sử phiên bản đều không thực hiện chèn thêm dòng dữ liệu.
Theo Nghị định 147/2024/ND-CP, bạn cần xác thực tài khoản trước khi sử dụng tính năng này. Chúng tôi sẽ gửi mã xác thực qua SMS hoặc Zalo tới số điện thoại mà bạn nhập dưới đây: