Self-hosted AI Agent 實戰系列

這個系列在講什麼

這個系列不是在教「五分鐘架好 AI Agent」，而是把我真的在做的事情攤開來：為什麼要 self-host、 框架怎麼選、context 怎麼瘦身、tool 怎麼收斂、搜尋後端怎麼替換、還有整個系統怎麼維持在可運作的狀態。

如果在意的是 可控性、長期成本、工作流整合， 而不是單次 demo，這個系列應該會比較有參考價值。

目標讀者

• 想從 ChatGPT / Claude 的 chat UI，走向真正可操作的 agent workflow 的工程師
• 在意 self-hosting、資料可控性、成本結構與 automation quality 的 builder
• 已經在用 Obsidian / notes / scripts / bots，想把它們接成一個系統的人

文章列表

1. 為什麼我決定自架一個 AI Agent — 已發布
   從 consult 到 harness，為什麼我要自己掌握 agent 的 orchestration 與 adaptation。
2. 框架選型：Hermes vs 其他方案 — 撰寫中
   我實際在意的不是 feature list，而是 context、tooling、automation 與 operator fit。
3. Context Window 瘦身：從 199K 壓到 68K tokens — 規劃中
   如何拆掉高噪音系統 prompt、降低重複 context、把 retrieval 變得便宜。
4. Tool 精簡：從 64 個 tools 收斂到 35 個 — 規劃中
   工具不是越多越好，重點是模型什麼時候會誤用，以及怎麼縮小 decision surface。
5. 搜尋後端替換：用 SearXNG 取代商業搜尋 API — 規劃中
   降低成本、增加可控性，並讓搜尋和私有資料流更容易接在一起。
6. 把 Obsidian vault 接進 agent workflow — 規劃中
   不是單純 RAG，而是讓 agent 真正讀寫我每天在用的知識系統。
7. Discord / chat surface 串接與 operator UX — 規劃中
   怎麼把 agent 放進日常通訊介面，而不是把人逼回 terminal。
8. Self-hosted reliability：cron、watchdog、fallback 設計 — 規劃中
   agent 不是 demo，得能在凌晨壞掉時還有辦法被發現、被修復。
9. 從 single-agent 到 multi-agent orchestration — 規劃中
   什麼時候真的需要 subagents，什麼時候只是把問題複雜化。
10. 把 agent 變成長期可維護系統 — 規劃中
    最後一篇談 observability、技術債、版本演進與「不要讓自己的 automation 反咬自己」。

關鍵成果

• Context window 使用量從 199K 降至 68K tokens（-65%）
• Active tools 從 64 精簡至 35
• 以 SearXNG 替換商業搜尋 API，實現更接近完全 self-hosted 的搜尋層