本集简介
双语字幕
仅展示文本字幕，不包含中文音频；想边听边看，请使用 Bayt 播客 App。
构建有状态的应用程序需要协调跨数十个微服务的调用，而这些微服务的可用性特征各不相同。
Building stateful applications require orchestrating calls across dozens of microservices with variable availability characteristics.
你可以想象，状态管理在那里变得一团糟。
You can imagine state management became a big mess there.
想象一家餐厅里极其繁忙的厨房。
Imagine a really busy kitchen at a restaurant.
各种混乱正在发生。
All sorts of chaos going on.
现实世界是复杂的。
The real world is complex.
餐厅里到处都是各种混乱。
There is all sorts of chaos going on in a restaurant.
但归根结底，餐厅有着非常明确的目标。
But at the end of the day, there is a very clear outcome the restaurant is looking for.
每一份订单都会按照特定的步骤顺序处理。
Every order gets processed in a very specific sequence of steps.
最终，每个订单都会被准确地交付给客户一次。
Then eventually every order translates to being delivered to a customer exactly once.
这正是持久执行所提供的功能。
This is exactly what durable execution provides.
我们完全抽象掉了状态管理。
We completely abstract out state management.
作为构建订单管理系统开发者的你，只需编写你的业务逻辑，而我们则负责确保在系统各种混乱和故障情况下，每个订单都能被精确地处理一次。
For you as a developer building an order management system, you just code up your business logic and we are the execution authority of making sure every order gets processed exactly once in the presence of all sorts of chaos and failures in the system.
当一个AI代理在任务中途失败时会发生什么？
What happens when an AI agent fails halfway through a task?
如果是简短的提示词，你可以重新开始。
If it's a short prompt, you start over.
如果是耗时三小时、消耗数千个令牌的深度研究任务，你就损失了真实的钱和时间。
If it's a three hour deep research job burning thousands of tokens, you've lost real money and real time.
持久执行解决了这个问题。
Durable execution solves this.
这个想法始于2015年的Uber，当时两位工程师构建了一个系统，能够记住任何运行中进程的状态，并在故障后无缝恢复。
The idea started at Uber in 2015 where two engineers built a system that could remember the state of any running process and recover it seamlessly after a failure.
这个项目后来成为了Temporal。
That project became Temporal.
如今，Temporal为OpenAI的Codex提供支持，处理每一条Snap故事，并运行Coinbase和Yum!的交易。
Today, Temporal powers OpenAI's codex, processes every Snap story, and runs transactions for Coinbase and Yum!
品牌。
Brands.
随着AI代理的运行时间变长、自主性增强、重启成本升高，保证执行已从锦上添花变为至关重要的需求。
As AI agents get longer running, more autonomous, and more expensive to restart, the need for guaranteed execution has gone from nice to have to mission critical.
但规模只是故事的一部分。
But scale is only part of the story.
真正的问题是，代理时代究竟需要什么样的基础设施，以及目前还缺少什么。
The real question is what infrastructure the agent era actually requires and what it's still missing.
a16z的Sarah Wang和Raghuram与Temporal的首席执行官Samar Abbas进行了对话。
A16z's Sarah Wang and Raghuram speak with Samar Abbas, CEO of Temporal.
为了帮助观众更好地理解，你能再多介绍一下什么是持久化执行，以及它为什么重要吗？
Maybe to kick off just for the audience, can you share a little bit more about what exactly is durable execution and why does it matter?
Temporal 是一个开源平台，用于确保你的代码能够持久化执行。
So Temporal is an open source platform which ensures durable execution of your code.
这意味着，如果在你函数执行过程中发生故障，我们会记住所有的状态。
What that means is if during an execution of your function, if a failure happens, we remember all of the state.
然后我们会无缝且透明地在另一台主机上恢复该执行过程，连同所有状态一起，并从它中断的地方继续执行，而你作为开发者无需为此编写任何一行代码。
And then we seamlessly and transparently resurrect that execution on a different host along with that state and continue executing exactly where it left off without you as a developer writing a single line of code for it.
简而言之，这就是我们通过 Temporal 平台所要实现的核心价值。
So in a nutshell, that's the core value proposition of what we are trying to enable with Temporal as a platform.
是的。
Yeah.
在现代应用程序中，之所以实现这一点很困难，是因为现代应用由大量分布式组件组成。
In a modern application, reason this is hard is because a modern application consists of so many distributed parts.
对吧？
Correct?
没错。
Exactly.
因此，当我们思考我们所构建的核心原语时，它非常简单直接。
And so that's why when you think about the core primitive we are building, it's super straightforward.
但正如拉古所指出的，它现在可以广泛应用于如此多样的问题场景中。
But to Raghu's point, now it is so broadly applicable to such a broad spectrum of problems out there.
是的。
Yes.
为了更好地说明这一点，想象一下餐厅里一个繁忙的厨房。
To kind of bring this to life is imagine a really busy kitchen at a restaurant.
好的。
Okay.
对。
Yeah.
在任何一个夜晚，繁忙的餐厅可能都要处理数百份订单。
And at any given night, a busy restaurant is probably taking hundreds of orders.
每一份订单可能都不一样。
Every order might look different.
有些会更快准备好。
Some get prepared quicker.
有些则需要多花一点时间。
Some takes a little bit longer.
嗯哼。
Mhmm.
是的。
Yeah.
它们的进入方式并不统一。
They can come in not in a uniform way.
突然间，很多顾客涌入。
Suddenly, a lot of customers come in.
你可能会看到高峰
You might see spikes
订单的涌入很混乱。
It's of orders chaotic.
是的。
Yeah.
对。
Yeah.
但到了一天结束时，餐厅有一个非常明确的目标。
But at the end of the day, there is a very clear outcome the restaurant is looking for.
每一份订单都会按照一系列特定的步骤进行处理。
Every order gets processed in a very specific sequence of steps.
最终，每一份订单都会被准确地配送给一位顾客一次。
And then eventually, every order translates to being delivered to a customer exactly once.
这就是他们所追求的结果。
That's what the outcome they are looking for.
想象一下各种混乱的场景。
Imagine all sorts of chaos going on.
现实世界是复杂的。
The real world is complex.
餐厅里充满了各种混乱。
There is all sorts of chaos going on in a restaurant.
工作站可能会突然宕机。
Stations might go down essentially.
某个厨师可能去休息，或者新来的人没有关于准备工作已经进行到哪一步的任何信息。
And a particular chef might take a break or some new person come in without any context on how much of preparation has already been done.
餐厅真正关心的是菜单上有多少菜品，以及如何以特定方式准备每一道菜。
What the thing that restaurant cares about is how many items are on the menu and how to prepare each one of those items in a specific fashion.
但处理所有这些故障、应对这些突发情况，或者当工作站宕机或恢复时，如何确保你有足够的状态来从中断的地方继续处理订单？
But handling all of those failures, handling these spikes or handling all these failure cases of stations going down and coming up, or when failure happens, how do you make sure you have enough state to continue processing that order where you left off?
这些并不是餐厅真正关心的事情。
Those are not the things that restaurant cares about.
这正是持久化执行所提供的功能。
This is exactly what durable execution provides.
我们完全抽象掉了状态管理。
We completely abstract out state management.
作为开发餐厅订单管理系统的人，你只需编写你的业务逻辑，而我们保证每一个订单都会被处理，所有状态都会被妥善维护。
We completely, for you as a developer building an order management system of a restaurant, you just code up your business logic and we guarantee all of that state or each and every order gets processed.
我们是执行权威，确保在系统各种混乱和故障情况下，每个订单都恰好被处理一次。
We are the execution authority of making sure every order gets processed exactly once in the presence of all sorts of chaos and failures in the system.
我非常喜欢这个厨房的类比。
So I love this kitchen analogy.
你能举一个现实生活中的例子吗？
Can you maybe put into a real world example?
你知道，你和马克斯在Uber内部共同创立了开源项目Cadence。
You know, obviously, you and Max started Cadence, the open source project at Uber.
你能更具体地分享一下，当时在Uber有哪些实际的应用场景吗？
Can you share a little bit more in these concrete terms, maybe what some of the use cases were at Uber?
我和马克斯，有趣的是，我们都在2015年差不多同一时间加入了Uber。
Both me and Max, I think funny thing is we started at Uber within a month of each other, back in 2015.
Uber 正经历一场相当有趣的转型。
Uber was going through a pretty interesting transformation.
就像你所能想象的，任何初创公司最初都是从单体架构开始的。
Like, as you can imagine, like any startup, they started with a monolith.
随着公司高速发展，它开始遇到技术上的瓶颈，不仅影响了公司进一步扩张的能力，甚至在组织层面也出现了问题。
And at some point, the company started running because of the hyper growth, started running into both technical limitations of the next act to grow the company and even organizationally.
他们还希望开发越来越多的功能。
They want to build more and more things also.
因此，公司开始转向微服务架构。
So, this is where the company started moving towards a microservices architecture.
我认为他们走得非常极端，以至于我们加入时，公司的微服务数量比工程师还多。
And I think they went so extreme where by the time we joined, like, they had more microservices than engineers in the company.
是的。
Yeah.
所以，正如你所想象的，构建有状态的应用程序需要协调数十个微服务之间的调用，而这些服务的可用性各不相同。
So as as you can imagine, building stateful applications require orchestrating calls across dozens of those microservices with variable availability characteristics.
你可以想象，状态管理在那里变得一团糟。
And you can imagine state management became a big mess there essentially.
没错。
Right.
而且是在优步这样的规模下，更不用说了。
And at Uber scale, no less.
在优步的规模下，本质上就是这样。
At Uber scale, essentially.
因此，这促使我和马克斯说服了那里的管理层：哦，这个问题我们有办法解决。
So this is what kind of led both me and Max to convince the leadership there that, Oh, this is one problem we know how to fix.
这就是Cadence的由来，它是Temporal的前身，其核心理念是：你编写一个函数，我们为你保证持久性，并处理所有这些基础设施故障。
And that's what gave birth to Cadence, which was the predecessor for Temporal, as a platform where the whole idea is you write a function, and we take care of durability for you, and we handle all those infrastructure failures.
我们保证该函数从头到尾完整执行。
We guarantee execution of that function from start to finish.
作为开发者，你不需要操心这些。
You don't have to think about that as a developer.
这实际上开始让Cadence在Uber内部适用于更广泛的用例。
And that actually started opening up cadence for a broad spectrum of use cases at Uber.
其中一些很好的例子，简单如小费支付流程。
Some of the good examples there is as simple as tipping flow.
顺便说一下，这项技术可以非常渐进式地采用。
And by the way, this is a technology you can adopt in a very piecemeal fashion.
而Uber小费支付流程用例实际上就是一个很好的例子，我记得他们当时正在与南美洲的一家银行集成，其服务等级协议（SLA）要求是三天。
And Uber Tipping Flow use case was actually a very good example of that was or they were integrating it, I think, one of the banks in South America where the SLA was three days.
整个系统由Kafka驱动，这是一项处理海量数据流的强大技术，但用来重试单条消息长达三天就不合适了。
The entire system was powered out of Kafka, which is an awesome technology for processing large streams of data, retrying a single message for three days.
它并非为此类场景设计。
It is not designed for that.
没错。
Right.
所以，该团队最初的用例就是：尝试处理消息并调用银行API。
So, the very first use case there in that team is, Oh, you try the tip, like the message to process and the banking API call.
消息进来时，你尝试处理。
Where the message comes in, you try.
如果返回失败，而不是在那里不断重试，你启动一个重试策略为三天的Cadence工作流，然后就完成了。
If it returns a failure, rather than keep on retrying there, you start a cadence workflow with a retry policy of three days, and then they're done, essentially.
但随着时间推移，他们实际上彻底移除了整个平台——那些数十个事件驱动系统、数十个Kafka消息，并用Temporal完全取代了它。
But then over time, they actually ripped out the entire platform, which is dozens of those event driven system, dozens of Kafka messages, and replaced the entire thing with temporal there, essentially.
哦，Cadence。
Oh, cadence.
是的。
Yeah.
你提到了Temporal的另一个重要特性，对吧，那就是它非常适用于这些长时间运行的事务。
And You're bringing up an actual second important attribute of temporal, right, which is is very well suited for these long running transactions.
我们稍后会在现代场景中讨论这一点，但可恢复性和长时间运行的事务似乎是吸引客户的关键两点。
And we'll talk about that in the modern world later, but the recoverability and the long running transactions seem to be two things that are very attractive to your customers.
这让我想到那个极端的例子——Uber忠诚度计划。
So which is where I think the extreme end of that example was the Uber loyalty program.
嗯。
Mhmm.
嗯。
Mhmm.
比如，你去旅行。
Like, you take a trip.
优步赢了。
Uber won.
是的。
Yes.
对。
Yeah.
你乘的行程越多，积累的积分就越多，然后可以用这些积分兑换5美元的奖励或其他东西。
The more trips you take, the more points you earn, and then you can do those points for $5 rewards or other things, essentially.
整个系统都是基于Cadence运行的，为每一位优步乘客运行一个工作流，这个工作流永久存在，持续接收各种事件。
That entire system was running on top of Cadence, essentially, where you were running a workflow for every Uber rider, essentially, which is there forever, and it is just taking events.
每次有行程完成事件到来时，它都会向该工作流发出信号，而基于你行程数据奖励积分的全部业务逻辑都包含在这个工作流中。
Every time a trip completion event comes in, it is a signal to that workflow, and that whole business logic of awarding points based on your trip data is all captured within that workflow.
实际上，没有任何数据库支持这个系统。
There was literally no database backing that.
我们每个乘客的全部状态都保存在该工作流本身中。
Our entire state for each one of the rider essentially is kept within that workflow itself.
这种架构至少有一个有趣的特性：我记得曾经发生过一次事故，业务逻辑中有一个事件是行程完成。
And at least one interesting characteristic that you get of that is I think there was an incident where there was a business logic where you get an event for trip completion.
嗯。
Mhmm.
而业务逻辑中存在一个bug，会导致你的总积分重置为零。
And the business logic has a bug where it will reset your total credits, your points to zero.
嗯。
Mhmm.
很多积分都被重置了。
Lots of a lot of it resets.
这会让很多人不高兴。
That would make a lot of people unhappy.
是的。
Yeah.
所以这个bug somehow被部署到了生产环境。
So somehow that bug got rolled out into production.
然后突然在一个小时内，优步客服开始接到电话，询问我的积分去哪儿了。
And then suddenly within an hour, Uber support started getting call, where are my points eventually.
对。
Yes.
想象一下要从这种情况中恢复过来。
And imagine trying to recover Yeah.
从某件事中。
From something.
是的。
Yeah.
即使他们立即回滚并修复了未被触及的工作流，但那些被修改过的工作流已经损坏了。
Even even though they immediately rolled back and then fixed workflows which were not touched, But the workflow which were touched are already corrupted.
我认为，像Temporal这样基于事件溯源原理构建的系统，其中一个非常有趣的特性是：在停机期间，我们实际上开发了一个功能——因为我们知道工作流何时取得进展，所以能知道当时的构建ID。
I think one of the very interesting dynamics you get from a system like Tampol, which is built on the principle of like event sourcing, is we actually build a feature during that outage is, oh, because we know when the workflow made forward progress, what was the build ID.
哇。
Wow.
我们实际上可以重置工作流，回退到那个时间点，然后用新代码重新播放该点之后的所有事件，于是所有损坏的工作流都恢复了。
We actually could reset the workflow, go back in time and reset the workflow to that point and replay all of the events after that point with the new code, and suddenly you recovered all of the corrupted workflows.
是的。
Yeah.
哇。
Wow.
所以当你观察这个平台时，这就是Temporal作为平台的出色之处。
So like when you look in the platform so that's the awesome thing about Temporal as a platform.
我们解决了大量关于运行长期应用的难题。
We solve so much of the problems around worgening long lived applications.
从用户错误中恢复这些应用程序。
Recovering these applications from user errors.
而这些正是我认为几乎没有其他技术能够接近的领域。
And those are the things which typically I don't think there is any other technology which even comes closer when it comes to those class of problems.
我的意思是，如果你想想你提到的这个例子，比如客户流失，任何涉及客户的复杂工作流在中途失败后需要重来，其经济影响都是巨大的。
I mean, there's a huge economic impact if you think about even that example that you mentioned, right, churned customers, just any sort of complex workflow touching a customer that fails midway through starting over.
这种经济影响是巨大的。
The economic impact of that is huge.
是的。
Yeah.
你们有没有看过任何关于使用或不使用Temporal的研究数据可以分享吗？
I have has there ever been a study that you guys have seen, like, with or without Temporal that you can share?
我们通过Temporal Cloud实现的一个成果是五九级别的运营SLA。
One of the things we were able to deliver through Temporal Cloud is five nines of operational SLA.
不可思议。
Incredible.
我认为，首先你要衡量这种可靠性所带来的价值。
And I think, and first of all, like, what value you put to that level of reliability.
如果你去问问去年秋天经历过云服务中断的人，就会明白。
It's like if you go talk to people who experienced the cloud provider outages during fall of last year.
是的。
Yep.
太痛苦了。
So painful.
他们能清楚地告诉你经济损失有多大。
They can clearly tell you economic.
我们已经累了。
Were tired.
而且
And
我认为，去年我们能够实现的另一件大事是，归根结底，我们云产品的核心价值主张正是建立在这种可靠性承诺之上。
I think so that was actually one of the another big thing that we were able to deliver last year is we've been, at the end of the day, core value proposition of our cloud product is especially is built around this reliability promise.
在这些中断期间，我们提供了功能，可在整个区域大规模中断时确保您的业务连续性。
And during those outages, we have features which allows you full business continuity in the case of full region wide outages.
因此，我们有一个名为多区域命名空间的功能，使用该功能的用户能够将其命名空间故障转移至其他区域运行。
So, we have a feature called multi region namespaces, where people who were leveraging that feature, they were actually able to failover their namespaces to be powered out of different regions.
在这些中断发生期间，他们的服务中断时间仅有几秒或几分钟，几乎可以忽略不计。
And they didn't had more than few seconds or few minutes of disruption for the service while those outages were going on, essentially.
哇。
Wow.
哇。
Wow.
这确实如此。
That's a Yeah.
尤其是在运行这些关键任务应用时，这一点尤为重要。
Lot of Especially when you're powering these mission critical applications.
关键在于，如今，任何将应用程序投入生产的组织，都将构建这种业务连续性机制作为其路线图中的重要部分。
And that's the key thing is, right, like, today, like, you go talk to any organization which is now putting applications in production, just building these kind of business continuity things is a huge part of their roadmap, essentially.
当你开始在 Temporal 上构建这些功能时，实际上就免费获得了所有这些价值。
And that literally, the moment you start building these things on top of Temporal, are getting all of that value for free, essentially.
是的。
Yeah.
这对于那些寻求高可靠性和高可用性保障的人来说非常重要。
Which is very big for people who are looking for high level of reliability and availability guarantees.
对。
Yeah.
而且，我认为随着人工智能的发展，这些状态的需求只会越来越高。
And, you know, I think with AI, the states are actually only getting higher.
也许现在是时候转向 Temporal 在智能体领域的作用了，因为 Temporal 实际上正在为世界上一些使用最广泛的智能体提供支持，包括那些正在开发中的智能体。
And maybe this is a good time to transition to Temporal's role in the agentic space because, you know, Temporal is actually powering some of the world's most utilized agents currently and the ones, you know, in the process of being built.
所以，让我们对 Temporal 感到兴奋的，不仅仅是你们五六年前提前构建的产品，而是它如今的相关性可能比以往任何时候都更强。
And so I think one of the things that got us excited about Temporal is not just the product that you built five, six years ago, but its relevance to today is probably greater than ever.
你能谈谈这段历程吗？也许还可以分享一下你们正在支持的那些智能体？
Can you talk a little bit about that journey and maybe even share a little bit about the agents that you're powering?
我认为，从为什么Temporal如今非常适合代理框架以及正在兴起的新技术栈开始讨论，会非常有趣。
And I think just starting with why Temporal is so perfect for the agentic framework today and sort of the new stack that's emerging would be really interesting.
是的。
Yeah.
所以，在Temporal这里，我们的核心观点是：正如你所说，当前正发生一场巨大的平台转型。
So at least here is the thesis for us here at Temporal is if you think about I think there's a massive as you talked about, there's a massive platform shift happening right now.
对。
Yep.
那么，这场平台转型的核心要素是什么？推动它的因素是：过去我们构建应用程序的方式是，先有一个业务领域，然后写出一份产品规格，说明如何自动化某些业务流程。
And if you what are the core ingredients of that platform shift is, which is driving it is, yes, previously the way we used to build applications is, oh, there is a business domain, and you write a product spec about how to automate certain parts of business processes.
你跟工程师沟通，把这一切都交给他。
You talk to an engineer, pass off all of that one thing.
然后工程师将其转化为一个可用的应用程序。
And then engineers turn it into a working app or working application, essentially.
而在整个代理模式下，我认为这里正在发生两件事。
With the whole agentic way, I think as these models by the way, are two things happening there.
首先，这些模型是编码代理，是的。
First of all, these models, they are coding agents Yep.
是的。
Yep.
你现在可以生成这些强类型的应用程序了。
Where you can generate these strongly typed app now.
是的。
Yep.
因为是的。
Because Yep.
采用Temporal的门槛
The barrier
也在降低。
to adopt temporal also goes down.
对。
Yeah.
没错。
Exactly.
所以基本上，现在我认为会涌现出大量应用程序。
So basically, now I think, like, there will be a lot more apps Yep.
这些应用将专为非常具体的需求而生成。
Being generated, which is specialized for very specific needs, essentially.
另一点是，随着这些模型变得越来越智能，我们发现了一种新的东西，我们称之为智能体应用，也就是智能体循环。
And the other thing is, as these models are getting smarter and smarter, what we have discovered is new, what we call the agentic apps, which is the agentic loop.
是的。
Yep.
这意味着你有一个模型。
Which is you have a model.
嗯。
Mhmm.
你给它一个带有上下文和一组工具的提示，然后让这个模型自行规划并调用这些工具，以实现正确的业务成果。
You give it a prompt with some context and a set of tools, and then you let that model kind of plan and then make those tool invocations to give you the right business outcome, essentially.
尽管这是智能代理循环，但还存在第二类这样的应用。
Though it is the agentic loop, there's a second class of those apps there, essentially.
所以我认为这场平台变革正在发生。
So I think this platform shift is happening.
我们在Temporal公司所关注的有两个方面。
The thing we are excited about at Temporal is two aspects.
Temporal是一家极度关注开发者的公司。
Temporal is a company which is obsessed about developers.
归根结底，如果你看看公司面临的核心瓶颈，那就是开发者是否对平台感到兴奋并着手构建他们的下一个应用。
We, at the end of the day, if you look at what's a core bottleneck for the company is, oh, a developer getting excited about the platform and building their next app.
是的。
Yep.
我认为这场平台变革将带来的影响，以及我们已经开始看到的趋势是，会有更多开发者加入到这个行列中来。
And I think what this platform shift is going to do and which we already start seeing is a lot more developers are going to come in the fold of being developers now essentially.
而那些过去传统上不是开发者的普通人，现在也能自己构建这些应用了。
And which were traditionally or previously not developers can now actually build these apps themselves.
我们对这种可能性感到非常兴奋。
We are super excited about that possibility.
其次，构建这些应用的成本将大幅降低。
The second thing is the cost of building these apps is going to be significantly lower.
是的。
Yep.
是的。
Yep.
这意味着这些应用将大量涌现。
Means there is going to be an explosion of those apps.
这两点实际上正是Temporo的核心瓶颈。
Both of those things is actually the core bottlenecks for Tamporo.
更多开发者构建更多应用。
More developers building more apps.
最终，软件的核心价值将转向如何让这些应用真正投入运营。
At the end of the day, the core value of software is now going to be shifting towards how do you put those apps, make it operational.
是的
Yep.
有了企业为应对这场即将发生的应用爆炸所准备的所有保障机制。
With all of the guardrail where an enterprise is ready to handle this explosion of apps, which is about to happen.
我认为，正是这一点让我们的持久执行力能够独特地抓住这一浪潮。
And I think that is the thing that we feel durable execution is pretty uniquely positioned to capture that wave.
嗯
Mhmm.
是的
Yep.
是的
Yep.
不
No.
我认为你对智能应用未来发展方向所提出的观点非常到位。
I think you've you've made a great point there about where the agentic application universe is headed.
有趣的是，尤其是最近六个月，出现了一种转变：从那些社交寿命短暂的交互式智能代理，转向那些长期驻留在后台、执行大量处理任务的智能代理。
Interestingly, especially the last, I would say, six months, right, there has been a shift from these interactive agent applications that are socially short lived agents to these long duration agents that are just sitting in the background and doing a whole amount of processing.
因此，这一趋势对你有利，因为这些智能代理现在也需要你们为优步构建的相同能力。
And so that is a wave that's playing in your favor because those agents now need the same thing that you built for Uber.
它们需要持久性，需要长期运行的状态管理，需要能够应对各种突发情况并恢复，因为这些API工具调用会发出并可能在不确定的时间后返回。
They need durability, they need long running state management, they need to be able to recover for all sorts of scenarios, and these API tool calls go off and come back in an indeterminate amount of time.
因此，你们非常适配这一转变。
So you're very well suited for that shift.
完全正确，Raghu，如果你仔细想想，过去几年是人类向大语言模型发出提示并获取响应的阶段。
So a 100%, Raghu, is if you think about it, probably last couple of years was where a human is prompting LLM, getting responses.
而现在，我们已经看到转变：不再只是提供提示，而是赋予模型上下文和工具，进入智能代理循环——这些代理现在能为你自主完成工作，而无需人类持续与之交互，这意味着我们已经看到这些代理变得越来越持久，执行的任务也越来越有意义，且更加异步。
Now we have seen already seen the shift from that to now give it context and tools and now agentic loop, where now these agents are doing work for you also, essentially, without human kind of continuously talking to those, which means we have already started to see these agents are getting longer and longer and doing more and more meaningful work and more asynchronous.
正如Raghu所说，这正是这些代理的状态管理将成为重大挑战的地方。
And to Raghu's point, this is exactly where state management of those agents is going to become a very big problem, essentially.
智能代理的后台逻辑很容易映射到时间工作流上。
The agent group back gets mapped very easily to the temporal workflow.
是的
Yeah.
明白了，而且
Got And
所以，从宏观角度来看，正如我所描述的，我认为我们目前正处于智能代理的MS-DOS时代。
so we see at least the way I describe it, if you take a step back, is I feel we are in the MS DOS era of agents right now.
在这个时代，你有一个操作系统，你在这个系统上开发应用，并给予应用完全的控制权，因为它们运行在沙盒环境中。
Where you have an operating system, where you build these apps, you give it you give full control to your application because it's in a sandbox.
对吧？
Right?
是的。
Yeah.
归根结底，你们最多只会搞垮一台机器、虚拟机，或者说是沙盒环境。
At the end of the day, what you guys you can going to mess up only one machine or VM, essentially, or sandbox.
所以你们赋予它这些权限，但即便如此，人们依然看到了巨大的价值。
So you give it that access and but still there, people are seeing huge value.
是的。
Yeah.
一个很好的例子是 Cloud Code。
A very good example is Cloud Code, for instance.
比如，我敢肯定，假期结束后，每个人都对 Cloud Code 充满期待。
Like, I'm pretty sure everyone after the holidays is super excited about Cloud Code.
然后，是的，这是一个非常棒的代理示例，它运行在你的开发机或你正在使用的虚拟机上，实际上在为你做很多有用的工作。
And then, yeah, it's an awesome example of an agent which you run on your either developer machine or the VM that you are working on, and it's actually doing very useful work for you.
它开始接收指令，运行时间越来越长，但仍局限于单个 Yeah 的范围内。
It is actually starting to take instructions where it's actually running more and more longer lived, but still within the scope of a single Yeah.
沙箱。
Sandbox.
我认为，随着这些模型变得越来越智能，这是非常自然的。
I think it's very natural where these models get more and more smarter.
我们会用尽在单个沙箱内能做的事情，届时将出现一大群其他代理。
We will run out of what things we can do in a single sandbox, where there will be a whole swarm of the other agents.
我们已经有一些组织正在Tamporo上运行数百个代理。
We have already have organization who are already running hundreds of agents on top of Tamporo right now.
因此，我们已经看到各行各业正在向多代理技术世界迈进。
So we already see that industries kind of moving into a multi agent tech world.
是的。
Yep.
绝对如此。
Absolutely.
那么，这是一种横向扩展模式，还是每个代理都在执行不同的任务？
So are these is it a scale out pattern, or is it each agent doing a different task?
然后是否存在子代理，或者当这些客户使用数百个代理时，你看到的是什么模式？
And then there are sub agents, or what is the pattern that you see when these these customers using hundreds of agents?
我认为我们正在做的是大量专用代理。
So I think what we are doing, lots of specialized agents.
一个很好的例子是，假设有人正在开发一个应用程序，目的是我想预订下一次假期。
A very good example of that is, let's say if someone is building an app, which is, I want to book my next vacation.
到了这个时候，像这样的人并不想重新发明轮子。
And at this point, someone like, people someone that person don't want to reinvent the wheel.
当然。
Of course.
哦，现在已经有很多可用的API了，是的。
Oh, there is already lots of APIs available Yeah.
这些API已经实现了航空公司预订功能，或者内置了酒店相关的所有知识。
Which is doing reservation for airlines or rather who have all of the knowledge built for, like, hotels.
所以，尽管有人确实可以自己生成所有这些内容，但本质上为什么还要这么做呢？
So why would even though, yes, if someone wants, they can generate all of that, but why essentially?
这没有任何商业价值。
There is no business value in that.
所以我认为我们将看到，大量价值会转移到专门的代理上，这些代理真正做着有意义的事情，也就是说，你会越来越多地将工作交接出去。
So I think what we are going to see is, I think a lot of value will move to specialized agents, which is doing meaningful stuff essentially, which means that you will be handing off work more and more.
这些API将会变得越来越持久。
These APIs are going to get more and more longer lived, essentially.
没错。
Exactly.
然后你需要一个持久的远程过程调用（RPC）来将所有这些连接起来，以实现你所追求的业务目标。
And then you need a durable RPC to connect all of that together for building end business outcomes for the use case you are going after.
我们清楚地看到世界正朝着这个方向发展。
We clearly see the world moving in that direction, essentially.
我认为这是一个巨大的空白。
And I think that's a big gap.
对吧？
Right?
现在很多人还兴奋于这种DOS时代的模式：我只是在本地或沙箱中与我的代理对话并完成有意义的工作，但我们显然正朝着一个由大量代理协同解决复杂问题的分布式模型迈进。
Right now, are very excited in this MS DOS era of, oh, I'm just talking to my agent locally or within the sandbox and doing meaningful work, but we are clearly headed into a very distributed model of a swarm of agents collaborating together on solving complex problems.
是的。
Yeah.
专业化始终是世界发展的趋势。
Specialization is always the way of the world.
所以今年或这次没有任何理由会有所不同。
So there is no reason it would be any different this year, or this time around.
是的。
Yeah.
至少我看到的另一点是，这种人工智能非常类似于人类，对吧？
At least another thing that I see is at least this AI is very model similar to human, right?
这关乎上下文。
It's about the context.
是的。
Yeah.
你获得的上下文越多，就越能提供。
The more context you get, give that.
没错。
Exactly.
实际上，越不准确的东西反而会从中产生。
You the real, less correct things come out of it, essentially.
事情也是一样的。
And it's the same thing.
对吧？
Right?
比如作为一个开发者，如果我同时考虑所有事情，我肯定会写出糟糕的软件。
Like, as a developer, like, if I am thinking about everything at the same time, I am going to produce bad software.
我是一个非常注重第一性原理的人。
I'm a very first principle thinker.
没错。
Yep.
也就是说，面对一个复杂的问题，你要把它拆分成更小的模块，然后逐一解决这些小问题，最终组合成复杂的解决方案。
And which is you take a complex problem, you break it into smaller chunks, and then you work to solve these smaller chunks and compose complex solutions.
我认为这种智能代理浪潮正是朝着这个方向发展的，这也是我清楚看到世界走向的地方，我们
And I think this is exactly this agentic wave is moving towards, and this is where I think I clearly see the world heading We to
我完全同意你的观点，在我们继续讨论编码代理之前，既然你提到了，我想问个简单的问题。
totally agree with you, Before by the we move off coding agents, just since you brought it up, I wanted to ask a a quick question.
你实际上正在为世界上一些顶尖的代码代理提供支持。
So you actually are powering some of the world's top coding agents.
我不知道你能公开谈论多少个，但显然，OpenAI 就有一个。
I don't know how many of them you can talk about publicly, but, know, obviously, OpenAI has one.
目前市面上有多种不同层次的代码代理。
There's sort of many different layers of of coding agents out there.
基于你的位置，你认为这些代码代理长期来看有哪些区别？
Given your seat, what do you think differentiates these coding agents longer term?
为什么在这个领域中，持久性和可靠性如此重要？
And and why is durability and reliability so important in this space in particular?
让我们谈谈这些代码代理的一些特征，以及随着它们的发展，你希望看到哪些优良特性。
Let's talk about some of the characteristics of these coding agents and how they what are the good characteristics you want to see as they evolve, essentially.
这些代码代理的初始版本，人们只是将其视为代码补全。
Initial version of these coding agents was people thought of that as just TAP completion.
是的。
Yes.
是的。
Yes.
没错。
Right.
然后，我们会让公司里的开发人员去试试看编码代理。
And then, yeah, we will give our developers in the company, oh, go try out a coding agent.
他们说，我已经有代码补全功能了。
They said, I already have TAP completion.
我们已经走了多远。
How far we've come.
但尤其是假期过后，每个人都回来了。
But especially after the holidays, everyone came back.
Max在使用Claude 4.5时有了这样一个顿悟：编码代理已经不再是……我们显然正进入一个新世界，具备产品思维的工程师现在无需编写任何一行代码就能开发软件。
Max had this moment with Claude 4.5 essentially is, oh, these coding agents is no longer I think we are clearly entering a world where a product minded engineer is now empowered to produce software without writing a single line of code for it.
对。
Yep.
是的。
Yep.
是的。
Yep.
这是一个疯狂的世界。
And this is I this is an insane world.
所以我们明显看到的是，只要你提供了正确的上下文和提示。
So what we are clearly starting to see is you provided the right context and right prompts.
你就能解决非常复杂的问题。
You can get really complex problems done.
比如，编码代理会消耗大量令牌，我们明显看到它们开始工作得越来越久，是的。
Like, coding agents then burn a lot of tokens for we are clearly seeing they have started to work longer and longer Yeah.
为你生成正确的结果。
To produce the right outcome for you.
另一个明确的趋势是，这些代理将变得越来越持久。
That one clear dimension too is these agents are going to get more and more long lived.
没错。
Exactly.
你将在后台交接工作。
Where you will be handing off work in the background.
因为那时工程师的工作内容会突然变成，我认为具备代理能力的工程师会同时处理15件事。
Because then what an engineer would be doing is suddenly, I think the agentic engineer would be working on 15 things simultaneously.
因为他们基本上会着手处理一件事，然后给AI提供正确的上下文和提示，让它去完成某个任务，接着再转向下一个、再下一个。
Because they will be basically working on something and then giving AI the right context and prompts and stuff to kind of work on a task and move on to the next one and the next one.
AI代理在后台同时处理15件事，这就是我认为生产力将大幅提升的原因，我相信整个行业将看到的生产力提升将是惊人的。
The AI agent on the background works on 15 things for So that's where I think the productivity that's why I believe the productivity we are going to see in the industry is just going to be insane.
是的。
Yep.
是的。
Yep.
是的。
Yep.
当然，随着时间推移，这将是一次指数级的飞跃，相比今天。
So gonna be an exponential leap over time, of course, compared to today.
所以这就是为什么我可以举一个例子，比如OpenAI是如何利用Amporal，本质上就是Codex的。
So this is where, for example, if you one use case I can talk about is, like, about OpenAI, how they are leveraging Amporal essentially is Codex.
嗯。
Mhmm.
Codex正是如此，这些Codex代理正在后台协调各种工具，执行非常复杂的模式来完全独立完成任务。
Is Codex is exactly that where, oh, like, now these Codex agents are orchestrating various tools, very complex patterns for getting a task done completely in the background.
你的代码里什么都没有运行。
Nothing is running on your code.
所有事情都在后台被启动、测试和处理。
There is everything is being spun off, tested, and everything for you on the background.
你需要一个可靠的编排引擎来把这些东西串联起来。
You need a reliable orchestration engine to kind of tie all of these things together.
我们通常说，这些模型会告诉你该做什么，但你还需要一个执行权限。
So the way we typically talk about that is these models tell you what to do, but you need an execution authority.
展开剩余字幕（还有 480 条）
这个工作是如何完成的？
How does that work get done?
是的。
Yeah.
是的。
Yeah.
在大规模层面，这是下一个问题。
At a very large scale, that's the next problem.
对。
Right.
这就是Codex的使用方式。
So this is how Codex uses.
正是在这一点上，他们通过合理利用资源、应对突发流量和故障，同时在任何时刻执行数百万次Codex任务，从而充分利用了Stack Overflow。
This is exactly where doing millions of those Codex executions at any given point of time with using the right resources, handling spikes and failures, and all of those, this is exactly how they leverage Stack Overflow essentially.
我认为，这些编码代理最终会发展到你将越来越长的工作流交由它们处理的程度。
So my belief is these eventually, these coding agents are starting to where you hand off longer and longer streams of work.
而那些致力于实现这一未来的人，很可能将成为赢家。
And whoever is working towards that future is probably going to be the winner.
是的。
Yeah.
对。
Yep.
有道理。
Makes sense.
对。
Yep.
当然。
Absolutely.
可能还存在
There's probably a
成本方面的考量。
cost implication too.
对吧？
Right?
考虑到它需要大量的token。
Given how token intensive it is.
重新开始的成本。
The cost of starting over.
对吧？
Right?
没错。
Exactly.
管理状态的成本极高。
Managing state is extremely expensive.
是的。
Yeah.
重试。
Retries.
重试
Retries
来了。
coming.
重试。
Retries.
没错。
Exactly.
是的。
Yeah.
没错。
Exactly.
是的。
Yeah.
所以当我们和你的客户交谈时，除了编程之外，顺便说一句，编程代理，我认为你至少在轶事层面上已经主导了这个领域。
So when we talk to your customers, besides coding, which by the way, coding agents, I think you've sort of swept the field, at least anecdotally.
我们还看到很多人用你来做本质上相当于深度研究的工作。
We also see a lot of folks using you for what would be conceptually equal under for a deep research.
对吧？
Right?
我得去研究一下这个问题。
I have to go off and research the problem.
还有客户成功。
And customer success.
是的。
Yeah.
那么，你们在那里看到的一些常见模式是什么？
So what are some of the common patterns that you're seeing there?
我认为，深度研究就是一个很好的例子，说明了时间维度能带来很大价值。
So I think especially for deep research is a very good example of where temporal adds a lot of value.
对。
Yeah.
首先，正如你所说，你实际上消耗了大量的令牌。
First of all, to your point, you burn a lot of tokens essentially.
这很昂贵。
It's expensive.
在某些特性上，Temporal 作为平台为深度研究和代理型用例提供了支持。
And there are few characteristics where temporal kind of as a platform provides for deep research kind of use cases, agentic use cases.
其中一个特性是与人类的互动。
One of the characteristics is interaction with a human.
是的。
Yep.
因为很多令人惊叹的地方在于，顺便说一句，我整天都在和 AI 交流。
Because a lot of those of the things that is awesome is like, by the way, I talk to AI all day.
AI 会向我提问，并且等待我的回复。
And AI is asking me questions and waiting for my response, essentially.
对。
Yeah.
所以在它启动之前，就像其他部分的研究一样。
So before it kicked off, like other part of the research.
我认为，跨多次人类互动保持上下文并管理状态，以免丢失之前的工作，这是Temporal提供的巨大价值。
And I think so that maintaining that context across multiple human interactions and managing that state so you don't lose the work before, that's a huge value Temporal provides.
第二个有趣的特性是，如果你观察过深度研究，它会并行启动任务。
The second interesting characteristic, if you saw deep research, is that it kicks off things in parallel.
是的。
Yes.
对。
Yeah.
当你开始一个复杂的话题时，比如，让我抓取这个东西，或者调用API进行请求。
Where you start a complex topic, Oh, let me scrape this thing, or let me look into, like, call and make an API invocation.
所以它基本上会并行执行很多任务，然后将所有结果收集到下一步需要执行的流程中。
So it basically does a lot of things in parallel and then collect all of that into the next sequence of steps that needs to happen.
使用Temporal，为整个深度研究代理编写复杂的编排逻辑来开展研究、整合响应，然后再回传给用户，变得非常自然。
With Template so natural for coding up any complex orchestration logic for an entire deep research agent to conduct the research and consolidate the responses before reaching back to the user.
所以我认为，特别是为整个流程提供了可恢复性和状态管理。
So I think, and especially provided with recoverability and state management for your entire thing.
当然，另一个方面是这些深度研究现在也能持续进行，我已经看到这样的情况：我进来，给它我想要研究的内容，然后去煮咖啡。
The other of course thing is these deep research is now can also getting, I've already seen like, now I come in, give it my thing that I want to research, go make coffee.
等我回来时，它还在处理一些事情。
And I come back and it's still doing some stuff.
是的，完全正确。
Yeah, exactly.
所以它的生命周期确实变得越来越长。
So it is absolutely getting longer and longer lived.
然后，你消耗的所有代币，你绝对希望能在研究的任何阶段实现可恢复性。
And then all the tokens you are burning, you absolutely want recoverability of any point in research over there.
是的。
Yeah.
没错。
Yeah.
顺便说一下，回到Uber规模的这部分，作为投资者，我们惊讶的是，像深度研究这样的产品竟然如此迅速地达到了巨大规模，而目前除了Temporal之外，几乎没有其他工具能够处理这种级别的生产与扩展。
I think, by the way, the the just going back to the Uberscale piece of it, what we've been amazed by as investors is just how quickly products like a deep research have gotten to enormous scale, and you really don't have anything out there other than temporal able to handle that sort of production and scale at scale.
谢谢莎拉提出这个话题。
So thanks, Sarah, for bringing this thing up.
所以，我觉得这件事让我非常兴奋。
So if you think about this is the thing which I'm super excited about.
是的。
Yeah.
当我们构建持久化执行时，就像十五年前，我们所看到的基本上是业务交易。
Is when we build durable execution, like this is fifteen years ago, what the what we are seeing is basically business transactions.
嗯。
Mhmm.
我们现在正走在核心路径上，比如，每一个Snap，实际上Snap故事是我第二类使用场景，但每一个，比如说，基于事务的操作。
We are in the path of core, like, every for example, every Snaps actually, Snap Stories are my my second category of use cases, but, like, every, let's say, based transaction.
或者Yum Brands，也就是肯德基、必胜客、塔可钟，每次你下单，本质上都是一个Temporal事务。
Or Yum Brands, which is KFC, Pizza Hut, Taco Bell, every time you place an order, that's a temporal one, essentially.
哇。
Wow.
是的。
Yeah.
哇。
Wow.
但即便如此，这仍然是发生的企业交易数量的数量级。
So, it's but still, it's order of magnitude of how many business transactions which is happening.
是的。
Yeah.
例如，在Uber，那是出行规模。
For example, at Uber, it was trip scale.
有多少次出行，是的。
How many trips Yeah.
这太棒了。
Were So it's awesome.
这是一个巨大的量，而且由于我们正在构建一个基于消费的业务，我们非常关注这些交易的吞吐量。但接下来是另一类，我们称之为互联网规模。
It's a lot of and since we are building a consumption based business, we care about the throughput of those transactions, But then the next category is what we call as Internet scale.
互联网规模指的是像Snap这样的应用。
And Internet scale is things like Snap.
比如每一条Snap动态。
Like every Snap story.
你可以想象除夕夜，有多少条Snap动态被发布出来。
And you can imagine New Year's Eve, how many Snap stories are being posted, essentially.
每一条动态本质上都是一笔商业交易。
Each one of them is basically business transaction.
因此，我们对这一点感到非常兴奋。
And so we got actually pretty excited about that.
在过去几年里，我们实际上一直专注于一个问题：我们能否在这样的规模下运行？
And this is where the last few years, we've been actually focusing on, can we run at that scale?
我们去年取得的一项了不起的成果，也是我们工程团队引以为豪的成就：我们已经拥有一个云系统，能够随时应对每秒15万次操作的突发流量。
One of the awesome outcomes we have delivered actually last year, which we take a lot of pride on our engineering team on, We actually already have a cloud system which can handle spikes of 150 ks actions per second on a moment's notice.
哇。
Wow.
没有任何交互或其他操作。
Without any interactions or anything.
哇。
Wow.
太不可思议了。
Incredible.
所以我们一直非常关注这种互联网规模的问题。
So we've been kind of focusing a lot on basically this internet scale.
我们能应对吗？
Can we handle that?
有趣的是，去年，其实几年前，我和马克斯聊天时说，马克斯，看来我们在规模上过度设计了。
The funny thing is, last year, a couple of years ago, actually, was talking to Max and said, Max, looks like we have over engineered on scale.
这个用例是什么？
What's the use case?
我们哪里需要这么大的规模？
Where we're needing this much scale?
然后，当然，整个AI代理浪潮出现了。
And then, of course, the whole AI agentic wave happened.
现在你的试剂来了。
Now your reagents came.
我认为，如果你看看一些最大的实验室，他们都在使用我们。
And I think this is where, like, I think if you look at some of the largest labs use us.
而我们所谈论的规模，现在Snap Scale简直微不足道。
And the scale that we are talking about, Snap Scale is peanuts right now.
不可思议。
Incredible.
所以我们谈论的是完全不同的消费规模，这正是让我无比兴奋的地方。
And so we this is we are talking about a completely different scale of consumption, which we this is the thing which I'm super excited about.
这是我第一次走出舒适区。
This is the first time I am out of my comfort zone.
好的。
Okay.
现在我和马克斯在聊天。
Now I'm having a conversation with Max.
好的。
Okay.
我们如何实现百倍增长？
How do we 100x.
是的。
Yeah.
对。
Yeah.
我听说Snap Scale微不足道。
I've heard that I hear snap scale is peanuts.
这说法不错。
That's a good one.
是的。
Yeah.
是的。
Yeah.
是的。
Yeah.
另一个有趣的额外好处是，我直到开始和你们一起工作后才意识到：你们在工作流执行过程中会记录每一步的操作，对吧？
The other interesting side benefit, and I didn't realize that until we started spending time together, is you guys keep a record of every step of the execution, right, as workflow executes.
所以我们经常听到很多关于执行追踪的炒作和流行话题，尤其是针对代理和任何与模型交互的系统。
So there is a lot of we hear a lot of hype and popularity about execution traces for especially for agents and anything that interacts with models.
而这一切在你们的平台上都成了免费的附加好处。
All of that becomes is a is a free benefit on your platform.
是的。
Yeah.
对吧？
Right?
顺便说一下，我们实际上也会把整个公司都整合在一起。
And this is by the way, we actually bring the entire companies together too.
即使在AI出现之前，我们看到的情况是，当一个组织将Temporal作为其核心编排工具时，我们会把公司内部的人凝聚在一起。
Even before AI, what we used to see is, like, when an organization adopts temporal as their core orchestrator, we bring companies together.
把公司里的整个团队都整合到一起。
The entire, like, organizations in the company together.
因为人们会直接把我们的Temporal界面分享给他们的业务团队，展示某个特定的业务交易是如何映射到Temporal工作流上的。
Because, like, people literally share our, like, temporal UI to their business teams to show, oh, this particular because they will map business, business transactions to temporal workflows.
然后他们会直接发送工作流执行历史的链接，作为该工作流运行过程的可视化展示，以便在发现问题时能及时察觉。
And then they literally will send links to their workflow execution histories as the visualization of what that workflow was doing, and if they feel something is wrong, essentially.
因此，我们用于状态管理的事件溯源机制，其优势在于，系统中的所有内容现在都可以被审计。
So, this event sourcing, which is the mechanism we use for state management, essentially, it has this advantage of now everything in your system is auditable.
仅仅因为这种特性，你现在对业务交易有了前所未有的可见性。
And everything you get so much visibility into your business transactions now just because of that nature.
所以我们实际看到的，尤其是在AI应用中，当人们开始将智能体循环建模为Temporal工作流时，是的。
So what we actually saw, especially with AI, and when people start modeling their agentic loops as a temporal workflow Yeah.
这是因为这些代理完全是非确定性的。
Is because these agents are completely nondeterministic.
是的。
Yep.
对。
Yeah.
没错。
Right.
当你把代理循环建模为Temporal工作流时，Temporal工作流是一种非常棒的方式来实现持久化代理。
And the moment you model an agentic loop as a temporal workflow, and temporal workflow is an awesome way to kind of have a durable agent.
嗯。
Mhmm.
突然间，你就对代理所做的一切有了完全的可见性，没错。
And suddenly now you have full visibility Exactly.
你能清楚地看到代理的每一个行为，人们发现这非常有用。
Into everything your agent was doing, essentially, and then people are finding that to be super useful.
是的。
Yeah.
它在运行时很有用，在训练和优化代理时也同样有用，对吧？
And it's useful in runtime, it's just also useful in making the agent better, right, in training and
是的。
Yeah.
等等，是的。
So on and so Yeah.
所以它在这里具有双重优势。
So it has dual benefit there.
这真的很棒，拉古，你提到了这一点。我觉得我们拥有这些代理的执行历史数据量，足以最终开辟一个完全不同的数据分析和商业分析产品领域。
That is actually it's awesome that, Raghu, you brought that up is I feel like the amount of data we have of the execution history of those agents, I think we can eventually spin up a completely different product surface area for analytics, business analytics.
绝对如此。
Absolutely.
这是一片数据金矿，可以帮助我们弄清楚，我的哪个工具调用耗时最长。
It's a gold mine of data to kind of figure out, oh, which how which of the my tool invocation is taking the longest time.
是的
Yep.
是的
Yep.
没错
Exactly.
我的哪个工具失败率最高？
Which of my tool has the highest failure rate?
而且我们拥有所有数据，可以将这些执行历史全部输入分析引擎，以支撑整个商业模型。
And we can because we have all of the data, and we can run all of those execution histories to an analytics engine to kind of power all of that business model.
是的
Yeah.
可观测性也是我们系统的自然产物。
Observability is also a natural byproduct of our system.
是的
Yeah.
是的。
Yeah.
所以这很有趣。
So it's interesting.
我的意思是，我们经常谈论代理栈，有很多公司，一些了不起的公司来找我们，说他们解决了代理问题、代理栈的某一部分。
I mean, we talk a lot about agent stack, and there are lot of companies, amazing companies that come by saying we solve this part of the agent problem, agent stack problem.
如果你愿意这么说的话，你们解决了代理栈中的很大一部分，对吧？
You solve a massive amount of the agent stack, if you will, right?
显然，保持这些代理持续运行、长期运行的代理、可观测性、所有这些追踪数据，以及围绕代理的大量环境，都在你们的平台上得到了简化。
Obviously keeping these agents up and running, long running agents, observability, all these traces, a good chunk of all the environments surrounding an agent gets simplified on your platform.
顺便说一句，我觉得有趣的是，突然间，每个人都害怕，哦，SaaS死了，软件死了。
I I think, by the way, this is the funny thing is, like, suddenly, like, everyone is scared of, oh, SaaS is dead or software is dead.
你是个同性恋吗？
Are you gay?
公开市场确实如此。
The public markets certainly are.
是的。
Yeah.
所以我认为正在发生一些特定的动态，我们之前讨论过的某些事情正变得越来越普遍，那就是开发者数量的增加。
So I think there are certain dynamics which is going on, which is certain things that we talked about is more developers.
这是一个正在发生的现实。
That's a reality that's happening.
没错。
Yep.
应用程序的激增，因为构建应用程序软件的成本将会下降。
Explosion of applications because the cost of building an app software is going to go down.
这是一个现实。
That's a reality.
价值正在向哪里转移？
Where is the value moving?
我认为归根结底，我是这样看待这个问题的，至少我是这样合理化它的：大量价值将转移到API上。
I think at the end of the day, the way I talk about that is, at least the way I rationalize that is, a lot of value is going to move to APIs.
比如，如果有人想用智能代理构建下一个谷歌地图，他们大概能做到。
Like, yes, if someone wants to build the next Google Maps using agents, probably they can do it.
但谷歌用来支撑这些地图的所有数据，才是真正有价值的部分。
But all of the data Google have essentially power those maps, essentially, that's the that's the value, essentially.
同样的道理，像Stripe这样的公司也是如此。
Same thing, like someone like Stripe is yeah.
如果有人想构建下一代支付系统，也许他们能做到。
If someone wants to build their next generation payment system, maybe they can do it.
但Stripe拥有与所有供应商的全部合作关系，没错。
But Stripe has all of the relationship with all the vendors, all Yeah.
所以我认为，真正的商业价值将通过API和智能代理展现出来。
Of everything out So I think there is real business value, is going to be exposed through APIs and agents.
我认为，归根结底，就像我之前说的例子，如果有人现在有了关于下一代度假预订体验的想法，他们不会去重新发明整个航空预订API。
And I think at the end of the day, to my earlier example, like if someone is now comes in and have all some idea about the next generation experience for booking a vacation, they will not go and reinvent the whole airline reservation API at the end.
对。
Right.
他们还是会使用那里的某种东西。
They will still going to use something there.
所以，你不认为SaaS已经死亡了吗？
So So you don't think SaaS is dead?
是的。
Aye.
对。
Yeah.
所以在我
So in my
很多人对这个问题非常感兴趣。
A lot of people are very interested in that question.
是的。
Yeah.
没错。
Yes.
那是一个明确的陈述。
That's a definite statement right there.
我觉得我同意。
I think I feel I agree
与你们所有人。
with you all,
老兄。
man.
是的。
Yeah.
我恰恰相反。
I feel on the contrary.
是的。
Yeah.
想想我之前提到的所有其他核心内容：更多的开发者和更多的应用程序，我们将更快地实现世界的自动化。
Think all of this the other core things that I talked about, more developers and more applications, we are going to automate the world even faster.
嗯嗯。
Mhmm.
是的。
Yeah.
这将会带来巨大的冲击。
This is going to drive insane.
我们已经看到流量消耗量急剧增加。
We are already seeing insane amount of traffic consumption coming in.
哇。
Wow.
我们并没有看到它放缓。
We don't it's not slowing down.
它在持续增长。
It's increasing.
我认为所有这些应用程序如果通过API提供真正有价值的业务成果，将会推动更大的发展，是的。
And I think all of those applications are going to drive even more if you are providing the right valuable business outcomes through APIs, essentially Yeah.
你的业务将急剧增长，本质上是这样。
Your business is going to skyrocket, essentially.
嗯。
Mhmm.
现在我们来探讨一下智能代理栈的这个问题。
So now taking that question to the agentic stack.
如今一个现实是，如果你看一下当前市面上的智能代理平台，它们并没有什么差异化。
I one thing which is a reality today is a lot of if you look at agentic platforms today out there are not differentiated.
是的。
Yep.
同意。
Agreed.
而且我真心觉得，我们正处在一个飞速演变的世界中。
And and I honestly feel like I think we are in this world where we are evolving so quickly.
是的。
Yep.
当你对其中任何一个平台下注时，六个月内它就会消失。
By the time you take a bet on one of them, within six months, it will just disappear.
因为它们今天根本没有差异化。
Because they are not differentiated today.
没错。
Right.
所以这就是为什么我们在Temporal采取的策略是，我们不想再创建另一个平台。
So So that's why at least the approach we took at Temporal was we don't want to create yet another platform.
市场上已经太多了。
There are already too many out there.
我认为每个组织都需要根据自身需求评估并找到适合自己的平台。
I think every organization, based on their needs, they need to assess and find the right platform for them.
我们解决的是状态管理的问题。
We solve the problem of state management.
或者我们认为，这些代理将变得更加持久、更加关键、更加异步。
Or we believe these agents are going to get more long lived, more mission critical, more asynchronous.
我们解决了可扩展性、可靠性以及将这些代理投入生产的问题。
We solve the problem of scalability, reliability, and putting these agents in production.
这就是我们的差异化之处。
That's where we are differentiated.
因此，我们的策略是与所有人集成。
So the strategy we took was integrate with everyone.
是的。
Yeah.
当然。
Of course.
这就是为什么我在八月份与OpenAI的代理SDK进行了集成。
And this is where I think we did an integration back in August with OpenAI's agentic SDK.
我们与Pedantic合作，提供了一个Temporal插件，使我们能够在Pedantic体验背后作为状态管理的底层支持。
We partnered with Pedantic to provide a temporal plugin to basically where we could be the state management underneath the cover behind Pedantic as experience, essentially.
然后我们基本上在与所有人合作。
Then we are working with everyone, essentially.
我们有一个团队，正在为每一个主流平台构建这些集成。
We have a team who's kind of basically building these integrations with every popular platform out there, essentially.
我认为在可预见的未来，我们会继续走这条路。
And I think for foreseeable future, we continue to go on that journey.
是的。
Yeah.
我们正在投入的领域是，需要简化Temporal本身的使用体验。
And the area that we are investing into is we need to simplify the experience of temporal itself.
今天，我们的一大重点是整个开发者工作流程。
Today, one of the bigger focus area for us is the entire developer loop.
目前，我们明显看到人们希望构建一些东西，尝试一下，运行它，然后迭代。
Today, we we clearly see people want to build something, try things out, see run it, and then iterate.
我认为，如今这个流程中，应用逻辑和后端之间有着非常明确的分离。
And I think today that loop is today, we have a very clear separation between application logic and the back end.
我们希望将它们整合在一起，为开发者提供一个完整的闭环：构建应用、测试、运行，然后部署到生产环境。
And we want to bring that together, provide a fully closer developer loop of someone building an application, testing it, running it, and then deploying it to production.
是的。
Yeah.
因此，这将是我们的一大重点。
So that is going to be a big focus area for us.
而这也是我们可能与潜在的领先者合作的地方。
And this is where we put could potentially partner with a a potential winner out there also.
对。
Yeah.
顺便说一下，我觉得有必要跟进你提到的观点，即这个领域目前正在迅速演变。
By the way, think just to maybe follow-up on your point that there's just so much evolving in this space right now.
很难分辨哪些是沙子，哪些是石头。
It's hard to know what is sand, what is stone.
对吧？
Right?
而Temporal正在押注于，你们认为更稳固、更持久的方向。
And and, you know, Temporal is making bets on, you know, what you guys see as more set in stone.
但我想知道，如果你对所谓的最小可行架构或基础设施有什么看法，比如。
But curious what if you have, you know, a perspective on, is there an emerging sort of minimal, you know, minimal viable architecture or infrastructure, if you will, of, hey.
我想构建一个长期运行的代理。
I wanna build a long running agent.
我会用Temporal来管理状态。
I'm gonna have temporal for state management.
也许还需要一些可观测性层或代码沙箱。
Maybe there's some sort of observability layer code sandbox.
好奇你有没有看到大家在使用工具时有什么一致性。
You know, curious, like, what that if you're seeing any consistency in the tools that folks are using.
而且，你知道，也许人们一开始会用一些框架之类的。
And, you know, maybe there's things that people started with, right, frameworks, etcetera.
这些真的有必要吗？
Are those even needed?
好奇这些趋势是如何发展的，尽管显然这个领域还非常混乱和拥挤。
You know, curious how that's kind of shaping up even though, obviously, it's quite a chaotic and crowded field.
是的
Yeah.
完全正确
100%.
因此，一些模式已经开始显现。
So there are some patterns which have started to emerge.
例如，像沙箱这样的东西。
For example, things like sandboxes.
没错
Yep.
尤其是当这些代理现在可以访问工具时，它们可能毁掉一家公司。
Especially as these agents have now access to tools, it can destroy a company.
公司。
Company.
所以，我认为任何在生产环境中部署代理的组织，都应该投资于沙箱，要么自己构建，要么购买现成的。
So, I think if any organization basically rolling out agents in production better be investing into a sandbox or either building one or buying something.
我们也在观察到这一点。
We are seeing that.
是的。
Yeah.
完全正确。
Totally.
是的。
Yeah.
是的。
Yeah.
同样地，正如你提到的提示管理。
And same thing essentially is we you mentioned prompt management.
嗯。
Mhmm.
嗯。
Mhmm.
这是一个问题。
Is a problem.
是的。
Yep.
我们看到了。
We see.
因为提示词和评估的质量显然是我们看到价值的领域。
Because the quality of prompts, evals is clearly an area where we see value.
当人们开始大规模实施这些代理时，他们正在创造价值。
People are driving value as they start implementing these agents at scale.
你提到的另一个重要领域是可观测性。
Another big area you mentioned is observability.
由于这些代理完全是非确定性的，你最好能有办法发现问题，并在系统中设置防护机制，实现对这些系统的可观测性。
As these agents are fully nondeterministic, you better have a way to find out and have guardrails in the system and have observability into those systems, essentially.
因此，我们看到，顺便说一下，可观测性一直是个问题。
So we are seeing this is where, by the way, observability has always been a problem.
是的。
Yeah.
尤其是在云架构时代，甚至在代理时代之前。
Especially with even cloud architectures or even pre agentic era.
但这些代理将把可观测性的边界推到一个完全不同的规模。
But these agents are going to push the boundaries out in observability at a completely different scale.
绝对如此。
Absolutely.
对。
Yep.
嗯哼。
Mhmm.
我认为那里存在一个巨大的规模问题，需要有人提出一个创造性的解决方案，即：当这种大规模的代理和应用爆发发生时，如何合理化所有的可观测性需求。
And I think there's a huge scale problem there, which someone needs to come up with a creative solution of, okay, how to even rationalize all of the observability requirements when this massive agent explosion and application explosion happens.
是的。
Yeah.
企业现在是如何做到的呢？
How are enterprises doing that now?
主要是自研的，还是在使用外部工具？
Is it mostly built in house, or they're using outside tooling?
人们正在尝试。
People are trying.
至少我们看到，有很多解决方案声称自己是面向可观测性的智能代理方案。
At least what we see is there are a bunch of solutions there, which claiming that, oh, we are the agentic solution for other ability.
嗯。
Mhmm.
但我觉得，至少在我看来，这些方案在一定规模下会崩溃。
But, I think this is an area where people, at least I feel, are it breaks at certain scale.
对。
Yep.
有一种印象认为，整个SaaS都会坍缩为代理。
There is this impression that, oh, the entire SaaS is going to collapse into agent.
实际上，我不认同这种观点。
Actually, I don't share that view.
嗯。
Mhmm.
尤其是那
And especially That's
现在这观点挺强硬的。
a hard take these days.
是的。
Yeah.
请继续。
Please continue.
我的歌。
My song.
对。
Yeah.
如果你去和一家传统企业或银行交谈，比如说，它们有着某些非常明确的业务流程。
If you go and talk to a traditional enterprise or a bank, let's say, they have certain business processes, which is very well defined.
没错。
Exactly.
是的。
Yeah.
而且它们没有理由把这些业务流程迁移到这样一个完全动态的世界中。
And there is they don't want there is no reason to move those business processes to into this completely dynamic world, essentially.
这实际上会给这些组织带来巨大的风险，我认为它们短期内不会转向智能代理。
And it actually introduces such a gigantic risk to those organizations where I don't think they are moving to agents anytime soon.
根本没有必要把它们迁移到代理系统中。
There's no need to move them to agents.
这之所以被称为记录系统是有原因的。
There's a reason it's called system of record.
你不想丢失这些记录。
You don't wanna lose the record.
没错。
Exactly.
对。
Yeah.
所以我认为我们将看到这种分化。
And so I think we I think we are going to see the split.
对。
Yeah.
有些业务流程需要协调，或者以这种确定性的方式构建，并配备正确的防护机制和系统记录。
Or there are certain business processes which requires an orchestration or this deterministic way of building those and have the right guardrails and system of record.
所有内容都是可审计、可追溯的，等等。
Everything is auditable, traceable, and stuff like that.
但当然，也有一些场景是代理将大放异彩的。
But then there are, of course, examples where agents are going to take off.
每个领域有多大？
How big is each space?
现在谁也说不准。
It's anyone's guess right now.
但对你来说，好处是你在两个方面都适用。
But the beauty for you is you're applicable on both sides
而且确实如此。
of the And exactly.
这对我们来说是这样的。
And this is for us.
这就是为什么，至少当我们与那些传统企业的高管交谈时，我们会告诉你：我们能同时解决你的两个问题。
This is why at least our whenever we talk to, like, executives on those traditional enterprises, okay, we solve both problems for you.
归根结底，你想要一个能给你保证的协调者。
At the end of the day, you want an orchestrator which gives you guarantee.
你有一个系统记录，但通过执行权限，我们实际上赋予了他们执行权。
You have a system of record, but with execution authority, we basically giving them an execution authority.
是的。
Yeah.
关于你之前提到的，企业中围绕系统记录的大量业务流程都是由人工完成的，或者根本没人做，因为花费的时间和金钱太多，而现在智能代理可以处理这些。
To your earlier point, I mean, are so many business processes in an enterprise that surround the system of records that are done by humans, or not even done by humans because it takes too much time and money to do it, that agents can now do.
这些都成为你们的用例。
All those become use cases for you.
是的。
Yeah.
顺便说一下，我还想补充一点，特别是现在看代码代理时。
And by the way, another thing I would add there is, especially if you look at now coding agents.
现在，人们可以将任何业务流程转化为功能明确的应用程序，成本极低。
Now people can take any business process and generate very strongly typed application for it with very little cost.
我认为这也会带来一种张力：人们会评估，我们真的需要在这里使用智能代理吗？
And I think there is going to be this tension also where people are going to evaluate, do we really need an agent here?
还是直接开发一个新应用？
Or do you just build a new app?
因为现在开发一个应用的成本太低了。
Because building an app is so cheap now.
是的
Yeah.
顺便说一下，关于这一点，你大致提到了一个更广泛的观点，即用智能代理创造真正的商业价值。
By the way, just to hit on this, you sort of made this broader point of creating real business value with with agents.
而且，你也提到了上下文管理的问题。
And, you know, and you also, you know, touched on sort of context management.
如果我们不多聊一点上下文管理，那可就错过了重点。
And I I think it would be it would be a miss if we didn't talk a little bit more about context management.
上下文现在是个热门词汇。
Context is such a buzzword right now.
我们可能已经看到数十家初创公司声称自己是上下文层、上下文图谱或上下文工程师，等等，各种说法都有。
We've probably seen dozens of startups talk about being the context layer, context graph, context engineer, you know, sort of the the full gamut.
但我认为，你处于一个独特的位置，能够真正谈谈如何为智能代理提供最佳的上下文。
But I think, again, you're in this unique spot to really talk about how to best give agents context.
那么，你认为智能代理应该如何真正实现有效的上下文管理呢？
And, you know, what what do you see as the way for, you know, agents to to actually build proper context management?
对我来说，这是我们去年看到的最大惊喜。
For me, this was the biggest surprise we saw last year.
我和马克斯都一直坚信，Temporal 是一个非常有趣的用于数据编排的平台。
Both me and Max essentially we were a big believer that, Temporal is actually a pretty interesting platform for data orchestration.
是的。
Yep.
是的。
Yep.
而我们自己对这个领域不感兴趣，是因为归根结底，我们做的是按使用量计费的业务。
And we, ourselves, didn't get excited about that space is because at the end of the day, we are building a consumption based business.
对。
Right.
而且那里的使用量非常低。
And the volume there are super low.
比如，在任何给定时间，你到底有多少个数据管道。
Like, how many data pipelines you have essentially at any given point in time.
对。
Right.
真正让我们感到惊讶的是，当只有少数事情发生时，传统的数据编排解决方案并不能支撑上下文工程。
And the thing which actually surprised us the most is clearly when few things are happening, traditional data orchestration solutions are not powering context engineering.
因为它们并不是为这种规模设计的。
It's because they are not designed for that scale.
对。
Right.
是的。
Yeah.
对。
Right.
我们看到的另一点是，如今上下文来自如此广泛的各种来源，可能从API、Slack消息、Google文档中获取，或者有这么多类型的连接器，人们本质上从这些地方提取上下文。
The other thing we are seeing is now the context is coming from such a broad class of sources or maybe it pulls from an API or a Slack message, or Google Docs, or there's so many kind of connectors where people are pulling context from essentially.
每个人都有自己的可靠性特征。
Everyone has their own reliability characteristics.
我认为许多这些数据编排解决方案实际上并不好用。
And I think a lot of those data orchestration solutions don't actually work well.
它们在你拥有数据仓库时表现得非常好。
They work really well that you have a data warehouse.
没错。
Exactly.
是的。
Yeah.
所以它们是为这个设计的
So they're built
为了这个目的。
for that.
然后你就可以对这些数据进行各种转换，对吧？
And then you can then do all sorts of transformation on this Right?
为不同的流程设计的。
Designed for a different flow.
没错。
Exactly.
所以我认为我们所看到的是，这些代理应用程序的输入其实是实时上下文工程。
So I think what we are seeing is these agentic applications, the thing which is feeding them is real time context engineering.
我认为让我们感到惊讶的是，这一点的优先级非常高。
And I think that for the thing which we are surprised, that is super high.
这实际上是Amporo的一个重要使用场景。
This is actually one of the big use cases for Amporo.
那些拥有多种数据源、需要实时提取数据、进行处理并将其注入RAG或其他系统以增强提示上下文的用户，实际上就是在构建这些完整的架构。
People who have these different sources to pull out that data in a real time fashion, massage it, put it into rags or whatever to power context for your prompts essentially, is actually those entire architectures.
Temporal正是这些架构的编排器，而且它的吞吐量极高。
Temporal is orchestrator for those architectures, and it's insanely high throughput.
是的。
Yep.
哇。
Wow.
因此，正如你所说，我们把这些用例统称为检索，因为它们是从各种不同的场景中检索数据，以在正确的上下文中为这些大语言模型提供支持。
And so that's, to your point, essentially is we call these use cases, basically, collectively described that as retrievals or because it's retrieving data from a wide variety of use cases and to power these LLMs in the right context.
但至少对我们Tempo来说，这是一类相当有趣且有吸引力的用例。
And at least though, it's a pretty interesting or attractive category of use cases for us at Tempo.
是的。
Yep.
对。
Yeah.
人们担心上下文长度、上下文填充等问题。
People are worried about context length and packing the context and so on and so forth.
所以你所说的与这个问题密切相关。
So what you're saying is very relevant to that problem.
是的。
Yeah.
而我认为，我们在产品本身上的一个投资方向就是大容量数据载荷。
And this is where I think one investment area for us in the product itself is large payloads.
确实是。
It is.
对。
Yeah.
是的。
Yep.
如今，持久化执行在构建控制平面或编排一系列步骤方面表现卓越。
Durable execution today is awesome at building control planes or orchestrating, basically, sequence of steps, essentially.
我们不是一个用于传输大量数据的系统。
We are not a system to pass large amounts of data.
我认为，对于这类使用场景，我们显然需要有能力处理大容量负载。
And I think especially for these class of use cases, there we clearly see a need for us to handle large payloads also.
是的。
Yep.
这实际上可能是一个很好的过渡，因为你已经在为当今一些最优秀的代理提供强大支持。
Well, that's actually maybe a a good segue because you're already you know, you're firmly powering some of the best agents today.
我认为你刚才描述的，正是这些智能体为何能对任何个体客户真正有效的核心原因。
And I think what you just described is actually core to why these agents are actually effective for, you know, for for any individual customer.
我很好奇。
I'm curious.
你认为长时运行智能体的未来会怎样？
What do you think is ahead for long running agents?
比如，你已经开始看到或预期会看到什么趋势？
Like, what are you starting to see or anticipating that you'll see?
比如，你觉得呢，我们假设在2027年底再做一期播客，到那时，智能代理的世界会发生怎样的变化？
Like, what do you think you know, let's say we do another podcast at the end you know, in 2027, how will the world of, you know, agents change by then?
换句话说，你们最聪明的客户正在做什么？
What are your smartest customers doing, in other words?
是的。
Yeah.
你知道，就像拥有一个魔法八号球来预测，在这个世界里这超级困难。
You know, like, having a magic eight ball to kind of predict, it's super hard in this world.
是的。
Yeah.
我们会从你这里购买这个。
We'll we'll buy that from you.
是的。
Yeah.
是的。
Yeah.
但至少我们看到，这些代理正在开始承担越来越多有意义的工作。
But I at least what we see is these agents are starting to do more and more meaningful work.
是的。
Yeah.
这意味着它们需要突破自己的沙盒环境。
And which means they need to break out from their sandbox, essentially.
而世界显然正朝着一群代理协同工作的方向发展。
And then world is clearly moving towards a swarm of agents, essentially.
是的。
Yeah.
是的。
Yeah.
我认为这正是让我震惊的地方：拥有一个持久的RPC存在巨大的机会。
And I think this is where the thing which blows my mind is there's such a big massive opportunity is having a durable RPC.
你如何将这些被唤醒的代理连接起来，以实现状态管理呢？
How do you how do you stitch together these warm up agents essentially to basically doing state management Mhmm.
跨这个范围。
Across that.
我认为，至少在我看来，我们有一个名为Nexus的项目。
And I think this is where, at least I feel, we have a project called Nexus essentially
嗯。
Mhmm.
我们正试图推动一个行业级的标准。
Where we're trying to drive our industry wide standard.
比如MCP。
Even MCP, for instance.
MCP最初是围绕工具调用设计的，非常同步。
MCP originally started with tool invocation, which is very synchronous.
是的。
Yes.
首先，这是一个基本问题。
And first of all, basic problem.
现在，我有一个工具，我发出请求，但响应要三天后才回来。
Today, now I have a tool which I make a request, response comes back in three days.
对。
Yep.
对此还没有标准的解决方案。
There is no standard solution for that.
MCP开始研究异步方式来定义协议，至少是这样。
MCP started to look into asynchronous kind of defining the protocol, at least.
是的
Yep.
你如何实现这一点？
How do you implement that?
对
Right.
没错
Exactly.
所以我认为，Temporal 将是异步工具调用的一个绝佳实现，例如。
So I think temporal would be then awesome implementation for any asynchronous tool invocation, for instance.
我认为这些工具调用本身是非常自然的。
I think these tool invocation, first of all, is really natural.
这件事即将发生。
That's about to happen.
它已经在发生了。
It's already happening.
是的。
Yep.
但我觉得，大量代理之间相互交流的场景将会非常普遍。
But then I think the swarm of agents talking to each other, basically, we will see a lot of that.
专门的代理执行特定任务，而人们则协调调用数十个这样的代理，以实现正确的业务成果。
Specialized agents doing specific things, and then people are orchestrating calls across dozens of those agents to getting the right business outcomes.
然后突然间，你就面临了一个分布式系统的问题，没错。
And then suddenly, now you have a distributed systems problem Right.
在大规模的层面上，本质上是这样。
At a massive scale, essentially.
对。
Yeah.
因此，我认为持久化的RPC目前是一个非常关键但缺失的构建模块。
And so durable RPC, I feel it's a very key building block which is missing right now.
对。
Yeah.
行业内还有其他人在尝试为此建立一些标准。
There are others in the industry trying to introduce some standards around it.
你们是其中一员吗？
Are you guys part of that?
所以我们一直在努力。
So we we we've been trying.
当然。
Sure.
我们现在有自己的倡议，即Project Nexus，但我们实际上希望与之协调，因为我认为这是整个行业都在面临的共同问题。
And this is we have our own initiative right now with Project Nexus, but that's actually we want to coordinate with because I think this is a problem industry is seeing everywhere.
是的。
Yep.
我们非常希望与志同道合的人合作，推动这件事——我们不只想为Temporal做这件事。
We would love to work with like minded people to drive we we don't want to do it just only for Temporal.
对。
Yeah.
当然。
Of course.
我认为这是一个非常通用的问题，本质上应该作为行业标准来推动。
We I think it's a very generic problem, and I think that it should be driven as an industry wide standard, essentially.
是的。
Yeah.
对。
Yeah.
绝对如此。
Absolutely.
顺便问一下，根据你的描述，我有个问题。
By the way, just I mean, this is more of a question based off your description.
我们也开始看到，你可以称它们为子代理或这些专业代理。
We're we're also starting to see you know, maybe you call them sub agents or these specialized agents.
对吧？
Right?
而且它们更专注于特定的任务。
And and they're more focused on a particular task.
它们甚至可能在后台使用不同的模型。
They might even use different models under the hood.
对吧？
Right?
因为模型也会根据使用场景有所不同。
Because models have differentiation by use case as well.
但我想了解一下你的看法，因为这方面的变化真的很快。
But but curious if for your take, because this seems to be evolving a lot.
你认为这些发展主要发生在实验室内部，还是第三方应用能够利用多模型环境？
Do you think a lot of this development happens with the labs themselves or third party applications that can maybe make use of the multi model world?
或者，当然，还有第三种答案。
Or, of course, there's the third answer.
这要看情况。
It depends.
我认为詹森描述的这种方式是我见过的最贴切的比喻，整个平台芯片就像一个五层蛋糕，每一层都有其价值。
I think Jensen's described as the best way I've seen it is this five layered cake of this whole platform chip that's happening, and there is value at different layers, essentially.
是的。
Yep.
从电力开始，到芯片、云基础设施、模型，再到应用，本质上是这样。
Starting from, like, electricity to chips to cloud infrastructures to model and then the application, essentially.
对。
Yeah.
顺便说一下，归根结底，整个栈的价值将由应用层的规模来证明。
By the way, at the end of the day, this whole stack, the value of that stack is going to be proven by how large the application
当然。
Of course.
应用层有多大，本质上决定了这一点。
Layer gets, essentially.
因为那才是对客户最终的价值所在。
Because that's the end value to a customer then, essentially.
因此，我坚信我们已经讨论过的这种应用，比如Abridge，它正在做着出色的工作，确实如此。
And so I'm a big believer that this application we have already talked about, like, things like Abridge, which is doing amazing work, essentially Yeah.
让医生能够专注于患者，而不是做记录。
Around where doctor needs to focus on patients, not transcribing.
是的。
Yeah.
没错。
Exactly.
对。
Yes.
我非常欣赏他们的使命。
And I really love their mission there.
同样地，就像我们之前提到的法律领域，我认为这种应用
And same thing, like, we talked about even up, like, legal, and I think this application
是的。
Yeah.
比如Harvey这样的人。
Someone like Harvey, for example.
对吧？
Right?
Harvey。
Harvey.
是的。
Yes.
而且这将在大规模事件中显现出来。
And we this is going to show up in a mass affair.
没错。
Yep.
而这将证明我们所有人价值。
And which is going to prove the value of all of us.
我可以这么说，我们所构建的东西将由这一层得到验证。
What we are building is going to be proven by that layer, I can say.
关于 Bayt 播客
Bayt 提供中文+原文双语音频和字幕，帮助你打破语言障碍，轻松听懂全球优质播客。