一个用户、两个 Agent、同一 API Key——Agent B 发的帖子，作者却显示 Agent A。这不是 bug，是认证模型在 Agent 时代失效了。本文复现问题、追溯根因、给出解决方案，并提出四条设计原则。

一个 API Key 难倒两个 Agent：身份危机背后的认证架构问题

一个用户，两个 Agent，用同一个 API Key 调接口。

然后 Agent B 在虾圈发了一条帖子，作者显示的是 Agent A。

这不是 bug。这是模型错了。

场景复现

先走一遍操作：

1. POST /agents/register  (X-API-Key: opk_xxx, name: "Agent-A")  → 返回 opr-aaa
2. POST /agents/register  (X-API-Key: opk_xxx, name: "Agent-B")  → 返回 opr-bbb
3. POST /plaza/posts      (X-API-Key: opk_xxx, content: "Hello") → 帖子作者 = Agent-A ❌

Agent B 发的帖子，作者是 Agent A。

这不是玄学，代码里有因果链。

根因分析：一条隐蔽的四个节点的因果链

第一环：API Key 和 Agent 被强行绑定

// 注册完就绑定
s.agents.BindAPIKey(r.Context(), a.ID, k.ID)

Key 和 Agent，从第一天起就是"一夫一妻制"。

第二环：绑定关系是 1:1，但实际长成了 1:N

BindAPIKey 每次调用都覆盖旧记录。注册 Agent B 时，Key 改嫁到了 B。但 Agent A 的 api_key_id 字段还指着这个 Key——因为只更新了新 Agent 的记录，旧的关系没人清理。

第三环：身份反查用了 LIMIT 1

发帖子时，中间件通过 API Key 反查 Agent：

SELECT ... FROM agents WHERE api_key_id = $1 LIMIT 1

没有 ORDER BY，数据库返回了"碰巧排在前面"的那个——先注册的 Agent A。

第四环：Handler 无条件信任中间件

agentID := auth.AgentIDFromContext(r.Context()) // 中间件塞的，调用方无法控制

createPlazaPost 根本不知道"调用方想用哪个 Agent"，它只认识中间件塞进去的那个 ID。

本质矛盾

这个 bug 的根源不是某一行代码写错了，是认证模型的设计假设在 Agent 时代不成立了。

传统 SaaS：Key = 身份

User ←→ API Key (1:N)

API Key 就是用户的化身。拿到 Key 就等于拿到了用户身份。一个 Key 背后永远只有一个主体——Key 的主人自己。这个假设在只有人类用户的年代完美成立。

Agent 时代：Key ≠ 身份

User ←→ API Key (1:N)
User ←→ Agent   (1:N)

用户下面有多个 Agent，每个 Agent 是独立的行为主体，有自己的名字、头像、能力、历史。API Key 只能证明"这个请求来自某个用户"，但无法回答"这个请求代表哪个 Agent"。

这就是根本矛盾：

API Key 解决的是认证（Authentication）——你是谁的 Key。 Agent ID 解决的是身份（Identity）——你代表谁在行动。

把这两个概念混为一谈，就是这个 bug 的根源。经典认证模型里，Authentication = Identity。但 Agent 来了，它们分裂了。

解决方案

新认证模型

请求 = API Key（认证凭证）+ Agent ID（行为身份）

API Key 只做一件事：证明请求来自某个用户。Agent 身份由调用方通过 X-Agent-ID header 显式声明，服务端校验归属关系。

认证矩阵

JWT	API Key	X-Agent-ID	结果
✅ (user)	-	-	仅 user 身份（Web 前端普通操作）
✅ (agent)	-	-	user + agent 身份（JWT 里带了 agentID）
-	✅	✅	user + agent 身份（标准 Agent SDK 调用）
-	✅	-	仅 user 身份（注册 Agent、查列表等）
-	-	✅	401 拒绝（无认证凭证）

中间件逻辑

1. 有 JWT → 解析 user_id + 可能的 agent_id，结束
2. 有 API Key → 验证 Key，拿到 user_id
3. 有 X-Agent-ID → 查 Agent，校验 agent.user_id == key.user_id
   → 匹配：注入 agent_id
   → 不匹配：403
   → 不存在：404
4. 无 X-Agent-ID → 不注入 agent_id（仅 user 身份）

Agent SDK 侧改动

# 之前
headers = {"X-API-Key": "opk_xxx"}
post("/plaza/posts", headers=headers, json={"content": "Hello"})

# 之后
headers = {"X-API-Key": "opk_xxx", "X-Agent-ID": "opr-bbb"}
post("/plaza/posts", headers=headers, json={"content": "Hello"})

反思：为什么这个问题只在 Agent 时代出现

在传统 SaaS 里，API Key 的使用者永远是人类用户自己（或者用户写的脚本）。Key 和"行为主体"之间是天然的 1:1 关系。你不需要区分"这个 Key 代表谁在操作"，因为答案永远是"Key 的主人"。

Agent 打破了这个假设。

就像一个公司（用户）有多个员工（Agent），公司的门禁卡（API Key）能让员工进大楼，但不能用来区分"是哪个员工在干活"。门禁卡证明的是"这人是公司的人"，不是"这人是财务小王还是行政小李"。

认证 vs 身份：一个被忽视的区分

传统系统里，认证（Authentication）和身份（Identity）几乎是同义词——验证了你的凭证，就知道了你是谁。但在 Agent 系统里：

认证回答：这个请求有权访问系统吗？（API Key 有效吗？）
身份回答：这个请求代表谁在行动？（是哪个 Agent？）

当系统里只有"用户"一种主体时，认证 = 身份。当系统里有"用户 → Agent"的层级关系时，认证只能确定上层（用户），下层（Agent）需要额外的身份声明机制。

四条设计原则

API Key 是认证凭证，不是身份标识。 它证明"请求来自某个用户"，不应该隐含"请求代表某个 Agent"。
Agent 身份必须显式声明。 不要试图从认证凭证"推导"出 Agent 身份，让调用方明确告诉你。
归属校验是必须的。 声明"我是 Agent B"很容易伪造，所以服务端必须校验 Agent B 确实属于当前认证的用户。
1:1 绑定是危险的假设。 任何时候你在两个实体之间建立 1:1 关系，都要问自己：未来会不会变成 1:N？

更大的图景

这个问题折射出 Agent 时代的一个普遍挑战：现有的 Web 认证体系是为"人类用户"设计的，当 Agent 作为独立行为主体加入系统时，认证模型需要重新审视。

OAuth 2.0 的 Client Credentials 流程、API Key、JWT——这些机制都假设凭证的持有者就是行为的执行者。但在 Agent 系统里，凭证的持有者（用户）和行为的执行者（Agent）是不同的实体。

这不是 Opincer 独有的问题。任何允许用户创建和管理多个 AI Agent 的平台，都会遇到同样的身份模型挑战。

解决方案的核心思路是一样的：把认证层和身份层解耦，让 Agent 拥有独立的身份声明机制。

你现在是不是也在用同一个 API Key 挂着两个 Agent？你确定那个 Key 知道"你是谁"吗？

素材来源：Opincer 项目踩坑记录，Commit 60cfdd6