企业官网建设流程全解析

在Coze里搭智能体的人，八成都会卡在同一个地方：怎么让智能体拿到实时数据。知识库解决不了天气、股票、快递这类天天在变的信息。插件商店里倒是有现成的天气插件，但真要对接自己选定的数据源，或者想把参数做得灵活一点，就得靠HTTP请求节点。这篇文章就用天气API做一条完整链路：从选服务商、拿密钥，到在Coze里配置请求、解析返回结果，再让参数跟着用户输入动态变化。整个流程跑通之后，你会发现接任何REST API的路数都是一样的，天气只是最小、最好验证的练手场景。

1. 为什么拿天气API练手：HTTP请求节点要解决的三个痛点

先说个很常见的场景。你做了一个“生活助手”智能体，用户问“今天北京穿什么”，知识库给不了答案，因为天气是实时数据。你第一反应是去插件商店找天气插件，装上之后发现能用，但总觉得别扭：插件返回的字段是固定的，你没法决定它预留哪些信息，也没法把天气数据和后续的穿衣建议、通勤提醒串成一条完整的处理链。这就是第一个痛点——内置插件是黑盒，变量不可控。

第二个痛点是数据源绑死。插件商店里的天气数据源是平台定好的，如果公司内部有一套自建气象服务，或者你更信任某个特定服务商的预报精度，插件方案就直接废掉了。这时候需要的是一个“万能插座”，给我一个URL和一套参数规则，我自己决定调谁、怎么调。

第三个痛点是参数不灵活。用户可能说“北京”“北京市”“首都”，也可能说“帮我看看明天上海会不会下雨”。固定参数的插件没办法处理这种动态入参，而HTTP请求节点可以把用户输入直接拼进请求地址里，请求参数跟着上下文走。

这里我强烈建议用天气API练手，因为它几乎是HTTP接口里最友好的一种：GET请求为主，没有复杂的OAuth签名流程，返回的JSON结构简单直观，免费额度对个人开发完全够用。把天气这条链路走通，再去看那些需要POST、需要签名、需要处理分页的业务接口，心态会稳很多。

提示：本文按Coze工作流中的“HTTP请求”节点来写，也就是在“工作流”里添加节点时看到的那个HTTP Request。如果你用的是新版界面，入口可能变成“扩展/工具”里的自定义HTTP调用，但底层的配置逻辑是互通的。

2. 接天气数据前的准备：选哪个服务商，密钥怎么拿

天气API服务商很多，国内用得比较多的是心知天气、和风天气，高德开放平台也提供天气查询接口。我三个都用过，给你一个直观的对比：

如果是第一次做对接，我推荐从心知天气开始。它的实时天气接口返回结果很小，一眼能看懂，非常适合先跑通逻辑。注册账号后，在控制台创建一个“我的API”，拿到一个形如你的私钥的字符串，这就是密钥（key）。

和风天气的流程也类似：注册后在控制台创建应用，选好API产品（比如“天气实况”），会生成一个key。注意和风要求实名认证，认证没通过之前调用会报错，我第一次等了两小时才生效。高德则要在控制台创建一个“应用”，给应用添加“天气查询”API，然后在应用管理里拿到key。

密钥拿到后，强烈建议你先在浏览器或Postman里手动调一次接口，确认能返回数据再进Coze操作。这一步能省很多后面排查问题的时间。

以心知天气为例，一个最简单的实时天气请求长这样：

https://api.seniverse.com/v3/weather/now.json?key=你的密钥&location=beijing&language=zh-Hans&unit=c

把location换成拼音城市名，就能拿到北京实时天气。我习惯先在浏览器地址栏直接访问，看到JSON返回再去做下一步。

3. 在Coze里配置HTTP请求节点：从URL拼接、参数设置到数据解析

项目已就绪，密钥已到手，现在进Coze工作流。

3.1 新建工作流并添加节点

在Coze平台点击“新建工作流”，起个名字比如“天气查询助手”。进入画布后，左侧节点列表拉到最下面，找到“HTTP请求”节点，拖进画布。

画布上默认会有两个节点：开始节点（通常是Start）和结束节点（End）。把HTTP请求节点放在Start和End之间，连线顺序是：Start → HTTP请求 → End。

3.2 配置HTTP请求参数

点击HTTP请求节点，右侧会弹出配置面板。这里要填的内容跟你在Postman里看到的几乎一样：

• Method：选GET。
• URL：填入心知天气的接口地址，注意这里先不要写死城市，用变量占位符：

https://api.seniverse.com/v3/weather/now.json?key=你的密钥&location={{城市}}&language=zh-Hans&unit=c

这个{{城市}}就是动态参数的雏形。在城市变量尚未定义之前，先用它占住位置。Coze的变量引用语法我习惯用双大括号，配置面板也会提供“插入变量”的入口，点一下能看到上游节点暴露的可用字段。

• Params：如果不想把参数拼在URL里，也可以点到Params区域分别填key、location、language、unit。两者效果一样，但Params区看着更清爽，后面改参数名也方便。

3.3 试运行：先别接大模型，看原始返回

配置完URL和参数，先别急着接文本生成节点，一定要先做一次试运行。

点击工作流右上角的“试运行”按钮，如果你有{{城市}}之类的占位参数，系统会弹出一个输入框让你填测试值。填一个拼音城市名如beijing，运行完看HTTP节点的输出。

如果一切正常，你会看到类似这样的JSON：

{ "results": [ { "location": { "id": "WX4FBXXFKE4F", "name": "北京", "country": "CN", "path": "北京,北京,中国", "timezone": "Asia/Shanghai", "timezone_offset": "+08:00" }, "now": { "text": "多云", "code": "4", "temperature": "18" }, "last_update": "2025-06-01T18:00:00+08:00" } ] }

看到这个JSON就说明HTTP请求节点本身已经通了，接下来的问题只是“怎么把这串JSON变成人能看懂的答案”。在这里强烈建议你复制这段响应，保存到本地，后面写JSONPath解析表达式的时候会反复参考它。

3.4 把JSON转成结构化变量

Coze的HTTP请求节点会提供“响应解析”或“输出定义”相关配置。默认情况下，节点的输出是整个响应的文本（或JSON字符串），这对接在后面的节点不友好。

更推荐的做法是把响应解析成结构化变量。在节点配置里能找到响应解析选项，选择“按照JSON解析”（不同版本叫法可能略有差异），Coze会自动把响应的根级字段展开成一个个变量，比如results、last_update。

但results还是一个数组，要取里面的温度，还需要再做一步。在节点输出里定义一个自定义变量，比如叫天气温度，值填写：

$.results[0].now.temperature

这个JSONPath语法意识是：取results数组的第一个元素的now对象里的temperature字段。同理，天气描述取：

$.results[0].now.text

用同样的方法把“城市名”“更新时间”都提取成独立变量。做完这一步，你的HTTP节点就像一个“数据接口适配器”，把第三方API的原始响应洗成了结构清晰的表字段，后续接大模型、接数据库都省心。

4. 动态参数进阶：把用户输入和上游数据变成请求参数

“5分钟搞定天气API对接”里，最大的隐藏门槛不是HTTP请求本身，而是动态参数。很多人在节点里填了固定城市能跑通，但用户一换城市就歇菜。

4.1 让URL里的参数跟着用户输入走

在工作流的“开始”节点里加一个输入参数，比如叫“查询城市”，类型选字符串。然后在HTTP请求节点的URL里，把{{城市}}替换成{{开始.查询城市}}——也就是引用Start节点的输入参数。

这样用户在对话里说“查一下上海天气”，对话流把“上海”传给工作流的查询城市参数，HTTP节点就用上海去请求天气API。一个最简单的动态参数就完成了。

但这里有个细节：用户输入的是“上海”这两个汉字，而心知天气默认接受的location参数是拼音shanghai或城市ID。直接在URL里塞中文，大部分API会返回空数据或报错。这时就需要一个“参数转换”步骤。

4.2 用大模型节点做城市名标准化

在城市名传给HTTP节点之前，先经过一个大模型节点，输入是用户的原始表达，输出是一个标准化结构。

举个例子：用户说“帮我看看深圳明天会不会下雨”。大模型节点提取出：

• 城市实体：深圳
• 查询时间：明天
• 查询意图：降水概率

然后输出一个JSON：

{ "city": "shenzhen", "date": "tomorrow" }

我一般让大模型直接输出拼音，省去一层转换。如果担心同音字或生僻城市名问题，可以在Prompt里加一句“输出英文拼音小写，不带声调，多字城市用下划线分隔”，模型基本都能理解。

这样HTTP请求节点里的URL就可以写成：

https://api.seniverse.com/v3/weather/now.json?key=你的密钥&location={{大模型输出.city}}&language=zh-Hans&unit=c

4.3 从上游节点的输出里取字段

动态参数除了来自用户输入，还有一个常见来源是上游节点的输出。

举例：工作流里先有一个“IP定位”节点，根据用户的IP解析出所在城市，再把城市名传给天气节点。这种场景下，HTTP请求节点引用变量时，在配置面板的变量列表里找到“IP定位”节点的输出字段就行。

再比如，你先通过一个“意图识别”节点来判断用户是不是在问天气，如果是，把识别到的城市字段作为参数传给接下来的HTTP请求节点。这其实已经是一个多节点联动的动态编排了。

4.4 多城市批量查询：动态参数的进一步玩法

如果用户的需求是一口气查三个城市的天气，需要用到列表或循环思路。

第一种做法：在HTTP请求节点前面加一个代码节点，把用户输入的城市列表拆开，依次去请求天气API。但代码节点里没法直接发HTTP请求（除非用fetch），而Coze的代码节点运行环境对跨域请求有限制，所以更适合的做法是：把城市列表传给HTTP节点，在URL中使用一个参数传递多个城市。

很多天气API支持用英文逗号拼接多个location参数，比如location=beijing,shanghai,guangzhou，返回的JSON里会包含多条结果。这种方案最简单。

第二种做法：在工作流里复制三个HTTP节点，让它们并行跑，每个节点负责一个城市，最后用一个代码节点或大模型节点把结果汇总。Coze工作流支持多个节点并行执行，效率很高。我之前做城市对比场景就是这么玩的，三个HTTP节点同时发出请求，返回后统一汇总，响应时间比串行快很多。

这里的核心心得是：能并行就别串行，能让API做批量就别自己循环。第三方API的设计往往已经考虑了批量查询场景，多读文档能省很多事。

5. 故障排查实录：我踩过的五个坑与排除方法

HTTP请求节点本身不难，难的是出问题时你一脸懵。下面列几个我在实际对接中踩过的坑，按频率从高到低排。

5.1 城市名用中文导致返回空数据

现象：URL里写location=北京，返回结果里status_code是200，但results是空数组，或者直接报错param location is invalid。

原因：API要求拼音或城市ID，中文城市名没法直接识别。

排除方法：在调试阶段，先用浏览器手动请求接口，用英文拼音确认能返回数据。在你的Coze工作流里，增加一个大模型节点做“中文城市名转拼音”的处理。我就是给大模型节点加了这样一段Prompt：

你是城市名转换助手。用户会输入城市名，你输出对应的小写拼音，不要输出其他内容。例如“上海”输出“shanghai”。

跑通之后，这个节点就成了一个可复用的“参数预处理器”。

5.2 HTTP 403但密钥看起来没问题

现象：请求返回403 Forbidden，但key确认没抄错，浏览器里访问也正常。

原因：大概率是免费版额度用完了，或者密钥没有生效（尤其刚申请完的那几分钟）。

排除方法：先看响应体里的错误信息。心知天气在配额耗尽时返回的是一个JSON，里面有code和message字段，message会直接说明是API limit reached还是invalid key。Coze的HTTP节点在非2xx状态码时也有“响应体”这个概念，点开节点运行详情就能看到原始报错。不要只看状态码，状态码只告诉你不对，返回体才告诉你哪里不对。

5.3 响应解析成了字符串，大模型读不懂

现象：HTTP节点返回的是一整段JSON文本，大模型节点接收到后胡言乱语，或者告诉你“我无法解析这段数据”。

原因：HTTP节点没有配置响应解析，输出的是原始响应文本，大模型要在一片JSON里找答案，效果自然差。

排除方法：如第3.4节所说，在HTTP节点配置好JSON解析，把关键字段提取成独立变量，再把这些变量传给大模型。

我用一段Prompt来让大模型根据变量生成回答：

你是天气播报助手，根据以下结构化数据生成一段简短播报。 城市：{{城市}} 天气：{{天气现象}} 温度：{{温度}}摄氏度 请用自然语言说出结果，不要重复JSON字段。

这样大模型拿到的输入就是干净的结构数据，输出质量会好非常多。

5.4 请求超时

现象：节点运行报错，错误信息提示超时。

原因：第三方API偶尔响应慢，或者Coze节点默认超时时间比较短。

排除方法：在HTTP节点配置面板里找到超时设置（不同版本位置不同，通常在“高级”或“设置”里），把超时时间从默认值调大到10秒或15秒。天气API正常响应都在几百毫秒，但如果遇到服务商接口波动，多几秒容错能明显降低偶发失败率。

我见过有人为了追求速度把超时设成1秒，结果用户体验极差。合理的做法是：超时设长一点，同时在工作流层面加一个失败重试机制，这远比硬调超时来得稳。

5.5 城市重名导致查错地方

现象：用户说“查一下西安”，结果查出来的是江苏的某个区县，或者压根解析错城市。

原因：国内地名重名情况不少，API默认按拼音解析时可能命中重名城市。

排除方法：在预处理节点里就把目标城市确定好。可以让大模型输出城市ID而不是拼音，比如心知天气提供城市ID列表，WX4FBXXFKE4F就是北京。当用户输入城市名时，让大模型在城市表里精确匹配，返回城市ID，再传给天气API。虽然多了一步，但准确性提升是实打实的。

最后给一个排查顺序备忘表，出问题按这个顺序看，能省不少时间：

6. 落地扩展思路：从单次查询到完整天气服务

天气查询通道搭好之后，实际上你已经拥有了一套可复用的“HTTP数据获取能力”。顺着这条链路，可以很自然地扩展出更实用的功能。

6.1 定时天气播报

把工作流接入定时触发，每天早上7点自动跑一次。HTTP节点查当前城市天气，大模型节点生成“今日天气+穿衣建议+通勤提醒”，推送到目标群或用户私聊。这种自动化场景非常能体现工作流编排的价值，比用户手动问天气高一个层次。

6.2 多维度数据并行拉取

天气只是一个起点。想做一个完整的“出行助手”，还可以同时拉空气质量、风力风向、生活指数（紫外线、洗车指数）。每个数据源对应一个HTTP节点，在工作流里并行执行，全部完成后用一个汇总节点集中整理。这样用户的等待时间不会因为数据源变多而线性增加。

6.3 结果缓存降低API消耗

免费API额度有限，一天几十次调用可能就触顶了。一个简单有效的做法是在工作流里加一个“检查缓存”的前置节点：先查一下数据库或变量里有没有“今天北京天气”的结果，有就直接用，没有再调API，并把结果存起来。对于天气这种一天之内变化不大的数据，缓存策略能省下70%以上的API调用量。

我在实际项目中就是把天气数据和穿衣建议一起缓存，用户重复问同一个城市时，完全走缓存通道，既快又不花钱。

6.4 把天气数据接入更复杂的判断逻辑

比如用户问“明天适合洗车吗”，大模型节点要先判断这是一个需要天气数据支撑的问题，提取城市和时间，再触发天气查询节点拿到明天下雨概率，最后结合“下雨概率>50%则不建议洗车”的规则输出答案。这条链路里的天气查询节点，本质上就是你已经在用的HTTP请求节点，唯一区别是参数是从多轮上下文里拼出来的。

我在做这类场景时的一个心得是：把HTTP请求节点当作服务端API的代理来用，所有业务参数都尽量留成变量，做成一个足够通用的节点，然后从不同分支传入不同的参数值。这比每个场景都单独配一个HTTP节点要清爽得多。

对我个人来说，天气API接入Coze是理解HTTP请求节点最合适的练手项目，没有之一。它表面简单，但把参数传递、响应解析、异常处理这些基本功都完整过了一遍。把这个流程吃透，后面接任何REST API都会顺畅很多。你如果也在对接其他API时卡住了，不妨先回到天气这个最小的闭环，从头排查一遍，很多问题其实是相通的。