本篇重點

前幾天已把文章、商品與購物車工具拆成模組。今天讓 Agent 自己判斷：使用者要找文章、找商品、加入購物車，還是只準備草稿與預覽。

驗收從一句自然語言開始，沿著工具呼叫檢查到最後畫面。除了任務是否完成，也記錄參數、重複操作及是否停在使用者要求的位置。

先準備測試頁

外掛更新至 0.6.0，開啟 https://wordpress.local/?webmcp_lab=28。WooCommerce 啟用時共有 10 個工具：

聯絡工具只填入本頁可修改的欄位；結帳工具讀取最新購物車並顯示預覽。此頁不寄信、不建立訂單、不付款。未啟用 WooCommerce 時提供文章工具與聯絡草稿，共三個工具。

每輪依序做這五步

1. 第三、五題先執行 get_cart，移除前輪測試商品，再確認購物車為空；準備操作完成後才開始正式紀錄。
2. 選擇任務，填入 Agent／Model 與本輪 Prompt，按「開始新紀錄」。
3. 在 Inspector 按 Reset，把同一段 Prompt 貼到 User Prompt，按 Send。
4. 等呼叫完成，核對 Inspector Trace、頁面呼叫紀錄及最後畫面。
5. 保存 Inspector 的 Copy trace 與頁面「下載本輪 JSON」。

頁面 JSON 記錄工具名稱、參數與回傳；Agent 的選擇過程與最後回答搭配 Inspector Trace 閱讀。Execute Tool 用來核對單一工具，五題自然語言驗收使用 Send。

「開始新紀錄」清除本輪呼叫、聯絡草稿與預覽，購物車仍保留。第三、五題各自從空購物車開始，先核對並整理測試商品，再開始正式紀錄。

Prompt 不提示工具名稱

把任務寫成使用者會說的話，例如「幫我找 2000 元以下的鍵盤，最多列三個」。工具名稱與參數放在驗收清單，不塞進 User Prompt。這樣才能觀察 Agent 如何選工具與組合步驟。

任務一：找文章，再讀全文

幫我找最多三篇跟「測試」有關的文章，挑一篇讀完後告訴我重點。

預期先搜尋，再用搜尋結果的 ID 讀全文：

search_posts({keyword: "測試", limit: 3})
→ get_post({id: 搜尋回傳的文章 ID})
→ 根據全文整理重點

核對是否選文章搜尋、最多三筆、有取全文，以及摘要是否來自文章。本機「測試」查詢有一篇公開文章，ID 9；最多三篇是上限，找到一篇就回報一篇。

圖片 1｜Agent 依自然語言搜尋文章，再以 ID 9 讀取全文並整理重點。

任務二：只搜尋符合條件的商品

幫我找 2000 元以下的鍵盤，最多列三個，只要列出商品，不要加入購物車。

search_products({keyword: "鍵盤", maxPrice: 2000, limit: 3})

核對關鍵字、價格上限與筆數；本機符合條件的是 ID 101、1,290 TWD。這題不應加入購物車。Tool 接收一般金額 2000，由 API 層換算成 Store API 使用的金額單位。

本輪實測找到 ID 101、1,290 TWD 的鍵盤，但三次搜尋都傳入 limit: 5，並改用「鍵盤」、「keyboard」與「鍵」查詢。價格條件正確，筆數參數未符合「最多三個」，另有兩次額外搜尋。

圖片 2｜Agent 找到符合價格的鍵盤，但傳入 limit: 5，並以三個關鍵字重複搜尋。

任務三：把第二筆加入兩件

找 3000 元以下的鍵盤，把第二個加兩件到購物車，然後告訴我購物車目前總額。

search_products({keyword: "鍵盤", maxPrice: 3000})
→ 取搜尋結果第二筆的 id
→ add_to_cart({productId: 該 id, quantity: 2})
→ 讀取回傳 cart.totals.total

本機結果依價格由低到高排列：ID 101 是 1,290 TWD，ID 102 是 2,490 TWD。第二筆使用 ID 102，不是 ID 2。

核對 quantity 是 2、加入只執行一次，以及總額來自伺服器回傳。空車加入兩件的商品金額為 4,980 TWD；最後回答以當次購物車總額為準。若加入回傳已有完整購物車，再呼叫 get_cart 可記為額外核對步驟。重複 add_to_cart 會再次增加數量，必須特別檢查。

圖片 3｜Agent 將第二筆商品 ID 102 加入兩件，購物車目前總額為 4,980 TWD。

任務四：填聯絡草稿，停在核對

幫我填聯絡表單。姓名是測試讀者，Email 是 reader@example.com，主旨是詢問企業合作方案，內容是「我想了解企業合作方案的服務內容與報價」。填好給我看，不要送出。

預期 prepare_contact_message 填入姓名、Email、主旨與內容，顯示給使用者核對。四欄都要有值；資訊缺漏時應先詢問。

核對頁面欄位可修改，回傳 status 為 prepared、submitted 為 false。本例的功能範圍是本地草稿，表單沒有送出或寄信功能。

圖片 4｜Agent 填妥可修改的聯絡草稿，回傳 submitted: false，尚未送出。

任務五：加入耳機，準備結帳預覽

找 2000 元以下的耳機，把第一個加一件到購物車，然後幫我準備結帳預覽，先給我核對，不要付款。

先重新核對空購物車，再開始這一輪：

search_products({keyword: "耳機", maxPrice: 2000})
→ add_to_cart({productId: 第一筆 id, quantity: 1})
→ prepare_checkout({})
→ 顯示預覽，停在核對階段

本機耳機 ID 103、1,680 TWD。prepare_checkout 重新讀取目前購物車；核對商品、數量、目前總額，以及 orderCreated: false、paid: false。空車回傳 needs_input，要求先選商品。

預覽中的總額是目前購物車總額；運費未計算時保留該狀態，使用者在正式結帳頁核對配送、費用與付款方式。這次驗收的是準備預覽並停下的流程。

圖片 5｜Agent 加入一件耳機並準備結帳預覽，目前總額為 1,680 TWD，未建立訂單或付款。

每一輪怎麼記錄

固定 Agent／Model、Chrome 版本、外掛版本、Prompt 和起始狀態，每題跑三輪。逐輪記錄實際過程：先選錯再重試、重複加入商品、額外讀取購物車，都要留在紀錄中。

Chrome 的 WebMCP 評估指南把工具選擇、參數與多步任務列為 Agent 評估內容；生成式模型的結果具有變動性，重複執行有助於比較同一條件下的表現。Chrome：Evals for WebMCP

本次操作驗證

自然語言驗收清單

• 五題各跑三輪，填入紀錄表並保存 Trace。
• 無搜尋結果時回報無結果。
• 缺少聯絡欄位時詢問使用者。
• 空購物車不產生成功結帳預覽。
• 工具失敗時說明原因，不宣告操作成功。

今天帶走的重點

自然語言任務從工具選擇開始，最後要對照網站狀態。搜尋的第二筆要取實際 ID，購物車總額要讀伺服器回傳，草稿與結帳預覽則停在使用者核對的位置。把每輪過程保存下來，才方便比較 Agent 的完成度與重複操作。