AI服务台最难的任务，可能不是回答，而是知道何时别插话。ShipStation Global在10月13日披露内部助手Deckhand的生产复盘：它在Slack里检索知识、识别报错图片并衔接Jira，但人工接手时会退到一旁。这个4月已上线的系统，前三个月1221次智能体对话中有812次没有转成工单；比这组数字更值得复制的是，团队如何筛选知识与约束行动。

快速看点：历史聊天先验证有完整解法再入库；创建工单必须由员工明确确认；回复覆盖率不等于问题解决率，聊天自助与人工服务仍在同一个流程里。

先改求助流程，再给模型接工具

过去，员工在IT支持频道提问，答案却分散在Confluence、内网页面、PDF和旧线程里。即使此前有人处理过相同问题，新提问者也未必知道去哪里找。Deckhand选择直接进入已有的Slack求助入口，而不是要求员工先学习一个新的聊天应用。

这使实施目标变得具体：能自助解决的提供步骤，信息不完整的继续澄清，需要人工处理的带上上下文建单。对IT团队，少一张缺少描述的工单，往往比多一段流畅回答更有价值。流程有没有衔接下一步，才是这个助手的交付对象。

入口服务负责接收事件并组织线程与用户信息；Strands智能体运行在Bedrock AgentCore中，连接知识库和经Gateway暴露的MCP工具。Jira建单、分类、图片处理等能力在工具层执行，反馈与日志另行保存。模型负责选择步骤，但实际系统动作没有混在一段提示词里。

旧线程不是知识库，完整解法才是

团队没有把多年频道历史原样交给检索。聊天记录里有闲聊、通知、没有结论的问题，以及看似合理却没有被验证的建议。如果这些内容都被当成答案，检索准确找到一句话，也可能给员工带来错误操作步骤。这是知识工程问题，不是单纯扩大上下文就能解决。

处理流程先导出完整线程，再区分已解决、未解决和已升级处理等情况；只有线程本身包含完整可用修复方法，才被认作已解决。随后提取问题、系统、错误信息和步骤，并通过结构化字段检查后写入知识文档。历史资料的价值因此来自证据，而不是来自数量。

这套思路对企业内部支持有直接参考价值：一个“大家都这么说”的答案，和一个用户照着步骤完成修复的案例，不应拥有相同可信度。随着软件版本和业务环境变化，已成功过的方案也可能失效，知识维护仍需把日期、适用系统和后续负反馈纳入更新，而非一次导入后就放手运行。

能建单，也要能拒绝和保持安静

Deckhand会识别公告、社交信息和人与人之间的交流，并抑制不必要回复；在求助线程里主要回应原提问者。若最后一次回复来自人工帮助者，机器人保持安静。这样的设计不是削弱智能体，而是承认多人工作流里“谁正在处理”本身就是重要状态。

工具权限另有约束。创建Jira工单需要用户点击确认，更新只接受匹配支持项目格式的有效工单标识，分类字段也要验证后才能送入业务系统。图片工具限制下载来源，凭据置于受控存储，各服务使用限定权限。提示词里的“不要泄露密码”，不能替代这些代码和基础设施检查。

前三个月，系统处理1935条消息、开启1221次智能体对话，创建409张工单，其余812次在聊天中处理。这说明部分请求没有转入工单流程，但不证明每次都经过独立业务验收。材料中的97.5%在结果段对应消息回复覆盖，不能改写成97.5%的IT故障自动解决。

员工正反馈在迭代后于6月达到96%，也不等于所有使用者满意或所有回答正确。团队会收集负反馈，修正提示词及知识。更稳妥的观察方式，是同时看错误答复、人工升级、重复提问和真实处理结果，而不是只看机器人是否给出了回应。

小编判断：减少摩擦，别先追求无人化

这份复盘给出的重点，不是另一套“AI替代IT”的故事，而是低风险自助、上下文完整建单和人工接管之间的协作。把没建单的对话直接换算成工时收益，需要额外假设；把回复率写成解决率，则连指标含义都会改变。企业试点应先约定可检查的完成标准。

可复用的实施顺序是：梳理真实求助入口，整理经过验证的知识，再接入少量有确认闸门的动作，最后把反馈变成持续改进资料。能答、能转交、能停下来，比让机器人在每个线程里都表现积极更重要。员工感受到的服务质量，来自整个支持流程，而不只来自模型本身。