如果你最近開始做「工作型」agent（不是聊天而已，而是要跑腳本、處理資料、寫檔案、產出報告、還要能多輪續跑），大概很快就會遇到三種痛：提示詞越寫越長、環境跑起來不一致、對話一變長 agent 就開始忘東忘西。
解法其實不是再多塞幾段 prompt，而是把能力拆成三塊：Skills 負責「怎麼做」、Shell 負責「在哪裡做」、Compaction 負責「怎麼讓它一路做到完」。下面整理一些比較不直覺、但在長流程特別有用的技巧。
先想清楚：你的 agent 不是在聊天，是在跑一個工作流程
Skills：把流程寫成「可重用的作業手冊」
Skill 可以想像成你幫 agent 準備的一份資料夾：裡面有 SKILL.md（像 README + SOP）、還可能放模板、範例輸出、檢查清單。重點是它能版本化、可重用，而且只有在需要時才載入。
- 你不必把所有規則塞進 system prompt。
- 模板與範例放在 skill 裡，不用時不花 token，用到時直接拉品質。
- 流程更新就改 skill 版本，少一點「某段 prompt 在哪個服務裡」的追查地獄。
Hosted Shell：給 agent 一個能安裝、能執行、能寫檔的終端
很多知識工作最後都需要「落地」：例如跑一段 Python 清理資料、輸出 CSV，再寫一份報告。Shell 工具讓 agent 真的進到終端環境做事。你可以：
- 用 Hosted Shell：平台代管容器，可重現、隔離、適合上線。
- 用 Local Shell：你自己執行 shell 呼叫，超適合開發期除錯或接內網工具。
我通常把它當成「把推理和執行切開」的開關：模型負責規劃與檢查，shell 負責跑程式、產檔、存中間結果。
Compaction(壓縮)：長流程不崩壞的秘密武器
做長流程最討厭的一件事：跑到一半上下文爆掉，agent 開始重問問題、重抓資料、甚至忘記剛輸出的檔案在哪。Server-side compaction 的方向是：上下文長到某個程度就自動壓縮，把「重要狀態」留下來，讓任務能繼續跑。
你可以把它視為長流程的基本配備，而不是「快爆了才手動整理對話」。如果你有里程碑節點，也能用獨立的 compact endpoint 在 checkpoint 後做一次更可控的壓縮。
三個一起用的直覺：把輸出變成 artifacts，讓流程可續跑
如果你只用 prompt，最後常變成「它說它做了」，但你沒有任何檔案能驗證。三件事一起上，整個工作流會變得更工程化：
- Skills：把流程與品質標準寫死（怎麼做）。
- Shell：把結果寫到檔案（做到什麼）。
- Compaction：讓它在多輪中不失憶（怎麼續跑）。
技巧 1：Skill 描述要像路由規則，不要像介紹文
我見過最常踩的坑：skill description 寫得很漂亮，但模型不知道什麼時候該用它，結果要用時不觸發、不該用時亂觸發。把 description 當成路由邏輯會更有效，至少回答三件事：
- Use when：什麼輸入/情境該用？需要哪些工具？
- Don’t use when：哪些狀況不要用？改用什麼？
- Outputs：會產出哪些檔案、放哪裡、如何驗證成功？
描述越具體越好，例如直接寫「輸出 /mnt/data/report.md，且包含結論、方法、風險與建議四段」。
技巧 2：加負向範例與邊界案例，路由會突然變穩
有個反直覺現象：你把 skills 開起來後，觸發率可能先下降，因為模型在「看起來都差不多」的技能之間猶豫。補救方式很土但很有效：寫負向範例。
- 「不要在使用者只是問概念時呼叫本 skill」
- 「不要在沒有資料來源或沒有權限時呼叫本 skill，改先回覆需要哪些輸入」
- 「如果偵測到資料欄位缺失，先輸出缺失欄位清單並停止寫最終報告」
像 Glean 這類早期使用者也提過：加入負向範例與邊界案例後，路由命中能拉回來。工程上你可以把這件事當成一種「規格測試」：技能不是寫完就完，要靠迭代把邊界補齊。
技巧 3：模板與範例別塞 system prompt，塞進 Skill 才划算
很多人一開始為了讓輸出一致，會在 system prompt 放一大段模板，結果：
- token 變大 → 成本/延遲上升
- 不相關問題也被模板干擾
- 模板要改時很難找、很難控版本
把模板、範例輸出、檢查清單放進 skill 幾乎是「白拿」的優化：不用時不載入，用到時直接有標準格式。特別適合：週報、稽核摘要、事故復盤、支援單 triage、資料清理後的分析稿。
技巧 4：長流程要先設計「續跑」：容器重用 + previous_response_id + 預設 compaction
如果你的任務分成多步驟（安裝→抓資料→清理→分析→寫報告），最怕每一步都像重新開始。實作上我會做三件事：
- 重用同一個容器：依賴不用重裝，中間檔案留著，快取也留著。
- 用 previous_response_id 延續：把它當作「同一條 thread 繼續跑」，讓模型保持任務狀態。
- compaction 當預設：不要等快爆上下文才救火，會更常失去關鍵狀態。
你會明顯感覺到：agent 不再一直重問「資料在哪」「我該從哪一步開始」，而是像一個真的在做專案的人。
技巧 5：想要更「可預期」就明講：請使用某個 Skill
預設狀況下模型會自己決定要不要用 skill。這很方便，但在生產任務（尤其是有合約輸出的）我會更偏向明確指定：
「請使用 <skill name> skill 完成本次任務。」
好處是把路由不確定性降到最低，你也更好寫測試與監控。
技巧 6：Skills + 網路存取很危險，先用最小權限把它關起來
如果 skill 裡有很強的程序（例如會自動抓資料、整理後回寫系統），再加上開放網路，就可能變成資料外洩的高風險通道。建議的安全姿勢：
- 網路預設最小 allowlist：只允許必要網域，而且每個請求的 allowlist 要更小。
- 假設外部內容不可信：外部資料可能夾帶提示注入或惡意內容，skill 內要有清理與驗證步驟。
- 消費者流程更要保守：避免在缺少確認機制的情境下，讓強程序 + 開網路直接執行敏感動作。
技巧 7：把 /mnt/data 當作交付邊界，你會更好做產品化
Hosted Shell 的輸出，建議統一寫到 /mnt/data，把它當成標準交付區：
- 工具寫檔（報告、清理後資料、程式碼）。
- 模型基於檔案內容做檢查與總結。
- 你的服務端把 artifacts 拉回去展示/下載/存檔/做 diff。
這會讓整個系統更像「可驗收的 pipeline」，而不是「一段不可重現的對話」。
技巧 8：allowlist 有兩層（組織層 + 請求層），運維上要故意做小
網路控管通常分兩層：
- 組織層 allowlist：管理者設定的「最大可去目的地」集合。
- 請求層 network_policy：每次任務指定，必須是組織層的子集合。
這其實很適合拿來做治理：組織層保持小而穩、請求層更小更精準。當請求想去不在組織層的網域時，直接報錯阻擋，反而是好事。
技巧 9：有驗證需求就用 domain_secrets，別把 API key 直接給模型看
要打受保護 API 時，最怕憑證被模型輸出到 log、或意外出現在 artifacts。用 domain_secrets 類機制的好處是：
- 模型只看到占位符（例如 $API_KEY）。
- 執行時才對核准網域注入真實密鑰。
- 就算 prompt 或工具輸出被記錄，也較不容易外洩。
技巧 10：同一套 Skills/工具語意，先本地快跑，再搬到雲端求穩
很推薦的開發節奏是：
- 先用本地 shell：快速迭代、好除錯、可以接內網工具。
- 成熟後換 hosted 容器：追求可重現、隔離、部署一致性。
- Skill 保持不變：流程才是核心資產，執行位置只是載體。
這樣你會同時得到「開發速度」與「上線穩定」。
三種常見組合模式：照著做就能做出可交付的 agent
模式 A：Install → Fetch → Write Artifact（最基本、最實用）
這模式超像你自己在終端做事：裝套件、抓資料、寫出報告。差別是 agent 幫你做完並把檔案放在 /mnt/data。
- install 幾個必要套件
- fetch：爬資料或呼叫允許的 API
- write：輸出 report.md、cleaned.csv 等 artifacts
模式 B：Skills + Shell（讓成功案例可以重複成功）
當你做出第一個能跑的工作流，下一步就是「不要讓它因為 prompt 漂移而壞掉」。把流程寫進 skill（含護欄、模板、檢查清單），再讓 agent 在 shell 裡照 SOP 跑，會穩很多。
- 資料清理 + 產出摘要
- 試算表分析或編修
- 例行標準報告（固定章節、固定輸出）
模式 C（進階）：把 Skills 當企業工作流的載體（會越用越像 SOP 系統）
多工具編排時，最容易掉準確率的是「從 A 工具結果推到 B 工具操作」這段。skills 的價值在於把這段變成程序化步驟：該查什麼、怎麼檢查、失敗怎麼降級、最後產出什麼。
像 Glean 這樣的團隊也分享過：針對特定企業系統（例如 Salesforce）的 skill，配合更好的路由描述、負向範例與模板內嵌，能提升評測表現並改善延遲。對工程師來說，這意味著你不是在「教模型變聰明」，而是在「把流程寫清楚讓它照著做」。
未來趨勢
- Skills 會更像「可執行流程資產」：未來會更常看到 skill 搭配版本控管、回歸測試、審核流程，變成組織級 SOP 的一部分。
- 長流程記憶管理走向自動化：compaction 會更深度地與 artifacts、checkpoint、觀測指標整合，減少人工整理上下文的成本。
給專業人士的實務建議
- 先做「可驗收」再追求「更聰明」：把輸出固定成 /mnt/data 的 artifacts（檔名、格式、成功判準），你會更容易測試、除錯與產品化。
- 安全從第一天做：網路用兩層 allowlist 做最小權限；需要授權就用 domain_secrets；外部內容一律當不可信，skill 內要有驗證與降級策略。
參考資料
- 參考來源：OpenAI 官方文件：https://developers.openai.com/blog/skills-shell-tips
