Code Mode 什么時候更省別只數工具調用要數模型往返判斷 Code Mode 是否更省最容易犯的錯誤是盯著“工具調用了多少次”。同樣讀取 10 個文件可以是模型發起 10 次串行決策也可以是模型先寫一個有界程序讓程序完成 10 次讀取、篩選和聚合再把一份壓縮結果交還模型。兩種方案的工具調用數都可能是 10但模型往返、重復上下文和中間輸出完全不同。所以真正應該優化的不是Promise.all這個語法而是完整任務中的模型輪次、上下文回放、結果體積與失敗邊界。一、先區分兩條執行回路直接工具調用的典型循環是模型選擇一個工具觀察結果再決定下一步。它的優勢不是“簡單”而是每一步都可以利用新信息重新判斷。搜索方向要不要改變、是否需要審批、寫入前是否應停下來、工具的原生引用或文件能力是否必須保留這些任務天然需要直接調用。程序化工具調用則把一段可預測工作交給代碼一次模型請求生成 JavaScript在隔離的 V8 Runtime 中完成多次調用、循環、條件判斷、過濾、排序、去重或聚合只把較小的結構化結果返回給模型。它省下的不是工具本身而是工具之間不必要的模型往返。證據圖 1OpenAI Programmatic Tool Calling 文檔按任務形狀區分兩種模式。可預測、可聚合并能返回更小結構化結果的階段適合程序化調用需要新判斷、審批或保留原生能力時直接調用更合適。這里還要劃清一個產品邊界OpenAI API 的 Programmatic Tool Calling 是公開能力說明Codex 產品內部如何組合模型、執行環境、Responses Lite 與其他工具路徑是另一層實現。本文只借官方文檔解釋能力邊界不把 API 文檔等同于 Codex 全部后端。二、成本要按模型往返記賬可以先用一個簡化式建立直覺任務成本 ≈ 模型輪次 × 每輪重復上下文 工具結果輸入 模型輸出緩存輸入比未緩存輸入便宜但不是免費。按當前 Codex Rate CardGPT-5.6 Sol 的緩存輸入為 12.5 Credits / 1M Token。假設 100k 緩存上下文被重復帶入 30 次模型請求僅這一項就是 3M cached input也就是 37.5 Credits。這個例子是作者換算不是官方對單任務成本的預測。更關鍵的是長上下文經常還會攜帶工具結果、計劃、日志和歷史決策。串行工具調用越多模型越可能重復接收同一批背景信息。程序化階段如果能在運行時先裁剪結果只回傳模型真正需要的字段節省會同時來自“更少輪次”和“更小結果”。三、一條長線程說明了什么又不能說明什么GitHub Issue #32503 給出了一條長 Codex Desktop 線程的追蹤GPT-5.6 Sol 產生 739 個 exec cells其中只有 5 個使用Promise.all。報告同時觀察到每個含工具回合的模型請求數約高 5.3 倍、每回合總 Token 約高 7.9 倍約 94% 的輸入 Token 被報告為緩存。它足以支持一個機制判斷如果多個已知的獨立讀取被拆成“模型一次、工具一次、再回模型”的串行鏈重復上下文會放大任務成本。但它不能證明一個普遍倍率。該追蹤混合了不同模型、上下文窗口、推理強度和工具路徑5.3 倍與 7.9 倍不能直接推廣到所有倉庫、所有套餐或所有任務。正確用法是把它當作排查線索而不是產品承諾或普遍 Bug 定論。四、受控樣本支持“條件收益”不支持“全部批處理”Issue #35050 在兩個無關代碼庫上做了同模型對照。重復 High/XHigh 樣本中顯式有界批處理讓加權使用分別下降約 45% 和 27%一個 Max 配對下降 47.4%但作者明確說明單個配對需要復現。這組數據比跨模型長線程更接近可比較實驗但樣本仍然只覆蓋兩類只讀倉庫任務不能推廣成“Code Mode 固定節省 27%—45%”。更重要的反例是一個過度激進的提示變體反而多消耗 26.8% 加權 Credits。為什么批得更多反而可能更貴為了湊批次擴大調查范圍讀取了原本不需要的數據把輸出很大的操作塞進一輪結果壓縮失敗一個子調用失敗導致整批重跑回滾成本高于串行把寫入、審批或共享狀態操作并發化正確性成本上升模型為了設計復雜批處理程序產生了更多推理與輸出。因此“能并發”不是決策條件“已知、獨立、只讀、結果可控、失敗邊界清楚”才是。五、一個可落地的任務形狀矩陣適合程序化調用多個已知且獨立的數據源只讀操作不共享可變狀態結果可過濾、聚合、去重或校驗返回給模型的內容明顯小于原始結果失敗可以定位到單個子調用并能局部重試。適合直接調用或串行執行下一步需要模型基于新結果重新做語義判斷如果依賴關系可預測、后續參數可由代碼推導且失敗邊界明確仍可留在程序化階段搜索需要模型動態改變關鍵詞或來源涉及寫入、審批、權限和外部狀態需要工具原生引用、文件或交互產物失敗會改變后續策略不能機械繼續。真實任務通常不是二選一。更穩妥的結構是“分階段混合”模型先判斷階段目標階段內對已知只讀操作做有界批處理階段結束后把壓縮結果交回模型再決定下一個階段。六、不要用調用數證明優化要做完整任務 A/B評估前還必須固定同一模型、推理檔位、倉庫快照、任務、驗收標準和工具權限并執行多次重復。之后至少同時記錄四組指標質量結論、引用、邊界和最終驗收是否一致資源未緩存輸入、緩存輸入、輸出和加權 Credits編排模型輪次、工具調用、程序單元、失敗與重試延遲首次有效結果、總時長、P50 與 P95。作者建議先用 6—8 個互相獨立的只讀調用做一個有界試驗并把 20% 的資源改善當作值得保留的觀察閾值之一這只是工程起點不是官方門檻。若質量下降、失敗重跑增加或輸出無法裁剪即使工具調用看起來更“并發”也不算優化。七、批次太大、等待太久同樣會放大成本程序化調用不是“批得越多越省”。至少有七條常見放大路徑批次太小導致頻繁回模型每個中間階段都返回模型結果沒有在代碼層壓縮批次過大觸發限速、截斷或整批重試依賴任務被提前并發慢工具等待期間反復喚醒模型開放式搜索一次鋪開過多寬泛查詢。Issue #33402 報告過外層exec聚合結果截斷。它只是一個社區個案不能說明所有 Code Mode 都存在同樣問題卻足以提醒 Harness每個工具和每個批次都要有max_bytes、max_rows、max_items不能把完整日志、網頁或大文件無條件匯總給模型。緩存也要分開看“命中率”和“總處理量”。94% 緩存命中可能與很高的累計緩存輸入同時成立命中率高只能說明重復前綴獲得折扣不能說明重復輪次已經消失。八、Promise.all不是目標失敗語義才是Promise.all中任一子調用拒絕整個 Promise 就會拒絕。如果 Runtime 或提示隨后重跑整個批次已經成功的讀取也可能重復。對于可以局部恢復的只讀任務更穩妥的基線通常是constresultsawaitPromise.allSettled(batch.map((item)safeToolCall(item)));constfailedresults.map((result,index)({result,index})).filter(({result})result.statusrejected);并發還要有上限。每批 6—8 項只是工程起點真實數值取決于工具限速、結果大小、資源競爭和失敗率。讀操作通常易于重試寫操作必須額外解決共享狀態、冪等、事務、鎖和回滾。真正的優化目標是在不犧牲正確性與可恢復性的前提下減少無價值模型往返和重復上下文。九、用七問判斷串行、并行還是分階段問題若答案為“是”若答案為“否”調用之間有數據依賴嗎串行或由代碼推導確定依賴繼續判斷會寫入共享狀態嗎串行、加鎖或事務繼續判斷需要逐項審批嗎串行繼續判斷單項失敗會改變整體策略嗎串行或小批次繼續判斷輸出可控并能本地壓縮嗎可考慮并行限制批次與返回體外部服務能承受并發嗎可考慮并行降低并發所有調用是否預先已知可批處理自適應分輪這也給出三類清晰邊界已知、獨立、只讀、可壓縮的調用適合程序化批處理測試、多倉庫掃描、文檔檢索等任務只在局部條件滿足時適合數據庫事務、刪除、發布、付款、權限變更、自適應調試和開放式搜索不得盲目并行。十、搜索和工具等待需要專門的 Harness網絡搜索的對象集合會被上一輪證據改變不能照搬文件批處理。更穩妥的流程是第一輪只發起 2—4 個高價值查詢抽取來源、日期、結論和證據等級識別缺口與沖突后第二輪只查缺口連續沒有新增證據時停止。Harness 同時限制每輪查詢數和頁面數優先官方源做 URL 去重并避免把整頁原文直接塞入主上下文。工具等待則要同時處理三層Runtime使用異步完成事件不因“仍在等待”反復喚醒模型完成后一次聚合只重試失敗項Harness給慢工具設置超時與結果預算用 DAG 表達依賴超過等待預算時交付部分結果或降級提示明確“工具未返回前不要重復請求同一資源只在存在獨立子任務時繼續”。自然語言提示不能代替 Runtime 約束但可以減少不必要的中間響應。十一、十步落地策略先畫依賴圖不按工具數量直接決定并行只對獨立、只讀、無審批、輸出可控的調用批處理小批開始按限速、大小和失敗率調整使用Promise.allSettled局部失敗局部重試在代碼層過濾、去重、計數和抽樣給每項設置max_bytes、max_rows或max_items不把完整日志、網頁和大文件直接返回模型寫入保持串行或使用顯式鎖、事務與冪等鍵搜索按證據缺口分輪單批失敗率超過 20%、輸出接近上限或出現重復讀取時停止并重新規劃。十二、完整 A/B 與四層根因質量指標至少包括驗收通過率、漏項、錯誤和人工返工資源指標包括總 Credits、未緩存輸入、緩存輸入、輸出、模型輪次、工具調用和重試編排指標包括批次數、平均批大小、并發度、失敗率、重復讀取和截斷延遲指標包括總墻鐘時間、工具等待時間和模型時間。還要按獨立只讀、依賴讀取、寫入、測試、網絡搜索、多代理和高風險操作分組不能把不同任務混成一個平均數。如果結果異常不要只怪模型。根因可能同時位于四層模型策略可能批次偏小、重復驗證或停止條件弱系統提示可能鼓勵全面工作卻不給預算Runtime 可能頻繁生成中間響應、截斷聚合或錯誤重試Harness 可能沒有去重、依賴圖、輸出上限和 P95/P99 熔斷。公開證據只確認了部分現象不能虛構每一層的貢獻比例。常見誤解也應一并排除Code Mode 不是任意代碼執行啟用它不保證減少模型輪次Promise.all數量不是效率指標網絡搜索不能一次并行完社區 Issue 提供的是機制線索和有限對照不是總體因果估計。最終結論很簡單先壓縮不必要的模型往返再考慮并發語法。Promise.all是手段任務形狀、失敗語義、結果預算與完整成本才是控制面。參考資料OpenAI DevelopersProgrammatic Tool CallingOpenAI DevelopersUsing GPT-5.6OpenAI Help CenterCodex Rate CardGitHub openai/codex Issue #32503GitHub openai/codex Issue #35050GitHub openai/codex Issue #33402 Code Mode 什么時候更省：別只數工具調用，要數模型往返
Code Mode 什么時候更省別只數工具調用要數模型往返判斷 Code Mode 是否更省最容易犯的錯誤是盯著“工具調用了多少次”。同樣讀取 10 個文件可以是模型發起 10 次串行決策也可以是模型先寫一個有界程序讓程序完成 10 次讀取、篩選和聚合再把一份壓縮結果交還模型。兩種方案的工具調用數都可能是 10但模型往返、重復上下文和中間輸出完全不同。所以真正應該優化的不是Promise.all這個語法而是完整任務中的模型輪次、上下文回放、結果體積與失敗邊界。一、先區分兩條執行回路直接工具調用的典型循環是模型選擇一個工具觀察結果再決定下一步。它的優勢不是“簡單”而是每一步都可以利用新信息重新判斷。搜索方向要不要改變、是否需要審批、寫入前是否應停下來、工具的原生引用或文件能力是否必須保留這些任務天然需要直接調用。程序化工具調用則把一段可預測工作交給代碼一次模型請求生成 JavaScript在隔離的 V8 Runtime 中完成多次調用、循環、條件判斷、過濾、排序、去重或聚合只把較小的結構化結果返回給模型。它省下的不是工具本身而是工具之間不必要的模型往返。證據圖 1OpenAI Programmatic Tool Calling 文檔按任務形狀區分兩種模式。可預測、可聚合并能返回更小結構化結果的階段適合程序化調用需要新判斷、審批或保留原生能力時直接調用更合適。這里還要劃清一個產品邊界OpenAI API 的 Programmatic Tool Calling 是公開能力說明Codex 產品內部如何組合模型、執行環境、Responses Lite 與其他工具路徑是另一層實現。本文只借官方文檔解釋能力邊界不把 API 文檔等同于 Codex 全部后端。二、成本要按模型往返記賬可以先用一個簡化式建立直覺任務成本 ≈ 模型輪次 × 每輪重復上下文 工具結果輸入 模型輸出緩存輸入比未緩存輸入便宜但不是免費。按當前 Codex Rate CardGPT-5.6 Sol 的緩存輸入為 12.5 Credits / 1M Token。假設 100k 緩存上下文被重復帶入 30 次模型請求僅這一項就是 3M cached input也就是 37.5 Credits。這個例子是作者換算不是官方對單任務成本的預測。更關鍵的是長上下文經常還會攜帶工具結果、計劃、日志和歷史決策。串行工具調用越多模型越可能重復接收同一批背景信息。程序化階段如果能在運行時先裁剪結果只回傳模型真正需要的字段節省會同時來自“更少輪次”和“更小結果”。三、一條長線程說明了什么又不能說明什么GitHub Issue #32503 給出了一條長 Codex Desktop 線程的追蹤GPT-5.6 Sol 產生 739 個 exec cells其中只有 5 個使用Promise.all。報告同時觀察到每個含工具回合的模型請求數約高 5.3 倍、每回合總 Token 約高 7.9 倍約 94% 的輸入 Token 被報告為緩存。它足以支持一個機制判斷如果多個已知的獨立讀取被拆成“模型一次、工具一次、再回模型”的串行鏈重復上下文會放大任務成本。但它不能證明一個普遍倍率。該追蹤混合了不同模型、上下文窗口、推理強度和工具路徑5.3 倍與 7.9 倍不能直接推廣到所有倉庫、所有套餐或所有任務。正確用法是把它當作排查線索而不是產品承諾或普遍 Bug 定論。四、受控樣本支持“條件收益”不支持“全部批處理”Issue #35050 在兩個無關代碼庫上做了同模型對照。重復 High/XHigh 樣本中顯式有界批處理讓加權使用分別下降約 45% 和 27%一個 Max 配對下降 47.4%但作者明確說明單個配對需要復現。這組數據比跨模型長線程更接近可比較實驗但樣本仍然只覆蓋兩類只讀倉庫任務不能推廣成“Code Mode 固定節省 27%—45%”。更重要的反例是一個過度激進的提示變體反而多消耗 26.8% 加權 Credits。為什么批得更多反而可能更貴為了湊批次擴大調查范圍讀取了原本不需要的數據把輸出很大的操作塞進一輪結果壓縮失敗一個子調用失敗導致整批重跑回滾成本高于串行把寫入、審批或共享狀態操作并發化正確性成本上升模型為了設計復雜批處理程序產生了更多推理與輸出。因此“能并發”不是決策條件“已知、獨立、只讀、結果可控、失敗邊界清楚”才是。五、一個可落地的任務形狀矩陣適合程序化調用多個已知且獨立的數據源只讀操作不共享可變狀態結果可過濾、聚合、去重或校驗返回給模型的內容明顯小于原始結果失敗可以定位到單個子調用并能局部重試。適合直接調用或串行執行下一步需要模型基于新結果重新做語義判斷如果依賴關系可預測、后續參數可由代碼推導且失敗邊界明確仍可留在程序化階段搜索需要模型動態改變關鍵詞或來源涉及寫入、審批、權限和外部狀態需要工具原生引用、文件或交互產物失敗會改變后續策略不能機械繼續。真實任務通常不是二選一。更穩妥的結構是“分階段混合”模型先判斷階段目標階段內對已知只讀操作做有界批處理階段結束后把壓縮結果交回模型再決定下一個階段。六、不要用調用數證明優化要做完整任務 A/B評估前還必須固定同一模型、推理檔位、倉庫快照、任務、驗收標準和工具權限并執行多次重復。之后至少同時記錄四組指標質量結論、引用、邊界和最終驗收是否一致資源未緩存輸入、緩存輸入、輸出和加權 Credits編排模型輪次、工具調用、程序單元、失敗與重試延遲首次有效結果、總時長、P50 與 P95。作者建議先用 6—8 個互相獨立的只讀調用做一個有界試驗并把 20% 的資源改善當作值得保留的觀察閾值之一這只是工程起點不是官方門檻。若質量下降、失敗重跑增加或輸出無法裁剪即使工具調用看起來更“并發”也不算優化。七、批次太大、等待太久同樣會放大成本程序化調用不是“批得越多越省”。至少有七條常見放大路徑批次太小導致頻繁回模型每個中間階段都返回模型結果沒有在代碼層壓縮批次過大觸發限速、截斷或整批重試依賴任務被提前并發慢工具等待期間反復喚醒模型開放式搜索一次鋪開過多寬泛查詢。Issue #33402 報告過外層exec聚合結果截斷。它只是一個社區個案不能說明所有 Code Mode 都存在同樣問題卻足以提醒 Harness每個工具和每個批次都要有max_bytes、max_rows、max_items不能把完整日志、網頁或大文件無條件匯總給模型。緩存也要分開看“命中率”和“總處理量”。94% 緩存命中可能與很高的累計緩存輸入同時成立命中率高只能說明重復前綴獲得折扣不能說明重復輪次已經消失。八、Promise.all不是目標失敗語義才是Promise.all中任一子調用拒絕整個 Promise 就會拒絕。如果 Runtime 或提示隨后重跑整個批次已經成功的讀取也可能重復。對于可以局部恢復的只讀任務更穩妥的基線通常是constresultsawaitPromise.allSettled(batch.map((item)safeToolCall(item)));constfailedresults.map((result,index)({result,index})).filter(({result})result.statusrejected);并發還要有上限。每批 6—8 項只是工程起點真實數值取決于工具限速、結果大小、資源競爭和失敗率。讀操作通常易于重試寫操作必須額外解決共享狀態、冪等、事務、鎖和回滾。真正的優化目標是在不犧牲正確性與可恢復性的前提下減少無價值模型往返和重復上下文。九、用七問判斷串行、并行還是分階段問題若答案為“是”若答案為“否”調用之間有數據依賴嗎串行或由代碼推導確定依賴繼續判斷會寫入共享狀態嗎串行、加鎖或事務繼續判斷需要逐項審批嗎串行繼續判斷單項失敗會改變整體策略嗎串行或小批次繼續判斷輸出可控并能本地壓縮嗎可考慮并行限制批次與返回體外部服務能承受并發嗎可考慮并行降低并發所有調用是否預先已知可批處理自適應分輪這也給出三類清晰邊界已知、獨立、只讀、可壓縮的調用適合程序化批處理測試、多倉庫掃描、文檔檢索等任務只在局部條件滿足時適合數據庫事務、刪除、發布、付款、權限變更、自適應調試和開放式搜索不得盲目并行。十、搜索和工具等待需要專門的 Harness網絡搜索的對象集合會被上一輪證據改變不能照搬文件批處理。更穩妥的流程是第一輪只發起 2—4 個高價值查詢抽取來源、日期、結論和證據等級識別缺口與沖突后第二輪只查缺口連續沒有新增證據時停止。Harness 同時限制每輪查詢數和頁面數優先官方源做 URL 去重并避免把整頁原文直接塞入主上下文。工具等待則要同時處理三層Runtime使用異步完成事件不因“仍在等待”反復喚醒模型完成后一次聚合只重試失敗項Harness給慢工具設置超時與結果預算用 DAG 表達依賴超過等待預算時交付部分結果或降級提示明確“工具未返回前不要重復請求同一資源只在存在獨立子任務時繼續”。自然語言提示不能代替 Runtime 約束但可以減少不必要的中間響應。十一、十步落地策略先畫依賴圖不按工具數量直接決定并行只對獨立、只讀、無審批、輸出可控的調用批處理小批開始按限速、大小和失敗率調整使用Promise.allSettled局部失敗局部重試在代碼層過濾、去重、計數和抽樣給每項設置max_bytes、max_rows或max_items不把完整日志、網頁和大文件直接返回模型寫入保持串行或使用顯式鎖、事務與冪等鍵搜索按證據缺口分輪單批失敗率超過 20%、輸出接近上限或出現重復讀取時停止并重新規劃。十二、完整 A/B 與四層根因質量指標至少包括驗收通過率、漏項、錯誤和人工返工資源指標包括總 Credits、未緩存輸入、緩存輸入、輸出、模型輪次、工具調用和重試編排指標包括批次數、平均批大小、并發度、失敗率、重復讀取和截斷延遲指標包括總墻鐘時間、工具等待時間和模型時間。還要按獨立只讀、依賴讀取、寫入、測試、網絡搜索、多代理和高風險操作分組不能把不同任務混成一個平均數。如果結果異常不要只怪模型。根因可能同時位于四層模型策略可能批次偏小、重復驗證或停止條件弱系統提示可能鼓勵全面工作卻不給預算Runtime 可能頻繁生成中間響應、截斷聚合或錯誤重試Harness 可能沒有去重、依賴圖、輸出上限和 P95/P99 熔斷。公開證據只確認了部分現象不能虛構每一層的貢獻比例。常見誤解也應一并排除Code Mode 不是任意代碼執行啟用它不保證減少模型輪次Promise.all數量不是效率指標網絡搜索不能一次并行完社區 Issue 提供的是機制線索和有限對照不是總體因果估計。最終結論很簡單先壓縮不必要的模型往返再考慮并發語法。Promise.all是手段任務形狀、失敗語義、結果預算與完整成本才是控制面。參考資料OpenAI DevelopersProgrammatic Tool CallingOpenAI DevelopersUsing GPT-5.6OpenAI Help CenterCodex Rate CardGitHub openai/codex Issue #32503GitHub openai/codex Issue #35050GitHub openai/codex Issue #33402