GitHub 新 API 能查資源所屬成本中心：Coding Agent 費用要按團隊核算，還差哪幾步？

GitHub 在 2026 年 11 月 3 日宣布新增 REST API，可查詢使用者、組織、儲存庫或企業團隊隸屬哪個成本中心。這是企業追蹤 AI Coding 與研發平台支出的重要資料拼圖，但 API 回傳的是「資源歸屬」，不是「某個 Agent 任務花了多少錢」的完整帳單。本文拆解官方端點、權限、產品計費差異、報表連接方式，並提供可供財務與 IT 共用的核算表與驗收流程。[S01][S02]

專題編輯：Adrian Hsu｜企業 AI 策略編輯

一、新聞真正重要的不是增加一個 API，而是企業終於能問對成本問題

「公司有多少人在用 AI Coding？」與「每個團隊為哪種業務價值花了多少錢？」是兩個不同層級的問題。前者可以看啟用人數或使用紀錄，後者需要成本歸屬、產品類型、帳務期間、用量和工作成果。若企業只看總帳單，可能知道整體花了多少，卻不知道哪個事業部提出需求、誰負責控制預算，以及哪些支出能與交付成果建立關係。

GitHub 官方於 11 月 3 日的 Changelog 公告：REST API 現在可以指定資源類型與名稱，直接查詢其成本中心隸屬關係，支援 user、organization、repository、team 四種資源類別。過去常需要列出成本中心後逐個比對資源；新端點則讓查詢更直接。回應包含成本中心 ID 與名稱；若沒有隸屬關係，memberships 陣列為空。[S01]

這項變更的真正價值是降低治理系統確認資源歸屬的複雜度。它能讓內部的財務資料、部門組織表與 GitHub 資源之間建立更穩定的關聯，但仍需使用其他正式用量或帳單來源，才能進一步計算成本。若只看新端點就宣稱已能取得逐個 Coding Agent 任務的 token、費用與 ROI，便超出官方證據的範圍。

二、官方 API 究竟查得到什麼？先把「歸屬」與「費用」分開

依 GitHub REST 文件，端點為 GET /enterprises/{enterprise}/settings/billing/cost-centers/memberships，必要的查詢參數是 resource_type 與 name。對使用者與組織，name 是登入名稱或組織名稱；對儲存庫，使用 owner/repo；對企業團隊，則使用團隊 slug。API 回傳資源與其成本中心隸屬資訊。當 memberships 為空，表示此查詢結果沒有找到所屬成本中心，不能自行假設應歸哪個部門。[S02]

curl -L \
  -H 'Accept: application/vnd.github+json' \
  -H 'Authorization: Bearer YOUR_TOKEN' \
  -H 'X-GitHub-Api-Version: 2026-03-10' \
  'https://api.github.com/enterprises/ENTERPRISE/settings/billing/cost-centers/memberships?resource_type=repository&name=OWNER%2FREPO'

上面的 ENTERPRISE、OWNER、REPO 和 YOUR_TOKEN 是必須由讀者在授權環境替換的示意值，不是已驗證的真實資源。實際呼叫需要 GitHub Enterprise Cloud 對應功能、帳號可見範圍及具備企業計費讀取權限的授權方式。這篇文章未使用任何企業實際憑證，也未在讀者帳戶發出 API 請求。

官方文件的回應例子會有 resource 與 memberships，後者的各項包含 cost_center 物件，其中列出成本中心的 id 與 name。它沒有承諾同一次回應提供 SKU 成本、請求次數、任務 token、代理產生的程式碼行數或各小組預算上限。因此採購或財務人員應把它理解為一個「查人員或資產屬於誰」的資料查詢器，而不是新的一站式成本儀表板。

三、為何標題不能寫成「GitHub 全面開放 Coding Agent 費用逐團隊即時查詢」？

因為資源歸屬的資料，與產品實際計費的資料屬於不同系統。官方成本中心說明指出，對 GitHub Actions 這類以使用量計費的產品，成本分攤常依儲存庫或組織；對 Copilot 這類授權制產品，則與使用者歸屬有關；對以 AI Credit 方式計價、例如 Copilot cloud agent 的產品，成本中心可依使用者，或未直接指定時依授權所屬組織分攤。[S03]

這代表企業不能對每種產品套用同一個「Repository 等於部門」公式。即使某個開發者正在替 A 部門開發功能，其個人 Copilot 授權可能歸屬平台工程部；同時，GitHub Actions 的計費可能由該 Repository 所屬的成本中心承擔。若公司沒有事先定義分攤原則，最後總帳或許是對的，部門報表卻可能導致錯誤管理決策。

也不能把成本中心當成自動計算營運報酬的工具。Coding Agent 完成多少個任務、是否通過測試、是否減少缺陷或縮短需求交付時間，都需要研發流程的獨立指標。使用費用下降可能只是團隊暫停試用，未必意味效率提高；AI 使用費用上升也可能伴隨高價值功能交付。正確做法是將帳務資料與可驗證成果共同觀察，而不是把使用量當成生產力分數。

四、成本中心、AI Credit Pool、預算上限是三種不同控制

GitHub 於 2026 年中另有與 AI Credit 相關的成本中心功能。7 月公告說明，企業可針對成本中心限制其從共用 AI Credits 池使用的額度；上限由 GitHub 按分配至該成本中心的授權自動計算，不能任意手填金額；這與「超過共用額度後的計量費用預算」是不同控制。當成本中心使用完分配的包含額度，管理員可依設定選擇阻擋後續包含使用量，或在允許的條件下轉為額外付費；實際設定與適用方案須依當前企業帳號條件核對。[S04]

在團隊治理上，至少要分三層。第一層是歸屬：誰屬於哪個成本中心。第二層是計價：產品的用量、授權或 AI Credits 如何形成帳務金額。第三層是控制：是否設置團隊預算、包含額度上限、個人預算或警示通知。新 API 主要改善第一層，不能用一個呼叫取代另外兩層。對金融或跨國企業，第四層還可能需要會計科目、內部分攤與稽核調整。

例如企業有平台工程、業務系統、數據分析三個團隊，均使用 Copilot，而平台工程也負責維護其他團隊的 CI。應先說清楚 Copilot 使用費用按授權人員歸屬，Actions 按儲存庫歸屬，還是另外有跨部門代工的分攤約定。否則看板可能精準呈現一個帳務系統的數字，卻未必符合企業內部預算責任。

五、權限模型：能看見多少，取決於企業角色，不是拿到 Token 就行

官方說明指出，企業擁有者、Billing Manager，以及具適當企業計費讀取權限的 GitHub App 可查詢企業內資源的成本中心歸屬；組織擁有者和部分自訂角色則受限於原本可以查看的資源與成本中心。官方 REST 文件也指定相應的細緻權限類型與 Enterprise billing: read 要求。[S01][S02]

對企業而言，這意味著最小權限比快速拿到一組萬用 Token 更重要。若準備每日批次查詢，應優先評估用專門 GitHub App 安裝權杖、受限制的秘密管理和可審計的服務身分，而不是把高權限個人 PAT 交給每位報表製作者。權限不足時可能回傳 403，資源不存在或不可查時可能出現 404；必須保留錯誤狀態，避免把「系統沒有權限查」誤計為「這個團隊沒有成本」。

API 資料也屬企業內部管理資訊。雖然成本中心名稱看起來不像個資，但它可能間接揭露組織結構、專案名稱和預算安排。若要儲存在數據倉儲或提供給 AI 分析，仍需確認可見範圍、保留期限和內部資料分級。技術上可以導出，不代表可以無限制分享到所有員工或第三方平台。

六、怎麼做一套可靠報表？先畫三張表，不要先畫漂亮儀表板

第一張是「組織與成本中心對照表」，欄位至少有成本中心 ID、名稱、負責主管、預算期間、內部會計科目、有效起訖與核准版本。第二張是「GitHub 資源隸屬表」，保留 resource type、resource name、API 查詢時間、回傳的 memberships 及查詢錯誤。第三張是「實際用量與帳務表」，使用 GitHub 官方 Billing Usage API 或經核對的帳單匯出資料，保存 SKU、期間、數量、幣別、折抵和淨額等可用欄位。[S05]

對帳時先檢查資料的涵蓋範圍與期間。若成本中心隸屬在月中改變，需要定義是按交易發生日歸屬，還是按月結帳時的歸屬；不能因為 API 回傳的是現在的關係，就把過去帳單全部覆寫成現在的部門。若部分產品沒有完整的逐任務歸屬資料，應明確標示「未能分配」，保留待查項，而不是為了讓圖表總額等於帳單而任意平均分攤。

一份可用的管理報表，至少能回答四個問題：帳單總額如何和官方報表對上？各部門費用的分攤依據是什麼？目前尚有多少無法歸屬的使用量？如果某個成本中心突然增加，應由誰查明是授權、用量還是專案搬遷所致？只有做到這些，成本透明度才真正有助於決策。

七、Node.js 實作思路：兩個 API，先驗資料結構再計算

對技術團隊，推薦將「資源歸屬查詢」與「用量報表」分成不同模組，避免誤用欄位。以下是只查成本中心 membership 的最小示意程式，使用 Node.js 內建 fetch，不會推測不存在的成本 API。請在授權的測試環境執行，勿將 Token 提交至 GitHub：

const enterprise = process.env.GH_ENTERPRISE;
const token = process.env.GH_TOKEN;
const resourceType = 'repository';
const name = 'OWNER/REPO';
if (!enterprise || !token) throw new Error('Missing configuration');

const url = new URL(`https://api.github.com/enterprises/${encodeURIComponent(enterprise)}/settings/billing/cost-centers/memberships`);
url.searchParams.set('resource_type', resourceType);
url.searchParams.set('name', name);

const response = await fetch(url, {
  headers: {
    Accept: 'application/vnd.github+json',
    Authorization: `Bearer ${token}`,
    'X-GitHub-Api-Version': '2026-03-10'
  }
});
if (!response.ok) throw new Error(`GitHub API HTTP ${response.status}`);
const data = await response.json();
console.log(JSON.stringify({ resource: data.resource, memberships: data.memberships }, null, 2));

這份示例只處理受控查詢與明確的 HTTP 錯誤回報。正式應用還需要分頁與用量來源的接口、速率限制處理、可觀察性、秘密輪替、輸入合法性檢查與權限治理。尤其不要將多個月的成本趨勢直接建立在即時 membership 查詢上，因為它無法自行提供完整的歷史隸屬變化。要做財務結帳，須與當期實際帳務資料及內部異動紀錄共同核對。

八、FinOps 不是監控 AI 請求越少越好，而是對齊每筆支出要得到什麼成果

企業管理者常想問「每個部門平均花費多少」。這是有用的起點，但不應成為唯一指標。對研發工作，更具意義的分母可能是通過驗收的功能、已合併且沒有重大回歸的 Pull Request、成功解決的營運缺陷或縮短的交付週期。這些指標都應經過定義，並且把需求複雜度與高風險功能的審查成本納入考量。

例如 A 團隊在一個月內使用大量 Coding Agent 執行測試生成，B 團隊使用很少。若 A 團隊因此改善了可重現的測試覆蓋並降低缺陷，額外成本可能有理由；若只是重複生成、反覆失敗和大量未被合併的程式碼，則應改善流程。此處沒有足夠數據可以宣稱 AI 一定帶來特定比例的 ROI。可行做法是先設立基準期，再比較任務完成率、人工審查時間、失敗重跑量與實際支出。

這也改變內訓目標：不是要求員工每人每天使用多少 AI，而是教團隊以需求拆解、測試、授權和審查，減少錯誤重工。當使用資料能對應真正產出，FinOps 才不會淪為只削減 AI 工具預算的會計活動。

九、企業應如何啟動 30 天試點？

第一週，找出官方帳務資料能取得哪些欄位，確認 Enhanced Billing Platform 及成本中心功能的適用性，建立成本中心負責人與產品計費規則。第二週，使用新 membership API 抽查一組真實但經授權的使用者、儲存庫和團隊，逐筆記錄空結果、權限不足及對照錯誤。第三週，把指定期間的帳單或 Usage API 報表與歸屬資料連接，保存未分攤項目與調整紀錄。第四週，與主管核對一張簡單報表，選定後續每月審查節奏及異常處理窗口。

驗收不只看圖表能否開啟，還要抽查來源、同一期間的淨額、無歸屬資源比例、異動前後紀錄及權限。若財務認為一個 SKU 應按人分攤、IT 卻按儲存庫計算，就應先定義會計政策，不要讓技術實作悄悄決定管理原則。若資料不完整，報表必須把未知列出來，而不是強迫每筆費用出現在某個團隊名下。

補充：財務與 IT 協作時，四種錯誤應分別處理

第一種是資源沒有歸屬：必須由責任單位補建成本中心關係，而不是由分析師自行猜測。第二種是 API 沒有權限：應由授權管理員確認可視範圍，避免把 403 記成零成本。第三種是帳務期間不同：查詢目前的部門隸屬不能取代某個歷史月份的內部結帳規則。第四種是產品成本歸屬邏輯不同：授權費用、Actions 使用量及 AI Credit 計價可能使用不同分配基礎，不應在同一條公式裡混算。

一個小型試點可以先選 10 個有代表性的資源，再請財務與 IT 共同手動核對。只有當這些樣本的資源類型、隸屬、帳務期間與費用欄位都能合理解釋，才擴展為自動化報表。把差異清單保存為版本化的審核紀錄，能避免未來組織異動時無法回溯原本的決策。

十、常見問題與下階段觀察

這個 API 是否可回傳個別 Coding Agent 任務費用？ 官方 11 月 3 日公告與端點文件證實的是成本中心 membership 查詢，未將逐任務費用列為此端點的回應欄位。若要看費用，需另接適用的 Billing Usage 來源，並確認產品是否有足夠維度可供分攤。

沒有成本中心 membership 代表沒有支出嗎？ 不是。這可能是尚未分配、資源歸屬方式不同或查詢結果不完整。空集合不能等同於零費用，也不能把 403 權限錯誤當成空集合。

是否所有 GitHub 方案都可使用？ 成本中心功能以 GitHub Enterprise Cloud 相關帳務條件為核心；個別 API 權限與報表可用性應按官方文件及企業訂閱查核，不應套用到所有免費或自管版本。

下一步該看什麼？ 觀察 GitHub 是否擴充 AI 使用量與費用的正式報表維度，以及企業如何整合部門預算、代理使用資料和可驗證研發成果。現階段最有價值的不是增加儀表板數量，而是先把歸屬資料與計費原則分開、保留查核證據，再建立可以持續檢驗的成本決策。

結論：把「可以查屬於誰」變成「知道為何花錢」

新 REST API 讓 GitHub 資源和成本中心的對照更容易，卻沒有把所有 Coding Agent 成本分析一鍵完成。可靠的做法是串接資源歸屬、官方用量帳務、組織責任及研發成果四種資料，清楚說明分攤規則、期間與未知項。對企業而言，這項更新值得關注的原因，是它讓 AI 開發成本治理多了一項可機器查證的基礎，而不是出現了一個不需要財務判斷的自動報帳系統。

官方來源與編輯界線

[S01] GitHub Changelog，2026-11-03：https://github.blog/changelog/2026-11-03-look-up-a-resources-cost-center-with-the-github-rest-api/ 。[S02] GitHub REST API，Cost centers：https://docs.github.com/en/enterprise-cloud@latest/rest/billing/cost-centers 。[S03] GitHub Docs，Cost centers：https://docs.github.com/en/billing/concepts/cost-centers 。[S04] GitHub Changelog，2026-07-02：https://github.blog/changelog/2026-07-02-cost-centers-now-support-included-usage-caps/ 。[S05] GitHub REST API，Billing usage：https://docs.github.com/en/enterprise-cloud@latest/rest/billing/usage 。公告由 GitHub 自行發布，功能可用性與企業實際帳單尚未經獨立帳號實測；本文所有金流及治理情境均為方法示例，不宣稱特定企業的節省金額或已部署成果。

圖片與素材說明

封面與數據流程圖為原創抽象編輯圖，圖中若出現資源名稱及費用欄位，僅用作資料模型示意，不代表 GitHub 官方介面或企業實際帳單。

內容製作與更正

本文由 AI 協助整理、撰寫及查核；專題編輯為 TARAISG AI 編輯計畫中的策展角色，身分說明見作者頁。本文未宣稱經具名人工或專業法律審核；技術範例與管理建議的適用條件請依正文及官方文件核對。