262k 寫在設定裡。33k 才是現場
前幾天看到 r/openclaw 有人問一個蠻典型的問題。他用 Qwen3.8 27B、本地 Docker，OpenClaw 裡 contextWindow 設 262144，模型定義也寫支援 262k。照規格看起來都對，但實際跑到大概 33k 左右，agent 就開始一直要 /compact 或 /new。ollama ps 看起來也顯示 runtime 只有 33k。
我的 take 是，這種問題在個人玩家那邊是 debugging，在 enterprise 場景就是 trust issue。
PM 或 IT buyer 通常不會在意是哪一層沒有吃到設定。他們看到的是，sales deck 說 262k，admin console 也像是 262k，結果營運現場只有 33k。落差一出現，後面所有 adoption conversation 都會變難。你再解釋 provider config、model manifest、runtime env var，對方心裡想的通常是，這套東西到底誰 owns？
AI agent 產品很麻煩，因為它是 config、provider、runtime 三層疊在一起。像這個例子，留言有人提到要看 Ollama 端是否用 256k 建模，或是 OLLAMA_CONTEXT_LENGTH=262144 有沒有設到。技術上合理，但從產品角度看，合理和可營運中間差很多。
可營運的意思是，系統要能直接告訴我現在 effective context 是多少，別讓 user 自己猜。最好還能分清楚 expected、configured、runtime 三個值。只要三個不 aligned，就應該有 warning，甚至 block rollout，不能等 agent 工作到一半才突然說該 compact 了。
我以前看 enterprise pilot，最常卡住的其實也不一定是模型能力。更多時候，是沒有人能回答責任邊界。PM 說 infra，infra 說 provider，vendor 說 local runtime 不在控制範圍。最後 business owner 只記得一件事，demo 那天它壞了。
所以我會把 context window mismatch 看成 product observability 的一部分。企業會想要 cost control、data residency、compliance，runtime 也會越來越常回到客戶自己手上。ownership model 就要更清楚。誰保證 config 生效？誰顯示 effective limit？誰在 mismatch 的時候喊停？
規格宣稱可以讓人願意試用，實際可營運才會讓人願意上線。262144 和 33k 的差距，看起來只是 token 數字，對 enterprise buyer 來說其實是信任感的 gap。產品自己看不見這個 gap，客戶一定會先看見。
作者：Vivian L