Claude Code 原始碼洩漏之後，第一時間大家當然會被「終於看到內部長什麼樣」這件事吸引，但很快討論重點就變了。真正讓開發者興奮的，不是某幾段 system prompt，也不是某種前所未見的推理技巧，而是大家終於更清楚地看到：一個能在真實開發場景中長時間運作的 Coding Agent，背後其實是一套很厚的工程包裝。
這件事的重要性在於，它把很多人對 AI coding product 的想像拉回現實。過去不少人會把 Claude Code、Codex 這類產品的效果，歸因成「模型特別強」或「prompt 特別會寫」，但這次大家愈看愈發現，真正有價值的部分其實是 Harness，也就是包在模型外面的執行環境、權限制度、工具接口、記憶機制、驗證流程與任務編排方式。換句話說，模型只是核心引擎，真正把它變成可靠產品的，是外面的整套結構。
這也是為什麼洩漏之後，社群快速把注意力轉向 harness engineering。因為大家突然意識到，所謂好用的 coding agent，不是單靠模型智力堆出來的，而是靠大量工程細節把錯誤率壓低、把失控邊界縮小、把每一步都變得更可預期。
Harness 的本質，不是加功能，而是把不穩定的模型變成可管理的系統
如果只把 agent 理解成一個會寫程式的聊天介面，就很容易把問題想得太簡單。實際上，模型本身最大的問題從來不是「不夠會寫」，而是它不穩定、不持久、容易失焦，也容易在資訊不完整時自作主張。Harness 的存在，就是為了處理這些問題。
這次事件之後，大家普遍整理出一個共識：好的 harness 不是功能插件集合，而是一個管理不確定性的系統。它要做的事情很多，但核心只有幾項。
第一，是限制 agent 的行為邊界，避免它在未經授權的情況下做高風險決策。
第二，是把任務狀態保存下來，避免每次 context 壓縮或 session 切換之後都要重新猜。
第三，是讓 agent 有能力自我驗證，而不是每次都靠人類做最後一道 QA。第四，是讓整個流程可回退、可重來、可審查，而不是一次做錯就整局污染。
從這個角度看，Claude Code 洩漏最有價值的地方，不在於暴露了什麼驚人的祕密，而在於它再次證明了一件事：真正成熟的 AI coding product，已經不是「模型加殼」，而是「模型作為其中一個元件的完整系統」。
長任務的真正解法，不是塞更多上下文，而是把狀態外部化
這波討論裡最值得記下來的一個觀察，是大家對長任務處理方式的重新理解。過去很多人直覺上會覺得，agent 做不好長任務，是因為 context window 還不夠大；只要視窗更長、壓縮更好，問題自然會消失。但 Claude Code 相關的工程文章與社群分析都指出，事情沒有這麼單純。
模型在長任務裡真正出問題的地方，不只是「記不住」，而是當上下文變長之後，整體注意力會劣化，決策品質也會開始下降。它會忘記前面講過的限制、混淆先前做過的選擇，甚至在工作還沒完成時提早收尾。這代表長任務的關鍵，不是想辦法讓一個 session 永遠撐下去，而是要把任務中那些不可遺失的資訊寫到聊天歷史之外。
這也是為什麼大家開始特別重視 feature list、progress log、plan file、init script、CLAUDE.md、AGENTS.md 這類結構化文件。這些東西的用途，不只是「提供說明」，而是把任務狀態從模型的暫時記憶中抽出來，變成可以跨 session 延續的外部記錄。當 agent 每次進場時，不是從一堆模糊聊天紀錄裡猜自己之前做過什麼，而是直接讀取一份明確的狀態說明，它才能真正做到長時間穩定推進。
這背後其實是一個很重要的開發觀念：不要把對話當作唯一的工作載體。真正需要被保存的，不應該只是聊天內容，而是任務狀態本身。
Deterministic control 必須下沉到系統層，而不是只寫在 Prompt 裡
這次大家從 Claude Code 延伸出來的另一個很強烈的心得，是：凡是你希望每次都會發生的規則，都不該只存在 prompt 裡。因為 prompt 本質上仍然是對模型的語言引導，而不是硬性執行約束。只要模型判斷失誤、context 被擠壓，或當前任務目標跟規則發生競爭，這些規則就可能被弱化甚至遺失。
因此，成熟 harness 的思路是把「每次都必須成立」的東西下沉到 deterministic control layer，也就是 hooks、permissions、checkpoints、policy engines、classifier 這類結構裡。像是某些檔案不能改、某些命令不能跑、編輯後一定要 format、compact 後一定要重新注入關鍵上下文、配置改動一定要記錄，這些都應該交給系統層保證，而不是期待模型每次都乖乖記得。
這件事很像傳統軟體工程裡，不能把業務關鍵約束只放在前端提醒文字裡，而是要落到 schema、驗證器、權限系統與 transaction 上。對 agent 來說也是一樣。Prompt 可以描述原則，但不能取代制度；語言可以引導行為，但不能替代執行保證。這正是 harness engineering 最務實、也最容易被低估的地方。
權限設計不是附屬功能，而是 agent 產品的主結構
Claude Code 洩漏後，很多人開始更認真地看待 permissions。原因很簡單：只要 agent 能改檔、能跑命令、能碰網路、能調外部工具，它就已經不是單純的建議系統，而是具備真實影響力的執行者。這時候權限模型就不再是 UX 細節，而是產品架構核心。
官方後續公開的 auto mode 設計尤其值得注意。它呈現出一個很成熟的想法：開發者真正痛苦的不是每個 prompt 都要人工批准，而是批准久了之後會疲乏，最後變成什麼都直接點同意。這代表「人工審批」本身並不等於安全，因為當流程過於頻繁，使用者的警覺性會自然崩壞。因此更好的做法不是在全手動與全放權之間二選一，而是建立更細緻的中介層。
這種中介層通常會包含三段。第一段是明顯安全、可直接放行的操作，例如讀檔或在專案內做低風險修改。第二段是限定範圍內可接受的自動操作，例如某些類型的測試、格式化、局部編輯。第三段則是高風險或高不確定性操作，例如破壞性 shell 指令、外部資料傳送、跨專案權限動作，這些必須由 classifier 或人工介入。從產品設計角度來看，這種分層不是加分功能，而是把 autonomy 變得可商用的必要條件。
好的 agent 不是更會寫，而是更會驗證
如果要從這次討論中只挑一個最值得拿走的心得，那很可能就是：驗證能力比生成能力更重要。這句話乍看普通，但其實影響非常大。因為今天多數模型在「生出一段看起來合理的東西」這件事上早就不弱，真正的問題是它能不能分辨自己寫出來的東西到底有沒有真的工作。
因此，大家愈來愈重視的不是如何讓 agent 多產一點，而是如何讓它有更完整的 verification loop。這包含測試、瀏覽器自動化、畫面比對、logs、metrics、traces、端到端檢查，以及更進一步的 evaluator agent 或 reviewer agent。當 agent 能直接看到 UI、能跑實際流程、能讀運行資料、能檢查回歸影響，它才比較有機會從「生成器」變成「可交付系統的一部分」。
這也解釋了為什麼不少團隊在做 agent product 時，後期投入的重點不是再加更多寫碼工具，而是讓 agent 看得到更多執行後的世界。因為只要驗證通路沒建立，人類就永遠是最後一道單點瓶頸。你可以讓 agent 一晚寫十個功能，但如果隔天還是得人肉把每個功能全部驗一次，那產能提升其實非常有限。
多 Agent 的真正價值，是建立 Context Firewall
社群在這波事件後也重新強化了對 subagents 的理解。很多人原本把多 agent 想成單純平行化，也就是把一個大工作切成多份，同時跑比較快。但實際上，更多團隊開始強調的是另一個更重要的功能：context firewall。
所謂 context firewall，就是讓主控 agent 保持乾淨，只負責規劃、協調與決策，而把局部任務交給獨立上下文的子 agent 處理。這樣做的好處，不只是效率，而是避免那些中間調試過程、失敗嘗試、局部猜測，把整條主線對話污染掉。當子 agent 完成工作後，只把必要結果、結論與產出交回來，主線上下文就能維持較高品質與較長壽命。
這種設計也跟多人角色分工有關。Claude Code 相關研究與後續社群討論裡，都很強調 planner、generator、evaluator 這種角色拆分。因為一個 agent 如果同時負責規劃、實作、審查、驗證與收尾，它很容易陷入自我肯定偏差，或在長時間工作後逐步失焦。相反地，把不同認知工作分開，不但比較容易對症下藥，也更容易建立穩定 review loop。
所謂厲害，很多時候只是把失敗模式處理得夠完整
這次事件還有一個很值得記下來的副作用，就是它讓更多人對 AI product 的想像變得更成熟。很多人在看過相關分析後，最大的感受不是「原來裡面有神級黑魔法」，而是「原來真正有用的部分，是一堆非常具體、非常樸素的工程處理」。
例如，怎麼避免 agent 過早宣告完成，怎麼避免 compact 後丟掉關鍵任務狀態，怎麼在 context 滿載前讓任務安全切換，怎麼把高風險操作擋下來，怎麼在被 prompt injection 污染之前先做防護，怎麼讓每次編輯都有回退點，怎麼讓 agent 對自己產出的內容做更嚴格的驗證。這些問題單看都不華麗，但全部加起來，就是產品可靠性的真正來源。
也正因如此，這波事件之後大家最關注的，反而不是怎麼複製某個 prompt，而是怎麼複製某種架構思路。因為可移植的從來不是機密字串，而是 failure mode catalog、state model、tool contract、verification loop 與 permission architecture。這些東西才是別人真正能學，也真正能拿來做產品差異化的部分。
結論：真正值得學的，不是 Claude Code 說了什麼，而是它怎麼被工程化
Claude Code 原始碼洩漏後，外界關注到的核心，其實可以濃縮成一句話：可靠的 coding agent，並不是靠更長的 prompt 長出來的，而是靠更好的 harness 設計養出來的。當模型被放進一個有狀態管理、有權限分層、有 deterministic control、有驗證迴路、有回退機制、也有多 agent 分工的環境裡，它才會從一個會寫字的模型，變成一個能長時間交付結果的工程系統。
這件事對所有想做 AI coding product、agent workflow 或自動化開發工具的人都很重要。因為它提醒我們，未來真正拉開差距的，不只是誰用到更強的模型，而是誰更早理解：模型只是引擎，harness 才是產品。
