待翻译：Getting Started with GitHub Agentic Workflows

AI 服务暂时不可用，以下为来源正文，待恢复后补全翻译。

--> Getting Started with GitHub Agentic Workflows - KDnuggets --> Join Newsletter # Introducing GitHub's Agentic Workflows It's 9 AM on a Monday, and forty-three new issues are sitting in the backlog. Some are real bugs. Some are duplicate feature requests. A couple are just someone venting about a typo. Whoever is on triage duty this week is going to spend the first two hours of their day reading, labelling, and replying to all of them before they can touch anything they actually planned to build. That's the exact kind of work GitHub built Agentic Workflows to take off your plate. On June 11, 2026, GitHub moved Agentic Workflows into public preview, giving every repository the ability to run coding agents inside GitHub Actions to handle exactly this kind of reasoning-heavy, repetitive work. Not code completion. Not a chat sidebar. A scheduled or event-triggered agent that reads an issue, a pull request, or a week's worth of commits, and does something useful with what it finds. This article walks through what the feature actually is, why the security model matters more than the pitch-deck version of it, and how to write, compile, and run your first workflow today. By the end, you'll have a working triage workflow of your own and a clear sense of what's still a bit rough around the edges. # What Are GitHub Agentic Workflows? Strip away the marketing language, and the idea is fairly simple. You write a Markdown file that lives in .github/workflows/. The top of that file has a small block of YAML frontmatter describing when the workflow runs, what it's allowed to touch, and which AI engine powers it. Below the frontmatter, you write plain-English instructions describing what you want the agent to do. A command-line interface (CLI) tool called gh-aw reads that Markdown file and compiles it into a .lock.yml file, which is a completely ordinary GitHub Actions workflow. That's the part worth sitting with for a second: there is no separate agent runtime bolted onto your repository. It reuses your existing runners, your existing branch protection rules, and your existing policy constraints, because underneath the natural language, it's just Actions. The project is built by GitHub Next and Microsoft Research, and it currently supports four AI engines out of the box: GitHub Copilot, Anthropic's Claude, OpenAI Codex, and Google Gemini, with the option to plug in a custom processor if none of those fit. Copilot is the default engine, and if your organization already pays for a Copilot plan, workflow runs can bill directly to that organization instead of requiring you to manage a separate API key. It also sits inside a bigger idea GitHub calls Continuous AI, which is really just the practice of applying AI systematically across the software lifecycle instead of one prompt at a time. Agentic Workflows is the mechanism for doing that on a schedule or in response to repository events, rather than only when a person happens to be sitting at their keyboard asking Copilot a question. It's also worth being clear about what this is not. It isn't the same thing as Copilot's cloud coding agent, which you kick off manually from an issue or a pull request when you want an agent to implement something specific for you right now. Agentic Workflows is closer to a standing policy: "every Monday, summarize the week's issue activity" or "every time a PR opens, review it for security concerns." One is a task you hand off. The other is a habit you build into the repository itself. # Why This Is Worth Paying Attention To GitHub doesn't typically publish adoption numbers this early in a preview, so the fact that they attached named customer quotes to the launch says something about how far along the internal testing already was. Carvana told GitHub the flexibility and built-in controls gave their engineering team enough confidence to run agentic workflows across genuinely complex systems, including changes that touch more than one repository at a time, according to the official changelog. Marks & Spencer described a similar story from a different angle: their developers were losing real sprint hours to the boring stuff — issue triage, dependency maintenance, vulnerability remediation, and routine review — and building a shared catalogue of reusable agentic workflows let teams pick up that automation across any repository without reinventing it each time. Hud.io made a point that's easy to miss if you're only skimming the feature list: getting an agent to open a pull request was never the hard part of this. Trusting the output enough to actually merge it is. That's really the whole thesis behind the security design covered in the next section. Here's the shape of the feature as it stands today, pulled directly from GitHub's own numbers page: Metric Value Supported AI engines 4 built-in (Copilot, Claude, Codex, Gemini), plus custom engine support Security layers 5 (read-only token, zero secrets, network firewall, safe outputs, threat detection) Documented design patterns 18+ (IssueOps, ChatOps, DailyOps, BatchOps, and more) Supported GitHub event triggers 10+ (issues, pull_request, push, schedule, discussion, label, and others) Safe output types 8+ (create-issue, create-pull-request, add-comment, add-label, and others) Installation One command: gh extension install github/gh-aw # The Security Model Is the Real Story Here Most "AI does your DevOps now" pitches skip straight past the obvious question: what happens when the agent gets it wrong, or worse, gets manipulated by something hostile sitting inside an issue comment or a file in the repo. Prompt injection through repository content is a known risk with any agent that reads untrusted text, and GitHub built five layers specifically to contain that, rather than pretend it can't happen. Read-only tokens: The agent's GitHub token is scoped to read-only access by default. If it tries to push code, open a PR, or delete a file directly, the token itself doesn't allow it, regardless of what the agent decides to attempt. Zero secrets in the agent process: The process actually running the AI model never receives write tokens, API keys, or credentials of any kind. Those live only in a separate job that runs after the agent has already finished and its proposed output has been checked. If the agent is compromised mid-run, there's nothing in its reach worth stealing. A sandboxed container behind a network firewall: The agent executes inside an isolated container, and all outbound traffic is routed through what GitHub calls the Agent Workflow Firewall, a Squid proxy enforcing an explicit allowlist of domains. Anything outside that allowlist gets dropped at the kernel level, so a compromised agent has no path to quietly phone home with your data. Safe outputs: This is the part worth understanding properly, because it's the mechanism that makes the rest of the model work in practice. The agent can't write to your repository directly at all. Instead, it produces a structured description of what it wants to do — something like "open an issue with this title and this body." A separate job with narrowly scoped write permissions reads that request and applies only what you've explicitly allowed in the workflow's frontmatter: a hard cap of one issue per run, a required title prefix, specific label restrictions, whatever you decide. The agent proposes. A gated, deterministic job disposes. Agentic threat detection: Before any of that output actually lands in your repo, a dedicated threat-detection job runs its own AI-powered scan across the proposed changes, checking for injection attempts, leaked credentials, or suspicious code patterns. If something looks wrong, the whole run fails, and nothing gets written. Put together, the agent can read almost anything in your repository, but it can only ever act through a narrow, auditable contract you define yourself. That's a meaningfully different trust model from installing a third-party GitHub Action and granting it broad write permissions on faith. # What You Need Before You Start You don't need much to get going, but each of these matters: An account with one of the supported AI engines: GitHub Copilot, Anthropic Claude, OpenAI Codex, or Google Gemini. A GitHub repository where you have write access. GitHub Actions must be enabled on that repository. And the GitHub CLI, version 2.0.0 or later, must already be authenticated on your machine. Check your CLI version with gh --version, and if you need to authenticate, run: # Logs your local gh CLI into GitHub with the two scopes # agentic workflows need: repo access and workflow write access gh auth login --scopes repo,workflow Once that's done, install the extension that does the actual Markdown-to-YAML compilation: # Installs the gh-aw extension into your existing GitHub CLI gh extension install github/gh-aw If you're already on GitHub CLI 2.90.0 or newer, running any gh aw command will offer to install this automatically the first time you use it, so you won't hit a missing-extension error out of nowhere. # Setting Up Authentication This is the one step that trips up almost everyone the first time, so it's worth slowing down here. If you're using GitHub Copilot inside a repository owned by an organization with a Copilot plan, you want the built-in GITHUB_TOKEN approach. It bills usage straight to your organization and means nobody has to babysit a personal access token (PAT) as a repo secret. Your organization admin needs to enable "Allow use of Copilot CLI billed to the organization" under Copilot policy settings first. Once that's on, all you need in your workflow frontmatter is: permissions: contents: read copilot-requests: write # routes Copilot billing through the org, not a personal token This is a genuinely recent change worth calling out directly: as of the same June 11, 2026 release, GitHub Agentic Workflows no longer requires a PAT at all for this path. Earlier hands-on writeups from the technical preview period in February 2026 describe generating a fine-grained PAT with Copilot Requests permission and manually adding it as a COPILOT_GITHUB_TOKEN secret. That step still exists as an option for personal repositories or for third-party engines like Claude or Codex that need their own API key stored as a secret, but if you're running Copilot inside an org-owned repo, you can skip the token dance entirely now. For anything that does need a stored secret (personal repos, or Claude and Codex as your engine), you add it once through your repository's Actions secrets, either in the GitHub UI or with gh aw secrets set from the CLI. # Writing Your First Workflow Let's build something you'd actually want running in a real repository: an agent that triages new issues the moment they're opened, classifies them, labels them, and posts a short, useful response. You could write this file by hand, but a better first experience is to let a coding agent scaffold it for you. Run this once per repository to set that up: # Adds skills, instructions, and a helper agent to this repo # so any coding agent you use afterward understands how to # author and edit agentic workflows correctly gh aw init Then, from inside your coding agent of choice (Copilot CLI or VS Code agent mode both work), you'd prompt something like: create a new workflow that triages newly opened issues, classifies them by type and priority, applies labels, and posts an acknowledgement comment. The agent handles the file creation and the first compile pass for you. But it helps to actually read and understand the file it produces, so here's a hand-written version you can drop straight into .github/workflows/issue-triage.md: --- description: Classify new issues, apply labels, and post a short response on: issues: types: [opened] # only fires when a brand-new issue is created permissions: contents: read # age [truncated for AI cost control]