2015年，Netflix的工程师们面对一个令人头疼的问题：数百个微服务并发运行，任何一个故障都会引发连锁崩溃，测试环境正常但生产环境一直不稳。他们造了一把锁——一个叫做Conductor的工作流编排引擎，把所有服务的执行顺序、错误重试、状态追踪都交给这个”总指挥”。Conductor运行了，Netflix的工程效率提高了，问题解决了。然后，Netflix把这把锁开源了，继续去做下一件事。

十年后，这把锁的创造者们拿到了6000万美元。

2026年4月23日，Orkes宣布完成6000万美元B轮融资，由AVP（América Venture Partners）领投，Prosperity7 Ventures、Nexus Venture Partners、Battery Ventures、Vertex Ventures US跟投，公司总融资额达到约9000万美元。Orkes的核心产品，正是企业级Conductor工作流编排平台。

这笔融资发生在一个特定的历史节点：AI Agent从”演示热”进入”生产冷”的关键拐点。

一把被遗弃的锁，和一门价值9000万美元的生意

故事要从2016年说起。

Netflix将Conductor开源后，这个项目迅速成为微服务编排领域的事实标准之一。Tesla、美国联合批发抵押贷款（United Wholesale Mortgage）、澳大利亚媒体公司Foxtel……数千家公司开始依赖Conductor管理复杂的业务工作流。

但2023年底，Netflix宣布停止维护开源版Conductor。这个决定震动了依赖Conductor的开发者社区——没有人预料到这么快。

项目没有被废弃，因为Conductor的原始开发者已经做好了准备。

Orkes的联合创始人兼CTO Viren Baraiya和CEO Jeu George，正是Conductor在Netflix内部的核心架构师。他们在离开Netflix之后，于2022年以930万美元种子轮启动了Orkes，专门提供基于Conductor的企业级托管服务。2024年2月，他们完成了2000万美元A轮（Nexus Venture Partners领投）。如今，他们的B轮是A轮金额的3倍。

这条”开源→商业化”的路径本身并不新奇。Redis的创造者创立了Redis Labs，ElasticSearch的作者成立了Elastic，Kafka的联合创始人成立了Confluent。这些公司都遵循着相同的逻辑：当一个开源项目变成关键基础设施，企业会愿意付钱买可靠性、支持和更多功能。

但Orkes的时间节点不同——它在AI Agent浪潮的前夜，完成了从”微服务编排”到”AI Agent编排”的战略转型。这个转型是理解此次融资的关键。

演示很容易，失败也很容易：AI落地的可靠性危机

企业AI落地正在经历一场隐形的”可靠性危机”，这场危机还没有被主流讨论足够多，但每一个认真推进AI落地的工程团队都在亲历它。

当工程师在本地测试AI Agent时，一切看起来都很完美：Agent接到任务，调用外部API，处理数据，生成结果，一气呵成。演示给业务方，掌声响起。然后，项目进入生产部署阶段，真正的噩梦才开始。

场景一：状态丢失导致的重复执行

一个金融交易Agent需要执行三个步骤：查询账户余额、调用支付API扣款、更新内部账本。步骤一和步骤二都成功了，但在步骤三执行到一半时，服务器因为资源限制重启了。Agent重新启动时，因为没有持久化的状态记录，它以为自己是全新开始，于是重新执行了步骤一和步骤二——账户被重复扣款了。

这不是假设。这是Orkes在技术博客中记录的一个真实客户案例，问题定位花了三周时间。

场景二：并发竞争条件

一个企业的CRM Agent系统部署了50个并发Agent，每个Agent负责处理一批客户工单。由于缺乏中央协调机制，多个Agent同时尝试更新同一条客户记录，产生了数据竞争。最终的结果是：部分客户工单被处理了两次，另一部分客户工单记录被损坏，数据一致性被破坏。

场景三：超时导致的任务状态悬空

一个文档处理Agent需要调用OCR服务提取文字，然后调用LLM服务生成摘要，最后更新数据库。OCR服务有时候需要20秒才能返回结果。Agent的默认超时设置是15秒，于是OCR调用超时，整个任务被标记为失败。但OCR服务实际上已经完成了处理，只是响应晚了一点。结果：这个文档被列入”处理失败”队列，等待下次重试，OCR费用被重复支付。

场景四：多步骤可观测性缺失

一个复杂的采购审批Agent需要完成12个步骤，涉及ERP系统、邮件服务、审批平台三个外部服务。某天，一批采购申请集中卡在第7步。工程师打开日志，发现日志分散在三个不同的服务里，没有统一的执行视图，无法快速判断问题出在哪个服务的哪个具体调用。排查耗费了6个工时。

Orkes的CEO Jeu George在接受VentureBeat采访时说了一句话，精准描述了这个状况：”AI Agent的演示成功率是99%，但生产环境的可靠性却是60%。这个差距，就是我们在解决的问题。”（数字来自George本人对客户案例的总结，反映行业普遍规律，非第三方研究数据）

这句话背后隐藏的市场逻辑是：每家正在认真推进AI Agent落地的企业，都会以某种方式遭遇这个差距。要么雇佣高级工程师手写复杂的错误处理逻辑，要么采购专门的编排平台。

Conductor的核心解法：把”可靠性”做成基础设施

Conductor（以及Orkes云版本）的核心架构设计，本质上是在解决分布式系统中的一个经典难题：如何让一组步骤在任何失败情况下，都能保证”恰好执行一次”并且状态可追溯？

这个问题在微服务时代已经存在了，但AI Agent让它变得更加紧迫——因为AI Agent的每一步都可能涉及昂贵的LLM调用（失败了还要付token费）、不稳定的外部API（成功率不是100%），以及不可预测的执行时间（从毫秒到数分钟不等）。

Conductor的关键机制有三个：

第一：持久化执行状态（Durable Execution）

工作流的每个步骤执行结果都被写入持久化存储（Conductor使用分布式数据库保存状态）。即使执行系统崩溃、服务器重启、网络中断，当服务恢复时，Conductor会从上次成功完成的步骤之后继续执行，而不是从头重跑。

对AI Agent来说，这意味着一个5步骤的长流程在第4步失败时，不需要重新花费前3步的时间和API费用。Orkes的技术博客记录了一个客户案例：一个文档处理工作流，原来每次失败都要从头重新处理，平均浪费12分钟。引入Conductor后，断点续跑使平均恢复时间降到了45秒。

第二：中央化状态追踪（Centralized State Tracking）

所有Agent和子任务的执行状态都汇聚在Conductor的状态机中。无论系统多复杂，都有一个统一的地方可以查询”现在每个任务在哪个步骤、花了多少时间、调用了哪些外部服务”。

这种中央化视图对工程团队的日常运维价值极大。Conductor提供了一个可视化的工作流执行历史界面，支持实时查看任何一个工作流实例的完整执行轨迹。当生产环境出现问题时，工程师不需要在十几个服务的日志里手动比对时间戳，打开Conductor界面就可以直接定位问题步骤。

第三：内置重试和补偿逻辑（Built-in Retry & Compensation）

每个步骤都可以声明式配置重试策略——包括最大重试次数、等待时间（支持指数退避，避免雪崩效应）、超时时间。失败时的回滚操作（Saga补偿模式）也可以配置，不需要在应用代码里手写复杂的try-catch和回滚逻辑。

这种声明式配置的好处是：重试逻辑和业务逻辑分离。业务开发者只需要关心”做什么”，运维可靠性层的”怎么保证做成功”由Conductor统一负责。

Orkes在开源Conductor基础上，为AI场景增加了四类专用功能：

  • LLM任务节点：Conductor工作流定义中可以直接声明”调用GPT-4”、”调用Claude Opus”等步骤，内置token配额管理和成本追踪
  • Human-in-the-Loop暂停：Agent执行到需要人类审批的步骤时，自动暂停等待，审批完成后自动继续
  • Agent间通信协议：在多Agent系统中，Conductor作为中央协调器，管理任务分发、结果汇聚和Agent间消息传递
  • AI可观测性仪表板：提供专门针对AI工作流的监控视图，包括LLM调用延迟、token消耗趋势、Agent成功率、平均执行时间等指标

市场拐点：AI Agent编排的战争刚刚开始

Orkes的竞争对手阵营正在快速扩张，这场战争的规模正在超越初创公司之间的竞争。

云厂商已经入场。AWS在2026年4月9日发布了BedrockAgentCore中的Agent Registry预览版，提供企业级AI Agent的集中目录、语义搜索、审批工作流和CloudTrail审计。Google在Cloud Next ‘26（2026年4月22日）上将Vertex AI重命名为Gemini Enterprise Agent Platform，并宣布投入7.5亿美元合作伙伴基金推动企业AI Agent部署。微软的Copilot Studio也在向多步骤Agent编排方向演进。

同类初创公司在同期融资。与Orkes同日（2026年4月23日），AI分析平台Omni完成了1.2亿美元C轮融资，估值达到15亿美元。整个AI基础设施赛道的融资密度在2026年Q2显著提速。

云厂商的入局，证明了这个市场足够大，但也带来了一个关键问题：独立平台如何在巨头面前找到生存空间？

Orkes的护城河建立在两个方面：

护城河一：云无关性（Cloud Agnostic）

Conductor的架构天然是云无关的——它可以部署在AWS、GCP、Azure或私有云上，不与任何单一云厂商绑定。对于跨云部署或有数据主权要求的企业（金融、医疗、政府），这是一个关键优势。

AWS的BedrockAgentCore只能运行在AWS上，Google的Gemini Enterprise Agent Platform只能运行在GCP上。当一家银行的Agent工作流横跨三个云厂商的服务时，统一的编排层只能来自云无关的独立平台。

护城河二：开源社区的历史积累

Conductor开源已有10年，全球超过15,000个GitHub star，数千家公司在生产环境中运行过Conductor。Orkes不仅是Conductor的商业化版本，也是Conductor OSS的主要维护者，接管了Netflix停止维护后的整个项目维护工作。

这种历史积累体现在三个层面：第一，已有数千家企业的工程师理解Conductor的工作方式，采购Orkes的学习成本接近零；第二，Conductor社区积累了大量的实战案例、最佳实践和问题解决方案；第三，Orkes作为唯一能提供官方企业支持的公司，在这个社区里具有天然的可信度。

Orkes面临的主要挑战，不是来自竞争对手，而是来自客户的认知转换成本。很多企业的工程团队已经习惯了用自定义Python脚本或者AWS Step Functions处理Agent编排，说服他们引入一个专门的编排平台，需要一次文化和架构上的转变。

这个问题没有简单的解法，只能靠案例积累和社区口碑慢慢改变。这也是Orkes把B轮资金优先用于开发者教育和迁移工具的原因。

值得关注的是，Orkes的定价模式也和云厂商形成了差异化。AWS和Google的Agent编排服务通常按执行次数和存储量计费，对高频低复杂度工作流比较友好，但对于执行时间长、步骤多的复杂AI Agent任务，账单可能会出乎意料地高。Orkes提供基于资源使用的订阅定价，对于运行数百个长时间执行Agent的企业来说，总成本通常更可预测。

这种定价差异在企业技术选型时变得越来越重要——当AI Agent从实验性项目变成每天处理数万次任务的生产系统，成本可预测性是采购决策中权重最高的因素之一。

当然，这里也存在一个需要正视的对立视角：云厂商的内置编排方案有其拥护者。一部分工程师认为，专门引入第三方编排平台会增加技术栈的复杂度——又多了一个需要维护、升级、监控的组件。对于只在单一云上运行Agent的企业来说，AWS Step Functions或Google Workflows的”开箱即用”集成，可能比引入独立平台更简单。如果云厂商持续完善其原生编排能力，Orkes的差异化空间就会收窄。这是Orkes在赢得市场时需要持续回答的核心挑战。

第三层洞察：可靠性，不是功能，是护城河

表面上看，Orkes的融资故事很简单：AI Agent市场爆发，需要编排工具，钱就来了。

但更深层的逻辑涉及AI竞争的阶段性转换。

AI的竞争已经进入第二阶段。第一阶段比的是模型能力——谁的模型更聪明，谁就有优势。在这个阶段，Anthropic、OpenAI、Google用数十亿美元的训练预算建立起了难以复制的壁垒。第二阶段比的是系统可靠性——谁能让AI在真实的生产环境中稳定运行，不丢数据、不重复执行、不悄悄出错。

在第二阶段的竞争中，赢家是那些深刻理解分布式系统本质的工程基础设施团队。而理解分布式系统，需要的不是算法博士，而是在Netflix、Google、Meta这类公司处理过真实大规模故障的工程师。Orkes的创始团队在Netflix处理的，正是每月数十亿次工作流执行的可靠性问题。

存在一个结构性悖论：AI Agent越聪明，它的生产可靠性挑战就越大。

更聪明的Agent会尝试执行更复杂的多步骤任务，调用更多外部服务，涉及更长的执行时间和更多的状态转换。GPT-5.5这类新模型能够自主规划十几步的复杂任务，但每增加一步，出错概率就增加一次，状态管理的复杂度就指数级上升。复杂度的增加，让编排层的稳定性变得更加关键，而不是更不重要。

这意味着Orkes所在的赛道，不会因为LLM进步而消失——恰恰相反，LLM越进步，对可靠编排基础设施的需求就越强烈。这是一个随着AI进步而需求同步增长的市场，而不是会被AI能力提升所取代的市场。反脆弱性是这个商业模式的核心特征。

还有一个常被忽视的经济账：AI Agent的故障成本随着落地深度增加而飙升。一个每天处理1000条客服工单的AI Agent，如果出现状态管理问题，可能导致500条工单被重复处理——这不只是工程效率问题，而是直接的业务损失和客户信任损耗。企业采购可靠性工具的ROI，不是和”有多少功能”比较，而是和”不用它时我们会损失多少”比较。这个比较的结果，往往让采购决策变得很容易。

从Netflix内部工具到独立赛道

回到开头的故事：Netflix的工程师造了一把锁，开源出去，然后去做了别的事。但这把锁被全球数千家公司用了10年，成了他们技术栈里不可或缺的一部分。

当Netflix说”我们不想维护这个项目了”，没有一家云厂商第一时间跳出来说”我来接”。是锁的创造者自己接了过去，然后把它变成了一门生意。

这门生意的核心假设是：在AI Agent时代，系统的可靠性和可观测性，和算法能力一样，是企业技术栈的基础设施，不是可以凑合的附加功能。当一个企业把核心业务流程——采购审批、客户服务、财务对账、合规检查——都交给AI Agent执行时，这些流程的可靠性要求和传统软件系统没有任何区别，甚至更高，因为AI Agent的行为本身带有一定的不确定性，更需要外部的稳定框架来约束。

这个假设现在有一个具体的数字验证：6000万美元，B轮。

AI Agent的”烦人数字”：每个企业都在悄悄经历的技术债

有一个现象值得单独讨论，因为它在主流科技媒体里很少被正面提及：AI Agent落地的技术债，正在以一种安静而昂贵的方式积累。

2025年到2026年，大量企业的AI团队都经历了类似的路径：先用Python脚本把几个LLM调用串起来，然后加一些if/else的错误处理，然后发现生产环境里偶尔会有奇怪的故障，然后再加一些日志，然后再修复一些边界情况……每一步都很小，但积累起来，团队花在”维护AI管道可靠性”上的时间，往往超过了”开发新AI功能”的时间。

这种情况在传统软件工程里有一个成熟的解法：把基础设施关注点从业务逻辑里分离出来，用专门的中间件处理消息队列、重试、事务等问题。Kafka处理消息流，Redis处理缓存，PostgreSQL处理持久化——这是现代软件架构的基本常识。

但在AI Agent领域，这种分离还没有成为常识。很多企业的AI团队还在把”工作流编排”当成业务逻辑的一部分来手写，而不是作为基础设施来配置。结果是：每个团队都在重复发明轮子，而且发明出来的轮子质量参差不齐。

Orkes的核心商业主张，其实就是一句话：你不应该手写工作流编排逻辑，就像你不应该手写数据库引擎一样。

这个主张听起来简单，但要说服一个已经有了”凑合能用”的自定义解决方案的工程团队，需要让他们看到具体的成本：他们花了多少工程小时在维护这套自定义逻辑？发生了多少次因为状态管理问题导致的生产事故？每次事故的排查成本是多少？

这种成本核算，是Orkes的销售团队要做的核心工作。而B轮融资，提供了他们扩大这项工作的资金。

Conductor的生态：开源基金会、社区与商业化的平衡艺术

Orkes的另一个鲜少被讨论的资产，是Conductor生态系统本身的治理结构。

Netflix在宣布停止维护Conductor的同时，基本上把这个生态的命运留给了社区。Orkes在接过维护权之后，面临一个经典的开源商业化困境：如果把Conductor企业版功能做得太好、太封闭，开源社区会分叉（fork）出一个独立版本；如果完全开放所有功能，商业化的差异化就变得困难。

Orkes的解法是创立了Conductor OSS Foundation（conductor-oss.org），把核心的工作流引擎保持完全开源，同时把AI专用功能（LLM任务节点、Human-in-the-Loop、多Agent协调协议）作为Orkes企业版的差异化功能。这种”开源核心+企业附加”的分层策略，被Redis Labs、Elastic、Confluent等多个成功的开源商业化公司验证过。

但Orkes的情况有一个特殊之处：它不仅是Conductor企业版的提供商，也是Conductor OSS的实际维护者。这意味着，当任何Conductor OSS用户遇到Bug需要修复时，这个修复工作会落在Orkes的工程团队身上——即使这些用户永远不会成为付费客户。

这是一个持续的成本，但也是一个持续的护城河。每一次对Conductor OSS的贡献，都在巩固Orkes作为”Conductor正统继承者”的地位。当一个企业从免费的开源版迁移到需要企业支持时，它最可能选择的对象，是那个最了解这个代码库来龙去脉的公司。

在GitHub上，Conductor OSS仓库（conductor-oss/conductor）目前有超过15,000个star，在工作流编排类工具中属于第一梯队。对比：Airflow（Apache基金会管理，针对数据管道场景）有超过30,000个star；Temporal（另一个企业级工作流编排竞争者）有约11,000个star。Conductor在AI Agent编排这个细分赛道上的社区体量，是竞争对手Temporal的1.4倍。

值得一提的是，Temporal（由Uber Cadence的前创始团队创建）也是这个领域的主要竞争者，融资规模更大（2022年完成1亿美元B轮，估值15亿美元）。Orkes和Temporal的竞争，将是这个赛道接下来几年的主线叙事之一。

对企业的技术决策者来说，Orkes此次融资传递的信息很清晰：AI Agent编排不是一个临时解决方案，也不是一个可以等待云厂商顺带解决的附属功能。在AI Agent真正成为企业业务流程主力的时代，可靠的编排基础设施将和数据库、消息队列一样，成为技术栈的标配组件。而那些还在用手写脚本凑合的团队，终将面对一个关键的系统性问题——就像当年Netflix工程师面对微服务混乱时一样。

那个时候，他们需要的答案，Orkes已经准备好了。

写在最后：一个创业者的选择题

Orkes的故事提供了一个值得思考的创业模式参考：开源社区是否是最好的企业软件商业化起点？

从结果来看，Netflix Conductor的10年积累为Orkes提供了常规创业公司无法快速复制的资产：全球数千家公司的生产验证、真实的大规模故障经验、和一个已经理解并认可这个产品的工程师社区。

但这个模式也有它的代价：维护开源项目本身需要持续的工程投入（Orkes需要维护Conductor OSS，同时开发商业版功能），而且开源社区的用户并不直接转化为付费客户——需要额外的销售和市场工作来完成这个转化。

对于Orkes来说，6000万美元的B轮应该足以覆盖接下来1到2年的扩张成本。但AI Agent编排这个市场的竞争，将在2026到2027年间真正白热化——不只是初创公司和初创公司之间，而是包含了AWS、Google、Microsoft这三家在企业软件领域拥有压倒性渠道优势的科技巨头。

独立平台能在这场竞争中生存和繁荣的前提，是证明自己比云厂商的”内置”编排工具提供了无法替代的差异化价值。Orkes目前的云无关性和开源传承是两张牌，够不够打赢，要等真实的市场来回答。

但有一点是确定的：AI Agent的可靠性问题不会随着时间自动消失。解决这个问题的公司，无论是Orkes还是别的什么，都将成为下一个十年企业技术栈里的基础设施成员。这个位置，值得6000万美元去争。

从更宏观的视角来看，Orkes的融资代表了一类投资逻辑的胜利：不投”AI能力”，投”AI可靠性”。在AI能力层，赛道已经极度拥挤，估值泡沫的风险显而易见。但在AI基础设施层，真正解决生产可靠性问题的公司，其商业价值往往被低估——因为这类工具的效果是”系统不崩”，而不是”功能酷炫”，前者很难在演示视频里呈现。

AVP领投这笔B轮，押注的不是Orkes的功能有多炫，而是每一家正在认真落地AI Agent的企业，都迟早会遇到它正在解决的那些问题。这个假设的置信度，随着GPT-5.5这类强大Agent模型的广泛部署，每一天都在上升。

参考资料

  • VentureBeat: “Orkes raises $60M Series B to take AI agent orchestration mainstream” (2026-04-23) — https://venturebeat.com/business/orkes-raises-60m-series-b-to-take-ai-agent-orchestration-mainstream/
  • TechCrunch: “Microservices orchestration platform Orkes raises $20M Series A” (2024-02-21) — https://techcrunch.com/2024/02/21/orkes-raises-20m-series-a/
  • Netflix Tech Blog: “Netflix Conductor: A Microservices Orchestrator” (2016) — https://netflixtechblog.com/netflix-conductor-a-microservices-orchestrator-2e8d4771bf40
  • Orkes 官网: “Running a Billion Workflows per Month with Netflix Conductor” — https://orkes.io/blog/running-a-billion-workflows-per-month-with-netflix-conductor/
  • Conductor OSS Foundation 官网 — https://conductor-oss.org/
  • Orkes 官网: “Durable Execution Explained: How Conductor Delivers Resilient Systems” — https://orkes.io/blog/durable-execution-explained-how-conductor-delivers-resilient-systems/
  • AWS: “AWS Agent Registry Preview in Amazon Bedrock AgentCore” (2026-04-09) — https://www.theregister.com/2026/04/09/aws_ai_agent_registry
  • Google Cloud Next ‘26: “Gemini Enterprise Agent Platform Announcement” (2026-04-22) — https://cloud.google.com/blog/topics/events/google-cloud-next-2026