Featured image of post 我不允许 Personal Agent 读我的邮箱:该给它的是一张『员工工牌』,不是我的『分身』!

我不允许 Personal Agent 读我的邮箱:该给它的是一张『员工工牌』,不是我的『分身』!

今年下半年,personal agent 这个词被各家厂商轮番抬到台面上。有厂商给它一个专属的云电脑,有厂商让它常驻在你的 Gmail 里、你可以像给同事写信一样给它发邮件派活,标榜的都是同一个卖点:24 小时在线,替你回邮件、替你排日程、替你把那些你不想亲自点的按钮点完。

我不打算用这个功能。不是因为我觉得它不好用,而是因为「让它替我读邮件」这句话里,藏了一个被所有人跳过去的步骤。

读取,就是复制。 只要一个 agent 拿到了读你收件箱的权限,你的邮件就不再只存在于你的收件箱里了。它多了一份副本,而这份副本在别人的服务器上、在某个你从来没有听说过的中转链路里。这一点在过去几年还只是理论上成立,而这个九月,它变成了一份 154 页的、有名有姓的书面材料。

先看那份报告里最不体面的两段

9 月 10 日,Anthropic 发布了它的第四份威胁情报报告《Detecting and countering misuse of AI》,覆盖 2025 年 12 月到 2026 年 8 月这段时间里它检测到的滥用行为。报告里点名了七家中国背景的 AI 实验室,说它们在做「非法蒸馏」——用一个更强的模型的输出来训练自己的模型。加总的交换量大约 1.9 亿次。

数字我不打算全列,只挑三段最说明问题的:

  • 阿里那条线最大,2026 年 5 月到 7 月超过 1.51 亿次交换,峰值接近每天 300 万次,跑在 3500 多个被判定为欺诈的账号上。手法还很讲究:它在每个请求里塞一段固定指令,逼着 Claude 把完整的思维链写在标签里吐出来,管道只捞标签内的文本——因为对训练来说,教会学生模型「怎么想」比「想出什么」值钱得多。
  • Moonshot 那条线性质完全不同。它没有造 prompt,而是把 Kimi 用户真实的请求转发给 Claude,再把 Claude 的回答显示给用户,用户以为那是 Kimi 答的。10 天窗口里,将近 30 万条真实用户请求通过 5380 个欺诈账号转了出去,账号大多落在新加坡和日本。
  • DeepSeek 那条线在 7 月 14 天里做了 1200 万次以上,还多了一层筛选:它检查请求头里的 user-agent 字符串,看到 claude-code、claude-agent-sdk、opencode 这类标记就把请求标成高价值,悄悄路由到 Claude Opus——专门捞 agentic coding 的数据。

前三段是手段,接下来这段才是我想说的重点。

报告里举了两个「敏感信息随行出境」的例子:一个是评估为与军方有关联的用户,上传了成都数百个摄像头的监控录像,让 Kimi 识别被追踪对象的异常行为;另一个是某国企工程师,在搭内部系统时把专有代码和多家公司的有效凭据粘进了 Kimi 会话。

这两个人做选择的时候,以为自己只是在用一家中国公司的产品。他们的数据去了哪里,他们不知道。Anthropic 说得很直白:它不知道 Moonshot 有没有告知过客户这些请求被转发了。

我必须把话说清楚:以上都是 Anthropic 单方面的指控,报告自己也承认所列案例是「值得注意的样本」而非完整画像,且没有第三方独立核实;中国商务部否认了这些说法,称「无事实和法律依据」;阿里随后禁止员工使用 Claude Code。我不站队谁真谁假——对我这个议题来说,这些指控成立与否都不影响结论。因为让这件事可以发生的结构,本来就在那里:你一旦把内容交出去,它就在一条你看不见的链上走。

「读取」到底意味着几条链路

我把「用户以为的读取」和「实际可能的读取」拉了个对照。这张表值得每个打算开这个功能的人存一份:

你以为的路径 实际可能的路径 谁拿到了内容 你能查得到吗
我的邮箱 → 我用的那家 AI 我的邮箱 → 模型厂商 API 厂商(按它的条款) 有限,取决于日志开关
我的邮箱 → 我用的那家 AI 我的邮箱 → 中转站 → 模型厂商 中转站运营者 + 厂商 基本查不到
我的邮箱 → 我的 Agent 我的邮箱 → Agent 的云电脑(持久磁盘、快照、备份) 平台,含快照 查不到
我的邮箱 → 我的 Agent 我的邮箱 → 路由层按需换模型 每一家被路由到的厂商 通常看不到

第四行是最容易被忽略的。为了让成本好看,现在的产品普遍会在后面挂一个路由层,简单问题走便宜模型、难问题走贵模型。你的邮件内容于是变成了一个会被分发的东西——分给谁,取决于当天哪个模型便宜、哪个配额还够。

而第二行那段「中转站」,Anthropic 在报告里给了一个我认为最准确的词:transfer station。攻击方把请求发给中转站,中转站用自己的一池欺诈账号转发给 Anthropic 的 API,流量就此被「洗白」成来自全球各地的合法个人用户。你的请求不是被转发一次,而是被经手一遍。

这就是为什么我对「读取」这个词这么敏感。在我这里,给 agent 读权限,等价于把数据的保管权交出去,而且是交给一整条你不掌握、不透明、不在你选择范围内的链路。

「分身」这个比喻错在哪

真正让我决定写这篇的,不是上面那条链路,而是「分身」这个说法本身。

厂商的营销语言里,agent 是你的数字分身、是你的另一种存在方式。这个比喻听起来很浪漫,但它偷换了一件很具体的事:分身意味着你和它信息对等,而信息对等恰恰是你今天最不想要的东西。

老板不会这么干。一个老板雇了助理,他会把所有信息都给这个助理吗?不会。助理拿到的是一个范围:日程可以看,报销单据可以处理,但薪酬表、董事会材料、并购意向书、银行 U 盾,都不会交出去。助理做的判断,是建立在老板已经定好的判断之上的——老板定原则,助理执行细节。助理的权限是有边界的,助理的行为是有记录的,助理是可以被换掉的。

我拉了一张对照表,把「人类助理」和「今天的 personal agent」放在一起:

维度 人类助理 今天的 personal agent
她是谁 签了合同、有身份的人 一个常驻在别人云上的进程
她能看到的范围 你交办的那些事 你授权的一切,且随你接的工具自动变大
行为有记录吗 邮件、工单、CRM 里留痕 取决于厂商,多数默认不给你看
你能否问「上周三你干了什么」 能,她自己记得 要开开发者模式翻日志,还不一定全
她带走了什么 要扛一箱纸或一个 U 盘 每次调用就复制一份到远端
人员流动 交接工牌、签保密、你换密码 你得逐个撤 token,还不确定有几把钥匙
出事谁担责 公司担责,有法可依 责任落在服务条款的某一行里

右边这一列,每一条都比左边差。而右边这一列正在被包装成「你的分身」。

再往深一层:你连复盘都做不到。 人类助理你至少可以事后问、可以找第三方对账、可以把邮件记录翻出来。而 agent 的「上周三做了什么」,答案在它的运行日志里,运行日志在厂商手里,厂商给你的通常是摘要视图。出了问题你想查「它到底把我的哪封邮件发给了谁」,你会发现你连问的对象都没有——文档里只会写「日志保留 xx 天」。

一个你无法复盘、无法追责、无法限制范围、却掌握你全部身份与凭据的执行体,这不是分身,这是风险敞口。

那我会怎么用它:让它入职,而不是让它接管

我不反对用 personal agent。我反对的是「把整个收件箱交给它」这个起点。我的做法是把它当成一个新入职的员工处理——不是修辞,是具体清单:

  • 发一张工牌,而不是给它你的身份证。 给它一个专用的邮箱地址(比如 assistant@你的域名),它只能收发这个地址的信。要它看的信,你转给它。你的主收件箱里的东西,它一封都看不到。
  • 划定收件范围,并且留痕。 转发给它的时候抄送自己一份,让它处理过的每封信在你自己的邮箱里都有对应记录。它做的动作不至于脱离你的视野。
  • 关键动作卡在审批上。 回信、改价、承诺时间、对外发东西,这类带不可逆后果的动作,走审批再放行。敏感的开关、金额上限、有效期限,都该是显式的策略,而不是一句「你看着办」。这块现在是整个行业最热的一层。
  • 凭据给钥匙不给主钥。 不要把你长期有效的 API key、密码管理器主密码塞给它。能发短时会话钥匙就发短时会话钥匙,能限额度就限额度,能设有效期就设有效期。
  • 留一份完整的动作日志在你手里。 至少要做到:它读了什么、改了什么、发出去了什么,你能导出来。没有这个,前面四条都只是心理安慰。
  • 保留「一键离职」。 撤凭据、吊销工牌、把日志整包导出、把已发出的东西列一份清单——这个流程要在用它之前就写好,不要等出事那天现场想。

这套东西听起来比「让 agent 读我的邮箱」麻烦得多。但它换来的是:这个员工能看到的东西,我说了算;它做过的事,我查得到;它越界了,我关得掉。

写到这里我想把话题拉回去。这不是我一个人的洁癖。厂商正在把这类能力当成标配往外推:给 agent 一个云电脑、让它常驻在你的邮件里、把「你可以像给同事发邮件一样给它派活」当成宣传语。这个方向本身没错——真正好用的 agent 确实需要长期在线、需要跨会话的记忆、需要能自己动手。问题在于,能自己动手的能力,和能碰到你全部信息的能力,被捆绑在一起卖出去了。

这两件事应该分开。前者是产品能力,后者是信任边界。现在的情况是:你想用前者,就必须接受后者,而且接受的姿势是整个收件箱。

我不接受。我宁可多花十分钟转发邮件,也不愿意有一天要去问一个我控制不了的进程——「上周三,你把我的哪封信发给了谁?」

相关阅读:

By AI博士 万戈