GitHub 7 月 2 日宣布,Copilot agent session streaming 進入 public preview,GitHub Enterprise Cloud 且使用 enterprise managed users 的企業,可以把 Copilot 代理工作階段資料串到自己的端點,或透過 REST API 查詢。這些資料包括 prompts、responses、tool calls 等代理操作過程,涵蓋 GitHub.com、Copilot CLI、Visual Studio Code、Visual Studio 與合作 IDE。
這項更新把 AI 寫程式工具從「開發者按下去後得到結果」推向「企業可以追蹤過程」。當 Copilot 代理能讀檔、修改程式、呼叫工具、執行多步驟工作,企業不能只看最後 commit 或 pull request。它需要知道代理在中間看過什麼資料、採取什麼動作、是否觸碰敏感內容,以及有沒有出現異常提示或危險工具呼叫。

GitHub Copilot 串流資料補上代理工作黑盒
GitHub 官方說明指出,企業可在 AI Controls 的 Copilot 子頁面開啟 Copilot Usage Records Streaming 與 Copilot Usage Records API。這代表 Copilot 代理的活動不再只留在使用者介面或單一工具中,而能被導入企業既有的資料管線、SIEM 或內部稽核系統。
對大型軟體團隊來說,這是很實際的門檻。AI agent 可能在一個 session 內跨過多個檔案、依照提示做重構、呼叫測試工具,也可能誤解需求。若事件調查只能回頭看最後輸出的程式碼,資安團隊很難分辨是人類操作、模型建議,還是代理工具在某個步驟做出錯誤判斷。

企業資安團隊開始接管 AI coding 可視性
GitHub 文件把 streaming events 定位成代理每個動作的事件流,包含思考、寫程式與執行工具。這類欄位級資料讓企業可以建立告警、留存紀錄與事後追查流程。對金融、醫療、政府承包商或大型雲端公司來說,這不只是方便管理,而是 AI 工具能不能進正式開發環境的前提。
Copilot 的競爭也因此從模型能力延伸到治理能力。企業採購 AI coding 工具時,會同時問三個問題:模型能不能真的完成任務、能不能限制可用範圍、出事時能不能留下足夠紀錄。session streaming 回答的是第三個問題,也會影響前兩個問題的採用速度。
AI coding 供應商競爭轉向控制面與合規資料
過去 AI coding 市場多半圍繞補全品質、代理能力與 IDE 整合。現在大型客戶更在意控制面:哪些團隊能用、哪些模型可用、資料如何外送、使用紀錄能否進入內部監控。GitHub 把 agent session data 開放出來,等於把 Copilot 放進企業軟體常見的合規語境。

這也會壓迫其他 AI 開發工具跟進。只要代理式編程繼續擴大,供應商不能只宣稱模型會改程式,還要證明它能被管理、被限制、被追蹤。AI 寫程式正在從個人效率工具變成企業軟體治理的一部分。
消息來源:GitHub Changelog、GitHub Docs – Streaming session events、GitHub Docs – Copilot policies。