AI 開發工具
GitHub Agentic Workflows 加入 PR 即時 steer，但官方周報指向的 v0.87.4 尚未包含它
新功能讓執行中的代理讀取 PR 評論並按 `steer` 指示修正工作，同時要求明確的讀取權限。官方周報卻建議從較早建立的 v0.87.4 試用；固定該標籤的部署實際上拿不到功能。
GitHub Agentic Workflows（`gh-aw`）在 8 月 24 日合併 PR steering：工作流設定 `safe-outputs.create-pull-request.steer: true` 後，系統會先建立 PR，讓仍在執行的代理搜尋使用者留下、含有 `steer` 關鍵字的 PR 評論或 review comment，再把回饋納入後續工作。這把原本只能等待代理完成的 Actions 工作，改成可在既有審查介面中途校正。
權限邊界設計得相對明確。工作流必須自行宣告 `pull-requests: read`；編譯器若解析不到有效權限便直接報錯，而非自動擴權。若 GitHub MCP 使用工具 allowlist，編譯結果亦只加入 `pull_request_read`。PR 本身會標示 steering 已啟用，因此評論者知道留言可能成為模型輸入。
但發布資訊存在值得部署者注意的版本錯位。8 月 24 日周報把 steering 列為 v0.87.4 系列重點，並要求讀者下載 v0.87.4 試用；GitHub 的不可變 release 頁面則顯示該 pre-release 在 8 月 22 日建立。steering PR 到 8 月 24 日才合併，而且修改了 11 個 commits，故鎖定 v0.87.4 的建置不可能包含這項功能。v0.87.4 本身實際新增的是更嚴格的 safe-output 編譯驗證、可固定 Agent Plugin、逐 engine 模型覆寫，以及避免把 `GH_TOKEN` 留在 clone 的 `.git/config` 等變更。
工程團隊不應只按周報範例更新設定，應先確認使用的 commit 或後續標籤是否真正含有 PR #55171。另一個安全問題是 steering 把協作者留言正式接入提示路徑；即使它不擴張 GitHub 權限，也可能成為 prompt injection 或工作範圍漂移入口。後續版本需要清楚界定哪些身分可 steering、留言如何排序與去重，以及代理已執行具副作用步驟後如何處理互相衝突的指示。