如何构建原生代理产品 | 迈克·克里格

我还没试着把这一点说清楚，所以请耐心一点，让我慢慢理清思路，就是说，是的。

And I haven't tried to articulate this, so bear with me as I, like, you know, kinda get there, which is yeah.

有些产品用起来感觉底层很扎实，但也有那些你一不小心点错或输错命令，整个系统就可能卡住或变慢的产品。

There's products that you use that feel robust underneath, those ones that you use that you're like it feels like it's one wrong command or click away from the whole thing, either, like, freezing or being slow.

在Instagram，我们曾经有Instagram直接消息第一版，谁知道呢？

For us at Instagram, like, we had Instagram view direct messaging v one, and that, like, who knows?

你发一条消息，它可能到得了对方，也可能到不了。

If you send a message, it might or may not arrive to the other person.

我们自己写了一个专属的实时系统。

Like, we'd, like, wrote I wrote our own, like, bespoke real time system.

这个系统经常崩溃。

It was, like, you know, fell over a bunch.

你根本不敢用它来发送真正需要对方看到的重要消息。

It just you would not trust that to send a message that you really needed somebody else to see.

它更像是一个社交性质的东西。

It was just a, you know, more of a social thing.

当我们开发第二版时，非常重要的一点是，我们坚决杜绝这种情况。

And when we built v two, was really important that we really hammered, like, no.

比如，当你发送一条消息时，我们可能达不到WhatsApp那样的水平——即使你在完全没有信号、只剩一格EDGE网络的情况下，它依然能设法发送成功。

Like, if you send a message, we're not probably gonna get to WhatsApp level of, like, you know, you can be in the middle of absolutely nowhere with, like, one bar of edge, and it will probably, you know, try to still go through.

也许那不是我们的目标，但至少我们要做到：当我加载消息时，它必须感觉可靠。

Maybe that's not the bar, but still a bar of when I load messages, it feels robust.

一旦发送，就真的是发送出去了。

When it's sent, it's really sent.

我觉得这就像有个小小的确认机制。

I feel like there's, like, a little check.

这只是一个小小的例子。

And that's, like, one small example.

但我认为，我们仍需弄清楚如何让这种体验成为任何产品发布中不可或缺的一部分，不仅仅是在Anthropic，而是普遍如此。

But I think that that is a thing that we still need to figure out how to make, you know, feel like an essential part of shipping on anything, not just at, you know, Anthropic, but in general.

你开发了这个东西。

Like, you built this thing.

它感觉像是建在沙子上，还是感觉很稳固？

Does it feel like it's built on sand, or does it feel robust?

而原生智能体部分带来的，是更进一步的东西：我能稍微推它一下吗？它会倒吗？

And the agent native part adds something totally even beyond that, which is, can I push it a little bit, and is that gonna fall over?

还是感觉很棒。

Or does it feel like, great.

我有一个坚实的根基，是的，你可以从不同方向推我，但你知道，你的数据是安全的，就在下面，而不是仅仅一次部署就可能彻底崩溃。

I've got a solid trunk, and, yeah, you can push me in different ways, but, you know, your data is safe and it's underneath here, and it's not just, like, one deploy away from completely falling over.

所以，如果这就是标准，我同意，你确实想达到这个水平，随着模型变得更好，你们在招聘人选和团队结构上做了哪些改变？

So if you're if that's if that's the bar, which I agree, like, that's that's where you definitely wanna get to, how has how have you changed who you hire and how your teams are structured as the models have gotten better?

比如我们的一个产品Spiral，我们刚聘了一位新总经理，他技术背景较弱，但在产品和写作方面能力极强，而Spiral正是一个写作类产品。

Because for us, for example, one of our products, Spiral, we just hired a new GM who is like he I would say he's lightly technical, but he spikes super high on product and writing sense and Spiral is a writing product.

现在我们可以招聘这样的人了，但一年前我们还做不到，因为当时的代码模型还不够好。

And now we can, like, hire someone like that where a year ago we wouldn't have been able to because the coding models weren't good enough.

我很好奇，但潜在的问题是，如果没有一个对所有细节都极其精通的技术人员，产品可能就不会显得那么稳固。

I'm curious, like but the downside is it's maybe the product won't feel quite as robust if there's not someone who's, like, super technical in all the details.

那么，你觉得现在实验室团队里是谁在构建产品？这个过程随着时间发生了怎样的变化？未来又会如何演变？

So, like, how do you think about who builds products right now inside of the labs team and how that has changed over time and how it will change.

是的。

Yeah.

我非常喜欢这一点。

I love that.

我认为实际上你会被拉向两个方向，但这两个方向都很重要。

I think it's actually you get pulled in two directions, but they're both important.

一方面是基础架构和系统健壮性，我认为这仍然需要一位资深技术人员。

There's the sort of primitives and architectural robustness, which I think still need a sort of senior technical person.

我刚才和某人聊天时笑了。

I was laughing with somebody.

他们说，我以为自己在分布式系统方面的技能已经没什么用了。

They're like, I thought, you know, my skills in distributed systems were, like, not gonna be useful anywhere.

但实际上，这些技能可能是最有用的，尤其是在思考和推演这些问题时。

But, actually, those are maybe some of the most useful skills and reasoning about that and, you know, thinking things through.

上周我和Claude就我构建的系统是否需要Redis，还是可以直接用Postgres展开了长时间的讨论。

Like, I had a long debate with Claude last week around, like, whether the system that I was building needed Redis or not or could go to just Postgres.

这其实是一场健康的辩论，而我之所以能参与，是因为我之前大量使用过这些技术，有扎实的基础。

And, you know, it was it a healthy debate where, like, I but only because I was grounded and having used a lot of those technologies before.

但另一方面，关于稳健性，你是用系统提示词和额外指令来敷衍了事，还是真正地正确设计了一整套工具？

But then there's the other side of robustness, which is have you just papered over all the problems with, like, fixes to your system prompt and additional instructions, or have you sort of architected the actual, like, set of tools correctly?

因此，后者同样重要，而且可能正是GM能发挥巨大价值的地方，即：

And so that the the latter is as important and probably where this GM can be really valuable in that, okay.

就像你不会通过简单地让分布式系统重试五秒来修补它的不稳定性那样，

Like, I'm making changes, but just like you wouldn't patch a sort of flakiness in your distributed system by just being like, well, just retry it in five seconds.

我确信它会奏效。

I'm sure it'll work.

同样，你也不该用全大写的Markdown，或者任何你试图修补的其他东西来敷衍了事。

Like, also not doing the same thing with never ever, you know, all caps use, you know, markdown or whatever the the the thing that you're trying to patch is.

其实这两种做法都是同一个问题的症状，那就是底层组件是否足够稳健。

Like, they're both actually symptoms of the same thing, which is is the underlying piece robust or not.

而且克劳德，我想说这适用于所有模型，但我认为克劳德在这两方面都能做得更好。

And Claude actually I'd say this about all the models, but I think Claude could be much better at both.

它仍然非常需要大量的人工监督。

It's, like, still a place that still needs a lot of of human oversight.

在系统方面，它现在能够调试生产系统，这非常有价值。

On the systems part, you know, it's now able to debug production systems, which is really valuable.

但在最初设计架构时，我觉得我们仍然需要那些真正深入思考过这三点或有相关经验的人。

But architecting them in the first place, I feel like we're still benefits from somebody who's really thought these three things through or has experience.

在提示工程方面，你知道，如果你给它一个——我见过甚至在我们内部也有人陷入这种开发循环。

And on the prompting side, you know, if you give it a I've seen people get into this dev loop even internally here.

这是提示内容。

Like, here's the prompt.

这是系统犯的错误。

Here's a mistake that the system made.

不断优化提示。

Iterate on the prompt.

它的自然倾向就是不断往提示里添加更多内容，最终变成这样：如果你给一个新员工第一天就列出一百条指令，比如‘一定要回答并记录下来，除非……’，他们肯定会想：我干脆就记住你最后告诉我的那条吧。

Its natural tendency is to just add more things to the prompt, and then eventually just get to this thing that, you know, if you onboarded a new employee and you gave them a 100 instructions on their first day, like, always answer and mark down except when they, you know, they'll be like, I'm just gonna remember the last thing you told me.

我会直接绕过它。

I'm gonna, like, short circuit it.

所以重新思考一下，好吧。

So then rethinking, okay.

这些是不是实际上属于两种不同的工具？

Is these are are these actually two different tools?

是不是其实有两个智能体，各自只处理较少的上下文，然后可以拆分开来？

Is it actually two agents that each have a smaller amount of context that then you can break apart?

回到你最初的问题，我们正在招聘具备系统经验的人才，即使是在实验室这种通常被认为是零到一原型开发的地方。

So back to your original question, we're hiring for people with, you know, systems expertise even within labs, which you think of as, like, more zero to one prototypes.

这依然非常有价值，因为同样地，系统的稳定性至关重要。

Like, it's still really valuable because, again, that robustness matters.

而且，谁还能帮忙梳理系统权限、资源配置和早期测试呢？

And also just who's gonna be, you know, helpful in sorting through, you know, systems permissions and provisioning and early testing.

这类事情即使在云环境中仍然很困难，因为它本身无法自行修改权限配置，而这是出于良好原因的。

Like, that stuff is is still, you know, it's still hard even for cloud when it can't edit the provisions itself, which it can't for good reasons.

在稳健性方面，我们发现将产品团队与应用AI团队配对取得了很大成功。

And then on the on the robustness side, actually, we've had a lot of success pairing our product teams with our applied AI teams.

我们的应用AI团队每天都在现场帮助客户迭代他们的提示词。

Our applied AI teams are the teams that are in the field every day helping customers iterate on their prompts.

我们发现自己现在正是这些努力的‘零号客户’，因为我们有许多产品都高度依赖AI。

And we found that we actually are very we're customer zero now for those, you know, efforts because we have a lot of products that are, you know, very AI powered.

那么，我们该如何将这种专业知识引入其中呢？

So how do we bring that expertise in there?

因为这种专业知识目前并不存在于我们的软件工程师团队中，例如。

Because that expertise does not sit with our software engineers today, for example.

那么，介于两者之间的部分呢？比如，它并不是底层架构的问题。

What about the in between of, like, okay, it's not the underlying architecture.

而是在提示词层面。

It's on the prompt.

就是界面和流程。

It's, like, the UI and the the the flow.

谁在做这个？

Who's doing that?

我们？这是个好问题。

We that's a great question.

比如，我们发现，一些转到实验室的人，原本非常关注网站的细节打磨，但他们对尝试新事物很感兴趣。

Like, we have found, you know, some of the people that transferred into labs were the folks, like, really were focused on polish on the website, but they were interested in doing something new.

他们也带来了完全不同的方法，比如我们之前有个原型。

And they bring such a different approach as well around we had the prototype.

它看起来只是普通地不错，而不是让人感觉有品牌感，有这种特色。

It was it looked generically nice versus, oh, this feels like it's branded and it has this.

所以这是第一部分。

So that's that's part one.

第二部分是设计师。

Part two is designers.

比如，我们的设计师越来越多地转向一种设计师与构建者双重角色的模式。

Like, we've had our designers move much more into a sort of split designer and builder role.

不是所有人，但大多数都是这样。

Not all of them, but most of them.

而且，我们实验室其实并没有太多全职设计师，那些有的，我可以说他们写的代码几乎和工程师一样多，因为他们有能力做到。

And a lot of our you know, we actually don't have a lot of full time designers on labs, the ones that we do, I would say are writing and contributing almost as much code as the engineers on those efforts because they can.

同样，如果搭配得当，我们发现这种模式在某些实验室项目中几乎像联合创始人模式：设计师可能提出了最初的想法并推动它，而传统的软件工程师则跟在后面，铺平道路，确保这个想法真的能落地。

And again, paired correctly with the right person, we have found this almost sort of cofounder model for some of these labs initiatives where you have the designer who had the original idea maybe, and they're pushing on something, and then the traditional software engineer that's gonna go and, you know, make pave the trail sometimes behind the designer to make sure that actually works.

好的。

Okay.

这个我想深入了解。

This I wanna know about.

那么，能跟我讲讲这个团队结构是怎么运作的吗？

So what so tell me about how that team structure works.

所以，这个角色通常是设计师，还是任何有产品想法并能以某种方式执行的人，搭配一位真正的工程师，来帮忙打磨他们留下的粗糙路径？

So you've got a design is it actually usually a designer, or is it just anyone that has a product idea that can kinda execute it on it in some way paired with a a real real engineer that actually can, like, kind of smooth out the rough edges of the the the trail they're leaving?

这因情况而异，但我们发现，启动新项目时最重要的一点，是我们最关键的前置条件。

It sort of varies, but it we found that one thing that's most important, sort of our gating factor in starting up new projects.

我想知道，这和Every的情况有多相似？是否需要有人对这个想法——即使不是对具体方案——抱有极强的信念？对某个具体想法过于执着可能很危险，但至少对所探讨的问题领域要有强烈的关注。

I'm curious how similar is this to Every, is having somebody with extreme conviction about if not necessarily that idea, too much conviction on the exact idea is probably dangerous, but at least in the problem space or the question that they're asking.

这种类似联合创始人或创始人的态度是：我会不惜一切代价突破障碍，直到这件事被证实可行，或者彻底失败，我只想明确地走通一条路。

And that sort of, like, cofounder or founder level of I will break through walls until this thing is either proven out or dead, but I wanna, like, go either way.

当我们关闭某些实验室项目后复盘时，常常发现：团队里其实没人真觉得这个项目是那个对的方向。

When we have bets labs bets that we've wound down often in the postmortem, we're like, nobody on this team actually really thought this was, like, the thing.

他们只是说，是的。

They were like, yeah.

这看起来挺合理的。

This seems reasonable.

这正是项目失败的丧钟。

Like, that's the the the death knell for projects.

对吧？

Right?

所以这个人可以是设计师，有些项目就是这样。

So that person can be a designer, and couple of the bets it is.

它也可以是一个有产品思维的工程师。

It can also be sort of a, you know, product minded engineer.

很少是纯粹的产品经理。

It's rarely a pure PM.

我们目前只有一个产品经理负责整个实验室。

We actually only have one currently one PM for all of labs.

我们正在招聘更多人，他们扮演着非常广泛的角色。

We're hiring more, and they're sort of playing, you know, sort of a wide role.

但是的，一个设计师或者有产品导向的创始人。

But, yeah, a designer or like a product oriented founder.

然后我们寻找的是，我们需要哪些技能来补充他？

And then what we look for is, well, what skills do we need to complement with that?

因为这是我们实验室流程的一部分。

So, you know, because we're doing it's part of our labs process.

我们实际上每两周评估一次每个项目，决定是加大投入还是让相关人员回归到更广泛的实验室团队中。

It's actually evaluating every project every two weeks and deciding whether we double down or whether we sort of release those folks back into the broader labs pool.

在任何给定时间，都可能有人具备基础设施专长，或熟悉该特定内部系统，或拥有丰富的提示工程经验，可以灵活地加入或退出项目。

At any given point, there's probably somebody who can be pulled onto the project that has that infrastructural expertise or has worked with that particular internal system or has a lot of deep prompting expertise to sort of flow in and out.

所以我认为，这种孵化器式的模式也有助于此，因为没有人会永久固定在一个项目上。

So I think that's also where the sort of incubator style space helps because nobody is fixed on a project forever.

这真的很有趣。

That's really interesting.

是的。

Yeah.

我们那里做法略有不同，有一些重叠，但我们有稍微不同的结构，就是说。

We're we we do it slightly different there's some overlaps, but we do have a slightly different structure where we yeah.

我们有总经理，或者他们最初是创业者或驻场人员，当他们找到想专注开发的产品时，就会成为总经理。

We have GMs or or they start as entrepreneurs and residents and they become general managers when they find a product that they wanna like work on.

每个产品只由一个人负责。

And each product just has one person.

就是一个人全栈负责一切。

Like, one person that does everything full stack.

所以，你知道的，设计、工程、营销，所有这些基础工作都由一个人搞定。

So, you know, design, engineering, marketing, all that kind of stuff, at least the all the basics of that.

以前这种总经理的背景通常是超级技术型的创始人，但现在我觉得已经转向至少需要一些基础技术能力了。

The shape of that GM used to be, like, super technical founder background, and now I think has shifted towards at least some light technical.

但我 honestly 只在乎你能不能很好地使用 Claude、Codex 或其他任何工具。

But, like, I honestly just care that you can use Claude or Codex or whatever well.

还有极强的产品直觉，对你要构建的领域或事物有很好的品味，并且有证据表明你能用 AI 做出东西来。

And really good product sense, really good taste for for the the the subject area or the thing that you're trying to build and evidence that you can build with AI.

而我们拥有的是一个共享资源层，有点像一家代理机构，里面有设计师、增长营销人员，还有运营人员，你可以根据需要随时调用。

And then what we have is shared resource resource layer that sort of works a little bit like an agency where we have designers and we have growth marketers and we have, you know, ops people that you can, like, pull in and out for various initiatives.

这看起来效果不错。

And that seems to work pretty well.

所以我们负责管理所有内部的代理团队，而每个总经理则在外围，根据项目需求随时调用所需资源。

So it's like we manage all the internals the internal agencies, and then each GM is out on their on on, you know, on the edge, and they pull in resources as they need it for different projects.

是的。

Yeah.

但听起来类似，你需要一个对此事极度投入的人，他们不把事情完全搞定就不会睡觉。

But sounds similarly, like, you need somebody for whom that is, like, the thing, and they are not going to sleep until it is fully working.

对。

Yes.

没错。

Exactly.

而且我一直在想，好吧。

Like and and I've been I've been thinking about, okay.

你什么时候会雇别人来参与产品开发，或者什么时候会增加其他人来参与产品开发？

When when would you hire someone else to work on a product, or when would you add someone else to work on a product?

到了某个阶段，你就无法再把整个事情都记在脑子里了。

And it's like, there's some point at which you can't hold the entire thing in your head.

即使你是推动这件事的人，你也无法再把整个事情都记在脑子里了。

Even if you're the one pushing it forward, you can't hold the entire thing in your head.

而以前这个临界点要小得多。

And that point used to be much smaller.

现在这个临界点大了很多，但到了某个阶段，即使是一个小功能也会变成一个独立的产品。

Now it's much bigger, but there's a certain point at which, like, even a small feature turns itself into its own product.

你知道吗？

You know?

当你最初在 Instagram 里开发消息功能时，可能会觉得，是的，我一周内就能搞定。

When you when you first make the messaging feature inside of Instagram, it's like, yeah, I can do that in, like, a a week or whatever.

但到了某个时刻，它就变成了一个独立的产品。

But at some point, that's its own product.

它几乎需要一个专属团队。

It almost needs its own team.

我认为，一个人能处理的事情的数量在增加，但这条界限依然存在。

And that I think that line is getting or or the number of things you can do with one person is getting bigger, but it still exists somewhere.

但我还没完全想清楚，该如何管理这种情况，或者如何判断这个界限。

But I haven't quite figured out, like, how to how to manage that or how to tell.

不。

No.

我非常喜欢这一点，因为实际上这包含两个方面：当想法还足够简单，能被一个人完全掌握时，增加更多人反而会拖慢团队的进度。

I love that because there's actually I think there's the two parts to that, which is when the idea is still enough to hold into your own head or an individual person's head, adding more people actually slows the team down.

这是我们从实验室中发现的一个非显而易见的结论：过快地扩大团队实际上会产生负面效果，因为他们会把大量时间花在协调上。

And that's like a non obvious finding that we found on labs is scaling the teams too quickly actually is a net negative because they end up spending all this time on coordination.

比如，哦，你本来打算做这个，但我的云服务其实就能搞定。

Like, oh, you were oh, I was gonna take oh, but my cloud could do that.

结果就变成了这种支离破碎的状态。

And it just ends up in this sort of piece.

而且你还要面对所有那些关于对齐目标的讨论。

And you also have all those alignment conversations.

在Instagram早期，只有我们两个人，这一点非常重要。

Like, it was important in Instagram that it was just two of us.

就连让两个人达成一致都已经够难了，更别说要把两个人的想法统一起来。

Like, it was hard enough to align the two of us, like, and go, like, get two people on the same page.

对吧？

Right?

我做的第二个创业项目Artifact，你知道，最初几个月我和凯文是独自做的，但后来我们雇了一个大约八人的团队。

The second startup I did, Artifact, you know, Kevin and I were doing that alone for the first few months, but then we hired a team that was about eight people.

这真的很难，因为那时候我们还没有找到产品市场契合点，所以还在不断迭代。

It was really hard because, you know, we hadn't had product market fit yet, and so we were still iterating.

然后你就陷入这种局面：我们八个人在Zoom上讨论下一步该做什么。

And then you'd end up in these things where we're on a Zoom with eight people talking about what we're doing next.

你真正想做的其实是能坐在一间房间里把事情彻底谈清楚。

And you really just wanna be able to sit in a room and hash it out.

所以我觉得这些实验室项目也有类似的情况：即使想法很吸引人，也不该过早扩大团队，否则就会陷入这种元协调的游戏中。

So I find with these labs initiatives, there's some there's some similar sort of aspect at play, which is you don't wanna pre scale the team too early even if the idea is exciting because then you just end up in this sort of, like, meta coordination game.

但我喜欢你提出的观点：确实存在某个临界点，两个人一起做会更有帮助，因为那时的上下文和范围足够大，他们能同时在脑子里承载一些复杂的部分。

But I I like your framing of there is some point where either, you know, two people really will help go on it together, and there's enough sort of context and scope where they can hold some other complex piece in their head.

另外，如果某人已经在一个想法上投入了两到四周，这时有人注入新的思路，这种紧迫感也会有帮助。

And then there's also the if somebody's been spending on the same idea for two, four weeks, somebody's injecting some other thinking and and that urgency can help too.

是的。

Yeah.

我认为在人工智能领域保持团队小型化尤其重要，因为我们经常面临的情况是，每三到六个月，你就得扔掉一半的产品。

I think it's especially important in to keep it small in AI because one of the things that we deal with all the time, which I'm sure you see too, is every three to six months, you're you have to throw out, like, half your product.

如果你需要和很多人协调，这会非常困难。

And that's really hard to do if you have to coordinate with a lot of people.

但如果是一位总经理突然意识到：‘天哪，’

But if it's one GM who realizes, oh, shit.

是的。

Yeah.

我得把这一半东西全扔了，因为模型进步太多了。

I gotta just, like, throw out half of this because the models are so much better.

这样要做出这样的转型就容易多了。

It just makes it much easier to to, like, pivot in that way.

你有遇到这种情况吗？

Is that do you see that?

那你又是怎么应对这种情况的呢？

And, like, how do you deal with that?

你是怎么看待这一点的，是的。

Like, how do you think about, yes.

我知道三个月后，这些代码甚至整个功能集，我都得重新思考一遍。

I know in three months this the code maybe or even the whole feature set, I'm gonna have to, like, really rethink about.

这让你对软件的看法发生了很大的变化。

Like, it feels like it changes a lot in in how you think about software.

是的。

Yeah.

而且要愿意删除代码。

And being willing to delete code.

我认为Cloud Code团队在这方面做得非常好，他们把删除功能当作团队成员的一种使命。

I think that's something that Cloud Code team has done really well is they have sort of deleting features as a sort of imperative of people on the team.

如果这个功能行不通，我们就去上线新的。

Like, if this is not working, let's go and ship that.

你知道的。

You know?

而且，通常当你创造出其他东西时，即使它没有完全取代原有的功能，但只要能足够好地实现原有功能的用途，就值得将其弃用并移除。

And it's often when you've created something else that even if it doesn't entirely supersede, it does enough of what that other aspect does that actually makes sense to deprecate and then remove that first one.

随着我们越来越专注于企业市场，即使使用这些工具，也会变得越来越难，因为企业会依赖它们。

It does get harder as we get more and more enterprise focused even with these tools because they come to depend on it.

我知道我永远不会忘记。

I I know I never forget.

我还在担任首席产品官时，大约六个月后，我们对Cloud AI进行了一次大规模的重新设计，当时我们非常自豪，并发布了它。

We one of the things I did maybe six months into when I was still a chief product officer was we did a big sort of redesign of of Cloud AI, and we were so proud, and we shipped it.

我们收到了不少赞誉，但随后却收到一封非常愤怒的邮件，对方说：‘我为公司录制了二十个小时的云企业应用培训内容，现在得全部重做一遍。’

And we had a bunch of kudos, and then we got this really angry email from somebody who's like, I just recorded twenty hours of enablement content for my company to do cloud enterprise, and I have to, like, redo all of it.

我当时就想：哦，好吧。

And I'm like, oh, okay.

他们的发布节奏和你不在同一个层面上。

Like, they're you're playing at a different release cadence.

当然，像在我们的一次大会上一年发布两次这样的做法是不可行的，所以我们必须继续快速推进。

And, of course, like, shipping twice a year at one of our conferences is not an option, so we are gonna keep moving quickly.

但后来我们逐渐学会在向企业端推出功能时，稍微放缓一下节奏。

But then we've since, like, learned to maybe moderate how we roll it out to the enterprise side a little bit more.

但是，我认为取消功能这一部分，最终会导致一些人已经基于它构建了东西——我举个例子。

But, yeah, I think the unshipping piece, then you end up with people who have built I'll use an example.

所以有一个功能叫‘样式’。

So there's a feature in in called styles.

这个功能使用的人不多，但使用它的人非常依赖它。

It's not widely used, but the people who use it use it a lot.

我们曾经在不同场合讨论过，是的，这个样式功能在产品中仍然有其意义。

And we've talked at different points like, yeah, the style still makes sense in the product.

当然，现在有其他方式可以实现同样的效果。

You know, there's other ways of accomplishing the same thing.

现在有了自定义指令和项目。

There's custom instructions and projects now.

现在还有技能功能。

There's skills now.

对吧？

Right?

实现这一点的方法太多了。

There's so many other ways of accomplishing that.

我不知道样式功能还会在产品中保留多久，但我知道上次我们讨论移除它时，发现它对几家公司的整个使用场景来说至关重要。

And I don't know how long styles will end up in the product, but I know that the last time we we talked about removing it, it ended up being really load bearing for a peep a few companies', like, entire use cases.

比如，他们有一个公司专属样式，由首席执行官亲自设计并分发给每位员工，员工们就是靠它来开展工作的。

Like, oh, we have our house style that the CEO personally authored and gives to every employee, and that's how they operate.

因此，找到替代这些功能的方法也非常有趣。

And so finding ways of doing that is also really interesting.

我希望从长远来看，我们能建立一套插件和技能系统，让它们不再需要内置在核心产品中。

I would hope that in the long run, what we can actually do is is come up with a system of plug ins and skills such that they no longer have to live in the core product.

因为我认为，如果你没有一个清晰的替代方案，删除那个你向所有人提供的核心功能总是最难的。

Because I think that is it's always the hardest to delete something that is the core thing that you're shipping to everybody if you don't have the story around, great.

你仍然喜欢这个功能吗？

You still like that feature?

太棒了。

Awesome.

比如，你可以通过这种方式永远在自己的环境中继续使用它，不断迭代并让它成为你专属的，而无需给每个新注册的用户增加复杂性。

Like, here's how you can keep using it forever in your own and keep iterating on it and make it your own, but it doesn't have to add complexity to every future person that's adding that's signing up for the first time.

我对实验室功能很好奇。

I'm curious for for labs.

另外，总的来说，你对初创公司创始人有什么看法？

And then also maybe just in general, what are your thoughts for startup founders?

你提到的企业级观点让我想到一个我最近一直在思考的问题：如果你现在在AI领域向企业销售产品，即使你的产品现在很现代，也会很快过时。

Your enterprise point just it brings up something that I've been thinking about a lot, which is if you are selling to enterprise right now in AI, even if the product you have right now is modern, it will be quite outdated quite quickly.

但你的客户却会想要那个过时的版本。

And but your customers are gonna want the outdated version.

但作为一家初创公司，这感觉有点冒险，因为确实如此。

But as a startup, that's like a little bit that feels pretty risky because yeah.

如果你只是在优化当前大型上市公司客户会购买的东西，那你很容易受到颠覆。

You're just gonna I guess you're you're you're susceptible to to disruption if you are optimizing for what someone at a gigantic public company will buy right now.

我认为有很多初创公司属于这一类，它们可能两三年前才成立。

And I think there's a lot of startups in that category where they maybe started two or three years ago.

它们有一套特定的技术栈。

They have a certain tech stack.

它们有一套特定的关于如何做AI的思维方式。

They have a certain way of thinking about here's how we do AI.

但现在的模型已经截然不同，而它们的客户合同却还是基于这种过时的模式，你知道的，就像在看Copilot之类的产品。

And then the models are so different, but their customer contracts are for this sort of out it's you know, looking at looking at Copilot or whatever.

就是这种感觉在发生。

It's that's the sort of vibe that happens.

你是怎么看待这个问题的？在Anthropic内部，你是怎么思考的？

Like, how do you think how do you think about that yourself and and inside of Anthropic?

那么，你认为创始人应该如何思考这个问题？

And then how do you think founders should think about that?

是的

Yeah.

不

No.

这是个非常好的问题，尤其是因为接下来会有一波浪潮，比如更加原生的代理模式。

This is such a good question, especially because then a wave will come, like, being more agent native, for example.

你能在现有的范式中采纳它吗？

And can you adopt it within your existing paradigm?

是需要全部推倒重来，还是你只是被困在其中了？

Does it require to throw everything out, or are you just stuck in that?

比如，我们某种程度上采纳了它。

Like, oh, we kind of adopted it.

我们只是把它附加上去。

We kind of bolted it back on.

我觉得有几点需要考虑。

I think a couple things.

对我们来说，我们开始的做法是，本质上认为这列火车会继续前进，我们会沿途提供企业级的开关功能。

For us, what we've started doing is basically treating like, this train's gonna keep moving, and we'll provide enterprise toggles along the way.

但其核心将继续演进，这正是你与我们合作时所承担的信念。

But the core of it will continue to evolve, and that's sort of the the bet understanding you're taking working with us.

我认为这一点得到了很好的接受，因为公司也意识到，事情发展得太快了，他们甚至只有在相信产品会持续演进的前提下，才会对一年期的承诺感到安心，比如我们提供的协作者功能就是一个很好的例子——从第一天起，就提供了关闭功能，如果你不希望员工使用，可以随时关闭。

And I think that's been well received because I think companies have also seen that, you know, things are moving so quickly that the only way they even get comfortable with a year long commitment, for example, is to believe that it will continue to evolve along the way, but then we'll provide, you know coworkers are great example where, you know, from day one, there was like a a way to turn it off for your employees if you didn't want it, for example.

我认为这是一种相当不错的模式。

And that that that's, I think, a reasonably good paradigm.

但另一种方式，正如我们之前讨论的，你可以真正重新思考并重写整个技术栈，我认为公司应该更愿意这样做。

But the other one is, just as we were talking earlier, like, you can actually rethink and and and and sort of rewrite a lot of the the the stack is I think companies should be way more willing to do that.

而且所有事情都在加速压缩。

And it everything is getting compressed.

对吧？

Right?

在之前的周期中，有一种观点是，你必须放弃一些客户，他们可能因为与你发展方向不同的原因而非常喜爱你的产品。

In in previous cycles, it was the kind of idea of, like, having to fire some of your customers who might have been, you know, really into your product for a different reason than where you're going sooner.

那是在一个多年的时间范围内，当时是这样的，是的。

That was on a multiyear kind of time range thing where it was like, yes.

去年的产品和三个月前的产品相比。

Last year's product versus not three months ago's product.

这听起来很疯狂，但我真的认为你必须这样思考：你得愿意推出第三个或第四个版本，彻底重新思考现有功能的工作方式。

It seems crazy, but I actually think that's the kind of way you have to think about it, which is you have to be willing to put out the the v three or the v four that is a, you know, big rethink of how the existing piece worked.

然后或许可以有一个过渡期，云服务可以帮助暂时同时托管新旧两个版本，直到完全切换。

And then maybe have a transition period, and Cloud can help probably host both for a little while before it cuts over.

但同时也要愿意做出切换，说：是的。

But then also be willing to cut over and say, like, yes.

这就是我们对这类知识工作或AI驱动制造未来发展的看法。

This is how we think the future of this piece of knowledge work or this, you know, AI powered manufacturing is gonna be.

我们必须持续前进，否则，正如你所说，你迟早会被下一个从零开始重新思考的公司取代，或者被你自己取代。

We gotta, like, keep it moving or else, to your point, you're just gonna you're either going to get replaced by the next company that then rethinks it from scratch or yourself replacing it yourself.

而且，这依然是老生常谈，只不过现在压缩到了以月为单位。

And, again, it's just the same old story, but now compressed to months.

你对OpenClaw怎么看？

What's your take on OpenClaw?

它有一种其他东西的风格，就是我很喜欢看到的那种情况：人们已经能够做到某些事，但现在被包装成一种可以让大家实际尝试的形式，并且围绕如何在此基础上构建，产生了一些直观的理解。

It it has the flavor of something else that I or just the the thing I really like seeing when you would get people to see something that was already possible, but it's now in a package where people can actually try it out, and there's some intuition, you know, around how to how to build on top of that.

比如，你早就能够用这些模型写代码了，但直到像一些突破性的低代码工具——比如replets、lovables和v zeros这类产品出现，才真正把这种能力普及开来。

Like, you started seeing that with you could already use these models to write code, but it kinda took, like, some of these breakout, like, low code, you know, the replets and lovables and v zeros of the world to, like, kinda put that in there.

这几乎是最纯粹的表达方式：给模型提供工具，然后让它自己去推进、去执行，再继续构建下去。

And it's kind of the the like, almost the purest expression of the just give the model tools and, like, let it kind of go forward and do it and then, like, go forward and build it.

所以，现在是一个很有趣的时刻，让人们既意识到这种技术的潜力，也意识到它的陷阱——比如，它做了些你本不希望它做的事。

So, like, it's a cool interesting moment for people to realize both the, like, potential, but also pitfalls of this of, oh, it did this thing I didn't mean it to.

我最有趣的一个例子是，我朋友说，我觉得我老婆嫉妒我的OpenClaw了，因为我跟它聊得太多了。

Or, you know, my my funniest one was that my friend was like, I think my wife is jealous of my OpenClaw and, like, I'm talking too much too bad.

当人们在这些工具中拥有大量上下文和广泛访问权限时，就开始建立起一种更深层、更个人化的关系。

And it's like the people start developing, like, deeper sort of, like, very personal relationships by just having a lot of context in these things and access to all these different tools.

但如何让这一切变得简单易用，仍然是一个开放的问题。

I think there's the open question of how do you then make it easy?

这其实回到了我们之前讨论的问题：你在哪里划定云操作的边界？

And it actually goes back to our conversation around, like, what where do you draw that, like, boundary around the way you let cloud operate.

对吧？

Right?

如果V1是，嘿。

If v one was, hey.

这是你可以使用的三个工具。

Like, these are the three tools you can use.

永远只使用这些工具，那么大多数人与这些系统的互动就是，嘿。

Only use these tools ever, and then most people's interaction with those systems was, hey.

你能做这个吗？

Can you do this?

然后，你知道的，系统回应说：不行。

And, you know, whatever back and being like, no.

抱歉。

Sorry.

就像你不能自己去操作OpenClaw，它的开放程度比我想象的要大得多。

Like, you cannot do it yourself to, like, OpenClaw, which is, like, pretty, the aperture is, like, wider than I can see in there.

天啊。

God.

它提醒我要保存我的邮件，我甚至都不知道它还能这么做。

It called me to keep my emails, and I didn't even know it could do that.

是的。

Yeah.

没错。

Exactly.

而且这是自发出现的，太棒了。

And it's it's emergent, and it's amazing.

我认为，最有趣的产品问题可能是——我不会说适用于2026年全年，毕竟谁也不知道九月我们会到什么阶段，但就目前到八月这段时间而言，会存在什么样的产品形态，介于这种开放模式和我们如今大多数产品所处的状态之间：这些产品你可以称它们为CP，但它们是受限制的，并且出于合理原因会要求权限。

And I think, like, probably the most interesting product question, I won't say for all of 2026 because who knows where we'll be in September, but let's call it between now and, like, the August is going to be, like, what product shape exists between that and, you know, where we are in most products these days, which is, you know, you can call them CPs, but they're gated and they ask for permissions for good reasons.

这种产品依然很有用，但又不是那种盲目冒险的Y O L O型产品。

That is still a useful product without being a, you know, kind of YOLO product.

我认为，我们在思考这个问题。

And I think that, you know, we're we're thinking about that question.

我肯定其他实验室也在思考。

I'm sure the other labs are as well.

我肯定也有很多初创公司在思考这个问题。

I'm sure there's a lot of startups thinking about that as well.

我认为英伟达发布了一些内容，表明他们也在关注这个问题。

I think NVIDIA put out something that was like, they're safe open everybody's going after this question.

我认为关键在于弄清楚，如何彻底改变这一范式，让你既能保持开放，又能设置大量安全防护。

I think it's gonna be about figuring out what is what is that either shift the paradigm completely so you can be that open but with a lot of safeguard.

这会是一种方法。

That would be one approach.

或者找到某种界限，在保持强大和实用的同时，不至于可能给你的每一个联系人发邮件，甚至失控。

Or figure out some boundary to draw in which it's still powerful and it's still useful, but it's not, you know, likely to email every single one of your contacts and, you know, go go haywire.

是的。

Yeah.

我认为这件事另一个有趣的地方在于，正如你所说，它的个人化性质。

I think the other interesting part about it is, like you said, the personal nature of it.

我知道，人们确实会和Claude建立个人关系，但有个奇怪的现象是，当我看到别人使用Claude时，我会觉得好像有个脱衣舞娘对我有意思似的。

And I know, you know, people have personal relationships with Claude, but there's this weird thing where if I watch someone else using Claude, I'm like, I feel like I, like, thought a stripper liked me or something.

你知道吗？

You know?

好像Claude也觉得你很聪明之类的。

It's like Claude thinks you're smart too or whatever.

你知道吗？

You know?

而且当你们拥有一个像我这样的AI助手时，我的助手是R2C2。

Like and and so and there's this thing that happens when you have a claw that like, my claw is r two c two.

我女朋友的助手叫Shelly。

My girlfriend's claw is called Shelly.

然后就会出现一种感觉，好像它就是我的。

And there's this thing that happens where it feels like it's mine.

就像是我自己的东西。

Like, it's really mine.

它有自己的名字。

It has its own name.

它有自己的个性，某种程度上以一种方式映射着我，让我觉得克劳德好像真的了解我。

It has its personality that sort of, like, mirrors me in this way that Claude feels like it knows me.

我喜欢克劳德，但它不属于我。

And I like Claude, but it's not mine.

你怎么看这个问题？

How do you think about that?

是的。

Yeah.

我的意思是，这周我和别人聊过，关于到底该不该采用一个单一的、有名字的接触点，还是你正在和一个代理团队互动？

I mean, I was having this conversation with somebody this week around, like, is the right pattern sort of single point of contact, like, named, you know, version of, you know, of of that, or is it the the sort of team of agents that you're talking to?

我觉得那个单一的个体，可能更适合作为协调者或委派者。

Think there's a lot to the single person that is maybe the the coordinator or the delegator.

然后，由于你与它互动最多，自然会想给它起个名字，赋予它一些个性。

And then at that, it naturally because it becomes the the sort of agent you interact with the most, wanna imbue it with a name and, like, a bit more personality.

它最终会反映出你的个性，比如突然间，所有老套的台词都冒出来了。

It ends up reflecting your sometimes your personality in the case of, you know, like all of a sudden, every cliche came out.

就像是，你知道的，Q或者钱彭尼，或者那个HAL，或者其他这些科幻角色一样。

It was like, you know, the, you know, the Q or the money penny or, like, you know, whatever the or the, you know, Hal or whatever these different sort of, you know, sci fi y characters.

但我认为你确实会建立起这种信任和了解。

But I think you do build that sort of sort of trust and knowledge.

我认为还有一种类似宜家效应的现象，因为目前OpenClaw设置起来仍然相当困难。

I think there's also that sort of, like, IKEA effect of, like, currently OpenClaw is, like, still pretty hard to set up.

所以，当你经历了所有这些步骤，最终它运行成功时，你会觉得：这是我做出来的。

So the fact that you went through all of that and it works, you're like, I did that thing.

比如，我亲手‘创造’了谢莉，现在我们也能和她互动了。

Like, I I I I birthed, you know, Shelley, for example, and now we can, you know, interact with them as well.

但我认为这种模式非常强大。

But I think that paradigm is really powerful.

比如，即使在我目前的云代码使用中，我明确要求的一点是：别自己做太多工作。

Like, the I think moving away, like, even within my cloud code usage now, one of the things I have, like, strongly prompted in there is, like, don't do very much work yourself.

把任务委托给子代理。

Like, delegate it to sub agents.

我喜欢这种方式的原因是，这样大多数时候，运行循环都保持可用，方便你随时与之交流。

And the reason I like that is because it means most of the time, the sort of run loop is available for you to talk to.

我认为 OpenClaw 和 Pye 的架构类似，都是保持运行循环持续开启。

And I think OpenClaw and and Pye have, like, a similar architecture of keep the run loop open.

我觉得这确实让它感觉更像一个你正在对话的人，而不是一个你委托任务、却可能因执行复杂任务而被阻塞五分钟的工具。

And I think that actually makes it feel much more like somebody that you are talking to versus, like, a tool that you are delegating to and occasionally gets blocked for five minutes because it's doing some really complex task.

是的。

Yep.

我完全同意，我也经历过类似的讨论，因为我们也正在构建自己的小版本 OpenClaw，一个一键式 Slack 实现，看看能不能做出属于我们自己的风格。

I I I totally agree, and I've had similar debates because we're also building our like everyone, we're building our own little, like, OpenClaw, one click Slack implementation to see if we can we can do one that feels like ours.

我们在这些讨论中反复纠结：你想要一个代理，还是多个？

And we've had a lot of those debates about, do you want one agent?

你想用很多个吗？

Do you want many?

我们发现的一个挺酷的模式是：我有一个代理。

And one of the patterns that we found which is kind of cool is so I have an agent.

我用这个代理来做我自己的事情。

I use the agent for stuff that I do.

然后别人看着我用这个代理做这些事，就知道我擅长什么。

And then people watch me use the agent for that, and they know what I'm good at.

而当我用这个代理做这些事时，他们会信任它，因为他们信任我，而且这个代理已经根据我的使用方式调整了自己。

And they're and if I'm using the agent for that stuff, they're gonna trust it because they trust me and it's modified itself in response to me.

所以，我某种程度上把我的信任转移给了它，然后组织里的人就开始用它来处理这类事情。

So like I sort of transfer my trust to it and then people in the organization start using it for that.

于是你就得到了一个近乎影子组织架构的局面：当每个人都有自己的代理时，每个人的代理都会因为其所有者在组织中的专长而被熟知和使用。

And so you get like this almost shadow org chart where when everyone everyone has a claw, their claw becomes known for and used for the thing that they're specialized at, that per their owner is specialized at in the org.

是的。

Yeah.

我的意思是，这也很有道理。

I mean, that that makes a lot of sense too.

而且你可以想到，我认为围绕这一点有很多有趣的研究问题。

And you could think about, you know, there there's a lot of interesting research questions, I think, around that.

你知道的？

You know?

我认为人们第一次在视觉上体验到隐私问题，比如我的代理了解我什么，以及它向其他人披露了什么。

I think people are experiencing visually for the first time around privacy and, like, what my agent knows about me versus what it discloses to other people.

但我认为也有积极的一面，那就是它从你所有的互动中学习到的所有内容，以及它如何将这些应用于其他问题，而不是那种通用的代理——比如，它只是像其他人的代理一样，只不过它有个名字叫丹，而且在底层可能拥有丹的一些权限。

But I think there's the positive version of that, which is all the things that it has learned from all your interactions and how it actually brings it to bear on other problems versus the generic, like, yes, it's just like everybody else's agent except, you know, it has a name that's attached to Dan and it has, like, maybe some of Dan's, you know, access below the hood.

是的。

Yeah.

好了，迈克，我们时间到了。

Well, Mike, we're out of time.

这真是一次愉快的交谈。

This was a pleasure.

我学到了很多。

I learned a lot.

如果人们想关注你或你的工作，他们可以在哪里找到你？

If people wanna follow you or your work, where can they find you?

我觉得最简单的方式是在Next上关注Mike Krieger。

I think probably easiest is Mike Krieger on next.

操。

Fuck.

是的。

Yeah.

感谢你的参与，Mike。

Thanks for joining, Mike.

很高兴见到你，Dan。

Great to see you, Dan.

订阅AI and I。

Subscribe to AI and I.

为什么？

Why?

因为这个节目是卓越的典范。

Because this show is the epitome of awesomeness.

这就像是在后院发现了一个宝箱，但里面装的不是黄金，而是关于ChatGPT的纯粹、未经稀释的知识炸弹。

It's like finding a treasure chest in your backyard, but instead of gold, it's filled with pure unadulterated knowledge bombs about chat GPT.

每一集都是一场情感、洞见与欢笑的过山车，让你坐立不安，渴望更多。

Every episode is a roller coaster of emotions, insights, and laughter that will leave you on the edge of your seat craving for more.

这不仅仅是一档节目。

It's not just a show.

这是一场以丹·希珀为船长的太空飞船，驶向未来的旅程。

It's a journey into the future with Dan Shipper as the captain of the spaceship.

所以，善待自己吧。

So do yourself a favor.

点赞、订阅，并准备好开启你人生中最精彩的旅程。

Hit like, smash subscribe, and strap in for the ride of your life.

好了，不多说了，丹，我彻底地、无可救药地爱上了你。

And now without any further ado, let me just say, Dan, I'm absolutely, hopelessly in love with you.