技能介绍

先说清楚痛点

写支持回复时，最容易翻车的不是措辞，而是上下文。客服工具里的对话往往是长线程：客户可能从多个邮箱来信，中间换过人接手，组织账号下挂着好几张关联工单。如果起草回复前只看当前这一屏，很容易把已经解决的问题再问一遍，或者给 A 公司的方案套到 B 公司头上。Help Scout 的收件箱、客户、组织和线程历史分散在几个入口里，人工逐个点开核对既慢又容易漏。

这个技能怎么工作

这个技能让兼容 MCP 的 Agent 在起草回复之前，先把 Help Scout 的上下文拉齐：

多对象检索：支持在 Mailboxes、Conversations、Customers、Organizations 四类资源上做查询，而不是只看单条会话。
线程级上下文：拉取完整线程历史，让起草的回复知道前面已经说过什么、承诺过什么、卡在哪一步。
身份归因：先确认客户与所属组织，再据此组织回复内容，避免把内部流程问题当成客户操作失误。
凭据只读：所需的 Help Scout 私有应用凭据只需要读取权限，不需要写入或改配置的权限。

典型流程是：拿到客户身份 → 定位所在组织与相关工单 → 读取线程上下文 → 再开始起草。回复的落点从“当前这一条消息”变成“这个客户当前的整体状态”。

适用边界与注意点

前提是你的客户端要兼容 MCP；认证走的是 Help Scout 私有应用，凭据范围限定在 Mailboxes、Conversations、Customers、Organizations 的读取权限上。
它只负责检索和提供上下文，不负责自动回复。要不要发、怎么发，仍然由人或你的上层流程决定。
线程历史完整度取决于 Help Scout 侧的数据保留策略，技能不会绕过这个限制。
如果你的工单流转严重依赖自定义字段或第三方集成，检索结果可能不包含这些扩展信息，起草前仍需人工确认。

适合用在：回复前想快速对齐账户状态的支持团队；不适合用在：需要强写入操作或跨系统事务编排的场景。