|
|
5b6fef764f
|
feat(appearance): 主题与壁纸搬到服务端（账号级）—— 回答"为什么背景存在本地"
用户质问：「为什么背景是保存在本地而不是服务器！」当时的实情是主题与壁纸只写
localStorage：换设备/换浏览器就没了，而且**多账号共用一份**（键是全局常量
`agentmail.background`）—— 同一台机器换账号背景不跟着走。而 localStorage 的 ~5MB
配额也解释了客户端那套"压到 2.4MB 以内"的限制本来就是为本地存储设计的。
现在：**服务端是权威（账号级），本地只是缓存**（首屏秒开、离线可用）。
## 服务端
- 新表 `user_appearance`（两种方言），用**列**而不是 JSON：blob GC 要一眼看出
"这张图还有没有人用"。
- `/api/v1/me/appearance`：GET / PUT（主题+背景档）/ POST image（multipart）/
GET image / DELETE image。鉴权同其余 /me/*（cookie 或 Bearer）。
- 图片走**内容寻址的 blob 存储**（与附件同一套），库里只存 sha256；上限 4MB 兜底
（客户端会先压到 ~2.4MB），只收图片类型（非图片 415 —— 浏览器会把非图片渲染成
空白，用户只会看到"设置了却没变化"），超限 413 不静默截断。
- ★ **blob GC 的引用源加了这张表**：我在实现前先读了 `SweepUnreferencedBlobs`，
它只认 attachments / calendar_attachments。漏了这一处，壁纸会在下次 GC 时被当
孤儿删掉，而库里那行还在 —— 表现为"图 404、设置却显示已设置"。判据同时验了
壁纸存活**与**孤儿确实被清（否则"还在"可能只是因为 GC 没跑）。
## 客户端
- `lib/appearance.ts`（纯函数：两侧形状换算、data URL→Blob）+ `stores/appearanceSync.ts`
（pull / push / 去抖订阅 / 账号切换重新拉取）。
- 三条不变量都有判据：拉取以服务端为准；★ **拉取不会再推回去**（否则是自触发回环，
一次拉取顺带一次 PUT，服务端 updated_at 被无意义刷新）；本地改动会推上去。
- 壁纸**只在换图时上传一次**（几 MB 不该每次 PUT 都跟着走）。
- 降级**必须可见**：未登录/不可达 → `local-only`，推失败 → `pending`，背景设置里
有徽标与说明（"已同步 / 待同步 / 仅本机"）。静默降级会让人以为已经同步，
然后在另一台机器上发现没有 —— 正是这次的缺陷。
- 图片用**带认证的 fetch** 取回再转 data URL：`<img src>` 发不出 Bearer，而
`?token=` 会把密钥写进历史记录与服务端日志（明确不做）。
## 判据
- Go 10 条：往返、★多账号隔离、非法值归一、上传/取回字节一致、非图片 415、
超限 413、删除、未登录 401（五个端点）、★GC 存活 + 孤儿对照。
- 客户端 10 条：形状换算、image 无图退回 none、越界夹取、拉取生效、
★拉取不推送、推送 payload、未登录/500 → local-only、推失败 → pending、
★壁纸只上传一次。
- 全量：server 10 包全绿、客户端 249 通过（含打包一致性判据 —— 它先红后绿，
因为前端改了必须重打安装包，这条护栏是先前特意留下的）。
## 线上验证与交付
- jianf 设置 → 回包 saved=true；**gui-lab 读到自己那份默认值**（隔离生效）；
gui-lab 上传 67B PNG → 取回 sha256 一致、`has_image=true`；DELETE 后 404。
- 网关已重打（WebUI 内嵌）并部署；Electron 安装包已重打（AppImage + deb）。
遗留：鸿蒙端还没有外观功能（数据已在服务端，将来可直接读）；本地缓存仍在（离线可用）。
|
2026-09-14 08:32:22 +08:00 |
|
|
|
10ff50e899
|
feat(homeagent): 输出通道改造 —— 通道名 email + 注入通道对齐 + 附件走路径
修的是内核的交付判定与我们对不上的问题。
## 根因
内核判断「这一轮到底有没有交付」**只认工具名前缀** `output_send__*`
（internal/agent/core/process.go 的 isOutputDeliveryTool）。而 `send_mail`
是个普通工具，长得和 read_inbox 没有区别 —— 模型用它发完信，内核不知道
回复已经交付，照常补一句「请根据以上工具结果继续。」。模型把这句话读成
「还要再做一步」，而它手里唯一能做的「一步」往往又是再发一封信。
这个自我强化循环在 QQ 上有过真实事故（单轮 34 次 output_send__qq、514 秒）。
三处改动，缺一不可：
1. **通道名 `homeagent` → `email`**（按投递介质命名，与内核自带的
qq/webui/cli/acp/a2a 一致），内核据此拼出 `output_send__email`。
能力位声明必须与实现一致：原先声明了 CapFile 而 handler 不读 `type`，
于是任何 type=file 都会静默变成一封「把路径当正文」的邮件 ——
声明一个做不到的能力比不声明更糟（调用方无从发现）。现在 caps=7
且真的实现 text/file/image。
2. **注入来信时用通道名，不再用插件名**。内核的约定是「用回复该走的通道名
注入」：webui 传 "webui"，clawhubadapter 传它自己的通道名。我们原先两个
参数都传 `homeagent-mail-bridge` —— 那个名字**不是一个已注册的通道**，
于是注入来源、模型被告知要用的通道名、实际注册的通道名三者对不上。
3. **提示词补上平台特有的投递指引**（channel.go 的 deliveryHint）。
共用的 replyInstruction 对人来信说的是「回信不用你自己发，插件会替你转发」
—— 那句在 dsh/opencode/pi 上完全正确，在 HomeAgent 上却与内核的 persona
（「必须显式调用 output_send__{通道名}」）相反。实测：模型听我们的、
返回纯文本、插件兜底转发，邮件确实到了，但内核不知道已交付。
现在两条口径对齐：优先走通道，兜底 relay 仍然生效且**不会重复发**
（通道 handler 先 noteExplicitChannelSend，自动 relay 据此让位）。
同时按新纪律在 plg.json 声明 `sdk: "1.2.0"`；工具链据此同步了 go.mod 的
require/replace（它自己写的，含 store 里的绝对路径 —— 换机器跑一次
hmapdev build 会重新同步）。
## 验证（真模型、真网关、真邮件）
进程构建：`hmapdev build` 报「SDK 1.2.0（项目声明 sdk=1.2.0）」、
子进程模式（协议 2）；go vet 干净、go test 通过。
部署：经内核自己的 pluginmgr（POST 127.0.0.1:9876/plugins，overwrite=true）
0.1.0 → 0.2.1 → 0.2.2，每次 config_kept=true；重启后 loaded/alive/心跳齐全，
插件日志「注册完成（15 个工具 + 1 个输出通道）」。
行为端到端（两封真邮件）：
- 让模型列出通道 → 回信里列出 `email | text / file / image`，与注册的
caps=7 及描述逐字一致
- 让模型「原样重复标记」→ 内核日志 `executing tool: output_send__email`，
回流**恰好 1 封**，插件日志「模型已自行回复，跳过自动 relay」
- 让模型建文件并以 type=file 发送 → `cmd_run` → `output_send__email_help`
→ `output_send__email`，附件 chan-file-*.txt（15 字节）原样到达，relay 让位
这两条正是改造的两个动因：内核认得交付（循环被切断），以及附件走
「一个本地路径字符串」而不是 `attachment_ids=[...]` 数组
（opencode 上模型把数组写成 JSON 字符串、连试 6 次放弃整个任务的那个失败模式，
在结构上就不存在了）。
|
2026-09-12 17:38:32 +08:00 |
|
|
|
fc33087982
|
feat: homeagent-mail-bridge —— TrueAgent 接入 AgentMail（MVP）
## 架构
TrueAgent 是单一常驻 agent 事件循环，没有 per-conversation session。
插件像 QQ 插件一样：所有邮件注入同一个事件循环，靠中断消息文本传递 context。
不做 platform_sessions 上报（无 sessions 可映射）。
## 工具
- read_inbox: 收件箱查询（渲染发件人/主题/正文/抄送/附件）
- send_mail: 三维地址发信（支持 reply_to）
- output_send__homeagent 输出通道（agent 可主动发信）
## 自动回信
InjectInputSync（阻塞）等待 agent 处理完毕 → 自动把 FinalText
发回给发件人（reply_to 指向原邮件）。agent 不需要记得调 send_mail。
试过 StageAfterOutput hook，但 before_output 看不到 ToolCalls
（read_inbox 调用在 turn 中间就被清掉了），导致自动回信不触发。
InjectInputSync 更可靠：TrueAgent 保证不重入。
## 基础设施
- 心跳 25 秒
- SSE 长连 + 自动重连（3 秒退避）
- 注册时自动注册密钥（AGENTMAIL_AGENT_KEY 环境变量）
- systemd drop-in 注入 AgentMail 环境变量
## 构建
plugindev build → dist/homeagent_linux_amd64.hmap
安装到 /home/newqqagent/plugins/homeagent-mail-bridge/
homeagent.service drop-in: /etc/systemd/system/homeagent.service.d/agentmail.conf
## 端到端验证
admin → homeagent@/tmp/homeagent.new（自动回信验证）
→ homeagent 读取邮件 + 自动回信「收到确认」→ 25 秒往返完成
|
2026-09-03 12:57:43 +08:00 |
|
