Shell + 技能 + 壓縮：關於長時間運行的、執行實際工作的代理的提示

我們正從單輪對話助理轉向長時間運行的代理，它們可以處理真正的知識工作：讀取大型數據集、更新文件和編寫應用程序。

基於開發者反饋以及我們自己構建 Codex 和內部代理的經驗，我們正在發布一組新的代理原語，使長時間工作變得更加實用：

文檔和 API 參考分別涵蓋了上面的每一項。這篇文章重點介紹了到目前為止我們所見過的、效果最好的非顯而易見的提示和模式，無論是在 OpenAI 的工作中還是在 Glean（一個早期的技能客戶）的生產中。

一個簡短的思維模型

技能：模型可以按需加載的“程序”

技能是一組文件加上一個包含前言和指令的 SKILL.md 清單。可以把它想像成：一個版本化的劇本，模型在需要執行實際工作時可以參考。

當技能可用時，平台會向模型公開每個技能的名稱、描述和路徑。模型使用這些元數據來決定是否調用技能。如果調用，它會讀取 SKILL.md 以獲取完整的流程。

Shell 工具：代理的“執行”

Shell 工具讓模型可以在真實的終端環境中工作，可以是：

託管 shell 通過 Responses API 運行，這意味著您的請求帶有狀態工作、工具調用、多輪延續和工件。

壓縮：保持長時間運行

隨著工作流程變得更長，它們會遇到上下文窗口限制。服務器端壓縮通過管理上下文窗口並自動壓縮對話歷史記錄來保持長時間運行。

Responses API 中的壓縮為您提供了兩種處理方式：

為什麼它們在一起更好

提示和技巧

1) 像編寫路由邏輯一樣編寫技能描述（而不是營銷文案）

您的技能描述實際上是模型的決策邊界。它應該回答：

一個實用的模式是在描述中直接包含一個簡短的“何時使用 vs. 何時不使用”塊，並保持具體（輸入、涉及的工具、預期的工件）。

2) 添加反例和邊緣案例以減少誤觸發

一個令人驚訝的失敗模式是，使技能可用最初可能會減少正確的觸發。我們看到的一個解決方案是反例加上邊緣案例覆蓋。

在實踐中，這意味著編寫一些明確的“不要在以下情況調用此技能…”案例（以及應該做什麼）。這有助於模型更乾淨地路由，尤其是在您有多個乍一看相似的技能時。

Glean 直接看到了這一點：基於技能的路由最初在有針對性的評估中使觸發下降了約 20%，然後在他們在描述中添加了反例和邊緣案例覆蓋後恢復了。

3) 將模板和示例放在技能內部（它們在不使用時基本上是免費的）

如果您一直在將模板塞入系統提示中，請停止。

技能內部的模板和工作示例有兩個優點：

這對於知識工作輸出尤其有效，例如：

Glean 報告說，這種模式推動了他們在生產中獲得的一些最大的質量和延遲提升，因為這些示例僅在技能觸發時才加載。

4) 儘早使用容器重用和壓縮來設計長時間運行

長時間運行的代理很少能作為一次性提示成功。從一開始就計劃好連續性：

這種組合減少了重新啟動行為，並使多步驟作業在線程增長時保持一致。

5) 當您需要確定性時，明確告訴模型使用該技能

默認行為是模型決定何時使用技能。這通常是您想要的。

但是，當您運行具有明確合同的生產工作流程（並且您寧願是確定性的而不是聰明的）時，只需說：

“使用 <技能名稱> 技能。”

這是您可以拉動的最簡單的可靠性槓桿。它將模糊的路由變成了一個明確的合同。

6) 將技能加上網絡視為高風險組合（設計用於遏制）

這是一個安全提示，現在很容易忽略，以後很難修復。

將技能與開放的網絡訪問相結合，會為數據洩露創建高風險路徑。如果您使用網絡，請保持網絡允許列表嚴格，假設工具輸出不受信任，並避免在用戶期望強確認控制的面向消費者的流程中使用開放互聯網加上強大的程序。

一個強大的默認姿態：

7) 使 /mnt/data 成為您工件的交接邊界

對於託管 shell 工作流程，將 /mnt/data 視為寫入您將檢索、審查或傳遞回後續步驟的輸出的標準位置。示例包括報告、清理後的數據集和完成的電子表格。

一個好的思維模型：工具寫入磁盤，模型在磁盤上推理，開發人員從磁盤檢索。

8) 將允許列表理解為一個兩層系統（組織級別和請求級別）

網絡在兩個地方受到控制：

兩個在操作上很重要的含義：

如果請求包含組織允許列表之外的域，它將出錯。

9) 使用 domain_secrets 進行身份驗證的調用（避免憑證洩漏）

如果允許的域需要身份驗證標頭，請使用 domain_secrets，以便模型永遠不會看到原始憑證。

在運行時，模型會看到佔位符（例如，$API_KEY），並且一個 sidecar 僅為批准的目的地注入真實值。每當您的代理需要從容器內調用受保護的 API 時，這都是一個強大的默認設置。

10) 在雲端和本地使用相同的 API

您可以使用這兩種原語，而無需承諾託管所有內容：

一個實用的開發循環看起來像：

三種構建模式

雖然您應該隨意嘗試這些新的代理原語，但這裡有三個如何組合它們來構建有用應用程序的示例。

模式 A：安裝 -> 獲取 -> 寫入工件

這是從託管 shell 中受益的最簡單方法：代理安裝依賴項，獲取外部數據，並生成一個具體的交付物。

例如：

這種模式是實際工作代理的基礎，因為它創建了一個乾淨的審查邊界：您的應用程序可以向用戶顯示工件，記錄它，對其進行差異比較，或將其饋送到後續步驟中。

模式 B：技能 + shell 用於可重複的工作流程

一旦您構建了一個或兩個成功的 shell 工作流程，您就會注意到下一個問題：這可行，但當提示漂移時，可靠性會降低。

這就是技能的用武之地。以下是一個可以遵循的持久結構：

這對於以下工作流程特別有效：

模式 C（高級）：技能作為企業工作流程的載體

我們看到的一個早期模式是單個工具調用和多工具編排之間的差距中準確性的損失。技能可以通過使工具推理更具程序性而不膨脹系統提示來彌合這一差距。

來自 Glean 的一個具體例子：

這是事情變得強大的形狀。技能成為活的 SOP（標準操作程序）：隨著您的組織的發展而更新，並由代理一致地執行。

一次構建，隨處運行

當長時間運行的代理既可以遵循程序又可以在計算機上執行實際工作時，它們會變得非常有用。技能、託管 shell 和壓縮創建了這個基礎。概括地說：

在您自己的應用程序中開始使用。請參閱技能文檔、shell 文檔和壓縮文檔以了解如何操作。