从 Slack 线程中运行支持查询和 Bug 检查
我构建了 Doozy，因为我所在公司（Spur）的支持团队人手不足，经常需要等待工程团队为客户运行查询，或确认某个问题是否为 Bug。任务：作者构建了 Doozy，一个集成 Slack 的 AI 智能体，旨在解决支持团队等待工程团队运行数据库查询或验证 Bug 的瓶颈。工作流程包括在 Slack 线程中提及智能体并分配任务；它在隔离的 E2B 沙箱中针对 Postgres、Stripe 和 GitHub 等系统执行操作。凭证通过外部网关按请求注入，破坏性工具默认禁用，除非由所有者明确启用。虽然未详细说明具体审批步骤，但通过初始任务分配和线程中结果回顾体现了人工参与。；工具：custom-built or unnamed agent。人工角色：源证据不可用；原始帖子未说明人员在最终工作流中如何参与。；局限：系统依赖特定基础设施（E2B 沙箱、外部凭证网关）和集成（Slack、Postgres、Stripe 等）。安全性依赖于网关架构防止密钥泄露，但提示注入仍可能导致工具滥用。来源未指定延迟、并发限制或按工作区定价模型的确切成本。破坏性操作的人工审批工作流被提及为一项功能（所有者启用），但未作为每个操作的强制步骤。。
工具
custom-built or unnamed agent
Agent Work Atlas 发布日期:
概述
我构建了 Doozy，因为我所在公司（Spur）的支持团队人手不足，经常需要等待工程团队为客户运行查询，或确认某个问题是否为 Bug。
工作流程
作者构建了 Doozy，一个集成 Slack 的 AI 智能体，旨在解决支持团队等待工程团队运行数据库查询或验证 Bug 的瓶颈。工作流程包括在 Slack 线程中提及智能体并分配任务；它在隔离的 E2B 沙箱中针对 Postgres、Stripe 和 GitHub 等系统执行操作。凭证通过外部网关按请求注入，破坏性工具默认禁用，除非由所有者明确启用。虽然未详细说明具体审批步骤，但通过初始任务分配和线程中结果回顾体现了人工参与。
原文报告的结果
来源指出 Spur 公司有 13 人每天使用该工具，它已成为团队的关键部分，主要由支持和成功团队而非工程师使用。然而，未提供关于节省时间、错误减少或成本效率的量化指标。作者提到第一个版本“很粗糙”但功能正常，重建版本为多租户。可衡量的验收检查是跟踪实施后与简单数据查询相关的工程工单减少量。
人工角色
源证据不可用；原始帖子未说明人员在最终工作流中如何参与。
局限
系统依赖特定基础设施（E2B 沙箱、外部凭证网关）和集成（Slack、Postgres、Stripe 等）。安全性依赖于网关架构防止密钥泄露，但提示注入仍可能导致工具滥用。来源未指定延迟、并发限制或按工作区定价模型的确切成本。破坏性操作的人工审批工作流被提及为一项功能（所有者启用），但未作为每个操作的强制步骤。
试一试
作为 DevOps 工程师，为 [公司名称] 实施基于 Slack 的 AI 支持智能体。 1. **背景**：支持团队等待工程团队在 [数据库名称] 上运行 SQL 查询或检查 [支付提供商] 状态。 2. **设置**：配置一个在 Slack 线程中被 @提及 时触发的智能体。 3. **安全**：确保智能体在隔离沙箱（如 E2B）中运行，不存储凭证。实施一个按请求注入凭证的网关。 4. **控制**：将所有破坏性工具默认设为“拒绝”。需要工作区所有者手动启用。 5. **审计**：在 Slack 线程中记录每个外部操作的回执，并维护仅追加的审计日志。 6. **试运行**：为 [特定客户 ID] 执行一个示例查询并发布结果。 7. **确认**：在启用更广泛访问权限之前，等待人工审查示例输出。 交付物：智能体配置文件、已启用工具列表和示例审计日志条目。如果缺少输入，请询问数据库架构和 Slack 工作区 ID。
来源报告未经独立核验。发布日期为本站案例发布日期，并非原始文章日期。