当代理开始“有说服力地犯错”，监控软件的旧地图失效了

一个传统软件错误会留下清晰的痕迹：服务崩溃、网络调用失败、堆栈追踪指向某一行代码。但一个 AI 代理失败时，它可能只是安静地做错了事——给客户退了不该退的款、在数据库里写入了错误字段、或者把一次本应拒绝的请求执行得滴水不漏。没有异常日志，没有报错，系统状态一切正常。直到某个用户偶然发现，损失已经以代理的运行速度被放大到成百上千次。

这正是 Raindrop 试图占据的位置。这家旧金山公司把自己定义为“AI 代理可靠性公司”，产品形态上对标应用监控领域的 Sentry，但监控对象从确定性的代码执行变成了非确定性的代理行为。2026 年 9 月 17 日，Raindrop 宣布完成由 CRV 领投的 A 轮融资，累计融资额达到 5000 万美元。据 RuntimeWire 报道，本轮金额约为 3500 万美元，此前公司在 2025 年 12 月完成了一轮由 Lightspeed Venture Partners 领投的 1500 万美元种子轮。官方新闻稿未直接披露 A 轮单独金额，仅确认累计数字。

与融资同步发布的还有新产品 Simulations。这是一个把代理测试从“上线后发现问题”推向“上线前阻止问题”的尝试：在代理变更部署之前，用真实生产流量和既有测试用例回放变更后的行为，再对其结果运行异常检测。Raindrop 称，这能让 AI 工程师在合并代码之前看到“他们的变更会改变什么”。

字段 内容
公司 Raindrop
轮次 A 轮
金额 本轮约 3500 万美元（累计 5000 万美元；官方仅披露累计额）
投资方 CRV（领投）；Lightspeed Venture Partners、Y Combinator（跟投）；OpenAI、Anthropic、Thinking Machines 资深研究员（天使投资人）
总部 旧金山
创始人 Zubin Koticha（CEO）、Ben Hylak、Alexis Gauba
官网 https://www.raindrop.ai/

从 Sidekick 的失败里长出来的公司，卖的是“静默故障”的可见性

Raindrop 的起点不是一份市场研究报告，而是一个具体的产品失败。三位创始人——Zubin Koticha、Ben Hylak 和 Alexis Gauba——在 2023 年创立公司之前，正在构建一个名为 Sidekick 的编码代理和 VS Code 扩展。据 RuntimeWire 报道，这个产品能吸引付费用户，但团队缺乏一种有效手段来理解代理在部署后为什么会失败。传统应用监控能识别崩溃的服务或失败的网络调用，却无法捕捉一个代理完成了请求但结果错误、忘记了一条指令、陷入循环、或者执行了一个技术上合法但违背用户意图的动作。

这个经历构成了 Raindrop 的产品原点。公司进入 Y Combinator 2024 冬季批次，随后在 2025 年 12 月完成种子轮。种子轮投资方名单带有明显的开发者工具生态色彩：Figma Ventures、Vercel Ventures、Y Combinator，以及来自 Replit、Cognition、Framer、Speak、Notion 的创始人或高管。这意味着在 A 轮之前，Raindrop 的资本结构中已经嵌入了多家潜在客户和分发渠道的关系。

创始团队的履历也值得拆开来看。Koticha 和 Gauba 此前联合创立了 DeFi 期权平台 Opyn，该平台被 Coinbase 收购，据披露处理交易量超过 150 亿美元。Hylak 在 Apple 的 Human Interface 团队工作了四年，参与构建 visionOS。一个来自 DeFi 的创始人团队转向 AI 代理可靠性，这个路径本身说明了问题：DeFi 领域的智能合约漏洞和代理静默故障在结构上高度相似——两者都是在复杂、非确定性环境中，错误行为可以长时间不被发现，直到造成不可逆的损失。Raindrop 的官方新闻稿还提到，团队中包括在 Robinhood 发明欺诈 transformer 模型的工程师、在 Square 开创恶意异常检测的工程师，以及来自 Segment、Semgrep、Socket.dev 的安全工程师。这些背景指向同一个技术判断：代理故障本质上是一个检测问题，而不是传统的日志聚合问题。

监控生产轨迹是一回事，在变更上线前模拟未来是另一回事

Raindrop 的产品分为两个层次。第一层是生产环境监控：读取代理的执行轨迹，捕捉语义层面的异常——幻觉答案、工具误用、模型升级导致的行为变化。公司称其运行基于每个客户自身产品训练的小模型来读取这些轨迹，当行为发生偏移时，工程团队可以看到什么变了、什么时候开始的、影响了哪些用户，并附带数百个真实示例。Vercel 的 AI 工程师 Bani Singh 在新闻稿中提供了一个使用场景：当出现构建失败或代理陷入循环时，团队会在 Slack 中看到问题，并获取受影响用户数量和可深入查看的对话上下文。

第二层是 Simulations，这是本轮融资真正的产品叙事核心。传统 evals 的局限在于，它们只能检查团队预先想到要写下来的场景。Raindrop 的 Simulations 走的是另一条路：回放真实生产流量和既有测试用例，对代理的拟议变更运行异常检测，然后报告回归、成本变化、输出漂移和工具错误。据 RuntimeWire 报道，Simulations 会运行代理的真实代码，对其所依赖的服务——数据库、通信工具、支付系统、外部 API——创建有状态的合成副本，并生成形似客户环境的数据。

这里的技术难点在于，简单回放缓存的 API 响应是不够的。当一个代理可以写入数据库、发起退款、搜索一个不断变化的代码仓库、或者使用一条原始轨迹中不存在的新工具时，历史日志本身就存在缺口。Raindrop 用一个瑞士奶酪的比喻来解释这个问题：每一次真实的工具调用都是一个洞，揭示了那一刻世界的一个快照；你需要把足够多的洞叠在一起，才能重建代理周围的环境。但当一个全新工具被加入时，它在任何地方都没有历史轨迹，系统必须模拟出缺失的部分。

这个方向与前沿实验室的内部实践形成了呼应。据 Raindrop 引用的公开信息，OpenAI 已发表关于“部署模拟”的研究，用候选模型对去标识化的生产对话重新生成响应，以预测发布前的错误行为率；Anthropic 则构建合成宇宙来训练和压力测试自己的代理。Raindrop 的叙事是：把这些前沿实验室用于自身模型的测试流程，打包给每一个构建代理的团队。但需要明确的是，OpenAI 和 Anthropic 的研究是面向自身模型训练和评估的内部实践，Raindrop 的 Simulations 是一个面向第三方开发者的产品化尝试，两者在规模、数据可得性和验证标准上存在本质差异。Raindrop 能否真正复现“前沿实验室测试流程”的效果，目前没有独立第三方验证。

客户名单光鲜，但“财富 100 强”和“数十亿条轨迹”都未经审计

Raindrop 披露的客户名单包括 Vercel、Framer、Clay、Speak、AngelList、Tolan、Avoca、Replit，以及若干财富 100 强企业。Lightspeed 合伙人 Bucky Moore 在新闻稿中称“财富 100 强公司正在 Raindrop 上运行其代理流量”。公司还称每月处理数十亿条轨迹。

这些数字需要被放在正确的认识论位置上。它们全部来自公司自报或投资方声明，没有独立第三方审计或验证。本次采集材料未找到财富 100 强客户的具体数量，这些客户在 Raindrop 上运行的是核心生产流量还是试点项目也未披露。每月数十亿条轨迹这个指标，在没有收入数据、客单价或留存率的情况下，只能说明 Raindrop 确实有流量经过其系统，无法说明这些流量的商业价值或客户付费意愿。RuntimeWire 在报道中也明确标注这些运营指标“仍为公司自报”。

商业模式同样是一个未披露的变量。Raindrop 没有公开定价方式、收费结构或收入规模。对于一个声称服务财富 100 强企业的公司来说，这可能意味着两种截然不同的现实：要么是已经建立了可观的经常性收入，要么是仍处于以免费或低价换取标杆客户的阶段。从本轮资金用途——加速异常检测研究、扩展至更多企业、推进 Simulations，以及招聘机器学习工程和市场推广岗位——来看，Raindrop 仍处于从产品验证向商业化过渡的阶段。招聘 go-to-market 岗位本身就是一个信号：公司需要建立销售和客户成功能力，而不是仅靠产品自下而上的采用。

一个正在被资本和巨头同时盯上的赛道，Raindrop 的差异化窗口并不宽

AI 代理可观测性和可靠性正在快速形成一个独立品类，而这个品类的竞争格局在 Raindrop 完成 A 轮时已经相当拥挤。最直接的参照是 Braintrust，这家公司在 2026 年 2 月完成了由 ICONIQ 领投的 8000 万美元 B 轮融资，客户包括 Notion、Replit 和 Cloudflare。另一个信号来自并购市场：竞品 Galileo 被 Cisco 收购后并入 Splunk，从 2026 年 8 月起以“Splunk Agent Observability”的名义销售。这意味着大型基础设施厂商已经将代理监控视为值得直接买断的资产，而不是需要从零开始构建的能力。

Raindrop 的差异化主张是同时拥有生产监控和上线前模拟两个环节。RuntimeWire 的分析指出，这个闭环给了 Raindrop 比单纯的追踪仪表盘更强的位置：每一个生产故障都可以变成未来的测试用例，每一个拟议修复都可以对照用户实际交互方式来衡量。这个逻辑在纸面上成立，但它也意味着 Raindrop 必须同时在两个战场上竞争：在生产监控端对抗 Braintrust 和 Splunk Agent Observability，在测试和模拟端对抗尚未被明确定义的对手——可能是传统的 eval 平台向生产流量回放方向扩展，也可能是云厂商在自家代理开发工具链中内置类似能力。

一个更深层的竞争问题在于数据飞轮的壁垒。Raindrop 的 Simulations 依赖真实生产流量和客户环境数据来构建合成副本。这意味着产品的质量与客户使用 Raindrop 生产监控的深度直接相关。一个只使用 Simulations 而不使用 Raindrop 生产监控的客户，能否获得同等质量的模拟结果？反过来，一个已经在 Braintrust 或 Splunk 上建立了生产监控体系的客户，迁移到 Raindrop 的 Simulations 需要付出什么成本？这些问题的答案目前未披露。

把敏感生产轨迹放进第三方系统，是企业采用绕不开的摩擦点

Raindrop 的产品逻辑要求客户做一件在传统软件监控时代就存在阻力的事情：把生产环境的执行数据交给第三方系统。在 AI 代理语境下，这个问题的敏感度被放大了。代理轨迹中可能包含用户对话内容、支付信息、健康数据、数据库写入记录、外部 API 调用细节。Raindrop 的 Simulations 还需要为代理所依赖的服务创建有状态的合成副本，并生成形似客户环境的数据。这意味着 Raindrop 不仅能看到代理做了什么，还需要理解代理运行所依赖的底层系统结构。

RuntimeWire 在报道中直接点出了这个矛盾：Raindrop 的招聘计划——机器学习工程和 go-to-market 岗位——对应的是 Simulations 必须解决的两个问题：准确复现复杂的客户环境，以及说服企业将敏感生产轨迹放入另一个测试系统。对于财富 100 强企业而言，后者往往比前者更难。安全审查、数据驻留要求、供应商风险评估、采购周期，这些因素会显著拉长销售周期，并可能将 Simulations 的采用限制在非敏感工作负载上。Raindrop 未披露其是否已获得 SOC 2、ISO 27001 或其他安全认证，也未披露数据保留策略和隔离机制。

从已披露的信息看，Raindrop 的客户名单中既有 Vercel、Framer、Clay 这样的开发者工具和 AI 原生公司，也有未具名的财富 100 强企业。这个组合暗示了一种可能的采用路径：先在数据敏感度相对较低、技术接受度较高的开发者工具公司中验证产品，再向数据敏感度更高、采购流程更重的传统企业扩展。但这条路径的每一步都未被 Raindrop 公开描述，属于编辑从客户结构推断的可能策略，而非公司确认的路线图。

资金用途指向两个未解问题：模拟的保真度和商业化的速度

Raindrop 将本轮资金用于三个方向：加速异常检测研究、将产品扩展至更多企业、推进 Simulations。前两个方向是常规的研发和扩张投入，第三个方向才是决定这轮融资能否兑现其叙事的关键。

Simulations 目前处于研究预览或早期访问阶段，官方新闻稿称其为 research preview，RuntimeWire 则称其为 early access；Raindrop 称正式可用计划在未来一个月内推出。这个时间表意味着，在本轮融资宣布时，Raindrop 的核心新产品尚未进入正式商用状态。一个尚未 GA 的产品被作为 A 轮融资的核心叙事来讲述，这在创业公司融资中并不罕见，但它要求投资者和观察者把“Simulations 能做什么”和“Simulations 已经被验证能做什么”区分开来。目前公开的信息只支持前者。

从已披露的技术描述看，Simulations 的保真度取决于两个因素：合成副本对真实服务行为的还原程度，以及异常检测算法在模拟轨迹上识别回归的准确性。第一个因素在数据库和支付系统等有状态服务上尤其困难——一个合成数据库副本能否准确模拟真实数据库的约束、触发器、存储过程和并发行为？一个合成支付系统副本能否模拟失败模式、超时和部分成功状态？Raindrop 称其创建的是“有状态的合成副本”，但这个描述本身没有说明保真度的边界。第二个因素则取决于 Raindrop 的异常检测在多大程度上能区分“有意义的回归”和“模拟环境本身引入的噪声”。如果模拟环境的保真度不足，异常检测可能产生大量误报，反而增加工程团队的工作量。

从资本结构看，本轮由 CRV 领投，Lightspeed 和 Y Combinator 跟投，加上来自 OpenAI、Anthropic、Thinking Machines 的资深研究员作为天使投资人。这个组合的合理性在于：CRV 的 Reid Christian 在新闻稿中强调自己“花了十年支持开发者关键基础设施”，Lightspeed 的 Bucky Moore 则从种子轮开始押注。但天使投资人来自三家前沿 AI 实验室的研究员，这个细节值得注意。它可能意味着 Raindrop 的技术方向获得了前沿实验室研究人员的认可，也可能意味着这些研究员看到了 Raindrop 所处理的数据对自身研究的潜在价值。两者并不互斥，但公开材料没有提供进一步的信息来区分这两种可能性。

代理可靠性成为独立品类的底层逻辑，以及它可能不成立的条件

Raindrop 的融资故事建立在一个更大的行业判断之上：AI 代理的可靠性问题正在成为一个独立的软件品类，而不是现有 APM 或日志工具的一个功能扩展。这个判断有一些数据支撑。METR 研究发现，代理可独立完成的任务时长大约每七个月翻倍，单次运行可持续数天并涉及数千次工具调用。当代理的运行时长和工具调用数量以这种速度增长时，人工审查每一条轨迹在经济学上变得不可行，自动化检测从“锦上添花”变成“必需基础设施”。

但“代理可靠性成为独立品类”这个判断有一个隐含前提：代理的部署规模和自主程度会持续增长到足以支撑一个独立的监控和测试工具市场。如果代理的实际部署在中期内仍然局限于低风险、有人工监督的场景，那么对专门的代理可靠性工具的需求可能被现有的 APM 平台、日志工具和人工审查流程所吸收。Cisco 收购 Galileo 并将其并入 Splunk 的路径，恰恰说明了一种相反的整合逻辑：代理监控可能不会长期作为一个独立品类存在，而是被吸收进更大的可观测性平台中。Raindrop 的独立存在，取决于它能否在整合发生之前建立起足够强的产品壁垒和客户锁定。

从已披露的客户结构和产品形态看，Raindrop 的壁垒可能来自数据飞轮：生产监控积累的轨迹数据越多，Simulations 的模拟保真度和异常检测准确性越高，客户越倾向于同时使用两个产品。但这个飞轮的每一环都尚未被独立验证。生产监控的轨迹数据量（每月数十亿条）是公司自报的；Simulations 的保真度没有第三方评估；客户同时使用两个产品的比例未披露。如果这个飞轮在现实中运转得比叙事中慢，Raindrop 面对 Braintrust 和 Splunk Agent Observability 的竞争时，差异化优势可能比看起来更薄。

还有一个更根本的待验证假设：代理故障的“静默性”是否真的构成了一个与传统软件故障足够不同的检测问题。Raindrop 的整个产品逻辑建立在这个判断之上——传统监控工具无法捕捉代理的语义错误，因此需要专门的代理可靠性平台。但如果传统 APM 厂商通过在现有追踪和日志能力之上叠加基于 LLM 的语义分析来缩小这个差距，Raindrop 的技术护城河可能比其叙事所暗示的更浅。目前没有公开信息表明传统 APM 厂商在这方面的进展速度，但 Cisco/Splunk 的收购动作已经表明它们不会坐视这个市场被独立玩家占据。

验证边界与可复核指标

本文涉及的“首个、唯一、最大、领先”、订单、出货、性能等表述，如无另行说明，均是公司、创始人或投资方在现有公开材料中的披露口径；RecodeX未在本次采集材料中找到独立审计或第三方测试结论，因而不将其视为已经独立确认的事实。文中的产业协同、竞争位置和商业路径属于基于已披露产品与融资用途的编辑分析，不代表相关结果已经实现。

  • 技术侧应核验第三方测试条件、样本规模、良率、稳定性及与可比方案一致口径的结果；
  • 商业侧应核验去重后的付费客户、可执行合同、收入确认、复购率以及订单转化；
  • 资本与产业协同应以工商股权、关联交易、联合开发、采购或量产文件为准。

RecodeX 极客视：Raindrop 的 A 轮融资真正的赌注不是“代理会失败”——这已经是事实——而是“代理失败需要一套独立的检测和模拟基础设施，而不是现有监控工具的一个补丁”。这个赌注的成立条件比融资新闻稿所暗示的更苛刻：Simulations 需要在未来一个月内从研究预览走向可验证的正式产品，财富 100 强客户需要从“运行流量”走向“为两个产品付费”，而 Raindrop 需要在 Cisco/Splunk 和 Braintrust 的夹击下证明数据飞轮的转速足够快。在代理可靠性这个品类里，资本已经投下了信任票，但产品验证的时间窗口正在以代理运行的速度缩短。