ShipStation在Slack上线AI IT助手Deckhand：前三个月处理1935条消息，97.5%在频道内回复
ShipStation Global工程团队基于Amazon Bedrock AgentCore构建了Slack内的AI IT帮助台Deckhand，可回答常规IT问题、识别报错截图并创建Jira工单。据AWS博客，其上线三个月内处理1935条消息、发起1221次对话、仅409次转为工单，员工正面反馈率从首月82%升至96%。
AI解读：1221次对话中只有409次转为工单，其余812次在聊天中解决。按单张工单约30分钟处理时间估算，ShipStation称这相当于三个月节省约406小时、一年约1600小时。
第三方来源为AWS官方博客，由ShipStation Global与AWS人员联合撰写，上述效果数据来自ShipStation自述，尚无独立验证。
知识库来源包括Confluence文章、公司内网页与PDF、以及通过递归语言模型从Slack历史线程中挖掘出的已解决支持对话。
当消息属于公告、社交聊天或人与人之间的对话时，Deckhand会输出“SKIP”保持沉默；若最后一条回复来自人工，或消息以@某人开头，它也不回应。
ShipStation Global工程团队构建了一个名为Deckhand的AI IT帮助台代理，运行在Slack中、部署于Amazon Bedrock AgentCore上。据AWS机器学习博客发布的技术说明，Deckhand可回答常规IT与公司问题、读取报错截图，并创建和更新Jira Service Management工单。
该博客由ShipStation Global与AWS人员联合撰写，称Deckhand在2026年4月上线后的前三个月处理了1935条消息、发起了1221次代理对话、创建了409张Jira工单，对频道内消息的回复覆盖率为97.5%。
上线三个月的数据与限制
据该博客披露，Deckhand于2026年4月上线，起步时每天约30条消息，到初夏增至每天最多100条。前三个月共处理1935条消息、发起1221次代理对话、创建409张Jira工单，对频道内消息的回复覆盖率为97.5%。
其中约三分之一的问题发生在非美国工作时间。ShipStation称，在无人值班的时段，Deckhand回复了94%的提问。
博客同时给出正面反馈率变化：4月为82%，6月升至96%。团队称这一提升来自根据负面反馈修改系统提示词并更新知识库内容。以上数据均来自ShipStation与AWS的联合说明，尚无独立第三方验证。
关于工单分流，博客称1221次代理对话中只有409次转为工单，其余812次在聊天中解决，并据此按单张工单约30分钟处理时间估算，三个月相当于节省约406小时、一年约1600小时。该估算是ShipStation自行给出的口径。
- 上线时间：2026年4月
- 前三个月处理消息：1935条
- 发起代理对话：1221次
- 创建Jira工单：409张
- 频道消息回复覆盖率：97.5%
- 非工作时段回复率：94%
- 正面反馈率：4月82%，6月96%
知识库如何从Slack历史中挖出答案
Deckhand的答案来自一个Amazon Bedrock知识库，数据源包括从Confluence同步的文章、从公司内网同步的页面与PDF，以及从Slack历史线程中挖掘出的已解决支持对话。每个文档带有标题、来源链接、内容类型和事件日期等元数据，用于按条件过滤。
Slack历史被视为最有价值的来源，但原始导出混杂闲聊、自动告警和未真正解决的线程。ShipStation采用三阶段流程处理：先用脚本通过Slack API导出完整历史；再由运行在Amazon Bedrock上的DSPy递归语言模型在沙箱Python环境中逐条分类为已解决、未解决或已升级，并过滤公告和非提问；对每个已解决线程，递归调用子模型提取问题摘要、原始问题、解决方案、是否可自助、自助步骤、涉及应用与系统、报错信息等结构化字段，并用Pydantic模型校验。
博客称，只有完整可行的修复方案出现在线程本身时，该线程才会被判定为已解决。校验失败的输出会在代码循环中被捕获并重试。最终结果写成按问题组织的Markdown文档，上传到Amazon S3供知识库索引。
何时沉默：共享频道中的回复规则
博客把“知道何时不回答”描述为Deckhand最精细的逻辑之一。代理对每条消息的第一个判断是：这属于公告、社交消息，还是人与人之间的对话；若是，则输出“SKIP”，由Slack服务抑制回复。
在话题线程中，它只回复原发帖人。如果最后一条回复来自另一位人工协助者，它保持沉默，因为已有人接手。如果某条回复以@某人开头，意味着消息不是发给机器人的。
每条答案附带反馈按钮。点赞直接记录；点踩会弹出简短字段询问哪里出了问题。评分连同原问题和机器人回复存入DynamoDB，负面反馈被用于改进系统提示词、代理行为以及修正知识库中的错误信息。
安全与权限控制
博客称，提示词规则用于约束行为，但不替代访问控制。创建工单需要显式确认：Deckhand提议建单时，Slack服务会添加一个“Create Ticket”按钮，选择后经代理发送确认。工单更新只接受符合帮助台项目模式的合法键值，并拒绝空评论。
请求分类作为单独的Amazon Bedrock Converse API调用运行，返回结构化工单字段，经Pydantic校验后才会到达Jira。图片工具被限制为只能从Slack文件主机下载，使用机器人令牌认证，每次请求最多5张、每张不超过5MB，再通过Converse API发送给视觉模型。
Slack令牌、签名密钥和Jira凭据存放在AWS Secrets Manager中，每个服务和工具运行在各自限定范围的IAM角色下。提示词层面的行为保障包括：不索取密码或多因素认证码，不在工单评论中写入凭据，不暴露用于工单字段的个人资料元数据。