teamai-cli 调用模型没反应 / 先确认是密钥没读到还是出口不通

teamai-cli 执行后既不报错也不返回，最常见的两种原因是密钥没有被进程读进去，以及请求根本没走到模型端点。两者表现很像：终端停在原地，没有输出，没有错误码。判断方向是先用调试输出确认请求是否发出，再按“进程内配置 → 密钥 → 域名解析与出口 → 端点可达性”逐层缩小范围。通常不需要重装工具，也不必立刻怀疑模型服务本身；多数情况是配置层级放错、环境变量没进到当前进程，或者超时设得偏长导致等待被误认为卡死。

teamai-cli 调用模型没反应时，先分清“请求没发出”和“请求发出但没回”。打开调试日志可以看到是否走到了发起请求这一步；若没有请求记录，重点查进程内配置与密钥加载；若有请求记录但长时间无响应，重点查域名解析、出口连通性和超时设置。最后用一次最小请求单独测端点，把工具问题和外部服务问题分开。所有判断以命令输出和日志行为为准，不要凭等待时长下结论。

先打开调试输出，看请求是否真的发出去了

没发请求和发了没回，处理路径完全不同。前者要查配置加载，后者要查网络和端点。调试开关的具体参数名以你安装的 teamai-cli 版本为准，先用帮助命令确认：

teamai-cli `--help`
teamai-cli run `--help`

常见形式是设置日志级别或打开 verbose 开关，例如用环境变量提高日志级别，或者给子命令加调试参数。下面只是通用写法，实际名称需要按帮助输出替换：

# 方式一：环境变量（名称以帮助输出为准）
export TEAMAI_LOG_LEVEL=debug

# 方式二：命令行参数（名称以帮助输出为准）
teamai-cli run `--verbose` "你好"

需要看的关键日志通常包含请求发出记录、目标地址、请求方法、状态码或连接阶段信息。可以关注这几类行：带有 request、POST、endpoint、host 的行表示工具准备发起调用；带有 connect、timeout、retry 的行表示已经进入网络阶段。如果日志停在读取配置或鉴权之前，说明请求还没发出去；如果看到目标地址却没有任何响应记录，说明请求发出去了但在等返回。

把输出同时写入文件，方便事后翻查和提交：

teamai-cli run `--verbose` "你好" 2>&1 | tee teamai-debug.log

日志级别调高后输出会比较杂，建议只在排查阶段打开，确认问题后恢复默认级别，避免把调试信息长期留在终端记录里。

确认密钥已被进程读到

密钥未加载时，有的工具会直接报鉴权失败，也有的会静默等待或重试，看起来就像“没反应”。先确认当前 shell 里变量存在，但不要把值打印出来：

# 只判断是否存在和长度，不回显密钥内容
[ -n "$TEAMAI_API_KEY" ] && echo "key is set, length=${#TEAMAI_API_KEY}" || echo "key is missing"

变量存在不代表进程能读到。如果 teamai-cli 是通过图形界面、系统服务或另一个容器启动的，它的环境变量来源可能和你当前终端不同。比较稳妥的做法是在同一个终端会话里启动命令，或者把密钥写进工具自己的配置文件。

配置文件里密钥字段的位置和层级因版本而异，通常位于 provider 或 model 段下的 api_key、token 一类字段。放错层级是常见问题，例如写在了顶层而工具只读某个子段下的字段。改完配置后，用调试日志确认加载结果，重点看日志中是否出现读取配置文件的路径以及密钥字段被识别但值被打码的记录。如果日志显示密钥为空或字段未找到，问题就在这一层，不必再往下测网络。

确认域名解析与出口可达

密钥确认加载后，再判断请求有没有出得去。先测域名解析，再测连通性，两步分开看：

# 解析测试，把 api.example.com 换成配置文件里的实际域名
getent hosts api.example.com
nslookup api.example.com

# 连通性测试，端口按端点实际使用的 443 或其他端口替换
curl -v `--max-time` 10 https://api.example.com/ -o /dev/null

解析返回空结果或超时，说明问题在 DNS；解析正常但 curl 卡住或连接被拒绝，说明问题在出口或防火墙。curl 输出里的 Trying ... 之后长时间没有 Connected，通常指向网络路径不通；出现 Connection refused 则更可能是端口或目标地址写错。

同时检查代理相关环境变量是否被意外设置，或者本该设置却没有设置：

env | grep -i -E 'http_proxy|https_proxy|no_proxy'

如果终端能访问而 teamai-cli 不行，差异往往就在这些变量上：有的进程继承了代理设置，有的没有。超时时间的配置位置一般在配置文件或命令行参数里，名称可能类似 timeout、request_timeout。默认值偏长时，连接失败会表现为长时间无输出，排查阶段可以临时调短，让失败更快暴露出来，确认原因后再改回合适值。

用最小请求区分是端点慢还是工具本身卡住

做到这一步，需要把工具和外部服务分开判断。先绕过 teamai-cli，直接用 curl 对端点发一次最小请求。下面的骨架只保留必要字段，请求路径和字段名以你的端点文档为准：

curl -v `--max-time` 15 https://api.example.com/v1/chat \
  -H "Authorization: Bearer $TEAMAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"your-model","messages":[{"role":"user","content":"ping"}]}'

观察耗时可以用 curl -w 打印各阶段时间：

curl -o /dev/null -s -w 'dns:%{time_namelookup} connect:%{time_connect} total:%{time_total}\n' \
  `--max-time` 15 https://api.example.com/v1/chat \
  -H "Authorization: Bearer $TEAMAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"your-model","messages":[{"role":"user","content":"ping"}]}'

结果判读可以按这个思路：curl 很快返回 200 或正常响应，说明端点可用，问题更可能在 teamai-cli 的配置或参数处理；curl 返回 401 或 403，说明密钥或权限这一层还没过，回到第二步；curl 在 connect 阶段就超时，说明出口问题仍在，回到第三步；curl 能连上但 total 时间很长、迟迟没有响应体，说明端点侧慢或请求体过大，这时和工具本身无关，调超时或换时段重试更合理。

如果 curl 正常而 teamai-cli 仍然无输出，用同样的最小输入再跑一次工具，对比两边日志的时间点和目标地址，差异点通常能直接指出是哪一层配置没有生效。

把复现步骤与日志整理成可提交的信息

确认问题不在自己这一侧的配置后，整理信息再提交，能省掉来回补充的轮次。建议收集这些内容：

teamai-cli 的版本号和安装方式，可通过版本命令获取
完整的复现命令，包括参数和输入内容
调试级别日志，覆盖从启动到卡住的完整时间段
同一台机器上的 curl 最小请求结果，包含状态码和耗时输出
解析测试和连通性测试的输出
相关配置文件片段，只保留字段结构和层级，不保留值

脱敏是硬要求。日志和配置片段里不得出现密钥原文，也不要把完整请求头直接贴出。提交前用替换方式处理：

# 提交前把疑似密钥内容替换掉再人工检查一遍
sed -E 's/(Bearer )[A-Za-z0-9._-]+/\1<redacted>/g' teamai-debug.log > teamai-debug-redacted.log

替换后仍要人工过一眼，确认没有遗漏的 token、内网地址或账号信息。日志里保留时间戳、目标域名和状态码这些判断依据即可，密钥值对定位问题没有帮助。整理好的信息在团队内先对齐一次，确认是共性问题还是单机环境差异，再决定是否需要上游介入。