Bắt đầu với quy trình làm việc tự động (Agentic Workflows) của GitHub

# Bắt đầu với Quy trình làm việc Agentic của GitHub Quy trình làm việc Agentic của GitHub đang trong giai đoạn xem trước công khai. Tìm hiểu tất cả về chúng tại đây. Bởi Shittu Olumide, Chuyên gia Nội dung Kỹ thuật vào ngày 5 tháng 8 năm 2026 trong Trí tuệ Nhân tạo # Giới thiệu Quy trình làm việc Agentic của GitHub Đó là 9 giờ sáng thứ Hai, và bốn mươi ba vấn đề mới đang nằm trong danh sách chờ. Một số là lỗi thực sự. Một số là yêu cầu tính năng trùng lặp. Một vài chỉ là ai đó phàn nàn về một lỗi chính tả. Bất cứ ai đang làm nhiệm vụ phân loại tuần này sẽ dành hai giờ đầu tiên trong ngày để đọc, gắn nhãn và trả lời tất cả chúng trước khi họ có thể chạm vào bất cứ thứ gì họ thực sự định xây dựng. Đó chính xác là loại công việc mà GitHub đã xây dựng Quy trình làm việc Agentic để giúp bạn giải quyết. Vào ngày 11 tháng 6 năm 2026, GitHub đã chuyển Quy trình làm việc Agentic sang giai đoạn xem trước công khai, cung cấp cho mọi kho lưu trữ khả năng chạy các tác nhân mã hóa bên trong GitHub Actions để xử lý chính xác loại công việc lặp đi lặp lại, đòi hỏi nhiều suy luận này. Không phải hoàn thành mã. Không phải thanh bên trò chuyện. Một tác nhân được lên lịch hoặc kích hoạt theo sự kiện sẽ đọc một vấn đề, một yêu cầu kéo hoặc các cam kết trong một tuần, và thực hiện điều gì đó hữu ích với những gì nó tìm thấy. Bài viết này sẽ trình bày về tính năng này thực sự là gì, tại sao mô hình bảo mật lại quan trọng hơn phiên bản trình bày của nó, và cách viết, biên dịch và chạy quy trình làm việc đầu tiên của bạn ngay hôm nay. Đến cuối cùng, bạn sẽ có một quy trình làm việc phân loại hoạt động của riêng mình và một cái nhìn rõ ràng về những gì vẫn còn hơi thô. # Quy trình làm việc Agentic của GitHub là gì? Bỏ qua ngôn ngữ tiếp thị, ý tưởng khá đơn giản. Bạn viết một tệp Markdown nằm trong .github/workflows/. Phần đầu của tệp đó có một khối YAML frontmatter nhỏ mô tả khi nào quy trình làm việc chạy, những gì nó được phép chạm vào và công cụ AI nào cung cấp năng lượng cho nó. Bên dưới frontmatter, bạn viết các hướng dẫn bằng tiếng Anh đơn giản mô tả những gì bạn muốn tác nhân thực hiện. Một công cụ giao diện dòng lệnh (CLI) có tên gh-aw đọc tệp Markdown đó và biên dịch nó thành một tệp .lock.yml, đây là một quy trình làm việc GitHub Actions hoàn toàn bình thường. Đó là phần đáng để suy nghĩ một chút: không có thời gian chạy tác nhân riêng biệt nào được gắn vào kho lưu trữ của bạn. Nó sử dụng lại các trình chạy hiện có của bạn, các quy tắc bảo vệ nhánh hiện có của bạn và các ràng buộc chính sách hiện có của bạn, bởi vì bên dưới ngôn ngữ tự nhiên, nó chỉ là Actions. Dự án được xây dựng bởi GitHub Next và Microsoft Research, và hiện tại nó hỗ trợ bốn công cụ AI sẵn có: GitHub Copilot, Anthropic's Claude, OpenAI Codex và Google Gemini, với tùy chọn cắm bộ xử lý tùy chỉnh nếu không có công cụ nào phù hợp. Copilot là công cụ mặc định, và nếu tổ chức của bạn đã trả tiền cho gói Copilot, các lần chạy quy trình làm việc có thể thanh toán trực tiếp cho tổ chức đó thay vì yêu cầu bạn quản lý một khóa API riêng. Giải pháp này cũng nằm trong ý tưởng lớn hơn mà GitHub gọi là AI liên tục (Continuous AI), thực chất là việc áp dụng AI một cách có hệ thống trong toàn bộ vòng đời phần mềm thay vì chỉ sử dụng từng câu lệnh một. Quy trình làm việc tự động (Agentic Workflows) là cơ chế để thực hiện điều đó theo lịch trình hoặc phản ứng với các sự kiện kho lưu trữ, thay vì chỉ khi một người đang ngồi trước bàn phím và đặt câu hỏi cho Copilot. Cũng cần làm rõ điều này không phải là gì. Nó không giống với tác nhân mã hóa đám mây của Copilot, mà người dùng kích hoạt thủ công từ một vấn đề hoặc một yêu cầu kéo (pull request) khi muốn một tác nhân thực hiện một điều cụ thể ngay lập tức. Quy trình làm việc tự động gần giống với một chính sách cố định: "mỗi thứ Hai, tóm tắt hoạt động vấn đề trong tuần" hoặc "mỗi khi một PR được mở, hãy xem xét các vấn đề bảo mật". Một cái là nhiệm vụ người dùng giao phó. Cái kia là một thói quen được xây dựng vào chính kho lưu trữ. # Tại sao điều này đáng được chú ý GitHub thường không công bố số liệu về mức độ chấp nhận sớm như vậy trong giai đoạn xem trước, vì vậy việc họ đính kèm các trích dẫn từ khách hàng đã nói lên mức độ thử nghiệm nội bộ đã diễn ra. Carvana đã nói với GitHub rằng sự linh hoạt và các kiểm soát tích hợp đã mang lại cho đội ngũ kỹ sư của họ đủ tự tin để chạy các quy trình làm việc tự động trên các hệ thống thực sự phức tạp, bao gồm các thay đổi liên quan đến nhiều kho lưu trữ cùng một lúc, theo nhật ký thay đổi chính thức. Marks & Spencer mô tả một câu chuyện tương tự từ một góc độ khác: các nhà phát triển của họ đã mất nhiều giờ làm việc quý giá vào những công việc nhàm chán — phân loại vấn đề, bảo trì phụ thuộc, khắc phục lỗ hổng và đánh giá định kỳ — và việc xây dựng một danh mục chung các quy trình làm việc tự động có thể tái sử dụng đã cho phép các nhóm áp dụng tự động hóa đó trên bất kỳ kho lưu trữ nào mà không cần phải tạo lại mỗi lần. Hud.io đã chỉ ra một điểm dễ bị bỏ qua nếu người dùng chỉ lướt qua danh sách tính năng: việc yêu cầu một tác nhân mở một yêu cầu kéo chưa bao giờ là phần khó khăn của việc này. Tin tưởng vào kết quả đủ để thực sự hợp nhất nó mới là điều khó. Đó thực sự là toàn bộ luận điểm đằng sau thiết kế bảo mật được đề cập trong phần tiếp theo. Dưới đây là hình dạng của tính năng như hiện tại, được lấy trực tiếp từ trang số liệu của GitHub: | Chỉ số | Giá trị | |---|---| | Các công cụ AI được hỗ trợ | 4 tích hợp sẵn (Copilot, Claude, Codex, Gemini), cộng với hỗ trợ công cụ tùy chỉnh | | Các lớp bảo mật | 5 (mã thông báo chỉ đọc, không có bí mật, tường lửa mạng, đầu ra an toàn, phát hiện mối đe dọa) | | Các mẫu thiết kế được ghi lại | Hơn 18 (IssueOps, ChatOps, DailyOps, BatchOps, và nhiều hơn nữa) | | Các trình kích hoạt sự kiện GitHub được hỗ trợ | Hơn 10 (issues, pull_request, push, schedule, discussion, label, và các loại khác) | | Các loại đầu ra an toàn | Hơn 8 (create-issue, create-) |