Infrastructure — 我學到了什麼
這裡記錄我在「Mac Mini、tmux、Agent Team、gather system、跨機器同步」累積的學習。 每段話末尾的
[📎 source]可反查到原始 obs / insight / memory / AAI wiki。
為什麼這個 topic 存在
(待累積足夠材料後人工撰寫；目前先 append 每日 delta)
每日累積
2026-05-02（2 段，3 個引用 source）
☕ 今天的 infrastructure 不是在講「機器有沒有開著」，而是在講兩件更日常的事：東西堆在哪裡、門是怎麼鎖的；以及一條資料管線怎麼會因為幾個小小漏勾，最後讓你很有把握地看錯世界。
一、基礎設施不再等同於伺服器正常運作，而是要讓隱形的占用與入口都被看見
今天最有意思的地方，是 Mac mini 的問題乍看很像「硬碟快滿了」，但真正的 lesson 比清垃圾深一點。透過 SSH（Secure Shell，從另一台機器安全登入並下指令） 跑完整個 /Users/lunhsiangyuan 掃描後，系統找到 8 個超過 2GB 的檔案；最大的不是照片、影片或桌面備份，而是藏在 model/cache 目錄裡的 AI 模型檔。Ollama models（本機語言模型的模型倉庫） 在 ~/.ollama/models/blobs 裡合計 34GB，另有 Gemma-4-26B 4bit model（量化後比較省空間、但仍然很大的模型） 三個 shard 合計 15.6GB，還有 Chrome 的 on-device model cache 4.27GB。這有點像診間冰箱：你以為空間被日常藥品佔掉，打開才發現角落堆滿很久沒用、但每一盒都看起來「好像以後會用到」的東西。這毫無疑問把 disk cleanup 從「刪大檔」改成「判斷哪些快取可以重抓、哪些模型仍是工作依賴」。
同一天另一條線也在講同一個概念，只是對象從硬碟變成入口。AAI Portal 已經有一套三層式 access pattern：沒登入的人看 Google sign-in，登入但沒白名單的人看 request form，真正被授權的人才看到依 docs[] 過濾後的 document cards。這裡的 server-side guard（伺服器端守門函式，也就是在頁面送出前先判斷能不能看） 已經能用 requireInternalAccess(docSlug) 做 per-document authorization，所以保護 wiki route 不再等同於重寫一套登入系統，而是把既有門禁拿來接到新的走廊上。結論是，infrastructure 的成熟度常常不是多買一台機器或多寫一層 UI，而是你能不能把「儲藏室」與「門禁表」都畫成可查、可重用、可維護的地圖。同 dynamics 也見於醫院感染管制：不是每個病房重新發明隔離規則，而是讓入口、動線、責任人一眼看得出來。
📎 sources: obs-64844 · obs-64820 📚 references:
- Saltzer, J. H., & Schroeder, M. D. (1975) “The Protection of Information in Computer Systems”. Proceedings of the IEEE 63(9):1278-1308.
- Barroso, L. A., Clidaras, J., & Holzle, U. (2013) The Datacenter as a Computer: An Introduction to the Design of Warehouse-Scale Machines. Morgan & Claypool.
- Norman, D. A. (1988) The Design of Everyday Things. Basic Books.
二、資料管線最危險的不是壞掉，而是漏掉一群東西後還繼續自信地產生答案
GPT-5.5 review 把原本的 incremental load plan 判成 REVISE，最關鍵不是它挑了五個錯，而是這五個錯其實都指向同一個 mental model：一條 ETL pipeline（Extract, Transform, Load，把資料抓出來、整理好、寫進資料庫的流程） 只要前面漏人、後面沒補欄位、最後又沒有去重，它就不會大聲爆炸，反而會安靜地產生一份看似整齊的報告。例子很具體：只查 "bispecific antibody" 會漏掉標成 BiTE、T-cell engager、CD3 bispecific 或 dual-targeting antibody 的試驗；只查 "antibody drug conjugate" 也可能漏掉只用商品名或 INN name 的 Phase 2/3 ADC trial。接著 load_trials_from_json() INSERT 時沒有呼叫 classify_phase_group()，新試驗的 phase_group 變成 NULL，下游依 Phase 2/3 找 mechanism tag 的 query 就會像拿著錯的門牌找病人，怎麼走都少一批人。
更麻煩的是，這些 gap 彼此會互相放大。deduplication（去重，也就是把跨查詢重複出現的 NCT ID 合併成一筆） 如果沒做，trial count 會膨脹；batch_mechanism_tag.py 只吐 CSV 並提示 rerun migration，卻沒有直接把 override 寫回 database，這和 incremental load 想要的「一邊補、一邊更新」節奏不合；原本 8 rounds × 3 minutes 的規劃，對 DB-only rounds 也許可以，但對需要 online research 的 Phase 3 deep-dive、target pair analysis、competitive landscape 來說太趕。這毫無疑問不是單一 bug，而是 pipeline 把「查得到」誤當成「查全了」，把「有輸出」誤當成「已寫入」，把「跑完一輪」誤當成「答案可靠」。同 dynamics 也見於 grant review 與臨床資料庫建置：表格填滿不代表 cohort 定義正確，時間到了不代表 evidence 已經成熟。
📎 sources: obs-64890 📚 references:
- Goodhart, C. A. E. (1975) “Problems of Monetary Management: The U.K. Experience”. Papers in Monetary Economics. Reserve Bank of Australia.
- Campbell, D. T. (1979) “Assessing the Impact of Planned Social Change”. Evaluation and Program Planning 2(1):67-90.
- Kahneman, D. (2011) Thinking, Fast and Slow. Farrar, Straus and Giroux.
2026-05-03（2 段，5 個引用 source）
☕ 今天的 infrastructure 像是在整理一間正在運作的診間：不是只看機器有沒有開、硬碟有沒有滿，而是要看哪一扇門先被打開、哪一疊資料真的搬到需要的人手上。
一、自動化不再等同於「有裝工具」，而是 shell 真的會先走到你設計的那扇門
今天最反直覺的點，是 gog 的問題一開始看起來像認證壞掉，其實比較像診間助理明明把正確表單放在櫃檯，但病人一進門先被隔壁舊窗口叫走。Mac Mini 上已經有 ~/bin/gog 這個 wrapper（包裝指令，就是在原本工具外面先補好環境變數的小門房），理論上它會自動注入 GOG_KEYRING_PASSWORD 與 GOG_ACCOUNT，讓 Gmail 操作不用每次手動加 --account。可是 which gog 找到的是 /opt/homebrew/bin/gog，不是 wrapper，所以指令直接報 missing --account。這毫無疑問說明，自動化不是「工具存在」就算數；真正算數的是 PATH（shell 搜尋指令的路線表） 先把誰找出來。
機制其實很生活化：.zshenv 先把 $HOME/bin 放到 PATH 前面，後面又把 /opt/homebrew/bin prepend 到更前面，於是後寫的那行把前面那扇門蓋過去。修好後，which gog 回到 /Users/lunhsiangyuan/bin/gog，gog gmail labels list 可以不加 --account 成功執行，實測寄出主旨 [RHT Intel] gog auth restored on Mac Mini 的 email，拿到 message_id 19deb7bae146da5d。結論是，基礎設施的可靠性常常藏在這種一行順序裡；它不再等同於「我知道怎麼手動補參數」，而是讓 Serie agent 之後能自動送出 RHT intelligence reports，不需要人站在旁邊扶方向盤。同 dynamics 也見於手術室流程：器械都有不夠，真正關鍵是 scrub nurse 第一時間拿到的是對的那一盤。
📎 sources: obs-64932 · obs-64933 · obs-64935 📚 references:
- Saltzer, J. H., & Schroeder, M. D. (1975) “The Protection of Information in Computer Systems”. Proceedings of the IEEE 63(9):1278-1308.（它提醒我們，入口與權限要設計在真正會被經過的位置。）
- Kernighan, B. W., & Pike, R. (1984) The UNIX Programming Environment. Prentice Hall.（Unix 工具鏈的精神，就是小工具靠環境與組合工作。）
- Norman, D. A. (1988) The Design of Everyday Things. Basic Books.（好設計會讓正確動作變成最自然的動作。）
二、跨機器同步不是搬檔案，而是把正在累積的工作記憶放回真正會被使用的地方
另一條線看起來是 disk monitoring，但它真正教的不是「Mac Mini 還有多少空間」。這台機器在 2026-05-03 09:04:36 CST 顯示 /System/Volumes/Data 用了 147 GiB、還有 251 GiB，可用量健康，只有 37% capacity；真正值得盯的是哪些東西正在長大。最大的兩個倉庫是 .ollama/models 32.65 GB 與 .omlx/models 14.57 GB，合計 47.22 GB 的 AI model storage（本機模型倉庫，像放在機器旁邊的工具箱）。Chrome 的 OptGuideOnDeviceModel 也吃了 3.98 GB，yuan-voice-clone 有 6.60 GB，clawd/agents 裡的 agents 目錄有 3.34 GB。這些不是單純垃圾；它們比較像診間裡的耗材與病歷櫃，有些可以清，有些清掉就會讓明天工作變慢。
有趣的是，Serie agent 已經在 Mac Mini 跑了 3 天的 HRSA FORHP TCCP 監控，於 ~/clawd/agents/serie/research/monitor/ 產生 19 個從 2026-05-02 到 2026-05-03 的 timestamped markdown files，還包含 rht_sop.md 與 hourly reports；但真正的 TCCP grant application project 在 MacBook Pro 的 ~/Projects/hrsa-forhp-tccp/，不是 Mac Mini。這就像研究助理每天把資料整理在家裡桌上，主治醫師開會時卻在醫院電腦前找不到。同步 ~/clawd/agents/serie/ 的 519MB 與 ~/.openclaw/agents/serie/ 的 108MB，不只是 rsync 的技術動作，而是把 working memory（工作記憶，正在累積、尚未正式出版的知識） 放回會寫 proposal 的地方；同時還要避免兩台機器同時跑 Serie agent 造成 session lock conflicts。這毫無疑問把「跨機器同步」從備份問題，提升成 workflow ownership 問題。同 dynamics 也見於 multicenter registry：資料存在不代表可用，只有回到分析與決策發生的地方，它才開始算數。
📎 sources: obs-64919 · obs-64984 📚 references:
- Kleppmann, M. (2017) Designing Data-Intensive Applications. O’Reilly Media.（資料系統的難題常在複製、狀態與一致性，而不只是存放。）
- Goodhart, C. A. E. (1975) “Problems of Monetary Management: The U.K. Experience”. Papers in Monetary Economics. Reserve Bank of Australia.（你只盯容量數字，就可能錯過真正影響工作的狀態。）
- Simon, H. A. (1969) The Sciences of the Artificial. MIT Press.（人造系統的價值，要看它如何支援目標與環境，不只看零件本身。）
🔗 延伸：Mac Mini agent sync
2026-05-04（2 段，6 個引用 source）
☕ 今天的 infrastructure 都在講同一件事：系統不是因為有數字就可靠，而是因為你知道那個數字量到的是哪個抽屜、哪個檔案、哪一種工作狀態。
一、監控不再等同於看見數字，而是先確認你量到的是同一個世界
今天最有趣的反轉，是 Mac mini 一開始看起來像突然瘦身成功：SSH 查到 root volume 只用了 15 GiB、capacity 6%，和前一天 147 GiB、37% 的紀錄相比，像是一夜之間少了約 132 GiB。這種畫面很容易讓人鬆一口氣，像體重計突然少了十公斤，第一反應不是懷疑地板歪了，而是想相信自己真的變輕了。可是答案很快被拆開：先前量到的是 root volume（根磁碟區，主要放系統檔案的地方），真正應該追蹤使用者資料的是 /System/Volumes/Data（macOS APFS volume group 裡放使用者資料的資料磁碟區）。重新對準之後，Mac mini 仍是 147 GiB used、251 GiB available、37% capacity，完全貼合 2026-05-03 的歷史值，也和 2026-05-02 cache cleanup 後的 153 GiB 脈絡一致。
這毫無疑問把 disk monitoring 從「跑 df 看容量」提升成「先定義哪個 volume 才是病人」。APFS volume groups（Apple File System 的磁碟區群組，也就是 system 與 data 分開但看起來像同一台機器） 很方便，卻也讓自動化腳本有機會拿錯量尺；再加上 nested SSH command 裡的 awk escaping error，整件事提醒我們，監控最危險的不是沒有資料，而是資料看起來太乾淨。結論是，automation 必須把 /System/Volumes/Data 寫成明確 target，否則每一次漂亮下降都可能只是量錯抽屜。同 dynamics 也見於臨床品質指標：抽錯分母時，感染率或再入院率也會變得很好看，但那不是照護變好，只是地圖畫錯。
📎 sources: obs-65253 · obs-65257 📚 references:
- Kahneman, D. (2011) Thinking, Fast and Slow. Farrar, Straus and Giroux.
- Norman, D. A. (1988) The Design of Everyday Things. Basic Books.
- Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (2016) Site Reliability Engineering: How Google Runs Production Systems. O’Reilly Media.
二、真正成熟的 cleanup 不是把東西丟掉，而是知道什麼會再長回來、什麼可能仍在工作
另一條線看起來像例行清理，實際上是在建立一種更成熟的儲物櫃觀。2026-05-02 11:03 做過的 cache cleanup 到今天仍然有效：Homebrew cache 從 2.8 GB 降到 53 MB，npm cache 從 2.8 GB 降到 1.4 GB，bun install cache 從 2.2 GB 降到 379 MB，合計約 6-7 GiB 的 recovery 沒有馬上長回來。這代表那些 cache（快取，可以重抓或重新生成、但會暫時佔空間的東西） 確實是可以管理的廚房邊角料；清掉之後沒有讓服務停擺，因為 .openclaw 今天 2026-05-04 09:49 仍有新 timestamp，Mac mini 仍在跑 OpenClaw services。這不是「硬碟變乾淨」而已，而是證明清理策略沒有傷到正在動的肌肉。
可是同一天的 file-level scan 也提醒我們，不能把所有大檔都當垃圾。最大的四個 Ollama blob 加起來約 34.8 GB，其中 17.99 GB 的 blob 在 2026-04-09 修改，另外 6.14 GB、5.97 GB、4.68 GB 的 blobs 也都在 2026-04-14 到 2026-04-20 之間更新；du -sh 又確認 .ollama/models 33 GB、.omlx/models 15 GB、Library 11 GB、yuan-voice-clone 6.6 GB、.openclaw 3.9 GB。更微妙的是，.ollama/models directory level 已 94 天沒動，但裡面的 individual blobs 有 4 月 timestamp，所以 directory staleness 不等於 model staleness。這毫無疑問說明 cleanup 不再等同於「找 30 天沒動的大資料夾刪掉」，而是要分清楚 directory timestamp（資料夾自己的修改時間） 和 file-level activity（資料夾裡單一檔案的近期活動）。同 dynamics 也見於研究資料治理：舊資料夾不一定無用，真正要看的是裡面的 cohort、模型、報表是否還在支撐現在的決策。
📎 sources: obs-65261 · obs-65263 · obs-65264 · obs-65270 📚 references:
- Kleppmann, M. (2017) Designing Data-Intensive Applications. O’Reilly Media.
- Sculley, D., Holt, G., Golovin, D., et al. (2015) “Hidden Technical Debt in Machine Learning Systems”. Advances in Neural Information Processing Systems 28.
- Goodhart, C. A. E. (1975) “Problems of Monetary Management: The U.K. Experience”. Papers in Monetary Economics. Reserve Bank of Australia.
[← 回 Alfred Brain Hub]