撰寫本文時，Artie 是一個由 17 人組成的小團隊。我們每一個人都在與 Hermes 協同工作——這是來自 @NousResearch 的一款開源 AI Agent 框架（harness）。它運行在德國的一台實體伺服器上，為每個團隊擁有不同的個性，並且會在夜間「做夢」。
這就是它變成現在這個樣子的過程。
一切始於一位工程師的 WhatsApp 聯絡人
幾個月前，我們的一位工程師 Ani（@anirudhsriramzz）正在為自己運行 Hermes。這只是一個個人設置，他透過 WhatsApp 與其對話。
大約在同一時間，我們的 CTO Robin 參加了一場黑客松（hackathon），在那裡朋友向他展示了一整套負責執行工作的 Agents。他帶回來的問題很簡單：我們如何讓 Artie 的所有人都能使用這種能力，而不僅僅是工程師？
我們首先評估了 OpenClaw。它不錯。但我們很容易看到 Agent 偏離軌道並做一些沒人要求的事情，所以在追求規模化之前，我們更想要的是防護欄（guardrails）。因此我們選擇了 Hermes，並開始思考這些防護欄應該是什麼樣子。
戴著眼罩的大腦
我們對這件事的看法是：每家實驗室都推出了一個「大腦」。你可以問它任何問題，它都會回答。同樣的問題問五次，你會得到五個答案，看似合理，卻各不相同。
對於聊天視窗來說，這沒問題。但當你想讓這個大腦真正完成一項工作时，這就成了問題。如果銷售工程師需要針對 25 個開放中的客戶線索進行風險評估，他們每次都需要相同的格式，以便採取行動、比較週度數據並信任該系統。
賽馬佩戴眼罩是為了專注於跑道，而不是看觀眾。技能（Skills）和工具就是眼罩。而框架（harness）則是將它們綁上去的方式。Hermes、Codex、Claude Code 以及其他產品都是同一概念的不同變體：一種決定模型允許做什麼以及其輸出應呈現何種樣貌的方法。
一旦我們以這種方式思考，專案就不再是「設置一個聊天機器人」，而是變成了「為 Artie 的每項工作打造眼罩」。
一台位於德國、年費 60 美元的伺服器驅動了一切
Robin 和 Ani 在某個週末花了大約三個小時設置了第一個 Hermes。我們租賃了 Railway 上最便宜的方案，啟動了一個預設配置文件的 Hermes，然後交給工程團隊去折騰。
五天之內，我們就反覆觸及 Railway 的使用限制。每一次警報都是一次升級提示。這是第一個真正的教訓：一旦團隊真正採用了 Agent，帳單看起來就不像是一個副業項目了。
我們的生產基礎設施運行在 AWS 上並保持在那裡。但這是一個內部的 Agent 沙盒，而非客戶基礎設施，我們想看看能把它做得多便宜。我們找到了 Hetzner（@Hetzner_Online），一家德國託管公司，並購買了一台年費 60 美元的實體機器。如今，Artie 所有的 Hermes 實例都運行在這台機器上。
我們是一家精簡的公司。關於 Artie 的 AI 應用，核心問題一直是：如何在燒錢最少的情況下，讓團隊盡可能地具備 AI 原生思維？Hetzner 那台機器就是第一個答案。
我們真正想要的
有了能夠承擔負載的機器後，我們坐下來決定了 Hermes 的目的。兩個目標。
每個人都有助手。 工程師、銷售、營運、行銷、設計。一個年輕版的自己，幫助你做得更多，而不是取代你的東西。業界普遍擔心 Agent 會搶走工作。我們的經驗恰恰相反：當每個人都有助手時，每個人的交付速度都更快，並能承擔以前無法處理的工作。
人類始終在迴路中。 Hermes 可以執行任何被指示的任務。但在任何內容進入生產環境、文檔或面對客戶之前，必須經過人工審核。
人有專長，Agent 也應該如此
在一個 17 人的團隊中，沒有人只擅長一件事。但每個人都有某個領域特別突出。我們招聘時看重的是這種「尖峰」能力。
所以我們問自己，為什麼我們的 Agent 不應該這樣呢？讓一位Junior 工程師去寫行銷文案是一種浪費。讓一位Junior 行銷人員去改代碼更糟。我們按照對待人才的方式來建模 Agent：給每個 Agent 一個領域、一個個性，以及該領域所需的資源存取權限。
這讓我們擁有一系列 Hermes 配置文件，每個團隊一個。
Hermes Plan 和 Hermes Code 屬於工程團隊。Plan 供技術負責人使用：決定是先做 A 再做 B，還是並行做 A 和 B 稍後做 C，並將其記錄下來。Plan 將工作分派到 Kanban 看板。Code 領取工單並在背景中針對現有代碼庫執行，開啟 PR（Pull Request），然後等待。人類審核 PR，只有通過後才會合併到 master。一個任務完成會觸發計劃中的下一個任務。
誰也沒預料到的副作用是：工程團隊現在大部分時間都花在規劃上。過去人們生活在代碼和執行中。現在他們生活在系統設計和審核中，而 Hermes Code 處理中間環節。
Hermes Sales 在發現電話（discovery call）前進行準備。它研究潛在客戶，弄清他們現有的技術堆疊，並提取當前交易上下文。因為它也擁有我們的文檔和工程知識，它能更进一步：如果潛在客戶告訴我們他們正在使用特定工具遷移數據，Hermes 可以在通話開始前告訴銷售代表該工具通常在哪裡出問題，例如架構漂移（schema drift）。
Hermes Design 和 Hermes Code 共同讓行銷團隊無需拉入工程師即可設計、構建和發布登陸頁面。我們的行銷網站基於 Next.js，且不再使用 CMS。Design 在現有組件系統內工作，在發明新組件前先檢查是否已存在，然後移交給 Code 進行實現。
Hermes BizOps 處理重複性的營運工作：管道審查、對帳、追蹤器更新，以及找出需要人工介入的異常情況。
此外，還有一個預設配置文件用於處理所有不適合上述類別的事務。
我們大多數人透過 Slack 與這些 Agent 溝通。有些人使用 Hermes 桌面版。無論如何，整個流程從被動轉為主動：Agent 已經掌握了代碼庫、文檔、CRM 和互聯網資訊，因此它們可以從各處獲取答案，而不是等待輸入上下文。
技能像代碼一樣版本控制，從第一天起就是如此
配置文件是個性。技能（Skills）才是让它们勝任的關鍵。
技能是一類真實工作的可重用程序：先檢查什麼、哪些來源具有權威性、輸出長什麼樣、如何驗證。我們從第一週就開始編寫自己的技能，並將它們放入 Git 倉庫。每個 Hermes 都從那裡讀取。當技能發生變化時，它就是一次帶有歷史記錄的提交，每個配置文件都會同步更新。
我們刻意避免編寫過多技能。有百萬種方法可以讓 AI 為你服務，網路上的大多數建議都是建立一個 24/7 的全自動 Agent 工廠。如果你有無限的 Token，當然可以。但我們沒有。一個翻閱數百個技能以決定使用哪一個的 Agent，會在決策過程中燒掉大量 Token。因此，我們砍掉了所有顯得不值得其成本的部分，並且繼續削減。
我們最終確立的規則：如果價值明顯，成本就是合理的。如果價值模糊，就不會被構建。
Hermes 做夢
Hermes 有一個 cron 系統。你可以給它一個任務和頻率，它就會自行運行。
受 Anthropic 關於 Agent 記憶研究的啟發，我們用它來模仿人類所做的一件事。在快速眼動睡眠（REM sleep）期間，你的大腦會整理一天的經歷。有些東西被提升為長期記憶。有些則被丟棄。一年中如果你頻繁搬家和旅行，這段時間之所以難忘，是因為沒有重複的事物。
因此，每晚當無人使用時，每個 Hermes 都會「做夢」。它回顧當天所做的事情，決定哪些有用、哪些沒用，將有用的部分提升到記憶中，並降級其餘部分。然後它會向我們的工程師發送一份報告。報告內容類似於：我做錯了這件事，我做錯了那件事，我已經修正了，我存儲了修正結果，並且我忘記了導致錯誤的習慣。
隨著幾週過去，每個配置文件對於應該或不應該為其團隊做什麼變得越來越有主見。我們沒有編程這些觀點。它們來自「做夢」。
為什麼我們運行自己的框架
人們常問為什麼我們不直接使用 Cursor、Codex 或 Claude Code。
我們可以，而且技術上明天就能遷移工作負載。但因為我們自己運行和操作 Hermes，底層的模型可以是任何人的。如果某家實驗室下週漲價，我們就切換。我們的配置文件現在足夠穩定，更換模型不會破壞它們。週一我們可能在使用 Anthropic 的模型；如果價格變動，週五我們可能就切換到了 OpenAI。
第二個原因是功能。如果 Cursor 不支持你需要的身份驗證，或者在你的代碼庫中不斷犯同樣的錯誤，你得提工單並等待。當 Hermes 需要某些東西時，我們直接構建。Hermes 是 Artie 的一部分，像任何內部工具一樣接入我們的系統，而不是我們勉強掛上去並希望它能持續運行的東西。
目前 AI 工程很昂貴，因為 Token 經濟學尚未穩定。有一天，運行這類東西的成本將接近免費。在此之前，擁有框架是我們控制帳單的方式。
目前的狀況與未來展望
Hermes 大概完成了 85% 到 90%。它每天都在處理實際工作。第一次嘗試並不總是最佳嘗試。
因此我們投資於評估（evals）。每當 Hermes 收到問題並產生答案時，我們想知道耗時多少、調用了哪些技能、哪些工具失敗以及原因。我們自託管了 Arize Phoenix，這是一個開源專案，讓我們無需購買額外工具即可獲得這些數據。來自 Hermes 的追蹤數據進入 Phoenix，Phoenix 告訴我們：這個任務調用了五個技能和兩個工具，這個工具耗時最長，那個失敗了，原因是這個。
在此之下，我們透過 Datadog 運行遙測數據：消耗的 Token 數、每個任務的成功率，以及當 Hermes 宕機或記憶體存儲填滿時向值班人員發送的警報。每個任務都在沙盒中運行，我們構建了自己的清理系統，每天清除沙盒。
這一切的重點在於，我們不再需要猜測變更是否讓 Hermes 變得更好。我們修改一個技能，得到一份報告。如果更好，就保留。如果更差，就回滾。
我們還將文檔寫入了 Hermes 伺服器本身：你的配置中有什麼、你被允許做什麼、數據意味著什麼。任何 Hermes 都能讀取它。這意味著我們可以啟動一個 Hermes，其唯一工作是閱讀評估數據並改進其他配置文件。
這基本上就是 Hermes Coach。它在指導 Hermes。
十七個人，一台德國伺服器，一群每晚睡覺、醒來時稍微更敏銳的 Agents。我們構建它，是因為我們很小，卻希望像大公司一樣快速交付。
