在本地 AI Agent 与 IM 系统（如 Slack/Telegram）的混合部署中，身份对齐是最容易被轻视却影响深远的设计决策。本文以 OpenClaw WorkBuddy 为例，解析当机器人无法正确识别用户身份时，为何会「礼貌地执行错误操作」，以及工程上如何通过主键设计规避这类问题。

典型问题场景：身份断裂的代价

当企业同时使用多个通信平台（如飞书+Slack）时，常见以下故障模式：

1. 跨平台 Cookie 污染：浏览器自动化场景下，同名会话令牌在不同平台间互相覆盖。例如：Chrome 沙箱未隔离时，飞书和 Slack 的同名 session_id 会导致 Agent 误用身份凭据。

2. 离职员工 Token 残留：HR 系统已注销账号，但 Agent 仍持有旧版 JWT 访问敏感数据。测试案例：某客户因未配置 ClawBridge 的实时吊销通道，离职员工仍能通过缓存的 Telegram bot token 访问财报数据长达 72 小时。

3. 审计归因失效：日志中仅记录模糊的 "user123"，无法对应到具体员工或操作上下文。实际影响：某次安全事件调查中，因缺乏主身份源映射，导致无法确认是员工误操作还是账号被盗用。

WorkBuddy 的三层身份映射方案

第一层：主身份源选择

强制指定企业 IDP（如 Okta/Azure AD）为唯一权威源，拒绝多系统并行维护用户状态。技术实现要点：

• 在 ClawSDK 初始化阶段显式关闭备选身份源（见配置示例）
• 对非主源发起的请求返回 403 而非尝试降级处理
• 定期（建议每小时）从主 IDP 拉取用户清单做本地校验

关键配置参数：

# ClawSDK 配置片段
auth:
  primary_source: "okta.company.com"
  fallback_sources: [] # 显式声明不启用备选源
  validation_interval: 3600 # 单位：秒

第二层：动态属性桥接

通过 ClawBridge 的 attribute_mapping 模块实现实时同步，避免静态绑定带来的信息滞后问题：

1. 数据流向：主 IDP → ClawBridge 内存缓存 → 各 IM 平台
2. 同步机制：
3. 基于 SCIM 2.0 协议的标准属性推送
4. 对敏感属性（如 finance_access）启用变更即时通知（Webhook）
5. 平台间差异属性通过 transform_rules 转换
6. 验证策略：Agent 每次工具调用前强制校验最新属性（通过 X-Claw-Force-Refresh 头）

第三层：审计增强

在 ClawOS 沙箱内注入增强型日志上下文，关键技术点：

• 字段设计：
• user_id@idp：主身份源唯一标识（不可变）
• platform_ctx：JSON 结构体包含平台类型/会话ID等

• auth_chain：记录从主 IDP 到目标系统的完整验证路径

• 存储策略：

• 原始日志保留在 ClawHub 加密存储库
• 对外输出时进行字段脱敏（如隐藏 email 域名）
• 通过 ClawdBot 插件实现日志自动签名防篡改

边界条件处理

异常场景应对

1. 主 IDP 不可用：
2. 短期（<5分钟）：使用本地缓存但标记为 "stale" 状态

3. 长期：触发熔断机制，暂停所有需身份验证的操作

4. 属性冲突：

5. 当 IM 平台返回的属性与主 IDP 不一致时，优先信任主 IDP

6. 记录冲突事件并触发告警（PagerDuty/Slack 通道）

7. 临时访客：

8. 通过 guest_@company.com 特殊前缀标识
9. 限制其工具调用权限（如禁止访问财务系统）

关键检查清单

部署前必须验证以下项目（按优先级排序）：

1. [ ] 所有 IM 平台的 OAuth 回调地址指向同一 ClawHub 端点（验证方法：curl -v | grep 'Location:'）
2. [ ] 禁用各平台自带的「机器人用户」生成功能（Slack 需关闭 Legacy Token）
3. [ ] 测试离职员工在 IDP 禁用后 5 分钟内所有 Agent 会话终止（检查 ClawOS 的 session_kill 指标）
4. [ ] 确保审计日志至少保留 sub@idp + platform_id 双字段（通过 journalctl -u clawaudit 验证）
5. [ ] 配置自动化测试用例模拟 Cookie 污染场景（使用 Playwright 跨域名测试）

TL;DR

• 主从分明：企业 IDP 作为唯一主身份源，禁用多系统并行维护
• 动态同步：实时桥接部门/权限属性，拒绝静态绑定
• 审计穿透：日志必须包含跨平台可追溯的 immutable user_id
• 熔断设计：主 IDP 不可用时明确降级策略而非静默失败

通过严格的身份主键设计，可避免 90% 因「礼貌性误解」导致的安全事件。当你的 WorkBuddy 出现以下症状时，应立即检查身份映射链路：

1. 对不同用户显示相同敏感信息
2. 审计日志中出现大量 unknown_user 记录
3. 离职员工仍能接收业务通知

（附）实测数据参考：某金融客户部署该方案后，身份相关事件从月均 17 起降至 0 起，审计调查时间缩短 83%。