我经常在聊天里收到值得留下的东西：一段讨论、几张截图、一份资料，或者随手想到的问题。把它们收藏起来并不难，难的是过几天还能找得到，而且知道当时为什么保存。

我想要的流程很具体：看到素材，发给 QQ 或微信里的助手；助手先保留原文，再帮我整理；最后在电脑、平板和手机的 Obsidian 里都能查看。我把三端同步插件的刷新间隔设为 1 分钟，日常使用几乎无感，不需要反复点击手动同步。平时换设备，也不用重新搬运整套笔记，更不用让某台电脑一直开着。

于是，我把 Obsidian、阿里云 OSS、服务器上的 Hermes，以及 QQ／微信机器人连到了一起。下文的“QV 助手”只是我对 QQ、微信这两个入口的简称，不是需要额外购买的软件。

搭建过程中，最有价值的改进并不是换了一个模型，而是逐渐分清了几个问题：消息有没有到服务器、原文有没有保存、附件有没有下载、AI 有没有整理、手机有没有同步。把这些问题分开，系统才容易检查和维护。

本文整理于 2026 年 10 月 22 日。实际部署基于 Hermes 0.21.4，并做过定制修改。教程中的在线服务采用中国内地云服务器、阿里云 OSS、国内模型 API、QQ 和微信；Obsidian 与 Hermes 分别在自己的设备和服务器上运行。模型示例采用 DeepSeek 官方接口，属于供读者复现的配置，不代表本文改动了现有服务器的模型设置。

一、先看懂整套流程

这套系统可以分成四层：

• QQ／微信助手；负责什么：QQ 接收完整转发的群聊消息；微信接收多选复制后粘贴发送的文字等素材；不负责什么：微信入口目前不能接收原生合并转发的聊天记录

• Hermes 与归档程序；负责什么：调用模型、保存素材、执行笔记整理；不负责什么：不能凭空恢复未收到的消息

• 阿里云 OSS；负责什么：保存 Markdown 和附件，作为各端共同访问的存储；不负责什么：不会自己理解笔记或处理编辑冲突

• Obsidian 与同步插件；负责什么：阅读、编辑、把远端文件同步到本机；不负责什么：关闭或未同步时，不保证立刻看到新内容

QQ／微信发送素材
        │
        ▼
服务器上的 Hermes 消息入口
        │
        ├─ 原始素材 → 本地持久保存 → 上传 OSS 并校验
        │
        └─ AI 整理 → 写入整理结果 → OSS
                                     │
                       ┌─────────────┼─────────────┐
                       ▼             ▼             ▼
                  电脑 Obsidian  平板 Obsidian  手机 Obsidian
                       └────── 每 1 分钟自动同步 ────┘

原文保存和 AI 整理是两项工作。AI 超时、拒绝处理或者接口余额不足时，已经成功保存的原文仍然可以留下。但“已保存到服务器”和“已上传 OSS”也不是一回事，后文会专门解释。

二、准备什么，先做到哪一步

我的目标是个人使用、少量并发，模型通过 API 调用，不在小服务器上运行大模型。准备这些东西即可开始：

• 电脑、平板和手机上的 Obsidian；用途与选择：三端保存和阅读同一套 Markdown 知识库

• Remotely Save 插件；用途与选择：把 Obsidian 仓库与 OSS 对接

• 中国内地的 Linux 云服务器；用途与选择：运行 Hermes 与归档程序；本文命令按 Ubuntu 类系统举例

• 阿里云 OSS 存储空间；用途与选择：建议从独立、私有的测试桶开始

• 国内模型 API 账号；用途与选择：本文以 DeepSeek 官方接口为例

• QQ 机器人应用；用途与选择：需要应用凭据和测试账号权限

• 微信账号；用途与选择：用于完成 Hermes 微信入口的扫码接入

• 对应版本的软件文件；用途与选择：Obsidian 安装文件、Remotely Save 插件文件、Hermes 官方源码发行包

小型云服务器可以先用于单人文本流程，是否需要扩容取决于实际负载。我的实例在一次只读检查中，Hermes 服务内存约为 228 MiB；这是当时服务的占用，不是整机占用或峰值，也不是配置保证。

建议分三次完成，而不是一口气把所有功能都打开：

1. 先让电脑、平板和手机同步同一份测试笔记。

2. 再实现 QQ、微信分别与 Hermes 正常对话。

3. 最后接入素材归档、批次收集、失败重试等增强功能。

其中前两项属于基础配置；第三项有我自己加的程序。本文会明确标出这些定制部分。只安装原版 Hermes、写几句提示词，并不会自动获得下文全部可靠性机制。

三、先把 Obsidian 和 OSS 接起来

1. 先整理一个测试仓库

Obsidian 的仓库就是本地文件夹。我的聊天素材默认采用下面的结构，读者可以用一个空仓库先试：

我的知识库/
├── AGENTS.md
├── 00_Inbox/
│   └── 文件传输助手/
│       └── YYYY-MM-DD.md
└── attachments/

文件传输助手 在这里是一个笔记目录名，不是接管微信自带的文件传输助手账号。机器人默认把当天的素材和整理结果追加到该目录下的日记。

先新建一篇 同步测试.md，写一句容易识别的文字，再放入一张不含隐私的小图片。不要拿整个正式知识库做第一次同步实验。

2. 创建私有 OSS 存储空间

在阿里云 OSS 控制台创建存储空间，选择中国内地地域、标准存储、私有访问。服务器和 OSS 尽量选同一地域，便于后续管理。

这里最容易误解的是：笔记要在多台设备上同步，不需要把桶改为公开。 各设备通过各自配置的凭据访问即可。

然后在 RAM 访问控制里，为这套知识库创建专用身份和授权。使用独立测试桶时，可以先把权限限制到这一个桶，所需操作通常包括列出文件、读取、写入；如果同步插件需要传播删除，还要单独考虑删除权限。不要直接给它整个账号的 OSS 管理权限。权限的资源范围和操作名称以阿里云的访问控制说明为准。

记录下面几项，保存在自己的密码管理工具里，不要写进笔记或网站文章：

• Bucket 名称。

• Region，例如 cn-hangzhou。

• 访问地址 Endpoint。

• 专用身份的 AccessKey ID 和 AccessKey Secret。

3. 配置 Remotely Save

在 Obsidian 中启用 Remotely Save。已经准备好可信插件文件时，也可以把 main.js、manifest.json 和随包提供的 styles.css 放入仓库的 .obsidian/plugins/remotely-save/，重新打开 Obsidian，再到第三方插件中启用。不要把下载到的整个上层文件夹误当作插件目录。

选择 S3 or compatible 类型，填写 OSS 参数。下面是新建测试环境的示例，桶名和凭据必须替换成自己的值：

• 服务类型；示例或说明：S3 or compatible

• Endpoint；示例或说明：https://s3.oss-cn-hangzhou.aliyuncs.com

• Region；示例或说明：cn-hangzhou，与桶所在地域一致

• Bucket；示例或说明：自己创建的测试桶名称

• Access Key ID / Secret；示例或说明：专用 RAM 身份的凭据

• 请求地址风格；示例或说明：Virtual Hosted；不要强制 Path Style

• 远端目录；示例或说明：所有设备一致，且必须与服务器写入位置对应

• 自动同步间隔；示例或说明：1 分钟，即 60 秒；电脑、平板和手机都设置

S3 在这里是兼容接口类型，存储仍然是阿里云 OSS。上述 S3 访问地址及请求风格可对照阿里云的S3 接入说明和兼容性说明。

还有一个容易混淆的地方：服务器使用 OSS 原生 SDK 时，通常配置 https://oss-cn-hangzhou.aliyuncs.com；插件使用 S3 兼容接口时，按其要求配置对应地址。不要把一个界面的 Endpoint 不加判断地复制到另一个界面。

初次配置时，点击插件的连接检查，然后等待一次自动同步；排查时也可以手动触发一次。在 OSS 控制台找到刚才的测试笔记，核对它的完整对象路径。这一步是安装验收，日常使用依靠每分钟的自动同步。

我的电脑、平板和手机都通过同步插件连接同一套知识库，自动同步间隔设为 1 分钟。本机检查到的 Remotely Save 版本为 0.5.25，配置为双向同步、空远端前缀；保存后立即触发同步关闭，但每 60 秒的定时同步仍然开启。空前缀意味着相对路径直接对应桶根目录。其他设备需要各自配置插件，不能以为电脑设好后，平板和手机就会自动完成设置。

比如本地是 00_Inbox/文件传输助手/同步测试.md，云端可能直接是同一路径，也可能前面多了一个远端目录。以后服务器写笔记时，必须写到这个实际位置。两边都显示“连接成功”，但写进不同目录，手机一样看不到。

4. 接入平板和手机，完成三端自动同步

电脑配置完成后，在平板和手机上分别建立用于同步的本地仓库，启用同一插件，填写同一桶和相同远端目录，并把自动同步间隔都设为 1 分钟。首次接入时先检查同步预览或计划，确认不会把远端已有内容误判为待删除数据，再执行同步。

我建议按这个顺序检查：

1. 电脑创建测试笔记，等待自动同步后，平板和手机都能看到。

2. 三端的图片都能正常显示，附件文件也确实存在。

3. 在平板或手机修改测试文字，电脑在后续自动同步后能看到修改。

有了这个小闭环，再迁入正式资料。我的日常体验是：一分钟的间隔已经很短，阅读和切换设备时几乎感觉不到同步过程，不需要手动刷新。它依然是定时同步，不是多人同时编辑的实时协作；设备休眠、应用被系统暂停或网络不可用时，要等恢复运行后继续同步。

5. 加密和同步范围要提前决定

如果插件启用了文件内容或文件名加密，直接往 OSS 写明文 Markdown 的脚本通常不能与它无缝混用。必须先统一加密方式，再接入服务器，不能指望“写到同一个桶”就自动兼容。

我的本机配置未设置内容加密密码。插件对自身设置文件做的混淆，也不能当作笔记已经加密。当前冲突策略是保留较新的版本，这仍有覆盖另一边修改的可能，因此我保留备份，也尽量避免与机器人同时编辑同一篇笔记。

同样，.obsidian/ 里可能包含插件配置和凭据。是否同步这部分应单独决定；不要把整个配置目录当作公开教程附件。同步也不能替代独立备份，误删可能随着同步传播到其他设备。

四、在服务器安装 Hermes，先跑通一轮文本对话

1. 固定版本，准备独立运行环境

我的实际基线是 Hermes 0.21.4，对应源码提交为：

004fa2e7cbbe77d7544988104941ff99da6e79c9

这是说明我的改动建立在哪个版本上，不是在建议读者永远停留在旧版本。新版的依赖、安装方式和配置字段可能不同，定制代码也需要重新适配。

下面采用“已准备好对应版本官方源码包，在服务器本地安装”的方式，不依赖第三方整合脚本。准备文件时核对版本及发布方提供的校验信息；只有同名压缩包，不能证明内容相同。本文没有附带完整源码发行包。

使用普通 Linux 用户登录服务器。以 Ubuntu 24.04 的软件包为例：

sudo apt update
sudo apt install -y python3 python3-venv python3-pip git build-essential
python3 --version

0.21.4 的 Python 版本要求为 >=3.11,<3.14。如果系统自带的 Python 不在这个范围，先解决运行环境，不要强行忽略依赖错误。系统软件源采用云厂商提供的境内镜像。

把源码发行包解压到 ~/.hermes/hermes-agent/，确认这一层能看到 pyproject.toml。接着执行：

cd ~/.hermes/hermes-agent
python3 -m venv venv
source venv/bin/activate
python -m pip install -i https://mirrors.tuna.tsinghua.edu.cn/pypi/web/simple --upgrade pip
python -m pip install -i https://mirrors.tuna.tsinghua.edu.cn/pypi/web/simple -e '.[messaging]' oss2
hermes --help

这里为这次安装临时指定清华大学 PyPI 镜像，没有修改系统全局 Python 配置。如果某个固定版本尚未被镜像收录，应先核对发行包和依赖版本，不要删掉版本约束硬装。

这些命令是根据已核实的版本要求整理的安装参考；本次写作没有重新创建一台空服务器做全新安装验收。已经有 Hermes 服务的机器，也不要直接用这个目录覆盖正在运行的版本。

2. 接入国内模型 API

在 DeepSeek 开放平台创建 API Key，确认账户可正常调用。运行：

hermes setup

在模型配置环节选择 DeepSeek；所用版本没有该选项时，使用它提供的兼容接口配置入口。主要参数是：

• Base URL；填写方式：https://api.deepseek.com，以该版本输入框要求为准

• API Key；填写方式：在官方平台创建的密钥

• Model；填写方式：使用官方文档当前可调用的模型 ID，不凭模型昵称猜测

写作时官方文档列出了 deepseek-flash 等可用 ID，具体能力和费用以DeepSeek API 文档为准。配好后，先在 Hermes 命令行里发一句普通文本，确认真的得到回复。

这里先只启用需要的文本模型和消息功能。读图、语音等后续能力，需要另行检查所选国内接口及适配器的支持情况；文本对话成功不能证明它们也成功。

模型列表里能看到某个名字，也不等于实际能调用。一次真实的简单请求，比只看配置页更可靠。

五、连接 QQ 和微信，只让自己的账号使用

1. QQ 入口

到 QQ 开放平台创建机器人应用，按照平台当前要求开通所需的私聊能力，把自己的账号加入测试范围，并取得应用 ID 和密钥。

在 Hermes 环境中运行：

hermes gateway setup

选择 QQ Bot，按提示填写参数。0.21.4 对应的应用凭据字段包括 QQ_APP_ID 和 QQ_CLIENT_SECRET。

先发一条普通文字，确认服务器收到事件且能回复。再记录这条入站事件的发送者标识，作为自己的允许名单。QQ 机器人的用户 OpenID 不应直接当作日常 QQ 号码填写。

2. 微信入口

再次运行接入向导，选择 Weixin，按提示使用微信扫码并确认登录。这条链路使用微信机器人接口，和企业微信自建应用、微信客服是不同的接入方式。

扫码完成后，同样先检查普通私聊：能否接收文字、能否回复、是否识别为自己的账号。不要在第一步就用合并聊天记录测试，否则很难判断是接入故障还是消息类型限制。

3. 同时检查网关和渠道的权限

我的部署过程中修过一个很实际的问题：配置文件里写了“只允许自己”，但其他入口仍可能有放行所有用户的开关；还有某些环境变量，在当时的版本里根本没有被读取。

以下是 0.21.4 部署中使用的渠道策略结构。它是应合并进原文件的片段，不是完整配置文件，不要覆盖模型和其他既有设置：

platforms:
  qqbot:
    dm_policy: allowlist
    allow_from:
      - "替换为自己的QQ用户OpenID"
    group_policy: disabled
  weixin:
    dm_policy: allowlist
    allow_from:
      - "替换为自己的微信入站用户ID"
    group_policy: disabled

同时检查 .env 中的 QQ_ALLOWED_USERS、WEIXIN_ALLOWED_USERS 是否与本人身份一致，并关闭 QQ_ALLOW_ALL_USERS、WEIXIN_ALLOW_ALL_USERS 和 GATEWAY_ALLOW_ALL_USERS。新版配置的层级可能调整，应按安装版本核对，不要把不同版本的示例混在一起。

更改后重新加载服务，并验证本人允许、陌生身份拒绝。不能仅凭 YAML 看起来正确就结束检查。

密钥保存在私有配置中，确保运行用户可读、其他普通用户不可读。对已经存在的配置文件，可以执行：

chmod 600 ~/.hermes/.env ~/.hermes/config.yaml

六、让服务在退出终端后继续运行

前台运行正常以后，再交给系统服务管理器。下面是与这套目录布局相配的用户级 systemd 示例，适用于确认源码入口可用的环境。

先创建用户服务目录：

mkdir -p ~/.config/systemd/user

再用文本编辑器创建 ~/.config/systemd/user/hermes-gateway.service：

[Unit]
Description=Hermes messaging gateway

[Service]
Type=simple
WorkingDirectory=%h/.hermes/hermes-agent
Environment="PATH=%h/.hermes/hermes-agent/venv/bin:/usr/local/bin:/usr/bin:/bin"
ExecStart=%h/.hermes/hermes-agent/venv/bin/hermes gateway
Restart=on-failure
RestartSec=10
UMask=0077

[Install]
WantedBy=default.target

保存后执行：

systemctl --user daemon-reload
systemctl --user enable --now hermes-gateway.service
sudo loginctl enable-linger "$(whoami)"
systemctl --user status hermes-gateway.service --no-pager

enable-linger 用于让该用户的服务在退出登录后继续运行。确保系统时间正确，笔记按 Asia/Shanghai 生成日期，避免当天素材写进另一天。

如果安装程序已经创建了服务，应检查并使用现有服务，不要再启动第二套同账号消息接收进程。排查日志可以用：

journalctl --user -u hermes-gateway.service -n 80 --no-pager

到这里，应该分别完成“多端文件同步”和“QQ／微信连接 AI”两个基础闭环。聊天内容自动进 Obsidian，还需要下面的归档层。

七、真正决定体验的，是素材归档层

我最初以为，告诉机器人“记得保存原文”就够了。后来发现，这个要求不应该完全交给模型执行：模型可能还没开始整理就报错，可能忘记调用保存工具，也可能因为无法处理内容而停止。

所以，我把它改成了程序流程：素材先落本机持久存储，之后才进入依赖模型的处理步骤。

1. 我实际加了哪些程序

下面这些文件是个人部署里的定制模块，名称用于解释结构，不是原版 Hermes 自带的安装命令：

• obsidian_fallback.py；作用：在消息入口识别应归档的素材，提前保存

• archive_queue.py；作用：持久队列、状态查询、去重与上传重试

• archive_media.py；作用：下载和缓存通道交付的附件，识别部分错误响应

• sync_obsidian.py；作用：写入 OSS 笔记、追加校验、保存恢复副本

• human_batch.py；作用：批次收集；我的日常控制消息是 111 开始、000 结束并整理

• owner_context.py；作用：为本人提供有限的跨渠道近期历史参考

完整复现增强层，需要取得与 Hermes 版本匹配的这些模块、网关接入改动、配置说明和服务文件。本文没有附带这套定制代码的完整发行包，因此基础配置步骤可以照做，增强部分不能只靠复制规则文件完成。 我也不建议拿别人目录里的几个同名脚本直接覆盖现有服务。

2. 保存状态必须说清楚

在这套实现里，消息先进入服务器私有 SQLite 队列和附件缓存，再由一个大约每 30 秒触发的短任务尝试上传。失败后保留任务并退避重试，写入成功还要读回核对。

• 已接收；实际含义：消息已经到达处理入口，尚不等于可靠保存

• 已落本机／pending；实际含义：原文已在服务器持久保存，上传可能仍未完成

• 原文归档完成／done；实际含义：该归档任务已完成 OSS 上传和读回校验

• AI 整理完成；实际含义：整理结果也已成功写入，应单独核实

如果附件下载失败，任务不能因为“文字已经收到”就宣称整份素材归档完成。如果 AI 处理失败，应保留原文并说明整理未完成。

这解决的是模型失败时的素材留存问题，不会让模型必须处理某种内容，也不能恢复从未到达服务器的消息。

3. 原文和整理结果放在哪里

我默认把同一天的原文和整理结果放在同一篇笔记：

00_Inbox/文件传输助手/YYYY-MM-DD.md

笔记里通过小标题区分素材、来源、时间和 AI 整理。不要让模型把推测写进“原文”，也不要为了让笔记更简洁就直接删掉素材。

“同一篇笔记”指默认的 Markdown 记录，不是整个系统只产生一个文件：图片和其他二进制附件仍单独放在 attachments/；服务器还保留队列、缓存和恢复数据。跨天、指定其他笔记位置等情况也需要单独处理。

4. OSS 追加需要保护，不能当成本地文件追加

我使用的日记追加方式，实际上涉及读取旧内容、合并后写回整个对象。为降低覆盖和重复风险，后来补上了：

• 同一服务器上的写入串行执行。

• 用稳定的操作 ID 防止重试重复追加。

• 修改已有笔记前保存旧内容和计划写入内容的恢复副本。

• 写入后读回校验，异常时不报告成功。

• 创建独立笔记时拒绝意外覆盖同名文件。

这些措施能减少问题，但锁只能协调这台服务器上的写入，锁不住另一台设备的 Obsidian。我的习惯是让机器人整理时，不同时手工编辑同一篇日记；需要自己改时，先同步，再编辑，改完再同步。

如果以后需要经常多人或多端同时编辑，应重新设计写入方式。当前方案没有实现通用的实时协同编辑。

八、把自己的整理规则写下来

我把知识库规则放在仓库的 AGENTS.md，再让服务器上实际执行整理的技能和规则文件引用、落实这些约定。文件名本身没有魔法：如果 Hermes 的工作目录和技能没有读取它，放在本地仓库里也不会自动生效。

下面是一份适合个人素材库的规则示例，可以按自己的目录改写：

# 聊天素材整理规则

- 默认只保存待整理素材；普通聊天不自动写入知识库。
- 没有另行指定时，保存到 00_Inbox/文件传输助手/YYYY-MM-DD.md。
- 先确认原文已持久保存，再进行 AI 整理；AI 整理失败不得删除原文。
- 原文、识别或转写内容、AI 补充必须分开标记。
- 保留已有笔记；整理结果追加写入，不擅自覆盖整篇文章。
- 图片和文件保存为附件，正文使用可在 Obsidian 中访问的链接。
- 不把临时下载链接当作附件已经永久保存的证明。
- 明确指定其他目录时，按本次要求处理，并确认实际保存结果。
- 普通对话需要入库时，等待我明确说明。
- 只有上传和读回校验成功，才能告诉我“已保存到知识库”。
- 不自动安装大型依赖或修改无关服务。
- 过程通知和新写的操作说明使用简体中文。

这里有两类要求：目录、文风等可以交给规则引导；“先保存”“失败重试”“访问控制”等，应尽量落实为程序行为。规则保存成功，只证明规则写进去了，还需要观察后续任务是否真的遵守。

普通对话不进入 Obsidian，也不等于聊天系统完全不保留会话历史。这两个保存范围需要分别理解。

九、我希望日常只做这三件事

1. 一条素材：加一个明确标记

对于无法自动辨认的纯文本，我会明确写：

素材：
这里是需要保留的内容……

请保留原文，再按主题整理，放到文件传输助手。

这样可以减少“这是一条普通聊天，还是待保存材料”的歧义。

2. 一批素材：收完再整理

在已经安装批次收集模块的部署中，使用方式是：

111

这是我使用的开始收集指令。等待收集提示后，连续发送需要整理的内容。全部发完，再单独发送结束并开始整理的指令：

000

也就是 111 → 连续发送素材 → 000。这里的关键是独立控制消息，素材正文里出现这些数字，不应被误当作指令。相比单纯要求模型“等我发完”，程序收集状态可以保存到磁盘，重启后仍能恢复。111 和 000 是我的使用约定，不是原版 Hermes 的通用命令；复现时要让自己的批次收集程序识别这两个指令。

我的实现按渠道、会话和用户区分批次，上限是 200 段或约 20 万字符；超出后应明确分批，不能静默截断。收集中的本地保存也不应冒充已经上传 OSS。

普通聊天另外采用短时间合并和忙时排队。它的临时合并缓冲不具备素材批次相同的重启保障，因此重要材料更适合走明确的素材收集流程。

3. 换一个渠道接着聊

QQ 和微信仍是独立会话，我加的是本人身份绑定后的近期历史参考：默认参考另一渠道近 7 天、最多 12 条可见消息，并限制总长度。

这可以帮助接续“刚才整理的那份材料”，但不是把全部聊天记录无限合并。旧消息不能变成新的操作授权，也不应因为被引用就再次归档。开始新话题时可以明确说“不引用之前的对话”。

十、图片、PDF、CSV、视频，分别看待

我现在会把媒体能力拆成三个检查点：平台有没有交付文件、程序有没有完整保存、AI 有没有理解内容。

• 普通文字；这套部署能确认到哪一步：有原文入队、OSS 写入与读回的验证记录；使用时怎么检查：核对原文是否完整、是否出现整理结果

• JPG／PNG 等图片；这套部署能确认到哪一步：既有真实笔记存在图片附件和识别结果；使用时怎么检查：换用模型后重新验证读图能力；检查附件能打开

• CSV；这套部署能确认到哪一步：不能把文本处理能力视为所有 CSV 已验收；使用时怎么检查：用小文件检查编码、表头、行列和完整性

• PDF；这套部署能确认到哪一步：尚无覆盖全部 PDF 类型的端到端验收；使用时怎么检查：分别测试文字版、扫描版、密码保护和大文件

• 视频；这套部署能确认到哪一步：不能从“媒体事件可接收”推导出全片分析已实现；使用时怎么检查：检查是否取得完整视频，再单独验证提取或理解流程

• 实况照片；这套部署能确认到哪一步：尚未验证静态图与动态片段完整配对保存；使用时怎么检查：不能把收到一张 JPG 当作完整保留实况照片

QQ 转发附件的独立下载模块还设置了来源、文件大小和数量限制，其中单文件下载上限为 25 MiB。这个数值是该模块的限制，不是所有通道统一的附件承诺。

临时链接也可能过期。有时下载返回 HTTP 200，内容却是一小段错误说明，所以程序还需要检查实际响应和文件内容，不能只看状态码。对不认识的二进制格式，当前实现可能以 .bin 保存，文件扩展名和预览能力还需要核对。

十一、QQ 直接转发群聊，微信用多选复制粘贴

QQ 和微信的素材入口，我实际采用了两种不同的操作方式。

QQ 可以接收完整转发的群聊消息。 我把需要整理的群聊记录转发给 QQ 助手，由服务器接收后进入保存和整理流程。对于一大批聊天素材，这个入口比较顺手；附件保存仍需要按前面的大小和格式要求检查。

微信目前不能接收同样的原生合并转发记录，但可以多选后复制。 我的实际操作是：

1. 在微信聊天中长按消息，进入多选，勾选需要整理的内容。

2. 点击多选界面下方的“复制”。

3. 打开 AI 助手的聊天窗口，把复制的内容粘贴到输入框里发送。

4. 内容较多时，先单独发 111，分批粘贴发送，最后单独发 000。

这让微信里的文字聊天也能方便地进入知识库，不必等原生合并转发功能打通。复制粘贴发送的是文本，不能据此认为图片、视频或文件本体也被完整带过去；需要保留这些附件时，应另外发送并检查归档结果。

微信客服有自己的 API 接入流程，但它和企业微信自建应用不是同一套配置。腾讯云的微信客服接入指南列出了回调地址、Token、EncodingAESKey 等设置，可进入微信客服后台检查。接上模型 API，也不会自动完成客服消息的接收。

是否能用微信客服收取完整合并记录，需要拿一份无敏感信息的样例实际发送，再检查 API 返回内容。在完成这项测试之前，我不会把它写成已经可用的替代方案。

十二、我踩过的坑，以及现在怎么排查

• 机器人会回答，Obsidian 没有新笔记；优先检查什么：是否真的部署了归档层；任务是否仍为 pending；客户端是否同步

• OSS 里有文件，客户端看不到；优先检查什么：远端目录是否一致，是否有额外前缀，是否启用了不兼容的加密

• 原文在，整理结果不在；优先检查什么：模型调用或整理写入失败，不要重复覆盖原文

• 图片显示一个链接但打不开；优先检查什么：是否真正下载了附件，链接是否过期，返回的是否是错误内容

• 白名单填了却没按预期生效；优先检查什么：当前版本是否读取该字段，网关和适配器是否还有其他放行设置

• 一次发很多消息，机器人逐条抢答；优先检查什么：是否安装了批次收集模块，而不是仅保存了一条行为偏好

• 服务重启后任务状态不对；优先检查什么：素材是否持久保存，临时缓冲是否尚未提交，服务是否启动了两份

• 同一段文字重复出现；优先检查什么：重试是否带稳定操作 ID，是否混用了多个写入脚本

• 同步后笔记少了一部分；优先检查什么：是否并发修改了同一文件，是否有恢复副本和独立备份

这些问题里，很多都不是换一个更强的模型能解决的。先检查文件、队列和实际接口返回，往往比让机器人反复解释更有效。

十三、真正开始使用前，我会做一次小验收

准备不含隐私的测试素材，逐项验证：

• ☐ 电脑、平板、手机三端可以自动同步一篇测试笔记和一张图片，间隔均设为 1 分钟。

• ☐ QQ 和微信各自能完成一轮普通私聊。

• ☐ 本人账号可以使用，未授权身份不能触发任务。

• ☐ 素材原文能在不依赖模型整理成功的情况下持久保存。

• ☐ 上传失败时保留待处理状态，恢复后能重试，不误报成功。

• ☐ 同一条归档任务重复处理，不会重复写入。

• ☐ 原文和整理结果能在正确日记位置看到，附件可以打开。

• ☐ 普通聊天不会自动写进 Obsidian，明确保存请求可以入库。

• ☐ 111 开始收集、000 结束并提交整批素材；收集状态在重启后能恢复。

• ☐ QQ 完整转发的群聊内容能够接收；微信多选复制、粘贴发送的文字能够保存和整理。

• ☐ 退出服务器登录后，服务继续运行。

• ☐ 从一份测试备份中恢复过文件，知道恢复路径在哪里。

我的实际使用已经覆盖三端每分钟自动同步、QQ 完整转发群聊，以及微信多选复制粘贴输入。部署记录中也有真实 OSS 图文结果、隔离写入测试和程序回归验证，2026 年 10 月 22 日的只读检查确认了 Hermes 网关与归档定时器处于运行状态。这些经验不等于所有文件格式、所有设备后台状态都已经逐项测试；新部署仍应按上面的清单检查自己的环境。

十四、如果让我重新搭一次

我仍然会保留这套分工：Obsidian 管笔记，OSS 管存储，QQ／微信提供随手输入的入口，Hermes 帮我理解和整理。

不过，搭建顺序会更克制一些：先用一篇测试笔记打通同步，再让一个聊天入口正常工作，最后补齐素材保存和失败处理。每增加一个环节，都用实际文件和状态核对结果。

现在对我来说，最理想的使用方式不是让机器人替我决定什么都值得留下，而是我负责选择素材，它负责保留、整理和归位。原文仍在，整理结果可以修改，换一台设备也能继续阅读。这才是我想要的个人知识库。