企业官网建设流程全解析

1. 为什么大模型读不懂你的数据库：从 2300 张表说起

你手里有一套本地 SQL 数据库，表不少，字段命名还带着浓浓的“历史遗留风”——比如t_fund_perf_cmp、FUND_NAV_CAL这种，注释基本靠猜。这时候你想让 DeepSeek 帮你写 SQL，把自然语言变成查询语句，听起来很美好，但一上手就卡住了：模型根本不知道你的表长什么样。

我试过最直接的办法，把建表语句一股脑贴进对话里。表少的时候还行，十几张表、几百个字段，DeepSeek 确实能写出像样的 SQL。但一旦表数量上去，比如某金融库有 2300+ 张表，光元数据就 40 多 MB，你不可能每次提问都塞进去。就算模型上下文够长，每次请求烧掉几十万 Token，成本也扛不住。更麻烦的是，模型在超长上下文里会“分心”，你问 A 表的字段，它可能扯到 B 表去。

所以核心矛盾是：模型需要表结构才能写 SQL，但表结构太大，不能一次性喂。解决办法不是把数据库整个倒给模型，而是让模型学会“按需取用”——先根据你的问题找到相关表，再拉取这些表的字段信息，最后生成 SQL。这个“按需取用”的通道，就是 MCP（Model Context Protocol）。

MCP 本质上是一套让大模型和外部数据源对话的协议。你可以把它理解成给 DeepSeek 装了一个“数据库目录查询插件”：模型不直接读库，而是通过你定义好的工具（Tool）去问——“哪些表跟‘基金业绩对比’有关？”、“把Fund_Performance_Compare的字段列给我”。工具在本地执行，只把精简后的结果返回给模型，Token 消耗可控，准确率也高。

这篇内容适合谁？如果你本地已经有 SQL 数据（MySQL、PostgreSQL、SQLite 都行），想让 DeepSeek 直接读取表结构并帮你写查询，又不想把整个 schema 塞进 prompt，那这套 MCP 配置就是为你准备的。下面我会给出可复制的 MCP 服务端代码、DeepSeek 接入配置、SQL 查询模板，以及一次端到端验证，确认模型能正确取回指定表数据。

整个链路分三段：元数据准备 → MCP 服务端暴露工具 → DeepSeek 客户端调用工具。元数据你可以从数据库的information_schema直接读，也可以从数据字典文档里提取。从实践来看，如果数据库注释齐全，直接读元数据最省事；如果命名混乱、注释缺失，建议先整理一份 JSONL 格式的表描述文件，把表名、中文名、字段、类型、说明都写清楚，后面 MCP 读这个文件就行。这样模型拿到的信息是“人话”，写 SQL 的准确率会明显提升。

2. TaoToken 前置：给 DeepSeek 一个稳定的调用入口

MCP 服务端写好后，需要一个支持 MCP 的客户端来调用 DeepSeek。这里有两种路子：一种是用现成的开源客户端，比如 DeepChat、CherryStudio，它们内置了 MCP 配置界面，填上服务端地址就能用；另一种是自己写一个轻量客户端，通过 API 调 DeepSeek，同时挂载 MCP 工具。不管哪种，你都需要一个能稳定访问 DeepSeek 的 API 入口。

我目前用的是 TaoToken 的 API 入口，地址是https://taotoken.net/api。它兼容 OpenAI 风格的接口，DeepSeek 的模型 ID 直接填deepseek-chat或deepseek-reasoner就能调。对于 MCP 场景来说，关键是这个入口要支持标准的tools参数传递，因为 MCP 工具最终会以 function calling 的形式发给模型。实测下来，TaoToken 的接口在工具调用上返回结构是完整的，tool_calls字段能正常解析，不会出现“模型不认工具”的情况。

你需要先拿到一个 API Key。登录 TaoToken 控制台，在 API Keys 页面创建一个，复制出来备用。这个 Key 后面会填到客户端的配置里，或者写进你自定义客户端的请求头。注意不要把 Key 硬编码到 MCP 服务端代码里，MCP 服务端只负责本地工具执行，不负责调模型；调模型是客户端的事，Key 放在客户端配置里更安全。

如果你用的是 DeepChat 这类客户端，配置分两步：第一步在“模型设置”里填 Base URL 为https://taotoken.net/api，API Key 填你刚创建的，模型选deepseek-chat；第二步在“MCP 设置”里添加一个 SSE 类型的服务端，地址填http://localhost:30059/sse（端口跟你 MCP 代码里写的一致）。这样客户端启动时就会去连你的本地 MCP 服务，把search_table和get_table_schema两个工具注册给 DeepSeek。

如果你打算自己写客户端，那就在请求体里带上tools数组，每个工具的name、description、parameters按 MCP 服务端暴露的 schema 填。DeepSeek 返回tool_calls后，你在本地执行对应的 MCP 工具，把结果作为tool角色的消息再发回去，模型就能基于表结构生成最终 SQL。这个流程跟 OpenAI 的 function calling 完全一致，TaoToken 的接口不需要额外适配。

有一点要注意：MCP 服务端和模型调用是解耦的。MCP 服务端只跑在本地，监听一个端口，等客户端来连；模型调用走的是 TaoToken 的 API，两者通过客户端的“工具注册”机制串起来。所以你的 MCP 服务端不需要联网，也不需要配置任何模型 Key，它只负责读本地的元数据文件、执行搜索和 schema 查询。这样设计的好处是安全——数据库元数据不出本地，只有模型生成的 SQL 和必要的表结构片段会发到 API。

3. 可复制配置：MCP 服务端 + DeepSeek 客户端

先写 MCP 服务端。我用 Python 的mcp库，基于 FastMCP 实现，代码可以直接复制运行。核心是两个工具：search_table根据关键词搜表名，get_table_schema根据表 ID 返回字段详情。元数据我放在doc/demo.jsonl里，每行一张表的 JSON；另外准备一个doc/demo_table.md作为表名索引，方便关键词搜索。

import io import json from mcp.server.fastmcp import FastMCP mcp = FastMCP("DemoDB", port="30059") def load_tables() -> dict: with open("doc/demo.jsonl", "r", encoding="utf-8") as f: tables = {} for line in f: table = json.loads(line) tables[table["id"]] = table return tables ALL_TABLES = load_tables() @mcp.tool() def search_table(keyword: list[str]) -> str: """Search table by keyword.""" table = [ "id | name", "--- | ---", ] with open("doc/demo_table.md", "r", encoding="utf-8") as f: for line in f: for kw in keyword: if kw in line: table.append(line.strip()) if len(table) == 2: return "No table found." return "\n".join(table) def format_table(table: dict) -> str: """Format the table to markdown.""" buf = io.StringIO() buf.write(f"# 表名: {table['name']} 中文名: {table['cn_name']}\n") buf.write("## 字段列表\n") buf.write("| 字段名 | 中文名 | 类型 | 说明 |\n") buf.write("| --- | --- | --- | --- |\n") for col in table["columns"]: buf.write(f"| {col['name']} | {col['cn_name']} | {col['type']} | {col['desc']} |\n") buf.write("\n") return buf.getvalue() @mcp.tool() def get_table_schema(ids: list[int]) -> str: """Get the schema of the tables by ID.""" if len(ids) == 0: return "" buf = io.StringIO() for id in ids: table = ALL_TABLES.get(id, None) if table is not None: buf.write(format_table(table)) return buf.getvalue() if __name__ == "__main__": mcp.run("sse")

doc/demo.jsonl的格式长这样，每行一张表：

{"id": 1, "name": "Fund_Performance_Compare", "cn_name": "基金业绩对比表", "columns": [{"name": "fund_code", "cn_name": "基金代码", "type": "varchar", "desc": "基金唯一编码"}, {"name": "nav", "cn_name": "单位净值", "type": "decimal", "desc": "最新单位净值"}, {"name": "return_1y", "cn_name": "近一年收益率", "type": "decimal", "desc": "百分比数值"}]}

doc/demo_table.md是给search_table用的索引，每行格式为id | name | cn_name：

1 | Fund_Performance_Compare | 基金业绩对比表 2 | Fund_Nav_History | 基金净值历史表 3 | Fund_Manager_Info | 基金经理信息表

启动服务端：

python3 db_mcp.py

看到Uvicorn running on http://0.0.0.0:30059就说明 MCP 服务起来了。接下来配置 DeepSeek 客户端。以 DeepChat 为例，在 MCP 设置里新增一个 SSE 服务：

{ "mcpServers": { "demo-db": { "type": "sse", "url": "http://localhost:30059/sse" } } }

然后在模型设置里填 TaoToken 的接入信息：

{ "baseUrl": "https://taotoken.net/api", "apiKey": "你的_TaoToken_API_Key", "model": "deepseek-chat" }

如果你用的是 Cline 或 Claude Code 这类编码工具，配置逻辑一样，只是文件位置不同。Cline 的 MCP 配置在cline_mcp_settings.json，Claude Code 在~/.claude/settings.json或项目级.mcp.json。三件套记牢：Base URL 填https://taotoken.net/api，Key 填 TaoToken 控制台创建的 Key，Model ID 填deepseek-chat。MCP 服务端地址统一填http://localhost:30059/sse。

配置完成后重启客户端，在对话界面输入“帮我查一下基金业绩对比表里近一年收益率大于 10% 的基金代码”，DeepSeek 会先调search_table，拿到表 ID 后调get_table_schema，最后生成 SQL。整个过程你可以在客户端的工具调用日志里看到。

4. 验证请求：一次端到端取数确认

配置好之后，别急着写复杂查询，先用一个最小请求验证链路通不通。打开 DeepChat，新建对话，输入：

帮我找一下跟“基金业绩”相关的表，然后列出 Fund_Performance_Compare 的字段。

正常情况下，你会看到模型先发起一次search_table调用，参数是{"keyword": ["基金", "业绩"]}，MCP 返回：

id | name --- | --- 1 | Fund_Performance_Compare | 基金业绩对比表

接着模型发起get_table_schema调用，参数是{"ids": [1]}，MCP 返回：

# 表名: Fund_Performance_Compare 中文名: 基金业绩对比表 ## 字段列表 | 字段名 | 中文名 | 类型 | 说明 | | --- | --- | --- | --- | | fund_code | 基金代码 | varchar | 基金唯一编码 | | nav | 单位净值 | decimal | 最新单位净值 | | return_1y | 近一年收益率 | decimal | 百分比数值 |

最后模型输出 SQL：

SELECT fund_code, nav, return_1y FROM Fund_Performance_Compare WHERE return_1y > 10 ORDER BY return_1y DESC;

如果你在客户端里看到这个完整链路，说明 MCP 投喂成功。这时候你可以进一步测试：换一个更模糊的问题，比如“最近哪些基金表现好”，看模型能不能自己推断出要用return_1y字段并生成排序查询。实测下来，只要search_table的索引文件里中文名写得清楚，DeepSeek 的推断准确率很高。

再验证一个边界情况：问一个不存在的表。输入“帮我查一下用户订单表”，search_table会返回No table found.，模型应该回复“没有找到相关表，请确认表名或提供更多关键词”，而不是瞎编一个 SQL。这个行为能帮你确认工具调用的错误处理是正常的。

如果你用的是自己写的客户端，验证方式是在代码里打印每次tool_calls的返回，确认search_table和get_table_schema都被正确执行，并且结果以tool角色消息回传给了模型。一个常见的坑是：工具返回的 Markdown 表格里如果有换行符处理不当，模型可能解析失败。建议在format_table里确保每行以\n结尾，不要有多余空行。

端到端验证通过后，你就可以把这套配置用在日常查询里了。比如让 DeepSeek 帮你写多表 JOIN：先搜“基金经理”，拿到Fund_Manager_Info的表 ID，再搜“基金业绩”，拿到Fund_Performance_Compare，然后让模型根据两张表的字段生成关联查询。整个过程模型只取回了必要的 schema 片段，Token 消耗远低于一次性塞全库。

5. 常见报错排查：401、local proxy failed、reading choices

配置过程中最容易卡在几个报错上，我按实际遇到的频率排一下。

401 Unauthorized：这个基本是 API Key 问题。检查 TaoToken 控制台里 Key 是否复制完整，有没有多余空格。如果你用的是自定义客户端，确认请求头是Authorization: Bearer <Key>，不是x-api-key。另外注意 Base URL 结尾不要多加/v1，TaoToken 的入口是https://taotoken.net/api，客户端一般会自动补/v1/chat/completions。如果填成https://taotoken.net/api/v1，有些客户端会拼成/api/v1/v1/...，导致 404 而不是 401，但表现都是请求失败。

local proxy failed / connection refused：这个报错说明客户端连不上 MCP 服务端。先确认python3 db_mcp.py还在运行，终端没有报错退出。然后检查端口：代码里写的是30059，客户端配置里也必须是30059，不能一个写 30059 一个写 30060。如果你在 Docker 里跑 MCP，localhost 可能不通，需要把地址换成宿主机的局域网 IP。还有一个隐蔽问题：某些客户端对 SSE 地址要求以/sse结尾，如果你只填http://localhost:30059，它会连不上，必须补全/sse。

reading choices 报错 / 返回结构解析失败：这个通常出现在模型返回了工具调用，但客户端解析choices[0].message.tool_calls时字段对不上。先确认你用的模型 ID 是deepseek-chat，这个模型支持 function calling。如果你填的是deepseek-reasoner，它可能不返回tool_calls，而是把工具调用写在推理内容里，导致客户端解析失败。另外检查 TaoToken 接口返回的 JSON 里tool_calls数组是否完整，每个元素是否有id、type、function.name、function.arguments。如果arguments是字符串形式的 JSON，客户端需要先JSON.parse再执行。

OAuth 相关报错：如果你用的是 Claude Code 或某些需要 OAuth 的客户端，可能会遇到 token 过期或 scope 不足。这类客户端通常要求你先在设置里完成授权流程。如果你只是用 DeepSeek + MCP，建议直接用 DeepChat 或 CherryStudio，它们对 API Key 模式支持更直接，不需要走 OAuth。Claude Code 的 MCP 配置在settings.json里，格式是：

{ "mcpServers": { "demo-db": { "command": "python3", "args": ["/path/to/db_mcp.py"] } } }

注意 Claude Code 用的是 stdio 模式，不是 SSE，所以你的 MCP 代码里mcp.run("sse")要改成mcp.run("stdio")。这个区别很容易踩坑：SSE 模式监听端口，stdio 模式通过标准输入输出通信。如果你在 Claude Code 里配了 SSE 地址，它会一直连不上。

Codex auth.json 配置：如果你用 Codex 类工具，认证信息在~/.codex/auth.json，里面需要填api_key和base_url。Base URL 同样是https://taotoken.net/api，Model ID 填deepseek-chat。改完文件后重启 Codex 生效。注意这个文件权限建议设为600，避免 Key 泄露。

排查顺序建议：先确认 MCP 服务端单独能跑通（用curl http://localhost:30059/sse看有没有响应），再确认客户端能连上 MCP，最后确认模型调用返回正常。三步分开测，比一股脑调更容易定位问题。

6. 把 MCP 投喂链路用起来：从单表查询到多表关联

链路跑通之后，真正的价值在于日常查询效率的提升。以前你要写一个多表 JOIN，得先翻数据字典、确认字段名、理清关联关系，现在只需要用自然语言描述需求，DeepSeek 会通过 MCP 自动取回相关表的 schema，然后生成 SQL。你只需要检查 SQL 逻辑对不对，不用再手动查表结构。

一个实用技巧：在search_table的索引文件里，除了表名和中文名，可以把常用字段的中文别名也写进去。比如return_1y旁边标注“近一年收益率、年化收益”，这样你问“年化收益大于 10% 的基金”时，模型更容易命中正确的表和字段。索引文件不需要很精确，关键词覆盖越广，搜索命中率越高。

另一个技巧是控制get_table_schema返回的字段数量。如果一张表有上百个字段，全部返回给模型会浪费 Token。你可以在format_table里加一个过滤逻辑，只返回跟查询相关的字段，或者按字段重要性排序，把核心字段放前面。实测下来，模型对前 20 个字段的注意力最集中，后面的字段容易忽略。

如果你想让这套配置长期跑在本地，建议把 MCP 服务端做成 systemd 服务或 Docker 容器，开机自启。这样客户端随时连都有响应，不用每次手动python3 db_mcp.py。Docker 方式的话，Dockerfile 里把doc/目录挂载进去，端口映射30059:30059，启动命令就是python3 db_mcp.py。

最后提醒一点：MCP 工具返回给模型的是表结构，不是真实数据。模型生成 SQL 后，你需要自己在数据库里执行，或者再写一个执行 SQL 的工具挂到 MCP 上。但执行 SQL 的工具要谨慎，建议只读权限，并且加白名单限制，避免模型生成DELETE或UPDATE语句误操作生产库。对于本地开发库，可以放开；对于生产库，最好只让模型生成 SQL，人工确认后再执行。

这套 MCP + DeepSeek 的组合，核心思路是“让模型按需取用元数据”，而不是“一次性喂全量”。你可以在 TaoToken 的模型对话页面直接测试 DeepSeek 的 SQL 生成能力，确认模型本身没问题后，再把 MCP 工具挂上去。接入文档里有完整的 API 参数说明，API Keys 页面可以管理你的调用凭证。如果你打算长期做编码和 Agent 类任务，Coding Plan 的额度更适合高频调用场景。