Iam

谢扬做了一个新产品叫 Qoni，定位是给 Personal Agent 用的身份基建。赛博禅心那篇报道的标题起得很准：给 Agent 发一张工牌。

思路我一看就熟。今年 6 月我在 当 Agent 有了工牌：钉钉群里的 Agent IAM 架构设计 里设计过几乎一样的东西——Agent 每次执行任务前，换一张 限定事务、限定时段、最小权限 的临时通行证；沙箱本身不持有任何凭证；每一步操作都记在委托它的人名下。Qoni 的 Dana 例子和这套设计对得上：授权页勾了「读客户资料」「发邮件」、没勾「删除」，有效期 15 分钟；09:43 Agent 去删客户资料，被拦下；09:44 Dana 撤销授权，工牌作废。

三个月后有人把我画在纸上的架构做成了产品，这是好事。 说明这个方向不是我一厢情愿。

但这篇报道里有一个细节，我读到时停了一下。它在「入职」那一节：

因为 Salesforce、飞书这些工作 SaaS「并不认识什么 Agent 工牌」，但好在大家还都是认邮箱/手机号的，那么 Qoni 也就给这些 Agent 配了自己的邮箱和手机号，像新员工入职一样去注册账号、收验证码。

给 Agent 发工牌的产品，为了让工牌真能用，做的第一件事是——给每个 Agent 再配一个邮箱和一个手机号。

这个动作里藏着整个 Agent 身份问题的死结，而几乎所有报道都滑过去了。

周一早上，运营群里有人 @了运营 Agent：「帮我看看上周退款率为什么涨了」。

Agent 开始干活。它先查了 AI 表格里的退款明细，又调了客服工单系统的投诉分类，接着跑了一段 SQL 算出各渠道的退款占比，最后生成一份带趋势图的分析报告发到群里。整个过程 40 分钟，中间还主动追问了一句：「要不要把退款金额 > 500 的单独拉出来？」

报告质量不错。但安全团队事后审计时发现了三个问题：

1. Agent 查退款明细时，用的是 @它那个人的 App Token——这个人恰好是运营总监，有全量数据权限。群里其他人没有这个权限，但他们都看到了报告。
2. Agent 调工单系统时，用的是一个 写死在环境变量里的 API Key，这个 Key 的权限范围是 read:all，理论上 Agent 可以读任何人的工单。
3. 日志里只记了「运营总监访问了退款表」， 没有记录是 Agent 在执行。

这是一个典型场景，我在不同企业里见过不同程度的版本。

在 Claude Tag 的 Agent Identity：为什么这是 Agent 时代的 OAuth 中，我讨论了 Agent 为什么需要自己的身份。这篇接着往下走： 当 Agent 进入钉钉群，权限、凭证、审计这套架构具体怎么设计？