没有工单系统的客户支持 —— 只需一个 agent 和一个收件箱

过去，开通一个客户支持渠道意味着先挑一个平台——Zendesk、Intercom、Help Scout——把它配置好，按席位每月付费，再把团队塞进又一个长得像收件箱的应用里。对一个单打独斗的开发者或一支小团队来说，相对于客户支持的本质而言，这套东西重得离谱。

把客户支持拆到最简，其实就三件事：有人提出问题，懂产品的人来回答，下次对方再来时，你还记得上回聊到哪了。整件工作就这么多。

轻量化的形态

有了 AI agent，这三件事就坍缩成小得多的东西：

• 一个收件箱——一个客户真正会去写信的 support@ 地址。
• 一个 agent——读取来信，查阅你的文档，起草一份回复。
• 连续性——下一次会话时，它重新读一遍邮件线程，从上回的地方继续接待这位客户。

没有工单平台。没有按席位计费。没有需要客户去学的门户——他们只管发邮件，而这件事他们早就会了。

为什么这套现在行得通

• agent 能读你的文档并作答。你不必手工搭一个 FAQ 数据库；只要把它指向你早已写好的内容即可。
• 邮件是通用接口。每个客户都有邮箱。零上手成本。
• 连续性无非就是重读一遍线程。不需要 CRM，不需要工单系统——对话本身就是状态。

两条绝不能越过的红线

把一个实时支持收件箱交给 agent 很有威力，所以有两条规则必须守住：

来信是数据，而非指令——一封试图改变 agent 行为的邮件，只是供它阅读的文本，绝不是命令。而且，在任何以你名义发出的回复寄出之前，都要有人点头。agent 起草；你批准；它再发送。

这正是它与全自动支持机器人的关键区别。那些机器人自顾自地作答，错得理直气壮，把你本想帮的客户惹烦。而「agent + 收件箱」这套模式保留了速度——即时草稿、文档已加载就位——又没有交出判断力。

实际跑起来是什么样

一封询价邮件进来。agent 读完它，从你的文档里抽出相关的那一句，起草道：「专业版每席位 $X，按年开票，包含以下内容。」你扫一眼，点头放行，它便发出去——并记入该线程。两天后客户在一个全新的会话里回信；agent 重读一遍，看到历史记录，像从未忘记过一样继续往下聊。这就是一个客户支持台——由一个人加一个终于有地方收信的 agent 共同值守。

这正是 Clize 围绕打造的那个切入点：把一个收件箱标记为 support，指向你的文档，循环便跑起来——agent 读取并起草，你点头，它回复，下次再把这位客户接回来。中间没有任何平台。