围绕一个真实出行目标连续提问，看 AI 能不能在不同阶段正确选择航班列表、机场天气、延误风险和实时动态等 Tool。

台风天出行，是我觉得特别适合拿 AI Agent 来测试的一个场景。毕竟今年我们大大小小经历很多台风。

正常天气下选航班，可能看看时间和价格就够了。但遇到台风，问题会一下变复杂：哪些航班可选？哪个时间段的机场天气更差？几个时间接近的航班，谁的延误或取消风险相对更低？临近出发以后，实际运行状态又有没有变化？

这些信息原本分散在不同的数据能力里。最近正好在折腾 Trae 和 MCP，我就想试一个更接近真实出行决策的场景：围绕同一个出行目标持续和 AI 对话，看它在不同阶段能不能选对 Tool，并把前后获得的数据衔接起来。

先说明一点：这次我更关注的是 Agent 能不能正确拆任务、选 Tool、理解数据边界，而不是用某一天的结果证明“哪一个航班一定更稳”。台风、天气和航班运行都在变化，预测只能作为相对比较依据。

我把航班管家的航空数据 MCP 接进 Trae。它目前提供航班动态、机场对航班查询、航班舒适度、未来延误及取消风险、机场未来天气、飞行轨迹，以及全国民航每日运行总览、机场运行统计、航司运行统计等 9 个 Tool。

第一步：先处理机场歧义，再找候选航班

这个问题看起来很自然，但里面其实先藏着一个航空数据里的典型坑：我只说了“上海”，没有指定具体机场。

上海属于多机场城市。如果上下文无法确定具体机场，Agent 不应该擅自把城市名称补成某一个机场三字码。更稳妥的做法，是先确认我能接受哪些机场，再继续查询。

为了不把这个歧义带进后面的比较，我会把条件补完整，例如：上海两个机场都可以接受，再分别查询符合条件的航班。

这一步对应的是机场对航班查询 Tool：dast_flight_route。它解决的是“有哪些航班可选”，而不是一上来就查某一个航班的实时动态。

这里我比较看重的一点是：Agent 面对的是用户意图。机场对查询、单个航班动态、天气和延误预测虽然都和航班有关，但实际上是不同的业务动作。

第二步：有了候选航班，再看机场天气

拿到候选航班以后，我不会立刻让 AI 给结论，而是继续补天气背景。

这时候 Agent 需要继续调用 dast_future_weather。

同一个“帮我选航班”的任务，到这里已经不是一次提问对应一次 API，而是先找到候选航班，再补充机场天气。更接近真实的 Agent 使用方式，是围绕同一个目标连续补充需求，由 Agent 在每一轮判断应该调用哪类数据能力。

当然，天气信息只能说明运行背景，不能直接推出某个航班一定延误或取消。所以我不会在这一步让它直接下结论。

第三步：把候选航班的延误和取消风险拉出来

天气看完以后，真正需要比较的是：在这些候选航班里，哪些航班当前预测的运行风险相对更低？

对应的 Tool 是 dast_delay_rate，用于提供未来延误概率和取消风险。

这里有一个非常重要的边界：预测概率不能被 Agent 写成确定事实。

更稳妥的表达应该是“某航班当前预测的延误风险相对较低，可以优先关注”，而不是“这个航班肯定不会延误”。

换句话说，这一步真正要做的不是让 AI 给出一个“保证不延误”的答案，而是把候选航班放到同一套预测口径下做相对比较。

第四步：临近出发，再查一次实时航班动态

如果最后已经选定了某个航班，到了出发当天，我会把问题切换到实时状态：

这时候才应该调用 dast_flight_dynamic，查询指定航班的实时运行状态。

需要注意的是，如果没有额外的定时任务或监控机制，单纯一次 MCP 调用并不等于 Agent 会在后台持续关注航班变化。因此这里更准确的动作是“出发当天再次查询”。

这样一来，整条任务链就比较清楚了

候选航班查询  →  dast_flight_route

机场未来天气  →  dast_future_weather

延误 / 取消风险  →  dast_delay_rate

出发当天实时状态  →  dast_flight_dynamic

这四个 Tool 原本是独立的数据能力，但放到 Agent 里以后，可以围绕一个真实目标串成一条连续任务链。

我觉得这个场景真正值得测试的，不是“AI 会不会查航班”

如果只是问“某个航班今天几点起飞”，传统航班查询工具已经能很好解决。

但“明天台风，我必须从上海去广州，帮我从可选航班里找一个相对稳妥的方案”不是一个接口就能回答的问题。

AI 至少要完成几件事：先把机场范围说清楚，再找到候选航班；根据候选航班继续补天气；再比较延误和取消风险；最后到了出发当天，把关注点切换到实时航班动态。

所以这次测试里，我更关注的不是它有没有调用成功某一个 Tool，而是它有没有把“航班可选性 → 天气背景 → 预测风险 → 实时状态”这几层信息放在正确的位置上。

如果 Agent 能做到这一点，MCP 的价值就不只是“多了一个查询接口”，而是让多个专业数据能力可以围绕同一个任务被组合起来。

还有两个很容易被忽略的细节

第一，航空数据里的日期并不只是一个 YYYY-MM-DD。航班动态和机场对查询的日期，需要按航班出发机场当地自然日理解；全国、机场和航司运行统计则使用北京时间自然日。参数格式正确，不代表业务语义一定正确。

第二，机场三字码不要让模型在不确定时猜。像北京、上海这类多机场城市，如果上下文无法确定具体机场，更稳妥的做法是先确认机场范围，而不是自己补全。

这些细节看起来不像“台风天选航班”的主角，但恰恰决定了 Agent 能不能稳定地把专业数据用对。

最后：这类结果应该怎么理解

这类场景最适合让 Agent 做的是“整理和比较”，而不是替用户做确定性承诺。机场天气和延误风险都可能随着时间变化，临近出行仍然需要重新查看实时航班动态，并以航空公司、机场等实际运行信息为准。

对我来说，这次场景测试比较有意思的地方就在这里：我不需要自己处理每个接口的参数和返回结构，只需要围绕同一个出行目标持续提问，再看 Agent 能不能在不同阶段选择合适的航空数据 Tool、衔接前面已经拿到的信息，并把它们组织成一条可用的决策链。

接入信息

航班管家航空数据 MCP

Remote MCP Endpoint：https://fly.huoli.com/mcp/dast_mcp

目前包括航班动态、机场对查询、航班舒适度、未来延误及取消风险、机场未来天气、飞行轨迹及民航运行统计等 9 项 Tool。