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/apiKey 在 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 KeysKimi 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_sourcetaotoken_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.jsonWindowsC:\Users\你的用户名\.kimi\mcp.json内容结构{ mcpServers: { brickcore: { url: http://43.142.83.156:8000/brickcore/agent-hub/, headers: { Authorization: Bearer 你的MCP_API_KEY } } } }保存后重启 Kimi Code。配置检查项对照检查项正确值TransporthttpRequires OAuth不要勾选用 Bearer API KeyAuthorization与平台 MCP_API_KEY 完全一致url 末尾建议带/3.3 为什么不能写进 Environment VariablesKimi Code 的 Environment Variables 是给 stdio 子进程用的HTTP 模式下这些变量不会自动变成请求头。你把Authorization塞进 envKimi Code 发起 HTTP 请求时 headers 里是空的BrickCore 的mcp/auth.py校验 Bearer 失败直接 401。这就是authenticated: false最常见的来源。记住一句话HTTP 走 headersstdio 走 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_id5AI 会调用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/apiKey 用 TaoToken 控制台创建的。想先验证模型通道可以用模型对话页面发一条测试请求确认能正常返回再回到 MCP 配置。模型通、MCP 通两条链路分开验证排障效率高很多。5. 本篇常见报错逐条排查把原文第九节的现象整理成对照表遇到问题直接查现象原因处理401 / authenticated: falseKey 错误或 Authorization 误写在 env 而非 headers检查 headers 是否带 BearerKey 是否与平台一致Connection failed 但后端 200Windows 上 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_sourcetaotoken_aicg_blog_end 创建Base URL 用https://taotoken.net/apiMCP 的 Authorization 始终来自 BrickCore 的 MCP_API_KEY按kimi mcp add --transport http ... --header或 mcp.json 的 headers 填写。TaoToken 只出现在模型 Key 和通道配置层不替代 MCP_API_KEY这一点在排障时反复确认能省掉大量来回试错。如果你还在做长期编码或 Agent 类项目需要更稳定的模型调用额度可以了解下 Coding Plan把模型通道固定下来MCP 侧专心调工具。接入细节和参数说明在接入文档里有完整对照遇到 headers 或反代问题可以先翻文档再动手改配置。