開始前需要準備什麼
GLM-5.2 是模型,而不是完整的程式碼代理。周圍的工具仍必須讀取檔案、編輯檔案、執行指令、保留狀態,並決定何時停止。
連接之前,請準備好:
- 程式碼代理介面。 Claude Code、Cline、OpenCode 或您自己的工具迴圈都可以扮演此角色。
- API 存取權或本機推理。 託管存取是評估模型較快速的方式。本機推理能提供更多控制權,但需要大幅增加的硬體與營運工作。
- 能夠自我驗證的儲存庫。 在要求代理修改程式碼之前,您應該確切知道建置、lint、型別檢查與測試指令。
- 隔離的工作分支。 不要在有未提交變更的正式環境分支上開始長時間的自主任務。
- 明確的界線。 決定代理是否可以安裝相依套件、存取網路、變更結構描述、執行遷移或建立提交。
最後兩項不是可有可無的安全作秀。擁有 Shell 存取權的程式碼代理,可能做出技術上有效、卻完全不符合您發布流程的變更。
選擇正確的 GLM-5.2 執行方式
有三種合理的方式。最佳選擇更多取決於您現有的工具與資料規則,而非模型品質。
| 方式 |
最適合 |
主要優點 |
主要取捨 |
| 搭配 Z.ai 的 Claude Code |
已在使用 Claude Code 的開發人員 |
直接使用 Anthropic 相容設定 |
需要獨立的 Z.ai 金鑰與方案 |
| GPT Proto API |
相容 OpenAI 的代理與自訂應用程式 |
使用單一金鑰,以隨用隨付方式存取 200 多個模型 |
仍需要代理介面或工具迴圈 |
| 本機部署 |
私有程式碼、自訂服務、持續性工作負載 |
完整控制權,可掌握權重與基礎架構 |
大型儲存空間、記憶體、GPU 與服務需求 |
首次評估時,請使用託管存取。您可以先了解 GLM-5.2 是否適合您的儲存庫,再決定是否購買或預留推理硬體。如果您已經透過單一應用程式路由多個文字、影像或影片模型,GPT Proto 模型集合也能讓您測試 GLM-5.2,而不必建立另一個隔離的整合。
如何搭配 Claude Code 使用 GLM-5.2
Z.ai 為 Claude Code 與 Goose 等工具提供 Anthropic 相容端點。目前的文件使用:
https://api.z.ai/api/anthropic
您需要 Node.js 18 或更新版本、Claude Code、Z.ai API 金鑰,以及包含 GLM-5.2 的有效方案。官方安裝指令如下:
npm install -g @anthropic-ai/claude-code
在 macOS、Linux 或 WSL 上開啟 ~/.claude/settings.json。在原生 Windows 上,請使用 %USERPROFILE%\.claude\settings.json。加入以下環境設定,但不要刪除檔案中現有的其他無關欄位:
{
"env": {
"ANTHROPIC_AUTH_TOKEN": "your_zai_api_key",
"ANTHROPIC_BASE_URL": "https://api.z.ai/api/anthropic",
"ANTHROPIC_DEFAULT_HAIKU_MODEL": "glm-4.5-air",
"ANTHROPIC_DEFAULT_SONNET_MODEL": "glm-5.2[1m]",
"ANTHROPIC_DEFAULT_OPUS_MODEL": "glm-5.2[1m]",
"CLAUDE_CODE_AUTO_COMPACT_WINDOW": "1000000",
"CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC": 1,
"API_TIMEOUT_MS": "3000000"
}
}
在 Claude Code 中,[1m] 後綴會啟用 1M 上下文版本。如果無法辨識該模型名稱,Z.ai 也建議使用較新的 Claude Code 版本。上述設定遵循目前的 Z.ai Claude Code 指南與 GLM-5.2 模型切換指南。
從您希望代理存取的儲存庫啟動 Claude Code:
cd path/to/your-project
claude
接著執行:
/status
確認設定來源是您編輯的檔案,且選取的模型是 glm-5.2 或 glm-5.2[1m]。如果仍顯示其他模型,請關閉所有 Claude Code 工作階段、開啟新的終端機、驗證 JSON,並檢查該安裝所使用的檔案路徑。
有意識地選擇 High 或 Max 努力程度
GLM-5.2 提供 High 與 Max 推理層級。在 Claude Code 中,Z.ai 將 low、medium 和 high 對應至 GLM-5.2 High;xhigh、max 和 ultra 對應至其 Max 模式。您可以使用 /effort 變更設定。
程式碼說明、小型錯誤調查、測試產生與範圍明確的編輯,請從 High 開始。當代理必須跨多個子系統追蹤錯誤、規劃大型遷移,或處理具有多個可能原因的模糊故障時,請使用 Max。Max 可能改善計畫,但通常也會產生更多推理 token,並讓回覆速度變慢。這應該是任務層級的決策,而非永久的預設值。
如何在 GPT Proto 上呼叫 GLM-5.2 API
Claude Code 只是其中一種介面。如果您的程式碼代理接受 OpenAI 相容提供者,請將其指向 GPT Proto,並使用模型字串 glm-5.2。
安裝目前版本的 OpenAI Python 用戶端:
python -m pip install openai
請將金鑰儲存為環境變數,不要直接貼入原始碼:
export GPTPROTO_API_KEY="your_gptproto_api_key"
加入有效金鑰後,以下請求即可直接執行:
import os
from openai import OpenAI
client = OpenAI(
api_key=os.environ["GPTPROTO_API_KEY"],
base_url="https://gptproto.com/v1",
)
response = client.chat.completions.create(
model="glm-5.2",
messages=[
{
"role": "system",
"content": (
"You are a repository-level coding assistant. Inspect before "
"proposing changes. Preserve existing API contracts, do not add "
"dependencies without approval, and list the verification "
"commands required for every proposed edit."
),
},
{
"role": "user",
"content": (
"An API client occasionally sends two refresh-token requests "
"after several requests fail with 401. Identify the likely race "
"condition, describe the files you would inspect, and return a "
"minimal repair plan before writing code."
),
},
],
)
print(response.choices[0].message.content)
等效的 cURL 請求如下:
curl https://gptproto.com/v1/chat/completions \
-H "Authorization: Bearer $GPTPROTO_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "glm-5.2",
"messages": [
{
"role": "system",
"content": "Inspect before editing. Preserve API contracts and report the tests required for every proposed change."
},
{
"role": "user",
"content": "Plan a safe fix for duplicate refresh-token requests after concurrent 401 responses."
}
]
}'
這是真正的 API 呼叫,但尚未是自主程式碼代理。若要將其轉變為代理,您的應用程式必須為讀取檔案、搜尋儲存庫、套用修補程式與執行測試等操作,提供受控工具。接著,它必須持續將工具結果回傳給模型,直到任務達到明確的停止條件。
在教學中很容易模糊這項區別。聊天完成可以提出修補程式;代理則是決定要檢查哪些檔案、執行變更、觀察結果並再次嘗試的系統。
GPT Proto 目前列出的 GLM-5.2 價格為每 1M 個輸入 token $1.26,以及每 1M 個輸出 token $3.96。您可以在 GLM-5.2 API 頁面查看目前費率與模型詳細資訊;帳戶層級的計費則可在 GPT Proto 模型頁面查看。
使用儲存庫層級任務,而不是聊天提示
「修復驗證錯誤」給了代理一個目標,卻沒有界線、驗證方法或完成定義。更好的請求會明確說明工程合約。
請使用以下範本:
Goal
Fix the duplicate refresh-token request that occurs when several API calls
receive 401 responses at the same time.
Relevant context
- The frontend is TypeScript.
- Authentication state is managed in src/auth/.
- HTTP requests pass through src/api/client.ts.
- Existing public API contracts must not change.
Constraints
- Do not add dependencies.
- Do not change backend endpoints or token formats.
- Do not create a commit.
- Ask before modifying files outside src/auth/ and src/api/.
Required process
1. Read the relevant files and map the current refresh flow.
2. State the most likely cause and any assumptions.
3. Propose the smallest safe change before editing.
4. Implement only after the plan is clear.
5. Run npm run typecheck, npm run lint, and the authentication tests.
Definition of done
- Concurrent 401 responses share one refresh request.
- Queued requests retry once after refresh succeeds.
- Failed refresh clears authentication state without an infinite retry loop.
- Existing tests pass and a regression test covers the concurrent case.
Stop conditions
- Stop and ask if the fix requires a new package, backend change, migration,
secret, or destructive command.
Final report
List changed files, explain the behavior change, show verification results,
and identify any remaining risk.
這個提示比「修復錯誤」更長,但通常能減少代理浪費的回合。它告訴模型哪些內容不要碰,也讓跳過驗證的情況變得明顯。
值得嘗試的三個 GLM-5.2 程式碼代理範例
小型程式碼產生測試幾乎無法揭示代理模型的能力。GLM-5.2 的定位是長期工作,因此請使用涉及導覽、規劃、工具與驗證的任務進行評估。Z.ai 表示其上下文視窗為 1M,並且在 SWE-bench Pro 與 Terminal-Bench 2.1 上較 GLM-5.1 有顯著提升,但這些基準測試結果不保證它能在您的儲存庫中成功。您自己的任務完成率比一般分數更重要。請參閱官方 GLM-5.2 模型文件,了解其回報的評估設定。
1. 追蹤並修復多檔案錯誤
提供錯誤報告、相關記錄、測試指令,以及檢查儲存庫的權限。要求代理在編輯前先繪製呼叫路徑。這可以測試它是否能在中介軟體、服務與狀態管理之間維持假設,而不是直接修補第一個可疑函式。
要求加入回歸測試。沒有回歸測試,看似合理的修補程式可能看起來已完成,卻仍留下競態條件。
2. 在不改變行為的情況下升級相依套件
要求代理盤點直接與傳遞相依套件的使用情況、閱讀您提供的遷移說明、更新可能最小的範圍,並執行完整的相關測試套件。告訴它不要使用廣泛型別轉換來隱藏型別錯誤,也不要停用 lint 規則。
這項測試的是對限制條件的遵循。挑戰不在於變更版本字串,而在於介面在程式碼底層變動時仍維持行為。
3. 在實作前稽核不熟悉的儲存庫
提供功能需求,要求產生儲存庫地圖、可能的整合點、受影響的測試與未解決問題。第一輪不要允許編輯。
這是一種低風險的實用評估方式,因為您可以在授予寫入權限前,判斷模型是否理解架構。如果它的地圖錯誤,請修正上下文,而不是支付多次失敗的實作迴圈。
如何使用 1M 上下文,而不必付費閱讀所有內容
1M token 視窗是上限,而不是目標。最昂貴的錯誤,是假設檔案越多,答案就一定越好。
從儲存庫地圖開始。包括頂層目錄樹、套件資訊清單、建置與測試指令、架構說明,以及最接近故障行為的檔案。隨著假設逐步形成,再讓代理要求其他檔案。
排除明顯的雜訊:
- 產生的建置輸出
- 相依套件與 vendor 目錄
- 壓縮後的資產
- 與任務無關的大型快照
- 與故障無關的歷史記錄
- 密鑰與本機環境檔案
對於長時間任務,要求代理維護簡短的檢查點,其中包含目前目標、已變更檔案、所作決策、測試結果與未解決風險。檢查點比反覆重播先前的每段對話更便宜,也更容易檢查。
請記住,API 計費通常計算每次請求處理的 token,而不只是唯一文字。如果代理在十個回合中反覆傳送相同的 300K token 儲存庫上下文,在計入新訊息之前,計費輸入可能接近 3M token,具體取決於提供者的快取與請求行為。大型視窗能解決容量問題,但不會消除上下文管理的必要。
GLM-5.2 程式碼代理的成本是多少?
按照 GPT Proto 目前列出的費率,基本計算方式如下:
cost = input_tokens / 1,000,000 × $1.26
+ output_tokens / 1,000,000 × $3.96
以下是三個說明性總額:
| 單一任務的累計用量 |
輸入成本 |
輸出成本 |
總計 |
| 50K 輸入 + 5K 輸出 |
$0.0630 |
$0.0198 |
$0.0828 |
| 300K 輸入 + 30K 輸出 |
$0.3780 |
$0.1188 |
$0.4968 |
| 1M 輸入 + 100K 輸出 |
$1.2600 |
$0.3960 |
$1.6560 |
這些是 token 成本範例,不代表每項任務的保證價格。程式碼代理在讀取檔案、規劃、套用變更、解讀測試失敗與重試時,可能會進行多次模型呼叫。真正重要的是整個執行過程中累計計費的輸入與輸出。
以下三項控制可讓成本保持易於理解:
- 設定代理回合的最大數量。
- 要求在任務擴展至新目錄或不同問題之前先取得核准。
- 依任務記錄 token 與成本,而不只是依月份記錄。
第三項控制有助於公平比較模型。較便宜的 token,如果需要兩倍的重試次數,仍可能產生更昂貴的修復。
可以在本機執行 GLM-5.2 嗎?
可以,但「本機」需要加以說明。
GLM-5.2 以 MIT 授權發布,其 官方 Hugging Face 模型卡列出 vLLM、SGLang、Transformers、KTransformers、Unsloth、Ascend NPU 與量化執行環境的部署方式。因此,自行託管在技術上是可行的。
完整模型仍約有 753B 個總參數,每個 token 約有 40B 個參數處於啟用狀態。啟用參數數量可以降低推理運算量,但所有專家權重仍需要儲存並可供使用。粗略以僅計算權重的方式估算,753B 個參數在 16 位元精度下需要約 1.5TB,在 4 位元精度下約需 376GB,這還未計入執行環境負擔、KV 快取、長上下文記憶體與服務預留空間。實際需求取決於量化方式、框架、硬體拓撲與上下文長度。
因此,GLM-5.2「可在本機執行」的說法可能為真,但對筆記型電腦使用者仍毫無意義。高度量化的社群版本可能降低入門門檻,但也可能同時改變速度、輸出品質、支援的上下文,或三者皆改變。
在以下情況選擇本機部署:
- 原始碼不能離開您所控制的基礎架構。
- 您需要修改或微調權重。
- 持續使用使自有基礎架構更具經濟效益。
- 您的團隊能夠操作並監控多 GPU 推理。
在以下情況選擇託管 API:
- 您仍在評估模型是否適用。
- 使用情況間歇性發生或難以預測。
- 相較於基礎架構控制權,您更需要可用的存取權。
- 您的團隊不希望自行負責推理營運。
GLM-5.2 的適用範圍,以及人工審查仍然重要的地方
GLM-5.2 是儲存庫分析、多檔案實作、測試修復、效能調查、相依套件工作與工具驅動技術研究的可靠選擇。當任務確實跨越許多相關檔案時,其大型上下文尤其實用。
不要將長上下文與行動權限混為一談。以下事項應保留人工核准步驟:
- 正式環境資料庫遷移
- 驗證與授權變更
- 加密、金鑰管理與安全控制
- 具破壞性的 Shell 指令
- 相依套件授權決策
- 自動提交、合併與部署
- 無法透過版本控制或備份復原的變更
對於這些任務,代理可以進行調查、草擬計畫、準備修補程式並執行安全檢查。涉及界線變更的操作仍應由人員核准。
實用的 GLM-5.2 程式碼代理檢查清單
執行前:
- 建立隔離的分支或工作樹。
- 確認選取的模型與端點。
- 從可存取的上下文中移除密鑰。
- 定義允許的目錄與工具。
- 提供確切的建置與測試指令。
- 說明是否允許新增相依套件。
- 設定回合、時間與成本限制。
接受結果前:
- 閱讀差異內容,而不只是代理的摘要。
- 確認只有在要求時才變更公開 API 與結構描述。
- 風險重大時,獨立執行測試。
- 檢查是否停用規則、吞掉錯誤、使用廣泛型別轉換或跳過測試。
- 記錄未解決的風險與後續工作。
這項設定能將 GLM-5.2 帶入您的終端機或應用程式。這份檢查清單則能將連線轉變為可用的工程流程。
最終結論
使用 GLM-5.2 作為程式碼代理的最佳方式,不是交給它最大可能的上下文後等待。請透過適合您技術堆疊的介面連接它,從儲存庫地圖與範圍明確的任務合約開始,要求在編輯前先提出計畫,並將驗證納入完成定義。
想要成熟的終端機工作流程時,請使用 Claude Code。當 OpenAI 相容代理或自訂應用程式更適合時,請使用 GLM-5.2 API。只有在隱私、控制權或持續使用量足以讓硬體值得投入時,才考慮自行託管,不要提前進行。
使用 GPT Proto時,同一個 API 金鑰與餘額也能存取更廣泛的 AI 模型庫,因此您可以比較 GLM-5.2 與其他程式碼模型,而不必圍繞每個提供者重建整合。