Grok 4.7 模型介紹：500K Context、長時間 Agent 與 API 導入重點

前言

2026 年 9 月 21 日，xAI 正式發布 Grok 4.7。這次更新的重點不是單純把聊天回答再寫得漂亮一點，而是把模型定位在長時間程式設計、Agent 任務與專業知識工作：讓模型可以處理比較複雜的工作、持續檢查自己的結果，並在多輪工具呼叫後完成一個可交付的成果。xAI 官方公告：Introducing Grok 4.7

截至 2026 年 9 月 22 日，Grok 4.7 已經可以透過 xAI API 使用，模型代號是 grok-4.7。官方文件列出的規格包含 500,000-token context window、文字與圖片輸入、可調整的 reasoning effort，以及 function calling、Web search、X search 和 code execution 等工具能力。Grok 4.7 模型文件

本文會從模型定位、官方 benchmark、API 價格、快速整合方式與後端導入風險幾個角度，整理 Grok 4.7 適合什麼工作。官方公布的分數會明確標註為官方結果；至於是否值得放進自己的產品，仍然要用真實工作負載做 evaluation。

本文封面為 AI 生成的概念插畫，用來呈現模型串接程式碼、工具與資料流的意象，並非 Grok 4.7 的實際操作介面截圖。

Grok 4.7 是什麼？

Grok 4.7 是 xAI 目前面向 coding、agentic tasks 與 knowledge work 的旗艦模型。這裡的 agentic tasks 可以理解成：模型不只回答一個問題，而是先拆解目標，再讀取資料、呼叫工具、執行程式碼、檢查結果，必要時修正方向，最後才交付答案或檔案。

相較於 Grok 4.6，xAI 表示 Grok 4.7 使用較大的 base model，並以更長的 reinforcement learning 訓練和更困難的任務組合強化模型。訓練資料特別偏向需要數小時才能完成的工作，因此官方強調它在自我驗證、長上下文管理與長流程任務上有所改進。xAI 也表示，模型經過原生訓練來理解 Grok Bot harness，讓它更適合對話與一般知識工作。xAI：Grok 4.7 模型改進

不過，這些描述是 xAI 公開的訓練方向，不代表我們已經知道完整的模型架構或每一個內部訓練細節。工程上比較實際的理解方式是：Grok 4.7 的價值單位，從「回答一個 prompt」往「完成一個需要多步驟驗證的任務」移動。

flowchart LR
    A[使用者目標] --> B[Grok 4.7 規劃]
    B --> C{需要工具？}
    C -->|否| D[產生文字回覆]
    C -->|是| E[Function calling / Search / Code execution]
    E --> F[取得工具結果]
    F --> B
    B --> G[驗證並交付成果]

核心規格

以下資料以 xAI 官方模型文件在 2026 年 9 月 21 日更新的內容為準。

項目	Grok 4.7
API model ID	grok-4.7
Context window	500,000 tokens
Knowledge cutoff	2026 年 5 月
輸入模態	文字、圖片
輸出模態	文字
文字輸出限制	官方文件標示無文字輸出上限
Reasoning effort	low、medium、high、xhigh；預設為 high
API	Responses API、Chat Completions
工具	Function calling、Web search、X search、Code execution
Batch API	不支援

這份規格有幾個容易被忽略的地方。第一，500K context 不代表每次請求都適合塞滿 500K tokens；長上下文會增加成本、延遲與管理複雜度。第二，輸入支援圖片，但官方模型頁並沒有把音訊或影片列為 Grok 4.7 的輸入模態，因此不要把它和完整的多媒體模型混為一談。第三，「無文字輸出上限」是模型文件的描述，實際應用仍然應該自行設定 token budget、逾時與停止條件。

Grok 4.7 相較 Grok 4.6 的變化

Grok 4.7 並不是透過新的 API 名稱來重新定義整個平台，而是沿用 Grok 4.6 的產品方向，再把重點放到更長、更複雜的任務。從官方公告可以整理出以下差異：

面向	Grok 4.6	Grok 4.7 的官方定位
主要方向	Coding、Agent、Knowledge work	延續相同方向，強化長時間任務
訓練重點	一般推理與工具工作流	更長的 reinforcement learning，偏重多小時任務
自我檢查	可以透過 prompt 與工具實作	官方宣稱更擅長驗證自己的工作
Context 管理	500K context window	同樣為 500K，但更強調長上下文使用
API 價格	$2 / 1M input、$6 / 1M output 起	標準價格與 Grok 4.6 相同
執行速度	官方作為比較基準	官方表示以相同服務速度提供

因此，升級的重點不一定是「每一個短問題都回答得更好」，而是當工作需要讀很多檔案、執行多次工具、跑測試並根據結果修正時，Grok 4.7 是否能提高整體任務成功率。

官方 benchmark 怎麼看？

xAI 在發布頁公布了多項評測結果。以下只列出幾個比較能反映 coding 與長流程工作的項目，分數都是 xAI 官方公布的結果，不是獨立第三方重現：

評測	Grok 4.7	Grok 4.6	評測方向
CursorBench 4.0	46.3%	40.4%	長時間軟體工程
DeepSWE v1.1	71.0%*	65.2%	軟體工程
EEBench	64.0%	53.0%	電機工程
AA Briefcase v1.1	1,657	1,546	多小時辦公工作
Terminal-Bench 4.0	38.0%	20.3%	多小時終端機工作
Harvey Legal Agent Benchmark	19.6%	15.8%	法律工作

* DeepSWE 的 Grok 4.7 分數是 high-effort 設定。這個註記很重要，因為 reasoning effort、工具配置、時間限制與評測版本，都可能影響最後結果。即使同一個模型在官方 benchmark 表現很好，也不能直接推導成「放進所有 repository 都會有同樣提升」。

比較合理的解讀是：xAI 想證明 Grok 4.7 的優勢集中在長時間 coding、終端機工作、專業知識任務與文件產出，而不是只追求短回答的低延遲。

安全與資安能力

Grok 4.7 這次也更新了 safeguard stack。xAI 表示，它在自家測試中具備更好的拒答與 jailbreak resistance，並且希望在資安和生物領域這類雙重用途場景中，同時保留良性工作的可用性與對危險請求的拒絕能力。xAI：Safety & Cybersecurity

官方公告提到幾個數字：

• 在 LatchBio 的 biosafety benchmark 中，Grok 4.7 得分為 62.4%。
• 在 xAI 的 HackerBench v0.3 中，官方表示只有 3.3% 的高風險雙重用途 prompt 通過，同時較少阻擋合法的防禦性資安工作。
• xAI 已開始提供少量邀請制的 Grok 4.7 red-team 能力給資安合作夥伴。

這些數字應該被視為xAI 的發布資料，而不是獨立安全認證。若要在資安產品、CI/CD 或自動化維運中使用，仍然必須自行測試 prompt injection、越權工具呼叫、機密資料外洩、惡意程式碼與錯誤修補等案例。模型拒絕危險請求，不等於整個 Agent 系統已經安全。

API、價格與可用性

截至本文撰寫時，Grok 4.7 可透過 xAI API、Grok Build、Cursor，以及部分 model gateway 使用。xAI 官方公告也列出第三方 coding harness 與雲端平台等整合方式；實際可用性仍會依平台、帳號與方案變化。xAI API Release Notes

標準 API 價格

價格以每 1M tokens 計算，並依 prompt 是否超過 200K tokens 分級：

請求大小	Input	Cached input	Output
200K prompt tokens 以下	$2	$0.50	$6
超過 200K prompt tokens	$4	$1	$12

這個價格結構帶來兩個工程上的結論。第一，長上下文不只會影響延遲，也會直接影響單次請求成本。第二，對於多輪 Agent，應該設計穩定的 prompt prefix 與快取策略，而不是每一輪都重新傳送大量相同內容。

Grok 4.7 Fast 與區域端點

Grok 4.7 Fast 是同一模型以較快基礎設施提供的變體，官方文件表示它的 token 價格是標準價格的兩倍，目前只在 Cursor 與 Grok Build 提供，並不開放給公開 xAI API。若需要資料留在美國境內，xAI 也提供 https://us.api.x.ai/v1 區域端點，但 token 使用價格會增加 10%。Grok 4.7 API 文件

最小 API 範例

下面是根據 xAI 官方文件整理的 Responses API 最小範例。它需要先建立 API key，並將 XAI_API_KEY 放在環境變數中；這段程式碼用來展示請求形狀，正式導入前仍應依 SDK 版本與錯誤處理需求調整。

curl https://api.x.ai/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $XAI_API_KEY" \
  -d '{
    "model": "grok-4.7",
    "input": "請檢查這段 JavaScript 的 bug，提出修正方式，並說明你如何驗證修正結果。"
  }'

若要做長時間 Agent，真正重要的通常不是把 model 換成 grok-4.7，而是處理以下幾個 API 細節：

1. 設定 prompt cache key：xAI 建議在 Responses API 使用 prompt_cache_key；如果使用 Chat Completions，則可以使用 x-grok-conv-id header，讓同一段對話比較容易路由到相同伺服器並命中快取。
2. 保留加密 reasoning content：Responses API 會回傳 reasoning.encrypted_content。多輪對話時，應該把這些 reasoning item 原樣放回下一次 request 的 input，不要自行解析或修改。
3. 處理長迴圈：工具很多、對話很長的 Agent 應該搭配 context compaction、最大迴圈數、總時間限制與明確的停止條件。
4. 把工具結果視為不可信輸入：模型讀到的網頁、issue、README 或終端機輸出，都可能包含 prompt injection。工具 Gateway 仍然要做 Schema 驗證、權限檢查與審計。

適合哪些工作？

從目前公開規格與發布方向來看，Grok 4.7 比較值得優先測試在以下場景：

1. Repository 級別的程式設計

例如跨檔案重構、除錯、補測試、migration、讀取 CI 結果後再次修正。這類工作需要模型把多個檔案、工具結果與測試輸出放在同一個任務脈絡裡，正好對應 Grok 4.7 強調的長時間 coding 能力。

2. 需要工具的 Agent

如果流程需要搜尋文件、查詢 X、執行程式碼，或呼叫內部 API，Grok 4.7 的 function calling 與工具整合比較有發揮空間。不過，模型「可以提出工具呼叫」和系統「允許它執行工具」是兩件事，權限邊界仍應由後端服務控制。

3. 文件與簡報產出

xAI 表示 Grok 4.7 在 GDPval 與 AA Briefcase 上比 Grok 4.6 有改善，並把法律、護理、金融分析等專業工作列為測試方向。若要導入企業工作流，建議先讓模型產生草稿與結構，再由規則檢查、來源引用和人工審核把關。

4. 文字加圖片的分析任務

Grok 4.7 支援文字與圖片輸入，因此可以納入截圖除錯、架構圖閱讀、文件圖片整理等流程。但如果需求是原生音訊、影片理解或即時語音互動，應該改看 xAI 其他專用模型，而不是假設 Grok 4.7 包含所有模態。

哪些情況不一定適合？

Grok 4.7 的能力越強，不代表每個請求都應該交給它。以下工作可能需要先比較成本和延遲：

• 高流量、短答案、固定格式的分類、標籤與摘要。
• 只需要幾百 tokens 回覆，且 P95 延遲比推理品質更重要的互動功能。
• 需要音訊或影片輸入的工作。
• 沒有沙盒、工具權限、人工核准與完整 trace 的自動化流程。
• 可以離線執行、但又需要 Batch API 的大批量工作；目前 Grok 4.7 模型頁標示不支援 Batch API。

在這些情況下，可以讓小型或低成本模型處理例行工作，再把複雜、失敗或高價值的任務升級給 Grok 4.7。模型路由通常比「所有問題都使用旗艦模型」更容易控制成本。

後端導入前的 evaluation 清單

如果團隊真的準備把 Grok 4.7 放進產品，建議先建立一組和實際工作相同的任務集，而不是只測幾個展示用 prompt：

1. 準備代表性案例：包含正常任務、錯誤輸入、工具 timeout、權限不足、prompt injection 與需要人工核准的操作。
2. 固定比較條件：讓 Grok 4.6、Grok 4.7 和其他候選模型使用相同的 prompt、工具、資料集與停止條件。
3. 記錄任務級指標：至少包含最終成功率、測試通過率、工具參數正確率、重試次數、P50／P95 延遲、輸入／輸出 tokens 與每個成功任務成本。
4. 從 read-only 開始：先讓 Agent 讀取程式碼、查詢文件或產生建議；接著才逐步開放可回滾的寫入，最後才考慮需要人工核准的生產操作。
5. 為長流程設定邊界：限制總執行時間、工具呼叫次數、最大輸出量與重試次數，避免模型在錯誤狀態中無限循環。

真正值得比較的不是「哪個模型的 benchmark 分數最高」，而是哪個模型可以用可接受的成本與風險，穩定完成自己的任務。

限制與注意事項

知識截止日期不是發布日期

官方模型文件列出的 knowledge cutoff 是 2026 年 5 月。Grok 4.7 雖然在 9 月發布，但不代表模型自然知道 5 月之後發生的所有事件。需要即時資訊時，應使用 Web search、X search、檔案檢索或其他有明確來源的工具，並在產品中保留引用與時間戳。

Context 越大不一定越好

500K tokens 是容量上限，不是建議每次都使用的目標。把整個 repository 或所有歷史對話塞進 context，可能導致成本升高、重要資訊被稀釋，甚至讓工具結果更難判斷。較好的做法是搭配摘要、檢索、context compaction 與明確的工作狀態。

加密 reasoning 會改變可觀測性設計

Responses API 的 reasoning.encrypted_content 可以在多輪對話中保留狀態，但後端不應把它當成可直接閱讀的 Chain of Thought。系統應該觀測模型輸出的工具呼叫、工具結果、狀態轉移、停止原因與最終成果，而不是依賴讀取內部推理文字來做審計。

官方 benchmark 不是自己的 SLA

官方 benchmark 能幫助我們了解模型發布方向，但無法取代產品級測試。尤其是 coding Agent，實際結果會受到 repository 品質、測試覆蓋率、工具權限、prompt、網路狀況與執行時間限制影響。導入前最好把 benchmark 當成候選篩選資料，再用自己的任務集做最後決策。

總結：Grok 4.7 的價值在「完成工作」

Grok 4.7 的核心訊號可以濃縮成三件事：

1. 它把旗艦模型的重點放在長時間 coding、Agent 與專業知識工作。
2. 它提供 500K context、可調整的 reasoning effort 與工具呼叫能力，適合多步驟工作流。
3. 它的標準 API 價格與 Grok 4.6 相同，但超過 200K prompt tokens、Fast 變體與區域端點都會改變成本。

如果你的需求是 repository 級別的除錯、需要多次工具呼叫的 Agent，或是希望用同一個模型處理程式碼與專業文件，Grok 4.7 值得放進 evaluation 名單。若只是大量處理短文字，或系統還沒有權限控管、沙盒和可觀測性，先使用更簡單的模型與工作流，通常會是更穩健的選擇。

模型可以提出計畫、呼叫工具和修正錯誤，但真正的可靠性仍然來自整個系統：清楚的權限、可回滾的操作、可追蹤的 trace、合理的成本上限，以及能夠驗證結果的測試。

參考資料

• Introducing Grok 4.7 — xAI（2026-09-21）
• Grok 4.7 模型文件 — xAI API
• Grok 4.7 API 使用指南 — xAI API
• Release Notes — xAI API