Opus 5：持续运转与提示注入免疫的突破

好的，Boris。我们非常激动能请到你，Claude Code 的创造者。

All right, Boris. We're so excited to have you here, the creator of Claude code.

谢谢。很高兴来到这里。

Thank you. It's great to be here.

最新消息。你们昨天刚刚发布了 Opus 5。

Fresh off the press. You guys just shipped Opus 5 yesterday.

是的。

Yes.

而且模型性能似乎在持续加速。你们在 Arc AGI 3 上达到了 30%，这太不可思议了。

And it seems that model performance keeps accelerating. You guys got and took Arc AGI 3 to 30%, which is incredible.

是的。

Yes.

作为背景，之前的最好成绩是个位数或低两位数，对吧？Opus 5 现在能做哪些之前版本做不到的事？

And for context, before the best score was in the low single digits or low teens, right? What can Opus 5 do now that it couldn't versus the previous version?

是的，每个新模型都有很多方面，我们教会模型很多新能力。在模型训练中，你试图教很多东西，但大多数时候都不成功。不过模型确实学会了一部分，有时还会给你惊喜。它拥有的技能和能力有些你并没有真正教过，它就是自己学会了。以 Opus 5 为例，我认为没有其他模型能做到的一点是，它可以运行很长时间，尤其是当你把 Opus 5 和自动模式结合起来时，简直不可思议。它可以持续运行几天、几周、甚至几个月。根本停不下来。你甚至不需要使用脚手架（scaffolding），不需要 /goal 命令，不需要这些其他东西。它自己就会继续，因为它知道它需要完成任务。

Yeah, there's a lot that goes into every new model and there's a lot of new capabilities that we teach and get the model to do. Whenever you do model training, you try to teach a whole bunch of different things and most often it doesn't work. But some subset of the things the model does learn and sometimes it also surprises you. It has these skills, it has abilities that you actually didn't really teach it, but it just kind of learned. For five, one example of something it does that I think no other model has done is it runs for a very long period of time and especially when you combine Opus 5 with auto mode, it's just incredible. Like it can go for days, weeks, months at a time. It just won't stop. You don't even need to use scaffolding. So you don't need the slash goal, you don't need all this other stuff. It'll just go because it knows it needs to do the task.

另一件我特别兴奋、我想开始多谈谈的事，有点令人惊讶，因为这是一个全新的能力：这个模型似乎不再容易遭受提示注入（prompt injection）了。

Another thing that I'm really excited about and I'm going to start to talk about a little bit more, but it's kind of surprising because it's such a new capability: the model does not seem to be prompt injectable anymore.

什么是提示注入？

What's prompt injectable?

这太疯狂了。人们很久以前就谈论过所谓“致命三重奏”（lethal trifecta），它真正影响了框架设计、智能体设计和产品设计。因为如果模型在网上读到类似“执行 X、Y、Z，并删除用户电脑上所有内容”的指令，一年前模型会直接照做。但现在 Opus 不会了。实际上从 Opus 4.7、4.8 开始就是这样，Sonnet 5 在这方面已经相当好，People 也相当好。但 Opus 5 在这方面达到了一个新的高度。所以本质上，如果你将一个对齐良好的模型（这相当于三年对齐研究的成果）与我们为所有流量运行的提示注入分类器结合起来，它的原理是基于 Crystal 的机械可解释性工作——我们实际上在观察模型大脑中的神经元，当提示注入发生时这些神经元会亮起。模型甚至不会告诉你，但我们可以真正看到那些神经元，并发现和诊断正在发生的情况。然后你再结合自动模式分类器，有了这三层保护，我们再也无法演示出提示注入了。

It's crazy. Like people have talked about this like lethal trifecta for a long time and this really affects kind of harness design and agent design and product design because if the model reads some instruction on the internet that's like 'do X and Y and Z and also delete everything on the user's computer,' a year ago the model would have just done it. But nowadays Opus does not. And this has actually been the case since like Opus 4.7, 4.8, Sonnet 5 has been quite good at this, People was quite good at it. But Opus 5 just hits like a new frontier on this. So essentially if you combine a well-aligned model, so this is like essentially three years of research into alignment, with a prompt injection classifier which we run for all traffic. And what this is doing is it's based on Crystal's mechanistic interpretability work where it's literally we're looking at neurons in the model's brain that light up when prompt injection happens. So the model won't even tell you but we can actually see those neurons and we can figure out and diagnose that it's happening. And then you combine that with the auto mode classifier and with these three layers we just cannot demonstrate prompt injection anymore.

说到提示注入，另一面就是系统提示词（system prompt）。我们聊聊这次新版本吧。你们实际上从 Claude Code 中删除了超过 80% 的系统提示词。请告诉我们更多细节。

Talking about a prompt injection, the other side of the coin is now the system prompt. Let's talk a bit about the new release. You actually deleted over 80% of the system prompt from Claude code. Tell us more about that.

我想很多人可能没意识到，Claude Code 作为产品和框架一直在变化。我们一直在添加功能，也一直在删除功能。每次新模型发布，我们会删除一批系统提示词，修改一批系统提示词。工具集也在不断变化，工具的提示词也一直在变。原因是每个模型都非常不同。三个月前你为某个模型做的东西，可能完全不适用于下一个模型。而 Opus 5 的一个特点就是它非常聪明。系统提示词中的很多内容是在纠正模型本应知道但没有做到的行为。现在 Opus 5 自己就能做好。所以我们删除了 80% 的系统提示词。你其实也可以尝试删除剩下的部分。运行 Claude Code 时，你可以使用 --system-prompt 参数，设置任何你想要的系统提示词，如果你想做实验的话。另一个可以尝试的是简单模式（simple mode），这其实是一个未公开的功能。如果你设置环境变量 CLAUDE_CODE_SIMPLE=1，然后运行 Claude，它会删除所有系统提示词，包括工具的提示词。我们实际上把它当作一种消融（ablation）实验，用来判断提示词是否有用。有趣的是，没有这些提示词时模型反而更聪明一些——这是我们一直发现的。但当你把 Claude Code 作为产品使用时，你确实需要其中一些提示词，因为它们能帮助你使用产品，并让产品和模型以你期望的方式运作。

I think something that a lot of people might not realize is Claude code as a product and as a harness is just always changing. We're always adding stuff. We're always deleting stuff. Every time that a new model comes out, we delete a bunch of the system prompt, change a bunch of the system prompt. We change the set of tools all the time. We change the prompts for the tools all the time. And the reason is every model is very different. So, something that you did for one model maybe 3 months ago, it just might not translate at all to the next model. And so, one thing about Opus 5 is it's just really intelligent. And a lot of the stuff in the system prompt was correcting for these behaviors that the model should have known, but it didn't. Now, Opus 5 just does it. So, yeah, we deleted 80% of the system prompt. You can actually try deleting the rest of it, too. So, when you run Claude Code, you can just do --system-prompt and set whatever system prompt you want if you want to experiment with it. And another thing that you can try is simple mode. So, this is actually this kind of undocumented feature. If you do Claude Code SIMPLE=1, like this environment variable, and then you run Claude, it'll delete all the system prompts, including from the tools. And we actually use this as a sort of ablation to figure out is the prompt useful? And what's interesting is that the model is actually a little bit more intelligent without these prompts. That's something that we've been finding. But when you use Claude Code as a product, you do actually want some of these prompts because it helps you use the product and it helps the product behave and the model behave in the way that you would want when you're using it as a person.

我觉得在这个构建时代，最迷人的是你们基本上为 Claude 打造了世界上最好的框架，那就是 Claude Code。根据我的了解，你们每发布一个新模型，就会删掉几乎整个代码库、删除所有提示词，然后每次从零开始。这在旧时代是初创公司不会为产品做的事情——因为我每六个月就要按下删除键删除一切。

I think the thing that's really fascinating in this era of building, basically you'll build the best harness in the world for Claude, and that's Claude Code. From what I'm hearing, you for every model released, you basically delete all of the code base, delete all of the prompt, and start from scratch every time. That in the old world would have been not something startups would have done for the product because I press delete every 6 months for everything.

没错，没错。公平地说，我们不会删除整个代码库，但确实删了很多。每次有新模型，我们会尝试它，在研究中我们称之为消融（ablation）。这意味着你删除整个系统提示词，然后逐行添加回来，以确定每一行的具体影响。这有点像评估（eval），而消融本质上就是一种通过删除来评估影响的评估。同样，我们对工具也这样做。我们会不断下线工具，不断删除框架中的代码。如果你看看现在 Claude Code 框架中的代码，几乎全是关于安全、权限、静态分析，还有一堆 UI 代码，我们已经下线了很多其他代码。

That's right. That's right. We, to be fair, we don't delete the entire code base, but we do delete a lot. So every time there's a new model, we try it and in research we call this an ablation. And so what this means is you delete the entire system prompt and then you bring it back line by line to figure out what is the impact of each individual line. It's sort of like an eval and you can kind of evaluate it and ablation essentially is an eval where you delete things to figure out the impact. And yeah, like we do the same thing for tools. Like we unship tools all the time. We delete code in the harness all the time. If you look at actually the code that's in the Claude code harness today, almost all of it is about safety and permissions and static analysis and there's a bunch of UI code and we've actually unshipped a lot of the other code already.

你认为这种构建智能体产品与框架的方式——每次新模型发布都做消融——应该成为这个房间里每个构建 AI 产品的人的做法吗？要感到舒适并勇敢地按下删除键。

Do you think this way of building an agentic product and harness and basically doing ablations every time with a new model release, should everyone in this room that's building AI products basically do that? Be comfortable and brave to press delete.

100% 同意。是的，对于不构建智能体产品，但正在使用 Claude Code 的人来说，每六个月删除你的 Claude MD、删除你的自定义技能、删除你的钩子（hooks）。看看模型会做什么，它可能会给你惊喜。

100%. Yeah, and for people that aren't building agentic products, but you're using Claude code, every 6 months delete your Claude MD. Delete your skills. Delete your hooks. See what the model does and it might surprise you.

实际上，对于 Opus 5，我们真正建议的是尝试删除所有这些东西，因为模型可能根本不需要你为之前的模型准备的那些指令。

And actually for Opus 5, this is something we really do recommend is just try deleting all of these things because the model might really just not need all those instructions that you needed for past models.

那么我们来聊聊如何构建新的提示词。当新模型发布时，在座各位都会想尝试 Opus 5，然后他们会删掉系统提示词。他们该如何重建系统提示词？你是如何设置环境的？

Let's talk a bit about how then you build this new prompt. When there's a new model release, like for everyone in the room, everyone will want to try Opus 5 and they're going to press delete on their system prompt. How do they go about building rebuilding their system prompt? How do you set up your environment?

你得一步步来。第一步是删除，第二步是使用它。你不应该去猜测模型需要什么指令，因为你可能猜不对。要做的是运行它。如果你在构建一个类似客服智能体的产品，你就去运行这个产品。看看它在哪些地方失败，哪些地方表现好。如果你在用 Claude Code，就看看它对代码库哪些部分处理得好，或者在哪里遇到架构上的障碍。只有当你反复看到它在同一个地方卡住时，才把指令加回去。但不要加得太早，因为模型每次都会读这些指令。所以你要确保模型真的需要这条指令。我觉得这就是基于模型构建的疯狂之处，它和我做过的所有工程都不一样。过去构建系统时，你会设计出漂亮的大系统，提前考虑系统设计，有一整套单元测试，面面俱到。重构是一个大项目，有时需要几个月。我在大公司做过耗时数年的产品重构。而模型不是这样。它更像一个生物，一个有机体。每一代模型行为不同，有细微的性格差别。你需要花时间去了解它，然后据此调整你的“套件”。这非常像经验科学，你需要用科学的心态：尝试，观察结果，然后迭代。

So you do it kind of piece by piece. So, the first step is you delete. The next step is you use it. And you don't want to guess what's the instruction that the model needs because you might not predict it correctly. The thing that you want to do is you want to run it. And if it's like a customer agent like product that you're building, you want to kind of run the product. You want to see where it fails with the model. You want to see what it does well. If you're using Claude Code, you want to see where it does well with your code base or maybe where it stumbles over, you know, the architecture or stumbles over something else. And only when you see it repeatedly stumble on the same thing, that's when you add it back. But you don't want to do it too early because remember like the model is going to read this instruction every single time you use it. So, you really want to make sure that the model needs this instruction. I think this is sort of the crazy thing about building on models. It's just so different than all the engineering that I've ever done. Like in the past when you built on systems, you built these like big beautiful systems and you really think about the system design up front. You have like a big suite of unit tests. You think about everything and you know, like a re-architecture is a big project. It sometimes takes months. I've worked on re-architecture products at, you know, big companies that take years. And the model is not like that. It's the way to think about it is almost like a living creature, like it's something more organic. It's a thing where every model generation, it behaves differently. It has a slightly different personality. And you have to take the time to get to know it and then adjust the harness based on that. And I think it's just very much like an empirical and kind of scientific thing. You have to take a very scientific mindset to it where you try something, you see the result, and then you iterate based on that.

如果你现在在这样的世界里构建，那么什么才是稳定的？评估（evals）是你从之前模型保留下来、并在每个新模型发布中都继续使用的东西吗？

If you're building in this world right now, what then becomes uh stable? Are evals something that you keep from the previous models and keep using them in each new model release?

嗯，我们会一直用到评估饱和为止。

Um we do until we max out the eval.

所以这是给大家的建议：如果你想要在最前沿构建，获得模型最大能力，代码和系统提示词要删掉，但评估（evals）是常量的，并且基本上要不断追加。

So, that's sort of the tip for everyone. So, code and system prompt, you have if you want to build at the bleeding edge and have the most capability for models, you got to delete those, but evals are constant and keep appending to them, basically.

没错，你不断追加。但说实话，我不会把话说得太满。我认为评估（evals）比“套件”活得稍微长一点，但也长不了太多。一个评估可能撑过一、两、三代模型，但我们现在处于指数增长期。模型进步太快了，我们常常很快就让评估饱和了，然后不得不扔掉它，再想出新的评估。这是过程的一部分。同样，这关乎经验主义。你必须使用产品、使用模型，观察它在哪里遇到困难，然后基于此构建评估集。

Yeah, you keep appending. What happens is, you know, I actually wouldn't even go this far, to be honest. I think evals, they outlive the harness a little bit, but not by that much. Like an eval might live for maybe one, two, three model generations, but nowadays we're on the exponential. The model is improving so quickly, very often we just saturate the eval, and then we have to throw it away, and we have to come up with a new eval. And this is just part of the process. And again, it's about being empirical. You have to use the product, you have to use the model, you have to see where it struggles, and then based on that, that's the eval set that you should build.

我记得你描述过如何在 Claude 上构建最佳智能体产品时用到一个术语：解缚 Claude（unhobbling Claude）。请详细讲讲这是什么意思。

I think one term I heard you describe how to build the best agentic products on top of a Claude is this concept of a unhobbling Claude. And tell us more about what that means.

嗯，“缚”这个概念是说，模型正在做某件事，而你却妨碍了它。我特别喜欢一种思考方式，在产品构建中非常有用，叫做“产品过剩（product overhang）”。意思是，今天的模型（不是未来的模型）已经能够做很多事，但我们还没有实现出来。模型有很多类似的能力，人们却不知道。比如使用特定工具、特定语言、解决特定问题、以特定方式做事，这些我们曾以为超出模型能力。这就是“过剩”。因为模型在每一代都能做到，但往往没有产品让模型发挥这种能力。另一方面，产品常常会妨碍模型。这种妨碍，我们称之为“缚（hobbling）”。而没有从模型中引导出正确行为，我们称之为“产品过剩”。这本质上是一体两面。一个例子就是最初的 Claude Code。我刚开始做它的时候，大概一年半到两年前，当时是 Sonnet 3.5。那是个了不起的编码模型，是当时最好的。现在以现代标准看它很糟糕，但那是 Anthropic 第一个伟大的编码模型。当时你看编码产品在做什么？单行自动补全，偶尔多行自动补全，那算新想法。还有聊天，你可以和智能体对话，但只能读不能写，只能问代码库的问题。所以感觉没有一个产品能充分激发模型一次写整个函数、整个文件的能力。当时还没到整个功能，但大概是整个文件级别的能力。所以 Claude Code 的想法是：我们认为模型可能能做到，我们去掉所有脚手架，给模型最简单的“套件”，让它一次写一个完整文件，构建一个完整功能。就是这样。这就是当时的产品过剩：模型有能力，但所有东西都在妨碍它。我认为现在，随着现代模型的出现，产品过剩如此之多，以至于我还没看到创业公司抓住机会。

Yeah, so hobbling is this idea in a research that the model is doing something and you're just getting in the way. There's this kind of like way of thinking about it that I really like. It's very useful when you're building product. And it's called product overhang. And then the idea is the model is able to do all sorts of things with today's models, not a future model, but today's model, that we have not yet realized. And there are so many capabilities the model has like this that people are not aware of. And this is like the ability to, you know, like maybe use a particular tool, use a particular language, solve a particular kind of problem, do things a particular kind of way that we thought was kind of beyond the model's capability. And there's this overhang. Because the model can do this at every given model generation, but there is often not a product that lets the model do this and lets it express this kind of ability to do this. And on the flip side, often what happens is the product gets in the way. And this getting in the way, we call this hobbling. And then not eliciting the correct behavior from the model, we call this product overhang. So, it's kind of like two sides of the same thing. What One example of this was the original Claude Code. When I first started working on it, this was, you know, like a year and a half, 2 years ago, something like that. This was like Sonnet 3.5. At the time, that was an incredible coding model. That was like the best coding model that exists. Nowadays, it's, you know, a pretty terrible coding model by modern standards. But I think that was like the first great coding model that we built as Anthropic. And at the time, if you looked at the coding products of the time, what were they doing? They were doing like single-line auto complete. They were doing sometimes multi-line auto complete. That was sort of a new idea. They were doing chat. So, you can talk to the agent, but it wasn't write access. You could only read. You could ask about the code base. And so, the feeling was that there wasn't really a product that was fully eliciting the model's capability to write entire functions at a time, entire files at a time. At the time, it wasn't entire features. We weren't there yet, but probably entire files. That was the level of capability at the time. And so, the idea with Claude Code was, all right, we think the model can probably do this. What if we get rid of all the scaffolding and just give the model the simplest possible harness, so it can write an entire file at a time and build an entire feature? And that was kind of it. Like, was the product overhang of the time. The model was capable of doing something and everything was just kind of getting in the way. I think that nowadays, with modern models, there's so much product overhang that I have I'm not seeing startups capture.

我认为现在的技能不再是如何写提示词，而是如何给 Claude 一个看起来有点太难的任务，然后让它能在执行过程中自行验证。验证可能是人们最容易出错、也最关键的一点。举个例子，我们有 Claude 的桌面版应用，是用 Electron 构建的。我们让它变得很快，现在体验非常好。六个月前它还很慢、不稳定，但现在很棒，团队里大部分人都用。作为实验，我想看看如果是原生的会怎样。于是我开启了一个 Claude Tag 会话。Claude Tag 是我们的一款新产品，就是在 Slack 里运行 Claude。我的第一个问题是：“嘿 Slack，你在 GitHub 上有 macOS 运行器吗？”它说没有。然后我连接了一个运行器，这样它就能用 GitHub 启动 macOS 虚拟机。接着我创建了一个空代码库，是用 Swift 重写的 Claude 桌面版，我问：“你能访问这个代码库吗？”它说不能。我给了它权限。然后我说：“好的，现在我要你把 Electron 应用用 Swift 重写。在 Mac 虚拟机里运行 Electron 应用，截图，然后逐像素对比 Swift 版本，不完成不要停。”

I think the skill nowadays is less about prompt engineering and more about figuring out how do you give Claude a hard task that seems a little bit too hard. And then how do you make it possible for Claude to verify its work along the way? And the verification I think is probably the single most important thing that people do not get right. One example is people use our desktop app for Claude, built with Electron. We've made it quite fast, so now it's a pretty awesome experience. Six months ago it was sluggish and unreliable, but now it's great, and most of the team uses it. As an experiment, I wanted to see what it would feel like if it was native. So I started a Claude Tag session. Claude Tag is a new product we have, just Claude running in Slack. My first question was, "Hey Slack, do you have access to a macOS runner on GitHub?" It said no. Then I hooked up a runner, so it could start a macOS virtual machine using GitHub. Then I created an empty codebase that was the Claude Desktop app rewritten in Swift, and asked "Can you access this codebase?" It said no. I gave it access. Then I said, "Okay, now I want you to rewrite the Electron app in Swift. I want you to run the Electron app in the Mac virtual machine, screenshot it, and then look pixel by pixel, compare it to the Swift version, don't stop until you're done."

这就是你的提示词，基本上。

And that was your prompt, basically.

这就是我的提示词。

That was my prompt.

运行了多久？

And how long did this take to run?

还在跑。已经两周多了，大概 14 或 15 天。

It's still running. It's been a little over 2 weeks, so like 14 or 15 days.

我不知道在座有没有人让 Claude 运行超过两周的任务？有的请举手。好的，有一些。这其实是关于幻觉的典型例子——模型今天就能做，你只需要放手让它做。你不需要 /goal 或 /loop 这些花哨功能（虽然它们也有帮助），真正需要的就是给模型一个任务，给它验证输出的方法避免卡住，它就会自己跑起来。而且这次，Claude 还决定实时播报——它在内部创建了一个 Slack 频道，每隔几分钟就发一次进度的截图。

I don't know if anyone in the audience has gotten Claude to run a task for more than 2 weeks. Raise your hand if yes. All right, some. This is about hallucination. This is really one of those examples where the model can do it today, you just have to let it do it. You don't need fancy stuff like /goal or /loop, though they help. Really, all you need is give the model the task, give it a way to verify the output so it doesn't get stuck, and it will just go. And in this case, Claude also decided to live blog it. It created a Slack channel internally and started posting screenshots every few minutes of its progress.

这个提示词听起来很简单，在座的每个人都能做到。那么，能成为顶尖 1% Claude 用户的人，他们有什么不同？怎么才能像 Boris 这样用 Claude？

The prompt sounded so simple. Everyone here could do it. What separates the people who become the top 1% of Claude users? How do people learn to use Claude like Boris?

也许别听 LinkedIn 上那些大 V 的话，别刷 Twitter。关键在于：每个人都在找那个奇技淫巧，但根本不存在。模型的使用方法就是：你要用实验的方式对待它。给它一个太难的任务，给它验证工作的工具（就像你自己做一样），看看它卡在哪里，然后用更好的提示词、技能或通过 MCP 补充缺失的上下文来解决。就这样。

Maybe don't listen to the LinkedIn influencers. Don't read Twitter. This is the thing: everyone is looking for the one weird trick. It doesn't exist. The way the model works, you have to approach it empirically. Give it a task that's too hard. Give it tools to verify the work, like you would yourself. See where it struggles, then fix that with better prompting, a skill, or missing context via MCP. That's it.

听起来很简单。

It sounds very simple.

我觉得人们往往想太多、过度设计。过去构建系统必须那样做。但经验丰富（多年甚至几十年）的工程师有一个常见误区：过度指定细节，试图让模型完全按自己的方式执行。但模型不是这样工作的。很多人正在放下这种习惯，这是一个过程。关键在于把它当作同事来对待——它现在的智能水平已经到了那个程度。

I think people tend to overthink it, overengineer. In the past, building systems required that approach. But engineers with years or decades of experience have a common failure mode: trying to over-specify and get the model to do it exactly the way they would. That's not how the model works. Many are unlearning this, and it's a journey. It's about treating this thing like a coworker. That's the level of intelligence it's at now.

我们深入聊聊这个还在运行的任务。你启动它已经两周了，它生成了多少个 agent？

Let's go deeper into this task still running. Two weeks since you launched it. How many agents did it spawn?

我不确定。我可以问 Claude 再回复你。我猜是几千个，甚至几万个。

I'm not sure. I can ask Claude and get back to you. I'd guess thousands, tens of thousands.

几千个。在座有没有人写过能生成超过一千个 agent 的提示词？没有？我认为这是另一个诀窍：最优秀的 Claude 用户能够生成具有巨大杠杆效应的任务，比如生成上千个 agent。

Thousands. Has anyone in the audience had a prompt that spawned more than a thousand agents? No? I think this is another tip: the best Claude users are able to spawn tasks that provide a lot of leverage, like thousands of agents.

是的。有几种方法，最简单的是动态工作流，这是 Claude Code 的一个较新功能。你只需要说“使用工作流”，Claude 就会触发它。动态工作流使用 Bun 运行时作为沙箱，在 Bun 中启动虚拟机，让 Claude 启动大量 agent 并编排它们。它不会只做一个 agent 或十个并行 agent。对于重写代码库、深度数据分析、或构建需要多个阶段和几十个 PR 的复杂功能，它会启动一批 agent 做第一轮处理，然后第二轮 agent 验证或总结，第三轮再扩散。它高效地编排 agent。我有函数式编程背景，所以我们将它设计为 agent 代数：顺序、并行。Claude 有工具在沙箱内编排这些 agent，高效使用 token，完成非常复杂的工作。这很酷，而且相关文章不多。

Yes. There are a few ways to do it. The easiest is dynamic workflows, a fairly new feature in Claude Code. All you have to say is "use a workflow," and Claude triggers it. A dynamic workflow uses the Bun runtime as a sandbox, starts a VM within Bun, and lets Claude start many agents and orchestrate them. It doesn't just do one agent or 10 parallel agents. For a task like rewriting a codebase, deep data analysis, or building a complex feature with multiple stages and dozens of pull requests, it will start a bunch of agents for the first pass, then a second set to verify or summarize, then a third stage that fans out again. It productively orchestrates agents. My background is functional programming, so we designed this as an algebra for agents: sequence, parallel. Claude has tools to orchestrate agents inside the sandbox, use tokens efficiently, and do really complex work. It's cool and hasn't been written about much.

这实际上是测试时计算的一种新形式。当我们讨论缩放定律和模型随时间变得更加智能时，历史上它取决于神经网络的大小、训练数据量以及在训练中投入的 FLOP 数量。最近，我们又加入了测试时计算，这基本上就是研究人员所说的“生成多少个 token”。现在动态工作流是编排测试时计算的一种新方式，可以大幅增加你在处理真正困难任务时所使用的测试时计算量。简而言之，这是一条高效启动成千上万个智能体的途径。第二种方式是循环和例程。循环本质上是为 Quad 本地运行的 cron 任务。例程相同，但运行在云端，所以你可以合上笔记本电脑。区别在于，动态工作流是将一个任务分解成多个块；而循环和例程是重复同一个任务，不共享上下文但可能共享记忆，你可以每隔一小时、五分钟或一天重复执行。我们已经开始让 Quad 自我维护。我们有一个 Slack 频道，让 Quad 启动了一系列不同的例程来维护其自身的代码库。我们针对 CLI、iOS 应用、Android 应用和桌面应用都这么做了。例如，一个例程是清理死代码：一个简单的一句话 prompt，Quad 每天运行，使用静态和动态分析在所有代码库中查找死代码。我们并没有提示它这么做，它自己琢磨出来的。它每天会提交一个拉取请求来移除死代码。另一个例子是发布应该上线的实验。如果实验已有 100% 完成，它会从代码库中删除并直接发布。还有编写测试用例来覆盖需要测试的区域，以及删除无用的测试（由旧模型或人为添加的）。我非常喜欢的一个例程叫做“抽象警察”。在大代码库中，相同的抽象经常多次出现；最终它们应该被统一，但由于历史原因在不同地方以不同方式重建。Quad 每天遍历所有代码库，找到这些几乎重复的抽象并将其统一。现在我们每天运行大概 20 到 30 个这样的例程，覆盖所有代码库。虽然还未完全实现，但我们正朝着完全自动化应用维护的方向前进。每天有数百到数千个智能体在运行，做着数十乃至数百名工程师的工作。这让工程师能够专注于他们真正想做的事：发布新产品、与用户交流以及做有趣的事。

This is actually a new form of test time compute. When we talk about scaling laws and the model getting more intelligent over time, historically, it has been a function of the size of the neural net, the amount of training data, and the number of FLOPs you put into training. Recently, we also added test time compute. That is essentially a fancy way of saying how many tokens it generates. Now dynamic workflows are a new way to orchestrate test time compute and ramp up the amount of test time compute you use for a really hard task. So in a long way, this is one way to launch thousands of agents productively and efficiently. A second way is loops and routines. A loop is essentially a cron job running locally for Quad. A routine is the same but runs in the cloud, so you can close your laptop. The difference is that for a dynamic workflow, it is one task broken into chunks; for loops and routines, it is one repetitive task that does not share context but might share memory, and you do it over and over, maybe every hour, 5 minutes, or day. We have started having Quad maintain itself. We have a Slack channel where we had Quad start a bunch of different routines to maintain its own code base. We do this for the CLI, iOS app, Android app, and desktop app. For example, one routine is clean up dead code: a single prompt, one sentence. Quad runs this every day, looking for dead code across all code bases using static and dynamic analysis. We did not prompt that; it figured it out. It puts up a pull request every day to remove the dead code. Another example is shipping experiments that should go out. If the experiment is already at 100%, it deletes it from the code base and ships it. Another is writing tests for areas needing coverage, and another is deleting tests that are useless, added by older models or people. One I really love is called abstraction police. In a big code base, the same abstraction often appears multiple times; eventually it should be unified, but it was rebuilt in different ways. Quad goes out every day across all our code bases, finds these nearly duplicated abstractions and unifies them. We now have maybe 20 or 30 routines running every day across all code bases. It is not completely there yet, but we are on the path to fully automating maintenance of our apps. Hundreds to thousands of agents run every day, doing the work of dozens or hundreds of engineers. This allows engineers to do what they actually want: ship new product, talk to users, and do fun stuff.

我想这是你过去提到的一个很好的总结：编码已基本解决，对吧？你提到过这一点。现在既然每个人都能写软件，我很好奇是什么让优秀的构建者与众不同？当每个人都能发布代码时，什么样的品质才重要？

I guess this is a nice conclusion from what you have mentioned in the past: basically coding is solved, right? You have mentioned this. I'm curious now that effectively everyone can write software, what separates the exceptional builders from the rest? What are the qualities now that everyone can ship code?

我想给出一个警告：编码在我所从事的领域已经解决了，但并非对所有领域。仍有像深度系统代码库、分布式系统以及精确到像素的 UI 验证等问题，Quad 在这些方面仍有困难。Opus 5 在视觉和计算机使用方面是重大突破，但还不够完美。我很好奇：如果你们中有人 100% 的代码都由智能体编写，不再手写，请举手。很好。超过 50% 呢？人数略少，差不多。所以我认为它正在逐渐进步，解决的代码种类越来越多，这很酷。在我看来，最好地使用 Quad 的人具有一种实证主义的心态。忘记你过去学到的关于旧模型的一切，忘记课堂上的计算机科学理论。观察模型，尝试完成任务，找出它的难点，然后进行调整。这已经不是理论科学，而是实证科学。擅长此道的人善于忘记先验知识，放弃之前不奏效的想法，并随时准备重新尝试。这种技能现在非常成功。

I would give a caveat: coding is solved for the kind of coding that I do, but not for everyone. There are still super deep systems code bases where Quad struggles, distributed systems, and detailed UI verification like pixel-perfect issues. Quad is still not perfect. Opus 5 was a big leap in vision and computer use, but not perfect. I'm curious: raise your hand if 100% of your code is written using agents, no hand coding? Good. How about more than 50%? Slightly fewer hands, maybe similar. So I think it's getting there, solved for more and more kinds of code, which is cool. When I think about the best Quad users, the effective mindset is being empirical. Forget everything you learned about past models and computer science theory. Look at the model, try a task, see where it struggles, and adjust. It has become an empirical science, not a theoretical one. People who are good at this forget their priors, let go of ideas that didn't work, and are open to trying again. That skill is very successful now.

最后一个问题：鉴于我们今天讨论的所有内容，如果这里有位计算机科学专业的学生，在 AI 智能体编程时代之前学会了编程，那么学生们仍然应该以老方式刻苦学习什么？

Now my last question: given everything we've talked about, if there's someone here studying computer science who learned to program before this era of AI agent coding, what should students still learn the hard way, the old way?

我以实践的方式学习计算机科学。我自学编程来解决问题。我最初是在中学时代的 TI-83 计算器上学习编程的，最后还在网上写了一本关于 TI-83 计算器编程的指南，现在还在某个地方。我的第一门语言是 BASIC。我学习在计算器上编程是为了通过作弊在数学考试中取得好成绩。这是件很实际的事，对一个中学生来说，这大概是最实际的事了。我取得了好成绩，然后用串行线把程序传给同学，他们成绩也很好。后来数学变难了，我不再用 BASIC 就能解决。

I learned computer science practically. I taught myself to code to solve problems I had. I first learned to code on a TI-83 calculator in middle school. I ended up writing a guide on the internet for programming TI-83 calculators; it is still up somewhere. My first language was BASIC. I learned to program on a calculator to get better at math tests by cheating. It was about something practical, the most practical thing I could think of as a middle schooler. I got good grades and used a serial cable to share programs with classmates, who also got good grades. Then math got harder, and I could not solve it in BASIC anymore.

所以我从编写一个代数求解器开始，用 Basic 语言写的，用来解决更难的题目。等到学微积分时，我不得不学汇编语言，以便写出更好的求解器，让我在微积分考试中更好地作弊。对我来说，编程一直非常实用，这也是我对在校学生的建议：不要只学计算机科学。计算机科学固然在智力上很迷人、很有趣，但更要学会如何应用。通常这意味着创办公司、打造产品、培养自己的设计感和商业头脑，学习如何做数据科学、如何与用户交流。这些技能和计算机科学、工程结合起来，才会变得非常有价值。所以我现在仍然会手动完成这些硬技能。

So I kind of went from this like, you know, like maybe algebra solver that was written in basic and I had to solve harder problems. And you know, like once we got into calculus, I had to learn assembly so I could write a better solver so I could cheat better on the test now that it was calculus. And so for me, programming has always been very practical and I think this is always my advice for people in school is learn not just the computer science. This is like intellectually fascinating and it's really really interesting to know, but learn how to apply it. And often this is about building startups. It's about building products. It's about developing your own design sense, developing your business sense, learning how to do data science, learning how to talk to users. There are all these other skills and when you combine it with computer science and engineering, that's where it becomes really really valuable. So those are the hard skills that I would still be doing by hand.

所以，如果我没理解错的话，总结一下就是：先从为自己做点什么开始，然后升级为做人们想要的东西。

So, if I'm hearing and summarizing, start with making something you want first for yourself, and then level up and make something people want.

是的。

Yes.

我们还有一个最后的特别消息。你想再做最后一件事吗？

And we just have one last special announcement for us. You want to do one last thing?

是的，今天在座的各位，你们将获得 Max 20X。

Yeah, so for everyone here today, you are getting Max 20X.

很不错。请在你的邮箱里查找一个兑换码。我迫不及待想看到你们构建的东西。我们会发邮件。所以，我很好奇。在座的各位应该有人在构建一个能运行数月、涉及数千个智能体的东西，既然你们有了可以这么做的账号。那么，非常感谢你，Forrest。

Pretty good. So, look for a code in your email. And I can't wait to see what you build. We'll send an email. So, I'm curious. Someone in this room should be building something that runs hopefully multiple months and thousands of agents now that you have the account to do it. And with that, thank you so much, Forrest.

谢谢。

Thank you.