GPT-6 Astra 程式化工具呼叫：何時使用及為何使用
了解 GPT-6 Astra 在生成的程式中何時應呼叫工具、allowed_callers 與 output_schema 的運作方式，以及如何控制成本、安全性與審核流程。
傳統函式呼叫會暫停模型，向應用程式回傳工具請求，等待結果後再繼續執行。這個循環雖然清晰且可控，但當任務需要大量依賴性呼叫、本地篩選或彙總時，效率就會變低。GPT-6 Astra 程式化工具呼叫（PTC）讓模型能在單一執行流程中撰寫程式，並調用符合條件的工具。
變更內容
啟用託管的 programmatic_tool_calling 工具，然後使用 allowed_callers 標記符合資格的工具。
const tools = [
{ type: "programmatic_tool_calling" },
{
type: "function",
name: "get_sales",
description: "返回一個區域和一個月的銷售記錄。",
allowed_callers: ["程式化"],
strict: true,
parameters: {
type: "object",
properties: {
region: { type: "string" },
month: { type: "string" }
},
必填： ["區域", "月份"],
additionalProperties: false
}
}
];
若 allowed_callers 被省略或設為 ["直接"]，該工具可直接呼叫。["程式化"] 將其限制於生成的程式碼，而 ["直接", "程式化的"]允許兩者。這是一項執行策略控制，因此應像審查權限一樣審查它，而非提示措辭。
PTC 支援已記錄的工具類別，包括函式與自訂工具、MCP、套用修補程式、本機或託管 Shell，以及程式碼解譯器。支援並不代表每個工具都應被公開。
何時 PTC 是較佳的模式
在模型需要以下情況時使用：
- 擷取多筆獨立記錄並進行彙整；
- 根據先前的結果呼叫一個工具；
- 在將大型結果返回推理上下文之前先進行過濾；
- 比較不同來源的結構化輸出；
- 運行一個有界限的數據處理迴圈。
例如，季度分析可能需要十二次區域-月份呼叫，接著進行總計和異常檢測。程式可以執行這些呼叫並回傳簡潔摘要，而無需強制進行十二次模型往返。
對於一兩個簡單操作、高風險寫入、每一步都需要明確應用程式決策的工作流程，或圖形必須確定性的任務，建議優先使用直接函數調用。PTC 並非自動更便宜：一個邊界設定不佳的程式可能會產生過多的調用。
結構化輸出提升程式品質
對於可預測的函式，請定義一個 output_schema。實際的 function_call_output.output 仍為 JSON 字串，但此結構描述能讓生成的程式碼擁有可靠的形狀。穩定的型別可減少防禦性解析與意外假設。
回傳緊湊的資料，例如 ID、型別化的度量值以及明確的錯誤物件。在需要數字的程式碼中避免使用散文。讓分頁、最大行數與截斷在結果中可見，使程式無法將部分資料集誤認為完整群體。
工具搜尋與延遲載入
工具搜尋仍是一項頂層能力。官方指南警告，延遲載入的工具必須在程式啟動前載入，因為正在執行的程式無法呼叫工具搜尋。先規劃探索，再執行。若目錄是動態的，讓模型先載入所需的小部分子集，然後才開始 PTC。
安全控制
以牆壁時間、呼叫次數、輸出位元組、網路目的地和成本來限制每個程式。將工具限制為最低權限，並將機密保留在執行環境中，而非產生的程式碼中。
MCP 核准可以暫停程式。在呈現有意義的核准預覽時，保留程式狀態。對於寫入操作，請使用冪等金鑰和伺服器端授權。即使模型是根據可信的指令撰寫，所產生的程式碼仍不可信任。
記錄程式雜湊或經過編輯的原始碼、工具序列、已清理的引數、核准、結果、代幣使用情況及持續時間。避免儲存憑證或原始敏感資料。
生產決策框架
提出四個問題：
- 是否有足夠的呼叫或依賴關係來證明嵌入式程式的合理性？
- 每個工具都能安全地界定和定型嗎？
- 應用程式是否適合委託中間控制？
- 工作流程在核准或部分失敗後能否恢復？
若任一答案為否，則將編排保留在應用程式碼中。對於固定流程而言，您所擁有的確定性程式碼通常是正確的選擇。
成本與正確性實驗
將 PTC 與使用相同任務的傳統迴圈進行基準測試。包含一個小型單次呼叫案例、一個依賴性五次呼叫案例，以及一個大型聚合案例。測量總代幣數、工具呼叫次數、實際耗時、失敗率，以及計算結果的正確性。一個更快但默默丟棄分頁記錄的答案並非改進。
強制部分失敗：一個區域超時、一個結果違反其輸出結構、一個 MCP 操作請求核准，以及一個資料集為空。生成的程式應保留哪些輸入成功，避免將缺失視為零，並回傳足夠的細節，讓模型能夠解釋限制。
在基礎設施限制之下設定硬性上限，讓程式可預測地失敗。清晰的 CALL_BUDGET_EXCEEDED 結果比容器被終止更容易恢復。對於分析型工作負載，應在確定性程式碼中獨立重新計算一部分輸出。對於任何財務或合規結果，應優先採用經過驗證的計算，而非盲目信任生成的彙總結果。
此實驗常呈現混合設計：以PTC處理大量讀取探索，並以應用程式自有程式碼執行最終寫入或受規範的計算。混合編排是優勢，而非未能全面採用最新功能。
常見問題
PTC 與多重代理相同嗎？
不。PTC執行一個工具呼叫程式。多智能體將有限的工作委派給擁有各自上下文的子智能體。
PTC 能否呼叫需要核准的 MCP 工具？
是的。批准可以暫停程式。您的應用程式必須保留狀態並安全地繼續執行。
PTC 會移除功能架構嗎？
不。強烈的輸入與輸出合約變得更加重要，因為生成的程式碼會使用它們。
每個工具都應該支援兩種呼叫模式嗎？
否。僅允許工作流程所需的模式，特別是針對敏感工具。
結論
當工具編排本身成為瓶頸時，程式化工具呼叫便極具價值：涉及大量呼叫、依賴關係、篩選與彙總。請選擇性地使用，在執行前延遲載入工具，定義結構化輸出，並嚴格限制資源與權限。對於簡短或高風險的工作流程，傳統的應用程式控制迴圈仍較易於稽核。
