被客户问怕了，我用 SF-FastGPT 做了个“全球气象助手”

Want595

22241人浏览 · 2026-06-02 14:32:36

Want595 · 2026-06-02 14:32:36 发布

背景

最近我迷上了一个比赛——SF-FastGPT挑战赛。

简单说就是给你一个 FastGPT 平台，让你自己动手搭一个能解决真实问题的 AI 智能体，最后大家 PK 谁的应用更"扛造"。我这种爱折腾的人哪能忍，二话不说就报名了。

报名的时候我就琢磨：到底做什么方向的智能体，才能既不太卷（避免和大厂通用助手撞车），又能真正戳中某个垂直行业的痛点？

想了一晚上，第二天上班路上灵光一闪——就它了。

灵感

我们公司主要的业务是气象数据方面。

听起来高大上对吧？实际上苦只有我们自己知道：每天要被问八百遍"明天北京下不下雨""上海这周末能洗车吗""三亚现在台风到哪了"……

以前这活儿靠人工——同事 A 盯中央台，同事 B 翻 ECMWF，同事 C 还得去 NOAA 上扒卫星云图。客户问过来，我们就开始"全国气象数据大串联"，五分钟能回一句都算快的。

最离谱的一次，客户凌晨两点问"明天我的航班能不能飞"，群里三个人轮流爬起来查不同数据源，最后拼了张表发过去。客户倒是满意了，我们三个人第二天集体顶着黑眼圈开会。

所以这次挑战赛，我把目标定得很明确：

搭一个"全球气象助手"——输入城市或经纬度，它能在 30 秒内告诉你当地实况、未来 7 天预报、极端天气预警，最好还能告诉你"现在该不该出门"。

任务清楚了，下面进入手把手抄作业环节。

搭建一个气象助手智能体

Step 1：访问 FastGPT 平台

打开浏览器，输入 https://59.37.133.113:18443/，先看一眼整体长相。

整体风格非常"工程师友好"——左侧导航清晰，中间留白舒服，右上角直接是新建入口。对比之前用过的某国产同类平台，这里给我的第一感觉是：终于不用在五层菜单里找功能了。

Step 2：新建应用

点右上角「新建应用」，平台会让你选应用类型。

一共两种：

智能问答：纯 Prompt，适合做单轮闲聊
工作流：可视化拖拽节点，能接入外部工具

我选工作流。原因很简单——我喜欢搭积木。

Step 3：起名 + 选模板

应用名我直接写"全球气象助手"，模板选默认就行。

Step 4：进入工作流搭建界面

点进去的那一刻，我非常惊喜。

整个画布是节点式的：左边是组件库，中间是画布，右边是节点配置。像搭乐高一样把 LLM、判断器、HTTP 请求这些组件拖进来，连上线，就能跑。

默认有一个"系统配置"，我的任务就是搭建一个能"看天气"的智能体。

Step 5：接入 MCP 工具

这一步是核心中的核心。

MCP（Model Context Protocol） 是 Anthropic 提出来的一套标准协议，简单说就是让大模型能"伸手"去调用外部工具。我把之前公司内部一直在用的全球气象查询接口，按照 MCP 协议包装了一层，发布成了一个独立的 MCP Server。

把它接入到 FastGPT 之后，就可以在工作流里调用这个工具了。

Step 6：编排工作流

工具接进来只是"硬件到位"，真正决定智能体聪不聪明的是工作流编排思路。我先放一张最终版的脑图，方便你对着看：

[用户输入]
   ↓
[意图识别 LLM]  ──→ 判断：查实况 / 查预报 / 查预警 / 闲聊
   ↓
[参数提取 LLM]  ──→ 从自然语言里抠出 city / lat / lon / type
   ↓
[路由判断器]    ──→ 城市名有？走城市查询；没有？走经纬度查询
   ↓
[MCP 气象工具]  ──→ 调用真实接口
   ↓
[数据格式化]    ──→ 把 JSON 翻译成人话
   ↓
[最终回答 LLM]  ──→ 用友好口吻总结输出
   ↓
[返回给用户]

下面挨个节点讲我为什么这么设计。

6.1 意图识别节点

第一版我图省事，把意图识别和参数提取塞在一个 LLM 里跑，结果实测准确率只有 60% 多——"明天上海天气怎么样"这种问法稍微变一下，模型就开始抽风。

拆成两个节点之后，准确率直接拉到 92%。这是个通用经验：让 LLM 一次只做一件事，效果远好于让它打全场。

6.2 参数提取节点

我给它的 Prompt 里塞了三类示例：

城市名："北京"、"Shanghai"、"东京"
经纬度："39.9, 116.4"、"北纬 30 度东经 120 度"
时间："今天"、"明天下午三点"、"这周末"

Prompt 里塞 5 个以上真实样例，比你写十段规则都管用。 这也是踩过的坑。

6.3 路由判断器

FastGPT 自带"条件分支"组件，用它做 if-else 就行。这里我判断的是"用户有没有给城市名"，有就优先走城市接口（更准），没有就退化到经纬度接口。

6.4 数据格式化节点

这是最容易被忽略、但用户感知最强的一环。

MCP 工具返回的是这样的 JSON：

{
  "temp": 28.5,
  "humidity": 65,
  "wind_speed": 12,
  "description": "多云转小雨"
}

直接把这坨东西丢给最终回答的 LLM，它会照着念出来——"temp 是 28.5，humidity 是 65"——用户当场就想卸载。

所以我加了一个简单的模板节点，把数据渲染成：

当前北京气温 28.5℃，相对湿度 65%，风速 12 km/h，天气多云转小雨。

这种"人话化"的中间层，是判断一个 AI 应用是 60 分还是 90 分的分水岭。

Step 7：运行测试

激动人心的时刻到了。我在测试框里敲下第一句话：

"苏州今天的实况天气"

效果非常不错。

Step 8：补全智能体基本信息

测试通过之后，回到应用详情页把"身份证"补全——头像、简介。

简介我写的是：

支持查询全球的实况和预报气象信息。

这种"一句话价值主张"很重要——用户 3 秒决定用不用你的应用，没人愿意看你长篇大论的产品介绍。

Step 9：发布智能体

一切就绪，点右上角"保存并发布"。

FastGPT 会生成一个分享链接，用户点开就能直接用。

Step 10：实际体验

体验链接：https://59.37.133.113:18443/chat/share?shareId=g7xeAQg9IlVj8JQFC6ux75kB

未来规划

这次的"全球气象助手"只是个开始，接下来我打算沿着三条线继续卷：

数据源扩展：目前接的是国外的全球气象 API，下一步要纳入中央气象台、ECMWF、NOAA 三家做交叉验证，单一数据源说错就完蛋
多模态输入：让用户能直接发一张天空的照片，模型反推当前天气（"这片云看起来要下了，建议提前回家"）
行业垂直版本：在通用气象助手之上，再做几个细分场景——"农业气象助手"（告诉农民伯伯什么时候打药最好）、"户外运动气象助手"（告诉徒步爱好者这条路线安不安全）、"航空气象助手"（给航司和机场用）

说到底，通用大模型是"通才"，垂直智能体是"专家"。把行业 Know-How 灌进去，才是 AI 真正创造价值的地方。