OMI Slack 插件 Token 排障指南修复消息以 Bot 身份而非用户身份发布的问题【免费下载链接】FriendAI that sees your screen, listens to your conversations and tells you what to do项目地址: https://gitcode.com/GitHub_Trending/fr/Friend在 plugins/omi-slack-app 这一 OMI 语音 Slack 集成插件中用户通过语音指令即可把消息发送到指定 Slack 频道而消息以谁的账号身份出现在频道里直接决定了产品的使用体验。本文聚焦该插件在 Railway 部署环境下最常见的故障——消息以 Bot 身份而非用户身份发布系统梳理其根因、日志判定方法、应用配置修复步骤与验证手段并结合仓库源码slack_client.py 与 main.py还原底层调用逻辑帮助开发者一次定位、彻底修复。问题现象本地正常、线上变脸插件在本地开发环境运行时发送的消息会以登录用户的身份出现在 Slack 频道中而部署到 Railway 之后同样一条消息却以Bot 身份显示为应用机器人发布。这并非业务逻辑差异而是 OAuth Token 类型在本地与云端环境中发生了不一致。从源码角度看消息最终由 slack_client.py 的send_message发出它在发送前会打印当前使用的 Token 类型并在响应中检查bot_id字段来判断消息实际发布身份——这两处日志正是我们排查的第一手依据。三大根因1.as_user参数已废弃且会产生误导早期实现中调用chat.postMessage时会显式传入as_userTrue试图让消息以用户身份发布。但该参数已被 Slack API 标记为废弃deprecated语义含糊且在不同 Token 类型下表现不一致。修复方案很直接直接移除该参数。当前源码中的send_message只传入channel与text两个参数见 slack_client.py# Note: as_user parameter is deprecated and not needed with user tokens # User tokens automatically post messages as the authenticated user result client.chat_postMessage( channelchannel_id, texttext )只要携带的是用户 TokenSlack 会自动以该用户身份发布消息无需任何额外参数。2. Bot Token 与 User Token 语义不同Slack 存在两类核心 Token发布身份截然不同Token 类型前缀发布身份是否期望User Tokenxoxp-*以认证用户身份发布✅Bot Tokenxoxb-*以 Bot 应用身份发布❌两者的来源也不同用户 Token 通过OAuth 流程中authed_user.access_token返回Bot Token 则来自响应顶层access_token。仓库中的exchange_code_for_tokenslack_client.py正是围绕这两者的取舍实现的# Use the USER token (authed_user) instead of bot token authed_user data.get(authed_user, {}) user_token authed_user.get(access_token) if not user_token: # Fallback to bot token if user token not available user_token data.get(access_token) print(⚠️ WARNING: Using BOT token (user token not available), flushTrue) ... else: print(✅ Using USER token (messages will appear as user), flushTrue)从源码结构可以推断当 Slack 授权响应中没有返回authed_user.access_token例如应用未配置用户级权限时代码会降级使用 Bot Token此时消息必然以 Bot 身份发布——这正是本地正常、线上变 Bot的典型触发点。3. Slack App 配置让 Bot 抢占了优先权如果应用在 Slack 后台的Bot Token Scopes中配置了chat:write等写权限Slack 在 OAuth 时可能倾向于下发 Bot Token即使用户侧也申请了相同权限。因此文档明确建议Bot Token Scopes 应保持为空或最小化必要时直接清空避免干扰用户 Token 的发放。如何在日志中判定 Token 类型修复并重新部署后在 Railway 日志中观察认证与发消息过程的输出即可判断身份是否正确。✅ 正常用户 Token✅ Using USER token (messages will appear as user) ✅ User token starts with: xoxp-... Sending with USER token: xoxp-... ✅ Message posted as USER❌ 异常Bot Token⚠️ WARNING: Using BOT token (user token not available) ⚠️ This means messages will post as BOT, not as USER Sending with BOT token: xoxb-... ⚠️ Message posted as BOT (bot_id: ...)这两组日志分别对应 slack_client.py认证阶段与 slack_client.py发送阶段。发送阶段还会根据响应中的bot_id字段给出最终判定token_type USER if access_token and access_token.startswith(xoxp-) else BOT if access_token and access_token.startswith(xoxb-) else UNKNOWN print(f Sending with {token_type} token, flushTrue) ... if bot_id: print(f⚠️ Message posted as BOT (bot_id: {bot_id}), flushTrue) else: print(f✅ Message posted as USER, flushTrue)四步修复方案Step 1让已认证用户重新认证修复只对修复之后完成的 OAuth 生效修复前已认证的用户仍持有旧的BotToken。需要引导用户打开 Railway 应用首页/点击Logout Clear Data清空本地存储中的旧 Token重新点击Connect Slack Workspace完成一次全新认证。该流程在 main.py 的/logout端点中会删除users与sessions中对应记录确保旧凭据不再被复用用户数据持久化逻辑见 simple_storage.py。Step 2核对 Slack App 的 OAuth 与权限配置在 Slack 应用管理后台api.slack.com/apps中检查OAuth Permissions页面User Token Scopes应包含channels:read查看公开频道chat:write发送消息groups:read查看私密频道users:read查看用户信息Bot Token Scopes应为空或尽量精简若 Bot Scopes 包含chat:writeSlack 可能优先下发 Bot Token建议直接清空 Bot Scopes。可同时核对App ManifestSettings App Manifest中的 YAML 配置确保与界面一致oauth_config: scopes: user: - channels:read - chat:write - groups:read - users:read # bot: [] # Leave empty or remove仓库中实际请求的用户级 Scope 更完整见 slack_client.pyuser_scopes channels:read,channels:history,chat:write,groups:read,users:read,search:read其中channels:history用于读取频道消息历史、search:read用于搜索消息对应get_channel_history与search_messages两个方法。注意权限以 Slack 应用后台实际配置为准Manifest 只是另一种等价配置方式若后台 Scope 不全OAuth 授权 URL 即使写入了 Scope 也可能被 Slack 忽略。Step 3核对环境变量确认 Railway 环境变量与本地.env保持一致指向同一个 Slack 应用SLACK_CLIENT_IDSLACK_CLIENT_SECRETOAUTH_REDIRECT_URL必须与 Slack 后台 Redirect URL 完全一致例如https://your-app.up.railway.app/auth/callback这两个凭证在 slack_client.py 的构造函数中读取并用于构建授权 URL 与换取 Token。若云端与本地指向不同的 Slack 应用Token 类型与权限自然不一致。Step 4使用测试界面验证应用内置了带?devtrue开关的测试界面可在不依赖 OMI 设备的情况下完整走一遍认证与发消息流程https://your-railway-app.railway.app/test?devtrue该接口实现在 main.py支持输入任意uid、发起 Slack 认证、录入一条语音指令并观察实时日志。结合日志中 Token 前缀xoxp-/xoxb-与最终发布身份即可确认修复是否生效。Token 前缀速查表前缀类型发布身份xoxp-*User Token以用户身份发布 ✅xoxb-*Bot Token以 Bot 身份发布 ❌xoxa-*App-level Token应用级令牌非发布消息用xoxr-*Refresh Token刷新令牌在日志中只需一眼识别前缀即可判断消息将以何种身份出现。从源码理解完整调用链结合仓库代码一次正常的用户身份发消息完整链路如下用户访问/auth?uiduser_idmain.py 生成带 CSRF 防护的state并调用get_authorization_url构建含user_scope的授权 URLSlack 授权后回调/auth/callbackmain.py 调用exchange_code_for_token换取 Token优先取authed_user.access_token拿到用户 Token 后list_channels拉取频道列表并写入 simple_storage.py 持久化存储用户对 OMI 设备说出指令后/webhook收到实时转写分段由 message_detector.py 的ai_extract_message_and_channel解析目标频道与消息内容最终send_message携带用户 Token调用chat_postMessage消息以用户身份发布。任何一个环节拿到的不是用户 Token最终都会表现为消息以 Bot 身份发布。排查时建议按授权响应 → 存储 Token → 发送日志三段对照即可快速锁定是 OAuth 配置问题还是存量数据问题。小结消息以 Bot 身份发布并非偶发问题而是 Slack OAuth 权限模型下 Token 类型错配的必然结果。核心修复动作只有三件事移除废弃的as_user参数、确保应用只配置 User Token ScopesBot Scopes 留空、让已认证用户重新完成一次 OAuth。借助源码中的日志埋点与?devtrue测试界面任何部署环境都能在数分钟内完成验证。【免费下载链接】FriendAI that sees your screen, listens to your conversations and tells you what to do项目地址: https://gitcode.com/GitHub_Trending/fr/Friend创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考