010. 不是更會聊天，而是開始接管流程｜Agent 的想像力邊界正在外移
如果你有一個晚上不用睡覺、而且可以自己學東西的員工，你會叫他做什麼？
Kelly Tsai 這支原始影片有一個很好的切入點：很多人把 Hermes Agent 或類似工具架好之後，最先想到的仍是回信、整理待辦、會議紀錄。這些當然有用，但它們其實還停在「把聊天助理變勤勞」的層次。
影片真正有意思的地方，是它把鏡頭轉向幾個比較不直覺的開源案例。有人讓 agent 替一個不存在的文明持續寫百科；有人讓兩間無人類 AI 公司互相競爭 GitHub stars；有人把本地電腦活動變成可查詢的個人記憶；甚至有人把 agent 接到感測器、風扇、加濕器與攝影機，讓它真的去管理香菇生長箱。
這些案例不一定都會變成主流產品。部分專案帶有 hackathon 展示性質，影片中的數字也應理解為 Kelly 當下畫面與講者轉述，而不是魚塘替它做外部背書。但它們共同指出一個方向：agent 的價值不只在於「回答」，而在於能不能持續記住上下文、觀測環境、使用工具，並把結果寫回現實流程。
換句話說，問題不再只是「AI 能不能幫我產一段文字」，而是「我願意讓哪一段流程擁有自己的感知、記憶與行動能力」。
給讀者的 Takeaway
- 真正的差異不是 agent 比 chatbot 多會講幾句話，而是它多了記憶、工具與持續運作。
- 影片案例多半是實驗型專案，適合看模式，不適合照單全收成產品判斷。
- 當 agent 接到檔案、電腦事件或硬體設備時，權限與觀測邊界會比 prompt 本身更重要。
021. 虛構文明百科｜當 agent 不再等人提問，而是自己出版世界
第一個案例是一個像 Wikipedia 的網站，但它記錄的不是現實世界，而是一個完全虛構的 civilization。Kelly 在影片中展示的畫面提到，這個網站當時有約 1000 篇文章、54 萬字、88 個時代與 87 種語言，內容由 agent 生成與延展。
這不是一般「請 AI 幫我寫一篇世界觀設定」的玩法。影片中的介紹把它描述成一個自主出版系統：多個 agent 負責撰寫、評論、交叉連結、配圖，以及延展虛構文明的歷史。人類給的東西可以很少，甚至只是 seed，例如「一座會記得島上所有事情的島」。接下來，系統自己把世界觀往外長。
這個案例有兩層啟發。
第一層是創作。過去的 AI 寫作多半是單篇輸出：你給題目，它回一篇文章。這裡更像是一個長期運轉的內容引擎，它要維持人物、年代、語言、制度與事件之間的相互一致。當內容規模上來，困難就不再是「寫得像不像」，而是「記不記得自己寫過什麼」。
第二層是系統。虛構文明只是比較戲劇化的外衣，背後其實是一個知識庫自動維護問題：誰新增條目、誰檢查矛盾、誰負責連結、誰決定哪些事件值得被記錄。這些都是企業知識管理、產品文件、研究資料庫會遇到的問題。
因此，這個案例的商業價值未必在「讓 AI 寫小說百科」，而是在提醒我們：一個 agent 系統若能長期維持自己的 canon，它就可能被改造成團隊內部文件、專案歷史、研究脈絡或客戶知識庫的自動維護者。
當然，風險也同樣清楚。虛構世界可以容忍幻覺，真實知識庫不行。若把這種架構拿去處理公司文件，必須有來源引用、版本紀錄、人工審核與刪改權限。越是會自動出版的系統，越需要知道它從哪裡讀到每一件事。
032. AI 公司競賽｜把策略交給 agent，觀察它怎麼經營一個 repo
第二個案例叫 Gladiator。影片中的描述是：兩間沒有真人操作的 AI company，拿到一樣的 starting point，分別採取不同策略，競爭哪一個 GitHub repo 更受歡迎。
Kelly 展示的設定裡，一邊是 Growth First，一邊是 Quality First。前者比較重視成長與行銷，後者比較重視技術品質。它們要做的產品是類似 LLM Judge 的工具：把同一個 prompt 送給多個模型，比較誰更快、更便宜、更好。換句話說，這不是單純「agent 寫程式」，而是讓 agent 模擬產品團隊會遇到的策略選擇。
這個實驗有趣之處，在於它把常見的新創爭論變成可觀察的 sandbox。到底先衝使用者成長比較重要，還是先把 code 寫穩比較重要？在真實公司裡，這個問題會混入市場、運氣、人脈、品牌與資本；在 hackathon demo 裡，至少可以把兩種策略放在同一個起點下比較。
影片後段 Kelly 也實際把 Hermes Agent 架在 VPS 上，請它 launch 這個 demo。逐字稿中提到，agent 幫她完成了原本需要 clone、install、create companies、start dashboard、run demo 等步驟，並回報結果頁面。畫面中的 demoDB 結果顯示，Growth First 與 Quality First 兩邊都有 stars、cost、heartbeat 等指標，成本約在 3 美元上下。
這裡最值得讀的不是誰贏，而是「agent 作為操作員」這件事。以前工程師會把 README 當成給人看的文件；現在，README 也可能是給 agent 看的操作規格。只要指令足夠清楚，agent 可以讀文件、安裝依賴、跑 demo、找結果頁，再把執行摘要回報給使用者。
這讓開源專案的品質標準多了一個維度：不是只有人類能不能看懂，而是 agent 能不能可靠執行。未來的 quick start、setup guide、error handling、sample config，都會同時服務人類與 agent。
給讀者的 Takeaway
- Agent 可以成為 README 的執行者，而不只是閱讀者。
- 策略 sandbox 的價值在於觀察不同 agent 行為，而不是把結果當商業真理。
- 開源專案若希望被 agent 使用，setup path 必須更清楚、更可重跑、更少隱性前提。
043. 一鍵 VPS 部署｜便利性背後是權限邊界
影片中間有一段帶有明顯贊助與導購性質：Kelly 示範用 Hostinger VPS 一鍵部署 Hermes Agent。她提到 KVM2 規格、2 個 vCPU cores、8GB RAM、100GB disk space，也提到折扣碼、AI credits、Agentic Mail、server region 與 deploy 約數分鐘完成。
魚塘不需要替任何 VPS 方案背書，但這段仍然有分析價值。因為它指出一個很現實的問題：如果 agent 要 24 小時醒著、本地電腦關機也能跑、記憶要持久、任務要定期執行，那它就不能只活在某個人的筆電上。
VPS 的優點很直覺：環境穩定、不中斷、可遠端存取、部署流程可以標準化。對長期 agent 來說，這些是基礎設施，而不是附加功能。Kelly 的示範把複雜安裝流程包成一鍵部署，也代表這類工具正在從「懂 Linux 的人可以玩」往「一般創作者也能架」移動。
但便利性也會放大權限問題。影片提到本地與 VPS 隔開，因此不用擔心本地檔案、帳密與私鑰混在一起。這個方向是對的：把 agent 放在隔離環境，確實比讓它直接拿到整台個人電腦權限更安全。
不過，隔離不等於萬無一失。只要 agent 能寄信、能開 API、能操作 repository、能讀長期記憶，它就仍然持有權限。真正的設計重點是最小授權：不同任務使用不同 token，敏感資料不要混進通用記憶，外部行動要有確認點，日誌要能追蹤 agent 做過什麼。
這段最適合帶走的不是某個主機商，而是部署觀念：長期 agent 需要穩定執行環境，也需要清楚的隔離層。沒有前者，agent 只是偶爾醒來的工具；沒有後者，agent 會變成一個太方便、也太危險的自動化帳號。
054. ScreenPipe 與本地活動記憶｜萬能助理的代價是被記得
第三個案例是 ScreenPipe。影片中 Kelly 提到它是 YC 相關的新創專案，GitHub 上有 2 萬多 stars、2000 多 forks，核心賣點是記錄使用者電腦活動，並讓 agent 能查詢這些本地資料。
聽到 24/7 record your screen，很多人的第一反應會是恐怖。Kelly 也特別說明，這不是單純把螢幕二十四小時錄影上傳，而是讓系統在本地捕捉一些事件，例如你切換 app、點了什麼、開了什麼會、看了哪些內容。它的訴求是 local、private、secure，資料留在本機，再透過 MCP 等方式讓不同 agent 使用。
這正好回到 agent 的核心限制：如果它不知道你剛剛做過什麼，就只能靠你手動餵上下文。你要它整理五分鐘前的會議，它得先拿到會議內容；你要它回答今天跟某人談了什麼，它得先有可查詢的活動記錄；你要它接續你上午的研究，它得知道你打開過哪些文件與網頁。
本地活動記憶，就是在替 agent 補一層「生活脈絡」。它的價值很強，尤其是個人工具場景：整理會議紀錄、回想對話、找回剛剛看到的資料、把一天工作轉成摘要、讓 agent 理解你的專案節奏。
但它也是整支影片中最需要慎重看待的能力。因為「記得所有事情」是一個雙面詞。對個人來說，它可能是超強助理；對公司來說，它可能碰到客戶資料、機密文件、同事對話與合規問題。即使資料留在本地，也必須處理存取控制、保存期限、搜尋權限、刪除權，以及哪些 app 或視窗應排除在記錄之外。
所以 ScreenPipe 類工具的產品關鍵，不只在能不能記，而在能不能讓使用者安心地忘。真正成熟的 agent 記憶系統，應該允許分區、遮罩、暫停、刪除、審計與明確的資料邊界。
給讀者的 Takeaway
- Agent 要變聰明，常常不是缺模型，而是缺可查詢的個人脈絡。
- 本地記憶適合個人效率，但進企業會立刻碰到資料治理。
- 好的記憶系統必須同時設計「記住」與「刪掉」。
065. 香菇生長箱｜當 agent 接到感測器，決策就離開螢幕
影片最後一個案例最有畫面感：用 Hermes Agent 管理一個香菇生長箱。Kelly 介紹的硬體包含樹莓派、溫度感測器、二氧化碳濃度感測器、兩個繼電器、排風扇、加濕器與 USB 攝影機。軟體則是 Hermes Agent 加上一些 Python 工具。
這個系統的基本迴路是：每 30 分鐘讀取一次環境資料，根據菇種與生長階段判斷要不要開排風扇、要不要加濕；調整後再過 10 分鐘檢查數字是否回到預期。影片提到它支援 6 種不同的菇，每種又分 6 個生長階段。作者表示，這套系統已經跑完兩輪猴頭菇栽培，從種下到採收都由 AI 控制。
這個案例之所以重要，是因為它把 agent 從「處理資訊」推向「管理環境」。在螢幕裡，錯一段摘要或跑壞一個 demo，通常還能重來；在現實世界，錯誤會影響溫度、濕度、生長條件，甚至設備安全。因此，實體世界 agent 需要比純軟體 agent 更嚴格的護欄。
最基本的護欄包括：設備控制上限、異常停止條件、人工覆寫按鈕、感測器故障偵測、操作日誌、定期校準，以及不能讓模型自由生成未驗證的控制指令。Agent 可以做判斷，但最終應該被包在明確的控制邏輯裡。
從產品想像來看，香菇不是重點。重點是這個模式可以推廣到其他需要週期觀測與小幅控制的場景：溫室、魚缸、實驗設備、家用能源、庫存環境、甚至某些工業監控。只要任務具有「看資料、判斷狀態、調整設備、再次確認」的迴路，agent 就可能成為決策層。
但這也再次提醒我們：越接近現實世界，越不能只看 demo 有多酷。真正可用的系統，必須讓模型的自由度被工程邊界包住。
076. 從四個案例看同一件事｜Agent 的本體是長期系統，不是單次對話
把這四個案例放在一起看，會發現它們其實在回答同一個問題：agent 到底要拿來做什麼？
虛構文明百科回答的是「能不能讓 agent 維持一套長期知識系統」。AI 公司競賽回答的是「能不能讓 agent 照文件操作、執行策略、產出可比較的結果」。ScreenPipe 回答的是「能不能讓 agent 擁有本地個人脈絡」。香菇生長箱回答的是「能不能讓 agent 透過感測器與設備進入現實世界」。
這些答案都比「幫我回信」更接近 agent 的本質。因為 agent 真正增加的是四種能力：記憶、工具、時間與行動。
記憶讓它不必每次從零開始。工具讓它能操作檔案、API、瀏覽器、資料庫與硬體。時間讓它能定期醒來、長期觀測、在事件發生後反應。行動則讓它不只產出文字，而是改變某個狀態。
也因為如此，agent 的產品設計不能只問「模型夠不夠強」。更重要的問題是：
- 它可以讀什麼？
- 它可以記多久？
- 它可以對外做什麼？
- 哪些行動必須先問人？
- 它做錯時，有沒有停損機制？
- 它的記憶與操作紀錄能不能被審計？
Kelly 這支影片的價值，不在於每個案例都值得照抄，而在於它把想像力往外推了一圈。當 agent 開始接到知識庫、repo、VPS、本地事件與感測器，我們要設計的就不只是 prompt，而是一套持續運作的代理系統。
下一波 agent 工具的勝負，可能不只取決於誰的模型比較會說話，而取決於誰能更可靠地管理記憶、權限、環境與回饋迴路。那才是從助理走向系統的分水嶺。
給讀者的 Takeaway
- Agent 的四個核心能力是記憶、工具、時間與行動。
- 越是長期運作，越需要權限最小化與可審計紀錄。
- 最有價值的應用，通常不是「更會聊天」，而是接到一段真實流程後能穩定運作。