跳到正文
AWS Machine Learning Blog· Kenneth Salmon·· 4 小时前AI 评分51

ShipStation Global 如何基于 Amazon Bedrock AgentCore 打造 AI IT 帮助台 Deckhand

How ShipStation Global built an AI IT help desk on Amazon Bedrock AgentCore

AI 导读

ShipStation Global 工程团队在 Amazon Bedrock AgentCore 上构建了运行于 Slack 的 AI IT 帮助台 Agent Deckhand，上线前三个月回复 97.5% 的频道消息，正反馈率从 4 月的 82% 升至 6 月的 96%。

正文 · AI 翻译

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

反复回答相同的 IT 问题、处理常规工单，消耗了 IT 团队本可用于其他工作的时间。为了收回这些时间，ShipStation Global 工程团队基于 Amazon Bedrock AgentCore 构建了 Deckhand，一个面向 Slack 的 AI 驱动 IT 服务台智能体。

ShipStation Global 是面向中小型发货方的领先智能货运与物流平台，它秉持一个简单的信念：团队越高效，为客户提供的服务就越好。Deckhand 正是这一信念的实践。它可以从精选的知识库中回答常见的 IT 和公司问题，读取错误消息截图，并创建和更新 Jira Service Management 工单。

在本文中，我们讨论了 ShipStation 如何构建 Deckhand 的架构，最终解决了 97.5% 的频道内查询，同时获得了员工 96% 的正面反馈评分（图 1）。

Chart showing Deckhand reached 97.5% channel coverage and a 96% positive feedback rating over three months

图 1：3 个月的频道覆盖率和正面反馈

业务挑战

Deckhand 解决的问题是每个 IT 团队都熟悉的：相同的问题被反复提出，错误消息在下班后发布，信息需要从不同团队收集。在 ShipStation Global，这些对话都发生在一个繁忙的服务台 Slack 频道中，员工提问，IT 逐一回复。答案通常早已存在于某篇 Confluence 操作指南、公司内网页面，或者八个月前的某个对话线程中。找到它们才是难点。

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

  • 员工发布了超过 1,500 个对话线程，且数量持续增长。
  • 由于员工分布在美国、英国、西班牙、波兰、澳大利亚和菲律宾，超过五分之一的问题在美国工作时间之外提出。
  • 答案分散在不同的地方：Confluence 文章、内网页面和 PDF、IT 维护的指南，以及频道自身的历史记录。
  • 重复的问题消耗了本可以由结构化自助流程处理的时间。

“我们创建 Deckhand 是因为获得帮助应该像在 Slack 中提问一样简单，而不是去琢磨一张工单表单，或把邮件发进虚空。我们相信工单是运营摩擦的体现，而非生产力的体现。Deckhand 能当场解决常见问题；当它无法解决时，一键就能将对话转换为包含完整上下文的工单，从而改善员工体验，让我们的团队不再无休止地重复这句话：‘请提交工单。’”

— ShipStation Global IT 高级总监 Chris Collins

解决方案概览

Deckhand 在 Slack 中的运作方式就像任何一位队友一样——加入频道、阅读对话，并从 Slack 个人资料中获取上下文，就地回答 IT 问题。我们将其运行在 Amazon Bedrock AgentCore 上，这是一个可以使用任意框架或模型来大规模构建、连接和优化智能体的平台。AgentCore runtime 是 Amazon Bedrock AgentCore 的一项功能，它将智能体托管在隔离的会话中，因此我们无需运行任何服务器或容器。

该解决方案包含四个主要组件，如图 2 所示：

  1. Slack 服务： 一个托管在 AWS App Runner 上的 FastAPI 和 Slack Bolt 应用程序。它接收 Slack 事件，决定机器人是否应响应，并根据请求者的 Slack 个人资料（包括姓名、电子邮件、时区和经理）构建用户上下文有效负载。
  2. 智能体服务： 一个 Strands 智能体，以容器形式部署在 Amazon Bedrock AgentCore runtime 上，使用 Amazon Bedrock 中的 Anthropic Claude 管理多轮工具智能体循环。
  3. 工具与知识： 一个单一的 AWS Lambda 函数，通过 AgentCore Gateway（Amazon Bedrock AgentCore 的一项功能）以 Model Context Protocol (MCP) 工具的形式提供，可对请求进行分类、创建和更新 Jira 工单，以及分析图像。一个 Amazon Bedrock 知识库 对来自 Confluence、公司内网、Slack 和营销页面的内容进行索引，并将其存储在 Amazon Simple Storage Service (Amazon S3) 中。
  4. 运营与反馈。Amazon DynamoDB 存储反馈，AWS X-Ray 使用 OpenTelemetry 跟踪请求路径，各服务将日志记录到 Amazon CloudWatch。

Architecture diagram of Deckhand on Amazon Bedrock AgentCore showing the Slack service, agent runtime, knowledge base, Gateway-backed Lambda tools, Jira Service Management, and DynamoDB feedback

图 2：架构图，展示 Slack 事件进入 Slack 服务和 Amazon Bedrock AgentCore runtime，并有单独的路径分别通向 Amazon Bedrock 知识库、由 AgentCore Gateway 支持的 Lambda 工具、Jira Service Management 以及 DynamoDB 反馈。

当员工在 Deckhand 所属的频道中发帖时，Slack 服务会汇集完整的会话历史和用户上下文，然后通过 AgentCore runtime API 调用智能体。智能体会搜索知识库并按需调用工具。找到答案时，它会返回最终响应（图 3）。找不到时，它会提出澄清性问题或提议创建工单（图 4）。

Slack screenshot of Deckhand replying with numbered self-service steps

图 3：Deckhand 提供自助服务步骤作为响应

Slack screenshot of Deckhand offering a Create Ticket button

图 4：Deckhand 提议创建工单

Deckhand 工作流程

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

前提条件

要实现此模式，您需要满足以下条件：

  • 一个有权访问 Amazon Bedrock、AgentCore runtime 和 AgentCore Gateway 的 AWS 账户。
  • 一个具有事件订阅、签名密钥以及针对您的用例进行了权限范围配置的机器人令牌的 Slack 应用。
  • 一个容器镜像注册表，例如 Amazon Elastic Container Registry (Amazon ECR)。
  • 一个 Amazon S3 存储桶和一个 Amazon Bedrock 知识库。
  • 针对每个运行时和工具进行了权限范围配置的 AWS Identity and Access Management (IAM) 角色，以及用于第三方凭证的 AWS Secrets Manager 条目。

使用 Strands Agents 和 AgentCore 构建智能体

该智能体特意保持轻量。使用开源的 Strands Agents SDK，一个智能体由一个模型、一组工具和一个系统提示词组成。该 SDK 管理推理循环，使模型能够选择工具、处理结果并迭代，直到生成答案。Deckhand 的智能体服务仅用几行 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 通过环境变量设置，这使得无需修改应用程序代码即可切换模型。

工具以两种方式与智能体集成。Amazon Bedrock Knowledge Bases 检索是原生的 Strands 工具，只需一次导入即可支持知识库搜索。其他功能，包括分类、工单管理、用户解析和图像分析，由注册在 AgentCore Gateway 上的 Lambda 函数处理。Gateway 将这些功能暴露为 MCP 工具，Lambda 按工具名路由每次调用。这种分离使工具逻辑可以独立更新，智能体无需重新构建即可从 Gateway 访问新工具。

AgentCore runtime 将智能体作为容器托管，无需进行服务器或会话管理。Slack 服务对每条消息同步调用智能体，提供线程记录和用户上下文，并发布最终回复。由于包括员工档案在内的上下文随每个请求一并提供，智能体可以自动补全工单详情。

知识库设计与答案路由

Deckhand 基于一个 Amazon Bedrock 知识库回答问题，其中包含核心的 S3 支持的数据源：

  • 从 Confluence 同步的文章。
  • 从公司内网同步的内部页面、PDF 和活动。
  • 从 Slack 中挖掘的已解决支持线程（下一节介绍）。

每个文档都包含标题、来源 URL、内容类型和活动日期等元数据。这使得智能体可以筛选内容，例如当用户询问 Austin 办公室即将举行的活动或每周午餐菜单时。

使用递归语言模型（RLM）挖掘 Slack 历史记录

最有价值的数据源是已解决支持线程的存档。在 Deckhand 出现之前，Slack 是问题得到解决的地方：多年来员工描述问题、IT 带领他们完成修复。这段历史是一个有机的知识库，经过了最好的审阅者——问题得到解决的人本人——的验证。但它也很嘈杂：原始导出内容混杂了闲聊、自动警报以及从未真正解决的线程。将未经验证的修复方案或混乱的摘要编入索引，意味着知识库会以与正确答案相同的置信度呈现错误答案，因此提取必须精确。

挖掘过程遵循三阶段流水线（图 5）：

  1. 一个脚本通过 Slack API 导出频道的完整历史记录，获取每个线程的完整回复，并写入包含线程标记、时间戳和回复数的结构化转储。
  2. DSPy 的递归语言模型（RLM）在 Amazon Bedrock 上运行 Claude，将该导出视为沙箱化 Python 读取-求值-打印循环（REPL）内的可导航记忆空间，而非单个提示词。它对数据进行迭代处理，将每个线程分类为已解决、未解决或已升级，并过滤掉公告和非问题。严格的标准保证了高质量：只有当完整、可行的修复方案在线程本身中清晰可见时，该线程才算作已解决。
  3. 对于每个已解决的会话线程，RLM 会编排递归的子 LLM（大语言模型）调用来提取结构化字段，每个字段都根据 Pydantic 模型进行验证。这些字段包括问题摘要、原始提问和解决方案。它们还记录修复方式是自助服务还是需要提交工单、自助服务步骤、所涉及的应用和系统、错误消息以及标签。当子 LLM 调用返回的结果不符合 schema 时，RLM 基于代码的循环会在解释器中捕获该验证错误并重试。结果会被写成一份按问题组织的 markdown 文档。该流水线将其上传到 Amazon S3，供知识库进行索引。

Three-stage pipeline diagram: export Slack channel history, classify threads as resolved or not, and extract structured fields

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

我们选择 RLM，因为它将整个 Slack 历史记录保存在一个持久化的沙箱变量空间中，可以对导出内容进行迭代推理，并保持一致的输出结构。这样一来，当员工遇到同事曾解决过的问题时，Deckhand 就能提供经过验证的解决方案，通常是以可操作的编号步骤呈现。

知道何时不应回答

共享频道中的 AI 机器人往往先在社交层面失败，而不是在技术上。Deckhand 最精细的逻辑就是决定何时保持沉默：

  1. 智能体对每条消息的第一个判断是：它是一条公告、社交消息，还是人与人之间的对话。如果是，它就输出“SKIP”，Slack 服务随即抑制回复。
  2. 在线程中，它只回复最初的提问者。
  3. 如果最后一条回复来自另一位人工帮助者，它会保持沉默，因为人已经接手了。
  4. 如果一条回复以 @某人 开头，那么这条消息不是发给机器人的。

收集反馈

每个回答都带有反馈按钮。点赞会被直接记录，而点踩则会提示填写一个简短的“哪里出了问题”字段。评分会连同原始提问和机器人的回答一起存储在 DynamoDB 中。

负面反馈是宝贵的数据集，用于改进系统提示词和智能体行为，以及更新知识库中不正确的信息。

安全与验证

提示词规则可以增强行为，但不能替代访问控制。强制执行通过代码和基础设施来管理：

  • 创建工单需要明确确认。当 Deckhand 提出要创建工单时，Slack 服务会添加一个 创建工单 按钮，点击该按钮即通过智能体发送确认。工单更新只接受符合服务台项目模式的有效键，并拒绝空评论。
  • 分类在执行前会经过验证。请求分类作为单独的 Amazon Bedrock Converse API 调用运行，返回结构化的工单字段，并在任何内容到达 Jira 之前使用 Pydantic 进行验证。
  • 图像工具被限制为只能从 Slack 的文件主机下载。它使用机器人令牌进行身份验证，将每个请求限制为最多五张图片、每张不超过 5 MB，并通过 Converse API 将文件发送给视觉模型。
  • 凭证不写入代码。Slack 令牌、签名密钥和 Jira 凭证存放在 AWS Secrets Manager 中，每个服务和工具都在各自作用域受限的 IAM 角色下运行。
  • 提示词强制执行行为安全措施：绝不索要密码或多因素认证（MFA）验证码，绝不在工单评论中写入凭证，绝不暴露用于工单字段的个人资料元数据。

成果

Deckhand 于 2026 年 4 月上线。它最初每天处理约 30 条消息，到初夏时达到每天最多 100 条。在上线后的前三个月里，它处理了 1,935 条消息，开启了 1,221 个智能体会话，并创建了 409 个 Jira 工单。它回复了 97.5% 的消息。三分之一的问题是在下班后提出的，当时 IT 团队没有人上班，而 Deckhand 回答了其中 94% 的问题。原本要等到第二天早上才能得到答复的人，当晚就得到了答案。

随着团队不断改进，反馈也有所提升。在修订系统提示词和知识库以解决用户反馈的问题后，好评率从 4 月的 82% 提升到 6 月的 96%。

最显著的成效是工单分流。一个智能体会话代表一个原本可能会变成 Jira 工单的问题。在 1,221 个会话中，只有 409 个变成了工单，其余 812 个都在聊天中得到解决。提交一个工单并处理、关闭它大约需要 30 分钟。这 812 个会话在三个月内累计节省约 406 小时，一年约 1,600 小时。员工把这段时间留给了自己的工作，而 IT 团队也无需将其花费在工单受理上。

结论

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

要构建类似的解决方案，请从一个维护良好的知识源和一个明确定义的操作开始。智能体开发请参考 Amazon Bedrock AgentCore 文档 和 Strands Agents SDK，连接内容源请参考 Amazon Bedrock Knowledge Bases 文档。

要讨论适用于您组织的智能体 AI 用例，请联系您的 AWS 客户团队。

关于作者

来源：AWS Machine Learning Blog · aws.amazon.com

#教程/实践#Agent#RAG#部署/工程#Anthropic