最近大半年我一直在折腾 Coding Agent把 Claude Code 和 Codex 同时接进同一个项目里的体验让我最深的感受不是模型变聪明了而是决策链路实在太长。每次 Agent 要决定“下一步干什么”都得把当前状态打包发给大模型等它思考、返回、再执行。一个简单的“删掉未使用的 import”也要等好几秒而且它还经常把一堆无关文件读进来上下文越滚越臃肿。后来我试着在这套流程外面加了一个轻量决策层也就是标题里说的 Jev核心就一件事把那些不需要大模型推理的判断在进入模型之前先干掉。这篇文章完整记录一下 Jev 接入 Claude Code 和 Codex 的具体做法。这个方案解决的核心问题是Coding Agent 的每一步操作不必要地消耗模型推理、请求延迟和上下文窗口。适合正在用 Claude Code 或 Codex CLI 做日常开发、又想降低调用成本和提高响应速度的开发者也适合想在自己项目里搭“Agent 路由层”的人参考。下面全程用我自己的实操经验来讲不写理论空话。1. 先搞清楚问题Coding Agent 到底卡在哪了1.1 Agent 的每一步都在做大模型推理先说一个我观察到的现象。很多人第一次用 Codex CLI 或 Claude Code 的时候会觉得“哇它真的能改代码”。但用上两周就会烦它太慢了。一个“把某个函数里死代码删掉”的请求从输入到看到 diff往往要等十几秒。为什么会慢我翻过几次日志发现问题的根源不在某个模型本身而在决策链路。Agent 拿到任务之后不是一步到位完成修改的它要先规划、再读取相关文件、再决定改哪里、改完还要检查每一步都可能发起一次大模型调用。更麻烦的是为了“稳妥”它会把大量不相干的文件内容塞进上下文。有一次我只是让 Claude Code 改一个工具函数日志里显示它为了找引用关系读入了十几个文件token 消耗直接爆表。这在技术上叫“长思维链 广泛上下文”的问题。模型聪明是聪明但每次都要从头理解一遍当前仓库状态代价就是延迟和费用。特别是团队里有人高频使用 Coding Agent 的时候每月的 API 账单会非常可观。1.2 慢与贵的本质是不会分级决策我后来想明白一个类比一个公司如果不管大事小情都要拉 CEO 开会那这个公司一定又慢又贵。正常的组织是有层级的前台先接待主管批常规事项只有真正复杂的问题才往上递。Coding Agent 现在的问题恰恰是——所有判断都让大模型这个“CEO”来拍板。实际上很多任务根本不需要动脑子。比如清理未使用的 import把项目里的单引号统一成双引号批量重命名局部变量给某个没有复杂逻辑的函数补一个简单的单元测试模板修复 lint 报错里的缩进、空行、尾逗号。这些任务的共同特征是规则明确、风险低、改动范围小。用大模型去处理相当于杀鸡用牛刀。如果它们能在“进大模型之前”就被拦截或者分流响应速度和开销都会有明显改善。1.3 我想到的解法在最外层加一个决策网关所以我给自己常用的 Agent 工作流加了一个新的东西——Jev。Jev 不是另一个 Coding Agent它不写代码、不改文件除非规则里明确配置了内建脚本它只做一件事在每次请求真正进入 Claude Code 或 Codex 之前先做一个快速决策这个请求应该走本地脚本直接解决还是交给 Claude Code还是交给 Codex。我把这种架构理解成“给 Coding Agent 加一层快速决策能力”。Jev 本质是一个决策网关用规则引擎跑一遍毫秒级返回路由结果。这层网关做得足够轻所以 Agent 日常请求不会因为加了它而变慢反过来因为大部分简单任务被拦下了整体反而快了。这套方案适合什么样的人如果你已经在用 Claude Code 或 Codex CLI 做日常开发觉得每次请求太慢、token 消耗太大或者你同时接了多个 Agent 工具想统一管理它们的调用范围那这篇内容应该对你有用。2. Jev 的整体设计规则路由 分级执行2.1 定位不是 Agent而是 Agent 前面的路由器Jev 整个系统由两块组成决策器和执行器。决策器负责回答问题“这个请求该怎么处理”它接收请求元数据动作类型、涉及文件、文件哈希、上下文摘要然后在本地规则表里做匹配。匹配结果有三种路由到 Claude Code、路由到 Codex、本地直接执行。执行器负责真正干活。当决策结果是“本地直接执行”时Jev 会在进程内跑一段内建脚本或调用仓库里的脚本文件然后把结果作为“已完成”状态返回给上层 Agent。如果决策结果是路由到某一个大模型 AgentJev 就只是把控制权交给对应的工具不参与后续过程。这个设计最大的好处是Jev 本身不依赖大模型 API。决策器是纯本地的规则匹配执行器的本地路径也是预定义脚本。它像是一个“前台接待”大部分时间只是回答“你去哪个窗口”偶尔自己动手盖个章。2.2 决策核心三张规则表我把 Jev 的决策逻辑归纳成三张表路由表Route定义什么样的事件交给哪个 Agent。比如跨模块重构、架构设计 → Claude Code生成单元测试、数据迁移脚本 → Codex涉及文件超过 5 个的批量修改 → Claude Code 完整模式。拦截表Intercept定义什么样的事件不需要任何 AgentJev 自己直接处理。比如简单文本替换、改缩进、删注释、解决 lint 修复。拦截表是提升速度的关键部分。缓存表Cache记录“相同请求上次的决策结果”。同一文件在内容没变的情况下重复触发相同动作时直接用缓存结果连规则都省得跑了。这三张表的匹配顺序很关键我建议顺序是缓存 拦截 路由。先查缓存命中就返回没命中再看能不能拦截都不能才进路由表做工具选择。顺序错了会出大问题比如路由表规则和拦截表规则条件重叠时如果路由表先执行简单任务就可能被意外送进大模型那你加这一层的意义就没了。2.3 为什么决策层坚决不用大模型有人问过我Jev 的决策逻辑本身是不是也可以让某个小模型来跑这样不是更“智能”吗我试过一次。在一个测试分支上我把决策器换成了一个轻量模型调用效果确实“看起来更智能”但它带来了三个新问题延迟从毫秒级变成秒级决策没有任何可审计性你不知道它为什么选了 Codex以及多了一层 API 费用。最关键的是为了让决策准确它也需要上下文等于把原来省下来的 token 又还回去了。决策这个动作最重要的是低延迟、可解释、成本为零。规则引擎完美满足这三点。大模型可以处理规则覆盖不到的模糊场景但那个优先级不应该是第一位的——先用规则把 80% 的常规情况挡住剩下 20% 的模糊情况让大模型 Agent 自己去判断这才是合理的分层。3. 接入 Claude Code用 PreToolUse 钩子做前置预判3.1 接入点PreToolUse 钩子先明确一个前提如果你只想“路由到一个大模型 Agent”那其实不需要这么复杂手动切工具也行。Jev 的价值在于干预 Agent 的单步工具调用让它在每一步实际操作前都问一句“这一步值不值得做大模型推理”。Claude Code 提供了 hook 机制特别是 PreToolUse。这个 hook 会在工具被实际调用之前触发我们可以在里面跑任意命令。如果命令返回特定退出码还能阻止这次工具调用。这就是 Jev 接入 Claude Code 的核心入口。我们把 Jev 的命令挂到 PreToolUse 上在 Claude Code 准备写文件或执行命令之前把“动作类型 目标文件 文件哈希”这些元数据传给 Jev。Jev 拿到之后跑规则返回三种可能放行继续用 Claude Code 执行拦截Jev 自己已经用本地脚本处理完毕换人建议把后续工作切到 Codex实际场景中很少在单步内动态切换更多是记录建议。在 Claude Code 的 settings.json 中配置 hooks大致是这样的{ hooks: { PreToolUse: [ { matcher: Write|Edit|MultiEdit, hooks: [ { type: command, command: jev decide --hook pre-tool --tool \$TOOL_NAME\ --input \$TOOL_INPUT\ } ] } ] } }这里的$TOOL_NAME和$TOOL_INPUT是 Claude Code 注入的 hook 变量。Jev 命令行工具再自己解析出文件路径计算哈希跑规则。3.2 在 Jev 里定义“直接本地处理”的规则为了发挥 Jev 的作用我建议先把拦截表做好。以下是来自我某个项目的真实配置换掉了具体仓库信息intercept: - name: fix-single-import when: action: cleanup files: 2 hint: [import, unused] do: run: scripts/cleanup_imports.py output: json - name: unify-quotes when: action: format files: 5 hint: [quote, lint] do: run: npx prettier --single-quote {files} output: json这两条规则的含义是如果 Claude Code 试图执行的是小范围的 import 清理或者格式化任务Jev 就直接在本地执行对应命令并且返回一个结构化结果。Claude Code 收到这个结果后会以为是它自己执行成功的工具调用继续后面的流程。用户看到的唯一不同是速度快了很多token 没消耗。3.3 返回格式与钩子的配合细节这里有一个关键点Claude Code 的 PreToolUse hook 如果想拦截原始调用并且告诉 Claude Code“我已经用别的方式完成了”不能只输出文本需要输出特定结构的 JSON并且设置适当的退出码。Jev 的decide命令在本地处理成功时会输出类似于{ result: intercept, success: true, summary: 已使用 cleanup_imports.py 清理 3 个未使用 import, output: ... }然后进程退出时返回退出码 0。Claude Code 会把这个当成“工具已经成功执行”的信号不再调用原始工具。如果 Jev 判断需要放行给 Claude Code就输出{ result: pass }同时退出码 0。Claude Code 就继续执行原始的 Write/Edit。如果 Jev 想强制阻止工具调用比如发现目标文件不该被修改可以使用退出码 2并输出 JSON 说明原因。这个机制用来做安全管控非常好用比如禁止 Agent 触碰config/production.yaml这类敏感文件。接入 Claude Code 的步骤其实不多但有两个细节我提醒你注意。第一matcher的正则一定要严格Write这样单独的单词有时候匹配不到带参数的Write工具全名我建议写成Write|Edit|MultiEdit这种组合并且在上线前用一条假命令验证。第二Jev 的所有日志要写到文件而不是 stderr因为 stderr 里的任何非结构化输出都可能干扰 Claude Code 对 JSON 的解析。4. 接入 Codex把 Jev 包装成 MCP 决策工具4.1 Codex 的接入路径和 Claude Code 不一样如果说 Claude Code 是“每一步都能插一脚”那 Codex CLI 更接近一个“整体规划型”的工具。它支持用户通过命令行输入自然语言需求然后自己决定读取哪些文件、修改哪些文件。要在 Codex 里做快速决策不能依赖跟 Claude Code 一样的 hook更常用的方式是把 Jev 包装成一个本地 MCP 服务器。MCP 现在是很多 Agent 工具的标准协议。Codex 的配置里可以直接声明一个本地 MCP 服务器这个服务器暴露若干个工具Codex 在自己的规划阶段会看到这些工具并按需调用。我把 Jev 封装成 MCP 之后暴露了这么几个工具jev_should_route(query)接收一个自然语言查询和当前工作目录返回“本地直接处理 / 用 Codex / 用 Claude Code”的建议jev_run_local(task)执行本地规则里匹配到的脚本并返回执行结果jev_get_cache(action, file_hash)查询缓存。4.2 注册一个 Jev MCP ServerCodex 的配置文件路径可能因为版本不同而有差别但核心结构是一致的。用 TOML 声明 mcpServers指向 Jev 的启动脚本即可。下面是一个典型配置片段# ~/.codex/config.toml或项目级 .codex/config.toml [mcp_servers.jev] command npx args [-y, jev-mcp, --config, .jev/config.yaml] env { JEV_CACHE_DIR .jev/cache }配置完成后重启 Codex它会自动连接 Jev 的 MCP 服务。Codex 在收到用户任务时会先看到 Jev 提供的决策工具。如果 Jev 返回的建议是“本地直接处理”Codex 一般会选择调用jev_run_local而不是自己动手分析代码。如果建议是“交给 Claude Code”那 Codex 可以停止执行提示用户切换工具或者在一个多 Agent 协作脚本里触发 Claude Code 的进程。4.3 双 Agent 协同什么时候该听 Jev 的建议我一开始担心 Codex 不会调用 Jev 提供的工具因为 MCP 工具只是给它“看到”并不强制它用。实测下来只要 Jev 的工具描述写得到位Codex 是愿意用的。原因在于 Codex 本身也被训练为尽量使用可用工具来解决问题而不是自己硬分析。举个例子我配置了一条规则“如果用户的请求是生成一个纯函数的单元测试并且目标文件没有复杂依赖则建议用 Codex 自己做如果请求里包含‘重构’或‘架构’字样则建议切到 Claude Code。”然后我给 Jev 写了一条路由规则route: - name: arch-task when: hint_includes: [架构, 重构, refactor, architecture] target: claude-code - name: test-gen when: hint_includes: [测试, test, unit] target: codex当用户在终端输入“给 utils/date_helper.py 写个单元测试”时Codex 会调用jev_should_route拿到结果“目标 codex”之后就会像没事人一样继续自己干活。但如果用户说“重构一下支付模块的设计”Jev 返回“目标 claude-code”Codex 就会提示“这个任务建议使用 Claude Code 完成是否要我帮你切换”这其实就是我们想要的“快速决策能力”——不是替 Agent 做决定而是让它意识到什么任务该用什么工具。Codex 这侧接入的常见坑是 MCP 通信的进程占用。Jev 的 MCP 服务如果启动失败Codex 并不会报错只会静默地不显示相关工具。排查的时候建议先用命令行单独启动jev-mcp确认没有语法错误再回 Codex 里测试。5. 完整落地可直接抄的配置方案5.1 目录规划与依赖选型不管你是接 Claude Code 还是 Codex我都建议把 Jev 做成项目级配置放在仓库根目录的.jev/下。这样换一台电脑clone 下来就能用团队其他人也容易共享同一套决策规则。我的典型目录结构repo-root/ .jev/ config.yaml cache/ # 决策缓存 logs/ # 决策日志 scripts/ cleanup_imports.py format_check.py依赖方面Jev 本体我推荐用 Node.js 或者 Go 做一个单文件工具。Node 的好处是生态方便跟 Claude Code / Codex 的运行时天然匹配npx 分发最简单Go 的好处是部署时不用装依赖。我自己的选择是 Node TypeScript编译成一个 CLI 和 MCP server发布在 npm 上团队里直接用npx jev就能拉起。5.2 config.yaml 全量示例下面给一份接近生产可用的配置。我会把每个字段为什么这么写也一起讲清楚。# .jev/config.yaml version: 1.0 cache: enabled: true ttl: 300 # 秒默认 5 分钟 key_include: [action, file_hash, tool] decision: timeout_ms: 300 # 决策器自身超时, 超时直接放行 default_target: claude-code # 无规则匹配时, 默认交给谁 confidence_threshold: 0.7 # 多条件匹配时, 达到该分数才生效 intercept: - name: quick-cleanup when: action_in: [cleanup, lint-fix] files_between: [1, 3] do: run: python .jev/scripts/quick_clean.py tag: local - name: format-only when: action: format files_between: [1, 5] hint_not_includes: [refactor] do: run: npx prettier --write {files} tag: local route: - name: complex-refactor when: action_in: [refactor, architecture, migration] files_over: 5 target: claude-code - name: test-generation when: action_in: [test, write-test] files_between: [1, 3] hint_includes: [unit] target: codex逐段解释一下cache节控制决策缓存。ttl我建议不要设太长。因为开发阶段的文件哈希变化很快如果缓存太久规则匹配到的可能是旧文件状态导致 Jev 认为“这事情本地能解决”实际底层文件已经大变样了。300 秒是一个折中值。如果你是做稳定维护的老项目调到 900 秒也可以。decision.timeout_ms是保险丝。Jev 一旦因为异常卡住比如脚本抛异常、文件系统变慢不能影响主流程。300 ms 内没返回就默认放行交给 default_target。这个值不能设太大了否则“快速决策”变成了“快速变慢”。confidence_threshold是给多条件匹配算分用的。比如一条规则命中两个条件中的第一个另一个没匹配上匹配度可能是 0.6。低于阈值就不生效走兜底路由。5.3 关键参数怎么定超时、TTL、置信度有朋友问我这些 TTL、阈值、超时参数是怎么“算”出来的说实话没有公式但有一套基于经验的推导方式。决策超时timeout_ms主要取决于远程还是本地。如果 Jev 只做本地文件哈希和规则匹配300 ms 已经非常宽裕如果规则里调用了一些外部脚本那可以把超时放宽到 800 ms但不要超过 1 秒否则用户的体验会明显变差。我自己的原则是Jev 超时时间应该控制在“用户可以无感等待”的上限内也就是 1 秒。缓存 TTL 的推导逻辑可以结合文件改动频率。简单说如果你观察到某个文件在一小时内被修改 5 次那它的平均稳定间隔就是 12 分钟。缓存 TTL 设为这个稳定间隔的一半6 分钟比较合适。如果你不想分析直接用 300 秒再根据成本账单做调整。置信度阈值则要看规则定义质量。规则条件写得具体每个条件权重高阈值设为 0.6 就够了如果规则条件比较模糊建议提升到 0.75避免误拦截。5.4 三条命令接口串起三种场景为了让 Claude Code 和 Codex 都能方便调用我给 Jev 设计了这样两个命令jev decide是给 Claude Code hook 用的。它从参数中读取动作、文件列表输出 JSON 决策结果。jev decide --action cleanup --files src/utils/a.ts,src/utils/b.ts --hash b7f3a1jev-mcp是给 Codex 用的 MCP 启动命令。它启动一个 stdio 服务监听 MCP 协议请求。两者共享同一个配置和缓存。如果你只是在终端里手动使用也可以直接跑jev route --query 给 utils 写测试 --dir .输出一行建议。这三个接口覆盖了“手动查询、Claude Code hook、Codex MCP”三个接入场景算是一个完整闭环。6. 我踩过的坑与排查实录6.1 matcher 正则不匹配钩子静默失效第一次给 Claude Code 配置 hooks 时我用的 matcher 是Write。结果发现 Jev 根本不会被触发。后来查日志Claude Code 的$TOOL_NAME传过来的是完整工具名比如WriteFile、EditFile、MultiEdit。Write未必能匹配上。改成Write|Edit|MultiEdit之后Jev 才开始工作。这个坑的教训是hook 的正则匹配和目标字符串都要先打日志确认。不要在配置里凭空猜。6.2 拦截规则太激进批量改坏代码有一回我把quick-cleanup的范围从files: [1,3]扩大到[1,10]本意是让更多清理任务走本地脚本。结果某次 Jev 用一个粗暴的 import 清理脚本处理了 7 个文件把几个有副作用的 import 也删了后续编译直接挂掉。那次之后我加了一条保护任何本地 intercept只要涉及文件超过 3 个必须先输出一个“diff preview”并在规则里设置confirm: true。Jev 因为这个标记会先生成 diff再让上层 Agent 决定是否提交。这个机制虽然多了一步但再没出过批量改坏代码的事故。6.3 JSON 混入日志Agent 解析失败我先在 Claude Code 里遇到过“工具返回结果无法解析”的报错。排查到最后发现是 Jev 脚本里有一行console.log(debug...)往 stdout 打了日志和 JSON 输出混在一起了。修复很简单把所有调试日志重定向到文件或者 stderr。但要记住在 MCP 和 hook 场景下stderr 也不是完全安全。最稳妥的做法是Jev 生产模式开启--json-onlystdout 只输出单行 JSON其他什么都别打。6.4 缓存命中但路由失真配置缓存之后我发现一个现象某些文件已经被人重构了但 Jev 还按旧的文件哈希返回旧的决策结果。原因很简单——缓存 key 里没有包含文件内容哈希。我后来把 key 设计成action file_path file_hash文件一变哈希就变缓存自动失效。这个改动之后缓存命中率确实降了一些但准确性大大提升。6.5 常见问题速查表症状可能原因解决办法Claude Code 里 Jev 从未被调用matcher 正则不对改成Write|Edit|MultiEdit先加日志验证Codex 里看不到 Jev 工具MCP 服务启动失败单独运行jev-mcp确认进程正常Jev 返回 JSON 但 Agent 解析失败stdout 混入了日志开启 json-onlystdout 只输出 JSON路由结果总是不准缓存 key 缺少文件哈希缓存 key 加入file_hash拦截脚本把代码改坏规则覆盖范围过大增加confirm: true控制文件数量决策本身要 2 秒规则里跑了外部脚本把外部脚本改成异步预加载或缩短超时7. 关于这层快速决策我再多说两句这套方案的取舍我认为最关键的是“别让决策层去抢 Agent 的活”。Jev 做的是快速判断不是精细修改。它适合的永远是规则明确、风险可控、改动范围小的场景而真正需要理解业务逻辑、梳理依赖关系的任务老老实实交给 Claude Code 或 Codex 就好。不要为了追求“全部自动化”把架构设计、跨模块重构也塞给规则引擎那只会让规则表膨胀成一个没人敢动的怪物。另一个体会是决策网关的价值最终要体现在可观测性上。我建议每个从 Jev 经过的请求都留一条日志记录“请求-规则-决策-耗时-是否命中缓存”。跑两周之后你会很清楚哪些规则经常触发、哪些规则形同虚设然后你就能有针对性地调整。我自己的 Jev 日志里拦截率从最初的 20% 提到了 60% 左右平均请求耗时才真正下来了。如果你也想在自己的开发流里加这层我建议从最小的规则开始先只接 Claude Code配一条“小范围 import 清理走本地脚本”的拦截规则跑一周看效果再逐步扩展路由表和 Codex 接入。这样即使出了问题回滚也很简单。
最近大半年我一直在折腾 Coding Agent把 Claude Code 和 Codex 同时接进同一个项目里的体验让我最深的感受不是模型变聪明了而是决策链路实在太长。每次 Agent 要决定“下一步干什么”都得把当前状态打包发给大模型等它思考、返回、再执行。一个简单的“删掉未使用的 import”也要等好几秒而且它还经常把一堆无关文件读进来上下文越滚越臃肿。后来我试着在这套流程外面加了一个轻量决策层也就是标题里说的 Jev核心就一件事把那些不需要大模型推理的判断在进入模型之前先干掉。这篇文章完整记录一下 Jev 接入 Claude Code 和 Codex 的具体做法。这个方案解决的核心问题是Coding Agent 的每一步操作不必要地消耗模型推理、请求延迟和上下文窗口。适合正在用 Claude Code 或 Codex CLI 做日常开发、又想降低调用成本和提高响应速度的开发者也适合想在自己项目里搭“Agent 路由层”的人参考。下面全程用我自己的实操经验来讲不写理论空话。1. 先搞清楚问题Coding Agent 到底卡在哪了1.1 Agent 的每一步都在做大模型推理先说一个我观察到的现象。很多人第一次用 Codex CLI 或 Claude Code 的时候会觉得“哇它真的能改代码”。但用上两周就会烦它太慢了。一个“把某个函数里死代码删掉”的请求从输入到看到 diff往往要等十几秒。为什么会慢我翻过几次日志发现问题的根源不在某个模型本身而在决策链路。Agent 拿到任务之后不是一步到位完成修改的它要先规划、再读取相关文件、再决定改哪里、改完还要检查每一步都可能发起一次大模型调用。更麻烦的是为了“稳妥”它会把大量不相干的文件内容塞进上下文。有一次我只是让 Claude Code 改一个工具函数日志里显示它为了找引用关系读入了十几个文件token 消耗直接爆表。这在技术上叫“长思维链 广泛上下文”的问题。模型聪明是聪明但每次都要从头理解一遍当前仓库状态代价就是延迟和费用。特别是团队里有人高频使用 Coding Agent 的时候每月的 API 账单会非常可观。1.2 慢与贵的本质是不会分级决策我后来想明白一个类比一个公司如果不管大事小情都要拉 CEO 开会那这个公司一定又慢又贵。正常的组织是有层级的前台先接待主管批常规事项只有真正复杂的问题才往上递。Coding Agent 现在的问题恰恰是——所有判断都让大模型这个“CEO”来拍板。实际上很多任务根本不需要动脑子。比如清理未使用的 import把项目里的单引号统一成双引号批量重命名局部变量给某个没有复杂逻辑的函数补一个简单的单元测试模板修复 lint 报错里的缩进、空行、尾逗号。这些任务的共同特征是规则明确、风险低、改动范围小。用大模型去处理相当于杀鸡用牛刀。如果它们能在“进大模型之前”就被拦截或者分流响应速度和开销都会有明显改善。1.3 我想到的解法在最外层加一个决策网关所以我给自己常用的 Agent 工作流加了一个新的东西——Jev。Jev 不是另一个 Coding Agent它不写代码、不改文件除非规则里明确配置了内建脚本它只做一件事在每次请求真正进入 Claude Code 或 Codex 之前先做一个快速决策这个请求应该走本地脚本直接解决还是交给 Claude Code还是交给 Codex。我把这种架构理解成“给 Coding Agent 加一层快速决策能力”。Jev 本质是一个决策网关用规则引擎跑一遍毫秒级返回路由结果。这层网关做得足够轻所以 Agent 日常请求不会因为加了它而变慢反过来因为大部分简单任务被拦下了整体反而快了。这套方案适合什么样的人如果你已经在用 Claude Code 或 Codex CLI 做日常开发觉得每次请求太慢、token 消耗太大或者你同时接了多个 Agent 工具想统一管理它们的调用范围那这篇内容应该对你有用。2. Jev 的整体设计规则路由 分级执行2.1 定位不是 Agent而是 Agent 前面的路由器Jev 整个系统由两块组成决策器和执行器。决策器负责回答问题“这个请求该怎么处理”它接收请求元数据动作类型、涉及文件、文件哈希、上下文摘要然后在本地规则表里做匹配。匹配结果有三种路由到 Claude Code、路由到 Codex、本地直接执行。执行器负责真正干活。当决策结果是“本地直接执行”时Jev 会在进程内跑一段内建脚本或调用仓库里的脚本文件然后把结果作为“已完成”状态返回给上层 Agent。如果决策结果是路由到某一个大模型 AgentJev 就只是把控制权交给对应的工具不参与后续过程。这个设计最大的好处是Jev 本身不依赖大模型 API。决策器是纯本地的规则匹配执行器的本地路径也是预定义脚本。它像是一个“前台接待”大部分时间只是回答“你去哪个窗口”偶尔自己动手盖个章。2.2 决策核心三张规则表我把 Jev 的决策逻辑归纳成三张表路由表Route定义什么样的事件交给哪个 Agent。比如跨模块重构、架构设计 → Claude Code生成单元测试、数据迁移脚本 → Codex涉及文件超过 5 个的批量修改 → Claude Code 完整模式。拦截表Intercept定义什么样的事件不需要任何 AgentJev 自己直接处理。比如简单文本替换、改缩进、删注释、解决 lint 修复。拦截表是提升速度的关键部分。缓存表Cache记录“相同请求上次的决策结果”。同一文件在内容没变的情况下重复触发相同动作时直接用缓存结果连规则都省得跑了。这三张表的匹配顺序很关键我建议顺序是缓存 拦截 路由。先查缓存命中就返回没命中再看能不能拦截都不能才进路由表做工具选择。顺序错了会出大问题比如路由表规则和拦截表规则条件重叠时如果路由表先执行简单任务就可能被意外送进大模型那你加这一层的意义就没了。2.3 为什么决策层坚决不用大模型有人问过我Jev 的决策逻辑本身是不是也可以让某个小模型来跑这样不是更“智能”吗我试过一次。在一个测试分支上我把决策器换成了一个轻量模型调用效果确实“看起来更智能”但它带来了三个新问题延迟从毫秒级变成秒级决策没有任何可审计性你不知道它为什么选了 Codex以及多了一层 API 费用。最关键的是为了让决策准确它也需要上下文等于把原来省下来的 token 又还回去了。决策这个动作最重要的是低延迟、可解释、成本为零。规则引擎完美满足这三点。大模型可以处理规则覆盖不到的模糊场景但那个优先级不应该是第一位的——先用规则把 80% 的常规情况挡住剩下 20% 的模糊情况让大模型 Agent 自己去判断这才是合理的分层。3. 接入 Claude Code用 PreToolUse 钩子做前置预判3.1 接入点PreToolUse 钩子先明确一个前提如果你只想“路由到一个大模型 Agent”那其实不需要这么复杂手动切工具也行。Jev 的价值在于干预 Agent 的单步工具调用让它在每一步实际操作前都问一句“这一步值不值得做大模型推理”。Claude Code 提供了 hook 机制特别是 PreToolUse。这个 hook 会在工具被实际调用之前触发我们可以在里面跑任意命令。如果命令返回特定退出码还能阻止这次工具调用。这就是 Jev 接入 Claude Code 的核心入口。我们把 Jev 的命令挂到 PreToolUse 上在 Claude Code 准备写文件或执行命令之前把“动作类型 目标文件 文件哈希”这些元数据传给 Jev。Jev 拿到之后跑规则返回三种可能放行继续用 Claude Code 执行拦截Jev 自己已经用本地脚本处理完毕换人建议把后续工作切到 Codex实际场景中很少在单步内动态切换更多是记录建议。在 Claude Code 的 settings.json 中配置 hooks大致是这样的{ hooks: { PreToolUse: [ { matcher: Write|Edit|MultiEdit, hooks: [ { type: command, command: jev decide --hook pre-tool --tool \$TOOL_NAME\ --input \$TOOL_INPUT\ } ] } ] } }这里的$TOOL_NAME和$TOOL_INPUT是 Claude Code 注入的 hook 变量。Jev 命令行工具再自己解析出文件路径计算哈希跑规则。3.2 在 Jev 里定义“直接本地处理”的规则为了发挥 Jev 的作用我建议先把拦截表做好。以下是来自我某个项目的真实配置换掉了具体仓库信息intercept: - name: fix-single-import when: action: cleanup files: 2 hint: [import, unused] do: run: scripts/cleanup_imports.py output: json - name: unify-quotes when: action: format files: 5 hint: [quote, lint] do: run: npx prettier --single-quote {files} output: json这两条规则的含义是如果 Claude Code 试图执行的是小范围的 import 清理或者格式化任务Jev 就直接在本地执行对应命令并且返回一个结构化结果。Claude Code 收到这个结果后会以为是它自己执行成功的工具调用继续后面的流程。用户看到的唯一不同是速度快了很多token 没消耗。3.3 返回格式与钩子的配合细节这里有一个关键点Claude Code 的 PreToolUse hook 如果想拦截原始调用并且告诉 Claude Code“我已经用别的方式完成了”不能只输出文本需要输出特定结构的 JSON并且设置适当的退出码。Jev 的decide命令在本地处理成功时会输出类似于{ result: intercept, success: true, summary: 已使用 cleanup_imports.py 清理 3 个未使用 import, output: ... }然后进程退出时返回退出码 0。Claude Code 会把这个当成“工具已经成功执行”的信号不再调用原始工具。如果 Jev 判断需要放行给 Claude Code就输出{ result: pass }同时退出码 0。Claude Code 就继续执行原始的 Write/Edit。如果 Jev 想强制阻止工具调用比如发现目标文件不该被修改可以使用退出码 2并输出 JSON 说明原因。这个机制用来做安全管控非常好用比如禁止 Agent 触碰config/production.yaml这类敏感文件。接入 Claude Code 的步骤其实不多但有两个细节我提醒你注意。第一matcher的正则一定要严格Write这样单独的单词有时候匹配不到带参数的Write工具全名我建议写成Write|Edit|MultiEdit这种组合并且在上线前用一条假命令验证。第二Jev 的所有日志要写到文件而不是 stderr因为 stderr 里的任何非结构化输出都可能干扰 Claude Code 对 JSON 的解析。4. 接入 Codex把 Jev 包装成 MCP 决策工具4.1 Codex 的接入路径和 Claude Code 不一样如果说 Claude Code 是“每一步都能插一脚”那 Codex CLI 更接近一个“整体规划型”的工具。它支持用户通过命令行输入自然语言需求然后自己决定读取哪些文件、修改哪些文件。要在 Codex 里做快速决策不能依赖跟 Claude Code 一样的 hook更常用的方式是把 Jev 包装成一个本地 MCP 服务器。MCP 现在是很多 Agent 工具的标准协议。Codex 的配置里可以直接声明一个本地 MCP 服务器这个服务器暴露若干个工具Codex 在自己的规划阶段会看到这些工具并按需调用。我把 Jev 封装成 MCP 之后暴露了这么几个工具jev_should_route(query)接收一个自然语言查询和当前工作目录返回“本地直接处理 / 用 Codex / 用 Claude Code”的建议jev_run_local(task)执行本地规则里匹配到的脚本并返回执行结果jev_get_cache(action, file_hash)查询缓存。4.2 注册一个 Jev MCP ServerCodex 的配置文件路径可能因为版本不同而有差别但核心结构是一致的。用 TOML 声明 mcpServers指向 Jev 的启动脚本即可。下面是一个典型配置片段# ~/.codex/config.toml或项目级 .codex/config.toml [mcp_servers.jev] command npx args [-y, jev-mcp, --config, .jev/config.yaml] env { JEV_CACHE_DIR .jev/cache }配置完成后重启 Codex它会自动连接 Jev 的 MCP 服务。Codex 在收到用户任务时会先看到 Jev 提供的决策工具。如果 Jev 返回的建议是“本地直接处理”Codex 一般会选择调用jev_run_local而不是自己动手分析代码。如果建议是“交给 Claude Code”那 Codex 可以停止执行提示用户切换工具或者在一个多 Agent 协作脚本里触发 Claude Code 的进程。4.3 双 Agent 协同什么时候该听 Jev 的建议我一开始担心 Codex 不会调用 Jev 提供的工具因为 MCP 工具只是给它“看到”并不强制它用。实测下来只要 Jev 的工具描述写得到位Codex 是愿意用的。原因在于 Codex 本身也被训练为尽量使用可用工具来解决问题而不是自己硬分析。举个例子我配置了一条规则“如果用户的请求是生成一个纯函数的单元测试并且目标文件没有复杂依赖则建议用 Codex 自己做如果请求里包含‘重构’或‘架构’字样则建议切到 Claude Code。”然后我给 Jev 写了一条路由规则route: - name: arch-task when: hint_includes: [架构, 重构, refactor, architecture] target: claude-code - name: test-gen when: hint_includes: [测试, test, unit] target: codex当用户在终端输入“给 utils/date_helper.py 写个单元测试”时Codex 会调用jev_should_route拿到结果“目标 codex”之后就会像没事人一样继续自己干活。但如果用户说“重构一下支付模块的设计”Jev 返回“目标 claude-code”Codex 就会提示“这个任务建议使用 Claude Code 完成是否要我帮你切换”这其实就是我们想要的“快速决策能力”——不是替 Agent 做决定而是让它意识到什么任务该用什么工具。Codex 这侧接入的常见坑是 MCP 通信的进程占用。Jev 的 MCP 服务如果启动失败Codex 并不会报错只会静默地不显示相关工具。排查的时候建议先用命令行单独启动jev-mcp确认没有语法错误再回 Codex 里测试。5. 完整落地可直接抄的配置方案5.1 目录规划与依赖选型不管你是接 Claude Code 还是 Codex我都建议把 Jev 做成项目级配置放在仓库根目录的.jev/下。这样换一台电脑clone 下来就能用团队其他人也容易共享同一套决策规则。我的典型目录结构repo-root/ .jev/ config.yaml cache/ # 决策缓存 logs/ # 决策日志 scripts/ cleanup_imports.py format_check.py依赖方面Jev 本体我推荐用 Node.js 或者 Go 做一个单文件工具。Node 的好处是生态方便跟 Claude Code / Codex 的运行时天然匹配npx 分发最简单Go 的好处是部署时不用装依赖。我自己的选择是 Node TypeScript编译成一个 CLI 和 MCP server发布在 npm 上团队里直接用npx jev就能拉起。5.2 config.yaml 全量示例下面给一份接近生产可用的配置。我会把每个字段为什么这么写也一起讲清楚。# .jev/config.yaml version: 1.0 cache: enabled: true ttl: 300 # 秒默认 5 分钟 key_include: [action, file_hash, tool] decision: timeout_ms: 300 # 决策器自身超时, 超时直接放行 default_target: claude-code # 无规则匹配时, 默认交给谁 confidence_threshold: 0.7 # 多条件匹配时, 达到该分数才生效 intercept: - name: quick-cleanup when: action_in: [cleanup, lint-fix] files_between: [1, 3] do: run: python .jev/scripts/quick_clean.py tag: local - name: format-only when: action: format files_between: [1, 5] hint_not_includes: [refactor] do: run: npx prettier --write {files} tag: local route: - name: complex-refactor when: action_in: [refactor, architecture, migration] files_over: 5 target: claude-code - name: test-generation when: action_in: [test, write-test] files_between: [1, 3] hint_includes: [unit] target: codex逐段解释一下cache节控制决策缓存。ttl我建议不要设太长。因为开发阶段的文件哈希变化很快如果缓存太久规则匹配到的可能是旧文件状态导致 Jev 认为“这事情本地能解决”实际底层文件已经大变样了。300 秒是一个折中值。如果你是做稳定维护的老项目调到 900 秒也可以。decision.timeout_ms是保险丝。Jev 一旦因为异常卡住比如脚本抛异常、文件系统变慢不能影响主流程。300 ms 内没返回就默认放行交给 default_target。这个值不能设太大了否则“快速决策”变成了“快速变慢”。confidence_threshold是给多条件匹配算分用的。比如一条规则命中两个条件中的第一个另一个没匹配上匹配度可能是 0.6。低于阈值就不生效走兜底路由。5.3 关键参数怎么定超时、TTL、置信度有朋友问我这些 TTL、阈值、超时参数是怎么“算”出来的说实话没有公式但有一套基于经验的推导方式。决策超时timeout_ms主要取决于远程还是本地。如果 Jev 只做本地文件哈希和规则匹配300 ms 已经非常宽裕如果规则里调用了一些外部脚本那可以把超时放宽到 800 ms但不要超过 1 秒否则用户的体验会明显变差。我自己的原则是Jev 超时时间应该控制在“用户可以无感等待”的上限内也就是 1 秒。缓存 TTL 的推导逻辑可以结合文件改动频率。简单说如果你观察到某个文件在一小时内被修改 5 次那它的平均稳定间隔就是 12 分钟。缓存 TTL 设为这个稳定间隔的一半6 分钟比较合适。如果你不想分析直接用 300 秒再根据成本账单做调整。置信度阈值则要看规则定义质量。规则条件写得具体每个条件权重高阈值设为 0.6 就够了如果规则条件比较模糊建议提升到 0.75避免误拦截。5.4 三条命令接口串起三种场景为了让 Claude Code 和 Codex 都能方便调用我给 Jev 设计了这样两个命令jev decide是给 Claude Code hook 用的。它从参数中读取动作、文件列表输出 JSON 决策结果。jev decide --action cleanup --files src/utils/a.ts,src/utils/b.ts --hash b7f3a1jev-mcp是给 Codex 用的 MCP 启动命令。它启动一个 stdio 服务监听 MCP 协议请求。两者共享同一个配置和缓存。如果你只是在终端里手动使用也可以直接跑jev route --query 给 utils 写测试 --dir .输出一行建议。这三个接口覆盖了“手动查询、Claude Code hook、Codex MCP”三个接入场景算是一个完整闭环。6. 我踩过的坑与排查实录6.1 matcher 正则不匹配钩子静默失效第一次给 Claude Code 配置 hooks 时我用的 matcher 是Write。结果发现 Jev 根本不会被触发。后来查日志Claude Code 的$TOOL_NAME传过来的是完整工具名比如WriteFile、EditFile、MultiEdit。Write未必能匹配上。改成Write|Edit|MultiEdit之后Jev 才开始工作。这个坑的教训是hook 的正则匹配和目标字符串都要先打日志确认。不要在配置里凭空猜。6.2 拦截规则太激进批量改坏代码有一回我把quick-cleanup的范围从files: [1,3]扩大到[1,10]本意是让更多清理任务走本地脚本。结果某次 Jev 用一个粗暴的 import 清理脚本处理了 7 个文件把几个有副作用的 import 也删了后续编译直接挂掉。那次之后我加了一条保护任何本地 intercept只要涉及文件超过 3 个必须先输出一个“diff preview”并在规则里设置confirm: true。Jev 因为这个标记会先生成 diff再让上层 Agent 决定是否提交。这个机制虽然多了一步但再没出过批量改坏代码的事故。6.3 JSON 混入日志Agent 解析失败我先在 Claude Code 里遇到过“工具返回结果无法解析”的报错。排查到最后发现是 Jev 脚本里有一行console.log(debug...)往 stdout 打了日志和 JSON 输出混在一起了。修复很简单把所有调试日志重定向到文件或者 stderr。但要记住在 MCP 和 hook 场景下stderr 也不是完全安全。最稳妥的做法是Jev 生产模式开启--json-onlystdout 只输出单行 JSON其他什么都别打。6.4 缓存命中但路由失真配置缓存之后我发现一个现象某些文件已经被人重构了但 Jev 还按旧的文件哈希返回旧的决策结果。原因很简单——缓存 key 里没有包含文件内容哈希。我后来把 key 设计成action file_path file_hash文件一变哈希就变缓存自动失效。这个改动之后缓存命中率确实降了一些但准确性大大提升。6.5 常见问题速查表症状可能原因解决办法Claude Code 里 Jev 从未被调用matcher 正则不对改成Write|Edit|MultiEdit先加日志验证Codex 里看不到 Jev 工具MCP 服务启动失败单独运行jev-mcp确认进程正常Jev 返回 JSON 但 Agent 解析失败stdout 混入了日志开启 json-onlystdout 只输出 JSON路由结果总是不准缓存 key 缺少文件哈希缓存 key 加入file_hash拦截脚本把代码改坏规则覆盖范围过大增加confirm: true控制文件数量决策本身要 2 秒规则里跑了外部脚本把外部脚本改成异步预加载或缩短超时7. 关于这层快速决策我再多说两句这套方案的取舍我认为最关键的是“别让决策层去抢 Agent 的活”。Jev 做的是快速判断不是精细修改。它适合的永远是规则明确、风险可控、改动范围小的场景而真正需要理解业务逻辑、梳理依赖关系的任务老老实实交给 Claude Code 或 Codex 就好。不要为了追求“全部自动化”把架构设计、跨模块重构也塞给规则引擎那只会让规则表膨胀成一个没人敢动的怪物。另一个体会是决策网关的价值最终要体现在可观测性上。我建议每个从 Jev 经过的请求都留一条日志记录“请求-规则-决策-耗时-是否命中缓存”。跑两周之后你会很清楚哪些规则经常触发、哪些规则形同虚设然后你就能有针对性地调整。我自己的 Jev 日志里拦截率从最初的 20% 提到了 60% 左右平均请求耗时才真正下来了。如果你也想在自己的开发流里加这层我建议从最小的规则开始先只接 Claude Code配一条“小范围 import 清理走本地脚本”的拦截规则跑一周看效果再逐步扩展路由表和 Codex 接入。这样即使出了问题回滚也很简单。
