1. 从被客户半夜追问天气说起全球气象助手到底解决什么问题先说清楚这个“全球气象助手”是什么、能做什么、适合谁。它是一个跑在 SF-FastGPT 上的智能体应用用户输入城市名或经纬度它会在一次对话里返回当地实况、未来几天预报和极端天气预警并且用自然语言总结成“今天该不该带伞、适不适合出门”这种能直接用的结论。适合两类人一类是被客户反复追问天气、想把自己从人工查数据里解放出来的气象/航运/农业/户外行业从业者另一类是想学 MCP 工具接入和工作流编排、但一直没找到完整可跟做案例的开发者。我所在团队做气象数据服务日常最怕的不是数据难拿而是客户的问题太口语化。“明天北京下不下雨”“上海这周末能洗车吗”“三亚现在台风到哪了”这些问题背后要串起实况接口、预报接口、预警接口三套数据源。以前靠人工同事 A 盯一个源、同事 B 翻另一个源客户凌晨两点问航班能不能飞三个人轮流爬起来查第二天集体顶着黑眼圈开会。问题不在于查不到而在于“把自然语言翻译成接口参数、再把接口 JSON 翻译回人话”这一段全靠人肉。所以这个智能体的目标很明确输入城市或经纬度30 秒内给出实况、预报、预警并附一句行动建议。技术链路上有三块硬骨头第一让模型能“伸手”调用真实气象接口这靠 MCPModel Context Protocol工具接入第二把意图识别、参数提取、路由、格式化串成一条稳定工作流这靠 SF-FastGPT 的可视化编排第三把模型调用的 endpoint 统一到一个 Key 上管理避免每个节点各配一套密钥、换模型时到处改配置这一步我用 TaoToken 来做统一入口。下面按“前置准备 → 可复制配置 → 验证请求 → 排错 → 收尾”的顺序拆。你如果只想抄作业重点看第 3 节的 MCP 配置片段和工作流节点参数那是整条链路能不能跑通的关键。2. 前置准备SF-FastGPT 里建应用、TaoToken 上拿统一 Key这一节解决“东西从哪来”。SF-FastGPT 是 FastGPT 的一个部署实例界面是节点式工作流画布左侧组件库、中间画布、右侧节点配置拖 LLM、条件分支、HTTP 请求这些组件连线就能跑。进入平台后点右上角“新建应用”应用类型选“工作流”而不是“智能问答”——智能问答是纯 Prompt 单轮闲聊工作流才能接外部工具这是能不能调气象接口的分水岭。应用名写“全球气象助手”模板用默认即可。接着是模型调用的统一 Key。我试过在每个 LLM 节点里单独填模型地址和密钥节点一多就乱换模型要逐个改密钥泄露风险也分散。后来改成所有模型请求都走 TaoToken 的统一入口一个 Key 管所有模型节点里只填 Base URL、Key、Model ID 三件套。TaoToken 的 API 地址是 https://taotoken.net/api 官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册后在控制台生成 Key。具体操作路径登录后进控制台找到 API Keys 页面新建一个 Key复制保存模型 ID 按你实际要用的填比如做意图识别和参数提取这种结构化任务选一个指令跟随稳的模型即可。这里要强调一点Base URL 填 https://taotoken.net/api 不要带多余路径很多 401 和 404 就是路径拼错导致的。Key 生成后先别急着往工作流里塞第 4 节会先用一条 curl 验证它通不通通了再进编排能省掉大量“到底是 Key 错还是节点配错”的排查时间。MCP 工具这边我把团队内部的全球气象查询接口按 MCP 协议包装成了一个独立 MCP Server对外暴露“查实况”“查预报”“查预警”三个工具方法。你如果没有现成接口可以先用任意公开气象 API 包一层重点是 MCP Server 的入参出参要固定入参收 city 或 lat/lon 加 type出参返回结构化 JSON。工具本身稳定工作流才有稳定的地基。3. 可复制配置MCP 片段、工作流节点参数与统一 Key 三件套这一节是全文最该抄的部分。先给 MCP 接入配置。SF-FastGPT 里接入 MCP 工具本质是告诉平台“这个工具在哪、怎么调、参数长什么样”。下面是一段可复制的 MCP 配置片段路径和字段按你实际部署调整{ mcpServers: { weather-global: { command: node, args: [/opt/mcp-weather/server.js], env: { WEATHER_API_BASE: https://your-weather-api.example.com, WEATHER_API_KEY: your_weather_api_key } } } }这段配置的意思是启动一个名为 weather-global 的 MCP Server用 node 跑 server.js气象接口的地址和密钥通过环境变量注入。把它填进 SF-FastGPT 的 MCP 工具配置区后工作流里就能看到这个工具暴露的方法。然后是模型调用的三件套。所有 LLM 节点统一填{ base_url: https://taotoken.net/api, api_key: sk-你的TaoToken密钥, model_id: 你的模型ID }Base URL、Key、Model ID 三件套缺一不可且三个 LLM 节点意图识别、参数提取、最终回答都用同一套这样换模型只改一处。如果你用 Codex 的 auth.json 或 Cline 的 MCP 配置思路一样Base URL 指向 https://taotoken.net/api Key 填 TaoToken 生成的Model ID 填你要的模型。工作流节点参数按这个顺序连意图识别 LLM 节点Prompt 让它只做分类输出“实况/预报/预警/闲聊”四选一不要让它顺便提参数。参数提取 LLM 节点Prompt 里塞五类以上真实样例覆盖城市名北京、Shanghai、东京、经纬度39.9,116.4、北纬30度东经120度、时间今天、明天下午三点、这周末让它输出结构化 JSON。路由判断器用条件分支组件判断“有没有城市名”有走城市接口没有退化到经纬度接口。MCP 气象工具节点接上面配好的 weather-global。数据格式化节点用模板把 JSON 渲染成人话。最终回答 LLM 节点用友好口吻总结。这里有个关键经验第一版我把意图识别和参数提取塞进一个 LLM实测准确率只有 60% 多“明天上海天气怎么样”换个说法模型就抽风拆成两个节点后准确率拉到 92%。让 LLM 一次只做一件事比让它打全场稳得多。数据格式化节点最容易被忽略但用户感知最强MCP 返回{temp:28.5,humidity:65,wind_speed:12,description:多云转小雨}直接丢给最终 LLM 它会念“temp 是 28.5”用户当场想卸载加一层模板渲染成“当前北京气温 28.5℃相对湿度 65%风速 12 km/h天气多云转小雨”体验立刻不一样。4. 验证请求一条 curl 打通 Key再跑真实气象查询配置填完别急着发布先验证。第一步验证 TaoToken 的 Key 通不通用一条 curlcurl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer sk-你的TaoToken密钥 \ -H Content-Type: application/json \ -d { model: 你的模型ID, messages: [{role: user, content: 只回复两个字通了}] }返回里如果 choices 数组有内容、message.content 是“通了”说明 Base URL、Key、Model ID 三件套没问题。这一步能过后面工作流里模型节点报错基本就不是 Key 的问题了。第二步验证 MCP 工具。在 SF-FastGPT 工作流画布上单独跑 MCP 气象工具节点入参填{city:苏州,type:current}看返回是不是结构化 JSON。如果返回空或报错先确认 MCP Server 进程起来了、环境变量里的接口地址和密钥对。第三步跑端到端。在测试框输入“苏州今天的实况天气”观察节点执行顺序意图识别输出“实况”参数提取输出{city:苏州,type:current}路由走城市分支MCP 工具返回 JSON格式化节点渲染成人话最终回答输出类似“苏州当前气温 28.5℃相对湿度 65%风速 12 km/h天气多云转小雨建议随身带伞”。整条链路跑通再换“39.9,116.4 未来三天预报”验证经纬度分支换“三亚现在有台风预警吗”验证预警分支。测试通过后回应用详情页补全头像和简介简介写“支持查询全球的实况和预报气象信息”一句话价值主张用户三秒决定用不用。然后点“保存并发布”平台生成分享链接点开就能用。发布后再用真实链接跑一遍确认线上和测试环境行为一致。5. 常见报错排查401、local proxy failed、reading choices、OAuth排错这节按真实报错对照遇到哪个查哪个。401 Unauthorized九成是 Key 问题。先确认 curl 验证那步过没过没过就是 Key 复制时带了空格或换行重新生成一个。如果 curl 过了但工作流里 401检查节点里的 Base URL 是不是写成了 https://taotoken.net/api/ 带尾斜杠或者误填了别的路径。三件套里 Base URL、Key、Model ID 任何一个错都会 401 或 404。local proxy failed通常是 MCP Server 没起来或端口不通。检查 server.js 进程是否在跑环境变量 WEATHER_API_BASE 和 WEATHER_API_KEY 是否注入成功。如果 MCP Server 依赖外部气象接口确认那层接口本身能通别把上游的错算到 MCP 头上。reading choices 报错一般是模型返回体结构和预期不符。常见原因是 Model ID 填错请求打到了不支持 chat/completions 格式的模型上或者 Base URL 指向了非兼容端点。回到 curl 那步用同一个 Model ID 再跑一次看返回体里有没有 choices 字段。没有就是模型 ID 或端点的问题。OAuth 相关报错多出现在用 Codex 的 auth.json 或某些需要授权流程的客户端时。如果你只是走 API Key 方式调 TaoToken不需要 OAuth把客户端里多余的 OAuth 配置去掉统一用 Bearer Token。Cline 的 MCP 配置里如果混了 OAuth 字段也会干扰清掉只留 Base URL、Key、Model ID。还有一个隐蔽的坑工作流里多个 LLM 节点用了不同 Key换模型时只改了一个导致部分节点 401。统一走 TaoToken 一个 Key 就是为了避免这个所有节点共用一套三件套改一处全生效。6. 把模型 endpoint 统一到 TaoToken 之后这套链路还能怎么扩联调跑通只是起点。把模型调用 endpoint 统一到 TaoToken 之后最大的好处是换模型、加节点、做多模型对比都不用动工作流结构只改三件套里的 Model ID。接下来我打算沿三条线扩数据源上目前接的是单一全球气象 API下一步纳入多家数据源做交叉验证单一源说错就完蛋输入形态上让用户直接发一张天空照片模型反推当前天气场景上在通用气象助手之上做农业、户外、航空几个垂直版本把行业 Know-How 灌进去。如果你也想抄这套作业路径很清晰SF-FastGPT 建工作流应用MCP 接气象工具工作流按“意图识别 → 参数提取 → 路由 → MCP 调用 → 格式化 → 最终回答”编排模型调用统一走 TaoToken 的 Base URL https://taotoken.net/api 加一个 Key。需要生成 Key 和看接入文档的去 API Keys 页面和接入文档想先验证模型效果的用模型对话页面直接试打算长期做编码和 Agent 的看 Coding Plan。搭完一个你对 AI 工程化的理解会上一个台阶——它本质上还是“输入 → 处理 → 输出”只不过中间那层从写死的业务逻辑变成了可自然语言驱动的 LLM 调用。