构建企业级Slack Agent的UX、安全、扩展经验

设计出色的用户体验

一个好的Slack机器人不仅回答命令，还需要采取行动并自然地沟通。我们重点关注几个用户体验方面，确保agent完全融入Slack。

沟通agent的状态

在处理Deep Search这样的复杂查询时，响应时间可能会有显著差异。保持用户的知情至关重要。我们实现了一个多阶段的沟通流程：

确认和启动：当用户@mention agent时，我们立即告诉他们搜索正在运行。我们使用emoji，比如👀，以一种在Slack中感觉原生的方式来传达状态，增强了agent的活跃感和响应性。

更新和升级：如果搜索耗时超过预期（超过几分钟），我们会主动发送更新，引导用户访问外部链接以实时查看。

处理冗长的AI响应和后续跟进

AI驱动搜索时代意味着响应可能很大且高度详细。我们发现提供一个快速、简洁的摘要至关重要。我们优先显示TL;DR摘要，同时为用户提供查看完整冗长响应的选项，通常使用Slack的Block Kit或线程等特性来提高可读性。

Agent还设计为管理对话上下文，允许在Slack线程内进行后续问题，即使平台API交互通常是无状态的，也能维持有状态的会话。

实现丰富的链接预览（Unfurling）

为了真正最小化上下文切换，我们使Sourcegraph链接在Slack中可直接操作。当用户粘贴Sourcegraph链接（文件、标准搜索或Deep Search）时，集成会自动"unfurl"它，显示丰富的预览，呈现相关上下文而无需点击。

链接unfurling的技术流程由Slack事件驱动：

Slack向Sourcegraph服务发送一个link_shared事件，包含URL。

集成解析每个URL以确定其内容类型：文件、搜索或deep search。

使用SHA256哈希生成唯一的实体ID，前缀为类型标识符（例如f-、s-或对话的readToken）。

服务返回包含丰富元数据的chat.unfurl响应，利用Slack的work objects API。

当用户点击这些unfurled链接时，Slack触发一个entity_details_requested事件，在flexpane侧边栏中显示完整详情。

所有unfurl和flexpane视图都生成遥测事件，允许我们跟踪成功和错误状态以进行持续改进。

点击卡片也允许你在Slack的flexpane组件内查看整个Deep Search（DS）对话。

企业级安全和部署

对于大型组织，agent必须在默认情况下安全，并无缝集成到Slack Enterprise Grid等复杂环境中。

支持Slack Enterprise Grid

Enterprise Grid对大型企业至关重要，因为它支持一个应用对应多个Slack工作区的设置。我们的应用专门设计用于处理这种多工作区配置，确保可扩展性和集中管理。

身份和授权技巧

采用的一大障碍是要求用户在安装Slack应用后手动"登录到你的Sourcegraph账户"。我们通过实现一个关键的身份验证技巧消除了这种摩擦：

我们通过两个系统中的已验证电子邮件地址将Slack用户与其相应的Sourcegraph账户绑定。一旦管理员启用集成，任何拥有匹配的、已验证的Sourcegraph账户的用户都会自动获得集成的访问权限。这确保了agent的权限与个人用户的代码访问权限一致——这是数据授权的关键部分——而无需任何额外的登录步骤。

企业部署和健康检查

由于Sourcegraph是企业软件，我们采用"自己创建应用"工作流，引导网站管理员完成应用创建流程。这确保管理员控制该应用，并正确配置其Sourcegraph实例URL，这对安全的凭证存储和管理OAuth流至关重要。

为了在设置期间验证基本连接，我们利用Slack的事件URL测试ping。我们通过附加一个自定义的?retry=<random number>查询参数来强制Slack向我们的服务发送新的HTTP请求。对这个修改后ping的成功响应作为一个可靠的信号，表明"Slack确实可以联系我们的服务，集成设置得当"。

使用Redis进行速率限制扩展

可扩展性和可靠性需要一个强大的技术栈和对资源管理的有纪律方法。为了防止滥用并确保系统稳定性，我们使用Redis实现了一个复杂但快速的速率限制机制。

我们的规则集很直接：用户在一个小时间间隔内被限制为固定数量的请求。系统使用基于用户和团队ID的简单计数器来跟踪活动。当发出请求时，Redis检查当前计数。如果达到限制，新请求被阻止，用户被告知何时可以重试。如果用户未达到限制，计数器被递增，系统在周期结束后重置计数。

这个系统通过三个非协商的目标设计而成：

故障开路：如果Redis经历停机，系统会故障开路，意味着请求仍然会通过。基础设施错误不会中断核心Slack集成功能。

隔离限制：限制按用户和团队ID隔离。如果一个用户发送过多请求，不会影响任何其他用户或工作区的性能。

速度：我们依赖基本计数器而不是复杂、延迟高的算法来阻止搜索滥用。

系统使用我们的键值存储立即检查这些限制，在重搜索任务消耗大量资源之前停止它们。这种架构对于维护"always-on"服务和处理大型多工作区环境中的高并发至关重要。

感谢阅读。如果你觉得这很有趣，不妨阅读更多关于我们构建的另一个Slack Bot的内容。

特别感谢Justin Dorfman对这篇博文的贡献。

解锁你的组织。更快地交付。

使用Sourcegraph，企业级代码理解平台。