【2026 最新】Mercury 3 Agent 驗收怎麼做？六步檢查並行負載、工具失敗與取消

你把模型換成 Mercury 3，畫面一開始還是空白；同時開八件工作，有些很快，有些卻一直重試。這時候，Mercury 3 Agent 驗收該看哪個數字？每秒生成多少 Token，只像廚師切菜的速度；客人等多久，還包括排隊、查庫存、送餐，以及做錯後重做。

這篇寫給第一次替 Agent 做負載驗收的讀者。先用白話弄懂時間線，再照六步建立一份能交給工程夥伴執行的測試單。你不必先會寫整套服務；最後要交出的，是「一次、四次、八次同時工作，哪一檔仍能正確完成與停止」的證據。

先說結論：Mercury 3 Agent 驗收看「交付＋停止」

負載驗收＝同一份工作 × 不同並行數，逐件核對正確交付與停止。並行是同時有幾件工作在進行；不等於模型內部一次算幾個位置，也不等於供應商伺服器的批次大小。你能控制自己的工作入口，未必看得見對方的排程。

截至 2026 年 10 月 20 日，Inception 發布文列出 Mercury 3 的 1,068 tokens/s；這是廠商生成速度數字。目前工具文件則確認 chat completions 支援工具呼叫，包括一次回傳多個呼叫。這兩件事，仍不足以替你的服務決定合適的並行數。

本文提供評估方法，沒有 Mercury 3 的本站 API 負載量測；後面的時間算式都是明確設定的教學例子。若你想先看速度與品質怎麼分開比較，可讀Mercury 2.5 四任務 A/B 教學；這篇進一步處理同時進來的多件工作，以及工具失敗、取消後的生命週期。

一、先看懂路線：模型回話，執行層動手

Agent 是會呼叫模型、執行工具、再把結果交回模型的程式。把它想成餐廳服務員：模型提出「請查訂單」，執行層才去查；查完還要回來組織答案。Agent Harness 原理解釋這個分工，最小 Harness 拆解則帶你看迴圈。

官方流程要求把模型的工具請求與結果，用 tool_call_id 對在一起，再讓模型回覆。工具參數串流到一半，先別執行。等完整呼叫解析與驗證通過，才接受工具工作；錯誤的參數應留下失敗紀錄，不能把「有吐出 JSON」當成做對。

每件工作配一個 task_id，每次模型請求另配 attempt_id，工具沿用呼叫識別碼。如此八件工作交錯回傳，你仍知道哪份結果屬於哪位客人。記錄事件名稱與相對毫秒即可，不把 API Key、真實客戶資料或完整私人對話寫入測試紀錄。

二、Mercury 3 Agent 驗收六步：先固定，再加壓

①「先用假訂單」：把題目與成功標準釘住

怕模型把答案猜對，卻沒真的查工具？建立一個只存在測試端的 lookup_order：輸入 {"order_id":"A01"}，回傳 {"order_id":"A01","status":"packed"}。使用提示詞「請先查詢 A01，再只輸出工具回傳的訂單編號與狀態 JSON」。

通過條件寫在執行層：確實呼叫正確工具、參數符合格式、拿到該次結果、最終 JSON 欄位與值正確，且未超過期限。只靠答案包含 packed 會漏掉多餘文字、錯訂單與憑空回答。先採每件工作恰好一次工具呼叫，重複呼叫另外判失敗，讓第一輪好解釋。

Mock（可控制的替身）固定等待 500 毫秒；這是你設定的條件，不是 Mercury 的性能。再準備等待 2 秒、固定拋錯兩種版本。用同一份訂單集合輪替，兩個模型看到相同題目；別讓模型自己選等待多久或自己決定哪一筆要失敗。

②「配方寫在紙上」：固定路由與請求設定

直連可依Inception Quick Start使用 https://api.inceptionlabs.ai/v1 與模型 mercury-3；走 Vercel AI Gateway 時模型名稱是 inception/mercury-3。兩條路分開成組，避免把代理、供應商與模型一起換掉。

直連實驗可先固定 reasoning_effort="low"、max_completion_tokens=512、stream=true；這是本文的起始配方，512 是自行設定的輸出上限。推理設定文件列出四種等級；要比較等級，另開一輪，只改這個旋鈕。

在已有 Python 環境的新資料夾，可先用 python3 -m venv .venv、source .venv/bin/activate、python -m pip install inceptionai 安裝官方 SDK，再用 python -m pip freeze > requirements.lock.txt 留下版本。金鑰放環境變數 INCEPTION_API_KEY，別貼入程式或分享的日誌。這三個指令是安裝準備，尚未產生測試成績。

把 SDK、程式版本、端點、模型、提示詞、工具 schema、輸出上限、推理等級、逾時與重試規則一起存成設定檔。測試前在帳戶設定費用上限，並限制總工作數；Token 上限按每次請求計，Agent 回合與重試仍會增加用量。

最小迴圈可照這份流程稿接起來：它刻意省略各 SDK 的型別宣告與串流組裝程式，實作時用前面的官方工具文件對照訊息格式，不把以下文字直接當可執行程式。

• 建立 messages，放入題目與工具定義；入列時配好 task_id，取得槽位才送請求。
• 呼叫 client.chat.completions.create(...)；逐塊記錄文字與工具參數，以呼叫索引組裝完整參數，完成解析後才執行。
• 驗證工具名稱及 order_id；只接受白名單的 Mock，不提供 shell、檔案寫入或真實訂單修改。
• 執行工具，把原本 assistant 工具訊息與帶有相符 tool_call_id 的 tool 結果加入 messages。
• 再次呼叫模型取得最終答案；這個練習最多兩次模型請求，超出就判失敗，避免無限迴圈。
• 不論成功、錯誤或取消，都保存終止狀態，於 finally 釋放槽位，再由程式核對結果。

③「先放五支碼表」：首字與工具各自量

每件工作至少標出下列事件。同一個測試程序使用單調時鐘，例如 Node 的 performance.now()；分散在不同機器的事件，應先處理時鐘與傳輸觀測誤差，別直接相減。

• enqueued → admitted：你的應用程式排隊多久。取得工作槽位後才開始模型請求。
• request_start → first_text：這次請求到第一個非空白、可見文字區塊的時間。工具回合可能沒有文字，留空值；另記 tool_call_ready，不要填成零。
• first_text → response_end：可見文字輸出窗口。這含傳輸與緩衝，別命名為純 GPU 生成時間。
• tool_start → tool_end：工具本身的等待。每個呼叫單獨記，包含錯誤與取消。
• enqueued → terminal：完整任務時間。terminal 明確寫成成功、失敗、逾時或取消；成功另記最終答案首字。

官方串流文件說明文字以區塊送出；diffusing=true 另會送出去噪過程中的整段文字。因此本輪保留一般串流，別把尚在修訂的中間字串算成穩定答案，也別把第一個 SSE 封包或推理事件當成使用者已看到回答。

服務端排隊與提示處理若沒有可用的獨立欄位，就記為未知；request_start → first_text 是用戶端觀察的合計，不能全扣給模型。工具可能並行，事件可能重疊，所以總時間直接量首尾；不要把各段 P95 相加。P95 是把一組觀測排序後，約 95% 落在其內的位置，並非每段各挑慢的一次拼起來。

④「同一批訂單換開幾個窗口」：比較 1／4／8

先用並行 1 跑通一次，再給每個檔位相同的 24 件工作；24 是小型練習配額，並非足以推論生產尾端的樣本量。固定工作集合與順序，每輪先把整批放進入口佇列，再開放工作槽位，分別設為 1、4、8：一次最多只允許那麼多件工作在進行，其餘留在應用入口排隊。

這叫固定批量測試：並行 1 要分多批做完，並行 8 可以同時處理更多件。既看整批花多久，也看每件從入列到終止花多久。若要模擬每秒持續湧入的真實流量，要另設到達率測試，不能拿這一小批直接宣布可承受多少使用者。

每輪先固定 Mock 為 500 毫秒，再整輪改成 2 秒。冷啟動與暖機分開標，不把暖機費用或失敗藏掉。交換測試次序，換不同時段重做；保留每一次，而不是從多次結果挑最快的。

第一輪盡量停用應用端與 SDK 可設定的自動重試，並確認 Gateway 的路由、重試與備援策略；不能控制的部分記錄為服務路徑條件。第二輪才加入有上限的重試，逐次留下狀態碼、等待、Token 與費用。遇到 429 按 Retry-After 等待，超出整件工作的期限就結束，不能換個 attempt 就重新起算客人的等待。

⑤「客人說不要了」：工具失敗與取消也要考

先把 A01 固定改成工具錯誤：預期是明確終止，或在事先核准的重試額度內復原；不接受模型把失敗改寫成訂單已查到。若使用 AI SDK，錯誤處理文件區分串流中的 tool-error 與其他 error；只消費文字串流，容易漏掉驗收需要的事件。

再分別於「尚在排隊」「模型回傳中」「工具等待中」觸發取消。以 AbortController 將 signal 傳至支援取消的請求與工具。Node 的 Promise 計時器可用 await setTimeout(delayMs, result, { signal }) 做可取消的 Mock；這裡的 setTimeout 來自 node:timers/promises，不是全域回呼版本。

驗收時檢查：排隊的工作有被移除、正在等候的 Mock 已停止、沒有新工具或下一輪模型請求、工作槽位已釋放、最終狀態是取消。用 try/finally 釋放槽位。關掉畫面或停止讀串流，不足以證明後端工作已停止。正式工具若已寄出信或寫入資料，取消傳輸也不能當作回滾證明，要用該工具的完成紀錄與冪等鍵核對。

⑥「先看交付率，再看速度」：做採用決定

每個檔位保存成功件數／提交件數、失敗類型、取消件數、請求次數、Token、費用與整批起訖。正常題的失敗、逾時要留在分母；刻意取消與故障注入另分測例組，避免把預期的取消當成普通答題失敗。延遲分布明示包含哪些狀態，成功者的 P95 要與失敗率一起報。

小樣本先報每筆原始值、中位數與最大值；若附 P95，交代採用的排序算法與樣本數。24 件中的尾端只有很少觀測，還不足以支持穩定服務保證。整批產能可算「通過的任務件數 ÷ 整批牆鐘秒數」，再看每件合格交付的總費用；重試的帳單也算進去。

先寫自己的通過門檻，例如這批固定題須全部正確、取消後零新增工具動作，再比較等待與成本。這些是你選的驗收規則。若 8 並行讓 429 或尾端等待變多，就退到已通過的 4；若工具等待占大頭，先改善工具或快取，再考慮換模型。

三、走完一張訂單：為什麼模型變快，任務仍可能慢？

用一段人工設定的串行時間線練習：入口排隊 200 毫秒，模型完整工具請求 300 毫秒，工具等待 2,000 毫秒，最後回答 400 毫秒，總共 2,900 毫秒。假設只把兩次模型請求合計從 700 壓到 350，其他不變，總時間變成 2,550 毫秒，約縮短 12%。

這段算式沒有測出 Mercury 3 的加速；它教你辨認可改善的部分。真實請求若有重疊、重試或額外回合，仍回到原始事件量首尾。觀察「模型快一倍」時，先問整件工作中有多少時間確實花在可加速的那一段。

Mercury 3 Agent 驗收 FAQ：八個直接答案

1. 每秒千 Token，就代表第一個字很快嗎？

不一定。開始輸出前的等待與開始後的輸出窗口要各自量；一般串流第一段文字，也不保證已足以給使用者採取行動。

2. 八個任務同時跑，就是模型的 batch size 嗎？

不是同一層指標。前者是你的應用有幾件工作在進行，後者描述服務端如何湊批計算；本測試只直接控制前者。

3. 工具回合沒吐字，首字時間填零嗎？

不要。留空並註明該回合以工具為輸出，再記完整工具請求到達與最終答案首字，避免看起來像立即回答。

4. 模型說「查到了」就算成功嗎？

不算。要對照工具執行、參數、結果與最終 JSON，並核對任務識別碼。

5. 重試後成功，可以刪掉第一次錯誤嗎？

保留。一次任務內可能有多次 attempt，錯誤、等待與費用都屬於同一件工作。

6. 取消後沒有新文字，等於不再扣費嗎？

不能據此判定。先核對應用、工具和請求紀錄，再核對供應商用量；本方法不替服務端計費作保證。

7. 沒有 API Key，今天能做什麼？

先寫固定訂單、Mock 成功／失敗結果、取消時點與通過標準，檢查事件是否可完整記錄；取得已核准的測試帳戶後再填入模型數據。

8. 今天該選 1、4 還是 8？

先選通過正確性、停止與成本門檻的檔位，再比較等待。若只有 1 通過，就先交付 1 的版本並查瓶頸。

給新手的三個重點

• 先把工作做對與停得下來寫成檢查條件，再量秒數。
• 固定題目與工具，只改並行數；用全部嘗試解釋產能與費用。
• 首字、工具等待、完整任務時間各有用途；未知的服務端時間就保持未知。