1. 从一次「桶里套桶」的聚合查询说起如果你正在用 Elasticsearch 做数据统计大概率写过restHighLevelClient的聚合查询。terms分组、dateHistogram按月分桶、再往桶里塞一个sum子聚合这套组合拳在业务里非常常见。但真正让人头疼的不是 DSL 怎么写而是 Java 端把SearchResponse拆开的那几行代码先拿父聚合再遍历Histogram.Bucket然后bucket.getAggregations().getAsMap()最后强转ParsedSum取值。层级一多别名一多ClassCastException和NullPointerException就轮番上阵。这篇就围绕一个具体需求展开按create_time按月分桶统计每个月所有入库记录的success_count累加值。索引里每条记录长这样uuid、file_name、type、create_time、success_count。目标是输出「月份 当月成功条数总和」的列表。我会先把原始写法讲清楚再演示怎么用走 TaoToken 的 Codex 来陪你改这段代码——让它帮你核对父子聚合的别名、calendar_interval和拆桶取值是否对得上你回到本地 IDE 编译运行验证。适合谁看正在用restHighLevelClient写聚合、被嵌套桶取值绕晕的后端同学想借助 AI 编码助手提升改代码效率、又不想把 Key 和 Base URL 配错的开发者。2. 前置注册 TaoToken 并创建 Key在让 Codex 帮你改代码之前先把模型接入通道配好。这一步不复杂但有两个细节特别容易填错我见过不少人卡在这里。先打开官网注册账号https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content注册完成后进入控制台创建一把 API Key。Key 只在创建时完整展示一次复制下来存好后面配置要用。https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite创建 Key 的入口在这里https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite注意Base URL 只填到/api不要带/v1也不要把官网那个带 UTM 参数的地址填进去。这是最常见的两个配置错误。3. 可复制配置Codex 的 Base URL 与 config.tomlCodex 的配置有两种方式改config.toml或者用环境变量。我建议先用config.toml直观、好排查。配置文件一般放在~/.codex/config.tomlWindows 是%USERPROFILE%\.codex\config.toml。核心是把model_provider的base_url指向 TaoToken 的 API 地址model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY然后在环境变量里放刚创建的那把 Keyexport TAOTOKEN_API_KEYsk-你创建的那把KeyWindows PowerShell 用$env:TAOTOKEN_API_KEYsk-你创建的那把Key如果你更习惯纯环境变量方式也可以直接设置export OPENAI_BASE_URLhttps://taotoken.net/api export OPENAI_API_KEYsk-你创建的那把Key配好之后启动 Codex它会读取config.toml里的 provider 配置。这里的关键点再强调一次base_url是https://taotoken.net/api结尾没有/v1。填错的话请求会 404而且报错信息往往不直观容易误以为是 Key 的问题。4. 把原始聚合代码交给 Codex 检查配置通了接下来是正题。先把原始需求对应的完整代码贴给 Codex让它对照检查。原始代码大致是这样public ListSimpleTotalCountVO dataUpdateTrend() { SearchRequest searchRequest new SearchRequest(esIndexData.getReadDataLog()); SearchSourceBuilder searchSourceBuilder new SearchSourceBuilder(); // 父聚合按月分桶 AggregationBuilder histogram AggregationBuilders.dateHistogram(DataManageConstant.TO_TIME) .field(DataManageConstant.CREATE_TIME) .format(DataManageConstant.DATE_TIME_PATTERN2) .calendarInterval(DateHistogramInterval.MONTH); // 子聚合对 success_count 求和 AggregationBuilder sum AggregationBuilders.sum(DataManageConstant.MONTH_SUCCESS_SUM) .field(DataManageConstant.SUCCESS_COUNT); histogram.subAggregation(sum); searchSourceBuilder.aggregation(histogram).size(0); searchRequest.source(searchSourceBuilder); ListSimpleTotalCountVO simpleTotalCountVOS new ArrayList(); try { SearchResponse search restHighLevelClient.search(searchRequest, RequestOptions.DEFAULT); Aggregation aggregation search.getAggregations().get(DataManageConstant.TO_TIME); List? extends Histogram.Bucket buckets ((Histogram) aggregation).getBuckets(); for (Histogram.Bucket bucket : buckets) { MapString, Aggregation asMap bucket.getAggregations().getAsMap(); ParsedSum parsedSum (ParsedSum) asMap.get(DataManageConstant.MONTH_SUCCESS_SUM); double value parsedSum.getValue(); int i new Double(value).intValue(); simpleTotalCountVOS.add(SimpleTotalCountVO.builder() .name(bucket.getKeyAsString()) .value(i) .build()); } } catch (IOException e) { throw new RuntimeException(e); } return simpleTotalCountVOS; }把这段贴给 Codex 时可以这样提问让它聚焦在几个易错点上这段 restHighLevelClient 的聚合查询父聚合是 dateHistogram 按月分桶 子聚合是 sum 对 success_count 求和。请帮我检查 1. 父子聚合的别名是否一致取值时 get 的 key 有没有写错 2. calendar_interval 用 MONTH 是否正确format 会不会影响 keyAsString 3. 拆桶时 getAggregations().getAsMap() 强转 ParsedSum 的写法有没有隐患 4. size(0) 的位置对不对。Codex 通常会指出几个点。第一DataManageConstant.TO_TIME和DataManageConstant.MONTH_SUCCESS_SUM这两个别名必须和 DSL 里完全一致大小写、下划线都不能差否则get()返回 null强转直接 NPE。第二calendarInterval(DateHistogramInterval.MONTH)在 7.x 之后推荐用calendarInterval老版本可能用interval要确认 ES 版本。第三bucket.getKeyAsString()返回的是格式化后的时间字符串如果format设成yyyy-MM-dd那 key 就是每月第一天符合预期。5. 验证请求跑通并确认结果改完代码后回到本地 IDE 编译运行。为了确认聚合逻辑本身没问题可以先用 Kibana 或 curl 直接跑一遍 DSL对照结果GET your_index/_search { size: 0, aggs: { toTime: { date_histogram: { field: create_time, calendar_interval: month, format: yyyy-MM-dd }, aggs: { monthSuccessSum: { sum: { field: success_count } } } } } }返回结构里每个 bucket 的key_as_string是月份monthSuccessSum.value是当月累加值。Java 端跑出来的SimpleTotalCountVO列表应该和这个一一对应。如果success_count在索引里是字符串类型原始数据里它确实是8990这种带引号的那sum聚合会报错或者返回 0。这时候要么在 mapping 里把它改成数值类型要么在写入时转换。Codex 在检查时一般也会提醒这一点值得留意。提示验证阶段如果只想快速确认模型接入是否正常可以先用模型对话跑一个简单请求确认通道没问题再回到代码调试。6. 本篇常见错排查报错一java.lang.NullPointerException在parsedSum.getValue()。八成是别名对不上。检查AggregationBuilders.sum(monthSuccessSum)里的名字和asMap.get(monthSuccessSum)是否完全一致。常量类里如果拼写有出入编译不报错但运行必炸。报错二ClassCastException: ParsedLong cannot be cast to ParsedSum。如果你用的是value_count或cardinality子聚合返回类型不是ParsedSum。本篇用的是sum所以是ParsedSum别混。报错三请求 404 或连接被拒。先查 Base URL。https://taotoken.net/api结尾不带/v1也不要把官网带 UTM 的地址填进去。Key 用创建的那把环境变量名要和config.toml里的env_key对上。报错四calendar_interval不识别。ES 7.2 之前没有calendar_interval要用interval。确认你的 ES 版本或者让 Codex 帮你按版本改写。报错五sum结果为 0。success_count字段类型是 text/keyword 时无法求和。用GET your_index/_mapping确认字段类型必要时重建索引或加fielddata不推荐最好改 mapping。7. 继续用 Codex 陪你改代码聚合查询这类代码难点往往不在 DSL 本身而在 Java 端拆响应时的层级和类型转换。把原始代码和报错信息一起丢给 Codex让它逐行核对别名、类型和取值路径比自己在 IDE 里打断点快得多。配好通道之后日常改代码、查报错、写单元测试都可以让它参与。如果你后面要做长期的编码任务或者 Agent 类工作流可以了解下 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite接入文档在这里配置细节和参数说明都能查到https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite我自己的习惯是先把 DSL 在 Kibana 里跑通确认聚合结构没问题再把 Java 代码贴给 Codex 检查拆桶逻辑。这样两边对照出错时能快速定位是查询写错了还是解析写错了。