认识 Bumblebee：Agentic AI 在90秒以内标记风险商户

Source: Dev.to

如果你熟悉支付公司，你就知道其中的流程。风险专员每月手动审查成千上万的商户网站，检查是否存在风险信号：可疑的隐私政策、定价不匹配、可疑的社交媒体表现、异常的域名注册模式。

在 Razorpay，我们的风险运营团队每月进行 10,000 到 12,000 次手动网站审查，每次大约需要四分钟的人力。这样每月消耗 700 到 800 人工小时，且质量参差不齐，因为不同的专员对同一信号的解读会不同。

传统的欺诈检测方法要么是投入大量人力，要么是构建僵硬的规则引擎——一旦欺诈者改变手法，规则就会失效。我们需要更好的方案，既能随交易量的增长而扩展，又能随时间变得更聪明。

因此我们构建了 Agentic Risk，一个多代理 AI 系统，能够端到端自动化商户网站评估，同时保留过去需要人工专业判断的细微差别。

从最初的 n8n 原型到 AI 代理，再到当前的多代理架构，这段旅程揭示了在大规模构建可靠 AI 系统时的基本真理。

业务问题：手动审查跟不上速度

先来描述一下自动化前的风险运营是怎样的。当新商户在 Razorpay 注册，或我们的欺诈检测系统标记了已有商户时，一个案件会进入我们的 Risk Case Manager 系统。人工专员接手该案件，开始调查流程。

在一切顺利的情况下，这个过程需要四分钟，但实际上很少如此。网站结构各异，政策页面可能隐藏在奇怪的位置，域名信息服务的界面不统一，社交媒体账号也不一定显而易见。最糟糕的不是耗时，而是结果不一致。一个专员可能因为商户使用了通用的隐私政策而标记风险，而另一个专员则认为同样的政策是可以接受的。

我们每月还要为第三方显性内容筛查服务支付数千美元，但该服务每月仅产生约 50 条警报，精确率不足 10%。而且，它只捕获了一种特定风险，忽略了我们关心的其他数十种欺诈指标。

根本问题在于，我们拥有优秀的可观测性工具、结构化数据系统和经验丰富的风险分析师，但这些组件之间的“胶水”是人工劳动。要想扩展只能雇佣更多专员，这会导致更大的不一致、更高的成本，却没有提升检测速度或准确性。

第一期：n8n 原型——可视化编排的局限

我们先使用 n8n（可视化工作流自动化平台）快速原型并验证假设。几周内，我们就实现了一个工作概念验证，集成了 webhook 接收、商户元数据获取、通过多模态 AI 进行网站内容审查、域名查询、GST 丰富化、欺诈指标以及基于 LLM 的风险分析。

该原型验证了自动化的可行性，并帮助我们确定了完整的数据点集合。然而，n8n 很快暴露出根本限制：

• 分支爆炸——处理边缘情况会产生难以维护的 40 节点工作流，且逻辑重复。
• 可观测性缺口——调试失败节点时日志过于粗糙，痛苦不堪。
• 平台不稳定——HTTP 和合并操作表现出非确定性行为。

n8n 原型让我们认识到，生产级风险自动化需要代码优先的方式，配合完善的可观测性并能够直接使用 Python 库。

第二期：Python + ReAct 代理——更好的控制，新瓶颈出现

我们将系统重构为一个 Python Web 应用，配备 API 前端和任务工作者。这立刻解决了第一期的若干问题：原生 Python 库、带有 trace ID 的结构化日志、带重试逻辑的异常处理以及复杂的 NLP 预处理能力。

核心是一个单一的 ReAct 风格代理，它会迭代推理应调用哪些工具，执行它们，并将结果纳入上下文，直至生成结构化的风险评估。第二期实现了完整的可观测性、便捷的工具添加以及取代脆弱条件逻辑的动态行为。

但也出现了新的瓶颈：

• 令牌膨胀——代理在上下文窗口中累计了 50 KB 以上的 HTML 内容、域名数据和欺诈指标，频繁触达令牌上限。
• 顺序执行——即使工具之间没有依赖，也会一个接一个调用，导致随工具数量线性扩展。
• 温度混用——单一的 temperature 参数对探索（工具选择）和利用（最终评分）都不够理想。

第二期证明了代理编排是正确的方向，但单代理架构无法支撑成千上万并发评估。

第三期：多代理架构——专精带来优势

突破在于我们不再把欺诈检测视为单一 AI 任务，而是构建了一个 多代理协作系统。我们不让一个代理完成所有工作，而是将职责拆分给针对特定角色进行优化的专用代理：Planner（规划器）、Fetchers（抓取器）和 Analyzer（分析器）。

Planner 代理 接收商户案件，检查可用工具、系统健康状态和 API 配额，并生成执行计划。这不是僵硬的脚本，而是对要收集的信息、优先级、超时、令牌预算以及预期 schema 的结构化说明。Planner 能够确定性地执行业务规则（例如，对非印度商户跳过 GST 验证，对 B2B 商户降低社交媒体检查优先级），从而减少不必要的 API 调用，将资源聚焦在高信号检查上。

Data Fetcher 代理 并行运行，每个代理负责一种数据源或工具——网站抓取、WHOIS 查询、欺诈数据库查询、社交媒体指标、价格对比、政策验证等。关键是，抓取器在返回结果前会进行 本地数据裁剪，保持令牌使用量低，让下游的 Analyzer 能专注于综合分析，而不是处理原始海量数据。