一台主機、零個公開埠：我的 AI agent 工作台

很多人問 AI agent 到底能不能拿來做「正事」。我的答案是可以，但前提是你得把它當成一套系統來架，而不是一個聊天視窗。這篇是我目前的配置，重點不在工具清單，而在每一個取捨。

全貌

1. 遠端存取：Tailscale，而不是開埠

我最常用 agent 的時間，其實是在手機上：通勤時丟一個「幫我查一下昨晚那個服務為什麼停了」，到辦公室時答案已經在那裡。

要從外面連回主機，最直覺的做法是開一個埠、或用 Cloudflare Tunnel 這類服務對外公開。我兩個都沒用，選了 Tailscale：

• 只有我自己的裝置連得到。沒有公開網址，不會被掃描。
• 不用設定防火牆、不用憑證，手機裝個 App 就好。
• 前面再加一層反向代理做登入驗證，就算裝置掉了也還有一道門。

取捨是：沒裝 Tailscale 的裝置就是連不到。公用電腦、別人的電腦都不行。對一個只有自己用的工作台，這是我願意接受的代價。

判斷準則很簡單：如果只有你自己要用，就不要把它放到網際網路上。

2. 模型代理：不綁死在單一家

agent 背後接的不是單一家模型，而是一個本機的模型代理層：agent 只認一個 API 端點，背後可以切換或分流到不同供應商。

好處是：某家額度用完、或某個模型在某類任務表現差，換掉只要改設定，不用動 agent 本身。旁邊再掛一個小服務專門盯用量，避免月底才發現額度燒光。

3. 本機元搜尋：SearXNG

agent 很常需要查網路。直接讓它打各家搜尋 API，會遇到限流、爬蟲阻擋、或要付費。

我在本機用 Docker 跑了一個 SearXNG：它會同時查多個搜尋引擎、合併結果，並提供 JSON API。agent 查資料時先打本機，速度快、結果穩定，也不用把每一次查詢都交給第三方 API。

4. 排程：讓 agent 每天先替你看一遍

目前有三個排程，全部是獨立 session、權限最小化：

排程	頻率	權限	做什麼
健康巡檢	每天 08:00	唯讀	跑基線檢查，回報服務、記憶體、連線、磁碟
版本摘要	每天 07:30	可寫資料夾	追蹤幾個上游專案的新版本
來源檢查	每週一	可寫資料夾	檢查公開資料來源的入口是否還活著

兩個設計原則：

1. 巡檢一定是唯讀。巡檢的 agent 不能重啟服務、不能清日誌、不能改設定——它只負責看和報告。要動手，由人決定。
2. 任務說明寫成「每次都能獨立看懂」。排程每次都開全新 session，不會記得上一次聊了什麼，所以 prompt 必須自帶所有前提與禁止事項。

5. 資料蒐集：零相依、可追溯

資料蒐集器刻意寫成零 npm 相依：Node.js 內建的 node:sqlite 與 node:zlib 已經夠用，連政府提供的 ODS 試算表都是自己解壓、解析。

少一個相依套件，就少一個會在半夜壞掉的理由。每份原始檔都保留雜湊值，數字有疑問時可以追回當時下載的版本。七個月少了六萬人那篇的數字就是從這裡來的。

6. 這個部落格

最後一塊是對外的出口：Markdown 寫文章 → 推到 GitHub 私有 repo → Cloudflare 自動建置部署，大約一分鐘上線。

部落格是唯一對外公開的東西，而且它是純靜態檔案，跟主機完全沒有連線。主機壞了、斷網了，網站照常運作。

回頭看，最重要的三個決定

1. 對外面是零公開埠。能用私有網路解決的，就不放上網際網路。
2. 自動化的權限越小越好。看的歸 agent，動手的歸人。
3. 把「維運」當成一等公民。每加一個元件，就同時想好：它怎麼被檢查、壞了怎麼知道、怎麼還原。

工具會一直換，這三條我覺得不會。