ShipStation Global 如何在 Amazon Bedrock AgentCore 上构建 AI IT 服务台 | Amazon Web Services
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 上运行它，这是一个用于大规模构建、连接和优化智能体的平台，支持任何框架或模型。AgentCore runtime 是 Amazon Bedrock AgentCore 的一项能力，它在隔离会话中托管智能体，因此我们无需运行任何服务器或容器。
该解决方案有四个主要组件，如图 2 所示：
Slack 服务：一个 FastAPI 和 Slack Bolt 应用程序，托管在 AWS App Runner 上。它接收 Slack 事件，判断机器人是否应作出响应，并根据请求者的 Slack 个人资料构建用户上下文负载，包括姓名、电子邮件、时区和管理者。
智能体服务：一个 Strands 智能体，作为容器部署在 Amazon Bedrock AgentCore runtime 上，使用 Amazon Bedrock 中的 Anthropic Claude 管理多轮工具智能体循环。
工具与知识：一个单一的 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（应用程序编程接口） 调用智能体。智能体搜索知识库并按需调用工具。当它找到答案时，会返回最终响应（图 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 构建智能体
该智能体有意保持轻量。使用开源 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、内容类型和事件日期。这允许智能体过滤内容，例如，当用户询问即将到来的活动或奥斯汀办公室的每周午餐菜单时。
使用递归语言模型 (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 按钮，选择该按钮会通过智能体发送确认。工单更新仅接受与 helpdesk 项目模式匹配的有效键，并拒绝空评论。
分类在执行前经过验证。请求分类作为单独的 Amazon Bedrock Converse API 调用运行，返回结构化工单字段，并在任何内容到达 Jira 之前使用 Pydantic 进行验证。
图像工具仅限于从 Slack 的文件主机下载。它使用 bot token 进行身份验证，将每个请求限制为五张图像，每张最大 5 MB，并使用 Converse API 将文件发送到视觉模型。
凭证不留在代码中。Slack token、签名密钥和 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；如有侵权，请联系管理员删除。
