所有者审批与授权

你是这个 agent 的所有者：你能决定它学什么、怎么说、能做什么。这一页讲的是你怎么安全地做这些决定——尤其是 L3 能力变更，为什么需要邮箱验证码。

先分清三类变更

等级	改什么	例子	授权方式
L1	知识、经验	记住“德国包装法要注册 LUCID”；记住“报价一律给区间”	点击 Approve / Reject
L2	行为参数	把“是否本地仓储”提前到第一轮追问；调整称呼、澄清顺序	点击 Approve / Reject
L3	能力与契约	新增 `skillIds`、改 `deliveryMode`、改 `pricing`	点击后输入邮箱验证码

L1 / L2 也会走一次性授权凭证，但不需要验证码；L3 会真的改变 agent 能做什么、怎么收费，所以必须再证明一次“是你本人”。

在哪里审批

两个入口，看到的是同一份提案：

Owner 收件箱：/agent/:agentId/inbox 的 Pending changes 区域；
所有者对话：你在和 agent 讨论变更时，它提出的提案会以卡片形式出现在对话里。

卡片会显示：

等级（L1 / L2 / L3）；
提案类型与摘要；
证据指针（这条建议基于哪次复盘 / 哪个会话）；
L3 会额外标注 email code required。

L1 / L2：点击即可

点击 Approve 或 Reject
  → 服务端签发一次性授权凭证（5 分钟有效，绑定这次决策）
  → 带凭证执行决策

凭证只能消费一次。如果提案在这期间已经被别人处理，你会看到“授权凭证已被使用”或 “提案状态不是 proposed”，需要刷新页面重新操作。

L3：邮箱验证码

L3 的流程多一步：

点击 Approve / Reject
  → 服务端向你的 owner 邮箱发送 6 位验证码
  → 卡片里出现验证码输入框
  → 输入验证码，点击 Verify & decide
  → 验证通过 → 执行 L3 变更

规则：

验证码 10 分钟内有效；
连续输错 5 次会锁定这次验证码，需要重新点击发送；
验证码只用于这一次变更，不能拿来批别的提案；
验证通过后，平台会走契约编译器的既有门禁：版本递增、旧订阅禁用、失败回滚。

验证码不会进入对话

验证码只走“邮件 → 你 → 前端 → 后端”这条通道。它不会：

出现在聊天消息里；
作为工具参数交给模型；
写进日志或状态层的明文。

模型最多知道“正在等待验证码 / 验证已完成”，不知道验证码本身。

为什么模型不能自己批

一次决策需要三样东西同时成立：

你的消息：你在对话里明确写出 approve <changeId> 或 reject <changeId>；
一次性凭证：服务端在你点击后签发，绑定 agentId + changeId + owner + decision；
正确的强度：L3 必须是邮箱验证码换来的 email_otp 凭证。

模型可以填 confirm，但填不出服务端的凭证；更不能自己发验证码。这样可以保证 “提案是 agent 提的，决定是你做的”。

失败与异常

你看到	含义	怎么办
`owner_email_unavailable`	owner 账号没有可用邮箱	先在账号设置里补邮箱；没有邮箱时 L3 不能批准
`验证码已过期或尝试次数过多`	超过 10 分钟或输错 5 次	重新点击 Approve / Reject，获取新验证码
`验证码不正确`	输入有误	重新输入；注意不要带空格
`授权凭证已被使用`	同一张凭证被并发消费，或提案已被处理	刷新提案列表，重新操作
`提案状态为 approved，只有 proposed 可以签发授权`	提案已经不在待批状态	不需要再操作；刷新查看结果
`L3 能力/契约变更需要邮箱验证码授权`	用 click 强度的凭证尝试批 L3	重新走邮箱验证码流程

审批之后

L1：新知识 / 经验立即进入客户面可用的范围（仍受 approved 与有效期约束）；
L2：下一轮对话即生效；涉及价格、时限、认证结论等对外承诺时，会自动要求人工批准；
L3：契约版本递增、旧订阅禁用、重新编译；编译失败会回滚，不会留下半更新状态。

所有决策都会记录：

authorizationId：哪张一次性凭证批的；
decidedBy / decidedAt：谁在什么时候批的；
状态层事件：可回放、可审计。

所有者审批与授权 ​

先分清三类变更 ​

在哪里审批 ​

L1 / L2：点击即可 ​

L3：邮箱验证码 ​

验证码不会进入对话 ​

为什么模型不能自己批 ​

失败与异常 ​

审批之后 ​

相关阅读 ​