ShipStation Global 如何基于 Amazon Bedrock AgentCore 构建 AI IT 服务台 Deckhand

本文由 ShipStation Global 的 Kenneth Salmon、Edward Boswell、Jack Armstrong、Robert Banh 和 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）。

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

业务挑战

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

频道数据让规模变得具体。在发布前的 12 个月里：

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

“我们创建 Deckhand，是因为获得帮助应该像在 Slack 中提问一样简单，而不是去解读工单表单或把邮件发进虚空。我们认为工单是运营摩擦的迹象，而非生产力的体现。Deckhand 会当场解决常见问题；当它无法解决时，只需一键就能把对话转化为一份上下文完整的工单，从而改善员工体验，并让我们的团队从无休止地重复‘请提交工单’这句话中解放出来。”

— Chris Collins，ShipStation Global IT 高级总监

解决方案概述

Deckhand 像任何队友一样在 Slack 中工作——加入频道、阅读对话，并从 Slack 个人资料中提取上下文，就地回答 IT 问题。我们将其运行在 Amazon Bedrock AgentCore 上，这是一个用于大规模构建、连接和优化代理的平台，支持任何框架或模型。Amazon Bedrock AgentCore 的 AgentCore 运行时能力在隔离会话中托管代理，因此我们无需运行服务器或容器。

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

1. Slack 服务： 一个 FastAPI 和 Slack Bolt 应用，托管在 AWS App Runner 上。它接收 Slack 事件，判断机器人是否应作出响应，并根据请求者的 Slack 个人资料（包括姓名、电子邮件、时区和管理者）构建用户上下文负载。
2. Agent 服务： 一个 Strands agent，作为容器部署在 Amazon Bedrock AgentCore runtime 上，使用 Amazon Bedrock 中的 Anthropic Claude 管理多轮工具 agent 循环。
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。

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

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

图 3：Deckhand 以自助步骤作出响应

图 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 构建 agent

该 agent 有意保持轻量。使用开源 Strands Agents SDK，一个 agent 由模型、一组工具和系统提示组成。该 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 通过环境变量设置，这样无需修改应用代码即可切换模型。

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

AgentCore 运行时将智能体托管为容器，免去了服务器或会话管理的需要。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，供知识库建立索引。

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

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

知道何时不该回答

共享频道中的 AI 机器人往往先在社会层面失败，然后才在技术层面失败。Deckhand 最精细的逻辑决定了何时保持沉默：

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

收集反馈

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

负面反馈是宝贵的数据集，用于改进系统提示词和智能体行为，并更新错误的知识库信息。

安全与校验

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

• 创建工单需要明确确认。当 Deckhand 提出创建工单时，Slack 服务会添加一个 Create Ticket 按钮，选择该按钮会通过智能体发送确认。工单更新只接受与帮助台项目模式匹配的有效键，并拒绝空评论。
• 分类在执行前会经过校验。请求分类作为单独的 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 运行时托管智能体，AgentCore Gateway 把 Lambda 函数变成智能体可调用的 MCP 工具，Amazon Bedrock Knowledge Bases 负责检索。团队无需搭建服务器或维护编排代码就完成了交付。

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

如需讨论贵组织的智能体 AI 用例，请联系您的 AWS 客户团队。

关于作者

Kenneth Salmon

Kenneth 是 ShipStation Global 的软件工程师，专长于集成、工作流自动化和 AI 驱动系统。他的工作重点是运用应用 AI、大型语言模型和对话式智能体来解决复杂的运营挑战。

Edward Boswell

Edward 是 ShipStation Global 的高级软件工程师，专长于 AI 应用和快速原型开发。他热衷于用 AI 消除运营瓶颈、提升团队效率。工作之外，Edward 曾是一名职业魔术师，喜欢在会议上表演助兴。

Jack Armstrong

Jack 是 ShipStation Global 的高级软件工程师。他是一名多语言程序员，熟悉 Python、TypeScript 等语言，在软件工程系统方面拥有丰富知识，尤其是 Amazon Bedrock。

Robert Banh

Robert 是 ShipStation Global 的工程总监，领导一支专注于在各部门部署 AI 的 SWAT 团队。他热衷于解决问题，并利用数据推动可执行的改进。

Nick Ciubotariu

Nick 是 ShipStation Global 的首席技术官。他拥有二十多年交付企业级软件和 AI 系统的经验，这些系统被数亿人使用。

Ravi Kashyap

Ravi 是 AWS 的高级解决方案架构师，与零售和电子商务公司合作，帮助他们构建、扩展和优化云与 AI 工作负载。他专注于自动化和应用 AI，并作为活跃的开源贡献者回馈开发者社区。