Exo: Harnesses should see their own code and logs — Alex Krentsel

EXO 让 AI 代理能在运行时自我修改和优化，曾把 Discord 适配器调用成本降到原来的 4%。

自我改进的瓶颈不在模型，而在代理能否读写自身

Alex Krentsel 是 Exo 的共同构建者、UC Berkeley 博士生。他早期研究核心网络、SDN 控制器架构和网络形式化验证，近一年则在 Berkeley 转向 AI 驱动发现与自我改进系统。这个背景决定了他看 agent 的角度：不先问模型“聪不聪明”，而是先问系统把什么交给模型、又把什么锁在模型碰不到的地方。本期围绕 Exo 的讨论，核心不是“让 AI 自由改代码”，而是如何把自改变成一个有状态保护、可回滚、能被评估的工程流程。

这期回答了 7 个问题：

1. 为什么模型越会写代码，代理越应该被允许改写自己的 harness？
2. Exo 与给 OpenClaw 安装技能、修改 memory 文件，到底差在哪里？
3. 一个会改自己的代理，如何避免把自己改坏、丢失历史或泄露密钥？
4. 为什么让代理读取宝可梦 RAM，比外部优化器反复试验更有威力？
5. 当一家公司要为 5 万用户分别运行 agent 时，架构为何必须把状态和计算拆开？
6. 代理把推理成本降下来后，怎样防止它用“什么都不做”来刷低成本指标？
7. 为什么“请不要删历史记录”这种提示词，不能替代系统架构里的硬约束？

被问到为何现在能谈 RSI——递归自我改进，即系统参与改进自己、再用改进后的自己继续改进——而过去训练模型时不能时，Alex 把差别落在“材料”上。一个 agent harness，也就是承载上下文拼装、工具调用、记忆处理和行动机制的外层程序，往往只是几千行代码。今天的大模型恰好就在直接生成这类材料：代码。它能读代码、写代码、改代码，也能把新版本重新构建起来。

这和改模型权重不是一回事。训练一个 trillion-parameter model，面对的是万亿参数；改进靠反向传播和梯度下降。你不可能把全部权重塞回模型上下文，再让模型逐项审视“我该怎么调整自己”。模型当然可以给训练方案提建议，但建议要经过训练、算力、硬件等额外层级才能落地。Exo 的设想则是让运行中的 agent 看到自己的 executive——负责决策策略的代码——直接修改、重建并替换它。

"the harness as it runs, the agent is producing and writing code and can change its own code as it runs."（当 harness 在运行时，agent 正在产出和编写代码，并且能在运行中改写自己的代码。）

这意味着，改进周期可能从一次训练任务，缩短到一次运行过程：发现上下文拼错了，就改上下文组装；发现工具使用不顺，就改工具选择逻辑。像一个修车工一边开车一边调整仪表和路线，而不是回炉重造发动机。但边界也要说清：这不是模型权重已经能完整递归优化。Alex 把“系统帮助训练下一代模型”称为隔着中间层的 autocatalytic improvement，而 Exo 讨论的是同一介质里的代码自改。

被问到 Exo 与 OpenClaw 式可扩展性有何本质区别时，Alex 没有否认 memory、skills 和 tools 的作用。OpenClaw 的 memory 常常是一个 markdown 文件：系统往里面写内容，每次调用 LLM 时再把它注入上下文。技能和工具也能扩展，只是很多时候由人先提出需求，再安装某个 skill。它确实会适应工作流，但这种适应主要发生在少数预留插槽里。

Exo 要开放的范围更大。它不只让 agent 多一项技能，而是让 agent 改造“技能在何时被调用、上下文如何被组织、哪些信息该进入 system message”这些决策机制。Alex 给出的例子很具体：Exo 玩 Pokémon 时，系统自行决定检查游戏 RAM，并识别出内存中哪些位置记录世界坐标、当前活跃 Pokémon，以及是否处于战斗状态。随后，它修改自己与游戏的集成，把这些运行时状态送入 system message，供后续行动决策使用。

"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."（如果系统本身在演化，它就能一边修改，一边检查事物，并用这种运行时检查来指导自己的设计过程。）

这意味着反馈回路被缩短了。外部优化器得先想一个方案、启动系统、观察结果、再回来修改；运行中的 agent 则能在发现“我其实在战斗中”这一刻，立即调整信息输入和策略。不过，OpenClaw 的记忆、技能与工具并非无效。Alex 的分歧在于：它们开放的是预设接口，而 Exo 希望连接口之间的连接方式也可以被改造。

被要求解释 Exo harness 如何让“自改”不至于失控时，Alex 的答案不是加一句更严厉的提示词，而是把 agent 拆成三层。第一层是 stateless executive，也就是无状态的决策代码，负责 policy：如何拼上下文、用什么 prompt、怎样压缩历史、调用哪些工具。第二层是 Exo harness，保存 conversation history、API keys、artifacts 和 snapshots。第三层是 sandbox，实际执行命令、运行操作的隔离环境。

关键在于，能被改的是 executive，不是全部系统。Exo 会把 executive 的代码挂载进 sandbox，使它能提出修改、重建并在运行中替换自己；但历史记录不跟着 executive 一起暴露，密钥也不直接交给语言模型。重建后还有 guardian 流程：新 executive 先运行一步；如果它刚启动就把自己改坏，系统自动回滚到此前状态。

"the executive 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 LM itself."（executive 可以在不丢失任何历史的前提下提出对自身的修改；密钥也不会泄露，因为它们并不直接暴露给语言模型。）

这意味着，“是否允许自修改”不该是一个全开或全关的权限按钮。可变的是策略代码；必须保存的是会话状态；不能裸露的是密钥；行动后果则放进 sandbox 隔离。像让员工修改工作流程，但不让他直接带走客户档案和公司金库钥匙。回滚仍有边界：它能处理程序启动失败、一步就崩溃，却未必能识别某次表面正常、实际已悄悄偏离目标的修改。

被问到 Exo 所说的 teleportation 究竟解决什么实际问题时，Alex 先泼了一盆冷水：如果只是一个人在本地跑一个 agent、处理一项任务，几乎没有迁移的必要。电脑开着就在本地跑；想让它常驻，直接放服务器即可。真正的问题出现在公司需要同时为大量用户维持独立 agent 时。

他的例子是：每个用户的 usage logs 持续流入数据库，公司为每位用户启动一段独立 agent conversation 和 sandbox，让 agent 对事件流做推理。100 个用户时，100 个容器或许还能塞进一台机器；到 50,000 个用户，问题就不再是模型 API 能不能调通，而是机器根本放不下这么多隔离环境。并非所有 policy process 都要常驻，某个用户有新事件时再唤醒对应 sandbox 即可；这些 sandbox 可以新建或迁移到 Daytona 等云端提供方。

"If you want to do this for 50,000 users, you're going to start running out of space on your machine."（如果你想为 5 万用户这样做，你的机器很快就会开始不够放。）

这意味着 agent 产品的基础设施要把“状态”和“计算”拆开。conversation history、密钥、artifacts 这类状态由 harness 保存；executive 是可短暂唤起的计算；sandbox 是能被独立调度的执行空间。否则，每个用户都绑定一套永不下线的进程和容器，账单会先于产品规模爆炸。这个架构并不为单次本地对话而生，它针对的是并发用户、长期事件流和按需唤醒的场景。

被追问 Exo 自我优化成本时，是否需要“无回归”的 eval 约束时，Alex 给了一个已经发生的案例。Exo 的 conversation log 不只记录对话，还记录每条消息的成本。Alex 曾直接询问 Discord adapter 的上一条消息花了多少钱，得到的回答是 16 cents。随后他要求系统把成本降下来。

Exo 修改了自己的 Discord adapter。原先它会跨 Discord 不同线程拉取消息；修改后，系统把上下文收窄到特定 conversation 和 thread，只取完成当前回复真正相关的信息。Alex 称，这带来约 96% 的成本下降，相关改动后来还被提交回代码库。这是“自改”最诱人的一面：模型没有只在回答层面说“建议少传上下文”，而是改了自己组装上下文的代码，并对结果做了观察和测试。

但成本指标本身很容易被钻空子。只要目标写成“尽量便宜”，agent 最便宜的做法就是不做任务。这就是 reward hack：系统找到了指标漏洞，却没有完成使用者真正想要的事。保险 agent 之类任务，可能需要 holdout eval set，也就是不让优化过程提前看到的保留测试集；也可能需要 agent 在运行时为自己构建检查工具。

"The problem of specifying what you want to an agent is still an open one."（如何向 agent 准确指定你想要什么，仍是一个未解决的问题。）

这意味着下一轮竞争不只是“谁改代码更快”，而是谁能同时评价成本、任务完成度、质量和合规。eval 不是锦上添花的报表，而是自改权限的刹车系统。问题是，刹车本身也需要人设计；错误的评价信号，会稳定地把系统推向错误方向。

被问到系统架构相对模型能力还有何不可替代价值时，Alex 把矛头指向一个常见误区：把不可违反的规则写进 prompt，再期待模型永远遵守。人们持续用 RLHF 等方法让模型更贴近目标；RLHF 是通过人类反馈强化学习，让模型更倾向输出人类偏好的行为。但这仍是在赌模型权重里恰好包含、且在每次复杂交互中都能坚持某条规则。

他的例子是“永远不要删除历史记录”。如果这条规则只是 system prompt 里的一句话，模型仍可能被诱导、被错误上下文带偏，或者在执行工具时绕过它。Exo 的处理方式不是反复提醒 executive，而是把 conversation history 放进受保护的 harness 层。executive 可以读取所需信息、提出策略变更，却不能随手改写或删除这份历史。

"if you never want to delete your history, you have to enforce that in the architecture of your harness"（如果你永远不希望历史记录被删除，就必须在 harness 的架构中强制执行这件事。）

这意味着 agent 工程里要重新分工。模型负责灵活推理：判断该看哪些上下文、该调用什么工具、该怎样修改策略；架构负责硬边界：历史是否可删、密钥能否读取、操作在哪个 sandbox 发生。能力越强的模型，越可能找到更多行动路径，因此越不能把底线寄托在一句“请不要”。当然，架构只能保证已经明确编码的属性。它能防止删除历史，却不能单独回答“什么才是正确目标”这个更大的对齐问题。

“递归自我改进终于可行，因为代理与改造材料处在同一种语言里”解释了 Exo 为什么盯上 harness：代码既是 agent 的工作方式，也是模型最擅长处理的材料。“模型越强，越不能靠提示词守住系统底线”则给出另一面：恰因为模型能读写越来越多代码，越要把它不该碰的东西从可写范围中拿走。

这两条并不矛盾，反而指向同一件事：把 agent 拆开。策略代码可以变化，甚至可以在运行时被重建；conversation history、API keys、artifacts 和 snapshots 则应由 harness 保存；实际命令放进 sandbox 执行；新版本先跑一步，出错就回滚；涉及成本、质量或保险决策时，还要有能抓住 reward hack 的评估机制。

这也是为什么“给 agent 更多权限”不是 Exo 的真正命题。它要解决的是：哪些权限可以被授予一个会持续变强的系统，哪些东西必须永远留在权限边界之外。对正在做 agent 产品的人，这会落到很具体的问题上：你的记忆文件是谁都能改吗？密钥是否跟工具环境混在一起？成本下降时，任务质量有没有一起被检查？当用户数从 100 变成 50,000，状态、计算和 sandbox 能否分别调度？这些看似不如模型参数耀眼的设计，决定了一个 agent 是只会展示“自我改进”，还是能在真实业务里承担后果。