Trao đổi về dự án
Quản trị AI

Copilot trên máy tính: xác định các hành động và các điểm cần xem xét

Một tác nhân AI chuẩn bị một báo cáo trong một ứng dụng. Học cách tách riêng quyền truy cập, chuẩn bị và chia sẻ, sau đó kiểm tra các điểm dừng của các phiên bản xem trước mới Copilot.

Illustration originale : périmètre, préparation, revue, effet autorisé

Nhóm của bạn muốn biến kết quả của một kho lưu trữ trình diễn thành báo cáo. Tác nhân có thể đọc các bài kiểm tra, chuẩn bị tài liệu và, giờ đây, tương tác với một ứng dụng máy tính để bàn. Nhưng ai quyết định rằng tài liệu đã sẵn sàng để chia sẻ? Việc chuyển từ một tệp cục bộ sang một hành động trong phần mềm khác buộc bạn phải xác định chính xác những gì bạn ủy quyền.

Hãy lấy một kịch bản giả tưởng: chuẩn bị một báo cáo kiểm tra trong một không gian không có tài khoản cá nhân, sau đó dừng lại trước khi chia sẻ. Hành trình được đề xuất này chưa được thực hiện. Nó nhằm phân biệt ba quyết định: truy cập một ứng dụng, chuẩn bị một thao tác và cho phép hiệu ứng của nó.

Hai thông báo, hai câu hỏi khác nhau

Ngày 1 tháng 10 năm 2026, GitHub công bố thử nghiệm công khai các tương tác của Copilot với các ứng dụng máy tính để bàn, trong Copilot CLI và Copilot app trên macOS và Windows. Việc truy cập dựa trên quyền của ứng dụng và các kiểm soát của quản trị viên. Thông báo này không bao gồm việc kiểm soát máy tính để bàn trên Linux.

Cùng ngày đó, các luồng công việc động chuyển sang phiên bản xem trước công khai. Chúng cho phép mô tả việc điều phối bằng mã: các bước, tính song song và các điểm kiểm tra. Phạm vi bao gồm CLI, ứng dụng và SDK, toàn bộ bộ công cụ dành để tích hợp Copilot trong một chương trình. Trong CLI, thông báo yêu cầu kích hoạt các tính năng thử nghiệm.

Đối tượng đã được thông báo Câu hỏi cần đặt trước khi thử nghiệm
Tương tác với ứng dụng máy tính Những ứng dụng và những thao tác nào có thể truy cập?
Quy trình làm việc động Các bước thực hiện theo thứ tự nào và dừng lại ở đâu?
Quyền ứng dụng Quyền này mở chính xác phạm vi kỹ thuật nào?
Xem xét kết quả Ai phê duyệt tài liệu và hiệu quả nghiệp vụ dự kiến?

Những câu hỏi này vẫn còn riêng biệt. Một sự điều phối được lập trình có thể tổ chức một phân tích mà mắc lỗi. Một quyền của ứng dụng có thể mở ra nhiều hành động mà chỉ có một hành động được mong muốn. Thứ tự của quy trình và độ chính xác của kết quả được kiểm tra riêng biệt.

Mô tả hành động trước khi mở quyền truy cập

Trong ví dụ của chúng ta, « sản xuất báo cáo » có vẻ đơn giản. Tuy nhiên, điều này có thể chỉ việc đọc một tệp, tạo một tài liệu, ghi đè một tài liệu hiện có hoặc truyền thông tin. Hướng dẫn của bạn phải nêu rõ đầu vào, đầu ra, vị trí được phép và điều kiện dừng.

Một nhiệm vụ đầu tiên có thể là: chỉ đọc kết quả tổng hợp của kho kiểm tra, soạn một tài liệu trong thư mục trình diễn và hiển thị bản xem trước. Việc chia sẻ ra bên ngoài vẫn là một bước riêng biệt. Phạm vi trở nên dễ hiểu đối với người đọc lại, ngay cả khi họ không quen với công cụ của tác nhân AI.

Ma trận sau đây là một đề xuất Partitech cho thử nghiệm thí điểm này. Nó không mô tả các cài đặt tự động của Copilot.

Thao tác Quyền được đề xuất Bằng chứng để đọc lại
Đọc kết quả tổng hợp Trong thư mục thử nghiệm thí điểm Danh sách các tệp đã sử dụng
Chuẩn bị một báo cáo Tại một địa điểm mới Tài liệu và các nguồn tương ứng
Chỉnh sửa một báo cáo hiện có Sau khi so sánh rõ ràng Sự khác biệt trước/sau
Chia sẻ tài liệu Quyết định con người mới Người nhận, nội dung và kênh
Xóa dữ liệu công việc Thủ tục riêng Danh sách chính xác các mục liên quan

Đối với mỗi thao tác, hãy xem xét chi phí lỗi và khả năng phục hồi của nó. Sửa một tiêu đề trong tài liệu cục bộ tốn ít công sức. Việc gỡ một tài liệu đã chuyển cho bên thứ ba có thể trở nên không thể. Sự khác biệt này cần được thể hiện bằng một ranh giới rõ ràng trong quá trình, thay vì bằng một câu nói chung về sự thận trọng.

Tách phạm vi, chuẩn bị, xem xét và hiệu lực được phép.

Làm cho việc điều phối dễ hiểu với nhóm

Một quy trình làm việc là con đường mà nhiệm vụ đi theo. Bằng cách mô tả nó trong một chương trình, bạn có thể làm rõ một số bước: thu thập các đầu vào, yêu cầu phân tích, kiểm soát cấu trúc của nó rồi trình bày kết quả cho một người.

Đây là một pseudocode khái niệm, không có cú pháp SDK và không có lệnh gọi thực thi. Nó minh họa quy trình mà chúng tôi đề xuất; đây không phải là một ví dụ đã được kiểm thử của giao diện GitHub.

identifier les fichiers autorisés
vérifier que les entrées sont présentes
produire une proposition de rapport
contrôler les références et les sections attendues
présenter le rapport et les changements prévus
attendre une décision explicite
si la décision autorise une action précise : exécuter cette action
sinon : arrêter en conservant le brouillon

Chương trình có thể áp đặt một bước xem xét. Nó không thay thế cho việc xem xét thực sự. Một cấu trúc đúng vẫn có thể chứa một kết luận sai; một tham chiếu có thể chỉ tới bài kiểm tra sai. Do đó, hãy yêu cầu mỗi khẳng định hữu ích phải dẫn đến một mục có thể kiểm chứng, và sự thiếu kết quả phải được báo cáo thay vì được điền bù bằng một giả định.

Một kết quả có cấu trúc ở đây có nghĩa là đầu ra phân biệt được nhận định, nguồn và giới hạn. Hợp đồng này tạo điều kiện kiểm soát độc lập: một công cụ khác hoặc một người đọc khác có thể so sánh các phần với các tập tin đầu vào. Nó không biến các câu thành bằng chứng.

Tài liệu về quy trình làm việc động vẫn là tham chiếu cho một triển khai. Kiểm tra phiên bản của nó vào thời điểm lập trình. Một nguyên mẫu điều phối không nên sử dụng lại chữ ký được cho là của một SDK từ một sơ đồ giáo dục đơn giản.

Đặt bước rà soát trước khi tạo tác động

Ranh giới đúng nằm ngay trước sự thay đổi liên quan đến đội. Trong phiên bản thử nghiệm, bản nháp có thể được chuẩn bị tự động, sau đó việc rà soát phải hiển thị tài liệu hoàn chỉnh, các nguồn đã sử dụng và hành động dự kiến. Chỉ hiển thị « tiếp tục? » không cho phép quyết định đúng đắn.

Sự phê duyệt phải liên quan đến một đối tượng xác định. Nếu nội dung, người nhận hoặc vị trí thay đổi sau khi xem xét, quyết định trước đó sẽ không còn bao phủ chính xác hoạt động. Khi đó, hãy dự kiến một lần trình bày mới. Nguyên tắc này thuộc phương pháp đánh giá của chúng tôi; nó không giả định rằng tất cả các giao diện Copilot áp dụng cho chúng một cách tự động.

Cũng hãy sắp xếp việc dừng lại. Chỉ còn lại gì khi bạn hủy một phiên làm việc? Nơi nào để tìm bản nháp? Làm sao biết một thao tác đã được thực hiện chưa? Việc tiếp tục mù có thể lặp lại một hành động. Trước khi khởi động lại, hãy kiểm tra tình trạng thực tế của kết quả và bước đã đạt được.

Môi trường trình diễn phải làm cho các lỗi có thể quan sát được mà không ảnh hưởng đến các tài khoản thông thường của bạn. Sử dụng các tệp giả lập và một ứng dụng thử nghiệm, loại bỏ quyền truy cập không cần thiết và giao việc thu hồi cho một người được xác định. Phiên bản thử nghiệm không yêu cầu mua hàng, email hay việc công bố thực tế.

Kiểm tra sự từ chối cũng như lộ trình dự kiến

Giao thức đủ điều kiện của chúng tôi bắt đầu bằng trường hợp được phép: các đầu vào có mặt, tài liệu đã được chuẩn bị và quá trình dừng lại tại điểm dự kiến. Ghi lại kết quả quan sát được mà không gọi nó là thành công tổng thể. Thử nghiệm đầu tiên này chỉ kiểm tra một con đường duy nhất.

Sau đó thêm một mục bị thiếu, một tệp nằm ngoài phạm vi và một yêu cầu chia sẻ không được phép. Mục tiêu là xem liệu hệ thống có dừng lại và chỉ ra những gì còn thiếu, thay vì mở rộng nhiệm vụ của nó. Cũng hãy xem xét một tài liệu bên ngoài chứa một hướng dẫn gây hiểu lầm, ví dụ như yêu cầu thay đổi người nhận. Tài liệu này vẫn là một dữ liệu để phân tích; nó không trở thành một quyền hạn mới.

Dấu vết tối thiểu phải cho phép phục hồi các nhập liệu, các quyết định và các tác động. Tránh thu thập một cách không phân biệt nội dung của tất cả các tài liệu. Xác định những người có thể xem các dấu vết này và thời gian lưu giữ chúng trong quy trình hiện tại của bạn.

Bài viết của chúng tôi về sandbox và các dấu vết Copilot app giải thích các thông báo tháng chín. Nó cung cấp bối cảnh hữu ích, nhưng các cơ chế của nó không tự động chứng minh việc bao quát các tương tác với ứng dụng máy tính được thông báo vào ngày 1 tháng mười.

Quyết định tiếp tục khi đội ngũ biết giải thích phạm vi được phép, kiểm tra bản nháp, dừng quá trình và khôi phục trạng thái tin cậy. Nếu thiếu một trong những yếu tố này, hãy điều chỉnh thử nghiệm thí điểm trước khi thêm các ứng dụng. Khả năng mới trở nên hữu ích khi ranh giới ủy quyền vẫn được nhìn thấy.

Nguồn và ngày kiểm tra

Nguồn GitHub tái mở cửa vào ngày 6 tháng 10 năm 2026: tương tác với ứng dụng máy tính, quy trình làm việc động và tài liệu khái niệm. Các phiên bản trước có thể phát triển. Ma trận, kịch bản và giả mã là các đề xuất gốc Partitech, không có kết quả thực thi nào được tuyên bố.

Chia sẻ bài viết