深入解析优步的AI基础设施

但我们不想限制工程师，即使他们正在做的是正确的项目用途，他们也应该能够花他们需要的任何钱，因为最终我们想最大化从中获得的收益。

But we don't want to restrict engineers even if they're working on, if this is going to the right project use, they should be able to spend, whatever they need because ultimately we want to maximise the gain from this.

但你也想确保有负责任的使用。

But you also want to make sure there's a responsible use.

所以我们尽量把跨层级所需的文书工作减到最少。

So we try to do the minimal amount of paperwork needed to cross the tiers.

他们会看到在所有工具中，他们在那个框架内以及所有框架中花了多少钱。

And they will see across any of our tools how much they're spending within that harness and across all the harnesses.

而且我们为不同的托管代理设置了不同的层级。

And we also have different tiers for different managed agents.

所以，比如，对于所有交互式层级、交互式框架，我们有一些消费层级。

So, like, then for all of the interactive tiers, interactive harnesses, we have some spent tier.

对于我们的一些后台编码代理，我们有独立的层级。

For some of our background coding agents, we have a separate independent tier.

所以我们确保他们能轻松管理所有这些。

So we make sure, like, they can easily manage across all of these.

但是我觉得这确实有道理。

But but I I guess it just makes sense.

即使我做自己的副业项目，我也会清楚自己在限额内花了多少。

Even if I do my side projects, I will be aware of my own spend on my whatever limit I I have.

我想我理解得对吗？就是别把令牌浪费在那些没意义的事情上……

And I guess I guess, do I sense it correctly that the thinking is just don't use tokens on stupid stuff that is...

那些毫无意义的事情，或者你可能无意中在烧钱，自己却不知道。

That makes no sense or or accidentally, you know, you might be just burning and you don't know.

所以，就是要有这种反馈。

So, like, just just get that feedback.

这些东西不是免费的。

Like, these things are not free.

没错。

Exactly.

我觉得有这种反馈很重要，而且我们还有一个叫“成本检查”的插件，它会检查你所有的会话，根据你的使用情况给你个性化的建议，比如提醒你：“嘿。”

Like, I think just having that feedback and we also have, like, a plugin called cost check that will run across all of your sessions and give you personalized tips based on your usage to say, hey.

比如说，这就是那种情况，你在某个项目或某个会话上花了这么多钱。

Like, this is the kind of thing, this much you're spending on this project and this session.

这些是你可以用来进一步优化成本结构的建议。

These are the tips that you can use to further, improve your cost profile.

我觉得所有这些都能促进管理层和工程师之间的良好沟通。

And I think all of this creates, a good conversation between managers and engineers.

同时，工程师们也能得到很好的反馈，了解自己花钱的效率如何。

But also engineers will also see good feedback into how they are efficiently spending across.

这对我们进行实时指导帮助很大，比如上下文健康、模型规模调整等等。

And that helped us a lot with all of the real time coaching with context health, model sizing and, like...

这样工程师们也能意识到在这个新时代里工作的重要性。

So that engineers are also aware of working in this new age.

我们当然也不希望出现低效的花费。

Like, we also don't want, like, you know, like, inefficient spend.

你还建立了哪些与AI相关的基础设施？

And what other foundations that you built are related to AI?

MCP网关。

MCP gateway.

哦，对。

Oh, yeah.

我觉得另一个背景故事大概是，嗯，2025年初的时候。

I think the the other backstory was around, like, I think early twenty twenty five.

我们开始，比如Cursor火起来的时候，我们启用了Cursor，而MCP是那时候出现的规范。

We started, like, as cursor kind of picked up, like, we enabled cursor and MCP was was a spec that was, like, created around that time.

我们很快意识到，嘿。

And we quickly realized that, hey.

它的力量在于……

The power of...

通过把我们的内部工具以简单的方式暴露出来，我们真的能增强AI的能力。

We can really increase the, power of AI by exposing all of our internal tools in an easy way across things.

然后我们可能就能把这种能力扩展到编程之外。

Then we could potentially leverage this beyond just coding.

我们可以把它用于各种软件工程任务。

We could leverage it for all kinds of software engineering tasks.

所以大约在2025年4月，我们开始开发类似模型网关的MCP网关。

So around April 2025, we started working on like, MCP gateway, like, you know, similar to model gateway.

这是一个统一所有工具的门户。

This is one gateway for all of the tools.

我们之所以这么做，是因为我们已经有了一个很好的IDL注册表，覆盖了所有服务，不管它们用的是Thrift还是Proto。既然我们有IDL规范，就可以为这些服务自动生成MCP规范。

So what we did was because we already had good ideal registry across all of our services, whether they're using Thrift or Proto, Since we have the ideal specs, we auto generate the MCP specs for any of these services.

另外我想补充一下，对于不了解的人来说，Uber的服务要么用Thrift，要么用Protocol Buffers作为强契约。

And and just to add, I guess, for those who don't know, like, Uber services either emit Thrift or Prada Buffer as strong contracts.

然后，我们……

And, like, we...

最初我们只有Thrift，后来也增加了对Protobuf的支持。

Initially, we had just Thrift, and later we added support for Protobuf as well.

但过去几年里所有的新服务都是用Protobuf的。

But all of the new services, in the last few years, they're all Protobuf.

那些几年前创建的服务，都是用Thrift写的。

The ones that were created, like, a few years back, they're all in Thrift.

而且随着它们被重写，团队通常会切换到proto。

And as they go through rewrites, usually, like, teams switch to proto.

但不管它们是Thrift还是proto，我们都会有……

But whether they're in Thrift or proto, like, we we would have...

我们……

We...

因为所有的IDL都在……

Since we have all of the ideals in the...

在同一个注册表里，我们可以用那个注册表为它们生成默认的MCP规范。

In one single registry, we could use that registry to generate a default MCP spec for them.

所以它们可以……

So they could...

公司里的任何人，都可以去使用这个工具，MCP网关。

Anyone in the company, they can go to this tool, MCP gateway.

他们可以看到我们自动生成的所有MCP服务器。

They can see all of the, MCP servers that we auto generated.

如果你进入任何一个，你就能看到从那个现有API生成的所有工具。

And if you go to any of that, you could see all of the tools that were generated from that existing API.

所以这些可能是那些服务中作为MCP工具展示的API。

So these might be the APIs from those services that are projected as MCP tools.

我们自动生成请求包、响应包和描述。

We auto generate the request pack, response pack, the descriptions.

之后，我们还会根据API描述，为API的SAN字段生成针对LLM优化的描述，这样我们就能看到一些工具带有3000、4000个令牌，然后我们可以优化它们以供模型消费。

Later, we also, based on the API descriptions, we generate LLM optimised descriptions for the API SAN fields so that we can we saw some tools with 3,000, 4,000 tokens so then we can optimise it for, model consumption.

而且只需要一个配置和安全策略的更改，他们就可以启用它。

And it is just one single config, and security policy change, and then they can enable it.

他们不需要做任何代码更改。

They don't have to do any code changes.

如果他们想要任何自定义的MCP，他们总是可以失去...

If they want any custom MCP, they can always lose...

我们有一个框架，可以创建自定义的MCP，并且通过MCP网关代理这些自定义的MCP。

We have a framework for creating a custom MCP and proxy their custom MCP also through MCP gateway.

另外一件有趣的事情是，我们所有的供应商工具，无论是Google还是Slack，也都通过MCP网关暴露出来。

The other, interesting thing we did was even all of our vendor, tools, whether it's Google, Slack, all of them are also exposed through MCP gateway.

这大大减轻了配置管理的负担，因为我们之前已经提到了AIFX。

This reduced a lot of burden on configuration management since we already spoke about AIFX.

所以，我可以以同样的方式安装任何工具，无论是内部的MCP工具还是外部的MCP工具。

Like, so I could install any of the tools in a same manner whether it's internal MCP tools or external MCP tools.

在过去的几个月里，我们还将所有这些MCP都做成了CLI。

In the last few months, we also projected all of these MCPs as CLIs.

所以你可以把任何MCP当作CLI来执行。

So you could execute any MCP as a CLI.

这样，如果某些代理框架想用CLI，就可以用CLI。

So then if some agentic hardness wants to use it as CLI, they can use it as CLI.

如果他们想用传统的MCP，也可以用MCP。

If they want to use traditional MCP, they can use MCP.

我理解的是，这一切之所以能实现，是因为一开始的API就已经是生成出来的，或者说是用某种方式写好的，对吧？

And and do I understand that this all comes because the APIs to start with were already either generated or or written in...

比如，很多API都是自动生成的，你们已经有了一个API平台。

Like, a lot of them were generated that you already had a platform for the APIs.

所以加上MCP就相对简单了。

So adding MCP was somewhat, I mean, trivial.

当然，这也有工作量，但你明白我的意思。

I mean, of course, it's work, but you know what I mean.

现在生成CLI也相对简单，因为你们在AI之前就已经有了基础。

And now generating CLIs is also somewhat trivial because, like, you you had a foundation before AI.

所以当你们有了这个基础之后，我……

And and then so when you have it, I...

这就是我在Uber身上看到的情况，你们在2022年之前就构建了很多东西，然后可以很容易地在上面加上AI基础设施。

You know, that's what I'm starting to see with Uber that, like, you built a bunch of stuff before 2022, and you could just kind of add AI infra pretty easily on it.

而且，负责API网关的同一个团队也负责MCP网关。

And and the same team that works on our API gateway also worked on MCP gateway.

所以，他们本来就在做API网关这块业务。

Like, so they're already in the business of building API gateway.

所以，他们知道怎么做各种协议转换，各种API网关。

So, like, they they they know how to do any kind of protocol transformations, any kind of any kind of API gateways.

所以，我们很快就把它建起来了。

So it was like we were able to pretty quickly build this.

所以我觉得，尤其是当我们把Google Workspace和所有Slack工具也整合进来之后，就产生了各种很棒的智能体工作流。

So I think this was probably like, especially once we got our Google Workspace and all of our Slack tools also into this, it kind of, like, created all kinds of, like, amazing agentic workflows.

那时候，人们可以自动化任何事情，从Slack到Google、Jira、Linear，任何工具、供应商工具，或者任何内部服务，都只需要一个CLI命令。

People could automate anything, right, at that point, like, from Slack to Google, Jira, Linear, like, any tool, vendor tool, or any internal service we are at a CLI call away.

然后，当我们开始思考这个领域时，另一组基础是，我觉得所有这些都属于供应商中立、工具中立的构建模块，我们认为无论发生什么，你都必须这样做，因为智能体需要某种方式来访问你的工具。

And then the other set of foundations as we started thinking about this space was, see, I think all of these go in this camp of vendor neutral, harness neutral building blocks that we think you would have to do this irrespective of what happens because agents need some way to access your tools.

另一件事是关于技能的。

Then the other thing was around skills.

我们今年早些时候就开始做这个了。

We jumped onto this earlier this year.

因为我们已经有这种单仓库的概念，所以我们创建了一个技能单仓库，里面包含了中央平台团队构建的所有核心技能，以及各个团队可以构建的特定技能。

Since we already have this notion of mono repos, we created a skill mono repo in some sense that has all of the core skills that central platform teams build and all of the team specific skills individual teams can build.

这些技能是……

And are these skills...

这些就是那种技能文件夹，就像你可以用于云、编解码器等的插件吗？

These are just like the the skills folders, like the plugins that you can use for for cloud, codecs, etcetera?

没错。

Exactly.

就是说，有插件和技能可以在所有工具链中使用。

Like, so there is plugins and skills that you can use across all the harnesses.

然后我们有一个统一的质量门禁，可以应用于所有这些。

Then we had, like, one single, like, quality gates that can run across all of them.

我们让它可以在所有工具链之间移植。

And we made it portable across all of the harnesses.

所以你可以用我之前提到的同一个 AIFX 工具来安装。

So you install with the same AIFX tooling that I mentioned.

如果你真的把这个技能加进去，它会更新所有工作台（harness）的配置，不管你现在用不用那个工作台。

And if you do plug in add that skill, it will update the configurations across all of the harnesses whether you are at that point using that harness or not.

这样即使你在不同工作台之间切换，这些插件也会自动安装好，你就不用担心重新安装、重新配置这些事了。

So that even if you switch across harnesses, you have these plugins auto installed so you don't have to worry about, like, reinstalling them and reconfiguring them and so on.

而且因为这些技能都用的是MCP网关的工具，我们也为所有技能提供了一个统一的标准机制来访问任何工具。

And since all of these skills are using the tools from the MCP gateway, we also have one standard mechanism for all these skills to access any of the tools.

现在我们正在开发一些工具，让工程师可以去选择他们的技能。

Now we are working some tools where engineers can go select their skills.

它会告诉他们各种提升技能的技巧。

It will tell them all kinds of tips to improve their skills.

我们正在进行的下一项工作是，如何从工作台收集追踪数据，然后为技能生成改进补丁，这样我们就能根据学到的经验不断改进技能。

The next thing that in flight that we are working is how do we then collect the traces from the hardnesses and generate, improvement patches for the skills so that we can continuously improve the skills based on learnings.

因为关于技能质量、规模、评估以及如何持续改进，有很多讨论。

Because there's a lot of discussion around the skill quality, scale, evals, and how do we, improve that continuously.

比如，你刚开始创建一个技能时，它可能并不完美，你需要某种机制来持续改进它。

Like, when when you first build a skill, they might not be perfect, and you need some mechanism to continuously improve that.

我觉得MCP和技能这两样东西给我们带来了很多好处。

I think both the MCP and skills, this this gave us, like, lot of, like, benefits.

而且，如果我看一下……

And, like, if I look at...

比如，在过去的几周里，每天大概有3万次技能执行。

Like, in the last few weeks, there's around probably 30,000 skill executions per day.

这对我来说挺有意思的，因为如果你跟别人说，我们在建一个技能库，大多数在创业公司里的人会怎么想呢。

This is kind of interesting for me to see because if if you told someone like, oh, we're building skills repo, like, what most people would think inside a startup.

我不是说像Uber那样的大公司，而是说，哦，你就做个git……

I'm not talking about Uber, but like, oh, you just do a git...

就一个仓库，里面放一堆技能，就是一堆技能文件夹，然后就这样了。

Just a repo and you have a bunch of skills there, just a bunch of skill folders, and and that's kind of it.

但很明显，实际情况要复杂得多。

But it's pretty clear that it's it's more complex.

是不是因为你需要支持的工程师人数很多，所以才这么复杂？

Is is it more complex because of how many people, engineers you need to support?

是因为你们还在跑评估吗？

Is it because you're also running evals?

因为你们一直在清理这些技能，或者跟踪它们有没有被使用，做这些类似的事情。

Because you you keep cleansing these scales or, like, tracking if they're used or not, use those kind of things.

完全正确。

Absolutely.

我觉得，你看，现在在……

I think, see, it's like now in the...

现在用这些最新的模型，很容易就能做出一个技能的初版。

Now with any of these latest models, it's very easy to create, like, a v zero version of the scale.

但要让它真正好用，覆盖各种使用场景，就很难了。

It's very hard to make it really good across all kinds of use cases.

所以我们就想确保有一个统一的地方，能更新所有这些技能。

And that's why we want to really make sure we have one place we can update all of these skills.

实际上，当我们把所有MCP的CLI接口暴露出来时，就靠几个工程师用AI来搞定。

In fact, when we exposed the CLI projection for all of our MCPs, Just a couple of engineers using AI.

我们把仓库里所有的技能都更新成了CLI模式，因为这样更节省token。

Updated all of the skills in this repository to use the CLI pattern because it's more token efficient.

因为如果每个技能都说要用MCP ABC、MCP DEF，那我装这两个插件，就会有两个MCP一直挂在上下文里，上下文就太臃肿了。

Because if every skill says I want MCP ABC, MCP DEF, Then if I install these two plug ins, I'm gonna have, like, six MCPs across these two always in my context, and there's so much context bloat.

然后我们把所有技能都换成了CLI模式，这对我们的token效率也有很大的提升。

And, like, then we replaced all the skills with, the CLI pattern So that had a lot of impact on our token efficiency as well.

另外，因为我们自动给每个人安装了技能市场，这样就少了一步配置。

And the other thing is because, we auto install this skill marketplace, for everyone, it reduces one more step of configuration.

这样一来，发现技能就很容易了。

And so then the discoverability is easy.

设置、配置和管理也都变得简单了。

The setup and configuration and management is easy.

我们还可以围绕这个建立一整套评估流程和发现流程。

And we could build a whole bunch of eval pipelines around that, discoverability pipelines around that.

虽然还有一些团队有自己的仓库，但大部分技能都是通过这个来管理的。

We still have teams that have, like, their own repositories, but majority of the skills go through this.

我最喜欢的是上下文图谱。

My favorite is, like, context graph.

什么是上下文图谱？

What is context graph?

背景是这样的，去年十二月，有个工程师建了一个AI助手，你可以去问它问题，比如……

The backstory is, back in December, like, one of the engineers built a AI assistant that you can go to, like...

我们叫它Cortana。

We call it Cortana.

你可以通过网页或者Slack，向它询问任何代码库的问题。

Like, you can go to web or you can go to Slack and ask any question from any code base.

它会像代理一样……

So it would do agent...

它会搜索我们所有的代码库，然后回答问题。

It would, like, search across all of our repositories and answer questions.

然后我们就……

And then we go...

然后我们就看到大家问各种问题。

And and then we saw people asking all kinds of questions.

比如，可能是做研究。

Like, it could be research.

也可能是，比如，什么是……

It could be, like, what is...

这个查询怎么跑？

How to run this query?

比如，这个的数据源是什么？

Like, what is the data source for this?

这个归谁管？

Who owns this?

比如，你能为这个做根因分析吗？

Like, can you do RCA for this?

一大堆软件工程的任务。

Whole bunch of software engineering tasks.

当我们查看这些追踪记录时，很明显我们可以优化模型获取上下文所需的轮数，因为我们有这么多系统。

And when we're looking at some of these traces, like, it was clearly obvious that, you know, we could optimize the number of turns it takes for the models to get grounding because we have so many systems.

从历史上看，这些都是孤立的系统。

Historically, all of these are siloed systems.

比如，工程师必须进入任务管理平台。

Like, engineer has to go into the task management platform.

工程师必须查看我们的值班仪表板，还必须查看我们之前讨论过的那个仪表板。

Engineer has to go to our on call dashboard, has to go to our your own dashboard that we talked about.

然后我们想，好吧。

Then we're like, okay.

我们怎么把所有这些整合到一个统一的思维导图中，供智能体使用呢？

How do we plug all of that into one mental map for the agents?

就在最近几个月，因此，这真是一个很酷的可视化效果。

Then just in the last few months, hence, like, it's a cool visualization Wow.

已经构建完成了。

Is built.

他们叫它Uber上下文图谱。

Like, they call it Uber context graph.

我们有超过100种节点类型，还有130多种边类型。

Like, we have, 100 plus node types, like, one thirty plus edge types.

这是三天前的实时数据。

This is live data as of three days ago.

如果你点击任何一个人节点，就能看到他们管理哪些资产、写了哪些设计文档、正在做什么功能、处理过哪些值班事件、有哪些配置变更、管理过哪些事故、还有哪些Jira事件。

If you click on any person node, you know what assets they manage, what design docs they wrote, what features they are working on, what on call events they worked on, what are the configuration changes, what incidents they managed, what Jira events.

而且任何一个节点，都和其他所有节点有关联。

And if you take any node, it has relationships to all other nodes.

这样一来，我之前提到的那个助手，

And what this allows us is, now the same assistant I talked about.

它现在默认就用这个上下文图谱作为基础。

It has the context graph as a default grounding.

所以如果你问任何问题，它会先用这个图谱来导航，明白吧。

So if you ask any question, it will first use this to, like, navigate, okay.

比如，这个人在问什么？

Like, what is this person asking about?

一旦你确定了，哦，这是关于这个领域、这组服务的，那么它就可以深入，去读其他文档，读其他东西。

Once you get grounded into, oh, like, this is about this domain, this set of services, then it can go deep and, like, read other documents, read other things.

所以它减少了你的执行...

So it it reduces your exec...

你的代理追踪以及它给出好答案所需的轮数。

Your, your agent traces and the amount of turns it needs to give you a good answer.

而且我们已经看到，在很多类问题中，质量提高了，成本降低了，延迟也降低了。

And we already see, like, in a whole bunch of categories of questions, the quality goes up, the cost goes down, the latency goes down.

而且我们只是...

And we have just...

我们在充分利用这个潜力方面还处于早期阶段。

We are still early in harnessing the full potential of this.

而且，我们非常兴奋，对于未来我们能在此基础上构建的所有东西。

And, like, we are super excited about, like, all all of the things that we can build on top of, this going forward.

那这些节点，它们代表人吗？

And then the nodes, are they people?

它们代表工具吗？

Are they tools?

这是架构的可视化展示。

This is the schema visualization.

所以公司里的每个人都会有一个节点，比如我有个节点，每个员工也都有一个节点。

So every person in the company will have, like, you know, like, there's a node for me, a node for, like, every employee.

然后它还会和所有实例建立关系，比如我生成的每个PR，都会有一个对应的节点。

And then it will have relationships to all of the instances like every PR that I generate, there will be a node for that.

而且会有一个链接标明，好的，这个PR是Uday创建的。

And there's a link saying, okay, Uday created this PR.

Uday管理这个资产。

Uday, manages this asset.

我负责这个产品功能。

I work on this product feature.

我参与了这份设计文档的编写。

I contributed to this design doc.

所以节点既代表人，也代表资产。

So then the nodes are both people, but they're also assets.

对，没错。

Yeah, exactly.

举个简单的例子，比如你问一个问题：全球范围内有多少次出行是用现金支付的？

Like one simple example is, let's say if you ask any question like how many, mobility trips around the world are with cash payment type?

你首先得搞清楚有哪些表、哪些列，还有没有其他人写过这些查询，他们是不是科学团队的。

Like you first need to understand what tables exist, what columns exist, are there other people who wrote these queries, Are they from science team?

他们是不是做出行科学的。

Are they from mobility science?

现在所有这些数据都是相互关联的。

Like, now all of this data is interconnected.

你可以去查一下，看看最近三十天有没有其他相关的查询。

Like, you can go and check, oh, are there other queries that were done in the last thirty days around this?

那有哪些类型的表呢？

And what kind of tables exist?

去探索那些列，因为再说一遍，这些都是相互关联的。

Go and explore those columns because, again, all of this is, interlinked.

然后你就能很快找到我们已有的那些标准查询，甚至能快速回答这类复杂问题。

Then you can quickly get to the blessed queries that we have and, answer these kind of even complex questions pretty quickly.

不然的话，你得翻很多很多文档，调用很多很多工具。

Otherwise, you would have to go through many, many docs, many, many tool calls.

这样效率就高多了。

This makes it really efficient.

比如，让我们手动写所有这些Cypher查询会难得多，但智能体在导航图结构方面真的很擅长，就像它们用Bash导航文件系统一样。

Like, it's much harder for us to manually write all of these Cypher queries, but agents are really good at navigating the graph, like how they're really good at navigating file system with Bash.

这对我来说听起来很未来感，但挺酷的。

This seems very futuristic to me, but it's pretty cool.

而且我猜数据存储量肯定巨大，因为Uber轻松就有超过一万名员工。

And I assume it's a ton of data storage just because Uber has, like, 10,000 plus people working there easily.

那么……

So...

好消息是，就像我们的API边缘网关团队在MCP网关项目上做的那样。

The good part is, you know, similar to how our our API Edge Gateway team worked on MCP gateway effort.

我们的图平台团队，他们负责管理生产环境中的图，那个图有数十亿个节点，他们也帮忙构建了这个图。

Our graph platform team that manages graph for our production graph with billions of nodes, they also helped build this graph.

所以这个……

So this is...

跟我们的生产图相比，这个要小得多。

Compared to our production graph, this is much smaller.

所以这个是线性的。

So this is linear.

所以对他们来说，这已经不再是规模上的挑战了。

So it's not like a scale challenge for them anymore.

我们还聊过……

And we also talked...

我之前提到过AI助手Cortana，它整合了所有上下文图的工具和技能，并且无处不在，在Slack、网页和命令行里都能用。

I already talked about the AI assistant Cortana, which kind of plugs some of all of the context graph tools, skills, and it's omnipresent in Slack, web, CLI.

所以公司里的任何人，哪怕是在某个国家的运营人员，都可以问任何问题，比如‘这个是怎么构建的？’

So anyone in the company, like even someone in, ops in some country, they can ask any question about, oh, how is this built?

‘这个在哪里？’

Where is this located?

‘谁负责这个？’

Who who works on this?

‘这背后的历史是什么？’

What was the history behind this?

它能够获取所有这些数据，包括我们所有的Google文档，然后给出一个非常好的答案。

And it is able to take all of this data, all of our Google documents and then give them a really good answer.

它打破了各个组织之间的信息孤岛。

And it breaks down kind of the information silos across orgs.

他们可以自助服务，问任何问题，执行任何人构建的任何技能。

They are able to self serve, ask anything, execute any skill anyone has built.

那我猜它肯定得能访问数据源，才能……

Then I guess it must have, like, access to the data sources to...

就是说……

For for...

至少对合适的人来说，它能去查日志、监控这些。

At least for the right people so it can go into, like, things like logs and and monitoring, those kinds of things.

它确实有日志和监控。

It has logs, monitoring.

你可以问，比如，这个服务的健康状况怎么样？

You can ask, okay, what is the health of, this service?

它能去查看它所有的依赖，用的是什么存储系统，跑各种查询，然后给你一个这个资产的360度全方位健康报告。

It can go look at all of its dependencies, what kind of storage systems it uses, run all the queries and give you a three sixty degree health report for that asset.

而且我们保留了所有现有的用户权限。

And we carry forward all of the existing user permissions.

所以如果我只访问我有权限访问的东西，其他数据就访问不了。

Then if I'm only able to access the stuff that I had access to, otherwise, data is not accessible.

因为在Uber内部，我记得当你为一个你本来没有权限的系统添加权限时，那叫“打破玻璃”。

Because inside Uber, I remember it used to be called break glass when you added a permission for a system you didn't have access to.

你得走一个审批流程，要么经过经理，要么经过总监之类的。

You go through an approval flow, which goes through either a manager or a director or whatnot.

但我知道Uber当时在这方面做得很大。

But I know Uber was was really big.

在我那时候，他们就已经非常重视这个了。

At at my time, they were really big on this already.

确实。

Absolutely.

所以我觉得那些算是当时的一些基础。

So I think those were, like, some of the foundations there.

我们还有一些正在推进中的东西。

Like, we have some more in in in the workings.

比如，我们在考虑一些更未来感的使用场景。

Like, we are thinking about some, like, even more futuristic use cases.

但是这些基础模块确实帮助了我们，在智能体这条路上，让我们从纯粹用于编码，扩展到各种工程任务。

But, you know, some of these building blocks really helped us in our, like, agentic journey and helping it take it from just pure, using it for just coding, to all kinds of engineering tasks.

我是不是该提一下Uber是如何完成AI基础工作的？

Would I just mention how Uber wrapped up AI foundations work?

但更多的基础工作还在后面。

But already more foundations work is to come.

我们的赞助商turbopuffer对此深有体会。

Our presenting sponsor turbopuffer knows this all too well.

他们正在从第一性原理出发，重建他们的存储架构。

They are rebuilding their storage architecture from first principles.

他们这样做是为了让更多类型的存储在大规模下更快、更便宜、更可靠。

They are doing this to make more types of storage faster, cheaper and more reliable at scale.

这个名为turbopuffer v3的新系统还没有上线生产环境，但它已经通过了持续集成测试。

The new system called turbopuffer v3 is not yet in prod, but it already passes CI.

不过，它的性能还远不如当前的生产版本v2，所以turbopuffer团队现在正在优化查询计划，直到它们达到或超过v2的速度。

Still, it's not nearly as performant as the current production version v two, and so the t puff team is now perf maxing query plans until they are as fast or faster than v two.

他们正在公开进行这项工作，记录他们如何一路提升性能，直到v3正式发布。

They're doing this in public documenting how they increase performance all the way up to the v three production launch.

比如，我们可以看到团队通过批量读取，将全文搜索性能提升了九倍。

For example, we can see how the team increased full text search performance nine x by batching reads.

现在很多都是基础性的工作，但接下来几周他们会分享一些非常酷的系统方面的内容。

A lot of this is basic foundation work right now, but they will be sharing some very cool systems work over the next few weeks.

但等等，为什么团队要完全重写呢？

But hang on, why is the team doing a full rewrite?

因为搜索在变化，turbopuffer也在变化。

It's because search is changing and so is turbopuffer.

Tfpsart是一个向量数据库，但它已经不再只是一个向量数据库了。

Tfpsart is a vector database, but it is no longer a vector DB.

它已经演变成一个高性能的搜索数据库。

It has evolved into a high performance database for search.

V3抛弃了向量主索引，所有索引将共享同一个列式存储系统。

The V3 discards the vector primary index and all indexes will share the same columnar storage system.

每个查询都会在向量化查询引擎上运行，这在搜索数据库中并不常见，但这样既能实现非常快的搜索，也能让数据库整体性能非常出色。

Every query will run on vectorized query engines which is something you don't usually see in search databases but which will result in both very fast search and just generally a very fast database.

turbopuffer团队正在记录他们的开发过程，你可以在turboprefer.com/v3上跟进。

The turbopuffer team is keeping a work log of their journey and you can follow along at turboprefer.com/v3.

看着它一步步被构建出来，真的很有意思。

It's a blast to see how it's being built.

我还想提一下我们的长期赞助商Linear，它是协调人类和智能体之间工作的平台。

I also want to mention our seasoned sponsor Linear, the place of coordinating work between humans as well as agents.

对我们软件工程师来说，最大的变化之一就是需要审查的代码量非常大。

One of the biggest changes for us software engineers is the sheer amount of code that we need to review.

Uber为此开发了定制工具，但Linear也做了类似的事情。

Uber has built custom tools to deal with this, but so has Linear.

这个功能叫Linear diffs，它让工程师可以直接在Linear里审查PR。

It's called Linear diffs and it lets engineers review PRs right inside of Linear.

我非常喜欢Linear diffs的一点是，diff就放在项目里的issue旁边，这样你可以在一个地方轻松看到所有上下文，了解变更的原因，而无需在不同工具之间来回切换。

One thing I really like about Linear diffs is how a diff sits next to an issue inside a project and so it's super simple to see all of the context in one place and know why the changes happen without needing to jump through different tools.

对于大型的PR，引导式审查会带你一步步了解核心改动，并解释改了什么。

For large PRs, guided reviews walk you through the core change with an explanation of what has changed.

引导式审查还会把辅助代码和支持性修改分开归类。

Guided reviews also group the glue code and the supporting edits separately.

这些虽小但重要的改动，让你能一口气读完一个大型PR。

These small but important changes make a large PR readable in one sitting.

而且Linear还支持堆叠式PR。

And Linear also supports stacked PRs.

如果你用过堆叠式PR，你会知道它们是拆分复杂工作的好方法；如果你还没用过，试过之后你可能会爱上它们。

If you've used stacked PRs you'll know that they're a great way to break up complex work and if you've not yet used them you'll probably love them when you try them out.

随着AI代理承担更多工作，我们做代码审查的方式也在不断变化。

How we do code reviews keeps changing as AI agents take on more of the work.

Linear带来的这些巧妙改动，帮助我们工程师更好地理解代码审查，也期待Linear能不断演进diff功能，以适应我们更多与AI代理协作的工作方式。

These neat changes coming from Linear help us engineers understand code reviews more and expect Linear to evolve diffs to keep up with how we work more with AI agents.

想了解更多，并享受Linear六个月免费优惠，请访问linear.apppragmatic。

To learn more and to get six months off of Linear, head to linear.apppragmatic.

那么，我们回到优步，看看如今在公司里，开发人员构建一个功能时都用哪些工具。

With this, let's get back to Uber and how building a feature looks like today in terms of tools used by devs at the company.

PRD和ERD，我猜有些人可能不知道，PRD是产品需求文档，ERD是工程需求文档。

PRD and ERD, I guess for those who don't know product requirements documents, and ERD was engineering requirements documents.

就像……

Like it's...

就像产品规格和工程计划，这是优步内部的叫法。

Like the product spec and engineering plan for those not familiar inside Uber.

所以，我觉得我们已经聊了一些AI基础，现在如果你考虑一个功能的生命周期，我们怎么能用合适的AI基础真正提升每个阶段，并且重新思考这些工具以适应AI时代。

So, I think we went through some of the AI foundations and, like, now if you think about the life cycle of a feature, then how can we truly uplevel each of those life cycle with the right set of AI foundations and also rethinking those tools for the AI era.

有些方面我们走得更远。

And some we are more further ahead.

有些方面我们还处于讨论的早期阶段。

Some we are early in the discussion.

我觉得甚至那种让智能体和工程师可以迭代协作的联合计划的概念，我们也在探索，有很多很棒的想法。

I think even the notion of a combined plan that agents and engineers can iteratively work together, we, like, get in, there's, like, a lot of, cool ideas.

但这其实也意味着，我们还有各种智能体技能，可以用来处理你的任何设计文档。

But this is kind of like, you know, that we also have all kinds of agentic skills for working with any of your design documents.

就像我之前说的，不管是产品设计文档、工程设计文档、发布评审、XP评审，还是生产就绪评审，所有这些都在同一个地方。

And as I saying before, whether it's a product design doc, engineering design doc, launch reviews, XP reviews, production readiness reviews, All of those things are in one place.

我过滤掉了一些很老的项目，这样我们可以浏览一下。

I'm filtering some really old projects, so that we can look through them.

但你会清楚地知道谁在负责这些项目，还能跟踪它们的进度。

But you'll know exactly who is working on them, track the status of that.

而且所有这些数据也会进入图谱中，这样我们就能完整了解哪些是权威的设计文档、审批状态如何、谁在负责它们。

And all of this data also goes into the graph as well so that we know full history of what are the source of truth design docs, approval status, who works on them.

每个项目也都有对应的Jira链接或Linear链接。

And each of these also have the Jira link or the Linear link.

这样我们就能从这个项目追溯到执行是如何落地的。

So then we can trace from this project how was the execution translated to.

这为人类和智能体都提供了一个可靠的依据系统，让他们知道每个项目的规格说明。

This gives, like, a source of proof system for both humans and agents to know the specs for every project.

我觉得规划还是非常重要的，尤其是对于那些不是简单的一次提示或一次性项目的事情。

And I guess I guess planning is still really important, especially for, like, something that is not just a trivial, you know, like, one prompt or one shot project.

没错。

Exactly.

而且因为我们需要，比如……

And because we need to, like...

有太多……

There's so many...

由于产品和国家的多样性，我们需要认真考虑各种边缘情况。

With the kind of product heterogeneity and, like, country heterogeneity, like, we need to, like, really think about all kinds of corner cases.

不仅仅是知道顺利路径，还得考虑所有可能的边缘情况以及它们应该如何存在。

More than, like, they know the the happy path, you have to think about all kind of corner cases and, like, how they should exist.

而且因为我们还在实体世界中运营，边缘情况的数量就更多了。

And since we also operate in physical world, the number of corner cases are, like, even more.

我真的会想，哦，如果这种情况继续下去会发生什么？

I would really think about, oh, what happens if this goes on?

如果这种情况继续下去会怎么样？

What happens if this goes on?

我们怎么处理这种情况的客服问题？

How do we handle a support case for this?

我们怎么处理

How do we handle

我觉得我们只需要……

I I I guess just need...

虽然不用说，但我还是提一下，因为可能不是那么明显。

Needless to add, but I'll just add it because it might not be as obvious.

优步在这么多国家和城市运营。

But Uber operates in so many countries and cities.

即使是在两个城市之间，实际情况也可能不同，或者人们的期望不同，习惯也不同，等等。

And even between two cities, the reality might be different or might be different expectations or people are used to different things and so on.

完全同意。

Absolutely.

我觉得然后……

I think then...

所以这就显得提前想好正确的计划特别重要。

And that's why it really becomes important to think about the right plan upfront.

而且这样也能让工程师或者客服人员更容易拿着这个计划去拆解和执行。

And this will also, make it easy for both the engineers or agents to take that plan and decompose and execute on that.

一旦有了计划，下一步就是怎么把它转化成……

Once we have the plan, then the next thing is how do you convert that into...

拆解并执行。

Decompose that and execute.

现在我们就要用到我们内部叫 Minion 的东西。

Now we're going to, what we call, Minion internally.

这是我们的后台编码代理。

So this is our background coding agent.

目前大约有15%的生产环境PR都是通过Minion处理的。

So around 15% of all of the production PRs go through Minion, right now.

基本上，有很多PR，有些PR工程师想交互式地处理，但我们也想让它变得非常简单。

Essentially, you know, there's a whole bunch of PRs that some PRs engineers want to do interactively, but we also want to make it really easy.

一旦你有一个任务，我有很好的规格说明，或者我想尽量减少干预，我就可以把它交给一个Minion。

Once you have for the task that I have really good spec or I want to do minimal steering, I can hand off that to, to a minion.

然后我们经历了...

And we had...

再次，我们经历了...

Again, we had...

我们做了多次迭代。

We did multiple iterations.

这是最新的一次迭代，我们称之为Minion v2。

This is the latest iteration we call Minion v two.

但是，你可以从网页上使用它。

But, like, you can use it from web.

你也可以从Slack上使用它。

You can use it from Slack.

你可以用计划模式，然后让它后台执行，或者你给一个……

You can, do a plan mode and then let it execute behind the scenes, or you give one...

如果是简单的提示，你可以一次性给出提示，然后让它后台执行。

You can give the prompt once and let it execute behind the scenes if it's like a simple prompt.

而且它还能访问……

And it has access to...

这用的是Mega DevPod。

This is using the Mega DevPod.

所以它能访问我们所有的代码库和所有仓库。

So then it has access to all of the repositories, all of the code base that we have.

它可以在多个仓库之间工作，根据你给出的计划和规格，跨仓库生成一个或多个PR。

It can work across repositories and and generate one PR or multiple PRs across repositories based on the plan and spec that you have.

我们刚开始的时候，主要是把维护类的任务交给Minion处理。

When we initially started, mostly maintenance kind of tasks used to be offloaded to Minion.

随着我们不断推进，在Minion环境中加入越来越多的工具，让它能自我验证在网页、移动端或后端API上的工作，我们的目标是逐步扩大人们能用Minion完成的任务范围。

As we progress on this journey, as we are adding more and more tools into the Minion environment where Minion can self validate its work in web or mobile or back end APIs, our goal is we can increase the kind of tasks people can do with Minion over time.

随着时间的推移，提高任务的完成比例。

Increase the percentage of tasks over time.

我觉得我们也能看到它和Slack的集成程度。

I think we can also see how integrated

在Slack里。

in Slack.

可以直接提一下……

Can just mention...

你是提Minion还是怎么说？

Do you mention Minion or what do you say?

你可以输入minion，然后它会显示状态。

You can do minion and then, it will show you the status.

而且你还可以……

And you can also...

比如，你不需要去网页上操作。

Like, you don't need to go to the web.

你直接在Slack里就能操作它。

You can steer it on Slack itself.

比如你可能有一个和工程经理、产品经理的Slack讨论串。

Maybe you have, like, a Slack thread with the EM, with the PM.

你可以在上面迭代设计。

You can iterate on the design.

就这么简单，大家反复讨论，然后达成一致。

With a simple thing, are just iterating and get alignment there.

然后你说，嘿，Adminion，跟进这个讨论串，能帮我创建一个PR吗？

And then say, hey, Adminion, follow this thread and, can you create a PR?

然后它会读取Slack讨论串的内容，帮你生成一个PR。

And then it will take the Slack thread context and then create a PR for you.

所以即使在我们的支持渠道里，它也特别有用。

So it's been really useful even in our support channels.

比如有人报告了一个bug。

Would see, like, someone reports a bug.

值班的人就问Minion，嘿。

The on call ask Minion, hey.

比如，什么……

Like, what...

你能看看问题出在哪里吗？

Can you see what is the issue?

然后Minion就会回来说，哦，这是根本原因。

And then Minion will come back with, oh, this is the root cause.

哦，这个看起来挺简单的。

Oh, this looks simple enough.

咱们直接在这儿修了吧。

Let's just fix it right there.

然后我们就直接修了。

And then we would, like, fix it.

就没有那种先加入待办，然后下个迭代再做的循环。

Like, there's no then loop of, like, adding it to backlog, doing in the next.

就是说，你能当场就把它修好。

Like, explain, like, you are able to fix it right there.

所以我们看到，随着Minion越来越强大，这种情况也越来越多。

So we see, like, more and more cases of that as Minion gets powerful as well.

所以我觉得我们好像……

So I think we've, like...

我们算是走过了构建这一步。

We we kind of went through, like, the build step.

我们之前也聊过DevPod。

We also before talked about DevPod.

它后来有改进，对吧？

It's improved since, hasn't it?

所以，这显示了我所有的DevPod，因为我在做context graph。

So, like, this is showing all of my DevPods since I'm working on context graph.

你看，你看到了吧。

Like, you see you see that.

但是，是的，就像你……

But, yeah, as you...

如果你想创建一个新的 DevPod，你会看到你想选择哪种类型。

If you if you want to create a new DevPod, you'll see, like, which flavor you want.

对于 Minion，有一个 DevPod 类型包含了所有的仓库，但是……

For for Minion, there is a DevPod flavor that has all of the repositories, but...

并且针对 Minion 的使用进行了优化。

And optimized for Minion usage.

但对于交互式使用，它会在几秒钟内创建一个 DevPod，然后你就可以运行它，并且你可以……

But for interactive, like, it will create a DevPod and within a matter of seconds, you will will you will have that running and you can

去……那真是令人印象深刻。

go to That's impressive.

几秒钟，我确定。

The seconds, I'm sure.

你做了些巧妙的事情，比如让东西保持预热或预填充，这样你就可以复制那些……是的。

You do some clever stuff like having things warm or prefilled so you can copy those kind of Yeah.

就像，它运行在……

It's like, it's it's running on...

所有……

All of...

这是因为，这是开发者相关的东西。

This is because, this is developer stuff.

比如，我们有多个独立的云环境用于这个，还有Kubernetes集群，一切都预热好了。

Like, we have, like, a separate multiple clouds that we are using for this and it's like Kubernetes cluster and everything is warmed up.

所以当你请求时，我们就能直接从预构建的镜像中克隆。

So then when you ask it, we are able to just clone from the pre built image.

而且它已经有构建缓存，所有仓库也都克隆好了。

And it has built caches, everything, repositories, everything already cloned.

随时可以开始构建。

It's ready for you to build.

我们在所有仓库中都使用Bazel作为构建系统。

We use Bazel across all of our repositories for build systems.

所以我就能进入一个仓库，为它运行Bazel。

So I was able to go into a repository, run Bazel for that.

我们以秒级的速度完成了这个过程，任何工程师...

We went through this in the order of seconds where any engineer...

如果我想在这里改代码，几秒钟内就能创建DevPod。

If I want to make a code change here, within order of seconds, create DevPod.

这是构建任何模块的唯一方式，而且每个人都知道这个命令。

It's one single way to build any module and then anyone knows this command.

现在智能体也知道同样的方式，对吧，在CloudMD和AgentsMD里。

Now agents also know the same way, right, in the CloudMD, AgentsMD.

他们知道如何构建测试，任何仓库里的任何模块，而且他们能使用完全相同的命令。

They know how to build a test, any module in any repository, and they're able to use the exact same commands.

所以我觉得这大概涵盖了在协同生成中需要做的事情。

So I think that covers kind of, like, you know, what the kind of stuff that you have to do in cogeneration.

所以你可以进行交互式的硬度测试。

So you can do interactive hardness.

你可以通过Minion来做。

You can do, like, through Minion.

接下来就是，你有PR了。

The next thing is, okay, like, you have the PR.

之后你做什么呢？

What do you do after that?

然后我们先讲自愈CI。

Then we will go through self healing CI first.

我们意识到的一件事是，因为我们的PR量逐年上升。

One thing that we realized is because our PR volume has gone up year over year.

哦，对。

Oh, yeah.

肯定暴涨了。

It must have exploded.

我们的p50周期时间和p90周期时间，无论是内循环，比如你在……

Our p 50 cycle time, p 90 cycle time both for inner loop where, like, you know, you are...

就是……

Get...

你……

You are...

你有了PR，想让它变成绿色状态，然后创建远程PR。

You have the PR and you want to get it to a green state and create the remote PR.

或者一旦你创建了PR，要等人来审查，还要让所有CI都通过。我觉得审查已经成了一个很大的瓶颈，其他公司也一样。

Or once you have your PR created, getting the human review, getting all the CI things to pass, I think review has become a big bottleneck, same as any other company.

我们看到年复一年的差距，我们真的想专注于拆解每一个环节，看看怎么深入优化，以适应AI时代。

And we see year over year the delta and we want to really focus on breaking down every aspect of this and how can we go really deep and optimising it for the AI era.

所以我们做的第一件事就是，把一堆简单的CI任务，以前是创建PR后才会跑的，现在移到了内循环里。

So first thing that we did was we took a whole bunch of like, simple CI jobs that used to run once you create the PR, and we moved it to inner loop.

我们把所有这些都放在一个命令后面，比如AIFX validate。

And we kept all of this behind one single command like AIFX validate.

所以当agent创建PR时，它能跑linter、覆盖率规则、构建规则、模板规则等等，这样PR处于良好状态的概率就提高了。

So then when agent creates a PR, can it run the linter, the coverage rules, the build rules, the template rules, like all of these things so that the probability of this PR is in a good condition, like, goes up.

然后我们加入了视觉验证的功能，我可以启动模拟器来测试，也可以启动网页来测试。

Then we hooked on ability to do visual validation where I can spin up emulator and test I can spin up, like, a web and test it.

我还可以启动一个预发布环境，把改动部署上去，运行API，然后进行测试。

I can spin up, like, a staging environment where I can deploy this change, run the APIs, and test it.

现在Minion或者我的交互式工具，它们都知道……

And now Minion or even my interactive harnesses, they know...

这些代理知道怎么做，具备相应的技能。

These agents know how to, have the skills for this.

所以它们可以完成这个验证循环。

So then they can go through this, verification loop.

假设你创建了PR，但有些东西还是失败了。

And let's say you create the PR and still something, fails.

那我们有自愈的CI。

Then we have a self healing CI.

你可以应用到所有PR，或者针对单个PR。

You can apply to all the PRs or per PR.

这是我们在所有GitHub PR上加的一条Uber特有的说明，你可以链接到你正在处理的那个issue。

So this is like an Uber specific line that we add to all GitHub PRs that you can link to the issue that you're working on.

你可以看到哪些检查失败了。

You can see which checks are failing.

你可以有一大堆自动化操作，比如自动请求审查、自动合并、自动修复。

You can have a whole bunch of automations, auto request review, auto merge, auto fix.

基本上，我们尽一切可能来缩短p50和p90的周期时间。

Essentially, everything that we can we can do to reduce the p 50, p 90 cycle times.

一旦你完成了所有这些，我们还有一个叫Code Inbox的东西。

And once you do all of this, then we have this thing called Code Inbox.

这里展示的是一个模拟版本，它会……

This is showing a mock version of that where, it will...

任何工程师都可以去。

Any engineer can go.

他们可以看到所有等待他们的PR，以及他们创建并等待审查的PR。

They can see all the PRs that are waiting for them, all the PRs that they created, that they're waiting for reviews.

所以，如果工程师把这个发来审查，我就去这个页面。

So if, engineer, send this for review, I go to this page.

我可以看到我们到目前为止做的所有事情。

I I can see all the things that we did so far.

这样我很容易就能看到，哦，AI代码审查通过了。

So it makes it really easy for me to get, oh, the AI code review passed.

这些是它检查的内容。

These are the things it checked.

这是冒烟测试的截图。

This is the sanity test screenshot.

所以我就知道，好的。

So I know, okay.

我知道了。

I know

你可以快速看一眼。

You can just quickly take a look.

你也有视频吗？

Do you have a video as well?

我能看到账单检查和所有这些。

I can see the the bill checks and all of that.

而且，我们还在添加风险评分、这个PR的影响范围等等。

And, we're also adding risk score, blast radius of this PR, and so on.

所以所有这些都会给工程师很好的信号，让他们判断，好的。

So all of this will give engineers really good signals to figure out, okay.

比如，这个PR是否适合合并，以及我应该重点关注哪些部分？

Like, is it good to land and which parts of the PR I should focus on?

是的，我觉得我们还在积极推动我们这一大堆想法。

And, yeah, I think we are still, like, are aggressively working on this whole bunch of ideas that we have.

但我们想确保，当我们准备好迎接大量PR涌入时，实际上我们不得不为CI系统添加内部代码红色警报，因为年复一年，CI任务的数量翻了一番甚至更多。

But we want to make sure, like, you know, as we are ready for the influx of PRs, we in fact had to add internal code red for our CI system because year over year, the number of CI jobs also doubled or more than doubled.

所以我们不得不加强这方面的基础建设，以便为大量新PR的到来做好准备。

So we had to, like, also, like, beef up a whole bunch of foundations in this space so that we can we can be ready for the influx of new PRs.

我猜你也看到了，工程师们不可能再像以前那样，用同样的严谨程度去审查每一个PR了。

And I guess, like, you're also seeing that there's no way engineers can review all PRs with the same rigor as we did in the past.

所以我觉得你们是在建一些工具，用来提示什么时候……

So I guess you're you're building tools to signal when...

哪些PR需要更多关注，哪些可能风险较低，可能影响面小，或者波及范围小。

Which ones to pay more attention to, which ones might be low risk in so many ways, maybe in impact, maybe in blast radius.

你觉得随着时间推移，代码审查会变成什么样？

What is your take on what will happen with code review over time?

你觉得会不会一直有人工代码审查，还是说某些情况下可能会消失？

Do you think there will always be human code review or for some things it might go away?

对，绝对会。

Yeah, absolutely.

我觉得，对我们来说，我们总是想更稳妥一些，因为Uber出一次事故的代价真的很高。

I So think, one is for us, we want to always on the safer side because the cost of an incident for Uber is really high.

所以即使有这些工具，我们还是……

So even with all of this tooling, we...

比如现在，我们还是要求每个PR都必须有工程师来审查。

Like, right now, we still require an engineer to review every PR that that goes that goes in.

一旦我们对风险评分的信心增强了……

Once the more confidence we get in our risk scoring...

而且我们还可以用多年的数据来做回测。

And we can also backtest it with years of data.

我们有所有这些数据。

We have all of this data.

而且我们对AI代码审查的信心越强，那么对于某些低风险的PR，我们也许可以启用所谓的“绿色通道”，也就是自动合并。

And the more confidence we have in our AI code reviews, then maybe for some class of low risk PRs, we could enable, we call it green lane like auto landing.

但在那之前，我们得确保所有方面都万无一失。

But we want to be really, really sure about all of the dimensions that we want before we go there.

不过目前的首要任务是，怎么让工程师轻松获取所有需要的信号，从而加快审查速度。

But right now, the main priority is how do we make it really easy for engineers to get all the signals they need to review faster.

如果我们在这方面做得好，我相信随着时间的推移，自动合并的PR比例会越来越高。

And if if we do a good job there, then I'm sure, like, you know, we can increase the percentage of, like, auto line PRs over time.

但那是第一优先级，第零优先级是把所有信号都放到正确的位置。

But that's kind of p one, p zero is, like, first getting all the signals in the right place.

不错。

Nice.

但代码收件箱确实不错。

But Code Inbox is nice.

我喜欢。

I like it.

我们该聊聊的是，比如，我怎么做冒烟测试。

This is, thing that we should touch upon is, like, maybe, how I can do sanity testing.

冒烟测试，就是给那些不懂内部术语的人说的，就是手动测试。

And and sanity testing, just for those who don't know the internal lingual, that's the manual testing.

手动测试。

Manual testing.

我想做。

I want to do.

比如说，我正在开发一个新功能。

Let's say I'm I'm working on some new feature.

它涉及两三个服务。

It touches two two or three services.

我怎么知道这个功能端到端是否正常工作？

How do I know if this feature is working end to end?

那么，工程师的典型工作流程，在智能体出现之前是这样的……

So then typical workflow for engineers is like, pre agentic world is...

我们称之为 Slate。

We call it Slate.

基本上，你可以创建自己的实例，部署你正在开发的分支。

Essentially, you can create your own instance that deploys the branch that you are working on.

你可以将测试账号的 UID 路由到你创建的实例上。

And you can route your test account UID, to the instance that you created.

所以当你登录时，你就是在运行那个分支？

So when you log in, you are executing that branch?

对。

Exactly.

就是执行那个分支。

Exiting that branch.

而其他上下游请求会走其他的预发布环境。

And rest of the upstream and downstream goes to the other staging setups.

这样你就能端到端测试，不用担心基础设施的其他部分。

So that way you can test end to end without worrying about other parts of the infrastructure.

而且这个机制会贯穿整个服务链路。

And this will carry forward across the service graph.

所以你可以从你的手机应用上说，哦，这是我想测试的测试账号。

So you can say from your mobile app, oh, this is the test account I want to test.

它会经过其他服务。

It will go through other services.

当它到达被测服务时，就会转到你的 Slate 实例。

And when it touches the service under test, then it will go to your Slate instance.

如果你要测试两三个服务，那么请求会进入所有两三个被测服务。

If you're testing two or three, then it will go to the service under test across all two or three.

所以用这个方案，你甚至可以进行多服务测试。

So you can do even multi service tests with this.

有了这个之后，我们只需要教代理如何部署 Slate。

Now that we had this, we had to just teach agents how to deploy Slate.

我们还提供了所有历史 API，你可以用来缓解这些服务的问题。

And we also give it all of the past APIs that you can use to mitigate any of these services.

基本上，这就像我作为工程师，想做一个冒烟测试，也就是手动测试我的改动。

Basically, this was a thing where I, as an engineer, want to sanity test, meaning I want to manual test up my changes.

我之前有一种很酷的方式来做这件事。

I had a way to do this in a pretty cool way.

现在我们可以把它交给代理，它们就能安全地端到端测试自己的改动。

And now we can just give it to agents and they can actually test their own changes end to end in a safe way.

所以这里我们展示的是那个方案的网页版。

So here we are showing a web version of that.

而且你可以看到，实际上，那个……

And you can see, in fact, like, the...

这就是我们刚才说的那种命令行模式。

This is like the CLI pattern we went through.

它用的是Slate MCP，创建新的Slate环境，然后它会提示说，哦，这是环境名称。

It's using, Slate MCP, create new Slate environment, and it's saying, oh, this is environment name.

然后，一旦环境创建好了，它会说把服务部署到这个环境，并给出服务名称。

And then, once it creates the environment, it's saying deploy service to this environment and giving the service name.

这是一个测试服务。

This is a test service.

现在它有了……

And now it had...

就像，它有自己的环境。

Like, it has its own environment.

这就是Slate的界面。

This is like the Slate UI.

而且它还有，你知道的……

And it has like, you know...

你看这里，你可以把测试账号的 UID 绑定到那个特定的实例上。

And if you see here, you can pin test account UIDs to that particular instance.

然后你会看到那个环境里的所有服务。

And you will see all the services that are in that particular environment.

你可以看到 Gitsha。

You can see the Gitsha.

现在，代理内部可以使用所有这些技能和工具。

And now the agent internally can use all of these skills and tools.

所以你看，它做的是对那个网页进行 AB 测试。

So if you see, what it did was it did AB testing of that web thing.

它在那个 Slate 环境中运行了代理浏览器，分别针对主分支和我的分支上的内容。

It ran agent browser in that Slate environment with what is on main and what is on my branch.

然后它生成了一份报告，让我查看所有发生的变更。

And it created a report for me to review the full set of changes that happened.

所以在这之后，我们可以去看它生成的报告。

And so then after this, we can go to the report that it generates.

你看，它生成了一个报告，显示前后对比，还给我展示了所有的……

Like, see, it generated a report that shows before and after, and showing me, like, all the...

没有回归问题，这对工程师来说验证起来非常容易。

There's no regressions, and this is very easy for, like, you know, engineers to validate.

我们还可以把一些截图和视频附到PR上。

And we can attach some of the screenshots and videos to to the PR.

同样的东西我们也适用于iOS、Android和Web。

And the same thing we have for, iOS, Android, web.

如果你想测试后端API，也可以测试后端API。

And if you want to do back end APIs, then you can also test the back end APIs.

我想补充一点，你可能在优步之外体会不到，但Slate非常重要，因为优步至今仍然有数千个微服务，或者可能不算是微服务。

I I just wanted to add, like, you know, like, one of the things that, again, you might not appreciate if you're not outside of Uber, but Slate is so important because Uber literally is still today still has thousands of microservices or maybe not not micro.

但是……

But...