摘要
本次调研沿 Exo 当前源码追踪了 --harness 从 CLI 解析、Agent 配置持久化、Rust Executor 装配、宿主机 TypeScript Runner 到 Codex Sandbox 进程的完整路径，并区分了 Exo 用户侧 REPL 与 Prime Agent 模型侧持久 IPython REPL。结果表明，Codex 等内置名称是 TypeScript preset 而非底层独立 Harness 类型；Exo 的核心差异在可信状态底座与可替换 Executor，而 Prime Agent 更侧重可编程上下文和 RLM。（来源：原始调研记录（本地存档））
核心内容
- Exo 将事件、Secret、Artifact 与 Sandbox 生命周期放在
ExoHarness，将 Prompt、工具和控制流放在可替换 Executor；“递归自我改进”主要发生在非参数 Harness 层。（来源：原始调研记录（本地存档）） - 持久枚举只有 Basic、RLM、TypeScript 与 Exo。
codex、claude-code、cursor、pi是 CLI 对 TypeScript 模块、Sandbox 镜像和网络默认值的硬编码组合。（来源：同上，“--harness的真实实现”） - Agent 的 Executor 配置作为版本化
config/executor.jsonArtifact 保存；--harness对已有 Agent 是选择与一致性检查，不是临时覆盖。（来源：同上） - TypeScript Runner 是宿主机 Node 进程，通过逐行 JSON 与 Rust 通信；真正的 Codex App Server 再运行于 Exoharness Sandbox。自定义 TypeScript Harness 因此属于可信宿主代码。（来源：同上，“Rust 与 TypeScript 的进程桥”）
exo repl是用户入口；Prime Agent 的 IPython REPL 是模型的可编程行动空间。两者都保留长期状态，但分别采用 substrate-first 与 RLM-first 的设计重心。（来源：同上，“Exo 与 Prime Agent”）- Exo 自带的 RLM Executor 比 Codex preset 更接近 Prime Agent，但当前使用每轮重建的 Boa JavaScript 状态和一次性
subquery，尚不具备 Prime Agent 的持久 Kernel 与长期子 Agent。（来源：同上） - 本机具备 Docker 等基础条件，但 Rust 版本低于仓库要求，且 setup 脚本只检查命令存在性；正式安装应先用仓库级
mise工具链规避版本误判。（来源：同上，“本地安装可行性快照”）
相关页面
- 概念：Harness Engineering、Self-Improving Harness、Recursive Self-Improvement
- 实体：Exo、Prime Agent、Codex
- 主题：LLM Agent Self-Improvement、Agent Harness 与 Agentic RL 开源生态
来源
- 原始文件：原始资料（本地存档）
- Exo 源码快照：
exoharness/exo@7801005e - 官方仓库与文档核实日期：2026-09-03
待核实问题
- 尚未本地构建或运行 Exo，安装脚本的工具链版本误判仍需端到端复现。
- 尚未在统一任务、模型和预算下比较 Exo、Exo+Codex、Exo RLM 与 Prime Agent。
- 项目 API 与
main分支仍快速变化，模块路径、Provider 和历史恢复行为需在安装时按锁定提交复核。