每个答案都存在于另一个系统里
DMARCLY 的工单分为两类。计费类：一份发票副本、一笔退款、一次取消、一次套餐变更。以及送达类：为什么一份 DMARC 报告显示失败、一条 SPF 记录是否被正确扁平化，以及一个域名此刻的身份验证究竟是什么状态。
这些答案几乎没有一个存在于收件箱里。它们存在于 Stripe、域名的实时 DNS，或账户自己的 DMARC 汇总数据中。在用 Airclou 之前，每张工单都意味着一次上下文切换：打开计费系统、找到客户、交叉核对订阅，然后再回来敲出答案。团队规模小、客户又遍布各个时区，这个队列便直接与开发产品争夺时间。
拥有真实操作、而非套话答案的 AI 智能体
2026 年 6 月，队列迁移到了 Airclou Helpdesk，AI 智能体被赋予了一组针对 DMARCLY 真实系统的操作。它可以凭一个邮箱地址、一个域名，甚至仅凭一个发票号就找到对应的 Stripe 客户——自行把发票、客户、订阅串联起来。它可以列出发票，并为未支付的发票返回既有的付款链接，而不是生成一份重复的报价。它可以在回答送达类问题之前，检查一个域名的实时 SPF、DKIM 和 DMARC 记录，并读取账户自己的汇总数据，让回复描述的是那位客户的真实情况，而非照本宣科地念文档。
贯穿这一切的规则是：AI 智能体依据它所验证到的内容作答，而非依据对话中的声称。一位客户说“我被扣了两次款”，触发的是一次查询，而不是一笔退款。
凡是动用资金之处，由人来决定
退款、取消和套餐切换，绝不会凭 AI 智能体自己的权限执行。被提议的操作会停靠在一张审批卡上，卡片清楚地展示已验证了什么、以及将会发生什么——只有当有人批准，或当它落在团队预先定义的自动审批范围内（例如一个退款上限）时，才会执行。执行是幂等的，因此重试绝不会重复退款。
数字说明了什么
自 2026 年 6 月以来，该工作区已处理超过 900 次对话。AI 智能体已端到端发送了 200 多份回复——自行调研、起草、对照其关卡核查，并在无人碰过工单的情况下送达。这些回复背后，是针对 Stripe 与实时 DNS 的 1,400 多次已验证查询。此外，已有 20 笔退款执行——每一笔都经过一张审批卡，或落在预先批准的自动审批范围内，且都留有记录：验证了什么、由谁决定。
哪些仍会交给人来处理
有很多。当 AI 智能体无法验证账户是否匹配、当客户的问题仍未解决，或当某个操作落在所有自动审批范围之外时，它会主动退让，工单则等待人工处理——主动退让是一种被认可的结果，而非失败。而当一次运行确实失败时，它会落成一个人能据以行动的、可见的工单状态，绝不会只是一行悄无声息的日志。AI 智能体的职责不是把队列藏起来；而是确保处理队列的人只会看到那些真正需要人来处理的工单。
看看 Airclou 还在哪些地方投入生产运行