我每天大概花六到八個小時跟 AI 對話。有時可能更多。
我讓 AI 幫我寫程式、審查程式、整理筆記、搜資料、規劃與討論程式架構、幫我把文章推上部落格。（參見前文：用手機叫 AI 幫我發部落格文章——我的 Raspberry Pi 筆記系統）
不過目前有個煩人的點就是我每次開一個新 conversation，前面花的力氣就感覺都喪失大半。
最近開始比較認真的在研究 AI Agent，這篇是我系列文的第一篇（希望不要也是最後一篇😆），我想先聊聊我思考了好一陣子的問題：到底什麼叫做「駕馭 AI」？
Harness （翻譯為馬具、韁具）
AI 的能力其實眾所皆知已經非常厲害了，現在的瓶頸其實是人和 AI 互動的 harness。
Harness 這個字很有意思，它的意思是「馬具」。不是馬的力氣不夠，而是我們需要一套機制把那股強大的力氣導到我們想要的方向上。
套用到 AI 的情境裡也一樣：model 的能力有了，真正的問題是我們能不能真正把它接進工作流程，讓它持續地、有脈絡地為我做事。這個部分我們可以看看 Anthropic 最近的動作也能看得出他們也有一樣的想法。
多數人現在用 ChatGPT 或 Claude 的方式，比較像是去找顧問——我們帶著一個問題去問，它給我們一個答案，然後問到了就結束。
這不是 harness，這是 consult。（硬要一個 AI 腔😆）
真正的 harness 長什麼樣？不只是要讓我的 AI 知道我在做什麼專案、昨天卡在哪裡、codebase 長怎樣，這些只是最基礎的一層。
真正的 harness 是我們說「幫我把筆記中的某某篇發到部落格」，它自己知道要先轉 frontmatter、複製到 blog repo、commit & push；是我們糾正它一次，它下次不會再犯同樣的錯。
Harness 的三個層次
我思考、研究並嘗試了幾個月之後，慢慢發現 harness 不是一個 binary 的東西——不是「有」或「沒有」，而是有深淺之分。大致可以分成三層：
第一層：Access
AI 要能看到我的東西，能記得我是誰。我的筆記庫、我的 code repo、我的行事曆、我的專案脈絡，它都能存取。
上週討論了什麼架構決策、某個 bug 最後怎麼解的、我的某某專案目前走到哪一步——這些東西不用每次對話開始都要重說一遍。
如果每次開新 conversation 都要先花五分鐘交代背景，那就是少了 Access 層。
多數人想像中的「AI 助理」大概就是這個層次。不過光是能看到我們的東西，到真正能幫我們做事，中間差距很大。
第二層：Orchestration
AI 能自己把多個工具串成一個流程。
我們給目標，它自己拆解步驟、選擇工具、排定順序，最後給出結果。
「幫我把筆記庫中的某篇文章發到部落格」——它知道要把 Obsidian 的筆記轉成我部落格的 frontmatter 格式、複製到 blog repo 的正確路徑、跑 git add / commit / push。我定義 what，它處理 how。
如果 agent 只能一步一步聽指令，那它本質上還是一個比較花俏的 CLI，我們的操作方式從打指令換成了打字，但認知負擔沒有真的減少。（還因為要等它 loading thinking，說不定負擔還更大。）
第三層：Adaptation
AI 會從跟我們的互動中學習，主動調整行為。
糾正它三次同樣的事，第四次它不再犯。
它知道我寫 commit message 的習慣、知道我不喜歡某些詞彙、知道我在某些地方的偏好或傾向、知道什麼時候該主動提醒明天的會議資料還沒準備。這一層的關鍵字是 judgment，不只是執行指令，它應該要開始有自己的判斷。
不過說實話，這一層目前整個產業都還在很早期的階段。
但這是 harness 的終極形態：AI 不只是工具，而是一個會隨著時間變得越來越了解我的工作夥伴。An agent，真正的代理人。
我覺得可以開始投入點心力在這三層的研究，一步一步打造能真的幫助我的生活的 AI Agent。
另外一個可以討論的是：harness 越緊，coupling 越深，fragility 也越高。
用 Taleb 的框架來看，如果整個工作流程都掛在 agent 上，那 agent 一掛就癱瘓，那叫依賴而非駕馭。
真正好的 harness 應該要能優美退化（graceful degradation）：AI 在的時候很快，不在的時候我們一樣能工作，只是比較慢（回到跟以前差不多的水準。）
關於這題我也許在未來的文章會再開一集來展開聊聊。
我認為的現有服務天花板
我不是要說 ChatGPT 或 Claude 不好。我覺得它們在 consult 模式下已經非常強了。
但如果我們試著把它們當成一個「長期的工作夥伴」來用，會發現它們基本上被鎖在第一層 Access 的範圍內，而且有結構性的限制。
第一個是 context。（我個人喜歡翻成前後文或脈絡，但業界還是都用 context）
不管 context window 有多大，它終究是一個 session 內的東西。
一旦關掉了這個 conversation，下次來就是一張白紙。
雖然它們有 memory 功能，但我們控制不了它記了什麼、怎麼記、記在哪，而且那個 memory 的顆粒度通常很粗——它記得我是工程師、我喜歡用 TypeScript，但它不記得我上週花了三天在 debug 一個 streaming response 的 race condition。而且難道我們每次對話完都要去檢查它的 memory？這樣 micromanagement？那是在自找麻煩吧。
第二個是工具。
使用雲端服務，能用的 plugin 或 tool 就僅止於平台給的那些。
想接自己的 Obsidian vault？想讓它直接操作某台樹莓派上的檔案系統？想讓它幫忙跑 git 指令？在 SaaS 的架構下，這些事情有的做不到，有的必須透過官方提供的 API 繞一大圈，而且隨時可能因為平台改版就壞掉。（君不見微軟最近連以前標榜「永久授權」的軟體都能發停用聲明了。商業公司終究有商業考量，想要最好的體驗還是得靠自己。）
第三個是資料流向。
我們的 prompt、conversation history、檔案——這些東西上傳之後，我們就不太確定它們去了哪裡、被怎麼處理、會不會被拿去訓練。
對很多個人使用者來說也許這不是什麼大問題，但如果把 AI 深度整合進自己的知識管理流程，裡面有想法、決策紀錄、未發表的文章草稿⋯⋯那這個問題就變得比較實際了。（雖然我現在還是串雲端 API，但希望在可見的未來能夠自己買 GPU 跑起足夠強大的 Model 來 own my own data。）
這三個算是 SaaS 產品的非戰之罪，它們本來就不是設計來讓我們 harness 的——它們是設計來讓 consult 的。
在這樣的架構下，第二層 Orchestration 和第三層 Adaptation 幾乎無法實現，因為我們沒有控制權去定義流程、也沒有機制讓 agent 從錯誤中學習。（我相信 Claude Code 和 Codex 也在努力朝 Agent 的方向發展，但還是那句老話，商業公司有商業考量，輕鬆使用的方便也有其代價。）
從 Consult 到 Harness 的斷層
所以回到開頭講的，真正的問題不是「AI 夠不夠聰明」，而是「我們跟 AI 之間的 緣分 介面夠不夠深」。
從 consult 到 harness，中間隔了一個結構性的 gap：我們並不真的擁有這個 agent。
不擁有意味著沒辦法改造它。沒辦法改造意味著沒辦法讓它真正貼合我們的工作方式。我們只能在別人提供的框架裡面活動，而那個框架是設計給所有人的平均值——不是為我們量身打造的。
這跟「要不要自己架部落格」是差不多的邏輯。WordPress.com 很好用，但我最後還是選了自架 Astro，因為我想控制每一個細節。
用 Notion 管筆記很方便，但我最後搬到了 Obsidian，因為我想要 file-over-app、想要資料留在本地。
AI agent 也是一樣的：只要用得夠深，遲早會碰到「我需要改這個東西但我改不了」的那一刻。
Self-hosted Agent
所以我最終還是決定自己架。
Self-hosted agent 不是唯一的解法，但它是目前我認為最能往 harness 的深處走的方式。
在第一層 Access，就拿回了完整的控制權——memory 怎麼存、存多少、存在哪，都能自己決定。想接什麼工具就接什麼工具，Obsidian vault、Discord bot、SearXNG、git、cron job，全部可以自己串。model 選哪個、system prompt 怎麼寫（雖然還是有上限，但此處按下不表）哪些 tool 開放不開放，都在自己手上。
在第二層 Orchestration，則可以定義自己的 workflow——把多個工具組成一條 pipeline，讓 agent 理解「幫我發文章」背後的完整流程，而不只是執行單一指令。
第三層 Adaptation 目前不管自架還是 SaaS 都還很粗糙，但至少自架給了我們調教的空間——我可以設計 feedback loop，讓 agent 把我的指正寫進 system prompt 或 memory，而不是每次都從零開始。
代價呢？當然有。得自己處理部署、維護、升級、安全性。得花時間理解框架的內部機制，不然出了問題會 debug 到想哭。得接受這東西不會像 ChatGPT 打開就能用——它需要投入時間去調教。
但這跟所有 own-vs-rent 的決策一樣：如果用得淺，SaaS 絕對夠用，自己架反而是浪費時間。如果用得深，深到開始碰天花板、開始覺得「我想改但我改不了，好痛苦」，那自己架就變成值得的投資了。
對我來說，那條線在大約三個月前就已經被跨過了。
這個系列要做的事
接下來的系列文，我會把我從零開始架一個 self-hosted AI agent 的過程攤開來寫。包括我怎麼選框架、怎麼部署、怎麼把 context window 的 token 數砍掉 65%、怎麼把 64 個 tool 精簡到 35 個、怎麼串接 Obsidian vault 和 Discord⋯⋯
我不打算寫成 step-by-step 的教學——那種東西看官方文件就好了。（現在這個年代可能問問 AI Agent 就好了）我更想記錄的是每個決策背後的 why，以及我踩過的、那些搜不太到的坑。
這系列不是要說服讀者非得自己架不可。我寫的是我的路，大家讀完之後可以自己判斷這條路適不適合自己。
下一篇預計會聊框架選型——市面上一堆 agent framework，我怎麼挑、挑的時候在意什麼、為什麼最後選了 Hermes Agent。