Solo Builder

AI 模型已經出局。 不是消失，是出局——作為一個比拼的戰場，它已經結束了。但大家仍然談模型，彷彿它就是全部：這個星期哪個最聰明、誰的 benchmark 又動了、誰推出了最大的那個。這些都已經不是重點。 真正的變化是這樣的。代幣價格在六年間跌了約 600 倍。2021 年底每百萬個代幣要 60 美元的模型，現在只要幾仙。開源模型免費做到了大部分旗艦模型收費才能做的事。模型變成了商品——一件你按流量租用、一發現有更便宜又夠聰明的選項就換掉的東西。 所以，既然模型是商品，價值就不在模型身上。價值往上移了一層。 其實你已經看得到這個轉變在發生。看看大家現在真正在做的東西：OpenHands，一個有近十萬 GitHub star 的開源軟體工程 agent；OpenClaw（前身是 Clawdbot），把模型接進你本來就在用的每一個管道的個人 agent runtime；Hermes，一邊工作一邊為自己寫技能、自我改良的 agent；DeepSeek Harness，主打「一切都是外掛」、推出數日便累積數萬 star 的 runtime。它們沒有一個是靠「模型更聰明」贏的——它們全都租用模型。它們贏在擁有了包著模型的那一層。 那一層，就是 Harness。 Harness 才是你真正擁有的部分。 Harness 是模型以外的一切。工具。上下文。記憶。護欄。工作流程。決定模型看到什麼、被允許做什麼、以及它的輸出接下來會怎樣的循環。模型只推理一秒。Harness 才是讓事情整天持續運作的那個。 這樣想：模型是那一條線，Harness 才是那個裝置。真正幹活靠的是裝置，不是那條線。 而最多人錯過的是——模型之所以變便宜，Harness 反而變值錢，理由和所有「挨著充裕層的稀缺層」一樣。當推理又便宜又可以互相替代，決定一個系統是把工作做完、還是卡在半路的，就是模型四周的「腳手架」，而不是模型本身。同一個模型、兩個不同的 Harness，在同一個任務上可以名列第一，也可以墊底。 這才是 2026 年值得留意的轉變。多年來問題一直是「要用哪個模型？」但真正預測你能否把東西做出來的問題，其實是「要用哪個 Harness？」——以及你有沒有把 Harness 當成一門手藝來對待，而不是把模型當成重點。 對獨立開發者來說，這基本上全是好消息。你本來就不可能贏模型競賽。但 Harness 正好體現了貫穿你整個成本結構的同一道分界：模型是一個你租來、要盯住的計量表，而裝置是你擁有、能持續打造的那一半。其中一個你只能在上面加值，另一個你只是付錢租用。 模型既然出局，Harness 就是主場。這就是下一件該練好的事。

第一次 agent 搞砸時，你的本能是換更大的模型；第二次，是「把 prompt 寫得更用力」。兩者都錯過了重點。 一個出錯的 agent，通常不是笨模型，而是你給了它一個錯誤的「工作形狀」。你選擇的模式——模型如何路由、它能碰哪些工具、它會不會檢查自己的成果——決定了它看起來聰明，還是一再以同樣可預測的方式失敗。 有三個模式值得你記住名字，不是因為它流行，而是因為每個模式的存在，都是為了解決某種特定的失敗模式。搞清楚你在對抗哪種失敗，模式就自己會挑好。 模式一：路由（Routing）——當輸入開始長得不像彼此 問題是這樣的：一個 prompt 是退款申請，下一個是帳單 bug 回報，再下一個是「你們的退款政策是什麼？」。用單一 agent 同時處理這三種，它會信心滿滿地用同一套泛泛而論的方式硬闖過去，因為它沒有任何理由區分對待。 路由透過在行動之前先做一個決策來修正這點：先分類輸入，再把它送給對的專家。那個專家可以是不同的 prompt、不同的模型，或不同的程式路徑——重點是分離，不是機制。 路由要解決的失敗模式是異質性。一個 agent 處理多種輸入時，會漂向「平均」。路由的意思是：平均的答案是對每個具體案例都錯的，所以別再平均了。 你需要它的徵兆很簡單——當你發現自己在單一 prompt 裡寫「如果使用者問的是 X，那就……」，你就是在用散文手刻一個路由器。把它抽出來，做成真正的決策。 模式二：工具使用（Tool use）——當模型一直自己編造答案 問模型「我現在的餘額是多少」，它會信心滿滿地報出一個它編的數字。這不是偷懶；模型只知道自己訓練時見過的東西，而你的餘額不在裡面。 工具使用是把 agent 從「知識」系統變成「行動」系統的模式。給它一個函式——get_balance()、search_docs()、run_query()——它就不再憑空捏造答案，而是去抓取答案。 工具使用要解決的失敗模式是在資料缺失時的胡編。當 agent 不知道、又沒有方法去查時，它會用自信的虛構填補空白。工具就是從虛構逃回事實的出口。 微妙的反向陷阱是：工具爆炸。加太多工具，每個決策都會變難，而不是變簡單——模型現在得在三十個選項裡挑對的才能行動。對獨立開發者來說，紀律是讓工具面保持小而精準地命名。三個描述清楚的工具，永遠勝過三十個含糊其辭的工具。 模式三：反思（Reflection）——當工作細緻、「錯得不明顯」又很便宜時 有些輸出明顯對或錯。但多數有趣的工作不是這樣。一段生成的函式通過了 lint，卻仍然有微妙的錯誤；一篇文章讀起來順暢，卻什麼都沒說。 反思加上第二次的檢視：先生成，再針對某個標準批判，然後修正。agent 在你看見之前，先檢查自己的成果。 反思要解決的失敗模式是沉默的錯誤——那些「不會報錯的錯誤」。它是三者中唯一會真正增加成本與延遲的（多一次模型呼叫，有時是一整串），所以是你設門檻最嚴的一個。反思只有在以下情況才值得付出代價： 正確性真的很重要（錯的答案昂貴——錢、資料、信任）。 你能清楚說出標準（「這樣能編譯過嗎？有沒有處理空值的情況？」）。 你寧可燒 token，也不願花自己的review時間。 對於一個快速的查詢或發散式腦力激盪，反思純屬浪費。但對於會碰到使用者資料的那段程式，它是你能買到最便宜的保險。 真正的技能是診斷失敗，而不是選模式 對獨立開發者來說，這才是關鍵的重構——因為當它壞掉時，你是唯一會去 debug 的人： 別先抓模式，先抓失敗。 Agent 對各式各樣的問題都給出含糊、攪在一起的答案 → 路由。 Agent 憑空捏造事實或數字 → 工具使用。 Agent 的答案看起來對，但經不起推敲 → 反思。 你每加一個模式，就買到一項能力，也多付一種新的失敗方式——更多延遲、更多 token、多一個要自己扛的活動零件。獨立開發者的紀律不是三種全疊上去，而是加上能殺掉你實際看到的那個失敗、最小的一個模式，其餘的都別加。 更大的模型修不好路由問題；更好的 prompt 修不好缺失的工具。模式才是藥，不是模型——而知道你需要三者中的哪一個，正是「它為什麼一直這樣」與「好了，修好了」之間的差別。 這是另外兩篇的「模式層」姊妹篇：API vs MCP（你的工具用哪種傳輸溝通），以及 AI agent 仍然做不到的事（任何模式都搆不到的天花板）。這篇談的是模式本身——每個模式為了什麼而存在，又何時才值得。 ...