用 Slack 智能助手打通 IT 支持流程

本文由 ShipStation Global 的 Kenneth Salmon、Edward Boswell、Jack Armstrong、Robert Bahn 和 Nick Ciubotariu 共同撰写。

反复回答相同的 IT 问题、处理常规工单，会占用 IT 团队本可以投入其他工作的时间。为了把这些时间拿回来，ShipStation Global 工程团队基于 Amazon Bedrock AgentCore 构建了 Deckhand，一个在 Slack 中提供服务、由 AI 驱动的 IT help desk Agent。

ShipStation Global 是面向中小型发货企业的领先智能运输与物流平台。它秉持一个简单的理念：团队效率越高，就越能为客户提供更好的服务。Deckhand 将这一理念落实到了日常工作中。它从经过筛选整理的知识库中回答常规 IT 问题和公司相关问题，识别报错截图，并创建和更新 Jira Service Management 工单。

本文将介绍 ShipStation 如何设计 Deckhand 的架构。这套方案解决了频道中 97.5% 的提问，并获得了员工 96% 的正面反馈评价（图 1）。

图 1：三个月内的频道覆盖率与正面反馈

Deckhand 要解决的问题，每个 IT 团队都很熟悉：同样的问题不断被问起，报错信息在下班后被发出来，而解决问题所需的信息分散在不同团队。在 ShipStation Global，这些交流集中在一个繁忙的 help desk Slack 频道里：员工提问，IT 团队逐个 thread 回答。答案通常早就存在于某篇 Confluence 操作指南、公司内网页面，或者八个月前的某个 thread 中。难的是把它们找出来。

频道数据让问题的规模变得具体。在上线前的 12 个月里：

• 员工发布了超过 1,500 个 thread，而且数量还在持续增长。
• 员工分布在美国、英国、西班牙、波兰、澳大利亚和菲律宾，超过五分之一的问题出现在美国工作时间之外。
• 答案分散在多个地方：Confluence 文章、内网页面和 PDF、IT 团队维护的指南，以及频道自身的历史记录。
• 重复问题占用了大量时间，而这些问题本可以通过结构化的自助操作步骤解决。

“我们创建 Deckhand，是因为获取帮助应该像在 Slack 中问一个问题一样简单，而不应该让人费力理解工单表单，或者发出一封不知道会不会有人回应的邮件。我们认为，工单反映的是运营中的阻力，而不是生产力。Deckhand 能当场解决常见问题；解决不了时，只需点击一次，就能把对话转成一张包含完整上下文的工单。这改善了员工体验，也让我们的团队不必再无休止地重复那句话：‘请提交工单。’”

—— Chris Collins，ShipStation Global IT 高级总监

Deckhand 在 Slack 中的工作方式和其他同事一样：加入频道、阅读对话，并结合 Slack 个人资料中的上下文，就地回答 IT 问题。我们将它运行在 Amazon Bedrock AgentCore 上。这个平台支持使用任意框架或模型，大规模构建、连接和优化 Agent。Amazon Bedrock AgentCore 的 AgentCore runtime 功能在隔离的会话中托管 Agent，因此我们无需自行运行服务器或容器。

这套方案包含四个主要组件，如图 2 所示：

• Slack 服务：使用 FastAPI 和 Slack Bolt 构建的应用，托管在 AWS App Runner 上。它接收 Slack 事件，判断 bot 是否应该回复，并根据提问者的 Slack 个人资料构建用户上下文 payload，其中包括姓名、邮箱、时区和直属经理。
• Agent 服务：一个 Strands Agent，以容器形式部署在 Amazon Bedrock AgentCore runtime 上，使用 Amazon Bedrock 中的 Anthropic Claude 管理多轮工具调用循环。
• 工具与知识：一个 AWS Lambda 函数，通过 Amazon Bedrock AgentCore 的 AgentCore Gateway 功能暴露为 Model Context Protocol（MCP）工具，负责请求分类、创建和更新 Jira 工单，以及分析图片。一个 Amazon Bedrock knowledge base 为来自 Confluence、公司内网、Slack 和营销页面的内容建立索引，并将内容存储在 Amazon Simple Storage Service（Amazon S3）中。
• 运维与反馈：Amazon DynamoDB 存储反馈，AWS X-Ray 通过 OpenTelemetry 跟踪请求路径，各服务将日志写入 Amazon CloudWatch。

图 2：架构图展示了 Slack 事件如何进入 Slack 服务和 Amazon Bedrock AgentCore runtime，以及分别通向 Amazon Bedrock knowledge base、由 AgentCore Gateway 提供访问的 Lambda 工具、Jira Service Management 和 DynamoDB 反馈存储的路径。

当员工在 Deckhand 已加入的频道中发消息时，Slack 服务会汇总完整的 thread 历史记录和用户上下文，然后通过 AgentCore runtime API 调用 Agent。Agent 搜索知识库，并按需调用工具。找到答案后，它会返回最终回复（图 3）；如果没找到，它会提出澄清问题，或者询问是否需要创建工单（图 4）。

图 3：Deckhand 回复自助操作步骤

图 4：Deckhand 提议创建工单

本节将介绍 Deckhand 的实现过程，从前置条件到可运行的部署。

要实现这一方案，需要准备：

• 一个能够访问 Amazon Bedrock、AgentCore runtime 和 AgentCore Gateway 的 AWS 账户。
• 一个配置了事件订阅、signing secret，以及权限范围符合使用场景的 bot token 的 Slack 应用。
• 一个容器镜像仓库，例如 Amazon Elastic Container Registry（Amazon ECR）。
• 一个 Amazon S3 bucket 和一个 Amazon Bedrock knowledge base。
• 为各 runtime 和工具分别限定权限范围的 AWS Identity and Access Management（IAM）角色，以及用于存储第三方凭证的 AWS Secrets Manager 条目。

使用 Strands Agents 和 AgentCore 构建 Agent

这个 Agent 刻意保持轻量。使用开源 Strands Agents SDK 时，一个 Agent 由模型、一组工具和 system prompt 组成。SDK 管理推理循环，让模型选择工具、处理结果，并不断迭代，直到生成答案。Deckhand 的 Agent 服务只需几行 Python 就能实现。

from strands import Agent
from strands.models import BedrockModel
from strands.tools.mcp import MCPClient
from strands_tools import retrieve
from mcp.client.streamable_http import streamablehttp_client

model = BedrockModel(
    model_id=MODEL_ID,
    max_tokens=2048,
    temperature=0.3,
)

gateway = MCPClient(lambda: streamablehttp_client(url=GATEWAY_URL))

agent = Agent(
    model=model,
    tools=[gateway, retrieve],
    system_prompt=SYSTEM_PROMPT,
)

模型 ID 通过环境变量设置，因此无需修改应用代码就能切换模型。

工具通过两种方式集成到 Agent 中。Amazon Bedrock Knowledge Bases 检索是 Strands 的原生工具，只需一条 import 就能支持知识库搜索。其他功能，包括分类、工单管理、用户解析和图片分析，由注册在 AgentCore Gateway 上的 Lambda 函数处理。Gateway 将这些功能暴露为 MCP 工具，Lambda 则根据工具名称路由每次调用。这样分离之后，工具逻辑可以独立更新，Agent 也能从 Gateway 获取新工具，无需重新构建。

AgentCore runtime 以容器形式托管 Agent，省去了服务器和会话管理。Slack 服务针对每条消息同步调用 Agent，传入 thread 对话记录和用户上下文，再发布最终回复。由于每次请求都会携带上下文，包括员工个人资料，Agent 可以自动补全工单信息。

知识库设计与回答路由

Deckhand 从一个 Amazon Bedrock knowledge base 中获取答案，其核心数据源由 S3 提供存储支持：

• 从 Confluence 同步的文章。
• 从公司内网同步的内部页面、PDF 和活动信息。
• 从 Slack 中挖掘出的已解决支持 thread，下一节会详细介绍。

每份文档都包含标题、来源 URL、内容类型和活动日期等元数据。这使 Agent 能够筛选内容，例如回答用户关于即将举行的活动，或奥斯汀办公室每周午餐菜单的问题。

使用 Recursive Language Models（RLM）挖掘 Slack 历史记录

最有价值的数据源，是已解决支持 thread 的历史档案。在 Deckhand 出现之前，Slack 就是解决问题的地方：多年来，员工在这里描述问题，IT 团队一步步指导他们修复。这些历史记录是一套自然积累的知识库，而且经过了最合适的审核者验证：问题得到解决的那个人。但它也充满噪声：原始导出数据混杂着闲聊、自动告警，以及实际上从未解决的 thread。如果把未经验证的修复方法或混乱的摘要编入索引，知识库就会以同样的置信度呈现错误答案和正确答案，因此提取过程必须足够精确。

挖掘过程采用三阶段流水线（图 5）：

1. 脚本通过 Slack API 导出频道的完整历史记录，获取每个 thread 的全部回复，并写入结构化导出文件，其中包含 thread 标记、时间戳和回复数量。
2. DSPy 的 Recursive Language Model（RLM）使用 Amazon Bedrock 上的 Claude，将导出数据视为沙箱化 Python read-eval-print loop（REPL）中可导航的记忆空间，而不是塞进单个 prompt。它迭代处理数据，将每个 thread 分类为已解决、未解决或已升级处理，并过滤掉公告和非提问内容。严格的判定标准保证了质量：只有在 thread 本身能看到完整、可执行的修复方法时，才将其认定为已解决。
3. 对于每个已解决的 thread，RLM 会编排递归的子 LLM（large language model）调用，提取结构化字段，并使用 Pydantic 模型逐一验证。这些字段包括问题摘要、原始问题和解决方案，还记录修复是否可以自助完成或需要提交工单、自助操作步骤、涉及的应用和系统、报错信息，以及标签。当子 LLM 调用返回的内容不符合 schema 时，RLM 基于代码的循环会在解释器中捕获验证错误并重试。结果被写成按问题组织的 Markdown 文档，随后由流水线上传到 Amazon S3，供知识库建立索引。

图 5：Slack 对话的导出、分类与提取工作流

我们选择 RLM，是因为它能将整个 Slack 历史记录保存在持久化的沙箱变量空间中，支持围绕导出数据进行迭代推理，同时保持一致的输出结构。因此，当员工遇到同事曾经解决过的问题时，Deckhand 能提供经过验证的解决方案，而且通常会以可执行的编号步骤呈现。

知道什么时候不该回答

共享频道中的 AI bot，往往先在社交层面出问题，才在技术层面出问题。Deckhand 最精细的逻辑，是判断什么时候应该保持安静：

• 对于每条消息，Agent 首先判断它是否属于公告、社交消息，或者人与人之间的对话。如果是，就输出 SKIP，Slack 服务会抑制这次回复。
• 在 thread 中，它只回复最初的提问者。
• 如果上一条回复来自另一位提供帮助的人，它就保持沉默，因为已经有人接手。
• 如果回复以 @某个人开头，这条消息就不是发给 bot 的。

每条回答都附带反馈按钮。点赞会直接记录，点踩则会弹出一个简短的“哪里出了问题”填写字段。评价会连同原始问题和 bot 的回复一起存入 DynamoDB。

负面反馈是一组有价值的数据，可以用来改进 system prompt 和 Agent 行为，并修正知识库中的错误信息。

安全与验证

prompt 规则能够改善行为，但不能替代访问控制。真正的约束由代码和基础设施执行：

• 创建工单需要明确确认。 当 Deckhand 提议创建工单时，Slack 服务会添加一个 Create Ticket 按钮。点击按钮后，确认信息会传给 Agent。更新工单时，只接受符合 helpdesk 项目格式的有效 key，并拒绝空评论。
• 分类结果通过验证后才能执行操作。 请求分类通过一次独立的 Amazon Bedrock Converse API 调用完成，返回结构化工单字段。在任何内容进入 Jira 之前，先使用 Pydantic 验证。
• 图片工具只能从 Slack 的文件托管服务下载文件。 它使用 bot token 进行身份验证，每次请求最多处理五张图片，每张不超过 5 MB，并通过 Converse API 将文件发送给视觉模型。
• 凭证不写进代码。 Slack token、signing secret 和 Jira 凭证存储在 AWS Secrets Manager 中，每个服务和工具都使用各自限定权限范围的 IAM 角色运行。
• prompt 规定了行为防护规则。 不得索要密码或 multi-factor authentication（MFA）验证码，不得在工单评论中写入凭证，也不得暴露用于填写工单字段的个人资料元数据。

Deckhand 于 2026 年 4 月上线。起初每天处理约 30 条消息，到初夏时最高达到每天 100 条。在最初三个月里，它处理了 1,935 条消息，启动了 1,221 次 Agent 对话，并创建了 409 张 Jira 工单。它回复了 97.5% 的消息。三分之一的问题出现在下班后，当时 IT 团队无人值班，而 Deckhand 回答了其中的 94%。原本要等到第二天早上才能获得帮助的人，当晚就得到了答案。

随着团队持续改进，反馈也在变好。团队针对员工反馈的问题修改 system prompt 和知识库后，正面评价比例从 4 月的 82% 提升到了 6 月的 96%。

最明显的收益，是减少了工单。一次 Agent 对话对应一个原本可能变成 Jira 工单的问题。在 1,221 次对话中，只有 409 次最终转成工单，其余 812 次都在聊天中解决了。从提交工单，到处理并关闭工单，大约需要 30 分钟。这 812 次对话在三个月里累计节省了约 406 小时，折算到一年约为 1,600 小时。员工把这些时间留给了自己的工作，IT 团队也不必把时间花在工单受理上。

Deckhand 分担了重复的 IT 问题，把时间还给员工和 IT 团队。它之所以能做到，是因为技术栈中的每个部分都只负责一件事，并以托管服务运行：AgentCore runtime 托管 Agent，AgentCore Gateway 将 Lambda 函数转换成 Agent 可以调用的 MCP 工具，Amazon Bedrock Knowledge Bases 负责检索。团队无需搭建服务器或维护编排代码，就交付了这套方案。

要构建类似方案，可以从一个维护良好的知识源和一项定义清晰的操作开始。开发 Agent 时，可参考 Amazon Bedrock AgentCore 文档和 Strands Agents SDK；连接内容源时，可参考 Amazon Bedrock Knowledge Bases 文档。

如果希望讨论适合贵组织的 agentic AI 使用场景，请联系您的 AWS 客户团队。