Hermes 文件能力再进化！一口气接住 3 类资源块，单文件支持 50MB

#探寻人工智能，人与AI全新序章#

7 月中旬，Hermes 又补上了一条很关键的文件链。

以前调用 MCP 时，文字和图片通常比较顺利。可一旦 MCP 返回的是 PDF、Word、Excel、压缩包或音频，事情就可能变得很奇怪。

MCP 明明告诉 Hermes：

文件已经找到名称是 report.pdf类型是 application/pdf大小也正常

Hermes 最后拿到的却可能只有文件名和类型，真正的文件内容没有进入工具结果。

从用户角度看，这就像快递员已经把包裹送到门口，Hermes 只抄下了快递单号，却没有把包裹拿进屋。

现在这条链终于补齐了。

Hermes 可以接住 3 类 MCP 资源块：

ResourceLink：资源链接EmbeddedResource：嵌入资源AudioContent：音频内容

PDF、Office 文档、压缩包等二进制文件可以自动保存到本地文档缓存；文字资源直接进入当前结果；音频会变成 Hermes 能继续使用的 MEDIA: 文件。

单个二进制资源上限为 50MB，同时加入了文件名清理、路径保护、错误 Base64 拦截和超大文件拒绝。

这次升级解决的，是 MCP 从“找到资源”到“真正把资源交给 Agent”的最后一步。

MCP 找到文件，为什么以前还是用不了

MCP 可以理解成 Hermes 和外部服务之间的一层标准接口。

通过 MCP，Hermes 可以连接：

企业知识库云盘项目管理系统聊天平台数据库文档系统本地软件内部业务系统

这些系统返回的内容，不一定都是一段文字。

例如，从知识库里查一份制度文件，可能返回 PDF；从项目系统里取一个附件，可能返回 Excel；从会议系统里拿记录，可能返回录音；从网盘获取资料，可能返回压缩包。

MCP 返回这些内容时，经常采用不同的数据块。

文字大致是这样：

TextContent

图片大致是这样：

ImageContent

Hermes 原来对这两类内容处理得比较完整。

但非图片二进制资源可能采用：

EmbeddedResourceResourceLinkAudioContent

旧处理链没有完整接住它们。

于是就会出现三种结果：

只看到文件元数据只显示“二进制数据，共 N 字节”资源块直接没有出现在最终结果里

MCP 服务器并没有失败，文件也确实返回了。问题出在 Hermes 收到结果后的最后一段转换过程。

这也是为什么有些 MCP 看起来“能找到文件，却不能继续处理文件”。

3 类资源块，到底有什么区别

这次新增支持的 3 类资源，名字看着有点技术，理解起来并不复杂。

第一类是 EmbeddedResource（嵌入资源）。

它相当于 MCP 直接把内容装在结果里一起交回来。

如果里面是文字：

会议结论项目说明错误详情资料摘要

Hermes 会直接把文字放进工具结果。

如果里面是 PDF、Office、压缩包等二进制内容，Hermes 会先解码，再保存到本地文档缓存，并把真实路径返回给 Agent。

第二类是 ResourceLink（资源链接）。

它不是文件本体，更像一张取件凭证：

资源地址文件名称MIME 类型对应的读取工具

Hermes 不会看到一个链接就绕过 MCP，自己随便访问网络。

它会保留资源地址，并提示 Agent 调用原 MCP 服务器提供的 read_resource 工具继续读取。

第三类是 AudioContent（音频内容）。

音频数据会进入音频缓存，再转换成：

MEDIA:/本地/音频路径

这样 Hermes 后续就可以继续转写、分析或交给支持音频的工具处理。

这三类资源分别解决了：

内容已经装在结果里资源需要继续向 MCP 读取返回的是音频媒体

PDF、Office 和压缩包会保存到哪里

当 MCP 返回嵌入式二进制资源时，Hermes 会把它保存到 Document Cache（文档缓存）。

工具结果中会出现类似信息：

文件已保存到：/实际缓存目录/report.pdf类型：application/pdf

这里最重要的变化，是 Agent 终于拿到了一个真实存在的本地路径。

有了路径以后，Hermes 才能继续：

检查文件大小读取文档内容提取第一页查看目录调用转换工具交给其他 Skill 或工具处理

文件名会优先取资源 URI 最后的有效部分。

例如：

slack://files/F123/quarterly-report.pdf

保存时会尽量保留：

quarterly-report.pdf

不过 Hermes 不会原样相信外部返回的文件名。

它会处理：

../ 等目录穿越字符换行和控制字符过长文件名异常后缀空文件名

文件名最长限制为 150 个字符，并尽量保留原来的扩展名。

这不是单纯为了整齐。

MCP 连接的是外部系统，文件名和 URI 都属于外部输入。如果不做清理，一个恶意名称理论上可能试图把文件写到缓存目录之外。

新版已经用端到端测试确认，包含目录穿越和控制字符的 URI，最终仍只能写进指定缓存目录。

50MB 上限，不只是防止硬盘被塞满

这次为单个 MCP 二进制资源设置了 50MB 上限。

超过上限时，Hermes 会明确返回文件过大，不会继续保存。

更细的一点是，它会在 Base64 解码前先检查数据长度。

这是因为很多 MCP 二进制内容采用 Base64 传输。

一个 50MB 文件转成 Base64 后，字符串会比原文件更大。如果先完整解码，再检查文件大小，内存里可能已经塞入了一份很大的数据。

新版的顺序是：

先检查 Base64 长度→ 判断是否可能超过 50MB→ 符合要求才解码→ 解码后再次确认→ 保存到文档缓存

遇到错误 Base64，也会返回明确的解码失败，而不是把异常内容写进文件。

这次新增的资源测试一共有 29 项，覆盖了：

PDF 完整写入文字资源直接返回ResourceLink 继续读取音频缓存错误 Base64超大文件恶意路径控制字符超长文件名错误结果中的资源文字

说明这次不是只补一个“能保存 PDF”的小功能，而是在补完整的资源交付边界。

ResourceLink 为什么不能直接下载

看到 ResourceLink，很多人可能会想：

既然已经有地址，Hermes 为什么不直接下载？

因为这个地址不一定是普通网页链接。

它可能是：

slack://files/F123drive://document/ABCcompany-docs://report/2026memory://project-notes

这些 URI 只有对应的 MCP 服务器知道怎么处理。

它们可能需要：

当前登录身份企业权限会话令牌内部路由特定 API

如果 Hermes 绕开 MCP，直接把地址当成公网 URL 访问，不但可能失败，还会破坏原有的权限边界。

新版会把 ResourceLink 整理成一段可执行提示，大致告诉 Agent：

这是一个资源链接名称是什么类型是什么URI 是什么请调用哪个 MCP read_resource 工具读取

而且指向的是 MCP 工具真正注册后的名称，例如：

mcp__slack__read_resource

不会再给模型一个实际上不存在的工具名，让它凭空猜测。

这条设计我认为很稳妥：

文件本体已经返回→ 保存到本地只返回资源凭证→ 继续通过原 MCP 读取

音频资源终于能进入后续工作流

AudioContent 的处理也很值得关注。

以前 MCP 返回一段音频时，即使数据已经包含在结果里，Hermes 也不一定能把它转换成后续工具认识的形式。

现在音频会保存到专用缓存，并返回：

MEDIA:/本地音频文件

后面就可以继续执行：

语音转文字会议录音总结提取待办事项识别说话内容生成时间线交给支持音频的模型

这意味着 MCP 文件交付不再只围绕文档。

例如一个会议 MCP 可以同时返回：

会议标题参与人员文字摘要原始录音相关附件

Hermes 能把文字直接使用，把附件保存到文档缓存，把音频保存成 MEDIA:，再分别交给合适的工具。

这才像一条完整的资料处理流水线。

用 4 步验证文件是不是真的拿到了

升级以后，不要只看 Hermes 有没有说“文件已获取”。

我会做 4 步验收。

先检查 MCP 服务器是否正常。

把下面命令里的服务器名称换成自己的：

hermes mcp test <服务器名称>

修改 MCP 配置后，可以在 Hermes 会话中执行：

/reload-mcp

然后交给 Hermes 一段明确的验证任务：

请调用对应的 MCP 工具获取目标文件。完成后不要只返回文件名称，请依次确认：1. MCP 返回的是文字、资源链接、嵌入资源还是音频；2. 如果是资源链接，继续调用该 MCP 的 read_resource；3. 如果是二进制文件，返回保存后的本地绝对路径；4. 检查文件是否真实存在，并返回文件大小；5. 尝试读取第一页、目录或基础元数据；6. 暂时不要删除缓存文件。

我判断交付成功的标准是：

有真实绝对路径文件确实存在文件大小不是 0类型与预期一致至少能读取基础内容或元数据

只返回：

文件名：report.pdf类型：application/pdf

还不能算真正交付完成。

自动落盘，不等于所有文件都能自动读懂

这次升级解决的是文件交付问题，不是万能解析问题。

Hermes 能把 Word、Excel、压缩包或 PDF 保存下来，不代表当前模型一定能直接理解每一种格式。

后续效果还取决于：

系统有没有对应解析工具当前模型是否支持该文件类型文件是否加密压缩包是否有密码文档内部结构是否复杂MCP 返回的 MIME 类型是否正确

例如 PDF 保存成功以后，可以继续用文档解析工具读取。

Excel 可能需要 Python、表格工具或专门的 Skill。

压缩包通常要先检查内容，再解压到安全目录。

音频要有 STT（语音转文字）能力，才能进一步整理内容。

所以正确流程应该是：

MCP 找到资源→ Hermes 接住资源→ 保存到安全缓存→ 验证文件存在→ 选择合适工具解析→ 再交给模型总结或处理

另外，50MB 是单个嵌入式二进制资源的保护上限，不代表所有 MCP 服务自身也支持 50MB。服务器、网络和上游平台仍可能有更小的限制。

干货总结

Hermes 这次补齐了 3 类 MCP 资源：

EmbeddedResource→ 文字直接进入结果→ 二进制文件保存到文档缓存ResourceLink→ 保留 URI、名称和类型→ 继续调用原 MCP 的 read_resourceAudioContent→ 保存到音频缓存→ 转换成 MEDIA: 文件

关键数字是：

单文件上限：50MB文件名上限：150 个字符新增资源测试：29 项覆盖：PDFOffice 文档压缩包音频文本资源资源链接

使用时，不要只问：

文件找到了吗？

应该继续确认：

文件保存到哪里？是否真实存在？大小是多少？能否读取第一页或基础元数据？

Hermes 以前通过 MCP 能找到越来越多外部资源。

现在，它终于开始把这些资源真正接进自己的工作流。

从“返回一个文件名”，到“获得真实路径并继续处理”，中间看似只差一步，却决定了 MCP 究竟只是一个查询接口，还是能真正替 Agent 完成交付的文件通道。