Stripe Radar 在其擅长的领域表现出色：在资金流动的瞬间对交易进行评分。但问题恰恰出在资金没有流动的那一刻。
我们提供 7 天免费试用。用户开始试用时需要绑定一张银行卡，但不会产生任何扣款——在底层，这是一个 Stripe SetupIntent，而非支付请求。没有扣款，就没有扣款时的事件，这意味着 Radar 最强大的规则在最关键的时刻无从发挥：当一个欺诈账户正在被创建、开始消耗试用额度的那一刻。
这是我们如何从在临时对话中手动应对欺诈，转变为运行一套自动化、分钟级欺诈防护层的故事——而这套系统正是基于我们自己的产品 Zero 构建的。
Radar 很出色，但"出色"不等于"完美"
Stripe Radar 确实很优秀。它基于超过每年 1 万亿美元的支付量进行训练，能以 92% 的概率识别曾经见过的银行卡，Stripe 也表示 Radar 平均能为使用它的企业减少 32% 的欺诈损失。
但请再读一遍这个数字：是减少，不是消除。平均减少 32% 已经相当可观——但这意味着仍有相当大比例的欺诈压力会落到你的门前。对此，Stripe 坦诚地解释了原因。用他们自己的话说："减少误报往往会增加真实欺诈漏网的可能性。" 漏网并非模型的缺陷，而是为了不误伤真实用户而主动承担的代价。每个反欺诈团队都在有意识地选择放行多少欺诈。
对于以试用为核心的产品而言，这个漏洞比表面数字所呈现的更大——因为 Radar 最强大的部分根本就没有运行。
为什么关卡只能减少，而无法终结欺诈
扣款时触发的引擎之所以只能减少欺诈而无法根除，有一个更深层的原因，这与 Stripe 的模型无关，而在于时机和信息。在用户添加银行卡的瞬间，他们还什么都没做。没有登录历史、没有产品行为、没有可供学习的使用模式——只有一张卡和少量网络信号。Radar 在证据最薄弱的时刻，凭借最有限的信息做出最优判断。
这就是真正的上限。你可以调整关卡，但无法给它提供尚不存在的数据。真正能区分滥用者和真实用户的信息，大多是在关卡做出决策之后才产生的。
第一阶段：在对话窗口中救火
我们最初的应对完全依赖人工。每当一波滥用袭来，就有人打开与智能体的对话，实时处理事件：拉取近期注册记录、查看银行卡信息、找出规律、手动封禁账户。
这种方式有效，但无法扩展。每次事件都要从零开始。那些经验——这个欺诈团伙的特征是什么、哪些信号可靠——只存在于某个人的脑子里和某个聊天记录里，对话窗口一关就烟消云散。
我们也在漏斗的另一端付出了代价：当我们想挽回那些放弃结账的真实用户时，一封不慎发给欺诈地址的邮件会造成真实伤害——它会确认该地址是有效的。我们构建的任何自动化系统都必须能区分真实潜在用户和植入的欺诈地址。
第二阶段：用 Radar 加固前门
我们的下一步是将所有能上移的措施都推进到 Radar——在绑卡环节设置黑名单和频率规则，并根据我们观察到的攻击压力进行调整。这是正确的第一步，也确实阻止了最粗糙的攻击。
但两个上限很快显现。第一个是 Stripe 自己承认的：扣款时触发的引擎是一个权衡旋钮，而非一堵墙——调紧了会误伤真实用户，调松了又会放进更多欺诈。第二个是结构性问题，且专属于试用场景：那 32% 的效果是在扣款时实现的，而 SetupIntent 试用根本没有扣款可供评分。 除非你明确为已保存的支付方式启用 Radar，否则引擎根本不会运行——即便运行，SetupIntent 上也只有"拦截"、"放行"和"3DS 验证"规则适用。"审核"动作——那个能让人工多看一眼的选项——永远不会触发。
因此，整个技术栈中表现最好的那一层，默认情况下恰恰在我们最需要它的时刻缺席。Radar 是前门的关卡，而我们需要的是关卡背后的巡逻。
第三阶段：基于 Zero 构建第二防护层
注册完成后，信息格局发生了逆转。账户开始留下痕迹——而这些痕迹中最丰富的部分，存在于支付处理商永远看不到的系统中：我们的身份提供商 Clerk。
于是我们让 Zero 接入了它。Clerk 掌握着 Stripe 无从得知的信息：账户的创建方式、注册方法和邮箱、背后的会话和设备，以及相对于当天其他所有注册的精确时间戳。Stripe 知道银行卡信息。两个系统单独来看都无法呈现完整图景——但智能体可以同时读取两者，并跨系统进行关联。在关卡处无迹可寻的滥用行为，并排对比时便一目了然：一个全新账户的登录身份与其账单身份不符，且与一批相似账户在几分钟内相继创建。这种跨系统的关联，正是扣款时触发的关卡无法实现的——而坐落于两个系统之上的智能体却能轻松做到。
基于这套更丰富的证据，我们每隔几分钟就对实时注册和账单数据运行一组 Zero 定时任务。三条原则指导着这些任务的设计：
1. 巡逻，而不仅仅是把守。 智能体不再只评估某一个时刻，而是在短循环中扫描所有近期注册，关联账户数据和支付元数据，将漏过前门的账户浮出水面。
2. 按置信度分级响应。 并非每个信号都值得采取相同的行动。高置信度的模式会被自动处理——账户立即被暂停，试用资格随即取消，因为这一操作可逆，而等待的代价是真实存在的。置信度较低的信号则绝不自动处理，而是汇总成报告供人工审核。在有把握的地方果断行动，在没把握的地方保持谨慎。
3. 保留人工审计记录。 每一次自动操作都会记录触发它的确切信号，以便在数秒内完成审查——乃至撤销。无法审计的自动化，是无法信任的自动化。
我们将同样严格的标准应用于漏斗的友好一侧。一个独立任务会找出真正放弃结账的用户，并起草一封挽回邮件供人工审批——背后设有刻意严格的欺诈过滤器，确保我们绝不会验证一个无效地址。同一套引擎，截然相反的目标。
对业务经济性的影响
巡逻系统上线后，数字立竿见影地发生了变化。看看第 90 百分位的注册用户——那些造成真实损失的重度账户。其中一个账户在最初几小时内消耗的试用算力，从约 4 美元降至约 0.25 美元——降幅达 94%。 在同一时间窗口内，所有新注册账户的平均每账户损失下降了约 85%。
变化的形态说明了一切。大多数注册从未给我们带来任何损失；损失始终集中在一条又长又重的尾部——那些只为消耗试用额度而存在的账户。巡逻系统没有缩小漏斗，而是切断了那条尾巴。注册数量没有减少，质量却更高了。
为什么选择智能体，而不是脚本
我们本可以写一个定时任务。我们没有，原因只有一个：威胁的变化速度快于发布周期。 当攻击者改变战术时，我们用自然语言更新任务的指令，新逻辑在下一次运行时即刻生效——无需部署，无需数据库迁移，无需提工单。"规则"就是一段提示词，而提示词的修改速度与攻击者的变化速度一样快。
这才是真正的启示。Radar 是应对扣款时风险的正确工具，我们也在充分依赖它。但以试用为核心的业务存在一个结构性盲区，任何扣款时触发的工具都无法覆盖——解决方案不是一个更大的规则引擎，而是一个快速、可审计、始终在线的第二防护层，能以与威胁同等的速度重新编程。
给以试用为核心的团队的建议
- 梳理你的无扣款时刻。 任何用户在支付被评分之前就能获得价值的环节，都是扣款时工具看不到的盲区。
- 叠加，而非替换。 保留 Radar 守住前门，在其背后增加持续的注册后巡逻。
- 跨系统关联。 你的支付处理商和身份提供商各自掌握着半幅图景，欺诈就藏在两者的交集里。
- 按置信度分级行动，并记录每一次操作。 只在操作可逆且信号强烈时自动执行；其余情况交由人工处理。
- 以适应速度为优化目标。 在反欺诈领域，能最快改变规则的团队才能赢。
想了解一个始终在线的智能体能在你的技术栈中自动化哪些工作？探索 Zero。
注：Radar 数据均来自 Stripe 官方公布的数字（stripe.com/radar；"A primer on machine learning for fraud detection"）。损失数据反映的是注册后最初几小时内每个新注册账户的算力成本，基于上线前后匹配时间窗口的对比测量，已排除内部账户；上线后的样本数据仍处于早期阶段，随时间推移将趋于稳定。
