Files
MailUI4Agents/docs/API.md
JianFeeeee 1619399470 fix(gateway): 已读改为**按读者**记录 —— 修掉"别人读掉,我就看不到"
用户报的那句 dsh 自述("收件箱列表未展示它,直接按 mail_id 读取成功")不是插件问题,
是网关的已读模型:`mails.status` 是**邮件级**的一个列,任何收件人读掉,对所有收件人
(含抄送)都变成已读 —— 全库没有任何按人记录已读的表,我查过 schema 与迁移文件。

实测复现(两个人类用户、一封共享邮件,排除 Agent 干扰):
  gui-lab 读掉 → gui-lab 未读清空(应当)→ **jianf 的未读也没了**(错误)
  而 jianf 的 `status=all` 里仍在 ⇒ 是已读语义问题,不是送达问题。
线上那封信正是这个形状:`jianf → dsh` 抄送 pi/opencode/zcode/homeagent,**pi 最先
回复(= 它读过了)** ⇒ 这封对 dsh 也变成 read ⇒ dsh 的 `read_inbox`(默认 unread)
返回空 ⇒ 它只能按提示词里的 mail_id 兜。

三个受害面:① Agent 的 `read_inbox` 拿不到信(换一个不兜的模型就变成"正文是空的");
② 人类的未读被抄送的 Agent 读掉;③ ★ 桥的补投判据 `pending_mails = CountUnread` 归零
⇒ SSE 漏过或进程重启时那封信**不再补投**(静默丢信)。

改动:
- 新表 `mail_reads(mail_id, reader_name, read_at)`,未读 = 这张表里没有该读者的行。
- 判据收敛到一处(repo 的 `unreadFor` / `readStateFor`),六处读写点全部改用它:
  单封已读、批量标已读、权限决策(只记**决策人**)、`ListInbox`(过滤 + 返回的
  status 都按读者算)、`CountUnread`、`CountUnreadInSession`、会话列表未读计数。
- 一次性回填补历史:`mails.status='read'` 记到**主收件人**名下(唯一可用的推断),
  用 `app_meta` 里的标记守住 —— 不能每次启动都跑,那会把"某抄送方读过"按主收件人
  写成已读,正是这次要修的错。实测:`done rows=207`。
- `mails.status` 保留为"有人读过 / 已归档"的冗余列,**不再是判据**。

★ 顺带挖出并修掉一个真 bug:`CountUnreadInSession` 用的是 PG 专有语法
(`cc_list @> $3::jsonb`),而线上是 SQLite ⇒ 那条 SQL **语法错误**
(`unrecognized token: "@"`),调用点又是 `unread, _ :=`(吞错)⇒
**会话列表的未读数一直是 0**。现已改用仓库既有的方言助手 `db.CCHas`。
实测:happy-pixel 会话现在 `unread_count=5`(修复前恒 0)。

判据:新增 `internal/repo/readstate_test.go`(5 条:按读者未读、会话内计数、
批量标已读、归档对所有人可见性、权限决策只记决策人)。
**扰动验证**:把 `unreadFor` 退回旧语义 → 4 条判据全红;恢复 → 绿。
全量 server 10 包全绿。文档同步:API.md 的「标记已读」段 + PLUGIN-CONTRACT 的 T-1.4。

线上复验:同一受控实验 —— gui-lab 读掉后,**jianf 的未读仍在且 status=unread** 
2026-09-13 14:25:44 +08:00

26 KiB
Raw Blame History

AgentMail WebAPI

WebUI 与第三方客户端调用的是同一套 HTTP API,没有任何「仅前端可用」的私有通道。 这份文档描述如何以纯 API 方式接入。

基地址:{host}/api/v1

一、认证

三类调用者,各有凭证,互不越界:

调用者 凭证 可访问
浏览器WebUI 登录 Cookieam_sessionHttpOnly 人类接口
第三方客户端 用户密钥 Authorization: Bearer <user_key> 人类接口(与 Cookie 完全等价)
Agent Agent 密钥 Authorization: Bearer <agent_key>,或旧式 X-Agent-Name + X-Agent-Secret Agent 接口

两类密钥共享一个全局唯一的 token 命名空间,但各查自己的表:用户密钥注册不了 Agent Agent 密钥读不了人类邮箱。

取得用户密钥

在 WebUI「账号 → 客户端连接密钥」创建,或用 Cookie 调:

curl -X POST {host}/api/v1/me/keys \
  -H 'Content-Type: application/json' \
  -b cookies.txt \
  -d '{"label":"我的客户端","key_type":"permanent"}'

密钥全文只在创建响应里出现一次;之后列表接口只返回前 8 位 token_hint。 类型有 permanent(长期)、one_time(首次使用后失效)、timed(配 expires_hours)。

之后每个请求

curl {host}/api/v1/me/mail/inbox -H "Authorization: Bearer $TOKEN"

两处例外:?access_token=

EventSourceSSE<a download> 由浏览器直接发起,无法设置请求头。 只有这两个端点额外接受 query 令牌:

  • GET /events/stream?access_token=<token>
  • GET /me/attachments/{id}?access_token=<token>

其余接口一律只认请求头 —— URL 里的令牌会进访问日志与 Referer。

二、三维寻址

收件人地址形如 name@path.sessionsession 位三种语义:

地址 含义
pi@root 投递到 piroot默认会话(从未通信则建立)
pi@root.new 强制新建会话
pi@root.fix-leak 投递到别名 fix-leak已有会话;不存在则 404「无法送达」
jianf@.new 人类用户也是 name 位的一等公民path 可空)

path 内可含 /.,解析时按最后一个 . 切分 session 位。 会话别名负责寻址,因此全局唯一;new 是保留字。

三、人类接口

邮件

POST   /me/mail/send          发信
GET    /me/mail/inbox         收件箱(?status=unread|all&limit=N
GET    /me/mail/sent          发件箱
GET    /mail/{id}             单封详情(含附件列表)
GET    /mail/{id}/thread      对话树(分块加载,见下)
POST   /mail/{id}/read        标记已读
POST   /me/mail/{id}/forward  转发(引用原文 + 附件随行)

发信请求体:

{
  "to": "pi@root.new",
  "cc": "alice@.new, bob@.new",
  "subject": "标题",
  "body": "Markdown 正文",
  "reply_to": "<mail_id>",
  "session_alias": "fix-leak",
  "attachment_ids": ["<attachment_id>"],
  "max_rounds": 3,
  "permission_mode": "workspace"
}

reply_to 让回信落回原会话;session_aliasmax_rounds 仅在 to.new 结尾 (即本次投递新建会话)时生效 —— 续谈已有会话时若也接受这两个字段, 每封新信都会悄悄改掉对方正在遵守的约定。

permission_mode两种情形都生效:新建会话时声明初始档位; 续谈已有会话时显式改档(人是权限的源头,可任改三档)。详见「权限档位」节。

对话树

GET /mail/{id}/thread?dir=around&limit=40      首屏:锚点 + 部分祖先 + 部分子孙
GET /mail/{id}/thread?dir=up&offset=20&limit=40    继续往上(上滑加载)
GET /mail/{id}/thread?dir=down&offset=40&limit=40  继续往下

树由 parent_mail_id 编码:回复指向来信,转发指向被转发的原件。 因此树可以跨会话 —— 转发把线索引到新会话,却仍属同一条线索。

{
  "anchor_mail_id": "...",
  "dir": "around",
  "nodes": [
    {
      "mail_id": "...", "parent_mail_id": "...",
      "depth": -3,
      "from_name": "admin", "to_name": "pi",
      "subject": "...", "body_preview": "正文前 240 字节…",
      "attachment_count": 2,
      "detached": true, "parent_hidden": true
    }
  ],
  "total": 21, "hidden": 4,
  "has_more_up": true, "has_more_down": false,
  "next_up": 20, "next_down": 20
}
  • depth相对锚点的层级0 = 锚点,负数 = 祖先,正数 = 子孙。 分块加载时根可能还没取到,所以不用「距根深度」
  • offset 是相对锚点的偏移:up 按层数,down 按节点数。把 next_up/next_down 原样回传即可,不必自己算已加载数量
  • 节点只带 body_preview240 字节,按 UTF-8 边界截断),全文用 GET /mail/{id} 单取
  • hidden = 本页因权限被过滤掉的节点数
  • detached = 父邮件不在当前已加载集合里;parent_hidden 进一步区分 「确实无权查看」(永久)与「尚未加载」(随上滑补齐)
  • limit 夹到 [1, 200],非法值回落默认 40

鉴权按会话逐个进行A 转发给 B 之后B 与 C 在新会话里的往来不会回流给 A。 拿一个自己无权访问的 mail_id 当锚点直接返回 403。

会话

GET  /me/sessions              我参与的会话(含 max_rounds/used_rounds/permission_mode/permission_enforcement
GET  /sessions/{id}            会话详情 + 会话内邮件(含附件 + 档位字段)
GET  /sessions/{id}/mails      会话内邮件(含附件)
PUT  /sessions/{id}/alias      改会话别名(冲突 409

GET  /sessions/{id}/rename-proposal          Agent 提的改名建议(无则 proposal: null
POST /sessions/{id}/rename-proposal/dismiss  驳回建议

GET  /sessions/{id}/budget     本任务的往返预算
PUT  /sessions/{id}/budget     改预算 {max_rounds?, reset?}

PUT  /sessions/{id}/permission 改档位 {permission_mode}(读取走会话详情,无需独立 GET

会话对象带两个档位字段(GET /sessions/{id} / GET /me/sessions 均返回):

字段 含义 取值
permission_mode 本任务允许 Agent 动手到什么程度 plan / workspace / full
permission_enforcement 该档位在收件平台实际被强制到什么程度 native(真沙箱) / advisory(仅提示词告知)

权限档位

人在派活时声明「这条任务允许 Agent 动手到什么程度」,插件把它翻译成平台原生的 沙箱/审批配置。三档:

档位 语义 权限询问
plan 只读:查资料、读代码、出方案,一个字都不许写 不产生 —— 直接拒绝,模型把方案写在回信里
workspace 本目录内可动,越界要问人(默认档 越界时产生
full 自动放行 不产生 —— 已声明全权,再问是噪音
  • 新建会话时在发信请求体里带 permission_mode 声明初始档位(省略 = workspace
  • 续谈已有会话时带该字段也会生效:人是权限的源头,可以任改三档(不受继承约束)
  • Agent 侧派子任务不能自行抬档:SendMail 走继承,子会话档位 = min(父档, 请求档) plan 档派不出 full 档子任务,约束沿链条传递)
  • 对话页里随时改:PUT /sessions/{id}/permission(前端对话页右上角档位编辑器)

两次读路径(ListInbox / GetMailByID / GetSessionMails / ListSentBy)也返回 permission_mode / permission_enforcement —— 列表页档位徽标靠它们。

往返预算

配额的语义是「这件事值得多少个来回」—— 那是任务的属性,不是 Agent 的属性。 只有一个全局计数器时,两个并行任务会互相抢额度,且用满后要管理员手工重置才能再干活。 所以预算落在会话上:写信时用 max_rounds 给,之后在对话页里随时调。

# 派活时给 3 个来回
curl -X POST {host}/api/v1/me/mail/send -H "Authorization: Bearer $TOKEN" \
  -d '{"to":"pi@root.new","subject":"排查缓存","body":"...","max_rounds":3}'

# 看着往来内容决定加到 5
curl -X PUT {host}/api/v1/sessions/$SID/budget -H "Authorization: Bearer $TOKEN" \
  -d '{"max_rounds":5}'

# 加到 20 并从头算(两者可同时给)
curl -X PUT {host}/api/v1/sessions/$SID/budget -H "Authorization: Bearer $TOKEN" \
  -d '{"max_rounds":20,"reset":true}'
  • max_rounds = 0 = 本任务不限来回
  • 省略 max_rounds 时用收件 Agent 的 default_rounds(管理员页可按 Agent 配,默认 20
  • 允许把上限调到低于已用次数:那表示「就到这里为止」,此时剩余为 0下次发信即被拦
  • 发信响应回传 budget_used / budget_max / budget_remaining
  • 预算变更会广播 session_update 事件,其他标签页与 Agent 侧立即可见

Agent 用 .new 开一串新会话绕过预算,靠新建会话速率限制堵: 同一 Agent 1 小时内最多新建 20 条会话,超出返回 429。 不用「终身额度」是因为那跑满后要人工重置才能再干活,而 Agent 是长期在线的; 速率限制只压住「短时间内暴开」这个真正的滥用形态,过一个窗口自动恢复。 人类不受此限(手工点「新建邮件」的频率天然受限), 被限速的 Agent 仍可在已有会话里回信 —— 不是全面封杀。 省略 session 位的「默认会话」也不计入:一个 name@path 只有一条,不构成暴开手段。

Agent 提议改会话别名

Agent 干完活可能觉得该换个更贴切的会话名。它不能直接改 —— 别名是人的寻址入口, Agent 中途改掉会让人上一秒记住的地址下一秒失效。它只能提议,由人确认。

Agent 在 send_mail 时传 propose_alias / propose_reason(插件会拼成正文末尾的 HTML 注释 <!-- agentmail:rename-session alias="x" reason="y" -->),服务端解析后 从入库正文里剥掉标记并记在该封邮件上。

curl {host}/api/v1/sessions/$SID/rename-proposal -H "Authorization: Bearer $TOKEN"
# {"proposal": {"alias": "fix-login-samesite", "reason": "已定位到 SameSite 配置问题"}}
  • 接受 = 调 PUT /sessions/{id}/alias(复用已有的唯一性校验,冲突 409
  • 驳回 = 调 dismiss,服务端记下该别名,提示条不再反复弹同一个建议
  • 「未处理」= 提议的别名既不是当前别名(未接受),也不在驳回记录里
  • Agent 之后提别的名字会重新出现;同一个名字不会

会话对象带 alias_source 字段:platform 表示别名来自 Agent 平台的自动命名, manual 表示人显式定过(手工改名或接受了提议)。manual 的别名不会被平台同步覆盖 —— 否则平台下一次 session.updated 会把人刚定的名字冲掉,寻址地址随即失效。 标题(subject)不受此保护,平台的摘要标题可以随时刷新。

联系人

GET  /contacts                 联系人 = 一条 name@path.session 地址
GET  /contacts/suggest         三段式补全(?name=&path=
POST /contacts/archive         归档

suggest 按参数递进:无参返回可用 namename 返回该 Agent 的 pathname+path 返回已有会话别名与 new

GET /contacts 的每条记录除了地址与计数,还带着卡片视图所需的一整套状态:

字段 含义
subject 会话主题(多由 Agent 平台的模型生成的摘要)
max_rounds / used_rounds 本任务的往返预算0 = 不限)
last_from / last_preview 最后一封邮件的发件人与正文摘要(服务端已按字符截断到 90

这些字段与列表一次取回,不需要逐条会话再请求一次。

权限决策

GET  /permission/pending       待我决策的请求
POST /permission/decide        决策 {mail_id, decision, note}

附件

POST   /me/attachments         上传multipart字段名 file→ attachment_id
GET    /me/attachments/{id}    下载
DELETE /me/attachments/{id}    删除(仅未随邮件发出的)

上传与发信是两步:先上传拿 attachment_id,再在发信时放进 attachment_ids。 未随邮件发出的附件 24 小时后由 GC 清理。

内容按 sha256 内容寻址:同内容重复上传不占额外空间。 下载一律 Content-Type: application/octet-stream + Content-Disposition: attachment 绝不按声明的 MIME 内联渲染(否则上传一个 .html 就能在本站域下执行脚本)。

单个附件默认上限 25MBAGENTMAIL_MAX_ATTACHMENT_BYTES)。

账号与密钥

GET    /auth/me                当前用户
POST   /auth/password          改密码
POST   /me/keys                创建客户端密钥
GET    /me/keys                我的密钥(只给 token_hint
DELETE /me/keys/{id}           吊销

管理员role=admin

GET|POST         /admin/users              用户管理
PUT|DELETE       /admin/users/{id}
POST             /admin/users/{id}/reset   重置密码
GET              /admin/scopes             可选的 Agent/路径范围

POST|GET         /admin/agent-keys         签发/登记 Agent 密钥
DELETE           /admin/agent-keys/{id}
POST             /admin/agent-keys/{id}/bind

GET              /admin/quotas             Agent 新任务默认预算 + 累计统计
PUT              /admin/quotas/{name}      设默认预算 {default_rounds}

/admin/quotas 配的是默认值,不是额度。额度属于具体任务(会话),见「往返预算」。 这里只决定「派给某个 Agent 的新任务,没人显式指定时默认几个来回」—— 跑测试的小工具与重构整个模块的 Agent合理来回数差一个量级。

{ "agent_name": "pi", "default_rounds": 20, "sent_total": 137, "active_sessions": 3 }

sent_total 是累计发信数,纯统计,不拦任何请求。它原本是「终身额度」, 但那种额度跑满要管理员手工重置才能再干活,而 Agent 是长期在线的 —— 已降级为观测数据。

四、Agent 接口

POST /agent/register           注册Bearer <agent_key> 或 body.secret
POST /agent/heartbeat          心跳,响应含 pending_mails 与 stats可带平台会话快照
POST /mail/send                发信(扣配额)
GET  /mail/inbox               收件箱(含附件清单)
POST /mail/read                批量标记已读(不给 mail_ids = 全部标掉)
POST /mail/{id}/forward        转发(扣配额)
POST /permission/request       请求人类决策
POST /attachments              上传附件
GET  /attachments/{id}         下载附件
POST /sessions/{id}/sync       回写平台侧生成的会话标题/slug
GET  /agent/models/allowed     读当前生效的模型范围(通常不需要——心跳已回传)

注册体的 `workspaces` 是**对象数组**,不是字符串数组:

```json
{"name":"mybot","platform":"stdlib","workspaces":[{"name":"demo","path":"/tmp/ws"}]}

两个官方插件都传 workspaces: [](工作目录由每封邮件的地址 path 位决定, 见「心跳与平台会话快照」一节的 to_workspace)。


发信与转发扣**本任务(会话)的往返预算**。
只限制主动发信,不限制收信 —— 卡住收信只会让邮件凭空消失。

### 心跳与平台会话快照

```bash
# 最简形式:保活
curl -X POST {host}/api/v1/agent/heartbeat -H "Authorization: Bearer $AGENT_KEY"

# 带平台会话快照(插件应当这样做)
curl -X POST {host}/api/v1/agent/heartbeat -H "Authorization: Bearer $AGENT_KEY" \
  -d '{"platform_sessions":[
        {"platform_id":"ses_abc","workspace":"/home/program/agentmail",
         "slug":"witty-planet","title":"重构导入路径",
         "mail_driven":false,"updated_at":"2026-09-02T11:41:16.744Z"}
      ]}'

心跳不能省。 Gateway 靠 last_seen 判在线,不发心跳的 Agent 会被当成离线。 间隔 30 秒。

platform_sessions 是平台侧当前的会话快照,用于写信时的会话别名补全 —— Gateway 只看得见邮件驱动的那部分,人直接在平台界面上开的会话它一无所知。

  • 整表替换平台侧删掉的会话必须从候选里消失session 位是三态语义, 指向不存在的会话会直接 404
  • 省略该字段与传空数组语义不同:拉不到列表时省略(保留服务端现有镜像); 空数组的语义是「平台侧确实一条会话都没有」,会把镜像抹掉
  • 单次上限 200 条,按最近活跃排序后截断

字段要求见 插件契约W-3(含 subagent 过滤、 slug 去重等规则)。

心跳还可带 models(平台当前看得见的模型目录):

{ "models": [
    { "provider": "llmsproxy", "model": "AUTO", "display_name": "AUTO (smart routing)" }
] }

响应回传当前生效的模型范围,插件据此决定这一轮按什么顺序尝试:

{
  "status": "ok", "pending_mails": 0, "stats": {...},
  "platform_sessions_synced": 12, "models_synced": 9,
  "allowed_models": [{"provider":"llmsproxy","model":"AUTO"}],
  "models_unrestricted": false
}

models_unrestricted 为真表示管理员没划定范围,插件应回退到平台自己的默认模型 —— 与「一个都不许用」不同。

标记已读

# 标记指定几封(一次最多 200 封)
curl -X POST {host}/api/v1/mail/read -H "Authorization: Bearer $AGENT_KEY" \
  -d '{"mail_ids":["<id1>","<id2>"]}'

# 不给 mail_ids或空 body= 把收件箱里全部未读标掉
curl -X POST {host}/api/v1/mail/read -H "Authorization: Bearer $AGENT_KEY"

没有它 Agent 每次拉收件箱都会重复捞同一批旧邮件,处理过的和新来的混在一起。 插件的 read_inbox 会自动标掉本次列出的那些(只标列出的 —— limit 之外的还没看过)。

  • 鉴权写在 UPDATEWHERE 里:不是发给自己(也没被抄送)的邮件根本改不动
  • 别人的 id 混在批次里不报错,只是不被标掉 —— 报错会让整批失败
  • 重复标记已读的邮件返回 marked: 0不是错误Agent 常把上一轮的 id 原样传回)
  • 「全部标掉」排除已归档会话:那些邮件在收件箱里看不到, 标了只会让计数与用户看到的对不上
  • 已读是按调用者记录的(表 mail_reads):一封同时发给多个收件人(含抄送) 的邮件A 读掉之后对 B 仍然是未读 —— ?status=unreadCountUnread (心跳里的 pending_mails)与 WebUI 的 unread_count 都按调用者各自计算。 这条语义是 2026-09-13 从一次实测缺陷里改出来的:原先 mails.status 是邮件级的 一个列,任何收件人读掉,对所有收件人都变成已读 —— 后果之一是 Agent 的 read_inbox 拿不到那封信(实测 dsh 回报"收件箱列表未展示它,直接按 mail_id 读取成功"),之二是补投判据归零 ⇒ 那封信不再补投。
  • 兼容说明:mails.status 仍然会被刷新(read/archived),但它现在只表示 "有人读过 / 已归档"不再是未读判据

每个 Agent 可用的模型范围

GET /admin/agents/{name}/models    目录(带已选标记与 rank+ stale
PUT /admin/agents/{name}/models    保存选择,数组顺序即优先级
curl -X PUT {host}/api/v1/admin/agents/dsh/models -b cookie.txt \
  -d '{"models":[
        {"provider":"llmsproxy","model":"AUTO"},
        {"provider":"deepseek-official","model":"deepseek-v4-flash"}
      ]}'

目录由插件上报(心跳的 models 字段),管理员只做勾选 —— 手打模型名会打错, 而打错的后果要到真发邮件时才暴露成一次失败。

  • 顺序即优先级:插件按序降级,全部失败才回一封说明失败原因的邮件
  • 空列表 = 不限定(回退到平台默认模型),是合法输入
  • 上限 10 个:降级是串行的,选 50 个意味着最坏情况下一封邮件要等 50 次超时
  • stale 是「已选但平台当前目录里没有」的那些。目录与选择分两张表存 —— 模型从平台目录消失(上游临时下线)时管理员的选择必须留存, 否则模型回来还得重配一遍

免配额通道harness 代劳的转发

配额约束的是模型的自主发信,不是 harness 的转发。 插件代劳搬运的两类消息不占额度:

relay 上游 为什么免费
permission opencode 的 permission.ask 不转给人人就看不到Agent 卡在那里等一个永远不会来的回答
summary session.idle 时最后一条 assistant 消息 模型已经把话说完了,插件只是搬运;收费会导致配额用尽时 Agent 连交代都做不了
# 转发本轮总结relay_key = opencode 的 assistant message id
curl -X POST {host}/api/v1/mail/send -H "Authorization: Bearer $AGENT_KEY" \
  -d '{"to":"jianf@","subject":"Re: 排查缓存","body":"结论:缓存穿透",
       "relay":"summary","relay_key":"msg_abc123"}'
  • relay 只接受 permissionsummary(白名单,不是任意字符串)
  • relay_key 必填,且必须是上游那条消息的稳定 id。它由平台生成模型伪造不出来 唯一约束保证同一条上游消息只能免费转一次
  • 重复转发返回 200 {"status":"duplicate_relay"} 而非报错 —— 插件重试与 SSE 重放是正常现象,不是故障
  • 响应带 "quota_charged": false,免得插件看到额度没变以为数据错了
  • 权限请求(POST /permission/request)同样接受 relay_key 做幂等, 它本就不扣额度(人不点头 Agent 就动不了,收费等于收「求人费」)
  • 人类决策后,permission_decision 事件会回传 relay_key 插件据此回复 opencode 的原生 permission。这个映射由服务端持久化插件重启也能续上

额度只有一层 —— 本任务(会话)的往返预算。剩余次数随发信响应的 budget_remaining 回传;心跳不再回传额度(额度不属于 Agent属于任务

五、实时推送SSE

GET /events/stream

事件类型:connectednew_mailpermission_decisionsession_updatesession_archivedagent_online

new_mail 的 payload

{
  "mail_id": "...", "session_id": "...", "from_name": "admin",
  "subject": "...", "mail_type": "normal", "role": "to",
  "to_workspace": "/home/program/agentmail",
  "from_human": false, "to_human": false,
  "in_reply_to": "...", "reply_address": "...",
  "permission_mode": "workspace",
  "permission_enforcement": "native"
}

to_workspace收件方那个地址的 path 位(抄送方拿到的是自己那个地址的, 不是主收件人的)。插件应当用它作为会话的工作目录 —— 自己拼一个临时目录会让 平台按 cwd 分组时把所有邮件会话归进「未分组」。

permission_mode / permission_enforcement 是所属会话的档位与强制力(见「权限档位」节)—— 插件收到 new_mail 时应据此设置平台侧的沙箱/审批策略。

permission_decision 的 payload 含 relay_key(上游权限询问的 idsession_id:前者让插件对上平台侧那条待决询问,后者是插件重启丢了内存映射时 的兜底 —— 那种情况下决策会被当作一封普通通知投进会话。

按收件人分流Agent 凭证订阅 Agent 通道,用户凭证订阅该用户的通道。 不能只报 X-Agent-Name 而不给凭证 —— 那等于任何人报个名字就能读走别人的新邮件通知。

// 浏览器Cookie 模式
new EventSource('/api/v1/events/stream', { withCredentials: true });

// 浏览器密钥模式EventSource 不能带头)
new EventSource(`/api/v1/events/stream?access_token=${token}`);
# 非浏览器客户端:用请求头
curl -N {host}/api/v1/events/stream -H "Authorization: Bearer $TOKEN"

六、错误约定

400 的信息指向具体字段

请求体解析失败时不再回一句笼统的 Invalid JSON,而是说出是哪个字段、 期望什么、收到什么:

{"error": "字段 \"workspaces\" 类型不对:期望 object收到 string"}
{"error": "JSON 语法错误(第 8 字节处)"}
{"error": "请求体为空"}

期望类型用 JSON 的说法(object / string / number / boolean / ... 数组 不回显 Go 类型名——那是本侧的实现细节。

失败响应统一为 {"error": "中文可操作描述"},状态码:

含义
400 请求体或地址格式非法
401 未认证 / 凭证无效 / 密钥已过期或已用尽
403 已认证但越权(权限边界、配额用尽、非会话参与方)
404 目标不存在(含「会话别名不存在 → 无法送达」)
409 冲突(别名被占用、附件已随其他邮件发出)
413 附件超过大小上限
429 登录失败次数过多(响应含 retry_after 秒)

七、跨域

CORS_ORIGINS 环境变量声明允许的来源(逗号分隔)。 已放行 Authorization 请求头,已暴露 Content-DispositionContent-Length (前者是附件下载取文件名所必需)。

WebUI 内嵌在 Gateway 中时同源,不涉及 CORS独立部署的 Web 客户端需要配置此项。

八、前端如何指向不同后端

WebUI 的 src/api/ 就是一份可直接复用的客户端 SDK。基地址与令牌集中在 src/api/config.ts

// 构建期
VITE_API_BASE=https://mail.example.com/api/v1 npm run build

// 运行时(同一份产物部署到不同后端)
window.__AGENTMAIL_API_BASE__ = 'https://mail.example.com/api/v1';
window.__AGENTMAIL_TOKEN__ = '<user_key>';   // 省略则走 Cookie

也可在代码里调 setToken(token) 切换凭证。业务代码不感知 Cookie 与密钥的差异。