过去几年，大语言模型（LLM）竞争的核心是参数规模、训练数据、推理能力和基准测试分数；但进入2026年下半年，一个越来越明显的变化正在发生：模型本身正在从竞争的全部，变成Agent系统中的一个核心组件，而决定模型能否真正完成复杂任务的另一半，是围绕模型构建的Agent Harness。 DeepSeek近期开源DeepSeek Harness，而OpenAI此前已经持续开源Codex CLI并公开其Codex Harness和App Server架构。这意味着大模型竞争正在从“谁的模型更强”逐渐扩展到“谁能构建更强的模型运行环境”。

这里需要特别澄清，“Codex Harness开源”与DeepSeek Harness的开源方式并不完全相同。DeepSeek直接发布了独立的DeepSeek Harness项目，目前采用MIT许可证；OpenAI则将Codex Harness的核心Agent逻辑包含在开源的Codex CLI代码库中，该仓库采用Apache-2.0许可证。OpenAI称，Codex Core同时承担Agent Loop运行时和单个线程的持久化管理，并通过App Server向CLI、IDE、Web以及其他客户端提供统一能力。

DeepSeek Harness的最大特点是“一切皆插件”。 其底层Cordis内核主要负责插件加载、卸载和依赖管理，模型、工具、Skills、Session、Sandbox、Storage、Agent Loop、调度乃至UI都被设计成可以组合、替换的插件。开发者可以通过配置改变Agent的能力组合，而无需修改Harness主体代码。DeepSeek同时提供Standard、PTC、Minimal和Creator等运行模式，其中PTC模式允许模型通过生成TypeScript程序，把多个工具调用组合到一次程序执行中，从而减少传统“模型—工具—结果—模型”的频繁往返。

另一个值得关注的设计是Trajectory，即完整的Agent运行轨迹。DeepSeek Harness把模型看到的系统提示、工具调用及结果、上下文注入以及子Agent调度等信息写入追加式会话日志，并以此支持恢复、分叉、检索和回放。这使Agent从一次性的聊天程序变成了具有状态、历史和可调试运行轨迹的软件系统。

相比之下，Codex的路线更强调Agent Loop、执行环境和客户端之间的标准化。 OpenAI把Codex Harness视为所有Codex产品背后的共同运行时，包括Web、CLI、IDE和桌面应用。其Codex Core负责Agent Loop、线程生命周期、持久化、工具执行和扩展，而App Server则通过双向JSON-RPC接口，让不同客户端共享同一套Agent能力。

更值得注意的是OpenAI最近提出的“Harness Engineering”。其内部实验显示，在一个完全由Codex生成和维护代码的项目中，人类工程师的主要工作已经从“写代码”转向设计Agent能够理解和验证的环境，包括清晰的代码结构、AGENTS.md、结构化文档、自动化测试、CI、日志、指标、浏览器控制以及可执行的反馈闭环。OpenAI甚至报告，一个内部产品在约五个月内形成了约100万行代码，团队的工程效率显著提高。需要强调的是，这属于OpenAI自身工程实践的披露，并非独立第三方基准，因此更适合作为趋势证据而非普遍性能结论。

两种架构实际上代表了两条互补路线：DeepSeek更强调Harness本身的模块化、可组合性和开放生态，OpenAI则更强调成熟Agent运行时、客户端协议以及让软件工程环境本身“Agent可读、可验证、可操作”。前者试图建立开放的Agent基础设施，后者则在探索如何把Agent嵌入真实的软件生产系统。

这意味着未来LLM竞争的评价维度也会发生变化。过去的问题是“模型能不能回答正确”，未来越来越重要的问题将变成：模型能否长期保持任务状态？能否正确选择工具？能否在错误