一个 AI = 1000 个客服？2100万美元融资，丹麦AI创业公司Parahelp凭什么让 Perplexity、Replit 抢着用？

你有没有想过,客户支持这件事可能彻底变了?当 Perplexity、Replit、Framer 这些全球顶尖的 AI 公司都在使用同一个客户支持系统时,我开始意识到这个领域正在发生一场革命。更让我震惊的是,这个系统不仅仅是回答用户问题,它还被授权直接处理退款、访问公司的 Stripe 账户、在没有任何人工监督的情况下移动资金。这听起来像科幻小说,但这正是 Parahelp 正在做的事情。

最近,这家由两位丹麦年轻创始人打造的公司宣布完成了 1800 万美元的 A 轮融资,由 Alt Capital 的 Jack Altman 领投。加上此前 320 万美元的种子轮,Parahelp 总共融资超过 2100 万美元。更有意思的是,他们的客户流失率为零。是的,你没看错,零流失率。在 SaaS 领域,这几乎是不可能完成的任务。这让我非常好奇:他们到底做对了什么?为什么那些本身就擅长构建 AI 系统的顶级 AI 公司,会选择使用 Parahelp 而不是自己开发?

从音乐 App 到 NFT 投资平台的探索之路

我一直相信，伟大的创业故事往往始于一些看似不相关的早期探索。Anker 和 Mads 的故事也不例外。Anker 在丹麦一个只有 200 人的小村庄长大，那里除了户外活动，几乎没有其他娱乐方式，这反而让他很早就开始接触编程。而 Mads 则在中学时期就创办了自己的时尚公司，负责设计和营销。两人在高中时期通过一个朋友相识，共同创立了一个面向丹麦年轻创业者的组织，将对创业感兴趣的高中生聚集在一起。这个决定改变了他们的人生轨迹。

在丹麦，创业文化远不如硅谷那样浓厚。事实上，丹麦语中甚至没有"创业公司"这个词汇，人们只会问"你的项目进展如何"。这种文化差异让 Anker 和Mads 在学校里显得格格不入。一旦他们发现了创业和编程的魅力，就很难再集中精力上课。他们开始合作开发各种消费类应用。Anker 负责编程，Mads 则负责设计和产品，这种分工一直延续到今天。

他们开发的第一批产品包括一个音乐应用，用户可以在活动现场实时创建协作播放列表。为了实现这个功能，他们甚至逆向工程了 Spotify 的 API。他们还开发了一个活动发现应用，虽然这个想法并不新颖，但却被附近所有高中的学生使用。这些早期项目虽然没有带来商业成功，但培养了他们对打造优秀产品的热爱，也让他们积累了宝贵的技术和产品经验。

在高中最后一年，Anker 已经开始学习 Solidity 编程，当 NFT 市场开始爆发时，他们的朋友们都在询问如何购买 NFT，但流程太过复杂。虽然他们自己并不热衷于交易 NFT，但他们看到了一个有趣的产品机会：让非技术用户也能轻松购买 NFT。这个想法最终成为了他们的第一个正式创业项目。

在 Anker 高中毕业后，Mads 还有一年才毕业，他们搬进了哥本哈根一家麦当劳楼上的一个小办公室。Anker 甚至在那里睡了一段时间。他们开发了一个投资应用，成为第一家在欧洲与 Stripe 合作的公司。经过多次尝试说服 Stripe 理解他们的系统运作方式后，他们终于实现了用户可以通过 Apple Pay 购买 NFT，而他们的系统会处理所有技术细节。

但他们很快就学到了残酷的一课。当他们终于通过监管审核并推出产品时，NFT 市场已经从数百万用户萎缩到只剩几千人。更糟糕的是，他们此前并没有真正与用户交流。当他们开始与剩余的用户对话时，发现这些用户只关心市场涨跌，对他们精心打造的产品功能并不感兴趣。他们无法控制市场走势，这意味着他们的产品前景黯淡。

两年的疯狂 Pivot 之旅

面对失败，Anker 和 Mads 展现出了超越年龄的成熟。他们没有固守原有想法，而是进入了全面 Pivot 模式。我认为这种快速调整方向的能力，是优秀创始人最重要的特质之一。很多创业者会因为沉没成本而继续投入到一个明显不可行的方向上，但 Anker 和 Mads 从一开始就建立了一套系统化的 Pivot 方法。

他们受到另一家 YC 公司 Slope 的启发，采用了一种"三周冲刺"的方法。每个新想法只投入三周时间去尝试，这样即使失败了，沉没成本也不会太大，同时也能让他们有勇气尝试那些看起来可能很愚蠢的想法。如果某个想法最终没有继续推进，他们会写一份事后总结，强迫自己真正去构建和销售一些东西，而不是停留在空想阶段。

在这个过程中，他们第一次来到旧金山，访问了一些黑客屋，并立刻爱上了硅谷的创业氛围。2024 年 1 月，当时 Anker 21 岁，Mads 只有 18 岁，他们搬进了伯克利的一个黑客屋。在那里，他们遇到了 same.dev 的团队，这些人说服他们申请 Y Combinator。这个决定成为了他们创业旅程的转折点。

在黑客屋里，他们开始探索 B2B 领域，最初开发了一个 co-pilot 工具并成功进入 YC。但在 YC 的 retreat 期间，他们发现虽然有客户在使用他们的产品，但客户并不真正满意，销售周期也很长，因为人们感受不到迫切的痛点。就在这时，Claude Sonnet 3.5 发布了，这个模型的出现让半可靠的 agentic 变革成为可能，至少在他们的测试中是这样。

这促使他们在 YC 批次中期做出了一个大胆的决定：全力投入端到端解决支持工单的方向。Mads 在一周内发送了 700 封个性化的冷邮件。他们的早期客户，包括 Captions 和 Perplexity，都是通过冷邮件获得的，因为他们在硅谷几乎没有任何人脉。他们向所有他们认为很酷的公司发送邮件，然后很快意识到，如果专注于软件创业公司，他们可以打造一个更好的产品。这些公司有共同的痛点：都需要与各种工具深度集成，都面临着快速增长带来的知识管理问题。

Parahelp 的核心价值：不只是回答问题，而是解决问题

当我深入了解 Parahelp 后，发现它与市场上其他 AI 客服解决方案有本质区别。大多数 AI 客服系统只是回答问题，但 Parahelp 的 AI agent 会实际采取行动来解决客户的问题。这种区别看似微小，实则是一个巨大的跨越。

举个最典型的例子：退款请求。当客户提出退款请求时，传统的 AI 客服可能会告诉客户退款政策是什么，或者说"我会帮您联系相关部门"。但 Parahelp 的做法完全不同。它会首先理解公司设定的退款标准，判断这个客户是否符合退款条件。如果符合，Parahelp 会直接连接到公司的 Stripe 账户，处理退款操作。没错，Parahelp 实际上连接了公司的银行账户，被授权在无需任何人工监督的情况下代表公司转移资金。

这听起来可能有些激进，但 Parahelp 在这方面做了充分的考虑。对于敏感操作，他们设置了 Slack 审批流程。AI agent 会说"我刚刚请求了一位团队成员审查这个问题，稍后会回复您"。但因为他们把 agent 设计成像真实人类客服那样工作，agent 知道有一个待审批的请求正在处理中，所以它会继续与客户聊天，回答其他问题。当计费经理在 Slack 中批准操作后，agent 就会执行必要的操作并跟进客户。

更有意思的是，对于某些客户的某些计费操作，Parahelp 在一段时间内达到了 99% 的成功率后，甚至不再需要人工审批。这种从需要监督到完全自主的演进，就像人类客服的成长路径：从处理小客户开始，随着经验积累和可靠性提升，逐渐被信任处理更重要的客户。

Parahelp 的客户名单让我印象深刻：Perplexity、Replit、HeyGen、Framer、11 Labs、Photoroom 等等，几乎都是最快速发展的 AI 原生公司。Perplexity 竟然是 Parahelp 的第二个客户，这发生在他们 YC 批次期间。一些客户甚至已经授权 Parahelp 处理拥有上千个席位的企业客户，这可能是一个六位数的大客户。让 AI agent 与这样重要的客户对话，显然需要极高的信任度。

我特别好奇一点：这些 AI 原生公司本身都在构建 agentic 系统，为什么他们不自己开发客户支持 AI，而是选择使用 Parahelp？Anker 和 Mads 给出的答案很有说服力。大多数公司都会尝试自己构建或启用现有工单系统中的默认 AI 功能，比如 Intercom、Zendesk 或 Front 自带的 AI。但这些系统在开始时效果很好，处理那些不需要工具调用的简单问题没有问题。但随着时间推移，问题就暴露出来了。

这些系统并不是为快速增长的软件公司的知识管理而构建的。它们默认不会连接到公司的所有知识源：Linear 中的技术信息、Notion 中的文档、Retool 中的内部工具、Slack 中的讨论。而这些信息每天都在变化。由于没有人真正维护这些 AI 系统，它们的解决率会逐渐下降。更糟糕的是，客户可能会因为过时的信息而获得糟糕的体验。没有内置的审查系统来监控 AI 的表现。

工具调用听起来可能很简单，很多其他 AI 支持解决方案也声称支持工具调用。但深入了解后会发现，工具调用远不止是调用 API 端点那么简单。它需要适当的护栏机制，需要建立完善的评估系统，确保当你能访问 Stripe 这样的敏感工具时，它应该始终被正确调用。Parahelp 在工程方面花费最多时间的就是建立评估系统：如何运行评估，如何持续运行评估以确保系统没有退化。

从手动监控到自动化评估的演进

Parahelp 的成长历程让我看到了 AI agent 公司在扩展过程中必然面临的挑战。在最开始，他们接入了第一个客户 Captions AI，一周后又接入了 Perplexity AI。这一切都发生在他们 Pivot 后的四周内。由于一切都还不确定，他们必须手动观察每一个工单处理过程，试图弄清楚如何运行适当的评估，以确保 agent 朝着正确的方向发展。

但随着客户数量增长，这种方式显然无法持续。现在 Parahelp 每天处理数千个支持工单和查询。他们根本不可能手动监控这些。所以他们必须建立自动化系统。我认为这是所有 agentic AI 公司都会面临的共同挑战：如何从手动监督过渡到自动化评估和优化。

更大的挑战还在于，客户的需求总是在变化。每当客户推出新功能、修复 Bug 或更新政策时，Parahelp 的 agent 需要立即了解这些变化。这就像是一个移动的靶子，你需要不断调整才能保持准确性。大多数尝试自建系统的公司会发现，即使他们擅长 AI 技术，也很难维持评估的持续通过、避免系统退化，以及时刻与产品、工程、营销和销售团队保持同步。

这就是为什么 Parahelp 能够成功的关键原因之一。他们不仅构建了一个能解决复杂问题的 AI agent，还构建了一整套系统来确保这个 agent 能够随着客户业务的发展而不断进化和优化。这不是一次性的技术实现，而是一个持续运作的智能系统。

Forward Deployed Engineering 的自动化革命

在去年夏天，Parahelp 遇到了一个严重的瓶颈：他们无法招聘足够的工程师来为所有想使用 Parahelp 的客户提供 forward deployed engineering 服务。Forward deployed engineering 是硅谷过去两年最热门的趋势之一，指的是工程师深入客户现场，了解客户的具体需求，然后为客户定制解决方案。

这种方法的问题在于它不具备规模化能力。Anker 和 Mads 意识到，他们可以尝试大量招人，但他们并不擅长建立一个以执行和运营为主的组织。他们的优势在于打造产品。他们想招聘的工程师也更擅长打造产品，而不是做大量手动工作，更像是顾问而非工程师。

他们想要保持小团队规模，同时实现极快的增长。这看起来几乎是不可能的任务，直到 Claude Opus 4 的发布改变了一切。他们花了整个夏天的两个月时间，暂停了增长，完全重建了他们的 agent 架构。Opus 4 是第一个在他们的内部基准测试中具备足够智能，能够动态生成评估集的模型。

这意味着什么？本质上，他们构建了一个 AI forward deployed engineer。它能够替代之前需要 Parahelp 员工完成的工作：与客户交谈，了解需求，然后更新系统。自从推出这个系统后，他们再也没有编写过任何定制的评估集，因为他们的 agent 会为客户自动完成这些工作。

我认为这可能代表了 forward deployed engineering 的下一代演进。对这种模式的批评一直是它无法规模化。但如果所有的 forward deployed engineer 都是 AI agent 呢？那么规模化就不再是问题了。Parahelp 从编码 agent 的设计中汲取了大量灵感，特别是两个关键要素：能够运行确定性代码，然后让 agent 进行优化，这样它就可以工作更长时间；以及拥有一个审查系统。

现在 Parahelp 的 agent 可以轻松工作 30 到 40 分钟来优化自己的策略，运行测试，然后进行审查。这两个特点让他们能够处理比简单问题复杂得多的场景。Opus 4 能够管理所有这些复杂的上下文，并推理如何改进系统。

Parahelp Assistant：AI 驱动的持续优化引擎

Parahelp 最近推出的新架构包含两个核心 AI agent：Parahelp Agent 和 Parahelp Assistant。Parahelp Agent 直接在客户的工单系统中工作，处理实际的客户支持请求。而 Parahelp Assistant 则是一个更加革命性的创新，它让客户能够快速设置 Parahelp，构建和优化策略，设置工具，并在发布到生产环境之前彻底测试所有内容。

Assistant 的设置过程非常简单。客户只需要向 Parahelp agent 发送一个电子邮件邀请，就像邀请一个新员工加入工单系统一样，然后系统就上线了，不需要工程师安装任何 SDK 或连接任何渠道。这种极简的设置流程是 Parahelp 能够快速扩展的关键因素之一。

但真正让我印象深刻的是 Assistant 的智能优化能力。在过去六个月里，Parahelp 的客户选择他们主要是因为他们能解决复杂的工单。但这也意味着在接入客户时需要运行大量复杂的评估。由于模型还不够智能，很多情况下需要手动完成这些工作。他们会通过内部工具运行评估来优化 agent，如果需要修复任何问题，他们常常需要进行 prompt 优化。这种 forward deployed engineering 的方法效果不错，但也意味着他们需要为每个客户编写大量无法复用的定制 prompt 优化。

随着客户增长和需求激增，他们发现自己在快速设置和保持高解决率方面开始落后，除非雇佣大量人员为每个客户做定制工作。作为非常注重产品的创始人，他们不喜欢这种方式。然后 Opus 4 发布了，他们意识到可以暂停增长，重建 agent 架构。

现在，Parahelp 有了一个研究 agent，它可以一次搜索多达 20000 个工单，然后用多个子 agent 来管理上下文，仔细分析通常 50 到 500 个工单。它会打开完整的工单内容，当然会移除所有敏感信息，然后分析 AI agent 是如何处理的、何时转交给人工、人工是如何处理的。最后它会提供一份详细的研究报告，附带来源和分析的所有工单，然后主动提出改进建议。

更酷的是，这些改进建议可以由支持经理直接在同一个会话中实施，只需要提示 agent："请实施这个建议，我刚添加了这个工具，请制定一个策略来调用这个工具以填补知识空白。"或者研究 agent 会自动查看人工客服如何回复类似问题，然后说："看起来我们需要有这个策略，人工客服就是这样做的，我认为通过这个策略我可以多解决 5% 的工单。"

这创造了一个持续的优化循环。你可以发现人工解决工单的模式,然后配置和测试这些模式并发布它们,让这个持续的循环在任何时候都能优化 agent 能够处理的工单数量。自从两周前为 Perplexity 推出这个系统并建立这个自动化飞轮后,他们的解决率提高了 12 到 15 个百分点,因为团队实际上已经做出了 250 多次发布。这相当于 10 名以上的团队成员能够根据他们的专业领域进行发布。

从客户支持到收入增长引擎

Parahelp 的愿景不仅仅是自动化客户支持,而是将支持系统转变为公司的收入增长引擎。我认为这是一个非常前瞻性的思考方式。传统上,客户支持被视为一个成本中心,企业总是希望尽可能降低支持成本。但 Parahelp 看到了不同的可能性。

他们即将推出的一个功能特别让我兴奋:批量跟进工具。假设客户想知道为什么他们的待办事项中有 700 个未解决的学生折扣相关工单。Parahelp Assistant agent 会分析这个情况,确定需要哪些端点、如何验证、应该如何回应,然后不仅为未来的类似工单建立策略,还会问:"我应该跟进所有这 700 个工单吗?" 一旦获得批准,它就会在工单系统中生成大量 Parahelp agent 来处理这些工单。

更进一步,这个批量跟进功能结合研究能力和所有系统的上下文后,Parahelp 实际上可以开始充当客户成功经理的角色,向客户追加销售或联系已流失的客户告诉他们新功能。每当客户推出新功能或修复 Bug 时,研究 agent 会自动提示他们:"我们应该跟进每一个曾经要求过这个功能的客户吗?" 然后它可以启动这个 agent 说:"嘿,这个功能现在在我们的 Pro Plus 计划中可用了。"

这是一个超级智能版本的客户关系管理,能够回溯并回复过去两年中所有询问过某个功能的人,现在你终于发布了这个功能。对于某些客户,Parahelp 已经解决了数十万个工单,这意味着 Parahelp agent 拥有数十万个潜在客户的邮箱,这些客户可能被追加销售到商业计划或显著扩展。但普通团队没有资源或全局视角来做到这一点。

Parahelp 还推出了一个工具,让 agent 可以在客户流失前给予折扣,或者发送追加销售链接。客户可以轻松定义他们想要的策略,突然之间,这不再只是成本节约,而是实际的收入生成。我问 Anker 和 Mads,Parahelp 的价值主张有多少是关于降低雇佣人类客服的成本,有多少是关于做一些用人工根本无法做到的事情,比如通过以前无法规模化的追加销售方式来增加收入。

他们的回答很明确:主要是后者。由于他们只专注于快速发展的软件公司,在很多情况下,这些公司今天并没有庞大的支持团队。支持成本本身并不是特别大。但如果他们必须跟上业务增长,支持成本就必须变得很大,因为他们必须雇佣很多人。所以更多的是实施 Parahelp,然后 Parahelp 成为他们本来需要雇佣的 100 个客服。而且由于所有这些 agent 拥有统一的大脑,它们不仅具有一个可以 24/7 工作的单一 agent 的影响,而且具有如果所有处理特定工单的 agent 都拥有统一大脑并能做各种事情的影响。

Parahelp 如何成为公司的知识中枢

一旦公司接入 Parahelp,一个有趣的现象就会发生:Parahelp 开始在公司内部传播开来。因为对于快速发展的软件公司来说,支持系统实际上是知识的大脑。公司员工开始把所有的知识转储和信息都导向 Parahelp Assistant,而 Assistant 也会主动提示他们提供更多知识。

很快,Parahelp 中就会有数百页只存在于 Parahelp 系统中的知识。他们遵循的一个原则是让公司员工极其容易访问这些知识。所以他们为销售、工程、企业和客户成功团队创建了"Ask Parahelp"频道,甚至为仍在回答问题的支持代理创建了类似 co-pilot 的频道。

对于某些客户,这些频道中有数百名员工,他们只是在向 Parahelp 提问,基本上把它当作支持团队以前作为资源提供服务的延伸。现在有了深度研究功能,他们不仅能够问"请告诉我如何将解决率提高 10%"这样的问题,产品团队、工程团队和领导团队实际上还可以问"我们的退款在过去一个月里是如何演变的,这与情绪、新功能或 Bug 有什么关联",然后找出如何通过遵循 Parahelp 提供的洞察来将退款百分比减少 20%。

这些洞察来自于 Parahelp 能够交叉比对退款分析数据和实际的客户对话,甚至包括产品反馈。如果他们推出了一个新功能并想了解客户对该功能的反应,他们也可以从中发现模式。产品团队可以使用这些作为改进新功能的参考。或者在功能请求中发现模式,看到很多客户都在要求构建某个功能,那就应该优先考虑这个功能,因为现在有数据支持。Bug 报告也是同样的道理。

Parahelp 变成了一个在整个组织中部署更广泛的工具,因为在很多方面,这是软件公司特有的,但对于软件公司来说,支持确实是客户知识和产品知识的中心,是组织其他部分大量工作的起点。

文章来自微信公众号 “ 深思圈 ”