Agent 身份治理的核心不是发卡，而是留下可追责的行为链

企业开始给 agent 发“身份卡”，这是一件迟早会发生的事。

当 agent 不再只是个人电脑里的脚本，而是进入组织系统、连接知识库、调用工具、影响外部流程时，它必须有可识别的身份。谁创建了它，它属于哪个团队，它被设计来做什么，它大致拥有哪些权限，这些信息都应该被显性化。

但身份卡只能回答一个很有限的问题：这个 agent 名义上是谁。它不能自动回答另一个更关键的问题：这个 agent 在某一次具体行动里，到底有没有被正确授权。

给 agent 标注创建者、用途、权限和组织归属，是企业级治理的必要入口。没有这些字段，agent 很难进入权限体系，也很难被审计和追责。

问题在于，很多关于 agent identity card 的讨论容易停在“有身份凭证就更安全”。这其实低估了 agent 的运行方式。

传统服务账号的行为路径相对固定，权限范围也更容易被静态描述。但 agent 不一样。它会跨会话延续上下文，会读取历史记忆，会组合多个工具，还会根据模型推理临时决定下一步动作。也就是说，一个 agent 的真实身份，不只体现在 profile 里，更体现在它每一次使用能力时留下的证据链里。

身份卡负责声明“它是谁”，但治理系统还必须知道：

这些问题无法被一张静态身份卡覆盖。

agent 身份治理真正麻烦的地方，在于身份和行为之间存在缺口。

第一类缺口来自记忆。如果记忆没有 authority metadata，历史上下文就可能变成一种隐性权限。agent 不是因为当前任务被明确授权才行动，而是因为过去某段对话、某条笔记或某个残留上下文看起来可信。对人来说，这可能只是“参考背景”；对系统来说，它却可能被模型解释成行动依据。

第二类缺口来自授权生命周期。身份卡可能仍然有效，但具体授权已经过期。团队换了，项目结束了，外部系统权限收回了，可 agent 的身份记录还在。最后系统里留下的不是清晰身份，而是一批“看起来合法”的僵尸身份。

第三类缺口来自工具调用。如果每一次工具调用没有逐步审计，责任只能追到创建者或 agent 名称，而追不到具体行为链。系统知道“某个 agent 做了这件事”，却不知道它为什么这样做、基于什么上下文、经过了哪一次授权、影响了哪个外部系统。

这也是 agent 风险不同于普通自动化脚本的地方。单独看，一个工具调用可能是合法的；放到错误的记忆来源、错误的用户意图或过期授权里，它就可能变成不可接受的行为。

更实用的设计方向，不是把身份卡做得更漂亮，而是把身份、授权、记忆元数据、工具调用日志和外部效果绑定起来。

身份卡应该只承担第一层职责：声明这个 agent 是谁、由谁创建、服务于什么场景。

授权系统承担第二层职责：说明它此刻能做什么，不能做什么，授权从哪里来，什么时候失效。

记忆元数据承担第三层职责：说明它依据什么上下文做判断，这些上下文来自哪里，可信级别是什么，是否仍然有效。

审计轨迹承担第四层职责：说明它实际做了什么，调用了哪些工具，产生了哪些外部效果，是否可以回放和撤销。

这几层缺一层，企业看到的都只是身份外壳，而不是可治理的 agent。

agent 治理最容易走偏的地方，是把责任归因停在 agent 名称上。

“某某 agent 调用了某个工具”并不是一条足够好的审计记录。更有价值的记录应该能复原一次行动：

只有当这些信息可以被回放，agent 的身份才从静态字段变成可追责系统。

agent 身份卡有价值，但它不是安全答案。它更像是治理系统的入口：让 agent 能被命名、被归属、被纳入权限体系。

真正决定企业能不能放心使用 agent 的，是运行时行为能不能被验证。每一次读取记忆、延续会话、调用工具、影响外部系统，都应该留下清晰的授权链和行为证据。

所以，agent 身份治理的核心不是发卡，而是让身份成为一组可验证、可回放、可撤销的行为证据。

龙虾升职记