【2026 最新】大型 Prompt 搬到 Ollama：SOP 拆分、Handoff 與 MTTF 驗收教學

大型 Prompt 搬到 Ollama，最容易犯的錯不是「context 開得不夠大」，而是把一份在 Claude、Codex 等 frontier agent 上運作的 35 KB preprompt 整包貼過去，同時換了模型、runtime、prompt 架構與記憶方式，最後根本不知道是哪一層壞掉。

這篇會把大型 Prompt 搬到 Ollama 拆成可重跑的工程流程：先做三段基線，再把單體 prompt 切成單一目標任務包，把可續跑狀態寫進 checkpoint，最後用預先定義的失憶警報決定繼續、停手或回滾。你不需要相信「短 prompt 一定比較好」，只需要讓每一次改動都能被驗收。

先記住一條公式：搬的是目標、狀態與驗收

可靠遷移＝固定任務 × 單一目標 × 可讀 handoff × 預先定義的 failure signal。

這是全文的主軸。Prompt 只是其中一個輸入；真正要保存的是「這一輪只做什麼、哪些事情已完成、證據在哪裡、下一輪從哪裡開始，以及什麼情況必須停」。只要這五件事仍藏在長對話裡，新 session 就只能靠猜。

本題來自 Patrick McCanna 在 2026 年 9 月發布的個人實驗筆記。他自述在 Ryzen AI MAX+ 395、128 GB 記憶體與約 65K context 的環境，把 35 KB preprompt 搬到未具名的 27B 本機模型後，遇到重複工具呼叫、重讀檔案與重寫完成工作的現象；但原文沒有公開確切模型、量化、版本、任務集、trace 或重複試驗。因此，35 KB、14% 與 65K 都只能視為該作者的單機觀察，不是 Ollama 的通則，更不能證明 prompt 長度就是唯一原因。

大型 Prompt 搬到 Ollama，先做 A0、A1、B

準備一組固定任務，最好取自你已完成、可以重置到相同 Git commit 的真實工作。每題都要有機器可判定的 Done，例如指定測試通過、只允許修改三個檔案、輸出 JSON 符合 schema。官方的 OpenAI eval 指南與 Anthropic 測試指南都強調代表性任務與可重複評分；不要用「agent 說完成了」當答案。

• A0｜參考組：原本 frontier 模型＋原始單體 prompt。它保留舊體驗，但只是端到端參考。
• A1｜遷移基線：本機同一模型、同一量化、同一 runtime 設定＋原始單體 prompt。A0 與 A1 的差，可能來自模型、template、量化、工具 schema 或硬體。
• B｜候選組：維持 A1 的模型與環境，只改成 task packet＋checkpoint＋失憶警報。A1 與 B 的差，才比較接近 prompt 架構效果。

每次執行都保存 model digest、量化、Ollama 與 agent harness 版本、context、sampling 參數、工具清單、任務 commit、timeout 與順序。若還沒先排除 chat template、量化或 runtime 差異，可先照本機 LLM parity 五關測試做最小診斷；如果連同一 GGUF 換 runtime 都不穩，則先看Ollama runtime 遷移 A/B，不要急著重寫 prompt。

步驟二：把單體 preprompt 切成 Single Objective task packet

原作者把這個做法稱為 Single Objective Prompting（SOP），但它不是目前公認的 LLM 標準名詞。實務上可把它理解為：一個 session 只承諾一個可以驗收的目標，其餘規則由穩定契約與工具邊界提供。

# task-packets/T-014.yaml
objective_id: T-014
goal: 將 timeout_ms 的預設值改為 5000，並更新對應測試
inputs:
  - src/config.ts
  - tests/config.test.ts
allowed_actions:
  read: [src/config.ts, tests/config.test.ts]
  edit: [src/config.ts, tests/config.test.ts]
  run: ["npm test -- config.test.ts"]
done_when:
  - 指定測試全數通過
  - 沒有修改清單外檔案
stop_when:
  - 需要新增依賴
  - 測試連續兩次以相同錯誤失敗
handoff_file: state/checkpoint.json

先把 35 KB 原文放進版本控制，不要直接刪。逐條把規則標成四類：永遠有效的產品契約、這一題才需要的任務資訊、可由工具強制的權限、以及沒有評測證據的歷史補丁。第一類留下；第二類移到 task packet；第三類交給 sandbox、tool allowlist 與 allow／ask／deny policy；第四類一次移除一條並跑 eval。整理大型規則庫時，可沿用WHY、OWNER、EXIT、EVAL的生命週期標記。

「只做 Y」通常比堆疊模糊禁令更容易讀，但它只是行為提示，不是安全邊界。真正的權限必須由 harness 強制。OpenAI 的當代模型遷移指南也建議從「仍保留產品契約的最小 prompt」開始，寫清楚結果、成功條件、允許的副作用、證據、輸出格式與停止規則，再用評測補回必要指令；這不是「越短越好」。

步驟三：明確設定 Ollama context，而且真的去驗證

Ollama 的專門 context 文件目前建議 agent 與 coding tool 至少配置 64,000 tokens，同時提醒 context 越大，記憶體需求越高。這是配置起點，不是「64K 一定不失憶」的保證；模型標示的原生上限，也不等於 runtime 實際分配值或整段都能穩定運用。

# 方式一：啟動服務時設定
OLLAMA_CONTEXT_LENGTH=64000 ollama serve

# 模型載入後，另開終端機確認實際分配
ollama ps

請讀 ollama ps 的 CONTEXT 欄，而不是猜預設值。再用同一個模型與 template 測量完整請求；35 KB 是位元組，不是 token 數，英文、中文、工具 schema 與 chat template 都會改變結果。

jq -n --rawfile system ./preprompt.txt '{
  model: "YOUR_MODEL",
  messages: [
    {role:"system", content:$system},
    {role:"user", content:"Reply with READY only."}
  ],
  stream: false,
  options: {num_ctx:64000, num_predict:8}
}' | curl -sS http://localhost:11434/api/chat \
  -H 'Content-Type: application/json' --data-binary @- | \
  jq '{done, done_reason, prompt_eval_count, prompt_eval_cached_count}'

Ollama API usage 文件定義了 prompt_eval_count 等欄位。把它當成「這次 runtime 實際回報的 prompt token」；不要拿 bytes／4 的估算代替。若使用 OpenCode，其官方 provider 設定目前指向 http://localhost:11434/v1，但 client 裡宣告的 context limit 不會自動替 Ollama server 分配記憶體，兩端都要核對。

步驟四：把 session 記憶改成可讀、可驗證的 checkpoint

Ollama 不會替你的 agent 保存「專案現在做到哪裡」。原生 chat API要由 client 傳入 messages；快取與 keep-alive 只減少運算或載入時間，不是持久記憶。長任務應把 canonical state 寫到檔案，完成一個 objective 就產生 handoff，新 session 只讀穩定契約、最新 task packet、最新 checkpoint 與必要檔案切片。這也呼應 Anthropic 公開的長任務 agent harness 範例；它是架構參考，不是保證每個模型都會改善的對照試驗。

{
  "schema_version": 1,
  "run_id": "2026-09-15-T014-B-03",
  "objective_id": "T-014",
  "task_sha256": "...",
  "state_version": 4,
  "completed": ["updated_default", "test_added"],
  "evidence": [{"command":"npm test -- config.test.ts","exit":0}],
  "artifacts": [{"path":"src/config.ts","sha256":"..."}],
  "next_action": "run lint",
  "blocked": []
}

Checkpoint 只寫可驗證事實，不抄整段聊天，也不保存隱藏推理。每次 handoff 後做一次 fresh-agent resume test：清空 session，僅載入上述最小集合，要求新 agent 說出 objective_id、已完成證據與下一個動作，接著執行一個無破壞性的驗證。如果接不起來，就表示 checkpoint 還缺 canonical state。若問題出在壓縮後不斷重讀，可另外用Reacquisition Cost量化重新找資料的成本。

步驟五：把 MTTF 從口號改成可判定事件

原作者把 MTTF 寫成 Mean Tokens To Forget；這不是標準 LLM 指標，而且 NIST 的可靠度工程說明裡，MTTF 指的是 Mean Time To Failure。本文保留它當儀表板暱稱，實際記錄的則是 tokens-to-first-predefined-failure：第一次「事先定義的關鍵失敗」發生時，該請求的 prompt_eval_count 是多少。

• duplicate_tool：前一次成功、環境沒有改變，卻立刻以相同參數再呼叫同一工具；有明確 retry reason 則不算。
• stale_reread：檔案 path＋content hash 都沒變，也沒有新的驗證理由，卻重讀同一片段。
• objective_drift：輸出的 objective_id 與 task packet 不符，或擅自新增任務。
• parse_failure：工具參數解析失敗，依預定 retry 次數仍未恢復。
• high_turn_low_diff：在你自行設定的 rolling window 內，沒有 accepted diff、測試結果或 state_version 前進。窗口大小是專案門檻，不是業界標準。

這些是告警訊號，不是 context exhaustion 的單獨診斷。模型能力、取樣、工具描述、parser bug、timeout 與無效測試都可能產生相同症狀。事件檔至少記錄時間、run_id、objective_id、turn、prompt_eval_count、tool name、標準化參數 hash、檔案 hash、state_version、result 與 retry_reason；append-only 的 events.jsonl 比事後憑印象判讀可靠。

如果某次執行直到固定 token／turn 上限都沒失敗，它是「右設限」，不是在上限那一刻失憶。最簡單的報法是逐次列出 >上限，並同時報告固定預算內的 failure-free rate；不要只把失敗樣本平均後宣稱「MTTF 提升幾倍」。成熟團隊再加中位數、區間或 survival curve。

步驟六：重跑、停手與回滾的完整 SOP

1. 凍結 task set：先用少量 smoke tasks 修 runner，再用短、中、長任務與 edge cases 跑正式集。
2. 固定環境：A1 與 B 使用相同 model digest、量化、context、template、工具、預算與乾淨 repo snapshot。
3. 重複且交錯：同一 task／seed 配對跑 A1、B，隨機交錯順序。範例可先設每組 5 次，但這只是 pilot 選擇，不是統計保證；變異大就增加樣本。
4. 先看硬指標：Done validator、越權事件、固定預算成功率與 fresh-session resume 成功率，再看 token、工具次數、重讀量與延遲。
5. 觸發就停：越權或破壞性操作、objective drift、checkpoint 無法解析、到達預算仍無進展，都立刻保存 trace 並停止 candidate。
6. 回滾：恢復已知可用的 A1 prompt／config 與 repo snapshot；不要讓 B 在背景繼續改檔。
7. 逐步上線：B 先跑 shadow／read-only，再開有限 edit，最後才進入真實寫入。做法可接到Shadow Eval的固定題庫與回歸門檻。

驗收門檻必須在看結果前寫好。例如「B 不增加越權事件、固定預算成功率不低於 A1 的容忍範圍，而且重複工具率下降」；容忍多少取決於失敗成本。若 B 勝出，也只能說整個「拆分＋handoff＋警報」組合在這個任務集有效。要知道是哪一項貢獻，再跑 monolithic／decomposed × no-handoff／handoff 的 2×2 ablation。

最常踩的六個坑

• 把 35 KB 當 35K tokens：tokenizer、語言與 template 都不同，必須讀 runtime counter。
• 只把 num_ctx 調大：工具 schema、history 與輸出也共享窗口；更大的 KV cache 還會吃更多記憶體。
• 把 prompt 文句當權限：「不要刪檔」不等於工具不能刪檔，安全邊界要由 harness 執行。
• Checkpoint 變成第二份肥 prompt：只保留 canonical facts、證據與 next_action，歷史 trace 另存。
• 看見重讀就判定失憶：驗證、錯誤恢復與檔案更新後的重讀可能合理，事件規則要看 hash 與 retry reason。
• 只跑一次就宣布成功：非決定性輸出需要重複執行與不確定性；單次漂亮 demo 不能取代 eval。