GitHub Copilot Spaces API GA：為什麼共享上下文正在成為 Agent 的新入口

GitHub 的 Copilot Spaces API 已正式可用。这条公告很短，但产品訊號很重要。

團隊现在可以透過 API 建立、讀取、更新和刪除 Copilot Spaces，也可以管理 collaborators 和 resources，而不必完全依賴 GitHub UI 里的手动操作。

表面看，这是一次 API 更新。

更深一层看，这是 AI Agent 管理方式的變化。

Agent 的下一個入口，不只是聊天框，而是共享上下文空間。

發生了什么

Copilot Spaces 的作用，是收集圍繞工作的上下文。GitHub 這次 GA，让这些上下文變得可编程：團隊可以建立 Space、更新配置、讀取详情、刪除不用的 Space，并透過 API 管理協作者和資源。

对小團隊来说，这可能只是方便。

对企业来说，这是基础设施。只要團隊开始在多個倉庫、專案和流程里使用 Agent，上下文就不能只存在于某一次提示詞里，也不能只存在于某個開發者的記憶里。

它需要生命週期。

為什麼共享上下文重要

AI Agent 常見的失敗，不一定是推理能力差。很多時候，是上下文管理差。

人知道產品歷史、倉庫約定、客戶约束、未解决 issue 和過去的決策。Agent 只知道目前任務里能存取到的內容。

上下文缺失时，團隊就会不斷重复：

• 重新解釋同一套架构；
• 重新貼上同一份需求；
• 重新上傳同一批檔案；
• 重新提醒同一个约束；
• 重新審閱同一类錯誤。

共享上下文空間減少的就是这些損耗。它把上下文从一次性的 prompt，變成一个可管理的物件。

團隊接下來應該做什么

1. 把上下文当成資產

如果一个流程会重复，它的上下文就不該埋在聊天紀錄里。它應該被保存、命名、版本化，并被複用。

比如：新人 onboarding 上下文、發布上下文、客戶上下文、事故復盤上下文、程式碼倉庫上下文。

2. 把上下文和執行分开

上下文空間告诉 Agent 什么重要。執行環境让 Agent 安全地行動。

把這兩層混在一起会帶來風險。好的 Agent 系統会给 Agent 足够的知识去工作，但不会让它在没有審閱的情况下擁有过高權限。

3. 给上下文加入審閱和清理機制

共享上下文也会過期。旧決策、廢棄 API、过时客戶資訊，都可能誤導 Agent。

團隊需要清理循環：谁擁有这个 Space，谁可以更新，它什么时候過期，重要變化如何被人審閱。

这和 Buda 有什么關係

Buda 也沿着同一个方向建立：Agent 需要的是工作區，而不只是提示詞。

在 Buda 中，Drive 为 Agent 提供持久知识。Sessions 保留任務历史。Skills 封裝可複用方法。沙盒執行让 Agent 能做事，但不直接接管人的機器。Channels 则把 Agent 的工作带回團隊已经在使用的溝通場景中。

人仍然負責方向和质量。Agent 負責執行。

GitHub Copilot Spaces API GA 強化了一个更大的趨勢：上下文正在成为產品介面的一部分。團隊不会靠不斷写更好的 prompt 来管理正式的 Agent 工作，而会管理共享空間、工作流、權限和審閱循環。

這就是 Agent 工作區正在成形的样子。

你可以在 buda.im 建立第一个 Agent 工作流，也可以阅读 Buda 的 Agent Workspace 如何組織任務、檔案和執行環境。