GLM-5 把 vibe coding 變工程

我拆 GLM-5 的長程 coding playbook，順手給你一份可直接貼進 agent 的模板。

我用 coding agent 一陣子了，越用越火大。Demo 看起來都很會，改一小段 code 也像模像樣，但一碰到多檔案、反覆修 bug、要追 tool output 的工作，它就開始亂跑。你丟一個半成品想法給它，它永遠說好；你叫它回頭檢查，它又像沒聽見。那種感覺很像把 autocomplete 包裝成 AI，還要你假裝這叫工程。

我真正想要的不是「會寫 code」而已。我想要的是一個能撐住長任務的東西：知道自己可能錯、願意改策略、能把前面幾輪的 evidence 接起來，不要每次都像失憶。後來我去看了 zai-org/GLM-5，才發現它們根本不是在賣一個單點模型，而是在講一套把 vibe coding 拉回 agentic engineering 的方法。

這篇就是我把那套方法拆開。不是宣傳文，不是幫它洗白。我只想看清楚：它到底在解決什麼問題，哪些地方值得抄，哪些地方你自己也能做。

Source anchor：我主要根據 GLM-5 GitHub repo 的 README 與公開說明來拆解。repo 裡有些數字我會照寫，沒提供的我就不亂補。

它不是更會寫 code，是更能撐住任務

"GLM-5.2, our latest flagship model for long-horizon tasks. It marks a substantial leap in long-horizon task capability over its predecessor GLM-5.1 and, for the first time, delivers that capability on a solid 1M-token context."

翻譯一下就是：它們不想只比誰 patch 寫得漂亮，而是比誰能把一個長任務從頭扛到尾。這個差別很大。會寫 code 的模型很多，能在一個亂七八糟的 repo 裡撐住十幾輪工具呼叫、還不把方向帶歪的，少很多。

我自己最常碰到的痛點，就是 agent 一開始很聰明，後面越跑越散。前兩輪還知道自己在修什麼，第三輪看到一個新錯誤就整個被帶走，開始對最新輸出過度反應。這時候你就知道，它不是在做工程，它是在追聲音最大的那個訊號。

GLM-5.2 強調 1M-token context，我不會天真到以為 context 大就等於會做事，但它至少解掉一個很現實的問題：模型不會那麼快把整個任務忘掉。對長任務來說，這不是小事。你要它看整個 codebase、看前面的實驗紀錄、看失敗原因，沒有足夠上下文，後面全是瞎忙。

實操寫法很簡單：你不要拿短 prompt 去測 agent。要拿真的長任務去壓它，像是跨檔案 refactor、帶測試的 bug fix、或是中途需求改一次。看它會不會保留約束、會不會記得前面已經試過什麼、會不會在證據變了之後修正方向。

• 測 agent 時，先測「能不能持續」再測「會不會回答」。
• 讓它跑多輪 tool call，觀察它有沒有失去任務主線。
• 如果它每次都像第一次看到問題，這模型就不適合做長程工程。

我會把這段當成整份 repo 的核心訊號：它不是在講更漂亮的輸出，而是在講更長時間的控制力。這才像工程，不像玩具。

Effort 可調，才像真的在管思考成本

"Advanced Coding with Flexible Effort: Stronger coding capabilities with multiple thinking effort levels to balance performance and latency"

也就是說，它不是逼模型每次都用同一種腦力。這點我很買單，因為現實世界根本沒有一種任務吃同一種成本。修 typo 跟追 production bug，怎麼可能用同一個 thinking budget。

repo 裡有 reasoning_effort 參數，提到 max 和 high 兩種層級，另外也說 enable_thinking=false 可以把思考關掉。這種設計我看了會點頭，因為它承認一件很基本的事：不是每次都要想很久，但該想久的時候也不能偷懶。

我之前最煩的 agent，就是不是太慢就是太衝。太慢的會在簡單問題上拖一堆時間，太衝的則是第一個答案看起來像樣就直接衝出去，後面再補救。兩種都很煩，因為你最後還是得自己收尾。

實操上，我會把 effort 切成工作層級。小修小補、可重現的 bug、單點 patch，用預設或低成本模式。跨模組改動、模糊需求、需要反覆驗證的工作，再升到高 effort。不要反過來，因為那只是在浪費 token 和時間。

如果你做的是產品內建 agent，這個參數最好讓 orchestrator 能控制，不要埋死在 prompt 裡。因為 prompt 不能知道這次是「改一行」還是「查一整串失敗鏈」。系統應該知道，模型不該猜。

• 把 effort 當作工作階層，不要當作炫技設定。
• 先用便宜模式跑，失敗再升級，不要一開始就灌滿成本。
• 記錄每次 effort 與結果，才知道哪種任務值得花腦力。

這種設計我才會叫它像基礎設施。因為基礎設施就是要能管成本，不是只會秀結果。

IndexShare 這種不帥的優化，反而最像真的做過系統

"We propose IndexShare, which reuses the same indexer across every four sparse attention layers, reducing per-token FLOPs by 2.9× at a 1M context length."

翻譯一下就是：它們知道長上下文不是白吃的。你可以把 context 拉很長，但如果每個 token 的成本一起爆掉，那最後還是沒人敢用。這種話很樸素，可是很重要。

我喜歡這個點，因為它不像行銷詞。它比較像工程師坐在那邊算帳後說：好，這個東西要活下來，就得把重複成本壓掉。reusing indexer across layers 這種做法，聽起來不性感，但很像真的碰過部署壓力的人才會做的事。

我以前踩過一個坑：團隊很愛 long context，因為 demo 很爽，結果一上線 latency 爆掉，成本也爆掉。最後大家才發現，能不能看得長是一回事，能不能一直看得長又是另一回事。前者是能力，後者是產品。

實操寫法是這樣：你做 agent 或長上下文系統時，不要只看「能不能塞進去」。你要一起看 token 成本、延遲、記憶體、cache reuse、以及 repeated retrieval 的代價。只要有一個環節沒算，後面就會被現實打臉。

• 長上下文一定要做成本 profile，不要只做能力 demo。
• 能重用的中間結果就重用，別每層都重算。
• 如果你的 agent 要反覆讀同一批資訊，先想怎麼共享狀態。

這段我會直接翻成一句話：長上下文不是炫技，長上下文是帳單。帳單付得起，才叫能力。

Benchmark 不是裝飾，它是在看你會不會把活做完

"On standard coding benchmarks, GLM-5.2 is the strongest open-source model, improving on GLM-5.1 by a wide margin: 81.0 vs. 62.0 on Terminal-Bench 2.1 and 62.1 vs. 58.4 on SWE-bench Pro."

這句話的重點不是「誰最強」這麼膚淺。重點是它們拿來比的，是 terminal-heavy 和 repo-heavy 的任務。也就是說，它們在測的不是漂亮回答，而是能不能真的把軟體工作做完。

我很在意這件事，因為很多模型在小題目上很像神，但一進到真實工程就露餡。你叫它修一個 bug，它先猜答案；你叫它跑測試，它開始自信地亂補；你叫它看 terminal output，它又只抓最後一行。這些都不是工程習慣，這些是幻覺。

repo 還提到它在 Terminal-Bench 2.1 上接近 Claude Opus 4.8，並且在 SWE-bench Pro 上也有明確數字。這些 benchmark 本身有限，我不會把它們當宇宙真理，但它至少告訴我：這個模型不是只會說，它有在對準真實工作流。

實操上，你自己的 agent 測試也要換腦袋。不要只餵單輪 prompt。要餵能失敗、能回頭、能被證據推翻的任務。像是 shell command 失敗、測試壞掉、文件過期、需求中途變更。看它會不會先查證，再動手，而不是先亂改。

如果它在這種情境下還能穩住，那才值得進你的流程。否則 benchmark 再漂亮，也只是簡報上的裝飾。

GLM-5.1 的定位，其實是在教模型怎麼當工程師

"GLM-5.1, our next-generation flagship model for agentic engineering, with significantly stronger coding capabilities than its predecessor."

這句話很直白：它們把「寫 code」跟「做 agentic engineering」分開看了。這個分法我覺得對。因為會寫 code 不代表會做工程，會補 patch 也不代表會管理一個多輪任務。

README 裡面提到，GLM-5.1 能處理模糊問題、拆解複雜任務、做實驗、讀結果、找 blocker，還能在數百輪、數千次 tool calls 裡維持最佳化。這才是我認為 agent 該有的樣子：不是只產生答案，而是能夠維持一個有節奏的工作流程。

我之前最常看到的失敗模式，就是模型卡在第一個假設裡出不來。明明 evidence 已經變了，它還是死守原本那條路，像是怕承認自己錯。工程不是這樣。工程是你要會改，而且要知道什麼時候該改。

實操寫法是把「修正」變成流程的一部分。不要只讓模型提案，還要逼它檢查結果、比較前後差異、寫下 blocker，再決定下一步。這樣它才不會把每一輪都當成獨立事件。

我會把這個當成 GLM-5 系列最值得抄的地方：不是更會答，而是更會工作。這差很多。

Scale 不是重點，能不能持續迭代才是

"Compared to GLM-4.5, GLM-5 scales from 355B parameters (32B active) to 744B parameters (40B active), and increases pre-training data from 23T to 28.5T tokens."

翻譯一下就是：它們把模型做大，也把資料做多，但不是單純堆數字，而是把它放進一個更像系統工程的敘事裡。老實說，我平常看到這種 scale 數字會先翻白眼，因為很多團隊只會拿大數字嚇人，卻不談怎麼把它用在真實工作上。

這份 repo 比較不一樣的地方，是它把 scale 跟 post-training、RL infrastructure、長任務能力綁在一起。它還提到 slime 這個 asynchronous RL infrastructure，意思很清楚：如果訓練迭代太慢，模型就算能學，也學不快。

我自己踩過的坑也很像這樣。不是模型不行，是迭代成本太高。每多跑一輪都要等很久、花很多錢、還很難比較結果，最後團隊就懶得試了。然後大家再一起抱怨模型怎麼沒進步。不是沒進步，是你根本沒讓它有足夠次數進步。

實操上，你如果在做自己的模型調整或 agent 改版，請把 iteration cost 當成第一級指標。不是只有 quality。因為一個很難反覆試的流程，通常最後都不會變好。你得讓自己付得起更多輪比較、更多次修正、更多次失敗。

這就是我從 GLM-5 讀到的真正訊號：大不是重點，能不能持續改進才是。

可抄的模板

# GLM-5-style long-horizon coding agent template（可直接貼進你的 agent / orchestrator / system prompt）

你是一個工程 agent，負責處理多步驟、長時間、會失敗的軟體任務。
你的目標不是講得像懂了。
你的目標是把工作做完，而且在 evidence 變動時願意修正。

## 核心原則
1. 持續保留任務主線，不要每輪都重開一個新故事。
2. 把 tool output 當 evidence，不要當裝飾。
3. 如果目前假設被推翻，先改 plan，再繼續做。
4. 優先做最小可驗證變更，不要一開始就大改。
5. 每一輪都記錄 blocker、假設、下一步。
6. 不要重複做同一個失敗動作，除非你能說清楚為什麼這次不一樣。

## Effort 控制
- `reasoning_effort = max`：用在 baseline 工作、簡單修補、可重現的問題。
- `reasoning_effort = high`：用在模糊需求、跨檔案 refactor、複雜 debug、長鏈條驗證。
- `enable_thinking = false`：只用在你要低延遲、低風險、可預期輸出的情境。

## 每輪工作流程
1. 用一句話重述目標。
2. 寫下目前假設。
3. 選最小下一步。
4. 執行 tool / command / patch。
5. 讀結果。
6. 如果 evidence 變了，更新 plan。
7. 寫下 blocker 或下一步。

## 回傳格式
- Goal
- Current hypothesis
- Actions taken
- Evidence observed
- Updated plan
- Blockers
- Next step

## 可直接用的 system instruction
你可以檢查檔案、跑命令、比較輸出、修正計畫。
不要在 evidence 很弱時裝作很有把握。
不要優化成只會回一個漂亮答案。
你要優化的是：在長任務裡正確完成工程工作。

## 可直接用的 controller 設定
- reasoning_effort: max | high
- enable_thinking: true | false
- max_iterations: 視任務而定
- stop_condition: verified fix / verified explanation / explicit blocker

這段你可以直接拿去改成自己的 agent prompt，或拆成 orchestrator 規則。重點不是文筆，是行為。只要你能把「重述目標、記錄假設、讀 evidence、更新 plan」這幾件事強制化，agent 就不會那麼容易開始胡扯。

我也建議你不要只把它放在 prompt 裡而已。prompt 很脆，controller 才是把行為鎖住的地方。你要的是流程，不是祈禱。GLM-5 這份 repo 最有價值的地方，就是它讓我重新把 agent 想成工程系統，而不是聊天機器人。

原始來源：https://github.com/zai-org/GLM-5。文中拆解與模板是我根據公開 README 與 repo 結構整理出來的衍生內容，不是官方摘要。