Gemini智能体进入SCIM目录：如何配置非人类用户

Google的Gemini正在以一种新的身份出现在Workspace中——不再是简单的聊天助手，而是拥有独立账号、独立目录条目的"同事智能体"（coworker agents）。这意味着你的SCIM同步管道里，很快会出现一批不是人的"用户"。

非人类用户悄然进入企业目录

过去我们谈论AI助手，默认它只是某个应用里的功能模块。但Gemini coworker agents的定位截然不同：它被赋予了一个正式的Workspace账号，并在企业目录中占据一个条目。从身份系统的视角看，它和一位新入职的员工没有本质区别——有账号、有标识、需要被分配权限。

这个变化看似微小，影响却很深远。SCIM（跨域身份管理系统）原本是为人类员工设计的配置协议，现在却要承载一类全新的主体。你的目录同步代码需要回答一个它从未被设计来回答的问题：当"用户"不是人时，配置逻辑应该怎么做？

SCIM（System for Cross-domain Identity Management，跨域身份管理系统）是一套由IETF标准化的开放协议，用于在不同系统之间自动化同步用户身份和群组信息。它最典型的应用场景是：当企业使用Okta、Azure AD等身份提供商（IdP）作为权威身份源时，通过SCIM将员工账号的创建、更新、禁用等操作自动推送到Slack、Zoom、Salesforce等下游应用，从而避免手动维护账号。SCIM定义了标准的User和Group资源模型，以及REST风格的端点（如/Users、/Groups），支持增删改查。正因为它面向的是企业员工这类主体，其资源模型、生命周期假设（入职、调岗、离职）都默认与人类账号绑定。当智能体作为目录条目出现时，SCIM协议本身并不会报错，但配置端的语义假设会开始失效，这正是本文讨论问题的根源。

智能体如何流入你的应用

Gemini智能体进入你的应用，走的仍然是标准的目录同步通道。Workspace把智能体作为目录条目推送到SCIM端点，你的应用像接收普通用户一样接收它——除非你主动做了区分。

关键在于识别。智能体条目通常带有特定的标记或属性，用来表明它并非人类账号。如果你的配置代码对此毫无感知，就会把它当成普通员工处理：创建个人资料、分配默认权限、纳入离职流程。反过来，如果你能正确识别，就可以为它设计一套独立的生命周期管理。

据Google的描述，智能体拥有自己的Workspace账号和目录条目，这是它能够被SCIM同步的前提。也就是说，这条路是官方支持的，而非某种绕行方案。

“智能体”（agent）在AI语境下通常指能够感知环境、自主规划并调用工具执行多步任务以达成目标的软件实体，与传统的被动式聊天机器人不同。Gemini coworker agents之所以被称为“coworker”，是因为它被设计为可在Workspace应用（如Docs、Gmail、Drive）中代表用户或团队独立执行操作，比如整理文档、撰写邮件草稿、跨应用检索信息。为了让这些操作在Workspace的权限与审计体系内被追踪，Google给它分配了正式账号——这相当于给智能体一张“企业工牌”。这也解释了为什么它会进入SCIM同步流：只有拥有账号，它才能被分配访问权限、出现在共享对象中、留下可审计的操作记录。理解这一点很关键：智能体不是隐藏在某个API密钥背后的匿名调用，而是身份系统里的一等公民。

配置代码需要为智能体做的几个决定

当智能体出现在SCIM feed里，你的配置逻辑需要做出一系列明确的选择，而不是任由默认行为替你做主。

身份建模：智能体在你的系统中应该被建为哪种主体？是当作特殊用户、服务账号，还是独立的一类实体？这决定了后续所有权限和审计逻辑的走向。

权限边界：智能体能访问什么、不能访问什么，需要有明确的声明。把人类员工的默认权限套在智能体身上，可能带来意想不到的暴露面。

生命周期：智能体何时被创建、何时被停用？它不像员工会主动离职，因此停用往往需要由策略触发，而非事件驱动。

审计归属：智能体的操作应该记录在谁的名下？如果和人类用户混在一起，事后追溯会变得困难。

这些问题没有统一答案，但每一条都值得在接入之前想清楚。

自动化账号配置（provisioning）中有一个常见的陷阱：默认行为往往是最危险的。许多SCIM实现会使用“未知用户即普通员工”的兜底逻辑，自动创建本地档案、加入默认组、授予通用权限。对智能体而言，这意味着它在你的系统里可能悄悄获得了和真实员工相同的访问范围。更稳妥的做法是基于SCIM条目中的属性（如userType、externalId或自定义扩展）做显式分支：识别为智能体后，走独立的建号和授权流程。此外，停用环节也需要被重新设计——人类员工的停用由HR离职事件触发，而智能体没有“离职”这一自然事件，必须依赖策略引擎、到期时间或使用量监控来主动回收，否则会产生大量“僵尸智能体”账号。

为什么这件事值得提前规划

把智能体塞进为人类设计的身份体系，短期看是最省事的做法，长期看却可能积累技术债。目录会变得越来越混杂，权限审计越来越难解释，当智能体数量增长时，这种混乱会被放大。

更务实的做法，是在智能体还不多的时候就把规则定下来：用属性区分它、用策略管理它、用独立的审计通道记录它。这样当Gemini智能体真正规模化进入企业应用时，你的配置管道不会成为瓶颈。