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 使用。
- 目录不必复杂，「资料 / 处理中 / 完成」三层足够；命名要能说明用途。
- 一条必须遵守的规则：不要把密码、密钥或不必要的敏感信息写进长期上下文文件。
- 会话变"重"或响应偏慢时，先检查是否把大段资料塞进了上下文文件。