作者 | Sergio De Simone

譯者 | 明知山

GitHub 最近 推出 Agentic Workflows（智能體工作流） 技術(shù)預覽版。據(jù) GitHub 介紹，這是一種借助可理解上下文與意圖的編碼智能體來自動化完成復雜、重復性倉庫任務的全新方案。該技術(shù)可實現(xiàn)自動問題分類與標注、文檔更新、CI 故障排查、測試優(yōu)化及報告生成等工作流。

我們最初探索 GitHub Agentic Workflows 源于一個簡單的問題：在 AI 編碼智能體時代，具備強大安全防護機制的倉庫自動化會是怎樣的形態(tài)？而一個很自然的切入點就是作為 GitHub 上可擴展倉庫自動化核心的 GitHub Actions。

GitHub Agentic Workflows 利用了大語言模型的自然語言理解能力，讓開發(fā)者只需通過簡潔的 Markdown 文件定義自動化目標、描述預期結(jié)果，隨后編碼智能體便可通過 GitHub Actions 執(zhí)行這些指令。

這樣可以在現(xiàn)有的自動化基礎設施之上構(gòu)建智能體工作流，繼承權(quán)限管理、日志記錄、沙箱隔離和可審計性等能力，同時融入 額外的安全控制機制，從而實現(xiàn)“真正可持續(xù)運行的智能體”。該架構(gòu)大量使用隔離沙箱來運行智能體與 MCP 服務器，避免單個組件被入侵后影響整個系統(tǒng)；智能體由防火墻保護，僅能訪問開發(fā)者明確授權(quán)的資源。

此外，該系統(tǒng)具備強大的安全防護機制，可將 AI 決策安全地集成到 CI 流程中。工作流默認以只讀權(quán)限運行，任何寫入操作（如創(chuàng)建 PR 或 Issue）都必須經(jīng)過 安全輸出 流程，確保輸出可審查、可管控。

GitHub 表示，開發(fā)者也可采用另一種方案：將 Copilot、Claude 等編碼智能體的 CLI 直接集成到標準的 GitHub Actions YAML 工作流中。但這樣做，會授予智能體超出特定任務所需的過多權(quán)限。

GitHub 重點介紹的示例包括持續(xù)分類、文檔維護、代碼質(zhì)量改進、每日狀態(tài)報告等，體現(xiàn)了 GitHub 所提出的 持續(xù) AI（Continuous AI） 的愿景。據(jù) GitHub 表示，無論是智能體工作流還是持續(xù) AI，其目的都是增強而非取代現(xiàn)有的 CI/CD 流程，并確保人類始終參與拉取請求審批等關(guān)鍵決策環(huán)節(jié)。

GitHub Agentic Workflow 的定義采用 Markdown 文件的形式，包含兩個部分：第一部分使用 YAML 指定配置細節(jié)，例如何時運行工作流、所需權(quán)限、輸出內(nèi)容以及使用的工具；第二部分用自然語言描述任務，如下例所示：

Keep it concise and link to the relevant issues/PRs.

在 Hacker News 上，woodruffw 表達了對 持續(xù) AI 這一寬泛概念 的擔憂，但同時也指出，利用 LLM 生成工作流規(guī)范或許具備一定價值：

我能理解讓 LLM 輔助開發(fā) CI/CD 工作流的價值，但想不明白為什么要讓它以持續(xù)運行的方式參與到 CI/CD 流程中？

wiether 評論稱，這種結(jié)合 YAML 和 Markdown 的工作流格式“糟糕得可笑”，在一定程度上背離了“讓非技術(shù)人員以低代碼 / 無代碼方式創(chuàng)建自己的工作流與 CI”這一目標。

最后，ljm 對使用智能體 AI 可能帶來大量額外開銷表示擔憂，并表示不希望“任何借助生成式 AI 進行重構(gòu)或文檔維護的工作流刷屏我的倉庫”。

如前所述，GitHub Agentic Workflow 仍處于技術(shù)預覽階段，暫不適合用于生產(chǎn)環(huán)境。如需更多工作流示例，GitHub 建議開發(fā)者查看 Peli 的 Agent Factory。

https://www.infoq.com/news/2026/02/github-agentic-workflows/

聲明：本文為 InfoQ 翻譯，未經(jīng)許可禁止轉(zhuǎn)載。