ShipStation Global 如何在 Amazon Bedrock AgentCore 上构建 AI IT 服务台

本文由 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 上，这是一个可使用任意框架或模型大规模构建、连接和优化智能体的平台。AgentCore 运行时是 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 的一项能力）暴露为 Model Context Protocol (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 运行时将智能体托管为容器，无需服务器或会话管理。Slack 服务对每条消息同步调用智能体，提供线程记录和用户上下文，并发布最终响应。由于每个请求都包含上下文（包括员工档案），智能体可以自动补全工单详情。

知识库设计与答案路由

Deckhand 从单个 Amazon Bedrock 知识库中回答，其核心数据源由 S3 支持：

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

每个文档都包含元数据，如标题、来源 URL、内容类型和事件日期。这使智能体能够过滤内容，例如当用户询问奥斯汀办公室即将举行的活动或每周午餐菜单时。

使用递归语言模型（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 服务会添加一个 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 的工程总监，领导一支 SWAT 团队，专注于在各部门部署 AI。他热衷于解决问题，并利用数据推动可落地的改进。

Nick Ciubotariu

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

Ravi Kashyap

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