【源码级拆解】Codex 0.149.0 默认开启特性：CodeMode——解锁工具调用的新篇章 这篇文章源于一次个人探索。用最新 Codex 写代码时我注意到它经常一口气回来好几组命令的结果，看起来像是并行工具调用。但去源码里一翻，Responses Lite 分支明确把顶层 parallel_tool_calls 设成了 false——那并行到底是哪来的？顺着这个疑问去看了 Codex 最新源码，就发现了 Code Mode 这套机制。 其实在此之前先是发现了最新 Claude Code 的 Bash-first 的 prompt 以及对应的源码判断（这也是为什么第一章先写这个的原因）。 读完源码后我最大的感受是：Codex 和 Claude Code 都在把 Harness 的控制粒度往“代码”这一层推进。Codex 目前让模型写 JavaScript 动态编排工具，Claude Code 则进一步用 JavaScript 动态编排 subagent；层级不同，但形状已经很接近了（虽然严格说 subagent 也是工具）。Harness 负责能力和边界这件事没变，真正变化的是模型开始从“选择下一次 tool call”，走向“直接写程序组织一整段执行流程”。 我不太相信 Codex 只会停在工具层。Code Mode 现在的独立 V8、能力白名单和进程隔离，本身就很像是在为更高层的动态 Agent 编排准备运行时；而 Claude Code 的 Dynamic Workflow 其实很早已经展示了这种模式会是什么样子。 本文的内容如下：Bash-first 策略 — Harness 为什么要把编排权交给模型？Codex Code Mode 实现 — 逐层打开：CodeModeOnly 怎么改工具拓扑exec 怎么经由 V8 → Rust Tool Runtime 完成嵌套调用并行为什么没绕过协议安全性靠什么保证演进线 — 从 Git 历史看通用 REPL → 受限 Code Mode 的路径Claude Code Dynamic Workflow — Codex 下一步大概率要做的东西 代码版本：Claude Code 2.1.236 本地发行包；OpenAI Codex commit 343074d4207d，源码日期 2026-08-22。一、Bash-first——当模型需要编排语言时最自然的解法 最新的 Claude Code 在低打断路径中有一段措辞直接的提示词： Do your work through the Bash tool wherever it can accomplish the job: read files with cat, head, or sed -n, search with grep and find, and make file changes with sed, heredocs, or short scripts, rather than using the dedicated Read, Edit, Write tools. Fall back to a dedicated tool only when Bash genuinely cannot do the job. 只要 Bash 干得了，就别去分别调用 Read、Edit、Write。这有点反直觉——专用工具是 Harness 花了力气做出来的，参数结构化、结果可渲染、权限可按字段判断，现在却主动劝模型绕过它们。 原因在于编排成本。假设要找出三个 Rust 模块里的超时配置并比较默认值，专用工具路径是：模型 -> Grep -> 模型 -> Read -> 模型 -> Read -> 模型 -> 汇总 每个箭头都是一次模型往返。而 Bash 能把整件事压成一次调用：rg -n "timeout|deadline" crates/{core,server,client}/src \ | sed -n '1,120p' 省下往返只是表面。这一次调用里，模型还多决定了搜索范围、过滤规则、输出上限。这些判断原本摊在多轮 Agent Loop 里，模型一步步给、Harness 一步步做，现在一并压进了一段可执行的程序里。 翻阅 Claude Code 2.1.236 本地发行包，三种低打断模式都开启了 Bash-first：bypassPermissions -> Bash-first auto (steerOnly) -> Bash-first bashFirst 开关 -> Bash-first 共同点在于都在压缩逐次确认和工具往返，让模型连续做完更长的一段工作。 代价同样明确。一条复合命令可以同时读文件、改文件、联网、拉起…