Con đường đưa tác nhân AI vào sản xuất theo Microsoft

Tổng quan

Chương trình tăng tốc (accelerator) Path to Production for Agents ngày 27/7 của Microsoft làm nổi bật điểm nghẽn thực sự: một tác nhân hoạt động tốt ở bản mẫu (prototype) vẫn chưa thể gửi tin nhắn tiếp cận SDR, thay đổi chiến dịch hay ghi dữ liệu vào CRM một cách an toàn nếu thiếu cơ chế quản trị cho hành vi bất định (non-deterministic). Khi thiếu cơ chế đó, đội ngũ marketing phải quay về khâu duyệt thủ công chậm chạp, và khâu này vẫn bỏ sót những hành động lệch chuẩn thương hiệu hoặc không tuân thủ một khi tác nhân chạy ở quy mô lớn. Bài viết này chuyển hướng dẫn kỹ thuật của Microsoft thành một khung vận hành gồm các bước kiểm tra an toàn thương hiệu, điểm phê duyệt, giám sát AgentOps, điều kiện dừng và kiểm soát chi phí theo từng quy trình, dựa trên kỷ luật vận hành production có quản trị mà Van Data Team áp dụng cho các hệ thống marketing dùng tác nhân AI.

Với các đội ngũ marketing B2B, RevOps và kỹ thuật, Microsoft Path to Production for Agents đáng chú ý vì chương trình xử lý đúng phần việc khó: đưa tác nhân AI từ bản mẫu thành hệ thống production an toàn, đáng tin cậy và có quản trị. Ngày 27/7/2026, Microsoft khởi động chương trình chuyên sâu kéo dài hai ngày của Azure Tech Community. Đây là một chương trình tăng tốc mang tính đào tạo, tập trung vào kỹ thuật, không phải một sản phẩm mới hay một giải pháp về marketing và an toàn thương hiệu.

Sự phân biệt đó rất quan trọng khi một tác nhân có thể liên hệ khách hàng tiềm năng, thay đổi quyết định chiến dịch, ghi dữ liệu vào CRM hoặc xuất bản nội dung. Vanaxity, tác nhân nội dung tự chủ của Van Data Team, áp dụng cùng kỷ luật production đó cho SEO, GEO và AEO: Vanaxity nghiên cứu, viết, minh họa, xuất bản và phân phối nội dung qua các bước chuyển tiếp có quản trị. Tại Van Data Team, chúng tôi bắt đầu bằng việc lập bản đồ quyền truy cập dữ liệu, quyền thực hiện hành động, bước duyệt, báo cáo và phương án phục hồi trước khi mở rộng quyền tự chủ.

Bài viết này tách bạch phạm vi chương trình của Microsoft theo thông tin được công bố với phân tích marketing của Vanaxity. Bài viết cung cấp cho người vận hành một khung thực tiễn, một thiết kế điều kiện dừng cho AgentOps, các câu hỏi về kiến trúc và một danh mục kiểm tra triển khai.

Những điểm cốt lõi cần nắm vững

Bài học cốt lõi là một tác nhân có năng lực vẫn chưa sẵn sàng cho production cho đến khi các hành động của nó được giới hạn, quan sát được, truy được trách nhiệm và khôi phục được.

• Microsoft đang cung cấp hướng dẫn kỹ thuật để đưa tác nhân vào production, chứ không ra mắt một sản phẩm tác nhân mới.
• Các chủ đề kỹ thuật đã được xác nhận gồm sự tin cậy, quản trị, mở rộng quy mô có kiểm soát, điều phối hiệu quả, chi phí hợp lý và AgentOps cho các hệ thống bất định.
• Vanaxity khuyến nghị coi tin nhắn công khai, thao tác ghi vào CRM, thay đổi chiến dịch và quyết định chi tiêu là những hành động phải qua điểm phê duyệt.
• Các đội ngũ vận hành production cần đánh giá dựa trên bằng chứng, quy tắc thương hiệu rõ ràng, nhật ký kiểm toán, hạn mức chi phí, điều kiện dừng và một chế độ dự phòng an toàn chỉ soạn bản nháp.
• Trong câu chuyện khách hàng PwC do Microsoft công bố, dự án thí điểm ChatPwC ban đầu kéo dài hơn bốn tuần một chút cho thấy 88% người dùng cho biết tiết kiệm được thời gian, 86% rất hài lòng và 69% cho biết độ chính xác và chất lượng được cải thiện. Đây là tín hiệu về giá trị của dự án thí điểm, không phải bằng chứng rằng các hành động hệ trọng của tác nhân đã được quản trị an toàn. Microsoft công bố kết quả thí điểm tại đây.

Để thấy các cơ chế kiểm soát đó vận hành xuyên suốt một quy trình nội dung, hãy xem tác nhân Vanaxity hoạt động thực tế.

Microsoft Path to Production for Agents bao gồm những gì

Chương trình tăng tốc của Microsoft bao quát vòng đời kỹ thuật, từ một bản mẫu tác nhân đầy hứa hẹn đến khi vận hành production có kiểm soát, với các chủ đề đã được xác nhận là sự tin cậy, quản trị, kiến trúc có khả năng mở rộng, điều phối với chi phí hợp lý và AgentOps.

Tên sự kiện của Microsoft nêu nhiệm vụ vận hành một cách súc tích:

"Path to production for agents." (Tạm dịch: Lộ trình đưa tác nhân vào production.)

Sự kiện này không tuyên bố giải quyết bài toán quản trị marketing. Microsoft đang đề cập đến các nguyên tắc thực hành kỹ thuật cho hệ thống AI tác nhân. Những ứng dụng về marketing, bán hàng, an toàn thương hiệu và FinOps dưới đây là phân tích của Vanaxity về cách các nguyên tắc đó nên được chuyển hóa vào những quy trình tiếp xúc trực tiếp với khách hàng.

Phân tích của Vanaxity: Vì sao mức sẵn sàng cho production lại quan trọng

Mức sẵn sàng cho production trở thành điểm nghẽn khi tác nhân có thể thực hiện hành động hệ trọng, vì đầu ra trôi chảy không chứng minh được rằng hành động đã được ủy quyền, có căn cứ dữ kiện, tuân thủ chính sách hay có thể phục hồi an toàn.

Một nghiên cứu điển hình trong ngành dịch vụ chuyên nghiệp cung cấp một mốc cơ sở đã được đo lường từ dự án thí điểm, thay vì một kết quả giả định. Trong dự án thí điểm ChatPwC ban đầu của PwC, kéo dài hơn bốn tuần một chút, 88% người dùng cho biết hệ thống giúp tiết kiệm thời gian, 86% rất hài lòng và 69% cho biết hệ thống cải thiện độ chính xác và chất lượng. Câu chuyện khách hàng của Microsoft ghi lại các số liệu đó. Những con số này cho thấy giá trị mà người dùng cảm nhận được và mức độ chấp nhận sử dụng, nhưng không chứng minh được việc dùng công cụ an toàn, tuân thủ quy trình phê duyệt hay khả năng ngăn thao tác ghi vào CRM trái phép.

Với một quy trình RevOps, yêu cầu kiểm soát production vẫn không đổi: nếu việc nghiên cứu một tài khoản khách hàng đã được duyệt sử dụng dữ liệu chưa có nguồn gốc được phê duyệt, hoặc một bản nháp ngụ ý một kết quả khách hàng không có căn cứ, vòng kiểm soát nên chặn tuyên bố đó, từ chối gửi khi chưa được phê duyệt, ghi lại lần thử thực hiện hành động và trả bản nháp về để nghiên cứu thêm. Văn phong hay hơn sẽ không làm quy trình trở nên an toàn; cơ chế kiểm soát tốt hơn thì có.

Tính bất định làm thay đổi mô hình vận hành. Các đội ngũ nên quan sát dữ liệu đầu vào, bằng chứng được truy xuất, các quyết định, yêu cầu gọi công cụ, đầu ra, phê duyệt, chi phí, lỗi và kết quả xử lý cuối cùng. Họ cũng cần các trạng thái rõ ràng: tiếp tục, tạm dừng, chuyển về chế độ chỉ soạn bản nháp, chuyển cấp hoặc chấm dứt. Tin tưởng mù quáng không phải là một chiến lược triển khai.

Marketing đẩy mức rủi ro lên cao hơn vì các hành động vượt ra ngoài ranh giới tổ chức. Một bài đăng công khai có thể làm tổn hại uy tín. Một cập nhật CRM trái phép có thể làm hỏng dữ liệu pipeline bán hàng. Một thay đổi chiến dịch có thể tiêu tiền hoặc mở rộng tệp đối tượng. Vì vậy, Vanaxity khuyến nghị cần có con người phê duyệt bất cứ khi nào một hành động tiếp xúc trực tiếp với khách hàng, mang tính công khai, có ảnh hưởng đáng kể về tài chính, khó đảo ngược hoặc nằm ngoài phạm vi đã được phê duyệt trước.

Khung vận hành cho marketing dùng tác nhân AI

Một tác nhân marketing chạy trong production cần có phạm vi hành động, ngưỡng nghiệm thu, chính sách có thể thực thi, dữ liệu đo lường vận hành (telemetry) và những người phụ trách chịu trách nhiệm trước khi được trao quyền tự chủ.

Xác định mục tiêu và phạm vi hành động

Hãy bắt đầu từ kết quả kinh doanh, sau đó xác định ranh giới xung quanh kết quả đó. Ghi lại các nguồn dữ liệu, tệp đối tượng, kênh, công cụ và hành động được phép. Liệt kê các hành động bị cấm với mức độ rõ ràng tương tự. Chỉ định một người phụ trách nghiệp vụ chịu trách nhiệm về kết quả và một người phụ trách kỹ thuật chịu trách nhiệm về độ tin cậy và sự cố.

Tại Van Data Team, chúng tôi bắt đầu bằng các câu hỏi: Tác nhân được phép đọc những gì? Được phép đề xuất những gì? Được phép thực thi những gì? Việc gì luôn cần phê duyệt? Bằng chứng nào phải được lưu giữ lại sau phiên chạy? Cách làm này biến một chỉ dẫn mơ hồ như "tăng trưởng pipeline" thành một quy trình có thể quản trị được.

Xây dựng bộ đánh giá và ngưỡng nghiệm thu

Kiểm thử khả năng hoàn thành tác vụ, mức bám sát dữ kiện, mức tuân thủ chính sách, cách xử lý dữ liệu, việc chọn công cụ và khả năng phục hồi khi gặp lỗi. Bộ đánh giá nên gồm các trường hợp thông thường, mơ hồ, mang tính đối kháng và thiếu dữ liệu đầu vào. Một bản demo trau chuốt là bằng chứng cho thấy điều đó khả thi, không phải bằng chứng rằng hệ thống phù hợp để chạy production.

Tiêu chí phát hành nên bao quát cả chất lượng lẫn vận hành. Hãy đo xem tác nhân có chọn đúng công cụ, giữ trong ngân sách token, đáp ứng mức độ trễ chấp nhận được của quy trình, cung cấp dữ liệu truy vết hữu ích, giữ khối lượng duyệt trong tầm kiểm soát và phục hồi an toàn hay không. Các mục tiêu về chi phí và độ trễ vốn biến động cần được đo trong môi trường của chính bạn, không mượn từ một benchmark không liên quan.

Biến an toàn thương hiệu thành các bước kiểm tra có thể thực thi

An toàn thương hiệu nên là một lớp chính sách, không phải một câu trong prompt hệ thống. Một bộ quy tắc thực tiễn nên:

• Yêu cầu bằng chứng đã được duyệt cho các tuyên bố về dữ kiện và bằng chứng có liên kết nguồn cho các số liệu cụ thể.
• Chặn các nội dung bịa đặt về kết quả khách hàng, giá, cam kết bảo đảm, quan hệ liên kết và cam kết pháp lý.
• Thực thi các quy tắc đã duyệt về tệp đối tượng, giọng điệu, kênh và mục đích sử dụng dữ liệu.
• Từ chối việc gửi, xuất bản, thay đổi chi tiêu chiến dịch và ghi dữ liệu vào hệ thống khách hàng khi chưa có phê duyệt bắt buộc.
• Dừng lại khi chưa xác định được nguồn gốc, độ mới, dòng dữ liệu (lineage) hoặc tình trạng cấp phép của dữ liệu.
• Lưu giữ bản nháp, bằng chứng, kết quả kiểm tra chính sách và quyết định của con người để phục vụ kiểm toán.

Áp dụng AgentOps và FinOps theo từng quy trình

Cơ chế giám sát theo kiểu AgentOps nên liên kết mỗi quyết định và mỗi lần gọi công cụ với đầu vào, phiên bản chính sách, phê duyệt, kết quả và lộ trình phục hồi tương ứng. Cơ chế kiểm soát theo kiểu FinOps nên phân bổ mức sử dụng cho từng tác nhân, quy trình, chiến dịch và kết quả kinh doanh, sau đó áp dụng các hạn mức đã cấu hình. Khi chạm hạn mức, hệ thống nên tạm dừng, hạ cấp hoặc xin phê duyệt thay vì âm thầm chi vượt mức.

Nếu đội ngũ của bạn muốn đưa mô hình này vào vận hành, hãy yêu cầu một buổi rà soát quy trình miễn phí qua trang cách Vanaxity hoạt động. Đầu ra hữu ích không phải là một cuộc gọi chung chung: đó là bản đồ nguồn dữ liệu và phân quyền, thiết kế bước duyệt, danh sách các lỗ hổng giám sát, quy trình xử lý rủi ro và một kế hoạch triển khai có phạm vi rõ ràng.

Điều kiện tiên quyết về kiến trúc và dữ liệu

Kiến trúc nên được lựa chọn dựa trên yêu cầu kiểm soát và phục hồi của quy trình, trong khi chất lượng dữ liệu và quyền dùng công cụ vẫn thuộc cùng một ranh giới production.

Hệ sinh thái công cụ liên quan gồm LangGraph, LangChain, CrewAI, cơ chế gọi hàm gốc (native function calling), Plan-and-Execute và bộ công cụ tác nhân của Microsoft Foundry. Đây là các phương án triển khai, không phải sự bảo chứng của Vanaxity hay khuyến nghị của Microsoft trong bối cảnh marketing.

Giao diện công cụ và MCP nên được xem là những ranh giới có quản trị. Hãy dùng schema rõ ràng, quyền ở mức tối thiểu cần thiết, tham số đã được xác thực, thời gian chờ tối đa (timeout), tính lũy đẳng (idempotency) ở những nơi hành động có thể lặp lại, và bước kiểm tra phê duyệt trước các lệnh gọi không thể đảo ngược. Tác nhân không bao giờ nên được thừa hưởng quyền truy cập rộng chỉ vì việc tích hợp như vậy thuận tiện.

Kỹ thuật dữ liệu cũng quan trọng không kém. Tác nhân thừa hưởng chất lượng, dòng dữ liệu, độ mới, quy tắc truy cập và kỳ vọng về mức dịch vụ của các hệ thống mà nó đọc và ghi. Airflow, dbt, Kafka và kho dữ liệu là những ví dụ về hạ tầng có thể nằm trong ranh giới đó. Nếu một pipeline dữ liệu không đáp ứng yêu cầu về độ mới, tác nhân phụ thuộc vào nó nên tạm dừng thay vì tự ứng biến. Vòng kiểm soát liên tục này là trọng tâm trong lợi thế của Vanaxity so với một danh mục kiểm tra SEO thủ công.

Giám sát AgentOps và thiết kế điều kiện dừng

Một thiết kế AgentOps hữu ích gắn mỗi rủi ro đáng kể với bằng chứng có thể quan sát, một điều kiện dừng, một người phụ trách và một phản ứng an toàn.

Tài liệu mẫu dưới đây là thiết kế vận hành do Vanaxity khuyến nghị, không phải hướng dẫn của Microsoft. Hãy điều chỉnh cho phù hợp với chính sách, hệ thống và mức độ rủi ro của bạn.

Cảnh báo yêu cầu sự chú ý trong khi công việc vẫn có thể tiếp tục. Tạm dừng là đóng băng tiến trình để chờ bằng chứng hoặc phê duyệt. Chặn là từ chối một hành động cụ thể. Hoàn tác là cố gắng khôi phục trạng thái trước đó sau khi đã thực thi. Không nên coi các trạng thái này là có thể thay thế cho nhau.

Chế độ dự phòng chỉ soạn bản nháp đặc biệt hữu ích. Nếu mất cơ chế phê duyệt, khả năng ghi nhật ký, mức sẵn sàng của dữ liệu hoặc nguồn ngân sách chi trả, tác nhân chỉ có thể tiếp tục chuẩn bị các nội dung không công khai khi chính sách cho phép. Tác nhân không được gửi, xuất bản, chi tiêu hay ghi vào hệ thống khách hàng.

Các chỉ số hiệu suất chính (KPI)

Mức sẵn sàng cho production của tác nhân AI nên được đo bằng các KPI riêng cho giá trị thí điểm, chất lượng đánh giá, hiệu quả kiểm soát, độ ổn định vận hành và chi phí. Một điểm hài lòng duy nhất hay một bản demo thành công không phải là tiêu chuẩn sẵn sàng cho production.

Bằng chứng benchmark từ dự án thí điểm

Câu chuyện khách hàng PwC do Microsoft công bố báo cáo các kết quả sau từ dự án thí điểm ChatPwC ban đầu, kéo dài hơn bốn tuần một chút. Đây là các benchmark thí điểm dựa trên bằng chứng, không phải ngưỡng phát hành áp dụng chung cho mọi trường hợp.

Các số liệu này lấy từ một câu chuyện khách hàng của Microsoft về đợt triển khai GenAI an toàn và có khả năng mở rộng. Nguồn này không báo cáo mức giảm của các thao tác ghi vào CRM trái phép, các lần bỏ qua bước phê duyệt, vi phạm chính sách hay lệnh gọi công cụ không an toàn. Vì vậy, các kết quả quản trị đó phải được đo lường riêng thay vì suy ra từ kết quả thí điểm.

Ngưỡng sẵn sàng cho production

Hướng dẫn đánh giá mức sẵn sàng của Microsoft Copilot Studio đưa ra các điểm khởi đầu mẫu dựa trên mức rủi ro và cảnh báo rõ rằng đó không phải tiêu chuẩn áp dụng chung. Các đội ngũ nên hiệu chỉnh chúng theo hậu quả khi thất bại, tần suất sử dụng, phương án dự phòng sẵn có, đối tượng người dùng và mức độ rủi ro pháp lý.

Một vòng cải tiến chỉ hoàn tất khi mọi bộ đánh giá đều vượt ngưỡng đã hiệu chỉnh, các lỗ hổng đã biết đều có người phụ trách và mốc thời gian, các lần chạy lại cho kết quả nhất quán và không còn vấn đề cấu hình nào gây chặn.

KPI kiểm soát quy trình

Hãy theo dõi các chỉ số sau cho từng tác nhân và quy trình, ngay cả khi chưa có ngưỡng chung nào được dẫn nguồn:

• Tỷ lệ thực thi hành động trái phép: số hành động hệ trọng trái phép đã được thực thi chia cho tổng số yêu cầu hành động hệ trọng.
• Tỷ lệ bỏ qua phê duyệt: số hành động hệ trọng được thực thi khi chưa có phê duyệt hợp lệ chia cho tổng số hành động hệ trọng đã thực thi.
• Mức đầy đủ của dấu vết: số phiên chạy có đủ mọi bản ghi bắt buộc về đầu vào, bằng chứng, quyết định, lệnh gọi công cụ, phê duyệt, kết quả và lỗi chia cho tổng số phiên chạy.
• Tỷ lệ hoàn tác thành công: số lần đảo ngược thành công chia cho số lần thử hoàn tác.
• Tỷ lệ thử lại: số lần thử lại với công cụ hoặc mô hình chia cho tổng số lần thử thực thi.
• Gánh nặng cho người duyệt: số phút con người dành để duyệt chia cho số đầu ra được chấp nhận.
• Chi phí cho mỗi đầu ra được chấp nhận: chi phí mô hình, công cụ, dữ liệu, hạ tầng và người duyệt chia cho số đầu ra vượt qua ngưỡng nghiệm thu.
• Thời gian phục hồi: khoảng thời gian từ khi xảy ra lỗi gây chặn hoặc sự cố đến khi khôi phục an toàn hoặc chuyển sang phương án dự phòng đã được ghi thành văn bản.

Đừng gán cho các cơ chế kiểm soát này một tỷ lệ phần trăm không có bằng chứng. Hãy thiết lập mốc cơ sở đo được trong giai đoạn thí điểm, xác định ngưỡng theo mức rủi ro của quy trình và chỉ báo cáo mức cải thiện khi đã có các quan sát tương đương trước và sau khi áp dụng kiểm soát.

Đoạn JSON-LD sau định nghĩa rõ các bảng hiển thị trong bài viết dưới dạng thực thể ItemList của schema.org. Các mục trong cột Hạng mục kiểm soát lặp lại bằng chứng, điều kiện dừng và phản ứng bắt buộc của từng hàng, để việc trích xuất không chỉ phụ thuộc vào khả năng đọc bảng trực quan.

Danh mục kiểm tra khi áp dụng và các kiểu thất bại thường gặp

Các đội ngũ nên thí điểm tác nhân ở chế độ chỉ đề xuất hoặc chỉ soạn bản nháp, sau đó chỉ mở rộng quyền tự chủ khi có bằng chứng cho thấy cơ chế kiểm soát và phục hồi hoạt động trong điều kiện sát thực tế.

Danh mục kiểm tra triển khai

• Chỉ định người chịu trách nhiệm về nghiệp vụ và kỹ thuật.
• Xác định các hành động, công cụ, tệp đối tượng và kênh được phép và bị cấm.
• Kiểm kê nguồn dữ liệu, quyền truy cập, dòng dữ liệu, độ mới và SLA của pipeline.
• Thiết lập các tình huống đánh giá và tiêu chí phát hành.
• Mã hóa các quy tắc về dữ kiện, thương hiệu, đối tượng, quyền riêng tư và tuân thủ thành các bước kiểm tra.
• Đặt điểm phê duyệt cho các hành động hướng ra bên ngoài, không thể đảo ngược và có ảnh hưởng đáng kể về tài chính.
• Cấu hình truy vết, nhật ký kiểm toán, định tuyến sự cố và phục hồi khi lỗi.
• Xác định điều kiện cảnh báo, tạm dừng, chặn, chuyển cấp, chấm dứt và hoàn tác.
• Phân bổ mức sử dụng và chi phí theo tác nhân và quy trình, kèm hạn mức đã được duyệt.
• Kiểm thử lộ trình dự phòng trước khi bật chế độ thực thi tự chủ.

Câu chuyện khách hàng của Microsoft về Kantar, một tổ chức dữ liệu và phân tích toàn cầu, minh họa sự phụ thuộc này bằng quy mô đã được đo lường. Một nhóm gồm 10 tác nhân đã làm sạch, gắn thẻ và sắp xếp 4.000 tài liệu thành 400 văn bản chính sách trong sáu tuần, với quy trình được chia thành các tác vụ con riêng biệt và dựa trên tri thức của tổ chức. Microsoft ghi lại nghiên cứu điển hình này cùng các số liệu.

Bằng chứng đó củng cố quy tắc về mức sẵn sàng của dữ liệu mà không cần bịa ra một kết quả thất bại: nếu một bước biến đổi dữ liệu ở thượng nguồn không đáp ứng yêu cầu về độ mới, một hệ thống an toàn không nên phỏng đoán hoặc âm thầm dùng lại dữ liệu cũ. Hệ thống nên tạm dừng hành động phụ thuộc, đánh dấu phần phụ thuộc bị lỗi, cảnh báo người phụ trách và lưu giữ thay đổi được đề xuất để duyệt.

Các kiểu thất bại cần loại bỏ trước khi ra mắt

• Coi một bản demo thành công là bằng chứng xác nhận cho production.
• Dùng một prompt chung chung làm toàn bộ lớp quản trị.
• Cấp quyền truy cập công cụ hoặc dữ liệu nhiều hơn mức tác vụ cần.
• Giám sát văn bản cuối cùng nhưng bỏ qua các quyết định và lệnh gọi công cụ.
• Cho phép thử lại không giới hạn hoặc âm thầm tiếp tục sau khi điều kiện dừng đã kích hoạt.
• Theo dõi tổng chi tiêu AI mà không phân bổ theo quy trình.
• Trình bày phân tích marketing của Vanaxity như thể đó là hướng dẫn của Microsoft.

Cách Van Data Team đưa giải pháp vào vận hành thực tế

Tại Van Data Team, chúng tôi xem Microsoft Path to production for agents là một quy trình vận hành, không phải một bài tập lý thuyết. Microsoft cung cấp khung kỹ thuật: sự tin cậy, mở rộng quy mô có quản trị, điều phối hiệu quả và AgentOps cho các hệ thống bất định. Việc áp dụng các nguyên tắc đó vào hoạt động tiếp cận khách hàng của SDR và vận hành chiến dịch là phân tích của Vanaxity, không phải tuyên bố của Microsoft.

Chúng tôi bắt đầu bằng việc lập bản đồ quy trình bàn giao hiện tại: hệ thống nguồn, dòng dữ liệu và độ mới của dữ liệu, các quyết định của tác nhân, quyền dùng công cụ, bước duyệt, dashboard và lộ trình phục hồi. Kế hoạch triển khai được xây dựng từ đó sẽ nêu rõ:

• Các tín hiệu cần thu thập, gồm đầu vào, bằng chứng, lệnh gọi công cụ, phê duyệt, kết quả, lỗi và chi phí.
• Các lỗ hổng quy trình cần khắc phục, chẳng hạn như còn thiếu người phụ trách, bước kiểm tra dữ liệu cũ, ngưỡng đánh giá hoặc quy trình hoàn tác.
• Các hành động cần con người phê duyệt, đặc biệt là tin nhắn gửi ra bên ngoài, thao tác ghi vào CRM, thay đổi chiến dịch, xuất bản và chi tiêu.
• Dashboard và sổ tay vận hành (runbook) xác định cảnh báo, hạn mức chi phí, điều kiện dừng, người phụ trách chuyển cấp và các trạng thái dự phòng an toàn chỉ soạn bản nháp.

Cách làm này biến quản trị thành thứ mà người vận hành có thể thực thi. Thay vì tin tưởng một tác nhân chỉ vì bản demo đã chạy tốt, đội ngũ nhận được tiêu chí nghiệm thu rõ ràng, các bước kiểm tra an toàn thương hiệu, khả năng kiểm toán và một lộ trình phục hồi cho những lúc hành vi của tác nhân hoặc dữ liệu thượng nguồn đi chệch khỏi kỳ vọng.

Ngân sách vận hành

Chương trình tăng tốc Microsoft Path to production for agents đưa bài toán kinh tế vận hành vào chương trình nghị sự về mức sẵn sàng cho production, thông qua trọng tâm đã được xác nhận về điều phối hiệu quả với chi phí hợp lý. Theo phân tích của Vanaxity, giá token của nhà cung cấp chỉ là điểm khởi đầu. Một mô hình rẻ có thể trở nên đắt đỏ sau khi cộng thêm các lần thử lại, lệnh gọi công cụ, khâu duyệt của con người và công việc phục hồi.

Hãy chạy mọi phương án ứng viên trên cùng một bộ tác vụ đại diện và ghi lại:

• Chi phí cho mỗi đầu ra được chấp nhận: chi phí mô hình, công cụ, dữ liệu, hạ tầng và người duyệt chia cho số kết quả vượt qua ngưỡng nghiệm thu.
• Hồ sơ thực thi: độ trễ đầu cuối, lượng token tiêu thụ so với ngân sách, tỷ lệ thử lại và số phút duyệt cho mỗi kết quả được chấp nhận.
• Chất lượng và khả năng chống chịu: kết quả đánh giá về mức hoàn thành tác vụ, căn cứ dữ kiện, tuân thủ chính sách và an toàn thương hiệu, cùng với thời gian phục hồi, mức hoàn tác thành công và khối lượng làm lại sau lỗi.

Đặt hạn mức chi phí và token cho từng tác nhân và quy trình. Xác định điều kiện dừng cho các trường hợp chi vượt mức, thử lại nhiều lần, vượt ngưỡng độ trễ, không đạt đánh giá hoặc yêu cầu gọi công cụ không an toàn. Khi một ngưỡng bị vượt qua, hãy tạm ngừng các hành động hướng ra bên ngoài hoặc không thể đảo ngược và chuyển về chế độ chỉ soạn bản nháp.

Ứng viên phù hợp cho production không phải là phương án có giá prompt thấp nhất. Đó là phương án mang lại kết quả đã được phê duyệt, có thể kiểm toán, trong giới hạn về chất lượng, rủi ro, độ trễ và khả năng phục hồi.

Câu hỏi thường gặp

Nguồn tham khảo