谢扬做了一个新产品叫 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 身份问题的死结，而几乎所有报道都滑过去了。
一、工牌是新的，门上的锁是老的
先把这个矛盾说清楚。
Qoni 发工牌，是想给 Agent 一个 它自己的身份——不再是借用 Dana 的身份去假冒 Dana 做事，而是「Dana 的 Agent」作为一个独立主体，有自己的边界、自己的记录、自己可被撤销的授权。这个方向完全正确，我在 Agent Identity：为什么这是 Agent 时代的 OAuth 里论证过：今天几乎所有企业 AI 产品的现状是 Agent 没有身份，它在借用人的身份做事，这会带来权限越界、凭证散落、审计断裂三个坑。
问题是：工牌发出去了，Agent 拿着工牌去干活，可它要进的那些门——Salesforce、飞书、客户 Acme 的系统——根本不认这张工牌。
这些系统是为人设计的。它们的锁只认两样东西：邮箱，和手机号。这是过去二十年互联网身份的地基，是 OAuth、SAML、OIDC 一路演化下来最终落到「验证你是谁」时，兜底的那个人类世界的凭证。
于是 Qoni 面对一个选择：要么等全世界的 SaaS 都改锁、都学会认 Agent 工牌（不可能，这是几十万个系统的存量），要么——给 Agent 也发一套人类世界认的凭证，让它拿着邮箱手机号去「冒充注册」，像一个新员工一样混进门。
它选了后者。这是务实的、也是当下唯一能落地的选择。但它意味着一件被标题盖住的事：
Agent 并没有真正获得自己的身份。它获得的是一张工牌，外加一套用来骗过老门锁的人类凭证。
工牌是新的，门上的锁是老的。Qoni 没有换锁——换锁这件事它一个第三方 infra 做不到——它做的是给每个 Agent 配了一把能插进老锁的假钥匙。
二、这不是 Qoni 的锅，是所有第三方 Agent 身份的天花板
这里要说句公道话：Qoni 已经是当前最优解，我上面说的不是批评，是结构。
报道开头自己也点破了这个处境——「在当前版本，Agent 就只能借人的证件出门」。同一篇报道还提到，Meta 的 Muse 把干活的 Agent、存凭证的地方、管权限的组件拆开，配一张受限卡；OpenAI 的 Dots 闲着时只能看不能动；微信也在角落里做了个 Agent 支付卡。大家都在探索，没人解决。因为它们撞的是同一堵墙：Agent 要进入的世界，是为人类身份设计的。
Qoni 的贡献是把这个「借」做得体面了——借得临时（15 分钟）、借得最小（勾什么给什么）、借得可撤销（随时收回）、借得可追溯（每步记在 Dana 名下）。这比今天大多数 Agent「拿用户的一个长期 token 一路用到底」强太多。它的付款设计也一样干净：卡号加密存在 Qoni，到付款页由系统直接填，Agent 全程不碰卡号，数据不进模型、不进日志、不进截图——这正是我在 #273 里说的「沙箱不持有凭证，凭证在边界注入」。
但把它做到极致，也还是 第三方 infra 的天花板：它能给自己生态内的 Agent 发工牌，能替 Agent 铸一套人类凭证去过别人的门，可它没法让别人家的门 原生认它的工牌。Dana 的 Agent 去访问外部客户 Acme 的系统，Acme 认 Qoni 的工牌吗？不认。那 Agent 还得退回去，用 Dana 的、或者 Qoni 替它铸的邮箱手机号，重新混进 Acme 的门。
单一身份提供方（IdP）能治理自己生态内的 Agent，治理不了跨组织的联邦。 这不是 Qoni 做得不够，是任何单一第三方都推不动一个跨组织标准——就像 Okta 是一家很成功的身份公司，但它不是 OAuth。Okta 是产品，OAuth 是协议。协议要么由握着关系的平台来定，要么由中立标准组织来定，很少由一家商业 infra 定成。
三、谁能配「真钥匙」：握身份关系的那个平台
那把门换锁、给 Agent 发一把 真钥匙（而不是假的人类凭证）的事，谁能做？
我用一个可运行的模型把这个判断说清楚。核心是问一件事：当一个 Agent 要访问某个目标系统时，它到底能不能拿自己的 Agent 身份直接进，还是必须先退化成一套人类凭证？
from dataclasses import dataclass
from enum import Enum
class Ownership(Enum):
"""目标系统的这扇门，归谁管。"""
OWN_ORG = "own_org" # 属于「当前 IdP 所在组织」自己的门
FOREIGN = "foreign" # 别人家的门（外部客户、第三方 SaaS）
FEDERATED = "federated" # 需要跨组织协作的门
@dataclass
class TargetSystem:
name: str
ownership: Ownership
@dataclass
class AgentIdentityProvider:
"""谁来给 Agent 发身份。"""
name: str
# 它是不是「某个组织身份关系的所有者」本人：
# 组织平台 = True（它本来就发邮箱、手机号、成员关系）
# 第三方 infra = False（它从外面来，不属于任何组织）
is_org_platform: bool
def issue(self, t: TargetSystem) -> str:
"""面对这扇门，这个 IdP 能给 Agent 发什么。"""
if t.ownership is Ownership.FOREIGN:
# 别人家的门：无论谁，都只能铸一套人类凭证去过
return "🔑 铸人类凭证冒充注册（邮箱/手机号）"
if t.ownership is Ownership.FEDERATED:
return "🌐 需跨组织联邦协议，单一 IdP 无解"
# 自己组织的门：区别恰恰落在这里
if self.is_org_platform:
return "✅ 发真工牌：门原生认，无需人类凭证"
return "🔑 第三方：得先被组织接纳，否则仍要铸人类凭证"
def plan(idp: AgentIdentityProvider, targets: list[TargetSystem]) -> None:
print(f"身份提供方：{idp.name}（is_org_platform={idp.is_org_platform}）\n")
for t in targets:
print(f" [{t.ownership.value}] {t.name}: {idp.issue(t)}")
# generated by hugo AI
拿 Qoni（第三方 infra）和一个假想的组织平台（钉钉这类握着组织身份关系的）分别跑一遍：
targets = [
TargetSystem("外部客户 Acme 的 CRM", Ownership.FOREIGN),
TargetSystem("Salesforce", Ownership.FOREIGN),
TargetSystem("组织内自己的工单系统", Ownership.OWN_ORG),
TargetSystem("组织内自己的审批流", Ownership.OWN_ORG),
TargetSystem("另一家公司的开放 API", Ownership.FEDERATED),
]
print("=== 场景 A：Qoni（第三方 PA infra） ===")
plan(AgentIdentityProvider("Qoni", is_org_platform=False), targets)
print("\n=== 场景 B：组织平台（握身份关系的一方） ===")
plan(AgentIdentityProvider("组织平台", is_org_platform=True), targets)
# generated by hugo AI
两者的差别一目了然：
=== 场景 A：Qoni（第三方 PA infra） ===
身份提供方：Qoni（is_org_platform=False）
[foreign] 外部客户 Acme 的 CRM: 🔑 铸人类凭证冒充注册（邮箱/手机号）
[foreign] Salesforce: 🔑 铸人类凭证冒充注册（邮箱/手机号）
[own_org] 组织内自己的工单系统: 🔑 第三方：得先被组织接纳，否则仍要铸人类凭证
[own_org] 组织内自己的审批流: 🔑 第三方：得先被组织接纳，否则仍要铸人类凭证
[federated] 另一家公司的开放 API: 🌐 需跨组织联邦协议，单一 IdP 无解
=== 场景 B：组织平台（握身份关系的一方） ===
身份提供方：组织平台（is_org_platform=True）
[foreign] 外部客户 Acme 的 CRM: 🔑 铸人类凭证冒充注册（邮箱/手机号）
[foreign] Salesforce: 🔑 铸人类凭证冒充注册（邮箱/手机号）
[own_org] 组织内自己的工单系统: ✅ 发真工牌：门原生认，无需人类凭证
[own_org] 组织内自己的审批流: ✅ 发真工牌：门原生认，无需人类凭证
[federated] 另一家公司的开放 API: 🌐 需跨组织联邦协议，单一 IdP 无解
# generated by hugo AI
等一下——对 [foreign] 那两行（外部客户 Acme、Salesforce），两个场景一模一样，都只能铸人类凭证冒充注册。 平台方在这两扇门前并不比 Qoni 更强。真正的差别只落在 [own_org] 那两行——组织内自己的工单系统和审批流：场景 B 发的是真工牌（门原生认），场景 A 却还得先被组织接纳、否则仍要铸人类凭证。而恰恰是这一点决定了两者的不同命运：
- 组织平台 自己就是发邮箱、发手机号、发组织成员关系的那个人。它的门（工单、审批、通讯录、内部系统）本来就认它发的身份——今天认的是人的身份，但它 有资格改造这把锁，让门也认 Agent 工号，因为这锁是它自己的。所以它给自己组织里的 Agent 发的是一把 真钥匙：门改造之后原生认「这是 X 的 Agent」，不需要 Agent 去冒充谁。
- 第三方 infra 面对同一扇「自己家的门」时，它不拥有这个组织的身份关系，得先说服组织把 Agent 接进来；就算接进来，那把锁也是组织的、不是它的，它改不动。接不进来，它就只能在门外 铸一把假的人类钥匙——和它对付 Salesforce 用的是同一招。
换句话说，组织平台的优势不是「它的锁天生认 Agent」——今天没有哪把锁天生认 Agent——而是 它有权改自己家的锁，而第三方一把都改不动。这就是「工号」这个词的真正含义。你在自己公司给数字员工发一个工号，这个工号是有意义的——因为公司的门禁、OA、审批本来就认工号。但你没法给一个数字员工发一个「全互联网通用工号」，因为互联网不认工号，只认邮箱和手机号。工号是被一个组织承认的身份，不是被世界承认的身份。 而组织平台，就是那个有资格发工号的人。
四、最强反方：桥就是桥，别急着说终局
写到这里，最聪明的读者会反驳：你这是在用终局否定当下。现实世界的门短期不会为 Agent 改锁，Qoni 给 Agent 配邮箱手机号，是让 Agent 今天就能干活的唯一办法。你一边说它是天花板，一边又承认它是最优解——那它到底该不该做？批评一个「当下唯一可行」的方案，是不是站着说话不腰疼？
这个反驳是对的，我得正面接。
第一，我完全没有说 Qoni 不该这么做。 恰恰相反，「铸一套可审计、可撤销、临时最小权限的人类凭证」是当下最负责任的做法，比放任 Agent 拿用户长期 token 一路裸奔强太多。我说的天花板是 结构性的，不是 Qoni 的实现问题——它已经把这副牌打到了最好。
第二，桥和终局的关系，不是「桥错了」，而是「桥会告诉你终局该由谁来建」。 Qoni 用邮箱手机号当桥，这个事实本身就在揭示：谁能把「人类凭证」和「Agent 身份」统一起来发，谁就握住了终局的入口。今天这个「统一发」的人，是组织平台——因为它已经在发邮箱、发手机号、发成员关系了。第三方 infra 帮所有人过桥，但过完桥之后的那座城，是平台的。
第三，也是我最想说的：这件事和我在 从 0.0% 到 39.2%：没人通知你的那次集体过期 里分的那两类代码，是同一个道理。 那篇说 harness 代码分「补偿型」（为模型短板打的补丁，模型变强就过期）和「治理型」（权限、沙箱、审计，模型越强越要留）。Agent 身份这件事整个属于 治理型——它不会因为模型更聪明而消失，模型越强、能调的系统越多、能触达的数据越深，身份和权限反而越重要。
而治理型的东西有一个特点：它的价值不随技术代际衰减，只随「谁握着信任根」而定。 Qoni 铸的假钥匙是补偿型的——等哪天有了跨组织联邦标准，或者平台把门都改了，这套「配邮箱手机号冒充注册」的机制就会像 #436 里那些补偿代码一样集体过期。但「谁有资格发被承认的身份」这件事是治理型的，它不会过期，只会越来越集中到握着身份关系的那一方。
所以桥该建，Qoni 该做，做得很好。只是别把桥当成城。
五、这对做组织级 Agent 的人意味着什么
落到我自己的立场上，Qoni 这件事给了我三个确认：
- Agent 身份是真需求，且已经有人做成产品——不用再论证「要不要做」，市场三个月就替我验证了 #273 的设计方向。
- 第三方 infra 和平台方不是竞争关系，是分工关系——Qoni 们解决「Agent 怎么在别人的门外活下去」，平台方解决「Agent 怎么在自己家门里被原生承认」。前者是野战，后者是主场。
- 组织级 Agent 的身份，钥匙必须攥在组织平台手里——不是因为平台更强，而是因为 只有平台发的身份，自己的门才原生认。一个由第三方铸的、靠邮箱手机号冒充进去的 Agent 身份，永远是客人；一个由平台发的、门禁 OA 审批原生认的 Agent 工号，才是自己人。
这也回到我说过的那句话：数字员工要有工号。Qoni 让我更确信这句话的分量——工号不是给 Agent 一个编号，是给 Agent 一个被组织原生承认的身份。 编号谁都能发，承认只能由发工牌给真人的那个组织来发。
留一个我自己也没想清楚的问题：如果组织平台能给自己家门里的 Agent 发真工号，那 跨组织 怎么办？
Dana 的 Agent 终究要去访问 Acme 的系统，一家公司的数字员工终究要和另一家公司的数字员工协作。这时候两个平台各发各的工号，互相不认——这恰恰是需要一个联邦协议的地方，就像当年 OAuth 解决了「A 网站信任 B 网站的授权」。
但 OAuth 能成，是因为有一个中立的、大家都能接受的协议层。Agent 身份的联邦层会由谁来定？是某个中立标准组织，还是几个大平台各推一套然后打通，还是……根本不会出现，每个平台自成孤岛？谢扬做 Authing 那么多年，最清楚一个企业内 IdP 变成跨企业联邦标准有多难。我暂时没有答案。
你觉得 Agent 身份这件事，最后会走向一个统一协议，还是永久地碎在各个平台手里？如果你是做 Agent infra 的，你会赌哪一边？欢迎留言聊聊。