10 月 28 日，GitHub 把 Agentic Workflows 正式開放了。用法說起來很簡單：你不用再親手寫 Actions 的 YAML 文件，換成寫一個 Markdown 文件，用平時說話的話把要它做的事情寫下來，GitHub 會把這個文件轉成標準的 Actions 流程，agent 就在流程裏面照着做。
它做的就是這些事：給新 issue 分流、讀 CI 失敗的日誌、把文檔保持在最新、起草測試。免費版、團隊版、企業版都能用。如果流程用的是默認的 Copilot 引擎，還需要一份 Copilot 授權。
維護過小開源項目的人都知道一個星期的時間是怎麼沒的。寫一個新功能，也許一個晚上就夠了。剩下的時間都耗在沒完沒了的小事上：一個 PR 的檢查沒過，得有人打開日誌去讀；新 issue 一條條進來，沒標籤，信息還缺一半，每條都得先回一句，不然就涼在那裏；CI 文件是兩年前從別的項目抄的，運行鏡像一換又掛了。
這些事雖然都不難，但是每週都來，從不間斷。兩三個人的小項目，一個星期就那麼幾個晚上，所以時間很快就全花在這上面了。
小項目多半就是這樣慢慢涼下去的。雖然代碼可能一直沒有問題，但是維護會先停下來。一個星期沒人看 CI 的失敗記錄，然後一個月，issue 攢着沒人回。外面的人點進來，先看見紅色的構建徽章，再看見四十條沒人回的 issue，什麼都不說就走了。一個沒人打理的項目，從外面看就是已經放棄了的項目，別人也就按放棄了對待它。
Agentic Workflows 要接的正是這一攤小事。agent 的做法是先讀，讀完把草稿交給你。它讀一份 CI 失敗的日誌，寫清是哪一步掛的、報錯指向什麼。它讀一條新 issue，想好該貼什麼標籤，把要問回去的話先擬出來。有改動沒配上測試的，它先起草一套測試，交給維護者檢查。
這些草稿本身不會改動任何東西，它們要等一個人看過點頭。如果草稿大多數時候是對的，維護者一個星期的時間就不再花在讀日誌、看 issue 上面了，這些事有人先做了，剩下的只有檢查和拍板，這本來就是該人來做的部分。
對剛起步的項目來說，除了省時間之外，還有一件事更要緊，就是習慣養不養得成。管 issue、給 CI 結果寫摘要、保持文檔更新，這些是習慣，大多數小項目從來沒養成過。過去想把這些習慣變成自動流程，你得先會寫 Actions YAML，能把習慣寫進文件裏，還得有紀律每週照着跑。剛開始維護項目的人，這兩樣通常都沒有，所以習慣一直養不成，項目在代碼出問題之前，先從外面看起來像沒人管了。
現在把習慣用大白話寫下來、做成一個流程，流程就會自己一遍遍跑下去，小項目也就有了大項目的樣子：每條 issue 有人先回，每個掛掉的構建都附一句說得清的解釋，文檔不再悄悄過期。
上手這一步是容易的，因爲要寫的就是用自己的話寫的 Markdown，比起學 Actions YAML 要求低得多，新手也寫得出來。接下來要學的就不是怎麼寫文件了，而是兩件事：把要求寫得足夠清楚，讓第一次讀到的 agent 不會理解偏；還有它交回來的東西，要像看一個還不熟悉的貢獻者交回來的東西那樣，帶着覈對的心態去讀。
費用問題分爲兩塊：首先，agent 每運行一次就按量收一次錢，好在 GitHub 給了一個 forecast 命令，讓你先估一遍一個流程長期跑下去要花多少錢。其次，除了運行時的費用之外，默認引擎的 Copilot 授權也是一筆費用。
agent 每天讀的是陌生人寫的東西：issue、PR 的說明、評論。新手最需要先弄明白這一塊，因爲新手最容易把默認設置原樣接受下來就往下走了，而 agent 每天讀的東西，正是風險所在的地方。這些文字裏面會混着指令，agent 得分清哪些指令是你給的，哪些只是它要讀的材料的一部分，而這兩樣東西是混在同一批句子裏一起到的。
GitHub 的安排是從謹慎那頭起步的。agent 默認只讀，能看你的倉庫，不能改。它想改什麼，改動先要過兩道檢查：一道是 safe outputs 的校驗，一道是單獨跑的威脅檢測，都過了纔會真正落下來。
它跑的時候待在一個沙箱容器裏，前面有 Agent Workflow Firewall 這道防火牆擋着；它能碰哪些 GitHub 內容，有一道完整性過濾在管；涉及其他倉庫的操作，還可以放進微虛擬機裏，和其他東西隔開。
落到實際就是：陌生人 issue 裏的一句被它讀岔了的話，不能直接在你的項目裏生效，它先變成一個提議，提議還要被檢查一遍。在我自己的項目裏，合併和發佈這兩件事，我仍然會留在人工點頭之後，這是加在這些安排之上的。
GitHub 的公告裏引了 Accenture 一位負責人 Ben Alton 的估計，說這套流程一週能給他自己的開發工作省下 29 個小時。這個數字我不會拿來做計劃，因爲一個一週總共只有 3 小時維護時間的項目，根本沒有 29 個小時可省。那是他一個人在大公司裏的一週，跟一個小倉庫的情況不是一回事。
小項目實際能拿到的變化很具體：以前沒人回的 issue 有人回了，CI 失敗了有人把原因寫清楚，文檔也有人跟着更新，維護者不用再把晚上的時間耗在這些事上。
用之前和用之後，各記一記自己花在倉庫上的時間。如果檢查它的草稿花的時間，和自己動手差不多，那答案就是不值，這個答案從你自己的晚上就能看出來，不用看廠商的估計。我自己的做法，是先讓它只做讀和彙報的事，合併和發佈留給人，用上一個月，看時間到底省沒省下來再說。
你要是維護着一個小倉庫，這幾件事裏面，你會先把哪件交給它：讀 CI 失敗的日誌，還是回新 issue？又有哪件事，不管它做得多好，你都要自己留着？
覺得有用，可以收藏這個博客或者訂閱更新。我會繼續拿真實項目實測這類 AI 工具，把能用得上的部分寫出來。