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_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_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 export，CI 里用平台的 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; c=json.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 会更省心。
