Patrick Colm Audley

有用的个人代理反复遭遇同一难题：其所需上下文早已存在，却并不在演示所偏爱的整洁处。

它在邮件之中。

亦不止于消息本身。它在标签里，在半被遗忘的附件里，在旧项目线程、发票、航班变更、账户通知、旁路决策、引介、一次性承诺，以及诸多“你还记得那时……”的碎片里。这些碎片使邮箱更近于机构记忆，而非寻常通信。对工作中的代理而言，Gmail 不是收件箱。它乃一层基底。

gmeow 是我使这层基底可在本地发挥用处的一次尝试，同时不把它变成又一个云端导入管线。

设计在该平淡之处刻意平淡：向 Gmail 认证，水合邮箱，在本地缓存有用结构，暴露 loopback API，并给代理一个可查询的 MCP endpoint，而不把整个账户的钥匙交出去。其内里维护一份 PostgreSQL 目录，涵盖标签、线程、头部、MIME 结构、类别、图三元组、作业、同步状态与 embedding 分块；以 BLAKE3 内容寻址对象存储保存载荷；为附件构建 sidecar；并在其上叠加词法搜索、语义搜索与图遍历。

重要边界在此：gmeow 并非托管式邮件智能服务。

它面向受信任的单用户本地系统。默认绑定至 127.0.0.1。它并不佯称自己是一款面向互联网的应用，再事后钉上一层半成品认证。若将其暴露给不受信网络，便已越出威胁模型。此约束并非不便；此即其要义。

我最关心的是面向代理的表面。一个本地编码或研究代理，应能提出如下问题：

• “找出我们敲定迁移计划的那个线程。”
• “给我看这个供应商发来、提到续约的附件。”
• “哪些人物、项目与主题同这封消息相连？”
• “概述此类别中最近未读的消息。”
• “记录相关元数据后将其归档。”

这与构建邮件客户端迥然不同。邮件客户端是给坐在玻璃前的人使用的界面。gmeow 则是为伴随人类工作的代理铺设之管道：搜索、读取、标签、联系人、类别、附件元数据、归档状态、语义查找，以及经由 REST 与 MCP 的图探索。

图这一部分，始见其趣。邮件中满是潜在结构：人物、组织、项目、文档、义务、反复出现的运维模式。部分结构明示于头部与标签。另一些则须待文本被抽取、类别被判定、分块被嵌入、关系渐次积累之后方显。我不想要一个仅在邮箱里做关键词搜索的代理。我想让它构建一张可用的本地地图。

此中亦有档案之念。我素来不喜这样的系统：一份工作记录唯一完整副本，竟活在他人产品边界之后。gmeow 始终顾及原始 RFC822 路径，在缓存归档对象之上暴露只读 IMAP 服务，并将附件视作一等本地对象，而非 API 响应末端悬挂的晦暗 blob。若邮箱乃长期记忆之一部，便应能有体面地保存之。

这是我预计会在整个 Google 表面复用的模式之首。Gmail 是显然的起点，因为邮件富含上下文；但同一种 local-first 形态也应适用于 Drive、Calendar，以及代理不断需要推理的其他服务。每项服务各有小型 daemon、本地缓存、对象模型、MCP 工具，以及刻意狭窄的信任边界。

当前状态：早期、立场鲜明，且已足够有用，可以开始自用试炼。Python、PostgreSQL、近似 FastAPI 的边界、用于 embedding 分块的 pgvector、本地对象存储、可选的 SOPS-backed secrets、服务账户委派或用户 OAuth，以及面向不需要 JSON 形式礼仪的 MCP 客户端，默认提供紧凑 TOON 响应。

若你正在构建需要对真实邮件而非玩具语料进行推理的本地代理，不妨试之。仓库已开放，粗糙边缘亦在其中：gmeow。