工具與 MCP

僅會回答的代理程式會把工作留給你。本頁說明平台如何讓代理程式執行動作：當呼叫工具時，回合內發生了什麼事、什麼機制防止對話崩潰，以及如何連接你自己的系統。

工具迴圈

一個回合並非單一的模型呼叫。模型可能會回答，也可能要求呼叫工具；如果它呼叫了工具，結果會被附加到對話中，模型會帶著該結果再次運行。它接著可能呼叫另一個工具。迴圈會持續進行，直到模型產生回答，或達到迭代限制為止。

這個限制很重要：若沒有它，一個不斷呼叫工具的模型（這確實是常見的故障）會無限運行，消耗 token，並讓客戶等待永遠不會到來的回覆。

迴圈所做的並非將它沿途累積的一切寫成給客戶的回答。一旦工具完成，請求會被重新建構為乾淨狀態——包含代理程式的指示、簡短摘要、本回合發現的事實以及問題——然後從中生成回覆。其原因是經過衡量的，這正是 Why agents get worse as context grows 的主題。

在模型運行前決定使用哪個工具

上述迴圈假設模型會要求正確的工具。通常它不會——而原因值得精確說明，因為這不是知識問題。

人們不會以軟體希望的方式來表述請求。"Any others like that?" 沒有命名任何工具、主題或數量；那些是兩則訊息前的事。模型接到這樣的內容時，必須解析「像那樣」指的是什麼、決定是否涉及工具、找出是哪一個、填入其參數，並寫出一個好的回答——一個樣本中要完成五項工作。通常被丟棄的是工具呼叫，而客戶得到的是一段文字，而非產品列表。

這涵蓋了多種類型的請求。"Any others like that?" 希望顯示項目；"show me the distribution of books by reading level" 希望計算並繪製目錄。若任由模型自行處理第二種情況，它會敘述工作過程而非執行——我們看過一個模型說了六次「讓我查詢資料庫」，然後將 SQL 語句列印到回覆中，這是工具的輸入內容，讀者絕對不應該看到。

因此，對於那些明顯隱含工具使用的請求，平台會先採取一步。一次小型、廉價的呼叫會閱讀對話並僅返回事實——正在要求什麼，以及數量為何。它只看到對話，看不到其他內容：不是代理程式的指示，也不是檢索到的材料，因此它不會偏離到回答問題上。然後：

• 平台撰寫指示，使用工具實際回應的措辭，並補回缺失的上下文；
• 該回合僅顯示該單一工具，因此沒有其他選項可選。

前者是關鍵，且很容易出錯。讓模型重寫自己的請求並未改變我們能測量到的任何結果——只是用不同的詞彙做同樣的猜測。由平台根據工具自身的定義來編寫該句子，將一個自託管的 35B 模型在相同請求上的表現從 16% 提升到 70%。到達工具的措辭是軟體可以計算的內容，因此由軟體來計算——這與將圖表資料和卡片內容保留在伺服器上而非模型手中的推理過程相同。

平台刻意不做的第三件事是：在協議層級強制呼叫。該選項存在，且確實進一步提高了數量。但它也會在自託管伺服器上（將其作為解碼約束實現時）將模型推入重複迴圈——根據我們的測量，大約每四回合中就有一回合，其中一回合花費兩分鐘發出相同的片段。永遠無法到來的回覆，比用文字回答更糟。

有兩個後果值得了解。即使編寫的指示是英文，回覆仍會以客戶的語言返回——這也由平台固定，不交由模型去注意。當一個回合本應移交某物卻移交了文字時，平台會注意到並再次要求，指出跳過的步驟並提供誠實的退出方式（「如果沒有合適的材料，請說」）——因為沒有退路的模型會發明一個。描述八個產品卻一個都沒顯示的代理程式，在等待的人看來，與忽略問題的代理程式完全一樣。

該檢查關注的是回傳的內容，而非其外觀。一個已學會結果形狀的模型會寫出形狀而不執行工作——一個空區塊，或對其從未執行的查詢的引用。兩者都被視為未交付。

額外的步驟僅耗費幾分之一秒，且僅在看起來需要它的訊息上運行——普通問題無需付費。在運行期間，對話會顯示其正在執行的操作。如果決策的任何部分不清楚，回合會像沒有它一樣繼續進行。

兩個預算，而非一個

工具結果是對話上下文被摧毀的最常見方式。單一的 CRM 查詢可能返回比模型整個上下文視窗更多的文字。

限制每個單獨的結果是顯而易見的防禦措施，但這並不足夠。結果在迭代間累積——對話只會增長——因此最壞的情況是迭代限制乘以每次迭代的幾個工具，再乘以每個結果的上限。每個結果都通過其自身的限制，但總量仍然溢出。

因此有兩個預算：每個結果的上限，以及整個回合的總預算。一旦總預算耗盡，後續結果會被替換為短佔位符，而非附加。

佔位符中的內容與截斷本身一樣重要。靜默截斷的結果比沒有更糟，因為模型無法知道它正在從半份記錄中推理。截斷通知和耗盡佔位符都明確指出內容不完整，並指示模型根據已有內容回答，且不要發明缺失的部分——這是在說「我只能看到前幾個訂單」的代理程式與自信地捏造其餘部分的代理程式之間的差異。

截斷也會記錄工具名稱和大小，因為一個經常溢出預算的工具是一個應該返回較少欄位的工具——這是一個值得注意的配置問題。

不產生正確工具呼叫的模型

並非所有模型都能可靠地產生結構化的工具呼叫；有些會將呼叫作為文字嵌入回覆中。迴圈並未將此視為失敗的回合，而是從訊息內容中解析工具呼叫，並在回覆到達客戶之前移除格式錯誤的片段——因此模型在失誤時僅會導致稍慢的回合，而非讓 JSON 洩漏到對話中。

連接你自己的系統

工具來自兩個來源。

內建工具隨平台提供——安排後續跟進、建立提醒、捕捉聯絡人詳細資料、調用技能、編輯文件、繪製圖表、搜尋網路。

大多數這些不是你做的決定。它們對每個代理程式可用，並附加到需要它們的回合，這正是擁有它們不會產生任何成本的原因：訪客的訊息沒有理由使用的工具根本不在該回合的列表中，因此它不佔用任何上下文，也不提供模型錯誤選擇的選項。沒有清單需要維護，也沒有配置會讓代理程式靜默地缺乏接聽電話號碼的能力。

技能自身的工具是例外，且刻意如此：它們僅在該技能載入時出現，在此之前不會出現。能力包是一種工作方式，工具是方法的一部分——單獨提供它們會讓模型跳過方法。請參閱 Skills and how one gets chosen。

是一個決定的事項是從公開來源回答——這個代理程式是否可以搜尋網路並閱讀其發現的內容，而非僅從你自己的材料中回答。這是一個單一開關，因為這是一個單一問題：搜尋和擷取是一起開啟的，因為一個能找到頁面但無法閱讀的代理程式，在測量上是三種配置中最差的。預設為關閉，而代理程式開啟後的行為——標籤、審查佇列——在 Retrieval 中有描述。

你的系統透過 MCP 連接。 租戶註冊 MCP 伺服器，其工具對該租戶的代理程式可用。支援三種傳輸方式：stdio 用於本機子程序，以及 streamable_http 和 sse 用於遠端伺服器。遠端 HTTP 伺服器是託管 CRM 或內部 API 的常見選擇——無需與平台一起安裝，且連接是針對每個租戶的。

由於工具定義是按租戶註冊的，一個租戶的代理程式永遠無法看到另一個租戶的工具或端點。

實際意義

• 代理程式可以在句子中間查詢某些內容，並用真實值回答。
• 它可以將預訂、歸檔和記錄到你已經運行的系統中，而非告訴客戶去執行。
• 當工具返回的內容超過回合能容納的量時，代理程式會表示其觀點是部分的，而非用合理的虛構來填補空白。

採取行動而非僅回答的商業論證見於 Agents that act。