EXO：完全递归的自我改进智能体

好的，我们正在远程演播室，和 EXO 的 Alex Cransel 在一起，他也来自 UC Berkeley。欢迎。

Okay, we're here in the remote studio with Alex Cransel, I guess, of EXO, but also UC Berkeley. Welcome.

非常感谢。很高兴来到这里。

Thank you so much. Happy to be here.

我们录制这期节目的原因是，当你出现在我的时间线上时，我不得不这么做。我之前不知道你已经出现过。这说明 YouTube 上的内容有多持久。但实际上我看过你的讲座，却没记住你在 OpenClaw 上的名字。

The reason we're recording is because I had to when you showed up on my timeline. I didn't know that you had already showed up before. This goes to show you how much persistence there is on YouTube. But like I actually had watched your lecture and then didn't register your name on OpenClaw.

那挺酷的。是啊，也许我该多说几次，或者把它放在幻灯片里。我当时太专注于讲架构了，没有去推销自己。

That's cool. Yeah, maybe I probably should have said it a few more times or put it in the slides. I was so focused on just talking about the architecture. I didn't go to pitch myself.

是啊。但也可能只是你的脸出现在那里，还有你知道的其他工作。但你知道，那都是一回事。嗯，最近你出现了，和我们的两位前嘉宾合作，在 Leon Space 上，Martin Casado 和 Anker Goya。当我真的和 Martin 在播客上聊天时，他实际上说他在和你一起捣鼓东西，他不喜欢，因为他说，我太想编码了，我当时试图揭穿他，你知道，这个 VC 假装他会编码。我说，你在干什么，伙计，他当时就在搞这个，现在你宣布了。所以我想给你机会讲讲 EXO 的故事，然后我们可以回到你想聊的任何其他背景。

Yeah. But also like maybe like your face on there, but also you know just like other other work. But uh you know that's all that's all of a of a piece. Um most recently you you showed up uh working with two of our former guests on Leon Space uh Martin Casado and Anker Goya. When I actually talked with Martin on the podcast, he actually said that he was hacking away with you and he didn't like because I he was like, I want coding so much and I was trying to call out like you know this this VC pretending that he codes. I was like you know what are you doing man and he was working on this and now you've announced it. So I just wanted to give you the floor to talk about the exo story and then we can work our way back to whatever other background that you want to do.

当然，谢谢。我的意思是，我首先要说，是的，我一直在和 Martine 和 Encore 一起构建这个。他们都是非常优秀的系统思考者。你可能知道，Martine 的背景是计算机科学博士。实际上，是由我的导师，我的博士导师 Scott Anker 在 Berkeley 指导的。所以，这算是我们共同的传承。

Yeah, for sure. Thank you. I mean, I'll start by saying, yeah, I've been building this with Martine and Encore. They're both really excellent systems thinkers. As you might know, Martine's background is in a PhD in computer science. Actually, advised by my adviser, my PhD adviser, Scott Anker, at Berkeley. So, that's kind of our shared lineage.

共同的传承。是的。我在 Nellifi 工作时，他是我的董事会成员，我当时在学习虚拟化网络和所有那些东西。

Shared shared lineage. Yeah. He was my board member when I was working at Nellifi and I was working I was learning about uh you know, virtualized networks and all those things.

是的。是的。我们都有系统背景。我的背景完全是系统，稍后我会详细讲。但简单介绍一下 EXO，让我们达成共识。简而言之，EXO 是一个完全递归的智能体。它能够在运行时安全地编辑自身的所有方面，以便在正在处理的任务上变得更好。它由一种非常简约但有主见的框架架构实现，将当今智能体的不同部分拆分成可以安全隔离、从而安全演化的组件。我们可以更详细地讨论它是如何做到的，但你应该把它看作一个真正进行完全递归自我改进的智能体。嗯，我认为今天它之所以成为可能，是因为我们正在进入机器学习堆栈中的一个新层次，在我看来，直到最近我们仍然非常专注于让模型在它们所做的事情上变得更好。当我们说模型时，我们指的是权重。你在训练模型。首先是大型预训练运行。然后变成对模型应用微调，让它们在特定任务上表现良好。我认为过去一年向智能体的转变让我们更加意识到框架、工具、我们为 LLM 大脑提供的身体中所蕴含的力量。而现在正在发生的转变是，我们真的进入了一个空间，开始意识到当我们调整这些框架时，它们会在特定任务上变得非常擅长，要么做得更好，要么更高效。也就是说，用更少的 token 调用、更少的用量来完成任务，降低成本。成本现在是一个巨大的问题，因为前沿模型变得越来越昂贵，因为它们更大、更难服务、需要更多 GPU 等等。所以这个项目源于我在 Berkeley 过去一年左右的研究，关于发现系统。也就是 AI 驱动的发现，对吧？这个项目出自 Berkeley 的 Sky Lab，叫做 Sky Discover。它是一个外部循环，试图优化和改进一个系统。而我真正好奇的是，我们如何把它推向极致？你有一个外部系统在优化一个内部系统。如果你想优化你正在优化的方式，那么你需要一个更外部的循环，这就是无限递归，我认为唯一的出路是折叠这个循环，让系统本身负责改进自己，我称之为“折叠循环”。这与有一个外部观察者看着并试图在系统运行时对它做出改变非常不同。我希望系统能够在运行时改变自己。这就是 EXO 的论点。

Yeah. Yeah. We're kind of come from systems backgrounds. My background is fully in systems and I'll talk more about that later. But just briefly to introduce EXO so we're all on the same page. In a nutshell, Exo is an agent that's fully recursive. So it's able to safely edit all aspects of itself at runtime to kind of get better at the task that it's working on. And it's enabled by this very kind of minimal but opinionated harness architecture that splits out different pieces of what an agent is today into components that can be safely isolated from each other and thus safely evolved. We can talk much more about how it does this, but you should think about it as an agent that really does full recursive self-improvement. Um, and I think it's really enabled today by the fact that we're we're entering a new layer in the like ML stack in my mind where up until recently we've still been really focused on trying to make models better at what they do. And when we say models, we're talking about the weights. You are training the model. First it was large pre-training runs. Then it became find kind of applying fine-tuning to these models to get them good at a particular task in their thinking. I I think the shift over the last year to agents has made us much more aware of the power that lies in the harness, the tooling, the body that we provide to the brain of the LLM. And the shift that's happening now is we're really entering a space where we're starting to realize that as we tweak these harnesses, they're get really good at particular tasks, either better at doing them or more efficient. So doing them with less token calls, less usage, driving cost down. Costs are a huge concern right now because frontier models keep getting more and more expensive because they're larger, they're harder to serve, they require more GPUs, etc., etc. And so the project came from I've spent the last year or so of my research at Berkeley on discovery systems. So AIdriven discovery, right? This project come out of the sky lab at Berkeley called Sky Discover. And it was this outer loop that tries to optimize and improve in a system. And what I got really curious about was how do we take this to its extreme? You have some outer system that's optimizing some inner system. What if you want to optimize the way you're doing your optimizing then you need some outer outer loop and it's this infinite recursion out and the only way I think out of that is to collapse that loop down and make it so that the system itself is responsible for improving itself which I'm calling to collapse the loop. So it's very different than having an outer observer that's looking and trying to make changes to the other system as it's running. I want the system to be able to change itself at runtime. And this is the the kind of thesis for Exo.

是的。我在这里补充几点评论。嗯，第一个意识到这一点的人可能是 PI OpenClaw 的人，对吧？他们当时说，嗯，框架应该自我修改以添加你需要的任何能力，但它并不是你设想的那种完全自我递归。第二，所以我们可以深入探讨，你已经做过一个 OpenClaw 讲座，我会在描述中链接，人们应该看看，如果与本次对话相关，我们可以稍微谈谈。第二点是，我完全没有在我的东西上关注这个。所以，对于我的两家公司，我有一个内部机器人做工作，还有一个外部机器人 Devon 修改内部机器人。内部机器人没有能力修改自己。老实说，我有点喜欢这种分离，就像，好吧，现在这有点像伪做事，然后是做事，然后是伪做事，对吧？嗯，区别显然在于它不是神奇的。就像，你开车，然后你打开引擎盖来修改汽车，如果需要的话，但大多数时候引擎盖是关着的。嗯，所以接下来的问题是，你什么时候需要那种 AGI 的感觉，就像“哇，它在我没有要求的情况下就自我修改了”。所以这就是我的两点评论。你想从哪里开始？

Yeah. And I'll maybe add a couple pieces of commentary here. Uh the first people to realize this was probably the PI openclaw people, right? Uh where they were like, well, the the harness should modify itself to to add whatever capability you need, but it is not fully self-recursive in the way that you envision it. Second of all, so so we can go into that and you've already done an open call lecture which which I'm going to link to in in description that people should see and we can cover a bit of that if if it's relevant to this conversation. Uh the second of all is I haven't followed this at all my for my stuff. So so uh for for my two companies I have an internal bot that does work and I have an external bot Devon that modifies the internal bot. It doesn't the internal bot has no ability to modify itself. And I kind of like that separation to be super honest of like okay well now this is like the pseudo do things and then there's do things and then pseudo do things right like um the the difference obviously is it is not magical. It it is like uh you you drive the car then you open the hood to to to modify the car if you need but most of most of the time the the hood is closed. Uh and so then the question the push back is like when do you need that AGI feeling of like wow it just modified itself without me asking. So those would be my two commentary pieces there. Wherever you want,

这些观点很好。让我谈谈这两点。OpenClaw 出现并在二月真正起飞。我认为你说得对。OpenClaw 真正发现的是如何让一个智能体系统感觉神奇，因为它能适应你的工作流程。它是可适应的。但我想指出一点。它以非常特定、狭窄的方式适应。所以如果我们去看架构，OpenClaw 的人在架构中使它可扩展的地方是特定的。其中一种动态方式，超级动态的方式是记忆。所有这些智能体系统都有某种记忆。字面上，它是某个地方的 memory.md 文件。

They're great points. Let me touch on both. So OpenClaw came around and took off in really took off in February. And I think you're right. The thing that OpenClaw really discovered was how to make an agentic system that feels magical in that it kind of adapts to your workflow. It is adaptable. But I want to point something out. It's adaptable in a very particular narrow way. So if if we were to go and look at the architecture, there are particular places where the open cloud folks in the architecture have made it extensible. Those are one the one dynamic way super dynamic way is memory. And all of these agent systems have some sort of memory. Literally it is a memory MD file somewhere.

有一个 markdown 文件，东西会被写进去。每次调用 LM 时，它都会被注入到上下文中，就像我们构造对 LM 的调用一样，我们可以编辑那个文件。这是主要的超级动态方式。否则，OpenClaw 会暴露一些你可以扩展的地方。你可以添加技能。你可以让智能体去查看某个技能并添加它。你可以添加工具。而且，这通常是由人类驱动的。人类会过来说，嘿，我想要一个这样的技能，让我安装这个技能，然后让 OpenClaw 去做。所以这绝对是自我改进和可扩展性。记忆是自我改进的一种形式。但这些智能体内部还有更多的东西在发生。

There is a markdown file that things get written to. It gets injected in context every time the LM is called, like we construct a call to the LM, and we can edit that file. That's the main super dynamic way. Otherwise, OpenClaw exposes these places where you can extend it. You can add skills. You can ask the agent here, look, go look at this skill, please add it. You can add tools. And by the way, this is very often kind of driven by a human. A human will come in and say, hey, I want a skill for this. Let me go install this skill. And then ask OpenClaw to do this. And so it's absolutely self-improvement and extensibility. And memory is a form of self-improvement. But there's so much more going on inside of these agents.

什么是智能体？顺便说一句，我认为我们有必要达成共识。每个人——我相信你的听众对智能体非常了解，但有一个共同的定义很重要。我认为智能体是一次 LM 调用，被包裹在用于构建上下文的机制中。它实际上是一个大型上下文构建机器，同时也提供了一种执行动作的方式。所以上下文的一部分是“我能做这些事情”，LM 可以说“请执行这个工具或这个动作”，而智能体负责实际执行该动作，然后将其反映回来。构建上下文的机制——所有这些我都称为策略。

What is an agent? By the way, I think it's worth getting on the same page. Everyone has—I'm sure your audience knows very well about agents, but having a shared definition is important. I think about an agent as an LM call that is wrapped in machinery that's used to construct context. It's really a big context construction machine, and also it provides a way of executing actions. So part of the context is here are the things I can do, and the LM can say please go execute this tool or this action, and the agent is responsible for actually taking that action and then reflecting it back. The machinery for constructing that context—all of that I call policy.

那么策略中包含什么？可能是你如何组装实际的 LLM 调用。你是取历史中的最后 10 条消息，还是取最后 100 条？后者会更昂贵，但提供更多信息。或者你取最后 10 条消息，再加上前 90 条的摘要，这就是我们考虑的压缩方式，等等。这些都是静态的策略决策，为 OpenClaw、Pi 或 Claude Code 定义，如果你看它们的源代码的话。所以这就是智能体的策略：它能使用的工具、它拥有的技能、它如何将它们包含在上下文中、它如何构建上下文、关于实际智能体代码的任何东西，这正是 Exo 要真正实现完全递归自我改进的目标。不仅仅是某些你可以插入额外技能的点。它已经改变了技能为你工作服务的机制本身。

And so what goes into policy? It could be how you assemble the actual LLM call. Do you take the last 10 messages in your history or do you take the last 100? That's going to be more expensive but provide more information. Or do you take the last 10 messages and then a summary of the previous 90, which is how we think about compaction, etc. These are all policy decisions that are static, that are defined for OpenClaw or for Pi or for Claude Code if you look at their source code. And so that is the kind of policy of what an agent is: the tools it can use, the skills it has, how it includes them in its context, how it constructs context, anything about the actual agent's code, which is what Exo sets out to actually make fully recursively self-improving. It's not just certain points where you can insert additional skills. It has changed the very machinery of what skills are for your job.

是的。以及构成它的策略。我正想说——如果我们一直在屏幕共享，我们可能会用一些图表。现在可能是时候调出一个小的架构图了。

Yeah. And the policies that make it up. I was just wanted to—if actually we should have been screen sharing, we might have used some charts. This might be appropriate time to pull up a little architecture diagram.

完全同意。让我把它调出来。这样讲起来更容易。所以在这里我们可以看到——这又来自我关于自主系统设计原理的讲座，那真的是对 OpenClaw 的深入探讨，因为它出现的时间，你知道，在我开始研究 Exo 之前大约一两个月。但你可以在这个架构中看到，OpenClaw 的核心层是这种网关控制器。底层有实际的上下文组装，顶层有连接器，这是你与它交互的方式。我在这里用红色标出了插件部分。这些地方使其可定制，比如说针对你的特定任务。如果你想以不同的方式管理记忆，比如说你在做某种开发，需要查看一大堆不同的文档，你可能希望在记忆中存储多个项目的文档，但你可能想对它们运行 RAG 来获取最相关的部分包含在上下文中。所以这个记忆插件允许你说，这是存储和索引记忆的不同方式。很好。人类过来设置它。或者有工具，你可以说，我想给我的 OpenClaw 添加一个额外的工具，或者技能。还有像 ClawHub 这样的网站，列出了你可以安装的一堆工具或技能。这仍然是人类过来修改，你可以过来说，请为我安装这个工具。但我们试图做出的转变是，所有其他不是红色的东西——所有连接的箭头、所有组件——我们认为所有这些都需要由智能体来改进，尤其是随着智能体不断变好，因为随着它们不断变好，这是苦涩的教训。你不想过度专业化，因为你不想让人类决定所有这些架构细节。随着模型变得更好，它知道如何以对给定任务最优的方式构建智能体。所以这就是转变。如果我把 Exo 的架构放在旁边，我会说我会在这里的所有组件周围画上红线，说它们都可以由智能体自身改变。

Totally. Let me actually bring that up. It'll be easier to talk through. So just in here we can see—and this is again from my lecture on principles of autonomous system design, which was really a deep dive on OpenClaw because it came out, you know, a couple months—a month or so before I started working on Exo. But you can see in this architecture the core layer of what OpenClaw is is this kind of gateway controller. There's a bottom layer that has the actual context assembly, and there's a top layer that has connectors, which is how you interact with it. And I've marked here in red the parts that are plugins. There are places that make this customizable, let's say for your particular task. If you want to manage memory in a different way, let's say that you're working on something that is—you're doing some sort of development that's looking at a whole bunch of sets of different docs, you might want in your memory the docs for a bunch of different projects, but you probably might want to run RAG over them to fetch the most relevant ones to include in the context. And so this memory plugin allows you to say here's a different way of storing and indexing your memories. Great. A human comes along and sets that. Or there's tools, and you can say here's an additional tool I want to give to my OpenClaw, or skills. And there's all of the like ClawHub sites that list out a bunch of tools or skills that you can install. This is all still a human coming in and modifying, and you can come and say please install this tool for me. But the shift that we're trying to make is all of the other things that are not red here—all of the connective arrows, all of the components—we believe all of that needs to be improvable by the agent, especially as the agents keep getting better, because as they keep getting better, it's this bitter lesson. You don't want to over-specialize because you don't want the human kind of deciding all these architecture bits. As the model gets better, it knows how to architect the agent in a way that's most optimal for the given task. So that's kind of the shift. If I were to put Exo's architecture next to this, I'd say I'd put red lines around all components here and say they are all changeable by the agent itself.

是的，这是它最极端的版本。你想让我谈的另一个问题是什么？

Yes, this is the most extreme version of what this does. What was the other question you wanted me to talk about?

你想要显式切换还是隐式切换，基本上就是这个问题，对吧？隐式切换就像最信任 AGI 的时刻，让它自己解决一切。而显式搜索是给那些不信任机器能自己解决问题的人准备的。

Do you want an explicit switch or an implicit switch is basically the question, right? Like implicit switch is the most like trusty AGI to figure everything out moment. And the explicit search is for people who don't trust machines to figure things out.

自己解决问题。

To figure things out.

我要说——然后我会去讨论另一个架构。但我确实想在它还在脑海中时谈谈这个。我只想指出，当你有一个外部独立的智能体修改内部智能体时，你仍然在信任机器。仍然不是你做出改变，对吧？你可能在帮助引导它，但你仍然必须对做出改变的机器有同样的信任。问题是，你是有一个外部系统来检查内部系统，还是让运行中的系统自己检查自己？当你把两层合并在一起时，酷的地方在于，同一个系统既决定做出改变，也决定运行什么，还决定检查什么。所以你的系统本身可以尝试一些事情，看看它做得如何，它自己的内部表现如何，并在运行时对自己做出改变。所以你可以说——我可以给你一个很好的例子。我们让 Exo 运行玩 Pokémon，在运行过程中，系统自己决定尝试检查游戏的 RAM，然后去映射 RAM。过去人们手动逆向工程过这个。他们弄清楚了内存映射中哪些组件在游戏中做不同的事情。所以在内存中有某些地方存储世界中的位置、当前活跃的 Pokémon、你是否在战斗中——字面上就是内存代码中的布尔值。

I will say—and then I'll go to discuss the other architecture. But I do want to touch on this now while it's still top of mind. I'll just point out you are still trusting a machine when you have an outer separate agent modifying the inner agent. It's still not you making the changes, right? You're maybe helping direct it, but you still have to have the same trust in the machine that's making the changes. The question is, do you have an external system that inspects an internal system, or do you let the running system itself inspect itself? And the cool thing when you merge the two layers together is that the same system that is deciding to make changes is also deciding what to run and also deciding what to inspect. And so your system itself can try things and look at how it does, how its own internals perform, and make changes to itself as it runs. So you could say—and I can give you a really good example. We've had Exo running playing Pokémon, and while it's running, the system itself decided to try inspecting the RAM of the game, and then went and mapped the RAM. And people in the past have reverse-engineered this manually. They figured out what components in the memory map do different things in the game. So there's like in the memory there are certain places where you store the positions in the world, the Pokémon that's currently active, are you in a battle or not—literally booleans in the code in the memory.

而且这个智能体能够修改它自己与游戏的集成方式，并把这一点反馈到系统消息中，以便在推进过程中更好地为决策提供信息。外层循环则必须考虑这一点，并可能尝试一个设计、告诉它、启动它、观察效果、再反思。如果系统本身在进化，当它做出改变时，它可以检查事物，并利用这种检查——运行时检查——来指导其设计过程。所以我认为这是一种更强大、更充分表达自我改进的方式，比外层系统更胜一筹。

And the agent was able to modify its own integration with the game and feed this into the system message to better inform its decision-making as it progresses. An outer loop would have to think about that and potentially try a design, tell it, launch it, see how it does, reflect back. If the system itself is evolving, as it makes changes, it can inspect things and use that inspection, runtime inspection, to inform its design process. So I think it's a more powerful way, a more fully expressive way of doing self-improvement than an outer system.

嗯，有道理。

Yeah, fair enough.

好的，现在也许我可以谈谈 Exo 的 harness 架构，如果这有用的话。

Okay, now maybe let me talk about the Exo harness architecture, if that's useful.

好，我们开始吧。

Yeah, let's do it.

我们在这个播客里很喜欢好的架构图。通常我是那个在草稿纸上画图的人。所以这实际上省了我不少功夫，顺便说一句。

We love a good architecture diagram on this pod. Usually I'm the person drawing it on a scratch pad. So this actually saved me a bunch of work, by the way.

所以你知道，为了提供背景，我想我之前没提过。我是伯克利的博士生，导师是 Sylvia Nasami。我和 Scott Shanker 以及 Yan Stoka 合作，我完全是系统背景出身。我在 ChatGPT 真正起飞之前就开始读博了，当时我是一名核心网络方向的人。所以我的工作是在核心系统领域，为 SDN 控制器设计更广泛的网络架构，也就是决定你的数据通过互联网走哪条路径。然后我还做网络的正式验证，我的学术脉络一直是非常深入地思考系统架构、权衡和设计。我不是 ML 背景的人往下进入智能体领域，而是系统背景的人往上走。

So you know, for context, I don't think I mentioned this earlier. I'm a PhD at Berkeley advised by Sylvia Nasami. I work with Scott Shanker and Yan Stoka, and I'm coming strictly from systems. I started my PhD before ChatGPT really took off, and I was a core networking person. So I've done my work in core systems, designing wider network architectures for SDN controllers, just how you decide what path your data takes through the internet. And then I do formal verification for networks, and I've come from a lineage of really thinking about system architectures and trade-offs and designs. I'm not an ML person kind of coming down into agents. I'm a systems person coming up.

嗯，我认为 AI 工程的美妙之处在于，系统背景的人和模型背景的人都有空间。我会说伯克利倾向于系统优先于模型，或者说系统编排模型的人，显然因为它是复合 AI 系统的发源地。

Yeah. Well, I think the beauty about AI engineering is there's room for both systems people and model people. I would say Berkeley tends to be the systems over models, or systems orchestrating models people, obviously because it's the school of compound AI systems.

复合 AI 系统，是的。

Compound AI systems, yeah.

所以我确实看到双方的观点。我确实认为存在一些人们没有解决的紧张关系，比如大型模型研究者总是说，哦，下一个大模型会把一切冲走，会把 harness 冲走。而显然我们这边在构建 harness。两者可能都是对的。

So I do see both sides. I do think that there is some tension that people don't address with regards to how large model researchers always say things like, oh, the next big model will wash things away, will wash the harness away. And obviously over here we're building harnesses. Both can be true.

我同意你的看法。但我的赌注是：人们一直试图让模型做符合他们目标的事情，而对齐是一个未解决的问题。我们一直试图用基于人类反馈的强化学习（RLHF）来让这些模型做正确的事。在 harness 空间，我们实际上有机会通过我们设计的系统架构来强制某些属性，这与试图押注于模型、LLM、权重包含我们想要的规则完全不同。例如，如果你永远不想删除你的历史记录，你必须在 harness 的架构中强制执行，而不是仅仅在上下文中要求，拜托 LLM，永远不要做任何会删除我历史记录的事情，因为我们不断看到有办法欺骗模型。所以我认为架构在这一点上很重要，并且对系统背景的人来说真正闪耀。

I agree with you. My bet is this though: people keep trying to get models to do things that align with their goals, and alignment is an unsolved problem. We keep trying to use RLHF to align these models to do the right thing. In harness space, we actually have an opportunity to enforce certain properties by the architecture of the system that we design, which is totally different than trying to bet on the model, the LLM, the weights containing the rules that we want. For example, if you never want to delete your history, you have to enforce that in the architecture of your harness rather than just asking in context, please LLM, don't ever do anything that'll delete my history, because we keep seeing that there are ways to trick the model. So that's the place that I think architecture holds and really shines for a systems person.

好的。那么让我稍微谈谈 Exo 的架构。这个项目 Exo 实际上是一个自我改进的智能体，但这是由这个有主见的、非常仔细地划分智能体的 harness 架构所实现的。所以我想把这与我们今天对智能体的看法做个类比。如果我从这里下来，当你想到 Claude Code 时，Claude Code 既是一个智能体。人们通俗地认为它是一个智能体。它也是一个 harness，它们是一起发布的，你把它放到一个环境中，它就能工作。所以对我来说一个常见的工作流程是，我启动一个虚拟机，我进去，我启动 Claude，然后我在里面做一个项目。我克隆一个仓库。顺便说一句，我必须用我的 GitHub 凭据登录，这样它才能去为我推送东西，然后我在这个隔离的空间里工作。我相对信任它，然后我危险地跳过权限，这样在这个虚拟机里，顺便说一句，我可以接受这里。哦，这有点冒险，因为我实际上已经登录了。我必须有我的密钥在那里。我当然有我的 GitHub 凭据在那里，但好吧，至少它不会毁了我的电脑，因为它运行在某个地方的虚拟机里。

Okay. So let me talk through the Exo architecture a little bit. This project Exo is really a self-improving agent, but that's enabled by this architecture for the harness that's opinionated and very carefully partitions agents. And so I just want to draw the parallel to how we think about agents today. If I come down here, when you think of Claude Code, Claude Code is both an agent. People colloquially think of it as an agent. It's also a harness, and they're kind of shipped together, and you drop it into an environment where it works. And so a common workflow for me is I spin up a VM, I go in there, I start Claude, and then I work on a project in there. I clone a repo. I have to log in with my GitHub credentials, by the way, so that it can go and push things for me, and then I'm working in this isolated space. I trust it relatively, and then I do dangerously skip permissions so that in this VM, and by the way, I can accept here. Oh, this is kind of risky because I've actually logged in. I have to have my keys there. I have my certainly my GitHub credentials there, but okay, fine, at least it's not going to destroy my computer because it's running in a VM somewhere.

我们提出的架构是将智能体的概念分解为三个不同的重要层。我首先会更一般地展示它们，然后我会回到这里的详细设计。它将智能体分解为执行器、Exo harness 和沙箱。这些层都有不同的属性。这非常重要。所以我们认为 harness，这里的 Exo harness，需要保留所有状态，即我们希望保护的最小事物集合，免受智能体的影响。这是智能体使用的东西，但我们希望保护它。而执行器包含所有策略。我们之前讨论过策略。策略包括你如何组装你的上下文，你的提示是什么，你如何做压缩，你的技能是什么，你的工具是什么，任何关于实际智能体如何决定它将做什么的事情。对吧？所以这样我们就有了一个非常好的划分。执行器是完全无状态的。所以它是一个完全无状态的进程，而 Exo harness 包含具有对话历史、可能需要的任何秘密（如 API 密钥）、工件或环境快照的层。

The architecture that we're proposing is one that decomposes the idea of an agent into three distinct important layers. And I'm going to show them first more generally, and then I'll come back to the detailed design here. It decomposes an agent into an executor, an Exo harness, and a sandbox. And these layers all have different properties. This is very important. So we think of the harness, the Exo harness down here, as needing to keep all state, the minimal set of things that we want to have protected from the agent. It's stuff that the agent uses, but that we want to have protected. And the executor contains all of the policy. And we talked about policy earlier. Policy entails how you assemble your context, what are your prompts, how do you do compaction, what are your skills, what are your tools, anything about how the actual agent is deciding what it's going to do. Right? So in this way we have a really nice split. The executor is fully stateless. So it's a fully stateless process, and the Exo harness contains the layer that has the conversation history, any secrets that might be needed such as API keys, artifacts or snapshots of an environment.

最后，我们有一个沙箱层，这是事情实际发生的环境。这不是超自然的想法，因为今天，Claude Code 运行在与它正在编辑的代码相同的环境中。你把它放进去，Claude Code 作为你机器上的一个进程运行，编辑你机器上的其他文件。或者你把 Claude Code 放到一个虚拟机里，它在虚拟机里运行并编辑该虚拟机上的文件。我们把它分开，实际的操作，比如你想去，智能体想去运行某种 bash 命令，在沙箱中执行，这与实际策略进程不同，策略进程可以在任何其他地方运行。但这样好的划分给你带来的是，它给你一个隔离的执行环境。它给你受保护的状态，然后它有一个非常明确的无状态层，适合自我进化。所以执行器可以以一种你不会丢失任何历史的方式提出对自己的更改。你不会泄露秘密，因为它们不暴露给 LLM 本身。我们的 Exo harness 提供了快照机制。这真正好的地方在于，你可以对沙箱环境进行快照，而智能体，策略本身，可以在运行时，在它运行的时候，选择尝试做一些更改并回滚自己。

And finally, we have a sandbox layer, which is the actual environment where things are happening, where things are taking place. This is not supernatural to think about because today, Claude Code runs in the same environment as the code itself that it's editing. You drop it in, and Claude Code is running as a process on your machine, editing other files on your machine. Or you drop Claude Code into a VM where it runs in a VM and is editing files on that VM. We split that out where the actual actions, like you want to go, the agent wants to go run a bash command of some sort, gets executed in a sandbox which is distinct from the actual policy process that can be running anywhere else. But what this gives you, this nice split, is it gives you an isolated execution environment down here. It gives you protected state, and then it has a very explicit stateless layer that's safe for self-evolution. So the executor can propose changes to itself in a way that you will not lose any history. You won't leak secrets because they're not exposed to the LLM itself. And our Exo harness provides a mechanism for snapshots. And what this is really nice for is you can snapshot the sandbox environment, and the agent, the policy itself, can choose at runtime, as it's running, to try to make some changes and roll itself back.

这就是 Exo 背后的基础架构。我想指出这些层能给我们带来什么。所以，一个智能体——我认为这是理解 Exo 和 Exo 框架架构最难的部分——是被分解的。它被拆分成这三层。它是在 Exo 框架中存储的对话历史、状态，加上正在运行的策略（即执行器），以及它运行所在的沙箱。这三者合在一起，定义了今天我们所说的智能体。希望这说得通。

So this is the fundamental architecture behind Exo. And I want to point out what these layers give us. So an agent now—and this is the hardest piece, I think, in understanding Exo and the Exo harness architecture—is decomposed. It's split across these three layers. It is the conversation history that's stored in the Exo harness, the state plus the policy that's running, which is an executive, plus a sandbox that it's running on. And those together define an agent as we think about them today. Hopefully that makes sense.

我喜欢这个分解，非常清晰。我对这里的一些要点有疑问，但我想先了解完整的顶层结构，然后再深入细节。

I like this breakdown, it's very clear. I have questions about some of the bullet points here, but I want to get the full top level first before we go into details.

是的。所以我再讲一张幻灯片，让这一切完全具体化，然后我们再深入所有细节。再说一次，这是我对 Exo 所依赖架构的看法。但在这个架构中，为了让它真正具体，你有沙箱，有一个完全有状态的框架来持有你的状态，还有上面运行着的执行器。在这里你可以看到策略、所有的压缩工具、技能、LM 调用等等。所以 Exo 所采取的步骤——真正让 Exo 成为自我改进智能体的步骤——是它会在自己的沙箱中挂载执行器自身的代码。结果，LM 能做的决策的一部分是，它可以说，嘿，去在运行时编辑自己框架的某个方面。在 Exo 框架中，我们有一个特殊的守护进程，允许执行器在运行时、在步骤中途被重建，并且还提供某种浸泡过程：重建后，我们尝试启动执行器，让它走一步，如果它意外把自己搞坏了，它会自动回滚到之前的状态。这些就是所需的最小组件集，因为现在你有一个执行器，它能看到自己的代码，能编辑自己的代码，能请求重建自己的代码并在运行中交换。最终，它受到 Exo 框架的保护，会将其回滚。而且，这个机制还能构建新工具、编写新技能、改变上下文组装方式的任何方面、调整适配器等等。所以，这是让 Exo 能够完全递归地自我改进的最后一步。

Yeah. So I'll go one more slide to kind of just make this fully concrete, and then we'll go into all the details. So again, this is my view of the architecture that enables Exo. But in this architecture, again, to make this really concrete, you have sandboxes, you have a harness that holds on to your state that's fully stateful, and you have the executive up here that runs. And here you can see policies, all the compaction tools, skills, LM call, etc. So the step that Exo takes—what really makes Exo a self-improving agent—is it goes and it will mount in its sandbox its own code for the executive itself. And now, as a result, the part of the decision-making that the LM can make is it can say, hey, go edit some aspect of its own harness at runtime. And we have in the Exo harness a special guardian kind of process that will allow the executive to be rebuilt at runtime mid-step, and also provides some sort of soaking process where after being rebuilt, we try to bring up the executive, let it proceed one step, and if it breaks itself off accidentally, it'll get rolled back to the previous state automatically. And those are the minimal set of components that are needed, because now you have an executor that can see its own code. It can edit its own code. It can ask to rebuild its own code and swap mid-run. And as a result, finally, it's protected by an Exo harness that will roll it back. And also, this mechanism can build new tools, write new skills, change anything about how the context is assembled, adjust adapters, etc., etc. So that is the final step that allows Exo to be kind of fully recursively self-improving.

这也意味着提议的更改可以并行化，因为在执行器和框架整体的提交中具有原子性，关注点分离得很好。如果你想回到——是的，我首先想到的是最后一点：可转移性，用于传送。这有多重要？你知道，传送经典上，我认为人们想本地运行东西，然后他们会说，我想合上笔记本电脑，我想把它移到云端。这大概是人们传送代码或智能体状态的唯一原因。这还指其他什么吗？

It also means that proposed changes can be parallelizable because there's atomicity in the commit of the changes in the executive and the harness overall, a good separation of concerns. If you want to go back—yeah, the first thing I land on is this last point: transferable for teleportation. How important is that? You know, teleportation classically, I think people want to run things locally and then they're like, I want to close my laptop, I want to move it to the cloud. That's kind of the only reason that people do teleportation of code or agent state. Is there something else that this refers to?

是的，这是个很好的观点。所以在一个你运行单个智能体处理单个任务的世界里，几乎没有必要把你的东西传送走。你要么在工作时本地运行，要么，顺便说一句，如果你希望它始终保持开启，你一开始就必须远程运行。比如，它必须放在某个服务器上，这样当你合上笔记本电脑时，它还在运行。所以我明白你的意思。这里的好处是，如果你想扩展到并行处理一堆不同的任务呢？你有一堆不同的对话。这是一个非常真实的需求。这不是你和我管理电子邮件所需，但可能是公司所需。假设一家公司想为每个用户的使用日志启动一个智能体中的对话，或一个专用智能体。用户进来，使用你的应用，你有一些库去记录到数据库。有一连串事件进来，你想让智能体在事件发生时对其进行某种推理。那么，你可能想为每个对话唤醒一个专用的沙箱环境，顺便说一句，这在 Exo 框架架构中完全可行。如果你要为 100 个用户做这件事，很好。它会适合你的一台机器，最多同时运行 100 个容器。如果你想为 5 万个用户做这件事，你就会开始耗尽机器上的空间。所以，你可能会有足够的策略进程，因为你一次只需要几个处于唤醒状态，但你会有很多不同的客户在不同时间被唤醒，并出现不同的专用沙箱。所以这种传送的一个好处是，一旦你开始耗尽机器上运行沙箱容器的空间，你就可以开始把其中一些移到云端。要么在 Daytona 中启动新的，要么把现有的移到 Daytona 或其他提供商。你可能想访问一些本地不可用的资源。所以这就是我看到的传送的好处。

Yeah, this is a great point. So in a world where you're running a single agent working on a single task, there is very little need for teleporting your stuff away. You either run it locally while you're working, or, by the way, if you want it to just be always on, you have to run it remote to begin with. Like, it has to be on a server somewhere so that when you shut your laptop, it's still going. So I get your point. The benefit here is, what if you want to scale up to working on a bunch of different tasks in parallel? You have a bunch of different conversations. This is a very real need. It's not a need for you and I managing our email, but it could be a need for a company. Let's say that a company is wanting to spin up a conversation in an agent or a dedicated agent to each user's usage logs. The user comes in, uses your app, you have some library that goes and logs to a database. There's a stream of events coming in, and there's some kind of reasoning you want an agent to do over that stream as it happens. Well, you might want to wake up a dedicated sandbox environment for each of those conversations, which, by the way, is fully doable in the Exo harness architecture. If you're trying to do this for 100 users, great. It's going to fit on your one machine, up to 100 containers running at once. If you want to do this for 50,000 users, you're going to start running out of space on your machine. So, you might have enough policy processes because you only need a couple to be awake at a time, but you're going to have a lot of different customers being woken up at different times and different dedicated sandboxes coming up. So a benefit of this teleportation is, once you start running out of space for running sandbox containers on your machine, you can start moving some of them off to the cloud. Either starting new ones up in Daytona or moving existing ones up to Daytona or some other provider. You might want to give access to some sort of resources that aren't available locally. So that's the benefit I see of teleportation.

为什么是 Daytona？你只是认识他们。对我来说，实际上——我来自我之前在 Harbor（Terminal Bench 的制造商）的一些评估，他们当时已经集成了 Daytona。我们实际上还集成了其他一些提供商。E2B，我用 actually.dev 来处理我的一些东西，我会把东西移过去，所以我只是把它作为一个例子。

Why Daytona? You just know them. For me, it's actually—I'm coming from some of my previous eval on Harbor, the makers of Terminal Bench, and they had Daytona just integrated. We actually have integrations for a number of other providers. E2B, I use actually.dev for some of my stuff where I move it off, so I only give it as an example.

是的。嗯，不，你知道，我们在播客里请过 Daytona 和 E2B。但我只是觉得，Harbor 团队的这个单一推荐现在推动了 Daytona 的大部分增长，这很有趣。显然，Daytona 有很好的销售，我应该说明，Daytona 在 Harbor 之外还做了很多其他的市场推广工作，但就像，是的，仅仅在播客上，就有很多人受到那个偏好的影响，很高兴看到你实际上可以在那里奖励好的体验。

Yeah. Well, no, you know, we've had both Daytona and E2B on the podcast. But I just think this single recommendation by the Harbor guys is driving most of Daytona's growth right now, which is very funny. Obviously, Daytona has good sales, and I should be clear that Daytona has done a lot of other GTM work outside of just Harbor, but like, yes, just on the pod itself, the number of people that are very influenced by that preference is nice to see that you can actually reward good experiences there.

好的，所以我想继续讨论其他部分。我们能回到架构图吗？我认为这里有一些东西可能值得深入探讨。我好奇的事情，例如，子智能体住在哪里？对，我好奇的事情是，你是否需要一个路由器来做 DSPy 类型的递归优化，你知道，提示词和工具调用以及 LM 优化，这确实有帮助。然后，是的，实际上我经常想到密钥存储，大多数智能体设置都没有，而你确实需要这个密钥存储。所以我只是指出这里让我印象深刻的东西。我们处理哪个都可以，看哪个让你有感觉。我想提醒你，我们这里在讨论两件事。有 Exo，构建在这之上的智能体，这是通过将执行器代码挂载到沙箱中完成的。还有我描述的 Exo 框架，这个架构。

Okay, so I want to keep going on other parts. Can we go back to the architecture diagram? I think there are some things here that can be maybe dived into. Things I've wondered, for example, are where do sub-agents live? Right, the things I've wondered are, do you need a router to do the DSPy type of recursive optimization, you know, prompt and tool call and LM optimization, which does help. And then, yes, actually I have often thought about secret store, which most agent setups do not have, and you really do need this secret store. So I'm just calling out things that stand out to me here. We tackle whichever gets you going. And I want to remind you here that we're kind of—there's two things we're talking about. There's Exo, the agent built over top of this, and that's done by kind of mounting the executive code in a sandbox. And there's the Exo harness here as I'm describing it, this architecture.

你问的一些问题涉及我们如何决定 exo 外骨骼的组件放在哪里，我现在会讲一下。但 exo 是构建在这个架构之上的，它完全递归地自我改进，而这个架构是为了实现这一点。

And some of the questions you're asking me about are how we decided where to put components of the exo harness, which I will talk through now. But exo is a thing built over top of this that's fully recursively self-improving, whereas this is an architecture to enable that.

嗯。

Yeah.

看这里，关于如何生成子智能体之类的决策，有点像执行器中的策略决策。所以你有代码可以去生成子智能体，这是一种决策。是的。什么时候生成它们？它们运行时有什么工具？有什么访问权限？所有这些在我看来都在执行器中，并在运行时使用。像今天构建的简单 exo 并不原生支持子智能体，但绝对可以用同样的模式在代码中实现。

So looking here, the decisions on like how do I want to spawn out sub agents, it's kind of a policy decision in the executive. So you have code written that can go and spawn sub agents, and that is a kind of a decision that happens. Yeah. When do you spawn them? When they run, what tools do they have? What access do they have? All of that to me is up in the executive and is used at runtime. None like the simple exo as it's built today doesn't natively come with sub agents, but absolutely can be implemented in the same pattern just in code.

嗯。

Yeah.

真正理解这个执行器的方式是，它是一块代码，这些模块实际上是我在概念上布局那块代码中包含哪些组件。但如何编写代码取决于你。但你有状态，例如，像记忆。你可能会在这里看到记忆。你选择记录或注入记忆的方式存在于执行器中，但实际的记忆本身会作为该对话或该智能体的工件进入 exo 外骨骼。所以有点像，你做事的方式在执行器中定义。运行时的实际状态存在于 exo 外骨骼中。

Really the way to think about this executive is it's a block of code, and these modules here are really me laying out conceptually what components go in that block of code. But it's up to you how you write that code. But state that you have, for example, like memory. You might see memory here. The way you choose to record or inject memory lives in the executor, but the actual memories themselves go down in the exo harness as artifacts for that conversation or for that agent. And so it's kind of like the how you do things is defined in the executive. The actual state at runtime lives in the exo harness.

是的。你基本上必须把算力和存储分开，才能让它可迁移、可恢复，对吧？人们经常把这些东西混为一谈。

Yeah. You have to separate compute and storage basically in order to make it teleportable to resumable everything, right? Like people sloppily comingle these things a lot.

然后我们可以提到密钥存储。密钥存储非常棒。我们希望它存在于 exo 外骨骼中，这样它就不会直接暴露给大语言模型。这再次说明，如果你考虑放入一个大语言模型，假设你正在构建一个外骨骼项目，即使为了让那个外骨骼能在你的环境中运行，你可能需要一个 API 密钥，如果你的智能体与你的 API 密钥在同一个环境中运行，那现在就可以被完全窃取，完全可读。因此，将密钥存储保留在宿主进程的 exo 外骨骼中，与操作发生的沙箱分开，是非常有帮助、非常方便，实际上也非常重要的。这样，密钥就被注入到执行器中，而不会实际暴露在工具可以看到正在使用什么的空间中，也就是容器中。

Then we can mention the secret store. The secret store is really great. We want it to live in the exo harness so that it's not exposed directly to the LLM. This is again if you think about dropping an LLM, let's say you're working on a project building a harness, even well for that harness to be able to run in your environment, you probably need an API key, and if your agent is running in the same environment as your API key, that is now fully kind of exfiltratable, like fully readable. And so it's very helpful and very handy and actually quite important to separate out a secret store that stays in the exo harness on the host process from the sandbox in which operations are taking place. And so that secret is kind of injected in the executor without actually exposing it in the space where the tools can see what is being used, which is in the container.

是的。而且还要有访问日志，以防出错后需要做一些调试历史记录。

Yeah. And also like an access log in case you need to sort of do some history of debugging after something goes wrong.

是的。是的。没错。而且我觉得，即使只是密钥被访问这个事实，如果访问模式异常，也应该被监控。如果我非常常规的任务不知怎么地请求我的 AWS 密钥，那肯定有问题，即使我有它在那里，你知道。而且我经常希望在这种监控方面有更多工作，通常你只会把它 tail 出来管道到 Slack 频道，人们只是盯着它。但那听起来很糟糕。

Yeah. Yeah. Exactly. Also I guess even the very fact of secrets being accessed, if there's an unusual pattern of access, that should be monitored as well. If my very routine task is somehow requesting my AWS keys, like something's wrong, even if I have it there, you know. And I often wish that there was more work on monitoring of that kind of stuff, where you typically would just have like it tail pipes out to like a Slack channel and people just keep an eye on it. But that sounds terrible.

是的。是的。是的。是的。是的。我觉得现在有很多事情正在发生，这个领域太新了，这些东西太强大了，我们只会尽我们所能开始从这些系统中提取价值。我们只会做最简单、现在有效的事情，但这不一定是我们要定居的地方，我想。

Yeah. Yeah. Yeah. Yeah. Yeah. I think there's a lot of things happening right now that are just the space is so new and these things are so powerful that we just are going to do this whatever we can just to start extracting value from these systems. We're just going to do whatever is easiest and works right now, but it is not necessarily the place we're going to settle, I think.

是的。嗯，我的意思是，你有这个余地，因为你正在设计 Exo，我想，从第一天起就把推荐的最佳实践放进去，然后每个得到你外骨骼的人都能受益。

Yeah. Well, I mean, you have the leeway because you're designing Exo to, I guess, put the recommended best practices in there from day one, and then everyone who gets your harness gets the benefit.

是的。嗯。

Yes. Yeah.

如果我们想深入探讨，我还有这个的更多变体。一个非常快的问题，我不期望有太多回应。对实时智能体有什么想法吗？那会改变什么吗？就像语音智能体或必须相对实时响应的事物。

I have further variants of this if we want to dive in there. A very quick one which I'm not expecting a ton of responses for. Any thoughts on real time agents? Does that change anything at all? Just like voice agents or like things that have to respond in like relatively real time.

如果我可以简要分享一下，如果人们想去试试这个，我想指出他们可以去哪里。

If I can briefly just share if people want to go try this, I want to point out where they can go.

是的，你知道，我们这里有 GitHub，地址是 github.com/exoharness/exo，顶部链接了很多文档。你可以了解 exo 的架构以及它是如何工作的，还有一些教程。但回到 GitHub，有一个快速入门，只是一个单行安装脚本，那会让你开始并运行起来，我很快会展示那是什么样子。但我要指出，我们还提供了 Exo 自带的一些预构建适配器。所以就像我向你展示的，你知道，熟悉 OpenClaw 的人都知道它有适配器，这些适配器是它与外部世界交互和接收消息的方式。我们为 EXO 提供了 Discord 适配器、IRC 适配器和 WhatsApp 适配器。你可以很容易地添加自己的。而这一切都引出了你问题的答案。我们实际上为 Exo 的 Discord 适配器构建了语音模式。所以你可以让 Exo 加入 Discord 语音聊天，和你聊天，但它还不是你所说的那种交互式模型，它有点像……

Yeah, you know, we have our GitHub here that is at github.com/exoharness/exo, and there is a bunch of docs here linked at the top. You can kind of learn about the architecture of exo and how it works and some tutorials. But coming back over to the GitHub, there's a quick start of just a one-line install script, and that'll get you going and get you running, and I can show what that looks like soon. But I'll point out we also have Exo comes with some pre-built adapters. So the same way that I showed you, you know, people familiar with OpenClaw know that it has adapters that are really the way it interacts with and can receive messages from the outside world. We ship EXO with an adapter for Discord, an adapter for IRC, and for WhatsApp. You can very easily add your own. And this all leads into the answer to your question. We actually went and built voice mode into Exo to the Discord adapter. So you can have Exo kind of join and chat with you in Discord in a voice chat, but it's still not an interactive model the way that you're talking about yet, where it's kind of...

是的。这是一个流水线级联的东西。

Yeah. It's a pipeline cascade thing.

是的。是的。这是一个流水线的东西。所以当我思考这需要如何改变时，我认为可能需要在智能体方面有更好的可中断工作的概念。这是另一件我注意到让我对 open claw 架构感到困扰的事情。尽管它很棒，但一旦智能体开始在一个线程中处理某件事，那个线程就无法中断。当某件事在后台工作时，如果你试图 ping 它，它就不会响应。你甚至不知道它在做什么，这真的很令人沮丧。所以你必须绕过这个问题的方法是，你去开始一个不同的对话。你说：“嘿，你知道那个线程里发生了什么吗？为什么它不回答？”

Yeah. Yeah. It's a pipeline thing. So as I think about how this needs to change, I think there might need to be some better notion of like interruptible work for agents on their side. This is another thing that kind of really I noticed has bothered me with the open claw architecture. As wonderful as it is, once an agent kind of goes and starts working on a thing in a thread, that thread is not interruptible. As a thing is off working, if you try to ping it, it just won't respond. You don't even know what it's doing, which is really frustrating. So the way you have to get around this is you go and you start a different conversation. You say, "Hey, do you know what's going on over in that other thread? Like why is it not answering?"

这并不完全正确。所以我们需要在智能体层重新发明那种交互式可中断工作的样子，这不同于我认为在模型层和这种交互式模型空间中正在进行的工作，但我想它会看起来更像一个系统操作系统的东西，就像当你在终端中工作时，你想启动某件事，你可能会把它放在后台，或者你打开 tmux，把它放在侧边的一个单独窗格中。我预计这将是一个架构决策，关于如何把任务放在后台，并在它们运行时将它们暴露给智能体。这可能就是它需要达到的程度。

Which is like not entirely correct. So the way that we're going to need to reinvent what that kind of interactive interruptible work looks like in the agent layer, which is separate from the work going on, I think, in the model layer and in this interactive model space, but I think will look much more like a systems OS thing, where the same way that when you're working in your terminal, you want to start something, you maybe put it in the background or you open tmux and you put it in a separate pane on the side. I expect this will be an architecture decision of how you put tasks in the background and expose them to the agent as they're running. That's the extent it might take.

我以为你会说发送信号，对吧？信号之类的。

I thought you were going to say you send signals, right? Signal or whatever.

是的，完全正确。不，就是这样。就像你可以把进程放到后台，完成后它会发送信号，你可以被唤醒。会有某种信号传递或发布/订阅总线，你启动一个进程，写入那个发布/订阅。对我来说，这就是这方面的系统架构思维。

Yeah, totally. No, exactly. So same way that you can background a process and when it's done it'll send some signal, you can be woken up. There'll be some sort of signal passing or some sort of pub/sub bus where you start a process, you write to that pub/sub. I think that's the architectural systems thinking for me on this.

好的，我觉得这些都说得通。那么另一个管理类问题：你们是否实现了 ACP，即 Zed 提出的那个统一许多编码智能体的协议？你了解它吗？你有什么看法或不同意见吗？

Okay, so I think that all makes sense. Then another kind of housekeeping question: did you implement ACP, the protocol from Zed that normalizes over a lot of coding agents? Do you know about it? Do you have any opinions or differences of opinion?

这是个好问题。实际上，我们还没走到那一步。我记得在 OpenClaw 架构中看到过它，作为一种允许在 OpenClaw 内生成其他编码智能体的方式。这确实是下周要做的很好的建议。

That's a great question. No, actually, we haven't gotten there yet. I remember seeing it in the OpenClaw architecture as a way of allowing spawning other coding agents within OpenClaw. That's actually a great suggestion for something to do next week.

是啊，把你的 clanker 扔过去。扔过去。

Yeah, throw your clanker at it. Throw it.

是的，我是说，我觉得每个人都在试图标准化。这是经典的系统设计问题。你有 10 个编码智能体。好吧，让我们做一个 API 来统治它们。所以 ACP 是当前的。你有另一个。Databricks 也有一个略有不同的。让我们先弄清楚它是什么。但还有普遍的不适感，任何通用协议总是最低公分母。那么，它真的比仅仅有一个 API 提供更多价值吗？这就是为什么 OpenClaw 采用 API 而不是说我们会与 10 个不同的智能体互操作，这让事情更简单，说实话。你不需要为所有东西都做模块。

Yeah, I mean, I think everyone's trying to normalize. This is a classic systems design thing. You have like 10 coding agents. Well, let's make the one API to rule them all. So ACP is the current one. You have a different one. Databricks has a slightly different one too. Let's just figure out what it is. But then there's also the general discomfort that any common protocol is always going to be lowest common denominator. So what right? Does it actually provide the value versus just having an API? That's why OpenClaw adopting an API instead of saying we will interop with 10 different agents makes it simpler, to be super honest. You don't have to have modules for everything.

不，有道理。我觉得这是我们将来会研究的。我们一直专注于首先架构需要什么样才能实现自我改进，其次构建那种自我改进的智能体部分。现在人们开始想用 Exo 做不同的事情，它已经在生产中运行了。Exo 框架及其上构建的智能体在 Brain Trust 生产中运行。这些部分正在加固。我觉得是时候考虑如何让其他人尽可能容易地集成。所以这是个很好的提醒。

No, that makes sense. I think it's something we'll look into. We've been really focused on first what the architecture needs to look like to enable self-improvement, and then second building out that kind of self-improving agent piece. And now that we have people starting to want to use Exo for different things, this is running in production. The Exo harness and agents built over top of it is running in production at Brain Trust. These pieces are hardening. I think it's time to think about how to make this as easy for others to integrate with as possible. So that's a great call out.

让我们来谈谈这个。再说一次，我认为去年我最喜欢的播客之一，是一位非常伟大的创始人和系统思考者，以及所有……

Let's bring that in. So again, one of my favorite podcasts of last year, I think, was a very great founder and systems thinker and all...

不可思议的思想家。

Incredible thinker.

他基本上做了什么？你能归功于马丁做了什么？恩科尔做了什么？然后也让我们谈谈在生产中看到了什么，你有什么故事。

What's he done basically? Can you attribute credit to like what did Martin do? What did Encore do? And then also let's talk a bit about what has been seen in production, whatever stories you have.

完全正确。是的，这个项目我认为非常独特，因为它有这些非常不同的人参与。恩科尔是一位不可思议的系统思考者，在 Brain Trust 的角色中看到了很多人们如何使用智能体，而且他也非常容易合作。马丁显然是一位出色的 VC，也是一位不可思议的系统思考者，但作为 VC 从不同的视角看待正在发生的各种推介和市场上的不同产品，显然也非常技术性。而我作为伯克利的研究员，处于不直接在生产路径上但处于研究前沿的事物中，尤其专注于进化系统和 AI 驱动的发现，以及如何改进事物的循环。循环在几个月前随着研究领域的一些大推文真正进入了讨论。我们从去年夏天就开始深入讨论这些循环，但它们并没有在 Twitter 上流行。

Totally. Yeah, this project I think is pretty unique because it has these different very different people coming in. Encore is an incredible systems thinker, sees a lot of how people are using agents out in his role at Brain Trust, and is just also excellent to work with. Martin, obviously fantastic VC, also an incredible systems thinker, but coming from a different perspective as a VC sitting and looking at these different pitches that are happening and different products that are out there, and obviously also deeply very technical. And you have me as a researcher at Berkeley. I'm in the milieu of the things that are not directly on the production path but are on the bleeding edge of research, and especially I've been focused on evolutionary systems and AI-driven discovery and loops on how you improve things. Loops really came into the discourse a couple months ago with some big tweets in the research space. We've been talking about these loops since last summer and really deeply, but they weren't trending on Twitter.

不，事情就是这样，对吧？但还有，我不知道你是否收到通知，但循环已死。我们现在只谈图。

No, that's how these things go, right? But also, I don't know if you got the memo, but loops are dead. Graphs is all we talk about now.

图是坏的。

Graphs are bad.

好的。是的，这是个帖子。要说明的是，这是个帖子。这只是影响者自嘲，每隔几个月你得循环一下。所以你有新东西可谈。

Okay. Yeah, this is a post. This is to be clear, this is a post. This is just influencers making fun of themselves for like, well, every few months you got to cycle it. So you got something new to talk about.

你知道图之后会流行什么吗？或者我很想得到点内幕。

Do you know what's coming after graphs or I'd love a tip off?

我不知道。Markdown 又成为你所需的一切了。我不知道。

I don't know. Markdown is all you need again. I don't know.

是的，我期待那一点。但回到我们有这三个参与者，这始于几个月前我做的关于自主系统原理的讲座，得到了社区很多参与。我喜欢看到人们的回应。马丁也来伯克利做了关于框架未来走向的演讲，我们在那里联系并见面交谈。同时他说，恩科尔在 Brain Trust 也在考虑这个，我们应该聚在一起谈谈。所以我们在一间会议室聚在一起，开始讨论这个架构需要什么样？你需要哪些属性？这真正始于对 Exo 框架更大的关注。你应该如何架构这些智能体以提供可扩展性和安全性？恩科尔首先尝试了分层架构，他又是位出色的系统思考者。当我们开始构建时，最初的三四周我对这个分层架构能让我们在自我改进方面做什么非常感兴趣。来自 AI 驱动的发现领域，我真的很想知道如果你把 AI 驱动的发现循环折叠到执行器本身会怎样，这得益于你有中间受保护的状态层和独立的受保护沙盒层。所以在三四周的时间里，我们三个人真正构建 Exo 框架或加固它，最初更多由恩科尔驱动，我们转向专注于自我改进，我的很多研究都在那个领域。所以我认为我的印记确实在那里。马丁，你知道，你之前说也许这只是 VC 在说，但马丁真的会写代码。马丁真的每天都在写代码。所以我们三个人一起工作非常有趣。如果你看提交记录，我们都在那里。所以我们的团队不只是摆样子，我相信你知道。但是的，这就是……

Yeah, I look forward to that. But to go back to kind of we have these three players, and so this started from I gave my kind of lecture on principles of autonomous systems back some months back, and it got a lot of engagement from the community. I love to see people's responses. Martin came and gave a talk also at Berkeley on the future of where harnesses are going, and we kind of linked up there and met up to talk. At the same time he said hey, Encore is thinking about this at Brain Trust, we should get together and talk. So we got together in a meeting room and just started talking about what does this architecture need to look like? What are the properties that you need? And really this started with a bigger focus on the Exo harness. How should you architect these agents to provide scalability and safety? And Encore took a first stab at the layered architecture, and again brilliant systems thinker. And as we started building that out, the first three or four weeks I got very interested in what this layered architecture will enable us to do with self-improvement. Coming from this space of AI-driven discovery, I was really wondering what if you collapse the AI-driven discovery loop into the executive itself, which is enabled by the fact that you have this protected layer of the state in the middle and a separate protected layer of the sandbox. So after spending three or four weeks on really the three of us building out the Exo harness or hardening it, originally kind of driven by Encore more, we shifted to focus on this self-improvement that a lot of my research has been in that space. So I think my imprints are really there. And Martin, you know, you said earlier hey maybe this is just a VC talking, but Martin really codes. Martin's really in this coding day-to-day. So it's been super fun the three of us working together. If you look at the commits, we're all there. So our team is not just posing, as I'm sure you know. But yeah, this is...

嗯，你知道，你得看实际效果。我想最后一个问题……是的，RSI 在这里是一个非常热门的大话题。

Well, you know, you got to see the proof in the pudding. I guess the last question I... Yes, RSI is like a very trending big topic here.

你有没有试过直接告诉 Exo 在没有目标的情况下改进自己，还是你会给它一个目标，或者你是怎么做的？

Have you tried just telling Exo to improve itself with no goal, or do you give it a goal, or like what do you do?

这是个非常好的问题。让我就这个说几句。这也源于我和 Yan 在伯克利做的一些研究。我们即将发表一篇关于这个问题的论文，即在这些优化问题中，最终的困难是你总是必须提供一个评估器，而这个评估器必须反映你的目标，否则就没有信号让系统去爬山或优化。或者那个信号，它可能会为自己找到一个信号，但它可能不符合你真正想要的，这也是一个危险且有害的失败模式。所以我们为此做了几件很酷的事情。首先，你可能希望你的智能体做的一件非常标准的事情是，你可能希望它运行得更便宜。推理成本真的很高。其中一个主要问题就是，你如何组装你的上下文？你包含多少历史记录？我可以告诉你，使用 OpenClaw 时，我运行 OpenClaw 的账单大幅上升，因为它组装上下文的方式。它把太多东西放进去。我们在 Exo 中做的一件事非常酷。嗯，Exo 的 harness，对话日志不仅存储你谈论的内容，还标注了每条消息的成本。因此，当执行者能够构建上下文并推理过去的对话以及这些对话不同部分相关的成本时。所以很早的时候，最让我兴奋的事情之一是，在我们构建了自我改进的 Exo 之后，我们问它，嘿，我注意到，我问，嘿，Discord 适配器中最后一条消息花费了多少？它说是 16 美分。我就想，你是认真的吗？16 美分？那太疯狂了。去想办法把它降下来。于是它就去在运行时重新架构了自己的 Discord 适配器。做了修改，观察它们，测试它们，真正缩小了每次 LM 调用中包含的上下文范围，只限定到特定的对话和特定的线程，而不是从 Discord 的不同线程中拉取消息，从而将成本降低了，我想，大约 96%。顺便说一句，我们之后把这个提交回去了。所以它所做的改变改进了自己，降低了成本，然后我们最终把它提交到了现在实际的代码中。

This is such an excellent question. So let me say a few words about this. And this is also coming out of some of my research that I'm doing at Berkeley with Yan. We're about to put out a paper on exactly this, which is in all these optimization problems, the final difficulty is you always have to provide some evaluator, and that evaluator has to kind of reflect your goals, because otherwise there's no signal for the thing to hill climb or to optimize. Or that signal it might find a signal for itself, but it might not align with what you actually want, and that's also a dangerous, pernicious failure mode. So there's a couple cool things that we do for this. For one, one very standard thing that you might want your agent to do is you might want your agent to run more cheaply. Costs for inference are really high. And one of the big issues is like even just how do you assemble your context? How much of the history do you include? I can tell you with OpenClaw, my bills for running OpenClaw ran way up because of the way it assembles its context. It puts so much stuff in there. One of the things we did in Exo, which is really cool. Well, the Exo harness, the conversation log stores not just what you talked about, but it also is annotated with costs for each of the messages. And so because of that, then when the executive has access to constructing context and also reasoning over the past conversations and the costs associated with different parts of those conversations. So very early on, one of the first things that was most exciting to me was after we built self-improving kind of Exo, we asked it, hey, I noticed, I asked, hey, how much did the last message cost in the Discord adapter? And it was like it was 16 cents. It's like, are you serious? 16 cents? That's actually crazy. Like go work on driving that down. And so it went and rearchitected its own Discord adapter at runtime. Made changes, observed them, tested them to really scope down the context that was included in each of the LM calls as they were built, by scoping it to certain conversations and certain threads only, rather than pulling messages from across different threads in Discord, in a way that drove down the cost to, I think, like a 96% decrease. And by the way, we committed this back afterwards. So the changes it made improved itself, decreased cost, and then we ended up committing that to the actual code that's there now.

你这样做是否以评估中没有回归为前提？你知道，这里没有写着“评估”的框。但是，Exo harness 是否应该自带评估？

Are you doing this subject to no regressions in eval? You know, there's no box that says evals in there. But like should an Exo harness ship its own evals?

是的，对于 Discord 的情况，这有点容易，因为它可以去测试并尝试从不同的地方读取消息。当我使用它时，我可以说：“嘿，这里有问题。”这是一个稍微简单的情况。如果你让它去做其他任务，它想降低这些任务的成本，一个非常有趣的失败模式是它可能会完全说：“好吧，我就是不做了，因为这是为我省钱的最便宜的方式，对吧？”我们在 AI 驱动的发现中也看到了这一点。

Yeah, with the Discord case, it's a little easier because it can go and then test and try reading messages from different places. As I'm using it, I can say, "Hey, something's wrong here." It's a slightly simpler case. If you're going off and having it do some other task that it wants to improve its costs on, a very funny failure mode is it could totally be like, okay, I'm just not going to do it, because that's the cheapest way for me to save money, right? And we see this in AI-driven discovery.

那是奖励黑客。

That's a reward hack.

奖励黑客，没错。防止奖励黑客，所以你肯定想要某种类似评估的东西，让它去检查性能是否仍然在你期望的水平。所以在 Discord 中，性能非常容易检查。你是否在回复我的消息？你是否包含了正确的上下文？使合理响应成为可能的上下文。这更像是一种二元判断。更容易检查。如果你有一个保险智能体试图做出正确的决策，你可能需要某种保留的评估集，你可以把它提供给智能体，或者你可以与智能体协作，为它构建内部工具，以便在它自我进化时在运行时检查。所以我同意你的观点。向智能体指定你想要什么的问题仍然是一个开放的问题。所以我期望我们在提供它的过程中构建更多的工具，当它改进自己时，它也应该跟踪性能并定义某种跟踪方式。

Reward hack, exactly. Preventing reward hacking, and so you definitely want some sort of eval-ish thing that it can go and check that the performance is still at the place that you would like. So in Discord, performance is very easy. Are you responding to my messages? Are you including the right context? Context that makes a reasonable response possible. It's kind of more of a binary. It's easier to check. If you have an insurance agent that's trying to make the right decisions, you might want some sort of hold-out eval set, and you can either provide that to your agent or you can work with the agent collaboratively to construct internal tools for itself to check that at runtime as it's evolving itself. So I agree with you. The problem of specifying what you want to an agent is still an open one. So I expect us to build out a bit more tooling in the process of providing it that as it improves itself, it should also track performance and define some way of tracking that.

嗯，你知道，如果你需要评估方面的人，我听说 Brain Trust 很不错。我不知道，这可能有点偏见。

Well, you know, if you ever need an eval guy, I've heard Brain Trust is pretty good. I don't know, it might be biased here.

完全正确。我想我们这里有 Exo 领域的一些顶尖人物在思考这个问题。

That's exactly right. I think we have some of the leading people here in the room for Exo thinking through that problem.

太好了。好的。嗯，谢谢你。你是一位出色的演讲者。显然你经常这样做。你即将去埃塞俄比亚教书，天知道为什么，但感谢你抽出时间与我们交流，尤其是在你的休息时间。所以这是很棒的工作，我真的很受启发。我希望更多的人研究这个并改编这些想法。你甚至不必使用这个架构，只要想法正确就行。我认为这将使智能体更加通用有用，这是我想要的。

Excellent. Okay. Well, thank you. You're a great speaker. Clearly you do this a lot. You're about to go teach in Ethiopia for God knows why, but thank you for spending some time with us, especially on your time off. So this is excellent work, and I'm really inspired. I hope more people study this and also adapt the ideas. You don't even have to use the architecture as long as you get the idea right. I think that it will make for much more generally useful agents, which is something I want.

是的，感谢邀请我。如果还有一分钟，我想问另一件事。我想提出另一个我认为这个听众会感兴趣的案例。

Yeah, thanks for having me. I wanted to ask one other thing if we have a minute. There's one other case I want to make that I think is of interest to this audience.

嗯。

Yeah.

我想回答一个你没有问但我可能问的问题，那就是，为什么我声称现在用这种架构实现 RSI 是可能的，而以前不可能？有什么区别？我想指出过去 6 个月发生的一件事，那就是我们已经从迭代模型权重、训练模型权重，转向迭代这个 harness 和这个智能体层。这里最大的区别是，现在这些智能体的媒介，对于这个 harness 层来说，与实际构建材料是相同的。我的意思是，智能体 harness 是几千行代码。而我们的 LM 在那个相同的空间里产生输出 token。它们在写代码。它们越来越擅长写代码。所以这是关键的区别。你以前有 LM，但改进实际 LM 的过程是改变权重。那是增量。你做反向传播、梯度下降、改变权重、修改权重。但你有一个万亿参数的模型。你不能把那个模型的权重反馈给它自己，问它如何调整自己？这根本不可扩展。它不在上下文中。你可以问 LLM，嘿，给我一些关于如何训练的想法，然后去尝试应用这些想法并运行它们。但它不在同一个媒介中。而现在，harness 在运行时，智能体正在产生和编写代码，并且可以在运行时改变自己的代码。这就是为什么我相信我们正在进入一个完全自我递归的阶段。

I think I want to answer a question that you didn't ask me, but you could have, which is like, why am I claiming that RSI is possible now with this architecture in a way that it wasn't before? What's the difference? And I want to point something out that's happened the last 6 months, which is we've moved from iterating on model weights, training model weights, to iterating on this harness and this agent layer. And the big difference here is that the medium is now the medium for these agents, for this harness layer, is the same as the actual building material. And what I mean by that is the agent harness is a couple thousand lines of code. And our LMs are producing output tokens in that same space. They're writing code. They're getting good at writing code. And so this is the crucial difference. You had LM before, but the process of improving the actual LM was changing weights. It was deltas. You do backpropagation, gradient descent, changing weights, modifying weights. But you have a trillion-parameter model. You can't feed the weights of that model back into itself and ask it how do you adjust yourself? It just doesn't scale. It's not in the context. You could ask an LLM, hey, give me some ideas for how to train, and then go try to apply those ideas and run them. But it was not in the same medium. Whereas now the harness, as it runs, the agent is producing and writing code and can change its own code as it runs. Which is why I believe we're entering a stage where this is fully self-recursive.

这不仅仅是自催化——即用计算机帮助设计下一代计算机——而是计算机本身由物理芯片构成，这些芯片的布局也是设计出来的。所以当你循环往复时，中间是有层级的。而这里，代码既是产物，又是运行在这一层的东西，所以我认为这才是思考 RSI（递归自我改进）的正确层级。

It's not just autocatalytic, which is where you use a computer to help design the next computer, but the computer itself is made of physical chips that are laid out. So there are layers in between as you loop back around. This is in the same exact code that is the thing being produced and is also the thing running at this layer, which is why I think it's the right layer to think about RSI.

嗯，我的意思是，要想完全自我改进，你得训练自己的模型，对吧？比如你得接上一些 GPU，然后说，这里模型不太好，咱们微调一下。

Well, I mean, you know, you want to be fully self-improving, you got to train your own models, right? Like you got to hook up some GPUs and like, well, the model's not good here, let's fine-tune there.

同意。但我要指出的是，那样你得到的是自催化改进。你在用系统帮助改进自身，但并不是在同一个媒介中。所以这就是我想指出的关键点。

Agreed. But I'll just point out that there you get autocatalytic improvement. You are using the system to help improve itself, but it is not in the same medium. So that's the thing I want to call out in this.

你在这方面非常纯粹主义。

You're very purist about this.

我非常纯粹主义。也许是因为我来自学术界，这是我的问题。是的。

I'm very purist about this. I maybe coming from academia, this is my fault. Yeah.

这让你想起其他系统吗？我在想的是，你知道，人们经常提到闲聊之类的东西，像这样的对话，你知道，如果仔细想想，它相当于一种编程语言级别的抽象。那是一个系统，而编程语言设计和 PLT（编程语言理论）确实可以类比。我有点这种感觉。

Does this remind you of other systems? What I'm thinking about is like, you know, people often bring up small talk and stuff, conversations like this, where, you know, it is on the order of a programming language type of abstraction. If you really think about it, that is a system, and programming language design and PLT, program theory, does translate. I feel that a little bit.

是的，这是个很好的类比。我也想过这一点。这里可能可以类比某种编程语言，它自身包含了自身的构造。

Yeah, that's a great comparison. I had thought about that. There's probably some comparison to draw here to some sort of programming language that contains its own constructs within itself.

是的。Lisp。

Yeah. Lisp.

是的，Lisp 肯定浮现在脑海中。

Yeah, Lisp definitely comes to mind.

是的。现在正在发生这样的时刻。这将是一个飞轮。我觉得这个起飞时刻将来自于在你所生产的同一层上进行迭代。

Yes. Yeah. There's a moment like that happening now. And this is the moment that's going to be a flywheel. I feel like this takeoff moment will come from iterating in the same layer that you are producing.

我也这么认为。这就是为什么我现在对这个领域如此兴奋。我觉得我们都很幸运能身处这个时代。

I think so. That's why I'm so excited to be in this space right now. I think we're all super lucky to be just in this moment in time.

太好了。嗯，我很高兴至少建立了初步联系。我相信这不是你最后一次上节目，但至少能介绍一下你的工作很好。我相信我们还会看到你更多的东西，但感谢你的概述。

Excellent. Well, I am very glad to at least make this initial contact. I'm sure this is not the last time you'll be on the show, but it's good to at least get an introduction to your work. I'm sure there's more that we'll see from you, but thanks for the overview.

非常感谢你邀请我，这是一次非常有趣的对话。我期待继续交流。

Thanks so much for having me on and a really fun conversation. I look forward to talking.

我们会在下方放你的联系方式。如果人们想以任何有意义的方式做出贡献，最好的起点是什么？

We'll put your contact details below. If people want to contribute in any meaningful way, what is the best place to get started?

是的，我们欢迎贡献者。Marty、Anker 和我正在和其他几个人一起构建。请来查看我们的 GitHub：github.com/exoharnness/exo。那里有我们 Discord 的链接。直接进来，一起聊聊。如果你只是对这些话题感兴趣，也欢迎加入讨论，因为这是一个非常关键的时期。现在还很早。我们一直在寻找贡献者和更多的讨论伙伴。所以，是的，就在那里联系，关注我的 Twitter。链接会在下方。

Yes, we welcome contributors. Marty and Anker and I are all building together with a handful of other people. Please come check out our GitHub, github.com/exoharnness/exo. And on there, there's a link to our Discord. Just come hop in, come hang out. If you're just interested in these topics, come join and discuss with us because it's a very formative time. This is still very early. We're always looking for contributors and more discussion partners. So, yeah, just reach out there, follow me on Twitter. It'll be linked below.

小贴士：当你加入这类早期社区时，实际上不仅仅关乎项目。还关乎人，以及你未来几年会和他们一起做什么。所以每当我看到这类早期社区，那真的是加入的好时机。太棒了。好了，我就说到这里。非常感谢。

Pro tip: when you join these kinds of early communities, it's actually not just about the project. It's also about the people and what you end up doing with them in future years. So whenever I've seen these kinds of early communities, it's actually a really good time to join these things. So awesome. All right. Well, I'll cut it there. Thank you so much.

谢谢。

Thank you.