97.5% 的 IT 提问没变成工单，ShipStation 把 Slack 历史变成了知识库

ShipStation Global 的 IT 团队以前每天要回答同样的问题。答案多半已经存在，在 Confluence 文章里，在内网页面里，在八个月前某条 Slack 线程里。找答案才是麻烦的地方。

他们建了一个叫 Deckhand 的 Slack 机器人，跑在 Amazon Bedrock AgentCore 上。上线前 12 个月，IT 帮助频道里积累了 1500 多条线程，提问量还在涨。员工分布在美国、英国、西班牙、波兰、澳大利亚和菲律宾，超过五分之一的问题发生在美国工作时间之外。

Deckhand 上线三个月的数据：处理 1935 条消息，发起 1221 次对话，只开了 409 个 Jira 工单。回复了 97.5% 的频道消息，下班后的问题解决了 94%。好评率从 4 月的 82% 升到 6 月的 96%。

开一个工单、处理、关闭，大约花 30 分钟。那 812 次没变成工单的对话，三个月省下约 406 小时，一年接近 1600 小时。员工拿回了自己的时间，IT 团队不用再做重复的 intake。

架构不复杂，每个部件只做一件事

Deckhand 分四块。

Slack 服务用 FastAPI 和 Slack Bolt，跑在 AWS App Runner 上。它接收 Slack 事件，判断 bot 该不该回复，从用户 profile 里组装姓名、邮箱、时区、经理这些上下文。

Agent 服务用 Strands Agents SDK 写，部署在 AgentCore runtime 的容器里，底层是 Amazon Bedrock 上的 Claude。推理循环交给 SDK，模型自己选工具、处理结果、迭代到出答案。

工具和知识放在一个 Lambda 函数里，通过 AgentCore Gateway 暴露成 MCP 工具。它负责分类请求、创建和更新 Jira 工单、分析图片。知识库用 Amazon Bedrock Knowledge Bases，索引 Confluence、内网、Slack 和营销页面的内容，存在 S3 里。

运维和反馈用 DynamoDB 存评分，X-Ray 做链路追踪，CloudWatch 收日志。

员工在频道里发消息，Slack 服务把整条线程历史和用户上下文打包，通过 AgentCore runtime API 调 agent。agent 查知识库、按需调工具。找到答案就返回，找不到就问一个澄清问题，或者提议开工单。

用 RLM 挖 Slack 历史，这是最值钱的一段

Deckhand 最有价值的数据源不是那些精心维护的文档，是 Slack 里已经解决过的线程。员工描述问题，IT 一步步带他们修好。这些历史是一个有机的知识库，审核者是问题被解决的那个人。

但它很脏。原始导出里混着闲聊、自动告警、没解决的线程。如果把一个没验证的修复或者一段混乱的总结索引进去，知识库会带着同样的自信给出错误答案。提取必须精确。

他们用了 DSPy 的 Recursive Language Model（RLM）。RLM 不把整个 Slack 导出塞进一个 prompt，而是把它放进一个沙盒 Python REPL 的变量里，当成可导航的内存空间。模型在上面迭代，写代码去检索、分类每个线程是 resolved、unresolved 还是 escalated，过滤掉公告和非问题。

判定 resolved 的标准很严：完整的、可操作的修复必须出现在线程本身里。

对每个 resolved 线程，RLM 再编排递归的子 LLM 调用，提取结构化字段，每个字段都用 Pydantic 模型校验。字段包括问题摘要、原始提问、解决方案、是自助还是需要工单、自助步骤、涉及的应用和系统、错误信息、标签。子 LLM 返回的东西不符合 schema，RLM 的代码循环会在解释器里捕获校验错误并重试。结果按问题组织成 markdown 文档，上传到 S3 供知识库索引。

选 RLM 的原因是它能把整个 Slack 历史维持在一个持久化的沙盒变量空间里，迭代推理，输出结构一致。当员工碰到一个同事以前解决过的问题，Deckhand 给出的是被验证过的方案，通常还是编号步骤。

知道什么时候不该说话

一个 AI 机器人放在共享频道里，社会性失败会先于技术性失败。Deckhand 打磨最多的逻辑是决定什么时候闭嘴。

它收到每条消息的第一个判断是：这是公告、社交消息，还是两个人之间的对话。如果是，输出 SKIP，Slack 服务不回复。在线程里，它只回复原帖作者。如果最后一条回复来自另一个人类帮手，它保持沉默，因为人已经接手了。如果一条回复开头 @ 了某个人，那这条消息不是给 bot 的。

安全和验证不靠 prompt

提示词规则能改行为，但不能替代访问控制。Deckhand 的强制措施在代码和基础设施里。

创建工单需要明确确认。bot 提议开工单时，Slack 服务加一个 Create Ticket 按钮，点下去才通过 agent 发送确认。工单更新只接受匹配 helpdesk 项目模式的合法 key，拒绝空评论。请求分类跑单独的 Amazon Bedrock Converse API 调用，返回结构化字段，先用 Pydantic 校验，再到 Jira。图片工具只能从 Slack 的文件主机下载，用 bot token 认证，每次最多五张图，每张不超过 5 MB，发给视觉模型走 Converse API。Slack token、签名密钥、Jira 凭证放在 AWS Secrets Manager，每个服务和工具跑在自己作用域的 IAM 角色下。prompt 里也写了行为护栏：不请求密码或 MFA 码，不在工单评论里写凭证，不暴露用于工单字段的 profile 元数据。

结果

Deckhand 2026 年 4 月上线，从每天 30 条消息涨到初夏的 100 条。三个月处理 1935 条消息，发起 1221 次 agent 对话，开了 409 个 Jira 工单。三分之一的问题在下班后进来，Deckhand 回答了其中的 94%。本来要等到第二天早上的人，当晚就拿到了答案。

ShipStation 的 IT 高级总监 Chris Collins 在 AWS 博客里说，他们建 Deckhand 是因为求助应该像在 Slack 里问个问题那么简单，而不是去解读工单表单或者发邮件到虚空里。他们认为工单代表的是运营摩擦，不是生产力。

这个案例有意思的地方不在框架多新。AgentCore runtime 托管 agent，Gateway 把 Lambda 变成 MCP 工具，Knowledge Bases 做检索，团队没搭服务器也没维护编排代码。真正反常识的是数据源的选择：最值钱的知识不在精心维护的 wiki 里，在那些没人整理、混着闲聊和告警的 Slack 历史里。RLM 做的事情是把这些脏数据变成了可验证的答案。

参考来源：AWS Machine Learning Blog，ShipStation Global 团队与 AWS 解决方案架构师合写的原文。