在智能体（Agent）从实验室走向大规模商业落地的历史拐点上，AI云基础设施正经历一场从“无状态模型托管”向“智能体运行期（Agent Runtime）”的底层架构重塑，这不仅是技术的演进，更是决定企业AI应用单位经济学（Unit Economics）生死的关键战役。
在近期举办的Nebius Inflection 2026峰会上，一场关于AI基础设施真正走向商业化深水区的讨论引发了市场的强烈关注。Nebius联合创始人Roman Chernin提出了一个让全场技术人员与企业CIO产生共鸣的核心观点：“当智能体走向大规模生产时，传统的、无状态的模型服务架构将彻底崩溃，行业必须全面转向‘智能体运行期’基础设施。”
“客户希望智能体完成任务的成本，能让产品在经济上可行。”Roman Chernin 直言，“Token将成为下一个基础设施层，未来的付费模式将基于结果（Outcomes），而不是Token。”
当前，市场对AI的关注点已从单纯的“模型参数战”转向了真实的ROI（投资回报率）和云端算力消耗的经济账。正如Nebius CEO Arkady Volozh在会上透露，公司正朝着年底实现 800兆瓦至1吉瓦的运行电力迈进，并已锁定总计4吉瓦的算力容量，这意味着数十万乃至数百万张GPU的惊人规模。然而，支撑这种百亿美元级别扩产逻辑的核心，不再是卖基础算力，而是为企业解决“Token乱烧却不出活”的痛点。
规模化下的“恐怖放大器”：无状态推理为何失效？
在第一波AI浪潮中，市场的核心商业模式是“售卖Token”。开发模式极为线性：用户输入 →→ 经过API调用模型 →→ 模型返回Token →→ 结束。这是一种“无状态”的单次请求。
但Agent的行为逻辑完全不同。Roman Chernin指出：
“Agent不仅仅是一次优化的模型调用，它是一个循环（Loop）。它需要规划、调用工具和模型、观察结果、重试，直到任务完成。”
在资本市场眼中，这种循环一旦失去控制，就是一场财务灾难。Roman 一针见血地指出了规模化下的恐怖放大器效应：
“如今，构建一个智能体原型很容易……但在规模化下，小小的错误会累积。表面看起来很美好的95%单次调用成功率，换算下来就是彻底的失败。一个糟糕的规划可能消耗十倍于我们预算的 Token。”
从微观概率来看：如果一个模型单次 API 调用的成功率是 95%，但当一个 Agent 为了完成某项复杂任务，需要在 Loop 中连续调用该模型及各类工具 15 次时，该 Agent 任务的终极成功率将暴跌至：。
这意味着超过一半的概率，Agent会在中间某个环节“死锁”或彻底跑偏（Over-scoping）。“一个糟糕的计划可能会烧掉比我们预算多10倍的Token。”Roman警告道。
Chernin在峰会上提出了一个被他称为"下一个循环"的概念，这也是整个Agent Runtime体系中最具商业想象空间的部分：
"每个智能体在运行时，都会产生大量数据——规划、追踪、成本和结果。当我们捕获了所有这些数据，我们就可以开始系统性地、持续地改进智能体。就像今天我们优化推理端点一样，我们可以优化路由，改进提示词和工具调用，降低成本。"
这意味着云平台的角色发生了本质转变：
"云平台变成了不仅仅是智能体运行的地方，它变成了让智能体可度量且持续变得更好的系统。"
Chernin指出了另一个常被忽视的结构性变化：
"云平台是为人类用户构建的——开发者阅读文档，在控制台点击，手动部署和调试服务。智能体需要不同的云接口——API优先、可编程且可观测。"
CEO Arkady Volozh在随后的演讲中补充了规模数据：Nebius目前运营超过200兆瓦算力，年底目标达到800兆瓦至1吉瓦，已签约预留容量超过3吉瓦，年底目标突破4吉瓦。
商业落地的硬性指标：Agent Runtime的五大核心技术要求
为了在生产环境中稳定、低成本、安全地运行成百上千个Agent，底层基础设施必须具备以下五大硬性指标：
① 确定性流式编排与多模型路由（Deterministic Orchestration & Routing）
-
市场痛点： 纯靠LLM自主决定下一步调用什么工具，极易导致“幻觉”或死循环。大企业在财务、合规等高风险场景下，要求过程必须可控。
-
技术解法： 平台必须提供能将确定性代码与LLM柔性推理结合的框架，并支持动态模型路由。在Agent循环中，将最关键的决策路由给最聪明、最贵的模型（如GPT-5）；而把海量的脏活累活，自动路由给便宜10倍、快10倍的开源模型（如DeepSeek-V4、Nemotron）。Nebius生态战略副总裁Devang Sachdev在演示中提到，仅通过将GPT-5.5替换为开源大模型，成本瞬间下降了95%。
② 长周期状态管理与持久化执行（Durable Execution）
-
市场痛点： Cognition（Devin）的CEO Scott在访谈中提到，Agent的运行时间正在从几分钟拉长到数小时甚至数天。“我们已经看到人们让Devin连续运行几周来完成整个实习生级别的项目。”
-
技术解法： 基础设施必须提供Agent运行期的状态持久化。当遇到网络波动、工具超时或硬件微观故障时，系统需自动捕获上下文，实现“无缝断点续传”，而不是重新从第一步开始燃烧昂贵的Token。
③ 面向机器而非人类的高吞吐数据访问层（Grounding Data Layer）
-
市场痛点： Pinecone创始人Ash Ashutosh在圆桌论坛上披露了一个惊人的拐点：“去年9月，我们有史以来第一次看到一类新的用户，他们发起API调用的数量超过了人类，这就是Agent。” 如果直接把人类阅读的长篇网页丢给Agent，单次任务轻松烧掉几百万Token，单位经济学（Unit Economics）直接破产。
-
技术解法： Tavily创始人Rotem Weiss指出，互联网正走向分化，一层为人类优化，另一层为机器优化。基建需要集成智能体联网检索，返回高度精炼、结构化、带语义上下文的JSON数据，这能将Token消耗暴降，并保证企业内不同Agent认知的一致性。
④ 全Trace异步可观测性（Observability & Tracing）
-
市场痛点： “当100个Agent跑起来时，最先崩溃的是什么？是可见性。你将一无所知，那将是一场混乱（Chaos）。” LangChain的Julia Schottenstein直言。当企业的算力账单翻了5倍，根本不知道在包含数万次调用的“智能体风暴”里，是哪只Agent在哪一步出了错。
-
技术解法： 平台必须标配全链路异步追踪，清晰记录规划、工具调用、Token消耗及失败节点，让复杂的非确定性AI行为像传统软件的Debug日志一样可审计。
⑤ 严苛的安全沙箱与成本兜底（Sandbox & Cost Caps）
-
市场痛点： 一个写错逻辑的Agent企图自我纠错，可能在几分钟内烧光几千美元预算（Shadow AI的爆发）。更危险的是，越权操作可能带来合规灾难。
-
技术解法： 必须在Runtime层设定“硬性成本墙（Cost Caps）”和完全隔离的安全沙箱。Guardrails AI的Shree Rajpal强调，必须通过事前仿真（Simulation）来拦截Agent可能导致的越权、注入攻击或“越狱”。
从“调模型”到“控系统”：极致的ROI飞轮
用Nebius生态策略副总裁Devang Sachdev演示的医疗合规Agent演进案例，可以最直观地概括上述基建变革的商业价值：
最初用基础模型直接跑，单次合规审计任务耗时半小时，耗费657美元，且存在严重的数据陈旧和发散问题。 而在建立起包含“开源大模型专有推理 + Tavily联网检索 + Pinecone结构化向量库 + Guardrails护栏沙箱 + LangSmith链路监控”的Agent Runtime完整飞轮后，成本瞬间暴跌至24美元（下降超96%），运行时间缩短至13分钟，且具备完美的商业可审计性。
“下一代AI的篇章不会由模型能做什么来定义。”Mark Boroditsky最后总结道，“它将由组织能够部署什么、企业能够信任什么、用户每天能够依赖什么来定义。”
这正是云基础设施向Agent Runtime演进的核心底层逻辑——用极其硬核、纵向集成的工程系统，把脆弱的AI模型包裹成企业可以百分之百信赖的现代生产力生产线。
值得注意的是，峰会圆桌讨论揭示了市场层面的真实压力。科技媒体The Information执行主编Amir Ifrati点出了一个正在发酵的叙事转折：
"我们正处于一个与10-15年前公共云早期非常相似的时刻——客户突然说，等等，我今年比预期多花了2000万美元。"
DataRobot首席产品官Venky对此直接表态："当AI账单从每用户30美元的订阅变成数百万美元的行项目，每个人都开始追问ROI。"
Cognition（Devin）CEO Scott则从结果侧给出了模型路由的实践逻辑：
"绝对最难的任务，你仍然需要最聪明的模型。但对于那另外80%-90%的任务，有性价比高出10倍、速度快10倍的开源模型完全可以胜任。模型路由正在成为越来越重要的一环。"
Nebius Inflection 2026峰会全文实录如下（由AI辅助翻译）
旁白
当AI遇见真实世界，会发生什么？
技术是基石。每一场革命都会到达一个拐点。这就是我们的拐点。正是你们的好奇心、你们的远见、你们的决心，以及你们对突破边界的不懈追求，才让这一切成为现实。我们正处于AI的黄金时代，这一切源于你们的雄心壮志——让AI在我们赖以生存的各行各业中蓬勃发展。
我们正在共同定义AI的下一个阶段。
请欢迎Nebius首席营收官Marc Boroditsky登台。
Marc Boroditsky — 首席营收官，Nebius
大家下午好，感谢各位的到来。正如刚才"上帝之声"所介绍的，我是Marc Boroditsky，Nebius的首席营收官。我非常荣幸地欢迎大家来到我们的首届Nebius Inflection大会。
好了，我不打算用又一场AI主题演讲来烦扰大家——那种声称整个世界将因AI而改变、AI让一切以前所未有的速度推进、眼前机遇无比巨大的演讲。
事实上，每周我们都会听到关于新模型、新基准、新智能体框架的发布公告。有时候，这些公告甚至在同一天，乃至同一个小时内接连出现。
我们其实正处于一个有趣的节点。我想在座各位都清楚：AI正在从一个工具，转变为能够做出令人惊叹之事、足以颠覆整个行业的存在。 但在座的每一个人都知道，我们需要的不是另一场关于机遇规模有多大的演讲。
我们需要一场更诚实的对话——关于当下地面上究竟正在发生什么。
因为有很多事情是在奏效的，但同样也有很多事情并不奏效，而且很多事情依然比人们在台上做主题演讲时愿意承认的要混乱得多。这种状况必须改变——如果AI要从实验阶段走向人们可以依赖的系统，我们就必须迈上新的台阶。
这正是我们创办Inflection的原因。
不是为了举办另一场会议，不是为了制造另一个产品发布时刻，也不是为了成为另一个发布行业公告的场合。我们创办它，是为了那些真正在做事的人。 运营者、创始人、研究人员、基础设施团队、投资者、企业领导者和建设者——那些正在将AI从可能性推向生产落地的人。
因为在当今的企业内部，AI的发展已经超前于针对它所做出的决策。 各团队正在构建智能体、多智能体自动化系统以及令人惊叹的全新工作流——有些经过了审批，有些属于"影子AI"，但所有这些都指向同一件事：人们不在等待。
而这正是工作变得真实的地方。
Demo跑通了，智能体看起来令人印象深刻，第一次模型调用感觉像魔法一样。然后它触碰到了真实世界——工作流、内部数据、延迟、SLA、治理，还有财务团队质问为什么账单突然翻了一倍。这时候，真正的代价才浮出水面。
我说的不是那张发票，我说的是AI规模化运行的代价。
因为一旦AI从试点阶段进入真实使用阶段，问题就变了。不再是"模型能不能做到"，而变成了：系统能不能可靠地做到？够不够快？够不够安全？成本是否合理？当某些事情发生变化时，我们能评估它吗？出了问题，我们能看到发生了什么吗？我们能治理一个多智能体集群，防止它造成危害吗？我们能证明其价值大于成本吗？
各组织对这些问题的回答，正是将定义这个十年的公司与其他公司区分开来的关键所在。
第一波浪潮追求的是规模——Token最大化，更多提示词，更多上下文，更多推理步骤，更多循环。但现实改变了衡量标准。接下来要走的路，不应该是关于更多Token，而应该是让每一个Token都物有所值—— 在数学上算得通的成本、用户信任的质量、能够改变业务的速度。
赢得下一个篇章的团队，不会是消耗算力最多的团队，而是将算力转化为成果的团队。
想想看：价值最大化，而非Token最大化。 在规模上创造价值的生产级AI，是摆在我们面前的下一个伟大拐点。
但技术本身不会创造拐点，人才会。 未来不会靠预言而诞生。
在Nebius，我们的使命很简单：帮助那些真正去构建未来的人。 而这些人，就在这个房间里——研究人员与运营者，创始人与企业领导者，基础设施与应用创新者，每个人都为一个更宏大的生态系统贡献着不可或缺的一块拼图。
我们相信，没有任何一家公司能够独自将AI的全部潜力带给这个世界。 这正是像今天这样的聚会如此重要的原因。
在今天的议程中，你们将听到AI领域最具洞察力、最具影响力的思想者们分享他们的观点。你们将了解技术的走向，哪些挑战仍有待解决，以及从实验走向规模化生产需要什么。我们希望这些对话能够挑战固有假设、锐化思维视角、激发新的想法。也希望你们充分利用今天汇聚于此的这群非凡之人。
Nebius团队的许多成员也在现场，他们来这里不仅仅是为了演讲，更是为了倾听、学习和协作。
随着今天议程的推进，我鼓励大家充分投入——提问、分享经验、挑战传统思维，把握与这群聚集于此的杰出领导者们建立连接的机会。
感谢大家成为其中的一部分。
在我们正式开始之前，我想分享一件对我们Nebius而言意义深重的事。Nvidia与Nebius从Nebius创立之初便携手同行、共同构建。 在此，我想播放一段来自Jensen Wang（黄仁勋） 的特别致辞。
来自黄仁勋的特别致辞
我的朋友们，周年纪念快乐，恭喜你们。Nebius，你们正在构建的东西非同寻常。数据中心正在成为AI工厂。它们将能源转化为tokens，再将tokens转化为智能。AI工厂是这个时代新的基础设施。 它们必须建在人们生活、工作和创造的地方——一个地区接一个地区，一个社区接一个社区，基础设施必须建在需求所在的地方。这正是Nebius正在构建的。
你们从深厚的云工程基因起步，然后为AI时代重建了你们的平台，仅用两年时间就从一个数据中心扩展到了吉瓦级规模的AI工厂。 Nvidia带来了加速计算、网络系统和推理软件。Nebius为开发者、初创公司、研究人员和企业构建了全栈AI平台。我们共同证明，世界各地都需要AI基础设施，而在本地构建是让它真正运转的唯一方式。
建设才刚刚开始。 Nvidia很自豪能与Nebius合作，共同构建AI时代的基础设施。恭喜你们，希望这次inflection大会圆满成功。
旁白
请欢迎Nebius联合创始人Roman Chernin登台。
Roman Chernin — Nebius联合创始人
好的，我以为Mark会来介绍我，但他们直到最后一刻才改变，把所有控制权都交给了机器人。还有Jensen，但我们都知道Jensen掌控着一切。好了，感谢大家的到来。
也感谢这个机会，让我来讲讲我们在Nebius构建了什么，我们认为我们已经交付了什么，以及我们下一步的方向。我们的行业显然正处于过去几年的拐点。我们展示了——实际上是你们展示了——AI能做什么。但现在我们需要共同证明，AI能够创造真实的经济价值。 要实现AI真正的承诺，我们需要为组织和人类创造真实的价值。实际上，我们需要建立健康的业务，拥有健康的利润率，而不仅仅是展示漂亮的营收数字和大规模融资。这是千载难逢的机会，我们需要兑现。
坏消息是，要兑现，你需要去搞清楚那些枯燥的基础设施细节。这是脏活，是不性感的工作。
有一个漂亮的原型是一回事。哦，好主意。但克服真实生产和规模化的复杂性是另一回事——关键产品要像原型展示的那样漂亮，但还要可靠。从Anthropic起步的公司需要转向开源模型，以满足单位经济性并真正发展壮大。在原型中运行良好的智能体，一旦扩展到规模，问题就会不断叠加，最终崩溃。从大型超大规模云厂商辞职、带着绝妙想法去构建自己实验室的优秀研究人员，需要的是能直接运转的基础设施。这就是我们开发Nebius的原因。我们希望在构建者扩展规模时帮助他们。
当我们审视市场时，我们看到了一个虚假的选择。一方面是老牌超大规模云厂商，拥有大量服务和全球覆盖，但看起来它们是在上一个Cloudera时代设计和构建的。它们没有针对AI工作负载和AI开发者进行优化。 它们在遗留基础设施上构建AI服务。它们的模式，说白了，始终是通过复杂的计费将开发者锁定在封闭服务中，更不用说它们存在永久性的利益冲突——它们可以为内部使用分配更多容量，而给云客户的反而更少。
另一方面是所谓的"新云"。我说了很多次，我很讨厌这个词——这是一个新的裸金属提供商类别，为AI工作负载而构建，但往往不可靠。说实话，构建者体验很差。构建它的人更像是系统集成商，他们不是真正的开发者。所以我们认为，这两种选择都有真实的局限性。
我们相信存在第三条路，一个新的产品类别——面向AI的规模化云（Scaled Cloud for AI）。从第一性原理出发构建：
第一，AI专属。 我们只为机器学习而构建和优化。我们不做任何其他事情。
第二，全栈，为客户提供最佳的总拥有成本，因为我们从底层做起。我们构建和运营数据中心，我们自己组装机架和服务器，我们构建全栈软件平台。
第三，以构建者体验为先。 我们称之为"Meet Builder"——开发者在哪里，我们就在哪里。我们让开发者专注于他们需要做的和需要控制的事情，并抽象掉大部分复杂性。
第四，开放性。 实际上，我们太小了，无法尝试将人们锁定在封闭的生态系统中。所以不做厂商锁定，依赖开放标准，给予选择。
最后同样重要的是，人很重要。 客户支持体验，工程师对工程师的关系。我们也从第一天起就自己使用我们的平台（dog fooding）。
直到现在，我们把Nebius建成了一家不同类型的公司，服务于不同类型的用户。你知道这句话："没有人因为选择AWS而被开除。"所以我们的客户也可以选择AWS，但他们选择在Nebius上构建，因为它快速、高效，而且实际上可以与拥有世界上最苛刻AI工作负载的团队共同工程化。我们将超级计算机的规模、可靠性与性能结合在一起。 这就是我们的模式。
让我分享一些我们如何与四类客户共同构建的例子。
第一类：超级实验室合作伙伴，微软和Meta。 我们帮助他们构建内部生态系统。当然，他们规模庞大、能力强劲，但他们来找我们，是因为他们知道我们能在物理世界的真实约束条件下非常快速地构建。他们需要世界上最大的互联集群，而我们交付定制机架和服务器、最新GPU以及多层存储，能效高且具备容错可靠性。
人们有时称之为商品化，但我们认为在这种规模下没有什么是商品化的。一个完全集成、生产就绪的AI工厂不是商品。 对我们来说，这是对我们如何从拥有世界上最疯狂需求的客户那里构建AI基础设施基础层的验证。他们教会了我们如何优化裸金属计算，并构建了AI云的基础。
第二类：需要快速行动才能生存的团队。 他们需要用更少的资源做更多的事，他们没有大型科技公司那样的大型基础设施团队支持他们，所以我们为AI实验室构建多租户云。
Recraft正在构建一个200亿参数的图像生成模型，但他们的训练会话不断被中断。我们的工程师直接修复了网络，直接给NiCkel打补丁，将训练速度提高了六倍。 Cursor需要访问Nvidia B300来完成他们的大型强化学习任务。他们是第一批在官方固件发布之前就大规模采用最新芯片的团队。所以我们快速行动，紧密合作。
我们将这些共同工程化的经验应用于许多其他客户，为英国两家最成功的生物技术初创公司加速药物发现，以及数十个其他团队——开发下一代图像AI的，如Black Forest；做机器人AI的，如Roda；做视频和世界模型的，如Descartes；以及加速研究的，如Core Automation。
对我们来说最大的奖励，是听到如此优秀、经验丰富的人不只是把我们当作供应商，而是当作合作伙伴。我们从这些团队学到，训练的真实成本不是GPU小时数。大规模训练会崩溃。所以我们构建了带有自动修复的健康检查，并为集群分配备用容量，以实现行业领先的可靠性，以及比某些大型云高达两倍的更好总拥有成本。 此外，他们需要最早获得最新硬件。所以我们大力投入，力争第一，尽早为他们提供只有少数提供商能做到的性能。
第三类：如果说AI实验室告诉我们训练一个好模型需要什么，那么下一类客户则告诉我们如何服务这些模型。 推理正在爆炸式增长，大家都听说了。推动这一趋势的是AI原生产品，它们已经服务于数百万用户并呈指数级增长。要成功，他们需要永不停歇的可靠推理基础设施。
但更重要的是，它支撑着他们产品的单位经济性。Hixfield服务超过2500万用户，在短短几个月内从零增长到数亿美元的营收。他们需要能够让他们非常快速、持续实验的开发者体验，以及非常高效的推理自动扩展，以应对峰值媒体需求。Brave每天提供超过1600万次实时AI摘要。他们最初采用自己动手的推理方式，只是租了集群自己运行系统，但后来转向了托管平台，因为我们能够改善他们的单位经济性。Sword Health为心理健康患者构建AI护理。当涉及敏感话题时，对用户来说高延迟感觉就像我们根本不在乎。通过使用Nebius的专用端点，他们能够将产品的端到端延迟从20秒以上降低到12秒以下。
所以对于这类客户，我们构建了Nebius Token Factory——一个托管推理平台，提供对所有模型的访问，针对每个用例进行优化。它基于我们在云中拥有的相同可靠基础设施和编排能力。推理优化是一个模型加系统级别的问题。我们将Nebius工程与我们宣布的两项近期收购相结合。其中一个是位于旧金山的Egan AI团队。他们专注于模型层面——先进的量化技术、稀疏注意力、内核级别，以及系统设计、编排、KV缓存。现在看来，我们拥有了一支相当强大的团队来交付推理，这一点得到了一些非常受人尊敬的人士的验证。
第四类：企业客户。 下一个教训是，只有当客户能够按照自己的方式使用我们时，我们才真正可用。并非所有人都从零开始，企业在走向成为AI公司的路上，不像AI原生企业那样灵活。他们不仅需要性能，还需要可信赖的基础设施。他们需要将智能体添加到现有系统和流程中的能力。
Revolut，全球最大的金融科技公司之一，拥有超过7000万用户。他们有大量AI智能体在非常敏感的数据上运行。他们添加了Nebius Token Factory来弥补现有提供商的不足。我们共同将他们AI开发的速度提升，并实现了65%更好的欺诈防护和41%更好的产品推荐。 另一个例子是Shopify。他们训练了推荐模型并构建了相当复杂的智能体系统。他们使用Sky Pilot来跨GCP和Nebius编排工作负载——这就是多云。Mastercard每天处理数十亿笔交易，他们将Tavily——我们最近收购的另一家公司——Nebius的智能体搜索集成到他们现有的流程中。现在他们不仅可以基于历史模式，还可以使用在线信号来检测洗钱。结果是更高的检测率和更短的响应时间。
这一切都发生在我们合作伙伴的生态系统中，因为这不仅仅是你如何构建产品，还有谁帮助客户提取价值。所以我们非常感谢所有早期冒险押注我们的合作伙伴。
大型组织面临的最大挑战甚至不是技术，而是运营模式和合规性。 所以我们构建了内置安全性、可观测性、成本控制和合规性的平台。我们也给了他们多种消费方式——通过控制台、API和SDK，配有文档齐全的操作手册，以及无锁定的100%可选标准和集成，使多云工作成为可能。团队可以将Nebius与他们已有的任何东西集成，并充满信心地构建。
我们为不同工程需求的不同类型团队塑造了Nebius。看一下这个：在基础层，最新最强大的GPU运行在我们自己的服务器和机架中。 在此之上，是一个功能强大的完整云平台，拥有强大的存储、自动修复、可观测性，一切高度集成以实现零性能损失，以及一套工具，包括我们自己的Slurm、Kubernetes、分隔符、无服务器和其他服务。在顶层，是AI运行时Token Factory，用于推理和模型微调，内置系统级优化和模型级优化。所有这些都有多种消费方式、安全性、合规性和可观测性。一个平台服务任何类型的构建者——AI产品开发者用于实验和发展产品，机器学习工程科学家用于将时间花在构建而非配置集群上，企业团队用于在受控条件下大规模运行AI。
Nebius能走到今天，要感谢我们有幸合作并从中学习的所有优秀客户。但这还不是全部。
我们刚刚展示和讨论的一切，是我们现在正在增长的。但我们想为即将到来的做好准备。也许我们还不知道如何交付的所有细节。这就是智能体（Agentic）新世界。让我分享我们如何思考AI基础设施的未来。
智能体正在呈指数级增长，再次改变我们的行业。 客户希望智能体以使产品可行的成本完成任务。Tokens将成为下一个基础设施层。人们将为结果付费，而不是为tokens付费。这对云提出了新的要求，我们需要应对。
一个智能体不只是一次优化的模型调用，它是一个循环。 它制定计划，调用工具和模型，观察结果，重试并继续，直到任务完成。今天，原型化一个智能体很容易。你可以把一个模型连接到几个工具上，让事情运转起来。但生产是不同的。运行一次智能体，与为组织中数千名用户大规模运行数千个智能体，是完全不同的。
小错误会不断叠加。 看起来不错的95%每次调用成功率，会转化为彻底失败。一个糟糕的计划可能消耗比预算多10倍的tokens。
那么云基础设施应该是什么样的？
第一，高性能推理——快速、成本高效，服务于许多并发稀疏任务。
第二，接地气的数据访问——实时网络搜索、提取和研究，为智能体提供上下文。
第三，编排——我们需要组织模型和工具之间的路由、重试、状态管理、持久执行，以及可以运行数分钟乃至数小时的任务。
第四，可观测性和评估——我们需要收集智能体计划了什么、做了什么、调用了哪些工具、什么失败了、花费了多少以及结果是什么的完整追踪。
第五，控制和安全——权限、沙箱和成本上限。
这是从无状态模型服务到智能体运行时基础设施的转变。
但当基础设施就位后，我们可以开始下一个循环。每个智能体在运行时都会产生大量数据——计划、追踪、成本和结果。当我们捕获所有这些数据时，我们可以开始系统性地、持续地改进智能体。就像今天我们优化推理端点一样，我们可以优化路由，改进提示和工具调用，降低成本。云平台不仅仅是智能体运行的地方，它成为使智能体可测量并持续改进的系统。
云还有另一个转变。一个新的角色出现了——智能体作为用户。 云平台过去是为人类用户构建的——阅读文档、点击控制台、手动部署和调试服务的开发者。智能体需要不同的云接口——API优先，可编程且可观测。 我们在一年前就开始朝这个方向迈进。我们通过MCP提供Nebius API，让智能体能够与平台交互。今年，我们正在开发Nebius Agent Echo，它知道如何在我们的基础设施上执行复杂任务。
但更深层的要点是工作负载优化。智能体的行为与人类不同——它们持续调用API，并行运行许多步骤，重试并优化成本和效率。这需要低延迟API、高效调度和成本控制。
为什么我认为Nebius能构建它？我们从硬件到API是垂直集成的，所以我们可以跨全栈优化智能体工作负载并取得成果。
目标很简单：我们需要让Nebius成为智能体能够有效使用的云。
真正令人兴奋的是，这是一片绿地。智能体AI对每个人来说都将是新的工作负载，对每个参与者来说都是如此。 没有数十年积累的经验。我们看到了新类型的开发者、新类型的应用程序，每个人都从零开始。当每个人都从零开始时，优势属于那些能够快速行动的人。
共同工程化——那就是我们这个房间里的人——提供AI产品的真实价值。这不会容易，但你做什么就得到什么。构建者能够解决这个问题，解决那些看似不可能的难题。我们Nebius将尽我们所能不拖累你们。我们继续以稳健的步伐构建面向AI的规模化云。
说到这里，让我请Arkady上台——我们的CEO，那个把我们推向极限的人——他将告诉大家他在哪些维度上推动我们。
Arkady Volozh — CEO & 联合创始人，Nebius
我想对Roma刚才说的内容做一个总结，也许稍微补充一点。就几张幻灯片，不是一个大型演示。
Nebius是什么
Nebius实际上是在做什么？我们在构建一个平台，一个算力平台。我们建造自己的数据中心，我们建造自己的机架，大家都知道。
最近，我们开始向下延伸技术栈，不得不在能源层面做一些事情，比如电网发电、Bloom合同等等。这是基础硬件平台。在此之上，我们构建云服务、推理服务、talking factory。现在我们正在构建一个agentic层。这些都是使Nebius成为Nebius自身的工具。
Nebius做什么，不做什么
所以，Nebius是一个算力平台与工具，服务于AI应用的开发者——那些真正创造AI的人。Nebius只是一个工具。
Nebius不做什么？Nebius不开发自己的模型，Nebius也不开发自己的应用。 那是我们的开发者客户在做的事。使用这些工具、使用这些算力的客户，构建出这些神奇的东西——无论是基础模型、消费者应用还是企业应用——这些才真正产生了价值，才是真实的产业。这才是AI真正创造价值的地方，在那里，一切都会变得快10倍、便宜10×10倍，或者多10倍。
如果这一切发生，整个生态系统就会运转起来，而我们离这一天已经非常近了。Nebius就是在这里扮演这个角色。
产品维度
Roma讲到了我们的二维空间。我们在构建产品——公平地说，主要是裸金属云、推理、agentics。我们为不同类型的客户开发这些产品，他们需要不同的东西，思考方式不同，说着不同的语言——无论是裸金属、购买GPU还是购买token。
这是不同类型的用户，他们是开发者或项目经理。现在使用AI的人远比使用传统云的人多得多。所以我们在这两个维度上构建，但还有第三个维度，那就是规模。
规模维度
我们在大规模地构建这些东西。
不到两年前，我们从一个10兆瓦的小型数据中心起步。我们说现在运行超过200兆瓦。我们最近表示，到今年年底，我们将达到800兆瓦到1吉瓦的运行功率。我们已经预订并签约了3吉瓦的容量，并表示到年底将超过4吉瓦。我们正在朝这个方向前进，非常接近了。
这就是规模，但规模不仅以兆瓦、吉字节来衡量，还可以以建设地点来衡量——差点忘了说这个。我们在欧洲、中东建造这些兆瓦和吉瓦级设施，印度和亚太地区也即将开始。当然，我们大多数已建和在建的项目都在美国。
重要的是，在我们签约的4吉瓦中，三分之二是我们自有的容量——是我们自己的土地、电力和厂房，不是租赁的。所以我们建立了一个相当庞大的系统。
GPU规模
这个容量，其规模可以用吉瓦来衡量，也可以用GPU数量来衡量。这里显示的是上半年的数字，但数字本身并不重要。我们正在建造的规模是数十万乃至数百万GPU。今天有多少公司能在公有云中提供数十万GPU？也许是三家超大规模云服务商，还有我们，也许还有其他人，我不确定。所以我们正在构建全球最大的公有AI云之一。
资金维度
这就是规模，但这个规模也可以用美元来衡量。有吉瓦，也有吉美元。
23个月前，我们从20亿美元起步，很高兴能以此为起点。这笔钱实际上足够我们开始预订所有这些容量，因为预订只需总资本支出的1%。去年我们又融了数十亿美元，开始建造这些数据中心。今年我们预订了数百亿美元的容量，这将使我们能够在今年建造吉瓦级GPU设施。现在我们在思考如何获得数千亿美元。
到目前为止，我们在融资方面非常有创意、非常高效。我们是最早（甚至是第一家）启动客户预付款模式的公司之一，这帮助我们带来了建设资金。我们也是最早签订大型兜底合同的公司之一，这使我们能够以较低成本为建设融资。当然，我们也有可转换债券和其他传统融资工具。
我可以向大家保证，我们将继续以同样的创造力和效率进行融资，很快就会有一些公告发布。但这是无限增长，我们需要越来越多的资金。建造这些吉瓦、数百万GPU需要数千亿美元，这是一个巨大规模的生产建设。
第四维度：时间
我想说，是的，我们在构建这个三维空间——产品、客户、规模，但还有第四个维度，那就是时间。
你无法把它放在图表上，但这个维度实际上就是公司本身的故事。下个月，我们将迎来成立两周年。我们创建了这家公司，汇聚了所有我们设法招募到的人才——那些来到我们这里的人，现在已经是数千人。所以，我们称之为第四维度。
正式宣告：不再是初创公司
借用今天这场活动的名称，我们决定应该做出改变——我们正式宣布，从今天起，停止称自己为初创公司。
我们创造了产品，我们以规模创造了它，我们为客户创造了它。正是客户，让这一切变得有意义。
我认为，现在是时候听听我们的一些客户的声音了。
Nebius 客户心声
Base CamP Research 正在构建生物学的互联网。 没错。
是的。
Robot Forces 正在打造机器人劳动力，承担那些人类不应该亲自去做的事情。 我们正在努力改善专业沟通方式。我们正在构建基础模型，以揭示关于大脑的全新生物学知识，从而改变痴呆症的发展进程。我们正在尝试赋予受监管行业加速软件开发的能力。
我们设计一种新分子，并在不到 24 个月内将其推向市场。这绝对是疯狂的——要知道，传统方式开发一种新分子可能需要七年时间。不，现在只需要 24 个月。
我们面临的主要技术挑战之一，是如何真正做好上下文工程，而不是不假思索地把所有内容都塞进上下文。制药行业通常需要大约 10 年时间和 20 亿美元。 我们必须综合考虑数据、模型和基础设施——谁能以超大规模最快速地提供算力，这正是 Nebius 发挥作用的地方。
Nebius 变得至关重要，是因为我们真正需要安全地扩展我们的 AI。 得益于 Nebius，我们能够在数周内完成模型的扩展。我们可以将时间从数月缩短到仅仅几个小时。 你们以我们希望的实验速度来支持我们。速度令人难以置信。 使用 Nebius，我们降低了大约 70%。原本需要两到三周的工作，我们可以在一周内完成。当我们开始使用 Nebius 时，我们看到 P99 延迟在 400 到 500 毫秒，这非常了不起。我们实际上一直在和他们沟通。
几乎每天都在沟通。
我认为现在是构建产品的极佳时机。 就在当下。有机会打造出被大量用户使用的产品。
到 2030 年，我预计我们将在生物学的所有领域看到真正伟大的进步。
我们将需要指数级增长的更多算力，才能将我们带到下一个层次。
找到那些与你同行的人，因为他们相信这个使命。这是一段非常令人兴奋的旅程。让我们出发吧。
行业圆桌讨论
旁白： 请欢迎《The Information》执行编辑 Amir Ifrati 上台。
《The Information》执行编辑 Amir Ifrati：
大家好，我叫 Amir，很高兴来到这里。这是一个非常好的切入点，从智能体层出发，探讨 Nebius 的客户——那些真正为 AI 用户提供产品的公司——是如何经历当下这个时刻的。废话不多说，让我们欢迎其他嘉宾上台。
嘿，大家好。
好的。当 Nebius 最初找到我，提出这个讨论的想法时，我以为今天的活动会和现在有所不同。我以为会是一个接一个的案例研究，讲述那些正在做他们以前认为不可能做到的事情的公司，甚至是六个月前还做不到的事情——这种情况依然存在，有很多可以聊的。但我认为我们现在处于一种……姑且称之为叙事转变的时刻。CIO 和 CTO 们谈论最多的是失控的成本、缺乏成本管控，这个话题似乎正在主导整个对话。所以我非常期待讨论这个问题，以及各家公司正在采取什么措施。
让我们为这个讨论做个铺垫。我想按顺序听取每位嘉宾的看法。我们先从 Database 的 Nikita 开始——你如何看待当下这个特殊时刻？这只是一个暂时的停顿、短暂的审视、重新考量或收缩？还是说，只要再过几周，等下一批模型出来，我们就会把这些都抛诸脑后，然后继续狂奔——比如，我们该把多少 API 调用量给 Anthropic 或 OpenAI？我们该把多少钱投给 Scott 和 Devin 以及那些智能体？请你先开始，并介绍一下自己。
Nikita（Database，前 Neon 创始人）：
好的，我叫 Nikita，我在 Database 工作。此前，我创立了一家叫 Neon 的公司，去年被收购了。我们处于所有 AI 编程智能体的下游消费端，为现代应用提供基础设施。在 Database，我负责运营一个数据库——也就是 Neon 演变而来的产品——以及一个应用平台。所以我与所有代码生成系统都有非常紧密的联系。
回答你的问题，我认为可以从两个视角来看：一是数据库视角，即大型工程组织内部在做什么；二是我们的客户在要求我们做什么。
先说客户——他们想要成本管控。我们刚刚经历了一个"token 消耗最大化"的小阶段，我认为我们还在其中。但随后，很多地方开始出现问题——尽可能利用 AI 对工程师来说固然重要，但也存在浪费性支出。所以人们想要搞清楚到底发生了什么。
从数据库的角度来看，如果你能把 AI 消耗通过 AI 网关来处理，我认为这是一个纯粹的基础设施观点：把你的 AI 消耗接入我们的 AI Unity Gateway，我们来告诉你发生了什么。从那以后，你就可以根据需要切换到其他模型，我们也可以为你托管这些模型，等等。这是 Database 纯粹从产品角度为客户提供的方案。
从内部来说，工程师的 AI 预算是无限的，"token 最大化"依然存在。大家可以带来自己的 AI 工具，大多数人在运行 Claude Code 或者类似内部版 Devin 的东西。我认为未来的走向是——我们会对工程师的生产力有更多可见性，当我们开始审视整个软件交付流水线，看清其中的瓶颈所在时。
《The Information》Amir Ifrati：
好的，谢谢。DataRobot 的嘉宾，请开始。
Venky — CPO，DataRobot：
当然。我是 Venky，DataRobot 的 CPO。我们一直非常专注于如何帮助企业真正重塑其工作方式，特别是与智能体协作的方式。就像智能体正在改变编程方式一样，我们思考的是如何在企业核心工作流中实现这一点，比如业务规划、安全合规、运营等方面。
在成本问题上，我们发现，当你开始看到这些东西真正投入生产时，它就不再是"每个用户每月多花 30 美元订阅费"这种小事了。你开始面对的是数百万美元的支出，突然间它成了一个大的预算项目。当"I（投资）"变得很大时，你自然要开始追问"R（回报）"在哪里。
所以现在大家都在重新审视：仅仅部署一个智能体就够了吗？它花费很多，但我到底得到了什么回报？
我们的观点是：在"I"这一侧，成本必须从一开始就作为核心设计原则来考量。在构建智能体、设计智能体、评估智能体时，你必须把成本纳入考虑。然后你要考虑如何选择合适的模型，以及如何在运行时优化——就像 Nikita 说的那样，根据意图路由到不同模型，确保你用的是最低成本的模型。如果你在自托管模型，你是否获得了最大化的利用率？这是投资侧需要做的大量工作。
而在ROI 侧，你必须选择有价值的问题来解决。你不能把每一个现有的工作流都塞进一个智能体框架，然后期待回报。你真的需要从头开始重新思考整个业务流程，以智能体原生的方式来重构。
《The Information》Amir Ifrati：
好的，我们稍后会深入探讨这个话题。
Narek，来自 Nebius，我在来这里的路上一直在思考我们所处的这个时刻。它真的让我想起了 10 到 15 年前公有云兴起时的情形。我当时在写关于 AWS 客户的报道，他们说："等等，我今年比预期多花了 2000 万美元。"那时候，2000 万美元是一笔很大的钱。所以这确实感觉是一个非常相似的时刻。你是否也有同感？在应用 AI 和客户成本方面，你认为我们现在处于什么位置？
Narek — Nebius：
是的，我认为成本问题是随着规模扩大而出现的。当你扩大规模时——是的，创建一个原型、展示一些结果非常容易。但如果你把这个原型扩展到数百个用户，经济账就会把你压垮。你需要运用一些技术来让它更可靠、更具成本效益。
我可以举一个例子。大约一年前，我们为我们的云平台创建了一个 MCP（模型上下文协议）。你可以把这个 MCP 接入我们的云，然后问一些问题，比如某个用户在我们平台上做了什么。使用 MCP，回答这个问题花了大约 15 分钟，消耗了 100 万个 token。 后来我们把它更新为一个 Echo 系统，其中包含了大量关于我们信息、API 等的上下文。同样的查询只需要几秒钟，智能体只消耗了几千个 token。
所以，不仅仅是使用模型本身很重要，优化数据层、为模型提供更高效的上下文同样至关重要。这将大幅降低你的成本。这正是我们在平台上看到的情况。
《The Information》Amir Ifrati：
Scott，我猜这些关于支出反弹的噪音对你来说可能是个好消息。你不仅通过对模型提供商进行抽象化来构建业务和产品，而且也非常注重结果导向。
结果优先。 告诉我们你如何经历这个时刻？你看到了所有这些头条新闻，看到很多客户、CIO 和 CTO 在讨论失控的成本。对你来说这是什么感受？
Scott — CEO，Cognition（Devin）：
是的，当然。我是 Scott，Cognition 的 CEO，我们构建了 AI 软件工程师 Devin。我非常赞同各位已经提出的所有观点。你确实看到了价格和支出增加到了一个让所有 CIO 都非常在意的程度。
我认为，从很高的层面来看，AI 是有效的，而且显然是值得的。
当我们谈论效率提升、能做到更多事情时，GPU 确实很贵，但也没那么贵。相对于你支付的 token 费用，与你获得的额外产能或产出相比，数学账算起来是非常清晰的——特别是与你支付给人类员工的费用相比，以及团队中每个人能多做多少事情相比。
我认为人们真正关注的是：如何真正衡量和优化这一点，如何从结果的角度来思考这个问题。 写 1 万行代码，对任何模型来说都比让人类写 1 万行代码便宜得多。但是，就像管理人类一样，管理智能体也是一回事——如果那 1 万行代码完全没用，用在了一个你从未真正发布或构建的任务上，那就完全是在浪费钱。
所以，更重要的是思考：我真正在推动什么实际结果？
人们谈到"杰文斯悖论"，我们在实际工作中确实非常明显地看到了这一点。每家公司都在构建更多、发布更多软件。 但他们想知道的是：发布这么多软件，我能获得什么具体回报？我如何衡量？也许是我的产品更快上市，从而获得更多收入；也许是我能给客户提供更好的体验；也许是我能更快、更好地构建内部工具，从而体现出更高价值。
重点不在于字面上的"一分钱一分货"，而在于确保你把 AI 引导向真正影响底线的用例上。
《The Information》Amir Ifrati：
你说得听起来很容易。但显然，在极大型企业里，存在很多各自为政的部门、不同的支出中心、成本中心、各做各事的不同业务部门。在早期的公有云时代，解决方案之一是集中化——建立某种中央决策机制来管理支出，而不是让每个团队各行其是。
能不能深入谈谈你们看到企业正在努力克服的组织层面的障碍？另外，我们上周在《The Information》刊发了一篇专栏，介绍了企业可以采取的一些基本步骤来降低成本。现在很多人都在谈论模型路由器，还有很多对成熟客户来说更容易实现、对不那么成熟的客户来说更难实现的方法。哪位想先谈谈这个？
Scott — CEO，Cognition（Devin）：
是的，正如你所说，说起来容易做起来难。在大型组织中，确实存在部门化的预算——这个能花多少，那个能花多少。
我想指出我们看到的几件事。
第一，对于很多支出，那些人们原本考虑外包或以服务方式购买的事情，现在发生了一种非常自然的转变：好，让我们想想如何用 AI 来做更多事情。这是一种更自然的替代方式。我实际上认为，很多大的收益来自于增加产出和提升产能，而不仅仅是削减成本。当然，还需要做一些工作，确保整个团队都清楚地知道收益来自哪里。但我认为这个过程正在很多大型企业中发生。
第二，关于模型路由，这是一个很好的观点。在 token 预算或资金预算的约束下，我们越来越看到，所有模型都在变得更好。在代码领域，最难的任务你仍然需要最聪明的模型——比如今天刚发布的 Fable，有些任务只有 Fable 才能完成。但现实是，软件工程师日常工作中，这类任务可能只占 10% 到 20%。对于另外 80% 到 90% 的任务，自然就会有一个问题：我如何确保我在使用更便宜的模型？ 有很多优秀的开源模型可以处理 50% 到 60% 的任务，速度快 10 倍，成本低 10 倍。显然，我会想要做出这种改进。
所以我认为模型路由正在成为越来越重要的一部分，而且这一趋势将持续下去。
the Information，Amir Ifrati：
你们能不能在某个时间点多谈谈开源的话题？好的，请继续。
Nikita（Database，前 Neon 创始人）：
我认为，对于大型组织来说，有一件事非常实际，那就是构建一个内部工具，这个工具对编码和非编码任务都有用。它可以是对 Claude Code 的一个轻量封装，也可以是更复杂的东西，但它肯定要通过 MCP 连接到所有内部流程，比如邮件、Slack，基本上就是所有工作发生的系统。很多工作显然是在生成代码，但也包括部署代码和运行 CICD 流程。这样做的好处是，因为每个人都在使用这个工具，你就拥有了更统一的视角。 当然，要做到这一点，这个工具在 Databricks 内部需要是有用的。这个工具叫做 Isaac。在 RAM 内部，我记得叫 Incept。当然，你也可以直接购买我们称之为 Devin 的现成工具。
一旦你拥有了这个工具，你就能从所有 AI 使用中获得大量的遥测数据，这不仅仅是你对 AI 的调用，而是实际上通过这个工具完成的工作。 一旦到了这一步，模型路由就成为一个真正可行的选项，你就可以开始把某些使用量导向更便宜的模型。基本上，一旦你走上了消费路径，并且端到端地覆盖了组织中发生的每一项工作，你就可以将其数字化，从而优化它——比如导向开源模型、选择不同模型，很多事情都可以发生。
你还会发现，瓶颈可能根本不在模型上。比如，现代 CICD 流程其实是有问题的。在 Databricks，我们有一段时间积压了很多 PR，它们要么在等待代码审查，要么在等待 CICD 流程完成。我们有各种图表显示并行堆积的 PR 数量不断攀升。所以我认为，当我们能够端到端地看到这些问题时，我们就会开始优化它们。而第一个前提条件，就是为你的组织构建一个工作真正发生的工具。
Venky（CPO，DataRobot）：
也许我会从另一个方向来谈，因为你是从组织层面开始的。我认为我们见过两种模式。我认为很多是自下而上的，人们自己拿起工具开始使用，最终他们倾向于将自己所做的事情自动化并加速，就像个人获得的生产力提升一样。但这些其实很难衡量。你当然可以定性地描述，但很难量化，因为你会说，我做了一个更好的演示文稿，质量更高，但不清楚如何衡量它。
所以我认为，我见过更容易衡量成效的地方，往往是更自上而下的方式。 比如 Chevron 是我们的客户，他们有一个直接向 CEO 汇报的团队，自上而下地推动，思考如何进行基于 AI 的转型。他们和我们合作，真正去解决那些极其困难的问题。他们的设施案例作为参考案例刚刚发布在我们网站上。
他们真正谈到的是：我们如何把以前无法整合在一起的东西整合起来？ 这就是人们所说的"角色坍缩"和"时间坍缩"——因为事情进展得更快，你可以做不同的事情。我们发现，将一个传统的推理模型、一个 Physics Nemo 这样做物理建模的模型整合在一起，去解决一个真正困难的工厂安全问题——这就是他们发现的价值。他们说：现在我们真的可以不用派人去进入气体泄漏现场了，因为他们现在可以用无人机安全地进行测量。 这是一种非常不同的方式，他们发现这是一个非常有趣的用例，真正改变了他们工作的经济逻辑。所以不是说节省了多少工程师，而是：我们正在建设一个未来的新设施，里面在气体泄漏现场工作的人会更少。这是一种完全不同的、自上而下的方法。
the Information，Amir Ifrati：
是的，我知道这里没有万能解药，但我觉得，那些极度成熟、运营大量数据库、知道如何在上面叠加 AI 来创建应用的公司，和那些处于重度监管行业、非常老旧、体量庞大、需要更多手把手指导的公司之间，似乎存在着相当大的差距。
我认为大家都在努力弄清楚，衡量结果、衡量 ROI 的最佳模型是什么，有哪些最好的案例？ OpenAI 和 Anthropic 可以说到嘴皮子磨破，告诉你应该怎么做。但是，有没有一些正在崛起的初创公司，能够提供正确的仪表盘？还是说会是那些传统的——我不想说传统——AI 领域的老玩家，包括你们自己，或者 Palantir 这样的公司，或者 Salesforce 这样的公司，会插进来说：我们是中间商，你需要我们来理清一切，知道如何路由到不同的模型，知道如何结合开源来实现你的目标。只要告诉我们你想实现什么，我们来帮你实现。 我只是想搞清楚这一点。
因为现在有一场巨大的争论：有人说，你只需要一套很好的数据库，多开几个数据库，在上面叠加 AI，就像 Snowflake 最近一直在说的那样，然后你就可以出发了，你不需要这个中间层。这是行业里目前一场巨大的争论，我很希望你们能发表意见。
Narek（Nebius）：
是的，我可以说。实际上，这是我们现在内部正在经历的痛点，因为我们正在为我们的团队启用 AI。我认为数据层对于 Agent 来说极其重要，需要针对 Agent 进行优化。 你可以通过为个人使用创建自己的 LLM 工作流来获得很高的生产力。但当你扩展规模时，你会意识到今天没有太多技术能帮助你，因为你需要一个语义层来向 Agent 展示、引导 Agent 了解公司背景——比如公司的术语是什么、公司的历史遗留是什么、历史是什么、流程是什么——而所有这些都分散在公司内部各种零散的数据源中，加上一半的信息在人们的脑子里，在那些邮件和聊天记录里。所以你需要一种不同的语义层来聚合所有这些。
现在，关于数据源的扩展问题： 你可以在个人生产力方面获得很多，比如我个人的 Claude，它能创建出色的分析查询，说实话比我们公司任何人都强。但我无法扩展它，因为它也包含了我个人的上下文。所以我需要一个中间层来连接所有数据源，并为公司提供共享的上下文。我认为公司应该走向"个人上下文 + 企业上下文"的模式，以实现真正的可扩展性。
the Information，Amir Ifrati：
是的，很高兴你提到了语义层。我们几周前实际上专门写了一篇关于语义层的文章，背景是微软的 Power BI 正在试图在其周围建立更多的围墙，让某些人更难进入——这里的"某些人"是指让客户使用 Databricks 或其他工具，将他们的数据从 Power BI 带入他们正在开发 AI 应用的整体环境中。
我很好奇你们对此的看法，以及这将如何发展。 在传统应用周围建立围墙和收费站，这种情况似乎正在发生。公司在财报电话会议上都在谈论这件事，这只是个开始。我不知道最终会走向哪里，不知道客户是否会反抗，或者客户是否能通过 Vibe Coding 的方式绕过它。我很想听听你们任何人对这一趋势的看法。
Venky（CPO，DataRobot）：
我会说，你可以设置收费站，有些人会逐渐接受，但我认为最终这行不通，因为客户会说：这是我的数据，这是我的知识产权。他们最终会找到正确的出路，他们会 Vibe Code 出去，会有替代方案，他们会去找别人，会有人说：嘿，不设这些限制也可以赚钱。 所以我认为这可能不是最难解决的问题，它会被绕过去。
Nikita（Database，前 Neon 创始人）：
是的，我其实亲身经历着这个问题。想想看，工作发生在哪里？是发生在 AI 工具里，还是发生在我的 SaaS 工具里？
Venky（CPO，DataRobot）：
没错。
Nikita（Database，前 Neon 创始人）：
那么，客户希望工作发生在哪里？归根结底，客户需要工作发生在哪里，这个东西就会在哪里落地。 你可以建起围墙，但如果客户想活在 Claude Code 里，那竞争对手就会提供一种能力，让你从 Claude Code 内部消费一切。
那么好，但你有你的 SaaS 工具，有数十亿的营收，这些东西怎么办？你当然必须两者都做，然后让人们在他们想工作的地方工作。你需要把 AI 引入你的产品，并确保——如果你幸运的话——你能提供比在 Claude Code 里消费同一产品更好的体验。如果你不幸运，你就会被去中介化。我认为每一家 SaaS 产品的拥有者，包括 Databricks，它既是数据产品也是 SaaS 工具，都必须两者兼顾，今天别无选择。至于未来会怎样，就让它自然发展吧。
Venky（CPO，DataRobot）：
举个例子，我们公司很多人现在用 Claude 来制作 PowerPoint 幻灯片，所以你不是在 PowerPoint 里做幻灯片，你实际上是在 Claude 里做，PowerPoint 只是一个导出机制，最后输出一个 pptx 文件。如果你对 PowerPoint 设置很高的壁垒说你不能用这个东西，那你就会用别的东西来代替 PowerPoint。顺便说一下，Claude 目前只支持 PowerPoint，还不支持 Google Slides，但等它支持了，我们就可以用任何一个了。所以关键在于，如果你在 AI 里工作，其他东西就变得不那么重要了。这就是你必须竞争的地方，我认为单纯地设置收费站是不可持续的。
the Information，Amir Ifrati：
好奇问一下，你们认为今天企业 AI 支出中，有多少比例是实验性的，或者说不被认为是核心必要的？有人知道答案吗，或者有什么猜测？
Scott（CEO，Cognition，即 Devin）：
我认为从支出的角度来看，说实话，现在实验性支出已经是相当小的少数了，因为那些被大规模扩展的工作流，通常是人们已经看到大规模有效的那些。从用例数量来看，确实有很多很多东西可以尝试，我们在合作的组织里看到这一点，内部也看到这一点。人们会尝试很多东西，会摆弄几个不同的用例，但显然，那些你发现"这个每次都有效"的用例，那种"每次我启动一个 Agent 去做这件事就能节省六个小时"的用例，才是被扩展 1000 倍的那些。 所以当我们谈论 AI 繁荣和消费量的巨大增长时，当然有一些"大家疯狂消耗 Token"的叙事，我相信这种情况存在。但我实际上认为，对于那些监控支出的组织来说，大多数已经到了将大部分支出用于真实用例的阶段。
Nikita（Database，前 Neon 创始人）：
尤其是编码，对吧？编码就是爆炸式增长。 对任何写代码的人来说，使用 AI 工具能让他们效率大幅提升，这是显而易见的，因此在这个特定类别上的支出简直是难以置信的。所以我认为这……
the Information，Amir Ifrati：
当然，但在某些情况下肯定是不可持续的。我们发布了一篇很受欢迎的文章，披露了 Meta 内部用于衡量这些成本的仪表盘，当时他们的工程师在谈论这件事，那个成本绝对是失控的。我不知道他们是 Anthropic 多大的客户，他们可能是前四大客户之一，现在可能还是。但我就是不确定事情有那么简单，我认为还有很多……
Venky（CPO，DataRobot）：
我认为在工程和编码领域，它已经证明了自己的价值，所以它是有用的，人们知道如何使用它，而且很多使用实际上是直接的生产型工作。但我会说，在很多其他用例中，情况完全不同。我们在传统行业看到很多这种情况，他们对 AI 或 Agent 的采用要早得多。我会说，在传统行业，超过大多数的支出可能仍然是实验性的——他们不是不花钱，他们在花 Copilot 的钱，在花 Gemini 的钱，在花流量的钱。个人生产力这块我认为是有的。但如果你想到关键任务型工作负载，编码是其中之一，那么在传统行业，下一个五个关键任务用例是什么？我会说现在还非常早期，还有很多实验正在进行。
the Information，Amir Ifrati： 底层模型的能力，与正在快速构建的各种"套壳工具"，以及人们今天实际使用它们的方式之间，差距有多大？
我感觉——也许只是我自己的感受——我几乎每天、肯定每周都在体验和听说新的使用方式。我很好奇这个差距有多大。
Scott（CEO，Cognition，即 Devin）：
我认为这真的取决于我们在谈论谁。旧金山的 AI 原生初创公司，我认为他们跟得相当紧。而企业美国，正如你所说，在某些情况下可能落后几个月，甚至几年，这是个大问题。 这是对很多企业采用情况的物理规律的重要提示。
人们问这个问题，很多 AI 公司有过那种疯狂的增长曲线，问题是这怎么可能增长得这么快、服务这么多？是可持续的吗？我的解读是：很多技术总是以浪潮的方式到来，这波之前是云计算浪潮，之前是移动，之前是互联网，再之前是个人电脑，等等。
我认为有几件事正在发生。首先，交付机制就是纯软件，所以公司采用和使用它要容易得多。
但我认为另一件事——正如你所指出的——是落后两年已经不再可以接受了。 如果你想想云计算的采用，很多很多公司就在最近几年才上云，他们刚刚把最后的系统从本地迁走。是的，你晚了五年、十年，但还好，我们用现有的东西撑过来了，也许早点来会更高效，但结果还不错。但在 AI 上晚五年、十年是行不通的。
the Information，Amir Ifrati：
你的例子是什么？在哪种情况下……
Scott（CEO，Cognition，即 Devin）：
显然是这样。
我认为很多企业也真的意识到了这一点。所以即使用相对的说法，晚六个月或三个月——顺便说一下，就可用的用例而言，这是很大的差距——仍然比我们以前见过的许多趋势快了一个数量级。
Narek（Nebius）：
我同意，并补充一点：AI 原生初创公司处于非常幸运的位置，他们没有历史包袱，他们从零开始。 历史越多、遗留越多，内部政治就越多，这意味着你需要越来越多的变革来适应。所以这真的取决于你的组织有多成熟——你越成熟，处境越艰难。
the Information，Amir Ifrati：
是的，甚至……
Venky（CPO，DataRobot）：
就拿编码来说吧，这可能是现在最成熟的 AI Agent 用例。如果你是一家有大型代码库、有团队的公司，然后你说：好，现在不再有那些不同的角色了，只有一个"构建者"角色，不再区分 PM、设计和工程。你必须重新组建所有团队，弄清楚怎么安排他们。这不是免费的。 但如果你是这个活动方圆 50 英里内的一家初创公司，从零开始，当然，你没有这些问题，或者你只有五个人，很容易绕过去。但如果你有 500 人、1000 人，重新组建团队、重新思考规划和工作方式，这是真实的工作量。
而那些还不理解这一切的人，只是因为他们还没有……适应得最好的最老的公司是哪家？我不太清楚。但在我们的客户群里，我会说是 Chevron，因为他们真的全力投入了，他们是真正自上而下地押注，这让他们非常不舒服。
工厂经理们会说：你们提议的这些我一个都做不了，因为有各种法规。但他们在推，他们建立了一个团队来推动。所以我认为每家公司都在以不同的方式尝试推进，但我认为我们深刻理解改变传统公司大量工作方式的代价有多大。
the Information，Amir Ifrati：
如果不谈谈 GPU 短缺问题，那就太遗憾了，你们 Nebius 的朋友和 Eric 对此再清楚不过了。我记得你们团队的 Mark 在上一次财报电话会议上提到了涨价的问题。我们也从很多初创公司创始人和 AI 产品创始人那里听说，现在外面的情况很艰难，很多算力都被大客户预定了。所以我很好奇，对你们自己，以及对你们的客户来说，有什么技巧？什么有效，什么无效？怎么拿到更好的价格？你们在做什么？
Narek（Nebius）：
这是个好问题，如何应对这个问题。我认为，如果你是 AI 的用户而不是构建者，你很可能处于可以使用开源模型的位置。
优化数据层也能让你从算力投资中榨取更多价值。 从基础设施和 GPU 的角度来看，可以结合多种类型的工作负载。你不需要为所有东西预留算力，对某些类型的应用你需要预留，但有时你可以大批量运行推理，就像 Shopify 做的那样，他们同时使用 GCP 和 Nebius 的可抢占实例，用于非关键工作负载。
所以有很多技巧，但核心思想是：你可以将你的工作负载类型映射到对算力的需求上。 对于大规模生产、可预测的生产，你需要预留。如果你使用类似"Token 工厂"的服务，可以从预留中榨取更多 Token，基本上是批量推理。你也可以将其与突发用量结合，这在特定情况下是可行的，尤其是如果你使用 Sky Pilot 这样的多云技术。
the Information，Amir Ifrati：
Scott，在剩余的时间里，我想请你带我们畅想一下五年后的未来，告诉我们你的 Agent 将会为我们做什么。我们还会有 IT 部门吗？会发生什么？
Scott（CEO，Cognition，即 Devin）：
五年后，我们都会在元宇宙里，不会有任何物理……开玩笑的。
我认为你真的会看到这个趋势继续下去。在旧金山说这话可能已经是陈词滥调了，但值得真正思考其含义。人们谈论 METR 研究，关于 Agent 能自主完成多长时间的工作：两年前，是 20 秒左右；一年前，是 5-10 分钟；现在我们在谈论几个小时的工作量，而且它继续沿着指数曲线增长。 我不知道最新的数字是多少，但我相信又翻了一番或更多。
如果你顺着这条曲线自然推演，问一个问题：如果它继续下去会怎样？那么你就在想：好，这个模型是一个可以完成数月工作的 Agent。 这几乎是一种不同的运营模式——你给这个 Agent 一整个计划，给它一个完整的目标，让它自己规划项目范围，思考如何完成目标，如何做所有这些事情。当你真正在天或周或月的时间尺度上这样做时，会是什么样子？我认为我们将会看到很多这样的情况。
the Information，Amir Ifrati：
举个你想让它做的月度项目的例子？
Scott（CEO，Cognition，即 Devin）：
这是个好问题。比如今天对于编码 Agent，是"这是客户报告的这个 Bug，去处理一下"，或者"我们刚写了这个功能的产品规格，去实现它"。我认为不久之后，会变成："从高层面来说，我们正在考虑优化我们的架构，想节省成本，想优化数据库。Devin，把这作为一个整体计划来承接，看看现在的情况，思考你认为哪里低效，然后构建你认为正确的一切，重新做这件事。" 不是一个任务，而几乎是一个开放式问题：我们应该做什么？你来告诉我，你去做研究，你来搞清楚。
我认为我们已经开始到达这个阶段了。 而且有趣的是，你越来越接近"想到一个想法，然后它就变成现实"，这是我个人非常兴奋的事情。我同意，我们将面临巨大的 GPU 短缺，请 Nebius 的朋友们给我们留一些。但我认为这就是我们将看到的，每一家企业都将能够构建更多，为他们的客户做更多。
the Information，Amir Ifrati：
在过去几个月里，你见过的最长时间跨度的工作任务是什么，让你感到惊讶的？
Scott（CEO，Cognition，即 Devin）：
我们见过有人运行了好几周的 Devin 会话，我不推荐这样做，有点像表情包行为了。但认真说，我们见过端到端的项目。比如对于我们的一些训练运行和项目，有些项目在一年前会是完整的实习项目，多周的实习项目，Devin 只用几天就完成了，它运行了所有这些东西，整理出一个漂亮的数据集，把结果交给你，真的令人惊叹。
Nikita（Database，前 Neon 创始人）：
听了这些，我有一个有趣的想法。我成长于各种基础设施项目的时代——数据库引擎、存储子系统，Pure Storage、Snowflake、Nutanix、Palo Alto Networks 这些公司，他们在构建基础设施产品。这些产品的决定性特征是什么？它们真的很难构建，需要很多非常硬核的系统工程师， 他们住在湾区，竞争非常激烈，可以去任何地方工作。而且通常每个这样的项目都需要很多年，构建一个企业级存储系统或数据库系统，端到端大概需要五年。
但这些系统还有另一个特性：它们可以被非常精确地规格化，因为你知道系统的 API 是什么，你知道数据库引擎是什么，你知道存储子系统是什么。 所以我认为这可能是一个构建更多基础设施系统的机会。如果你从零开始构建，从一个定义清晰的规格开始，你就可以深入设计你的系统，思考如何拆解工作，然后释放一支 Agent 大军去更快地构建这些东西。顺便说一下，我现在在 Databricks 已经看到了一些这样的情况，但我认为它将会是 10 倍、100 倍的规模。
the Information，Amir Ifrati：
你现在是在给我们做产品预告吗？
Nikita（Database，前 Neon 创始人）：
也许房间里有想要构建基础设施的创业者，我们现在确实生活在一个充满机遇的世界里。
the Information，Amir Ifrati：
好的，很棒。好了，时间到了，非常感谢各位先生。
Nebius客户顾问委员会公告
Marc Boroditsky — Nebius首席营收官
谢谢你，Amir、Scott Vanki、Nikita、Narek。听取客户的声音至关重要，能有像刚才台上那样杰出的领导者和高管与我们分享，是我们真正的荣幸。希望你们听到的是：这个差距是真实存在的——我们想用AI做的事情，与我们现有的系统、流程、工具以及企业就绪程度之间的差距。
为了实现我们的愿景，为了能够将合适的创新者、构建者和企业领导者的洞察带到桌面上，让我们Nebius能够从中获得灵感和理解，并将其转化为所需的输入，从而实现企业级和规模化AI的潜力——这个差距不在于雄心，而在于AI能做什么与组织实际上能够部署、信任和依赖的系统之间的差距。
正如我所暗示的，这需要跨整个技术栈的协作，而且不是那种一年一次在小组讨论中发生的协作，而是在我们构建过程中真实发生的协作——分享我们正在做什么、什么有效、什么无效，共同制定一套通用标准和可复用的架构。
Marc Boroditsky — Nebius首席营收官
为此，我很高兴宣布三项新举措，旨在汇聚我们行业中最有经验的构建者和从业者。
第一项是Nebius客户顾问委员会（Customer Advisory Board）的成立。 这不仅仅是一个头衔的集合，而是一个由来自整个AI技术栈的运营者、构建者和企业领导者组成的工作组。顾问委员会的使命很简单：帮助塑造生产级AI的未来。这正是我们今天在这里讨论的话题。
因此，我很荣幸介绍Nebius客户顾问委员会的首批成员，来自：Amy Black、Forest Labs、Cloudflare、Cognition、Cohere、Core Automation、Higgs Field、Recraft、Revolute和Road Out。他们中的许多人今天都在现场。事实上，如果你是其中之一，能站起来吗？好的，来了。谢谢你们站起来。请大家和我一起欢迎并感谢这些杰出的领导者的合作与承诺。顾问委员会是Nebius与上述公司建立合作关系的方式。
Marc Boroditsky — Nebius首席营收官
与顾问委员会同步，今天我们正式启动Nebius Fellows计划——这是一个由开发者、贡献者和社区组织者组成的网络，他们正在塑造AI真正落地现实世界时的样子。
我们的创始成员来自世界各地的城市，他们是vLLM和CNCF的贡献者，正在构建我们其他人所使用的AI Agent和评估框架。他们在全球各地举办聚会、黑客马拉松和研讨会，从特拉维夫到多伦多，从柏林到布宜诺斯艾利斯，从旧金山到新加坡。
为此，我荣幸地欢迎Nebius Fellows首届成员。向每一位Fellows，致谢。
他们做着令人难以置信的工作。我看过Waksa分享给我的一些他们的视频，能获得这样的社区支持是真正的荣幸。在我们朝着AI潜力构建的过程中，我对这意味着什么感到非常兴奋。
Marc Boroditsky — Nebius首席营收官
好的，最后，第三个项目——我想分享我们今天以预览版形式启动的全新构建者计划（Builder Program）。
这个计划面向刚刚起步的构建者，以及那些想要比周围基础设施跑得更快的人。无论是测试Agent、部署推理、学习技术栈，还是将想法转化为产品，你都将获得：Nebius和Tavily积分、课程、便捷访问我们功能的渠道，以及进入更广泛Nebius生态系统的路径。
现在可以在 dev.nebius.com 注册。
总结一下，我们正在新增三种重要的学习、协作和推进生产级AI的方式：我们的客户顾问委员会、Fellows计划和构建者计划。
Agentic拐点：从原型到生产就绪
Devang Sachdev — Nebius生态系统战略副总裁
下午好。感谢大家今天加入我。快速举手调查一下：有多少人已经构建或原型化了一个Agent？ 很好。如果你的Agent正在生产环境中运行，请保持举手。如果这些Agent有除你自己之外的用户，请保持举手。如果你不只是运行一个Agent，而是运行多个Agent，请保持举手。
好的，这就是我今天想和大家谈的差距。稍后会有一组优秀的嘉宾加入我们，帮助我们深入探讨这个问题。
但在开始之前，我想稍微为这场对话铺垫一下背景。一年前，我们问的问题是：我能构建一个Agent吗？ 从那以后，模型改进了，框架改进了，工具使用也改进了。但今天，我们问的问题是：我能在生产环境中运行一个Agent，或者10个，或者数百个吗？
你看，挑战在于大多数团队都原型化了Agent，但很少有团队能够成功且可靠地在生产环境中运行它们。
原因比你想象的更有趣。让我给你看一个真实的例子。
Devang Sachdev — Nebius生态系统战略副总裁
我们为医疗保健公司构建了一个合规审计Agent。这个Agent帮助合规团队对照约30个监管框架（GDPR、HIPAA、SOC 2等）审计他们的标准操作政策——可能有数百甚至数千条。
今天，我们将聚焦于一个非常具体的任务：FDA发布了一套针对AI赋能医疗设备的新指南，Agent的工作是找出哪些操作程序受到影响，并在Jira中提交修复工单。
让我们看看构建这个Agent时发生了什么。
构建原型实际上非常容易，几乎只花了我们一天时间，我想我们在午饭前就完成了大部分工作。而且一开始它确实有效。它使用GPT-4.5作为模型，LangChain和Deep Agents进行编排，Pinecone向量数据库进行检索。正如我所说，对于大多数任务，它开箱即用。
但对于这个特定任务——最新的FDA指南——它无法找到最新的那份。所以它使用了它已有的知识，完成了任务，但并没有完全理解触发该任务的变化是什么。这其实不是一个推理问题，而是数据新鲜度的挑战。
第一次迭代：解决数据新鲜度问题
Devang Sachdev — Nebius生态系统战略副总裁
于是我们添加了Willy，用实时Agentic搜索来为Agent提供数据基础。这只是对技术栈的一个改动。
效果立竿见影，Agent现在能够首先找到最新的FDA指南，并发现了47个受新指南影响的程序。它提交的工单数量也大约是原型Agent的两倍。
但两个新问题出现了：
第一，这个Agent增加了覆盖范围和范围。在发现47个受影响程序时，它不仅发现了与FDA指南相关的内容，还发现了一些与HIPAA和其他几个我们原本不打算让Agent关注的监管框架相关的内容。优先级不够清晰，留给人工来分类处理。
第二，你会注意到，仅这一次单任务运行就花费了约657美元。我们的工程师给我发了一条Slack消息说："这是真的吗？我们真的要花这么多钱来构建这个Agent吗？"这在生产环境中是完全不可持续的，至少对这个Agent来说是这样。
所以在解决了数据新鲜度问题的同时，我们暴露出了两个新挑战：一是范围过大，二是内在经济性问题。
第二次迭代：解决成本问题
Devang Sachdev — Nebius生态系统战略副总裁
于是我们尝试了第三种配置。我们换掉了GPT-4.5，用运行在Nebius Token Factory上的DeepSeek V4 Pro替代它。
成本立即从每次运行657美元降至约34美元，节省了95%的成本。 而且这没有经过任何后训练或微调。范围也有所改善，从47个发现减少到29个。
但又一次，两个新挑战出现了：
第一，运行时间实际上翻了一番，从半小时增加到约一小时，对于这个Agent来说相当长。
第二，当它提交带有特定严重程度的工单时，我们无法理解和解释其背后的推理逻辑。Agent在很大程度上是不透明的。
第三次迭代：达到生产就绪
Devang Sachdev — Nebius生态系统战略副总裁
于是我们继续尝试更新的模型，不断实验不同的模型，最终选定了Nvidia的Nemotron Ultra——他们上周刚刚发布，现已在Nebius Token Factory上提供。
我们还对技术框架做了一些其他改动：添加了LangSmith用于可观测性，以及来自Guardrails AI的Snowglobe用于用户模拟和对抗性测试。
运行这个特定配置后，我们看到：
成本进一步降至每次运行24美元
运行时间从一小时大幅缩短至13分钟
我们开始利用LangSmith的建议和Snowglobe模拟的数据来改善Agent行为
我们能够理解Agent在做什么、为什么这样做，并能引导Agent朝正确方向发展
在这一点上，这个Agent不仅在这个特定任务上表现良好，我们还在120多个具有已知基准答案的不同任务上运行了这个Agent及其他配置。这个特定配置表现最佳：近乎完美的召回率、高出20%的精确率，比闭源模型便宜约70-80%。
下一个前沿：规模化运营
Devang Sachdev — Nebius生态系统战略副总裁
你可能会认为这现在已经生产就绪了。确实如此，但我们发现了另一个挑战：我们可以构建和运行这一个Agent，但我们如何在生产环境中为数百个用户运行数百个Agent呢？
我们已经解决了运行时间和信任的问题，现在面临的是规模化运营的挑战。
让我们退一步，回顾所有四次运行，看看我们发现了什么。三件事格外突出：
第一，从原型到生产就绪的路径不一定是线性的，它实际上是一条成熟度曲线。 每次我们发现一个问题并解决它，就会发现需要新型修复和新型工具的新问题。因此实际上，正确的技术栈或正确的框架与正确的模型同样重要，因为两者共同作用才能产生正确的Agent结果。
第二，开源模型或开放权重模型正在迅速缩小差距。 对于大多数Agentic任务，开放权重模型开箱即用。在我们走过的整个过程中，我们没有进行任何重训练或微调。
第三，生产就绪与在生产中运行和持续改进并不是同一回事，尤其是当你运行数百个Agent副本时。这是下一个前沿，也是我接下来想与我们的小组深入探讨的话题。
圆桌讨论：AI Agent 的边界控制、评估与知识更新
主持人 Devang Sachdev（Nebius 战略与生态副总裁）：
现在请各位嘉宾上台。我们有来自 LangChain 的 Julia Schotenstein、再次来到现场的 Pinecone 的 Ash Ashutosh、Tavily 的 Rotem Weiss，以及 Guardrails AI 的 Shree Rajpal。感谢大家的参与。
Devang：
Shree，我想先从你开始。在某一次运行中，我们看到 agent 跑偏了——它开始去查找其他监管框架，而不是只关注既定的目标。在上线之前，有哪些手段可以让 agent 保持在既定范围内？
Shree Rajpal（Guardrails AI）：
这个问题问得非常好。我认为关于 agent 有一个很有意思的难题，那就是：在你真正开始部署 agent 之前，你甚至很难知道"范围"是什么，或者"超出范围"是什么样子的。 比如说，当你刚开始构建那个 agent 的时候，你可能会预期首先出现的失败模式是某种情况，但直到你用一些数据点、一些查询实际跑起来之后，才发现——哦，原来它是在这个地方跑偏的。
Agent 可能出错的方式，其"表面积"几乎是无限的，这正是构建 agent 与构建传统软件的核心区别之一。
我们对如何解决这个问题有非常明确的看法，而我们的很多思路都来源于自动驾驶汽车领域，那是多年来非常有价值的工作。在自动驾驶汽车中，问题空间是类似的——现实世界是无限的，而解决这个问题的核心方式就是仿真（simulation）。
与其先构建一个 agent，然后上线，再等某个用户以某种错误方式使用它，然后在生产环境中才看到失败，为什么不能提前模拟呢？在上线之前，模拟大量不同类型的用户查询，这些查询既要模仿真实用户，也要覆盖你之前从未见过的"偏轨"方式。这样就能帮你提前预判 agent 所有可能的失败方式。
这种模式在物理 AI 和硬件系统中已经被验证过，效果非常好。前沿模型实验室在构建模型和 agent 时也大量使用这种方式。我们也看到这种模式在你们构建的这类 agent 中越来越多地出现。
Devang：
Julia，你认为这种 agent 引导（steering），是一个编排（orchestration）问题，还是一个评估（evaluation）问题？不只是如何在上线前捕捉问题，还包括 agent 上线后如何持续监控？
Julia Schottenstein（LangSmith / LangChain）： 我认为编排和评估是紧密耦合的。原因正如 Shree 所描述的——你不再是用确定性代码编写 agent 逻辑了，而是使用一个框架和一个 LLM，让它在循环中调用工具。所以你无法精确定位某一行代码来告诉你 agent 会如何响应。
了解 agent 表现的最佳方式，就是写一些断言（assertions），明确你期望 agent 如何执行。
我们经常谈到"agent 开发生命周期"，它和软件开发生命周期非常相似——构建、测试、部署、监控——但对于 agent 来说，这个过程看起来非常不同，因为它是高度开放的。你接收的是自然语言形式的用户输入，本身就非常不确定，而 agent 的响应空间也是无限的。
所以你需要一套系统，能够快速迭代这个 agent 开发生命周期。这不只是编排问题，也不只是评估问题，而是要能够在上线前和上线后都进行测试，并且具备足够的可见性，真正了解 agent 最终交到用户手中时会表现如何。
Devang：
在运行这些仿真或评估时，你们会关注哪些指标？
Shree Rajpal：
好问题。我大致会把这些指标分成几大类。
第一类是产品或性能指标——agent 有没有在做它应该做的事情。
第二大类，我会称之为"防御性"指标——它是否造成了某种你没有预料到的危害？比如，如果它引用了不正确或不真实的来源，那就是在误导用户，同时也没有很好地完成任务。复杂的编码 agent 也是同理，它们有时无法很好地解决任务。
另一大类是：它是否可以被"越狱"（jailbreak）？它是否会造成某些伤害？能不能让它违反自己的护栏规则？ 这是另一大类指标。
这是思考指标的一个好起点。但我观察到的一个真实工作流是：你先构建一个 agent，对"什么叫成功"有一些初步的判断，但当你用更多数据跑起来之后，你会真正看到它的表现，然后才开始追踪新的指标。比如，你的客服 agent 移交给人工的频率太高了——这不是你事先就知道要追踪的指标，但当你真正看数据的时候，你就会意识到这是一个需要关注的指标。同样，它是不是调用了太多工具？成本是不是太高了？ 这些都可以构建成指标，但都是在你真正看到数据和行为之后，回溯性地建立起来的。
Devang：
在我们的测试中，加入仿真和 LangSmith 的建议，对提升 agent 准确率有很大帮助。换个话题，另一个大幅提升准确率的因素是我们加入了实时信息接地（live grounding）。这就涉及到知识的新鲜度问题。外部世界的知识在不断变化，是一个移动的目标。Rotem，你认为如何监控并维持 agent 始终拥有新鲜的知识？
Rotem Weiss（Tavily）：
我认为实时数据对于今天的任何 agent 来说都至关重要。就在两年前，你问"今天天气怎么样"或"昨晚比赛的比分是多少"，得到的回答是："对不起，我的知识截止到2021年，我无法回答这个问题。"今天还能接受这个答案的，大概只有下一代的……（笑）好吧，纽约有多少人。
说正经的，接地（grounding）最初的目的是：把模型连接到网络，让它能访问实时信息，至少能回答这些问题。 但我们现在看到的影响远不止于此——当你把 AI 连接到网络，你不只是获得了更新鲜的数据或更新鲜的答案，你真的能获得质量更好的响应。
要理解为什么会这样，我们需要看看今天的网络正在发生什么。到目前为止，人们是直接与网络交互的——你去 Google 搜索，你发邮件。但我们今天看到的是，人们通过 agent 与网络交互。这种转变正在把我们所知道的互联网推向两个层次：一个是更适合人类的互联网（也就是你今天所熟知的互联网），另一个是更适合机器智能的互联网。而我们正在构建的就是后者。
在思考这一层时，有四个核心支柱：Token 效率、准确性、新鲜度，以及延迟。不同的 agent 需要不同的权衡。像深度研究 agent，可能需要运行几个小时甚至几天，我不在乎它跑多久，我只要100%的准确率。但如果是车载语音助手，延迟才是最重要的支柱。
我们在 Tavily 构建的，正是能给你这种灵活性的东西，这与今天人类搜索的构建方式完全不同，也创造了一个巨大的机会。你可以把数小时的研究压缩成几秒钟。 举个例子，假设你在计划一次意大利之旅，你可能要去 Google 搜索地点、搜索活动、报名，然后自己把所有信息整合起来，这可能要花你几分钟甚至几个小时。Agent 可以在几秒内完成，它可以处理海量的网络数据，通过 LLM 进行综合，然后生成一个漂亮的结果。 这最终创造了一种新的范式——在这个网络搜索的新时代，更多的算力可以直接转化为更好的搜索结果。
Devang：
你提到了一个非常有趣的概念——"两个互联网"，一个给 agent，一个给人类。Ash，我想听听你的看法。在某一次运行中，我们看到 agent 消耗了可能数百万个 Token，而且它重复读取了之前已经检索过的信息。你认为我们是否需要一个以 agent 为第一优先级用户而非以人类或模型为优先级的检索系统？
Ash Ashutosh（Pinecone）：
是的。人类对机器是很宽容的。回顾 Pinecone 的发展历程——我们发明了向量数据库这整个概念，让人们可以在这些向量数据库上使用 AI 工具。2022年 ChatGPT 发布，Pinecone 随之推出，产生了有史以来数量最多的聊天机器人。但那时的用户是消费者，他们非常宽容。你给了错误的答案，没关系。你说"我不知道尼克斯队的比赛结果"，也没关系。
到了2023年，企业开始进入这个领域。企业没那么宽容，但他们终究还是人类。
去年9月，我们第一次看到了一类新用户，他们发出的 API 调用数量超过了人类——那就是 Agent。 而它们不宽容。它们接收你给的信息，相信那就是它们所拥有的信息，然后据此行动。
所以这不是 LLM 本身的问题，这根本上是一个错配问题——你要求 agent 执行任务，但你给它的是为人类构建的系统。这就是我们做的事——四年来，我们一直在为人类构建，然后这类新用户出现了，我们不得不从根本上改变这一切。
这就是我们在5月4日宣布的 Pinecone Nexus——对整个架构进行重构，专门面向 agent。
正如你所说的"两个网络"——我听说上个月，网络流量中 agent 搜索第一次超过了人类搜索，而这一超越在去年9月就已经开始成熟。
Pinecone Nexus 的核心模型是让人们能够做三件事：
第一，让 agent 能够表达自己的任务是什么；
第二，让 agent 以它能理解的方式——也就是结构化的方式——接收信息。 我不需要一首诗，我不需要音乐，我只需要一个精确的答案，因为我有任务要完成。
第三，就是解决数百万 Token 的问题，实现更高效的运行——这正是我们与 Nebius 合作的意义所在。通过将 Nexus 运行在一个计算经济模型上，我们测算的结果是：Token 减少了91%到95%，实际运行成本降低了80%。 这是我能向业务方说得清楚的 ROI，但这需要一套与为人类构建的系统截然不同的底层知识基础设施。 这就是核心所在。
Devang Sachdev — VP Strategy & Ecosystems, Nebius：
谈到对业务的影响。一个生产就绪的Agent意味着它可以被部署到生产环境中。而生产中的Agent意味着业务已经依赖于它。那么Julia，你认为我们跨越这道鸿沟的临界点在哪里？或者我们需要哪些指标，才能让Agent真正以自主方式运行——或者在一定程度上的自主、加上一些人工干预——从而让我们能够在规模化的情况下信任它们所做的决策？
Julia Schottenstein — LangSmith / LangChain：
是的，我们已经在研究Agent、或者尝试构建Agent很长时间了。差不多快四年了，这在这个领域已经算是很长的时间。而现在我们谈论的全都是Agent，这是我们使用的词。但去年，我们谈论的是**"agentics"（智能体化），我非常喜欢这个词，因为它更像是一个光谱**。当你在2023年刚开始使用最初的聊天机器人时，它几乎没有任何智能体化的特征。人们会谈论agentic RAG，在那里你的LLM开始做一些纠正性的选择，或者拥有更多的决策权，但它并不是一个Agent，它本质上只是一个聊天机器人。
现在随着我们的推进，模型变得强大得多，我们有了这些新的标准和互操作性。你有Agent和子Agent，可以采取行动，你现在将很多任务委托给模型，你确实开始看到越来越多的Agent在这个光谱上移动，变得越来越智能体化。而真正的问题并不是"它什么时候准备好进入生产"，这真的取决于具体的使用场景和风险程度。我们使用过deep agents，它是一个工具调用加循环的框架。很多企业仍然非常需要确定性。所以我们有一个叫做LangGraph的不同框架来帮助你——如果你需要这三个步骤100%的时间按照这个顺序发生，最高效的方式是代码，而不是LLM。
所以，这真的取决于使用场景以及你想要实现什么，取决于你对将任务完全委托给LLM有多大的容忍度。但如果你正在更多地向智能体化方向转移，你确实需要完整的"皮带加吊带"方法（即双重保障）。
所以这就是我们谈到的评估（Evals），我们谈到的可观测性（Observability），你还有护栏（Guardrails）。你从根本上无法信任这些系统，因为它们具有非确定性。因此，根据你的舒适程度、任务性质，你将采取不同的预防措施来确保它们生产就绪，尤其是在高风险场景中，比如企业环境，你面对的是容错性极低的终端用户。
Devang Sachdev — VP Strategy & Ecosystems, Nebius：
好的。让我再进一步提一个问题。我想我们还有几分钟就要结束了，但请各位给出你们的犀利观点（hot takes）。假设我们现在有一个Agent在运行，它正在做它的工作，我们现在要把100个Agent投入生产。你认为第一个会崩溃的东西是什么？我们从Julia开始。
Julia Schottenstein — LangSmith / LangChain：
可见性（Visibility），对吧？你将完全不知道发生了什么，会是一片混乱。
Ash Ashutosh — Pinecone：
是的，我会说是知识（Knowledge）这一层。当只有一个Agent时，你可以手动管理错误，你可以说，让我去重新编译一些东西，重新索引一些东西。100个Agent是一个知识基础设施问题。你不能让两个Agent尝试获取某些信息，却得到不同的结果，尤其是在企业中。它必须保持一致。如果做不到这一点，你就会失去信任。而一旦失去信任，你就永远无法进入生产。
Devang Sachdev — VP Strategy & Ecosystems, Nebius：
说得好。
Rotem Weiss — Tavily：
我支持，并且也认同可见性的观点。
Devang Sachdev — VP Strategy & Ecosystems, Nebius：
但你得表示不同意啊。
Julia Schottenstein — LangSmith / LangChain：
如果我们都同意，那就不是犀利观点了。
Rotem Weiss — Tavily：
但我还要补充一点，最终今天AI中最大的问题是搜索或组织上下文层。因为那些不学会如何利用自有专有数据的公司，将会被淘汰，因为在今天，这是他们在竞争中唯一的筹码。
Shree Rajpal — Guardrails AI：
我也会附和Julia的观点，你不会知道正在发生什么。但我还要说，当你运行100个Agent时，对它进行更新将会非常困难。你会发现，很难知道它是在变好还是在变差，你应该如何迭代它。所以，作为开发者让它变得更好的能力，在那种规模下会变得非常困难。
Devang Sachdev — VP Strategy & Ecosystems, Nebius：
我们有一些共识，但我仍然想在之后喝饮料的时候继续辩论这个问题，到时候再多聊。好的。
Ash Ashutosh — Pinecone：
你只让我们说一个。如果你让我们说两个，我们可能早就同意了。
Devang Sachdev — VP Strategy & Ecosystems, Nebius：
下次再说。好的，在我们结束之前，我想给在场的每个人留下一些今天走出这扇门就可以立即使用的东西。我们今天用来构建Agent的所有内容——生产基础设施、编排、可观测性、模拟、基础定位、检索——这些都是在生产中构建、运行和改进Agent所必需的核心层。而大多数团队在开始他们的旅程时都不得不重新发明这套架构。
因此，今天我们正式推出 Nebius Agents Blueprint（Nebius智能体蓝图）。这样你就不必从零开始原型开发。它是一个开放的参考架构，这意味着你可以使用我们创建的菜谱和操作手册，从原型Agent直接走向生产就绪的Agent。它可以在 build.nebius.com/blueprints 上获取。
至此，我想为我们的圆桌讨论画上句号。我还想特别提一件事：这个蓝图中所有的产品都是由今天在台上代表参与的各位所构建的，所以我要感谢他们。我也要感谢大家带来的精彩对话，同时感谢大家再次加入我们，希望大家今天余下的时间愉快。
Marc Boroditsky — 首席营收官，Nebius：
太棒了。感谢 Julia、Rotham、Ash、Sharia 和 Devon，为我们带来了一场精彩的关于智能体拐点的圆桌讨论。顺便说一句，蓝图只是一个开始，后续还有更多内容，我想我们都清楚，还有很多东西需要去构建。正如我们今天所分享的，随着市场向智能体方向演进，我们正处于这一拐点之上。我们正在根据从客户那里学到的经验、从合作伙伴那里获取的信息持续构建，以便在这场市场重大拐点中扮演举足轻重的支撑角色。
随着我们第一届 Nebius Inflection 大会即将进入尾声，有一件事对我来说非常清晰。正如我们所知，摆在我们面前的机遇是巨大的。但我想你们一遍又一遍地听到了这句话——这仅仅是开始，而我们肩负着让它真正实现的重大责任。
AI 的下一个篇章，不会由模型能做什么来定义。 它将由以下因素来定义：组织能够部署什么，企业能够信任什么，开发者能够构建什么，以及最终用户每天能够依赖什么。如果说今天的讨论让我得出一个结论，那就是：靠我们单打独斗，根本不可能完成这件事。 前进的道路，就在像今天这样的场合中延伸——人们在这里分享什么是有效的，构建者在这里坦诚相告，生态系统愿意共同承担超越任何单一公司的更大问题。
这种精神，正是我们创办 Inflection 的初衷。前方的挑战是真实存在的，每一次重大的技术变革都曾经历过这样的时刻。每一次变革，都是由那些**拒绝接受"困难等于不可能"**的人推动向前的。
我希望你们今天离开时，心中带着三个信念：协作不仅仅是有帮助的，它是不可或缺的；挑战固然重大，但并非无法实现；智能体 AI 的新时代已经到来，我们每个人都在塑造它的过程中扮演着自己的角色。
拐点，并不只是一场活动，它是一个时刻——在这个时刻，一个行业停止争论下一步是什么，开始承担责任，真正去构建它。当实验变成执行，当个人创新变成集体进步，这就是我们今天在这里开启的事业，这也是为什么这是一个拐点的开始。
我们很荣幸能够成为其中的一部分。代表 Nebius 的全体同仁——顺便说一句，这些是他们的照片——感谢你们共同的伙伴关系、你们的领导力，以及你们今天的到来。我们期待在下一届 Inflection 大会上与大家再相聚。谢谢。