Clay 每月 3.5 亿次 Agent：从 Demo 到生产的参考答案

3.5 亿次调用背后的工程现实

当大多数团队还在纠结”Agent 能不能用”的时候，Clay 的 GTM（Go-To-Market）Agent 基础设施已经在处理每月 3.5 亿次 Agent 调用和每周数万亿 tokens 的吞吐量。这个量级的系统不是靠一篇论文或一个开源框架就能搭建起来的——它背后是四个核心工程挑战的解决过程，每一个挑战都值得认真拆解。

第一个挑战是基础设施的可靠性。Agent 工作流与传统的请求-响应服务有本质区别：一个 Agent 调用可能持续几分钟甚至几十分钟，期间涉及多步推理、工具调用和外部 API 交互。如果执行到一半进程崩溃，所有中间状态都会丢失。Clay 的解决方案是持久化工作流执行——每个步骤完成后自动 checkpoint，即使节点宕机也能从断点恢复。他们的架构经历了从 AWS Lambda（无状态、超时限制严苛）到 ECS（有状态但不够持久）再到持久化工作流引擎的演进——这是一个典型的”从简单方案开始，在规模逼迫下逐步升级”的工程故事。

背压系统：用 TCP 拥塞控制的思想管理吞吐量

第二个挑战是吞吐量管理。同时服务数万个客户时，某些大客户的 Agent 调用量可能会挤占其他客户的资源。Clay 设计了一套背压系统，其核心思想借鉴了 TCP/IP 的拥塞控制算法——当系统负载接近上限时，不是简单地拒绝请求或无限排队，而是动态调整每个租户的调用速率，在保证客户公平性的前提下实现了 4 到 10 倍的吞吐量提升。

这套系统的巧妙之处在于它理解了 Agent 负载的特殊性：不同于 Web 请求的毫秒级响应，Agent 调用是长任务，排队延迟的感知被放大了。一个等待 30 秒的 API 调用和等待 30 秒的 Agent 响应是完全不同的体验——后者会让用户怀疑 Agent 是不是”卡住了”。背压系统通过平滑限制而非硬性拒绝，避免了这种糟糕的体验。

缓存、重试与成本：当每一分钱都乘以 3.5 亿

第三个挑战是成本控制。每月 3.5 亿次调用意味着任何微小的优化都会被巨量放大。Clay 的缓存策略可以将成本降低高达 70%——不是简单的响应缓存，而是对 Agent 推理链中的中间步骤进行语义缓存。当一个相似的查询到来时，可以复用之前的推理路径而不需要重新调用 LLM。限制重试次数同样至关重要：每次重试都会产生新的 token 成本，Clay 的做法是将重试策略与质量指标挂钩——只有当重试确实可能提升输出质量时才允许，否则宁可快速失败。

第四个挑战是质量保障。Clay 的质量体系由四个支柱构成：高质量的上下文（输入决定输出）、针对 GTM 场景调优的评估框架、离线和在线评估相结合、以及 Agent Builder 工具支持快速迭代。他们还在构建 “Audiences” 作为 Agent 记忆的基础层——让 Agent 不只是处理单次查询，而是持续积累对客户业务的理解。从 Demo 到 3.5 亿次月调用，Clay 的工程实践为每一个想将 Agent 投入生产环境的团队提供了一个宝贵的参考答案：Agent 的挑战从来不只是模型能力，更是基础设施、成本模型和质量体系的系统性工程。