Hermes Agent 把文件放在哪裏？工作目錄、上下文文件與存儲機制
摘要
Hermes Agent 的文件不是一個雜亂文件夾，而應分成三類各有職責的存放位置：工作目錄承載當前任務的輸入、生成物與工具執行，有明確邊界，工具不能任意越過工作區訪問系統路徑；上下文文件（SOUL.md、USER.md、MEMORY.md）不是普通附件，而是決定 Agent 如何理解關係與工作背景的長期約定；雲存儲是 Agent 的文件工作區，用於集中保存任務資料與產出，單個文件的上傳下載最大支持 1 GB，刪除只移除該 Agent 雲存儲中的託管副本、不影響你電腦上的原始文件，且一個 Agent 的文件不會自動被另一個 Agent 使用。三類分開的實際價值在於：你能明確知道一份資料放在哪裏、能被誰讀到、會不會長期留存，從而避免把敏感信息寫進長期上下文，也避免重要資料只存在於一次聊天記錄裏。
引子：文件放在哪裏，決定 Agent 能不能接着做
設想一個常見的失敗場景。你把一份項目簡報粘貼進聊天窗口，讓 Agent 提煉重點，它做得不錯。三天後你回來説"按上次那份簡報，再幫我出一版排期"，結果它給出的排期明顯對不上——因為那份簡報只存在於三天前的那段對話裏，不在任何可穩定取回的位置。
再設想另一個場景。你為了讓 Agent"記住"服務器信息，把一段包含密鑰的配置寫進了長期上下文文件。之後每次會話，這段內容都會作為背景被讀取。這不是記憶功能的正確用法，而是一次不必要的敏感信息長期暴露。
這兩個場景指向同一個問題："文件放在哪裏"不是收納習慣問題，而是決定了資料能否被穩定取回、會被誰讀到、以及會留存多久。 這篇文章把 Hermes Agent 的三類存放位置及各自的邊界講清楚。
一、三類位置，三種職責
先建立整體圖景。
| 位置 | 裝什麼 | 誰來讀 | 生命週期 |
|---|---|---|---|
| 工作目錄 | 當前任務的輸入、生成物、工具執行產物 | 本次任務的工具與執行過程 | 與任務相關，偏短期 |
| 上下文文件 | SOUL.md、USER.md、MEMORY.md | 每次會話都會被讀取的長期約定 | 長期，需主動維護 |
| 雲存儲 | 任務資料、參考文檔、需要留存的產出 | 需要時由你或 Agent 取用 | 長期，可下載、重命名、刪除 |
三者最容易被混淆的是上下文文件與雲存儲。它們都"長期存在"，但讀取方式完全不同：上下文文件是每次會話的背景，屬於常駐；雲存儲裏的文件是按需取用的資料，不會自動進入每次對話。
這個區別直接決定了敏感信息的處置方式——後面會具體講。
二、工作目錄：任務發生的地方，也是邊界所在
工作目錄用於當前任務的輸入、生成物和工具執行。它有兩個關鍵屬性。
第一，它是任務現場。 讀文件、寫文件、執行命令、生成產物都發生在這裏。一個能"接着做"的 Agent，需要在這裏保留任務的中間狀態，而不是每次從零開始。
第二，它有明確邊界。 工具不能任意越過工作區去訪問系統的任意路徑。這個限制不是能力缺失，而是讓"讀寫文件"這件事既可用又可控的前提。如果一個 Agent 能在整個文件系統上自由讀寫，那麼任何一次誤判都可能造成不可逆的後果。
理解這個邊界有實際意義：當你希望 Agent 處理某份資料時，正確做法是把資料放進它能訪問的位置，而不是期待它去你電腦的任意目錄裏找。
三、上下文文件：不是附件，而是長期約定
這三份文件常被誤解為"我上傳給 Agent 的資料"。實際上它們的角色完全不同——它們決定 Agent 如何理解這段關係和工作背景。
| 文件 | 主要作用 | 典型內容 |
|---|---|---|
SOUL.md | 角色、語氣、行為邊界 | 先給結論再給依據；不展開投資建議 |
USER.md | 穩定的用户偏好與畫像 | 偏好中文；術語保留英文原文 |
MEMORY.md | 跨會話事實、項目狀態與決策 | 項目名；上週做出的決定 |
它們與普通上傳資料的三個區別：
區別一：讀取時機不同。 上下文文件是常駐背景，每次會話都會被使用；雲存儲裏的文件只在需要時取用。
區別二：內容形態不同。 上下文文件適合放穩定的準則、偏好與事實條目，不適合放大段原始資料。把一份十頁的簡報塞進 MEMORY.md，只會讓每次會話都背上不必要的負擔。
區別三：敏感度要求不同。 因為常駐，所以不要把密碼、密鑰或不必要的敏感信息寫進長期上下文文件。需要 Agent 處理敏感配置時，用受控的方式提供，並在任務結束後清理，而不是讓它長期留在背景裏。
第三點是這篇文章裏最需要記住的一條實踐規則。
關於三份上下文文件如何共同決定 Agent 的行為，可參考《Hermes Agent 的性格從哪裏來？Persona、用户偏好與長期記憶如何共同作用》。
四、雲存儲：Agent 的文件工作區
雲存儲的定位是 Agent 的文件工作區：在控制台裏集中保存任務資料、上傳整理文件，或把需要的文件下載到本地。
4.1 什麼時候該用它
當 Agent 需要參考資料、工作文檔，或需要一個清晰的位置保存任務產出時，就該用雲存儲，而不是依賴一次聊天粘貼。兩個典型用法：
- 先上傳再處理：先上傳項目簡報，再讓 Agent 提煉重點。資料留在雲存儲，下次仍可引用。
- 為週期性工作建目錄：給一項持續進行的工作建立文件夾並持續維護，產出有穩定歸處。
4.2 需要知道的具體限制
這些是使用前應當明確的事實：
- 單個文件的上傳和下載最大支持 1 GB。 超過這個大小需要先拆分或壓縮。
- 刪除只移除該 Agent 雲存儲中的託管副本，不會刪除你電腦上的原始文件。但刪除前仍應先下載之後可能還需要的內容——託管副本刪掉就沒了。
- 一個 Agent 的文件不會自動供另一個 Agent 使用。 如果需要在兩個 Agent 之間流轉資料，需要顯式處理，不要假設它們共享同一份文件區。
- 上傳時保持頁面打開，等待上傳完成並確認文件出現在當前文件夾中，再繼續其他操作。
4.3 目錄結構不必複雜
一個實用建議是：通常不需要複雜目錄。分別建立「資料」「處理中」「完成」三個文件夾就足夠應付大多數場景。只有在確實能提升查找效率時，再增加層級。
判斷目錄是否健康的一個標準：目錄名稱能否清楚説明資料對應的任務。 如果你自己都需要點進去才知道里面裝了什麼，那這個命名就不合格——Agent 同樣依賴這些名稱判斷資料用途。
五、一份資料應該放在哪裏：判斷流程
面對一份具體資料，按下面的順序判斷。
第一問：它是準則、偏好還是事實條目？
是 → 上下文文件。準則進 SOUL.md，偏好進 USER.md，事實進 MEMORY.md。注意只放提煉後的結論，不放原始大段內容。
第二問：它是需要長期留存、可能反覆引用的資料或產出？ 是 → 雲存儲。上傳後歸入合適的文件夾，命名能説明用途。
第三問：它只服務於當前這一次任務？ 是 → 工作目錄處理即可，不必長期留存。
第四問：它包含密碼、密鑰或敏感個人信息嗎？ 是 → 不要寫進長期上下文文件。 用受控方式提供，任務結束後清理。
這個流程的價值在於把"隨手一放"變成有依據的選擇。絕大多數使用上的困擾，都源於第一問和第二問被混在一起——把大段資料塞進上下文文件，或把該長期留存的資料只留在聊天裏。
六、常見問題與排查方向
| 現象 | 更可能的原因 | 建議動作 |
|---|---|---|
| Agent 説找不到之前那份資料 | 資料只存在於歷史聊天裏，未落盤 | 上傳到雲存儲後再引用 |
| 無法上傳或下載文件 | 單個文件超過 1 GB，或上傳過程中離開了頁面 | 檢查文件大小；重新上傳並保持頁面打開 |
| 換了一個 Agent 後文件都不見了 | 文件屬於原 Agent 的雲存儲，不會自動共享 | 從原 Agent 下載後再上傳到新 Agent |
| 刪除雲存儲文件後本地文件也擔心丟 | 誤解刪除範圍 | 刪除隻影響託管副本，不影響本地原始文件 |
| 每次會話都很"重"、響應偏慢 | 大段原始資料被塞進了長期上下文文件 | 從上下文文件移出，改放雲存儲 |
| 擔心敏感信息長期暴露 | 密鑰或密碼被寫進了長期上下文文件 | 立即從上下文文件移除，改用受控方式提供 |
最後兩行是同一類問題的兩面：上下文文件被當成了資料倉庫。 判斷標準很簡單——如果一份內容不需要每次會話都被讀到，它就不該待在上下文文件裏。
七、LightVela 的做法：讓存放位置可見、可控
Hermes 在機制上區分了工作目錄與上下文文件，但資料的託管與取回仍需使用者自己安排。LightVela 的方向是把文件工作區做成可見、可控的產品能力：
- 集中的文件工作區：在控制台裏上傳、新建、整理、下載、重命名、刪除，不必離開產品去處理文件。
- 邊界明確：工作目錄有邊界，工具不會越過工作區訪問系統任意路徑。
- 刪除語義清晰：刪除只移除該 Agent 雲存儲中的託管副本，不動本地原始文件，並在刪除前提示先下載。
- Agent 間隔離：不同 Agent 的文件區相互獨立，避免資料在不該共享的地方互通。
- 與其他能力解耦：切換模型不會改寫雲存儲中的文件。
小結
- 三類位置各有職責：工作目錄（任務現場，有邊界）、上下文文件（常駐長期約定）、雲存儲（按需取用的資料與產出）。
- 上下文文件與雲存儲最容易混淆，區別在讀取時機：前者每次會話常駐，後者按需取用。
- 雲存儲的具體事實：單文件上傳下載上限 1 GB；刪除只移除託管副本、不影響本地原文件；一個 Agent 的文件不會自動供另一個 Agent 使用。
- 目錄不必複雜，「資料 / 處理中 / 完成」三層足夠；命名要能説明用途。
- 一條必須遵守的規則：不要把密碼、密鑰或不必要的敏感信息寫進長期上下文文件。
- 會話變"重"或響應偏慢時，先檢查是否把大段資料塞進了上下文文件。