GitHub Copilot Cloud Agent là gì? Cách giao việc và review code
Cách dùng GitHub Copilot Cloud Agent để giao issue, nhận pull request, kiểm tra chi phí, giới hạn và review code an toàn trước khi merge.
Bởi Võ Danh — 17 Tháng 8, 2026 trong Công nghệ
GitHub Copilot Cloud Agent cho phép bạn giao một việc lập trình trên GitHub rồi để agent xử lý ở chế độ nền. Nó đọc kho mã, lập kế hoạch, tạo nhánh, sửa code, chạy test và chuẩn bị pull request để bạn review. Bạn không phải ngồi nhìn con trỏ chạy từng dòng trong IDE. Nghe khá giống có thêm đồng nghiệp, chỉ khác là đồng nghiệp này sống trong một môi trường GitHub Actions tạm thời và không uống cà phê của phòng dev.
Tên gọi có thể làm nhiều người bối rối. GitHub hiện dùng “Copilot cloud agent” trong tài liệu, còn nhiều bài viết và giao diện cũ gọi là “Copilot coding agent”. Đây không phải agent mode chạy trực tiếp trong IDE. Cloud agent làm việc độc lập trên hạ tầng của GitHub, ghi thay đổi vào một nhánh và để lại log. Quyền đọc diff, yêu cầu sửa tiếp hay bấm Merge vẫn thuộc về con người.
Bài này giải thích cách dùng GitHub Copilot Cloud Agent từ issue đến pull request, các giới hạn dễ vấp và một quy trình review đủ chặt để không biến nút Merge thành trò may rủi.
GitHub Copilot Cloud Agent là gì?
Theo tài liệu chính thức của GitHub, cloud agent có thể nghiên cứu một repository, tạo kế hoạch triển khai, sửa lỗi, bổ sung tính năng nhỏ, cải thiện test, cập nhật tài liệu, xử lý nợ kỹ thuật và giải quyết xung đột merge. Khi nhận việc, nó tạo một môi trường phát triển tạm thời do GitHub Actions cung cấp. Trong đó, agent có thể xem code, sửa file, chạy linter và test.
Điểm khác biệt nằm ở nơi công việc diễn ra. Agent mode trong VS Code hoặc IDE khác sửa trực tiếp trên máy của bạn trong một phiên tương tác. Cloud agent chạy trên GitHub và có thể tiếp tục làm khi bạn chuyển sang việc khác. Mọi thay đổi đi qua branch, commit, log và pull request. Cách làm này hợp với công việc có đầu ra rõ ràng hơn là những cuộc dò đường dài chưa biết đích ở đâu.
GitHub cho biết tính năng có trên các gói Copilot trả phí. Với Copilot Business hoặc Enterprise, quản trị viên còn phải bật chính sách liên quan. Chủ repository có thể tắt agent cho một phần hoặc toàn bộ kho mã. Repository thuộc managed user account là một ngoại lệ không dùng được tính năng này.
Khi nào nên giao việc cho cloud agent?
Cloud agent làm tốt nhất khi nhiệm vụ nhỏ, có ranh giới và có cách kiểm tra kết quả. Ví dụ: thêm test cho một module đã ổn định, sửa lỗi được mô tả bằng bước tái hiện, đổi tên một API nội bộ, cập nhật tài liệu theo code hiện tại hoặc thêm log tại vài điểm đã chỉ định. Những việc này hơi tốn thời gian nhưng không đòi hỏi hàng chục quyết định sản phẩm.
Một issue kiểu “sửa lỗi đăng nhập khi token hết hạn, thêm test tái hiện và không đổi API công khai” tốt hơn hẳn “cải thiện phần đăng nhập”. Câu thứ hai rộng đến mức hai lập trình viên thật còn có thể hiểu theo hai hướng, huống hồ agent. Muốn kết quả dùng được, hãy ghi rõ file hoặc module liên quan, hành vi hiện tại, hành vi mong muốn, điều kiện chấp nhận và lệnh test cần chạy.
Đừng giao ngay một đợt nâng cấp kiến trúc kéo qua nhiều repository. GitHub nêu rõ mỗi phiên chỉ sửa repository được chọn, làm trên một branch và mở đúng một pull request. Phiên chạy còn có giới hạn cứng 59 phút. Nếu công việc dài hơn, agent sẽ dừng khi hết giờ. Cách xử lý hợp lý là chia việc thành các issue nhỏ có thể review riêng, không phải viết prompt dài bằng hợp đồng thuê nhà.
Cách dùng GitHub Copilot Cloud Agent từ một issue
1. Kiểm tra quyền và chính sách
Trước hết, tài khoản cần gói Copilot có hỗ trợ cloud agent và repository phải nằm trên GitHub. Nếu dùng tài khoản của công ty, hãy kiểm tra chính sách Copilot trong organization. Khi mục chọn Copilot không xuất hiện ở phần người được giao việc, nguyên nhân thường là quyền truy cập, chính sách hoặc repository đã tắt agent.
Đừng cấp quyền rộng chỉ để “cho chắc”. Agent mặc định làm việc trong repository đã chọn. Nếu cấu hình MCP server để truy cập công cụ hoặc dữ liệu khác, hãy giới hạn đúng phần cần dùng. MCP là giao thức giúp mô hình gọi công cụ và lấy ngữ cảnh từ hệ thống bên ngoài. Trang web này đã có bài giải thích MCP và cách dùng nếu bạn muốn hiểu kỹ lớp kết nối đó.
2. Viết issue có thể kiểm chứng
Một issue giao cho agent nên có năm mẩu thông tin: vấn đề, phạm vi, kết quả mong muốn, điều không được thay đổi và cách kiểm tra. Không cần văn vẻ. Càng cụ thể càng đỡ tốn lượt sửa.
Vấn đề: API /profile trả 500 khi trường avatar là null.
Phạm vi: packages/api/profile và test liên quan.
Kết quả: trả avatar: null, không phát sinh lỗi.
Không đổi: schema công khai và mã trạng thái của trường hợp khác.
Kiểm tra: chạy npm test -- profile.Mẫu này cho agent một đường chạy ngắn và cho người review một thước đo. Nếu repository có quy ước riêng, hãy thêm file custom instructions. GitHub hỗ trợ hướng dẫn bằng ngôn ngữ tự nhiên trong repository, dùng để nói rõ cách build, test, đặt tên và xác nhận thay đổi. Đừng chôn quy tắc quan trọng trong tài liệu nội bộ mà agent không đọc được rồi ngạc nhiên khi nó làm sai.
3. Giao issue cho Copilot và theo dõi phiên chạy
Trong issue, chọn Copilot ở phần Assignees để bắt đầu. Bạn cũng có thể mở phiên từ bảng agents, Copilot Chat, IDE, GitHub Mobile, GitHub CLI, REST API hoặc một số tích hợp như Jira, Slack, Teams, Azure Boards và Linear. Danh sách điểm khởi chạy thay đổi theo sản phẩm, nên trang hướng dẫn bắt đầu phiên của GitHub là nơi nên kiểm tra khi giao diện của bạn khác bài này.
Sau khi nhận việc, agent phân tích yêu cầu và làm trên branch riêng. Một số điểm khởi chạy tạo pull request ngay, số khác cho phép nghiên cứu, lập kế hoạch và sửa code trước khi mở pull request. Bạn có thể xem log để biết agent đã chạy lệnh nào, test nào qua, test nào lỗi và file nào được thay đổi.
4. Yêu cầu sửa tiếp nếu kết quả chưa đạt
Nếu diff đi lệch, đừng chỉ viết “làm lại cho đúng”. Hãy chỉ ra dòng hoặc hành vi sai, nhắc lại điều kiện chấp nhận và yêu cầu chạy đúng bộ test. Phản hồi cụ thể giúp phiên tiếp theo ngắn hơn. Bạn cũng có thể nhắc @copilot trong bình luận của pull request để yêu cầu thay đổi.
Cloud agent có thể hoàn thành phần đầu rồi để bạn tiếp quản. Đây thường là cách dùng tỉnh táo: giao phần dựng khung, test lặp lại hoặc cập nhật tài liệu; giữ quyết định thiết kế và phần nhạy cảm cho người hiểu hệ thống. Nếu bạn thích tác nhân chạy ngay trong terminal và muốn so sánh cách làm, bài Claude Code trong terminal cho thấy một luồng làm việc gần máy cục bộ hơn.
Chi phí được tính ra sao?
Cloud agent dùng cả GitHub Actions minutes và GitHub AI Credits. Số AI Credits phụ thuộc vào model và lượng token được xử lý trong phiên. Nếu mức dùng vẫn nằm trong phần được cấp kèm gói, GitHub nói bạn không phải trả thêm. Khi vượt mức, cách tính phụ thuộc cài đặt thanh toán của tài khoản hoặc tổ chức.
Vì giá và hạn mức có thể đổi, không nên đóng đinh một con số lấy từ ảnh chụp cũ. Hãy xem trang các gói GitHub Copilot và phần billing của chính tài khoản trước khi bật cho cả đội. Với repository riêng tư, một số hoạt động như Copilot code review cũng có thể dùng Actions minutes. Quản trị viên nên đặt cảnh báo chi tiêu thay vì đợi hóa đơn làm nhiệm vụ báo động.
Giới hạn cần biết trước khi giao việc
Ngoài mốc 59 phút và giới hạn một repository, một branch, một pull request cho mỗi nhiệm vụ, cloud agent chỉ làm việc với repository lưu trên GitHub. Quy tắc bảo vệ branch hoặc ruleset không tương thích có thể chặn agent tạo hay cập nhật pull request. Chẳng hạn, quy tắc chỉ cho phép một nhóm tác giả commit cụ thể có thể khiến phiên chạy không hoàn tất.
Agent cũng không tự hiểu mọi quy ước ngầm của đội. Nếu test cần dịch vụ nội bộ, biến môi trường hoặc bước cài đặt riêng, hãy cấu hình môi trường agent bằng file copilot-setup-steps.yml và chỉ cung cấp những bí mật thật sự cần. Không đưa dữ liệu khách hàng thật vào issue. Issue và log không phải két sắt, dù giao diện có trông gọn đến đâu.
Một giới hạn khác khó thấy hơn là chất lượng yêu cầu. Agent có thể viết code hợp cú pháp và vẫn giải sai bài toán. Test hiện có cũng có thể thiếu. Vì vậy, trạng thái xanh không chứng minh thay đổi đúng về nghiệp vụ. Nó chỉ chứng minh các kiểm tra vừa chạy không bắt được lỗi.
Cách review pull request do agent tạo
Bắt đầu bằng phạm vi. So sánh danh sách file với issue ban đầu. Một sửa lỗi nhỏ mà đụng vào cấu hình build, quyền truy cập và hàng chục file không liên quan là tín hiệu phải dừng lại hỏi tại sao. Diff càng lớn, khả năng người review đọc lướt càng cao.
Tiếp theo, đọc code thay vì chỉ đọc phần tóm tắt. Kiểm tra xử lý lỗi, dữ liệu rỗng, quyền truy cập, đường dẫn hiếm và hành vi tương thích ngược. Tìm token, khóa API, URL nội bộ hoặc dữ liệu thật bị ghi vào code và log. Nếu thay đổi có migration cơ sở dữ liệu, hãy xem cả đường quay lui.
Sau đó chạy test trên môi trường sạch. Đừng dựa hoàn toàn vào log của agent. Thêm ít nhất một test cho lỗi đã nêu và một test cho hành vi không được phép hỏng. Với thay đổi liên quan giao diện hoặc quy trình nhiều bước, kiểm tra thủ công vẫn đáng làm. Máy không phàn nàn khi yêu cầu sai; nó chỉ hoàn thành yêu cầu sai rất chăm chỉ.
Cuối cùng, yêu cầu một người chịu trách nhiệm về module duyệt pull request. Có thể dùng agent để tiết kiệm thời gian viết phần lặp lại, nhưng không nên dùng nó để xóa trách nhiệm. Tên người bấm Merge vẫn là dòng dễ tìm nhất khi sự cố xảy ra.
Một bộ quy tắc nhỏ cho đội dev
Đội mới dùng cloud agent có thể bắt đầu bằng repository ít rủi ro và nhóm issue gắn nhãn riêng. Chỉ nhận nhiệm vụ có tiêu chí chấp nhận, bắt buộc chạy test, cấm merge tự động và yêu cầu review của chủ module. Sau vài tuần, đo số pull request được chấp nhận, tỷ lệ phải sửa lại, thời gian review và lỗi lọt qua. Số pull request tạo ra tự nó không nói lên nhiều điều.
Hãy lưu hướng dẫn build và test trong repository để cả người lẫn agent đều dùng được. Tách việc lớn thành phần nhỏ. Giới hạn MCP, secrets và quyền mạng theo nhu cầu. Nếu agent thường xuyên vấp cùng một lỗi, sửa tài liệu hoặc môi trường thay vì lặp lại lời nhắc trong từng issue.
Có nên dùng GitHub Copilot Cloud Agent?
Có, nếu đội của bạn đã làm việc chủ yếu trên GitHub, có test tương đối ổn và biết chia nhiệm vụ thành phần nhỏ. Cloud agent tiện cho backlog kỹ thuật, test, tài liệu và lỗi có bước tái hiện rõ. Nó cũng để lại branch, commit và log nên dễ kiểm tra hơn một phiên chat không được lưu.
Chưa nên mở rộng nếu repository thiếu test, quy tắc build chỉ nằm trong đầu một người hoặc đội đang có thói quen merge theo màu xanh. Hãy thử với vài issue ít rủi ro, review thật kỹ và ghi lại phần nào tiết kiệm thời gian. Khi kết quả tốt lặp lại, mới tăng phạm vi. Agent có thể làm nền; trách nhiệm thì không chạy nền được.
Nguồn tham khảo
