ANTLR4 词法规则（Lexer Rules）完全指南：Token 定义、词法模式、递归规则与 Lexer 命令实战
2026/9/21 1:23:51
1. 401 与 authenticated: false 到底卡在哪一层
Kimi Code 通过 HTTP 模式连接 BrickCore MCP Server 时，出现401或对话里提示authenticated: false，绝大多数情况不是网络不通，也不是 BrickCore 服务没起来，而是认证信息放错了位置。Kimi Code 的 MCP 配置里有两个容易混淆的入口：一个是Environment Variables（环境变量），一个是headers（请求头）。HTTP 传输模式下，Authorization: Bearer <MCP_API_KEY>必须写在 headers 里，写进环境变量不会随 HTTP 请求发出去，服务端拿不到凭证，自然返回 401。
这里还有一个更隐蔽的坑：很多人把「调模型用的 Key」和「MCP Server 的 Key」当成同一个东西。Kimi Code 本身要调大模型，这部分走的是模型通道，Base URL 指向https://taotoken.net/api，Key 在 TaoToken 官网创建；而 BrickCore MCP Server 的鉴权，用的是 BrickCore 系统管理 → MCP 配置里生成的MCP_API_KEY。两者职责完全不同，TaoToken 只负责模型 Key 和通道配置，不替代 MCP_API_KEY。把这两个 Key 混用，就会出现「模型能回话，但一调 MCP 工具就 401」的典型现象。
这篇按排障视角走一遍：先分清两类 Key，再给出可复制的 Kimi Code 配置，然后用 curl 和对话双重验证，最后把常见报错逐条对照。适合正在用 Kimi Code 接 BrickCore MCP、卡在认证环节的测开和开发同学。
2. 先分清两类 Key：模型 Key 与 MCP_API_KEY
排障第一步不是改配置，而是搞清楚你手上到底有几个 Key、各自管什么。我见过太多人拿着模型 Key 去填 MCP 的 Authorization，改了半天没效果。
模型侧：Kimi Code 要调用大模型能力，需要一个模型通道的 Key。这个 Key 在 TaoToken 官网创建，创建入口在控制台的 API Keys 页面。模型请求的 Base URL 填https://taotoken.net/api。这部分配通之后，Kimi Code 才能正常对话、读代码、生成脚本。
MCP 侧：BrickCore MCP Server 的鉴权是独立的。管理员登录 BrickCore 后，进入系统管理 → MCP 配置，开启 MCP Server，填写平台对外地址，并设置一个足够长的随机MCP_API_KEY。使用者则在数据看板 → 首页看板 → BrickCore MCP Server 卡片里复制 URL 或一键复制 JSON。这个MCP_API_KEY才是填进 Kimi Code headers 里的那个值。
| 用途 | Key 来源 | 配置位置 | 作用 |
|---|---|---|---|
| 调模型 | TaoToken 控制台 API Keys | Kimi Code 模型配置 / Base URL | 让 Kimi Code 能对话、生成 |
| 调 MCP 工具 | BrickCore 系统管理 → MCP 配置 | Kimi Code mcp.json 的 headers | 让 MCP Server 认你的请求 |
注意：MCP_API_KEY 等同 API Token，权限不小。生产环境建议走 HTTPS、定期轮换，并按 RBAC 控制账号权限。
如果你还没创建模型 Key，可以先到官网 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 注册并创建，模型侧 Base URL 用https://taotoken.net/api。这一步只解决「Kimi Code 能说话」，不解决「MCP 能连上」，两者别混。
3. Kimi Code 接 BrickCore MCP 的可复制配置
配置前先确认 BrickCore 侧已经开启 MCP Server 并保存。默认端点路径是http://<host>:8000/brickcore/agent-hub/，末尾建议带斜杠。本地部署把 host 换成localhost，线上换成你的域名或 IP。
3.1 方式 A：命令行添加（推荐）
Kimi Code 支持用kimi mcp add直接注册 HTTP 类型的 MCP Server。关键是--header参数，把 Authorization 显式带上：
kimi mcp add --transport http brickcore \ http://43.142.83.156:8000/brickcore/agent-hub/ \ --header "Authorization: Bearer 你的MCP_API_KEY"本地部署改成：
kimi mcp add --transport http brickcore \ http://localhost:8000/brickcore/agent-hub/ \ --header "Authorization: Bearer 你的MCP_API_KEY"注意--transport必须是http，不要选成 stdio。stdio 模式才用环境变量传参，HTTP 模式认的是 headers。
3.2 方式 B：编辑 mcp.json
如果你习惯改配置文件，路径如下：
- Linux / macOS：
~/.kimi/mcp.json - Windows：
C:\Users\你的用户名\.kimi\mcp.json
内容结构：
{ "mcpServers": { "brickcore": { "url": "http://43.142.83.156:8000/brickcore/agent-hub/", "headers": { "Authorization": "Bearer 你的MCP_API_KEY" } } } }保存后重启 Kimi Code。配置检查项对照：
| 检查项 | 正确值 |
|---|---|
| Transport | http |
| Requires OAuth | 不要勾选（用 Bearer API Key） |
| Authorization | 与平台 MCP_API_KEY 完全一致 |
| url 末尾 | 建议带/ |
3.3 为什么不能写进 Environment Variables
Kimi Code 的 Environment Variables 是给 stdio 子进程用的，HTTP 模式下这些变量不会自动变成请求头。你把Authorization塞进 env，Kimi Code 发起 HTTP 请求时 headers 里是空的，BrickCore 的mcp/auth.py校验 Bearer 失败，直接 401。这就是authenticated: false最常见的来源。记住一句话：HTTP 走 headers，stdio 走 env。
4. 验证请求与成功结果
配置完别急着在对话里试，先用 curl 确认端点可达、鉴权通过，能把问题范围缩小到「配置」还是「服务」。
4.1 curl 自检
curl -s -o /dev/null -w "%{http_code}" \ -H "Authorization: Bearer 你的MCP_API_KEY" \ "http://43.142.83.156:8000/brickcore/agent-hub/"期望返回200或至少非401。如果返回 401，说明 Key 不对或没带上；返回 404，多半是 Nginx 没把/brickcore/agent-hub/反代到 backend:8000；连接被拒，检查地址、端口、防火墙。
4.2 Kimi Code 对话验证
重启 Kimi Code 后，在对话里输入：
用 BrickCore 查看 MCP 是否已连接成功或者直接让它干活：
用 BrickCore 列出所有项目能返回项目列表，就说明 MCP 连接成功。再试一个带写操作的场景，验证 preview → confirm 流程：
帮我在测试环境 preview 接口计划 plan_id=5AI 会调用preview_run_api_plan，返回影响范围（计划名、条数、环境）和一个 5 分钟有效的confirm_token。你回复「确认执行」，它才带 token 调run_api_plan，返回 record_id，异步执行。写操作必须走这一步，token 在 Redis 一次性消费，用后即废，防止 AI 在 IDE 里误触跑生产计划。
4.3 模型侧顺带验证
如果你模型 Key 还没配通，Kimi Code 连对话都起不来。模型侧 Base URL 填https://taotoken.net/api，Key 用 TaoToken 控制台创建的。想先验证模型通道，可以用模型对话页面发一条测试请求，确认能正常返回，再回到 MCP 配置。模型通、MCP 通，两条链路分开验证，排障效率高很多。
5. 本篇常见报错逐条排查
把原文第九节的现象整理成对照表，遇到问题直接查：
| 现象 | 原因 | 处理 |
|---|---|---|
| 401 / authenticated: false | Key 错误；或 Authorization 误写在 env 而非 headers | 检查 headers 是否带 Bearer，Key 是否与平台一致 |
| Connection failed 但后端 200 | Windows 上 Kimi Code 偶发编码显示问题 | 对话能返回数据可忽略红字 |
| 连接 refused | 地址/端口错、Nginx 反代缺失、防火墙拦截 | 核对 host:port，检查反代与放行 |
| 工具列表空 | MCP 未启用或配置未保存 | 回 BrickCore 系统管理 → MCP 配置确认已开启并保存 |
| 执行无权限 | 平台账号 RBAC 不足 | 找管理员补权限 |
| Nginx 404 | 只反代了 /api，没反代 /brickcore/agent-hub/ | 在 nginx-docker.conf 补上该路径到 backend:8000 |
几个容易忽略的点：一是Requires OAuth不要勾，勾了会走 OAuth 流程，和 Bearer Key 冲突；二是 url 末尾斜杠，有些反代规则对末尾敏感；三是改完配置一定重启 Kimi Code，热加载不一定生效。
如果 curl 返回 200 但 Kimi Code 里还是 authenticated: false，重点查 headers 拼写，Authorization大小写、Bearer后面有没有空格、Key 有没有多余换行，这些细节最容易翻车。
6. 配通之后：模型通道与 MCP 各归各位
把这条链路理顺之后，日常用起来是这样的：Kimi Code 在 CLI/IDE 里写代码、改用例，模型能力走 TaoToken 通道；需要查测试平台数据、跑 API 回归时，通过 MCP 调 BrickCore 的工具。两者互不干扰，Key 也各管各的。
模型 Key 和通道配置在 TaoToken 官网 https://taotoken.net/?utm_source=taotoken_aicg_blog_end 创建，Base URL 用https://taotoken.net/api；MCP 的 Authorization 始终来自 BrickCore 的 MCP_API_KEY，按kimi mcp add --transport http ... --header或 mcp.json 的 headers 填写。TaoToken 只出现在模型 Key 和通道配置层，不替代 MCP_API_KEY，这一点在排障时反复确认，能省掉大量来回试错。
如果你还在做长期编码或 Agent 类项目，需要更稳定的模型调用额度，可以了解下 Coding Plan，把模型通道固定下来，MCP 侧专心调工具。接入细节和参数说明在接入文档里有完整对照，遇到 headers 或反代问题可以先翻文档再动手改配置。