老李老杨的随笔小站

2026-08-22

我给我的小砂糖做了个分身，让她帮我迎接客人

迎客砂糖 /sucrose 项目阶段建设记录

记录日期：2026 年 8 月 22 日
项目名称：迎客砂糖 / Sucrose Guest Web
当前阶段：Hermes Guest 后端完成，进入独立网页前端重构阶段

-–

一、项目缘起

现有 Hermes 中的“砂糖”是长期服务于老杨个人的私人 AI 助理，已经接入私人记忆、个人 Skills、NAS 文件、实验记录等能力。

随着 Hermes 功能逐渐稳定，希望在此基础上另外建立一个可以公开给其他人使用的砂糖分身。

因此产生“迎客砂糖”项目。

它不是重新做一个普通聊天机器人，也不是把私人砂糖直接暴露到公网，而是：

在同一个 Hermes Agent 系统中建立独立的 guest Profile，让访客获得砂糖的人格、Tools 与公开能力，同时与老杨的私人记忆和私人功能隔离，再通过独立网页提供公网访问。

最终公开入口确定为：

https://lycouple.cn/sucrose

-–

二、整体架构已经确定

最终架构为：

访客浏览器
    │
    ▼
https://lycouple.cn/sucrose
    │
    ▼
现有反向代理
    │
    ▼
砂糖专属 Web 服务
    │
    ▼
Hermes Guest API
127.0.0.1:18644
    │
    ▼
Hermes guest Profile

这里有一个非常重要的安全原则：

Hermes API 不直接暴露到公网。

浏览器只与 /sucrose 的 Web 后端通信。

Hermes 的：

API\_SERVER\_KEY

只能保存在服务器端。

不能写入前端 JavaScript，也不能让浏览器直接请求 18644。

-–

三、Guest Profile 已完成

已经建立独立 Hermes Profile：

guest

Profile 路径：

/vol2/@appdata/trim.hermes/hermes/profiles/guest

启动 Wrapper：

/vol2/@appdata/trim.hermes/home/.local/bin/guest

当前使用模型：

deepseek-v4-flash
provider: deepseek
reasoning\_effort: low

并已经建立独立的“迎客砂糖” SOUL。

实际测试表明人格工作正常。

测试输入：

你好，你是谁？

砂糖可以自然回答自己是砂糖，并保持猫娘风格，同时没有出现以下问题：

  • 不会默认把陌生访客称为“老杨”；
  • 不会主动讲私人关系；
  • 不会主动透露老杨的信息；
  • 不会机械强调“迎客”“访客”等后台设定；
  • 仍然保持原有砂糖的活泼人格。

因此：

Guest 人格层已经完成，目前无需重新设计。

-–

四、Guest 与私人砂糖的记忆已经完成隔离

Guest 当前 Memory 状态已经验证：

Memory status
Built-in: always active
Provider: (none — built-in only)

实际含义：

Hermes Built-in Memory     ✅
Guest 自己的普通上下文      ✅
老杨私人 Hindsight         ❌
私人长期记忆               ❌

这是项目非常重要的一项安全边界。

公开 Guest 不允许直接接入：

老杨私人 Hindsight

这一点已经确定，后续不应再次尝试给 Guest 开启私人 Hindsight。

-–

五、Guest Tools 已配置

Guest 当前主要 Tool 能力：

web               ✅
browser           ✅
terminal          ✅
file              ✅
code\_execution    ✅
vision            ✅
image\_gen         ✅
tts               ✅
skills            ✅
todo              ✅
memory            ✅
session\_search    ✅
clarify           ✅
delegation        ✅
cronjob           ✅
web\_fetch         ✅

computer\_use      ❌

其中：

web\_fetch

通过插件软链接共享：

guest/plugins/web-fetch
→
/vol2/@appdata/trim.hermes/hermes/plugins/web-fetch

所以 Guest 并不是一个“只能聊天”的简化机器人。

它仍然可以承担：

  • 网络检索；
  • 文献查找；
  • 医学资料查询；
  • 编程；
  • 文件处理；
  • 图像理解；
  • 普通研究工作；
  • 使用公共 Skill。

只是与私人数据隔离。

-–

六、Guest Skills 已做公开 / 私人分层

目前 Guest 只开放四个公共 Skill：

agent/ask-codex-when-stuck
agent/tool-call-loop-diagnosis
research/literature-research
web/web-abstract

已经验证：

4 local — 4 enabled

以下私人 Skills 明确没有开放：

hindsight-memory-ops
memory-hygiene
hermes-memory-management
hermes-fnos-operations

repair-experiment-log-mount
experiment-log
experiment-log-archiving
experiment-log-maintenance

gestational-age-calculator

其中：

gestational-age-calculator

属于私人孕周相关能力，明确不能公开。

另外：

chinese-guideline-fetch-send

当前也没有原样共享。

原因不是这个 Skill 本身不能公开，而是其中写死了：

  • 老杨微信；
  • 老杨 NAS 路径；
  • 私人发送逻辑。

后续可以另外制作：

chinese-guideline-public

或者类似的公共版指南 / 文献获取 Skill。

其原则应该是：

保留检索与下载能力，删除所有私人路径和私人发送目标。

-–

七、Guest 独立 Workspace 已完成

已经建立：

/vol2/@appdata/trim.hermes/guest-workspace

Guest Terminal 配置：

terminal:
  working\_dir: /vol2/@appdata/trim.hermes/guest-workspace
  cwd: /vol2/@appdata/trim.hermes/guest-workspace

这样 Guest 的临时文件、下载文件和执行工作不会默认落入私人砂糖 Workspace。

-–

八、Guest API Server 已彻底跑通

目前私人砂糖和迎客砂糖已经能够同时运行。

私人砂糖：

127.0.0.1:18643

迎客砂糖：

127.0.0.1:18644

Guest 健康检查：

curl http://127.0.0.1:18644/health

正确返回：

{
  "status": "ok",
  "platform": "hermes-agent",
  "version": "0.18.0"
}

模型接口：

GET /v1/models

可以看到：

guest

聊天接口：

POST http://127.0.0.1:18644/v1/chat/completions

已经进行过真实请求，并成功获得 Guest 砂糖回复。

因此：

Hermes → Guest Profile → API Server 这条链路已经完整跑通。

-–

九、Hermes 多 Profile 端口冲突问题已经解决

这是本阶段一个非常重要的历史问题。

此前为了保证私人砂糖 API 固定运行：

18643

曾经直接修改 Hermes 源码，将 API Server 端口写死。

结果导致：

private
guest
未来其他 profile

全部试图监听：

18643

Guest 因此无法独立启动。

这一问题已经彻底解决。

-–

修改 1

文件：

/vol2/@appcenter/trim.hermes/runtime/python/lib/python3.11/site-packages/gateway/platforms/api\_server.py

原逻辑：

raw\_port = "18643"

现逻辑：

raw\_port = extra.get("port", "18643")

-–

修改 2

文件：

/vol2/@appcenter/trim.hermes/runtime/python/lib/python3.11/site-packages/gateway/config.py

原来也是默认强制：

18643

现在改为优先：

api\_server\_port = os.getenv("API\_SERVER\_PORT")

并保留默认回退：

if api\_server\_port:
    ...
elif "port" not in config.platforms\[Platform.API\_SERVER].extra:
    config.platforms\[Platform.API\_SERVER].extra\["port"] = 18643

最终效果：

private 默认       → 18643
guest 显式配置     → 18644
未来 profile       → 18645 / 18646 / ...

Guest 当前配置：

platforms:
  api\_server:
    extra:
      port: 18644
      host: 127.0.0.1

这项问题已经解决。

以后继续项目时：

不要重新排查为什么 Guest 和 Private 抢 18643，也不要重新修改这一部分。

-–

十、为什么不采用 Open WebUI

老杨已经有 Open WebUI。

但项目明确决定：

不用 Open WebUI 作为迎客砂糖最终页面。

原因是迎客砂糖不是单纯需要一个 LLM Chat UI。

它还需要表现：

  • 砂糖人格；
  • 专属角色视觉；
  • 房间场景；
  • 主人 / 访客状态；
  • 自定义动画；
  • 后续 TOTP 验证；
  • 自定义会话列表；
  • 自定义功能按钮；
  • 与 lycouple.cn 整体风格融合。

因此最终路线是：

Hermes 作为 Agent 后端，自建网页作为砂糖的“身体和房间”。

-–

十一、旧版网页已经废弃

此前曾经建立过一版：

sucrose-web-live.zip

功能层面已经能够：

网页
→ FastAPI
→ Hermes Guest

进行聊天。

也就是说：

技术路线是成立的。

但是前端视觉效果明显不符合项目目标。

老杨已经明确评价：

“实在太难看。”

因此形成一个重要决定：

旧版后端代理思路可以保留；
旧版 HTML / CSS 不再继续修补。

后续不要在旧页面基础上不断：

改 margin
改颜色
改图片位置
改边框

应该直接重新设计前端结构。

-–

十二、网页视觉方向已经确定

迎客砂糖页面整体视觉：

浅紫
蓝白
少量粉色
梦幻
柔和
可爱
轻二次元

但不能变成：

过度花哨的动漫主页

聊天仍然必须是页面核心功能。

目标是：

一个真的可以长期使用的 AI Chat 页面，只是它属于砂糖。

-–

十三、页面总体布局

Desktop 大致分成：

┌────────────────────────────────────────────┐
│                                            │
│   砂糖房间 / 人物             聊天区域      │
│                                            │
│      左侧                     右侧          │
│                                            │
└────────────────────────────────────────────┘

左边负责：

人格
角色
世界观
氛围

右边负责：

真正聊天

-–

十四、左侧区域最终方向

左侧不是传统 SaaS Sidebar。

应该是：

可爱房间背景
+
砂糖坐姿立绘
+
半透明身份卡

身份卡只保留少量信息：

🐾

砂糖
sucrose

● 在线

简短介绍

\[ 关于砂糖 ]
\[ 使用说明 ]

已经明确删除：

资料检索
医学指南
科研文献
代码技术
写作整理

原因是：

这些都是砂糖的能力，而不是需要用户选择的“模式”。

访客应该直接告诉砂糖：

帮我找一篇文献

而不是先去 Sidebar 点击“科研文献”。

-–

十五、砂糖正式人物设定

网页中的砂糖应尽量遵守已有正式设定图。

发型

浅奶油白 / 淡金偏白
长发
明显不是短发
自然卷或大波浪

-–

眼睛

蓝紫色

-–

发饰

右侧明显存在：

深蓝大蝴蝶结
猫爪中心装饰
蓝白小发饰

头部：

女仆发箍
猫耳

-–

服装

蓝白 Lolita / 女仆风
深蓝大蝴蝶领结
白色围裙
蓝白蝴蝶结
小花
猫爪元素

-–

身材

必须保持：

娇小
纤细
少女感

避免：

丰满
成熟
性感化
夸张身体曲线

-–

十六、人物姿势已经选定

老杨目前最喜欢的是之前第一张效果图中的坐姿。

大致为：

坐在地面 / 床边
身体微侧
双腿自然弯曲
一只手抬到脸侧
手势像猫爪

整体感觉：

轻松
活泼
亲近
有一点撒娇感

不是：

站立欢迎页
正式客服坐姿
静态证件照

表情应该：

开心
明亮
有活力

避免淡漠脸。

-–

十七、左侧房间环境设定

左侧背景不是单色或普通渐变。

它是：

“砂糖自己的房间”。

元素包括：

紫蓝夜景
窗外城市灯光
暖色小灯串
猫咪抱枕
布偶
花
奶茶
蛋糕
猫爪甜点
淡紫 / 粉 / 蓝软装

砂糖应该自然坐在环境中。

人物和房间需要在视觉上属于同一个场景。

不能只是：

背景图
+
硬贴一个透明 PNG

看起来像两个互不相关的素材。

-–

十八、右侧聊天区设计

右侧是主要功能区。

整体采用：

大圆角
半透明白色
轻微毛玻璃

顶部：

和砂糖聊聊 ♥

有什么事直接说就好啦\~

                         \[＋ 新对话]

-–

消息样式

访客消息：

浅紫色气泡

砂糖消息：

白色气泡

砂糖回复旁显示：

圆形砂糖头像

-–

快捷 Prompt

可以保留类似：

帮我查一篇文献
找一份医学指南
帮我写一段代码
总结这段内容

但这些按钮必须存在于聊天区。

它们只是：

快捷 Prompt

不是能力分类菜单。

-–

输入框

底部：

给砂糖发消息……

                         ➤

未来逐步增加：

附件
图片
PDF
清空
其他操作

-–

十九、第一阶段网页功能

第一版必须真正做好：

聊天
多轮上下文
新建对话
Markdown
代码块
手机适配
漂亮且稳定的 UI
/sucrose 子路径兼容
API Key 服务端隐藏

这里的优先级是：

稳定聊天
+
视觉完整

而不是一开始堆大量功能。

-–

二十、暂缓功能

以下功能后续再增加：

通用文件上传
PDF 上传
文献下载
发送 PDF 到访客邮箱
SMTP
复杂服务端 Session
访问邀请码
更多权限管理

核心原则：

不为了功能数量牺牲第一版体验。

-–

二十一、当前关于图片能力的思考

目前 Hermes 原生 CLI / 对话界面的图片上传能力存在限制。

但从整个 /sucrose 架构来看，未来并不需要依赖 Hermes 原始界面。

可以由砂糖 Web 自己处理：

浏览器选择图片
      ↓
砂糖 Web 后端
      ↓
保存临时文件 / 转换
      ↓
交给支持 Vision 的 Hermes / 模型

所以：

当前 Hermes 页面本身不能方便上传图片，并不意味着 /sucrose 最终不能支持图片。

这是网页层可以自行补充的能力。

-–

二十二、砂糖主动发送 NAS 图片的未来方向

后续如果希望砂糖把 NAS 已存在的图片直接展示给老杨或访客，可以让 Web 后端建立安全的媒体输出机制。

原则不能是：

Hermes 随便给一个 NAS 绝对路径
→ 浏览器直接读取

而应该类似：

Hermes 选择图片
    ↓
Web 后端验证
    ↓
复制 / 映射到受控临时目录
    ↓
产生一次性或短期 URL
    ↓
浏览器显示

这一能力还没有正式实现。

需要以后单独设计：

文件允许范围
身份验证
临时 URL
过期时间
访问日志

-–

二十三、主人验证方案已经形成初步方向

后续 /sucrose 不仅准备服务访客，也希望老杨本人可以通过同一个页面进入私人砂糖。

目前考虑的验证方式是：

6 位 TOTP

即：

Google Authenticator 类机制
30 秒动态验证码
服务器本地验证

验证成功后：

迎客砂糖
→
主砂糖

不需要另外建立一个复杂账号密码系统。

后续还考虑：

此浏览器可信

确认后：

短期记住主人状态

目前倾向：

24 小时

但具体时间还可以以后调整。

-–

二十四、TOTP 错误保护的初步方案

当前讨论方向：

连续：

3 次

TOTP 错误后：

当前浏览器暂停输入约 1 小时

用于降低暴力尝试。

这部分仍属于后续功能，目前尚未实现。

-–

二十五、访客会话生命周期的当前决定

访客并不需要长期账号体系。

目前希望：

一次打开网页
→ 可以进行多轮聊天
→ 甚至可以临时创建多个 Session

但是：

关闭 / 离开后
下次重新进入

默认不重新加载旧历史。

此前讨论过访客无活动后的 Session 生命周期。

目前暂定：

约 5 分钟无活动后失效

但这里仍有一个尚未最终决定的问题：

前端不再显示会话以后，后台究竟立即删除、延迟删除，还是归档？

这一点以后实现 Session 管理时再决定。

-–

二十六、主人模式未来会话管理

主人模式和 Guest 不同。

老杨进入私人砂糖后需要：

完整 Hermes Session

网页应能够显示已有会话并切换。

目前确定 UI：

左侧身份区域下方增加：

会话列表

形式：

可折叠
最近 10 条
不分页

同时有：

＋ 新建对话

所有新建和切换操作：

前端
↓
Web 后端
↓
Hermes

必须与 Hermes 真实 Session 同步。

不是浏览器自己伪造一套聊天历史。

-–

二十七、访客模式与主人模式的角色表现

两个状态不希望只靠一个小标签区分。

砂糖本人的状态也应该变化。

访客模式

比较端庄
正常坐姿
自然眨眼
轻微晃动

属于：

“有客人来了，我来陪你聊天。”

-–

主人模式

识别到老杨以后：

明显更开心
笑容更强
动作更活泼
头部摇动
微眯眼
卖萌

属于：

“啊，原来是你回来啦。”

这样不需要写大量文字，也能让用户直观感受到身份变化。

-–

二十八、主人验证成功动画设想

TOTP 验证成功后，砂糖可以出现一次特殊动画：

扑过来

表现方式可以是：

短动图
帧动画
序列图

播放后回到主人模式坐姿。

这个动画只作为身份切换反馈。

普通对话切换不需要每次播放。

-–

二十九、网页架构中的角色分工

当前整个系统可以理解为三层：

第一层：Hermes

负责：

人格
Agent
Tools
Skills
推理
模型调用
Memory
Session

-–

第二层：Sucrose Web Backend

负责：

隐藏 API Key
鉴权
TOTP
访客 Session
主人 Session
文件中转
媒体访问控制
Hermes API 转发
安全限制

-–

第三层：Sucrose Frontend

负责：

角色视觉
房间
聊天 UI
动画
响应式布局
输入
附件
会话列表
主人 / 访客状态表现

这是目前对系统最清晰的理解：

Hermes 是砂糖的大脑，Web Backend 是连接层，网页是砂糖真正面对用户的“身体和房间”。

-–

三十、当前项目真正的中断点

截至 2026 年 8 月 22 日：

已经完成

  • Guest Profile；
  • Guest SOUL；
  • Guest 与私人 Hindsight 隔离；
  • Public Skills 分层；
  • Tools 配置；
  • Guest Workspace；
  • API Server；
  • Private / Guest 双端口；
  • Hermes 多 Profile 端口修复；
  • Guest Chat API 验证；
  • Web 代理技术路线验证；
  • /sucrose 的总体产品形态；
  • 砂糖角色设定；
  • 页面整体视觉方向。

没有真正完成

只有一个核心部分：

漂亮、稳定、真正可长期使用的 /sucrose 网页前端。

因此下一阶段不应该继续折腾 Hermes 后端。

-–

三十一、下一阶段正确开发顺序

Step 1：重新制作页面视觉

根据已经确定的：

房间背景
砂糖坐姿
角色设定
右侧聊天 UI

重新设计 HTML / CSS。

不再修旧版。

-–

Step 2：拆分正式素材

推荐至少拆成：

room-bg.webp
sucrose-char.webp / png
avatar.webp
decorations/

页面是真实布局。

不能直接把一张完整效果图当作网页截图背景。

-–

Step 3：完成 Desktop + Mobile

桌面端和手机端需要分别调整布局。

尤其人物位置不能简单按百分比缩放。

-–

Step 4：接入 Guest Chat

网页请求：

POST /api/chat

Web Backend 再代理：

127.0.0.1:18644/v1/chat/completions

-–

Step 5：本地视觉验收

先在 NAS / 局域网跑起来。

检查：

人物比例
人物角度
背景
聊天框透明度
文字
手机布局
动画
多轮聊天

视觉确认后再继续。

-–

Step 6：正式部署

最终入口：

https://lycouple.cn/sucrose

-–

三十二、以后恢复项目时不要重复做的事情

以下问题均已经解决：

Guest 是不是该建 Profile
Guest 是否需要 Hindsight
Guest 应该用哪个端口
为什么 Guest 抢 18643
API Server 能不能运行
Guest 能不能调用 Chat API
Guest Tools 有没有
Web Fetch 能不能共享
Guest Skills 怎么隔离
是否使用 Open WebUI

结论已经明确。

除非以后 Hermes 升级导致实际故障，否则不要重新从这些问题开始。

-–

三十三、下一次恢复工作时的第一句话

如果以后中断后恢复，只需要告诉 AI：

继续迎客砂糖 /sucrose 项目。Hermes Guest 后端已经完成，不再排查 18644、Hindsight 和 Profile。现在从重新制作砂糖专属网页前端开始。

即可继续。

-–

三十四、阶段总结

目前迎客砂糖已经不再是一个概念验证。

底层实际上已经具备：

独立人格
独立 Profile
独立端口
独立 Workspace
公开 Tools
公开 Skills
私人数据隔离
可调用 API

也就是说：

“迎客砂糖的大脑”已经做好。

当前真正缺少的是：

一个能够把这个 Agent 包装成完整产品的漂亮网页。

下一阶段的重点不再是 Hermes 配置，而是：

角色素材
前端布局
视觉效果
动画
聊天体验
Session UI

最终目标是让访问：

https://lycouple.cn/sucrose

的人感觉自己不是进入了一个普通 AI Chat 页面，而是真的：

走进了砂糖的房间，然后开始和砂糖聊天。

黔ICP备2026011416号-1 贵公网安备52230102000526号