尧图网站建设 
OpenInterpreter 远程执行器集成测试指南app-server/exec-server 拆分下的 Docker 与 Wine 双环境测试【免费下载链接】openinterpreterA coding agent for open models like Kimi K3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter本篇指南围绕 OpenInterpreter基于 codex-rs 的开源编码智能体仓库中的远程测试技能文档 SKILL.md 展开。远程执行器测试remote executor tests用于验证 app-server 与 exec-server 的拆分架构确保智能体功能在本地与远程两种执行环境中都能正常工作。读完本文你将掌握如何用 Docker 容器和 Wine 两种方式拉起远程 exec-server 并运行核心/app-server 集成测试如何在测试用例中通过auto_env系列 fixture 显式接入远程执行环境以及如何按失败原因正确选择 5 个测试跳过宏。为什么需要远程执行器测试OpenInterpreter 采用 app-server应用侧、协议侧与 exec-server执行侧、命令与文件系统执行的拆分架构。这一拆分意味着智能体的一次工具调用可能发生在与 app-server 完全不同的机器和操作系统上。远程执行器测试正是为这一架构量身定制的集成测试层它们验证 agent 的各类特性文件访问、命令执行、工作区根目录、审批路径等在“本地执行”和“远程执行”两种模式下行为一致。按 remote-tests 技能文档 的说明这些测试目前要求x86_64 Linux 宿主机共有两种形态flavorDockerLinux exec-server在宿主机上通过 Docker 容器运行远程执行端WineWindows exec-server把为 Windows 交叉编译的 exec-server 跑在 Wine 下而 app-server 仍留在 Linux 宿主机上。测试环境选择机制从环境变量到目标操作系统在理解 fixture 之前先看测试框架如何判定当前运行在哪种环境中。环境判定逻辑位于 test_environment.rs核心是解析环境变量CODEX_TEST_ENVIRONMENT环境变量取值测试环境目标操作系统说明未设置Local宿主机 OS本地临时环境localLocal宿主机 OS显式本地dockerDocker { container_name }Linux需配合容器名变量wine-execWineExecWindows仅支持 Linux 宿主源码中的硬性 panic 校验相关的三个环境变量定义见 test_environment.rsCODEX_TEST_ENVIRONMENT主开关取值local/docker/wine-execCODEX_TEST_REMOTE_ENV遗留legacy变量单独设置时等价于选择 Docker 环境并直接给出容器名CODEX_TEST_REMOTE_ENV_CONTAINER_NAMEDocker 环境下指定的容器名。解析函数 parse_test_environment 还负责校验取值合法性与 UTF-8 非空。值得注意的是目标工作目录cwd的约定差异remote_cwdDockerfile:///tmp/codex-core-test-cwd-{instance_id}POSIX 约定WineExecfile:///C:/codex-core-test-cwd-{instance_id}Windows 约定。每个 Wine-exec 测试进程拥有隔离的文件系统根因此该驱动器根路径不会与其他 Bazel 分片冲突。当环境为远程时test_env() 会通过codex_exec_server::Environment::create_for_tests以CODEX_TEST_REMOTE_EXEC_SERVER_URL指定的 WebSocket 地址连接远程执行端并自动在远端创建测试工作目录最终组装出TurnEnvironmentSelection含environment_id为REMOTE_ENVIRONMENT_ID的选择项。Wine 场景下还保留了一套/C:/...的 Linux 绝对路径兼容写法以便测试夹具的AbsolutePathBuf与PathUri之间往返转换。测试夹具显式接入远程执行器remote-tests 文档明确指出单个测试用例必须显式选择opt-in在远程执行器上运行。这样做的目的是让绝大多数用例默认保持本地快速运行只有被标记的用例才进入 Docker/Wine 环境。codex_core 侧build_with_auto_env在 core 集成测试中使用TestCodexBuilder::build_with_auto_env()即可选择由测试进程环境变量自动决定的执行环境只有当测试需要对执行器做更精细控制时才自行构建。其实现位于 test_codex.rs/// Builds a test runtime using the execution environment selected by the test process. /// /// With no remote test configuration, or with CODEX_TEST_ENVIRONMENTlocal, this uses a /// temporary local environment just like [Self::build]. CODEX_TEST_ENVIRONMENTdocker or /// CODEX_TEST_ENVIRONMENTwine-exec selects the remote exec server configured by /// CODEX_TEST_REMOTE_EXEC_SERVER_URL; the legacy CODEX_TEST_REMOTE_ENV Docker-container /// configuration does the same. Only the automatically selected environment is registered. /// Use [Self::build_with_remote_and_local_env] when a remote test also needs the local /// environment to be selectable explicitly. pub async fn build_with_auto_env( mut self, server: wiremock::MockServer, ) - anyhow::ResultTestCodex { ... }从实现可以看到两个关键点“auto”语义来自test_env()——本地环境时行为与build完全一致临时本地目录远程环境时则连接远端 exec-serverauto_env方式只注册自动选中的那一个环境。如果某个远程测试还需要显式选择本地环境应改用姊妹方法 build_with_remote_and_local_env其include_local_environment参数为true。core 侧大量集成测试如 remote_env.rs、workspace_roots.rs 等都以这种 opt-in 方式接入。app-server 侧new_with_auto_env与send_thread_start_request_with_auto_envapp-server 集成测试的接入分两步见 remote-tests 文档除非测试自己定义了$CODEX_HOME/environments.toml、或需要在运行时定义自定义环境否则用TestAppServer::new_with_auto_env()启动服务器启动线程thread时使用TestAppServer::send_thread_start_request_with_auto_env()并且必须省略ThreadStartParams.environments保持None。第 2 点在源码中有强制校验send_thread_start_request_with_auto_env 会在调用方试图覆盖夹具环境时直接报错pub async fn send_thread_start_request_with_auto_env( mut self, mut params: ThreadStartParams, ) - anyhow::Resulti64 { ensure!( params.environments.is_none(), send_thread_start_request_with_auto_env requires params.environments to be omitted ); params.environments Some(vec![self.auto_env_params()?]); self.send_thread_start_request(params).await }这里auto_env_params()会从夹具保留的自动环境中取出TurnEnvironmentParamsenvironment_id、cwd、runtime_workspace_roots保证线程启动时选中的正是当前测试进程选定的环境。此外start_thread()这类便捷方法内部默认就走 auto-env 路径test_app_server.rsapp-server 的 v2 测试套件tests/suite/v2/中几乎所有线程类用例都以此方式运行。测试跳过宏按“失败原因”选择当某个测试在特定的远程执行器配置下无法通过时应该只在那种配置中跳过它并在宏支持时附上字符串原因方便后续读者理解。remote-tests 文档给出的选择原则是“按导致测试失败的原因选宏”跳过宏适用场景判定条件源码skip_if_target_windows!Windows目标行为导致的失败test_target_os() Windows即远程执行端是 Windowslib.rsskip_if_wine_exec!Wine 执行器运行器自身的限制is_wine_exec_test_environment()lib.rsskip_if_host_windows!Windows宿主限制编译期cfg!(target_os windows)lib.rsskip_if_remote!只能本地运行的行为本地专属is_remote_test_environment()lib.rsskip_if_no_remote_env!只能在远程运行的行为远程专属!is_remote_test_environment()lib.rs这些宏支持两种形式仅原因参数或($return_value, $reason)双参数形式便于非fn上下文中提前返回具体值。例如skip_if_no_remote_env!()在无远程环境时打印Skipping test because it requires a remote test environment.并直接返回。core 模块的 README 也收录了同一份对照表并给出了三种环境的对应关系Local 指向宿主 OS、Docker 指向 Linux、Wine exec 指向 Windows。文档同时提醒优先编写能在所有 host/target 配置下运行的测试要让路径相关测试跨配置兼容可参考 path-types 技能 中列出的常见改动。Docker 形态脚本化搭建 Linux 远程执行端Docker 形态的容器由 scripts/test-remote-env.sh 构建并初始化。按 remote-tests 文档 的用法说明在 bash 中 source 该脚本脚本本身会检测直接执行并拒绝见 第 142-145 行source 完成后还会获得测试结束时应调用的codex_remote_env_cleanup函数。脚本 setup_remote_env 的完整工作流程前置检查docker可用且守护进程可达Colima 需先colima start、cargo可用构建二进制在codex-rs下执行cargo build -p codex-cli --bin codex产物取自${CARGO_TARGET_DIR:-codex-rs/target}/debug/codex启动容器ubuntu:24.04、--privileged、--security-opt seccompunconfined在 Linux 宿主上加--network host因为远程集成测试使用的托管网络代理监听在 Linux runner 的环回接口上共享宿主网络命名空间才能让远端执行器走真实的审批/拒绝路径而非超时Docker Desktop 无相同语义故 macOS 本地保留 bridge 网络安装依赖apt-get install -y python3 zsh bubblewrap其中 bubblewrap 需要容器内的 mount 传播这正是需要--privileged的原因拉起 exec-server把codex二进制拷入容器/tmp/codex-remote-env/以codex exec-server --listen ws://0.0.0.0:31987后台启动并用 python3 socket 探测 31987 端口直至就绪wait_for_remote_exec_server_port5 秒超时导出环境变量CODEX_TEST_REMOTE_EXEC_SERVER_URLws://容器IP:31987、CODEX_TEST_REMOTE_ENV、CODEX_TEST_REMOTE_ENV_CONTAINER_NAME、CODEX_TEST_ENVIRONMENTdocker。宿主机上 host 网络模式下容器 IP 取127.0.0.1bridge 模式下用docker inspect取实际 IP。codex_remote_env_cleanup 则会docker rm -f删除容器并清空上述所有环境变量。文档给出的两条标准运行命令core 与 app-server 各一条应当原样可用运行core 集成测试对 Docker 远程执行器bash -c set -euo pipefail unset CODEX_TEST_REMOTE_EXEC_SERVER_URL source scripts/test-remote-env.sh trap codex_remote_env_cleanup EXIT cd codex-rs just test -p codex-core --test all 运行app-server 集成测试对 Docker 远程执行器bash -c set -euo pipefail unset CODEX_TEST_REMOTE_EXEC_SERVER_URL source scripts/test-remote-env.sh trap codex_remote_env_cleanup EXIT cd codex-rs just test -p codex-app-server --test all 两个细节值得注意其一开头的unset CODEX_TEST_REMOTE_EXEC_SERVER_URL确保脚本按“自建”模式拉起容器并生成新的 URL而不是指向一个可能已失效的旧远端其二trap codex_remote_env_cleanup EXIT保证无论测试成功与否退出时都会清理容器避免残留。脚本头部注释还给出了一个最小验证用例just test -p codex-core --test all remote_test_env_can_connect_and_use_filesystem可用于确认远程环境搭建成功。Wine 形态Bazel 下的 Windows 远程执行端Wine 形态会构建一个 Windows 版 exec-server 并在 Wine 下运行它app-server 留在 Linux 宿主机。由于涉及跨平台交叉编译依赖这些测试只能在 Bazel 中运行remote-tests 文档。运行命令core 集成测试bazel test //codex-rs/core:core-all-wine-exec-testapp-server 集成测试bazel test //codex-rs/app-server:app-server-all-wine-exec-test从源码结构看这条链路的执行者是 wine_remote_test_runner.rsBazel 构建目标定义在 testing/BUILD.bazel 的wine-exec-test-runner从环境变量CODEX_WINE_EXEC_TEST_BINARY读取真实测试二进制路径该变量由 Bazel 测试规则注入若是--list --format terse请求直接透传给测试二进制以支持 Bazel 的测试枚举否则通过WineExecServer::scope在 Wine 前缀中启动 Windows 版 exec-server拿到exec_server_url后以CODEX_TEST_ENVIRONMENTwine-exec、CODEX_TEST_REMOTE_EXEC_SERVER_URLurl运行测试二进制并显式移除CODEX_TEST_REMOTE_ENV与CODEX_TEST_REMOTE_ENV_CONTAINER_NAME两个遗留 Docker 变量避免环境判定串扰wine_remote_test_runner.rs。测试进程启动后test_environment()依据CODEX_TEST_ENVIRONMENTwine-exec将其识别为WineExec环境目标 OS 记为 Windows——这就是为什么同一份集成测试代码在三种形态下只需按skip_if_*宏做少量条件分支即可。在 macOS 上通过 Devbox 运行如果你日常开发机是 macOSremote-tests 文档给出的替代方案是使用 devbox内部 Linux 开发机用applied_devbox ls列出 devbox选择名字中包含codex的那台ssh devbox_name连接复用 devbox 上~/code/codex的同一份 checkout多个 checkout 会拉长构建时间、占用更多磁盘需要时先重置文件操作前检查本地与远端的 SHA 及修改文件是否同步。连上之后即可按上文 Docker/Wine 小节的标准命令运行测试。小结远程执行器测试体系的关键约束与入口可以归纳为前提x86_64 Linux 宿主Docker 形态或 Bazel 构建环境Wine 形态入口脚本scripts/test-remote-env.shDockersource 使用退出时codex_remote_env_cleanupBazel 目标//codex-rs/core:core-all-wine-exec-test、//codex-rs/app-server:app-server-all-wine-exec-testWineopt-in 夹具core 侧TestCodexBuilder::build_with_auto_env()app-server 侧TestAppServer::new_with_auto_env()send_thread_start_request_with_auto_env()须省略ThreadStartParams.environments跳过宏按失败原因选择skip_if_target_windows!/skip_if_wine_exec!/skip_if_host_windows!/skip_if_remote!/skip_if_no_remote_env!并优先写全配置通用的测试路径兼容可参考 path-types 技能。相关源码与文档索引remote-tests 技能、core 测试公共库、环境判定、core 测试夹具、app-server 测试夹具、Wine 测试运行器、core README。【免费下载链接】openinterpreterA coding agent for open models like Kimi K3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenInterpreter 远程执行器集成测试指南：app-server/exec-server 拆分下的 Docker 与 Wine 双环境测试
OpenInterpreter 远程执行器集成测试指南app-server/exec-server 拆分下的 Docker 与 Wine 双环境测试【免费下载链接】openinterpreterA coding agent for open models like Kimi K3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter本篇指南围绕 OpenInterpreter基于 codex-rs 的开源编码智能体仓库中的远程测试技能文档 SKILL.md 展开。远程执行器测试remote executor tests用于验证 app-server 与 exec-server 的拆分架构确保智能体功能在本地与远程两种执行环境中都能正常工作。读完本文你将掌握如何用 Docker 容器和 Wine 两种方式拉起远程 exec-server 并运行核心/app-server 集成测试如何在测试用例中通过auto_env系列 fixture 显式接入远程执行环境以及如何按失败原因正确选择 5 个测试跳过宏。为什么需要远程执行器测试OpenInterpreter 采用 app-server应用侧、协议侧与 exec-server执行侧、命令与文件系统执行的拆分架构。这一拆分意味着智能体的一次工具调用可能发生在与 app-server 完全不同的机器和操作系统上。远程执行器测试正是为这一架构量身定制的集成测试层它们验证 agent 的各类特性文件访问、命令执行、工作区根目录、审批路径等在“本地执行”和“远程执行”两种模式下行为一致。按 remote-tests 技能文档 的说明这些测试目前要求x86_64 Linux 宿主机共有两种形态flavorDockerLinux exec-server在宿主机上通过 Docker 容器运行远程执行端WineWindows exec-server把为 Windows 交叉编译的 exec-server 跑在 Wine 下而 app-server 仍留在 Linux 宿主机上。测试环境选择机制从环境变量到目标操作系统在理解 fixture 之前先看测试框架如何判定当前运行在哪种环境中。环境判定逻辑位于 test_environment.rs核心是解析环境变量CODEX_TEST_ENVIRONMENT环境变量取值测试环境目标操作系统说明未设置Local宿主机 OS本地临时环境localLocal宿主机 OS显式本地dockerDocker { container_name }Linux需配合容器名变量wine-execWineExecWindows仅支持 Linux 宿主源码中的硬性 panic 校验相关的三个环境变量定义见 test_environment.rsCODEX_TEST_ENVIRONMENT主开关取值local/docker/wine-execCODEX_TEST_REMOTE_ENV遗留legacy变量单独设置时等价于选择 Docker 环境并直接给出容器名CODEX_TEST_REMOTE_ENV_CONTAINER_NAMEDocker 环境下指定的容器名。解析函数 parse_test_environment 还负责校验取值合法性与 UTF-8 非空。值得注意的是目标工作目录cwd的约定差异remote_cwdDockerfile:///tmp/codex-core-test-cwd-{instance_id}POSIX 约定WineExecfile:///C:/codex-core-test-cwd-{instance_id}Windows 约定。每个 Wine-exec 测试进程拥有隔离的文件系统根因此该驱动器根路径不会与其他 Bazel 分片冲突。当环境为远程时test_env() 会通过codex_exec_server::Environment::create_for_tests以CODEX_TEST_REMOTE_EXEC_SERVER_URL指定的 WebSocket 地址连接远程执行端并自动在远端创建测试工作目录最终组装出TurnEnvironmentSelection含environment_id为REMOTE_ENVIRONMENT_ID的选择项。Wine 场景下还保留了一套/C:/...的 Linux 绝对路径兼容写法以便测试夹具的AbsolutePathBuf与PathUri之间往返转换。测试夹具显式接入远程执行器remote-tests 文档明确指出单个测试用例必须显式选择opt-in在远程执行器上运行。这样做的目的是让绝大多数用例默认保持本地快速运行只有被标记的用例才进入 Docker/Wine 环境。codex_core 侧build_with_auto_env在 core 集成测试中使用TestCodexBuilder::build_with_auto_env()即可选择由测试进程环境变量自动决定的执行环境只有当测试需要对执行器做更精细控制时才自行构建。其实现位于 test_codex.rs/// Builds a test runtime using the execution environment selected by the test process. /// /// With no remote test configuration, or with CODEX_TEST_ENVIRONMENTlocal, this uses a /// temporary local environment just like [Self::build]. CODEX_TEST_ENVIRONMENTdocker or /// CODEX_TEST_ENVIRONMENTwine-exec selects the remote exec server configured by /// CODEX_TEST_REMOTE_EXEC_SERVER_URL; the legacy CODEX_TEST_REMOTE_ENV Docker-container /// configuration does the same. Only the automatically selected environment is registered. /// Use [Self::build_with_remote_and_local_env] when a remote test also needs the local /// environment to be selectable explicitly. pub async fn build_with_auto_env( mut self, server: wiremock::MockServer, ) - anyhow::ResultTestCodex { ... }从实现可以看到两个关键点“auto”语义来自test_env()——本地环境时行为与build完全一致临时本地目录远程环境时则连接远端 exec-serverauto_env方式只注册自动选中的那一个环境。如果某个远程测试还需要显式选择本地环境应改用姊妹方法 build_with_remote_and_local_env其include_local_environment参数为true。core 侧大量集成测试如 remote_env.rs、workspace_roots.rs 等都以这种 opt-in 方式接入。app-server 侧new_with_auto_env与send_thread_start_request_with_auto_envapp-server 集成测试的接入分两步见 remote-tests 文档除非测试自己定义了$CODEX_HOME/environments.toml、或需要在运行时定义自定义环境否则用TestAppServer::new_with_auto_env()启动服务器启动线程thread时使用TestAppServer::send_thread_start_request_with_auto_env()并且必须省略ThreadStartParams.environments保持None。第 2 点在源码中有强制校验send_thread_start_request_with_auto_env 会在调用方试图覆盖夹具环境时直接报错pub async fn send_thread_start_request_with_auto_env( mut self, mut params: ThreadStartParams, ) - anyhow::Resulti64 { ensure!( params.environments.is_none(), send_thread_start_request_with_auto_env requires params.environments to be omitted ); params.environments Some(vec![self.auto_env_params()?]); self.send_thread_start_request(params).await }这里auto_env_params()会从夹具保留的自动环境中取出TurnEnvironmentParamsenvironment_id、cwd、runtime_workspace_roots保证线程启动时选中的正是当前测试进程选定的环境。此外start_thread()这类便捷方法内部默认就走 auto-env 路径test_app_server.rsapp-server 的 v2 测试套件tests/suite/v2/中几乎所有线程类用例都以此方式运行。测试跳过宏按“失败原因”选择当某个测试在特定的远程执行器配置下无法通过时应该只在那种配置中跳过它并在宏支持时附上字符串原因方便后续读者理解。remote-tests 文档给出的选择原则是“按导致测试失败的原因选宏”跳过宏适用场景判定条件源码skip_if_target_windows!Windows目标行为导致的失败test_target_os() Windows即远程执行端是 Windowslib.rsskip_if_wine_exec!Wine 执行器运行器自身的限制is_wine_exec_test_environment()lib.rsskip_if_host_windows!Windows宿主限制编译期cfg!(target_os windows)lib.rsskip_if_remote!只能本地运行的行为本地专属is_remote_test_environment()lib.rsskip_if_no_remote_env!只能在远程运行的行为远程专属!is_remote_test_environment()lib.rs这些宏支持两种形式仅原因参数或($return_value, $reason)双参数形式便于非fn上下文中提前返回具体值。例如skip_if_no_remote_env!()在无远程环境时打印Skipping test because it requires a remote test environment.并直接返回。core 模块的 README 也收录了同一份对照表并给出了三种环境的对应关系Local 指向宿主 OS、Docker 指向 Linux、Wine exec 指向 Windows。文档同时提醒优先编写能在所有 host/target 配置下运行的测试要让路径相关测试跨配置兼容可参考 path-types 技能 中列出的常见改动。Docker 形态脚本化搭建 Linux 远程执行端Docker 形态的容器由 scripts/test-remote-env.sh 构建并初始化。按 remote-tests 文档 的用法说明在 bash 中 source 该脚本脚本本身会检测直接执行并拒绝见 第 142-145 行source 完成后还会获得测试结束时应调用的codex_remote_env_cleanup函数。脚本 setup_remote_env 的完整工作流程前置检查docker可用且守护进程可达Colima 需先colima start、cargo可用构建二进制在codex-rs下执行cargo build -p codex-cli --bin codex产物取自${CARGO_TARGET_DIR:-codex-rs/target}/debug/codex启动容器ubuntu:24.04、--privileged、--security-opt seccompunconfined在 Linux 宿主上加--network host因为远程集成测试使用的托管网络代理监听在 Linux runner 的环回接口上共享宿主网络命名空间才能让远端执行器走真实的审批/拒绝路径而非超时Docker Desktop 无相同语义故 macOS 本地保留 bridge 网络安装依赖apt-get install -y python3 zsh bubblewrap其中 bubblewrap 需要容器内的 mount 传播这正是需要--privileged的原因拉起 exec-server把codex二进制拷入容器/tmp/codex-remote-env/以codex exec-server --listen ws://0.0.0.0:31987后台启动并用 python3 socket 探测 31987 端口直至就绪wait_for_remote_exec_server_port5 秒超时导出环境变量CODEX_TEST_REMOTE_EXEC_SERVER_URLws://容器IP:31987、CODEX_TEST_REMOTE_ENV、CODEX_TEST_REMOTE_ENV_CONTAINER_NAME、CODEX_TEST_ENVIRONMENTdocker。宿主机上 host 网络模式下容器 IP 取127.0.0.1bridge 模式下用docker inspect取实际 IP。codex_remote_env_cleanup 则会docker rm -f删除容器并清空上述所有环境变量。文档给出的两条标准运行命令core 与 app-server 各一条应当原样可用运行core 集成测试对 Docker 远程执行器bash -c set -euo pipefail unset CODEX_TEST_REMOTE_EXEC_SERVER_URL source scripts/test-remote-env.sh trap codex_remote_env_cleanup EXIT cd codex-rs just test -p codex-core --test all 运行app-server 集成测试对 Docker 远程执行器bash -c set -euo pipefail unset CODEX_TEST_REMOTE_EXEC_SERVER_URL source scripts/test-remote-env.sh trap codex_remote_env_cleanup EXIT cd codex-rs just test -p codex-app-server --test all 两个细节值得注意其一开头的unset CODEX_TEST_REMOTE_EXEC_SERVER_URL确保脚本按“自建”模式拉起容器并生成新的 URL而不是指向一个可能已失效的旧远端其二trap codex_remote_env_cleanup EXIT保证无论测试成功与否退出时都会清理容器避免残留。脚本头部注释还给出了一个最小验证用例just test -p codex-core --test all remote_test_env_can_connect_and_use_filesystem可用于确认远程环境搭建成功。Wine 形态Bazel 下的 Windows 远程执行端Wine 形态会构建一个 Windows 版 exec-server 并在 Wine 下运行它app-server 留在 Linux 宿主机。由于涉及跨平台交叉编译依赖这些测试只能在 Bazel 中运行remote-tests 文档。运行命令core 集成测试bazel test //codex-rs/core:core-all-wine-exec-testapp-server 集成测试bazel test //codex-rs/app-server:app-server-all-wine-exec-test从源码结构看这条链路的执行者是 wine_remote_test_runner.rsBazel 构建目标定义在 testing/BUILD.bazel 的wine-exec-test-runner从环境变量CODEX_WINE_EXEC_TEST_BINARY读取真实测试二进制路径该变量由 Bazel 测试规则注入若是--list --format terse请求直接透传给测试二进制以支持 Bazel 的测试枚举否则通过WineExecServer::scope在 Wine 前缀中启动 Windows 版 exec-server拿到exec_server_url后以CODEX_TEST_ENVIRONMENTwine-exec、CODEX_TEST_REMOTE_EXEC_SERVER_URLurl运行测试二进制并显式移除CODEX_TEST_REMOTE_ENV与CODEX_TEST_REMOTE_ENV_CONTAINER_NAME两个遗留 Docker 变量避免环境判定串扰wine_remote_test_runner.rs。测试进程启动后test_environment()依据CODEX_TEST_ENVIRONMENTwine-exec将其识别为WineExec环境目标 OS 记为 Windows——这就是为什么同一份集成测试代码在三种形态下只需按skip_if_*宏做少量条件分支即可。在 macOS 上通过 Devbox 运行如果你日常开发机是 macOSremote-tests 文档给出的替代方案是使用 devbox内部 Linux 开发机用applied_devbox ls列出 devbox选择名字中包含codex的那台ssh devbox_name连接复用 devbox 上~/code/codex的同一份 checkout多个 checkout 会拉长构建时间、占用更多磁盘需要时先重置文件操作前检查本地与远端的 SHA 及修改文件是否同步。连上之后即可按上文 Docker/Wine 小节的标准命令运行测试。小结远程执行器测试体系的关键约束与入口可以归纳为前提x86_64 Linux 宿主Docker 形态或 Bazel 构建环境Wine 形态入口脚本scripts/test-remote-env.shDockersource 使用退出时codex_remote_env_cleanupBazel 目标//codex-rs/core:core-all-wine-exec-test、//codex-rs/app-server:app-server-all-wine-exec-testWineopt-in 夹具core 侧TestCodexBuilder::build_with_auto_env()app-server 侧TestAppServer::new_with_auto_env()send_thread_start_request_with_auto_env()须省略ThreadStartParams.environments跳过宏按失败原因选择skip_if_target_windows!/skip_if_wine_exec!/skip_if_host_windows!/skip_if_remote!/skip_if_no_remote_env!并优先写全配置通用的测试路径兼容可参考 path-types 技能。相关源码与文档索引remote-tests 技能、core 测试公共库、环境判定、core 测试夹具、app-server 测试夹具、Wine 测试运行器、core README。【免费下载链接】openinterpreterA coding agent for open models like Kimi K3项目地址: https://gitcode.com/GitHub_Trending/op/openinterpreter创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考