一组具有代表性的 B2B 线索发现情境，展示 AI 如何从典型业务交流中识别值得人工核实的销售机会。
主网上线前，RPC 一直报 429：这是不是换供应商的窗口
RPC 服务商销售看到项目方抱怨 429 时，怎样从调用方法、峰值吞吐、重试和多节点准备程度判断对方是真要换，还是只需要修客户端。
以下是一个典型场景演示，用于说明产品的判断逻辑，不代表真实客户案例、客户证言、合同、收入结果或转化数据。
01场景描述
02Signal 判断
03可信度与优先级
04人工下一步
判断时关注的线索
- 主网上线日期明确，429 已影响测试或交易提交
- 对方知道峰值 RPS、调用方法和当前套餐限制
- 已经尝试退避重试，仍在询问第二 RPC 或故障切换
周二 21:40，项目方的技术群里先贴了一张错误日志，五分钟后才有人问供应商：
429 Too Many Requests，主网发布还有 9 天。现在这个 RPC 高峰一上来就限流，想加一条备用，最好本周能压测。
对 RPC 服务商销售来说，这条消息比“你们节点多少钱”有价值。对方给了错误码、上线日、用途和测试动作。但 429 不自动等于原供应商不行。它只说明请求速度超过当前允许容量，根因可能在套餐，也可能在客户端把自己放大成了流量洪峰。
在 Telegram 技术群里，销售先保留错误发生前后的原话，不要只截出“想换供应商”一句。前面几条关于索引任务、批量查询或压测脚本的讨论，可能正好解释流量从哪里来。
先还原那十秒发生了什么
Alchemy 把吞吐量按 CU/s 计算，也就是每秒 Compute Units（计算单位）。不同 RPC 方法消耗的计算单位不同，因此同样是每秒 100 个请求，简单查余额和大范围拉日志的压力并不一样。
其文档说明，吞吐限制按账户汇总，并在 10 秒滚动窗口里评估。多个应用共用一个账户时，一个数据任务突然拉高用量，可能让交易服务一起收到 429。
QuickNode 则用 RPS（Requests Per Second，每秒请求数）描述套餐限制；超过计划允许的 RPS，同样返回 429。两家的计量口径不同，销售不能只问“每秒多少请求”，还要问“哪些方法占了峰值”。
最先要的不是整月平均值，而是出错前后十秒的四样东西：时间戳、RPC 方法、请求量、HTTP 或 JSON-RPC 错误体。如果对方能给出这些，技术交流可以继续。如果只有群里一句“节点炸了”，先别承诺迁移。
重试可能救场，也可能把 429 放大
Alchemy 建议客户端收到 429 后重试，并优先使用指数退避。做法是第一次失败等约 1 秒，下一次约 2 秒，再下一次约 4 秒，同时加入随机毫秒数，避免大量客户端在同一时刻再次冲击服务。
如果项目代码每次 429 都立即重试 5 次，原本 200 个失败请求可能瞬间变成更多请求。群里说“已经加了重试还是不行”，销售要追问用的是固定间隔还是指数退避，有没有读取 Retry-After，重试上限是多少。
这一步很关键。客户端重试写错时，换一家 RPC 也可能在下一次活动中复现。能先指出这个风险的销售，比直接发套餐表更像懂业务的人。
哪些证据说明他真的在找第二条 RPC
下面几种回答会把优先级明显抬高：
- 上线日已经定了，压测要在 48 小时内完成；
- 429 集中在
eth_getLogs、批量查询或某个索引任务，而不是所有请求； - 项目方已经做了指数退避，仍需要更高吞吐或独立账户；
- 他主动问 WebSocket、归档数据、地区节点或故障切换；
- 现有合同或套餐升级来不及完成。
eth_getLogs 用来读取一段区块范围内的事件日志。QuickNode 的错误参考写明，这类日志查询受区块范围限制，范围过大时应拆分请求。项目方如果连查询范围都没检查，先帮他缩小请求；如果已经拆分且上线峰值仍超过容量，再谈供应商替换。
压测不能只追一个“最高 RPS”
项目方说“本周能压测”，销售要继续问测试脚本是否接近上线流量。把所有请求换成最轻的查余额方法，再跑出很高 RPS，只能证明链路能接很多轻请求；它不能说明日志同步、交易提交和 WebSocket 订阅混在一起时会怎样。
一个更有用的压测可以分三段。第一段跑平时流量 10 到 15 分钟，看延迟和错误基线；第二段逐级提高到预计峰值，不要从零瞬间冲到最大；第三段故意让主端点失败，检查客户端是否真的切到备用端点，以及恢复后会不会来回切换。每段都记录方法占比、成功率、P95 延迟和 429 数量。P95 延迟表示 95% 的请求在这个时间以内完成，比一个容易被极端值带偏的平均数更能描述多数用户体验。
还要把读请求和写请求分开。查余额失败可以稍后重试，交易广播失败却可能让用户重复点击；如果两个端点都收到同一笔已签名交易，客户端也要能识别重复结果。销售不必在 Telegram 群里设计完整架构，但要确认项目方有负责客户端、索引器和发布流程的人参加测试。
最后约定“通过”条件。例如预计峰值是 800 RPS，就写清在真实方法组合下允许多少 429、P95 延迟上限是多少、连续运行多久，以及主端点断开后多少秒内完成切换。没有通过条件，供应商和项目方可能各拿一张漂亮截图，却无法决定是否上线。
一条能让技术同事愿意继续聊的回复
“可以安排备用 RPC 压测。先发一段脱敏的 429 样本：出错时间、方法、峰值 RPS、当前重试策略，以及 HTTP 还是 WebSocket。若主要是日志查询，请带区块范围；若多个 App 共用当前账户，也请分开统计。我们先复现容量问题，再确认是加吞吐、拆任务，还是需要独立第二节点。”
这段回复没有攻击竞品，也没有把 429 直接说成故障。它让对方知道测试需要什么，并能快速筛出有没有工程准备。
项目方的技术群在上线前会非常吵，错误日志、代码问题和供应商抱怨混在一起。TOP Prospect 可以把“429 + 上线日期 + 备用 RPC”这类组合从原话中挑出来，销售真正要做的，是把十秒内的调用还原清楚。