使用Claude Code和MCP自动化一线客服支持

过去十周，我的Mac上每天清晨6点自动运行Claude Code，根据单一指令文件执行任务。它通过MCP服务器拉取流量、新的生产错误和运行时间，在我坐下来工作前将一份报告发送到我的邮箱。迄今为止已成功运行67次——稳定可靠，正是目的所在。

本周，我将这一流程扩展到早间最耗时的任务：客服收件箱。首次运行处理了5个工单线程，在我的邮件客户端中创建了3份回复草稿，并正确跳过了2个。本文包含完整设置，包括指令文件，以便您构建同样的系统。其中没有任何针对SiteSpeak的特定内容：任何配备MCP服务器的支持工具都能工作。

收件箱为何成为手动环节

我们的AI聊天机器人已经处理了sitespeak.ai上的第一线问题，这部分自动化已运行多年。真正的手动工作是机器人升级的问题：错误报告、账单咨询和想与真人交谈的潜在客户。这些信息都落入收件箱，每天早上我需要阅读每条对话，判断哪些“它坏了”是真的出了问题，然后撰写回复。

数量从来不是问题——每天只有少量工单，单凭节省的时间不足以证明自动化的价值。问题在于一致性：正确的回复需要检查错误日志、阅读相关代码、核实文档后再作答。每天清晨，在所有其他事务之间，彻底完成每个工单，正是拥有合适工具的代理应该为您做的工作。

设置一览

四个组件：

• Claude Code，按计划无头运行：通过launchd任务执行claude -p "/morning-report"（在Linux上可使用cron）
• 四个MCP服务器：支持工具的收件箱、Sentry、Nightwatch以及我的邮件客户端
• 一个Markdown技能文件，描述工作流程、分类规则和硬性限制
• 一个JSON状态文件，记录每个已处理的工单，确保运行幂等

没有胶水代码，没有API集成项目。代理依据指令文件，将四个服务器组合成一个小型代理工作流。这就是MCP的实际优势：每个工具通常需要的集成工作消失了，“集成”变成了一份人类可以阅读和编辑的文档。

运行的实际操作

根据技能文件的逐步流程：

1. 通过支持工具的MCP服务器列出开放收件箱工单，只保留上次运行后有活动的工单。状态文件过滤掉已处理的。
2. 读取访客自己的消息（而非仅机器人回答）。对每个工单分类：紧急（现有客户、故障、计费、要求转人工）、潜在客户（评估、定价、“能否做X”）或噪音（垃圾邮件、空会话、测试）。
3. 在草拟前进行调查。错误报告对照Sentry和Nightwatch匹配生产错误，并检查仓库中的相关代码。“如何做”类问题则核实在线文档。这一步的效果令我惊讶。
4. 先检查邮件。在草拟前，代理搜索过去30天内来自同一地址的现有邮件线程。人们常常在聊天机器人告知有人会跟进后，立即通过邮件联系支持。如果对话已在邮件中发生，则跳过该工单。
5. 在邮件客户端中创建草稿。不允许发送。每个草稿等待我审阅。
6. 归档工单，并将访客ID、所采取的行动和原因记录到状态文件中。跳过的工单也要记录，否则下次运行会重新读取相同的垃圾邮件。
7. 报告。支持部分与错误、流量和运行时间等信息一同出现在同一封早间邮件中，每行对应一个工单，并附带草稿链接。

整个运行有20分钟超时，因此挂起不会阻塞第二天的运行。

两条最重要的规则

以上都是基础架构。技能文件中的两行规则才真正使输出可信。

“永不猜测。草稿中的每个声明必须在本会话中验证，否则不得出现。”没有这条规则，LLM会愉快地编造您不拥有的功能，以自信友好的语气对付费客户说。有了这条规则，一个声明要么在运行期间对照代码、文档或错误日志进行了检查，要么就不出现。遵循此规则的草稿读起来像是由真正调查过问题的人写的——因为确实如此。

“绝不发送。仅草稿。”技能的硬性限制部分完全禁止发送工具。回复到达客户的唯一方式是我在邮件客户端中点击发送。这是最纯粹的人机协作形式。这并非出于对可靠性的顾虑——大多数草稿未经编辑就直接发出。但偶尔需要人工编辑的草稿往往是发给不满客户的，而这种消息一旦发出就无法撤回。

首次运行捕捉到的问题

最初48小时内，三件事让我确信这一流程物有所值：

• 跨通道去重第一天就生效了。五个工单中有一个被跳过，因为访客已通过邮件直接联系我们并得到了回复。如果没有“先检查邮件”步骤，他们将从同一家公司收到第二份略有不同的回复。这会让您的支持显得像机器人农场。
• 它标记了聊天机器人的错误。分类发现一段对话中机器人告诉客户某个设置不存在。事实上该设置存在，只是位于不同的设置页面。报告标注为“可能错误，需要当天人工回复”。我本可能会直接跳过该工单，信任机器人的回答，因一句错误的话而失去客户的信任。
• 潜在客户不再等待。评估产品的客户会收到创始人当天上午发送的简短个人邮件，其中已包含经过验证的正确答案。此前，该工单会一直搁置到我有空处理，有时甚至要等好几天。

诚实的局限性

这是创始人级别的设置，而非企业支持管道。每天少量工单，由一人审核所有内容。如果您深陷数百个工单的泥潭，仅草稿模式并不能消除瓶颈，您需要以不同方式看待它。

另外，代理无法接触生产环境中的账户数据，这是有意为之。账单类问题会生成草稿，表明问题已记录并询问人类所需的具体细节，而非对其无法查看的账户状态做出承诺。

而且，必须强制执行“验证或省略”规则。请像对待新支持人员的入职说明一样对待技能文件：明确的规则、明确的护栏，并假设任何未写下的内容最终都会出问题。

自行构建

经过清理的技能文件、README以及launchd/cron示例配置已在开放仓库中：github.com/sitespeakai/support-inbox-agent。将MCP服务器名称替换为您自己的工具，并根据与客户沟通的方式编辑规则。

您需要：

• 一个代理CLI。我使用Claude Code。任何能加载MCP服务器并遵循指令文件的工具都可。
• 一个支持工具，带有MCP服务器。SiteSpeak提供了这样的服务器：可以列出收件箱工单、阅读完整对话、拉取潜在客户信息以及归档工单。如果您使用SiteSpeak，最快的方式是通过我们的Claude Code插件：/plugin marketplace add sitespeakai/sitespeak-claude-plugin，然后/plugin install sitespeak-chatbot-manager@sitespeak-plugins，并使用您的API令牌进行认证。
• 一个错误追踪工具，带有MCP服务器（如果您需要调查步骤）。Sentry有官方MCP服务器。
• 一个邮件客户端或邮件API，带有用于草稿的MCP服务器。
• 一个调度器。macOS使用launchd，其他系统使用cron，并加上超时封装。

从仅分类版本开始：分类和报告，不生成草稿。运行一周，阅读它产生的内容。当您信任分类后再加入草稿功能，并永远保持手动发送。这个顺序也是我构建它的方式：报告运行了十周后，我才让它接触客户回复。

常见问题

这需要SiteSpeak吗？ 不需要。该技能适用于任何支持工具，只要其MCP服务器能列出工单、阅读对话、返回访客邮箱并归档工单。SiteSpeak的MCP服务器与技能示例工具名称完全匹配，因此是零修改的路径，但工作流程本身与工具无关。

代理能自动发送邮件吗？ 不能。技能的硬性限制部分完全禁止发送工具，因此代理只能创建草稿。每个回复都经过人工审核和发送。大多数草稿未经编辑直接发出，但偶尔需要修改的草稿往往是高风险的。

需要哪些MCP服务器？ 两个是必需的：支持工具的收件箱和能处理草稿的邮件客户端。错误追踪工具（如Sentry）是可选的，但它驱动了调查步骤——在代理写字之前，将错误报告与真实生产环境问题进行匹配。

如果您还没有处理第一线支持的聊天机器人，这部分比代理更重要。本文讨论的收件箱之所以保持小而精，正是因为机器人回答了大多数问题，使其不会到达人工。您可以免费试用SiteSpeak，今天就在您的网站上运行第一线支持，包括MCP服务器。