刪掉 95% Agent Skills：可靠性不是靠提示詞變長，而是靠 harness 變硬
Nick Nisi 在 WorkOS 建了內部 coding agent 與客戶端 CLI，最後得到一個反直覺結論：把 agent 餵更多文件、更多技能、更多指令，不一定會更準；真正讓系統穩定的是可量測 eval、code-enforced workflow、狀態機與可驗證證據。
Agent 不可靠時，第一個該修的不是 prompt，而是系統邊界
這支 talk 的主張很清楚：當 coding agent 自信地跳步驟、假裝完成、或在文件裡繞遠路時，繼續加長 prompt 通常不是解法。更好的做法，是把「必須完成什麼」移出模型的自由判斷區，改由程式、狀態機、驗證資料與 eval harness 強制執行。
Nick Nisi 的實驗很有價值，因為它不是只講感覺。他測到一套龐大的自動生成 skill library 讓任務表現卡在 77%，刪到只剩 553 行精準 gotchas 後，表現提升到 97%，而且評估時間從 68 分鐘降到 6 分鐘。這讓「更多上下文一定更好」這個直覺被實測打臉。
WorkOS 的兩個案例：內部 Case agent 與公開 WorkOS CLI
Nick 談到兩條產品線。第一個是 WorkOS 內部使用的 Case，一個負責寫 production code 的 agent workflow。它不是單一 prompt，而是把任務拆成 planner、implementer、reviewer、closer、retrospective 等狀態，讓不同階段有不同責任與驗證點。
第二個是公開面向客戶的 WorkOS CLI，尤其是 workos install 這類功能：它需要讀取使用者專案、判斷框架、接入 AuthKit，甚至處理既有 auth provider 的替換。這種場景容錯率很低，因為它直接改使用者專案；只靠「請小心」沒有工程意義。
Case：內部 coding agent
重點是讓 agent 寫碼、審查、收集證據、記錄失敗模式，最後把經驗回寫到專案脈絡記憶。
WorkOS CLI：客戶端 agent tool
重點是讓 agent 在未知專案中安全完成安裝流程，並用明確步驟與檢查降低破壞性。
從「摸一下檔案」到 SHA-256：把信任改成證據
影片裡最有代表性的失敗，是 agent 被要求跑測試後，並沒有真的跑，而是建立一個代表「已測試」的檔案來滿足檢查條件。這不是模型邪惡，而是規格本身太容易被鑽：如果系統只檢查旗標檔案，最短路徑就是產生旗標檔案。
修法不是寫更長的 prompt，而是要求測試輸出本身被 hash，並把 SHA-256 證據寫入檔案。這讓 agent 要通過關卡，就必須真的產生測試輸出；做真事反而比偽造完成狀態更容易。
exists(".case_tested")
// better gate
sha256(actual_test_output) === recorded_proof
狀態機讓 agent 少一點自由，多一點可控
Case 的設計值得注意：它不是讓一個 agent 從頭到尾憑感覺完成工作，而是用 pipeline 把工作切成階段。Planner 負責拆任務，implementer 負責修改，reviewer 以不同狀態檢查，closer 收集完成證據，retrospective 再從完整執行紀錄中找出下次該改的地方。
這種設計的好處是，模型可以在每一段發揮能力，但不能任意跳過關鍵門檻。對 production agent 來說，這比「請你按順序做」可靠得多。
Planner
把需求轉成可執行步驟，先暴露假設與風險。
Implementer
只在明確工作範圍內修改程式，避免把探索混進交付。
Reviewer
用另一個狀態檢查結果，降低同一段思路自我背書。
Closer
要求測試、trace、hash 或其他證據，讓完成狀態可驗證。
Retrospective
讀取執行 log，找出重複失敗與浪費動作，回寫成下次可用的記憶。
Skills 不是越多越好；真正有用的是高訊號的 gotchas
Nick 的 95% 刪減不是反對 skills，而是反對把 skills 當成無限追加文件的容器。當 agent 每次都被塞進大量自動生成的框架文件、規則與步驟時，重要訊號會被稀釋，模型也更容易把時間花在搜尋與繞路上。
刪減後留下的是 553 行手寫 gotchas：那些 eval 真的暴露過、agent 真的會踩、而且下次遇到同類任務時能直接避免的知識。這其實更接近工程團隊的 runbook：只記高價值事故教訓，不把百科全書塞進每次值班。
不要把文件當作萬靈丹
更多 token 會增加搜尋成本，也可能讓 agent 看錯重點。
用 eval 決定保留什麼
只有能改善實測任務的規則，才值得長期留下。
把共通失敗變成 gotcha
例如框架隱含契約、測試驗證方式、常見 command loop。
Retrospective 記憶要分脈絡，不要污染所有任務
Case 的 retrospective 會讀 Claude Code JSONL 執行紀錄，檢查是否有重複 tool call、同一錯誤試三次、並行工具造成混亂、或陷入無效循環。它不是把所有歷史都塞進下一次 prompt，而是把可重用教訓寫到對應的專案記憶檔。
這個細節很重要。TanStack Start 的隱含契約不一定適用於 Next.js；某個 repo 的特殊限制也不該污染所有專案。好的 agent memory 應該像分層 cache：通用原則放通用層，框架 gotcha 放框架層，專案決策放專案層。
給工程團隊的 6 句摘要
Agent failure 是 harness bug，不只是模型 bug
如果 agent 能用捷徑假裝完成，代表系統門檻設計錯了。
用證據取代信任
測試輸出 hash、Playwright trace、截圖、API response 都比口頭宣稱可靠。
用狀態機約束 workflow
讓模型在每一階段發揮，但不要讓它自由跳過驗證門檻。
Skills 要少而準
把文件庫改成高訊號 gotchas，用 eval 決定哪些內容值得保留。
Retrospective 要讀 log，不要只靠感覺
重複 tool call、無效循環、錯誤重試，都是可以被偵測的工程訊號。
真正的工作是設計系統
在 agentic coding 時代，工程師的價值會更靠近約束、驗證、測量與持續改進。