拆解 Codex Harness：让长程智能体可靠运行的工程设计
原题Codex， Behind the Harness — Dominik Kundel， OpenAI
推荐理由Dominik Kundel 以开源 Codex Harness 为样本，拆解模型如何通过应用服务器、Responses API、延迟加载工具、异步子 Agent、沙箱和上下文压缩变成可持续运行的产品。独立只读审查 Agent 负责检查授权与风险，持久 WebSocket 则在模型加速后减少网络传输开销。这场演讲把 Harness 展开为一套围绕 Agent 的可靠性架构，远比模型外面的一层薄包装更完整。对自建 Agent 的团队，它也提供一份排查清单：上下文成本、并发、文件隔离、传输和目标完成条件都需要独立设计。
看前速览
这场技术演讲以开源 Codex harness 为例，说明协议设计、上下文管理、异步协作、安全审查、传输机制与压缩策略如何让长时间运行的智能体真正可用。
Harness 是一层架构，而不只是模型封装。
演讲区分了连接 UI 与 harness 的应用服务器，以及连接 harness 与推理服务的 Responses API，并将兼容性视为生态系统设计问题。
上下文构建需要明确的成本与可靠性控制。
延迟加载工具和工具搜索让低频定义不必一开始就进入上下文窗口，而受限的技能列表也能控制 MCP 等能力带来的持续膨胀。
实用的智能体需要并发执行，同时不能失去编排能力。
主智能体可以把工作委托给子智能体或后台终端，并在任务变化时继续推进其他工作、发送补充输入、等待结果或停止执行。
安全审查应当理解上下文，并与实际执行隔离。
自动审查智能体仅具备只读权限，会独立评估授权、风险分类和拟执行的工具操作，既降低审批疲劳，也避免不安全的权限升级。
长程智能体的性能取决于传输机制和完成语义。
持久 WebSocket 避免重复发送未变化的状态；续行提示、显式完成工具和服务端上下文压缩，则让长时间、目标驱动的执行更可控。
完整摘要
Dominik Kundel 将 Codex harness 作为构建智能体产品的具体参考实现：应用服务器负责连接 UI 与 harness，Responses API 则负责连接 harness 与推理服务。他逐一拆解 harness 必须应对的工程问题：通过延迟加载工具与工具搜索抑制不可预测的上下文膨胀；借助异步子智能体和后台终端完成并发工作；再以沙箱协调文件系统操作。演讲最有价值的部分在于安全与可用性的结合：只读的自动审查子智能体会独立评估授权范围、风险类别和敏感操作，避免团队在便利性压力下默认给予无限制权限。随着推理变快，网络传输会成为瓶颈，因此系统采用持久 WebSocket 仅传递增量变化。最后，目标循环、可检测的完成条件与服务端上下文压缩，共同支撑跨越长上下文的持续执行。
文字稿
Codex, Behind the Harness
Dominik Kundel’s talk is a compact engineering tour of the Codex harness: the layer that turns a model into an agent experience. His core point is that the harness is open source and can be studied, extended, or used as a blueprint by teams building their own agent interfaces.
The architecture begins with two protocols. The app server carries requests from a user interface into the harness. The Responses API handles communication from the harness to model inference and exposes capabilities needed by agents, including tool use. Kundel stresses that both layers are designed for an open ecosystem, so compatible UIs, harnesses, and model providers can participate.
Much of the practical work is context construction. A harness has to balance context size, flexibility, and cacheability. Codex uses deferred tools and tool search so that rarely needed tool descriptions do not consume the initial context window. The talk then moves through the actions that make an agent useful: asynchronous subagents, background work, browser control through a persistent Node environment, and filesystem changes made through tools such as an apply-patch workflow.
Safety and speed are recurring constraints. Sandbox layers mediate filesystem actions, while auto review uses a separate read-only subagent to assess authorization and risk for sensitive actions. As models become faster, network overhead can become a bottleneck; a persistent WebSocket mode reduces repeated data transfer by sending changed information and tool results incrementally.
Finally, Kundel explains goal loops and compaction. A continuation prompt keeps the objective present until the model reports completion through an update tool, which is why concrete and verifiable goals matter. For long-running agents, automatic server-side compaction preserves the useful context in a new window. The closing takeaway is straightforward: learn from the open-source app server and harness, use the Responses API capabilities directly where they fit, and keep adapting as the models and platform evolve.