截至 2026 年 9 月 3 日，TeamCity 2026.2 官方已列出 MCP 對 Pipeline 的讀取、建立、更新、刪除 4 類工具能力。發布說明 因此，TeamCity 2026.2 MCP 企業驗收的結論很明確：可以進入企業試點，但本週先採用安全模式、專案級身分與只讀排障；不要預設開啟 Brave Mode，也不要讓通用 Agent 直接控制正式發布線。Xcode 建置與簽名仍應留在隔離的可信 Mac 節點。

誰該看這篇：
計畫把 Claude Code、Codex 或 Cursor 等外部 Agent 接入 TeamCity 的研發效能負責人。
需要審查 MCP 身分、權限繼承與審計證據的安全負責人，以及管理 Xcode 建置池、簽名節點與遠端 Mac 容量的平台工程團隊。

最後更新於 2026 年 9 月 3 日；版本與工具能力核對自 TeamCity 2026.2 發布說明、MCP 整合文件 及相關官方權限文件。

01

平台負責人的放量邊界

平台團隊首先要把 MCP 工具能力轉成分階段的營運政策，而不是只確認某個客戶端能否成功連線。建議把權限分成四層：

  • 只讀診斷：查看建置狀態、日誌與失敗資訊。可作為第一階段試點。
  • 受控觸發：觸發個人或測試專案建置。必須限制專案、分支與觸發身分。
  • 配置寫入：建立或更新 Pipeline。只能先在沙盒專案與非正式分支測試。
  • 專案刪除：刪除 Pipeline 或專案相關設定。試點初期直接停用，除非有雙人審批與可驗證的復原流程。

TeamCity 2026.2 的官方 MCP 文件确认了上述工具范围，但官方功能存在，不等於你的企業環境已完成授權驗收。你還要以內部專案分級、變更流程與角色權限匯出結果作為放量依據。

平台負責人應交付三項證據：工具清單與啟用狀態、各專案允許的操作範圍，以及測試請求的成功和拒絕記錄。若只能展示「Agent 已連線」，卻不能證明它在不允許的專案上會被拒絕，驗收不能通過。

02

安全團隊的身分與權限模型

TeamCity MCP 企業驗收最容易忽略的問題，是把 MCP 控制面、TeamCity 專案權限、Build Agent 執行權限與 macOS 本地帳號混成同一層。這四層必須分開審查。

OAuth PKCE 適合需要互動式授權與可撤銷工作階段的接入方式。使用者令牌適合代表明確使用者執行受控操作，但要確認到期、撤銷與責任歸屬。專案級受限令牌則更適合自動化 Agent，前提是它只取得必要專案與動作範圍。具體令牌行為應對照 TeamCity 官方存取令牌文件，不能只依賴客戶端介面顯示的名稱。

安全團隊要逐項核對：

  1. 建立專用 Agent 身分，不沿用全域管理員帳戶。
  2. 取得 OAuth PKCE 授權確認頁，保存授權者、範圍與時間。
  3. 匯出角色權限，特別檢查父專案是否把權限意外繼承給子專案。
  4. 為令牌指定有效期、撤銷責任人與密鑰保存位置。
  5. 用允許專案和禁止專案各做一次實際訪問測試。
  6. 確認撤銷令牌後，舊工作階段與新請求都不能繼續執行敏感動作。

TeamCity 角色與權限說明 與 REST 權限文件 應作為權限判定依據。不要用「Agent 看不到按鈕」代替伺服器端拒絕測試，因為 UI 隱藏並不等於 API 權限已收緊。

驗收提醒： 若父專案權限、令牌範圍與 Agent Pool 權限沒有分別留檔，你無法在事後回答「Agent 為何看得到這個專案」或「哪個身分觸發了簽名建置」。

03

專案負責人的寫入與刪除驗收

專案負責人不需要重新審查整套 MCP 架構，但必須對每個 Pipeline 動作提供可追蹤的業務邊界。讀取、觸發、修改與刪除不能用同一個「可用／不可用」結果概括。

先建立一個不含正式憑證的沙盒專案，放入可回復的測試 Pipeline。讓 Agent 讀取建置日誌，再觸發非正式分支建置。這兩項通過後，才測試更新配置。每次更新都要保留變更前後差異、審批記錄、操作者身分與回滾動作。

刪除動作應安排在獨立的驗收窗口。測試前先保存配置版本，限制身分只接觸沙盒專案，並確認刪除後能由既定流程復原。若操作記錄只留下「請求成功」，沒有專案、Pipeline、操作者和結果，就不算具備企業審計品質。可參照 TeamCity 使用者操作追蹤文件 核對記錄欄位與查詢方式。

這裡的優點是，寫入能力可以被拆小，逐項增加風險。缺點是，測試成本高於單純開通連線，且第三方 Agent 的提示注入、錯誤判斷與重試行為，不能由官方工具清單推導。你必須在自己的隔離專案中重測。

04

Mac 平台團隊的建置隔離

AI Agent 觸發 iOS 建置時，TeamCity 只是控制面入口。它不應因此取得生產 Mac 的互動式登入權限，也不應成為讀取 Keychain 的捷徑。

平台工程團隊應把任務拆成三條路由：

  • 普通診斷任務：使用一般診斷 Agent Pool，不接觸簽名憑證。
  • 非可信程式碼驗證：使用隔離的測試 Agent，限制檔案、網路與快取可見範圍。
  • 正式簽名發布：只允許固定流水線進入可信簽名 Pool，且該流水線已經過人工審核。

Agent Pool 本身不是完整的安全邊界。你還要核對節點作業系統帳號、TeamCity Agent 帳號、工作目錄、快取、環境變數和簽名憑證流向。TeamCity Agent Pool 配置文件 可用於確認專案與節點的分配關係；Agent 通訊說明 則可協助你檢查控制面與建置節點的連線方式。

落地驗收可照以下步驟執行：

  1. 建立與正式簽名池分離的測試 Agent Pool。
  2. 為測試節點建立低權限 macOS 本地帳號。
  3. 將 Xcode 專案放入非正式分支，移除或替換正式簽名憑證。
  4. 設定 TeamCity 任務路由，只讓測試標籤進入測試池。
  5. 以 MCP 觸發建置，保存任務路由、節點身分與建置結果。
  6. 用一個需要簽名的正式流程做拒絕測試，確認通用 Agent 不能繞過固定流水線。
  7. 重啟測試節點，再核對工作目錄、快取與憑證是否符合預期。
  8. 將測試結果交給安全團隊和專案負責人共同簽核。

若你需要隔離的下游測試環境，可先參考 遠端 Mac 雲端訂購方案。這個步驟的目的不是立即替換現有建置池，而是讓你在真實 Xcode 專案、真實任務路由與實際節點重啟條件下取得證據。

05

審計團隊的止損與復原

審計與運維團隊要驗證的，不是「正常時能否成功」，而是 Agent 失控、誤觸發或權限錯配時能否迅速停止。

至少安排以下五個故障演練：

  1. 撤銷專案級令牌，確認後續 MCP 請求被拒絕。
  2. 終止 OAuth 工作階段，確認既有授權不會無限期延續。
  3. 關閉 Brave Mode，確認寫入工具回到安全限制。
  4. 取消異常或重複觸發的建置，確認正式簽名任務不會繼續排隊。
  5. 還原被誤改的 Pipeline，核對版本歷史與實際配置一致。

你還要監控高頻 REST 請求、短時間內重複觸發、配置大量變更與刪除操作。這些事件要能關聯到 Agent 身分、TeamCity 使用者、專案、Pipeline、節點與時間。若只監控 CPU 或建置失敗率，無法識別權限濫用。

復原路徑也要寫清楚：MCP 暫停時，人工 TeamCity 流程是否仍可發布；控制面故障時，已排隊工作如何處理；Mac 節點故障時，是否能把任務轉到另一個受信任池。節點的恢復時間與實際交付能力不能從官方文件推論，必須以你的故障演練記錄為準。TeamCity 升級說明 應在正式升級前重新核對，尤其是安全修復或 MCP 工具權限有變更時。

06

技術管理層的決策表

完成角色驗收後，管理層可以用下表作為放量閘門。表中的「通過」必須有實際測試證據，不接受口頭確認。

接入方案 可開放動作 必要隔離條件 必備證據 建議結論
安全模式＋專用身分 只讀診斷 限定專案、無簽名憑證 權限匯出、允許與拒絕訪問記錄 優先試點
安全模式＋受限觸發 測試建置、個人建置 非正式分支、獨立 Agent Pool 任務路由、觸發記錄、取消演練 條件放量
Brave Mode＋沙盒專案 配置建立與更新 限定時段、可回滾版本、人工審批 差異、審批、版本歷史、復原記錄 隔離試驗
正式簽名流水線 固定流程觸發 可信 Mac 池、憑證不外流、禁止通用寫入 Xcode 實測、憑證流向、節點權限 逐步放量
通用 Agent＋正式專案 修改或刪除 Pipeline 無法證明最小權限或止損能力 缺少完整審計與撤銷證據 暫緩上線

當只讀排障、受控觸發、配置寫入和下游 Mac 隔離都通過後，才按專案風險逐步擴大範圍。任務量增加時，再根據建置排隊、隔離要求與故障域，決定採用專用或彈性遠端 Mac 節點；不要先購置大量硬體，再反過來尋找使用場景。

07

企業試點的執行清單

你可以把第一輪驗收壓縮成一個可交接的工作包：

  • 平台團隊：凍結安全模式基線，列出允許的 MCP 工具。
  • 安全團隊：建立專用身分，核查 OAuth PKCE、令牌範圍與父專案繼承。
  • 專案團隊：準備沙盒 Pipeline，測試讀取、觸發、更新與刪除的不同結果。
  • Mac 團隊：建立非簽名測試池，驗證 Xcode 任務路由與本地帳號權限。
  • 審計團隊：保存請求、操作、版本、節點與撤銷記錄。
  • 管理層：依照「通過、限制上線、暫緩」三檔結論簽核，不以 Agent 連線成功作為上線標準。

這套流程的優點是責任清楚、證據可重複核對。限制也很直接：它不能替你證明某個第三方 Agent 客戶端在所有企業網路條件下都相容，也不能替你保證 Mac 節點在重啟或憑證異常後一定能自動復原。那些結果必須由隔離環境實測。

08

結論與下一步

TeamCity 2026.2 MCP 適合從安全模式、專案級身分和只讀排障開始試點。Brave Mode 不應成為正式環境的長期預設；通用 Agent 也不應直接握有正式發布線的配置或刪除能力。對 iOS 團隊而言，真正的風險交界在 TeamCity 控制面、Build Agent、macOS 帳號與簽名憑證之間，不能只看 MCP 是否成功連線。

相較於把測試工作直接塞進現有自購 Mac，現有方案常見的缺點是節點用途混雜、簽名環境難以隔離、團隊擴容要提前承擔硬體成本，而且故障演練容易影響正式建置。若你要先驗證 Agent Pool 路由、真實 Xcode 專案、節點重啟和任務取消，租用一台隔離的遠端 Mac 通常比立即改造生產簽名主機更容易控制風險。你可以先從 Mac mini M4 遠端租用價格與週期 評估短期試點；驗收通過後，再決定是否擴展為長期建置池或專用簽名節點。