1. 从 FAQ 页面到能对话的知识库中间卡在哪很多团队做智能问答系统的起点都很像官网有一堆 FAQ客服每天重复回答同样的问题于是想把 FAQ 变成知识库让模型来答。方向没错但真正动手时会发现链路比想象中长——要爬网页、要抽问答对、要建向量库、要接模型每一步都涉及不同的工具和鉴权。Amazon Q CLI 加 Bedrock 知识库这套组合恰好能把这条链路串起来。Q CLI 是命令行里的 AI 助手从 1.9.0 版本开始支持 MCP意味着它能调用外部工具Bedrock 知识库负责把结构化数据变成可检索的向量存储。两者配合理论上可以做到用自然语言让 Q CLI 去爬 FAQ 页面整理成 Excel再导入知识库最后用模型生成回答。但我在实际搭这套东西时最先撞上的不是技术难点而是 Key 的管理问题。Q CLI 调 MCP Server 需要一套鉴权Bedrock 知识库检索需要另一套凭证模型推理又是第三套。三套 Key 分散在不同配置文件里改一个环境就要同步改三处调试时经常分不清是哪个环节的鉴权挂了。更麻烦的是MCP 工具调用链一旦变长报错信息往往只告诉你鉴权失败不告诉你是哪一层失败。这篇要解决的就是这个问题把 MCP endpoint 和鉴权配置统一收口到 TaoToken用一套 Key 打通 Q CLI 到 Bedrock 知识库的调用链。适合正在搭企业问答系统、被多 Key 配置折腾过的开发者。下面从环境准备开始一步步给出可复制的配置片段最后跑一次完整的问答链路验证。2. 用 TaoToken 统一 MCP 调用链的鉴权入口先说清楚 TaoToken 在这套架构里扮演什么角色。它提供的是统一的 API 接入层把模型调用、MCP 工具调用的鉴权收敛到一个 Base URL 加一个 Key。你不需要在 Q CLI 的 mcp.json、Bedrock 的 SDK 配置、模型推理的客户端里分别填不同的凭证而是让这些调用都指向同一个入口。具体来说Q CLI 通过 MCP 协议调用外部工具时MCP Server 的 endpoint 可以配置成 TaoToken 的 API 地址Bedrock 知识库检索和模型推理同样走这个统一入口。这样做的直接好处是换环境时只改一处 Key排查鉴权问题时只需要看一个地方。TaoToken 的 API 地址是https://taotoken.net/api注意这个地址不带任何查询参数直接作为 Base URL 使用。官网入口在https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end注册和查看文档都从这里进。在开始配置之前你需要先拿到 Key。进入控制台的 API Keys 页面创建一个建议按用途命名比如qcli-bedrock-kb方便后续区分。创建后 Key 只显示一次复制保存好。这里有个容易踩的坑很多人会把官网地址和 API 地址搞混。官网地址带 UTM 参数是给人看的API 地址是给程序调用的不要带任何多余参数。配置 MCP Server 时如果填了带参数的地址请求会直接失败。另外TaoToken 支持模型对话、Coding Plan、控制台管理等多个入口。如果你后续要做长期编码或 Agent 任务可以了解 Coding Plan如果只是验证模型连通性用模型对话页面就够了。但本篇的重点是 MCP 调用链的鉴权统一所以配置都围绕 API 地址展开。配置前还需要确认 Q CLI 的版本。MCP 支持是从 1.9.0 开始的用q --version检查一下。如果版本过低先升级。Bedrock 知识库那边确保你的知识库已经创建好并且有可用的数据源这部分不在本篇展开假设你已经有一个待接入的知识库。3. 可复制的 MCP 与 Bedrock 配置片段这一节给出具体的配置文件。Q CLI 的 MCP 配置在~/.aws/amazonq/mcp.jsonBedrock 相关的凭证通过环境变量注入。两处都指向 TaoToken 的统一入口。先看 MCP 配置。原来的 Playwright MCP Server 配置里command 和 args 是固定的但如果你要通过 TaoToken 代理 MCP 调用需要在环境变量里注入 Base URL 和 Key。下面这个片段可以直接复制把YOUR_TAOTOKEN_KEY替换成你实际的 Key{ mcpServers: { playwright: { command: npx, args: [-y, executeautomation/playwright-mcp-server], env: { TAOTOKEN_BASE_URL: https://taotoken.net/api, TAOTOKEN_API_KEY: YOUR_TAOTOKEN_KEY } } } }注意env字段里的两个变量。TAOTOKEN_BASE_URL固定为https://taotoken.net/api不要加斜杠结尾也不要加任何查询参数。TAOTOKEN_API_KEY填你创建的那个 Key。接下来是 Bedrock 知识库检索和模型推理的配置。这部分不走 mcp.json而是通过 Python SDK 的客户端配置。下面是一个完整的配置片段包含 Base URL、Key 和 Model ID 三件套import boto3 import os # TaoToken 统一入口配置 TAOTOKEN_BASE_URL https://taotoken.net/api TAOTOKEN_API_KEY os.environ.get(TAOTOKEN_API_KEY) # Bedrock 知识库配置 KNOWLEDGE_BASE_ID YOUR_KB_ID MODEL_ID anthropic.claude-3-sonnet-20240229-v1:0 # 构建 bedrock-agent-runtime 客户端 bedrock_agent_runtime boto3.client( service_namebedrock-agent-runtime, endpoint_urlTAOTOKEN_BASE_URL, aws_access_key_idTAOTOKEN_API_KEY, aws_secret_access_keyTAOTOKEN_API_KEY, region_nameus-east-1 ) # 构建 bedrock-runtime 客户端用于模型推理 bedrock_runtime boto3.client( service_namebedrock-runtime, endpoint_urlTAOTOKEN_BASE_URL, aws_access_key_idTAOTOKEN_API_KEY, aws_secret_access_keyTAOTOKEN_API_KEY, region_nameus-east-1 )这里有几个关键点。endpoint_url指向 TaoToken 的 API 地址aws_access_key_id和aws_secret_access_key都填同一个 Key。Model ID 根据你实际使用的模型填写上面给的是 Claude 3 Sonnet 的示例。如果你用的是其他模型替换成对应的 ID。如果你用的是 Codex 或 Cline 这类工具配置方式类似核心都是 Base URL 加 Key 加 Model ID 三件套。Codex 的auth.json里填 Base URL 和 KeyCline 的 MCP 配置里同样注入这两个环境变量。CC Switch 切换配置时也只需要切换这一组值。配置完成后启动 Q CLI 的 chat 模式输入/mcp查看 MCP Server 状态。如果配置正确会看到 playwright 处于 running 状态。如果显示 failed先检查 Key 是否有效再检查 Base URL 是否有多余字符。4. 跑一次完整的问答链路验证配置就绪后用一次完整的问答来验证链路是否跑通。这个验证分两步先用 Q CLI 通过 MCP 爬取 FAQ 页面并整理成结构化数据再用 Bedrock 知识库检索加模型生成回答。第一步在 Q CLI 的 chat 里输入自然语言指令让它去爬一个 FAQ 页面。指令可以这样写访问 https://www.example.com/faq点击 [data-sectionbusiness]只获取页面的文字内容而非 html 内容然后将文字内容保存到 faq_business.txtQ CLI 会调用 Playwright MCP Server 的工具链playwright_navigate打开页面playwright_click点击指定元素playwright_get_visible_text获取可见文本最后用文件写入工具保存。整个过程在终端里能看到工具调用的日志。这里有个细节值得注意指令里明确写了[data-sectionbusiness]这个 selector。如果不写模型可能会自己猜一个 selector猜错了就点不到正确的链接。获取准确 selector 的方法是在浏览器开发者工具里选中目标元素右键复制 selector然后放进指令里。爬取完成后继续让 Q CLI 把文本整理成 Excel。指令类似读取 faq_business.txt将内容按问答对拆分成结构化数据每个问答对包含 Category、Sub-Category、Question、Answer 四列保存为 faq_business.xlsxQ CLI 会调用文件读取和数据处理工具几分钟内生成 Excel 文件。这一步的产出是后续知识库导入的数据源。第二步验证 Bedrock 知识库检索和模型回答。用前面配置好的 Python 客户端先做一次检索retrieval_config { vectorSearchConfiguration: { numberOfResults: 3 } } # 如果问题分类明确添加元数据过滤 category Business if category ! others: retrieval_config[vectorSearchConfiguration][filter] { equals: { key: Category, value: category } } response bedrock_agent_runtime.retrieve( retrievalQuery{text: 如何修改订单}, knowledgeBaseIdKNOWLEDGE_BASE_ID, retrievalConfigurationretrieval_config ) print(response[retrievalResults])如果检索返回了结果说明知识库链路通了。接下来做模型推理system_prompt 你是一个客服助手根据提供的知识库内容回答用户问题。如果知识库中没有相关信息直接告知用户。 user_message f用户问题如何修改订单\n\n知识库内容{response[retrievalResults]} messages [{ role: user, content: [{text: user_message}] }] inference_config {temperature: 0} model_response bedrock_runtime.converse( modelIdMODEL_ID, messagesmessages, system[{text: system_prompt}], inferenceConfiginference_config ) print(model_response[output][message][content][0][text])如果模型返回了基于知识库内容的回答整条链路就跑通了。从 Q CLI 爬取数据到知识库检索再到模型生成回答全部走 TaoToken 的统一入口。实测下来这套配置最省心的地方是排查问题。以前三套 Key 的时候报错要看三个地方现在只需要确认一个 Key 是否有效Base URL 是否正确。如果检索返回空先检查知识库 ID 和过滤条件如果模型不返回先检查 Model ID 和推理参数。5. 常见报错与排查对照配置和验证过程中有几类报错出现频率最高。下面按报错信息对照排查都是实际遇到过的。401 Unauthorized这是最常见的鉴权失败。先检查TAOTOKEN_API_KEY是否填对有没有多余空格。然后确认 Base URL 是不是https://taotoken.net/api不要带 UTM 参数不要加斜杠结尾。如果 Key 是在控制台刚创建的确认复制完整了Key 只显示一次。local proxy failed / connection refused这个报错通常出现在 MCP Server 启动阶段。检查mcp.json里的env字段是否正确注入特别是TAOTOKEN_BASE_URL有没有拼错。另外确认 Q CLI 版本在 1.9.0 以上低版本不支持 MCP 的 env 注入。reading choices 相关报错这个一般出现在模型推理返回解析阶段。检查converse调用的返回结构不同模型的返回字段可能略有差异。如果用的是 Claude 系列output.message.content[0].text是标准路径。如果报错说找不到 choices说明你可能在用 OpenAI 格式的返回解析但实际调用的是 Bedrock 格式两者结构不同。OAuth 相关报错如果你在配置里混用了 OAuth 凭证和 API Key会出现这个报错。TaoToken 的接入用的是 API Key不需要 OAuth 流程。检查auth.json或环境变量里有没有残留的 OAuth 配置清掉即可。知识库检索返回空这不是鉴权问题而是检索配置问题。先确认KNOWLEDGE_BASE_ID正确再检查元数据过滤条件。如果Category过滤值写错了检索会返回空。可以先把过滤条件去掉用纯向量检索测试确认知识库本身有数据。MCP 工具调用超时Playwright 爬取网页时如果页面加载慢或元素找不到会超时。检查 selector 是否正确页面是否需要登录。可以在指令里加等待时间或者先用playwright_navigate单独测试页面能否打开。排查时有个原则先确认鉴权层通不通再确认业务层对不对。鉴权层的检查很简单用 curl 直接请求 TaoToken 的 API 地址看返回状态码。如果 401就是 Key 或 Base URL 的问题如果 200说明鉴权没问题再去查业务配置。6. 把 Key 收口之后链路才真正可维护搭完这套系统最大的感受是智能问答系统的难点不在模型而在链路的可维护性。Q CLI 加 Bedrock 知识库的组合本身能力很强MCP 让工具调用变得灵活元数据过滤让检索更精准。但如果鉴权分散在三四个地方每次调试都像在拆盲盒。把 MCP endpoint 和 Bedrock 凭证统一到 TaoToken 之后配置从三套变成一套排查从三个地方变成一个地方。这不是功能上的增强而是工程上的减负。对于要长期维护的问答系统来说这种减负比多接一个模型更有价值。如果你正在搭类似的系统建议先把鉴权收口做好再往上叠功能。MCP 调用链越长鉴权统一带来的收益越大。后续如果要加新的 MCP Server或者换模型只需要改一处配置不用动整条链路。最后留一个实用技巧在mcp.json和 Python 配置里把 Base URL 和 Key 都通过环境变量注入不要硬编码在文件里。这样切换环境时只需要改环境变量配置文件可以纳入版本管理团队协作时也不会因为 Key 泄露而返工。