好,那我直接給你一份完整版——但基於你的真實前提修正:你不跑本地模型,所以那份文件裡的「4060 直通 + Ollama 推論中心」整層是浪費的,16GB RAM + 8 vCPU 拿去餵一張你用不到的顯卡。以下是針對「純雲端調用型 Agent Fleet」的正確架構。
一、容量對比:Mac mini M5 16G vs MS-A2 64G
先定義清楚 workload。你的 agent 是 API-bound worker:Claude Code headless、OpenClaw session、n8n workflow、browser automation。這類 workload 的資源特徵:
| 資源 |
特徵 |
誰是瓶頸 |
| CPU |
95% 時間在等 API response,I/O-bound |
不是瓶頸,可超配 2–3x |
| RAM |
常駐佔用,不可壓縮,不可超配 |
真正的瓶頸 |
| Disk I/O |
context cache、log、git operations |
NVMe 下不是問題 |
| 網路 |
併發 API calls + 爬網 |
雙萬兆完全過剩,但爬蟲隔離有用 |
單一 agent 的實際 RAM footprint(實測級估算):
| Agent 類型 |
常駐 RAM |
峰值 |
| Claude Code headless(單 session) |
1–1.5GB |
2.5GB(大 repo indexing 時) |
| OpenClaw/Hermes 主節點 |
2–3GB |
4GB |
| n8n(含 5–10 個 active workflow) |
1.5GB |
3GB |
| Playwright/Chrome instance |
1.5–2GB/tab context |
4GB(記憶體洩漏前) |
| LiteLLM proxy |
500MB |
1GB |
容量結論:
|
Mac mini M5 16G |
MS-A2 64G |
MS-A2 96G |
| 可分配 RAM |
~9GB(macOS 吃 6–7G) |
~58GB |
~90GB |
| 標準 agent(1.5G/個) |
4–6 個 |
25–35 個 |
45–55 個 |
| 混合 fleet(含 browser、n8n) |
3–4 個 |
18–25 個 |
30–40 個 |
| 實務倍數 |
1x |
6–8x |
10–12x |
而且這還沒算質的差異:Mac mini 上 agent 之間沒有資源隔離,一個 Chrome 洩漏會拖垮全機;PVE 上每個 LXC 有 cgroup 硬限制,炸了只炸自己。
二、PVE 切割架構:三層設計
不做「推論層」,改成 Gateway 層 / Orchestration 層 / Worker 層:
[ PVE Host — 保留 2C / 4GB ]
│
├── Tier 0: Gateway 層(所有 agent 的出入口)
│ ├── LXC 100 litellm-gw 2C / 2GB LiteLLM proxy + claude-code-router
│ └── LXC 101 monitoring 1C / 2GB Uptime Kuma + Netdata + Loki
│
├── Tier 1: Orchestration 層(決定「誰在什麼時候做什麼」)
│ ├── LXC 110 n8n 4C / 4GB event-driven 觸發、webhook 入口
│ ├── LXC 111 openclaw 4C / 8GB OpenClaw/Hermes 主節點
│ └── LXC 112 vaultwarden-ro 1C / 1GB (選配)secrets 唯讀鏡像
│
├── Tier 2: Worker 層(實際幹活的 Claude Code fleet)
│ ├── LXC 120 cc-client-a 2C / 3GB 例:KGI Life 內容 pipeline
│ ├── LXC 121 cc-client-b 2C / 3GB 例:Neteon 站點維運
│ ├── LXC 122 cc-client-c 2C / 3GB 例:ALUXE ERP rebuild agent
│ ├── LXC 123 cc-geo 2C / 3GB geo.tenten.co Agent Harness
│ ├── LXC 124 cc-social 2C / 3GB Batom/Yenchuan/WeFer 排程 fleet
│ └── LXC 125–129 預留 5 格 每格 2C / 3GB,clone 即用
│
├── Tier 3: 髒活隔離區(唯一建議用 VM 的地方)
│ └── VM 200 browser-farm 6C / 12GB Playwright pool + bb-browser MCP
│
└── 剩餘預留:~10GB RAM buffer(絕對不要分光)
vCPU 總分配約 40–44 個 vs 實體 32 threads = 超配 1.3x,對 I/O-bound fleet 是保守值,可以放心。RAM 分配總和 ~52GB,留 6–8GB buffer 給 host page cache 和突發峰值。
為什麼 browser-farm 用 VM 不用 LXC
這是整個架構裡唯一反直覺的決定,三個理由:
- Prompt injection 爆炸半徑——爬回來的網頁內容是不可信輸入,萬一 agent 被誘導執行,VM 的 kernel 隔離比 LXC 共享 kernel 安全一個量級
- Chrome 的 sandbox 在 unprivileged LXC 裡經常要開
nesting + 降權才能跑,等於自己拆安全層
- 記憶體洩漏是常態,VM 可以整台定時 reset(每晚 cron reboot),LXC restart 有時清不乾淨 shared memory
三、與你既有規範的接線
這台不是孤島,它要嵌進你現有的 loop 架構:
Secrets 管理
- Host 上建
/opt/secrets/{client}/,每個 worker LXC 用 唯讀 bind mount 只掛自己客戶的目錄:mp0: /opt/secrets/kgi,mp=/secrets,ro=1
- Agent prompt 裡永遠只出現
/secrets/api-key.age 路徑,符合你的 file-path-only 原則
- 來源 of truth 仍是 Vaultwarden,host 上跑一支 rclone/age 同步腳本,單向拉取
Human Gate 的物理實作
- Worker LXC 的 git remote 全部設成 只能開 PR 的 deploy key(GitHub fine-grained token,無 merge 權限)——Gate 不是靠 prompt 約束,是靠權限做死
- n8n 上的 approval workflow 接 Slack,irreversible action 統一走
lxc-110 發出的審批訊息
Maker/Verifier 分離
- 直接用容器邊界實現:maker 跑在
cc-client-x,verifier 跑在獨立的 cc-verify LXC,兩邊 mount 同一個唯讀 artifacts 目錄但互相看不到對方的 workspace——比同機兩個 process 的「邏輯分離」硬得多
Loop ceiling 的執行層
- 每個 worker LXC 設 cgroup 限制之外,再加 systemd 層的
RuntimeMaxSec 包住 agent process,loop 超時直接被 kill,不依賴 agent 自律
四、Storage 與網路
2TB NVMe 切法(ZFS,不要 LVM-thin):
rpool/ROOT 100G PVE 系統
rpool/data 1.4T LXC/VM disks(每個 worker 32G 夠了)
rpool/artifacts 200G 跨容器共享:build logs、OPTIMIZATION_LOG、產出物
rpool/snapshots 其餘 自動 snapshot(worker 每日、orchestration 每 4h)
選 ZFS 的理由:worker LXC 高度同質(都是同一個 template clone),ZFS 的 block-level dedup 效果顯著,而且 zfs send 可以直接把整個 fleet 備份到你的 Google Drive pipeline(接你現有的 rclone + age 流程)。
網路:
10G port 1 → vmbr0 管理 + Tier 0/1/2(全部 agent 流量)
10G port 2 → 閒置或接 NAS(未來備份用)
2.5G port 1 → vmbr1 browser-farm 專用 bridge
2.5G port 2 → 備援
browser-farm 走獨立 bridge 的意義:可以在 host 防火牆對 vmbr1 做 egress 白名單(只准出 80/443,擋內網),爬蟲被注入也打不到你的管理面和其他 agent。這是四網口在這個場景下唯一真正有價值的用法。
五、Template 策略:這台真正的殺手鐧
Mac mini 加一個 agent 是「手動裝環境半小時」;這台做對 template 後是「30 秒 clone」:
- 建
tmpl-cc-worker(LXC 9000):Ubuntu 24.04 minimal + Node LTS + Claude Code CLI + 你的 /mnt/skills rsync 副本 + systemd 服務框架
- 新客戶/新 loop 上線 =
pct clone 9000 12X → 改 hostname → 掛對應 secrets mount → 啟動
- Skill 更新走一支 host-side ansible playbook(或就是一個 for-loop shell script)批次推到所有 worker——你的 weekly skill-gap discovery loop 產出的新 skill,發佈成本趨近於零
這才是 6–8 倍容量之外的複利:fleet 的邊際擴張成本歸零,你的 agent 數量上限從「硬體」變成「你設計 loop 的速度」。
六、採購與配置決策
| 決策點 |
建議 |
理由 |
| RAM |
買準系統自插 96G(48G×2) |
你的瓶頸只有 RAM,加價幅度小、容量 +55%,是全案 ROI 最高的一筆 |
| 顯卡版本 |
不要 4060 版 |
你不跑本地推論,8G VRAM 是死重,省下的錢貼 RAM |
| CPU 版本 |
9955HX 或 7945HX 皆可 |
I/O-bound fleet 下兩者差距 <10%,7945HX 版省的錢又是一條 RAM |
| SSD |
2TB 單條即可 |
agent 不囤資料,雲端調用型 32G/worker 綽綽有餘 |
一句話總結:這台的正確定位不是「小型 AI 伺服器」,是「agent 航空母艦的甲板」——推理在雲端(Anthropic API)和 Mac Studio,這台只負責讓 20–40 個 agent 有各自隔離、可秒級複製、權限做死的跑道。
