Klarent 切入的是 AI 代码生成后测试能力跟不上的环节。当模型写得越来越快,人类审不过来,传统测试脚本的维护速度完全跟不上代码膨胀的节奏。谁来验证这些代码本身,就从一个工程效率问题变成了企业信任问题。在 AI 智能体开始批量产出代码的背景下,测试环节的缺位可能意味着企业要么放慢 AI 采用速度,要么在未经验证的代码上承担业务风险。Klarent 试图把这个问题重新拉回软件交付的中心位置。

苏黎世初创公司 Klarent 试图把这个被忽视的环节重新放回软件交付的中心。2026 年 10 月,这家前身为 fore ai 的公司宣布完成 713 万欧元种子轮融资,由伦敦 Mosaic Ventures 领投,Moonfire Ventures 以及多位天使投资人参与,其中包括谷歌前总监 Jürgen Galler、Harris Barton 和 AngelInvest Ventures。公司称,这笔资金将用于进入美国市场、扩充工程团队、扩展 Web 与移动端测试能力,并推进与银行和保险公司的合作。从资金用途的分布看,Klarent 在种子轮同时押注地理扩张、产品线延伸和垂直行业渗透,这意味着其商业验证节奏可能比一般欧洲种子期企业软件公司更快。

Klarent 的切入点并不复杂:让大语言模型负责写测试代码,但绝不让模型直接执行测试。测试代码一旦生成,就以确定性、可重复的方式运行,顶部再叠加一层人工验证。这个被公司称为“确定性自主”的架构,试图在 AI 的灵活性与生产工程所需的严谨性之间找到一条中间路径。该架构的核心价值在于把 AI 的不确定性限制在生成环节,而把执行环节留在传统软件工程可以审计、可以复现的框架内。对于企业客户而言,这种边界划分可能比单纯的测试效率提升更具说服力。

字段 内容
公司 Klarent(前身为 fore ai)
轮次 种子轮
金额 713 万欧元
投资方 Mosaic Ventures(领投)、Moonfire Ventures、Jürgen Galler、Harris Barton、AngelInvest Ventures
总部 苏黎世
创始人 Asheem Panakkat(CEO)、Momchil Ivanov(CTO)
官网 https://klarent.ai

把 AI 限制在“写测试”这一步,是产品选择也是信任声明

Klarent 的产品逻辑有一个明确的边界:大语言模型只参与测试代码的编写,不参与测试的执行。据公司披露,测试代码生成后以确定性、可重复的方式运行,而不是依赖 AI 直接运行测试。这意味着同一段测试代码在相同输入下应当产生相同结果,避免了模型推理过程中可能出现的随机性和不可复现问题。在软件测试场景中,可复现性不是技术洁癖,而是缺陷定位的前提:如果一次测试失败无法被稳定重现,工程团队就无法判断问题出在产品代码、测试代码还是模型推理本身。

这一选择直接回应了企业客户对 AI 测试工具的核心顾虑。如果让模型既写测试又跑测试,客户很难区分一次测试失败是产品缺陷还是模型幻觉。Klarent 的做法是把 AI 的不确定性限制在生成环节,执行环节则回到传统软件工程的确定性框架中。公司称平台顶部设有人工参与验证层,客户只为已验证的结果付费;该商业模式描述来自公司披露,尚无独立第三方验证。这个“human-in-the-loop”设计不仅是质量控制手段,也是一种商业承诺:平台输出的不是未经筛选的 AI 结果,而是经过人工确认的验证结论。从采购视角看,这种承诺可能降低企业引入 AI 测试工具时的决策阻力,因为它把“AI 可能出错”的问题转化为“人工确认后才计费”的机制。

从产业链角度看,这种设计让 Klarent 的产品更接近传统测试自动化平台的替代品,而不是一个纯粹的 AI 测试工具。传统测试自动化平台需要人工编写和维护测试脚本,成本高且容易随产品迭代而失效。Klarent 试图用 LLM 降低测试代码的编写成本,同时用确定性执行保持结果的可信度。但这也意味着它的能力上限部分取决于 LLM 生成测试代码的质量——如果生成的测试覆盖不到关键业务路径,确定性执行本身并不能弥补测试设计的缺陷。换句话说,确定性解决的是“跑得稳”,而不是“测得对”。这两者之间的差距,可能决定 Klarent 在企业测试体系中的实际定位:是替代现有测试脚本的维护工作,还是只作为补充性的测试生成工具。

从 Google 的反馈循环问题出发,但客户验证还停留在欧洲

Klarent 的创始团队背景以两位前谷歌工程师为主。据 EU-Startups 报道,CEO Asheem Panakkat 在谷歌工作超过十年,领导过 Shopping 和 Lens 相关团队;CTO Momchil Ivanov 曾任 Staff Software Engineer,专注信息检索。两人在谷歌期间观察到 LLM 能力快速提升与软件产出量即将爆发这两个趋势同时到来,而他们反复追问的问题是反馈循环:如何让编写代码的 AI 智能体保持诚实。这个问题的实质是,当代码生成速度超过人类审查速度时,传统的代码审查和测试反馈机制可能失效,AI 生成的代码将在缺乏有效验证的情况下进入生产环境。

Panakkat 在融资报道中表示,团队最初做的是 LLM 的 evals,后来意识到更大的机会在 QA 本身。这个转变的逻辑是:如果 AI 将越来越多地编写世界上的代码,测试就不再是成本中心,而是决定这些代码是否可信的环节。Mosaic Ventures 合伙人 Chandar Lal 认为,随着 AI 代码生成加速,QA 将成为关键瓶颈;他称,说服该机构投资的关键是团队对确定性的坚持——“用 AI 写测试,而不是用 AI 跑测试”。从投资逻辑看,Mosaic Ventures 押注的不是一个测试工具的功能改进,而是 AI 代码生成产业链中一个尚未被充分占位的验证层。但这个判断能否成立,取决于企业是否真的愿意为独立的 AI 测试平台单独付费,而不是把测试能力并入现有的 AI 开发平台或自建工具链。

不过,从已披露的客户名单看,Klarent 的商业验证仍集中在欧洲市场。公司披露的欧洲客户包括 JD Sports、NZZ 和 Sixt。在 JD Sports 的案例中,公司称其 AI 智能体自动化了电商流程中的多系统工作流,公司称该零售商表示其自有团队无法复制这一自动化,该表述来自公司披露,尚无独立第三方验证。JD Sports 作为大型零售商的电商系统涉及订单、库存、支付、物流等多个环节,跨系统测试的复杂度确实高于单一应用测试,但公司未披露具体覆盖的系统数量、测试用例规模或自动化前后的效率对比数据。缺乏这些指标,外部很难判断“自有团队无法复制”究竟指向技术门槛、工程资源限制,还是特定历史条件下的组织能力缺口。

金融服务是公司明确要推进的方向。据公司披露,其正在与银行和保险公司合作,理由是这些行业“软件发布失败的代价可能高得惊人”。这一判断在行业逻辑上成立:金融行业的合规要求和系统耦合度使得测试失败的成本远高于一般互联网产品。一次支付系统回归测试的遗漏,可能触发监管问询、资金差错甚至客户信任危机。但公司尚未披露任何金融客户名称或合作阶段,这一方向的商业化进度仍待观察。从电商到金融的跨度,不只是客户行业的变化,还涉及测试场景、合规要求和部署模式的系统性差异。

种子轮 713 万欧元,资本结构简单但扩张节奏激进

713 万欧元种子轮在欧洲企业软件领域属于中等规模,但缺乏同口径可比数据。领投方 Mosaic Ventures 是一家伦敦早期基金,以投资欧洲技术公司为主;Moonfire Ventures 同样是欧洲活跃的种子阶段基金。天使投资人中,Jürgen Galler 的谷歌背景与创始团队经历形成呼应,但投资方未披露任何一位天使投资人的具体投资金额或参与条件。从资本结构看,本轮没有出现美国基金或战略投资方,这意味着 Klarent 在进入美国市场时,可能需要在后续轮次中引入具备美国企业软件渠道资源的资本,或者完全依靠自有销售团队从零建立客户关系。

这笔资金的使用方向透露出一个信号:Klarent 在种子轮就计划进入美国市场。对于一家总部在苏黎世、客户集中在欧洲的初创公司来说,这是一个激进的节奏。从资金规模看,713 万欧元能否支撑跨大西洋扩张取决于美国团队规模与销售周期,目前缺乏成本基准。美国企业软件市场的销售成本通常高于欧洲,尤其是在测试工具这一品类中,买家对安全认证、合规支持和本地化服务的要求可能更高。如果 Klarent 选择在美东或硅谷建立销售团队,仅人员成本就可能快速消耗本轮融资的相当比例。

另一个值得注意的细节是,公司未披露本轮融资的估值与股权条款。种子轮融资中,估值和股权稀释比例是判断创始团队谈判能力和投资人信心的重要指标,但这些信息均未公开。本次采集材料未披露产品细节的官方技术文档,外部无法通过官方渠道核实具体实现。在缺乏估值信息的情况下,外部只能从投资方组合和资金用途推断本轮的性质:这是一轮以产品扩张和市场进入为导向的融资,而非单纯的团队搭建或概念验证。这也意味着投资人对 Klarent 的期望可能已经越过“验证产品可行性”阶段,直接进入“验证规模化路径”阶段。

“确定性自主”解决了执行问题,但测试设计仍是瓶颈

如前所述,确定性执行与人工验证层的组合解决了一个真实问题:AI 直接执行测试时的不可复现性。但软件测试的瓶颈从来不只是执行环节。测试代码的质量取决于测试设计——哪些场景需要覆盖、边界条件如何定义、回归测试的优先级如何排序。如果 LLM 生成的测试代码只覆盖了表面路径,确定性执行只会让不完整的测试跑得更快、更稳定,而不会让产品更可靠。在关键业务系统中,测试覆盖率的缺失可能比测试执行的不稳定更危险,因为它会制造一种“测试已通过”的虚假安全感。

从已披露的信息看,Klarent 尚未说明其平台如何评估测试覆盖率、如何处理测试代码的维护更新、以及人工验证层的工作量有多大。人工验证层是商业模式的支点——客户只为已验证的结果付费——但这也意味着公司的毛利率与人工成本直接挂钩。如果验证层需要大量人工介入,规模化的边际成本可能高于纯软件产品;如果验证层只是形式上的确认,客户付费意愿又会下降。这个平衡点尚未被披露。更进一步,人工验证层的存在可能限制 Klarent 的扩张速度:每增加一个客户,验证工作量是否线性增长?验证人员是否需要理解客户的业务逻辑?这些问题的答案直接关系到公司能否在保持“已验证结果”承诺的同时实现规模化。

另一个待验证的假设是跨系统测试的通用性。JD Sports 案例中的多系统工作流自动化是 Klarent 的核心卖点之一,但电商系统的测试场景与银行核心系统、保险理赔系统差异巨大。公司称正在推进金融服务领域,但未披露其平台是否已经适配金融行业的合规测试要求、数据隔离标准或审计追踪能力。从电商到金融的跨行业扩展,需要的可能不只是销售团队,还有产品架构层面的调整。金融客户的测试环境通常要求更严格的变更管理、更细粒度的权限控制和更完整的审计日志,这些能力如果不能在平台层原生支持,就可能需要大量定制化开发,进而拖累交付效率。

竞争格局模糊,但替代方案清晰存在

以下竞争维度分析为编辑分析,基于公开产品类别,不代表公司披露信息。来源未披露具体竞争对手,无法进行同口径比较。但从产品形态看,Klarent 面临至少三类替代方案:传统测试自动化框架、AI 原生测试工具,以及企业自建的内部测试平台。这三类方案在成本结构、技术门槛和企业既有投入上各不相同,Klarent 需要同时应对来自低端开源方案和高端自建方案的挤压。

传统测试自动化框架如 Playwright、Cypress、Selenium 是开源或低成本方案,企业已有大量存量测试脚本和工程实践。Klarent 的价值主张是用 LLM 降低测试代码编写成本,同时用确定性执行与人工验证层保持结果可信度。但企业是否愿意将现有测试资产迁移到新平台,取决于迁移成本和平台兼容性。本次采集材料未涉及平台与现有测试脚本及 CI/CD 工具链的兼容性信息。如果 Klarent 无法与主流 CI/CD 平台和测试框架无缝集成,企业可能需要维护两套测试体系,这会显著削弱其价值主张。

企业自建方案是另一个常被忽视的替代品。JD Sports 案例中,公司称该零售商表示其自有团队无法复制这一自动化,该表述来自公司披露,尚无独立第三方验证。但大型企业的工程团队通常有能力基于开源框架和内部 LLM 工具搭建测试自动化系统。Klarent 需要证明其平台在测试设计、跨系统协调和验证效率上的积累,足以让企业放弃自建路径。在 AI 工具快速普及的背景下,企业自建测试智能体的门槛正在降低,Klarent 的差异化可能不在于“能不能做”,而在于“能不能在更短时间内做到企业级可信”。这个差异化需要更具体的产品能力和客户证据来支撑。

投资逻辑建立在 QA 瓶颈论上,但时间窗口并不宽裕

Mosaic Ventures 的投资逻辑清晰:来源称 AI 使代码生成速度超过测试能力,QA 将成为关键瓶颈。但“QA 成为瓶颈”与“企业愿意为 AI 测试平台付费”之间,还隔着预算归属、采购流程和效果验证三重门。QA 预算在企业 IT 支出中通常不占主导地位,测试工具的采购决策可能分散在工程团队、质量保障团队和平台团队之间。Klarent 需要明确自己的产品究竟卖给谁:是工程负责人、QA 负责人,还是更上层的技术决策者。不同的买家对应不同的价值叙事和销售周期。

Klarent 的“只为已验证结果付费”模式试图降低采购门槛,但如前所述,估值与单位经济学信息未披露。如果客户按验证结果付费,公司需要定义清楚“已验证结果”的计量标准——是按测试用例数量、按发现的缺陷数量,还是按覆盖的系统数量?这些商业细节均未披露。计量标准的模糊可能导致销售过程中的定价争议,也可能影响收入的确认方式。对于一家计划进入美国市场的企业软件公司来说,清晰的定价和计量体系是规模化销售的前提。

公司未披露现有团队规模与历史融资情况,外部无法判断其烧钱速率和跑道长度。如果美国市场拓展需要独立的销售和市场团队,资金消耗速度会更快。种子轮融资通常需要支撑 18 到 24 个月的运营,但 Klarent 同时推进美国市场、移动端扩展和金融服务三条线,每条线都需要产品、工程和销售资源的投入。在没有后续融资或收入数据的情况下,这种多线并进的策略可能带来资源分散的风险。

风险不在技术路线,而在验证节奏与规模化路径

公司未披露客户数量、合同金额、续约率和收入规模,因此无法判断验证节奏与扩张速度是否匹配。公司披露的欧洲客户包括 JD Sports、NZZ 和 Sixt,但仅有客户名称,缺乏可复核的商业指标。在缺乏收入数据的情况下,进入美国市场和推进金融服务更像是并行下注,而非基于已验证商业模型的自然延伸。对于种子期公司而言,并行下注本身并不罕见,但前提是核心市场的单位经济学已经清晰。目前 Klarent 尚未公开任何能够证明欧洲客户商业价值的指标。

金融服务领域尤其值得关注。银行和保险公司的软件测试涉及严格的合规审计、数据驻留要求和变更管理流程。Klarent 的平台如果需要在客户环境中部署,销售周期和集成成本将远高于电商客户。如前所述,金融服务合作仍处公司披露阶段。金融客户的采购流程通常涉及安全审查、合规评估和多轮技术验证,这些环节可能显著拉长从接触到签约的时间。如果 Klarent 在种子轮阶段同时推进多个金融客户的概念验证,工程团队可能被拖入大量定制化集成工作,反而影响产品化进度。

另一个结构性风险是 LLM 生成测试代码的版权和安全性问题。企业客户可能担心模型生成的测试代码包含敏感业务逻辑泄露、或生成代码本身存在安全漏洞。本次采集材料未涉及模型来源、数据隔离或安全认证信息。对于金融客户而言,这些问题的答案可能比测试效率提升更重要。如果 Klarent 使用第三方 LLM API,客户数据是否会经过外部模型提供商?生成的测试代码是否会包含客户系统的内部接口信息?这些安全和合规问题如果不能在早期得到明确回答,可能成为金融行业拓展的实质性障碍。

从已披露的“确定性自主”架构看,Klarent 的产品方向与 AI 代码生成时代的真实需求是吻合的。但方向正确不意味着商业成功。公司需要在资金耗尽前证明三件事:欧洲客户能规模化续约、美国市场能找到可复制的销售模式、金融服务领域的合规适配不需要推倒重来。这三件事中的任何一件失败,都可能让 713 万欧元的种子轮显得不够用。更关键的是,这三件事之间存在资源竞争关系,Klarent 需要在有限的时间和资金内做出优先级选择,而目前公开信息尚不足以判断其选择是否清晰。

验证边界与可复核指标

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

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

RecodeX 极客视:Klarent 把 AI 限制在“写测试”这一步,用确定性执行和人工验证来换取企业信任,这个架构选择在逻辑上自洽,也切中了 AI 代码生成带来的真实瓶颈。但种子轮就同时押注美国市场、移动端扩展和金融服务,资源分配的激进程度超过了已披露的商业验证。真正的考验不是技术路线能否跑通,而是公司能否在资金耗尽前,把三个欧洲客户的故事变成一个可复制的规模化路径。确定性自主解决了“跑得稳”的问题,但“测得对”和“卖得动”仍然没有答案。

信息来源

本文在采集与核验阶段引用了以下公开来源,按站点去重列出;来源内容归原发布方所有,其口径不代表 RecodeX 的核实结论。