在Coze里搭智能体的人八成都会卡在同一个地方怎么让智能体拿到实时数据。知识库解决不了天气、股票、快递这类天天在变的信息。插件商店里倒是有现成的天气插件但真要对接自己选定的数据源或者想把参数做得灵活一点就得靠HTTP请求节点。这篇文章就用天气API做一条完整链路从选服务商、拿密钥到在Coze里配置请求、解析返回结果再让参数跟着用户输入动态变化。整个流程跑通之后你会发现接任何REST API的路数都是一样的天气只是最小、最好验证的练手场景。1. 为什么拿天气API练手HTTP请求节点要解决的三个痛点先说个很常见的场景。你做了一个“生活助手”智能体用户问“今天北京穿什么”知识库给不了答案因为天气是实时数据。你第一反应是去插件商店找天气插件装上之后发现能用但总觉得别扭插件返回的字段是固定的你没法决定它预留哪些信息也没法把天气数据和后续的穿衣建议、通勤提醒串成一条完整的处理链。这就是第一个痛点——内置插件是黑盒变量不可控。第二个痛点是数据源绑死。插件商店里的天气数据源是平台定好的如果公司内部有一套自建气象服务或者你更信任某个特定服务商的预报精度插件方案就直接废掉了。这时候需要的是一个“万能插座”给我一个URL和一套参数规则我自己决定调谁、怎么调。第三个痛点是参数不灵活。用户可能说“北京”“北京市”“首都”也可能说“帮我看看明天上海会不会下雨”。固定参数的插件没办法处理这种动态入参而HTTP请求节点可以把用户输入直接拼进请求地址里请求参数跟着上下文走。这里我强烈建议用天气API练手因为它几乎是HTTP接口里最友好的一种GET请求为主没有复杂的OAuth签名流程返回的JSON结构简单直观免费额度对个人开发完全够用。把天气这条链路走通再去看那些需要POST、需要签名、需要处理分页的业务接口心态会稳很多。提示本文按Coze工作流中的“HTTP请求”节点来写也就是在“工作流”里添加节点时看到的那个HTTP Request。如果你用的是新版界面入口可能变成“扩展/工具”里的自定义HTTP调用但底层的配置逻辑是互通的。2. 接天气数据前的准备选哪个服务商密钥怎么拿天气API服务商很多国内用得比较多的是心知天气、和风天气高德开放平台也提供天气查询接口。我三个都用过给你一个直观的对比服务商免费额度返回格式适合场景备注心知天气免费版每日有调用量限制个人测试够用JSON结构简单实时天气/生活指数入门学习、轻量应用文档清晰返回字段少和风天气免费版有按日配额需实名认证JSON数据全面含分钟级降水专业天气服务、需要丰富气象数据功能强但字段多新手容易看花眼高德开放平台按量计费有免费调用额度JSON和地图生态打通已有高德地图相关业务需先创建应用再开通API如果是第一次做对接我推荐从心知天气开始。它的实时天气接口返回结果很小一眼能看懂非常适合先跑通逻辑。注册账号后在控制台创建一个“我的API”拿到一个形如你的私钥的字符串这就是密钥key。和风天气的流程也类似注册后在控制台创建应用选好API产品比如“天气实况”会生成一个key。注意和风要求实名认证认证没通过之前调用会报错我第一次等了两小时才生效。高德则要在控制台创建一个“应用”给应用添加“天气查询”API然后在应用管理里拿到key。密钥拿到后强烈建议你先在浏览器或Postman里手动调一次接口确认能返回数据再进Coze操作。这一步能省很多后面排查问题的时间。以心知天气为例一个最简单的实时天气请求长这样https://api.seniverse.com/v3/weather/now.json?key你的密钥locationbeijinglanguagezh-Hansunitc把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{{城市}}languagezh-Hansunitc这个{{城市}}就是动态参数的雏形。在城市变量尚未定义之前先用它占住位置。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:0008: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}}languagezh-Hansunitc4.3 从上游节点的输出里取字段动态参数除了来自用户输入还有一个常见来源是上游节点的输出。举例工作流里先有一个“IP定位”节点根据用户的IP解析出所在城市再把城市名传给天气节点。这种场景下HTTP请求节点引用变量时在配置面板的变量列表里找到“IP定位”节点的输出字段就行。再比如你先通过一个“意图识别”节点来判断用户是不是在问天气如果是把识别到的城市字段作为参数传给接下来的HTTP请求节点。这其实已经是一个多节点联动的动态编排了。4.4 多城市批量查询动态参数的进一步玩法如果用户的需求是一口气查三个城市的天气需要用到列表或循环思路。第一种做法在HTTP请求节点前面加一个代码节点把用户输入的城市列表拆开依次去请求天气API。但代码节点里没法直接发HTTP请求除非用fetch而Coze的代码节点运行环境对跨域请求有限制所以更适合的做法是把城市列表传给HTTP节点在URL中使用一个参数传递多个城市。很多天气API支持用英文逗号拼接多个location参数比如locationbeijing,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。虽然多了一步但准确性提升是实打实的。最后给一个排查顺序备忘表出问题按这个顺序看能省不少时间顺序检查项做法1请求是否成功发出用Postman或浏览器先请求一次接口2状态码2xx说明请求通4xx看鉴权和参数5xx看服务商3响应体点开Coze节点运行详情看原始返回4参数编码中文参数URL编码是否正确5解析路径JSONPath表达式是否对应实际返回结构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时卡住了不妨先回到天气这个最小的闭环从头排查一遍很多问题其实是相通的。