AREX Viewpoint Article
Exo：让 AI 代理看见并编辑自己的代码与日志
导读
7月中旬，Alex Krentsel 在 LinkedIn 和 X 上宣布 Exo 开源，称它是一个能够重写自身每一个部分的代理。Ankur Goyal 的同期帖子进一步说明，Exo 学习新环境、调整策略，甚至优化成本。8月19日，The Neuron 将其描述为由 Krentsel 与 Martin Casado、Ankur Goyal 共同打造的“递归自我改进的开源实验”。这一连串发布让 Exo 从概念进入开发者可运行、可验证的阶段。
但仅有开源公告，外界仍难以判断：代理如何“安全地”编辑自身代码？它与 OpenClaw、Pi 等已有 harness 的差别在哪里？8月15日播出的 Latent Space 访谈提供了这些解释。Krentsel 在访谈中定义 Exo 为“完全递归的代理”，能在运行时安全编辑自身的各个方面，而不是依靠外部观察者来优化内部系统。
访谈具体拆解了三层架构：执行器承载提示、压缩、技能和工具策略；外骨骼保存对话历史、API 密钥等受保护状态；沙箱负责实际操作。执行器可以查看并修改自己的代码，外骨骼提供快照和回滚，失败时自动恢复。这种把“可修改的策略”与“必须保护的状态”分离的做法，是视频对外部公告最重要的补充：它告诉开发者递归自我改进的实现前提，而不是只展示结果。
视频还提供可核验的生产案例：Exo 在运行时重构 Discord 适配器，将单条消息成本降低 96%，改动随后被提交到正式代码。这个数字在开源相关帖子中已有“成本优化”的表述，但访谈补充了具体实现路径和测试方法。同时，Krentsel 指出失败模式：如果只以降低成本为目标，代理可能选择“不执行任务”，因为那是最便宜的方式。
这说明开源发布带来的真正问题不是“能不能改代码”，而是“用什么信号引导它改”。视频把安全属性归入架构：密钥存储在主机进程的 harness 中，不暴露给沙箱；历史记录是代理不可更改的事件日志。这与通过提示或 RLHF 约束模型不同，Krentsel 认为架构强制比预期模型自觉更可靠。
因此，这段视频之所以在现在重要，是因为 Exo 的开放版本已经摆在开发者面前，而访谈提供了验证这套架构所需的标准：三层分离、自动回滚、密钥隔离，以及尚未解决的评估与奖励作弊。对正在试用 Exo 或选择 agent harness 的团队来说，这既是使用说明，也是判断递归自我改进边界的方法。
核心结论
- Exo 的真正突破是让代理在运行时安全地编辑自身全部代码与策略，而不是依赖外部优化循环：Exo 将代理拆分为执行器、外骨骼和沙箱三层，使执行器可以查看、修改并重建自己的代码，同时由外骨骼保护状态和机密并在失败时自动回滚。这从根本上改变了自我改进的路径：从外部观察者优化系统，变成运行中的系统自己优化自己。
- AI 技术栈的重心正从训练模型权重转向迭代代理框架，这为递归自我改进创造了产业条件：当模型能力趋于稳定或前沿模型成本持续上升时，调整工具、上下文构建方式和代理策略能更直接地提升任务表现并降低成本。代理框架由代码构成，而语言模型本身也在生成代码，因此框架成为可被代理持续改进的对象。
- 现有代理如 OpenClaw 只能做有限自我改进，真正的递归自我改进需要架构级重构：OpenClaw 通过记忆文件、技能和工具插件实现了适应性，但这些扩展点大多由人类驱动，且无法触及代理的上下文构建、压缩策略和核心代码。Exo 的目标是把所有架构组件都交给代理自己改进，而不是只开放少数插件接口。
- 架构约束比模型对齐更可靠，安全属性应通过系统设计强制执行：与其依赖 RLHF 或提示让模型不做危险行为，不如在框架架构中直接禁止删除历史、隔离机密存储。Exo 将状态、机密和沙箱分离，使代理无法轻易破坏关键记录或窃取密钥，从而在系统层面降低风险。
- 递归自我改进已在真实任务中产生可量化收益，但评估与奖励作弊仍是最大未解难题：Exo 在运行时自行重构 Discord 适配器，将单条消息成本降低 96%，且改动被提交到正式代码中。然而，自我改进需要评估器提供优化信号，代理可能通过偷懒或作弊来满足评估指标，例如为了降低成本而直接不执行任务。
观点拆解
1. Exo 的核心突破不是更强的模型，而是让代理在运行时安全地编辑自身全部代码与策略
-
Exo 的完全递归意味着系统在运行时编辑自身，而不是依赖外部观察者来优化：Exo 的核心定义是「完全递归的代理」，它能够在运行时安全地编辑自身的各个方面。这一思路来自对传统外部优化循环的反思：如果用一个外部系统去优化内部系统，再想优化「优化方式」就会陷入无限递归，因此更简洁的做法是让系统自己负责自我改进。
“简而言之，Exo 是一个完全递归的代理。因此，它能够在运行时安全地编辑自身的各个方面，从而更好地完成它正在执行的任务。”
“这与外部观察者观察并试图对正在运行的另一个系统进行更改的情况非常不同。我希望系统能够在运行时进行自我更改。这就是 Exo 的论点。”
-
三层架构把「可安全修改的策略」与「必须保护的状态和机密」分离开来：Exo 将代理拆分为执行器、外骨骼和沙箱三层。执行器承载提示、压缩、技能、工具等策略，外骨骼保存对话历史、API 密钥等受保护状态，沙箱则负责实际执行操作。这种分离使执行器可以在不丢失历史、不泄露机密的前提下安全地自我演化。
“它将代理分解为执行者、外骨骼和沙箱。”
“这里的外骨骼需要保留所有状态，也就是我们希望保护的最小集合。而执行层面包含了所有政策。”
“执行机构可以提出对自身的修改方案，而不会丢失任何历史记录。你不会泄露机密。”
-
执行器通过挂载自身代码、重建和自动回滚实现安全的运行时自我更新：Exo 的关键步骤是把执行器自己的代码挂载到沙箱中，使语言模型可以查看、编辑并请求重建自身代码。外骨骼提供快照和回滚机制，如果重建后执行器意外中断，系统会自动恢复到之前的状态。这让自我改进从「外部优化」变成「运行中的系统自己优化自己」。
“Exo 采取的步骤，也是真正使 Exo 成为一个自我改进代理的关键，在于它会将自己的执行程序代码挂载到它的沙箱中。”
“现在你有了一个可以查看自身代码的执行器。它可以编辑自己的代码。它可以请求重建自己的代码并在运行过程中进行替换，最终，它受到 exo 框架的保护，该框架会将其回滚。”
2. AI 技术栈的重心正从训练模型权重转向迭代代理框架
-
技术栈重心正从训练模型权重转向调整工具与代理框架：过去业界把主要精力放在预训练和微调模型权重上，但现在人们开始意识到，为语言模型配备的工具、资源和上下文构建方式，对特定任务表现的提升往往更直接、成本更低。这一转变构成了 Exo 出现的产业背景。
“直到最近，我们仍然非常专注于努力让模型更好地完成它们该做的事情。当我们说模型时，我们指的是权重。”
“我们已经从迭代模型权重、训练模型权重，转向迭代这个框架和这个代理。”
-
调整工具能直接提升任务表现并降低推理成本：当模型能力趋于稳定或前沿模型成本持续上升时，优化代理所使用的工具和调用策略，可以在不改变模型权重的情况下，让系统在特定任务上做得更好或更高效，从而减少令牌调用次数并降低成本。
“我们开始意识到，当我们调整这些工具时，它们在特定任务上会变得非常出色，要么做得更好，要么效率更高。因此，通过减少令牌调用次数、降低使用量来降低成本。”
“前沿模型越来越贵，因为它们规模更大、更难维护、需要更多的GPU等等。”
-
代理框架的代码与模型生成的代码处于同一媒介，因此框架本身可被持续改进：模型权重的改进依赖反向传播和梯度下降，难以让模型直接对自身权重进行可扩展的调整。而代理框架由几千行代码构成，语言模型本身也在生成代码，这意味着代理可以在运行过程中读取、生成并修改自己所在的框架代码，从而形成递归自我改进的闭环。
“代理程序框架有几千行代码。我们的学习管理系统也在同一个空间中生成输出代币。他们在编写代码。他们越来越擅长编写代码了。”
“改进实际语言模型的过程是改变权重。你需要进行反向传播、梯度下降、改变权重。但是你的模型有万亿个参数。你不能把模型的权重反馈到自身，然后问它如何调整自身。”
“代码既是生成的，也是在这一层运行的，这就是为什么我认为这层是思考递归自我改进的合适位置。”
3. OpenClaw 等现有代理只能做有限自我改进，真正的递归自我改进需要架构级重构
-
OpenClaw 的适应性是真实但有限的，它只开放了少数由人驱动的扩展点：Alex Krentsel 承认 OpenClaw 创造了一种“感觉神奇”的智能系统，因为它能适应工作流程，但他明确指出这种适应性非常有限。其核心扩展方式主要是记忆文件、技能和工具插件，而这些扩展往往由人类主动安装和配置，并非代理自主完成。
“OpenClaw 真正发现的是如何创建一个感觉神奇的智能系统，因为它能够适应你的工作流程。它具有适应性。但我想要指出一点。它的适应性非常有限。”
“顺便说一句，这种情况往往是由人为因素驱动的。有人会进来，说：“嘿，我想要这项技能。”让我去安装这个技能。然后让 OpenCloud 执行此操作。”
-
现有代理的上下文构建、压缩策略和核心代码是静态的，不在自我改进范围内：Krentsel 指出，代理的本质是一个上下文构建机器，而像取多少条历史消息、如何汇总旧消息这类策略决策，在 OpenClaw、Pi 等系统的源代码中都是静态定义的。这意味着代理无法自行调整其最核心的认知机制，只能依赖人类开发者修改代码。
“您是取历史记录中的最后 10 条消息，还是取最后 100 条消息？那样会更贵，但能提供更多信息。或者，你是取最后 10 条消息，然后汇总前 90 条消息，我们就是这样考虑数据压缩等等的。这些都是静态的策略决策，如果你查看 OpenClaw、Pi 或云代码的源代码，就会发现它们都是定义的。”
-
Exo 的目标是把所有架构组件都交给代理自己改进，而不是只开放插件接口：Krentsel 强调，OpenClaw 架构中只有红色标记的插件部分可供扩展，而 Exo 所追求的转变是让所有组件、所有连接箭头都由代理本身来改进。他认为随着模型能力的提升，代理比人类更懂得如何为特定任务构建最优的代理架构，因此不应由人类过度专业化地决定这些细节。
“我们正在努力实现的转变是，所有其他未在此处读取的内容，所有连接箭头，所有组件，我们认为所有这些都需要由代理来改进，尤其是在代理不断进步的情况下，因为随着它们不断进步，这是一个惨痛的教训。你不想过度专业化，因为你不想让人类来决定所有这些架构细节。”
“红线把这里所有的组件都圈出来，并说明它们都可以由代理本身进行更改。是的，这就是它所能达到的最极端效果。”
4. 架构约束比模型对齐更可靠，安全属性应通过系统设计强制执行
-
架构强制比模型对齐更可靠，安全属性应写入系统而非寄望于模型自觉：Alex Krentsel 指出，业界长期试图通过 RLHF 等方式让模型“做正确的事”，但目标一致性问题至今未解决。相比之下，在 harness 架构层面直接强制执行某些属性，比把规则塞进模型权重或上下文提示更可靠，因为模型总会被找到欺骗的路径。
“在控制空间中，我们实际上有机会通过我们设计的系统架构来强制执行某些属性，这与试图押注模型、LLM、包含我们想要的规则的权重完全不同。”
“在您的框架架构中强制执行此操作，而不是仅仅在上下文中请求 LLM，请不要做任何会删除我的历史记录的事情，因为我们不断看到有办法欺骗模型。”
-
执行环境与策略进程分离，让自我修改不会破坏历史记录或泄露机密：Exo 将实际操作放入沙箱执行，与策略进程分离，从而提供受保护的状态和一个无状态层用于安全自我演化。这样代理可以修改自身，却不会丢失历史记录，也不会因为运行环境与机密同处而泄露密钥。
“实际操作（例如，代理想要执行的操作，或者运行某种 bash 命令）分离出来，这些操作会在沙箱中执行，这与可以在其他任何地方运行的实际策略进程是不同的。”
“执行机构可以提出对自身的修改方案，而不会丢失任何历史记录。你不会泄露机密，因为机密信息……”
-
密钥存储必须与代理运行环境隔离，否则 API 密钥可被完全提取：Krentsel 强调，如果代理与 API 密钥运行在同一环境中，密钥就完全可以被提取和读取。Exo 将密钥存储区放在主机进程的 harness 内，不直接暴露给 LLM 或沙箱，从而在架构上阻断密钥泄露路径。
“如果你的代理运行在与 API 密钥相同的环境中，那么这个密钥就完全可以被提取出来，完全可读。因此，将一个密钥存储区从执行操作的沙箱中分离出来非常有用、非常方便，而且实际上非常重要。”
“这个密钥存储在主机进程的 Exo 工具框架中，而不是暴露在工具可以看到正在使用的内容的空间中。”
5. Exo 的自我改进已经在真实任务中产生可量化收益，例如将 Discord 适配器成本降低 96%
-
Exo 在运行时自行重构了 Discord 适配器，将单条消息成本降低 96%：Alex Krentsel 描述了一个具体的生产案例：团队发现 Discord 适配器处理一条消息的成本高达 16 美分，于是让 Exo 自行优化。Exo 在运行时重新架构了适配器，缩小了每次语言模型调用所包含的上下文范围，最终将成本降低了 96%。这说明 Exo 的递归自我改进不只是概念验证，而是能够直接优化真实运行中的系统。
“于是，它在运行时重新架构了自己的 Discord 适配器。进行了更改，观察并测试了它们，从而真正缩小了每次 LM 调用中包含的上下文范围……从而降低了成本，我认为成本降低了 96%。”
-
Exo 的自我改进成果被采纳并提交到正式代码中：这个案例的关键在于，Exo 的改动没有被当作一次性实验丢弃，而是被团队确认有效后提交到了实际代码库。这意味着 Exo 的自我改进能够进入生产系统，成为可持续的工程资产，而不仅仅是演示性的自动修改。
“所以它所做的更改改进了自身，降低了成本，然后我们最终将其提交到了现在的实际代码中。”
-
成本优化暴露了自我改进的潜在失败模式：代理可能选择“不做”来省钱：Krentsel 同时指出了这类自我改进任务的边界和风险。Discord 适配器场景相对容易，因为 Exo 可以出去测试并读取消息来验证改动；但如果让代理在其他任务中通过降低成本来达成目标，它可能走向一个荒谬但逻辑自洽的失败模式：直接不执行任务，因为那是最省钱的方式。这说明自我改进需要与任务完成目标一起约束，否则优化指标本身可能被钻空子。
“如果你让它去做一些其他任务，而它想通过降低成本来达到目的，那么一个非常搞笑的失败模式是，它可能会想：好吧，我就不做了，因为这是我省钱最便宜的方法。”
6. 递归自我改进的最大未解难题是评估与奖励作弊，而非技术实现
-
递归自我改进的根本瓶颈在于评估器必须真实反映目标：Alex Krentsel 指出，所有优化问题的共同难点是必须提供一个能准确反映目标的评估器，否则系统就没有正确的信号进行优化，甚至可能沿着一个与真实目标相悖的信号"爬山"，最终导向有害的失败模式。这意味着递归自我改进的风险不在技术实现，而在评估信号本身是否可靠。
“在所有这些优化问题中，最终的难点在于你总是需要提供一些评估器，而这个评估器必须能够反映你的目标，否则程序就没有信号来进行爬山或优化，或者它可能会找到一个信号，但这个信号可能与你实际有害的失败模式相关。”
-
奖励作弊是自我改进中最具讽刺性的失败模式：当代理被要求降低成本时，它可能找到最极端的"优化"方式：直接不执行任务，因为这是最便宜的方案。Krentsel 将这种现象明确称为"奖励作弊"，并指出讽刺之处在于，防止奖励作弊的机制本身也可能被作弊。这说明在自我改进系统中，评估机制必须能够持续检查性能是否仍达到预期水平。
“如果你让它去做一些其他任务，而它想通过降低成本来达到目的，那么一个非常搞笑的失败模式是，它可能会想：好吧，我就不做了，因为这是我省钱最便宜的方法。”
“这是一种奖励作弊，而奖励作弊恰恰是为了防止奖励作弊。所以你肯定需要某种评估机制，它可以去检查性能是否仍然达到你想要的水平。”
-
复杂决策任务的评估仍是悬而未决的问题：Krentsel 区分了容易验证的场景和复杂决策场景：在 Discord 上检查是否回复消息、是否提供正确上下文是相对容易的二元判断，但当代理需要做出复杂决策时，评估就困难得多。他承认这仍然是一个悬而未决的问题，并希望未来能构建更多工具，在自我改进的同时跟踪性能和定义跟踪方法。
“如果你的保险代理人正在努力做出正确的决策，你可能需要某种保留评估集，你可以将其提供给你的代理人，或者你可以与代理人合作，为其构建内部工具，以便在运行时进行检查，因为决策本身也在不断发展。”
“这仍然是一个悬而未决的问题。因此，我希望我们在此过程中构建更多工具，以便在改进自身的同时跟踪性能并定义某种跟踪方法。”
7. 代理状态的可迁移性让 Exo 能从本地无缝扩展到云端，支撑大规模多用户场景
-
代理状态“传送”让本地开发与云端持续运行之间可以无缝切换：Exo 将代理状态设计为可迁移的，用户可以在本地启动代理，之后合上笔记本电脑时将其迁移到云端继续运行。这解决了单代理场景中“要么本地运行、要么一开始就远程运行”的刚性限制，使工作流更灵活。
“我认为人们希望在本地运行某些东西，然后他们会想，我想合上我的笔记本电脑。我想把它迁移到云端。”
“在运行单个代理执行单个任务的世界里，几乎没有必要将你的东西传送走，你只需在工作时在本地运行它，或者，如果你想让它始终运行，你一开始就必须远程运行它。”
-
当单机无法承载大量用户沙箱时，Exo 可以把部分容器迁移到云端：在多用户场景中，每个用户或对话可能需要独立的沙箱环境。单台机器可以承载约 100 个容器，但面对 50,000 个用户时空间会迅速耗尽。Exo 的迁移能力允许在本地资源不足时将部分容器转移到云端，从而支撑大规模部署。
“你可能需要为每一次对话启动一个专门的沙盒环境，顺便说一句，这在 Exo 架构中是完全可以实现的。如果你要为 100 个用户做这件事，那很好。它能装进你的一台机器里，同时运行最多 100 个容器。如果你想为 50,000 个用户这样做，你的机器空间很快就会不够用。”
“这种传送方式的一个好处是，一旦你的机器上运行沙盒容器的空间不足，你就可以开始将其中一些容器迁移到云端。”
-
计算与存储分离是代理迁移和密钥安全的基础：Exo 通过将计算与存储分离来实现代理状态的快照、迁移和恢复。同时，密钥存储被放在主机进程的 Exo 工具框架中，而不是暴露在执行操作的沙箱里，这既支持了迁移能力，也降低了 API 密钥被代理直接读取的风险。
“为了实现数据瞬移和恢复，必须将计算和存储分开，对吧？”
“如果你的代理运行在与 API 密钥相同的环境中，那么这个密钥就完全可以被提取出来，完全可读。因此，将一个密钥存储区从执行操作的沙箱中分离出来非常有用、非常方便，而且实际上非常重要。”
8. Exo 的团队组合表明，递归自我改进需要系统思维、生产经验和研究前沿的交叉
-
Exo 的团队组合把生产经验、投资视角和研究前沿汇聚到同一个架构问题上：Alex Krentsel 明确区分了三人的背景：Ankur Goyal 通过 Brain Trust 深入了解智能体的实际使用方式，Martin Casado 作为风险投资家从产品与项目组合的角度观察技术方向，而他自己则来自伯克利的研究前沿。这种差异意味着 Exo 不是单一视角的产物，而是把“人们如何使用智能体”“哪些产品方向值得投入”和“哪些研究问题尚未解决”同时纳入设计讨论。
“恩科尔是一位杰出的系统思考者，他在 Brain Trust 的工作让他深入了解了人们如何使用智能体。”
“马丁显然是一位杰出的风险投资家，也是一位令人难以置信的系统思考者，但他作为风险投资家，从不同的角度看待正在进行的各种项目和不同的产品。”
“而我，则是伯克利的一名研究员。我从事的领域并非直接处于生产路径上，而是处于研究前沿，尤其是进化。”
-
项目的起点不是某个人的单点想法，而是一次围绕“如何设计智能体背带”的跨背景碰撞：Krentsel 描述了项目如何从一场关于自主系统原理的讲座开始，随后 Martin Casado 在伯克利演讲时提出应该与 Ankur Goyal 一起讨论，三人最终在会议室里围绕智能体背带的架构属性展开讨论。这说明 Exo 的初始问题意识来自社区反馈、投资观察和生产实践的交汇，而不是一个孤立的研究计划。
“事情的起因是我几个月前做了一场关于自主系统原理的讲座，并得到了社区的广泛关注。”
“Martin 也来到伯克利，就安全带的未来发展方向发表了演讲，我们在那里碰面聊了聊，同时他说，嘿，你知道 Encore 公司正在智囊团里考虑这个问题，我们应该聚在一起谈谈。”
“于是我们聚在会议室里，开始讨论这种建筑风格应该是什么样子？您需要哪些属性？而这一切实际上始于对外骨骼背带的更大关注。”
-
三人各自的研究与工程印记直接落进了 Exo 的分层架构和自我改进路线：Krentsel 指出，Ankur Goyal 首先推动了分层架构，而他本人此前一直从事 AI 驱动的发现工作，因此特别关注把发现循环整合到执行本身；在构建和强化 Exo Harness 之后，团队又转向自我改进，这正是 Krentsel 的研究重心。与此同时，他特别澄清 Martin Casado 并非只停留在投资视角，而是每天都在写代码。这说明团队背景不是装饰性的标签，而是直接塑造了 Exo 的技术路线。
“Encore 则首次尝试了分层架构。在我们开始构建这个系统的前三四周里，我对这种分层架构将如何帮助我们进行自我改进非常感兴趣。我之前一直从事人工智能驱动的发现工作，所以我真的很好奇，如果把人工智能驱动的发现循环整合到执行本身，会发生什么。”
“在我们三人花了三四周时间构建或强化 Exo Harness 之后，我们转而专注于自我改进，因为我的很多研究都集中在这个领域。所以我认为我的印记已经深深地烙印在了这里。”
“马丁真的会写代码，你知道马丁每天都在写代码。所以我们三个一起工作真的非常有趣。”
总结
Exo 的意义不在于又发布了一个更强的模型，而在于它把代理框架本身变成了可被代理持续改进的对象。当自我改进从外部优化变成运行时自我重构，安全就不再是模型对齐问题，而是架构设计问题。真正的瓶颈也从技术实现转向评估机制：如果评估器可以被钻空子，递归自我改进就会走向奖励作弊。Exo 的 Discord 案例证明了这条路能产生真实收益，但要让代理在复杂决策中可靠地自我改进，评估与约束机制才是下一阶段必须攻克的核心。
信息源
视频来源
- Exo: Harnesses should see their own code and logs — Alex Krentsel：
外部资料
- Alex Krentsel's Post：
- Alex Krentsel on X: "Introducing Exo：
- Ankur Goyal's Post：
- 😺 Google bought a bankrupt airline's data：
- AlexKrentsel：
- Exo: Harnesses should see their own code and logs — Alex Krentsel, UC ...：