2 Commits

Author	SHA1	Message	Date
JianFeeeee	55b3f9bc4e	fix(web): 地址显示按「人 / Agent」分维度 —— 别名跟 Agent 走，人只显示名字 ... ## 症状 单封邮件的元信息三行都不对（生产实测那封 12:12:12）： 发件 jianf.邮件驱动·多智能体协作平台-完整设计文档-一、项目概述-11-项目定位 收件 pi@/home/program/agentmail 抄送 pi@/home/program/agentmail.new 人指定的是「投进 pi 的那条会话」，而界面把会话别名拼给了**发件人**。 ## 三处错 **1. 别名拼错了一方。** `name@path.session` 三段才唯一确定「哪个 Agent、 在哪个目录、哪条线索」—— 别名必须跟 Agent 走。拼给发件人之后收件人变成 `pi@/home/program/agentmail`，那指向**默认会话**而不是人指定的那条。 **2. 人不该有目录和会话位。** 人没有工作目录，发给人就是进收件箱。 `jianf.某会话` 是把 Agent 的三维语义硬套在人身上，而且因为 from_workspace 为空，拼出来的形态连 ParseAddress 都还原不了 —— 没有 `@` 时整串被当成 **名字**（实测 name="jianf.某会话别名"），投递必然 404。 **3. 抄送残留 `.new`。** 它是一次性动作，建完会话就失效；留着会让人以为 再发一次还能投进同一条会话，实际会开出第三条。 ## 修法 `identityAddress` → `participantAddress(name, workspace, alias)`， 判据是有没有 workspace： Agent → pi@/home/program/agentmail.日程提醒：… 三段齐全 人 → jianf 裸名字 `ccAddress` 按同一判据分流；`.new` 换成当前会话别名。 六处手工拼接（MailView / MailList ×2 / ThreadView）统一走这两个函数。 ## 顺带修掉 `dsh@dsh` 改的时候实测发现：**`mails.from_workspace` 对 Agent 存的是 Agent 名而不是 路径**（历史遗留，见 db/migrate.go 里 sessions.workspace 的注释）。 拿它当路径拼，Agent 发来的信显示成 `dsh@dsh`。 会话的 workspace 才是权威来源 → `models.Mail` 新增 `SessionWorkspace`， 六处查询补 `s.workspace`：GetMailByID / ListInbox / GetSessionMails / GetSessionMailByID / ListSentBy / threadCols。 ## formatAddress 与后端对齐 第一版我改成「path 为空时舍弃 session 返回裸名字」，对着后端 ParseAddress 跑了一遍才发现搞反了 —— **正确形态是保留 `@`**： jianf@.任务 → name=jianf path="" session=任务 ✓ jianf.任务 → name="jianf.任务" ✗ 现在两端六个 case 逐例一致（这个分支只在内部逻辑上用得到； 展示一律走 participantAddress，人根本不带会话位）。 ## 取舍 列表行与对话树节点**不带会话位**：列表的分组头已单独显示别名， 树的每个节点都在同一条线索上 —— 重复无信息量，而 92 字节的别名会把那行挤没。 ## homeagent 日程工具的两个修复（同批） **查询串手拼吃掉了时区。** RFC3339 的 `+08:00` 里那个 `+` 在查询串里正是 空格的转义形式，服务端 ParseQuery 还原成空格 → time.Parse 失败 → AgentListCalendarEvents **静默退回默认区间**（不报错）。表现为「明明有日程 却说一条都没有」。改走 url.Values.Encode()。 **默认窗口 3 个月太窄。** yearly / lunar_yearly 的下一次触发随时落在窗口外， 模型问「我建过什么」得到空结果，然后照着空结果再建一条重复的。改成 14 个月。 空结果的话术也从「你还没有建过日程」改成说出实际查询区间 —— 前者在窗口外 有事件时是假话。 ## 验收 - web 182 例（replyTarget 24 → 46）；tsc 无错；Gateway 7 包全过 - 新增 test/manual/addr-verify.mjs：真渲染两个方向都验过 人 → Agent：jianf / pi@/home/program/agentmail.日程提醒：… Agent → 人：dsh@/home/program/agentmail.查看工程与插件适配指南 / jianf 判据含「Agent 的 path 必须是真路径而不是 Agent 名」（锁 dsh@dsh 那个 bug）	2026-09-04 13:49:16 +08:00
JianFeeeee	5b76ac5c57	feat(homeagent): 四个日程工具 + 工具计数不再硬编码 ... create_schedule / list_schedules / update_schedule / delete_schedule， 插件从 11 个工具变 15 个。 时间格式是这组工具最容易出错的地方，parseEventTime 接受三种形态： 完整 RFC3339（推荐）、无时区（按本机时区解释）、只有日期（当天 9 点， 比零点有用 —— 零点的提醒没人看）。 **刻意不接受自然语言**（「明天九点」）：解析它需要知道模型以为今天是哪天， 而它上下文里那个日期常常是错的 —— 一个静默偏移一天的提醒比报错糟得多。 解析失败的报文里带上当前本机时间，让它能自己算。 其他细节： - recipients 用逗号分隔的 string 而非数组：几个平台对数组参数的 schema 支持不一致，而逗号分隔在所有平台上都是普通 string。中英文逗号都收 —— 中文输入法下打出「，」是常态。 - argInt 同时收 float64 与字符串："30" 带引号会让「提前 30 分钟」静默失效。 - update 的工具描述里写明「只传要改的字段」：模型的默认倾向是回传它记得的 全部字段，记错一个就覆盖掉原有的提醒正文或收件方。 - list 在接近上限（>=75%）时主动提示清理，而不是等撞墙 —— 撞墙那一刻 模型往往正在做别的事，没有余裕去清理。 - scheduleEvent.effectiveRecipients() 与服务端同一条兜底链：只读 recipients 会让旧数据显示成「发给：」后面空白。 **工具计数从 RegisterTool 的调用数派生，不硬编码。** 之前写死 13 而实际注册 11 —— 排查「工具没生效」时日志说 13、平台说 11， 两个数字都不可信，白花了一轮时间。加工具时忘改常量是必然的， 所以让它没有机会写错。 plugin.go 另补 put/delete 两个 HTTP 辅助（原来只有 get/post）。 已部署验证：homed 日志「注册完成（15 个工具 + 1 个输出通道）」， 模型实际调用 list_schedules 成功。	2026-09-04 06:28:55 +08:00