流程是資料，完成由程式核對

規劃、執行、判斷分開

Claude → MCP：尋找既有流程，或檢查網頁、建立新流程。
Kav → 專屬 Chrome：按照 JSON 宣告的步驟執行，在本機核對輸入與結果。
程式驗證：抓資料不經模型；核對流程宣告的條件，回傳具名資料與證據。
需要判斷時 → Claude：把抓好的文字交給 Claude 理解條件與比較候選；一般查詢只需整理回答。

Kev 是選配：只在 pick 文字比對不唯一、需求是單一屬性時選用；沒有 Kev 或無法選定就回報需要協助，交回 Claude。這不是引擎內自動呼叫 Claude 的步驟。對外稱為「流程」，程式和工具中使用 recipe。內建流程在 recipes/，使用者流程另存於本機資料夾。

高鐵為什麼能比較快？

關鍵在於把固定的瀏覽器操作放進同一次本機工具執行，減少 Claude 逐步觀察、規劃與呼叫工具的往返。結果仍來自當次網頁查詢，不是快取上一份答案。

一、Claude 找到流程，只傳這次的變動條件

find_recipe 回傳流程名稱、用途與需要的參數；run_recipe 接收流程名稱和參數。以下是呼叫參數示意：

{
  "name": "thsr-timetable",
  "params": {
    "from": "台中",
    "to": "台北",
    "date": "2026/10/12",
    "time": "15:00"
  }
}

二、Kav 已經知道這個網站要做哪些事

recipes/thsr-timetable.json 宣告網址、四個欄位的標籤與值、要點的「查詢」按鈕，以及如何辨識結果表。日期與站名用參數代入，Claude 不必每次重新從畫面找出這四個欄位。

以下節錄真實流程的欄位宣告；還不是一份完整可執行配方：

{
  "type": "form_submit",
  "fields": [
    {
      "label": "出發站",
      "kind": "select",
      "value": "{from}"
    },
    {
      "label": "到達站",
      "kind": "select",
      "value": "{to}"
    },
    {
      "label": "出發日期",
      "kind": "text",
      "value": "{date}"
    },
    {
      "label": "出發時間",
      "kind": "text",
      "value": "{time}"
    }
  ],
  "submit": {
    "click": "查詢"
  }
}

三、本機程式操作網頁，並從 DOM 取出資料

run_recipe 進入 recipes.execute，再派給 run_form_submit。Kav 透過 Chrome 的控制介面執行：等頁面就緒、辨識欄位、填值並讀回確認、送出、等結果，最後從網頁 DOM 讀出表格。這些固定步驟不需要 Claude 每次決定「下一個點哪裡」。

流程的 result.rows.pattern 辨識車次列、columns 把每格轉成具名欄位，expect_text 要求頁面出現本次查詢日期。找不到、匹配不唯一、欄數不合或缺少日期，都可能回報需要協助，而非直接交出未核對的結果。

四、Claude 收到可直接整理的結果

回傳包含 status、具名的 rows、evidence 截圖位置，以及 kev 用量、total_ms。以下只示意其中一列，不是完整工具回傳：

{
  "出發時間": "15:00",
  "行車時間": "00:59",
  "抵達時間": "15:59",
  "車次": "0648"
}

Claude 拿到這些資料再回答使用者，不必每一步都看截圖找答案；截圖仍保留作為證據與出錯時的檢查依據。

專案中的實作依據

檔案／入口	負責的事
`kfw/mcp_server.py`	`find_recipe`、`run_recipe` 提供 Claude 工具入口。
`recipes/thsr-timetable.json`	宣告欄位、參數、送出按鈕與結果條件。
`kfw/recipes.py`	`execute` 派發、`run_form_submit` 執行、`label_rows` 附欄名。
`kfw/form.py`	共用 DOM 觀察、欄位操作、讀回與結果擷取。

高鐵加速不是 Kev 的功勞。既有高鐵實測都是精確比對，Kev 呼叫 0 次。對照實驗中，Kav 路徑整趟約 4–5 次工具呼叫，逐步操作瀏覽器約 18–33 次；單次 run_recipe 包住多個操作，不代表整趟對話只有一次工具呼叫。

這能解釋加速機制，但不是把各因素分開量測的因果實驗。網站載入、Claude 回答、第一次建立與網站改版後修復仍有成本。查看原始時間與比較限制。

591：抓取與判斷分開量測

2026/10/07，591 租屋列表實驗把「取得資料」與「挑哪一筆」拆開測。本機引擎抓 30 筆文字只花 31 毫秒；Claude 自己操作瀏覽器，三題各花 21–162 秒、45–91 萬輸入 token（含快取累計）。省下重複網頁操作的時間與 token，才是流程的價值。

判斷端，Kev 零錯選，但需要模型的唯一解只答對 4/11；兩條件並列或「最便宜」這類題目會停下。Claude 讀同一份文字全對。因此，抓資料交給本機程式，判斷題把抓好的文字交給 Claude；Kev 保留為單一屬性、離線或零雲端判斷成本的選配。

31 毫秒只量抓取階段，不含整趟載入、判斷與回覆，不能直接換算加速倍率。各組題數與列表版本不同：Claude 讀文字是 26 列版 16 題全對，瀏覽器組另測 3 題全對。

同一實驗，三種量測範圍

591 抓取與判斷實驗範圍
路徑	實測範圍	結果與時間
引擎＋Kev	30 列、18 題；13 題唯一解含 2 題字面比對	排除字面比對後 4/11；5 題該停全停，零錯選。Kev 約 1.1 秒／題。
Claude 讀抓好的文字	26 列版、16 題：11 題唯一解、5 題該停	16/16 全對；整批 24.6 秒，約 1.5 秒／題。
Claude in Chrome	真實頁面、另測 3 題；選擇瀏覽器的回合不計時	3/3 全對；43／162／21 秒，輸入含快取累計 91／61／45 萬 token。

這些 token 是 session usage 的累計輸入，含快取讀寫，不等於同樣數量的新輸入或可直接推算的費用。資料量與題組不同，這是分階段證據，不是完整同題的端到端對照。

實驗只量「選哪一列」，沒有完成端到端點擊。591 卡片的標題文字每列不同，且會開新分頁，現有 pick 路徑無法完成。擷取規則也曾寫得太窄而漏掉 4/30 列；最新程式回傳 rows_skipped，讓 Claude 看得到漏列訊號，仍需要核對規則是否完整。

來源：README「數字怎麼量的」、DECISIONS 2026-10-07 與實驗紀錄 261007-pick-judgment-experiment；原始題組與結果在專案 evals/pick-591/。

描述這個網站的這項動作

流程採宣告式資料，避免每次都讓模型重新探索。既有格式包含填表查詢、讀固定頁面、多站比價與多步驟操作。

既有流程	用途	Kev
`thsr-timetable`	站名、日期、時間 → 車次列表	既有實測 0 次
`bot-fx-rates`	讀牌告匯率並核對掛牌日期	不使用
`tw-shop-compare`	多站搜尋、語意判斷、商品頁核對	既有流程使用；選配能力，不是加速主張

這裡不提供未經試跑的可執行配方。以專案的 recipe schema 與 kav-fastweb skill 為準。

不能證明，就回報需要協助

Kav 會檢查頁面載入、欄位讀回、送出後效果，以及流程宣告的結果條件。表格欄位可宣告欄名，避免把一串文字交給模型猜。

卡住時回傳 needs_help 與原因；完成時回傳 done。這是依宣告條件核對的結果，不保證回答模型永遠不會誤讀，也不保證流程作者寫的擷取規則完整。591 實驗曾因 rows.pattern 寫太窄漏掉 4/30 列；現在回傳 rows_skipped，讓 Claude 看得到同一列表不符 pattern 的列數。

流程不允許代填密碼、付款、下單或繞過驗證。涉及其他網站狀態變更的動作，另需使用者明確要求與流程標示。

Kev 用量怎麼看

每次執行回傳 Kev 呼叫次數、輸入與輸出 token、模型時間加總與程式等待加總。多站並行時，時間加總可能大於整趟牆鐘時間，不能直接相除當成速度貢獻。

從這些工具開始

find_recipe、run_recipe、inspect_page、dry_run、save_recipe、list_recipes、delete_recipe、start_recording、stop_recording、status。

給 AI 的純文字入口量測摘要與限制人類可讀的實測紀錄

本頁依 2026/10/07 專案狀態整理；完整原始碼與格式以 GitHub 上的 kaiwutech-TW/kav-fastwebagent 為準。