AI 知識
從說明走向可驗證的 Agent 交付
很多人第一次接觸 AI Agent 的 Skill，會以為它像替 Agent 安裝一個新功能：裝完之後，AI 就應該會做某件事。
實際上，Skill 比較像一本寫得很清楚的工作手冊。它可以告訴 Agent 任務的步驟、輸入輸出、注意事項、範例與工具用法。但再完整的手冊，也不會自己變成能工作的電腦環境，更不會替你確認最後的結果真的可用。
這正是許多 Agent 看起來「規則都裝好了」，卻仍卡在交付前的原因。
Skill 解決的是「怎麼做」，不是「在哪裡做」
Skill 很適合把反覆出現的流程變成可重用的說明。例如整理文件時要讀哪些欄位、產出報告時要符合哪種格式、修改程式後要跑哪些檢查。它把口頭交代變成可被重複讀取的工作方法。
但當 Agent 真要完成任務，還會碰到另一個層次的問題：它有沒有一個地方可以執行命令、寫入檔案、啟動程序、保留中間產物？
Cloudflare 的 Sandbox SDK 文件把這類環境描述為隔離的 Linux 容器，可執行命令、管理檔案、使用背景程序與服務。這說明了「工作說明」和「工作場所」並不是同一件事。前者讓 Agent 知道該做什麼；後者才讓它能把動作落到真實產物上。
為什麼「有步驟」不等於「做得到」
想像一份很完整的烹飪步驟：食材、火候、時間都寫好了。但如果沒有廚房、器具與食材，食譜本身不會產生一道菜。
Agent 也是一樣。Skill 可以寫「讀取檔案、修改內容、執行測試、回報結果」，但每一步都還需要對應的執行位置與權限。缺少其中任何一項，Agent 可能還是能把流程描述得頭頭是道，卻無法留下能交付的檔案或可回看的結果。
這不是 Skill 沒用，而是把它期待成另一種東西。Skill 是能力的說明與組織方式，不是執行環境本身。
交付可靠度，至少要過三關
判斷一個 Agent 是否真的有完成工作的條件，不一定要先看它安裝了多少 Skill。先看三件更實際的事：
能不能跑
任務是否有被允許且可觀察的執行環境？它能不能使用需要的工具、檔案與程序？如果一個 Agent 只能產生建議文字，卻不能實際執行它聲稱會做的動作，使用者應該把這兩件事分開看。
能不能留下
產物在哪裡？中間檔、錯誤訊息、修改紀錄與最後輸出，是否能由下一個步驟或下一位人員取得？Cloudflare 的 sandbox lifecycle 文件特別提醒，容器在閒置或失敗後可能重啟；需要跨生命週期保留的資料，必須自行設計保存與重新初始化。這不是所有 Agent 都一樣的限制，但它提醒我們：不能只假設「上一輪做的東西一定還在」。
能不能證明
「完成」不是一句回覆，而是可核對的結果。對文件來說，可能是輸出檔與格式檢查；對程式來說，可能是測試或建置結果；對資料任務來說，可能是可追溯的查詢與輸出紀錄。
驗證不必做成複雜的考試，但必須讓人能分辨「AI 說做完」與「任務真的完成」之間的差別。
常見誤會：一直加 Skill 就會變可靠
當 Agent 做錯事時，最直覺的反應常常是再補一份 Skill、再加一條規則、再塞一個範例。這有時能修正特定流程，卻不會自動補齊環境、權限、產物管理與驗證。
更好的排查順序是：
- 它到底卡在理解步驟，還是卡在沒有工具可用？
- 它是否真的執行了動作，還是只回覆預計要做什麼？
- 它留下了哪些可以被讀回的產物？
- 它的完成宣稱，有沒有對應的驗證證據？
這四個問題，比「還要不要再裝一個 Skill」更接近真正的故障點。
結語：Skill 是起點，交付才是終點
Skill 的價值不在於讓 Agent 看起來裝了很多能力，而在於把工作方法整理得可理解、可重用。只是當任務從回答問題走向產出檔案、執行工具與交付成果，系統還必須提供能執行、能保留、能驗證的條件。
下次看到 Agent 很自信地說「已完成」，不妨多問一句：它是真的跑完了，還是只把流程說得很像跑完？