Từ các câu lệnh một lần đến quy trình làm việc: Cách sử dụng tác nhân tùy chỉnh trong GitHub Copilot CLI

Các nhà phát triển làm việc trên nhiều giao diện như CLI, IDE và GitHub. Thiết bị đầu cuối (terminal) thường là nơi họ tìm đến để làm việc nhanh chóng, tự động hóa tác vụ hoặc làm việc trực tiếp với các hệ thống và tập lệnh. Các công cụ như GitHub Copilot CLI đã giúp việc này trở nên dễ dàng hơn. Người dùng có thể tạo lệnh, gỡ lỗi và làm việc nhanh hơn mà không cần rời khỏi thiết bị đầu cuối. Tuy nhiên, giống như bất kỳ môi trường nào, CLI vẫn có thể gây ra những trở ngại: chạy lại các lệnh cũ, giải thích lại ngữ cảnh hoặc chuyển đổi nhật ký (log) cho nhóm thành thông tin có thể hành động. Những bước nhỏ này tích lũy dần, đặc biệt khi ngăn xếp (stack) và tiêu chuẩn của mỗi nhóm có chút khác biệt. Nhưng điều gì sẽ xảy ra nếu thiết bị đầu cuối của người dùng không chỉ chạy lệnh mà còn hiểu được ngăn xếp, công cụ và tiêu chuẩn của nhóm? Đó là lúc các tác nhân tùy chỉnh (custom agents) phát huy tác dụng. Thay vì bắt đầu lại từ đầu mỗi lần, người dùng có thể mã hóa ngữ cảnh của nhóm vào các quy trình làm việc có thể tái sử dụng, vượt ra ngoài các lời nhắc (prompts) một lần. Với các tác nhân tùy chỉnh trong CLI, người dùng có thể biến các tác vụ và mẫu lặp lại thành các quy trình làm việc nhất quán, có thể xem xét lại, phù hợp tự nhiên với các công cụ khác của họ, đồng thời tùy chỉnh thêm GitHub Copilot CLI với chuyên môn cho các tác vụ phát triển cụ thể. Các tác nhân tùy chỉnh là gì? Tác nhân tùy chỉnh là một tác nhân Copilot có thể được định nghĩa bằng cách sử dụng tệp Markdown. Thay vì dựa vào hành vi chung, người dùng mô tả cách tác nhân nên hoạt động, công cụ nào nó có thể sử dụng, tiêu chuẩn nào nó nên tuân theo và đầu ra nào nó nên tạo ra. Kết quả: hành vi của nó nhất quán ở bất cứ nơi nào nó chạy. Mỗi tác nhân mã hóa (coding agent) được tạo có thể hoạt động như một tác nhân chuyên biệt được điều chỉnh cho một tác vụ cụ thể. Ví dụ, một tác nhân mã hóa chung có thể đề xuất cách dọn dẹp mã của người dùng. Nhưng một tác nhân tùy chỉnh có thể áp dụng các quy tắc định dạng, công cụ, tiêu chuẩn tiếp cận, yêu cầu xem xét và yêu cầu an toàn của người dùng mỗi khi nó chạy. Các tác nhân tùy chỉnh được định nghĩa bằng cách sử dụng hồ sơ tác nhân (agent profiles) hoặc các tệp nằm trực tiếp trong kho lưu trữ của người dùng. Được viết bằng Markdown, các hồ sơ tác nhân này cho phép người dùng chỉ định: Vai trò và lĩnh vực chuyên môn của tác nhân Công cụ mà nó có thể truy cập Các rào cản bảo vệ (guardrails) giúp đầu ra an toàn và nhất quán Đoạn mã dưới đây cho thấy phần đầu của một hồ sơ tác nhân hoạt động như một trợ lý chuyên gia về khả năng tiếp cận web: --- description: 'Trợ lý chuyên gia về khả năng tiếp cận web (WCAG 2.1/2.2), UX toàn diện và kiểm thử a11y' name: 'Chuyên gia Tiếp cận' model: GPT-4.1 tools: ['changes', 'codebase', 'edit/editFiles', 'extensions', 'web/fetch', 'findTestFiles', 'githubRepo', 'new', 'openSimpleBrowser', 'problems', 'runCommands', 'runTasks', 'runTests', 'search', 'searchResults', 'terminalLastCommand', 'terminalSelection', 'testFailure', 'usages', 'vscodeAPI'] # Chuyên gia Tiếp cận Bạn là một chuyên gia đẳng cấp thế giới về khả năng tiếp cận web, người chuyển đổi các tiêu chuẩn thành hướng dẫn thực tế cho các nhà thiết kế, nhà phát triển và QA. Bạn đảm bảo các sản phẩm toàn diện, dễ sử dụng và phù hợp với WCAG 2.1/2.2 trên A/AA/AAA. # Chuyên môn của bạn **Tiêu chuẩn & Chính sách**: Tuân thủ WCAG 2.1/2.2, ánh xạ A/AA/AAA, các khía cạnh quyền riêng tư/bảo mật, các chính sách khu vực Vì hồ sơ tác nhân nằm trong kho lưu trữ của người dùng, nhóm của họ có thể xem xét, lập phiên bản và chia sẻ nó để các kỳ vọng tương tự theo dõi công việc từ CLI đến IDE và đến các yêu cầu kéo (pull requests) trên GitHub. Cách các tác nhân tùy chỉnh hoạt động trong GitHub Copilot CLI GitHub Copilot CLI phù hợp với công việc dựa trên tác nhân (agent-driven work) vì nó đã chạy các tập lệnh, gọi API và làm việc trực tiếp với các kho lưu trữ của bạn. Việc định nghĩa các tác nhân ở đây cho phép bạn tùy chỉnh thêm Copilot CLI bằng cách mã hóa các quy trình làm việc nặng về thực thi một lần, sau đó gọi chúng từ thiết bị đầu cuối. Tác nhân sẽ thực thi quy trình làm việc của bạn theo cùng một cách mỗi lần. Để thêm một tác nhân tùy chỉnh mới cho GitHub Copilot CLI, bạn sẽ cần: Gọi tác nhân từ Copilot CLI. Từ thiết bị đầu cuối, chạy Copilot CLI và sử dụng lệnh /agent. Chọn tác nhân tùy chỉnh bạn muốn sử dụng. Tạo một hồ sơ tác nhân trong thư mục .github/agents của kho lưu trữ mục tiêu của bạn. Hồ sơ tác nhân là một tệp Markdown với phần đầu YAML (YAML frontmatter) định nghĩa vai trò, phạm vi, khả năng và các quy tắc bảo vệ của tác nhân, để nó hoạt động nhất quán trong các quy trình làm việc của bạn. Tệp hồ sơ tác nhân kết thúc bằng .agent.md – ví dụ: accessibility.agent.md. Vì hồ sơ tác nhân là một tệp trong kho lưu trữ của bạn, nó có thể được xem xét, cập nhật và chia sẻ. Các quy trình làm việc phổ biến bạn có thể tự động hóa với các tác nhân tùy chỉnh Nơi tốt nhất để bắt đầu với các tác nhân tùy chỉnh là với các tác vụ mà nhóm của bạn đã lặp đi lặp lại, nhiều trong số đó thường bắt đầu trong thiết bị đầu cuối và tiếp tục trong IDE và trên GitHub. Dưới đây là một vài kịch bản thực tế: Tác nhân kiểm tra bảo mật Chạy các kiểm tra bảo mật tiêu chuẩn của nhóm bạn trên các kho lưu trữ của bạn, tóm tắt các phát hiện theo mức độ nghiêm trọng và xuất ra một danh sách kiểm tra sẵn sàng cho yêu cầu kéo (pull request) với chủ sở hữu và các bước tiếp theo. # .github/agents/security-audit.md --- name: Security audit description: Run our standard security checks across repositories and produce a PR-ready checklist grouped by severity. tools: # Keep this list aligned with what your team actually runs in CI. - gh - git - semgrep - trivy - gitleaks - jq --- ## Instructions You are the **Security audit** agent for this organization. ### Goal For the repositories provided by the user, run the team’s standard security checks, summarize findings by **severity** (Critical, High, Medium, Low), and output a **pull request (PR)-ready** checklist with owners and next steps. ### Operating rules - Prefer the repo’s existing security tooling and config files (for example: `.semgrep.yml`, `.trivyignore`, `.gitleaks.toml`) when present. - If a tool is missing, note it as a **High** severity “coverage gap” instead of inventing results. - Don’t paste secrets or full vulnerable payloads into output. Redact tokens and credentials. - Use inclusive language (use allowlist/denylist). - When referencing dates, use the format “March 23, 2026”. ### Standard checks to run (per repository) 1.