为什么大多数AI产品会失败：来自OpenAI、谷歌和亚马逊50多次AI部署的经验教训

我认为，成功的人对理解自己的工作流程极为专注，他们会仔细判断哪些部分适合交给AI增强，哪些部分仍需要人类参与。

I think folks that are successful are incredibly obsessed about understanding their workflows very well and augmenting parts that could could be right for AI versus the ones that might need human in the loop somewhere, etcetera.

当你试图自动化工作流程的某个环节时，绝不可能仅靠一个AI代理就能解决所有问题。

Whenever you're trying to automate some part of a workflow, it's never the case that you could use an AI agent and that will kind of solve your problems.

通常，你会有一个机器学习模型来完成工作的一部分。

It's always you probably have a machine learning model that's going to do some part of the job.

同时，还会有确定性的代码来完成工作中的另一部分。

You have deterministic code doing some part of the job.

因此，你必须极度专注于理解整个工作流程，以便为问题选择最合适的工具，而不是一味沉迷于技术本身。

So you really need to be obsessed with understanding that workflow so you can choose the right tool for the problem instead of being obsessed with the technology itself.

我看到的另一个模式是，人们真正理解了与非确定性API（即你的大语言模型）协作的理念。

And another pattern I see is also folks really understand this idea of working with a non deterministic API, which is your LLM.

这意味着他们也明白，开发周期与以往大不相同。

And what that means is they also understand the development lifecycle looks very different.

他们能够快速迭代：能否在不损害客户体验的前提下，快速构建并迭代，同时获取足够多的数据来评估行为？

And they iterate pretty quickly, which is can I build something iterate quickly in a way that it doesn't ruin my customer experience at the same time gives me enough amount of data so that I can estimate behavior?

所以他们能非常迅速地建立起这个飞轮。

So they build that flywheel very quickly.

如今，关键不在于你是否是第一个在竞争对手中部署智能代理的公司。

As of today, it's not about being the first company to have an agent among your competitors.

而在于你是否已经建立了正确的飞轮，从而能够持续改进。

It's about have you built the right flywheels in place so that you can improve over time.

对吧？

Right?

当有人告诉我，我们有一个一键式代理，会部署到你的系统中。

When someone comes up to me and says, we have this one click agent, it's going to be deployed in your system.

然后在两三天内，它就会为你带来显著的收益。

And then in in two or three days, it'll start showing you significant gains.

我几乎会持怀疑态度，因为这根本不可能。

I would almost be skeptical because it's just not possible.

这并不是因为模型不够强大，而是因为企业数据和基础设施非常混乱。

And that's not because the models aren't there, but because enterprise data and infrastructure is very messy.

而且代理需要一点时间来理解这些系统是如何运作的。

And you need a bit to even the agent needs a bit to understand how these systems work.

到处都存在非常混乱的分类体系。

There are very messy taxonomies everywhere.

人们常常会做这样的事情：获取客户数据，我们想获取客户数据，我们就去做了，诸如此类。

People tend to do things like get customer data, we want get customer data, we do and these kinds of things.

所有这些功能都存在，它们被不断调用，但实际上积累了大量陈旧的债务需要处理。

And all those functions exist, and they are being called and basically there's a lot of dead debt that you need to deal with.

所以大多数情况下，如果你专注于问题本身，并且非常了解你的工作流程，你就会知道如何随着时间推移逐步改进你的代理，而不是简单地随便部署一个代理，就指望它从第一天起就能正常工作。

So most of the times, if you're obsessed with the problem itself and you understand your workflows very well, you will know how to improve your agents over time instead of just slapping an agent and assuming that it will work from day one.

我甚至可以说，如果有人向你推销一键式代理，那纯粹是营销噱头。

I probably will go as far to say that if someone's selling you one click agents, it's pure marketing.

你不想被这种说法误导。

You don't want to buy into that.

我更愿意选择一家说‘我们会为你构建这个流程’的公司。

I would rather go with a company that says, we're going to build this pipeline for you.

而且它会随着时间推移不断学习，形成一个良性循环，而不是指望一个开箱即用的解决方案。

And that will learn over time and kind of build a flywheel to improve than something that's gonna work out of the box.

要替换任何关键工作流程，或构建一个能带来显著投资回报的系统，即使你拥有最好的数据层和基础设施层，通常也需要四到六个月的时间。

To replace any critical workflow or to build something that can give you significant ROI easily takes four to six months of work even if you have the best data layer and infrastructure layer.

太棒了。

Amazing.

这些观点与我在这档播客中其他对话的很多内容产生了强烈共鸣。

There's a lot there that resonates so deeply with other conversations I've been having on this podcast.

一家公司要想在AI应用上取得显著成效，创始人兼CEO必须深度参与其中。

One is just for a company to be successful at seeing a lot of impact from AI, the founder CEO has to be deep into it.

我曾邀请丹·希珀做客这档播客，他帮助多家公司推进AI落地。

I had Dan Shipper on the podcast, and they work with a bunch of companies helping them adopt AI.

他说，成功最重要的预测指标就是CEO每天多次与ChatGPT、Claude等工具交流。

And he said that's the number one predictor of success is the CEO chatting with Chad GPT, Claude, whatever, many times a day.

我很喜欢你举的Rackspace首席执行官的例子。

I love this example you gave with the Rackspace CEO.

就像每天早上花点时间了解最新的AI资讯。

It's like catch up on AI news in the morning every day.

我原本以为他会直接和聊天机器人聊天，而不是看新闻。

I was imagining he'd be, like, chatting with, like, the chatbot versus, like, reading news.

以你今天所掌握的信息，其实完全可以做到，当然也要选择合适的渠道，因为每个人都有自己的看法。

With the kind of information you have as of today, you could just I mean, you wanna choose the right channels as well because everybody has an opinion.

那么，你打算相信谁的观点呢？

So whose opinion do you want to bank on?

我觉得，拥有一群高质量的信息来源真的非常重要。

I feel like having that good quality set of people that you're listening to really makes sense.

他就是列了两三个固定的信息来源，每天都看。

So he just has a list of two or three sources that he always looks at.

然后他再带着一堆问题，去跟一群AI专家讨论，听听他们的看法。

And and then he comes back with a bunch of questions and bounces it around with a bunch of AI experts to see what they think about it.

而我就是那个群体中的一员，所以我很清楚。

And I was part of that group, so I kind of know

我非常喜欢这一点。

I love that.

关于他提出的那些问题。

About the questions that he comes up with.

这真酷。

So That's cool.

挺酷的。

It's pretty cool.

我当时就想，你为什么要做这么多事？

I was like, why are you doing so much?

然后他说，这些会渗透到我们所做的许多决策中。

And then he says it trickles down into a bunch of decisions that we would take.

好的。

Okay.

让我谈谈另一个在本播客中一直很热门的话题。

Let me talk about another topic that's very it's been a hot topic on this podcast.

Evals 曾经在 Twitter 上热火朝天一段时间。

It was a hot topic on Twitter for a while, Evals.

很多人对评估非常着迷，认为它们能解决 AI 领域的许多问题。

A lot of people are obsessed with evals, think they're the solution to a lot of problems in AI.

也有很多人觉得评估被高估了，认为你根本不需要评估，只要凭感觉就能搞定。

A lot of people think they're overrated, that way you don't need evals, can just feel the vibes and you'll you'll be alright.

你对评估有什么看法？

What's your take on evals?

在解决你提到的诸多问题时，评估能走多远？

How far does that take people in solving a lot of the problems that you talk about?

就社区里正在发生的事情而言，我觉得存在一种虚假的二元对立：要么认为评估能解决一切，要么认为在线监控或生产监控能解决一切。

In terms of, like, what is going on in the community, I I feel there's there's this false dichotomy of, like, there's either evolves is going to solve everything or online monitoring or production monitoring is gonna solve everything.

我找不到任何理由去完全信任其中任何一个极端，比如把我的整个应用都押注在某一种方法上。

And I find no reason to trust, like, one of the extremes in the sense that I will entirely bank my application on this and or like that to solve the thing.

对吧？

Right?

如果你退一步想想，评估到底是什么。

So if you take a step back, think of what are evals.

评估本质上是你对产品的信任性思考，或者说是你对产品的认知，这些会融入到你所构建的数据集中，因为这些对你来说才是重要的。

Evals are basically your trusted product thinking or like your knowledge about the product that is going into this set of datasets that you're going to build in the sense that this is what matters to me.

比如，这是我希望我的智能体不应该做的问题，让我构建一组数据集，以便在这些方面表现良好。

Like, this is the kind of problems that my agent should not do, and let me build a list of datasets so that I'm going to do well on those.

至于生产监控，你在这里做的是部署你的应用，然后设置一些关键指标，这些指标会向你反馈客户是如何使用你的产品的。

And in terms of production monitoring, what you are doing doing there is you're deploying your application, and then you're having this some sort of key metrics that actually communicate back to you on how customers are using your product.

比如，无论你部署的是什么智能体，如果客户对你的互动给出了好评，你最好能知道这一点。

Like, you could be deploying any agent and, like, if the customer is giving a thumbs up for your interaction, you better want to know that.

这就是生产监控要做的事情。

So that is what production monitoring is going to do.

对吧？

Right?

这种生产监控其实早已存在于各种产品中很长时间了。

And this production monitoring has existed for products like for a long time.

只是现在有了AI代理，你需要监控的粒度要精细得多。

Just that now with AI agents, you will need to be monitoring, like, a lot more granularity.

不仅仅是客户会给你明确的反馈，还有很多你可以获取的隐性反馈。

It's not just the customer always giving you explicit feedback, but there is many implicit feedback that you can get.

例如，在ChatGPT中，如果你喜欢某个回答，你可以直接点赞。

For example, in ChatGPT, right, like if you are liking the answer, you can actually give a thumbs up.

或者如果你不喜欢某个回答，有时客户不会点踩，而是直接重新生成答案。

Or if you don't like the answer, sometimes customers don't give you thumbs down, but actually regenerate the answer.

这清楚地表明，你生成的初始答案未能满足客户的期望。

So that is a clear indication that the initial answer that you generated is not meeting the customer's expectations.

对吧？

Right?

所以这些是你始终需要关注的隐性信号，而且在生产监控中，这类信号的范围一直在扩大。

So these are the kind of implicit signals you always need to think about, and that spectrum has been increasing in terms of production monitoring.

现在让我们回到最初的话题，好吧。

Now let's come back to the initial topic of, like, okay.

这是评估还是生产监控？

Is it Eval or is it production monitoring?

这有什么关系？

What does it matter?

我觉得，我们又回到了这个以问题为导向的方法：你到底想构建什么？

So I feel, again, we go back to this problem first approach of what is your what is it that you're trying to build?

比如，你想为客户提供一个可靠的应用，不会做错事。

Like, you're trying to build a reliable application for your customers that's not going to do a bad thing.

它总是会做正确的事。

Like, it's always going to do the right thing.

或者如果它做了错事，你也能迅速得到警报。

Or if it is doing a wrong thing, you are you are basically alerted, like, very quickly.

对吧？

Right?

所以我把它分为两个部分。

So the I break this down into two parts.

比如，没有人会在不进行测试的情况下直接部署应用程序。

Like, one is you like, nobody goes into deploying an application without actually, like, you know, just testing that.

这种测试可能是模糊测试，也可能是我有这10个问题，无论我做任何更改，它们都不能出错，我就构建这些内容，称之为评估数据集。

This testing could be wipes or this testing could be, okay, I had this 10 questions that it should not go wrong no matter what changes I make and let me build this and let's call this an evaluation dataset.

现在，假设你构建并部署了它，然后你发现，好吧，现在我需要了解它是否在做正确的事。

Now let's say you build this, you deployed this and then you figured, okay, now I need to understand whether it's doing the right thing or not.

如果你是一个高吞吐量或高交易量的客户，你不可能手动去逐一评估所有追踪记录。

So if you're a high throughput or like a high transaction customer, you cannot tactically sit and evaluate all the traces.

对吧？

Right?

你需要一些指标来判断哪些地方是你应该关注的。

You need some indication to understand what are the things that I should look at.

这时候生产监控就派上用场了——你无法预测代理可能出错的所有情况，但所有这些隐性信号和显性信号都会反馈给你，告诉你哪些追踪记录需要检查。

And this is where production monitoring comes into the picture that you cannot predict your the base in which your agent could be doing wrong, but all of these other implicit signals and explicit signals, those are going to communicate back to you what what are the traces that you need to look at.

而这就是生产监控的作用所在。

And that is where production monitoring helps.

一旦你获得了这类追踪数据，就需要分析在这些不同类型的交互中出现了哪些失败模式。

And once you get this kind of traces, you need to examine what are the failure patterns that you're seeing in these different types of interactions.

有没有哪些事情是我真正关心、绝对不希望发生的？

And is there something that I really care about that should not happen?

如果出现了这类故障模式，我就需要考虑为它构建一个评估数据集。

And if that kind of failure modes are happening, then I need to think about building an evaluation dataset for it.

比如说，我为我的代理构建了一个评估数据集，专门用于处理退款请求，而我明确配置了它不应提供退款。

And, okay, let's say I built an evaluation dataset for my agent trying to offer refunds where explicitly I have configured it not to.

于是我构建了这个评估数据集，然后对工具、提示词或其他内容进行了修改，并部署了产品的第二个版本。

So I built this evaluation data set and then like I made my changes in tools or prompts or whatever, and then I deployed the second version of the product.

对吧？

Right?

但现在并不能保证这是你唯一会遇到的问题。

Now there is no guarantee that this is the only problem that you're going to see.

你仍然需要生产监控来捕捉可能遇到的各种其他问题。

You still need production monitoring to actually have, like you know, catch different kinds of problems that you might encounter.

所以我觉得评估很重要。

So I feel evals are important.

生产监控也很重要。

Production monitoring is important.

但认为仅靠其中一种就能解决所有问题的观点，在我看来完全是不可取的。

But this notion of only one of them is going to solve things for you, that is completely dismissible in my opinion.

好的。

Alright.

非常合理的回答。

A very reasonable answer.

这里的关键并不是简单地两者都做。

And the point here isn't it's not just as simple as do both.

而是要捕捉不同的问题，单一方法无法覆盖你需要关注的所有方面。

It's more that there are different things to catch, and one approach won't catch all the things you need to be paying attention to.

没错。

Exactly.

太棒了。

Awesome.

我应该退后两步，谈谈在2025年下半年，'eval'这个词承载了多大的重量。

I ought to take two steps back and kind of talk about how much weight the term eval has had to take in the second half of twenty twenty five.

因为当你去见一家数据标注公司时，他们会告诉你，我们的专家在编写eval。

Because you go meet a data labeling company and they tell you, our experts are writing evals.

然后你又听到很多人说，产品经理应该编写eval，它们是新的PRD。

And then you have all of these folks saying that PMs should be writing evals, they're the new PRDs.

接着又有人声称eval几乎就是一切，也就是你应当构建来改进产品的反馈循环。

And then you have folks saying that evals is pretty much everything, which is the feedback loop you're supposed to be building to improve your products.

现在，作为初学者，退后一步想想，什么是eval？

Now step back as a beginner and kind of think, what are evals?

为什么人人都在说eval？

Why is everyone saying evals?

但实际上，这些都是过程中的不同部分。

And these are actually different parts of the process.

从某种意义上说，没有人是错的，因为这些确实属于评估。

Nobody's wrong in the sense that, yes, these are evals.

但当一家数据标注公司告诉你，他们的专家在编写评估时，他们实际上指的是错误分析，或者专家只是标注哪些内容应该是正确的。

But when a data labeling company is telling you that our experts are writing evals, they're actually referring to error analysis or experts just leaving notes on what should be right.

律师和医生也会做评估。

Lawyers and doctors write evals.

但这并不意味着他们在构建大语言模型的裁判，或构建整个反馈循环。

That doesn't mean they're building LLM judges or they're building this entire feedback loop.

当你说到产品经理应该编写评估时，并不意味着他们必须创建一个足以投入生产的大语言模型裁判。

And when you say that a PM should be writing evals, doesn't mean they have to write an LLM judge that's good enough for production.

我认为对此也有非常明确的做法，我支持KD的观点：你无法提前预知是需要构建一个大语言模型裁判，还是只需要利用生产环境监控中的隐式信号等。

I think there's also very prescriptive ways of doing this and plus one to KD, which is you cannot predict upfront if you need to be building an LLM judge versus you need to be using implicit signals from production monitoring, etc.

我认为马丁·福勒在2000年代曾提出过一个术语叫‘语义扩散’，意思是有人创造了一个术语，大家就开始用自己的定义去扭曲它，最终你反而失去了它原本的含义。

I think Martin Fowler at some point had this term called semantic diffusion back in the 2000s, which kind of means that someone comes up with the term, everybody starts butchering it with their own definitions, and then you kind of lose the actual definition of it.

这正是如今‘评估’、‘智能体’或AI领域任何术语正在发生的情况——每个人看到的都是它不同的侧面，我想。

That is kind of what is happening to evals or agents or any word in AI as of today, everybody kind of sees a different side to it, I guess.

但如果你让一群从业者坐在一起，问他们：为AI产品构建可操作的反馈循环重要吗？

But if you make a bunch of practitioners sit together and ask them, is it important to build actionable feedback loop for AI products?

我想他们都会同意。

I think all of them will agree.

不过，具体如何实现，真的取决于你的应用场景本身。

Now, how you do that really depends on your application itself.

当你面对复杂用例时，构建LLM评判器会极其困难，因为你看到大量新兴模式。

When you go to complex use cases, it's incredibly hard to build LM judges because you see a lot of emerging patterns.

如果你构建一个评判器来测试冗长性之类的问题，结果却发现出现了新的模式，而你的LLM评判器无法捕捉到。

If you build a judge that would test for verbosity or something like that, turns out that you're seeing newer patterns that your LLM judge is not able to catch.

然后你就不得不构建过多的评估标准。

And then you just end up building too many evals.

到了这个时候，不如直接观察用户信号，修复问题，检查是否出现倒退，然后继续前进，而不是去构建这些评判器。

And at that point, it just makes sense to look at your user signals, fix them, check if you have regressed and move on instead of actually building these judges.

所以一切都取决于具体情况。

So it all depends.

想想看，每个机器学习从业者都会告诉你，这真的取决于上下文。

Think one statement that every ML practitioner will tell you is it really depends on the context.

别对那些所谓的标准方法过于执着，它们会不断变化。

Don't be obsessed with prescriptions they're going to change.

这是一个非常重要的观点，尤其是现在‘评估’这个词对不同人意味着这么多不同的东西。

That's such an important point, this idea that especially that evals just means many things to different people now.

它只是一个涵盖太多事物的术语。

It's just like a term for so many things.

当你把评估看作数据标注公司提供的东西，或者产品经理所指的内容时，谈论评估本身就变得很复杂。

And it it's complicated to just talk about evals when you're when you see it as the stuff data labeling companies are giving you and things PM are right.

还有基准测试。

And there's also benchmarks.

人们有时也会把基准测试称为评估。

People call benchmarks a little bit evals.

这就像是

It's like

我最近和一个客户交谈，他们告诉我我们在做评估。

I I recently spoke to a client who told me we do evals.

是的。

Yeah.

我当时就想，好吧。

And I was like, okay.

你能给我看看你们的数据集吗？

Can you show me your dataset?

他们说，不行。

And say, no.

我们只是看了 LM Arena 和人工分析。

We just checked LM Arena and artificial analysis.

这些是你们知道的独立基准，我们知道这个模型最适合我们的用途，而我却说，你们根本没做评估。

These are, you you know, independent benchmarks, and we know that this model is the right one for our use And I'm like, you're not doing eval.

那不是评估。

That's not eval.

那是一次模型评估。

It was a model eval.

但它

But it

这说得通。

makes sense.

比如，这个词

Like, the word

你知道，它可以在那种语境下使用。

know, it could be used in that context.

我明白为什么人们会这么想。

I get why people think that.

但，是的，现在反而让事情更混乱了。

But, yeah, now it's just confusing it even more.

对。

Yep.

我脑海中还有一条进一步的疑问，我觉得这成为重大争议的原因是云代码（Cloud Code）。

Just like one more line of questioning here that I think that's on my mind is the reason this became kind of a big debate is Cloud Code.

云代码的负责人鲍里斯，不，不是这样的。

The head of Cloud Code, Boris, like, no.

我们不在云代码上做评估。

We don't do evals on Cloud Code.

全靠感觉。

It's all vibes.

Kriti，你能分享一下Codex和Codex团队是如何进行评估的吗？

What can you share, Kriti, on Codex and the Codex team of how you approach evals?

对于Codex，我们采取了一种平衡的方法，你需要做评估，同时也必须认真倾听客户的声音。

So Codex, we have, like, this balanced approach of, like, you know, you need to have evals and you need to definitely listen to your customers.

我认为亚历克斯最近刚上过你的播客，他一直在谈论你们如何极度专注于打造正确的产品。

And I think Alex has been on your podcast recently and he's been talking about how you're extremely focused on building the right product.

对吧？

Right?

而其中非常重要的一部分就是倾听客户的需求。

And a part of a big part of it is basically listening to your customers.

与其它领域的智能体相比，编码智能体具有非常独特的特点，因为它们专为可定制性而设计，面向工程师群体。

And coding agents are extremely unique compared to agents for other domains in the sense that these are actually built for customizability, and these are built for engineers.

所以，编码智能体并不是一个能解决前五大工作流或前六大工作流之类问题的产品。

So coding agent is not a product which is going to solve, like, these top five workflows or, like, top six workflows or whatever.

对吧？

Right?

它的设计目标是支持多种方式的自定义。

It's meant to be customizable in multi different ways.

这意味着你的产品将被用于各种不同的集成、工具和应用场景。

And the implication of that is that your product is going to be used in different integrations and different kinds of tools and different kinds of things.

因此，要为客户使用产品时可能产生的所有交互类型构建评估数据集变得极其困难。

So it gets really hard to build an evaluation dataset for all kinds of interactions that your customers are gonna use your product for.

对吧？

Right?

但话说回来，你也需要明白，如果我要做改动，至少不能损害产品核心的功能。

But that said, you also need to understand that, okay, if I'm gonna make a change, it's at least not going to damage something that is really core to the product.

因此，我们为此设置了评估机制。

So we have evaluations for doing that.

但同时，必须极其谨慎地理解客户是如何使用它的。

But at the same time, take extreme care on understanding how the customers are using it.

例如，我们最近开发了这个代码审查产品，它获得了极大的用户增长。

For example, we built this code review product recently, and it has been gaining, like, extreme amount of traction.

我觉得，OpenAI内部以及我们外部客户中的许多错误都已经被它捕捉到了。

And I feel like many, many bugs in OpenAI as well as, like, even our external customers are getting caught with this.

现在，假设我要对代码审查模型进行调整，或者改变我用来训练它的强化学习机制。

And now let's say if I'm making a model change to the course review or, like, a different kinds of RL mechanism that I trained with it.

如果我要部署它，我肯定希望进行A/B测试，确认它是否真的能发现正确的错误，以及用户对此的反应如何。

And now if I'm going to deploy it, I definitely do want to AP test and identify whether it's actually finding the right mistakes and are users how are users reacting to it.

有时候，如果用户因为错误的代码审查而感到烦躁，他们甚至会直接关闭这个产品。

And sometimes, like, if users do get annoyed by your incorrect code reviews, they go to the extent of just switching off the product.

对吧？

Right?

所以这些是你需要关注的信号，以确保你的新改动做对了事情。

So those are the signals that you want to look at and make sure that your new changes are doing the right thing.

对我们来说，提前想到这些场景并为此开发评估数据集是极其困难的。

And it's extremely hard for us to think of these kind of scenarios beforehand and develop evaluation datasets for it.

所以我觉得两者都有。

So I feel like there's a bit of both.

比如，有很多直觉，也有很多客户反馈。

Like, there's a lot of vibes and there's a lot of, like, customer feedback.

我们非常积极地关注社交媒体，了解是否有人遇到某些问题，并迅速修复。

And we are super active on, like, the social media to understand if anybody's having certain types of problems and quickly fix that.

所以我觉得这该怎么说呢？

So I feel it's it's a how do I put this?

这就像你在这里做的一系列事情。

It's it's like a domain of things that you do here.

这太有道理了。

That makes so much sense.

好的。

Okay.

我听到的是Codecs pro评估，但这还不够。

What I'm hearing Codecs pro evals, but it's not enough.

你需要，是的。

You need to Yes.

但也要观察客户的行为和反馈。

But also just watch customer behavior and feedback.

而且还有一些直觉，比如，这种感觉好吗？

And also there's some vibes just like, is this feeling good?

当我使用它时，生成的是让我兴奋的、我们认为很棒的代码吗？

Is this as I'm using it, generating great code that I'm excited about that we think is great.

我不认为有人会说，我有一套具体的评估标准，可以完全依赖它，然后就不用再考虑其他任何事情了。

I I don't think, like, if anybody is coming and saying that, like, my I have this concrete set of evas that I can, like, bet my life on and then I don't need to think about anything else.

这根本行不通。

Like, it it's not gonna work.

每当我们推出新模型时，团队都会聚在一起，测试各种不同的东西。

And every new model that we're gonna launch, we get together as a team and, like, you know, test different things.

每个人都在专注于不同的事情。

Each each each person is, like, concentrating on something else.

我们有一份难题清单，会把这些难题交给模型，看看它们的进展如何。

And, like, we have this list of hard problems that we have, and we throw that to the model and see how well they are progressing.

可以说，每个工程师都有自己的定制评估标准，只是为了了解新产品在新模型中的表现。

So it's, like, custom evals for each engineer, you would say, and just, like, understand what the, product is doing in its new model.

如果你是创始人，创业最难的部分不是拥有点子。

If you're a founder, the hardest part of starting a company isn't having the idea.

而是要在不被后台事务压垮的情况下扩大业务。

It's scaling the business without getting buried in back office work.

这就是Brex的用武之地。

That's where Brex comes in.

Brex 是为创始人打造的智能金融平台。

Brex is the intelligent finance platform for founders.

使用 Brex，您可以获得高额度的企业信用卡、便捷的银行服务、高收益的现金管理，以及一支由 AI 代理组成的团队，为您处理繁琐的财务任务。

With Brex, you get high limit corporate cards, easy banking, high yield treasury, plus a team of AI agents that handle manual finance tasks for you.

它们会替您完成所有不想做的事务，比如报销费用、排查交易中的浪费，并根据您的规则自动生成报告。

They'll do all the stuff that you don't wanna do, like file your expenses, scour transactions for waste, and run reports all according to your rules.

借助 Brex 的 AI 代理，您能更快推进工作，同时保持完全掌控。

With Brexis AI agents, you can move faster while staying in full control.

美国每三家初创企业中就有一家已经在使用 Brex。

One in three startups in The United States already runs on brex.

您也可以在 brex.com 上体验。

You can too at brex.com.

我们已经聊了将近一个小时，却还没来得及讨论您开发的、在课程中教授的、将我们刚才谈到的所有内容整合成一套逐步构建 AI 产品的强大软件开发流程。

We've been talking for almost an hour already, and we haven't even covered your extremely powerful software development workflow for building AI products that you developed, that you teach in your course, that you basically combined all the stuff we've been talking about into a step by step approach to building AI products.

您称之为‘持续校准、持续开发框架’。

You call it the Continuous Calibration Continuous Development Framework.

我们来展示一个视觉化图表，让大家清楚我们到底在说什么，然后一步步解释这个框架是什么、它是如何运作的，以及团队如何转变他们构建AI产品的方式，采用这种方法来避免大量痛苦和麻烦。

Let's pull up a visual to show people what the heck we're talking about, and then just walk us through what this is, how this works, how teams can shift the way they build their AI product to this approach to help them avoid a lot of pain and suffering.

在解释这个生命周期之前，先讲个小故事，说明为什么基里塔和我提出了这个框架：我们一直在接触很多公司，它们都受到竞争对手的压力，因为大家都在开发智能代理，认为我们也应该构建完全自主的代理。

Before we go about explaining the life cycle, a quick story on why Kirita and I came up with this is because there are tons of companies that we keep talking to that have the pressure from their competitors because they're all building agents, we should be building agents that are entirely autonomous.

事实上，我和一些客户合作过，为他们构建了端到端的智能代理。

And we I did end up working with a few customers where we built these end to end agents.

结果发现，由于一开始你并不清楚用户会如何与你的系统互动，也不确定AI会产生怎样的回应或行动，当你面对一个包含四五步、做出大量决策的庞大工作流时，要修复问题会非常困难。

Turns out that because you start off at a place where you don't know how the user might interact with your system and what kind of responses or actions the AI might come up with, It's really hard to fix problems when you have this really huge workflow, which is taking four or five steps, making tons of decisions.

你最终会陷入大量的调试和临时补丁中，比如我们当时在为一个客户服务场景构建系统——这也是我们在通讯中提到的例子。

Just end up debugging so much and then kind of hot fixing to the point where at a time we were building for a customer support use case, which is the example that we give in the newsletter as well.

我们不得不关闭了这个产品，因为我们一直在做太多临时修复。

And we had to shut down the product because we were doing so many hot fixes.

而且我们根本无法统计所有不断涌现的新问题。

And there was no way we could count all the emerging problems that were coming up.

网上也有不少相关的新闻。

And there's also quite some news online.

最近，我想加拿大航空就发生过一件事，他们的一个代理预测或虚构了一项退款政策，而这项政策并不在他们原始的规范中。

Recently, I think Air Canada had this thing where one of their agents predicted or hallucinated a policy for a refund, which was not part of their original playbook.

他们不得不去购买这项服务，因为涉及法律问题。

And they had to go buy it because legal stuff.

已经发生了许多令人恐惧的事件。

And there have been a ton of really scary incidents.

这正是这个想法的由来，对吧？

And that's where the idea comes from, right?

你该如何设计，才能不失去客户信任，同时确保你的代理或AI系统不会做出对公司的安全构成严重威胁的决策？

How can you build so that you don't lose customer trust and you don't end up or your agent or AI system doesn't end up making decisions that are super dangerous to the company itself?

同时，还要构建一个飞轮效应，让你在过程中不断改进产品。

At the same time, build a flywheel so that you can improve your product as you go.

是的。

Right.

正是在这种背景下，我们提出了持续校准和持续开发的理念。

And that's where we came up with this idea of continuous calibration, continuous development.

这个想法很简单，就是我们有一个循环的右侧，即持续开发，其中你界定能力范围并整理数据，本质上是建立一个数据集，明确你的预期输入和预期输出是什么。

The idea is pretty simple, which is we have this right side of the loop, which is continuous development, where you scope capability and curate data, essentially get a data set of what your expected inputs are and what your expected output should be looking at.

在开始构建任何AI产品之前，这是一个非常有益的练习，因为很多时候你会发现团队内部对产品应有的行为方式根本没有达成一致。

This is a very good exercise before you start building any AI product, because many times you figured out that a lot of the folks within the team are just not aligned on how the product should behave.

这时候，你的产品经理和领域专家就能提供更多的信息。

And that's where your PMs can really give in a lot more information and your subject matter experts as well.

于是你就有了一个AI产品应该表现优异的数据集。

So, you have this data set that your AI product should be doing really well on.

它并不全面，但足以让你起步。

It's not comprehensive, but it lets you get started.

然后你搭建应用，并设计合适的评估指标。

And then you set up the application and then design the right kind of evaluation metrics.

我特意使用‘评估指标’这个术语，尽管我们常说‘evals’，因为我希望明确说明：评估是一个过程，而评估指标是你在过程中需要关注的维度，对吧？

And I intentionally use the term evaluation metrics, although we say evals because I just want to be very specific on what it is because evaluation is a process, evaluation metrics are dimensions that you want to focus on during the process, right?

接着你就开始部署，运行你的评估指标。

And then you go about deploying, run your evaluation metrics.

第二部分是持续校准，即你发现最初未曾预料到的行为的部分。

And the second part is the continuous calibration, which is the part where you understand what behavior you hadn't expected in the beginning.

因为在开发过程中，你正在优化这个数据集。

Because when you start the development process, you have this data set that you're optimizing for.

但更常见的是，你会意识到这个数据集并不够全面，因为用户会以你未曾预测的方式与你的系统互动。

But more often than not, you realize that that data set is not comprehensive enough because users start behaving with your systems in ways that you did not predict.

而这就是你需要进行校准的地方。

And that's where you want to do the calibration piece.

我已经部署了我的系统。

I've deployed my system.

现在我发现了一些我根本没有预料到的模式。

Now I see that there are patterns that I did not really expect.

你的评估指标应该能为你提供这些模式的一些洞察。

And your evaluation metrics should give you some insight into those patterns.

但有时你会发现，这些指标也不够充分。

But sometimes you figure out that those metrics were also not enough.

你可能会遇到一些之前从未想到的新错误模式。

And you probably have new error patterns that you've not thought about.

这时你需要分析行为，发现错误模式。

And that's where you analyze your behavior, spot error patterns.

你不仅要针对发现的问题进行修复，还要设计新的评估指标，以识别这些新兴模式。

You apply fixes for issues that you see, but you also design newer evaluation metrics to figure out that they are emerging patterns.

但这并不意味着你总是需要设计新的评估指标。

And that doesn't mean you should always design evaluation metrics.

有些错误你只需修复即可，无需再回头，因为它们只是孤立的问题。

There are some errors that you can just fix and not really come back to because they're very spot errors.

比如，某个工具调用出错，仅仅是因为你的工具定义得不够完善，诸如此类的情况。

For instance, there's a tool calling error just because your tool wasn't defined well and stuff like that.

你可以直接修复并继续前进。

You can just fix it and move on.

对。

Right.

这基本上就是AI产品生命周期的样子。

And this is pretty much how an AI product lifecycle would look like.

但我们特别提到的是，在进行这些迭代时，要从低自主性迭代开始，逐步过渡到高控制性迭代。

But what we specifically also mentioned is while you're going through these iterations, try to think of lower agency iterations in the beginning, and higher control iterations.

这意味着要限制AI系统所能做出的决策数量，确保人类始终参与其中，然后随着时间推移逐步放宽限制，因为你正在构建一个行为飞轮，逐步理解哪些用例正在出现，以及用户如何使用系统。

What that means is constrain the number of decisions your AI systems can make and make sure that they're humans in the loop and then increase that over time because you're kind of building a flywheel of behavior and you're understanding what kind of use cases are coming in or how your users are using the system.

其中一个例子，我想我们在通讯稿中提到过，就是客户服务。

And one example, I think we give in the newsletter itself is the customer support.

这是一个很好的图示，展示了如何将自主性和控制力视为两个维度，随着迭代推进，你的AI系统自主决策能力不断提升，而人工控制逐步降低。

This is a nice image that kind of shows how you can think of agency and control as two dimensions, and each of your versions keep on increasing the agency, or the ability of your AI system to make decisions and lower the control as you go.

我们举的一个例子是客户服务代理，可以将其划分为三个版本。

And one example that we give is that of the customer support agent, where you can break it down into three versions.

第一个版本只是路由，即你的代理能否正确分类并将特定工单转到合适的部门？

The first version is just routing, which is, is your agent able to classify and route a particular ticket to the right department?

有时候你看到这里可能会想，只是做路由真的有那么难吗？

And sometimes when you read this, you probably think, is it so hard to just do routing?

为什么代理不能轻松完成这个任务？

Why can't an agent easily do that?

当你进入企业场景时，路由本身可能是一个极其复杂的问题。

And when you go to enterprises, routing itself can be a super complex problem.

任何零售公司，任何你想到的热门零售企业，都有层级化的分类体系。

Any retail company, any popular retail company that you can think of has hierarchical taxonomies.

大多数情况下，这些分类体系都非常混乱。

Most of the times, the taxonomies are incredibly messy.

我曾参与过一些案例，其中分类体系可能包含某种层级结构，然后直接列出‘鞋子’，接着是‘女鞋’和‘男鞋’，全都处于同一层级，而理想情况下应该是‘鞋子’作为父类，‘女鞋’和‘男鞋’作为子类。

I have worked in use cases where you probably have taxonomy that says some kind of hierarchy and then that says shoes, and then women's shoes and men's shoes all at the same layer where ideally you should be having shoes and then women's shoes and men's shoes should be sub classes.

然后你可能会想，好吧，我可以把这些合并起来，但继续深入后你会发现，还有另一个关于鞋子的分类区域写着‘女士用’和‘男士用’，而且这些并没有被整合。

And then you're like, okay, fine, I could just merge that and you go further and you see that there's also another section on the shoes that says for women and for men, and it's just not aggregated.

不知为何，这个问题一直没有被解决。

It's not fixed for some reason.

所以如果一个代理看到这种分类体系，它该怎么做？

So if an agent kind of sees this kind of a taxonomy, what is it supposed to do?

它应该被路由到哪里？

Where is it supposed to route?

很多时候，我们直到真正开始构建并深入理解时，才会意识到这些问题。

And a lot of the times, we are not aware of these problems until you actually go about building something and understanding it.

当这类问题出现时，人类代理会知道接下来该检查什么。

And when these kinds of problems or real human agents see these kinds of problems, they know what to check next.

也许他们会发现，位于‘鞋子’下的‘为女性’和‘为男性’这个节点最后一次更新是在2019年，这意味着它只是一个废弃的、无人使用的节点。

Maybe they realize that the node that says for women and for men that's under shoes was last updated in 2019, which means that it's just a dead node that's lying there and not being used.

所以他们知道，我们应该去查看另一个节点之类的。

So they kind of know that, okay, we're supposed to be looking at a different node and stuff like that.

我并不是说代理无法理解，或者模型没有能力理解这些内容。

And I'm not saying agents cannot understand this or models are not capable enough to understand this.

但企业内部存在许多极其古怪的规则，这些规则从未被记录下来。

But there are really weird rules within enterprises that are not documented anywhere.

你需要确保代理掌握所有这些背景信息，而不是简单地把问题扔给它去处理。

And you want to make sure that the agents have all of that context instead of just throwing the problem at that tray.

回到我们之前的版本，路由是一个你拥有高度控制权的环节，因为即使你的代理错误地将问题转接到错误的部门，人类仍然可以介入并撤销这些操作。

Coming back to the versions we had, routing was one where you have really high control, because even if your agent routes to the wrong department, humans can take control and undo those actions.

同时，在这个过程中，你也会发现你可能面临大量数据问题，需要加以修复，确保你的数据层足够完善，以支持代理正常运行。

And along the way, also figure out that you probably are dealing with a ton of data issues that you need to fix and make sure that your data layer is good enough for the agent to function.

我们接下来要做的是，正如我们所说的协作者角色：一旦你经过几次迭代确认路由功能正常，并解决了所有数据问题，就可以进入下一步——让代理根据客户支持人员的标准操作流程提供建议，对吧？

We do is what we said of a copilot, which is now that you've figured out routing works fine after a few iterations and you fixed all of your data issues, you could go to the next step, which is, my agent provide suggestions based on some standard operating procedures that we have for the customer support agent, right?

它只需生成一个草稿，供人类进行修改。

And it could just generate a draft that the human can make changes to.

当你这样做时，你也在记录人类的行为，也就是说，客户支持人员使用了多少草稿内容，又删减了哪些部分。

And when you do this, you're also logging human behavior, which means that how much of this draft was used by the customer support agent or what was omitted.

因此，当你这么做时，实际上是在免费获取错误分析，因为你完整记录了用户的所有操作，这些数据可以重新反馈到你的闭环系统中。

So you're actually getting error analysis for free when you do this, because you're literally logging everything that the user is doing that you could then build back into your flywheel.

然后我们说，在这之后，一旦你发现这些草稿效果良好，而且大多数情况下人类几乎不做修改，直接使用这些草稿，这时你就该转向端到端的解决方案助手，它不仅能起草解决方案，还能自动分类工单。

And then we say, post that, once you figured out that those drafts look good, and most of the times, maybe humans are not making too many changes, they're using these drafts as is, that's when you want to go to your end to end resolution assistant that could draft a resolution that could sort the ticket as well.

对。

Right.

这些就是代理能力的各个阶段，你从低代理能力开始，逐步提升到高代理能力。

And those are the stages of agency where you start with low agency and then you go up high rate.

我们还整理了一个非常不错的表格，列出了每个版本中你需要做什么，以及你能学到什么，从而推动你进入下一步。

We also have this really nice table that we put together, which is what do you do at each version and what you learn that can enable you to go to the next step.

你能获得哪些信息来反馈到这个循环中，对吧？

And what information do you get that you can feed into the loop, right?

当你只进行路由时，你会获得更高质量的路由数据。

When you're just doing your routing, you have better quality routing data.

你也会知道需要构建什么样的提示词来改进路由系统。

You also know what kind of prompts you need to be building to improve the routing system.

本质上，你正在为上下文工程建立结构，并构建你想要打造的反馈循环。

Essentially, you're figuring out your structure for context engineering and building that flywheel that you want to write.

在我讲解这些的时候，我也想明确两点。

And while I go through this, I want to also be very clear that two things.

第一，当你以CCCD的思路来构建时，并不意味着你一次性解决了所有问题。

One is when you build with CCCD in mind, it doesn't mean that you've fixed the problem all for once.

你可能已经经历了V3阶段，并看到了一种你以前从未想象过的数据分布。

It's possible that you've probably gone through V3 and you see a new distribution of data that you never previously imagined.

但这只是降低风险的一种方式，即在走向完全自主之前，你已经获得了足够多关于用户如何与你的系统互动的信息。

But this is just one way to lower your risk, which is you get enough information about how users behave with your system before going to a point of complete autonomy.

第二点是，你实际上也在构建一个隐式的日志系统。

And the second thing is you're also kind of building this implicit logging system.

很多人过来告诉我们：哦，等等，不是有评估系统吗？

A lot of people come and tell us that, oh, wait, there are evals, right?

那为什么还需要这样的东西呢？

Why do you need something like this?

仅仅构建一堆评估指标并将其投入生产的问题在于，这些指标只能捕捉到你已经意识到的错误。

The issue with just building a bunch of evaluation metrics and then having them in production is evaluation metrics catch only the errors that you're already aware of.

但还有很多新兴模式，只有在将系统投入生产后你才能真正理解。

But there can be a lot of emerging patterns that you understand only after you put things in production.

因此，对于这些新兴模式，你正在创建一种低风险的框架，以便理解用户行为，而不是陷入大量错误集中爆发、不得不一次性修复的境地。

So for those emerging patterns, you're kind of creating a low risk kind of a framework so that you could understand user behavior and not really be in a position where there are tons of errors and you're trying to fix all of them at once.

但这并不是唯一的方法。

And this is not the only way to do it.

有非常多不同的方式。

There are tons of different ways.

你需要决定如何限制你的自主性。

You want to decide how you constrain your autonomy.

它可以基于代理所采取的动作数量，这正是我们在本例中所做的。

It could be based on the number of actions that the agent is taking, which is what we do in this example.

它也可以基于主题。

It could be based on topic.

有些领域对于某些决策来说，让系统完全自主的风险非常高。

There are just some domains where it's pretty high risk to make a system completely autonomous for certain decisions.

但对于其他一些主题，根据问题的复杂性，让它们完全自主是可以接受的。

But for some other topics, it's okay to make them completely autonomous and depending on the complexity of the problem.

这时，你真正需要的是产品经理、工程师和领域专家共同达成一致，如何构建系统并持续改进它。

And that's where you really want your product managers, your, you know, engineers, and subject matter experts to align on how to build the system and continuously improve it.

这个想法主要是行为校准，同时在进行这种校准时不要失去用户的信任，我想。

The idea is just behavior calibration and not losing user trust as you do that behavior calibration, I guess.

如果有人想深入了解，我们会把他们引导到这篇实际的文章。

We'll link folks to this actual post if they wanna go really deep.

你基本上会一步步地经历所有这些步骤，还有很多示例。

You basically go through all of these steps by step, a bunch of examples.

这里的重点是，正如你所说，你所描述的一切都是为了使其成为持续、迭代的过程，逐步向更高自主性、更少控制的方向推进，甚至称之为持续校准、持续开发，其实就是在传达这是一种迭代的过程。

And the idea here is, as you said, that, like, the reason everything about what you're describing here is about making it continuous and iterative and kind of moving along this progression of higher autonomy, less control, and this idea of even calling it continuous calibration, continuous development is communicating, it's this kind of iterative process.

为了明确一下，这个命名其实是对持续集成、持续部署（CI/CD）的一种致敬。

And just to be clear, naming is kind of a ode to CI CD, continuous integration, continuous deployment suite.

这里的理念是，这是适用于人工智能的版本，不是仅仅集成单元测试并持续部署，而是运行评估、查看结果、迭代你所关注的指标，找出问题所在并不断改进。

And the idea here is like that, this is the version of that for AI, where instead of just like integrating to unit tests and deploying constantly, it's running evals, looking at results, iterating on on the metrics you're watching, figuring out where it's breaking and iterating on that.

太棒了。

Awesome.

好的。

Okay.

所以，我们会引导大家去阅读这篇帖子，如果他们想深入了解的话。

So again, we'll point people to this post if they wanna go deeper.

这是一次非常棒的概述。

That was a a great overview.

在我转向这个框架相关的其他话题之前，你认为还有什么是人们需要知道的重要内容吗？

Is there anything else before I go into different topic around this framework specifically that you think is important for people to know?

我们经常被问到的一个问题是：我怎么知道什么时候该进入下一阶段，或者当前的校准已经足够了？

I think one of the most common questions we get is how do I know if I need to go to the next stage or if this is calibrated enough, right?

其实并没有一套明确的规则可以遵循，但核心在于最小化意外情况。比如说，如果你每一两天就进行一次校准，发现没有出现新的数据分布模式，用户的行为也一直很稳定，那么你获得的信息量就非常有限了。

There's not really a rule book you can follow, but it's all about minimizing surprise, which means, let's say you're calibrating every one or two days and you figured out that you're not seeing new data distribution patterns, your users have been pretty consistent with how they're behaving with the system, then the amount of information you gain is kind of very low.

这时候你就知道可以进入下一阶段了，对吧？

And that's when you know you can actually go to the next stage, right?

到了这个阶段，重点就变成了清理工作。

And it's all about the wipes at that point.

你知道自己准备好了吗？

Like, do you know you're ready?

你没有收到任何新信息。

You're not receiving any new information.

但也要理解，有时某些事件会完全打乱你系统的校准。

But also, it really helps to understand that sometimes there are events that could completely mess up the calibration of your system.

例如，GPD 4.0 已经不存在了，或者将在 API 中被弃用。

An example is GPD four point zero doesn't exist anymore, or it's going to be deprecated in APIs as well.

因此，大多数使用 4.0 的公司应该切换到 5.0，而 5.0 具有非常不同的特性。

So most companies that were using four or should switch to five, and five has very different properties.

所以当你发现校准再次偏离时，就需要回到这个过程重新进行。

So that's where your calibration is off again, you want to go back and do this process again.

有时用户随着时间推移也会以不同方式与系统互动，或者用户行为会发生变化。

Sometimes users start behaving with systems also differently over time or user behavior evolves.

即使是消费类产品，对吧？

Even with consumer products, right?

你现在已经不会用两年前的方式和 ChatGPT 交流了，因为它的能力已经提升太多了。

You don't talk to ChatGPT the same way you were talking, say, two years ago, just because, you know, the capabilities have increased so much.

另外，当这些系统能够完成一项任务时，人们就会感到兴奋。

Also just people get excited when these systems can solve one task.

他们也想尝试用它来处理其他任务。

They want to try it out on other tasks as well.

我们曾经为承保人构建了这个系统，对吧？

We built this system for underwriters at some point, right?

承保是一项繁琐的任务。

Underwriting is a painful task.

有些协议，比如贷款申请，长达三四十页。

There are agreements that are like, you know, loan applications are like 30 or 40 pages.

这家银行的想法是构建一个系统，帮助承保人筛选保单和银行相关信息，以便审批贷款。

And the idea for this bank was to build a system that could help underwriters pick policies and information about the bank so that they could approve loans.

在整整三到四个月里，每个人都对这个系统印象深刻。

For a good three or four months, everybody was pretty impressed with the system.

我们甚至有承保人反馈，他们节省了大量时间等。

We had underwriters actually report gains in terms of how much time they were spending, etc.

三个月后，我们意识到他们对这个产品太过兴奋，开始提出一些我们从未预料到的深入问题。

Post three months, we realized that they were so excited with the product that they started asking very deep questions that we never anticipated.

他们会直接把整个申请文件丢给系统，然后问：对于这样一个案例，以前的核保人员是怎么做的？

They would just throw the entire application document at the system and go like, for a case that looks like this, what did previous underwriters do?

对用户来说，这看起来像是他们原有工作自然的延伸，但背后的技术实现却需要重大改变。

And for a user, that just seems like a natural extension of what they were doing, but the building behind it should significantly change.

现在，你需要理解‘对于这样一个案例’在贷款语境中究竟指的是什么。

Now, you need to understand what does for a case like this mean in the context of the loan itself.

是指特定收入范围的人群吗？

Is it referring to people of a particular income range?

还是指特定地理区域的人群之类的情况？

Or is it referring to people in a particular geo and stuff like that?

然后你需要调取历史文档，分析这些文档，再告诉他们：这才是实际情况，而不仅仅是说‘有政策X、Y、Z，你去查一下这个政策’。

And then you need to pick up historical documents, analyze those documents, and then tell them, okay, this is what it looks like versus just saying that there's a policy X, Y, and Z, and you want to look up that policy.

因此，对终端用户来说看似非常自然的需求，对产品构建者而言可能极其难以实现。

So something that might seem very natural to an end user might be very hard to build as a product builder.

你会看到，用户行为也会随着时间推移而演变。

You see that user behavior also evolves over time.

这时你就知道，需要回去重新调整了。

And that's when you know that you want to go back and recalibrate.

你认为当前人工智能领域哪些东西被过度炒作了？

What do you think is overhyped in the AI space right now?

更重要的是，你认为哪些东西被低估了？

And even more importantly, what do you think is is underhyped?

正如我所说，我对人工智能领域正在发生的各种事情持极度乐观的态度。

I am, as I said, like, super optimistic in different things that are going in AI.

所以我不会说有什么被过度炒作，但我感觉多智能体这个概念被误解了。

So I wouldn't say overhyped, but I feel kind of misunderstood is the concept of multi agents.

人们有一种观念，认为我面对一个极其复杂的问题。

People have this notion of, like, I have this incredibly complex problem.

于是我要把它分解成，嘿。

Now I'm gonna break it down into, hey.

你就是这个代理。

You are this agent.

负责这个。

Take care of this.

你就是这个代理。

You are this agent.

负责这个。

Take care of this.

如果我现在把所有这些代理连接起来，它们会以为自己进入了代理的乌托邦，但实际上根本不存在真正成功的多代理系统。

And now if I somehow connect all of these agents, they think they're the agent utopia, and it's never the case that there are incredibly successful multi agent systems that are built.

对吧？

Right?

这一点毫无疑问。

Like, there's no doubt about that.

但我认为，关键在于你如何限制系统偏离轨道的方式。

But I feel a lot of it comes in terms of how are you limiting the ways in which the system can go off tracks.

例如，如果你正在构建一个监督代理，而有一些子代理实际为监督代理执行工作，这是一种非常成功的模式。

And for example, like if you're building a supervisor agent and there are like sub agents that actually do the work for the super agent, supervisor agent, That is a very successful pattern.

但当你基于功能来划分职责，并期望所有这些部分能通过某种类似谣言传播的协议协同工作时，这种想法被严重误解了。

But coming with this notion of I'm going to divide the responsibilities based on functionality and somehow ex expect all of that to work together in some sort of, like, gossip protocol.

人们误以为你可以这样去做，这其实是非常错误的。

That is, like, extremely misunderstood that you could do that.

我认为，以当前的构建方式和模型能力，还远远达不到构建这类应用的水平。

I don't think, like, current ways of building and current, like, model capabilities are, like, right there in terms of, like, building those kind of applications.

我觉得这种想法被误解了，而不是被高估了。

I feel that is kind of misunderstood than overrated.

我认为它被低估了，虽然这可能很难让人相信，但我依然觉得编码代理被低估了——因为在推特和Reddit上，你经常能看到大量关于编码代理的讨论。

Underrated, I feel it's hard to probably believe, but I still feel coding agents are underrated in the sense that I feel like you can go on Twitter and you can go on Reddit and you see a lot of chatter about coding agents.

但如果你去和任何一家公司、尤其是非前沿领域的工程师交谈，你会发现编码代理的实际影响力和渗透率非常低。

But talking to an engineer in, like, any random company, especially outside of the area, you you can see like the amount of impact this coding agent can create and the penetration is very low.

所以我认为2025年和2026年将会是优化所有这些流程的绝佳年份，我相信这将为人工智能创造巨大的价值。

So I feel like 2025 and 2026 is going to be like an incredible year for optimizing all of these processes and I feel that is going to be creating a lot of value with AI.

关于第一点，这真的很有意思。

That's really interesting on that first point.

所以这里的观点是，你构建和使用一个能够自行分配子任务的代理，可能会比使用一堆所谓的Codex代理更成功。

So the idea there is you'll probably be more successful building and using an agent that is able to do its own sub agent splitting of work versus like a bunch of, say, Codex agents.

所以当你执行这个任务时，就去做那个任务。

So when you do this task, you do that task.

你可以让代理来做这些事情，而你作为人类来协调它们，或者你可以让一个更大的代理来协调所有这些事情。

You can have agents to do these things, and you as a human can orchestrate it, or you can have like one larger agent that is going to orchestrate all of these things.

但让代理之间通过点对点协议通信，尤其是在客户服务这样的使用场景中，很难控制哪个代理会回复你的客户，因为你必须在各个地方调整你的安全限制之类的东西。

But letting the agents communicate in terms of peer to peer kind of protocol and then especially doing this in a customer support kind of use case is incredibly hard to control what kind of agent is replying to your customer because you need to shift your guardrails everywhere and things like that.

是的。

Yeah.

好的。

Okay.

很棒的见解。

Great picks.

好的。

Okay.

阿什，你有什么想法？

Ash, what do you got?

我能说说评估吗？

Can I say evals?

我会被封杀吗？

Will I be canceled?

在哪个类别里？

On which in which category?

它们属于哪个类别？

Which which bucket do they go?

被高估了。

Overrated.

被高估了。

Overrated.

好的，说吧。

Okay, go for it.

我不会让你就这么轻易地

Won't Just let you get

开玩笑。

kidding.

我认为评估被误解了。

I think evals are misunderstood.

它们很重要，朋友们。

They are important folks.

我不是说它们不重要。

I'm not saying they're not important.

但我觉得，总是不停地换工具，不断去上手和学习新工具，这种做法被高估了。

But I think just this I'm going to keep jumping across tools and going to pick up and learn a new tool is overrated.

我仍然很传统，觉得你真的需要对你要解决的业务问题着迷。

I still am old school and feel like you would need really need to be obsessed with the business problem you're trying to solve.

人工智能只是一种工具。

AI is only a tool.

试着这样去想。

Try to think of it that way.

当然，你需要了解最新最前沿的技术，但不要过于沉迷于快速构建。

Of course, you need to be learning about the latest and greatest, but don't be so obsessed with just building so quickly.

如今，构建产品其实非常便宜。

Building is really cheap today.

设计更昂贵，真正思考你的产品、你要构建的东西。

Design is more expensive, really thinking about your product, what you're going to build.

它真的能解决一个痛点吗？

Is it going to really solve a pain point?

今天什么更有价值？

Is what is the more valuable today?

在未来近期内，这一点只会变得更加真实。

And it will only become more true in the near future.

对吧？

Right?

所以，真正专注于你的问题和设计是被低估的，而只是机械地构建则是被高估了，我想。

So really obsessing about your problem and design is underrated and just rote building is overrated, I guess.

太棒了。

Awesome.

好的。

Okay.

类似的问题。

Similar sort of question.

从产品角度来看，你认为明年AI会是什么样子？

From a product point of view, what do you think the next year of AI is gonna look like?

给我们描绘一下，到2026年左右，你认为事情会走向何方？

Give us a vision of where you think things are gonna go by, say, by the 2026.

是的。

Yeah.

我觉得后台代理或主动代理有很大的潜力，它们能够更深入地理解你的工作流程。

I feel there's a lot of promise in terms of this background agents or proactive agents who is like, they are going to, like, basically understand your workflow even more.

如果你想想AI今天在创造价值方面失败的主要原因，那主要是因为它不理解上下文。

If you think if you think of, like, where is AI failing to create value today, it's mainly about not understanding the context.

而它不理解上下文的原因，是因为它没有接入到实际工作发生的地方。

And the reason that it's not understanding the context is it's not plugged into the right places where actual work is happening.

对吧？

Right?

随着你越来越多地这样做，你可以给代理提供更多上下文，它就能开始看到你周围的世界，理解你正在优化的指标，或者你试图完成的活动类型。

And as you do more of this, you can give the agent more of context, and then it starts to see the world around you and understand what is the set of metrics that you're optimizing for or what are the kind of activities that you're trying to do.

从这里再往前走一步就很容易了，让代理反过来提醒你。

It is a very easy extension from there to actually gain more out of it and then let the agent prompt you back.

我们已经在Charge GPT Pulse中这样做了，它会给你每天更新你可能关心的内容。

We already do this in terms of Charge GPT Pulse, which kind of gives you this daily update of things you might care about.

拥有这样的提醒真的很好，它能让你突然想起一些你之前没想过的事情。

And it's it's very nice to actually have that, like, jog your brain up in terms of, oh, this is something that I haven't thought about.

也许这样挺好。

Maybe this is good.

当你将这种思路扩展到更复杂的任务时，比如编码代理，它会说：‘我已经修复了你的五个线性工单，这是补丁，请在每天开始时审阅一下。’

And now when you extend this to more complex tasks, like coding agent, which says that, okay, I have fixed five of your linear tickets and here are the patches, just review them at the start of your day.

所以我觉得这将会非常有用。

So I feel that is going to be extremely useful.

我认为这是2026年产品发展的明确方向。

And I see that as a strong direction in which products are going to build in 2026.

这太酷了。

That's so cool.

所以本质上，代理能预判你想做什么，并提前行动。

So essentially agents kind of anticipating what you want to do and getting going getting ahead of you.

我已经帮你解决了这些问题。

And here's I've solved these problems for you.

或者我觉得这可能会让你的网站崩溃。

Or I think this is gonna crash your site.

也许你应该直接修复这里的问题。

Maybe you should fix this thing right here.

或者我看到这里有个峰值，咱们重新设计一下数据库吧。

Or I see the spike here and let's refactor a database.

太棒了。

Amazing.

真是个奇妙的世界。

What a world.

好的。

Okay.

阿什，你有什么发现？

Ash, what do got?

我完全支持2026年的多模态体验。

I'm all in for multimodal experiences in 2026.

我认为我们在2025年已经取得了相当大的进展。

I think we have done quite some progress in 2025.

而且不仅仅是在生成方面，还包括理解方面。

And not just in terms of generation, but also understanding.

到目前为止，我认为大语言模型是我们最常使用的模型。

Until now, I think LLMs have been our most commonly used models.

但作为人类，我认为我们是多模态的生物。

But as humans, we are multimodal creatures, I would say.

语言可能是我们最后一种进化形式。

Language is probably one of our last forms of evolution.

当我们三个人交谈时，我认为我们一直在接收这么多信号。

As the three of us are talking, I think we're constantly getting so many signals.

我觉得，伦尼心不在焉，所以我可能会往这个方向走；伦尼觉得无聊了，那我就别说了。

I'm like, Oh, Lenny is not in his head, so probably I would go in this direction, Lenny is bored, so let me stop talking.

在你的思维链条背后，还有一条思维链条，你正不断用语言调整它，而这种表达维度尚未得到充分探索。

So there's a chain of thought behind your chain of thought, and you're constantly altering it with language that dimension of expression is not explored as well.

如果我们能构建更好的多模态体验，就能更接近人类对话的丰富性。

So if we could build better multimodal experiences that would get us closer to human like conversation richness.

我认为，考虑到当前的模型类型，还有很多枯燥的任务非常适合交给AI来处理。

I think, and just you will also just given the kind of models, there's a bunch of boring tasks as well, which are ripe for AI.

如果多模态理解能力得到提升，那么大量手写文档和极其混乱的PDF文件，如今就连最先进的模型也无法有效处理。

If multimodal understanding gets better, there are so many handwritten documents and really messy PDFs that cannot be passed even by the best of the models as of today.

如果可能的话，我们将能利用海量的数据。

And if it's possible, there'd be so much data that we can tap into.

太棒了。

Awesome.

我刚和DeepMind AI（谷歌旗下机构，他们怎么称呼整个组织都行）的德米斯聊过，他说这将是他们未来发展的重点方向，要把图像模型、LLM和他们的世界模型——我觉得叫Genie——结合起来。

I just had Demis from DeepMind AI, Google, whatever they call the whole org, talking about this where he thinks that's going to be a big part of where they're going, combining the image model work, the LLM and also their world model stuff, Genie I think is what it's called.

这将会是一段极其精彩的时代。

So that's gonna be a wild wild time.

好的。

Okay.

最后一个问题。

Last question.

如果有人想提升构建AI产品的能力，你认为他们应该重点培养哪一两项技能？

If someone wants to just get better at building AI products, what's just maybe one skill or maybe two skills that you think they should lean into and develop?

我觉得我们已经讨论过不少AI产品的最佳实践了，比如从小处着手，确保迭代顺畅，建立飞轮效应等等。

I think we did cover a bunch of best practices for AI products, which is start small, try to get your iteration going well and build a flywheel and all of that.

但再次强调，如果从宏观角度来看当今任何人的工作，就像我之前说的，未来几年实现成本将变得极其低廉。

But again, if you kind of look at it at a 10,000 feet level for anybody building today, like I was saying, implementation is going to be ridiculously cheap in the next few years.

所以，真正要精益求精的是你的设计、判断力和品味。

So really nail down your design, your judgment, your taste and all of that.

总的来说，如果你正在规划职业生涯，我觉得过去几年，你职业生涯的前两三年通常都专注于执行、技术细节等方面。

And in general, if you're building a career as well, I feel for the past few years, your former years, say the first two, three years of building your career is always focused on execution, mechanics and all of that.

而现在，AI能帮你快速上手并在此之后加速发展。

And now we have AI that could help you ramp pretty quickly and post that.

我的意思是，几年之后，每个人的工作都将聚焦于你的品味、判断力以及你独有的特质，我认为你应该专注于这一部分，思考如何融入这种视角。

I mean, after a few years, think everybody's job becomes about your taste, your judgment and what is uniquely you, I think nail down on that part and try to figure out how you can bring in that kind of a perspective.

这并不意味着你必须年纪很大或拥有多年经验。

It doesn't have to mean that you should be significantly old or have years of experience.

我们最近雇了一个人，我们一直用这个非常流行的App来跟踪任务。

We recently hired someone and we use this very popular app for tracking our tasks.

我们已经用了好几年了，还支付了高昂的订阅费用。

And we've been using it for years and we pay a high subscription fee for it.

而这个人来开会时，直接带了他自己写的白盒应用。

And this guy just came with his own white coded app to the meeting.

他帮我们全部接入了这个系统。

He onboarded us to all of it.

然后他说：好了，咱们就开始用这个吧。

And he's like, Okay, let's start using this.

我认为这种主动性和主人翁意识，真正去重新思考体验，才是让人脱颖而出的关键。

And I think that kind of agency and that kind of ownership to really rethink experiences is what will set people apart.

我并不是盲目忽视白盒应用维护成本很高的事实。

And I'm not being blind to the fact that white coated apps have high maintenance costs.

也许随着公司规模扩大，我们不得不替换它，或者寻找更好的方案。

Maybe as we scale as a company, we have to replace it or we have to think of better approaches.

但考虑到我们现在是一家小型公司，我真的很震惊，因为我从未想过这一点。

But given that we're a small sized company now, I was really shocked because I never thought of it.

如果你一直习惯于某种工作方式，你会认为开发是有成本的。

If you've been used to working in a certain way, you associate a cost with building.

我觉得在这个时代成长起来的人，心里对开发的成本要低得多。

And I feel like folks who grew up in this age have a much lower cost associated in their mind.

他们根本不介意去构建一些东西并直接推进。

They just don't mind building something and going ahead with it.

他们也非常热衷于尝试新工具。

They're also very enthusiastic to try out new tools.

这也可能是AI产品存在留存问题的原因，因为每个人都对尝试这些新工具如此兴奋。

That's also probably why AI products have this retention problem, because everybody's so excited about trying out these new tools and all of that.

但本质上，拥有自主权和责任感，我认为这也标志着繁琐工作的终结。

But essentially having the agency and ownership, and I think it's also going to be the end of the busy work era.

你不能坐在角落里做那些对公司的进展毫无帮助的事情。

You can't be sitting in a corner doing something that doesn't move the needle for a company.

你真的需要思考端到端的工作流程，如何带来更大的影响。

You really need to be thinking about, you know, end to end workflows, how you can bring in more impact.

我认为这一切都非常重要。

I think all of that would be super important.

这让我想起一件事。

That reminds me.

我刚刚在播客里采访了杰森·勒姆金。

I just had Jason Lemkin on the podcast.

他在销售、市场推广和提速方面非常在行，他还用智能代理完全取代了他的销售团队。

He's very smart on sales, go to market, run faster, and he replaced his whole sales team with agents.

他以前有10个销售人员，现在只有1.2个全职人员和20个代理。

He had 10 salespeople, now he has one point two and twenty agents.

其中一个代理负责跟踪每个人在Salesforce中的更新，并根据他们的通话内容自动帮他们更新信息。

And one of the agents, it was just tracking everyone's updates to Salesforce and kind of updating it automatically for them based on their calls.

其中一个销售人员说：好吧，我辞职了。

And one of the sales people is like okay I quit.