自用agent-harness的迭代心得：一個V2EX貼文攤開的，是代理框架的隱性成本帳

一則發在V2EX「分享創造」板的長文，近日在技術社羣引起討論。用戶woodchen分享了自建agent-harness框架的實踐細節，從工具調用到記憶設計再到沙箱架構，內容幾乎是一份自研代理框架的工程帳單。這類貼文的價值在於，它把大型模型廠商包裝在產品裡的工程決策，還原成一個個人開發者可以逐項核算的成本結構。

框架的底層：工具迴圈與回報機制

原po自述，框架的理論與方法「大部分都是抄codex和claude code」，桌面端用Wails撰寫。核心設計包含幾個層面。基礎是工具集，包括ask_user_choice、memory、call_mcp、workspace、read image、save file、send file等，沒有工具代理就無法執行任務。調用方式採round trip循環，下一步由代理自行決定。

其中一個工程教訓值得注意：工具必須在任何情況下回傳result，包括停止、暫停、錯誤與成功。缺了回報，代理就失去判斷依據。另一個教訓是進程必須後臺運行。原po早期以前端回傳result、後端持續調用，結果發現只要切換到未掛載元件的頁面，任務就暫停。改為本機後端持續執行、需要人工幹預或完成時發系統級通知，問題才解決。這條迭代路徑，實際上是把「頁面生命週期」從執行成本結構中剝除的過程。

快取與上下文：最貴的那一欄

原po對記憶與上下文工程的著墨，反映自建代理最直接的開銷在token成本。他採用四重記憶（基於RAG），並強調記憶設計「不要影響快取前綴」，否則快取頻繁失效，成本會大幅上升。對應的工程手段是把prompt分層組裝，靜態快取與動態內容剝離；上下文壓縮採漸進式；工具也漸進披露，避免一次性塞入佔用過多上下文、幹擾注意力。

這套做法與商業代理產品的取捨方向一致：模型推理費用隨上下文長度非線性上升，快取命中率直接決定邊際成本。個人開發者沒有企業級折扣，對這一欄的敏感度反而更高。

沙箱與安全：把執行風險隔離在遠端

網頁端的部分，原po用遠端機器加固定容器（提供接口、可喚起臨時容器）加一次性執行的臨時容器，來跑AI生成的Python腳本，做完即銷毀。他的原話是「放本機跑等於死」。Office三件套檔案的生成，也是靠skills加AI寫腳本實現。桌面端則在安裝後部署獨立的Python環境，不動機器上的主環境。

安全工程被列為單獨一節，重點是防止任何外部資訊影響代理，因為代理在本機運行。人為幹預方面，重要操作透過ask_user_choice把關，人的指令優先於代理的規劃。

這本帳說明了什麼

從工程工時角度，這個貼文與先前AI改寫工程工時帳的討論屬於同一條脈絡：代理工具的價值最終落在工時與token兩個可量化項目上。原po自己也交代了用途邊界，claude限速時改小東西會用自己的框架，大任務仍不放心交給它。

有趣的一段插曲是結尾：他讓claude替他寫說明，claude指出後端API有one-api的影子，堅持把「全自研」改成「重新設計實現」。原po承認實際上改了one-api超過七成的程式碼，模型仍能辨認出來源。這個細節側面顯示，模型對程式碼譜系的記憶力，正在成為工程帳裡一個新的查核項目。

整體而言，這則貼文沒有披露用戶量、營收或融資數字，本質是一個興趣驅動的自用專案。它的參考價值在於把代理框架的工程決策逐項攤開：快取前綴、上下文分層、沙箱隔離、回報閉環式設計，每一項都對應可核算的成本或風險。至於這條自建路線能否與claude code、codex等商業產品長期並存，原po的使用行為已給出階段性答案：小任務自用，大任務仍回頭依賴官方服務。