Agent 駕馭工程懶人包 (10)｜倢愷 Oscar 的四部曲講了什麼？8 個重點與前提

2026 年 5 月 7 日到 6 月 2 日，倢愷 Oscar 在 Medium 連發四篇〈Rethinking Agent Harness〉，Medium 標的閱讀時間是 73、49、33、49 分鐘，合計 204 分鐘。四篇回答的正是做 agent 最常卡住的四個決定：工具要掛幾個、能力要包成工具還是技能、找程式碼用 grep 還是向量庫、知識庫能不能交給 LLM 自己寫成 wiki。

Oscar 自稱 scientist，在 Medium 連載 LLM 技術文章。這篇把四篇整理成 8 個重點，每個重點寫出他自己交代的前提，再用官方文件與論文找反例。

快速回答 Oscar 四篇的共同主張是：選工具、檢索與知識庫，要同時對上模型、駕馭層（harness，模型以外負責工具、迴圈與狀態的程式）、資料、任務四個條件，只看工具名稱選不準。8 個重點各帶前提，例如 Skill 要有 bash 與檔案系統，LLM Wiki 要資料不改、只有一位維護者。PwC 2026 年 5 月的對話記憶問答實驗中，工具結果直接進對話時 grep 較準；改成寫檔再讀，10 組中有 5 組由向量檢索反超。選型前，先寫下資料多久更新，以及任務是查找、數值查詢還是跨文件綜合。

四部曲的 8 個重點，各自成立的前提是什麼？

前提各不相同：函式呼叫的保證取決於能不能控制解碼，Skill 取決於有沒有 bash 與檔案系統；Oscar 對 grep 的判斷以程式碼檢索為範圍，LLM Wiki 則要看資料是否不改、是否單人維護，以及任務是否偏跨文件綜合。下表每篇一列，前提欄是 Oscar 文中交代的條件；反例或邊界欄前三列是本站對照官方文件與論文補上的，第 4 列是 Oscar 自己的說明。

表 1　四部曲核心主張、前提與反例。來源：倢愷 Oscar 四篇原文（Medium）、OpenAI 函式呼叫文件、Anthropic Agent Skills 文件、PwC arXiv:2605.15184（皆查閱於 2026-10-23）。

Oscar 在第 4 篇結論寫了一句整體分工：前三篇處理的是模型與駕馭層，真正讓系統上線時撞牆的是資料與任務。圖 1 照這句話，把四篇放到模型、駕馭層、資料、任務四欄；歸類是本站依各篇內容做的。

前兩篇偏模型與駕馭層，第 3 篇是四欄都碰到的完整案例，第 4 篇把重心移到資料與任務。後面四節依工程主題展開，每個重點都附前提與反例。

函式呼叫失敗時，先分清楚是哪一層壞了？

先分層再修：Oscar 在第 1 篇把函式呼叫（function calling，模型輸出一段可交給程式執行的工具請求）的失敗分成三層。決策層（Decision）是不該呼叫卻呼叫，或該呼叫卻沒呼叫。序列化層（Serialization）是外殼壞掉，程式解析不出來。保證層（Guarantee）是 JSON 格式合法，內容卻違反 schema，也就是欄位與值的規則：例如溫度單位只允許 celsius、fahrenheit，模型卻填了 kelvin。

重點 1：三層的修法不同，只有決策層沒有技術手段能直接修。 他在第 2 篇（2026-05-13）寫得很直接：

「這三層裡，Decision 層是唯一沒辦法用「技術手段」直接解的。」 （倢愷 Oscar, Part 2: 理解 Skill 之美, Medium, 2026-05-13）

他批評多數工程師看到失敗就歸給幻覺（hallucination），放掉了分層除錯的機會。圖 2 把三層和他提到的處理手段放在一起。

序列化層靠輸出解析處理，保證層靠受限解碼處理；決策層沒有解碼手段，只能調整工具介面，降低選錯的機率。

重點 2：他認為格式保證與彈性，在 vLLM 與 SGLang 的預設路徑上要二選一。 輸出解析（Output Parsing）讓模型自由生成，事後用 regex 或狀態機抽出工具請求，模型寫出 kelvin 之後只能拒絕並重試。受限解碼（Guided Decoding）在每個 token 生成前，把不合法 token 的分數設成負無窮，模型就寫不出 kelvin。他在第 1 篇寫，vLLM 的 tool_choice="auto" 只走解析，"required" 才走受限解碼；agent 場景又大多用 auto，因為模型要在「呼叫工具」和「直接回答」之間切換。他還指出，函式呼叫的可靠性由模型方與推論服務兩層共同決定：模型在訓練時學會某種格式，推論服務要有對應的解析器，所以 vLLM 與 SGLang 為每個模型家族各維護一個。

受限解碼有兩項代價。他指出，把模型推到訓練時沒走過的輸出軌道，品質會下降（distribution mismatch）；複雜的 schema 還會拉長延遲。他給 OpenAI 的 gpt-oss Harmony 格式正面評價：模型先自由決定要不要呼叫、呼叫哪個工具，進入參數區段後才套 schema 限制。這是他對格式的解讀，OpenAI 的 Harmony 文件只寫 <|constrain|> 標記「轉到工具呼叫的資料型別定義」，文件沒有說明它會觸發受限解碼。

他還算了一筆帳：單步失敗率為 p，N 步全部成功的機率是 (1−p)^N。p 從 3% 變成 5%，10 步任務的成功率由 74% 降到 60%，20 步由 54% 降到 36%。他在第 2 篇自己說明，這個算式假設每步獨立，「非常不嚴謹」，只用來說明方向。

反例與更新。 vLLM 文件現行版（查閱於 2026-10-23）寫明，tool_choice="auto" 也能套結構化標記（structural tag）：至少一個工具設 strict: true（或伺服器用 --tool-strict-level 設下限）、伺服器沒有關掉 VLLM_ENFORCE_STRICT_TOOL_CALLING、所用解析器支援結構化標記，三個條件都成立時，會限制工具呼叫的外殼，並鎖住 strict 工具的參數 schema。條件不滿足時退回從原始文字抽取，文件寫明參數「可能偶爾格式錯誤或違反參數 schema」。Oscar 5 月描述的二選一，在這份文件裡已經有第三條路，文件沒有說明這項功能從哪個版本開始。

OpenAI 的函式呼叫文件建議永遠開 strict 模式，並寫明例外：微調模型一輪呼叫多個函式時，strict 會關閉。受限解碼的啟動成本，OpenAI 在 2024-08-06 的 Structured Outputs 公告寫得具體：新 schema 的第一次請求會多出延遲，一般 schema 在 10 秒內，複雜 schema 最久可到一分鐘。

工程上的意思： 日誌要分層統計：解析失敗算序列化層，參數違反 schema 算保證層，選錯工具算決策層。我會先看哪一層的次數最多，再決定改解碼設定還是改工具介面。Oscar 列了五條介面原則：工具少、命名清楚、先推理再結構化輸出、預設值不放進 schema、工具名共用前綴。其中三條在官方文件找得到對應，下表第一欄是 Oscar 的原則，後兩欄是官方文件的對應做法與數字。

表 2　Oscar 的工具介面原則與官方文件的對應。OpenAI 稱 20 個是軟性建議。來源：OpenAI 函式呼叫文件、Anthropic tool search 文件（查閱於 2026-10-23）。

Anthropic 的 tool search 文件另外寫，GitHub、Slack、Sentry、Grafana、Splunk 五個伺服器的典型設定，光工具定義就可能占約 55k token；用 defer_loading: true 只載入需要的 3 到 5 個，通常能減少超過 85%。

能力該包成工具，還是包成技能？

Oscar 的答案是：一類任務的完整流程包成技能（Skill），單一操作才包成工具。這是他在第 2 篇的主軸。

重點 3：技能封裝的是一段任務流程。 他的定義是，技能把一類任務的流程、參考文件、腳本與使用策略封裝起來，模型需要時才展開。差別在粒度：一個工具是一次基本操作，呼叫完拿結果就結束；一個技能是「用手上這些工具把某類任務做完」的步驟，觸發後模型可能呼叫十幾次工具。他認為在任務層級做決策，比在二十個微操作之間挑一個，更貼近模型訓練時見過的資料。

Anthropic 的 Agent Skills 文件給了載入的實際數字，下表列出三層。最佳實務文件另外建議 SKILL.md 本文控制在 500 行內。

表 3　Agent Skills 的三層載入。來源：Anthropic, Agent Skills overview（查閱於 2026-10-23）。

Oscar 另外估算，20 個各帶 2k 到 4k token 說明的工具，常駐會占 40k 到 80k token，20 個技能的描述加起來約 4k；這是他的估算，文中沒有附實測。

重點 4：技能的好處有前提：腳本要先驗證過，SKILL.md 要小，不要把工具一對一包成技能。 他列了三個會破壞設計的寫法，下表是破壞了什麼與他給的檢查方式。

表 4　技能設計的三個反例寫法。來源：倢愷 Oscar, Part 2，2026-05-13。

腳本的檢查他給三題：換到全新環境能不能一行指令跑起來、有沒有在至少三組不同輸入上驗證過、常見錯誤有沒有處理並明確輸出。他估計徒手寫程式的一次成功率約 70% 到 80%，呼叫驗證過的腳本接近 100%，這同樣是他的估計，沒有附實測。

反例與更新。 技能依賴 bash 與檔案系統。Anthropic 文件寫，API 上的 Skills 在沙箱容器中執行，沒有網路存取，也不能在執行時安裝套件，需要連網的腳本在這個環境跑不起來。已經透過 MCP 接了許多外部工具的系統，Anthropic 提供另一條路：用 tool search 按需搜尋工具，搭配 defer_loading，等需要時才把工具定義放進模型讀取的內容，不必改寫成技能。

四部曲之後，Oscar 在 2026-09-07 發了延伸文章，把漸進載入用在 CLAUDE.md 上。他比較「在 CLAUDE.md 寫『請讀 AGENTS.md』」和「用 @AGENTS.md 匯入」：前者要模型自己發出讀檔呼叫，內容以工具回傳值進入 context；後者由駕馭層在第一個請求前寫入。他歸納出四個差異：多一輪往返、模型一步沒做對就沒有訊號、指令層級較低、壓縮時優先被丟。Claude Code 的 memory 文件支持前提：CLAUDE.md 以使用者訊息形式送出，位在 system prompt 之後。

兩份文件也和他的文章有出入。他引用 4 月的原始碼分析，寫到技能清單不會在壓縮後立即重送；context window 文件現在寫，技能描述會重建並重新注入，需要 Claude Code v2.1.304 以上。他的測試顯示只有 AGENTS.md 時 Claude Code 沒有載入事件；memory 文件現行版寫，沒有 CLAUDE.md 時會直接讀 AGENTS.md，memory 文件寫明需 v2.1.277 以上。文件只列出最低版本要求，Oscar 沒有交代他測試用的版本，無法判斷差異來自版本更新，還是測試條件不同。

工程上的意思： 技能的成本由 SKILL.md 本文長度與腳本品質決定。盤點時先問「我有幾類典型任務」，再回頭決定每類任務會用到哪些工具，技能數會小於工具數；兩者一對一，代表只是把工具清單搬了地方。工具少於 20 個、又沒有反覆出現的流程時，我不會急著改寫成技能。

找程式碼為什麼從向量庫換成 grep？

Oscar 在第 3 篇（2026-05-18）的答案是：grep 同時給了完整性與可重試，向量檢索在程式碼上兩者都缺。這個結論的證據範圍是程式碼檢索。

重點 5：程式碼和自然語言的結構不同，向量檢索在程式碼上有三個問題。 識別字命中、切塊破壞語意、索引過期。重點 6：grep 的結果範圍完整，失敗也有資訊。 下表是他的逐項對照。

表 5　Oscar 對程式碼檢索的逐項對照。來源：倢愷 Oscar, Part 3，2026-05-18。

索引過期這項，他說實務上常用延遲更新，例如平均兩週才嵌入一次，撈到的片段可能跟現況對不上。結果範圍與失敗訊號兩項，是他論證 grep 的核心：grep 沒有 top-k 截斷，撈到 200 筆太寬，至少知道答案在裡面；撈到 0 筆，下一步就是擴大範圍或換 pattern。向量檢索失敗時，agent 分不出是查詢不準、切塊切斷還是嵌入模型不熟。他的總結是，好的 LLM 應用要讓模型、駕馭層、資料、任務四個元素對得上，Claude Code 用 Glob、Grep、Read 做檢索，同時對上這四件事。

反例。 PwC 美國團隊的 Sahil Sen 等五位作者在 2026-05-14 提交 arXiv 論文〈Is Grep All You Need? How Agent Harnesses Reshape Agentic Search〉，做了對照實驗，任務是長對話的記憶問答，與程式碼無關。他們用 LongMemEval 的 116 題子集，比較 grep 與向量檢索，駕馭層有自建的 Chronos，以及 Claude Code、Codex、Gemini CLI 三個命令列工具，GPT-4o 當評分模型。

工具結果直接放進對話時，grep 在 10 組模型與駕馭層的組合全部高於向量檢索；差距最大是 Chronos 搭 Gemini 3.1 Flash-Lite（86.2% 對 62.9%），最小是 Claude Code 搭 Claude Opus 4.6（76.7% 對 75.0%）。改成把結果寫進檔案、由模型另外讀取之後，向量檢索在 10 組中的 5 組反超 grep；Codex 搭 GPT-5.4 的 grep 由 93.1% 掉到 55.2%。

同一個 Claude Opus 4.6，工具結果直接放進對話時，grep 在 Chronos 是 93.1%，在 Claude Code 是 76.7%，換駕馭層的影響和換檢索方式相當。作者自己也限縮結論：

"We do not claim that grep "beats" vector in general, only that it can win end-to-end under the task distribution and corpora we study." （Sen et al., arXiv:2605.15184, 2026-05-14）

作者推測，這份題庫的答案常由字面片段決定，所以 grep 占優；他們在限制一節列出證據很少是字面的領域，包括科學綜述、圖文並重的文件與程式碼語意，語意檢索或混合檢索在那些領域的表現可能不同。這和 Oscar 的框架相容：同一種檢索方式，換駕馭層與資料，結果就變。PwC 的資料是對話紀錄，無法用來反駁程式碼場景，第 3 篇的結論要連同資料類型一起讀。

工程上的意思： 檢索工具的選擇，要連同工具結果怎麼送回模型一起測。把 grep 的輸出改成寫檔，改動的是駕馭層；Codex 搭 GPT-5.4 的 grep 準確率因此差了 37.9 個百分點（93.1% 對 55.2%）。評估檢索方案時，固定資料與模型，變動送達方式各跑一次。程式碼庫我會先用 grep 起步，要加向量檢索，得先有 grep 找不到的失敗案例當理由。

LLM Wiki 能不能取代企業檢索？

Oscar 在第 4 篇（2026-06-02）的答案是不能取代，LLM Wiki 只適合個人、資料不改、任務偏跨文件綜合的場景；企業內部要先切出符合條件的子語料。

LLM Wiki 出自 Andrej Karpathy 的 gist，gist 寫明原始資料放在 raw/，這一層不可變（immutable），模型只讀不改。Oscar 整理的完整結構是：模型維護的 markdown 知識庫放在 wiki/，CLAUDE.md 說明結構與流程，另有 index.md 與 log.md。流程分三種：匯入（ingest）時模型讀新資料、更新相關頁面；查詢（query）時先讀 index 再往下鑽；檢查（lint）時定期找矛盾與孤立頁面。Oscar 認為它的核心是在匯入時就做綜合，並把結果存到硬碟，查詢時不必每次現場拼湊。

重點 7：LLM Wiki 的甜蜜點是個人、不可變、重綜合三個條件的交集。 資料不改，匯入時合成的頁面才不會過期；只有一位維護者，就沒有權限合併問題；任務是學習與跨文件綜合，匯入時的合成成本才有回收。他指出，市面上常見的「文件少於 100 份用 wiki、多於 1000 份用 RAG」只是快速判斷，沒有回答為什麼是 100；他自己有多個專案用上千份檔案做 LLM Wiki，表現仍可維持。

重點 8：企業場景把這三個條件反過來，所以要切子語料。 他列了五個反轉，下表把個人 wiki 與企業檢索並排。

表 6　個人 LLM Wiki 與企業檢索的五個差異。來源：倢愷 Oscar, Part 4，2026-06-02；5% 與 95% 是他的經驗說法，文中未附資料。

反轉的後果，他舉了幾個。資料每天在改時，過期資訊還會被後續匯入當成背景知識擴散。權限不一致時，法務文件與產品規格合成同一頁，這頁該給誰看，取交集或聯集都有問題。規模上，他算過 1000 萬份來源、每份 15 次頁面操作、每次 1k token，共 150B token，用每百萬 token 1 美元的模型約 15 萬美元，他認為主要瓶頸在結構維護：要先用關鍵字搜尋或向量索引篩出相關頁面，檢索又回來了。

適合的子語料，他給了六項檢查：規模有界、資料少變、讀取權限一致、查詢以綜合為主、超過 70% 的內容會被查到、有明確維護者，並說這些門檻是參考值。例子包括決策前的廠商研究、研究團隊的實驗紀錄、法規研究。混合方案他留到後續文章，四篇裡沒有寫出。

工程上的意思： 先按查詢類型把公司知識庫切開：查找走索引，數值查詢用 text-to-SQL（把自然語言問題轉成 SQL 去查資料庫），綜合型才考慮 LLM Wiki。每一類各自驗證，同一個企業可以有三種檢索方式。要試 LLM Wiki，我會從有明確維護者的研究資料夾開始，不從全公司知識庫開始。

四篇放在一起，什麼情況下結論會失效？

模型、駕馭層、資料、任務任何一項改變，四篇的結論都可能失效。Oscar 在第 3 篇寫了同樣的意思：半年內只要有一個底層因素改變，就會出現「新一個時代」的技術。

前面三處更新說明了這件事：vLLM 的 auto 模式、Claude Code 壓縮後的技能描述、AGENTS.md 的讀取。vLLM 文件沒有交代功能從哪個版本開始；Claude Code 文件雖列出最低版本，Oscar 卻沒交代測試版本，所以差異來自版本更新還是測試條件，本文只標出需要重新查證的地方。

我的建議是把四篇當檢查表來用，選型結論得依自己的系統來下。動手挑工具之前，先寫一張四欄的小表：用哪個模型與推論服務、駕馭層開放哪些介面、資料多久改一次、任務是查找還是綜合。填得出來，再回頭對照 Oscar 的哪個重點前提與自己相符；填不出來的欄位，就是下一步要量的東西。他估計的腳本成功率（70% 到 80% 對接近 100%），以及企業內容中 5% 承擔 95% 查詢，文中都未附實測；我只當方向參考，預算要另外量。

這四篇寫於 2026 年 5、6 月，到 10 月已有三處被文件更新；半年後再用這 8 個重點時，先重查前提，再下結論。

常見問題

倢愷 Oscar 的 Rethinking Agent Harness 四部曲是哪四篇？

四篇都發表在 Medium：Part 1〈Behind Function Calling〉（2026-05-07）、Part 2〈理解 Skill 之美〉（2026-05-13）、Part 3〈為什麼 Grep 打敗了 RAG？〉（2026-05-18）、Part 4〈LLM Wiki 取代 RAG？〉（2026-06-02）。Medium 標示的閱讀時間依序是 73、49、33、49 分鐘。

grep 真的比向量檢索準嗎？

要看任務與工具結果如何回傳模型。PwC 在長對話記憶問答上測試 10 組模型與駕馭層（管理工具呼叫與結果回傳的程式）的組合：結果直接進對話時全部是 grep 較準；改成寫檔再讀，5 組由向量檢索反超。論文作者表明不主張 grep 普遍勝出。Oscar 的結論只針對程式碼檢索。

LLM Wiki 可以直接用在公司知識庫嗎？

不建議直接把整個公司知識庫交給 LLM Wiki（由模型把來源文件整理成知識頁面）。Oscar 認為它適合單人維護、資料不改、主要用來跨文件整理與比較的場景；企業資料常改、權限不一致，查詢類型也較混雜。他的做法是切出規模有界、資料少變、權限一致的子語料，例如決策前研究或實驗紀錄，其餘維持原本的檢索。

函式呼叫要不要一律開 strict？

OpenAI 的函式呼叫文件建議永遠開 strict（強制工具參數符合 schema，也就是指定的欄位與值的規則），例外是微調模型一輪呼叫多個函式時 strict 會關閉。代價是新 schema 的第一次請求有延遲：OpenAI 2024-08-06 的公告寫，一般 schema 在 10 秒內，複雜 schema 最久到一分鐘。schema 常變動的服務，延遲要實測。

延伸閱讀

• AGENTS.md 怎麼寫？規則寫越多，Agent 反而越貴？（2026 完整教學＋範例）
• RAG、Workflow、Agent 差在哪？什麼時候真的需要 Agent？（2026 完整比較）
• 為什麼 AI 越聊越笨、一直犯同樣的錯？Anthropic 揭密 Context Engineering 實戰（2026 懶人包）

參考資料

• 倢愷 Oscar, 【Rethinking Agent Harness，如何更好設計 LLM Agent】Part1: Behind Function Calling（Medium, 2026-05-07） https://axk51013.medium.com/rethinking-agent-harness-%E5%A6%82%E4%BD%95%E6%9B%B4%E5%A5%BD%E8%A8%AD%E8%A8%88-llm-agent-part1-behind-function-calling-e17c419c8e96
• 倢愷 Oscar, 【Rethinking Agent Harness】Part 2: 理解 Skill 之美（Medium, 2026-05-13） https://axk51013.medium.com/rethinking-agent-harness-part-2-%E7%90%86%E8%A7%A3-skill-%E4%B9%8B%E7%BE%8E-bb3a3342e84d
• 倢愷 Oscar, 【Rethinking Agent Harness】Part 3: 為什麼 Grep 打敗了 RAG？（Medium, 2026-05-18） https://axk51013.medium.com/rethinking-agent-harness-part-3-%E7%82%BA%E4%BB%80%E9%BA%BC-grep-%E6%89%93%E6%95%97%E4%BA%86-rag-40eafd507cf6
• 倢愷 Oscar, 【Rethinking Agent Harness】Part4: LLM Wiki 取代 RAG ？（Medium, 2026-06-02） https://axk51013.medium.com/rethinking-agent-harness-part4-llm-wiki-%E5%8F%96%E4%BB%A3-rag-041629319804
• 倢愷 Oscar, 【Harness 之美-1】在 CLAUDE.md 寫「請讀 AGENTS.md」就夠了嗎？（Medium, 2026-09-07） https://axk51013.medium.com/harness-%E4%B9%8B%E7%BE%8E-1-%E5%9C%A8-claude-md-%E5%AF%AB-%E8%AB%8B%E8%AE%80-agents-md-%E5%B0%B1%E5%A4%A0%E4%BA%86%E5%97%8E-a66f827e8f13
• Sahil Sen 等, PwC, Is Grep All You Need? How Agent Harnesses Reshape Agentic Search, arXiv:2605.15184（2026-05-14） https://arxiv.org/abs/2605.15184
• OpenAI, Function calling（文件頁，查閱於 2026-10-23） https://platform.openai.com/docs/guides/function-calling
• OpenAI, Introducing Structured Outputs in the API（2024-08-06） https://openai.com/index/introducing-structured-outputs-in-the-api/
• OpenAI, OpenAI Harmony response format（Cookbook，查閱於 2026-10-23） https://developers.openai.com/cookbook/articles/openai-harmony
• Anthropic, Agent Skills overview 與 Skill authoring best practices（查閱於 2026-10-23） https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
• Anthropic, Tool search tool（查閱於 2026-10-23） https://platform.claude.com/docs/en/agents-and-tools/tool-use/tool-search-tool
• Anthropic, How Claude remembers your project 與 Explore the context window（Claude Code 文件，查閱於 2026-10-23） https://code.claude.com/docs/en/memory
• vLLM, Tool Calling（文件 latest 版，查閱於 2026-10-23） https://docs.vllm.ai/en/latest/features/tool_calling/
• Andrej Karpathy, LLM Wiki（GitHub gist，查閱於 2026-10-23） https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f