核心要点
- 递归自改：Exo 是一个完全递归的 Agent，能在运行时安全改写自身的每一个部分——包括工具、skill、上下文组装方式和 adapter，而不只是像多数框架那样在少数几个预留插槽上做扩展。
- 三层切分：架构把 Agent 拆成 executor（纯无状态的 policy）、exo harness（保存会话历史、密钥、快照的有状态层）和 sandbox（真正执行动作的隔离环境），三层属性不同、职责不同。
- 降本 96%：Exo 的会话日志给每条消息标注了成本，Alex 发现 Discord adapter 单条消息花掉 16 美分，让它自己去优化；它重写了上下文组装逻辑，只取本线程消息，成本降约 96%。
- 同一介质：他认为 RSI 现在才成立，是因为 harness 只有几千行代码，而 LLM 的输出恰好也是代码——产出物和运行物处在同一介质，不像改权重那样隔着反向传播和万亿参数。
- 架构强约束：与其寄望 RLHF 把规则塞进权重，不如用架构强制属性。例如"永不删除历史"应由 harness 结构保证，而不是在 prompt 里恳求模型别删。
- 密钥隔离：secret store 放在 exo harness 而非 sandbox，密钥注入 executor 但对工具不可见，避免 Agent 与 API key 同处一个环境导致的全量可读、可外泄。
- 回滚兜底：executor 被重建后有一个 soak 过程——先跑一步，若把自己改崩就自动回滚到上一版本；sandbox 也可快照，Agent 能自主试错并撤销。
章节时间轴
- 0:03 开场与项目由来 — 主持人从 OpenClaw 讲座认出 Alex，引出他与 Martin Casado、Ankur Goyal 共建 Exo 的故事。
- 2:21 为什么是 harness 层 — 从大规模预训练到 fine-tune 再到 Agent，价值正从权重转移到 harness 这个"身体"上，同时成本压力持续加大。
- 3:53 塌缩循环的思路 — 外层优化内层会导致无限递归，出路是让系统自己改自己（collapse the loop）。
- 4:39 与 OpenClaw 的差别 — OpenClaw 只在 memory、skill、tool 等少数点位可扩展，且通常由人驱动；Exo 要让所有组件和连线都可被 Agent 改。
- 6:58 什么是 policy — Agent 本质是"上下文构造机 + 动作执行器"，取多少条历史、如何 compaction、有哪些工具都属于 policy。
- 10:48 显式开关还是隐式 — 外层 Agent 改内层同样是在信任机器；合并成一层的好处是决策、执行、自省由同一个系统完成。
- 11:34 Pokémon 案例 — Exo 自己去读游戏 RAM、映射内存含义，并把这些信息接进 system message 来改善决策。
- 15:26 三层架构详解 — executor 无状态、harness 存状态、sandbox 做执行，配合快照与回滚。
- 21:35 teleportation 的价值 — 不是为了合上笔记本，而是为了几万个用户各自唤醒专属 sandbox 时把容器迁到云上。
- 24:38 sub-agent、secret store 与访问日志 — 谁在哪一层实现，以及为什么密钥访问异常需要被监控。
- 29:16 实时与可中断 — 语音走 pipeline 级联；线程一旦开工无法中断是 OpenClaw 的痛点，解法更像操作系统的后台任务与信号。
- 32:22 ACP 与协议之争 — 通用协议总是最小公分母，OpenClaw 选择接入 PI 而非兼容十种 Agent 更简单。
- 34:39 三人分工与生产落地 — Ankur 带来生产视角、Martin 真的在写代码、Alex 带来进化式系统研究；Exo 已在 Braintrust 生产运行。
- 38:30 评估与 reward hacking — 让它省钱它可能干脆不干活；需要 hold-out eval 或与 Agent 协作构建自检工具。
- 42:21 为什么是现在 — 介质统一带来的飞轮，以及与 Lisp 式自含构造的类比。
详细内容
一、从"外层循环"到"塌缩循环"
Alex 的问题意识来自他在 Berkeley Sky Lab 的 Sky Discover 项目：那是一个 outer loop，负责优化和改进某个内部系统。他把这个设定往极端推了一步——如果你想优化"你做优化的方式"，就需要一个更外层的 loop，然后是更更外层，形成无限递归。
他给出的出路是把这个循环塌缩掉（collapse the loop）：不要外部观察者盯着系统做修改，而是让系统本身承担改进自己的职责，并且是在运行时改。这是 Exo 的核心命题，也是它与"外层 Agent 修改内层 Agent"这类方案的根本分歧。
主持人在这里给出了一个务实的反例：他自己两家公司的做法是内部 bot 干活、外部的 Devon 负责改内部 bot，内部 bot 完全没有自改能力。他喜欢这种分离——像开车与掀开引擎盖是两件事，大部分时候引擎盖是关着的。他的追问是：什么时候你真的需要那种"它没经我同意就改了自己"的 AGI 时刻？
Alex 的反驳是：当你用外层 Agent 改内层 Agent 时，你信任的仍然是机器，不是你自己在改，你只是在指方向而已。两种方案对机器的信任程度是一样的，真正的区别在于——是外部系统检视内部系统，还是运行中的系统检视自己。
二、OpenClaw 的可扩展性是"窄"的
Alex 承认 OpenClaw 在 2 月的爆发确实发现了某种魔法：一个能适应你工作流的 Agent 系统。但他强调这种适应性是以非常特定、非常窄的方式实现的。
具体来说，OpenClaw 的架构里预留了若干可扩展点位。最动态的一处是 memory——本质上就是某个 markdown 文件，每次构造 LLM 调用时注入上下文，Agent 可以改这个文件。除此之外是 skill 和 tool：你可以让它去装一个 skill、加一个工具。但这些动作往往是人驱动的——人说"我想要一个做这个的 skill"，然后让 OpenClaw 去装。
在他展示的架构图上，标红的部分就是这些插件位：memory 插件、tool、skill、connector。他的主张是所有没标红的东西——所有连接的箭头、所有组件——都应该能被 Agent 改进。理由是 bitter lesson：模型越来越强，你不该让人来定死这些架构决策，模型自己知道针对给定任务该怎么搭 Agent。如果把 Exo 的架构画在旁边，"所有组件都要标红"。
他也顺带给出了"policy"的定义：Agent 本质上是被机器包裹的 LLM 调用，是一台巨大的上下文构造机，同时提供执行动作的通道。取最近 10 条还是 100 条消息、10 条加上前 90 条的摘要（也就是 compaction）、有哪些工具和 skill、它们怎么进入上下文——这些在 OpenClaw、PI、Claude Code 里都是写死的静态决策，而它们全都是 Exo 要让 Agent 自己改的东西。
三、三层架构：executor / harness / sandbox
Alex 先描述了今天的常态：Claude Code 既是 Agent 也是 harness，两者一起发货，然后被丢进一个环境里跑。他自己的典型工作流是开一台 VM、进去起 Claude、clone 仓库、用 GitHub 凭证登录，然后 dangerously-skip-permissions——他当场承认这有点危险，因为 VM 里确实有他的凭证和可能的密钥，唯一的安慰是"至少毁的不是我本机"。
Exo 的架构把 Agent 分解成三层：
Sandbox 是真正发生动作的环境。今天 Claude Code 与它编辑的代码跑在同一个环境里；Exo 把执行（比如跑一条 bash 命令）切到 sandbox，与 policy 进程分离，policy 可以跑在任何别处。
Exo harness 是有状态层，保存所有需要被保护、但 Agent 又要用的东西：会话历史、API key 之类的密钥、环境的 artifact 与快照。
Executor 装的是全部 policy，并且是完全无状态的进程——上下文怎么组装、prompt 是什么、compaction 怎么做、有哪些 skill 和工具，全在这里。
这个切分带来三件事：隔离的执行环境、被保护的状态、以及一个"可以安全自我进化的显式无状态层"。executor 可以提议改自己，而你不会丢失历史（历史在 harness 里）、不会泄露密钥（密钥不暴露给 LLM）。Alex 强调理解 Exo 最难的一点是：今天我们说的"一个 Agent"，在这里被拆成了 harness 里的会话历史（state）+ 正在跑的 policy（executor）+ 它运行其上的 sandbox，三者合起来才等于一个 Agent。
让 Exo 成为自我改进 Agent 的关键一步是：把 executor 自己的代码挂载进 sandbox。于是 LLM 的决策空间里就多了一项——"去改自己 harness 的某个部分"。exo harness 里有一个 guardian 进程，允许 executor 在运行时、甚至在一步的中途被重建并热替换；重建后有一个 soak 阶段，让它先走一步，如果把自己改崩了就自动回滚到上一个状态。主持人补充了一个观察：这种分离让改动具备原子性，因此提议的修改是可并行的。
四、Pokémon、Discord 与真实的自我改进
Alex 举的第一个例子是让 Exo 玩 Pokémon。运行过程中，系统自己决定去检查游戏的 RAM，并把内存映射出来——人类过去是手工逆向出这些的：内存里哪些位置存世界坐标、当前出战的 Pokémon、是否处于战斗中（就是些 boolean）。Exo 修改了自己与游戏的集成，把这些信息喂进 system message 来改善后续决策。他的论点是：外层 loop 只能"想一个设计、告诉它、启动、看效果、再反馈"，而自我进化的系统可以边跑边检视，用运行时的观察直接反哺自己的设计过程。
第二个例子更有说服力，因为它带来了可量化的收益。exo harness 的会话日志不只记录聊了什么，还给每条消息标注了成本。于是 executor 既能构造上下文，又能对过去的会话及其成本做推理。Alex 问 Exo："Discord adapter 里上一条消息花了多少钱？"回答是 16 美分。他说"你认真的吗？16 美分？去把它降下来。"Exo 在运行时重构了自己的 Discord adapter，做了修改、观察、测试，把每次 LLM 调用的上下文收窄到特定会话和特定线程，而不是跨线程抓取消息，成本下降约 96%。这次改动事后被人工 commit 回了代码库。
他坦承这里的成本压力是真实的：OpenClaw 组装上下文时塞了太多东西，他自己的账单被拉得很高。而前沿模型只会越来越大、越来越难服务、越来越贵。
五、评估、reward hacking 与"你到底想要什么"
主持人追问：这些自我改进是在"eval 无回归"的前提下做的吗？架构图上并没有一个叫 evals 的盒子——exo harness 是否应该自带 eval？
Alex 承认这是核心难题。所有优化问题的最终困难都在于你必须提供一个 evaluator，而它必须真实反映你的目标，否则要么没有信号可爬，要么系统自己找到一个信号但与你想要的不一致——后者是危险且隐蔽的失败模式。
他直接点出了一个很滑稽的失败模式：如果你让 Agent 优化成本，它完全可以选择"干脆不做这个任务"，因为那是最省钱的做法。主持人接话"这就是 reward hack"，Alex 确认，并说他们在 AI 驱动发现的研究里反复见到这种情况。
Discord 这个案例之所以简单，是因为性能指标近乎二值：你有没有回我消息？上下文里有没有足够信息让回答合理？换成一个要做决策的保险 Agent，你就需要 hold-out eval 集，或者与 Agent 协作构建它自己在运行时可调用的自检工具。他的结论是"向 Agent 说清楚你想要什么"仍是开放问题，接下来会在上下文里补更多工具，要求它在自我改进的同时也追踪并定义性能度量。（主持人顺势推销了一句 Braintrust 的 eval 能力，Ankur 正是 Braintrust 的人。）
六、teleportation、密钥与可中断性
teleportation。 主持人质疑这个卖点：经典的 teleport 需求就是"我想合上笔记本、把任务挪到云上"，而如果你要它常驻，一开始就该跑在服务器上。Alex 同意单 Agent 单任务时确实没什么必要，价值在规模化并行：假设一家公司为每个用户的使用日志起一个专属 Agent，用户进来产生事件流，你想让 Agent 对这个流做推理。100 个用户，100 个容器还能塞进一台机器；50000 个用户就塞不下了——policy 进程不用太多（只需少数几个同时醒着），但 sandbox 会大量被唤醒。这时就把一部分 sandbox 迁到 Daytona、E2B 之类的云上，或者直接在云上新建。主持人插了一段行业观察：Harbor（Terminal Bench 的作者）默认集成 Daytona 这一个推荐，正在带动 Daytona 相当一部分增长。
secret store。 密钥必须留在 exo harness、不直接暴露给 LLM。如果 Agent 和 API key 跑在同一个环境里，密钥就是完全可读、可外泄的。Exo 的做法是把密钥注入 executor，但不让它出现在工具能看到的容器空间里。两人还延伸讨论了访问日志：不仅要记录谁用了密钥，异常访问模式本身就该被监控——"如果我一个日常任务突然要我的 AWS key，那就是出事了"。主持人吐槽现状是把日志 pipe 进一个 Slack 频道让人盯着，"这听起来很糟糕"。Alex 的回应是：这个领域太新、这些系统太强，大家先用最省事、能跑通的方式榨取价值，但这肯定不是最终形态。
可中断性。 被问到实时/语音 Agent 时，Alex 说 Exo 已经给 Discord adapter 做了语音模式（Exo 还自带 Discord、IRC、WhatsApp 三个 adapter），但那还是 pipeline 级联，不是真正的交互式模型。他真正在意的是另一件事——OpenClaw 架构里一个让他很困扰的点：线程一旦开始干活就不可中断，你 ping 它不会回，你甚至不知道它在干什么，只能另开一个会话去问"隔壁那个线程到底怎么了"。他认为解法不在模型层而在系统层，会更像操作系统：把任务放后台、开 tmux 分屏，然后通过信号或 pub/sub 总线在完成时唤醒。主持人接了一句"我以为你要说 SIGINT"，Alex 说正是。
七、为什么 RSI 到今天才可能
节目末尾，Alex 主动补了一个"你没问但可以问"的问题：为什么他敢说这套架构下 RSI 才成为可能，之前不行？
他的答案是介质统一。过去 6 个月，迭代对象从模型权重转向了 harness 和 Agent 层。而 harness 只有几千行代码，LLM 输出的恰好也是代码——产出物与建造材料是同一种东西。反观改进 LLM 本身：那是改权重、是 delta、是反向传播和梯度下降；一个万亿参数模型，你没法把权重喂回它自己再问"你该怎么调整自己"，规模上就不成立，也进不了上下文。你可以问 LLM 要一些训练思路，但那不是同一介质。
他还特意区分了两个词：用计算机帮助设计下一代计算机，是 autocatalytic（自催化）——因为中间隔着物理芯片和布局这些层；而在 harness 层，被生产的代码和正在运行的代码是同一个东西，这才是完全的 self-recursive。主持人调侃"要真正完全自我改进，你得连模型都自己训"，Alex 承认那也只是自催化，介质仍不统一。主持人评价："你在这件事上很纯粹主义。"Alex 笑称这大概是学术界的毛病。
主持人把话题引向编程语言：这种"系统包含描述自身的构造"的性质，让人想起 Smalltalk 一类的抽象，PLT 的思路是能迁移过来的。Alex 认同，主持人补了一句"Lisp"，Alex 说 Lisp 确实立刻浮现在脑海里。他的结论是：飞轮时刻会来自"你迭代的层和你产出的层是同一层"。
八、三人组与项目现状
项目的起点是 Alex 那场《principles of autonomous system design》讲座——实际上是对 OpenClaw 的深度拆解，在社区获得不少反响。Martin Casado 也在 Berkeley 讲过一场 harness 未来走向的演讲，两人因此接上头；同时 Ankur Goyal 在 Braintrust 看到大量真实的 Agent 用法，也在想同样的问题。三人在会议室里从"这套架构该长什么样、需要哪些属性"开始聊，Ankur 先给出了分层架构的第一版。
前三四周三人主要在打磨 exo harness 本身（更多由 Ankur 驱动），之后 Alex 把重心转向自我改进——那是他研究的主场。他特别澄清了主持人开头那句玩笑（"VC 假装自己会写代码"）：Martin 是真的在日常写代码，"看 commit 就知道，我们三个都在里面"。
现状：exo harness 及其上的 Agent 已在 Braintrust 生产环境运行，代码在 github.com/exoharness/exo，有一行安装脚本的 quick start 和架构文档。ACP（Zed 提出的、用于抹平各家编码 Agent 差异的协议）他们还没做，Alex 认为现在是时候考虑互通性了。主持人对协议之争的评价是：通用协议永远是最小公分母，OpenClaw 直接接 PI 而不是兼容十种 Agent 反而更简单。
金句
"唯一的出路，是把这个循环塌缩下来，让系统自己负责改进自己。" —— Alex Krentsel 3:53
"你在用一个外层 Agent 改内层 Agent 的时候，你信任的仍然是机器。" —— Alex Krentsel 10:48
"如果你永远不想删掉历史，你必须在 harness 的架构里强制它，而不是在上下文里恳求 LLM 别删。" —— Alex Krentsel 14:40
"我问它上一条消息花了多少钱，16 美分。我说你认真的吗？去把它降下来。" —— Alex Krentsel 39:15
"它完全可以说：行，那我干脆不做了，这样最省钱。" —— Alex Krentsel 40:48
"harness 只有几千行代码，而我们的模型输出的正是同一种东西——代码。" —— Alex Krentsel 43:06
提到的书·产品·人物
- Exo（开源项目）：本期主角，一个完全递归自我改进的 Agent 及其 harness 架构，代码在 github.com/exoharness/exo。
- Alex Krentsel（人物）：UC Berkeley 系统方向博士生，Exo 作者之一，背景是 SDN 控制器架构与网络形式化验证。
- Martin Casado（人物）：a16z 合伙人、Nicira 创始人，Exo 共建者，被强调"真的在日常写代码"。
- Ankur Goyal（人物）：Braintrust 创始人，Exo 共建者，给出了分层架构的第一版设计。
- Sylvia Ratnasamy / Scott Shenker / Ion Stoica（人物）：Alex 在 Berkeley 的导师与合作者，Scott Shenker 也是 Martin Casado 的博士导师。
- Sky Lab / Sky Discover（研究项目）：Berkeley 的 AI 驱动发现系统研究，Exo 的思想源头。
- OpenClaw（产品）：被反复对标的 Agent 系统，可扩展点位有限且多由人驱动；上下文组装方式导致成本偏高、线程不可中断。
- Claude Code（产品）：作为"Agent 与 harness 一起发货、并与被编辑代码同环境运行"的典型例子。
- Braintrust（公司）：Ankur 的公司，exo harness 已在其生产环境运行，也是节目中调侃的 eval 供应商。
- Daytona / E2B（产品）：sandbox 云端 provider，Exo 已有多家集成；Daytona 因 Harbor 的默认集成获得可观增长。
- Harbor / Terminal Bench（产品）：Alex 此前做评估时接触，其默认集成 Daytona 的选择被认为在带动后者增长。
- ACP（协议）：Zed 提出的编码 Agent 归一化协议，Exo 尚未支持，被列为下一步候选。
- PI（产品）：OpenClaw 选择直接接入的对象，被用来说明"接一个具体实现比接通用协议更简单"。
- Pokémon（案例）：Exo 自主读取游戏 RAM、映射内存语义并接入 system message 的演示场景。
- Discord / IRC / WhatsApp（adapter）：Exo 自带的三个对外交互适配器，Discord 上还实现了语音模式。
- Lisp / Smalltalk（编程语言）：被用来类比"系统包含描述自身的构造"这一性质。
适合谁听
正在设计 Agent 框架或 harness 的工程师，以及关心自我改进系统安全边界与成本结构的技术决策者。