TTCN3新执行器系列-序:从 settings.json 骨架到 TaoToken 统一 Key 的配置验证
1. 为什么 TTCN3 新执行器要先搞定配置骨架TTCN3 新执行器是什么简单说它是把 TTCN3 测试套从「内存对象模型」往「语言转换模型」迁移的执行引擎适合 actionword 驱动的测试用例尤其当测试套里 75% 以上都是用例代码时它的优势会很明显。它适合谁适合正在做 TTCN3 执行器预研、需要在本地或 CI 里跑通第一版编译链路的测试工程师。我参与过类似的项目踩过的坑很集中执行器本身还没跑起来环境配置先乱成一锅粥。脚本路径、编译器参数、AI 辅助工具的 Key 散落在各个 shell 脚本和 CI 变量里换台机器就要重新对一遍。所以这个系列的第一篇不碰执行器源码只做一件事——把settings.json骨架立起来再把 AI 工具的 Key 统一收口到 TaoToken最后做一次连通性验证。做完这一步你至少能确认「环境是活的」后面接执行器才有意义。这篇的目标很具体给你一份可复制的settings.json骨架告诉你 TaoToken 统一 Key 写在哪以及怎么用一条请求验证它真的通了。全程不需要改执行器任何一行代码。2. TaoToken 前置准备统一 Key 的定位在讲配置之前先把 TaoToken 的角色说清楚。它在这里不是执行器的一部分而是你本地和 CI 里所有 AI 辅助工具代码补全、脚本生成、日志分析之类的统一入口。你只需要维护一个 Key而不是每个工具配一份。官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址是 https://taotoken.net/api 。注意 API 地址不带 UTM 参数配置里写干净的这个就行。拿 Key 的路径是进控制台在 API Keys 页面创建一个新 Key。建议按用途命名比如ttcn3-exec-local和ttcn3-exec-ci这样后面排查问题时能一眼看出是哪个环境在用。创建完先复制保存页面刷新后通常不再完整显示。注意Key 只存在你的本地配置或 CI 的加密变量里不要写进会提交到仓库的settings.json。下面骨架里我会用占位符你替换成真实值即可。如果你后面要长期跑编码类任务比如让工具批量生成 actionword 映射代码可以了解下 Coding Plan它更适合高频、长会话的场景只是偶尔验证模型通不通用模型对话页面就够了。3. 可复制的 settings.json 骨架下面这份骨架是我实测下来比较稳的结构。它分三块执行器相关路径、AI 工具统一入口、以及每个工具自己的开关。你可以直接复制把占位符换掉。{ executor: { name: ttcn3-new-executor, workspace: ${WORKSPACE}/ttcn3, compile: { target: actionword, timeoutSec: 120, cacheDir: ${WORKSPACE}/.ttcn3-cache } }, ai: { provider: taotoken, baseUrl: https://taotoken.net/api, apiKey: ${TAOTOKEN_API_KEY}, defaultModel: claude-sonnet, timeoutSec: 60 }, tools: { codeAssist: { enabled: true, useAi: true }, logAnalyzer: { enabled: true, useAi: true } } }几个关键点解释一下。baseUrl固定写https://taotoken.net/api不要带任何查询参数。apiKey用环境变量占位本地用.env或 shell exportCI 里用平台的 secret 变量注入。compile.timeoutSec先给 120这是给后面执行器编译留的余量现在不影响验证。如果你在 CI 里用注入方式大概是这样export TAOTOKEN_API_KEY你的Key export WORKSPACE$(pwd)本地的话把这两行放进你的 shell 配置或者项目根目录的.env然后 source 一下。这样settings.json本身可以安全提交Key 永远不进仓库。4. 一次连通性验证确认 Key 真的通了配置写完不代表通了。我见过太多次「配置看着没问题请求一发就 401」。所以这一步必须做而且要在接执行器之前做。验证方式用最朴素的 curl直接打模型对话接口。命令如下curl -s -X POST https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer ${TAOTOKEN_API_KEY} \ -H Content-Type: application/json \ -d { model: claude-sonnet, messages: [ {role: user, content: reply with ok only} ], max_tokens: 16 }成功的话你会拿到一个 JSON里面choices[0].message.content大概是ok这样的短回复。看到这个就说明三件事都对了Key 有效、baseUrl 正确、网络能到。如果你更习惯用工具验证也可以直接在模型对话页面发一条同样的消息效果一样只是少了脚本化的那一步。CI 里建议用 curl方便把结果写进日志。验证通过后回到settings.json确认ai.apiKey读到的确实是同一个 Key。可以在本地跑一句python3 -c import json,os; cjson.load(open(settings.json)); print(c[ai][baseUrl], bool(os.environ.get(TAOTOKEN_API_KEY)))输出https://taotoken.net/api True就说明骨架和 Key 对上了。5. 本篇常见错排查报 401 或 invalid api key九成是 Key 没注入成功。先echo ${TAOTOKEN_API_KEY}看有没有值再看是不是复制时带了空格或换行。CI 里注意 secret 变量名大小写。报 404 或 not found检查baseUrl是不是多写了路径比如写成了https://taotoken.net/api/v1又在请求里拼了/v1。基址就写https://taotoken.net/api路径在请求里补。请求超时先确认timeoutSec不是设得太小60 秒一般够。如果本地网络本身慢把 curl 加-m 30单独测一次排除是配置问题还是网络问题。settings.json 解析失败最常见是尾随逗号。JSON 不允许最后一个元素后面有逗号用编辑器格式化一下就能看出来。CI 里能跑本地不能跑多半是环境变量作用域问题。本地 export 只对当前 shell 有效换个终端就没了写进.env并 source 更稳。Key 泄露风险如果你不小心把真实 Key 提交了立刻去控制台吊销重建别犹豫。这也是为什么骨架里坚持用环境变量占位。6. 下一步把验证过的配置接进执行器到这里你已经有了三样东西一份可提交的settings.json骨架、一个统一收口的 TaoToken Key、以及一次成功的连通性验证。这三样是后面接 TTCN3 新执行器的地基地基不稳后面编译报错你根本分不清是执行器的问题还是环境的问题。下一篇会在这个骨架上加执行器的编译入口和 actionword 映射配置。如果你现在想先把 Key 和文档看一遍可以从 API Keys 页面 和 接入文档 入手把 Key 管理和请求格式确认清楚。长期要在 CI 里跑编码类任务的顺手看下 Coding Plan 会更省心。