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

本文由 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）。

图 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 runtime 是 Amazon Bedrock AgentCore 的一项能力，可在隔离会话中托管代理，因此我们无需运行服务器或容器。

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

Slack 服务： 一个 FastAPI 和 Slack Bolt 应用，托管在 AWS App Runner 上。它接收 Slack 事件，判断机器人是否应作出响应，并根据请求者的 Slack 个人资料构建用户上下文载荷，其中包括姓名、电子邮件、时区和经理。
Agent 服务： 一个 Strands agent，以容器形式部署在 Amazon Bedrock AgentCore runtime 上，使用 Amazon Bedrock 中的 Anthropic Claude 管理多轮工具 agent 循环。
工具与知识： 一个 AWS Lambda 函数，通过 AgentCore Gateway（Amazon Bedrock AgentCore 的一项功能）作为模型上下文协议 (MCP) 工具公开，可对请求进行分类、创建和更新 Jira 工单，以及分析图像。一个 Amazon Bedrock 知识库为 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 知识库、由 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 知识库。
为每个 runtime 和工具配置权限范围的 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 runtime 将代理作为容器托管，从而无需进行服务器或会话管理。Slack 服务针对每条消息同步调用代理，提供线程记录和用户上下文，并发布最终响应。由于每次请求都包含上下文（包括员工个人资料），代理可以自动填写工单详细信息。

知识库设计与答案路由

Deckhand 从单个 Amazon Bedrock 知识库中获取答案，该知识库包含由 S3 支持的核心数据源：

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

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

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

最有价值的数据源是已解决支持线程的存档。在 Deckhand 出现之前，Slack 是问题得到解决的地方：员工多年来在那里描述问题，IT 人员则引导他们完成修复。这些历史记录构成了一个有机知识库，并由最理想的审核者进行验证：问题得到解决的当事人。不过，它也很嘈杂：原始导出内容混杂着闲聊、自动警报，以及实际上从未解决的线程。为未经验证的修复方案或含混不清的摘要建立索引，意味着知识库会以与正确答案相同的置信度提供错误答案，因此提取过程必须足够精确。

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

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

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

我们选择了 RLM，因为它会在持久化沙盒变量空间中保留完整的 Slack 历史记录，从而能够对导出内容进行迭代推理，并保持输出结构一致。因此，当员工遇到同事曾解决过的问题时，Deckhand 会提供已验证有效的解决方案，通常是可执行的编号步骤。

知道何时不回答

在共享频道中，AI 机器人在技术层面出问题之前，往往先在社交层面出问题。Deckhand 最精细的逻辑决定了何时保持安静：

代理对每条消息的首要判断是：它属于公告、社交消息，还是人与人之间的对话。如果是，代理就会输出“SKIP”，Slack 服务会抑制回复。
在对话线程中，它只回复最初发帖的人。
如果最后一条回复来自另一位人工协助者，它就保持沉默，因为已经有人接手处理。
如果回复以 @提及某个人开头，这条消息就不是发给机器人的。

收集反馈

每个回答都包含反馈按钮。点赞会直接记录；点踩则会提示填写简短的“出了什么问题”说明。评分会与原始问题和机器人的回复一同存储在 DynamoDB 中。

负面反馈是很有价值的数据集，可用于改进系统提示和代理行为，并更新知识库中的错误信息。

安全与验证

提示规则可以改善行为，但不能取代访问控制。访问控制通过代码和基础设施来实施：

创建工单需要明确确认。当 Deckhand 提议创建工单时，Slack 服务会添加一个创建工单按钮；点击该按钮后，代理会收到确认。工单更新只接受符合帮助台项目格式的有效键，并会拒绝空评论。
分类结果在执行操作前会经过验证。请求分类通过单独调用 Amazon Bedrock Converse API 来完成，该 API 会返回结构化工单字段，并使用 Pydantic 进行验证，验证通过后才会将内容发送到 Jira。
图像工具仅限从 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 客户团队。

作者简介

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 的特遣团队。他热衷于解决问题，并利用数据推动切实可行的改进。

Nick Ciubotariu

Nick 是 ShipStation Global 的首席技术官。他从事企业级软件和 AI 系统的交付工作已有二十多年，这些系统的用户达数亿人。

Ravi Kashyap

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