Mio 查看邮件 · 方案(修正版)

SalesRoom #271 · 2026-07-30 · 边界是「已判定 vs 未判定」,不是「自己 vs 别人」

修正:边界不是「自己 vs 别人」,是「已判定 vs 未判定」 Alex 指正

我原来把线画在「只能读自己的」。但那条线画错了地方 —— 「过滤过了」和「可以给别人看」不是一回事

规则层丢掉的只是明显不是工作邮件的(通知 / 验证码 / 退信 / 群发)。留下来的里面有一大块是 unknown —— 按定义就是还没判定,里面完全可能有私人内容。所以 _未分類/ 跨人可见是不行的,哪怕它「已经过滤过」。

反过来说:triage 判为工作、并且归到客户之后的内容,本来就承诺了组织共享(授权页上那句「同事和上级能看到」)。对这部分设「只能看自己的」反而是错的 —— 那正是产品要的协作。

三层可见性

通知 验证码 垃圾

工作 或 判不准

判为私人

判为工作

拉回来的邮件

规则层

丢弃 · 不落盘

mailboxes 人 _未分類

triage · LLM 判定

删除 · 不进共享

mailboxes 人 商谈 咨询 社内

客户档案 · 提炼产物

状态本人同事 / Mio 代同事查
_未分類/ 还没判定 —— 可能含私人内容 ✅ 能读 ❌ 绝对不行
商谈/ 咨询/ 社内/ triage 判为工作 ✅ 可以 —— 这正是授权页承诺的
客户档案里的产物 已提炼(VOC / 纪要 / 记忆) ✅ 本来就是共享的

所以工具怎么改

工具作用域身份怎么来
list_my_mail
read_my_mail
只有自己的,含 _未分類/ closure 钉死 —— 没有 user_id 参数,agent 连表达越权的语法都没有
search_team_mail
新增
全组织,但只含已判定为工作的
WHERE triage_status='done' AND rule_kind != 'private'
组织级,不限人 —— 但 SQL 里根本查不到 _未分類/ 的行

关键:限制写在 SQL 的 WHERE 里,不是写在提示词里。「未判定的不给看」如果靠 agent 自觉,等于没有限制 —— 它一次幻觉就越过去了,而且没有任何东西会拦。

为什么这样比「只能看自己的」好

协作真的成立了 「アトレ 那边最近谁在跟?说了什么?」—— 这是销售团队每天要问的。限制成只能看自己的,产品价值就少一半
隐私边界更准 原方案「自己 vs 别人」会把自己的私人邮件也当成可共享(因为在自己名下)。
新方案卡在「判定」这一关,私人内容连本人的共享层都进不去
和授权页的承诺对得上 我们对销售说的是「工作邮件会进入组织共享记忆」。
「工作」这个定语,现在有了对应的机制 —— 就是 triage 那一关

前置没变:先有邮件,再做工具 现状

依赖状态
连接 + 取数 + 落盘落库✅ 通了
定时取数❌ 还没有,只能手动点「立即取得」
triage(判定 + 分类)❌ 还没做 —— 而它现在成了可见性的闸门,没有它所有邮件都停在 _未分類/,谁也共享不了
真实工作邮件样本❌ Alex 的邮箱没有业务往来(12 封全是系统通知)

这次修正把 triage 的地位抬高了:它原来只是「让邮件更好找」,现在它是隐私边界的执行点。没有它,共享层就是空的 —— 这反而让实施顺序更清楚了。

建议顺序

做什么为什么在这个位置
1定时取数邮件先攒起来,不然后面全是空跑
2triage(门禁 + 路由 + 分类)它是隐私边界。没有它,`_未分類/` 永远只有本人能看,协作无从谈起
3Mio 的三个 typed tool此时才有东西可查,而且边界已经由 ② 建立
4skill(教判断)工具给能力,skill 教什么时候用、怎么按类批量呈现
Generated as a visual answer · open in browser