【2026 最新】Kapso 教學：用小型 CSV 看懂經驗銀行，六步驗收是否真的進步

你讓 Agent 試了十種資料模型，它記下一句「這招有效」。換一份 CSV，它真的會少走冤枉路，還是只是記住上一張考卷？這篇 Kapso 教學，要帶你從一份小型合成資料出發，把「留下經驗」拆成能追來源、能做對照、也能撤回的實驗。

前半寫給第一次接觸實驗型 Agent 的讀者；操作段需要已有 Python 3.10 以上、Git，以及可用的 Coding Agent CLI 帳戶。你會先準備假資料與基準，再看實驗樹和 lesson 卡，最後安排「空銀行／載入銀行」的同條件驗收。本文依 2026 年 11 月 15 日的官方文件與 leeroo-kapso 0.9.3 整理；資料準備與基準可在 CPU 上練習，Kapso 的付費 build、learn 與銀行收益則不預填成績。

先說結論：可重用經驗＝做過的事＋適用邊界＋新資料驗收

把 Kapso 想成一間會保留實驗簿的資料工作室。模型負責想辦法，程式負責動手，評分器負責量成績；經驗銀行保存「哪個方法，在什麼情況下，有什麼證據」。銀行像食譜集，可信度像每張食譜旁的試作紀錄。食譜很多，和下一道菜做得更好，是兩個問題。

• 先固定資料、評分規則與預算，再讓 Agent 搜尋方法。
• 把搜尋時會反覆看見的驗證成績，與最後才開封的驗收資料分開。
• 比較同一個新任務、同一個起始程式、同樣預算，只改有沒有載入同一版經驗。

一、Kapso 教學先認五個零件

① Brief：「一張實驗委託單」。寫目標、怎麼量、基準、規則與預算。② Harness：「工作室的操作規程」。帶入資料建模等領域的知識與檢查。想先補地圖，可讀 Agent Harness 白話入門。

③ Build：「一棵實驗樹」。每個候選節點記下假說、程式分支、量測與花費，後續嘗試可從既有候選延伸。④ Evaluation／Verifier：「尺與驗貨員」。評分程式算分，驗證角色檢查規則與證據，Judge 再判定結果；不要把這些工作合稱為「AI 說過關」。⑤ Lesson bank：「有收據的食譜集」。learn() 從完成的 campaign（整次實驗活動）整理卡片，下一個 build 再明確載入。

依 官方 lesson 文件，卡片分為 insight（機制或觀察）與 procedure（含程式的做法），帶有 credence（可信度評分）、scope（範圍）及證據。credence 應連同評分理由和適用條件一起讀，別把它當成下一筆資料成功的機率。這裡教的是改進工作方法的路徑，不用先學會訓練語言模型。

二、Kapso 教學上手：先做一個小到看得懂的 CSV 實驗

第 1 步：「裝到哪個 Kapso？」先核對套件與依賴

用獨立虛擬環境，避開同名套件。官方安裝頁列出 Python、Node.js、Git 與已登入的 Codex／Claude Code CLI；先依該頁完成帳戶設定，再執行以下指令。Python 套件本身不等於模型服務，CLI 的可用模型與額度也要逐一確認。

python3 -m venv .venv
source .venv/bin/activate
python -m pip install leeroo-kapso==0.9.3 numpy pandas scikit-learn
python -m pip show leeroo-kapso
kapso doctor build

以上啟用指令適用 macOS／Linux 終端機。官方明列 PyPI 上單叫 kapso 的套件是另一個 WhatsApp 工具；這輪使用 leeroo-kapso。先看 doctor 的必要項目是否全為 [OK ]。純 doctor 不呼叫模型；加上 --models 才會發送少量真實模型請求。

先把套件清單存成 python -m pip freeze > requirements-lock.txt，另外保存 CLI 版本、設定與模型 ID。不要直接把金鑰寫進 Brief。這次只用 CSV 與本地銀行；Leeroopedia 或外部索引若被載入，要在兩組都一致，並把它們另外計費。

第 2 步：「哪張表是考卷？」先把資料分三層

先用官方流失預測範例，縮小筆數練流程。churn 是顧客是否流失；每列是一位虛構顧客，模型交出流失機率。官方範例原本產生 10,000 列訓練資料與 3,000 列 holdout。下面把練習調為 1,200／400 列，原範例公布的分數不再是這份小資料的基準。

git clone --branch v0.9.3 --depth 1 https://github.com/Leeroo-AI/kapso.git kapso-src
cp -R kapso-src/examples/churn-first-build learn-lab
cp -R kapso-src/examples/churn-first-build target-lab
cd learn-lab
python -c "import generate as g; g.SEED=20261115; g.N_TRAIN=1200; g.N_HOLDOUT=400; g.main()"
python baseline.py --repeats 1 --bootstrap 200

打開 data/train.csv，有 churned 答案；data/holdout.csv 只有特徵；答案放在 private/holdout_labels.csv。MANIFEST.json 留下 seed、筆數與檔案指紋，baseline.json 保存這次基準。不要讓評分資料夾帶著先前執行留下的 result.json 啟動新 build。

本篇把這 400 列稱為搜尋驗證資料：即使答案不直接拿去訓練，只要 Agent 一再依它的分數選方法，這份成績就參與了選擇。真正的最終驗收資料另放在 Agent 不能存取的評分環境，等候選與銀行凍結後才使用。scikit-learn 的資料洩漏說明也要求測試資料與模型選擇分開。換句話說，練習題的高分，要再過一張新考卷。

第 3 步：「花到哪裡停？」寫規則，再啟動 build

把 Brief 改成自己的小實驗委託單。將 kapso-brief.md 改為下面內容；Baseline 欄換成剛才 baseline.json 的實際值。0.85 是本練習選定的目標，達不到也保留失敗紀錄。

Objective    Improve churn prediction on the synthetic CSV.
Measured by  kapso_evaluation/evaluate.py, ROC AUC, higher is better.
Baseline     Replace this line with the measured baseline.json result.
Target       0.85
Rules
  - Keep predict.py writing id,churn_probability for every holdout id.
  - Never modify the evaluator or fit on holdout rows or labels.
  - Fit imputation, scaling and feature selection on training data only.
  - Do not read the generator, private labels or unrelated host files.
  - Keep this evaluator version fixed; stop if a protocol change is needed.
Budget       minutes=45 experiments=2 usd=5
Harness      predictive-modelling

kapso build --brief kapso-brief.md --evaluation evaluation --data data --repo repo --output campaign-learn --detach
kapso watch campaign-learn --follow
kapso trace campaign-learn --json > trace-learn.json

ROC AUC（ROC 曲線下的面積）衡量正例能否排在負例前面，不是分類正確百分比。這組 45 分鐘、2 次實驗、5 美元是練習的搜尋上限設定，不是完成保證，也不是全部支出的硬封頂。預算文件明列未回報的中止 session 與獨立 gate 花費可能不在帳內；後續 learn 也應另外估算。先檢查帳戶額度與工具權限，再啟動付費工作。

把這份範例放進專用、無私人檔案的運算環境。寫在 Rules 裡的禁止事項是驗收規則，不會自動變成作業系統存取限制。尤其範例評分器透過絕對路徑讀取答案；同一使用者能執行任意程式時，另一個資料夾不能當成隔離。最終答案要由獨立評分端保管，評分端執行候選程式時也要隔離並禁止候選讀取答案。

三、從實驗樹追到 lesson：每句「有效」都要有收據

第 4 步：「它怎麼贏的？」沿分支讀三份證據

先看實際交付的候選，再看最好看的數字。執行 kapso trace campaign-learn，找到 delivered 的 branch／commit；再用 kapso trace campaign-learn --branch 分支名稱 追到該次假說、evaluation、verification 與 judge。若 delivered 為空，先處理原因，不把「嘗試過」當成「已成功」。

例如某個候選提出「把支援工單數做門檻特徵」。你要找的是：它改了哪段程式、是否只從訓練資料建立前處理、評分用了多少列、Verifier 是否找到讀取答案或改尺的證據。這是讀取紀錄的示範問題，不是本文已產生的候選結果。

官方完整性文件明說，檔案指紋檢查針對最終候選樹，不能證明評分真的執行，也不能攔住所有暫改再還原或偽造輸出。需要更強的驗收時，由你控制的程序對固定 commit 執行評分；外部評分 callback的數字預設與內部搜尋分數分開。第一次練習可先在所有候選凍結後，外部只評一次，避免一面看終考一面改。

第 5 步：「哪一條值得記？」學完後核對卡片邊界

完成且有可用證據的 campaign，再交給學習流程。先確認 kapso doctor learn 的需求，為學習階段單獨保留額度，執行 kapso learn campaign-learn，再用 kapso experience list 看銀行位置與 head（Git 版本）。先用專用系統帳戶做練習，避免把測試卡片混進日常銀行；這也方便完整備份與回復。

每張卡至少問四句：規則是什麼？哪一個 run 支持？在哪些資料條件下適用？什麼證據會推翻？「這類帶非線性關係的表格可試門檻特徵」仍需限定條件；「C000123 的答案是流失」則是記住一列資料。候選卡本身也可能被供應給下一次 build，別把能被讀取和已充分驗證畫上等號。

這裡有一個值得特別核對的地方：官方介紹描述更新後的 lesson 會做 A/B；但 Development mode 文件把 A/B 列為操作者另行執行的檢查，0.9.3 設定的 learning.ab.required 為 false。因此不要因為 learn 完成，就宣稱這次已經跑過同條件對照。去找實際 arms、紀錄與 verdict；not-run 就照實記為未執行。

四、經驗是否可轉移？讓新 CSV 的兩組只差一本食譜

第 6 步：「換資料還有用嗎？」凍結銀行，另開兩次 build

先凍結，再比較。回到 target-lab，以另一個 seed 產生同樣大小的新資料，重跑自己的基準；複製前述 Brief，填入新基準，維持 Harness、目標與預算一致。

cd ../target-lab
python -c "import generate as g; g.SEED=20261116; g.N_TRAIN=1200; g.N_HOLDOUT=400; g.main()"
python baseline.py --repeats 1 --bootstrap 200
# 先修改 kapso-brief.md，再執行下面兩個 build。
kapso build --brief kapso-brief.md --evaluation evaluation --data data --repo repo --output campaign-empty --detach
kapso watch campaign-empty --follow
kapso build --experience mine --brief kapso-brief.md --evaluation evaluation --data data --repo repo --output campaign-bank --detach
kapso watch campaign-bank --follow

空組 Brief 不填 Experience；銀行組只多 --experience mine。兩次之間先不再 learn 或更新銀行，記下銀行 head，並保存兩份 trace。Experience 文件說明每個 campaign 會固定載入的來源與版本；檢查 .kapso/serving/serving-record.yaml 與 serving-pull.jsonl，確認空組實際未獲供應銀行，銀行組實際讀了哪些卡。載入與採用，也要分開記。

接著凍結兩組交付 commit。在獨立評分端用範例的資料生成函式準備另一批未公開的特徵與答案，只把特徵交給隔離中的候選程式；保留同一份 target 訓練資料與 predict.py --data … --out … 介面，分別產出機率，再由外部評分程式依 ID 合併答案、檢查缺列與重複、計算同一指標。最終分數不回灌選模型或修改卡片。若看完終考還要修改，下一輪另準備新考卷。

上述最後一段是驗收規格，並非 Kapso 自動替你架好的隔離服務。只有換 seed，回答的是同一合成機制換樣本能否維持收益；跨產業、跨資料生成方式，還需要新的任務。生成程式與種子也留在評分端，避免讓候選走重建答案的捷徑。

同條件至少保存：兩組候選 commit、資料與評分器雜湊、模型與 CLI 版本、銀行 head、實際讀卡、搜尋分數、最終分數、耗時及成本。輪流安排先跑哪組；若工具提供隨機種子就記下，但不要把相同 seed 當成遠端模型必然逐字相同。先用一對跑通記錄，再預先決定多個新任務做成對比較。

總花費＝全部搜尋＋失敗重跑＋驗證＋學習＋外部服務。Trace 文件特別標示：部分主機的成本回報不完整，Codex session 可能沒有美元數字。帳上空白寫「未計價」，別填零。銀行建立成本另列；要談攤提，就除以後續實際使用次數，並同時呈現尚未攤提的總額。

若品質變差、收益落在波動內或花費上升，保留這個結果。撤回時，新 build 省略 Experience；要重現某版則用已保存的銀行副本或固定 Git ref，另開輸出目錄。不要直接編輯進行中 campaign 的 checkpoint。讀 WikiTrace 記憶退步評估，可進一步學會把救回的題目和新增的退步分開。

常見問題：八個先講答案的判斷

1. 裝好套件就能免費跑完整實驗嗎？

不能這樣估。套件、模型 CLI 額度、外部知識服務與運算是不同項；先完成 doctor 與帳戶額度檢查，再執行 build。

2. holdout.csv 這個檔名，就代表獨立終考嗎？

不代表。若它的分數反覆影響搜尋，就把它視為搜尋驗證；最終驗收另外保留。

3. Verifier 通過，就證明完全沒有洩漏嗎？

不能推出這個結論。官方明列最終樹檢查的限制；分開保存答案、隔離執行與外部重新評分，才能補上這些具體邊界。

4. credence 0.9 可以讀成九成一定有效嗎？

不可以直接換算。先讀卡片評分理由、證據與適用條件，再對照你這次的資料。

5. learn 成功就等於 A/B 成功嗎？

不等於。核對實際兩組執行紀錄與 verdict；未執行和沒有量到收益都照實保存。

6. 空銀行就是把同一個 campaign resume 一次嗎？

不是這個對照。resume 保留原先經驗與搜尋狀態；本篇兩組都從同一起始 repo 開新的輸出目錄。

7. 一對新 CSV 贏了，就能說銀行普遍有用嗎？

還不夠。一對先證明記錄流程可運作；擴充到預先選定的新任務，保留退步與花費，才逐步縮小結論的不確定性。

8. 完全新手今天做到哪裡就有收穫？

先產出假 CSV、自己的 baseline.json，並指出搜尋驗證與最終驗收各放哪裡。能說清楚這三件事，再花額度跑第一棵實驗樹。

給新手的三個重點

第一，先有自己的基準，再談進步。第二，每張經驗卡同時讀規則、邊界與收據。第三，同一份新任務只改銀行，品質與總成本一起算。若你想把這些檢查接成自己的迴圈，接著讀 最小 Agent Harness 實作；若想比較另一種累積方法的工具，可讀 AgentRun 的任務與工作流學習，注意兩者產物和驗收單位不同。