本文整理自 OpenAI Dominik Kundel 在 AI Engineer World’s Fair 的演讲。它真正值得看的地方，不是 Codex 又多了几个功能，而是 OpenAI 正在把 coding agent 的关键能力从“产品体验”下沉成一套可复用的 harness 与 Responses API 能力。原视频：https://www.youtube.com/watch?v=shRR1e2HXMk
Dominik 这场演讲讲的是 Codex，但更准确地说，它讲的是 coding agent 的控制层。
过去讨论 AI 写代码，很容易把焦点放到模型本身：哪个模型更聪明，哪次评测分数涨了，哪家上下文窗口更长。这个视频反而把视角移开了。Codex 真正被拆开的地方，是 UI、harness、模型推理、工具、沙箱、审批、压缩这些环节怎样接在一起。
这和我之前整理的 agent harness 知识线是一致的：生成能力已经不是唯一瓶颈。长程任务能不能稳定跑完，更多取决于模型外面那层系统有没有把上下文、权限、工具、状态、验证和治理组织好。
两条协议：UI 到 Harness，Harness 到模型
Codex 里有两条关键通道。
第一条是 App Server protocol，负责 UI 和 Codex harness 之间的通信。Codex App 自己也是跑在这套协议之上。OpenAI 把这层开出来，意思很明确：你可以不使用官方 UI，也能基于 Codex harness 做自己的 agent 界面。
第二条是 Responses API，负责 harness 和模型推理之间的通信。它不是 Chat Completions 的简单改名，而是按 agent 场景重新设计的接口：工具调用、web search、image generation、tool search、apply patch、WebSocket、server-side compaction 都属于这条线。
更关键的是，OpenAI 正在把 Responses API 做成开放 schema。Ollama、LM Studio、NVIDIA 等也参与了相关治理。换句话说，Codex 不是一个孤立产品，它也在定义“agent runtime 应该怎么和模型说话”。
上下文构造不是塞越多越好
Codex 发起一次任务时，第一步不是调用模型，而是构造上下文。Dominik 提到三个约束：大小、灵活性、成本。
上下文不是越大越好。塞太多内容不仅贵，还会把互相冲突的信息放进同一个窗口，反而让模型更混乱。Codex 的做法是把上下文分成稳定部分和不稳定部分。模型指令这类内容相对固定，容易缓存；技能列表、工具注册表、MCP 工具描述会随着用户环境变化，必须控制体积。
这里有两个具体设计值得记下来。
可用 skills 列表会被限制在总上下文窗口的 2% 以内。超过以后，描述会逐步压缩，而不是无限展开。
一部分工具会被标成 deferred loading，不直接塞进上下文。模型需要时再通过 tool search 发现它们。从 GPT-5.4 开始，Responses API 允许工具做这种延迟加载。对于装了很多 MCP、插件、内部工具的 agent 来说，这很实际：工具目录必须可检索，不能全量灌进 prompt。
Agent 的动作层：异步、电脑使用、文件系统
Codex 被称为 agent，不是因为它会说“我来帮你”，而是因为它能行动。演讲里重点讲了三类动作。
第一类是异步动作。比如 sub-agent 和 background terminal。主 agent 可以启动一个子 agent 或后台终端，然后继续做别的事；后续再向它发送 stdin、等待结果，或者关闭它。这类能力解决的是长任务里的并行和等待问题。
第二类是 computer use。早期 computer use 接口偏动作枚举：点一下、输入一下、截一张图。Codex 现在更倾向于让模型通过 code execution 脚本化操作。浏览器使用就是这样实现的：Codex 维护一个持久 Node REPL，让模型写 Playwright 代码去操作 Chromium。好处是它不只是“看一页点一下”，而是能理解页面结构，再对后续页面批量脚本化处理。
第三类是文件系统。OpenAI 的新模型已经按 apply_patch 这种文件编辑方式训练过，所以 Codex 会优先用 diff 改文件，用 shell 做搜索、构建、测试等操作。演讲里还提到 Codex harness 自带 ripgrep，因为模型训练里已经习惯用 rg 搜文件。Windows 上则训练模型原生使用 PowerShell。
这些细节看起来琐碎，但很说明问题：coding agent 的体验不是单靠模型“理解代码”做出来的，而是模型训练、工具接口和 harness 行为长期对齐出来的。
沙箱和自动审批：不是放权，而是把风险分类
文件系统操作都要经过沙箱。macOS 上 Codex 用 Seatbelt，Linux 上用 Bubblewrap，Windows 上 OpenAI 做了自己的开源 sandbox。
沙箱带来的一个老问题是 approval fatigue。长任务跑起来以后，如果每个动作都问人，用户迟早会开 full access。安全团队不喜欢，用户也不是真的更安全，只是被弹窗训练成了反射式批准。
Codex 的新方向是 auto review。它不是简单白名单，而是启动一个独立的自动审查 sub-agent。这个 sub-agent 只有只读权限，不能再启动别的 sub-agent。它会读取当前对话、工具调用、用户授权语境和风险分类，然后判断这次操作能不能自动通过。
这个例子很重要。删除文件本身不一定危险，关键是用户有没有授权、删除对象是什么、上下文里是否能解释这个动作。你让 agent 删除临时文件，和它未经要求删除 .git，风险完全不同。网络访问也一样，curl Google 测网络和上传本地文件不是一回事。
这就是 harness 里的治理层。安全不再只是“允许/拒绝”按钮，而是把动作、意图、影响和授权放在同一个判断里。
速度瓶颈开始从推理转向网络
Dominik 还讲了一个容易被忽略的点：模型越来越快以后，瓶颈会转移。
他们在 GPT-5.3 Codex Spark 上跑到 1000 tokens/s 后发现，慢的已经不只是 inference，而是多轮工具调用里的网络开销。于是 Responses API 引入 WebSocket mode，用持久连接替代 SSE/HTTP。更重要的是，它能发送 stateful delta：工具调用后只回传变化的 item，而不是把整串上下文项重新发一遍。
这说明 agent runtime 的性能优化会越来越像系统工程。模型速度、工具延迟、网络协议、状态同步都会影响体验。只盯 tokens/s 已经不够了。
Loop、Goal 和 Compaction：长程任务需要可验证的停止条件
演讲最后讲了 /goal 和 auto compaction。
/goal 的机制是 harness 自动注入 continuation prompt，让 agent 在目标未完成前继续执行。目标完成不是靠“感觉差不多”，而是模型调用 update_goal 之类的工具明确标记完成。
这也解释了为什么 goal 不能写成小作文。目标越具体、越可验证，harness 越容易判断任务是否结束。抽象愿望会让 agent 长时间漂移，具体验收条件才适合 loop。
auto compaction 解决的是另一件事：agent 跑几个小时甚至几天后，上下文窗口一定会满。Codex 会把历史对话压缩成一个 compaction item，供后续回合继续使用。关键点是，这不是随便摘要，而是模型训练时就适配过的 server-side compaction，所以性能不会突然掉太多。
这和我之前反复提到的 verification-first 是同一条线：长程 agent 不是让模型一直说下去，而是要有状态压缩、目标检查、轨迹保留和可恢复执行。
这场演讲真正给开发者的启发
如果只把 Codex 当成一个写代码工具，这场演讲的信息量会显得偏底层。可如果你正在做自己的 agent，它给的参考很直接。
工具不要全塞进上下文。用延迟加载和工具搜索，把工具目录变成可检索能力，而不是 prompt 负担。
权限不要只做静态开关。动作是否安全，要结合用户授权、操作对象、上下文意图和影响范围判断。
浏览器和电脑使用不要停留在“逐步点击”。能脚本化就脚本化，让模型用代码操控环境，效率会高很多。
长程任务必须有 goal、trace、compaction 和恢复机制。没有这些，agent 只能做短跑；一旦任务变长，就会丢状态、误判完成、或者把人拖回流水线。
最重要的一点是：Responses API 正在把很多 Codex 产品能力下沉为可复用接口。tool search、apply patch、WebSocket、server-side compaction 这些东西，不只是 Codex 的功能，而是 OpenAI 对下一代 agent harness 的接口判断。
模型会继续变强，但 harness 不会消失。真正会消失的是那些补模型短板的临时脚手架；留下来的，是上下文、工具、权限、验证、治理这些控制层。Codex 这场演讲把这件事讲得很具体。
